From jm at poure.com Wed Jul 1 03:25:22 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Wed, 01 Jul 2009 12:25:22 +0200 Subject: Looking for a solution to compile MacPorts and maintain my packages Message-ID: <1246443922.5450.4.camel@localhost> Dear friends, I am looking for a solution to share a Mac OS X computer between Kdenlive developers (VNC) and also to maintain my MacPorts packages (SSH). After running into the wall looking for an emulator or trying FreeDarwin, I see two solutions: 1) Buy a cheap Mac mini for 600? 2) Invest in a cheap G4, with Mac OS 10.4 for 100? So my question is: do you think MacPorts can be installed and upgraded on any old computer like the G4 (PPC) and MacOS 10.4? Are some packages in MacPorts dependent on Mac OS 10.5? Do you plan to continue on PPC or will you abandon PPC one day? Kind regards, Jean-Michel From jmr at macports.org Wed Jul 1 03:40:03 2009 From: jmr at macports.org (Joshua Root) Date: Wed, 01 Jul 2009 20:40:03 +1000 Subject: Looking for a solution to compile MacPorts and maintain my packages In-Reply-To: <1246443922.5450.4.camel@localhost> References: <1246443922.5450.4.camel@localhost> Message-ID: <4A4B3D03.9050909@macports.org> On 2009-7-1 20:25, Jean-Michel Pour? wrote: > So my question is: do you think MacPorts can be installed and upgraded > on any old computer like the G4 (PPC) and MacOS 10.4? Are some packages > in MacPorts dependent on Mac OS 10.5? Do you plan to continue on PPC or > will you abandon PPC one day? Yes, MacPorts works on 10.4 PPC. Yes, some ports need 10.5 (not many at present). Yes, we will most likely abandon PPC one day, probably at the same time we drop support for 10.5, which is to say, not for quite a while yet. Our policy is to try to support the two latest OS X releases. Panther has therefore been unsupported for some time, but still works as of MacPorts 1.7. (MacPorts 1.8 will no longer work on Panther.) When Snow Leopard ships in September, Tiger will become unsupported as per policy. Like Panther, though, it will probably more or less work for quite a while still. - Josh From jkorchok at hotmail.com Wed Jul 1 07:19:30 2009 From: jkorchok at hotmail.com (John Korchok) Date: Wed, 1 Jul 2009 10:19:30 -0400 Subject: Looking for a solution to compile MacPorts and maintain my packages In-Reply-To: <1246443922.5450.4.camel@localhost> References: <1246443922.5450.4.camel@localhost> Message-ID: We have 2 G4 and 2 Intel Mac minis with OSX 10.4, MacPorts and full MAMP installations , all completely updated, that we use on a daily basis with no problems. You can pick them up on eBay quite inexpensively, they're a good development solution. John Korchok -----Original Message----- From: macports-dev-bounces at lists.macosforge.org [mailto:macports-dev-bounces at lists.macosforge.org] On Behalf Of Jean-Michel Pour? Sent: Wednesday, July 01, 2009 6:25 AM To: macports-dev Subject: Looking for a solution to compile MacPorts and maintain my packages Dear friends, I am looking for a solution to share a Mac OS X computer between Kdenlive developers (VNC) and also to maintain my MacPorts packages (SSH). After running into the wall looking for an emulator or trying FreeDarwin, I see two solutions: 1) Buy a cheap Mac mini for 600? 2) Invest in a cheap G4, with Mac OS 10.4 for 100? So my question is: do you think MacPorts can be installed and upgraded on any old computer like the G4 (PPC) and MacOS 10.4? Are some packages in MacPorts dependent on Mac OS 10.5? Do you plan to continue on PPC or will you abandon PPC one day? Kind regards, Jean-Michel _______________________________________________ macports-dev mailing list macports-dev at lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From jm at poure.com Wed Jul 1 13:04:14 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Wed, 01 Jul 2009 22:04:14 +0200 Subject: Looking for a solution to compile MacPorts and maintain my packages In-Reply-To: <4A4B3D03.9050909@macports.org> References: <1246443922.5450.4.camel@localhost> <4A4B3D03.9050909@macports.org> Message-ID: <1246478654.4530.5.camel@localhost> On Wed, 2009-07-01 at 20:40 +1000, Joshua Root wrote: > - Josh Thanks for all these information. Finally I bought a dual processor Powermac G4 for 99?: http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=260437468424 It comes with Mac OS X 10.4, but I will try to upgrade it to 10.5. Then I will start compiling and try to chase bugs under PowerMac. I also release Live DVDs and USB keys for Kdenlive: http://www.kdenlive.org/user-manual/downloading-and-installing-kdenlive/live-demonstration-dvd-or-usb-storage I will try to release PPC USB keys. So this is the program. Thanks for your support. Bye, Jean-Michel From toby at apple.com Wed Jul 1 13:06:55 2009 From: toby at apple.com (Toby Peterson) Date: Wed, 1 Jul 2009 13:06:55 -0700 Subject: Looking for a solution to compile MacPorts and maintain my packages In-Reply-To: <1246478654.4530.5.camel@localhost> References: <1246443922.5450.4.camel@localhost> <4A4B3D03.9050909@macports.org> <1246478654.4530.5.camel@localhost> Message-ID: On Jul 1, 2009, at 1:04 PM, Jean-Michel Pour? wrote: > Finally I bought a dual processor Powermac G4 for 99?: > http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=260437468424 > > It comes with Mac OS X 10.4, but I will try to upgrade it to 10.5. > Then > I will start compiling and try to chase bugs under PowerMac. Getting Leopard running on that machine will be quite an adventure... - Toby From dluke at geeklair.net Wed Jul 1 13:28:04 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed, 1 Jul 2009 16:28:04 -0400 Subject: Looking for a solution to compile MacPorts and maintain my packages In-Reply-To: References: <1246443922.5450.4.camel@localhost> <4A4B3D03.9050909@macports.org> <1246478654.4530.5.camel@localhost> Message-ID: On Jul 1, 2009, at 4:06 PM, Toby Peterson wrote: > On Jul 1, 2009, at 1:04 PM, Jean-Michel Pour? wrote: >> Finally I bought a dual processor Powermac G4 for 99?: >> http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=260437468424 >> >> It comes with Mac OS X 10.4, but I will try to upgrade it to 10.5. >> Then >> I will start compiling and try to chase bugs under PowerMac. > > Getting Leopard running on that machine will be quite an adventure... Really? I have 10.5 running on a similar machine. Admittedly, the upgrade didn't go smoothly for me, but it wasn't too difficult to get working. http://www.geeklair.net/~dluke/archives/2008/01/geeklairnet-105-upgrade-notes.html -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From toby at apple.com Wed Jul 1 13:29:45 2009 From: toby at apple.com (Toby Peterson) Date: Wed, 1 Jul 2009 13:29:45 -0700 Subject: Looking for a solution to compile MacPorts and maintain my packages In-Reply-To: References: <1246443922.5450.4.camel@localhost> <4A4B3D03.9050909@macports.org> <1246478654.4530.5.camel@localhost> Message-ID: On Jul 1, 2009, at 1:28 PM, Daniel J. Luke wrote: > On Jul 1, 2009, at 4:06 PM, Toby Peterson wrote: >> On Jul 1, 2009, at 1:04 PM, Jean-Michel Pour? wrote: >>> Finally I bought a dual processor Powermac G4 for 99?: >>> http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=260437468424 >>> >>> It comes with Mac OS X 10.4, but I will try to upgrade it to 10.5. >>> Then >>> I will start compiling and try to chase bugs under PowerMac. >> >> Getting Leopard running on that machine will be quite an adventure... > > > Really? I have 10.5 running on a similar machine. > > Admittedly, the upgrade didn't go smoothly for me, but it wasn't too > difficult to get working. > > http://www.geeklair.net/~dluke/archives/2008/01/geeklairnet-105-upgrade-notes.html I'm under the impression that the Leopard installer just bails on older machines. Maybe not though, I don't have any firsthand experience with it. - Toby From dluke at geeklair.net Wed Jul 1 13:36:40 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed, 1 Jul 2009 16:36:40 -0400 Subject: Looking for a solution to compile MacPorts and maintain my packages In-Reply-To: References: <1246443922.5450.4.camel@localhost> <4A4B3D03.9050909@macports.org> <1246478654.4530.5.camel@localhost> Message-ID: <262E853F-463C-4E24-B193-6BEC5BD989EC@geeklair.net> On Jul 1, 2009, at 4:29 PM, Toby Peterson wrote: > I'm under the impression that the Leopard installer just bails on > older machines. Maybe not though, I don't have any firsthand > experience with it. Well, G4's with 867mhz or faster are supported (IIRC), so the installer should run without any LeopardAssist/XPostFacto style hacks. -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jmr at macports.org Wed Jul 1 13:47:37 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 02 Jul 2009 06:47:37 +1000 Subject: Looking for a solution to compile MacPorts and maintain my packages In-Reply-To: <262E853F-463C-4E24-B193-6BEC5BD989EC@geeklair.net> References: <1246443922.5450.4.camel@localhost> <4A4B3D03.9050909@macports.org> <1246478654.4530.5.camel@localhost> <262E853F-463C-4E24-B193-6BEC5BD989EC@geeklair.net> Message-ID: <4A4BCB69.7030907@macports.org> On 2009-7-2 06:36, Daniel J. Luke wrote: > On Jul 1, 2009, at 4:29 PM, Toby Peterson wrote: >> I'm under the impression that the Leopard installer just bails on >> older machines. Maybe not though, I don't have any firsthand >> experience with it. > > > Well, G4's with 867mhz or faster are supported (IIRC), so the installer > should run without any LeopardAssist/XPostFacto style hacks. It's a 450 MHz machine though... - Josh From dweber at macports.org Wed Jul 1 14:16:38 2009 From: dweber at macports.org (Darren Weber) Date: Wed, 1 Jul 2009 14:16:38 -0700 Subject: tar version comparison Message-ID: I need to test if the system has a tar version between 1.14 and 1.14.90, what is the best way to do this in tcl? I have the following tcl script snippet, but there may be an easier way. # tar-1.14 uses --strip-path, tar-1.14.90+ uses --strip-components set tarArg "--strip-components" set tarVersion [lrange [split [exec tar --version]] 3 3] set tarMaj [lrange [split $tarVersion .] 0 0] set tarMin [lrange [split $tarVersion .] 1 1] set tarRev [lrange [split $tarVersion .] 2 2] if ([expr $tarMaj == 1 && $tarMin == 14 && $tarRev < 90]) { set tarArg "--strip-path" } For example, on OSX 10.5.x we get these results from /usr/bin/tar: % set tarVer [lrange [split [exec tar --version]] 3 3] 1.15.1 % set tarMaj [lrange [split $tarVer .] 0 0] 1 % set tarMin [lrange [split $tarVer .] 1 1] 15 % set tarRev [lrange [split $tarVer .] 2 2] 1 % set tarArg "--strip-components" --strip-components % if ([expr $tarMaj == 1 && $tarMin == 14 && $tarRev < 90]) { set tarArg "--strip-path" } % puts $tarArg --strip-components 0 % TIA, Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby at apple.com Wed Jul 1 14:20:42 2009 From: toby at apple.com (Toby Peterson) Date: Wed, 1 Jul 2009 14:20:42 -0700 Subject: tar version comparison In-Reply-To: References: Message-ID: pextlib provides 'rpm-vercomp' which probably does what you want. - Toby On Jul 1, 2009, at 2:16 PM, Darren Weber wrote: > > I need to test if the system has a tar version between 1.14 and > 1.14.90, what is the best way to do this in tcl? > > I have the following tcl script snippet, but there may be an easier > way. > > # tar-1.14 uses --strip-path, tar-1.14.90+ uses --strip-components > set tarArg "--strip-components" > set tarVersion [lrange [split [exec tar --version]] 3 3] > set tarMaj [lrange [split $tarVersion .] 0 0] > set tarMin [lrange [split $tarVersion .] 1 1] > set tarRev [lrange [split $tarVersion .] 2 2] > if ([expr $tarMaj == 1 && $tarMin == 14 && $tarRev < 90]) { > set tarArg "--strip-path" > } > > For example, on OSX 10.5.x we get these results from /usr/bin/tar: > > % set tarVer [lrange [split [exec tar --version]] 3 3] > 1.15.1 > % set tarMaj [lrange [split $tarVer .] 0 0] > 1 > % set tarMin [lrange [split $tarVer .] 1 1] > 15 > % set tarRev [lrange [split $tarVer .] 2 2] > 1 > % set tarArg "--strip-components" > --strip-components > % if ([expr $tarMaj == 1 && $tarMin == 14 && $tarRev < 90]) { > set tarArg "--strip-path" > } > % puts $tarArg > --strip-components > 0 > % > > TIA, > Darren > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From dluke at geeklair.net Wed Jul 1 14:28:23 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed, 1 Jul 2009 17:28:23 -0400 Subject: Looking for a solution to compile MacPorts and maintain my packages In-Reply-To: <4A4BCB69.7030907@macports.org> References: <1246443922.5450.4.camel@localhost> <4A4B3D03.9050909@macports.org> <1246478654.4530.5.camel@localhost> <262E853F-463C-4E24-B193-6BEC5BD989EC@geeklair.net> <4A4BCB69.7030907@macports.org> Message-ID: On Jul 1, 2009, at 4:47 PM, Joshua Root wrote: > On 2009-7-2 06:36, Daniel J. Luke wrote: >> Well, G4's with 867mhz or faster are supported (IIRC), so the >> installer >> should run without any LeopardAssist/XPostFacto style hacks. > > It's a 450 MHz machine though... Yeah, I misread the listing (I don't know french :)). I actually have that same machine (but with a dual 1.2Ghz upgrade card) and it has been running fine with 10.5 for a while (as geeklair.net, actually). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jmr at macports.org Wed Jul 1 15:57:31 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 02 Jul 2009 08:57:31 +1000 Subject: tar version comparison In-Reply-To: References: Message-ID: <4A4BE9DB.1030201@macports.org> On 2009-7-2 07:16, Darren Weber wrote: > > I need to test if the system has a tar version between 1.14 and 1.14.90, > what is the best way to do this in tcl? Toby has answered your question, but it seems like you'd be better off just depending on gnutar rather than messing around doing different things for different tar versions. - Josh From ryandesign at macports.org Wed Jul 1 18:12:50 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 1 Jul 2009 20:12:50 -0500 Subject: Looking for a solution to compile MacPorts and maintain my packages In-Reply-To: References: <1246443922.5450.4.camel@localhost> <4A4B3D03.9050909@macports.org> <1246478654.4530.5.camel@localhost> Message-ID: On Jul 1, 2009, at 15:06, Toby Peterson wrote: > On Jul 1, 2009, at 1:04 PM, Jean-Michel Pour? wrote: > >> Finally I bought a dual processor Powermac G4 for 99?: >> http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=260437468424 >> >> It comes with Mac OS X 10.4, but I will try to upgrade it to 10.5. >> Then >> I will start compiling and try to chase bugs under PowerMac. > > Getting Leopard running on that machine will be quite an adventure... I have Leopard working on my 466-MHz Power Mac G4. So that's a generation or two newer than the 450-MHz G4 Jean-Michel bought. I used LeopardAssist [1] to bypass the 867-MHz Leopard installer check. There are a number of issues. Leopard assumes you have a graphics card at least as new as the 867-MHz Power Mac G4 it requires as a minimum, so on a lesser machine, there are some graphics glitches. The DVD player is useless unless you copy over the graphics drivers for your graphics card from a Tiger installation. And of course these are very slow machines we're talking about, by today's standards. Some of the larger ports take mine days to compile. I have mine set up exclusively to help me fix PowerPC-specific issues I encounter in MacPorts; thankfully those are rare. I would not want to use it as a primary development machine. I don't read French so I couldn't tell if your G4 is a single- or dual-processor model. If dual, you'll want to enable multiple simultaneous build jobs to speed things up. In /opt/local/etc/ macports/macports.conf, set build_make_jobs to the number of simultaneous jobs you want (which some people recommend setting to either the number of processors or cores you have available, or one greater than that number). Set build_make_jobs to 0 and MacPorts will determine the number of processors or cores you have available and use that number of jobs. [1] http://www.mac.profusehost.net/leopardassist/ From jm at poure.com Thu Jul 2 00:55:04 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Thu, 02 Jul 2009 09:55:04 +0200 Subject: Looking for a solution to compile MacPorts and maintain my packages In-Reply-To: <4A4BCB69.7030907@macports.org> References: <1246443922.5450.4.camel@localhost> <4A4B3D03.9050909@macports.org> <1246478654.4530.5.camel@localhost> <262E853F-463C-4E24-B193-6BEC5BD989EC@geeklair.net> <4A4BCB69.7030907@macports.org> Message-ID: <1246521304.17510.5.camel@localhost> On Thu, 2009-07-02 at 06:47 +1000, Joshua Root wrote: > > It's a 450 MHz machine though... Finaly I am buying a 1Ghz G4 with 1Go memory to the same dealer. Thanks. From dweber at macports.org Thu Jul 2 11:54:42 2009 From: dweber at macports.org (Darren Weber) Date: Thu, 2 Jul 2009 11:54:42 -0700 Subject: tar version comparison In-Reply-To: <4A4BE9DB.1030201@macports.org> References: <4A4BE9DB.1030201@macports.org> Message-ID: On Wed, Jul 1, 2009 at 3:57 PM, Joshua Root wrote: > On 2009-7-2 07:16, Darren Weber wrote: > > > > I need to test if the system has a tar version between 1.14 and 1.14.90, > > what is the best way to do this in tcl? > > Toby has answered your question, but it seems like you'd be better off > just depending on gnutar rather than messing around doing different > things for different tar versions. > > - Josh > Yes, so a dependency on gnutar is an option, but what if it's installed with the variant, with_default_names: Install files without 'gnu' prefix I suppose then the script has to check for the right command - tar or gnutar - and if it uses tar there will have to be a check for the version of tar that's called (or at least a check for `which tar` to confirm that it's $prefix/bin/tar). Thanks, Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: From dweber at macports.org Thu Jul 2 11:56:57 2009 From: dweber at macports.org (Darren Weber) Date: Thu, 2 Jul 2009 11:56:57 -0700 Subject: tar version comparison In-Reply-To: References: Message-ID: On Wed, Jul 1, 2009 at 2:20 PM, Toby Peterson wrote: > pextlib provides 'rpm-vercomp' which probably does what you want. > Is this command available in a Portfile? Where are the docs on how to use it? TIA, Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: From dweber at macports.org Thu Jul 2 12:23:34 2009 From: dweber at macports.org (Darren Weber) Date: Thu, 2 Jul 2009 12:23:34 -0700 Subject: tar version comparison In-Reply-To: <4A4BE9DB.1030201@macports.org> References: <4A4BE9DB.1030201@macports.org> Message-ID: On Wed, Jul 1, 2009 at 3:57 PM, Joshua Root wrote: > On 2009-7-2 07:16, Darren Weber wrote: > > > > I need to test if the system has a tar version between 1.14 and 1.14.90, > > what is the best way to do this in tcl? > > Toby has answered your question, but it seems like you'd be better off > just depending on gnutar rather than messing around doing different > things for different tar versions. > > - Josh > Can we assume that a dependency on gnutar will provide either ${prefix}/bin/gnutar or ${prefix}/bin/tar? To check for gnutar or tar, maybe the following could be used: if [file exists ${prefix}/bin/gnutar] { set gnutar ${prefix}/bin/gnutar } elseif [file exists ${prefix}/bin/tar] { set gnutar ${prefix}/bin/tar } # maybe some kind of confirmation that we get gnutar? # exec $gnutar --version To set this variable globally for a Portfile, where is the best place to put it? Assume the dependency on gnutar requires an installation. TIA, Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: From blb at macports.org Thu Jul 2 12:41:42 2009 From: blb at macports.org (Bryan Blackburn) Date: Thu, 2 Jul 2009 13:41:42 -0600 Subject: tar version comparison In-Reply-To: References: Message-ID: <20090702194142.GG35200@ninagal.withay.com> On Thu, Jul 02, 2009 at 11:56:57AM -0700, Darren Weber said: > On Wed, Jul 1, 2009 at 2:20 PM, Toby Peterson wrote: > > > pextlib provides 'rpm-vercomp' which probably does what you want. > > > > Is this command available in a Portfile? Where are the docs on how to use > it? 'man portfile' appears to be the only documentation for it beyond the source, though the docs there are short of verbose: rpm-vercomp versionA versionB Compare two RPM-format versions for equality. This works like strcmp() in that it returns -1, 0, or 1 when versionA is earlier, equal, or later than versionB. Bryan > > TIA, > Darren From kthenriksson at gmail.com Thu Jul 2 13:27:26 2009 From: kthenriksson at gmail.com (Kristofer Henriksson) Date: Thu, 2 Jul 2009 16:27:26 -0400 Subject: tar version comparison In-Reply-To: References: <4A4BE9DB.1030201@macports.org> Message-ID: <4809057c0907021327t7f249cb9w4e880fcd703a76d4@mail.gmail.com> Even with that variant, gnutar will still be available under the name gnutar, so you can always run gnutar without worrying about whether you have that variant or not. The variant just adds symlinks for everything. Regards, Kristofer On Thu, Jul 2, 2009 at 2:54 PM, Darren Weber wrote: > > > On Wed, Jul 1, 2009 at 3:57 PM, Joshua Root wrote: >> >> On 2009-7-2 07:16, Darren Weber wrote: >> > >> > I need to test if the system has a tar version between 1.14 and 1.14.90, >> > what is the best way to do this in tcl? >> >> Toby has answered your question, but it seems like you'd be better off >> just depending on gnutar rather than messing around doing different >> things for different tar versions. >> >> - Josh > > > Yes, so a dependency on gnutar is an option, but what if it's installed with > the variant, > > ? with_default_names: Install files without 'gnu' prefix > > I suppose then the script has to check for the right command - tar or gnutar > - and if it uses tar there will have to be a check for the version of tar > that's called (or at least a check for `which tar` to confirm that it's > $prefix/bin/tar). > > Thanks, > Darren > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > From dweber at macports.org Thu Jul 2 14:19:34 2009 From: dweber at macports.org (Darren Weber) Date: Thu, 2 Jul 2009 14:19:34 -0700 Subject: tar version comparison In-Reply-To: <4809057c0907021327t7f249cb9w4e880fcd703a76d4@mail.gmail.com> References: <4A4BE9DB.1030201@macports.org> <4809057c0907021327t7f249cb9w4e880fcd703a76d4@mail.gmail.com> Message-ID: Oh, great. That should save a bunch of this sort of stuff: #if [file exists ${prefix}/bin/gnutar] { # set gnutar ${prefix}/bin/gnutar #} elseif [file exists ${prefix}/bin/tar] { # set gnutar ${prefix}/bin/tar #} #set tarVer [lrange [split [exec $gnutar --version]] 3 3] #rpm-vercomp $tarVer 1.14.90 # rpm-vercomp versionA versionB # rpm-vercomp works like strcmp() in that it returns -1, 0, or 1 when versionA is # earlier, equal, or later than versionB. Thanks, everyone! Darren On Thu, Jul 2, 2009 at 1:27 PM, Kristofer Henriksson wrote: > Even with that variant, gnutar will still be available under the name > gnutar, so you can always run gnutar without worrying about whether > you have that variant or not. The variant just adds symlinks for > everything. > > Regards, > Kristofer > > On Thu, Jul 2, 2009 at 2:54 PM, Darren Weber wrote: > > > > > > On Wed, Jul 1, 2009 at 3:57 PM, Joshua Root wrote: > >> > >> On 2009-7-2 07:16, Darren Weber wrote: > >> > > >> > I need to test if the system has a tar version between 1.14 and > 1.14.90, > >> > what is the best way to do this in tcl? > >> > >> Toby has answered your question, but it seems like you'd be better off > >> just depending on gnutar rather than messing around doing different > >> things for different tar versions. > >> > >> - Josh > > > > > > Yes, so a dependency on gnutar is an option, but what if it's installed > with > > the variant, > > > > with_default_names: Install files without 'gnu' prefix > > > > I suppose then the script has to check for the right command - tar or > gnutar > > - and if it uses tar there will have to be a check for the version of tar > > that's called (or at least a check for `which tar` to confirm that it's > > $prefix/bin/tar). > > > > Thanks, > > Darren > > > > > > _______________________________________________ > > macports-dev mailing list > > macports-dev at lists.macosforge.org > > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Fri Jul 3 06:24:30 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 3 Jul 2009 08:24:30 -0500 Subject: tar version comparison In-Reply-To: References: Message-ID: On Jul 2, 2009, at 13:56, Darren Weber wrote: > On Wed, Jul 1, 2009 at 2:20 PM, Toby Peterson wrote: > >> pextlib provides 'rpm-vercomp' which probably does what you want. > > Is this command available in a Portfile? Where are the docs on how > to use it? I don't know if it was originally intended for rpm-vercomp to be used from portfiles, but it is currently being used in several portfiles to check that the user has a new enough version of Xcode installed; see e.g. libpixman. I also sometimes use it to check that the version of an installed dependency is new enough; see e.g. pango. From kingst at uiuc.edu Fri Jul 3 07:38:29 2009 From: kingst at uiuc.edu (Sam King) Date: Fri, 3 Jul 2009 09:38:29 -0500 Subject: help with portfile for qt4-x11 4.5.2 Message-ID: <4A4E17E5.4030703@uiuc.edu> Hello, I have been working on a Portfile for qt4-x11 4.5.2 and I have run into some problems. I am able to compile and install the library, but when I launch any qt applications none of the fonts work properly. They all show up as squares instead of characters, and some applications, like qtdemo-x11, end up creating directories in the current directory I am in, and the directory names use a unicode character set (perhaps Japanese or a Chinese language). I tried changing to a few random fonts using qtconfig (I am not sure which fonts I chose though since the names were spelled out using squares), but it did not help. I attached my current Portfile, it is based of the qt4-x11 4.4.3 portfile with a few tweaks. Note: qt4-x11 4.4.3 works fine on my system. Thanks! --Sam -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Portfile URL: From vince at macports.org Fri Jul 3 09:39:42 2009 From: vince at macports.org (vincent habchi) Date: Fri, 3 Jul 2009 18:39:42 +0200 Subject: help with portfile for qt4-x11 4.5.2 In-Reply-To: <4A4E17E5.4030703@uiuc.edu> References: <4A4E17E5.4030703@uiuc.edu> Message-ID: Le 3 juil. 09 ? 16:38, Sam King a ?crit : > Hello, > > I have been working on a Portfile for qt4-x11 4.5.2 and I have run > into some problems. I am able to compile I was planning to work on the aqua version, and I can't help you much with this one. But, tell me, what's the point of X11 version? Is it because some other application link both to qt4 and x11 ? Vincent From kingst at uiuc.edu Fri Jul 3 11:27:37 2009 From: kingst at uiuc.edu (Sam King) Date: Fri, 3 Jul 2009 13:27:37 -0500 Subject: help with portfile for qt4-x11 4.5.2 In-Reply-To: References: <4A4E17E5.4030703@uiuc.edu> Message-ID: <4A4E4D99.8070308@uiuc.edu> Hi Vincent, The reason I am interested in the x11 version is because I have an application that uses the X11Embed functionality to embed a widget from one process into another. If there is a generic Qt way to do this, or even a aqua specific way to do this, I would be willing to switch. --Sam From talklists at newgeo.com Fri Jul 3 15:12:07 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 3 Jul 2009 15:12:07 -0700 Subject: Active port install isssue Message-ID: <30D1FED1-D9BF-4A02-9CB1-80ED0BF6ACBE@newgeo.com> Clean install of my never-ending ASSP portfile project... Error: Target org.macports.activate returned: Image error: /opt/local/ bin/spfquery is being used by the active p5-mail-spf port. Please deactivate this port first, or use 'port -f activate p5-mail-spf- query' to force the activation. Warning: the following items did not execute (for p5-mail-spf-query): org.macports.activate Error: The following dependencies failed to build: p5-mail-spf-query p5-mail-srs p5-net p5-authen-sasl p5-gssapi p5-crypt-des p5-digest p5- net-ip-match-regexp p5-net-senderbase p5-net-syslog p5-perl-ldap p5- convert-asn1 p5-xml-parser p5-xml-sax-writer p5-text-iconv p5-xml- filter-buffertext p5-sys-syslog p5-tie-dbi p5-dbi p5-time-hires Error: Status 1 encountered during processing. I am not sure I understand this one. I know how to work around it, but I am looking for how to make the problem not be a problem for a user who is installing. Here is the list of depends: depends_lib \ port:p5-compress-zlib \ port:p5-digest-md5 \ port:p5-digest-sha1 \ port:p5-email-mime-modifier \ port:p5-email-send \ port:p5-email-valid \ port:p5-file-readbackwards \ port:p5-io-socket-ssl \ port:p5-libwww-perl \ port:p5-mail-spf \ port:p5-mail-spf-query \ port:p5-mail-srs \ port:p5-net \ port:p5-net-cidr-lite \ port:p5-net-dns \ port:p5-net-ip-match-regexp \ port:p5-net-senderbase \ port:p5-net-syslog \ port:p5-perl-ldap \ port:p5-sys-syslog \ port:p5-tie-dbi \ port:p5-time-hires -- Scott * If you contact me off list replace talklists@ with scott@ * From talklists at newgeo.com Fri Jul 3 22:29:01 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 3 Jul 2009 22:29:01 -0700 Subject: Active port install isssue In-Reply-To: <30D1FED1-D9BF-4A02-9CB1-80ED0BF6ACBE@newgeo.com> References: <30D1FED1-D9BF-4A02-9CB1-80ED0BF6ACBE@newgeo.com> Message-ID: <38EEAA40-48ED-4730-9B05-E8C8F09D340C@newgeo.com> Yeah, I do not get this: $sudo port -d install p5-mail-spf Installs clean... $sudo port -d install p5-mail-spf-query ---> Activating p5-mail-spf-query @1.999.1_0 Error: Target org.macports.activate returned: Image error: /opt/local/ bin/spfquery is being used by the active p5-mail-spf port. Please deactivate this port first, or use 'port -f activate p5-mail-spf- query' to force the activation. Warning: the following items did not execute (for p5-mail-spf-query): org.macports.activate Error: Status 1 encountered during processing. /opt/local/bin/spfquery is not being used by p5-mail-spf, unless I misunderstand what port contents is showing me. I had a 99% flawless install of ASSP and all it's chunks, but this one hitch, and I am going to have to add a -f to the install process? $port contents p5-mail-spf Port p5-mail-spf contains: /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/Mail/ SPF/.packlist /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Base.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Exception.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/MacroString.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/A.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/All.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/Exists.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/Include.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/IP4.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/IP6.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/MX.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/PTR.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mod/Exp.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mod/Redirect.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mod.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Record.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Request.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Result.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/SenderIPAddrMech.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Server.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Term.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Util.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/v1/Record.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/v2/Record.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF.pm /opt/local/sbin/spfd /opt/local/share/man/man3/Mail::SPF.3pm.gz /opt/local/share/man/man3/Mail::SPF::Base.3pm.gz /opt/local/share/man/man3/Mail::SPF::MacroString.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::A.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::All.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::Exists.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::Include.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::IP4.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::IP6.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::MX.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::PTR.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mod.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mod::Exp.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mod::Redirect.3pm.gz /opt/local/share/man/man3/Mail::SPF::Record.3pm.gz /opt/local/share/man/man3/Mail::SPF::Request.3pm.gz /opt/local/share/man/man3/Mail::SPF::Result.3pm.gz /opt/local/share/man/man3/Mail::SPF::SenderIPAddrMech.3pm.gz /opt/local/share/man/man3/Mail::SPF::Server.3pm.gz /opt/local/share/man/man3/Mail::SPF::Term.3pm.gz /opt/local/share/man/man3/Mail::SPF::Util.3pm.gz /opt/local/share/man/man3/Mail::SPF::v1::Record.3pm.gz /opt/local/share/man/man3/Mail::SPF::v2::Record.3pm.gz $port contents p5-mail-spf-query Port p5-mail-spf-query contains: /opt/local/bin/spfd /opt/local/bin/spfquery /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/Mail/SPF/ Query/.packlist /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Query.pm /opt/local/share/man/man1/spfd.1pm.gz /opt/local/share/man/man1/spfquery.1pm.gz /opt/local/share/man/man3/Mail::SPF::Query.3pm.gz On Jul 3, 2009, at 3:12 PM, Scott Haneda wrote: > Clean install of my never-ending ASSP portfile project... > > Error: Target org.macports.activate returned: Image error: /opt/ > local/bin/spfquery is being used by the active p5-mail-spf port. > Please deactivate this port first, or use 'port -f activate p5-mail- > spf-query' to force the activation. > Warning: the following items did not execute (for p5-mail-spf- > query): org.macports.activate > Error: The following dependencies failed to build: p5-mail-spf-query > p5-mail-srs p5-net p5-authen-sasl p5-gssapi p5-crypt-des p5-digest > p5-net-ip-match-regexp p5-net-senderbase p5-net-syslog p5-perl-ldap > p5-convert-asn1 p5-xml-parser p5-xml-sax-writer p5-text-iconv p5-xml- > filter-buffertext p5-sys-syslog p5-tie-dbi p5-dbi p5-time-hires > Error: Status 1 encountered during processing. > > I am not sure I understand this one. I know how to work around it, > but I am looking for how to make the problem not be a problem for a > user who is installing. > > Here is the list of depends: > depends_lib \ > port:p5-compress-zlib \ > port:p5-digest-md5 \ > port:p5-digest-sha1 \ > port:p5-email-mime-modifier \ > port:p5-email-send \ > port:p5-email-valid \ > port:p5-file-readbackwards \ > port:p5-io-socket-ssl \ > port:p5-libwww-perl \ > port:p5-mail-spf \ > port:p5-mail-spf-query \ > port:p5-mail-srs \ > port:p5-net \ > port:p5-net-cidr-lite \ > port:p5-net-dns \ > port:p5-net-ip-match-regexp \ > port:p5-net-senderbase \ > port:p5-net-syslog \ > port:p5-perl-ldap \ > port:p5-sys-syslog \ > port:p5-tie-dbi \ > port:p5-time-hires -- Scott * If you contact me off list replace talklists@ with scott@ * From blb at macports.org Fri Jul 3 23:35:12 2009 From: blb at macports.org (Bryan Blackburn) Date: Sat, 4 Jul 2009 00:35:12 -0600 Subject: Active port install isssue In-Reply-To: <38EEAA40-48ED-4730-9B05-E8C8F09D340C@newgeo.com> References: <30D1FED1-D9BF-4A02-9CB1-80ED0BF6ACBE@newgeo.com> <38EEAA40-48ED-4730-9B05-E8C8F09D340C@newgeo.com> Message-ID: <20090704063512.GI46531@ninagal.withay.com> On Fri, Jul 03, 2009 at 10:29:01PM -0700, Scott Haneda said: > Yeah, I do not get this: > $sudo port -d install p5-mail-spf > > Installs clean... > > $sudo port -d install p5-mail-spf-query > > ---> Activating p5-mail-spf-query @1.999.1_0 > Error: Target org.macports.activate returned: Image error: > /opt/local/bin/spfquery is being used by the active p5-mail-spf port. > Please deactivate this port first, or use 'port -f activate > p5-mail-spf-query' to force the activation. > Warning: the following items did not execute (for p5-mail-spf-query): > org.macports.activate > Error: Status 1 encountered during processing. > > /opt/local/bin/spfquery is not being used by p5-mail-spf, unless I > misunderstand what port contents is showing me. I had a 99% flawless > install of ASSP and all it's chunks, but this one hitch, and I am > going to have to add a -f to the install process? In order for contents to work the port has to be active, which means you forced p5-mail-spf-query to install right? That then detached p5-mail-spf from the conflicting file, so contents doesn't show it any more. Try deactivating both, then just activate p5-mail-spf and run contents again. You should see spfquery. A quick test here shows p5-mail-spf to install spfquery as well as spfd, which p5-mail-spf-query also installs but in a different location (bin vs. sbin). It would appear these two ports are conflicting with one another (and I note FreeBSD has tagged them as such [1]) so it seems like they shouldn't be installed at the same time. Note that 1.8 will have a way to denote this, but for now just use one, I'm guessing p5-mail-spf since it has been updated more recently (though that isn't the most scientific way to decide). Bryan [1] - [...] > -- > Scott * If you contact me off list replace talklists@ with scott@ * > From talklists at newgeo.com Sat Jul 4 00:10:54 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sat, 4 Jul 2009 00:10:54 -0700 Subject: Active port install isssue In-Reply-To: <20090704063512.GI46531@ninagal.withay.com> References: <30D1FED1-D9BF-4A02-9CB1-80ED0BF6ACBE@newgeo.com> <38EEAA40-48ED-4730-9B05-E8C8F09D340C@newgeo.com> <20090704063512.GI46531@ninagal.withay.com> Message-ID: <4E8E510B-5B46-424D-935A-5584F4DBE034@newgeo.com> On Jul 3, 2009, at 11:35 PM, Bryan Blackburn wrote: > On Fri, Jul 03, 2009 at 10:29:01PM -0700, Scott Haneda said: >> Yeah, I do not get this: >> $sudo port -d install p5-mail-spf >> >> Installs clean... >> >> $sudo port -d install p5-mail-spf-query >> >> ---> Activating p5-mail-spf-query @1.999.1_0 >> Error: Target org.macports.activate returned: Image error: >> /opt/local/bin/spfquery is being used by the active p5-mail-spf port. >> Please deactivate this port first, or use 'port -f activate >> p5-mail-spf-query' to force the activation. >> Warning: the following items did not execute (for p5-mail-spf-query): >> org.macports.activate >> Error: Status 1 encountered during processing. >> >> /opt/local/bin/spfquery is not being used by p5-mail-spf, unless I >> misunderstand what port contents is showing me. I had a 99% flawless >> install of ASSP and all it's chunks, but this one hitch, and I am >> going to have to add a -f to the install process? > > In order for contents to work the port has to be active, which means > you > forced p5-mail-spf-query to install right? That then detached p5- > mail-spf > from the conflicting file, so contents doesn't show it any more. Try > deactivating both, then just activate p5-mail-spf and run contents > again. > You should see spfquery. I will take your word for it, your explanation below makes sense to me now. > A quick test here shows p5-mail-spf to install spfquery as well as > spfd, > which p5-mail-spf-query also installs but in a different location > (bin vs. > sbin). > > It would appear these two ports are conflicting with one another > (and I note > FreeBSD has tagged them as such [1]) so it seems like they shouldn't > be > installed at the same time. I can not find reference to this, can you point me to it, it may help me leverage some of the issues below that I am going to have to bring up with the ASSP developers. > Note that 1.8 will have a way to denote this, > but for now just use one, I'm guessing p5-mail-spf since it has been > updated > more recently (though that isn't the most scientific way to decide). Thank you Brian, I was not aware contents worked that way. Thanks. Here is the problem... From the ASSP install requirements: Mail::SPF::Query version 1.999001 Mail::SPF version 2.005 So for whatever reasons, the devs of ASSP have deemed them both needed, and specify the min versions as well. How does CPAN deal with the installation of these two items if you had to guess? ASSP comes with a bash script to do these installs, just calling out to CPAN, and I have not heard anyone have this issue of conflicts. I can try to talk to the developers about this, but there are many a working install, so I am going to get resistance. I assume CPAN just writes over the other one? I am going to have to confirm, but the code looks like it does this: if (! Mail::SPF::Query) die('please install Mail::SPF::Query') if (! Mail::SPF) die('Mail::SPF') If that is the case, what wold you suggest? -- Scott * If you contact me off list replace talklists@ with scott@ * From blb at macports.org Sat Jul 4 00:58:33 2009 From: blb at macports.org (Bryan Blackburn) Date: Sat, 4 Jul 2009 01:58:33 -0600 Subject: Active port install isssue In-Reply-To: <4E8E510B-5B46-424D-935A-5584F4DBE034@newgeo.com> References: <30D1FED1-D9BF-4A02-9CB1-80ED0BF6ACBE@newgeo.com> <38EEAA40-48ED-4730-9B05-E8C8F09D340C@newgeo.com> <20090704063512.GI46531@ninagal.withay.com> <4E8E510B-5B46-424D-935A-5584F4DBE034@newgeo.com> Message-ID: <20090704075833.GJ46531@ninagal.withay.com> On Sat, Jul 04, 2009 at 12:10:54AM -0700, Scott Haneda said: > On Jul 3, 2009, at 11:35 PM, Bryan Blackburn wrote: [...] > >A quick test here shows p5-mail-spf to install spfquery as well as > >spfd, > >which p5-mail-spf-query also installs but in a different location > >(bin vs. > >sbin). > > > >It would appear these two ports are conflicting with one another > >(and I note > >FreeBSD has tagged them as such [1]) so it seems like they > >shouldn't be > >installed at the same time. > > I can not find reference to this, can you point me to it, it may help > me leverage some of the issues below that I am going to have to bring > up with the ASSP developers. A reference to which? > > >Note that 1.8 will have a way to denote this, > >but for now just use one, I'm guessing p5-mail-spf since it has > >been updated > >more recently (though that isn't the most scientific way to decide). > > > Thank you Brian, I was not aware contents worked that way. Thanks. > Here is the problem... > From the ASSP install requirements: > Mail::SPF::Query version 1.999001 > Mail::SPF version 2.005 > > So for whatever reasons, the devs of ASSP have deemed them both > needed, and specify the min versions as well. > > How does CPAN deal with the installation of these two items if you > had to guess? ASSP comes with a bash script to do these installs, > just calling out to CPAN, and I have not heard anyone have this issue > of conflicts. I don't know how CPAN handles it but note that the assp port in FreeBSD just depends on Mail::SPF, no reference to Mail::SPF::Query [2]. That would suggest someone thinks that's all that's needed. > > I can try to talk to the developers about this, but there are many a > working install, so I am going to get resistance. I assume CPAN just > writes over the other one? > > I am going to have to confirm, but the code looks like it does this: > if (! Mail::SPF::Query) > die('please install Mail::SPF::Query') > > if (! Mail::SPF) > die('Mail::SPF') > > If that is the case, what wold you suggest? grepping through the 1.5.1.4 files, I don't see any actual use of Mail::SPF::Query, just one reference to it in ASSP/assp.pl (for DebugSPF). Unless there's something well hidden, Mail::SPF should be fine... Bryan [2] - > -- > Scott * If you contact me off list replace talklists@ with scott@ * From jm at poure.com Sat Jul 4 09:44:42 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sat, 04 Jul 2009 18:44:42 +0200 Subject: [MacPorts] #18306: automoc requires apple-gcc42 depends-build In-Reply-To: <057.43b75f8c60925f636ec8f5fef8004241@macports.org> References: <048.6f5d29f170b650a919ab49776d892748@macports.org> <057.43b75f8c60925f636ec8f5fef8004241@macports.org> Message-ID: <1246725882.4499.3.camel@acer> On Sat, 2009-07-04 at 06:01 +0000, MacPorts wrote: > #18306: automoc requires apple-gcc42 depends-build > --------------------------+------------------------------------------------- > Reporter: jm@? | Owner: illogic-al@? > Type: defect | Status: assigned > Priority: Normal | Milestone: > Component: ports | Version: 1.7.0 > Keywords: | Port: automoc > --------------------------+------------------------------------------------- > > Comment(by devans@?): > > I think the way to configure apple-gcc-42 is this > > {{{ > configure.compiler apple-gcc-4.2 > }}} > > See [http://trac.macports.org/wiki/UsingTheRightCompiler > UsingTheRightCompiler] > Thanks. I am now running 10.5, so i cannot test. Sorry. From mcalhoun at macports.org Sat Jul 4 12:49:07 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Sat, 4 Jul 2009 15:49:07 -0400 Subject: [53388] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: <20090704143811.983081FD1104@beta.macosforge.org> References: <20090704143811.983081FD1104@beta.macosforge.org> Message-ID: <7A44BB6B-08E2-4B78-AB9D-A575E84B21A9@macports.org> -arch was used over -m once before (see http://lists.macosforge.org/pipermail/macports-dev/2009-April/008158.html) , but was changed back due to the reasons given in the message. Is there a compelling reason -arch should be preferred now? -Marcus On Jul 4, 2009, at 10:38 AM, jmr at macports.org wrote: > Revision53388Authorjmr at macports.orgDate2009-07-04 07:38:11 -0700 > (Sat, 04 Jul 2009)Log Message > clag the arch_flag_supported proc from trunk's portconfigure and > always use -arch when supported > Modified Paths > ? trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl > Diff > Modified: trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl > (53387 => 53388) > > --- trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl > 2009-07-04 14:22:52 UTC (rev 53387) > +++ trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl > 2009-07-04 14:38:11 UTC (rev 53388) > @@ -56,19 +56,41 @@ > default merger_arch_flag {yes} > default merger_arch_compiler {yes} > > +proc muniversal_arch_flag_supported {args} { > + global configure.compiler > + switch -exact ${configure.compiler} { > + gcc-4.0 - > + gcc-4.2 - > + llvm-gcc-4.2 - > + clang - > + apple-gcc-4.0 - > + apple-gcc-4.2 { > + return yes > + } > + default { > + return no > + } > + } > +} > + > proc muniversal_get_arch_flag {arch} { > global os.arch > - # Prefer -m to -arch > - set archf "-arch ${arch}" > - if { ${os.arch}=="i386" && ${arch}=="i386" } { > - set archf -m32 > - } elseif { ${os.arch}=="i386" && ${arch}=="x86_64" } { > - set archf -m64 > - } elseif { ${os.arch}=="powerpc" && ${arch}=="ppc" } { > - set archf -m32 > - } elseif { ${os.arch}=="powerpc" && ${arch}=="ppc64" } { > - set archf -m64 > - } > + # Prefer -arch to -m > + if {[muniversal_arch_flag_supported]} { > + set archf "-arch ${arch}" > + } else { > + if { ${os.arch}=="i386" && ${arch}=="i386" } { > + set archf -m32 > + } elseif { ${os.arch}=="i386" && ${arch}=="x86_64" } { > + set archf -m64 > + } elseif { ${os.arch}=="powerpc" && ${arch}=="ppc" } { > + set archf -m32 > + } elseif { ${os.arch}=="powerpc" && ${arch}=="ppc64" } { > + set archf -m64 > + } else { > + return -code error "selected compiler can't build for $ > {arch}" > + } > + } > return ${archf} > } > > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes From jeremyhu at macports.org Sat Jul 4 13:09:40 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 4 Jul 2009 13:09:40 -0700 Subject: [53388] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: <7A44BB6B-08E2-4B78-AB9D-A575E84B21A9@macports.org> References: <20090704143811.983081FD1104@beta.macosforge.org> <7A44BB6B-08E2-4B78-AB9D-A575E84B21A9@macports.org> Message-ID: <8FC6F274-E321-4497-980C-F3FDC7EDED4F@macports.org> On Jul 4, 2009, at 12:49, Marcus Calhoun-Lopez wrote: > -arch was used over -m once before (see http://lists.macosforge.org/pipermail/macports-dev/2009-April/008158.html) > , but was changed back > due to the reasons given in the message. > > Is there a compelling reason -arch should be preferred now? Well, "-arch ppc -arch i386 -arch x86_64 -m64" (which is done currently when ppc,i386,x86_64 are chosen) results in gcc trying to build ppc64 code... -arch is more correct. From mcalhoun at macports.org Sat Jul 4 14:06:42 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Sat, 4 Jul 2009 21:06:42 +0000 (UTC) Subject: [53388] =?utf-8?b?dHJ1bmsvZHBvcnRzL19yZXNvdXJjZXMvcG9ydDEuMC9ncm91cC9tdW5pdmVyc2FsLTEuMC50Y2w=?= References: <20090704143811.983081FD1104@beta.macosforge.org> <7A44BB6B-08E2-4B78-AB9D-A575E84B21A9@macports.org> <8FC6F274-E321-4497-980C-F3FDC7EDED4F@macports.org> Message-ID: Jeremy Huddleston writes: > > > On Jul 4, 2009, at 12:49, Marcus Calhoun-Lopez wrote: > > > -arch was used over -m once before (see > http://lists.macosforge.org/pipermail/macports-dev/2009-April/008158.html) > > , but was changed back > > due to the reasons given in the message. > > > > Is there a compelling reason -arch should be preferred now? > > Well, > > "-arch ppc -arch i386 -arch x86_64 -m64" (which is done currently when > ppc,i386,x86_64 are chosen) results in gcc trying to build ppc64 code... > > -arch is more correct. > > In the muniversal PortGroup and the base code changes I am finally getting close to finishing, having multiple architecture specifications (as in your example) would be a bug (it should never happen). For a few examples (e.g. gmp) something like -arch ppc64 -m64 could happen, but I do not believe that is a problem. The choice then is between one -arch ... or one -mXX. It seems to me -mXX should be the default for the reasons outlined in http://lists.macosforge.org/pipermail/macports-dev/2009-April/008158.html -Marcus From jeremyhu at macports.org Sat Jul 4 15:24:53 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 4 Jul 2009 15:24:53 -0700 Subject: universal_variant no not being honored? Message-ID: <0EDF68EB-CE42-4378-85BB-FE9961F97BEC@macports.org> samba3 has 'universal_variant no' set, but it looks like it's still trying to build universal (I'm using base trunk): Using FLAGS = -O2 -arch x86_64 -arch i386 -arch ppc -fno-common - O -D_SAMBA_BUILD_=3 -fno-common -I/opt/local/var/macports/build/ _Users_jeremy_src_macports-trunk_dports_net_samba3/work/samba-3.2.12/ source/iniparser/src -Iinclude -I./include -I. -I. -I./lib/replace - I./lib/talloc -I./lib/tdb/include -I./libaddns -I./librpc - DHAVE_CONFIG_H -I/opt/local/include -DHAVE_STRUCT_TIMESPEC -Iinclude - I./include -I. -I. -I./lib/replace -I./lib/talloc -I./lib/tdb/include - I./libaddns -I./librpc -I./popt -DLDAP_DEPRECATED -I/include -I/opt/ local/var/macports/build/_Users_jeremy_src_macports- trunk_dports_net_samba3/work/samba-3.2.12/source/lib -D_SAMBA_BUILD_=3 PICFLAG = -fPIE LIBS = -lresolv -liconv LDFLAGS = -dynamic -Wl,-search_paths_first -L/opt/local/lib - arch x86_64 -L./bin DYNEXP = LDSHFLAGS = -dynamiclib -flat_namespace -undefined suppress - dynamic -Wl,-search_paths_first -L/opt/local/lib -arch x86_64 -L./bin SHLIBEXT = dylib SONAMEFLAG = # From blb at macports.org Sat Jul 4 15:53:19 2009 From: blb at macports.org (Bryan Blackburn) Date: Sat, 4 Jul 2009 16:53:19 -0600 Subject: universal_variant no not being honored? In-Reply-To: <0EDF68EB-CE42-4378-85BB-FE9961F97BEC@macports.org> References: <0EDF68EB-CE42-4378-85BB-FE9961F97BEC@macports.org> Message-ID: <20090704225319.GE40871@ninagal.withay.com> On Sat, Jul 04, 2009 at 03:24:53PM -0700, Jeremy Huddleston said: > samba3 has 'universal_variant no' set, but it looks like it's still > trying to build universal (I'm using base trunk): Just tried it here, and only see Using FLAGS = -pipe -O2 -arch i386 -fno-common -O -D_SAMBA_BUILD_=3 -fno-common -I/mp/var/macports/build/_Users_blb_devel_macports_trunk_dports_net_samba3/work/samba-3.2.12/source/iniparser/src -Iinclude -I./include -I. -I. -I./lib/replace -I./lib/talloc -I./lib/tdb/include -I./libaddns -I./librpc -DHAVE_CONFIG_H -I/mp/include -DHAVE_STRUCT_TIMESPEC -Iinclude -I./include -I. -I. -I./lib/replace -I./lib/talloc -I./lib/tdb/include -I./libaddns -I./librpc -I./popt -DLDAP_DEPRECATED -I/include -I/mp/var/macports/build/_Users_blb_devel_macports_trunk_dports_net_samba3/work/samba-3.2.12/source/lib -D_SAMBA_BUILD_=3 My universal_archs is set to 'ppc i386' so it doesn't seem to be picking that up; my install is also trunk, last installed a little over 12 hours ago. Do you have any of samba3's dependencies installed +universal? Maybe it's getting some CFLAGS from one of those? Bryan > > Using FLAGS = -O2 -arch x86_64 -arch i386 -arch ppc -fno-common > -O -D_SAMBA_BUILD_=3 -fno-common -I/opt/local/var/macports/build/ > _Users_jeremy_src_macports-trunk_dports_net_samba3/work/samba-3.2.12/ > source/iniparser/src -Iinclude -I./include -I. -I. -I./lib/replace - > I./lib/talloc -I./lib/tdb/include -I./libaddns -I./librpc - > DHAVE_CONFIG_H -I/opt/local/include -DHAVE_STRUCT_TIMESPEC -Iinclude > -I./include -I. -I. -I./lib/replace -I./lib/talloc > -I./lib/tdb/include -I./libaddns -I./librpc -I./popt > -DLDAP_DEPRECATED -I/include -I/opt/ > local/var/macports/build/_Users_jeremy_src_macports- > trunk_dports_net_samba3/work/samba-3.2.12/source/lib > -D_SAMBA_BUILD_=3 > PICFLAG = -fPIE > LIBS = -lresolv -liconv > LDFLAGS = -dynamic -Wl,-search_paths_first -L/opt/local/lib > -arch x86_64 -L./bin > DYNEXP = > LDSHFLAGS = -dynamiclib -flat_namespace -undefined suppress - > dynamic -Wl,-search_paths_first -L/opt/local/lib -arch x86_64 -L./bin > SHLIBEXT = dylib > SONAMEFLAG = # From jeremyhu at macports.org Sat Jul 4 17:34:58 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 4 Jul 2009 17:34:58 -0700 Subject: universal_variant no not being honored? In-Reply-To: <20090704225319.GE40871@ninagal.withay.com> References: <0EDF68EB-CE42-4378-85BB-FE9961F97BEC@macports.org> <20090704225319.GE40871@ninagal.withay.com> Message-ID: <18DCD636-B626-4FB0-8EAE-D491C651AC51@macports.org> On Jul 4, 2009, at 15:53, Bryan Blackburn wrote: > On Sat, Jul 04, 2009 at 03:24:53PM -0700, Jeremy Huddleston said: >> samba3 has 'universal_variant no' set, but it looks like it's still >> trying to build universal (I'm using base trunk): > > Just tried it here, and only see > > Using FLAGS = -pipe -O2 -arch i386 -fno-common -O - > D_SAMBA_BUILD_=3 -fno-common -I/mp/var/macports/build/ > _Users_blb_devel_macports_trunk_dports_net_samba3/work/samba-3.2.12/ > source/iniparser/src -Iinclude -I./include -I. -I. -I./lib/replace - > I./lib/talloc -I./lib/tdb/include -I./libaddns -I./librpc - > DHAVE_CONFIG_H -I/mp/include -DHAVE_STRUCT_TIMESPEC -Iinclude -I./ > include -I. -I. -I./lib/replace -I./lib/talloc -I./lib/tdb/include - > I./libaddns -I./librpc -I./popt -DLDAP_DEPRECATED -I/include -I/mp/ > var/macports/build/_Users_blb_devel_macports_trunk_dports_net_samba3/ > work/samba-3.2.12/source/lib -D_SAMBA_BUILD_=3 > > My universal_archs is set to 'ppc i386' so it doesn't seem to be > picking > that up; my install is also trunk, last installed a little over 12 > hours > ago. Do you have any of samba3's dependencies installed > +universal? Maybe > it's getting some CFLAGS from one of those? Nope, it's definitely getting CFLAGS from base. I switched it over to muniversal, and it's now building correctly. (did you try it before I pushed the muniversal change or after?) From jmr at macports.org Sat Jul 4 20:57:51 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 05 Jul 2009 13:57:51 +1000 Subject: universal_variant no not being honored? In-Reply-To: <18DCD636-B626-4FB0-8EAE-D491C651AC51@macports.org> References: <0EDF68EB-CE42-4378-85BB-FE9961F97BEC@macports.org> <20090704225319.GE40871@ninagal.withay.com> <18DCD636-B626-4FB0-8EAE-D491C651AC51@macports.org> Message-ID: <4A5024BF.3080804@macports.org> On 2009-7-5 10:34, Jeremy Huddleston wrote: > > On Jul 4, 2009, at 15:53, Bryan Blackburn wrote: > >> On Sat, Jul 04, 2009 at 03:24:53PM -0700, Jeremy Huddleston said: >>> samba3 has 'universal_variant no' set, but it looks like it's still >>> trying to build universal (I'm using base trunk): >> >> Just tried it here, and only see >> >> Using FLAGS = -pipe -O2 -arch i386 -fno-common -O >> -D_SAMBA_BUILD_=3 -fno-common >> -I/mp/var/macports/build/_Users_blb_devel_macports_trunk_dports_net_samba3/work/samba-3.2.12/source/iniparser/src >> -Iinclude -I./include -I. -I. -I./lib/replace -I./lib/talloc >> -I./lib/tdb/include -I./libaddns -I./librpc -DHAVE_CONFIG_H >> -I/mp/include -DHAVE_STRUCT_TIMESPEC -Iinclude -I./include -I. -I. >> -I./lib/replace -I./lib/talloc -I./lib/tdb/include -I./libaddns >> -I./librpc -I./popt -DLDAP_DEPRECATED -I/include >> -I/mp/var/macports/build/_Users_blb_devel_macports_trunk_dports_net_samba3/work/samba-3.2.12/source/lib >> -D_SAMBA_BUILD_=3 >> >> My universal_archs is set to 'ppc i386' so it doesn't seem to be picking >> that up; my install is also trunk, last installed a little over 12 hours >> ago. Do you have any of samba3's dependencies installed +universal? >> Maybe >> it's getting some CFLAGS from one of those? > > Nope, it's definitely getting CFLAGS from base. I switched it over to > muniversal, and it's now building correctly. (did you try it before I > pushed the muniversal change or after?) Might have been a bug in portconfigure that I just tried to fix. It was checking [variant_isset universal], but a variant can be set without existing in the port. Now it checks with variant_exists as well. But... this is still a problem. If you look at configure.cflags before you declare the universal variant (like in all ports that use the default one, for instance), you don't see the universal_cflags in there. And if you append to cflags in the same place, the universal flags never get added. Might have to go back to appending them in the variant so they at least get in there by configure time. - Josh From blb at macports.org Sun Jul 5 00:38:30 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 5 Jul 2009 01:38:30 -0600 Subject: universal_variant no not being honored? In-Reply-To: <18DCD636-B626-4FB0-8EAE-D491C651AC51@macports.org> References: <0EDF68EB-CE42-4378-85BB-FE9961F97BEC@macports.org> <20090704225319.GE40871@ninagal.withay.com> <18DCD636-B626-4FB0-8EAE-D491C651AC51@macports.org> Message-ID: <20090705073830.GR40871@ninagal.withay.com> On Sat, Jul 04, 2009 at 05:34:58PM -0700, Jeremy Huddleston said: > > On Jul 4, 2009, at 15:53, Bryan Blackburn wrote: > > >On Sat, Jul 04, 2009 at 03:24:53PM -0700, Jeremy Huddleston said: > >>samba3 has 'universal_variant no' set, but it looks like it's still > >>trying to build universal (I'm using base trunk): > > > >Just tried it here, and only see > > > >Using FLAGS = -pipe -O2 -arch i386 -fno-common -O - > >D_SAMBA_BUILD_=3 -fno-common -I/mp/var/macports/build/ > >_Users_blb_devel_macports_trunk_dports_net_samba3/work/samba-3.2.12/ > >source/iniparser/src -Iinclude -I./include -I. -I. -I./lib/replace > >-I./lib/talloc -I./lib/tdb/include -I./libaddns -I./librpc - > >DHAVE_CONFIG_H -I/mp/include -DHAVE_STRUCT_TIMESPEC -Iinclude -I./ > >include -I. -I. -I./lib/replace -I./lib/talloc -I./lib/tdb/include > >-I./libaddns -I./librpc -I./popt -DLDAP_DEPRECATED -I/include > >-I/mp/ > >var/macports/build/_Users_blb_devel_macports_trunk_dports_net_samba3/ > >work/samba-3.2.12/source/lib -D_SAMBA_BUILD_=3 > > > >My universal_archs is set to 'ppc i386' so it doesn't seem to be > >picking > >that up; my install is also trunk, last installed a little over 12 > >hours > >ago. Do you have any of samba3's dependencies installed > >+universal? Maybe > >it's getting some CFLAGS from one of those? > > Nope, it's definitely getting CFLAGS from base. I switched it over > to muniversal, and it's now building correctly. (did you try it > before I pushed the muniversal change or after?) Was definitely before the muniversal change, if Josh's fix was it then perhaps +universal needed to be set someplace? That could be it if you have it set in variants.conf since my run was quite variant-free. Bryan From ryandesign at macports.org Sun Jul 5 00:44:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 5 Jul 2009 02:44:02 -0500 Subject: [53362] trunk/dports/print In-Reply-To: <20090704031512.489621FCCCD5@beta.macosforge.org> References: <20090704031512.489621FCCCD5@beta.macosforge.org> Message-ID: <9B04FE79-A855-418B-9F18-653190B52992@macports.org> On Jul 3, 2009, at 22:15, takeshi at macports.org wrote: > Revision: 53362 > http://trac.macports.org/changeset/53362 > Author: takeshi at macports.org > Date: 2009-07-03 20:15:09 -0700 (Fri, 03 Jul 2009) > Log Message: > ----------- > libLASi: adding this to enable unicode text in ps file produce by > plplot Have you considered using the cmake portgroup which might simplify this port? From jeremyhu at macports.org Sun Jul 5 07:44:59 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 5 Jul 2009 07:44:59 -0700 Subject: universal_variant no not being honored? In-Reply-To: <20090705073830.GR40871@ninagal.withay.com> References: <0EDF68EB-CE42-4378-85BB-FE9961F97BEC@macports.org> <20090704225319.GE40871@ninagal.withay.com> <18DCD636-B626-4FB0-8EAE-D491C651AC51@macports.org> <20090705073830.GR40871@ninagal.withay.com> Message-ID: >> Nope, it's definitely getting CFLAGS from base. I switched it over >> to muniversal, and it's now building correctly. (did you try it >> before I pushed the muniversal change or after?) > > Was definitely before the muniversal change, if Josh's fix was it then > perhaps +universal needed to be set someplace? That could be it if > you have > it set in variants.conf since my run was quite variant-free. Yeah, I have +universal in variants.conf, so it looks like jmr's fix should do the job for now. From raimue at macports.org Sun Jul 5 16:17:48 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Mon, 06 Jul 2009 01:17:48 +0200 Subject: GSoC: Mid-term evaluations this week Message-ID: <4A51349C.4070007@macports.org> Hi Dmitry and Juan, you have been working now for about 5 weeks on MacPorts code. Now the mid-term evaluation of your work will happen from 6th to 13th July. All your new code is only visible to those who have been following the branches in Subversion. It would be nice if you could give a quick overview over your project. What you have done so far? What is already working and how can it be tested? What problems did you encounter? How much time you are behind or ahead in your own roadmap? What do you plan to do next? I would like to see that on macports-dev to bring your topics to a broader audience and get you more involved on the mailing list. Your reply does not have to be too formal. And of course others should feel free to ask further questions if interested. Looking forward to your answers, Rainer From evenson at panix.com Mon Jul 6 05:51:53 2009 From: evenson at panix.com (Mark Evenson) Date: Mon, 06 Jul 2009 14:51:53 +0200 Subject: Macports trac/wiki down? Message-ID: The [Macports Trac instance][1] seems to have been down for several days. Is there any status on when it might be back, or is it being no longer used? [1]: http://trac.macports.org/ From jmr at macports.org Mon Jul 6 06:01:04 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 06 Jul 2009 23:01:04 +1000 Subject: Macports trac/wiki down? In-Reply-To: References: Message-ID: <4A51F590.4080301@macports.org> On 2009-7-6 22:51, Mark Evenson wrote: > The [Macports Trac instance][1] seems to have been down for several days. > > Is there any status on when it might be back, or is it being no longer > used? > > > [1]: http://trac.macports.org/ I haven't noticed any downtime. What happens when you try to use it? - Josh From evenson at panix.com Mon Jul 6 06:41:07 2009 From: evenson at panix.com (Mark Evenson) Date: Mon, 06 Jul 2009 15:41:07 +0200 Subject: Macports trac/wiki down? In-Reply-To: <4A51F590.4080301@macports.org> References: <4A51F590.4080301@macports.org> Message-ID: <4A51FEF3.10209@panix.com> Joshua Root wrote: > On 2009-7-6 22:51, Mark Evenson wrote: >> The [Macports Trac instance][1] seems to have been down for several days. >> >> Is there any status on when it might be back, or is it being no longer >> used? >> >> >> [1]: http://trac.macports.org/ > > I haven't noticed any downtime. What happens when you try to use it? > > - Josh The following python trace: Traceback (most recent call last): File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", line 367, in send_error 'text/html') File "/opt/local/lib/python2.5/site-packages/trac/web/chrome.py", line 728, in render_template if not req.session or not int(req.session.get('accesskeys', 0)): File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", line 194, in __getattr__ value = self.callbacks[name](self) File "/opt/local/lib/python2.5/site-packages/trac/web/main.py", line 267, in _get_session return Session(self.env, req) File "/opt/local/lib/python2.5/site-packages/trac/web/session.py", line 156, in __init__ self.promote_session(sid) File "/opt/local/lib/python2.5/site-packages/trac/web/session.py", line 214, in promote_session "WHERE sid=%s OR sid=%s ", (sid, self.req.authname)) File "/opt/local/lib/python2.5/site-packages/trac/db/util.py", line 50, in execute return self.cursor.execute(sql_escape_percent(sql), args) File "/opt/local/lib/python2.5/site-packages/trac/db/util.py", line 50, in execute return self.cursor.execute(sql_escape_percent(sql), args) ProgrammingError: current transaction is aborted, commands ignored until end of transaction block -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." From evenson at panix.com Mon Jul 6 06:55:45 2009 From: evenson at panix.com (Mark Evenson) Date: Mon, 06 Jul 2009 15:55:45 +0200 Subject: Macports trac/wiki down? In-Reply-To: <4A51FEF3.10209@panix.com> References: <4A51F590.4080301@macports.org> <4A51FEF3.10209@panix.com> Message-ID: <4A520261.1090501@panix.com> Mark Evenson wrote: > Joshua Root wrote: >> On 2009-7-6 22:51, Mark Evenson wrote: >>> The [Macports Trac instance][1] seems to have been down for several >>> days. [?] >> I haven't noticed any downtime. What happens when you try to use it? [?] > The following python trace: > > Traceback (most recent call last): > File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", line > 367, in send_error > 'text/html') > File "/opt/local/lib/python2.5/site-packages/trac/web/chrome.py", line > 728, in render_template > if not req.session or not int(req.session.get('accesskeys', 0)): > File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", line [?] Apparently something screwy with my login ID, as coming in with a clean browser shows everything normal (I'm loathe to clear my main browser's cookies but I guess I should, and then iterate over the login ID). Thanks to those who responded. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." From kthenriksson at gmail.com Mon Jul 6 07:59:24 2009 From: kthenriksson at gmail.com (Kristofer Henriksson) Date: Mon, 6 Jul 2009 10:59:24 -0400 Subject: Macports trac/wiki down? In-Reply-To: <4A520261.1090501@panix.com> References: <4A51F590.4080301@macports.org> <4A51FEF3.10209@panix.com> <4A520261.1090501@panix.com> Message-ID: <4809057c0907060759s215f3569y2515417ad89110d4@mail.gmail.com> I noticed the same thing happen to me in the past, where I would get a python backtrace upon logging in, though the logout link still would work for me. If I was logged out, I had no problems accessing pages. I just checked this again and I don't seem to be having these problems, but I wanted to confirm that more than one person has seen it and that it doesn't seem to have been caused by any recent change. On Mon, Jul 6, 2009 at 9:55 AM, Mark Evenson wrote: > Mark Evenson wrote: >> >> Joshua Root wrote: >>> >>> On 2009-7-6 22:51, Mark Evenson wrote: >>>> >>>> The [Macports Trac instance][1] seems to have been down for several >>>> days. > > [?] > >>> I haven't noticed any downtime. What happens when you try to use it? > > [?] > >> The following python trace: >> >> Traceback (most recent call last): >> ?File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", line 367, >> in send_error >> ? ?'text/html') >> ?File "/opt/local/lib/python2.5/site-packages/trac/web/chrome.py", line >> 728, in render_template >> ? ?if not req.session or not int(req.session.get('accesskeys', 0)): >> ?File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", line > > [?] > > Apparently something screwy with my login ID, as coming in with a clean > browser shows everything normal (I'm loathe to clear my main browser's > cookies but I guess I should, and then iterate over the login ID). > > Thanks to those who responded. > > > -- > "A screaming comes across the sky. ?It has happened before, but there > is nothing to compare to it now." > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From wsiegrist at apple.com Mon Jul 6 08:11:04 2009 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 6 Jul 2009 08:11:04 -0700 Subject: Macports trac/wiki down? In-Reply-To: <4809057c0907060759s215f3569y2515417ad89110d4@mail.gmail.com> References: <4A51F590.4080301@macports.org> <4A51FEF3.10209@panix.com> <4A520261.1090501@panix.com> <4809057c0907060759s215f3569y2515417ad89110d4@mail.gmail.com> Message-ID: <403CE01C-E8EB-431E-AFFC-83C5120F512A@apple.com> On Jul 6, 2009, at 7:59 AM, Kristofer Henriksson wrote: > I noticed the same thing happen to me in the past, where I would get a > python backtrace upon logging in, though the logout link still would > work for me. If I was logged out, I had no problems accessing pages. I > just checked this again and I don't seem to be having these problems, > but I wanted to confirm that more than one person has seen it and that > it doesn't seem to have been caused by any recent change. > > On Mon, Jul 6, 2009 at 9:55 AM, Mark Evenson wrote: >> Mark Evenson wrote: >>> >>> Joshua Root wrote: >>>> >>>> On 2009-7-6 22:51, Mark Evenson wrote: >>>>> >>>>> The [Macports Trac instance][1] seems to have been down for >>>>> several >>>>> days. >> >> [?] >> >>>> I haven't noticed any downtime. What happens when you try to use >>>> it? >> >> [?] >> >>> The following python trace: >>> >>> Traceback (most recent call last): >>> File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", >>> line 367, >>> in send_error >>> 'text/html') >>> File "/opt/local/lib/python2.5/site-packages/trac/web/chrome.py", >>> line >>> 728, in render_template >>> if not req.session or not int(req.session.get('accesskeys', 0)): >>> File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", line >> >> [?] >> >> Apparently something screwy with my login ID, as coming in with a >> clean >> browser shows everything normal (I'm loathe to clear my main >> browser's >> cookies but I guess I should, and then iterate over the login ID). >> >> Thanks to those who responded. >> Its a bug in Trac. You should be able to clear your cookies for macosforge.org and macports.org and login again to workaround the problem. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available URL: From armahg at gmail.com Mon Jul 6 08:55:47 2009 From: armahg at gmail.com (George Armah) Date: Mon, 6 Jul 2009 08:55:47 -0700 Subject: GSoC: Mid-term evaluations this week In-Reply-To: <4A51349C.4070007@macports.org> References: <4A51349C.4070007@macports.org> Message-ID: Juan's internet connection at home has been down this past week. He is working to get it back online as soon as possible. If he doesn't respond by Wednesday, I will attempt contacting him by phone and compose a message on his behalf. Thanks, George. On Sun, Jul 5, 2009 at 4:17 PM, Rainer M?ller wrote: > Hi Dmitry and Juan, > > you have been working now for about 5 weeks on MacPorts code. Now the > mid-term evaluation of your work will happen from 6th to 13th July. > > All your new code is only visible to those who have been following the > branches in Subversion. It would be nice if you could give a quick > overview over your project. > > What you have done so far? > What is already working and how can it be tested? > What problems did you encounter? > How much time you are behind or ahead in your own roadmap? > What do you plan to do next? > > I would like to see that on macports-dev to bring your topics to a > broader audience and get you more involved on the mailing list. Your > reply does not have to be too formal. And of course others should feel > free to ask further questions if interested. > > Looking forward to your answers, > Rainer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimue at macports.org Mon Jul 6 09:13:42 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 06 Jul 2009 18:13:42 +0200 Subject: GSoC: Mid-term evaluations this week In-Reply-To: References: <4A51349C.4070007@macports.org> Message-ID: <4A5222B6.2030104@macports.org> George Armah wrote: > Juan's internet connection at home has been down this past week. He is > working to get it back online as soon as possible. > If he doesn't respond by Wednesday, I will attempt contacting him by > phone and compose a message on his behalf. Students also have to fill out a form for mid-term evaluation. It is important that he does this by July, 13th or he will not get paid for his work! Rainer From armahg at gmail.com Mon Jul 6 09:51:41 2009 From: armahg at gmail.com (George Armah) Date: Mon, 6 Jul 2009 09:51:41 -0700 Subject: GSoC: Mid-term evaluations this week In-Reply-To: <4A5222B6.2030104@macports.org> References: <4A51349C.4070007@macports.org> <4A5222B6.2030104@macports.org> Message-ID: I am aware ... I think in the worst case, he can do that from an Internet Cafe. I'll keep thread updated on new developments. > Students also have to fill out a form for mid-term evaluation. It is > important that he does this by July, 13th or he will not get paid for > his work! > > Rainer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramercer at gmail.com Mon Jul 6 10:50:53 2009 From: ramercer at gmail.com (Adam Mercer) Date: Mon, 6 Jul 2009 12:50:53 -0500 Subject: [53410] trunk/dports/science/gmt/Portfile In-Reply-To: <20090705092522.5FA9E1FDDC89@beta.macosforge.org> References: <20090705092522.5FA9E1FDDC89@beta.macosforge.org> Message-ID: <799406d60907061050i61593ddep42c5e3bfecc9c2e4@mail.gmail.com> On Sun, Jul 5, 2009 at 04:25, wrote: > Revision 53410 Author takeshi at macports.org Date 2009-07-05 02:25:21 -0700 > (Sun, 05 Jul 2009) > > Log Message > > gmt: updated to 4.4.0 > > Modified Paths > > trunk/dports/science/gmt/Portfile > > Diff > > Modified: trunk/dports/science/gmt/Portfile (53409 => 53410) > > --- trunk/dports/science/gmt/Portfile 2009-07-05 08:52:54 UTC (rev 53409) > +++ trunk/dports/science/gmt/Portfile 2009-07-05 09:25:21 UTC (rev 53410) > +livecheck.type regex > +livecheck.url http://gmt.soest.hawaii.edu/gmt/gmt_home.html > +livecheck.regex {Current version is ([0-9]+.[0-9]+.[0-9]+.)} This won't work on MacPorts 1.7.1, only trunk has livecheck.type. Cheers Adam From jm at poure.com Mon Jul 6 15:47:23 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Tue, 07 Jul 2009 00:47:23 +0200 Subject: Shared access to Mac OS X: how to manage wakeonlan and sleep Message-ID: <1246920443.5774.0.camel@acer> Dear Friends, I just bought a G4 PowerMac (PPC) installed with Mac OS X 10.5 . This was a rather good bargain as it works quite well and compiles fine. And rather quickly. We share this computer over Internet for Kdenlive project. I am making this post on MacPorts devel because several projects may be interested in the solution. The Mac goes to sleep automatically after 3 hours of inactivity. My questions : * How can I manage sleep so that it is triggered after an SSH disconnection and let's say 30 minutes of inactivity. * When using screen, I would like to be sure that the Mac does not go to sleep. * Is sleep state safe? I would like to know if some of you have innovating solutions. This is only a compilation platform. We also have VNC access to view the result and verify that Kdenlive runs smoothly. Kind regards, Jean-Michel From ryandesign at macports.org Mon Jul 6 18:22:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 6 Jul 2009 20:22:05 -0500 Subject: Shared access to Mac OS X: how to manage wakeonlan and sleep In-Reply-To: <1246920443.5774.0.camel@acer> References: <1246920443.5774.0.camel@acer> Message-ID: <62A1852A-08EE-4F02-BF95-EDACCCC95039@macports.org> On Jul 6, 2009, at 17:47, Jean-Michel Pour? wrote: > The Mac goes to sleep automatically after 3 hours of inactivity. Then I assume you are either all on the same subnet as this Power Mac and can therefore send it a wakeonlan signal yourself, or else you have a device on the local subnet (perhaps a router running DD-WRT or another machine that's always on) to which you first connect and tell it to wake the Power Mac. > My questions : > > * How can I manage sleep so that it is triggered after an SSH > disconnection and let's say 30 minutes of inactivity. > > * When using screen, I would like to be sure that the Mac does not > go to > sleep. I don't know a built-in way to accomplish either of those, but I'm not familiar with what hooks might be available in the ssh or screen programs to let you do this. Personally whenever I want to sleep my machines I use small script "sleepmac" I wrote which looks like this: #!/bin/sh if [ ! -z "$1" ]; then sleep $1 fi SLEEPWATCHER=/opt/local/sbin/sleepwatcher if [ -x $SLEEPWATCHER ]; then $SLEEPWATCHER --now else osascript -e 'tell app "System Events" to sleep' & fi You can specify a delay before sleeping, e.g. to sleep in one minute: sleepmac 60 It uses the sleepwatcher port if installed, or AppleScript if not. There was some set of circumstances that I cannot recall or test for at the moment whereby sleep wouldn't work, complaining instead of an inability to connect to the windowserver, and I believe it involved being logged in via ssh and/or using screen. I think using sleepwatcher instead of AppleScript may have helped with this, or at least I was testing whether this helped. I have primarily been using Tiger so I don't know if any of this has changed on Leopard. sleepwatcher has many more capabilities that might be useful to you if you wanted to write a script or scripts to help you manage the requirements you mentioned. > * Is sleep state safe? It should be safe to put a machine to sleep in the middle of a compile, and it should resume where it left off when you wake up. If that's what you mean. > I would like to know if some of you have innovating solutions. This is > only a compilation platform. We also have VNC access to view the > result > and verify that Kdenlive runs smoothly. From armahg at gmail.com Mon Jul 6 19:34:48 2009 From: armahg at gmail.com (George Armah) Date: Mon, 6 Jul 2009 19:34:48 -0700 Subject: GSoC: Mid-term evaluations this week In-Reply-To: References: <4A51349C.4070007@macports.org> <4A5222B6.2030104@macports.org> Message-ID: I have spoken with Juan, he is composing a reply and will send it shortly. On Mon, Jul 6, 2009 at 9:51 AM, George Armah wrote: > I am aware ... I think in the worst case, he can do that from an Internet > Cafe. I'll keep thread updated on new developments. > > > >> Students also have to fill out a form for mid-term evaluation. It is >> important that he does this by July, 13th or he will not get paid for >> his work! >> >> Rainer >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Mon Jul 6 21:14:32 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 6 Jul 2009 23:14:32 -0500 Subject: [53496] trunk/base/doc/portfile.7 In-Reply-To: <20090707015831.7ED8E1FF8518@beta.macosforge.org> References: <20090707015831.7ED8E1FF8518@beta.macosforge.org> Message-ID: On Jul 6, 2009, at 20:58, blb at macports.org wrote: > Revision: 53496 > http://trac.macports.org/changeset/53496 > Author: blb at macports.org > Date: 2009-07-06 18:58:30 -0700 (Mon, 06 Jul 2009) > Log Message: > ----------- > portfile.7 - document rpm-vercomp's return information Should we be providing a reference to ticket #11873 at this point? > Modified Paths: > -------------- > trunk/base/doc/portfile.7 > > Modified: trunk/base/doc/portfile.7 > =================================================================== > --- trunk/base/doc/portfile.7 2009-07-07 01:53:06 UTC (rev 53495) > +++ trunk/base/doc/portfile.7 2009-07-07 01:58:30 UTC (rev 53496) > @@ -1944,7 +1944,12 @@ > .It Ic md5 Ar > Compute the MD5 hashes of the file(s). > .It Ic rpm-vercomp Ar versionA Ar versionB > -Compare two RPM-format versions for equality. > +Compare two RPM-format versions for equality. The return value is > like > +strcmp(), returning -1, 0, or 1 when versionA is earlier, equal > to, or > +later than versionB, respectively. Note that some comparisions > featuring > +floating-point notation may compare incorrection, eg, 2.101 is > considered > +later than 2.2 (101 is larger than 2) which may be incorrect per some > +projects versioning methods. > .It Xo > .Ic lpush > .Ar varName From blb at macports.org Mon Jul 6 22:18:05 2009 From: blb at macports.org (Bryan Blackburn) Date: Mon, 6 Jul 2009 23:18:05 -0600 Subject: [53496] trunk/base/doc/portfile.7 In-Reply-To: References: <20090707015831.7ED8E1FF8518@beta.macosforge.org> Message-ID: <20090707051805.GM593@ninagal.withay.com> On Mon, Jul 06, 2009 at 11:14:32PM -0500, Ryan Schmidt said: > > On Jul 6, 2009, at 20:58, blb at macports.org wrote: > > >Revision: 53496 > > http://trac.macports.org/changeset/53496 > >Author: blb at macports.org > >Date: 2009-07-06 18:58:30 -0700 (Mon, 06 Jul 2009) > >Log Message: > >----------- > >portfile.7 - document rpm-vercomp's return information > > Should we be providing a reference to ticket #11873 at this point? Ah, thanks for finding the ticket, noted in r53503. Bryan [...] From jm at poure.com Tue Jul 7 00:08:56 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Tue, 07 Jul 2009 09:08:56 +0200 Subject: Shared access to Mac OS X: how to manage wakeonlan and sleep In-Reply-To: <62A1852A-08EE-4F02-BF95-EDACCCC95039@macports.org> References: <1246920443.5774.0.camel@acer> <62A1852A-08EE-4F02-BF95-EDACCCC95039@macports.org> Message-ID: <1246950536.4631.20.camel@acer> Dear friends, > Then I assume you are either all on the same subnet as this Power Mac > and can therefore send it a wakeonlan signal yourself, or else you > have a device on the local subnet (perhaps a router running DD-WRT or > another machine that's always on) to which you first connect and tell > it to wake the Power Mac. This is the case. The router is able to pass-on wake on lan over the Internet. > It uses the sleepwatcher port if installed, or AppleScript if not. > There was some set of circumstances that I cannot recall or test for > at the moment whereby sleep wouldn't work, complaining instead of an > inability to connect to the windowserver, and I believe it involved > being logged in via ssh and/or using screen. I think using > sleepwatcher instead of AppleScript may have helped with this, or at > least I was testing whether this helped. I have primarily been using > Tiger so I don't know if any of this has changed on Leopard. > > sleepwatcher has many more capabilities that might be useful to you > if you wanted to write a script or scripts to help you manage the > requirements you mentioned. Thanks. > > * Is sleep state safe? > > It should be safe to put a machine to sleep in the middle of a > compile, and it should resume where it left off when you wake up. If > that's what you mean. I would love a script that scans "ps aux" and makes sure no compilation is going on. The best way is to scan ssh connections and screen utility. If compilation are running using screen (Unix command named "screen") and sshd, when these two processes are not running, no compilation is going on. On the converse a connection to SSH should disable sleep. Bye, Jean-Michel From raimue at macports.org Tue Jul 7 00:27:29 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 07 Jul 2009 09:27:29 +0200 Subject: Shared access to Mac OS X: how to manage wakeonlan and sleep In-Reply-To: <1246920443.5774.0.camel@acer> References: <1246920443.5774.0.camel@acer> Message-ID: <4A52F8E1.2020504@macports.org> On 2009-07-07 00:47 , Jean-Michel Pour? wrote: > * How can I manage sleep so that it is triggered after an SSH > disconnection and let's say 30 minutes of inactivity. > * When using screen, I would like to be sure that the Mac does not go to > sleep. I don't know any way how to prevent the Mac going to sleep while there is SSH activity. The tool pmset offers various controls for power management. The command 'pmset noidle' prevents sleep mode for the time it is running. This could probably be helpful. Rainer From lars.hoss at me.com Tue Jul 7 00:41:52 2009 From: lars.hoss at me.com (lars.hoss at me.com) Date: Tue, 07 Jul 2009 09:41:52 +0200 Subject: [20055] Can someone please have a look? Message-ID: <48463804437116113873406421550191185518-Webmail@me.com> Greetings everyone, 13 days ago I opened a bug for bzr in order to bump its version number. As it seems bzr has no active maintainer currently. Therefore I'd like to ask if someone can have a look at my provided patches add maybe incorporate them. Cheers, Lars From jm at poure.com Tue Jul 7 00:46:18 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Tue, 07 Jul 2009 09:46:18 +0200 Subject: Shared access to Mac OS X: how to manage wakeonlan and sleep In-Reply-To: <4A52F8E1.2020504@macports.org> References: <1246920443.5774.0.camel@acer> <4A52F8E1.2020504@macports.org> Message-ID: <1246952778.5226.4.camel@acer> Le mardi 07 juillet 2009 ? 09:27 +0200, Rainer M?ller a ?crit : > I don't know any way how to prevent the Mac going to sleep while there > is SSH activity. I think we could look for shell activity. It needs some testing but $ps -ac | grep bash returns the working user shells. I configured screen Unix utility to use bash shell. We should also include in this shell a working screen (VNC). So the best on SSH logout would be test the number of working shells and go to sleep mode within 5 minutes when no shell activity exists. > The tool pmset offers various controls for power management. The > command > 'pmset noidle' prevents sleep mode for the time it is running. This > could probably be helpful. On the converse any SSH access needs to disable sleep mode. The Mac G4 seems to be power consuming. It warms up my cellar. Bye, Jean-Michel From raimue at macports.org Tue Jul 7 00:57:16 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 07 Jul 2009 09:57:16 +0200 Subject: [20055] Can someone please have a look? In-Reply-To: <48463804437116113873406421550191185518-Webmail@me.com> References: <48463804437116113873406421550191185518-Webmail@me.com> Message-ID: <4A52FFDC.4070504@macports.org> On 2009-07-07 09:41 , lars.hoss at me.com wrote: > 13 days ago I opened a bug for bzr in order to bump its version > number. As it seems bzr has no active maintainer currently. Therefore > I'd like to ask if someone can have a look at my provided patches add > maybe incorporate them. I saw the ticket, but upgrading bzr usually needs to be done in combination with the bzr-* plugins, especially bzr-rebase and bzr-svn. Updating bzr only most probably breaks the plugins. Would you care to attach updates for them as well? Rainer From raphael at ira.uka.de Tue Jul 7 01:20:16 2009 From: raphael at ira.uka.de (Raphael Straub) Date: Tue, 7 Jul 2009 10:20:16 +0200 Subject: Shared access to Mac OS X: how to manage wakeonlan and sleep In-Reply-To: <1246920443.5774.0.camel@acer> References: <1246920443.5774.0.camel@acer> Message-ID: <50128CCD-385C-42CF-9F0F-4A018971BEDE@ira.uka.de> Jean-Michel Pour? wrote: > * How can I manage sleep so that it is triggered after an SSH > disconnection and let's say 30 minutes of inactivity. > > * When using screen, I would like to be sure that the Mac does not > go to > sleep. I had the same problem. My solution is to turn off idle sleep and use the following sleep script: #!/bin/bash #how many checks are necessary to shutdown checks=$1 #time between checks (see man sleep) time=$2 ### main loop count=0 while : do if [ `who | wc -l` -eq 0 ]; then count=`expr $count + 1` else count=0; fi if [ $count -eq $checks ]; then count=0; pmset sleepnow fi sleep $time done I start this script by the following launchd plist in /Library/ LaunchDaemons: GroupName nobody Label de.uni-karlsruhe.ibds.auto_sleep OnDemand ProgramArguments /usr/local/sbin/auto_sleep.sh 12 300 RunAtLoad UserName root As you can see, the script checks every 300 seconds if somebody is logged in and if this test fails 12 times in succession, the computer is put to sleep. Regards, Raphael -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4445 bytes Desc: not available URL: From jm at poure.com Tue Jul 7 01:53:10 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Tue, 07 Jul 2009 10:53:10 +0200 Subject: Shared access to Mac OS X: how to manage wakeonlan and sleep In-Reply-To: <50128CCD-385C-42CF-9F0F-4A018971BEDE@ira.uka.de> References: <1246920443.5774.0.camel@acer> <50128CCD-385C-42CF-9F0F-4A018971BEDE@ira.uka.de> Message-ID: <1246956790.6147.1.camel@acer> Le mardi 07 juillet 2009 ? 10:20 +0200, Raphael Straub a ?crit : > As you can see, the script checks every 300 seconds if somebody is > logged in and if this test fails 12 times in succession, the > computer > is put to sleep. Your script is much more secure than mine and fixes sleep issues on a Mac OS X build platform accessed with SSH or remote access. I configured 2 checks, which is 10 minutes. Thanks! From ryandesign at macports.org Tue Jul 7 03:24:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 7 Jul 2009 05:24:38 -0500 Subject: [53410] trunk/dports/science/gmt/Portfile In-Reply-To: <799406d60907061050i61593ddep42c5e3bfecc9c2e4@mail.gmail.com> References: <20090705092522.5FA9E1FDDC89@beta.macosforge.org> <799406d60907061050i61593ddep42c5e3bfecc9c2e4@mail.gmail.com> Message-ID: On Jul 6, 2009, at 12:50, Adam Mercer wrote: >> +livecheck.type regex >> +livecheck.url http://gmt.soest.hawaii.edu/gmt/ >> gmt_home.html >> +livecheck.regex {Current version is ([0-9]+.[0-9]+.[0-9]+.)} > > This won't work on MacPorts 1.7.1, only trunk has livecheck.type. Good catch. I changed livecheck.type to livecheck.check in r53510. From jjstickel at vcn.com Tue Jul 7 08:13:06 2009 From: jjstickel at vcn.com (Jonathan Stickel) Date: Tue, 07 Jul 2009 09:13:06 -0600 Subject: py25-mayavi port submission and sandbox violation In-Reply-To: <4A2F0C96.3020006@macports.org> References: <4A2E7296.1050303@vcn.com> <4A2F0C96.3020006@macports.org> Message-ID: <4A536602.5050002@vcn.com> Rainer M?ller wrote: > On 2009-06-09 16:32, Jonathan Stickel wrote: >> $ sudo port -t install py25-mayavi >> ---> Fetching py25-mayavi >> ---> Verifying checksum(s) for py25-mayavi >> ---> Extracting py25-mayavi >> ---> Configuring py25-mayavi >> ---> Building py25-mayavi >> trace: access denied to >> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/os.py >> (*unknown*) >> trace: access denied to >> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/os.pyc >> (*unknown*) >> ... many more of these lines ... >> trace: access denied to >> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/hashlib.py >> (*unknown*) >> trace: access denied to >> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/hashlib.py >> (*unknown*) > > The problem here is that trace mode does not follow symlinks. > /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 is > a symlink to /opt/local/lib/python2.5, where the files belong to the > python25 port. But under the path used above, the files are not known to > belong to any port. > > For now, you simply cannot use trace mode for py25-* modules. > >> Warning: An activity was attempted outside sandbox: >> /var/root/.CFUserTextEncoding >> Warning: An activity was attempted outside sandbox: >> /var/root/Library/Preferences/.GlobalPreferences.plist >> Warning: An activity was attempted outside sandbox: >> /var/root/Library/Preferences/ByHost/.GlobalPreferences.001b63950c72.plist > > These /var/root accesses also happen for me a lot in trace mode but yet > I don't know what causes them or if that access would be necessary (must > be something in one of the Xcode tools?). > >> [...] >> Interestingly, I also see sandbox warnings if I install py25-scipy with >> trace mode, but that port still builds and installs OK. Now, I am very >> new to python, and I know nothing about the python portgroup used for >> python ports. I just managed to put these portfiles together by looking >> at other python ports as examples. >> >> Can someone help me resolve this issue? If this is a problem that needs >> to be reported upstream to the Enthought developers, I can do that, but >> I need to know what to report. > > Report that building and installing the software writes to files outside > the destdir, in this case your home directory. Writing to the home > directory is really bad and should be avoided. > > The upcoming privilege escalation feature should prevent this to happen > again in the future by using another user than root to compile software. > The sandbox violation for the submitted ports has been fixed upstream, and I have incorporated the fixes in the portfiles. I think the ports are now ready for inclusion in macports. Some developer attention would be appreciated. The link to the tracker is: http://trac.macports.org/ticket/19567 Thanks! Jonathan From juanger at ciencias.unam.mx Tue Jul 7 12:17:01 2009 From: juanger at ciencias.unam.mx (=?ISO-8859-1?Q?Juan_Germ=E1n_Casta=F1eda_Echevarria?=) Date: Tue, 7 Jul 2009 14:17:01 -0500 Subject: GSOC09 MacPorts GUI Message-ID: <2bad8a110907071217x7b2881fex72a689040af084ce@mail.gmail.com> Hi everyone, I?ve been very busy these days working in the GUI, I?ve learnt a lot of things and first of all I want to thank my mentor, Georg Armah, for teaching me a lot of things and being so patient with me. Also I?d like to thank all the other mentors that have helped me on IRC (I should do that more!). Current Status Now is the time to introduce you my work. I?ve done the first version of the MacPorts GUI application and this is what I have: - Support for non-default MacPorts installation locations. (Via the Preferences window) - Basic and Advanced Search (currently can only search by port name and status, but this is easily extendible) - Install, Uninstall, Upgrade port operations in background - Sync and SelfUpdate in background What doesn?t work: - Status field in ports table doesn?t change after install, uninstall and upgrade. What still needs to be implemented: - Make the Framework use a separate process to perform port commands (see the Problems section below) - Port info. This will be displayed like a quick look window. - Progress notifications and cancel command. I?m thinking in having this as a activity window (Something like Safari?s downloads window) and allow the user to queue port commands to perform then sequentially. Installation To install it from source, you only have to checkout the gsoc09-gui branch, and build the MPGUI Xcode project with the Debug-InstallMacPorts configuration svn co http://svn.macports.org/repository/macports/branches/gsoc09-gui That will build the MacPorts.framework, a MacPorts 1.8 unprivileged installation and selfupdate it. I also have included a binary version that should work out of the box. To make it work I embedded the Framework in the application bundle but we have planned that the Framework will be installed separately form the application and will live in a Frameworks directory (in /Library or the per user ~/Library). Running The first time the application is run, the preferences window will come out and you should set the Tcl installation path. Since the GUI is tested with MacPorts 1.8, you can set it to the macports1.8/Library/Tcl directory created in the build directory if you built it from source. If you?re using the binary version you can install an unprivileged macports (from trunk), selfupdate it and test with it or use your /Library/Tcl installation (this will work partially). Screenshot Since I'm having problems with my internet connection I haven't tested it thoroughly, so If you encounter any problem, please let me know. Problems The main problem has been the multithreaded implementation because for some reason (it is very difficult to debug) the destroot phase was interrupted and the thread died when installing some ports (expat, libiconv, pngcrush, ?) that use xinstall with the ?-W? flag. After doing some tests we found that when the port command was run in another process rather than in a secondary thread, it was smoothly completed. Then we opted to create a separate process to handle port commands and made the GUI to communicate with it via distributed objects messaging. This is the version you?ll test. Currently I?m working into getting that separate process to be part of the Framework and also make it send notifications back to the Framework to know the progress of the port command being run. This way it will be more transparent to the client (in this case the GUI, but it could be something else) and the GUI implementation will be simpler. Final thoughts I hope to get a lot of feedback from you regarding the interface design and also about how it is working now. I?m working to get a new version of the Framework with the changes I explained in previous paragraphs by the beginning of the next week. -- 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: MPGUI.zip Type: application/zip Size: 225097 bytes Desc: not available URL: From jeremyhu at macports.org Tue Jul 7 23:41:50 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Tue, 7 Jul 2009 23:41:50 -0700 Subject: GSOC09 MacPorts GUI In-Reply-To: <2bad8a110907071217x7b2881fex72a689040af084ce@mail.gmail.com> References: <2bad8a110907071217x7b2881fex72a689040af084ce@mail.gmail.com> Message-ID: <9000A325-5048-428A-A029-19864603E9C0@macports.org> Hi Juan, That looks very promising. I'm excited about this work. I do have a few questions. 1) Do you plan to support categories? Ports list categories that they belong to, so it would be nice to have a browsing option that allows us to "expand" categories. 2) How are variants handled? Do you have a gui way to edit $prefix/ etc/macports/variants.conf? What about per-port variants at install time? 3) You said, "I?m working into getting that separate process to be part of the Framework and also make it send notifications back to the Framework to know the progress of the port command being run." ... I'm curious what level or notification you are designing. It would probably be nice to have a window that shows a general progress bar for the current port/stage... but for debugging purposes, it would be helpful if this could be expanded via "Details" button or similar to show the verbose or debug output. 4) Do you plan to have a preferences interface to common $prefix/etc/ macports/macports.conf options? Thanks, Jeremy On Jul 7, 2009, at 12:17, Juan Germ?n Casta?eda Echevarria wrote: > Hi everyone, > > I?ve been very busy these days working in the GUI, I?ve learnt a lot > of > things and first of all I want to thank my mentor, Georg Armah, for > teaching > me a lot of things and being so patient with me. Also I?d like to > thank all > the other mentors that have helped me on IRC (I should do that more!). > Current Status > > Now is the time to introduce you my work. I?ve done the first > version of the > MacPorts GUI application and this is what I have: > > - Support for non-default MacPorts installation locations. (Via the > Preferences window) > - Basic and Advanced Search (currently can only search by port > name and > status, but this is easily extendible) > - Install, Uninstall, Upgrade port operations in background > - Sync and SelfUpdate in background > > What doesn?t work: > > - Status field in ports table doesn?t change after install, > uninstall and > upgrade. > > What still needs to be implemented: > > - Make the Framework use a separate process to perform port > commands (see > the Problems section below) > - Port info. This will be displayed like a quick look window. > - Progress notifications and cancel command. I?m thinking in > having this > as a activity window (Something like Safari?s downloads window) > and allow > the user to queue port commands to perform then sequentially. > > Installation > > To install it from source, you only have to checkout the gsoc09-gui > branch, > and build the MPGUI Xcode project with the Debug-InstallMacPorts > configuration > > > svn co http://svn.macports.org/repository/macports/branches/gsoc09-gui > > That will build the MacPorts.framework, a MacPorts 1.8 unprivileged > installation and selfupdate it. > > I also have included a binary version that should work out of the > box. To > make it work I embedded the Framework in the application bundle but > we have > planned that the Framework will be installed separately form the > application > and will live in a Frameworks directory (in /Library or the per user > ~/Library). > Running > > The first time the application is run, the preferences window will > come out > and you should set the Tcl installation path. Since the GUI is > tested with > MacPorts 1.8, you can set it to the macports1.8/Library/Tcl directory > created in the build directory if you built it from source. If > you?re using > the binary version you can install an unprivileged macports (from > trunk), > selfupdate it and test with it or use your /Library/Tcl installation > (this > will work partially). > > Screenshot > > > Since I'm having problems with my internet connection I haven't > tested it > thoroughly, so If you encounter any problem, please let me know. > Problems > > The main problem has been the multithreaded implementation because > for some > reason (it is very difficult to debug) the destroot phase was > interrupted > and the thread died when installing some ports (expat, libiconv, > pngcrush, > ?) that use xinstall with the ?-W? flag. After doing some tests we > found > that when the port command was run in another process rather than in a > secondary thread, it was smoothly completed. > > Then we opted to create a separate process to handle port commands > and made > the GUI to communicate with it via distributed objects messaging. > This is > the version you?ll test. > > Currently I?m working into getting that separate process to be part > of the > Framework and also make it send notifications back to the Framework > to know > the progress of the port command being run. This way it will be more > transparent to the client (in this case the GUI, but it could be > something > else) and the GUI implementation will be simpler. > Final thoughts > > I hope to get a lot of feedback from you regarding the interface > design and > also about how it is working now. I?m working to get a new version > of the > Framework with the changes I explained in previous paragraphs by the > beginning of the next week. > -- > Ash Mac durbatul?k, ash Mac gimbatul, ash Mac thrakatul?k agh burzum- > ishi > krimpatul. > Juanger. http://xocoruby.blogspot.com > _______________________________________________ > 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 Jul 8 13:52:03 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 8 Jul 2009 13:52:03 -0700 Subject: Net-SSLeay 1.35 Message-ID: <5DE2CE1E-BFBC-48E0-B1C3-899157A6D499@newgeo.com> Looking at the homepage below, I see that 1.30 is current, where is 1.35 coming from, and where can I find out more about this? perl5.setup Net-SSLeay 1.35 revision 1 maintainers nomaintainer description Perl extension for using OpenSSL long_description Net::SSLeay Perl module for using OpenSSL homepage http://search.cpan.org/dist/Net_SSLeay.pm/ checksums md5 1e4ec37a4467eb66a62d3c090ac9029b platforms darwin depends_build-append port:openssl configure.env OPENSSL_PREFIX=${prefix} -- Scott * If you contact me off list replace talklists@ with scott@ * From raimue at macports.org Wed Jul 8 14:03:11 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 08 Jul 2009 23:03:11 +0200 Subject: Net-SSLeay 1.35 In-Reply-To: <5DE2CE1E-BFBC-48E0-B1C3-899157A6D499@newgeo.com> References: <5DE2CE1E-BFBC-48E0-B1C3-899157A6D499@newgeo.com> Message-ID: <4A55098F.7090606@macports.org> On 2009-07-08 22:52 , Scott Haneda wrote: > Looking at the homepage below, I see that 1.30 is current, where is > 1.35 coming from, and where can I find out more about this? > > perl5.setup Net-SSLeay 1.35 > revision 1 > maintainers nomaintainer > description Perl extension for using OpenSSL > long_description Net::SSLeay Perl module for using OpenSSL > homepage http://search.cpan.org/dist/Net_SSLeay.pm/ Looks like the homepage URL is incorrect now, only old version are available there. It should be . And in fact, this is also the default homepage URL set by the perl5 port group, so this line can be removed completely. Rainer From talklists at newgeo.com Wed Jul 8 19:30:09 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 8 Jul 2009 19:30:09 -0700 Subject: openssl Message-ID: <1BC2AA56-CA1D-4164-9D26-FBDD1B642EE2@newgeo.com> If I have for example, IO::Socket::SSL, which I am guessing uses openssl, what openssl will it use, and how can I find out? I am having a good deal of trouble getting ASSP to talk over SSL. It has been suspected that it is related to incorrect versions of openssl. It was simple enough to port update openssl and get a newer version. And if I type `which openssl` I get the new version in the macports area. /opt/local/bin/openssl However, when it comes to apps that use IO::Socket::SSL, which in turn, will call openssl, how can I be sure it is using the correct openssl, not the apple one? There are no patche for IO::Socket::SSL, so it is just being installed, nothing changed in it to point to a specific openssl. Further, p5-event none of the example in IO::Socket::SSL work for me. It also checks out ok locally: root at macbook IO-Socket-SSL-1.26 $perl Makefile.PL Checking if your kit is complete... Looks good Writing Makefile for IO::Socket::SSL root at macbook IO-Socket-SSL-1.26 $make cp SSL.pm blib/lib/IO/Socket/SSL.pm Manifying blib/man3/IO::Socket::SSL.3pm root at macbook IO-Socket-SSL-1.26 $make test PERL_DL_NONLAZY=1 /opt/local/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/01loadmodule............ok t/02settings..............ok t/acceptSSL-timeout.......ok t/auto_verify_hostname....ok t/cert_no_file............ok t/compatibility...........ok t/connectSSL-timeout......ok t/core....................ok t/dhe.....................ok t/inet6...................ok t/nonblock................ok t/readline................ok t/sessions................ok t/start-stopssl...........ok t/startssl................ok t/sysread_write...........ok t/verify_hostname.........ok All tests successful. Files=17, Tests=297, 35 wallclock secs ( 2.29 cusr + 0.82 csys = 3.11 CPU) -- Scott * If you contact me off list replace talklists@ with scott@ * From blb at macports.org Wed Jul 8 20:50:56 2009 From: blb at macports.org (Bryan Blackburn) Date: Wed, 8 Jul 2009 21:50:56 -0600 Subject: openssl In-Reply-To: <1BC2AA56-CA1D-4164-9D26-FBDD1B642EE2@newgeo.com> References: <1BC2AA56-CA1D-4164-9D26-FBDD1B642EE2@newgeo.com> Message-ID: <20090709035056.GO56868@ninagal.withay.com> On Wed, Jul 08, 2009 at 07:30:09PM -0700, Scott Haneda said: > If I have for example, IO::Socket::SSL, which I am guessing uses > openssl, what openssl will it use, and how can I find out? In general, you want to make sure things link to the dependencies installed with MacPorts. See and the entry following that. > > I am having a good deal of trouble getting ASSP to talk over SSL. It > has been suspected that it is related to incorrect versions of > openssl. Note that in IO::Socket::SSL's specific instance, it doesn't actually use OpenSSL but the Net::SSLeay module (p5-net-ssleay). p5-net-ssleay, on my system, does link to MacPorts' OpenSSL: $ otool -L /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-*/auto/Net/SSLeay/SSLeay.bundle /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-thread-multi-2level/auto/Net/SSLeay/SSLeay.bundle: /opt/local/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /opt/local/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) > > It was simple enough to port update openssl and get a newer version. > And if I type `which openssl` I get the new version in the macports > area. > /opt/local/bin/openssl > > However, when it comes to apps that use IO::Socket::SSL, which in > turn, will call openssl, how can I be sure it is using the correct > openssl, not the apple one? Since it goes through Net::SSLeay to make OpenSSL calls, the best method is the one I list above using otool, to see where the binding to OpenSSL is in fact linked. > > There are no patche for IO::Socket::SSL, so it is just being > installed, nothing changed in it to point to a specific openssl. > > Further, p5-event none of the example in IO::Socket::SSL work for me. I'm not sure what you mean here. Bryan [...] > -- > Scott * If you contact me off list replace talklists@ with scott@ * > From talklists at newgeo.com Wed Jul 8 21:21:40 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 8 Jul 2009 21:21:40 -0700 Subject: openssl In-Reply-To: <20090709035056.GO56868@ninagal.withay.com> References: <1BC2AA56-CA1D-4164-9D26-FBDD1B642EE2@newgeo.com> <20090709035056.GO56868@ninagal.withay.com> Message-ID: <3769947A-38CF-4F89-8293-E55277165DD8@newgeo.com> On Jul 8, 2009, at 8:50 PM, Bryan Blackburn wrote: > On Wed, Jul 08, 2009 at 07:30:09PM -0700, Scott Haneda said: >> If I have for example, IO::Socket::SSL, which I am guessing uses >> openssl, what openssl will it use, and how can I find out? > > In general, you want to make sure things link to the dependencies > installed > with MacPorts. See > > > > > and the entry following that. Thanks. One thing that is not clear, is you say "make sure things link to". How does one do that, the docs above do not explain that. When I make a port file, especially in the case of p5's, it is pretty simple. I have never seen any way to specify any paths for linking to any dependencies libs. >> I am having a good deal of trouble getting ASSP to talk over SSL. It >> has been suspected that it is related to incorrect versions of >> openssl. > > Note that in IO::Socket::SSL's specific instance, it doesn't > actually use > OpenSSL but the Net::SSLeay module (p5-net-ssleay). p5-net-ssleay, > on my > system, does link to MacPorts' OpenSSL: Glad you found that, as that is the p5 that is probably related to some of the issues I am having. > $ otool -L /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-*/auto/Net/ > SSLeay/SSLeay.bundle > /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-thread-multi-2level/ > auto/Net/SSLeay/SSLeay.bundle: > /opt/local/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, > current version 0.9.8) > /opt/local/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, > current version 0.9.8) When I run that on the machine I am having issues with: $otool -L /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-*/auto/Net/ SSLeay/SSLeay.bundle /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/Net/SSLeay/ SSLeay.bundle: /opt/local/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /opt/local/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) I get one more line than you do, not sure what that means. I updated openssl, `sudo port updgrade openssl` $which openssl /opt/local/bin/openssl $/opt/local/bin/openssl version OpenSSL 0.9.8k 25 Mar 2009 Does that mean, that p5-net-ssleay will now use the updated version? Maybe I do not get this, and openssl updates just the binary, and has nothing to do with the libs. What I do know, is ASSP needs p5-net-ssleay, there is a suspicion that the openssl version I am working against is too old, or too buggy, so I need to try to solve that. I do not know if I just need to update openssl via ports, or if I need to remove all related perl modules, and install them again, or if I need to remove all of ASSP and install that again as well to get the new bits. Toss in postfix, which also uses openssl as well and I am not sure what and where I need to look to update things. Add to that, ASSP is on a different machine than postfix, and I have two places I get to answer these questions. Ugh :) >> It was simple enough to port update openssl and get a newer version. >> And if I type `which openssl` I get the new version in the macports >> area. >> /opt/local/bin/openssl >> >> However, when it comes to apps that use IO::Socket::SSL, which in >> turn, will call openssl, how can I be sure it is using the correct >> openssl, not the apple one? > > Since it goes through Net::SSLeay to make OpenSSL calls, the best > method is > the one I list above using otool, to see where the binding to > OpenSSL is in > fact linked. I see where it is linked, and before, openssl version returned OpenSSL 0.9.7l 28 Sep 2006 So, by seeing "OpenSSL 0.9.8k 25 Mar 2009" in the version that I now have installed, and seeing 0.9.8 returned by otool, does that mean that when I ran port update openssl those files were updated? Or, does it mean that macports already happened to have the 0.98 versions in place, and I just happened to get to use those? >> There are no patche for IO::Socket::SSL, so it is just being >> installed, nothing changed in it to point to a specific openssl. >> >> Further, p5-event none of the example in IO::Socket::SSL work for me. > > I'm not sure what you mean here. Me neither :) I had something on the clipboard I did not mean to have. I think I meant that, in the IO::Socket::SSL download, there are a set of sample files, and running them, none of them work, and all barf with errors. Thanks -- Scott * If you contact me off list replace talklists@ with scott@ * From blb at macports.org Thu Jul 9 01:07:38 2009 From: blb at macports.org (Bryan Blackburn) Date: Thu, 9 Jul 2009 02:07:38 -0600 Subject: openssl In-Reply-To: <3769947A-38CF-4F89-8293-E55277165DD8@newgeo.com> References: <1BC2AA56-CA1D-4164-9D26-FBDD1B642EE2@newgeo.com> <20090709035056.GO56868@ninagal.withay.com> <3769947A-38CF-4F89-8293-E55277165DD8@newgeo.com> Message-ID: <20090709080738.GT56868@ninagal.withay.com> On Wed, Jul 08, 2009 at 09:21:40PM -0700, Scott Haneda said: [...] > > > > > > > >and the entry following that. > > Thanks. One thing that is not clear, is you say "make sure things > link to". How does one do that, the docs above do not explain that. > When I make a port file, especially in the case of p5's, it is pretty > simple. I have never seen any way to specify any paths for linking > to any dependencies libs. Yeah, the FAQ is more user-oriented rather than port maintainer oriented. Explaining the how is extremely complicated due to the varied nature of software (does it build executables, libraries, bundles, frameworks, etc)... By default though, port should be telling most software how to find the right headers and libraries installed by MacPorts with various configure-time settings. You should be able to see this if you run port in debug, eg for p5-io-socket-ssl: DEBUG: Environment: CFLAGS='-pipe -O2 -arch i386' CPPFLAGS='-I/opt/local/include' CXXFLAGS='-pipe -O2 -arch i386' MACOSX_DEPLOYMENT_TARGET='10.5' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/g++-4.0' F90FLAGS='-pipe -O2 -arch i386' LDFLAGS='-L/opt/local/lib -arch i386' FCFLAGS='-pipe -O2 -arch i386' OBJC='/usr/bin/gcc-4.0' INSTALL='/usr/bin/install -c' PERL_AUTOINSTALL='--skipdeps' OBJCFLAGS='-pipe -O2 -arch i386' FFLAGS='-pipe -O2 -arch i386' CC='/usr/bin/gcc-4.0' Note the -I/opt/local/include and -L/opt/local/lib in there. [...] > > When I run that on the machine I am having issues with: > $otool -L /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-*/auto/Net/ > SSLeay/SSLeay.bundle > /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/Net/SSLeay/ > SSLeay.bundle: > /opt/local/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, > current version 0.9.8) > /opt/local/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, > current version 0.9.8) > /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current > version 1.2.3) > /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version > 47.1.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 111.1.4) > > I get one more line than you do, not sure what that means. I believe libmx can be safely ignored so it looks fine, especially the OpenSSL libs (libssl and libcrypto) as well as libz, all being the MacPorts-provided ones. > > I updated openssl, `sudo port updgrade openssl` > $which openssl > /opt/local/bin/openssl > $/opt/local/bin/openssl version > OpenSSL 0.9.8k 25 Mar 2009 > > Does that mean, that p5-net-ssleay will now use the updated version? > Maybe I do not get this, and openssl updates just the binary, and has > nothing to do with the libs. Upgrading the port upgrades all bits for it, any binaries, libs, headers, etc. So if 'openssl version' says 0.9.8k, then the headers and libraries should be that version as well. > > What I do know, is ASSP needs p5-net-ssleay, there is a suspicion > that the openssl version I am working against is too old, or too > buggy, so I need to try to solve that. Hard to say without knowing how things aren't working; I know some software doesn't like when you compile using one version of headers then link against a different version of libraries. > > I do not know if I just need to update openssl via ports, or if I > need to remove all related perl modules, and install them again, or > if I need to remove all of ASSP and install that again as well to get > the new bits. Worst case would call for rebuilding anything which links against OpenSSL, but also make sure everything which wants it declares a dependency on the port. Otherwise, you end up with one port without the dependency and then it may link against the system OpenSSL, then another port comes along with that dependency and installs it then links against MacPorts' OpenSSL. If you try using those two together, you get a mess. > > Toss in postfix, which also uses openssl as well and I am not sure > what and where I need to look to update things. Add to that, ASSP is > on a different machine than postfix, and I have two places I get to > answer these questions. Ugh :) If they run on different servers, then precise OpenSSL versions should technically not matter, as long as the SSL/TLS protocols are properly followed. Of course if there's a bug in the protocol handling of a given version, then you have a problem. > > >>It was simple enough to port update openssl and get a newer version. > >>And if I type `which openssl` I get the new version in the macports > >>area. > >>/opt/local/bin/openssl > >> > >>However, when it comes to apps that use IO::Socket::SSL, which in > >>turn, will call openssl, how can I be sure it is using the correct > >>openssl, not the apple one? > > > >Since it goes through Net::SSLeay to make OpenSSL calls, the best > >method is > >the one I list above using otool, to see where the binding to > >OpenSSL is in > >fact linked. > > I see where it is linked, and before, openssl version returned > OpenSSL 0.9.7l 28 Sep 2006 This sounds like the system OpenSSL so perhaps when you ran it that time you didn't have the openssl port installed yet? > So, by seeing "OpenSSL 0.9.8k 25 Mar 2009" in the version that I now > have installed, and seeing 0.9.8 returned by otool, does that mean > that when I ran port update openssl those files were updated? Or, > does it mean that macports already happened to have the 0.98 versions > in place, and I just happened to get to use those? Hard to say, if you used 'port install openssl' then you didn't have the port installed at all; if you used upgrade, then that's a bit odd as the openssl port has never been at 0.9.7l, it went from 0.9.7g to 0.9.8 four years ago: > > >>There are no patche for IO::Socket::SSL, so it is just being > >>installed, nothing changed in it to point to a specific openssl. > >> > >>Further, p5-event none of the example in IO::Socket::SSL work for me. > > > >I'm not sure what you mean here. > > Me neither :) I had something on the clipboard I did not mean to > have. I think I meant that, in the IO::Socket::SSL download, there > are a set of sample files, and running them, none of them work, and > all barf with errors. I tried a couple of them, the client and server are able to talk to each other, though that isn't too surprising since they are using the same software; I also tried connecting to the server with the system openssl command, and it was able to get the SSL cert just fine... Bryan > > Thanks > -- > Scott * If you contact me off list replace talklists@ with scott@ * From talklists at newgeo.com Thu Jul 9 11:25:26 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 9 Jul 2009 11:25:26 -0700 Subject: openssl In-Reply-To: <20090709080738.GT56868@ninagal.withay.com> References: <1BC2AA56-CA1D-4164-9D26-FBDD1B642EE2@newgeo.com> <20090709035056.GO56868@ninagal.withay.com> <3769947A-38CF-4F89-8293-E55277165DD8@newgeo.com> <20090709080738.GT56868@ninagal.withay.com> Message-ID: On Jul 9, 2009, at 1:07 AM, Bryan Blackburn wrote: > On Wed, Jul 08, 2009 at 09:21:40PM -0700, Scott Haneda said: > [...] >>> >>> http://trac.macports.org/wiki/FAQ#WillMacPortslinktosystemlibrariesratherthanitsown >>> >>> and the entry following that. >> >> Thanks. One thing that is not clear, is you say "make sure things >> link to". How does one do that, the docs above do not explain that. >> When I make a port file, especially in the case of p5's, it is pretty >> simple. I have never seen any way to specify any paths for linking >> to any dependencies libs. > > By default though, port should be telling most software how to find > the > right headers and libraries installed by MacPorts with various > configure-time settings. You should be able to see this if you run > port in > debug, eg for p5-io-socket-ssl: > > DEBUG: Environment: CFLAGS='-pipe -O2 -arch i386' CPPFLAGS='-I/opt/ > local/include' CXXFLAGS='-pipe -O2 -arch i386' > MACOSX_DEPLOYMENT_TARGET='10.5' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/ > g++-4.0' F90FLAGS='-pipe -O2 -arch i386' LDFLAGS='-L/opt/local/lib - > arch i386' FCFLAGS='-pipe -O2 -arch i386' OBJC='/usr/bin/gcc-4.0' > INSTALL='/usr/bin/install -c' PERL_AUTOINSTALL='--skipdeps' > OBJCFLAGS='-pipe -O2 -arch i386' FFLAGS='-pipe -O2 -arch i386' CC='/ > usr/bin/gcc-4.0' > > Note the -I/opt/local/include and -L/opt/local/lib in there. Ok, I always run on debug mode, I will look out for those thing. When I am installing something like ASSP, it has 20 or so p5's to do, so there is a lot going by. I will do them one at a time and look at each. >> I updated openssl, `sudo port updgrade openssl` >> $which openssl >> /opt/local/bin/openssl >> $/opt/local/bin/openssl version >> OpenSSL 0.9.8k 25 Mar 2009 >> >> Does that mean, that p5-net-ssleay will now use the updated version? >> Maybe I do not get this, and openssl updates just the binary, and has >> nothing to do with the libs. > > Upgrading the port upgrades all bits for it, any binaries, libs, > headers, > etc. So if 'openssl version' says 0.9.8k, then the headers and > libraries > should be that version as well. port upgrade openssl took all of 5 seconds, if that. I would have expected it to take longer, if it had to rebuilt modules that depended on it. Or are these libs and headers just files that get pointed to, and not built into the binary. The binary just holds paths to the libs and headers? So, If I were to take a binary that was made on an intel machine, and take it to another identical intel machine, but did not bring along the libs and headers, it would not work until I did so? >> What I do know, is ASSP needs p5-net-ssleay, there is a suspicion >> that the openssl version I am working against is too old, or too >> buggy, so I need to try to solve that. > > Hard to say without knowing how things aren't working; I know some > software > doesn't like when you compile using one version of headers then link > against > a different version of libraries. ASSP is a email proxy, it supports SSL and TLS mostly by using p5's to make it all happen. The setup is Internet -> ASSP -> MTA If I made a SSL or TLS enabled connection directly to the MTA on port 25, SSL and/or TLS will work fine. If I make a connection to the ASSP proxy, it works some of the time. I send a email in the command line: `mail user at remote-mta-machine` This will always work `mail user at assp-proxy` this simply hits port 25, which is set to proxy to the far end MTA. It fails the SSL parts entirely. Some hosts that I send the `mail` command from work, others do not. I subscribed to a few mailing lists, some get through, some do not. I can use openssl as a client, and connect to the remote far end MTA just fine, connecting to ASSP, and I get the connection, but that is as far as I get. I have little knowledge of how this all works, so it is hard for me to even make test cases. >> I do not know if I just need to update openssl via ports, or if I >> need to remove all related perl modules, and install them again, or >> if I need to remove all of ASSP and install that again as well to get >> the new bits. > > Worst case would call for rebuilding anything which links against > OpenSSL, > but also make sure everything which wants it declares a dependency > on the > port. Otherwise, you end up with one port without the dependency > and then > it may link against the system OpenSSL, then another port comes > along with > that dependency and installs it then links against MacPorts' OpenSSL. > If you try using those two together, you get a mess. Perhaps I am in this mess. I made many of these p5 port files, and most just amounted to finding an older p5, editing the name and version, dropping in a description, maintainer, and hash. Maybe there was more research into those port files I needed to do. I looked at cpan for any dependencies, and add those as needed, but that is as far as I usually took it, other than running it, and if there were test cases, giving them a quick try. If it loaded, I considered it ok. Last night, I ran sudo port -df uninstall all and removed everything. I then ran sudo port -d install assp. It all went in, in one go, no errors, that was nice. However, I am still not able to get ASSP to work in SSL mode. I know what p5's ASSP installs, and can easily tell what dependencies I need to track down to look at. However, those depend on perl, which was installed, and curses was installed; a lot of other things too. Can I be reasonably confident, if any of those use openssl libs and headers, I need not run otool on them, and do any checking? Can you suggest any automated why to run otool against all the p5's and anything else you can think of, so I can find out if this is the area of my problems. This very well could be a bug in ASSP, and I am yet to find more than one person who has gotten this to work. So far, I am having a hard time finding the person who wrote the SSL sub routines in ASSP, to even get to the point where it can be debugged. >> Toss in postfix, which also uses openssl as well and I am not sure >> what and where I need to look to update things. Add to that, ASSP is >> on a different machine than postfix, and I have two places I get to >> answer these questions. Ugh :) > > If they run on different servers, then precise OpenSSL versions should > technically not matter, as long as the SSL/TLS protocols are properly > followed. Of course if there's a bug in the protocol handling of a > given > version, then you have a problem. Agreed. I have been delivering email from several machines that can not deliver to ASSP, for years. Millions of messages sent from php scripts that end up on some server somewhere. I am confident that things are ok on those sending machines. I am pretty sure the openssl versions on the MUA sending side, and the destination receiving side are ok. So something is happening on the ASSP machine. (I am running the ASSP proxy on a separate machine) >> So, by seeing "OpenSSL 0.9.8k 25 Mar 2009" in the version that I now >> have installed, and seeing 0.9.8 returned by otool, does that mean >> that when I ran port update openssl those files were updated? Or, >> does it mean that macports already happened to have the 0.98 versions >> in place, and I just happened to get to use those? > > Hard to say, if you used 'port install openssl' then you didn't have > the > port installed at all; if you used upgrade, then that's a bit odd as > the > openssl port has never been at 0.9.7l, it went from 0.9.7g to 0.9.8 > four > years ago: > > I used upgrade. I suspect this was PATH related, I may have been logged in as a user that did not have the .profile set up so it was polling the Apple supplied version. >>>> There are no patche for IO::Socket::SSL, so it is just being >>>> installed, nothing changed in it to point to a specific openssl. >>>> >>>> Further, p5-event none of the example in IO::Socket::SSL work for >>>> me. >>> >>> I'm not sure what you mean here. >> >> Me neither :) I had something on the clipboard I did not mean to >> have. I think I meant that, in the IO::Socket::SSL download, there >> are a set of sample files, and running them, none of them work, and >> all barf with errors. > > I tried a couple of them, the client and server are able to talk to > each > other, though that isn't too surprising since they are using the same > software; I also tried connecting to the server with the system > openssl > command, and it was able to get the SSL cert just fine... Can you show me how you tried them, I was not able to get them to work, but all I did was `perl filename` which probably was not a valid way to test. I really do not know perl, or SSL vocabulary well enough to properly test these out. Thanks Bryan. -- Scott * If you contact me off list replace talklists@ with scott@ * From blb at macports.org Fri Jul 10 00:52:44 2009 From: blb at macports.org (Bryan Blackburn) Date: Fri, 10 Jul 2009 01:52:44 -0600 Subject: openssl In-Reply-To: References: <1BC2AA56-CA1D-4164-9D26-FBDD1B642EE2@newgeo.com> <20090709035056.GO56868@ninagal.withay.com> <3769947A-38CF-4F89-8293-E55277165DD8@newgeo.com> <20090709080738.GT56868@ninagal.withay.com> Message-ID: <20090710075244.GQ89345@ninagal.withay.com> On Thu, Jul 09, 2009 at 11:25:26AM -0700, Scott Haneda said: > On Jul 9, 2009, at 1:07 AM, Bryan Blackburn wrote: > >On Wed, Jul 08, 2009 at 09:21:40PM -0700, Scott Haneda said: [...] > >>Does that mean, that p5-net-ssleay will now use the updated version? > >>Maybe I do not get this, and openssl updates just the binary, and has > >>nothing to do with the libs. > > > >Upgrading the port upgrades all bits for it, any binaries, libs, > >headers, > >etc. So if 'openssl version' says 0.9.8k, then the headers and > >libraries > >should be that version as well. > > port upgrade openssl took all of 5 seconds, if that. I would have > expected it to take longer, if it had to rebuilt modules that > depended on it. Or are these libs and headers just files that get > pointed to, and not built into the binary. The binary just holds > paths to the libs and headers? If upgrade is really quick like that, sounds like it actually had nothing to do (eg, you're already current for the given port). 'port upgrade' will also upgrade ports on which openssl depends, but not ports which themselves depend on openssl. The way the openssl binary works is that it is linked to the libssl and libcrypto libraries (as you can see if you use 'otool -L /opt/local/bin/openssl'), and these paths are encoded in the binary. > > So, If I were to take a binary that was made on an intel machine, and > take it to another identical intel machine, but did not bring along > the libs and headers, it would not work until I did so? Because of those paths being encoded into the binary, copying only the openssl file would not work since you'd also need the libs. > > >>What I do know, is ASSP needs p5-net-ssleay, there is a suspicion > >>that the openssl version I am working against is too old, or too > >>buggy, so I need to try to solve that. > > > >Hard to say without knowing how things aren't working; I know some > >software > >doesn't like when you compile using one version of headers then > >link against > >a different version of libraries. > > ASSP is a email proxy, it supports SSL and TLS mostly by using p5's > to make it all happen. The setup is Internet -> ASSP -> MTA > > If I made a SSL or TLS enabled connection directly to the MTA on port > 25, SSL and/or TLS will work fine. > > If I make a connection to the ASSP proxy, it works some of the time. > I send a email in the command line: > `mail user at remote-mta-machine` > This will always work > > `mail user at assp-proxy` this simply hits port 25, which is set to > proxy to the far end MTA. It fails the SSL parts entirely. Some > hosts that I send the `mail` command from work, others do not. I > subscribed to a few mailing lists, some get through, some do not. Some addresses working and others not, that doesn't sound like an initial connection issue (which would implicate SSL/TLS) but something after that. By 'fails the SSL parts entirely' what exactly do you mean, does it fail to finish the initial TCP handshake, fail to verify the cert, something else? > > I can use openssl as a client, and connect to the remote far end MTA > just fine, connecting to ASSP, and I get the connection, but that is > as far as I get. If you can see the cert (eg, by using --showcerts with s_client) then that sounds like SSL/TLS is working fine. [...] > > I know what p5's ASSP installs, and can easily tell what dependencies > I need to track down to look at. However, those depend on perl, > which was installed, and curses was installed; a lot of other things > too. Can I be reasonably confident, if any of those use openssl libs > and headers, I need not run otool on them, and do any checking? The big problem is that for any new ports, checking linkage is a good thing, especially for bits that get loaded into larger programs (like perl modules). If you aren't careful you can end up with one part linking to the system library and another part to the MacPorts equivalent. This can then lead to version mismatches and software crashing. > > Can you suggest any automated why to run otool against all the p5's > and anything else you can think of, so I can find out if this is the > area of my problems. I'm not aware of anything automated, I simply run 'otool -L' against any executables in bin/, .dylib files, .so files, and .bundle files. For a new port I usually just use 'port destroot' to get it to build but not install, then check the contents of the destroot for these files and check them there. For p5-net-ssleay, for example, it has one bundle file (which is its linkage to OpenSSL, through the C interface) in /opt/local/lib/perl5/vendor_perl/5.8.9/darwin*/auto/Net/SSLeay/SSLeay.bundle so checking that will show against which OpenSSL it is linked (I use darwin* in the path there because it may be different depending on how perl5.8 is installed variant-wise). [...] > > Can you show me how you tried them, I was not able to get them to > work, but all I did was `perl filename` which probably was not a > valid way to test. I really do not know perl, or SSL vocabulary well > enough to properly test these out. After it built (I have port's autoclean off so the build dir was still available), I simply move into the top dir for p5-io-socket-ssl (the one with the example directory among others). From here, I ran $ /opt/local/bin/perl5.8 example/ssl_server.pl in one terminal and the ssl_client.pl in another, and watched those talk fine. Leaving the ssl_server process up, I then used $ openssl s_client -connect localhost:9000 -showcerts -debug to connect to the server and verify it was able to get the cert, which it did. Bryan > > Thanks Bryan. > -- > Scott * If you contact me off list replace talklists@ with scott@ * > From jm at poure.com Fri Jul 10 00:57:23 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Fri, 10 Jul 2009 09:57:23 +0200 Subject: Impact of building using screen Unix utility Message-ID: <1247212643.4093.1.camel@acer> Dear friends, Building packages takes some time as I am using a G4. So I connect using SSH, start a new screen session (screen is the Unix executable). Screen is configured with the same variables $PATH and bash. Can screen impact on the quality of the build and create compilation errors? Thanks, Jean-Michel From and.damore at macports.org Fri Jul 10 10:02:29 2009 From: and.damore at macports.org (Andrea D'Amore) Date: Fri, 10 Jul 2009 19:02:29 +0200 Subject: Impact of building using screen Unix utility In-Reply-To: <1247212643.4093.1.camel@acer> References: <1247212643.4093.1.camel@acer> Message-ID: <6E37D361-44F3-4287-B74E-E72A818D15C5@macports.org> On 10/lug/09, at 09:57, Jean-Michel Pour? wrote: > Screen is configured with the same variables $PATH and bash. > Can screen impact on the quality of the build and create compilation > errors? With your premise it shouldn't, look at your $PATH to check something weird but the building environment should be the same. What do you mean exactly with the "quality" of the build? That a Terminal bash session would build a port while a screen bash session would break it? From ryandesign at macports.org Fri Jul 10 12:10:26 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 10 Jul 2009 14:10:26 -0500 Subject: [53627] trunk/dports/python/py25-checker In-Reply-To: <20090710160645.7527C20531D5@beta.macosforge.org> References: <20090710160645.7527C20531D5@beta.macosforge.org> Message-ID: <54F99A18-2A72-496F-8594-7F0E0CE7706E@macports.org> On Jul 10, 2009, at 11:06, jmr at macports.org wrote: > Revision: 53627 > http://trac.macports.org/changeset/53627 > Author: jmr at macports.org > Date: 2009-07-10 09:06:43 -0700 (Fri, 10 Jul 2009) > Log Message: > ----------- > py25-checker: install pychecker2 (needed for spe) > > Modified Paths: > -------------- > trunk/dports/python/py25-checker/Portfile > trunk/dports/python/py25-checker/files/patch-setup.py.diff > > Modified: trunk/dports/python/py25-checker/Portfile > =================================================================== > --- trunk/dports/python/py25-checker/Portfile 2009-07-10 12:53:07 > UTC (rev 53626) > +++ trunk/dports/python/py25-checker/Portfile 2009-07-10 16:06:43 > UTC (rev 53627) > @@ -5,6 +5,7 @@ > > name py25-checker > version 0.8.18 > +revision 1 > categories python > maintainers nomaintainer > platforms darwin freebsd > > Modified: trunk/dports/python/py25-checker/files/patch-setup.py.diff > =================================================================== > --- trunk/dports/python/py25-checker/files/patch-setup.py.diff > 2009-07-10 12:53:07 UTC (rev 53626) > +++ trunk/dports/python/py25-checker/files/patch-setup.py.diff > 2009-07-10 16:06:43 UTC (rev 53627) > @@ -1,11 +1,20 @@ > ---- setup.py 2006-02-04 11:29:46.000000000 +0900 > -+++ setup.py.new 2006-05-10 22:26:36.000000000 +0900 > -@@ -211,7 +211,7 @@ > +--- setup.py.orig 2008-08-18 14:53:12.000000000 +1000 > ++++ setup.py 2009-07-11 02:02:09.000000000 +1000 > +@@ -216,7 +216,7 @@ > @raise Exception: If script cannot be created on disk. > """ > try: > - checker_path = os.path.join(package_path, "checker.py") > -+ checker_path = os.path.join("PYTHONLIB/pychecker", > "checker.py") > ++ checker_path = os.path.join("/opt/local/lib/python2.5/site- > packages/pychecker", "checker.py") /opt/local is hardcoded here. > if sys.platform == "win32": > - script_str = "%s %s %%1 %%2 %%3 %%4 %%5 %%6 %%7 %%8 %%9 > \n" % (sys.executable, checker_path) > + script_str = "%s %s %%*\n" % (sys.executable, checker_path) > else: > +@@ -258,7 +258,7 @@ > + 'author' : "Neal Norwitz", > + 'author_email' : "nnorwitz at gmail.com", > + 'url' : "http://pychecker.sourceforge.net/", > +- 'packages' : [ 'pychecker', ], > ++ 'packages' : [ 'pychecker', 'pychecker2', ], > + 'scripts' : [ "pychecker" ], # note: will be > replaced by customized action > + 'data_files' : [ ( "pychecker", DATA_FILES, ) ], > + 'long_description' : LONG_DESCRIPTION, From ryandesign at macports.org Fri Jul 10 12:11:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 10 Jul 2009 14:11:49 -0500 Subject: [53622] trunk/dports/databases/mongodb In-Reply-To: <20090710072523.01EDC204AEA3@beta.macosforge.org> References: <20090710072523.01EDC204AEA3@beta.macosforge.org> Message-ID: <23FC634C-E3A3-4B39-8C18-05FEDF76BD91@macports.org> On Jul 10, 2009, at 02:25, blb at macports.org wrote: > Revision: 53622 > http://trac.macports.org/changeset/53622 > Author: blb at macports.org > Date: 2009-07-10 00:25:19 -0700 (Fri, 10 Jul 2009) > Log Message: > ----------- > databases/mongodb - update to 0.9.6 (ticket #20252); prepend > instead of append for LIBPATH so self-built libs are seen over > already-installed during upgrades [snip] > Modified: trunk/dports/databases/mongodb/files/patch-SConstruct.diff > =================================================================== > --- trunk/dports/databases/mongodb/files/patch-SConstruct.diff > 2009-07-10 05:53:05 UTC (rev 53621) > +++ trunk/dports/databases/mongodb/files/patch-SConstruct.diff > 2009-07-10 07:25:19 UTC (rev 53622) > @@ -1,6 +1,6 @@ > ---- SConstruct.orig 2009-06-23 11:41:23.000000000 -0600 > -+++ SConstruct 2009-07-02 19:55:42.000000000 -0600 > -@@ -273,23 +273,16 @@ > +--- SConstruct.orig 2009-07-08 11:25:25.000000000 -0600 > ++++ SConstruct 2009-07-09 23:47:17.000000000 -0600 > +@@ -304,23 +304,16 @@ > > env.Append( CPPPATH=[ "-I/System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Headers/" ] ) > > @@ -21,15 +21,15 @@ > - else: > - env.Append( CPPPATH=[ "/sw/include" , "/opt/local/ > include"] ) > - env.Append( LIBPATH=["/sw/lib/", "/opt/local/lib"] ) > -+ env.Append( CPPPATH=["@@PREFIX@@/include"] ) > -+ env.Append( LIBPATH=["@@PREFIX@@/lib/"] ) > ++ env.Append( CPPPATH=["/mp/include"] ) > ++ env.Append( LIBPATH=["/mp/lib/"] ) Your MacPorts prefix /mp got inserted into this patch in several places. > + env["CC"] = os.environ["CC"] > + env["CPP"] = os.environ["CPP"] > + env["CXX"] = os.environ["CXX"] > > elif "linux2" == os.sys.platform: > linux = True > -@@ -586,11 +579,7 @@ > +@@ -624,11 +617,7 @@ > haveReadLine = False > if darwin: > myenv.Append( CPPDEFINES=[ "USE_READLINE" ] ) > @@ -38,11 +38,29 @@ > - myCheckLib( "ncurses" , True ) > - else: > - myenv.Append( LINKFLAGS=" /usr/lib/ > libreadline.dylib " ) > -+ myenv.Append( LINKFLAGS=" @@PREFIX@@/lib/ > libreadline.dylib " ) > ++ myenv.Append( LINKFLAGS=" /mp/lib/libreadline.dylib " ) > elif myCheckLib( "readline" , release and nix , > staticOnly=release ): > myenv.Append( CPPDEFINES=[ "USE_READLINE" ] ) > - myCheckLib( "tinfo" , staticOnly=release ) > -@@ -757,8 +746,6 @@ > + myCheckLib( "ncurses" , staticOnly=release ) > +@@ -714,7 +703,7 @@ > + clientEnv = env.Clone(); > + clientEnv.Append( CPPPATH=["../"] ) > + clientEnv.Prepend( LIBS=[ "mongoclient"] ) > +-clientEnv.Append( LIBPATH=["."] ) > ++clientEnv.Prepend( LIBPATH=["."] ) > + l = clientEnv[ "LIBS" ] > + removeIfInList( l , "pcre" ) > + removeIfInList( l , "pcrecpp" ) > +@@ -722,7 +711,7 @@ > + testEnv = env.Clone() > + testEnv.Append( CPPPATH=["../"] ) > + testEnv.Prepend( LIBS=[ "mongotestfiles" , "unittest" ] ) > +-testEnv.Append( LIBPATH=["."] ) > ++testEnv.Prepend( LIBPATH=["."] ) > + > + > + # ----- TARGETS ------ > +@@ -793,8 +782,6 @@ > shellEnv["LINKFLAGS"].remove("-m64") > shellEnv["CPPPATH"].remove( "/usr/64/include" ) > shellEnv["LIBPATH"].remove( "/usr/64/lib" ) > @@ -51,3 +69,12 @@ > > l = shellEnv["LIBS"] > if linux64: > +@@ -816,7 +803,7 @@ > + > + shellEnv.VariantDir( "32bit" , "." ) > + else: > +- shellEnv.Append( LIBPATH=[ "." ] ) > ++ shellEnv.Prepend( LIBPATH=[ "." ] ) > + > + shellEnv = doConfigure( shellEnv , needPcre=False , > needJava=False , shell=True ) > From ryandesign at macports.org Fri Jul 10 12:17:16 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 10 Jul 2009 14:17:16 -0500 Subject: Impact of building using screen Unix utility In-Reply-To: <1247212643.4093.1.camel@acer> References: <1247212643.4093.1.camel@acer> Message-ID: On Jul 10, 2009, at 02:57, Jean-Michel Pour? wrote: > Building packages takes some time as I am using a G4. So I connect > using > SSH, start a new screen session (screen is the Unix executable). > Screen > is configured with the same variables $PATH and bash. > > Can screen impact on the quality of the build and create compilation > errors? I sometimes use "screen" to build ports on my systems. I see no reason why it would affect the build. It only annoys me by making the Terminal's scrollback buffer useless. (Is there a way to scroll up within screen?) From kthenriksson at gmail.com Fri Jul 10 12:21:28 2009 From: kthenriksson at gmail.com (Kristofer Henriksson) Date: Fri, 10 Jul 2009 15:21:28 -0400 Subject: Impact of building using screen Unix utility In-Reply-To: References: <1247212643.4093.1.camel@acer> Message-ID: <4809057c0907101221m504f7efcv790894924b5a1c70@mail.gmail.com> That's odd, because I've never had a problem using Terminal's scrollback at the same time as using screen. At any rate, screen's scrollback can be accessed with "ctrl-a [", and then use arrow keys or vi keys to move around. Push "q" when you want to stop. (Sorry for the double reply Ryan, I forgot to Reply-all the first time.) 2009/7/10 Ryan Schmidt : > On Jul 10, 2009, at 02:57, Jean-Michel Pour? wrote: > >> Building packages takes some time as I am using a G4. So I connect using >> SSH, start a new screen session (screen is the Unix executable). Screen >> is configured with the same variables $PATH and bash. >> >> Can screen impact on the quality of the build and create compilation >> errors? > > I sometimes use "screen" to build ports on my systems. I see no reason why > it would affect the build. It only annoys me by making the Terminal's > scrollback buffer useless. (Is there a way to scroll up within screen?) > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From wsiegrist at apple.com Fri Jul 10 12:22:30 2009 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 10 Jul 2009 12:22:30 -0700 Subject: Impact of building using screen Unix utility In-Reply-To: References: <1247212643.4093.1.camel@acer> Message-ID: On Jul 10, 2009, at 12:17 PM, Ryan Schmidt wrote: > On Jul 10, 2009, at 02:57, Jean-Michel Pour? wrote: > >> Building packages takes some time as I am using a G4. So I connect >> using >> SSH, start a new screen session (screen is the Unix executable). >> Screen >> is configured with the same variables $PATH and bash. >> >> Can screen impact on the quality of the build and create compilation >> errors? > > I sometimes use "screen" to build ports on my systems. I see no > reason why it would affect the build. It only annoys me by making > the Terminal's scrollback buffer useless. (Is there a way to scroll > up within screen?) > CTRL-a [ It has vi-like navigation and searching. -Bill From jeremy at lavergne.gotdns.org Fri Jul 10 12:26:38 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 10 Jul 2009 15:26:38 -0400 Subject: Impact of building using screen Unix utility In-Reply-To: References: <1247212643.4093.1.camel@acer> Message-ID: <8DD2EC43-76BB-4677-A2A8-D5283579E08C@lavergne.gotdns.org> And if ^a gets in your way for jumping in shells, you can change it to be ^b in the config. Additionally, ^a ESC works for scrollback. On Jul 10, 2009, at 3:22 PM, William Siegrist wrote: > CTRL-a [ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Fri Jul 10 12:29:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 10 Jul 2009 14:29:23 -0500 Subject: Impact of building using screen Unix utility In-Reply-To: <4809057c0907101221m504f7efcv790894924b5a1c70@mail.gmail.com> References: <1247212643.4093.1.camel@acer> <4809057c0907101221m504f7efcv790894924b5a1c70@mail.gmail.com> Message-ID: <8BA85CA1-D757-4A29-B84F-8D7FB8FC6395@macports.org> On Jul 10, 2009, at 14:21, Kristofer Henriksson wrote: > 2009/7/10 Ryan Schmidt wrote: > >> On Jul 10, 2009, at 02:57, Jean-Michel Pour? wrote: >> >> I sometimes use "screen" to build ports on my systems. I see no >> reason why >> it would affect the build. It only annoys me by making the Terminal's >> scrollback buffer useless. (Is there a way to scroll up within >> screen?) > > screen's scrollback can be accessed with "ctrl-a [", and > then use arrow keys or vi keys to move around. Push "q" when you want > to stop. Thanks. I was sure screen must have a scrollback buffer, I just hadn't looked into it. Here's more info on how to set it up and use it: http://www.samsarin.com/blog/2007/03/11/gnu-screen-working-with-the- scrollback-buffer/ From blb at macports.org Fri Jul 10 13:17:29 2009 From: blb at macports.org (Bryan Blackburn) Date: Fri, 10 Jul 2009 14:17:29 -0600 Subject: [53622] trunk/dports/databases/mongodb In-Reply-To: <23FC634C-E3A3-4B39-8C18-05FEDF76BD91@macports.org> References: <20090710072523.01EDC204AEA3@beta.macosforge.org> <23FC634C-E3A3-4B39-8C18-05FEDF76BD91@macports.org> Message-ID: <20090710201729.GI94829@ninagal.withay.com> On Fri, Jul 10, 2009 at 02:11:49PM -0500, Ryan Schmidt said: > > On Jul 10, 2009, at 02:25, blb at macports.org wrote: > > >Revision: 53622 > > http://trac.macports.org/changeset/53622 > >Author: blb at macports.org > >Date: 2009-07-10 00:25:19 -0700 (Fri, 10 Jul 2009) > >Log Message: > >----------- > >databases/mongodb - update to 0.9.6 (ticket #20252); prepend > >instead of append for LIBPATH so self-built libs are seen over > >already-installed during upgrades > > [snip] [...] > > - env.Append( LIBPATH=["/sw/lib/", "/opt/local/lib"] ) > >-+ env.Append( CPPPATH=["@@PREFIX@@/include"] ) > >-+ env.Append( LIBPATH=["@@PREFIX@@/lib/"] ) > >++ env.Append( CPPPATH=["/mp/include"] ) > >++ env.Append( LIBPATH=["/mp/lib/"] ) > > Your MacPorts prefix /mp got inserted into this patch in several places. Oops, thanks for the catch; fixed in r53637. Bryan [...] From talklists at newgeo.com Fri Jul 10 13:36:35 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 10 Jul 2009 13:36:35 -0700 Subject: Error on closing down ASSP Message-ID: <3848C50F-87FC-4D68-BE41-4FCB5BD25B29@newgeo.com> Running: Jul-10-09 13:35:34 Assp.pl version 1.5.1.4(1.0.01) (Perl 5.008009) initializing I have not had good luck with 1.5.1.5 and have not had time to write a report of my problems. Is the below solved in 1.5.1.5? What does this mean? ^C Jul-10-09 13:35:30 Sig INT Jul-10-09 13:35:30 Saving whitelist Jul-10-09 13:35:30 Saving redlist Jul-10-09 13:35:30 Saving delaying records Jul-10-09 13:35:30 Saving penalty records Jul-10-09 13:35:30 Error: orderedtie is unable to close I - Bad file descriptor Jul-10-09 13:35:30 Error: orderedtie is unable to close I - Bad file descriptor Jul-10-09 13:35:30 Saving cache records Jul-10-09 13:35:30 Error: orderedtie is unable to close I - Bad file descriptor Jul-10-09 13:35:30 Error: orderedtie is unable to close I - Bad file descriptor Jul-10-09 13:35:30 Error: orderedtie is unable to close I - Bad file descriptor Jul-10-09 13:35:30 Error: orderedtie is unable to close I - Bad file descriptor Jul-10-09 13:35:30 Error: orderedtie is unable to close I - Bad file descriptor -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Fri Jul 10 14:40:04 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 10 Jul 2009 16:40:04 -0500 Subject: [53636] trunk/dports/python In-Reply-To: <20090710200733.86184205A757@beta.macosforge.org> References: <20090710200733.86184205A757@beta.macosforge.org> Message-ID: <13C6149E-BE3C-4DCF-BDF6-D9B42159982B@macports.org> On Jul 10, 2009, at 15:07, mmoll at macports.org wrote: > Revision: 53636 > http://trac.macports.org/changeset/53636 > Author: mmoll at macports.org > Date: 2009-07-10 13:07:32 -0700 (Fri, 10 Jul 2009) > Log Message: > ----------- > New port: py26-biopython, derived from py25-biopython, version > bumped from 1.49 to 1.50 Can you please work with the maintainer of py25-biopython and py- biopython to keep the python 2.5 and 2.4 versions of the port updated to the same version number? It's best to keep these in sync as much as possible. You may wish to see if you both can comaintain all three ports to better facilitate this. From armahg at gmail.com Fri Jul 10 19:55:33 2009 From: armahg at gmail.com (George Armah) Date: Fri, 10 Jul 2009 19:55:33 -0700 Subject: GSOC09 MacPorts GUI In-Reply-To: <9000A325-5048-428A-A029-19864603E9C0@macports.org> References: <2bad8a110907071217x7b2881fex72a689040af084ce@mail.gmail.com> <9000A325-5048-428A-A029-19864603E9C0@macports.org> Message-ID: I was hoping Juan would have replied by now. He sent me an email and we are scheduling a fixed time to meet that works for both of us since his internet at home is still down. The good news is that he can still work from an internet cafe. > 1) Do you plan to support categories? Ports list categories that they > belong to, so it would be nice to have a browsing option that allows us to > "expand" categories. The framework has that information. I also asked Juan to layout the UI so that the main port list can easily be resized to accommodate a port category list view on the left - kind of like in Finder. Clicking on each category will filter the current port list to ports from just those categories. If there is time we will work on implementing this. 2) How are variants handled? Do you have a gui way to edit > $prefix/etc/macports/variants.conf? What about per-port variants at install > time? The framework also exposes them but currently they are not exposed in the GUI. I am not sure about editing variants.conf but per-port variants at install time is certainly doable. We just have to figure out a reasonable UI for it. > > > 3) You said, "I?m working into getting that separate process to be part of > the Framework and also make it send notifications back to the Framework to > know the progress of the port command being run." ... I'm curious what level > or notification you are designing. It would probably be nice to have a > window that shows a general progress bar for the current port/stage... but > for debugging purposes, it would be helpful if this could be expanded via > "Details" button or similar to show the verbose or debug output. The current design uses distributed objects to send messages from the port process to the Framework. The GUI has access to these messages from the Framework. Setting the verbose level is also possible using the Framework. We are planning to display a progress bar at the very least. A window with the log details should be fairly easy to do since we get all those messages. I have asked Juan to speak to the other GSoC student to see if any of his GSoC work would benefit us in this regard. > 4) Do you plan to have a preferences interface to common > $prefix/etc/macports/macports.conf options? We will need some help implementing this since I am not familiar with the macports.conf file / modifying its preferences etc. If it is one of the files the Tcl interpreter loads before performing port operations, and is modifiable via Macports Tcl commands then it should fairly easy to do. I'll discuss the above with Juan and ask him to contact you with some more questions. Our goal right now is to have a functional, non-buggy GUI that performs all the basic port functions and can be easily extended with advanced features. I think we will have time to implement some of the above suggestions. Thanks for the feedback! George. > > > Thanks, > Jeremy > > On Jul 7, 2009, at 12:17, Juan Germ?n Casta?eda Echevarria wrote: > > Hi everyone, >> >> I?ve been very busy these days working in the GUI, I?ve learnt a lot of >> things and first of all I want to thank my mentor, Georg Armah, for >> teaching >> me a lot of things and being so patient with me. Also I?d like to thank >> all >> the other mentors that have helped me on IRC (I should do that more!). >> Current Status >> >> Now is the time to introduce you my work. I?ve done the first version of >> the >> MacPorts GUI application and this is what I have: >> >> - Support for non-default MacPorts installation locations. (Via the >> Preferences window) >> - Basic and Advanced Search (currently can only search by port name and >> status, but this is easily extendible) >> - Install, Uninstall, Upgrade port operations in background >> - Sync and SelfUpdate in background >> >> What doesn?t work: >> >> - Status field in ports table doesn?t change after install, uninstall and >> upgrade. >> >> What still needs to be implemented: >> >> - Make the Framework use a separate process to perform port commands (see >> the Problems section below) >> - Port info. This will be displayed like a quick look window. >> - Progress notifications and cancel command. I?m thinking in having this >> as a activity window (Something like Safari?s downloads window) and allow >> the user to queue port commands to perform then sequentially. >> >> Installation >> >> To install it from source, you only have to checkout the gsoc09-gui >> branch, >> and build the MPGUI Xcode project with the Debug-InstallMacPorts >> configuration< >> http://www.screencast.com/users/juanger/folders/Jing/media/01000c79-6663-486f-81d7-6ce56d12366a >> > >> >> svn co http://svn.macports.org/repository/macports/branches/gsoc09-gui >> >> That will build the MacPorts.framework, a MacPorts 1.8 unprivileged >> installation and selfupdate it. >> >> I also have included a binary version that should work out of the box. To >> make it work I embedded the Framework in the application bundle but we >> have >> planned that the Framework will be installed separately form the >> application >> and will live in a Frameworks directory (in /Library or the per user >> ~/Library). >> Running >> >> The first time the application is run, the preferences window will come >> out >> and you should set the Tcl installation path. Since the GUI is tested with >> MacPorts 1.8, you can set it to the macports1.8/Library/Tcl directory >> created in the build directory if you built it from source. If you?re >> using >> the binary version you can install an unprivileged macports (from trunk), >> selfupdate it and test with it or use your /Library/Tcl installation (this >> will work partially). >> >> Screenshot< >> http://www.screencast.com/users/juanger/folders/Jing/media/dbc07263-fe93-4015-aeed-6341b589dafc >> > >> >> Since I'm having problems with my internet connection I haven't tested it >> thoroughly, so If you encounter any problem, please let me know. >> Problems >> >> The main problem has been the multithreaded implementation because for >> some >> reason (it is very difficult to debug) the destroot phase was interrupted >> and the thread died when installing some ports (expat, libiconv, pngcrush, >> ?) that use xinstall with the ?-W? flag. After doing some tests we found >> that when the port command was run in another process rather than in a >> secondary thread, it was smoothly completed. >> >> Then we opted to create a separate process to handle port commands and >> made >> the GUI to communicate with it via distributed objects messaging. This is >> the version you?ll test. >> >> Currently I?m working into getting that separate process to be part of the >> Framework and also make it send notifications back to the Framework to >> know >> the progress of the port command being run. This way it will be more >> transparent to the client (in this case the GUI, but it could be something >> else) and the GUI implementation will be simpler. >> Final thoughts >> >> I hope to get a lot of feedback from you regarding the interface design >> and >> also about how it is working now. I?m working to get a new version of the >> Framework with the changes I explained in previous paragraphs by the >> beginning of the next week. >> -- >> Ash Mac durbatul?k, ash Mac gimbatul, ash Mac thrakatul?k agh burzum-ishi >> krimpatul. >> Juanger. http://xocoruby.blogspot.com >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danocd at tiscali.it Sat Jul 11 07:02:38 2009 From: danocd at tiscali.it (=?ISO-8859-1?Q?Fra_Daniele_di_Ges=F9_ocd?=) Date: Sat, 11 Jul 2009 16:02:38 +0200 Subject: [MacPorts] #19543: Add suhosin in php5 extension portgroup In-Reply-To: <062.15976002604631b69c1602e244d1eb68@macports.org> References: <053.7e4e7cfdc36362b9265d7fad7c44d0ac@macports.org> <062.15976002604631b69c1602e244d1eb68@macports.org> Message-ID: Il giorno 06/lug/09, alle ore 06:13, MacPorts ha scritto: > #19543: Add suhosin in php5 extension portgroup > ------------------------------- > +-------------------------------------------- > Reporter: danocd@? | Owner: snc@? > Type: request | Status: assigned > Priority: Normal | Milestone: > Component: ports | Version: 1.7.1 > Keywords: | Port: suhosin > ------------------------------- > +-------------------------------------------- > > Comment(by snc@?): > > Created the new portfile using the portgroup in r53434. > > -- > Ticket URL: > MacPorts > Ports system for Mac OS J. M. ? J. T. Thank you so much! Sia lodato Ges? Cristo! Fra Daniele di Ges? ocd Carmelitano scalzo indegno Padri Carmelitani Scalzi Chiesa SS. Annunziata Piazza Umberto I 10 81024 Maddaloni CE ITALIA Tel 0823 434030 Fax 0823 204782 E-mail danocd at tiscali.it Sito internet: www.carmelovocazioni.it "Il C at rmelo e le Vocazioni on-line" From jeremyhu at macports.org Sat Jul 11 08:54:14 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 11 Jul 2009 08:54:14 -0700 Subject: GSOC09 MacPorts GUI In-Reply-To: References: <2bad8a110907071217x7b2881fex72a689040af084ce@mail.gmail.com> <9000A325-5048-428A-A029-19864603E9C0@macports.org> Message-ID: On Jul 10, 2009, at 19:55, George Armah wrote: > I was hoping Juan would have replied by now. Oh, he replied to me directly (copied at bottom). Thanks for replying to me as well. This looks like a great project, and I look forward to seeing it mature =) >> 1) Do you plan to support categories? Ports list categories that >> they >> belong to, so it would be nice to have a browsing option that >> allows us to >> "expand" categories. > > > The framework has that information. I also asked Juan to layout the > UI so > that the main port list can easily be resized to accommodate a port > category > list view on the left - kind of like in Finder. Clicking on each > category > will filter the current port list to ports from just those > categories. If > there is time we will work on implementing this. > > > 2) How are variants handled? Do you have a gui way to edit >> $prefix/etc/macports/variants.conf? What about per-port variants >> at install >> time? > > > The framework also exposes them but currently they are not exposed > in the > GUI. I am not sure about editing variants.conf but per-port variants > at > install time is certainly doable. We just have to figure out a > reasonable UI > for it. > > > > >> >> >> 3) You said, "I?m working into getting that separate process to be >> part of >> the Framework and also make it send notifications back to the >> Framework to >> know the progress of the port command being run." ... I'm curious >> what level >> or notification you are designing. It would probably be nice to >> have a >> window that shows a general progress bar for the current port/ >> stage... but >> for debugging purposes, it would be helpful if this could be >> expanded via >> "Details" button or similar to show the verbose or debug output. > > > The current design uses distributed objects to send messages from > the port > process to the Framework. The GUI has access to these messages from > the > Framework. Setting the verbose level is also possible using the > Framework. > We are planning to display a progress bar at the very least. A > window with > the log details should be fairly easy to do since we get all those > messages. > I have asked Juan to speak to the other GSoC student to see if any > of his > GSoC work would benefit us in this regard. > > > >> 4) Do you plan to have a preferences interface to common >> $prefix/etc/macports/macports.conf options? > > We will need some help implementing this since I am not familiar > with the > macports.conf file / modifying its preferences etc. If it is one of > the > files the Tcl interpreter loads before performing port operations, > and is > modifiable via Macports Tcl commands then it should fairly easy to do. > > > I'll discuss the above with Juan and ask him to contact you with > some more > questions. Our goal right now is to have a functional, non-buggy GUI > that > performs all the basic port functions and can be easily extended with > advanced features. I think we will have time to implement some of > the above > suggestions. > > > Thanks for the feedback! > George. On Jul 8, 2009, at 06:53, Juan Germ?n Casta?eda Echevarria wrote: > El 8 de julio de 2009 01:41, Jeremy Huddleston > escribi?: > >> Hi Juan, >> >> That looks very promising. I'm excited about this work. I do have >> a few >> questions. >> >> 1) Do you plan to support categories? Ports list categories that >> they >> belong to, so it would be nice to have a browsing option that >> allows us to >> "expand" categories. > > > I planed to use a source view, but I ended droping it because the > interface > design was a lot more complex (for me and users). Categories will be > filtered using the advanced search predicate editor. > > >> >> >> 2) How are variants handled? Do you have a gui way to edit >> $prefix/etc/macports/variants.conf? What about per-port variants >> at install >> time? > > > I have thought of per-port variants only, but now that you say that, > I think > I could add something in the preferences window to change the > vavriants.conf > file > > >> >> >> 3) You said, "I?m working into getting that separate process to be >> part of >> the Framework and also make it send notifications back to the >> Framework to >> know the progress of the port command being run." ... I'm curious >> what level >> or notification you are designing. It would probably be nice to >> have a >> window that shows a general progress bar for the current port/ >> stage... but >> for debugging purposes, it would be helpful if this could be >> expanded via >> "Details" button or similar to show the verbose or debug output. >> > > Yes, that's the idea, I want to have progress bars and also detailed > log > views. The level of the notifications are customizable because I > change the > ui_$priority tcl methods to send the notifications. > > >> >> 4) Do you plan to have a preferences interface to common >> $prefix/etc/macports/macports.conf options? >> > > I haven't thought of preferences so far, in fact I added the > preferences > interface just to make it more friendly for this demo version (this > way you > don't have to change the source code). But thanks for pointing that, > I'll > take a look at macports.conf. > > >> >> Thanks, >> Jeremy >> >> > Thanks to you!! > > -- > Ash Mac durbatul?k, ash Mac gimbatul, ash Mac thrakatul?k agh burzum- > ishi > krimpatul. > Juanger. http://xocoruby.blogspot.com From jeremy at lavergne.gotdns.org Sat Jul 11 11:46:43 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 11 Jul 2009 14:46:43 -0400 Subject: [53678] trunk/dports/mail/imap-uw/Portfile In-Reply-To: <20090711184533.8E432207211B@beta.macosforge.org> References: <20090711184533.8E432207211B@beta.macosforge.org> Message-ID: <7039C3B7-0DB4-405B-9F71-82BCA8F002C7@lavergne.gotdns.org> Also took openmaintainership. On Jul 11, 2009, at 2:45 PM, snc at macports.org wrote: > Modified: trunk/dports/mail/imap-uw/Portfile (53677 => 53678) > > --- trunk/dports/mail/imap-uw/Portfile 2009-07-11 18:36:53 UTC (rev > 53677) > +++ trunk/dports/mail/imap-uw/Portfile 2009-07-11 18:45:33 UTC (rev > 53678) > @@ -7,7 +7,7 @@ > version 2007 > revision 2 > categories mail > -maintainers nomaintainer > +maintainers snc openmaintainer > description University of Washington IMAP daemon > long_description IMAP (Internet Message Access Protocol) is a > method \ > of accessing electronic messages kept on a > (possibly \ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Sat Jul 11 12:33:31 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 11 Jul 2009 14:33:31 -0500 Subject: [53669] trunk/dports/science/netcdf/Portfile In-Reply-To: <20090711145744.14793206ECB0@beta.macosforge.org> References: <20090711145744.14793206ECB0@beta.macosforge.org> Message-ID: <96611212-F5F3-43E0-BD9A-94F1B95426F4@macports.org> On Jul 11, 2009, at 09:57, takeshi at macports.org wrote: > Revision: 53669 > http://trac.macports.org/changeset/53669 > Author: takeshi at macports.org > Date: 2009-07-11 07:57:43 -0700 (Sat, 11 Jul 2009) > Log Message: > ----------- > netcdf: fixed +universal In the future, could you please commit whitespace changes separately from functional changes? It's just hard to see what changes you made here in order to fix the universal variant, between all the whitespace changes you made. Thanks. > Modified Paths: > -------------- > trunk/dports/science/netcdf/Portfile > > Modified: trunk/dports/science/netcdf/Portfile > =================================================================== > --- trunk/dports/science/netcdf/Portfile 2009-07-11 14:53:11 UTC > (rev 53668) > +++ trunk/dports/science/netcdf/Portfile 2009-07-11 14:57:43 UTC > (rev 53669) > @@ -1,15 +1,16 @@ > +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: > nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 > # $Id$ > > -PortSystem 1.0 > +PortSystem 1.0 > > -name netcdf > -version 4.0.1 > -revision 3 > -maintainers nomaintainer > -platforms darwin > -categories science > +name netcdf > +version 4.0.1 > +revision 3 > +maintainers nomaintainer > +platforms darwin > +categories science > > -description NetCDF - Network Common Data Form > +description NetCDF - Network Common Data Form > long_description \ > NetCDF is an interface \ > for array-oriented data access and a library that \ > @@ -21,35 +22,34 @@ > The netCDF software was developed at the Unidata \ > Program Center in Boulder, Colorado. > > -homepage http://unidata.ucar.edu/packages/netcdf/ > +homepage http://unidata.ucar.edu/packages/netcdf/ > > -master_sites ftp://ftp.unidata.ucar.edu/pub/netcdf/ \ > - http://www.gfd-dennou.org/arch/netcdf/unidata-mirror/ \ > - ftp://www.gfd-dennou.org/arch/netcdf/unidata-mirror/ > +master_sites ftp://ftp.unidata.ucar.edu/pub/netcdf/ \ > + http://www.gfd-dennou.org/arch/netcdf/ > unidata-mirror/ \ > + ftp://www.gfd-dennou.org/arch/netcdf/ > unidata-mirror/ > > -checksums md5 a251453c5477599f050fa4e593295186 \ > - sha1 > 96b361de72bcf68eaba42e7e5cf0f92c33d288e9 \ > - rmd160 ba74363bbc4c76fc1bbac578ba4c2af4739b4958 > +checksums md5 > a251453c5477599f050fa4e593295186 \ > + sha1 > 96b361de72bcf68eaba42e7e5cf0f92c33d288e9 \ > + rmd160 > ba74363bbc4c76fc1bbac578ba4c2af4739b4958 > > -configure.cppflags "-DNDEBUG -Df2cFortran" > -configure.cxxflags "-O2 -fno-common" > -configure.cflags "-O2 -fno-common" > -configure.args --enable-shared \ > - --disable-f77 > +configure.cppflags-append "-DNDEBUG -Df2cFortran" > +configure.cxxflags-append "-O2 -fno-common" > +configure.cflags-append "-O2 -fno-common" > +configure.args --enable-shared \ > + --disable-f77 > > -test.run yes > -test.target check > +test.run yes > +test.target check > > -destroot.destdir \ > - prefix=${destroot}${prefix} \ > - MANDIR=\\\${prefix}/share/man > +destroot.destdir prefix=${destroot}${prefix} \ > + MANDIR=\\\${prefix}/share/man > > post-destroot { > file delete -force ${destroot}${prefix}/share/man/whatis.db > # xinstall -m 755 -d ${destroot}${prefix}/share/${name} > } > > -default_variants +netcdf4 > +default_variants +netcdf4 > > variant gcc43 description conflicts g95 description {Enable > Fortran support with gfortran} { > depends_lib-append port:gcc43 > @@ -66,10 +66,10 @@ > } > > variant openmpi description {compile with openmpi} { > - depends_lib-append port:openmpi > - configure.fc openmpif77 > - configure.cc openmpicc > - configure.cxx openmpicxx > + depends_lib-append port:openmpi > + configure.fc openmpif77 > + configure.cc openmpicc > + configure.cxx openmpicxx > } > > variant dap description {enable dap} { From jm at poure.com Sat Jul 11 13:15:47 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sat, 11 Jul 2009 22:15:47 +0200 Subject: Impact of building using screen Unix utility In-Reply-To: <8BA85CA1-D757-4A29-B84F-8D7FB8FC6395@macports.org> References: <1247212643.4093.1.camel@acer> <4809057c0907101221m504f7efcv790894924b5a1c70@mail.gmail.com> <8BA85CA1-D757-4A29-B84F-8D7FB8FC6395@macports.org> Message-ID: <1247343347.6444.2.camel@localhost> In fact, I found that kdebase4-runtime failes when build with screen. Creation of icons failed with an error. It seems that the OS did not give enough permissions. I recompiled using SSH only and it worked. Strange. Bye, JMP From juanger at ciencias.unam.mx Sun Jul 12 13:08:57 2009 From: juanger at ciencias.unam.mx (=?ISO-8859-1?Q?Juan_Germ=E1n_Casta=F1eda_Echevarria?=) Date: Sun, 12 Jul 2009 15:08:57 -0500 Subject: GSOC09 MacPorts GUI In-Reply-To: References: <2bad8a110907071217x7b2881fex72a689040af084ce@mail.gmail.com> <9000A325-5048-428A-A029-19864603E9C0@macports.org> Message-ID: <2bad8a110907121308i7d67bd32xc57c9f12d0c4cc46@mail.gmail.com> I've made some changes and since the demo version is now an old revision in the repository, if any of you want to checkout the code and build it you'll need to specify the revision: svn co http://svn.macports.org/repository/macports/branches/gsoc09-gui -r 53683 Greetings -- 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 wes at wezm.net Sun Jul 12 19:33:40 2009 From: wes at wezm.net (Wesley Moore) Date: Mon, 13 Jul 2009 12:33:40 +1000 Subject: Removal of dnsmasq startup item Message-ID: <664f64be0907121933we97ac5dj9b9d9caaae575b51@mail.gmail.com> Hi,I use dnsmasq on my home network for dhcp and dns. I've noticed that a startup item is no longer generated. I think this caused the previously existing one to be removed when I upgraded. The next time I rebooted dnsmasq did not start and all my clients stopped working. I can see in Changeset 51337 that the startupitem generation was commented out but the commit message doesn't mention this. Also I can't find any bug ticket that suggests there was a problem with the existing startup item. So I was wondering if anyone knew why the change was made? If there was a good reason then so be it, if not, I'll raise a ticket to have it re-enabled. Regards, Wes -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at lavergne.gotdns.org Sun Jul 12 19:35:32 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sun, 12 Jul 2009 22:35:32 -0400 Subject: Removal of dnsmasq startup item In-Reply-To: <664f64be0907121933we97ac5dj9b9d9caaae575b51@mail.gmail.com> References: <664f64be0907121933we97ac5dj9b9d9caaae575b51@mail.gmail.com> Message-ID: I'm going to say I accidentally commented it prior to simply marking it in variants.conf on my system. A change to re-enable it is forthcoming :-) On Jul 12, 2009, at 10:33 PM, Wesley Moore wrote: > I use dnsmasq on my home network for dhcp and dns. I've noticed that > a startup item is no longer generated. I think this caused the > previously existing one to be removed when I upgraded. The next time > I rebooted dnsmasq did not start and all my clients stopped working. > > I can see in Changeset 51337 that the startupitem generation was > commented out but the commit message doesn't mention this. Also I > can't find any bug ticket that suggests there was a problem with the > existing startup item. So I was wondering if anyone knew why the > change was made? If there was a good reason then so be it, if not, > I'll raise a ticket to have it re-enabled. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Sun Jul 12 19:44:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 12 Jul 2009 21:44:38 -0500 Subject: default / options keywords Message-ID: Are the workings of the "default" and "options" keywords documented somewhere, or where in the code do I look to understand exactly how that's working? It seems to be about late variable substitution, e.g. when the xcode portgroup says default destroot.destdir {DSTROOT="${destroot}"} the curly brackets around the whole thing prevent variable substitution at the time the portgroup is loaded, and MacPorts plugs in the value of destroot into that string later, yes? It gives the port a chance to change destroot before it gets plugged into the string. It also seems to be about being able to access portgroup variables without everyone having to "global" them first, e.g. you can just say "xcode.target something" in a portfile without having to first say "global xcode.target". Is this all it is or is there more? From blb at macports.org Sun Jul 12 20:06:19 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 12 Jul 2009 21:06:19 -0600 Subject: default / options keywords In-Reply-To: References: Message-ID: <20090713030619.GI3066@ninagal.withay.com> On Sun, Jul 12, 2009 at 09:44:38PM -0500, Ryan Schmidt said: > Are the workings of the "default" and "options" keywords documented > somewhere, or where in the code do I look to understand exactly how > that's working? > > It seems to be about late variable substitution, e.g. when the xcode > portgroup says > > default destroot.destdir {DSTROOT="${destroot}"} > > the curly brackets around the whole thing prevent variable > substitution at the time the portgroup is loaded, and MacPorts plugs > in the value of destroot into that string later, yes? It gives the > port a chance to change destroot before it gets plugged into the > string. > > It also seems to be about being able to access portgroup variables > without everyone having to "global" them first, e.g. you can just say > "xcode.target something" in a portfile without having to first say > "global xcode.target". > > Is this all it is or is there more? For the most part; 'default' helps to do the delayed evaluation with some tracing. 'options' is what lets you use the more declarative style you usually see in Portfiles ("name portname") as well as setting up how to handle *-append, *-delete, and *-replace. Both are procs in port1.0/portutil.tcl if you want to see the full code, not sure of what documentation there is. Bryan From mail at uwe-arzt.de Mon Jul 13 07:58:40 2009 From: mail at uwe-arzt.de (Uwe Arzt) Date: Mon, 13 Jul 2009 16:58:40 +0200 Subject: [MacPorts] #20283: error building in 10.6 In-Reply-To: <052.bfc4e82fa399705e06cbbc646b5d80d2@macports.org> References: <052.bfc4e82fa399705e06cbbc646b5d80d2@macports.org> Message-ID: Hi all, i don't have a 10.6 machine yet (I am not registered in the Mac OS X Developer program). Is somewhere an public 10.6 machine available with an ssh login for testing purposes? Thanks :q! Uwe Am 13.07.2009 um 16:47 schrieb MacPorts: > #20283: error building in 10.6 > ------------------------------ > +--------------------------------------------- > Reporter: snc@? | Owner: mail@? > Type: defect | Status: new > Priority: Low | Milestone: > Component: ports | Version: 1.8.0 > Keywords: | Port: pthsem > ------------------------------ > +--------------------------------------------- > The error was: > {{{ > Command output: pth_uctx.c:37: error: expected specifier-qualifier- > list > before 'size_t' > }}} > > -- > Ticket URL: > MacPorts > Ports system for Mac OS -- mail at uwe-arzt.de www.uwe-arzt.de From mdcrawford at gmail.com Mon Jul 13 08:10:24 2009 From: mdcrawford at gmail.com (Michael Crawford) Date: Mon, 13 Jul 2009 08:10:24 -0700 Subject: [MacPorts] #20283: error building in 10.6 In-Reply-To: References: <052.bfc4e82fa399705e06cbbc646b5d80d2@macports.org> Message-ID: On Mon, Jul 13, 2009 at 7:58 AM, Uwe Arzt wrote: > Is somewhere an public 10.6 machine available with an > ssh login for testing purposes? I would expect that such a machine would violate Apple's NDA on 10.6. And yes I know that it's really silly to have an NDA covering something that anyone can get if they pay for an ADC account. I'm sure Apple's attorneys have some rational reason for this. Attorneys never do anything irrational, you know. I'm not certain yet, but I might be signing up for the paid ADC account soon. If I do, I'll get the 10.6 seed. I wouldn't be permitted to say anything about 10.6 itself, but I expect I would be permitted to publicly submit MacPorts patches that also worked on 10.5. Regards, Mike -- Michael David Crawford mdcrawford at gmail dot com GoingWare's Bag of Programming Tricks http://www.goingware.com/tips/ From talklists at newgeo.com Mon Jul 13 12:19:47 2009 From: talklists at newgeo.com (Scott Haneda) Date: Mon, 13 Jul 2009 12:19:47 -0700 Subject: openssl In-Reply-To: <20090710075244.GQ89345@ninagal.withay.com> References: <1BC2AA56-CA1D-4164-9D26-FBDD1B642EE2@newgeo.com> <20090709035056.GO56868@ninagal.withay.com> <3769947A-38CF-4F89-8293-E55277165DD8@newgeo.com> <20090709080738.GT56868@ninagal.withay.com> <20090710075244.GQ89345@ninagal.withay.com> Message-ID: <9AECC1F7-AFF8-481C-9BB1-7478AF87FB5C@newgeo.com> >>>> What I do know, is ASSP needs p5-net-ssleay, there is a suspicion >>>> that the openssl version I am working against is too old, or too >>>> buggy, so I need to try to solve that. >>> >>> Hard to say without knowing how things aren't working; I know some >>> software >>> doesn't like when you compile using one version of headers then >>> link against >>> a different version of libraries. >> >> ASSP is a email proxy, it supports SSL and TLS mostly by using p5's >> to make it all happen. The setup is Internet -> ASSP -> MTA >> >> If I made a SSL or TLS enabled connection directly to the MTA on port >> 25, SSL and/or TLS will work fine. >> >> If I make a connection to the ASSP proxy, it works some of the time. >> I send a email in the command line: >> `mail user at remote-mta-machine` >> This will always work >> >> `mail user at assp-proxy` this simply hits port 25, which is set to >> proxy to the far end MTA. It fails the SSL parts entirely. Some >> hosts that I send the `mail` command from work, others do not. I >> subscribed to a few mailing lists, some get through, some do not. > > Some addresses working and others not, that doesn't sound like an > initial > connection issue (which would implicate SSL/TLS) but something after > that. > By 'fails the SSL parts entirely' what exactly do you mean, does it > fail to > finish the initial TCP handshake, fail to verify the cert, something > else? I wish I knew. This is hard one for me to debug. Basically, an email from the outside world comes in, hits the proxy on port 25, and all I see in the ASSP logs is "starting SSL connection" and "SSL connection failed, problem with MTA?". Not exact verbiage, but the basics are the same. Some cases I can get this to happen with a machine I am in control of, so I can look at the logs on that sending machine. I just get a dropped connection, and the mail is queued up and will be tried again later. Curiously, in 5 hours or so, they can sometimes make it through. >> I can use openssl as a client, and connect to the remote far end MTA >> just fine, connecting to ASSP, and I get the connection, but that is >> as far as I get. > > If you can see the cert (eg, by using --showcerts with s_client) > then that > sounds like SSL/TLS is working fine. I thought so too, and those work on the machines I have access to where I can make tests. However, letting a local delivery agent try, and it will not work. >> I know what p5's ASSP installs, and can easily tell what dependencies >> I need to track down to look at. However, those depend on perl, >> which was installed, and curses was installed; a lot of other things >> too. Can I be reasonably confident, if any of those use openssl libs >> and headers, I need not run otool on them, and do any checking? > > The big problem is that for any new ports, checking linkage is a > good thing, > especially for bits that get loaded into larger programs (like perl > modules). If you aren't careful you can end up with one part > linking to the > system library and another part to the MacPorts equivalent. This > can then > lead to version mismatches and software crashing. I checked the better part of the libs with otool, and all seems to be in order. I went as far as installing this whole batch via CPAN, and got the same problems as well. >> Can you show me how you tried them, I was not able to get them to >> work, but all I did was `perl filename` which probably was not a >> valid way to test. I really do not know perl, or SSL vocabulary well >> enough to properly test these out. > > After it built (I have port's autoclean off so the build dir was still > available), I simply move into the top dir for p5-io-socket-ssl (the > one > with the example directory among others). From here, I ran > > $ /opt/local/bin/perl5.8 example/ssl_server.pl > > in one terminal and the ssl_client.pl in another, and watched those > talk > fine. Leaving the ssl_server process up, I then used > > $ openssl s_client -connect localhost:9000 -showcerts -debug > > to connect to the server and verify it was able to get the cert, > which it > did. I downloaded the source in order to get the examples directory. I then ran this $/opt/local/bin/perl5.8 ssl_server.pl unable to create socket: IO::Socket::INET configuration failederror: 00000000:lib(0):func(0):reason(0) Am I doing something wrong, how were you able to get that to work? -- Scott * If you contact me off list replace talklists@ with scott@ * From enl at macports.org Mon Jul 13 15:05:26 2009 From: enl at macports.org (Dmitry Gorbik) Date: Tue, 14 Jul 2009 02:05:26 +0400 Subject: GSoC: Mid-term evaluations this week Message-ID: Hello all! Almost all planned ideas connected with logging are implemented. I am going to implement some minor feautures next (versioning of logging format, timestamps) and last 2 week spend on writing documentation, testing, entegrating in the main project. Also the output for user may be changed. What do we have now: - Separate storage of logs for each port - Autocleaning logs if keeplogs option in macports.conf is set or by using command port clean --logs - port log command: port log shows log file for port. Also there are some filtering options: --stage and --prefix . Stages are basically "clean", "fetch", "patch" etc, and prefix can be only "debug", "msg" and "info". Likely I am going to expand prefixes to change verbosity. Logging by stages is done automaticaly, but you can specify stage directly by using ui_${stage}_${prefix} command. And please get a look at it, you can checkout "gsoc09-logging" branch and test it. Huge thanks to Bryan, Raim and other macports devs who helped my to deal with some problems during the work. 06.07.2009, ? 3:17, Rainer M?ller wrote: > Hi Dmitry and Juan, > > you have been working now for about 5 weeks on MacPorts code. Now the > mid-term evaluation of your work will happen from 6th to 13th July. > > All your new code is only visible to those who have been following the > branches in Subversion. It would be nice if you could give a quick > overview over your project. > > What you have done so far? > What is already working and how can it be tested? > What problems did you encounter? > How much time you are behind or ahead in your own roadmap? > What do you plan to do next? > > I would like to see that on macports-dev to bring your topics to a > broader audience and get you more involved on the mailing list. Your > reply does not have to be too formal. And of course others should feel > free to ask further questions if interested. > > Looking forward to your answers, > Rainer Gorbik Dmitry . Enlightened . enl at macports.org Gorbik Dmitry . Enlightened . enl at macports.org Gorbik Dmitry . Enlightened . enl at macports.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at lavergne.gotdns.org Mon Jul 13 15:31:01 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 13 Jul 2009 18:31:01 -0400 Subject: macports website Message-ID: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> We've had a ticket (#20278) come in about the web site once again. Previously, to our chagrin the XHTML broke in IE7 (#14062). I'd like to point out that using XHTML was a somewhat divergent path from HTML. With the advent of HTML 5, we find ourselves once again returning to the HTML side of things. Interested in this transition, I asked wms how to go about instigating the change. He directed me to ask you for your thoughts on bringing the site into HTML 5. So, ticket-filers, hecklers, committers, package maintainers, admins, and others: How do you feel about having the site change forward to HTML 5? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From talklists at newgeo.com Mon Jul 13 18:55:23 2009 From: talklists at newgeo.com (Scott Haneda) Date: Mon, 13 Jul 2009 18:55:23 -0700 Subject: port upgrade Message-ID: <1B3ACE12-E5B2-4181-8B96-41AFBD525173@newgeo.com> It is about time for me to learn about the port upgrade process. My ASSP port file is complete, and working as far as installs go. There may be some bugs in ASSP, or the perl modules, that I can not figure out, but the port itself is solid. My next step is to make sure that upgrades are smooth. ASSP is a copy to install type of app, you unzip it, move the files in place, and start it, that is all there is to it. It comes with a healthy list of perl dependencies, but as long as those are in place, it works. MacPorts is largely in this case, being used to avoid the problems a lot of mac users had with CPAN, and get all the perl bits in place. Largely, when ASSP is updated, only one file will be updated, which is assp.pl, the core application for the proxy. My install essentially unpacks, and loops through all the files in the distribution. Some need removing, as they are windows specific, some need reinplacing to change the perl chebang, and some need some line endings patches up. ASSP comes with for example, a greylist.txt file, in it will be a list of hosts that are to be excluded from greylisting. There are many other files that are like this, that is one example. This file is also assumed to be edited by the end user, either by hand, or via the web admin that assp.pl provides. ASSP will create log files, I know that an port upgrade assp will leave those alone, I believe even an uninstall will leave those alone. But what is the procedure for upgrades? I would not want greylist.txt touched. What happens if there is an introduction of a new file, that will need to be copied in place? What happens if there is an introduction of a existing file that needs to be over-written? I am looking for suggestions on how to best make this a solid and stable process for users of this port file. -- Scott * If you contact me off list replace talklists@ with scott@ * From blb at macports.org Mon Jul 13 19:14:19 2009 From: blb at macports.org (Bryan Blackburn) Date: Mon, 13 Jul 2009 20:14:19 -0600 Subject: openssl In-Reply-To: <9AECC1F7-AFF8-481C-9BB1-7478AF87FB5C@newgeo.com> References: <1BC2AA56-CA1D-4164-9D26-FBDD1B642EE2@newgeo.com> <20090709035056.GO56868@ninagal.withay.com> <3769947A-38CF-4F89-8293-E55277165DD8@newgeo.com> <20090709080738.GT56868@ninagal.withay.com> <20090710075244.GQ89345@ninagal.withay.com> <9AECC1F7-AFF8-481C-9BB1-7478AF87FB5C@newgeo.com> Message-ID: <20090714021419.GR659@ninagal.withay.com> On Mon, Jul 13, 2009 at 12:19:47PM -0700, Scott Haneda said: [...] > > > >Some addresses working and others not, that doesn't sound like an > >initial > >connection issue (which would implicate SSL/TLS) but something > >after that. > >By 'fails the SSL parts entirely' what exactly do you mean, does it > >fail to > >finish the initial TCP handshake, fail to verify the cert, > >something else? > > I wish I knew. This is hard one for me to debug. Basically, an > email from the outside world comes in, hits the proxy on port 25, and > all I see in the ASSP logs is "starting SSL connection" and "SSL > connection failed, problem with MTA?". Not exact verbiage, but the > basics are the same. > > Some cases I can get this to happen with a machine I am in control > of, so I can look at the logs on that sending machine. I just get a > dropped connection, and the mail is queued up and will be tried again > later. Curiously, in 5 hours or so, they can sometimes make it > through. Hmm, so intermittent then? That makes things much more difficult to pin down... [...] > > I downloaded the source in order to get the examples directory. I > then ran this > > $/opt/local/bin/perl5.8 ssl_server.pl > unable to create socket: IO::Socket::INET configuration failederror: > 00000000:lib(0):func(0):reason(0) > > Am I doing something wrong, how were you able to get that to work? That was all I did to run it; make sure you do have the p5-io-socket-ssl port installed first. You might try it with debug: $ /opt/local/bin/perl5.8 ssl_server.pl DEBUG Maybe that'll help... Bryan > > -- > Scott * If you contact me off list replace talklists@ with scott@ * > From blb at macports.org Mon Jul 13 19:46:08 2009 From: blb at macports.org (Bryan Blackburn) Date: Mon, 13 Jul 2009 20:46:08 -0600 Subject: port upgrade In-Reply-To: <1B3ACE12-E5B2-4181-8B96-41AFBD525173@newgeo.com> References: <1B3ACE12-E5B2-4181-8B96-41AFBD525173@newgeo.com> Message-ID: <20090714024608.GS659@ninagal.withay.com> On Mon, Jul 13, 2009 at 06:55:23PM -0700, Scott Haneda said: [...] > > ASSP comes with for example, a greylist.txt file, in it will be a > list of hosts that are to be excluded from greylisting. There are > many other files that are like this, that is one example. This file > is also assumed to be edited by the end user, either by hand, or via > the web admin that assp.pl provides. If this file (and others like it) are basically config files, you'll want to make sure to properly handle them; see the config files entry on the PortfileRecipes page: > > ASSP will create log files, I know that an port upgrade assp will > leave those alone, I believe even an uninstall will leave those > alone. But what is the procedure for upgrades? I would not want > greylist.txt touched. If log files aren't registered as part of the port install (which they usually aren't), then they shouldn't go away on uninstall. If you need a port-specific subdirectory of ${prefix}/var/log, then you need to create that directory and use destroot.keepdirs so that it is kept around (see the portfile(7) man page). > > What happens if there is an introduction of a new file, that will > need to be copied in place? What happens if there is an introduction > of a existing file that needs to be over-written? Upgrade basically just deactivates the port at the current version, then activates the new version. So you'll want to make sure the port is complete at every version then not worry about anything else, save for the config and log file bits mentioned above. Bryan > > I am looking for suggestions on how to best make this a solid and > stable process for users of this port file. > -- > Scott * If you contact me off list replace talklists@ with scott@ * > From ryandesign at macports.org Mon Jul 13 19:52:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 13 Jul 2009 21:52:42 -0500 Subject: port upgrade In-Reply-To: <1B3ACE12-E5B2-4181-8B96-41AFBD525173@newgeo.com> References: <1B3ACE12-E5B2-4181-8B96-41AFBD525173@newgeo.com> Message-ID: <2EC92854-12EE-469A-91AB-89A24236EF76@macports.org> On Jul 13, 2009, at 20:55, Scott Haneda wrote: > It is about time for me to learn about the port upgrade process. > My ASSP port file is complete, and working as far as installs go. > There may be some bugs in ASSP, or the perl modules, that I can not > figure out, but the port itself is solid. > > My next step is to make sure that upgrades are smooth. > > ASSP is a copy to install type of app, you unzip it, move the files > in place, and start it, that is all there is to it. It comes with > a healthy list of perl dependencies, but as long as those are in > place, it works. > > MacPorts is largely in this case, being used to avoid the problems > a lot of mac users had with CPAN, and get all the perl bits in place. > > Largely, when ASSP is updated, only one file will be updated, which > is assp.pl, the core application for the proxy. > > My install essentially unpacks, and loops through all the files in > the distribution. Some need removing, as they are windows > specific, some need reinplacing to change the perl chebang, and > some need some line endings patches up. > > ASSP comes with for example, a greylist.txt file, in it will be a > list of hosts that are to be excluded from greylisting. There are > many other files that are like this, that is one example. This > file is also assumed to be edited by the end user, either by hand, > or via the web admin that assp.pl provides. > > ASSP will create log files, I know that an port upgrade assp will > leave those alone, I believe even an uninstall will leave those > alone. But what is the procedure for upgrades? I would not want > greylist.txt touched. > > What happens if there is an introduction of a new file, that will > need to be copied in place? What happens if there is an > introduction of a existing file that needs to be over-written? > > I am looking for suggestions on how to best make this a solid and > stable process for users of this port file. During the destroot phase, your port must stage its files into the directory identified by the ${destroot} variable. Since ports should generally put things inside the MacPorts prefix, that means you will usually be copying things to some place under ${destroot}${prefix}, e.g. a program the user is expected to run might be installed into $ {destroot}${prefix}/bin During the install phase, MacPorts takes everything in the destroot and copies it to a location in ${prefix}/var/macports/software/$ {name} (in a directory named for the version, revision and selected variants) During the activate phase, MacPorts makes hard links from the thing in ${prefix}/var/macports/software/${name}/... to the corresponding place in / and in the deactivate phase, MacPorts removes those hard links again. So simply anything you put in the destroot will be registered to the port. If you uninstall or upgrade the port, the items that were registered to the old version of the port will be removed. So you would not want to register configuration files or log files or the like to the port. Instead, you would register sample versions of the configuration files to the port, and either advise the user to make a copy of these files, or do so for the user upon first installation if they don't already have them. The whois port demonstrates the former strategy while apache2 shows the latter. From talklists at newgeo.com Mon Jul 13 21:39:03 2009 From: talklists at newgeo.com (Scott Haneda) Date: Mon, 13 Jul 2009 21:39:03 -0700 Subject: port upgrade In-Reply-To: <2EC92854-12EE-469A-91AB-89A24236EF76@macports.org> References: <1B3ACE12-E5B2-4181-8B96-41AFBD525173@newgeo.com> <2EC92854-12EE-469A-91AB-89A24236EF76@macports.org> Message-ID: Thanks for the other reply Bryan, I will combine my comments here, rather than opening an entirely new email, since they are so closely related. On Jul 13, 2009, at 7:52 PM, Ryan Schmidt wrote: > On Jul 13, 2009, at 20:55, Scott Haneda wrote: > >> It is about time for me to learn about the port upgrade process. >> My ASSP port file is complete, and working as far as installs go. >> There may be some bugs in ASSP, or the perl modules, that I can not >> figure out, but the port itself is solid. >> >> My next step is to make sure that upgrades are smooth. >> >> [snip...] > > [snip...] > > So simply anything you put in the destroot will be registered to the > port. If you uninstall or upgrade the port, the items that were > registered to the old version of the port will be removed. > > So you would not want to register configuration files or log files > or the like to the port. Instead, you would register sample versions > of the configuration files to the port, and either advise the user > to make a copy of these files, or do so for the user upon first > installation if they don't already have them. The whois port > demonstrates the former strategy while apache2 shows the latter. It seems there is a pretty strong desire to put config files into /opt/ local/etc or equivalent. I can see that being the case with apache, or bind, and other software that generally works with that in mind. ASSP is a self contained application, with files, that loosely can be called config files. They can not be moved, that would require a lot of patching to the ASSP software, and would imo, create confusion to the end user. MacPorts is largely being used in this case take take advantage of installing several p5's, the fact it installs ASSP, is almost a nicety. I think the only way to explain this so I get it right, it to step through it, bare with me on the length of this email... ASSP ends up living in /opt/local/var/ASSP/ Installed files: assp.cfg assp.cfg.defaults assp.pl docs/ errors/ files/ images/ logs/ move2num.pl notes/ notspam/ okmail/ pb/ quarantine/ rebuildspamdb.pl reports/ spam/ stat.pl assp.cfg needs to never be touched by ports once installed. According to the docs, an update is to do the following: - invalidptr.txt - URIBLCCTLDS.txt - nodelay.txt (merge) - redre.txt - ipnp.txt (merge) - blockreportuser.txt - validptr.txt - bombre.txt (merge) - whiteorg.txt (merge) - strictspf.txt (merge) - invalidhelo.txt So the non merge, are safe to replace, the merge are not. In these cases, if I could simply let ports replace them, and as long as a backup of the entire /opt/local/var/ASSP directory was made, I would be happy with that and a UI message that said which files needed to be merged. * By merge, they mean, append your changes to the file. I would rather not get in the business of teaching ports how to merge those files, and leave that to the user. There are some other cases, but understanding how to deal with these should suffice. If I can rely on new files that were made after assp was installed staying untouched, then the app generated, and user generated data is safe. It looks to me, like I have a limited set of files I need to make sure are not touched by ports. The idea of registering these files as .sample files, and asking the user to change them, completely destroys the way that ASSP is designed to work. I would consider them more preferences, than config files, and with any preference file, it will contain some defaults, be written to by the user, and should not be messed with on uninstall of an app, and only sometimes modified on upgrade, if a format changes. Is destroot.keepdirs really only for directories, or can it be applied to files as well? Is that the preferred method here, to simply create a list of files I want to keep and iterate them with destroot.keepdirs? This protects those files from any modification at all when performing upgrade or uninstall? Or perhaps I do something like this: post-activate { set keepers {list of files I want to keep} foreach keep $keepers { if {![file exists ${keep}]} { file copy ${keep} \ ${assp_base}/${keep} } } } That is probably syntactically wrong. I am not sure if that is right either, and it makes sense to me how that would deal with a new install, but not a upgrade, or a uninstall. I think what I really want to do, is just unregister a list of files form the port after the first time it is installed. Maybe there is a way to trick ports into doing this by copying a file in during a certain phase but just keeping the name the same? Thanks for the guidance, I am almost there. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Mon Jul 13 23:39:15 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 14 Jul 2009 01:39:15 -0500 Subject: macports website In-Reply-To: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> Message-ID: <3100B517-DF68-43B7-9573-B956A1FA1A6E@macports.org> On Jul 13, 2009, at 17:31, Jeremy Lavergne wrote: > We've had a ticket (#20278) come in about the web site once again. > Previously, to our chagrin the XHTML broke in IE7 (#14062). > > I'd like to point out that using XHTML was a somewhat divergent > path from HTML. With the advent of HTML 5, we find ourselves once > again returning to the HTML side of things. > > Interested in this transition, I asked wms how to go about > instigating the change. He directed me to ask you for your > thoughts on bringing the site into HTML 5. So, ticket-filers, > hecklers, committers, package maintainers, admins, and others: How > do you feel about having the site change forward to HTML 5? I have not kept up with the developments of HTML 5 except for the canvas tag. Is there a specific feature of HTML 5 you believe we should be using on the MacPorts web site, or are you just talking about changing the doctype? Would changing the doctype to HTML 5's give us better browser compatibility than we have now? I thought we were pretty much as good as we could get now with the XHTML 1.1 doctype, though dropping back to XHTML 1.0 transitional or even HTML 4.01 wouldn't be out of the question. www.apple.com and www.macosforge.org both use HTML 4.01 today. #20278 was due to an inexplicable issue on the user's end that reformatted and changed the source code of our web site, breaking it; nothing we can do to fix that. #14062 was due to Internet Explorer not handling XHTML documents served with the correct content type, so we fixed it by serving the incorrect content type to IE only. From jeremy at lavergne.gotdns.org Tue Jul 14 03:12:25 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 14 Jul 2009 06:12:25 -0400 Subject: macports website In-Reply-To: <3100B517-DF68-43B7-9573-B956A1FA1A6E@macports.org> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <3100B517-DF68-43B7-9573-B956A1FA1A6E@macports.org> Message-ID: <2F1B597B-CCD3-460A-A786-99A888615F6E@lavergne.gotdns.org> I'd suggest using the HTML 5 doctype so it's ready to go in the future, but essentially using HTML 4.01 transitional. On Jul 14, 2009, at 2:39 AM, Ryan Schmidt wrote: > I have not kept up with the developments of HTML 5 except for the > canvas tag. Is there a specific feature of HTML 5 you believe we > should be using on the MacPorts web site, or are you just talking > about changing the doctype? Would changing the doctype to HTML 5's > give us better browser compatibility than we have now? I thought we > were pretty much as good as we could get now with the XHTML 1.1 > doctype, though dropping back to XHTML 1.0 transitional or even HTML > 4.01 wouldn't be out of the question. www.apple.com and www.macosforge.org > both use HTML 4.01 today. > > #20278 was due to an inexplicable issue on the user's end that > reformatted and changed the source code of our web site, breaking > it; nothing we can do to fix that. > > #14062 was due to Internet Explorer not handling XHTML documents > served with the correct content type, so we fixed it by serving the > incorrect content type to IE only. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jmr at macports.org Tue Jul 14 03:40:07 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 14 Jul 2009 20:40:07 +1000 Subject: macports website In-Reply-To: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> Message-ID: <4A5C6087.2000809@macports.org> On 2009-7-14 08:31, Jeremy Lavergne wrote: > I'd like to point out that using XHTML was a somewhat divergent path > from HTML. With the advent of HTML 5, we find ourselves once again > returning to the HTML side of things. On the other hand: XHTML5. > Interested in this transition, I asked wms how to go about instigating > the change. He directed me to ask you for your thoughts on bringing the > site into HTML 5. So, ticket-filers, hecklers, committers, package > maintainers, admins, and others: How do you feel about having the site > change forward to HTML 5? Wanting to support IE is the number one reason to use HTML rather than XHTML. IE has never handled XHTML; if you serve it with the right MIME type it can't display it and just downloads the file, and if you serve it as text/html it parses it as invalid HTML. Do we care enough about IE to warrant any action? I don't think anyone would complain if you did the work to switch the site over to HTML, but I don't see nearly enough value in it to do that work myself. - Josh From jeremy at lavergne.gotdns.org Tue Jul 14 03:50:21 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 14 Jul 2009 06:50:21 -0400 Subject: macports website In-Reply-To: <4A5C6087.2000809@macports.org> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> Message-ID: <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> On Jul 14, 2009, at 6:40 AM, Joshua Root wrote: > On 2009-7-14 08:31, Jeremy Lavergne wrote: >> I'd like to point out that using XHTML was a somewhat divergent path >> from HTML. With the advent of HTML 5, we find ourselves once again >> returning to the HTML side of things. > > On the other hand: XHTML5. Doesn't exist in any practical sense. >> Interested in this transition, I asked wms how to go about >> instigating >> the change. He directed me to ask you for your thoughts on >> bringing the >> site into HTML 5. So, ticket-filers, hecklers, committers, package >> maintainers, admins, and others: How do you feel about having the >> site >> change forward to HTML 5? > > Wanting to support IE is the number one reason to use HTML rather than > XHTML. IE has never handled XHTML; if you serve it with the right MIME > type it can't display it and just downloads the file, and if you serve > it as text/html it parses it as invalid HTML. Do we care enough > about IE > to warrant any action? > > I don't think anyone would complain if you did the work to switch the > site over to HTML, but I don't see nearly enough value in it to do > that > work myself. And also getting the site off of XHTML ;-) No one said you had to do the work, and those of us that are interested could tend to it :-P It seems like a fairly simple change since it is PHP-driven. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jmr at macports.org Tue Jul 14 03:57:53 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 14 Jul 2009 20:57:53 +1000 Subject: macports website In-Reply-To: <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> Message-ID: <4A5C64B1.2020700@macports.org> On 2009-7-14 20:50, Jeremy Lavergne wrote: > And also getting the site off of XHTML ;-) A move for which you still haven't mentioned any specific advantages. - Josh From jeremy at lavergne.gotdns.org Tue Jul 14 03:58:50 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 14 Jul 2009 06:58:50 -0400 Subject: macports website In-Reply-To: <4A5C64B1.2020700@macports.org> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> <4A5C64B1.2020700@macports.org> Message-ID: <5F55C538-90A9-4731-9598-8BB5182F09FB@lavergne.gotdns.org> Future work? I wonder, what were the advantages of going with XHTML to begin with? On Jul 14, 2009, at 6:57 AM, Joshua Root wrote: > A move for which you still haven't mentioned any specific advantages. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From anil at recoil.org Mon Jul 13 21:58:49 2009 From: anil at recoil.org (Anil Madhavapeddy) Date: Tue, 14 Jul 2009 05:58:49 +0100 Subject: ocaml port updates In-Reply-To: <4A7BC281-83A4-429E-96C7-9566EF74BCB4@recoil.org> References: <4A7BC281-83A4-429E-96C7-9566EF74BCB4@recoil.org> Message-ID: On 9 Mar 2009, at 20:45, Anil Madhavapeddy wrote: > On 9 Mar 2009, at 20:38, Daniel J. Luke wrote: > >> On Mar 9, 2009, at 4:22 PM, Anil Madhavapeddy wrote: >>> Most of the ports involved are openmaintainers and the updates are >>> a bit interlinked due to ocaml being updated to 3.11.0. >> >> >> In a case like this, I would open one ticket and CC all of the >> maintainers of the various ports (and discuss there how to proceed). > > Sounds good; I stuck it up on http://trac.macports.org/ticket/18786 These updates have been ignored for 3 months despite Damien Pollot also breaking out individual diffs, and it's getting to be a bit of a pain to maintain my own parallel tree with OCaml ports (http://github.com/avsm/darwinports ). Can I get a macports account to put the new ports in or could someone take a gander? thanks Anil From wsiegrist at apple.com Tue Jul 14 07:12:58 2009 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 14 Jul 2009 07:12:58 -0700 Subject: macports website In-Reply-To: <4A5C64B1.2020700@macports.org> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> <4A5C64B1.2020700@macports.org> Message-ID: <96A77103-271E-426B-9C89-A4F0327BA48F@apple.com> On Jul 14, 2009, at 3:57 AM, Joshua Root wrote: > On 2009-7-14 20:50, Jeremy Lavergne wrote: >> And also getting the site off of XHTML ;-) > > A move for which you still haven't mentioned any specific advantages. > The W3C has abandoned XHTML2, so we should not do any new work in XHTML. I suppose the current XHTML1.1 site will be fine for quite a while, but converting it to HTML is pretty easy and puts us on the supported path. -Bill From kthenriksson at gmail.com Tue Jul 14 07:26:11 2009 From: kthenriksson at gmail.com (Kristofer Henriksson) Date: Tue, 14 Jul 2009 10:26:11 -0400 Subject: macports website In-Reply-To: <96A77103-271E-426B-9C89-A4F0327BA48F@apple.com> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> <4A5C64B1.2020700@macports.org> <96A77103-271E-426B-9C89-A4F0327BA48F@apple.com> Message-ID: <4809057c0907140726gb3af326l2d61c246d679a784@mail.gmail.com> I believe that while the W3C will be disbanding the XHTML working group, this does not extend to the specification itself, which will exist in the HTML 5 specification (see http://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax). In other words, XHTML will continue to be have the same level of support by the W3C, with XHTML 5 and HTML 5 being two equivalent representations of the markup. Since HTML 5 is not yet a recommendation, it would be hasty to switch to it already. If we switch to XHTML 5 when the HTML 5 specification is released, it would be by far the easiest path that we could take while maintaining support for current standards. It seems that some are simply opposed to XHTML. Is there a particular reason to dislike using it for the site? On Tue, Jul 14, 2009 at 10:12 AM, William Siegrist wrote: > > On Jul 14, 2009, at 3:57 AM, Joshua Root wrote: > >> On 2009-7-14 20:50, Jeremy Lavergne wrote: >>> >>> And also getting the site off of XHTML ;-) >> >> A move for which you still haven't mentioned any specific advantages. >> > > > The W3C has abandoned XHTML2, so we should not do any new work in XHTML. I > suppose the current XHTML1.1 site will be fine for quite a while, but > converting it to HTML is pretty easy and puts us on the supported path. > > -Bill > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From wsiegrist at apple.com Tue Jul 14 07:50:12 2009 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 14 Jul 2009 07:50:12 -0700 Subject: macports website In-Reply-To: <4809057c0907140726gb3af326l2d61c246d679a784@mail.gmail.com> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> <4A5C64B1.2020700@macports.org> <96A77103-271E-426B-9C89-A4F0327BA48F@apple.com> <4809057c0907140726gb3af326l2d61c246d679a784@mail.gmail.com> Message-ID: <7A759652-0313-49DA-B763-C766308A4222@apple.com> On Jul 14, 2009, at 7:26 AM, Kristofer Henriksson wrote: > I believe that while the W3C will be disbanding the XHTML working > group, this does not extend to the specification itself, which will > exist in the HTML 5 specification (see > http://www.w3.org/TR/html5/the-xhtml-syntax.html#the-xhtml-syntax). In > other words, XHTML will continue to be have the same level of support > by the W3C, with XHTML 5 and HTML 5 being two equivalent > representations of the markup. > > Since HTML 5 is not yet a recommendation, it would be hasty to switch > to it already. If we switch to XHTML 5 when the HTML 5 specification > is released, it would be by far the easiest path that we could take > while maintaining support for current standards. > > It seems that some are simply opposed to XHTML. Is there a particular > reason to dislike using it for the site? > http://webkit.org/blog/68/understanding-html-xml-and-xhtml/ -Bill From cedric.lists at gmail.com Tue Jul 14 09:11:20 2009 From: cedric.lists at gmail.com (=?ISO-8859-1?Q?C=E9dric_Luthi?=) Date: Tue, 14 Jul 2009 18:11:20 +0200 Subject: mimms 3.2.1 update Message-ID: <32ba1ee20907140911neaf4f20o725260b145c4a65e@mail.gmail.com> Hello, We have a maintainer timeout on https://trac.macports.org/ticket/20204 Could someone please commit ? Best regards. C?dric Luthi From mmoll at macports.org Tue Jul 14 09:52:23 2009 From: mmoll at macports.org (Mark Moll) Date: Tue, 14 Jul 2009 11:52:23 -0500 Subject: installing Rpy using MacPorts Message-ID: <824BBB8E-3400-4DF8-B598-D2585EFBE565@macports.org> I am trying to create a port for rpy2, an interface to R from python. I have R and python2.6 installed through MacPorts. When I run "python setup.py build" in the rpy2-2.0.6 directory, I get the following error: ---> Computing dependencies for py26-rpy ---> Building py26-rpy Error: Target org.macports.build returned: shell command " cd "/opt/ local/var/macports/build/_Users_mmoll_src_macports_dports_python_py26- rpy/work/rpy2-2.0.6" && /opt/local/Library/Frameworks/Python.framework/ Versions/2.6/bin/python2.6 setup.py --no-user-cfg build " returned error 1 Command output: running build running build_py running build_ext building 'rpy2.rinterface.rinterface' extension /usr/bin/gcc-4.0 -L/opt/local/lib -bundle -undefined dynamic_lookup build/temp.macosx-10.5-i386-2.6/rpy/rinterface/array.o build/ temp.macosx-10.5-i386-2.6/rpy/rinterface/r_utils.o build/ temp.macosx-10.5-i386-2.6/rpy/rinterface/rinterface.o -L/opt/local/lib/ R/lib -L/opt/local/lib/R/modules -L/opt/local/lib/R/lib -L/opt/local/ lib/R/modules -lR -o build/lib.macosx-10.5-i386-2.6/rpy2/rinterface/ rinterface.so -L/opt/local/lib/R/lib -lR -dylib_file libRblas.dylib:/ opt/local/lib/R/lib/libRblas.dylib -L/opt/local/lib/R/lib -lRlapack -L/ opt/local/lib/R/lib -lRblas ld: library not found for -lR -dylib_file libRblas.dylib:/opt/local/ lib/R/lib/libRblas.dylib collect2: ld returned 1 exit status error: command '/usr/bin/gcc-4.0' failed with exit status 1 Error: Status 1 encountered during processing. If I copy/paste the last gcc command on the command line I do *not* get an error. How could this be? I can't think of any environment variable that would explain the difference between the "python setup.py build" command and the command line. -- Mark From stechert at gmail.com Tue Jul 14 12:00:39 2009 From: stechert at gmail.com (Andre Stechert) Date: Tue, 14 Jul 2009 12:00:39 -0700 Subject: ocaml port updates In-Reply-To: References: <4A7BC281-83A4-429E-96C7-9566EF74BCB4@recoil.org> Message-ID: <12a697af0907141200u28108db4v2f6b831a1822f4fc@mail.gmail.com> I'm taking a look now. On Mon, Jul 13, 2009 at 9:58 PM, Anil Madhavapeddy wrote: > On 9 Mar 2009, at 20:45, Anil Madhavapeddy wrote: > >> On 9 Mar 2009, at 20:38, Daniel J. Luke wrote: >> >>> On Mar 9, 2009, at 4:22 PM, Anil Madhavapeddy wrote: >>>> >>>> Most of the ports involved are openmaintainers and the updates are a bit >>>> interlinked due to ocaml being updated to 3.11.0. >>> >>> >>> In a case like this, I would open one ticket and CC all of the >>> maintainers of the various ports (and discuss there how to proceed). >> >> Sounds good; I stuck it up on http://trac.macports.org/ticket/18786 > > These updates have been ignored for 3 months despite Damien Pollot also > breaking out individual diffs, and it's getting to be a bit of a pain to > maintain my own parallel tree with OCaml ports > (http://github.com/avsm/darwinports). > > Can I get a macports account to put the new ports in or could someone take a > gander? > > thanks > Anil > _______________________________________________ > 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 Jul 14 12:01:53 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 14 Jul 2009 12:01:53 -0700 Subject: memtester port Message-ID: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> I am not seeing a port for memtester. $cd ~/Downloads/memtester-4.0.8 $sudo make $file memtester memtester: Mach-O executable i386 $./memtester 100 3 -L memtester version 4.0.8 (32-bit) Copyright (C) 2007 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 .... My portfile: # $Id$ PortSystem 1.0 name memtester version 4.0.8 categories sysutils maintainers hostwizard.com:scott description A userspace utility for testing the memory subsystem for faults. long_description A userspace utility for testing the memory subsystem for faults. homepage http://pyropus.ca/software/memtester/ master_sites http://pyropus.ca/software/memtester/old-versions checksums md5 a4971ed1ccaf5b2e2148fd66b0eb7363 \ sha1 1330edaa60e0d797b83df51a56bba377db9223fc \ rmd160 b804eb9563f98ffbd51ce17c091b71a466ba4eae $sudo port -d install DEBUG: Changing to port directory: /Users/me/macports/sysutils/memtester DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: adding the default universal variant DEBUG: Requested variant darwin is not provided by port memtester. DEBUG: Requested variant i386 is not provided by port memtester. DEBUG: Requested variant macosx is not provided by port memtester. DEBUG: Changing to port directory: /Users/me/macports/sysutils/memtester DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: adding the default universal variant DEBUG: Requested variant darwin is not provided by port memtester. DEBUG: Requested variant i386 is not provided by port memtester. DEBUG: Requested variant macosx is not provided by port memtester. DEBUG: Executing org.macports.main (memtester) ---> Fetching memtester DEBUG: Executing org.macports.fetch (memtester) ---> Verifying checksum(s) for memtester DEBUG: Executing org.macports.checksum (memtester) ---> Checksumming memtester-4.0.8.tar.gz DEBUG: Correct (md5) checksum for memtester-4.0.8.tar.gz DEBUG: Correct (sha1) checksum for memtester-4.0.8.tar.gz DEBUG: Correct (rmd160) checksum for memtester-4.0.8.tar.gz ---> Extracting memtester DEBUG: Executing org.macports.extract (memtester) ---> Extracting memtester-4.0.8.tar.gz DEBUG: setting option extract.args to /opt/local/var/macports/ distfiles/memtester/memtester-4.0.8.tar.gz DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.5' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/ _Users_me_macports_sysutils_memtester/work" && gzip -dc /opt/local/var/ macports/distfiles/memtester/memtester-4.0.8.tar.gz | /usr/bin/gnutar --no-same-owner -xf -' DEBUG: Executing org.macports.patch (memtester) ---> Configuring memtester DEBUG: Using compiler 'Mac OS X gcc 4.0' DEBUG: Executing org.macports.configure (memtester) DEBUG: Environment: CFLAGS='-O2' CPPFLAGS='-I/opt/local/include' CXXFLAGS='-O2' MACOSX_DEPLOYMENT_TARGET='10.5' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/g++-4.0' F90FLAGS='-O2' LDFLAGS='-L/opt/local/lib' FCFLAGS='-O2' OBJC='/usr/bin/gcc-4.0' INSTALL='/usr/bin/install -c' OBJCFLAGS='-O2' FFLAGS='-O2' CC='/usr/bin/gcc-4.0' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/ _Users_me_macports_sysutils_memtester/work/memtester-4.0.8" && ./ configure --prefix=/opt/local' sh: ./configure: No such file or directory Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/ _Users_me_macports_sysutils_memtester/work/memtester-4.0.8" && ./ configure --prefix=/opt/local " returned error 127 Command output: sh: ./configure: No such file or directory Warning: the following items did not execute (for memtester): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. Where am I getting tripped up on this one? Do I need destroot to also install the binary and the man pages, or does that happen as part of make install? Could this be that make is not able to understand the prefix? I could then add configure.pre_args-delete --prefix=${prefix} and just hand install this man and binary in correct locations? Here is the by hand method: $sudo make --prefix=/opt/local make: unrecognized option `--prefix=/opt/local' Usage: make [options] [target] ... Options: -b, -m Ignored for compatibility. -B, --always-make Unconditionally make all targets. -C DIRECTORY, --directory=DIRECTORY Change to DIRECTORY before doing anything. -d Print lots of debugging information. --debug[=FLAGS] Print various types of debugging information. -e, --environment-overrides Environment variables override makefiles. -f FILE, --file=FILE, --makefile=FILE Read FILE as a makefile. -h, --help Print this message and exit. -i, --ignore-errors Ignore errors from commands. -I DIRECTORY, --include-dir=DIRECTORY Search DIRECTORY for included makefiles. -j [N], --jobs[=N] Allow N jobs at once; infinite jobs with no arg. -k, --keep-going Keep going when some targets can't be made. -l [N], --load-average[=N], --max-load[=N] Don't start multiple jobs unless load is below N. -L, --check-symlink-times Use the latest mtime between symlinks and target. -n, --just-print, --dry-run, --recon Don't actually run any commands; just print them. -o FILE, --old-file=FILE, --assume-old=FILE Consider FILE to be very old and don't remake it. -p, --print-data-base Print make's internal database. -q, --question Run no commands; exit status says if up to date. -r, --no-builtin-rules Disable the built-in implicit rules. -R, --no-builtin-variables Disable the built-in variable settings. -s, --silent, --quiet Don't echo commands. -S, --no-keep-going, --stop Turns off -k. -t, --touch Touch targets instead of remaking them. -v, --version Print the version number of make and exit. -w, --print-directory Print the current directory. --no-print-directory Turn off -w, even if it was turned on implicitly. -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE Consider FILE to be infinitely new. --warn-undefined-variables Warn when an undefined variable is referenced. -N OPTION, --NeXT-option=OPTION Turn on value of NeXT OPTION. This program built for powerpc-apple-darwin9.0 Report bugs to -- Scott * If you contact me off list replace talklists@ with scott@ * From blb at macports.org Tue Jul 14 12:21:33 2009 From: blb at macports.org (Bryan Blackburn) Date: Tue, 14 Jul 2009 13:21:33 -0600 Subject: installing Rpy using MacPorts In-Reply-To: <824BBB8E-3400-4DF8-B598-D2585EFBE565@macports.org> References: <824BBB8E-3400-4DF8-B598-D2585EFBE565@macports.org> Message-ID: <20090714192132.GE20770@ninagal.withay.com> On Tue, Jul 14, 2009 at 11:52:23AM -0500, Mark Moll said: > I am trying to create a port for rpy2, an interface to R from python. > I have R and python2.6 installed through MacPorts. When I run "python > setup.py build" in the rpy2-2.0.6 directory, I get the following > error: > > ---> Computing dependencies for py26-rpy > ---> Building py26-rpy [...] > ld: library not found for -lR -dylib_file libRblas.dylib:/opt/local/ > lib/R/lib/libRblas.dylib See for some work on rpy2, and for the fix in R (which I see I can probably commit here soon). Bryan [...] > > -- > Mark From jeremy at lavergne.gotdns.org Tue Jul 14 12:22:04 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 14 Jul 2009 15:22:04 -0400 Subject: memtester port In-Reply-To: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> Message-ID: <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> On Jul 14, 2009, at 3:01 PM, Scott Haneda wrote: > I am not seeing a port for memtester. > # $Id$ > PortSystem 1.0 > > name memtester > version 4.0.8 > categories sysutils > maintainers hostwizard.com:scott > description A userspace utility for testing the memory subsystem > for faults. > long_description A userspace utility for testing the memory > subsystem for faults. > > homepage http://pyropus.ca/software/memtester/ > master_sites http://pyropus.ca/software/memtester/old-versions > checksums md5 a4971ed1ccaf5b2e2148fd66b0eb7363 \ > sha1 1330edaa60e0d797b83df51a56bba377db9223fc \ > rmd160 b804eb9563f98ffbd51ce17c091b71a466ba4eae > > ... > > ---> Configuring memtester > DEBUG: Using compiler 'Mac OS X gcc 4.0' > DEBUG: Executing org.macports.configure (memtester) > DEBUG: Environment: CFLAGS='-O2' CPPFLAGS='-I/opt/local/include' > CXXFLAGS='-O2' MACOSX_DEPLOYMENT_TARGET='10.5' CPP='/usr/bin/ > cpp-4.0' CXX='/usr/bin/g++-4.0' F90FLAGS='-O2' LDFLAGS='-L/opt/local/ > lib' FCFLAGS='-O2' OBJC='/usr/bin/gcc-4.0' INSTALL='/usr/bin/install > -c' OBJCFLAGS='-O2' FFLAGS='-O2' CC='/usr/bin/gcc-4.0' > DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/ > _Users_me_macports_sysutils_memtester/work/memtester-4.0.8" && ./ > configure --prefix=/opt/local' > sh: ./configure: No such file or directory > Error: Target org.macports.configure returned: configure failure: > shell command " cd "/opt/local/var/macports/build/ > _Users_me_macports_sysutils_memtester/work/memtester-4.0.8" && ./ > configure --prefix=/opt/local " returned error 127 > Command output: sh: ./configure: No such file or directory > > Warning: the following items did not execute (for memtester): > org.macports.activate org.macports.configure org.macports.build > org.macports.destroot org.macports.install > Error: Status 1 encountered during processing. > > Where am I getting tripped up on this one? You need to add `use_configure no` > Do I need destroot to also install the binary and the man pages, or > does that happen as part of make install? Could this be that make > is not able to understand the prefix? You might consider patching the Makefile's install portion, or you'll find yourself using xinstall lines to do the installation 'manually' in the portfile. > > I could then add > configure.pre_args-delete --prefix=${prefix} > and just hand install this man and binary in correct locations? > > Here is the by hand method: > $sudo make --prefix=/opt/local > make: unrecognized option `--prefix=/opt/local' > Usage: make [options] [target] ... > Options: > -b, -m Ignored for compatibility. > -B, --always-make Unconditionally make all targets. > -C DIRECTORY, --directory=DIRECTORY > Change to DIRECTORY before doing > anything. > -d Print lots of debugging information. > --debug[=FLAGS] Print various types of debugging > information. > -e, --environment-overrides > Environment variables override makefiles. > -f FILE, --file=FILE, --makefile=FILE > Read FILE as a makefile. > -h, --help Print this message and exit. > -i, --ignore-errors Ignore errors from commands. > -I DIRECTORY, --include-dir=DIRECTORY > Search DIRECTORY for included makefiles. > -j [N], --jobs[=N] Allow N jobs at once; infinite jobs > with no arg. > -k, --keep-going Keep going when some targets can't be > made. > -l [N], --load-average[=N], --max-load[=N] > Don't start multiple jobs unless load > is below N. > -L, --check-symlink-times Use the latest mtime between symlinks > and target. > -n, --just-print, --dry-run, --recon > Don't actually run any commands; just > print them. > -o FILE, --old-file=FILE, --assume-old=FILE > Consider FILE to be very old and don't > remake it. > -p, --print-data-base Print make's internal database. > -q, --question Run no commands; exit status says if up > to date. > -r, --no-builtin-rules Disable the built-in implicit rules. > -R, --no-builtin-variables Disable the built-in variable settings. > -s, --silent, --quiet Don't echo commands. > -S, --no-keep-going, --stop > Turns off -k. > -t, --touch Touch targets instead of remaking them. > -v, --version Print the version number of make and > exit. > -w, --print-directory Print the current directory. > --no-print-directory Turn off -w, even if it was turned on > implicitly. > -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE > Consider FILE to be infinitely new. > --warn-undefined-variables Warn when an undefined variable is > referenced. > -N OPTION, --NeXT-option=OPTION > Turn on value of NeXT OPTION. > > This program built for powerpc-apple-darwin9.0 > Report bugs to > > > -- > Scott * If you contact me off list replace talklists@ with scott@ * > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From talklists at newgeo.com Tue Jul 14 12:43:11 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 14 Jul 2009 12:43:11 -0700 Subject: memtester port In-Reply-To: <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> Message-ID: <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> >> Where am I getting tripped up on this one? > > You need to add `use_configure no` Ok, done http://dl.getdropbox.com/u/340087/Drops/07.14.09/memtest-4460164b-123912.txt Looks like this was called from the makefile: mkdir -m 755 -p /usr/local/{bin,man/man8} install -m 755 memtester /usr/local/bin/ gzip -c memtester.8 >memtester.8.gz ; install -m 644 memtester.8.gz / usr/local/man/man8/ That probably was not good? >> Do I need destroot to also install the binary and the man pages, or >> does that happen as part of make install? Could this be that make >> is not able to understand the prefix? > > You might consider patching the Makefile's install portion, or > you'll find yourself using xinstall lines to do the installation > 'manually' in the portfile. My plan was to infact xinstal the files, but I am open to learning how to patch the makefile. In this one, do I need to just reinplace INSTALLPATH = /usr/local Here is the makefile http://dl.getdropbox.com/u/340087/Drops/07.14.09/Makefile-5698c444-124226.txt Thanks -- Scott * If you contact me off list replace talklists@ with scott@ * From jeremy at lavergne.gotdns.org Tue Jul 14 12:44:39 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 14 Jul 2009 15:44:39 -0400 Subject: memtester port In-Reply-To: <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> Message-ID: Ooo! you use dropbox! /drool On Jul 14, 2009, at 3:43 PM, Scott Haneda wrote: > http://dl.getdropbox.com/u/340087/Drops/07.14.09/memtest-4460164b-123912.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Tue Jul 14 12:46:17 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 14 Jul 2009 15:46:17 -0400 Subject: memtester port In-Reply-To: <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> Message-ID: <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> On Jul 14, 2009, at 3:43 PM, Scott Haneda wrote: > My plan was to infact xinstal the files, but I am open to learning > how to patch the makefile. > > In this one, do I need to just reinplace > INSTALLPATH = /usr/local > > Here is the makefile > http://dl.getdropbox.com/u/340087/Drops/07.14.09/Makefile-5698c444-124226.txt That's the major thing. You will also want to change the man/man8 to be share/man/man8. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From walt at wump.org Tue Jul 14 12:48:44 2009 From: walt at wump.org (Walt Pawley) Date: Tue, 14 Jul 2009 12:48:44 -0700 Subject: macports website In-Reply-To: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> Message-ID: At 6:31 PM -0400 7/13/09, Jeremy Lavergne wrote: >Interested in this transition, I asked wms how to go about instigating >the change. He directed me to ask you for your thoughts on bringing >the site into HTML 5. So, ticket-filers, hecklers, ... Ah, my category. It's been my experience that every such "upgrade" breaks the functionality of browsers that are not "up to date." New browsers, OTOH, seldom have trouble rendering decent presentations of the standards of their predecessors'. Is the point of fixing what isn't broken just being "politically correct?" -- Walter M. Pawley Wump Research & Company 676 River Bend Road, Roseburg, OR 97471 541-672-8975 From jeremy at lavergne.gotdns.org Tue Jul 14 12:54:09 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 14 Jul 2009 15:54:09 -0400 Subject: macports website In-Reply-To: References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> Message-ID: <34224537-5F3A-4AAD-8E54-592FAC9F9271@lavergne.gotdns.org> I don't seeing using HTML 5 as an upgrade so much as a side step. It doesn't break things -- even as far back as IE6, which most companies use. Also, since yet another ticket has shown up due to having to do fun fancy tagging due to the XML side of XHTML, I figured it would be another reason to bring back the discussion of getting of XHTML. On Jul 14, 2009, at 3:48 PM, Walt Pawley wrote: > Ah, my category. > > It's been my experience that every such "upgrade" breaks the > functionality of browsers that are not "up to date." New > browsers, OTOH, seldom have trouble rendering decent > presentations of the standards of their predecessors'. Is the > point of fixing what isn't broken just being "politically > correct?" -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From talklists at newgeo.com Tue Jul 14 12:55:43 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 14 Jul 2009 12:55:43 -0700 Subject: memtester port In-Reply-To: References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> Message-ID: On Jul 14, 2009, at 12:44 PM, Jeremy Lavergne wrote: > Ooo! you use dropbox! /drool > > On Jul 14, 2009, at 3:43 PM, Scott Haneda wrote: > >> http://dl.getdropbox.com/u/340087/Drops/07.14.09/memtest-4460164b-123912.txt ha ha :) If you want to try out a small little app I made, allows you to drop any file, or group of files/folders, and it will create that semi obfuscated url above, and put it on your clipboard. It also alerts with Growl. You can use one file, and it does as above, your can use multiple files, and it will create a list of urls, and you can drop a folder, and it will zip it. You can get it here http://dl.getdropbox.com/u/340087/Drops/07.14.09/Droppings-811da69a-125445.zip -- Scott * If you contact me off list replace talklists@ with scott@ * From talklists at newgeo.com Tue Jul 14 12:58:17 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 14 Jul 2009 12:58:17 -0700 Subject: memtester port In-Reply-To: <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> Message-ID: On Jul 14, 2009, at 12:46 PM, Jeremy Lavergne wrote: > On Jul 14, 2009, at 3:43 PM, Scott Haneda wrote: >> My plan was to infact xinstal the files, but I am open to learning >> how to patch the makefile. >> >> In this one, do I need to just reinplace >> INSTALLPATH = /usr/local >> >> Here is the makefile >> http://dl.getdropbox.com/u/340087/Drops/07.14.09/Makefile-5698c444-124226.txt > > That's the major thing. You will also want to change the man/man8 > to be share/man/man8. Ok, working on it. How do you test this as you go, and tell ports to not clean up the files, so I can see if the reinplaces worked to my liking? -- Scott * If you contact me off list replace talklists@ with scott@ * From jeremy at lavergne.gotdns.org Tue Jul 14 13:01:33 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 14 Jul 2009 16:01:33 -0400 Subject: memtester port In-Reply-To: References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> Message-ID: <5FA189A5-AB74-4C18-89AE-2B5D2B04BC8B@lavergne.gotdns.org> You just tell it what phase you want it to do, and then it'll stop after it. `sudo port patch memtester` fetch -> extract -> patch -> configure -> build -> test? -> destroot - > install -> activate It's on the Guide if you need a precise listing. On Jul 14, 2009, at 3:58 PM, Scott Haneda wrote: > Ok, working on it. How do you test this as you go, and tell ports > to not clean up the files, so I can see if the reinplaces worked to > my liking? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Tue Jul 14 13:02:14 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 14 Jul 2009 16:02:14 -0400 Subject: memtester port In-Reply-To: References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> Message-ID: There's also -k (keep mode) which should counteract the default to autoclean. On Jul 14, 2009, at 3:58 PM, Scott Haneda wrote: > Ok, working on it. How do you test this as you go, and tell ports > to not clean up the files, so I can see if the reinplaces worked to > my liking? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From talklists at newgeo.com Tue Jul 14 13:14:27 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 14 Jul 2009 13:14:27 -0700 Subject: memtester port In-Reply-To: <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> Message-ID: On Jul 14, 2009, at 12:46 PM, Jeremy Lavergne wrote: > On Jul 14, 2009, at 3:43 PM, Scott Haneda wrote: > >> My plan was to infact xinstal the files, but I am open to learning >> how to patch the makefile. >> >> In this one, do I need to just reinplace >> INSTALLPATH = /usr/local >> >> Here is the makefile >> http://dl.getdropbox.com/u/340087/Drops/07.14.09/Makefile-5698c444-124226.txt > > That's the major thing. You will also want to change the man/man8 > to be share/man/man8. Is this an issue wrt to the mkdir? Should I change that as well? install: all mkdir -m 755 -p $(INSTALLPATH)/{bin,man/man8} install -m 755 memtester $(INSTALLPATH)/bin/ gzip -c memtester.8 >memtester.8.gz ; install -m 644 memtester.8.gz $ (INSTALLPATH)/man/man8/ Is the way I am doing ${master_sites} correct? Is it acceptable to leave out the long description, I think the short is more than enough. Is my category correct in sysutils? # $Id$ PortSystem 1.0 name memtester version 4.0.8 categories sysutils maintainers hostwizard.com:scott description A userspace utility for testing the memory subsystem for faults. long_description A userspace utility for testing the memory subsystem for faults. homepage http://pyropus.ca/software/memtester/ master_sites ${homepage}/old-versions checksums md5 a4971ed1ccaf5b2e2148fd66b0eb7363 \ sha1 1330edaa60e0d797b83df51a56bba377db9223fc \ rmd160 b804eb9563f98ffbd51ce17c091b71a466ba4eae use_configure no pre-patch { reinplace "s|/usr/local|${prefix}|" ${worksrcpath}/Makefile reinplace "s|/man/man8/|/share/man/man8|" ${worksrcpath}/Makefile } $sudo port -d install memtester DEBUG: Found port in file:///Users/haneda/macports/sysutils/memtester DEBUG: Changing to port directory: /Users/haneda/macports/sysutils/ memtester DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: not using configure, so not adding the default universal variant DEBUG: Requested variant darwin is not provided by port memtester. DEBUG: Requested variant i386 is not provided by port memtester. DEBUG: Requested variant macosx is not provided by port memtester. DEBUG: Executing org.macports.main (memtester) DEBUG: Skipping completed org.macports.fetch (memtester) DEBUG: Skipping completed org.macports.checksum (memtester) DEBUG: Skipping completed org.macports.extract (memtester) DEBUG: Skipping completed org.macports.patch (memtester) DEBUG: Skipping completed org.macports.configure (memtester) DEBUG: Skipping completed org.macports.build (memtester) DEBUG: Skipping completed org.macports.destroot (memtester) ---> Installing memtester @4.0.8_0 DEBUG: Executing org.macports.install (memtester) couldn't change working directory to "/opt/local/var/macports/build/ _Users_haneda_macports_sysutils_memtester/work/destroot": no such file or directory DEBUG: Executing org.macports.activate (memtester) ---> Activating memtester @4.0.8_0 Error: Target org.macports.activate returned: Image error: Source file /opt/local/var/macports/software/memtester/4.0.8_0 does not appear to exist (cannot lstat it). Unable to activate port memtester. Warning: the following items did not execute (for memtester): org.macports.activate Error: Status 1 encountered during processing. I am messing something up, as there is a path above that is not there. -- Scott * If you contact me off list replace talklists@ with scott@ * From kthenriksson at gmail.com Tue Jul 14 13:13:46 2009 From: kthenriksson at gmail.com (Kristofer Henriksson) Date: Tue, 14 Jul 2009 16:13:46 -0400 Subject: macports website In-Reply-To: <06CD71F1-DDFA-4D28-9BE2-81AF89A7989E@lavergne.gotdns.org> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> <4A5C64B1.2020700@macports.org> <96A77103-271E-426B-9C89-A4F0327BA48F@apple.com> <4809057c0907140726gb3af326l2d61c246d679a784@mail.gmail.com> <06CD71F1-DDFA-4D28-9BE2-81AF89A7989E@lavergne.gotdns.org> Message-ID: <4809057c0907141313w2418829ew66cd55f07bb9a545@mail.gmail.com> I read the article he linked to, and it seems that one main concern with XHTML is the MIME type issue, which exists because IE does not deal with the XHTML mime type properly. We deal with this by sending the wrong MIME type to IE. The result is that IE receives invalid markup but parses it anyway and presents the page satisfactorily, and everyone else receives entirely valid XHTML. I suppose there is also the issue of error handling brought up by the recent ticket, for which the two are polar opposites, with XHTML failing entirely for any error, and HTML not failing for any error at all, just rendering as well as possible. Is this also a concern--do we prefer no errors in the event of invalid markup? Any points I missed? As a side note, such divergent error handling makes it a shame that there is no debug-type option for error handling to be set in browsers, with XHTML-style failure when debugging is enabled and silent HTML-style perseverance when disabled. On Tue, Jul 14, 2009 at 3:56 PM, Jeremy Lavergne wrote: > Did Siegrist's link take care of your question? > > On Jul 14, 2009, at 10:26 AM, Kristofer Henriksson wrote: > >> It seems that some are simply opposed to XHTML. Is there a particular >> reason to dislike using it for the site? > > From jeremy at lavergne.gotdns.org Tue Jul 14 13:21:52 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 14 Jul 2009 16:21:52 -0400 Subject: memtester port In-Reply-To: References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> Message-ID: <6202FB01-7B42-4AEE-8FE9-9AFEFB0C6258@lavergne.gotdns.org> On Jul 14, 2009, at 4:14 PM, Scott Haneda wrote: > Is this an issue wrt to the mkdir? Should I change that as well? You wouldn't make it past your pre-patch if that were the case. It would error out saying it couldn't find the file. > install: all > mkdir -m 755 -p $(INSTALLPATH)/{bin,man/man8} > install -m 755 memtester $(INSTALLPATH)/bin/ > gzip -c memtester.8 >memtester.8.gz ; install -m 644 memtester.8.gz > $(INSTALLPATH)/man/man8/ > > Is the way I am doing ${master_sites} correct? Is it acceptable to > leave out the long description, I think the short is more than > enough. Is my category correct in sysutils? long_description is needed, but you can set it to ${description} I need to head out for a few hours ... someone else care to continue helping? :-) > > # $Id$ > PortSystem 1.0 > > name memtester > version 4.0.8 > categories sysutils > maintainers hostwizard.com:scott > description A userspace utility for testing the memory subsystem > for faults. > long_description A userspace utility for testing the memory > subsystem for faults. > > homepage http://pyropus.ca/software/memtester/ > master_sites ${homepage}/old-versions > checksums md5 a4971ed1ccaf5b2e2148fd66b0eb7363 \ > sha1 1330edaa60e0d797b83df51a56bba377db9223fc \ > rmd160 b804eb9563f98ffbd51ce17c091b71a466ba4eae > > use_configure no > > pre-patch { > reinplace "s|/usr/local|${prefix}|" ${worksrcpath}/Makefile > reinplace "s|/man/man8/|/share/man/man8|" ${worksrcpath}/Makefile > } -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From talklists at newgeo.com Tue Jul 14 16:28:58 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 14 Jul 2009 16:28:58 -0700 Subject: memtester port In-Reply-To: <6202FB01-7B42-4AEE-8FE9-9AFEFB0C6258@lavergne.gotdns.org> References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> <6202FB01-7B42-4AEE-8FE9-9AFEFB0C6258@lavergne.gotdns.org> Message-ID: <9CF165AF-3ED6-46BB-945E-A574C77D41A2@newgeo.com> On Jul 14, 2009, at 1:21 PM, Jeremy Lavergne wrote: > long_description is needed, but you can set it to ${description} > > I need to head out for a few hours ... someone else care to continue > helping? :-) I think I got it, cool thing is, now people do not have to pay the whopping $1.39 to buy this app :) Here is my final port, my areas of concern are the livecheck regex. That is a copy and paste from elsewhere, and I can not break it out. You have to escape regex inside livecheck? So d+ is all numbers, that ?: is a mystery to me, and then a dot, and then a digit, and then aything. I have three distinct version digits, so there may be some altering that needs to happen here. Perhaps the * means, match the pattern of digit and dot as many times as it happens? Any other suggestions before I ship it off to trac? PortSystem 1.0 name memtester version 4.0.8 categories sysutils maintainers hostwizard.com:scott platforms darwin description A userspace utility for testing the memory subsystem for faults. long_description ${description} homepage http://pyropus.ca/software/memtester/ master_sites ${homepage}/old-versions checksums md5 a4971ed1ccaf5b2e2148fd66b0eb7363 \ sha1 1330edaa60e0d797b83df51a56bba377db9223fc \ rmd160 b804eb9563f98ffbd51ce17c091b71a466ba4eae livecheck.url ${homepage}/old-versions/ livecheck.regex "${name}-(\\d+(?:\\.\\d+)*)${extract.suffix}" use_configure no pre-patch { reinplace "s|/usr/local|${destroot}${prefix}|" ${worksrcpath}/ Makefile reinplace "s|man/man|share/man/man|" ${worksrcpath}/Makefile } -- Scott * If you contact me off list replace talklists@ with scott@ * From jeremy at lavergne.gotdns.org Tue Jul 14 18:46:53 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 14 Jul 2009 21:46:53 -0400 Subject: memtester port In-Reply-To: <9CF165AF-3ED6-46BB-945E-A574C77D41A2@newgeo.com> References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> <6202FB01-7B42-4AEE-8FE9-9AFEFB0C6258@lavergne.gotdns.org> <9CF165AF-3ED6-46BB-945E-A574C77D41A2@newgeo.com> Message-ID: On Jul 14, 2009, at 7:28 PM, Scott Haneda wrote: > Here is my final port, my areas of concern are the livecheck regex. > That is a copy and paste from elsewhere, and I can not break it > out. You have to escape regex inside livecheck? Yes, if you use quotations, you must use double escapes. If you use braces, then only one escape is needed. > So d+ is all numbers, that ?: is a mystery to me, and then a dot, > and then a digit, and then aything. I have three distinct version > digits, so there may be some altering that needs to happen here. > Perhaps the * means, match the pattern of digit and dot as many > times as it happens? The d is "one numeric digit or more." The ?: basically means find the first one and stop -- saves on speed and memory versus matching the whole line. * means 0 or more (and finally ? means 0 or 1 -- that's ? + and * quantifiers). > Any other suggestions before I ship it off to trac? Does it pass `port lint --nitpick memtester`? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From talklists at newgeo.com Tue Jul 14 19:01:13 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 14 Jul 2009 19:01:13 -0700 Subject: memtester port In-Reply-To: References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> <6202FB01-7B42-4AEE-8FE9-9AFEFB0C6258@lavergne.gotdns.org> <9CF165AF-3ED6-46BB-945E-A574C77D41A2@newgeo.com> Message-ID: >> Any other suggestions before I ship it off to trac? > > Does it pass `port lint --nitpick memtester`? Thanks for the regex explanation, I was so hung up on that quoting issue and escapes. Handy command on the nitpick $port lint --nitpick memtester ---> Verifying Portfile for memtester ---> 0 errors and 0 warnings found. I had a few newline issues, but I am all set now. -- Scott * If you contact me off list replace talklists@ with scott@ * From jeremy at lavergne.gotdns.org Tue Jul 14 19:36:06 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 14 Jul 2009 22:36:06 -0400 Subject: memtester port In-Reply-To: References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> <6202FB01-7B42-4AEE-8FE9-9AFEFB0C6258@lavergne.gotdns.org> <9CF165AF-3ED6-46BB-945E-A574C77D41A2@newgeo.com> Message-ID: <60865659-FAEE-464F-B514-C26A55B7D3F7@lavergne.gotdns.org> Alrighty, create a port submission ticket and you're good to go. On Jul 14, 2009, at 10:01 PM, Scott Haneda wrote: > I had a few newline issues, but I am all set now. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From talklists at newgeo.com Tue Jul 14 20:16:11 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 14 Jul 2009 20:16:11 -0700 Subject: memtester port In-Reply-To: <60865659-FAEE-464F-B514-C26A55B7D3F7@lavergne.gotdns.org> References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> <6202FB01-7B42-4AEE-8FE9-9AFEFB0C6258@lavergne.gotdns.org> <9CF165AF-3ED6-46BB-945E-A574C77D41A2@newgeo.com> <60865659-FAEE-464F-B514-C26A55B7D3F7@lavergne.gotdns.org> Message-ID: On Jul 14, 2009, at 7:36 PM, Jeremy Lavergne wrote: > Alrighty, create a port submission ticket and you're good to go. > > On Jul 14, 2009, at 10:01 PM, Scott Haneda wrote: > >> I had a few newline issues, but I am all set now. http://trac.macports.org/ticket/20306 -- Scott * If you contact me off list replace talklists@ with scott@ * From talklists at newgeo.com Wed Jul 15 11:38:44 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 15 Jul 2009 11:38:44 -0700 Subject: On the heels of the memtester port Message-ID: <3B59D8ED-58B6-4AE5-B36F-EF6F8B2177C2@newgeo.com> Hello, I have been reading today about Makefiles, not getting too far. The Makefile for memtester did not accept the --prefix argument. I also had this issue with the rbldnsd port as well. Can someone summarize why some sources are so simple to make a portfile for, and others require reinplacing the Makefile to alter it just enough to conform how MacPorts will need it to be? 99% of the time, --prefix works fine, why would someone omit it, and assume that software wants to be in say /usr/local/bin? There could be any number of other layouts the user wants to put things in, /opt/ local being just one. memtestx is a branch of memtester, that is pay for software. A very small fee. I would like to release memtester as free software. I feel a lot of people would benefit from it. However, a lot of people are not going to want to install MacPorts just to get memtester. If I use MacPorts to make a package installer, do I need to do so on each of 10.4, and 10.5 for PPC and Intel, and make 4 total binary files? Is there any way to make a universal binary so I can only distribute one file? Suggestions on how to deal with the man page would also be appreciated, as well as a standard to OS X location to store memtester in this scenario. Is /Applications a bad spot of a command line binary in a case like this? Thank you porters -- Scott * If you contact me off list replace talklists@ with scott@ * From jeremy at lavergne.gotdns.org Wed Jul 15 11:46:08 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 15 Jul 2009 14:46:08 -0400 Subject: On the heels of the memtester port In-Reply-To: <3B59D8ED-58B6-4AE5-B36F-EF6F8B2177C2@newgeo.com> References: <3B59D8ED-58B6-4AE5-B36F-EF6F8B2177C2@newgeo.com> Message-ID: On Jul 15, 2009, at 2:38 PM, Scott Haneda wrote: > Can someone summarize why some sources are so simple to make a > portfile for, and others require reinplacing the Makefile to alter > it just enough to conform how MacPorts will need it to be? > > 99% of the time, --prefix works fine, why would someone omit it, and > assume that software wants to be in say /usr/local/bin? There could > be any number of other layouts the user wants to put things in, /opt/ > local being just one. Where the user wants to install the software is something that can be overlooked by developers who right software for their needs and then release it to the public. They're under no obligation to make it conform to expected behavior. When people aim to be as compliant as they can, you find the easiest portfiles. > memtestx is a branch of memtester, that is pay for software. A very > small fee. I would like to release memtester as free software. I > feel a lot of people would benefit from it. However, a lot of > people are not going to want to install MacPorts just to get > memtester. > > If I use MacPorts to make a package installer, do I need to do so on > each of 10.4, and 10.5 for PPC and Intel, and make 4 total binary > files? Is there any way to make a universal binary so I can only > distribute one file? Unless specifically deactivated, all ports have a +universal variant. This will combine the pcc and and intel, and targets whatever OS you have configured (both of these settings are found at the bottom of macports.conf). > Suggestions on how to deal with the man page would also be > appreciated, as well as a standard to OS X location to store > memtester in this scenario. Is /Applications a bad spot of a > command line binary in a case like this? Manpages are ${prefix}/share/man/manX/ If you're going to install these outside of MacPorts, I'd suggest /usr/ local/bin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Wed Jul 15 11:48:39 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 15 Jul 2009 14:48:39 -0400 Subject: On the heels of the memtester port In-Reply-To: References: <3B59D8ED-58B6-4AE5-B36F-EF6F8B2177C2@newgeo.com> Message-ID: <36F5AD8A-7844-4498-A5AC-A5722F62C629@lavergne.gotdns.org> On Jul 15, 2009, at 2:46 PM, Jeremy Lavergne wrote: > If you're going to install these outside of MacPorts, I'd suggest / > usr/local/bin ... for the binaries. basically, you'd mimic macports in that $ {prefix} would be `/usr/local` -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From talklists at newgeo.com Wed Jul 15 11:58:03 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 15 Jul 2009 11:58:03 -0700 Subject: On the heels of the memtester port In-Reply-To: <36F5AD8A-7844-4498-A5AC-A5722F62C629@lavergne.gotdns.org> References: <3B59D8ED-58B6-4AE5-B36F-EF6F8B2177C2@newgeo.com> <36F5AD8A-7844-4498-A5AC-A5722F62C629@lavergne.gotdns.org> Message-ID: <1F4AF118-8259-4545-8E57-C689DA09E46E@newgeo.com> On Jul 15, 2009, at 11:48 AM, Jeremy Lavergne wrote: > On Jul 15, 2009, at 2:46 PM, Jeremy Lavergne wrote: > >> If you're going to install these outside of MacPorts, I'd suggest / >> usr/local/bin > > ... for the binaries. basically, you'd mimic macports in that $ > {prefix} would be `/usr/local` Cool, thanks. I just did sudo port -d dmg memtester and it worked fine. Is there a way on the command above to alter prefix for the one time build to /usr/local/bin and is there a way to also alter it to be able to put the man page in the correct place? Or do I just create a separate local port for these specific needs? -- Scott * If you contact me off list replace talklists@ with scott@ * From jeremy at lavergne.gotdns.org Wed Jul 15 12:23:15 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 15 Jul 2009 15:23:15 -0400 Subject: On the heels of the memtester port In-Reply-To: <1F4AF118-8259-4545-8E57-C689DA09E46E@newgeo.com> References: <3B59D8ED-58B6-4AE5-B36F-EF6F8B2177C2@newgeo.com> <36F5AD8A-7844-4498-A5AC-A5722F62C629@lavergne.gotdns.org> <1F4AF118-8259-4545-8E57-C689DA09E46E@newgeo.com> Message-ID: On Jul 15, 2009, at 2:58 PM, Scott Haneda wrote: > sudo port -d dmg memtester > ... > Is there a way on the command above to alter prefix for the one time > build to /usr/local/bin and is there a way to also alter it to be > able to put the man page in the correct place? > > Or do I just create a separate local port for these specific needs? I believe that build only happens if destroot is empty or you force it; autoclean can be your enemy. That being said, you can build macports to use any prefix you desire, and use it strictly for building/testing your dmg. On a per-port level -- I'm not sure I'd suggest that since all the dependencies should also be in this specified location. The easiest way to achieve that is just compiling MacPorts for another prefix. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From talklists at newgeo.com Wed Jul 15 12:50:18 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 15 Jul 2009 12:50:18 -0700 Subject: On the heels of the memtester port In-Reply-To: References: <3B59D8ED-58B6-4AE5-B36F-EF6F8B2177C2@newgeo.com> <36F5AD8A-7844-4498-A5AC-A5722F62C629@lavergne.gotdns.org> <1F4AF118-8259-4545-8E57-C689DA09E46E@newgeo.com> Message-ID: <95C6814B-704B-4701-ADCF-C232E3C32A4A@newgeo.com> On Jul 15, 2009, at 12:23 PM, Jeremy Lavergne wrote: > On Jul 15, 2009, at 2:58 PM, Scott Haneda wrote: > >> sudo port -d dmg memtester >> ... >> Is there a way on the command above to alter prefix for the one >> time build to /usr/local/bin and is there a way to also alter it to >> be able to put the man page in the correct place? >> >> Or do I just create a separate local port for these specific needs? > > I believe that build only happens if destroot is empty or you force > it; autoclean can be your enemy. That being said, you can build > macports to use any prefix you desire, and use it strictly for > building/testing your dmg. > > On a per-port level -- I'm not sure I'd suggest that since all the > dependencies should also be in this specified location. The easiest > way to achieve that is just compiling MacPorts for another prefix. Hmm, sounds like a lot of work for just one small binary. I just pulled the binary out of the pkg, and get info on it, and it says it is a Intel file. $lipo -info memtester Non-fat file: memtester is architecture: i386 I also just uninstalled and then `sudo port install memtester +universal` $lipo -info memtester Non-fat file: memtester is architecture: i386 I suspect this has to do with: DEBUG: not using configure, so not adding the default universal variant I am probably getting in over my head on this one, but would like to hear some suggestions. -- Scott * If you contact me off list replace talklists@ with scott@ * From jmr at macports.org Wed Jul 15 15:51:56 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 16 Jul 2009 08:51:56 +1000 Subject: On the heels of the memtester port In-Reply-To: References: <3B59D8ED-58B6-4AE5-B36F-EF6F8B2177C2@newgeo.com> Message-ID: <4A5E5D8C.6090800@macports.org> On 2009-7-16 04:46, Jeremy Lavergne wrote: > Unless specifically deactivated, all ports have a +universal variant. Not actually true. Setting 'use_configure no' or 'use_xmkmf yes' will disable the default universal variant, because it depends on there being an autoconf-like configure script. - Josh From jmr at macports.org Wed Jul 15 15:58:39 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 16 Jul 2009 08:58:39 +1000 Subject: On the heels of the memtester port In-Reply-To: <3B59D8ED-58B6-4AE5-B36F-EF6F8B2177C2@newgeo.com> References: <3B59D8ED-58B6-4AE5-B36F-EF6F8B2177C2@newgeo.com> Message-ID: <4A5E5F1F.20606@macports.org> On 2009-7-16 04:38, Scott Haneda wrote: > Hello, I have been reading today about Makefiles, not getting too far. > > The Makefile for memtester did not accept the --prefix argument. I also > had this issue with the rbldnsd port as well. The --prefix argument is for a configure script, not a makefile. Make does allow you to pick up variables from the environment, or set them on the command line with NAME=value syntax. > Can someone summarize why some sources are so simple to make a portfile > for, and others require reinplacing the Makefile to alter it just enough > to conform how MacPorts will need it to be? If software can be installed with `./configure && make && sudo make install` it's generally easy to make a port for. The more it differs from this, the more work you'll likely have to do. > If I use MacPorts to make a package installer, do I need to do so on > each of 10.4, and 10.5 for PPC and Intel, and make 4 total binary > files? Is there any way to make a universal binary so I can only > distribute one file? You can build universal binaries with MP, but you can't target an OS version other than the one you're running on. A universal package built on Tiger would likely work on Leopard as well, but not vice versa. - Josh From raimue at macports.org Wed Jul 15 16:27:09 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 16 Jul 2009 01:27:09 +0200 Subject: ocaml port updates In-Reply-To: References: <4A7BC281-83A4-429E-96C7-9566EF74BCB4@recoil.org> Message-ID: <4A5E65CD.1060806@macports.org> On 2009-07-14 06:58 , Anil Madhavapeddy wrote: > Can I get a macports account to put the new ports in or could someone > take a gander? I would like to see some maintainer for the various ocaml related ports. The main problem for other committers is to test or verify if the ports are doing everything "right" and work as expected. There are also a lot of other ocaml-* related submissions in Trac [1] pending for a long time. Please apply for MacPorts commit access as described in . Usually we require a track record of multiple Trac submissions and in best case also maintainership of some ports. In your case, I think you proved enough knowledge about Portfiles and MacPorts by maintaining your own parallel mirror of these ocaml ports. Rainer [1] http://trac.macports.org/query?status=assigned&status=new&status=reopened&summary=~ocaml-&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=port&order=priority From stechert at gmail.com Wed Jul 15 16:36:36 2009 From: stechert at gmail.com (Andre Stechert) Date: Wed, 15 Jul 2009 16:36:36 -0700 Subject: ocaml port updates In-Reply-To: <4A5E65CD.1060806@macports.org> References: <4A7BC281-83A4-429E-96C7-9566EF74BCB4@recoil.org> <4A5E65CD.1060806@macports.org> Message-ID: <12a697af0907151636n765a7e18h53e2aee80ba6c0a7@mail.gmail.com> Also: I think it's time to start putting caml ports in their own subdirectory. E.g., dports/php contains 25 php specific ports. devel/caml-* is up to 22 and there are some packages like cryptokit, that aren't, but probably should be, included in that number. Cheers, Andre On Wed, Jul 15, 2009 at 4:27 PM, Rainer M?ller wrote: > On 2009-07-14 06:58 , Anil Madhavapeddy wrote: >> Can I get a macports account to put the new ports in or could someone >> take a gander? > > I would like to see some maintainer for the various ocaml related ports. > The main problem for other committers is to test or verify if the ports > are doing everything "right" and work as expected. There are also a lot > of other ocaml-* related submissions in Trac [1] pending for a long time. > > Please apply for MacPorts commit access as described in > . Usually we require a > track record of multiple Trac submissions and in best case also > maintainership of some ports. In your case, I think you proved enough > knowledge about Portfiles and MacPorts by maintaining your own parallel > mirror of these ocaml ports. > > Rainer > > [1] > http://trac.macports.org/query?status=assigned&status=new&status=reopened&summary=~ocaml-&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=port&order=priority > _______________________________________________ > 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 Jul 15 17:50:48 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 15 Jul 2009 19:50:48 -0500 Subject: memtester port In-Reply-To: References: <160D9E56-2673-46CA-8D8E-D23F5E0C4D15@newgeo.com> <1FD7B072-1DFA-42F7-8269-2B900C9FF867@lavergne.gotdns.org> <0E053DFE-7699-47C3-A0D2-B4E0698BF8B0@newgeo.com> <824FFAC4-D217-46DF-8C9F-5EB06A8BEC1B@lavergne.gotdns.org> <6202FB01-7B42-4AEE-8FE9-9AFEFB0C6258@lavergne.gotdns.org> <9CF165AF-3ED6-46BB-945E-A574C77D41A2@newgeo.com> Message-ID: <4DB92DD8-EB31-49EB-82F2-91E09CEBE427@macports.org> On Jul 14, 2009, at 18:28, Scott Haneda wrote: > livecheck.regex "${name}-(\\d+(?:\\.\\d+)*)${extract.suffix}" On Jul 14, 2009, at 20:46, Jeremy Lavergne wrote: > On Jul 14, 2009, at 7:28 PM, Scott Haneda wrote: > >> Here is my final port, my areas of concern are the livecheck >> regex. That is a copy and paste from elsewhere, and I can not >> break it out. You have to escape regex inside livecheck? > > Yes, if you use quotations, you must use double escapes. If you use > braces, then only one escape is needed. Right. The first backslash escapes the next character from the Tcl interpreter. The second backslash escapes the next character from the regular expression interpreter. If you use a Tcl curlybrace-enclosed string instead of a doublequote-enclosed string, you don't use the extra level of escaping. >> So d+ is all numbers, that ?: is a mystery to me, and then a dot, >> and then a digit, and then aything. I have three distinct version >> digits, so there may be some altering that needs to happen here. >> Perhaps the * means, match the pattern of digit and dot as many >> times as it happens? > > The d is "one numeric digit or more." To be precise, "\d" is a single "digit 0 thru 9". "+" means "one or more of the preceding". So "\d+" is "one or more digits 0 thru 9". > The ?: basically means find the first one and stop -- saves on > speed and memory versus matching the whole line. No, "?:", when it is the first thing inside parentheses, means the parentheses only group but are not remembered as a backreference. It's pretty irrelevant in this case. Livecheck only makes use of the first remembered parentheses (which it uses as the version number) and any subsequent remembered parentheses are not used at all. > * means 0 or more (and finally ? means 0 or 1 -- that's ? + and * > quantifiers). Right. So all together, the remembered part for the version number is: (\d+(?:\.\d+)*) meaning: one or more digits, followed by zero or more period-followed- by-one-or-more-digits. The period has a backslash before it because otherwise it doesn't mean a period; it means "any character". I personally use the simpler (\[0-9.\]+) meaning: one or more digit-or-period. This period does not have a backslash before it because it is inside a character class (the square brackets). There are many ways to skin a cat with regular expressions. And there are many references that will teach you all about regular expressions, and I encourage you to find one and read all about them. They take a bit of getting used to but once you know the syntax they're very powerful. >> Any other suggestions before I ship it off to trac? > > Does it pass `port lint --nitpick memtester`? IMHO passing "port lint" is sufficient. "--nitpick" is, well, nit- picky, and I don't have a problem with ports not conforming to it. From ryandesign at macports.org Wed Jul 15 17:56:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 15 Jul 2009 19:56:02 -0500 Subject: ocaml port updates In-Reply-To: <12a697af0907151636n765a7e18h53e2aee80ba6c0a7@mail.gmail.com> References: <4A7BC281-83A4-429E-96C7-9566EF74BCB4@recoil.org> <4A5E65CD.1060806@macports.org> <12a697af0907151636n765a7e18h53e2aee80ba6c0a7@mail.gmail.com> Message-ID: On Jul 15, 2009, at 18:36, Andre Stechert wrote: > Also: I think it's time to start putting caml ports in their own > subdirectory. > > E.g., dports/php contains 25 php specific ports. > > devel/caml-* is up to 22 and there are some packages like cryptokit, > that aren't, but probably should be, included in that number. By all means. Do they build similarly enough that it might also be a good idea to create a portgroup for them? For example, most of them seem to need to use "ocamlfind printconf destdir" to find out where to install. Perhaps the way that's done could be standardized in a portgroup. From macsforever2000 at macports.org Thu Jul 16 10:23:45 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Thu, 16 Jul 2009 11:23:45 -0600 Subject: [MacPorts] #20267: freeradius-2.1.3 build failure In-Reply-To: <131115054391800214345508570722533431159-Webmail@me.com> References: <055.b0364d42c0f3e5be4f9f5a34c8e56cce@macports.org> <064.86b28eadee5aa17d862303b55c57f1e4@macports.org> <131115054391800214345508570722533431159-Webmail@me.com> Message-ID: On Jul 16, 2009, at 11:19 AM, Eduardo J Garcia wrote: > So how do I fix what the message says: > > "Error: Target org.macports.activate returned: Image error: /opt/ > local/bin/radclient is being used by the active openradius port. > Please deactivate this port first, or use 'port -f activate > freeradius' to force the activation. > Error: Status 1 encountered during processing." > > In other words how do I deactivate the port? sudo port deactivate openradius -Frank From jeremy at lavergne.gotdns.org Thu Jul 16 19:14:59 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 16 Jul 2009 22:14:59 -0400 Subject: [MacPorts] #20246: [PATCH] Update py25-coverage to 3.0.1 In-Reply-To: <1F4DE216-943C-40AD-8BA1-3FB4E4ECAC7B@mac.com> References: <054.34901491e1f7ae8bbd23f3d86722492e@macports.org> <063.bba13f45f28b7561b1967aeea341a67d@macports.org> <1F4DE216-943C-40AD-8BA1-3FB4E4ECAC7B@mac.com> Message-ID: <9ECFC18B-C20B-4136-8E5A-78DE9F732119@lavergne.gotdns.org> That shouldn't hurt until 1.8 is out. Yes we should fix it, but is setting subfolders to 644 helping? We might run two find commands to set the permissions: 755 everything and 644 non-directories. Or am I missing an obvious command? On Jul 16, 2009, at 10:08 PM, Ian Eure wrote: > The permissions in the source tarball are broken (0600), and > preserved when the package is installed, rendering it unusable to > non-root users. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Thu Jul 16 22:55:47 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 17 Jul 2009 00:55:47 -0500 Subject: macports website In-Reply-To: <4A5C6087.2000809@macports.org> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> Message-ID: <8E538330-8806-41A2-9D12-FDC264274A0E@macports.org> On Jul 14, 2009, at 05:40, Joshua Root wrote: > Wanting to support IE is the number one reason to use HTML rather than > XHTML. IE has never handled XHTML; if you serve it with the right MIME > type it can't display it and just downloads the file, and if you serve > it as text/html it parses it as invalid HTML. Do we care enough > about IE > to warrant any action? Well, I want our site to work on IE 6 and up, and on other browsers. As far as I know, our current XHTML 1.1 site meets this goal, so no action is necessary. From ryandesign at macports.org Thu Jul 16 22:57:16 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 17 Jul 2009 00:57:16 -0500 Subject: macports website In-Reply-To: <5F55C538-90A9-4731-9598-8BB5182F09FB@lavergne.gotdns.org> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> <4A5C64B1.2020700@macports.org> <5F55C538-90A9-4731-9598-8BB5182F09FB@lavergne.gotdns.org> Message-ID: <71ED276C-8B17-4763-87AF-7194C375FAA2@macports.org> On Jul 14, 2009, at 05:58, Jeremy Lavergne wrote: > I wonder, what were the advantages of going with XHTML to begin with? I haven't been terribly active in web development in some years, but when I was, XHTML was the new hotness and the recommended way to code websites. Perhaps Juan had the same background when he coded the current version of the site. (I believe it was Juan, yes?) From ryandesign at macports.org Thu Jul 16 23:00:32 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 17 Jul 2009 01:00:32 -0500 Subject: macports website In-Reply-To: <7A759652-0313-49DA-B763-C766308A4222@apple.com> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> <4A5C64B1.2020700@macports.org> <96A77103-271E-426B-9C89-A4F0327BA48F@apple.com> <4809057c0907140726gb3af326l2d61c246d679a784@mail.gmail.com> <7A759652-0313-49DA-B763-C766308A4222@apple.com> Message-ID: On Jul 14, 2009, at 09:50, William Siegrist wrote: > On Jul 14, 2009, at 7:26 AM, Kristofer Henriksson wrote: > >> It seems that some are simply opposed to XHTML. Is there a particular >> reason to dislike using it for the site? > > http://webkit.org/blog/68/understanding-html-xml-and-xhtml/ If you're suggesting that document as a basis for using HTML instead of XHTML, then I would want to see a newer document on the topic; that one is from September 2006 and the web changes rather quickly. From ryandesign at macports.org Thu Jul 16 23:14:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 17 Jul 2009 01:14:23 -0500 Subject: port upgrade In-Reply-To: References: <1B3ACE12-E5B2-4181-8B96-41AFBD525173@newgeo.com> <2EC92854-12EE-469A-91AB-89A24236EF76@macports.org> Message-ID: <349B6951-CCD5-4BC2-8500-D277AAB9E4A5@macports.org> On Jul 13, 2009, at 23:39, Scott Haneda wrote: > It seems there is a pretty strong desire to put config files into / > opt/local/etc or equivalent. I can see that being the case with > apache, or bind, and other software that generally works with that > in mind. Yes, config files generally go in ${prefix}/etc. Note that apache2 actually has its config files in the nonstandard location ${prefix}/ apache2/conf; I don't generally recommend creating new ports that ignore the ${prefix}/etc convention. A subdirectory of ${prefix}/etc would of course be fine, and appropriate if there are multiple config files. > ASSP is a self contained application, with files, that loosely can > be called config files. They can not be moved, that would require a > lot of patching to the ASSP software, and would imo, create > confusion to the end user. MacPorts is largely being used in this > case take take advantage of installing several p5's, the fact it > installs ASSP, is almost a nicety. > > I think the only way to explain this so I get it right, it to step > through it, bare with me on the length of this email... > > ASSP ends up living in /opt/local/var/ASSP/ > > Installed files: > assp.cfg > assp.cfg.defaults > assp.pl > docs/ > errors/ > files/ > images/ > logs/ > move2num.pl > notes/ > notspam/ > okmail/ > pb/ > quarantine/ > rebuildspamdb.pl > reports/ > spam/ > stat.pl > > assp.cfg needs to never be touched by ports once installed. Then don't copy it into ${destroot} in the destroot phase; copy it from assp.cfg.defaults directly into ${prefix}/wherever in the post- activate phase. > According to the docs, an update is to do the following: > - invalidptr.txt > - URIBLCCTLDS.txt > - nodelay.txt (merge) > - redre.txt > - ipnp.txt (merge) > - blockreportuser.txt > - validptr.txt > - bombre.txt (merge) > - whiteorg.txt (merge) > - strictspf.txt (merge) > - invalidhelo.txt > > So the non merge, are safe to replace, the merge are not. In these > cases, if I could simply let ports replace them, and as long as a > backup of the entire /opt/local/var/ASSP directory was made, I > would be happy with that and a UI message that said which files > needed to be merged. > > * By merge, they mean, append your changes to the file. I would > rather not get in the business of teaching ports how to merge those > files, and leave that to the user. > > There are some other cases, but understanding how to deal with > these should suffice. If I can rely on new files that were made > after assp was installed staying untouched, then the app generated, > and user generated data is safe. > > It looks to me, like I have a limited set of files I need to make > sure are not touched by ports. > > The idea of registering these files as .sample files, and asking > the user to change them, completely destroys the way that ASSP is > designed to work. I don't understand why; it's exactly the solution to your problem. In the destroot phase, don't install a nodelay.txt; instead, install a nodelay.txt.sample. Then, in post-activate, copy nodelay.txt.sample to nodelay.txt and tell the user about it. Or, if nodelay.txt already exists, tell the user to merge in changes from nodelay.txt.sample. See the php5 port for an example of this. (Well, I don't copy the file for the user, but I do tell them to either copy it or merge it depending on whether the file already exists or not.) > I would consider them more preferences, than config files, and with > any preference file, it will contain some defaults, be written to > by the user, and should not be messed with on uninstall of an app, > and only sometimes modified on upgrade, if a format changes. I don't see the distinction between a preference file and config files. Whatever you call it, they are files containing data unique to the user and should not be overwritten by MacPorts on upgrade. Therefore, don't register them to the port as part of the destroot. > Is destroot.keepdirs really only for directories, or can it be > applied to files as well? Yes, destroot.keepdirs is only for directories. It has no meaning for files. The destroot phase works as follows: First, MacPorts creates the ${destroot} directory and a bunch of empty directories inside it for the various places ports are likely to install files. Basically the entire hierarchy, such as ${prefix}/ bin, ${prefix}/include, ${prefix}/lib, ${prefix}/share/man, etc., is created for you, so that you don't have to make these directories manually in the destroot phase of every port. Next, the pre-destroot, destroot, and post-destroot phases run, during which your port is to put files into the right places within $ {destroot}. Finally, MacPorts removes any empty directories in ${destroot}. If there are directories you would like to keep, even though they are empty, you use destroot.keepdirs, in response to which MacPorts creates a .turd_${name} file in each directory. Thus, when MacPorts gets to the part where it removes empty directories, it will not remove these "kept" directories, because they are not empty, because they contain a file (the .turd_${name} file). > I think what I really want to do, is just unregister a list of > files form the port after the first time it is installed. Maybe > there is a way to trick ports into doing this by copying a file in > during a certain phase but just keeping the name the same? > I can only reiterate: if you put the file in the ${destroot} directory during the destroot phase, the file is registered to the port. If you don't want the file registered to the port, don't do that. From wsiegrist at apple.com Thu Jul 16 23:40:22 2009 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 16 Jul 2009 23:40:22 -0700 Subject: macports website In-Reply-To: References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> <4A5C64B1.2020700@macports.org> <96A77103-271E-426B-9C89-A4F0327BA48F@apple.com> <4809057c0907140726gb3af326l2d61c246d679a784@mail.gmail.com> <7A759652-0313-49DA-B763-C766308A4222@apple.com> Message-ID: <3F9227E9-2A1C-49A5-B2AF-8CF2BD7596B2@apple.com> On Jul 16, 2009, at 11:00 PM, Ryan Schmidt wrote: > > On Jul 14, 2009, at 09:50, William Siegrist wrote: > >> On Jul 14, 2009, at 7:26 AM, Kristofer Henriksson wrote: >> >>> It seems that some are simply opposed to XHTML. Is there a >>> particular >>> reason to dislike using it for the site? >> >> http://webkit.org/blog/68/understanding-html-xml-and-xhtml/ > > If you're suggesting that document as a basis for using HTML instead > of XHTML, then I would want to see a newer document on the topic; > that one is from September 2006 and the web changes rather quickly. > Ok, join #webkit on freenode and ask them for their current opinion. Or I can go bump the date on that blog post, whichever you prefer. :) Seriously, though, that is still their opinion on the matter, and they have some expertise in this area. -Bill From ryandesign at macports.org Fri Jul 17 01:27:07 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 17 Jul 2009 03:27:07 -0500 Subject: macports website In-Reply-To: <3F9227E9-2A1C-49A5-B2AF-8CF2BD7596B2@apple.com> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> <4A5C64B1.2020700@macports.org> <96A77103-271E-426B-9C89-A4F0327BA48F@apple.com> <4809057c0907140726gb3af326l2d61c246d679a784@mail.gmail.com> <7A759652-0313-49DA-B763-C766308A4222@apple.com> <3F9227E9-2A1C-49A5-B2AF-8CF2BD7596B2@apple.com> Message-ID: On Jul 17, 2009, at 01:40, William Siegrist wrote: > On Jul 16, 2009, at 11:00 PM, Ryan Schmidt wrote: > >> On Jul 14, 2009, at 09:50, William Siegrist wrote: >> >>> On Jul 14, 2009, at 7:26 AM, Kristofer Henriksson wrote: >>> >>>> It seems that some are simply opposed to XHTML. Is there a >>>> particular >>>> reason to dislike using it for the site? >>> >>> http://webkit.org/blog/68/understanding-html-xml-and-xhtml/ >> >> If you're suggesting that document as a basis for using HTML >> instead of XHTML, then I would want to see a newer document on the >> topic; that one is from September 2006 and the web changes rather >> quickly. > > Ok, join #webkit on freenode and ask them for their current > opinion. Or I can go bump the date on that blog post, whichever you > prefer. :) Seriously, though, that is still their opinion on the > matter, and they have some expertise in this area. Ok, that's good to know. I wouldn't expend energy converting our current site back to HTML 4.01 but we can keep it in mind for the next rewrite of the site (or use HTML 5 if the specification is finished by that time). I tentatively agree with those who were wary of using HTML 5 now, before the spec is finished. From raimue at macports.org Fri Jul 17 07:03:21 2009 From: raimue at macports.org (=?windows-1252?Q?Rainer_M=FCller?=) Date: Fri, 17 Jul 2009 16:03:21 +0200 Subject: GSOC09 MacPorts GUI In-Reply-To: <2bad8a110907071217x7b2881fex72a689040af084ce@mail.gmail.com> References: <2bad8a110907071217x7b2881fex72a689040af084ce@mail.gmail.com> Message-ID: <4A6084A9.2080705@macports.org> Hi Juan, first of all you are doing good on this so far. But I also have some comments and proposals: First of all, the initial loading of the port list takes a long time about 1-2 minutes for my installation. How is this list being retrieved? Could this be made faster? For example, instead of calling registry::installed on each port, call registry::installed once to get a list of all installed ports. Also there is the possibility to have ports installed which are no longer in the index. They can be found with port(1) using the 'obsolete' pseudo-port on trunk. I think those would not be shown at all in the current port list. Where did you get the icons for the toolbar from? We have to be careful about licenses when using icons from Apple. On 2009-07-07 21:17 , Juan Germ?n Casta?eda Echevarria wrote: > * Support for non-default MacPorts installation locations. (Via the > Preferences window) The whole thing crashes with a "Bus error" if I select a wrong path. It should fail more gracefully, please. > * Basic and Advanced Search (currently can only search by port name > and status, but this is easily extendible) After clearing the search field and removing the filter bar, the view is still filtered. It should show all ports again. > * Install, Uninstall, Upgrade port operations in background > * Sync and SelfUpdate in background Usually such operations require root privileges. I read the note that it does not work yet with such an install. But anyway, do you have plans how to handle that for a default /opt/local install? Additionally these MPProcesses seem not to be correctly terminated and are still around after closing MPGUI.app. > * Progress notifications and cancel command. I?m thinking in having > this as a activity window (Something like Safari?s downloads > window) and allow the user to queue port commands to perform then > sequentially. Currently no commands are indicating success or failure, I hope that will change with this :-) Rainer From juanger at ciencias.unam.mx Fri Jul 17 11:58:51 2009 From: juanger at ciencias.unam.mx (=?ISO-8859-1?Q?Juan_Germ=E1n_Casta=F1eda_Echevarria?=) Date: Fri, 17 Jul 2009 13:58:51 -0500 Subject: GSOC09 MacPorts GUI In-Reply-To: <4A6084A9.2080705@macports.org> References: <2bad8a110907071217x7b2881fex72a689040af084ce@mail.gmail.com> <4A6084A9.2080705@macports.org> Message-ID: <2bad8a110907171158v57e6d434ob17e087270dbe523@mail.gmail.com> Hi Rainer, Hi Juan, > > first of all you are doing good on this so far. But I also have some > comments and proposals: > > First of all, the initial loading of the port list takes a long time > about 1-2 minutes for my installation. How is this list being retrieved? > Could this be made faster? For example, instead of calling > registry::installed on each port, call registry::installed > once to get a list of all installed ports. > This is something that bugs me too, 1-2 minutes is far too long, in my computer it takes like 15 seconds but with a testing MacPorts installation, I think your numbers can be more real life. The framework gets the list roughly in this way: 1. performs a mportsearch with the regex ".+". 2. Transforms the returned list to a Cocoa NSDictionary. 3. Creates a MPPort object for each entry in the NSDictionary (i.e. one per port) 4. Iterates over the MPPort objects setting their state to Not Installed 5. performs a registry::installed to get the list of installed ports 6. Transforms the returned list to a Cocoa NSDictionary 7. Creates a MPReceipt 8. Iterates over the MPRecipt objects changing the corresponding MPPort object state (Installed, Active, Outdated). As you can see, It is a very complicated process and I haven't worked in make it faster. If anybody has some recommendation, I'll be glad to hear it. > Also there is the possibility to have ports installed which are no > longer in the index. They can be found with port(1) using the 'obsolete' > pseudo-port on trunk. I think those would not be shown at all in the > current port list. > I haven't thought of that, I think I can add it to my TODO and come with a solution. If I can get the list, It shouldn't be difficult to add. > > Where did you get the icons for the toolbar from? We have to be careful > about licenses when using icons from Apple. > I got them from the Pallet project. Maybe I should work in new Icons (but I'm not that good with using Illustrator nor Photoshop) > On 2009-07-07 21:17 , Juan Germ?n Casta?eda Echevarria wrote: > > * Support for non-default MacPorts installation locations. (Via the > > Preferences window) > > The whole thing crashes with a "Bus error" if I select a wrong path. It > should fail more gracefully, please. > Yes, It dies in the Framework. I am planing a solution to this maybe by looking if there are the necessary files in the directory or by catching errors in the Framework. > > > * Basic and Advanced Search (currently can only search by port name > > and status, but this is easily extendible) > > After clearing the search field and removing the filter bar, the view is > still filtered. It should show all ports again. > Oh, sorry, I think that is my fault as the filter bar uses cocoa bindings. Adding it to the TODO. > > > * Install, Uninstall, Upgrade port operations in background > > * Sync and SelfUpdate in background > > Usually such operations require root privileges. I read the note that it > does not work yet with such an install. But anyway, do you have plans > how to handle that for a default /opt/local install? > It should work as the framework can handle the need of root privileges automatically but currently I am changing some things in the framewok > > Additionally these MPProcesses seem not to be correctly terminated and > are still around after closing MPGUI.app. > Yes, that is someting that happened with MPActionTool but I have changed that. now the processes that perform port operations are in the framework and terminate after doing their work. > > > * Progress notifications and cancel command. I?m thinking in having > > this as a activity window (Something like Safari?s downloads > > window) and allow the user to queue port commands to perform then > > sequentially. > > Currently no commands are indicating success or failure, I hope that > will change with this :-) > Yes, this is something I'm currently working on. > > Rainer > Thanks a lot for your comments and feedback. I'd like to update the binary version each week to get feedback more easily in what I'm working. I'd included your comments in the TODO list in https://trac.macports.org/wiki/MacPortsGUI. I hope to fix some of the issues you found for the next binary version. -- 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 talklists at newgeo.com Fri Jul 17 12:01:08 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 17 Jul 2009 12:01:08 -0700 Subject: port upgrade In-Reply-To: <349B6951-CCD5-4BC2-8500-D277AAB9E4A5@macports.org> References: <1B3ACE12-E5B2-4181-8B96-41AFBD525173@newgeo.com> <2EC92854-12EE-469A-91AB-89A24236EF76@macports.org> <349B6951-CCD5-4BC2-8500-D277AAB9E4A5@macports.org> Message-ID: >> assp.cfg needs to never be touched by ports once installed. > > Then don't copy it into ${destroot} in the destroot phase; copy it > from assp.cfg.defaults directly into ${prefix}/wherever in the post- > activate phase. This is good to know, I was just not aware of this method. How do I set permissions when in this phase, I assume doing so with the ports commands will register it? >> According to the docs, an update is to do the following: >> - invalidptr.txt >> - URIBLCCTLDS.txt >> - nodelay.txt (merge) >> - redre.txt >> - ipnp.txt (merge) >> - blockreportuser.txt >> - validptr.txt >> - bombre.txt (merge) >> - whiteorg.txt (merge) >> - strictspf.txt (merge) >> - invalidhelo.txt >> >> So the non merge, are safe to replace, the merge are not. In these >> cases, if I could simply let ports replace them, and as long as a >> backup of the entire /opt/local/var/ASSP directory was made, I >> would be happy with that and a UI message that said which files >> needed to be merged. >> >> * By merge, they mean, append your changes to the file. I would >> rather not get in the business of teaching ports how to merge those >> files, and leave that to the user. >> >> There are some other cases, but understanding how to deal with >> these should suffice. If I can rely on new files that were made >> after assp was installed staying untouched, then the app generated, >> and user generated data is safe. >> >> It looks to me, like I have a limited set of files I need to make >> sure are not touched by ports. >> >> The idea of registering these files as .sample files, and asking >> the user to change them, completely destroys the way that ASSP is >> designed to work. > > I don't understand why; it's exactly the solution to your problem. > In the destroot phase, don't install a nodelay.txt; instead, install > a nodelay.txt.sample. Then, in post-activate, copy > nodelay.txt.sample to nodelay.txt and tell the user about it. Ahh, ok, I understand now. Can that copy of .sample to rename to real file name be avoided? Can I just copy it in as it is named and be done with it? I do not want .sample files hanging out in /etc in this case. Sorry about all this, I was just totally unaware this was even a possibility. > Or, if nodelay.txt already exists, tell the user to merge in changes > from nodelay.txt.sample. Of the files, some are to be merged, some are to be replaces. This is good actually, as it gives me a place to tell the users where the files are. Perfect. > See the php5 port for an example of this. (Well, I don't copy the > file for the user, but I do tell them to either copy it or merge it > depending on whether the file already exists or not.) Thanks, will look into that port. >> I would consider them more preferences, than config files, and with >> any preference file, it will contain some defaults, be written to >> by the user, and should not be messed with on uninstall of an app, >> and only sometimes modified on upgrade, if a format changes. > > I don't see the distinction between a preference file and config > files. Whatever you call it, they are files containing data unique > to the user and should not be overwritten by MacPorts on upgrade. > Therefore, don't register them to the port as part of the destroot. Understood. >> Is destroot.keepdirs really only for directories, or can it be >> applied to files as well? > > Yes, destroot.keepdirs is only for directories. It has no meaning > for files. > > The destroot phase works as follows: > > First, MacPorts creates the ${destroot} directory and a bunch of > empty directories inside it for the various places ports are likely > to install files. Basically the entire hierarchy, such as ${prefix}/ > bin, ${prefix}/include, ${prefix}/lib, ${prefix}/share/man, etc., is > created for you, so that you don't have to make these directories > manually in the destroot phase of every port. > > Next, the pre-destroot, destroot, and post-destroot phases run, > during which your port is to put files into the right places within $ > {destroot}. > > Finally, MacPorts removes any empty directories in ${destroot}. > > If there are directories you would like to keep, even though they > are empty, you use destroot.keepdirs, in response to which MacPorts > creates a .turd_${name} file in each directory. Thus, when MacPorts > gets to the part where it removes empty directories, it will not > remove these "kept" directories, because they are not empty, because > they contain a file (the .turd_${name} file). Does this ever become an issue with .DS files getting in there, and that would prevent proper ports operations? Or is it only .turd files that prevent the deletion of a dir? I know a real non leading dot file will prevent it, and I expect that, but a .* file other than .turd, how is that covered? >> I think what I really want to do, is just unregister a list of >> files form the port after the first time it is installed. Maybe >> there is a way to trick ports into doing this by copying a file in >> during a certain phase but just keeping the name the same? > > I can only reiterate: if you put the file in the ${destroot} > directory during the destroot phase, the file is registered to the > port. If you don't want the file registered to the port, don't do > that. Cool, thanks, this will work. http://dl.getdropbox.com/u/340087/Drops/07.17.09/Portfile-dea0db16-115619.txt $port lint ---> Verifying Portfile for ASSP Warning: Line 109 should say "use_configure no" instead of declaring an empty configure phase Is that a big deal? Will I have any issues with just following those instructions? I think I tried and it did not like the use_configure command. I will be installing my own custom launchd item, and not using ports for this. I have never done this, do I just make a dir called "files" and put whatever I want in there? I can reference it with {filesdir}? Thank you. -- Scott * If you contact me off list replace talklists@ with scott@ * From jmr at macports.org Fri Jul 17 12:49:22 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 18 Jul 2009 05:49:22 +1000 Subject: GSOC09 MacPorts GUI In-Reply-To: <2bad8a110907171158v57e6d434ob17e087270dbe523@mail.gmail.com> References: <2bad8a110907071217x7b2881fex72a689040af084ce@mail.gmail.com> <4A6084A9.2080705@macports.org> <2bad8a110907171158v57e6d434ob17e087270dbe523@mail.gmail.com> Message-ID: <4A60D5C2.8010900@macports.org> On 2009-7-18 04:58, Juan Germ?n Casta?eda Echevarria wrote: > The framework > gets the list roughly in this way: > > 1. performs a mportsearch with the regex ".+". > 2. Transforms the returned list to a Cocoa NSDictionary. > 3. Creates a MPPort object for each entry in the NSDictionary (i.e. > one per port) > 4. Iterates over the MPPort objects setting their state to Not Installed > 5. performs a registry::installed to get the list of installed ports > 6. Transforms the returned list to a Cocoa NSDictionary > 7. Creates a MPReceipt > 8. Iterates over the MPRecipt objects changing the corresponding > MPPort object state (Installed, Active, Outdated). > > As you can see, It is a very complicated process and I haven't worked in > make it faster. If anybody has some recommendation, I'll be glad to hear it. The macports API could do with a proc that just returns the list of all ports in the index, which should be faster than using mportsearch to do the same thing. The other place where a lot of time is probably being spent is registry::installed. Unfortunately the flat-file registry has performance issues that can't be addressed without switching to a new format (i.e. registry2.0). Make sure you profile and find out for certain where you should be focusing your optimisation efforts. > Also there is the possibility to have ports installed which are no > longer in the index. They can be found with port(1) using the 'obsolete' > pseudo-port on trunk. I think those would not be shown at all in the > current port list. > > > I haven't thought of that, I think I can add it to my TODO and come with > a solution. If I can get the list, It shouldn't be difficult to add. These will be in the list returned by registry::installed, so if you take the union of the two lists (taking into account that the full PortInfo won't be available for all ports) it should work as desired. - Josh From juanger at ciencias.unam.mx Fri Jul 17 14:25:34 2009 From: juanger at ciencias.unam.mx (=?ISO-8859-1?Q?Juan_Germ=E1n_Casta=F1eda_Echevarria?=) Date: Fri, 17 Jul 2009 16:25:34 -0500 Subject: GSOC09 MacPorts GUI In-Reply-To: <4A60D5C2.8010900@macports.org> References: <2bad8a110907071217x7b2881fex72a689040af084ce@mail.gmail.com> <4A6084A9.2080705@macports.org> <2bad8a110907171158v57e6d434ob17e087270dbe523@mail.gmail.com> <4A60D5C2.8010900@macports.org> Message-ID: <2bad8a110907171425s6bab3de5g56b3f26b9e128149@mail.gmail.com> > > The macports API could do with a proc that just returns the list of all > ports in the index, which should be faster than using mportsearch to do > the same thing. The other place where a lot of time is probably being > spent is registry::installed. Unfortunately the flat-file registry has > performance issues that can't be addressed without switching to a new > format (i.e. registry2.0). > > Make sure you profile and find out for certain where you should be > focusing your optimisation efforts. > - Josh > In fact, I also want to add more helper functions to the macports API which are now implemented in a separate tcl file inside the MacPorts framework and since neither I nor my mentor know too much of Tcl or the MacPorts base source code I was wondering If any other mentor will be willing to review my tcl code. I think the time is being spent in registry::installed because I meaured the time in my computer and it takes 4 seconds in a new installation (with 7 ports) and 7 seconds in my installation in which I have 130 ports installed. Can anyone tell me how much it takes in his installations? Thanks for your comments Josh! -- 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 jeremy at lavergne.gotdns.org Fri Jul 17 14:37:09 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 17 Jul 2009 17:37:09 -0400 Subject: [MacPorts] #20246: [PATCH] Update py25-coverage to 3.0.1 In-Reply-To: <60FEDC6E-E09D-4183-A81B-1830979FD4EF@mac.com> References: <054.34901491e1f7ae8bbd23f3d86722492e@macports.org> <063.bba13f45f28b7561b1967aeea341a67d@macports.org> <1F4DE216-943C-40AD-8BA1-3FB4E4ECAC7B@mac.com> <9ECFC18B-C20B-4136-8E5A-78DE9F732119@lavergne.gotdns.org> <60FEDC6E-E09D-4183-A81B-1830979FD4EF@mac.com> Message-ID: How about tar's --no-same-permissions? On Jul 17, 2009, at 5:34 PM, Ian Eure wrote: > Though this still may not DTRT, since some files in the tarball may > need to be executable. > > I guess you could also download the .zip instead. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From vincent-opdarw at vinc17.org Fri Jul 17 14:41:33 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Fri, 17 Jul 2009 23:41:33 +0200 Subject: macports website In-Reply-To: <4809057c0907141313w2418829ew66cd55f07bb9a545@mail.gmail.com> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> <4A5C64B1.2020700@macports.org> <96A77103-271E-426B-9C89-A4F0327BA48F@apple.com> <4809057c0907140726gb3af326l2d61c246d679a784@mail.gmail.com> <06CD71F1-DDFA-4D28-9BE2-81AF89A7989E@lavergne.gotdns.org> <4809057c0907141313w2418829ew66cd55f07bb9a545@mail.gmail.com> Message-ID: <20090717214133.GD7995@xvii> On 2009-07-14 16:13:46 -0400, Kristofer Henriksson wrote: > As a side note, such divergent error handling makes it a shame that > there is no debug-type option for error handling to be set in > browsers, with XHTML-style failure when debugging is enabled and > silent HTML-style perseverance when disabled. One problem is that Firefox does not fix HTML errors in the "right" way (by "right" way, I mean: not expected by the web site developers), and when I look at a badly-written site with Firefox, it's not obvious that there's something wrong, or the cause of a problem can be difficult to track (because the developer uses a different browser and may not see the problem). At least, with XHTML-style failure, one can clearly see that there's a problem and one can fix it. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From vincent-opdarw at vinc17.org Fri Jul 17 14:21:31 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Fri, 17 Jul 2009 23:21:31 +0200 Subject: macports website In-Reply-To: <5F55C538-90A9-4731-9598-8BB5182F09FB@lavergne.gotdns.org> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> <4A5C64B1.2020700@macports.org> <5F55C538-90A9-4731-9598-8BB5182F09FB@lavergne.gotdns.org> Message-ID: <20090717212131.GC7995@xvii> On 2009-07-14 06:58:50 -0400, Jeremy Lavergne wrote: > Future work? I wonder, what were the advantages of going with XHTML > to begin with? One can use XML tools on it. I sometimes do that on the bug database to see if I haven't missed anything and so on. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From juanger at ciencias.unam.mx Fri Jul 17 16:43:46 2009 From: juanger at ciencias.unam.mx (=?ISO-8859-1?Q?Juan_Germ=E1n_Casta=F1eda_Echevarria?=) Date: Fri, 17 Jul 2009 18:43:46 -0500 Subject: GSOC09 MacPorts GUI In-Reply-To: <2bad8a110907171425s6bab3de5g56b3f26b9e128149@mail.gmail.com> References: <2bad8a110907071217x7b2881fex72a689040af084ce@mail.gmail.com> <4A6084A9.2080705@macports.org> <2bad8a110907171158v57e6d434ob17e087270dbe523@mail.gmail.com> <4A60D5C2.8010900@macports.org> <2bad8a110907171425s6bab3de5g56b3f26b9e128149@mail.gmail.com> Message-ID: <2bad8a110907171643l58214d2di7a36978b3f6cddcf@mail.gmail.com> Hi everyone, I've been doing some profiling and I found that the most time consuming part of the initialization is the registry:installed proc. http://www.screencast.com/users/juanger/folders/Jing/media/cc7278af-385a-461e-8a4f-e4ef440cce58 What could I do with that problem? I still need to add some helper methods to the macports API though but I don't know if registry2.0 is usable right now. Thanks! -- 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 mta at umich.edu Fri Jul 17 20:36:15 2009 From: mta at umich.edu (Mike Alexander) Date: Fri, 17 Jul 2009 23:36:15 -0400 Subject: Uninstall not updating state file Message-ID: Using macports from SVN version r53993, which is pretty much up to date, I get an error if I do port uninstall foo port install foo where foo is any installed port. The error is Error: Target org.macports.activate returned: Registry error: foo x.y.z_w not registered as installed. This correct, but irrelevant. The problem is that the line "target: org.macports.install" is not being removed from the .macports.foo.state file by uninstall. Did this ever work? I think I remember it working at some time in the past, but I can't find any place in the macports source where it tries to remove that line, either in r53993 or r51337 which is the last version I used much. Does anyone have any idea where to look for the bug? -- Mike Alexander mta at umich.edu Ann Arbor, MI PGP key ID: BEA343A6 From ryandesign at macports.org Fri Jul 17 21:57:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 17 Jul 2009 23:57:29 -0500 Subject: Uninstall not updating state file In-Reply-To: References: Message-ID: On Jul 17, 2009, at 22:36, Mike Alexander wrote: > Using macports from SVN version r53993, which is pretty much up to > date, I get an error if I do > > port uninstall foo > port install foo > > where foo is any installed port. The error is > > Error: Target org.macports.activate returned: Registry error: foo > x.y.z_w not registered as installed. > > This correct, but irrelevant. The problem is that the line > "target: org.macports.install" is not being removed from > the .macports.foo.state file by uninstall. Did this ever work? I > think I remember it working at some time in the past, but I can't > find any place in the macports source where it tries to remove that > line, either in r53993 or r51337 which is the last version I used > much. Does anyone have any idea where to look for the bug? I'm not sure yet that there is a bug -- unless this reproducibly happens every time with every port. I didn't think "port uninstall" was supposed to do anything with the state file. If you want the state file gone, you "port clean" the port. Usually this happens automatically after install. Did you have a failed install of this port before? Or do you have autoclean turned off in macports.conf? From raimue at macports.org Sat Jul 18 06:06:34 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 18 Jul 2009 15:06:34 +0200 Subject: Uninstall not updating state file In-Reply-To: References: Message-ID: <4A61C8DA.5070007@macports.org> On 2009-07-18 05:36 , Mike Alexander wrote: > Using macports from SVN version r53993, which is pretty much up to > date, I get an error if I do > > port uninstall foo > port install foo > > where foo is any installed port. The error is > > Error: Target org.macports.activate returned: Registry error: foo > x.y.z_w not registered as installed. To reproduce this you either have to set "portautoclean no" in macports.conf or use 'port -k' so that the work directory is not being removed. > This correct, but irrelevant. The problem is that the line "target: > org.macports.install" is not being removed from the .macports.foo.state > file by uninstall. Did this ever work? I think I remember it working > at some time in the past, but I can't find any place in the macports > source where it tries to remove that line, either in r53993 or r51337 > which is the last version I used much. Does anyone have any idea where > to look for the bug? Indeed, this is a bug. It does work as expected with 1.7, but not on trunk. Thanks for the report. The problem is that no phase gets removed from the state file at all, just the next phase will be appended at the end. In 1.7 the install phase is not recorded to the state file. On trunk it will get recorded, introduced by me in r49491 [1]. My reasoning was that install has to match previously selected variants, otherwise you can get unexpected results. For example: port destroot port install +foo That would result in a normal build, but install with different variants although they have not been compiled in. So we have to check that the variants passed to install match the variants previously used. There has been another very old bug in the variants compare code which I just fixed in r54002 [2]. Probably we need an exception in the code that install should not be recorded although it needs state checking for variants? Rainer [1] http://trac.macports.org/changeset/49491 [2] http://trac.macports.org/changeset/54002 From mta at umich.edu Sat Jul 18 20:27:14 2009 From: mta at umich.edu (Mike Alexander) Date: Sat, 18 Jul 2009 23:27:14 -0400 Subject: Uninstall not updating state file In-Reply-To: <4A61C8DA.5070007@macports.org> References: <4A61C8DA.5070007@macports.org> Message-ID: <8EA2004EF961069A05EB02A7@fitzrovia.msalexander.com> --On July 18, 2009 3:06:34 PM +0200 Rainer M?ller wrote: > To reproduce this you either have to set "portautoclean no" in > macports.conf or use 'port -k' so that the work directory is not being > removed. > Yes, I have that option set in macports.conf. I like to be able to look at the results of a build if things go wrong later. I should have mentioned that in the bug report, but it's been so long since I set that option I forgot it was there. Mike From ryandesign at macports.org Sun Jul 19 00:26:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 19 Jul 2009 02:26:03 -0500 Subject: port upgrade In-Reply-To: References: <1B3ACE12-E5B2-4181-8B96-41AFBD525173@newgeo.com> <2EC92854-12EE-469A-91AB-89A24236EF76@macports.org> <349B6951-CCD5-4BC2-8500-D277AAB9E4A5@macports.org> Message-ID: <2688818E-036F-406F-983D-B66618F7818B@macports.org> On Jul 17, 2009, at 14:01, Scott Haneda wrote: >>> assp.cfg needs to never be touched by ports once installed. >> >> Then don't copy it into ${destroot} in the destroot phase; copy it >> from assp.cfg.defaults directly into ${prefix}/wherever in the >> post-activate phase. > > This is good to know, I was just not aware of this method. How do > I set permissions when in this phase, I assume doing so with the > ports commands will register it? The tcl equivalent of the command line's "chmod" command is the "file attributes" command. There are several ports that use this so I would grep through the portfiles to find an example to follow. >>> The idea of registering these files as .sample files, and asking >>> the user to change them, completely destroys the way that ASSP is >>> designed to work. >> >> I don't understand why; it's exactly the solution to your problem. >> In the destroot phase, don't install a nodelay.txt; instead, >> install a nodelay.txt.sample. Then, in post-activate, copy >> nodelay.txt.sample to nodelay.txt and tell the user about it. > > Ahh, ok, I understand now. Can that copy of .sample to rename to > real file name be avoided? Can I just copy it in as it is named > and be done with it? I do not want .sample files hanging out in / > etc in this case. > > Sorry about all this, I was just totally unaware this was even a > possibility. You're doing it already in your port: if {![file exists ${assp_base}/assp.cfg]} { file copy ${assp_base}/assp.cfg.defaults \ ${assp_base}/assp.cfg I now recall the discussion weeks ago on the list wherein this bit was added to the port. So in the above code, the assp base directory will contain both assp.cfg.defaults (which is registered to the port and which the user does not modify but which serves as documentation for the user as to what the defaults are), and assp.cfg (which the assp software actually uses and which the user modifies as needed). Why is it a problem to have .sample files in /etc or anywhere? >> If there are directories you would like to keep, even though they >> are empty, you use destroot.keepdirs, in response to which >> MacPorts creates a .turd_${name} file in each directory. Thus, >> when MacPorts gets to the part where it removes empty directories, >> it will not remove these "kept" directories, because they are not >> empty, because they contain a file (the .turd_${name} file). > > Does this ever become an issue with .DS files getting in there, and > that would prevent proper ports operations? Or is it only .turd > files that prevent the deletion of a dir? I know a real non > leading dot file will prevent it, and I expect that, but a .* file > other than .turd, how is that covered? As I said, the destroot cleanup code removes empty directories anywhere in the destroot directory. If a directory contains any file of any name, the directory will not be removed. So there's nothing special about the .turd name. A file by any other name would have the same effect. .DS_Store files get created when you do certain operations on a directory in the Finder. Since nobody is browsing the destroot directory in the Finder while the destroot phase is running, .DS_Store files won't get created in there and won't be a problem. If you do manage to create .DS_Store files in the destroot directory, you can cause problems. To test this, I just modified the zlib port to sleep for a minute in post-destroot, to give me a chance to fiddle with the destroot directory in the Finder. I changed to list view and played with the width of the columns to create a .DS_Store file. After the 60-second timeout, MacPorts told me about the mtree violation caused by the .DS_Store file. ---> Fetching zlib ---> Verifying checksum(s) for zlib ---> Extracting zlib ---> Applying patches to zlib ---> Configuring zlib ---> Building zlib ---> Staging zlib into destroot sleep 60 Warning: violation by /.DS_Store Warning: zlib violates the layout of the ports-filesystems! Warning: Please fix or indicate this misbehavior (if it is intended), it will be an error in future releases! If I fiddled with a subdirectory, I could create a .DS_Store file in a subdirectory, for example in /Applications or /usr. If I did such fiddling with multiple ports, the second port would complain on activation that it could not copy the .DS_Store in place because it already existed and was registered to the first port. So, don't fiddle with the destroot directory in the Finder while the destroot phase is running and you won't cause the problem. :) > http://dl.getdropbox.com/u/340087/Drops/07.17.09/Portfile- > dea0db16-115619.txt > $port lint > ---> Verifying Portfile for ASSP > Warning: Line 109 should say "use_configure no" instead of > declaring an empty configure phase > > Is that a big deal? Will I have any issues with just following > those instructions? I think I tried and it did not like the > use_configure command. Line 109 says "configure {}". You should use "use_configure no" instead of "configure {}" as lint says. Your portfile already says "use_configure no" on line 41 so you can just delete line 109 completely. > I will be installing my own custom launchd item, and not using > ports for this. I have never done this, do I just make a dir > called "files" and put whatever I want in there? I can reference it > with {filesdir}? Sure, that would work. From blb at macports.org Sun Jul 19 13:41:54 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 19 Jul 2009 14:41:54 -0600 Subject: [54029] users/kimuraw/rb-gnome/README In-Reply-To: <20090719095619.C1BD32115D3A@beta.macosforge.org> References: <20090719095619.C1BD32115D3A@beta.macosforge.org> Message-ID: <20090719204154.GG42887@ninagal.withay.com> On Sun, Jul 19, 2009 at 02:56:19AM -0700, ryandesign at macports.org said: > Revision: 54029 > http://trac.macports.org/changeset/54029 > Author: ryandesign at macports.org > Date: 2009-07-19 02:56:19 -0700 (Sun, 19 Jul 2009) > Log Message: > ----------- > fix typos > > Modified Paths: > -------------- > users/kimuraw/rb-gnome/README Any particular reason why you're editing stuff in others' /users tree? Bryan [...] From ryandesign at macports.org Sun Jul 19 23:00:21 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 20 Jul 2009 01:00:21 -0500 Subject: [54045] trunk/dports/devel In-Reply-To: <20090719191409.EE3CD2118939@beta.macosforge.org> References: <20090719191409.EE3CD2118939@beta.macosforge.org> Message-ID: <492B6E81-B10B-49C9-8DAC-36B9C7836C21@macports.org> On Jul 19, 2009, at 14:14, jameskyle at macports.org wrote: > Revision: 54045 > http://trac.macports.org/changeset/54045 > Author: jameskyle at macports.org > Date: 2009-07-19 12:14:08 -0700 (Sun, 19 Jul 2009) > Log Message: > ----------- > Provides drivers and development files for activewire board. Just a few comments: > +maintainers I see you already fixed this; thanks. All ports must list a maintainer listed. If nobody wants to maintain the port, you can put "nomaintainer". > +use_bzip2 no No need for this line; that's already the default. > +extract.suffix .dmg > +extract { > + file mkdir /tmp/${distname} > + system "hdiutil attach ${distpath}/${distname}.dmg -private - > nobrowse -mountpoint /tmp/${distname}" > + > + file mkdir ${workpath}/${distname} > + file copy /tmp/${distname}/Documentation ${workpath}/${distname} > + file copy /tmp/${distname}/Examples ${workpath}/${distname} > + file copy /tmp/${distname}/Source ${workpath}/${distname} > + file copy /tmp/${distname}/LICENSE.txt ${workpath}/${distname} > + > + system "hdiutil detach /tmp/${distname}" > +} I added the option "use_dmg yes" to MacPorts 1.7.0 so that you wouldn't have to do all that yourself -- though I see it doesn't work if you change the worksrcdir like you do. I will have to file a bug about that. "use_dmg yes" also doesn't work if you're not root. I'll file a bug about that too. > +pre-configure { > + foreach {i} {libaw awdriver awconfig} { > + 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" > + > + } > +} With the patch from #15514 I get: Warning: reinplace s|/usr/share/man/man1/|/mp/include|g didn't change anything in /mp/var/macports/build/ _Users_rschmidt_macports_dports_devel_activewire/work/aw_4.0/Source/ libaw/libaw.xcodeproj/project.pbxproj Warning: reinplace s|/usr/local|/mp|g didn't change anything in /mp/ var/macports/build/_Users_rschmidt_macports_dports_devel_activewire/ work/aw_4.0/Source/awdriver/awdriver.xcodeproj/project.pbxproj Warning: reinplace s|/usr/local|/mp|g didn't change anything in /mp/ var/macports/build/_Users_rschmidt_macports_dports_devel_activewire/ work/aw_4.0/Source/awconfig/awconfig.xcodeproj/project.pbxproj So you may want to change this to pre-configure { reinplace "s|/usr/local|${prefix}|g" ${worksrcpath}/awconfig/ awconfig.xcodeproj/project.pbxproj reinplace "s|/usr/share/man/man1/|${prefix}/include|g" $ {worksrcpath}/libaw/libaw.xcodeproj/project.pbxproj ${worksrcpath}/ awdriver/awdriver.xcodeproj/project.pbxproj } Actually, I'm pretty sure it's incorrect to replace "/usr/share/man/ man1" with "${prefix}/include". Replacing it with "${prefix}/share/ man/man1" is more likely, no? > +proc xcode::get_build_args {args} { > + global tcl_platform > + global universal_archs universal_target macosx_deployment_target > + global os.major os.arch > + global developer_dir > + > + set xcode_build_args "OBJROOT=build/ SYMROOT=build/" > + > + # MACOSX_DEPLOYMENT_TARGET > + if {[variant_isset universal] && [info exists > universal_target]} { > + append xcode_build_args " MACOSX_DEPLOYMENT_TARGET=$ > {universal_target}" > + } else { > + append xcode_build_args " MACOSX_DEPLOYMENT_TARGET=$ > {macosx_deployment_target}" > + } > + > + # ARCHS > + if {[variant_isset universal]} { > + append xcode_build_args " ARCHS=\"${universal_archs}\"" > + } else { > + if {${os.major} >= 10 && $tcl_platform(wordSize) == 8} { > + append xcode_build_args " ARCHS=x86_64" > + } elseif {${os.arch} == "powerpc"} { > + append xcode_build_args " ARCHS=ppc" > + } else { > + append xcode_build_args " ARCHS=i386" > + } > + } > + > + # SDKROOT > + if {[variant_isset universal] && ${os.arch} == "powerpc" && $ > {os.major} == "8"} { > + if {[info exists developer_dir]} { > + append xcode_build_args " SDKROOT=\"${developer_dir}/ > SDKs/MacOSX10.4u.sdk\"" > + } else { > + append xcode_build_args " SDKROOT=\"/Developer/SDKs/ > MacOSX10.4u.sdk\"" > + } > + } > + return $xcode_build_args > +} What was the idea behind overriding this portgroup function? It looks like you made only a 1-line change from r53725 of the portgroup, but the portgroup has changed since then. > +destroot { > + xinstall -m 755 -d ${destroot}${prefix}/bin > + xinstall -m 755 -d ${destroot}${prefix}/lib You don't need to make those directories because MacPorts does it for you. From ryandesign at macports.org Sun Jul 19 23:04:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 20 Jul 2009 01:04:02 -0500 Subject: [54050] trunk/dports/python In-Reply-To: <20090719210852.035AA211A32C@beta.macosforge.org> References: <20090719210852.035AA211A32C@beta.macosforge.org> Message-ID: <5F082656-020C-4A75-B543-2866E22519F2@macports.org> On Jul 19, 2009, at 16:08, jameskyle at macports.org wrote: > Revision: 54050 > http://trac.macports.org/changeset/54050 > Author: jameskyle at macports.org > Date: 2009-07-19 14:08:51 -0700 (Sun, 19 Jul 2009) > Log Message: > ----------- > Provides the Python Experimental Programming Library. > Includes support for ActiveWire cards. > Added: trunk/dports/python/py26-pyepl/Portfile > =================================================================== > --- trunk/dports/python/py26-pyepl/Portfile > (rev 0) > +++ trunk/dports/python/py26-pyepl/Portfile 2009-07-19 21:08:51 UTC > (rev 54050) > +worksrcdir pyepl-${version} > +extract.suffix tgz > +distfiles ${worksrcdir}.${extract.suffix} extract.suffix generally begins with a period, and worksrcdir and distfiles are both based on distname, so the most concise way to express the above is: distname pyepl-${version} extract.suffix .tgz Then you don't need to set worksrcdir or distfiles. From raimue at macports.org Mon Jul 20 16:48:07 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Tue, 21 Jul 2009 01:48:07 +0200 Subject: New committers: aecollins1, singingwolfboy, mnick Message-ID: <4A650237.3030705@macports.org> Please join us in welcoming the following new MacPorts committers: - Anthony Collins (aecollins1) - David Baumgold (singingwolfboy) - Maximilian Nickel (mnick) 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 jmpp at macports.org Tue Jul 21 07:38:00 2009 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue, 21 Jul 2009 10:08:00 -0430 Subject: macports website In-Reply-To: <71ED276C-8B17-4763-87AF-7194C375FAA2@macports.org> References: <09894555-C237-4D50-A278-077690F75F2B@lavergne.gotdns.org> <4A5C6087.2000809@macports.org> <435172BE-2F78-4E87-B211-2DAD895FE57A@lavergne.gotdns.org> <4A5C64B1.2020700@macports.org> <5F55C538-90A9-4731-9598-8BB5182F09FB@lavergne.gotdns.org> <71ED276C-8B17-4763-87AF-7194C375FAA2@macports.org> Message-ID: <8182BED9-E4AF-47FB-8611-149417AAE17A@macports.org> On Jul 17, 2009, at 1:27 AM, Ryan Schmidt wrote: > > On Jul 14, 2009, at 05:58, Jeremy Lavergne wrote: > >> I wonder, what were the advantages of going with XHTML to begin with? > > I haven't been terribly active in web development in some years, but > when I was, XHTML was the new hotness and the recommended way to > code websites. Perhaps Juan had the same background when he coded > the current version of the site. (I believe it was Juan, yes?) > Yes, it was me who coded the "new" website back some years ago. And yes, that's my precise background and that's why I chose xhtml over html. Looking back, though, I do admit it was most probably a mistake to go for 1.1 rather than just 1.0 or maybe even 1.0 transitional, but it's been so long that I don't remember why I made that particular decision (could have been an innocent copy & paste operation, a Dreamweaver preset, gremlins, who knows). So, if the site now works even on IE 6 (thanks to Ryan's work!), I don't see what the point is in changing the doctype for the sole sake of cross-browser compatibility (IE 6? what more can you ask for??? ;). I would say, lets safe that energy for another facelift & revamp of the entire site, even I find my work to be showing its age pretty bad already, that design is so Safari 1.0 days! Regards,... - jmpp PS: I need not say, we can of course use a different, more appropriate doctype if a complete redesign is carried out ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Tue Jul 21 14:16:06 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 21 Jul 2009 16:16:06 -0500 Subject: [54124] trunk/dports/graphics/tiff/Portfile In-Reply-To: <20090721181939.7B747214748B@beta.macosforge.org> References: <20090721181939.7B747214748B@beta.macosforge.org> Message-ID: On Jul 21, 2009, at 13:19, toby at macports.org wrote: > Revision: 54124 > http://trac.macports.org/changeset/54124 > Author: toby at macports.org > Date: 2009-07-21 11:19:39 -0700 (Tue, 21 Jul 2009) > Log Message: > ----------- > remove faulty Xcode version check (#20382) I reverted this change in r54132. I had deliberately added this code 4 months ago; see #18801 [1]. Do not remove code others have deliberately added to portfiles without discussing the issue first. Do not modify maintained ports without giving the maintainer 72 hours to respond to the issue. The maintainer probably never even saw this ticket since it wasn't assigned to him and he was not Cc'd. If the maintainer timeout policy is too restrictive we can discuss whether it needs to be changed. Perhaps we need to add exemptions for certain kinds of changes. The reason I reverted your change is that this check is in over a dozen other ports too and we need a fix that addresses all ports, not just tiff. I would like for the fix to be that a more advanced Xcode version check (taking into account alternate Xcode install locations) is done by MacPorts base; see #12794 [2]. Until such a time as that is done, we need the code in each portfile, because despite your statement in #20382 [3] that users should know that they need the latest Xcode, they demonstrably do not know this. Most of the Xcode version checks currently in portfiles were added because users reported that something did not work, and the reason was their Xcode was too old. To prevent other users from having this issue in the future, the Xcode version check was added to the ports. The Xcode version check in these ports is not "faulty"; it merely does not accommodate nonstandard Xcode install locations. To my knowledge, MacPorts has never supported nonstandard Xcode install locations to date, so I think the correct resolution to #20382 for now is to tell the user to install Xcode in the standard location. Or if we can come up with new code that uses xcode-select when available and add that to all the ports that currently check Xcode versions, that could be a solution too. [1] http://trac.macports.org/ticket/18801 [2] http://trac.macports.org/ticket/12794 [3] http://trac.macports.org/ticket/20382 From blb at macports.org Tue Jul 21 19:09:52 2009 From: blb at macports.org (Bryan Blackburn) Date: Tue, 21 Jul 2009 20:09:52 -0600 Subject: [54124] trunk/dports/graphics/tiff/Portfile In-Reply-To: References: <20090721181939.7B747214748B@beta.macosforge.org> Message-ID: <20090722020952.GI16057@ninagal.withay.com> On Tue, Jul 21, 2009 at 04:16:06PM -0500, Ryan Schmidt said: [...] > > I reverted this change in r54132. I had deliberately added this code > 4 months ago; see #18801 [1]. > > Do not remove code others have deliberately added to portfiles > without discussing the issue first. > > Do not modify maintained ports without giving the maintainer 72 hours > to respond to the issue. The maintainer probably never even saw this > ticket since it wasn't assigned to him and he was not Cc'd. If the > maintainer timeout policy is too restrictive we can discuss whether > it needs to be changed. Perhaps we need to add exemptions for certain > kinds of changes. Note that the port was broken for installs of Xcode outside of /Developer, so changing without maintainer approval makes sense if that's all that's being touched. > > The reason I reverted your change is that this check is in over a > dozen other ports too and we need a fix that addresses all ports, not > just tiff. I would like for the fix to be that a more advanced Xcode > version check (taking into account alternate Xcode install locations) > is done by MacPorts base; see #12794 [2]. Until such a time as that > is done, we need the code in each portfile, because despite your > statement in #20382 [3] that users should know that they need the > latest Xcode, they demonstrably do not know this. Most of the Xcode > version checks currently in portfiles were added because users > reported that something did not work, and the reason was their Xcode > was too old. To prevent other users from having this issue in the > future, the Xcode version check was added to the ports. This is probably abusing port groups some, but can we move the check to one so we don't have all this code repeated in these "over a dozen other ports" until the check can be done within base instead? > > The Xcode version check in these ports is not "faulty"; it merely > does not accommodate nonstandard Xcode install locations. To my > knowledge, MacPorts has never supported nonstandard Xcode install > locations to date, so I think the correct resolution to #20382 for > now is to tell the user to install Xcode in the standard location. Or > if we can come up with new code that uses xcode-select when available > and add that to all the ports that currently check Xcode versions, > that could be a solution too. As far as I know, as long as Xcode is installed with the Unix development environment (or whatever that setting is called) which puts the stuff in /usr, MacPorts shouldn't care whether Xcode is installed in /Developer, /Volumes/Someplace/Developer, or elsewhere. Or are there other references to /Developer beyond this Xcode version check? The new developer_dir variable (on trunk) is set to that location by default, but it can be set in macports.conf (and long-term probably should be set using xcode-select). Bryan > > > [1] http://trac.macports.org/ticket/18801 > > [2] http://trac.macports.org/ticket/12794 > > [3] http://trac.macports.org/ticket/20382 From ryandesign at macports.org Tue Jul 21 20:12:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 21 Jul 2009 22:12:28 -0500 Subject: [54029] users/kimuraw/rb-gnome/README In-Reply-To: <20090719204154.GG42887@ninagal.withay.com> References: <20090719095619.C1BD32115D3A@beta.macosforge.org> <20090719204154.GG42887@ninagal.withay.com> Message-ID: <5BEA6457-A1C5-4CB7-869B-6E7EC95CE3DE@macports.org> On Jul 19, 2009, at 15:41, Bryan Blackburn wrote: > On Sun, Jul 19, 2009 at 02:56:19AM -0700, ryandesign at macports.org > said: > >> Revision: 54029 >> http://trac.macports.org/changeset/54029 >> Author: ryandesign at macports.org >> Date: 2009-07-19 02:56:19 -0700 (Sun, 19 Jul 2009) >> Log Message: >> ----------- >> fix typos >> >> Modified Paths: >> -------------- >> users/kimuraw/rb-gnome/README > > Any particular reason why you're editing stuff in others' /users tree? I didn't mean to step on any toes. I reviewed the commit, as I try to review all commits, and saw some obvious errors -- spelling mistakes, and files with "$Id$" header lines but without the svn:keywords property. I could have pointed this out or sent a patch, but I didn't feel there was a strong likelihood that these typos and omissions had been intentional so I went ahead and fixed them. I wouldn't want to rewrite someone else's code in their user directory, but I felt fixing obvious errors would be ok. Even if the code is currently in a user directory, it is still in the MacPorts repository and so part of the MacPorts project and is presumably destined for inclusion in MacPorts in the future, and the sooner we can fix errors in MacPorts the better. From nox at macports.org Wed Jul 22 05:39:54 2009 From: nox at macports.org (nox) Date: Wed, 22 Jul 2009 14:39:54 +0200 Subject: [53541] trunk/dports/devel/icu In-Reply-To: <20090708001113.4B60B200E8DF@beta.macosforge.org> References: <20090708001113.4B60B200E8DF@beta.macosforge.org> Message-ID: <8AA2F3EF-258A-47FC-B5D3-845F4C50CD6D@macports.org> Mmh. Why did you patch runConfigureICU? Le 8 juil. 09 ? 02:11, takanori at macports.org a ?crit : > Revision53541Authortakanori at macports.orgDate2009-07-07 17:11:10 > -0700 (Tue, 07 Jul 2009)Log Message > icu: version bump to 4.2.1 > Modified Paths > ? trunk/dports/devel/icu/Portfile > Added Paths > ? trunk/dports/devel/icu/files/ > ? trunk/dports/devel/icu/files/patch-source_runConfigureICU.diff > Diff > Modified: trunk/dports/devel/icu/Portfile (53540 => 53541) > > --- trunk/dports/devel/icu/Portfile 2009-07-07 21:53:10 UTC (rev > 53540) > +++ trunk/dports/devel/icu/Portfile 2009-07-08 00:11:10 UTC (rev > 53541) > @@ -5,10 +5,8 @@ > > name icu > set my_name icu4c > -version 4.0 > -revision 1 > -set doc_version [join [lrange [split ${version} .] 0 1] _] > -categories devel > +version 4.2.1 > +categories devel textproc > platforms darwin freebsd > maintainers nox openmaintainer > description International Components for Unicode > @@ -20,21 +18,21 @@ > support for supplementary Unicode characters (needed for GB > 18030 repertoire support). > > homepage http://www.icu-project.org/ > -master_sites http://download.icu-project.org/files/${my_name}/$ > {version}/ \ > - sourceforge > +master_sites http://download.icu-project.org/files/${my_name}/$ > {version}/ > > distname ${my_name}-[join [split ${version} .] _] > extract.suffix .tgz > distfiles [suffix ${distname}-src] > +patchfiles patch-source_runConfigureICU.diff > > -checksums icu4c-4_0-src.tgz \ > - md5 29ab09d84b72a74953cbb4d3d5759e14 \ > - sha1 ff1d3fa084d2dff140f6b5f53dc1566fdb5ebb17 \ > - rmd160 c80dc50b9177b60a0191ea095c4c1c3360d2c6f4 \ > - icu4c-4_0-docs.zip \ > - md5 32781fab60b60ab69cf7a6fbe4ee303a \ > - sha1 9a7c0a0c63adf02fb156b076d76acaa7dc59a15b \ > - rmd160 ce81012d86ff609b443b710f822f107d629a75ed > +checksums ${distname}-src.tgz \ > + md5 e3738abd0d3ce1870dc1fd1f22bba5b1 \ > + sha1 872a77fca51325ab0b335cbbadc1739576078434 \ > + rmd160 1b94317a117c40d564ec047cff9cb2de2de3bd9e \ > + ${distname}-docs.zip \ > + md5 abad0bb5d1869ba908718d6900468377 \ > + sha1 703760245543aa64fa92084d77bba4f019bab0ae \ > + rmd160 0ef1c2ef6f649924fa9ee603a48ae664965b0eec > > worksrcdir ${name}/source > set docdir ${prefix}/share/doc/${name}-${version} > @@ -50,16 +48,6 @@ > --enable-static \ > --disable-samples > > -# ICU wants to build with -O3, let's do as it wants. > -configure.cflags-delete -O2 > - > -pre-configure { > - # The -delete statement above may lead to configure.cflags > variable being unset > - if {! [info exists configure.cflags]} { > - configure.cflags > - } > -} > - > # Fix bug #11981 that prevents ICU from building when upgrading. > # The default configure flags causes utilisation of outdated ICU > # headers/libs instead of the right ones. > @@ -84,10 +72,10 @@ > > variant doc description {Install extra documentation} { > extract.only [suffix ${distname}-src] > - distfiles-append ${my_name}-${doc_version}-docs.zip > + distfiles-append ${distname}-docs.zip > > post-extract { > - system "unzip -q ${distpath}/${my_name}-${doc_version}- > docs.zip -d ${workpath}/doc" > + system "unzip -q ${distpath}/${distname}-docs.zip -d $ > {workpath}/doc" > } > > post-destroot { > @@ -100,4 +88,5 @@ > destroot.env MAKE=/usr/local/bin/gmake > } > > -livecheck.distname ICU4C > +livecheck.name internationalcomponentsforunicodecc > +livecheck.regex "(?i)International Components for Unicode \\ > (C/C\\+\\+\\) (.*)" > \ No newline at end of file > Added: trunk/dports/devel/icu/files/patch- > source_runConfigureICU.diff (0 => 53541) > > --- trunk/dports/devel/icu/files/patch- > source_runConfigureICU.diff (rev 0) > +++ trunk/dports/devel/icu/files/patch-source_runConfigureICU.diff > 2009-07-08 00:11:10 UTC (rev 53541) > @@ -0,0 +1,11 @@ > +--- ./runConfigureICU.orig 2009-07-02 03:51:26.000000000 +0900 > ++++ ./runConfigureICU 2009-07-08 02:12:40.000000000 +0900 > +@@ -250,8 +250,6 @@ > + MacOSX) > + THE_OS="MacOS X (Darwin)" > + THE_COMP="the GNU C++" > +- RELEASE_CFLAGS='-O2' > +- RELEASE_CXXFLAGS='-O2' > + ;; > + *BSD) > + THE_OS="BSD" > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes From ryandesign at macports.org Wed Jul 22 13:41:57 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 22 Jul 2009 15:41:57 -0500 Subject: [54124] trunk/dports/graphics/tiff/Portfile In-Reply-To: <20090722020952.GI16057@ninagal.withay.com> References: <20090721181939.7B747214748B@beta.macosforge.org> <20090722020952.GI16057@ninagal.withay.com> Message-ID: On Jul 21, 2009, at 21:09, Bryan Blackburn wrote: > On Tue, Jul 21, 2009 at 04:16:06PM -0500, Ryan Schmidt said: > [...] >> >> I reverted this change in r54132. I had deliberately added this code >> 4 months ago; see #18801 [1]. >> >> Do not remove code others have deliberately added to portfiles >> without discussing the issue first. >> >> Do not modify maintained ports without giving the maintainer 72 hours >> to respond to the issue. The maintainer probably never even saw this >> ticket since it wasn't assigned to him and he was not Cc'd. If the >> maintainer timeout policy is too restrictive we can discuss whether >> it needs to be changed. Perhaps we need to add exemptions for certain >> kinds of changes. > > Note that the port was broken for installs of Xcode outside of / > Developer, > so changing without maintainer approval makes sense if that's all > that's > being touched. I had thought MacPorts had never worked with Xcode outside of / Developer. Also, our current documentation does not list this as a reason to allow non-maintainer updates. We should allow more non- maintainer updates; I'll open a new thread about this. >> The reason I reverted your change is that this check is in over a >> dozen other ports too and we need a fix that addresses all ports, not >> just tiff. I would like for the fix to be that a more advanced Xcode >> version check (taking into account alternate Xcode install locations) >> is done by MacPorts base; see #12794 [2]. Until such a time as that >> is done, we need the code in each portfile, because despite your >> statement in #20382 [3] that users should know that they need the >> latest Xcode, they demonstrably do not know this. Most of the Xcode >> version checks currently in portfiles were added because users >> reported that something did not work, and the reason was their Xcode >> was too old. To prevent other users from having this issue in the >> future, the Xcode version check was added to the ports. > > This is probably abusing port groups some, but can we move the > check to one > so we don't have all this code repeated in these "over a dozen > other ports" > until the check can be done within base instead? That could be possible. I will look into it. >> The Xcode version check in these ports is not "faulty"; it merely >> does not accommodate nonstandard Xcode install locations. To my >> knowledge, MacPorts has never supported nonstandard Xcode install >> locations to date, so I think the correct resolution to #20382 for >> now is to tell the user to install Xcode in the standard location. Or >> if we can come up with new code that uses xcode-select when available >> and add that to all the ports that currently check Xcode versions, >> that could be a solution too. > > As far as I know, as long as Xcode is installed with the Unix > development > environment (or whatever that setting is called) which puts the > stuff in > /usr, MacPorts shouldn't care whether Xcode is installed in / > Developer, > /Volumes/Someplace/Developer, or elsewhere. Or are there other > references to /Developer beyond this Xcode version check? The new > developer_dir variable (on trunk) is set to that location by > default, but > it can be set in macports.conf (and long-term probably should be > set using > xcode-select). I was thinking of the fact that developer_dir was just added to trunk. I don't know what all it's used for. I was also thinking of the universal SDKs. But in 1.7.x I suppose the user can specify the path to those in macports.conf, and in trunk that's been removed and the SDK is only used on Tiger PPC, which doesn't need developer_dir since Xcode can't be relocated on Tiger. From ryandesign at macports.org Wed Jul 22 13:57:30 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 22 Jul 2009 15:57:30 -0500 Subject: Allowing more non-maintainer updates Message-ID: The Non-Maintainer Port Updates section of the guide lists conditions when we may update ports that have a maintainer: http://guide.macports.org/#project.update-policies.nonmaintainer The existing conditions are: * The maintainer does not respond within 72 hours * A port is abandoned by its current maintainer * A critical port is broken that affects many users There are some conditions I would like to add to these: * Required port variable missing (e.g. platforms or long_description) * Syntax error * Spelling or grammar error in comments, descriptions, etc. * Hardcoded /opt/local * Forgot to bump revision or epoch after change that requires it * No $Id$ tag * No svn:keywords or svn:eol-style properties * Build fix for pre-release Mac OS X version * Removing code for very old versions of Mac OS X (I would currently limit this to Jaguar and earlier; once MacPorts 1.8.0 is released, make this Panther and earlier) * Removing code for ports which will be deleted (e.g. removing mysql3 variants since I want to remove mysql3 port) Thoughts? Additions? I'm thinking about whether we should also allow changes which simplify ports, e.g. if a port sets distfiles and worksrcdir but this could be changed to just set distname, or if a port uses "system" to call some utility but the same could be achieved with a Tcl command, or if a port overrides a phase but the same could be accomplished by setting phase variables. But I'm not sure how to word it so as not to be too ambiguous. I might also want to allow changes which implement common MacPorts idioms, e.g. defining and using a ${branch} variable. From jeremy at lavergne.gotdns.org Wed Jul 22 14:30:58 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 22 Jul 2009 17:30:58 -0400 Subject: Allowing more non-maintainer updates In-Reply-To: References: Message-ID: <8965CA8E-2832-4CF4-BD0F-FEC97D17817B@lavergne.gotdns.org> I like the idea. How about we add removing changes that were rolled back previously that were accidentally/blindly reinstated? adding comments? We might consider expanding the "hardcoded" section to include other items, such as moving ports off of about-to-be abandoned packages (e.g., python24) or changes to base (e.g., `default parallel_build yes`). We might also consider upgrading PortGroups, if that day ever comes to pass. On Jul 22, 2009, at 4:57 PM, Ryan Schmidt wrote: > The Non-Maintainer Port Updates section of the guide lists > conditions when we may update ports that have a maintainer: > > http://guide.macports.org/#project.update-policies.nonmaintainer > > The existing conditions are: > > * The maintainer does not respond within 72 hours > * A port is abandoned by its current maintainer > * A critical port is broken that affects many users > > There are some conditions I would like to add to these: > > * Required port variable missing (e.g. platforms or long_description) > * Syntax error > * Spelling or grammar error in comments, descriptions, etc. > * Hardcoded /opt/local > * Forgot to bump revision or epoch after change that requires it > * No $Id$ tag > * No svn:keywords or svn:eol-style properties > * Build fix for pre-release Mac OS X version > * Removing code for very old versions of Mac OS X (I would currently > limit this to Jaguar and earlier; once MacPorts 1.8.0 is released, > make this Panther and earlier) > * Removing code for ports which will be deleted (e.g. removing > mysql3 variants since I want to remove mysql3 port) > > Thoughts? Additions? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From blb at macports.org Wed Jul 22 14:34:59 2009 From: blb at macports.org (Bryan Blackburn) Date: Wed, 22 Jul 2009 15:34:59 -0600 Subject: Allowing more non-maintainer updates In-Reply-To: References: Message-ID: <20090722213459.GE23655@ninagal.withay.com> On Wed, Jul 22, 2009 at 03:57:30PM -0500, Ryan Schmidt said: > The Non-Maintainer Port Updates section of the guide lists conditions > when we may update ports that have a maintainer: > > http://guide.macports.org/#project.update-policies.nonmaintainer > > The existing conditions are: > > * The maintainer does not respond within 72 hours > * A port is abandoned by its current maintainer > * A critical port is broken that affects many users > > There are some conditions I would like to add to these: The NewCommittersGuide page documents such things to some degree: > > * Required port variable missing (e.g. platforms or long_description) If required, I'd technically call that broken. > * Syntax error If it causes something like PortIndex to fail, again, broken. > * Spelling or grammar error in comments, descriptions, etc. That's pretty cosmetic, so definitely not broken, not sure this would really be a big deal unless it makes things like 'port search' not find proper ports. > * Hardcoded /opt/local Again, broken. > * Forgot to bump revision or epoch after change that requires it I'd call that broken as well. > * No $Id$ tag > * No svn:keywords or svn:eol-style properties Hmm, policy failures but the port should be working; I'd say for non-committer maintainers, perhaps go ahead and change it... > * Build fix for pre-release Mac OS X version Broken, just for that platform, so anything outside making that work would be off limits. > * Removing code for very old versions of Mac OS X (I would currently > limit this to Jaguar and earlier; once MacPorts 1.8.0 is released, > make this Panther and earlier) To avoid any possible confusion (eg, seeing that there's a platform variant for something and thinking that means it will work) this makes sense to remove. > * Removing code for ports which will be deleted (e.g. removing mysql3 > variants since I want to remove mysql3 port) Removal would then cause those ports referencing it to be broken. > > Thoughts? Additions? These policies have been listed on the NewCommittersGuide page for ages so perhaps they should be moved to the guide? There hasn't been a huge amount of changes to it lately, so it may be safe (after the above updates). > > I'm thinking about whether we should also allow changes which > simplify ports, e.g. if a port sets distfiles and worksrcdir but this > could be changed to just set distname, or if a port uses "system" to > call some utility but the same could be achieved with a Tcl command, > or if a port overrides a phase but the same could be accomplished by > setting phase variables. But I'm not sure how to word it so as not to > be too ambiguous. I'd call that making the Portfile more efficient, since it technically works but could work better. Some of these would be obvious (system install changed to use xinstall, for example) but others may end up being somewhat subjective. Many cases simply tend to be lack of awareness of what all can be used in a Portfile, so I'd guess that many would welcome the improvement on the port. > > I might also want to allow changes which implement common MacPorts > idioms, e.g. defining and using a ${branch} variable. Or perhaps any of the various bits on the PortfileRecipes wiki page? Bryan From blb at macports.org Wed Jul 22 14:45:03 2009 From: blb at macports.org (Bryan Blackburn) Date: Wed, 22 Jul 2009 15:45:03 -0600 Subject: [54124] trunk/dports/graphics/tiff/Portfile In-Reply-To: References: <20090721181939.7B747214748B@beta.macosforge.org> <20090722020952.GI16057@ninagal.withay.com> Message-ID: <20090722214503.GF23655@ninagal.withay.com> On Wed, Jul 22, 2009 at 03:41:57PM -0500, Ryan Schmidt said: > On Jul 21, 2009, at 21:09, Bryan Blackburn wrote: [...] > >Note that the port was broken for installs of Xcode outside of / > >Developer, > >so changing without maintainer approval makes sense if that's all > >that's > >being touched. > > I had thought MacPorts had never worked with Xcode outside of / > Developer. Also, our current documentation does not list this as a > reason to allow non-maintainer updates. We should allow more non- > maintainer updates; I'll open a new thread about this. For the most part, all we really care about is what's in /usr so Xcode's specific install location hasn't really matter (and of course, until 2.5, it couldn't be easily changed anyway). Other than the Xcode version checks, I'm not aware of much that needs to know where it is located, since the *nix-level tools are in /usr as well as xcodebuild. [...] > > I was thinking of the fact that developer_dir was just added to > trunk. I don't know what all it's used for. I believe the plan is to be able to abstract out the specific location so we can support various locations of Xcode (which would probably be good for anyone with multiple versions installed as well). > > I was also thinking of the universal SDKs. But in 1.7.x I suppose the > user can specify the path to those in macports.conf, and in trunk > that's been removed and the SDK is only used on Tiger PPC, which > doesn't need developer_dir since Xcode can't be relocated on Tiger. Note that the SDKs are technically not for universal (except as you note, on 10.4/PPC) but are for targetting a certain OS version. I'd really like to see any and all use of the SDKs removed since the official MacPorts policy is that we don't support cross-platform development. And further to that, I'd also really like to see +universal removed completely until it can be done more cleanly, since that definitely seems to be a major cause of tickets & support issues. Things like keeping track of actual build archs instead of just noting +universal would be a necessity if we really want it to work; we currently just say "you need to make sure everything is built the same" but that'd be better done by port. Though I'm guessing we're going to need to revamp the registry first in order to properly store these settings... Bryan From ryandesign at macports.org Wed Jul 22 19:59:00 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 22 Jul 2009 21:59:00 -0500 Subject: [54124] trunk/dports/graphics/tiff/Portfile In-Reply-To: <20090722214503.GF23655@ninagal.withay.com> References: <20090721181939.7B747214748B@beta.macosforge.org> <20090722020952.GI16057@ninagal.withay.com> <20090722214503.GF23655@ninagal.withay.com> Message-ID: <22204C6F-CC7F-4F6A-B008-F78C7D125BF4@macports.org> On Jul 22, 2009, at 16:45, Bryan Blackburn wrote: > On Wed, Jul 22, 2009 at 03:41:57PM -0500, Ryan Schmidt said: >> On Jul 21, 2009, at 21:09, Bryan Blackburn wrote: >>> Note that the port was broken for installs of Xcode outside of / >>> Developer, so changing without maintainer approval makes >>> sense if that's all that's being touched. >> >> I had thought MacPorts had never worked with Xcode outside of / >> Developer. Also, our current documentation does not list this as a >> reason to allow non-maintainer updates. We should allow more non- >> maintainer updates; I'll open a new thread about this. > > For the most part, all we really care about is what's in /usr so > Xcode's > specific install location hasn't really matter (and of course, > until 2.5, it > couldn't be easily changed anyway). Other than the Xcode version > checks, > I'm not aware of much that needs to know where it is located, since > the > *nix-level tools are in /usr as well as xcodebuild. > >> I was thinking of the fact that developer_dir was just added to >> trunk. I don't know what all it's used for. > > I believe the plan is to be able to abstract out the specific > location so we > can support various locations of Xcode (which would probably be > good for > anyone with multiple versions installed as well). So are you saying we want to be able to access the *nix-level tools within the Xcode install location instead of within /usr? >> I was also thinking of the universal SDKs. But in 1.7.x I suppose the >> user can specify the path to those in macports.conf, and in trunk >> that's been removed and the SDK is only used on Tiger PPC, which >> doesn't need developer_dir since Xcode can't be relocated on Tiger. > > Note that the SDKs are technically not for universal (except as you > note, on > 10.4/PPC) but are for targetting a certain OS version. I'd really > like to > see any and all use of the SDKs removed since the official MacPorts > policy is that we don't support cross-platform development. For some meaning of the word "support", we have been supporting the universal variant with i386 ppc for some time, which counts as cross- compiling. Admittedly it often doesn't work. > And further to > that, I'd also really like to see +universal removed completely > until it can > be done more cleanly, since that definitely seems to be a major > cause of > tickets & support issues. Things like keeping track of actual > build archs > instead of just noting +universal would be a necessity if we really > want it > to work; we currently just say "you need to make sure everything is > built > the same" but that'd be better done by port. > > Though I'm guessing we're going to need to revamp the registry > first in > order to properly store these settings... While I'm not happy with our universal support yet, removing it would limit a user to choosing either all 32-bit or all 64-bit software. Since build_arch was only just added to MacPorts trunk, and Snow Leopard, which is the first version to build 64-bit by default, is not released yet, I doubt the majority of ports have been tested for 64-bit compatibility, so I bet we have some ports that don't build 64- bit. (wine springs to mind, last time I checked.) Many people have so far been using universal as a way to get 64-bit, setting universal_archs to i386 x86_64. For ports that cannot build 64-bit, you simply don't install it universal, and it builds 32-bit, using the 32-bit part of its dependencies. If we remove universal, you would either choose 64-bit software and then not use those 32-bit- only ports at all (since the dependencies would be 64-bit only), or you use only 32-bit software. That seems worse than what we have now, which lets the user use 64-bit for the ports where it's possible and 32-bit for those where it's not. From ryandesign at macports.org Thu Jul 23 00:49:00 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 23 Jul 2009 02:49:00 -0500 Subject: [54124] trunk/dports/graphics/tiff/Portfile In-Reply-To: References: <20090721181939.7B747214748B@beta.macosforge.org> <20090722020952.GI16057@ninagal.withay.com> Message-ID: On Jul 22, 2009, at 15:41, Ryan Schmidt wrote: >> This is probably abusing port groups some, but can we move the >> check to one >> so we don't have all this code repeated in these "over a dozen >> other ports" >> until the check can be done within base instead? > > That could be possible. I will look into it. How's this? http://trac.macports.org/ticket/20408 I don't think the code that reads MacPorts trunk's developer_dir variable is right. It doesn't seem to be using the value I put in macports.conf. I also haven't tested on Leopard. From jmr at macports.org Thu Jul 23 07:24:37 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 24 Jul 2009 00:24:37 +1000 Subject: Allowing more non-maintainer updates In-Reply-To: References: Message-ID: <4A6872A5.8070602@macports.org> On 2009-7-23 06:57, Ryan Schmidt wrote: > The Non-Maintainer Port Updates section of the guide lists conditions > when we may update ports that have a maintainer: > > http://guide.macports.org/#project.update-policies.nonmaintainer > > The existing conditions are: > > * The maintainer does not respond within 72 hours > * A port is abandoned by its current maintainer > * A critical port is broken that affects many users > > There are some conditions I would like to add to these: [...] Maintainership was never meant to stop other people from fixing things, so we should indeed make this clear in the docs. All the things you list are valid reasons for others to fix a port. However, I would tend to agree with Bryan that perhaps amending the third bullet point above to "A port is obviously broken" might be more succinct. - Josh From mnick at macports.org Thu Jul 23 11:02:48 2009 From: mnick at macports.org (Maximilian Nickel) Date: Thu, 23 Jul 2009 20:02:48 +0200 Subject: Vim MacPorts support Message-ID: <7bad5d350907231102gceb7d5fsc81431415a478679@mail.gmail.com> Hi everyone, i've started work on MacPorts support for Vim. Right now it consists of syntax coloring for Portfiles, lint support and autoloading stuff. Syntax coloring is still in early stages, down to the configure phase most stuff should work though. Lint support is implemented through Vim's compiler. Running :make when editing a Portfile will run port lint on it. If there are errors a quickfix window will open and display them. As port lint doesn't report line numbers for errors right now, there is no support for directly jumping to the errorneous lines yet. Anyway, if you want to check it out, you can get the source with "svn co?https://svn.macports.org/repository/macports/users/mnick/macports.vim" Just copy everything in that directory into your ~/.vim directory and you should be set I've not yet decided how to exactly color the syntax, so if you have suggestions i'd be happy to hear them, along with any other suggestions. Cheers, Max From raimue at macports.org Thu Jul 23 11:51:17 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Thu, 23 Jul 2009 20:51:17 +0200 Subject: Vim MacPorts support In-Reply-To: <7bad5d350907231102gceb7d5fsc81431415a478679@mail.gmail.com> References: <7bad5d350907231102gceb7d5fsc81431415a478679@mail.gmail.com> Message-ID: <4A68B125.9050104@macports.org> On 2009-07-23 20:02 , Maximilian Nickel wrote: > i've started work on MacPorts support for Vim. Right now it consists > of syntax coloring for Portfiles, lint support and autoloading stuff. > Syntax coloring is still in early stages, down to the configure phase > most stuff should work though. Very nice, Max! While being the maintainer of vim, I never got around to work on a syntax file, so I appreciate your efforts. > Lint support is implemented through Vim's compiler. Running :make when > editing a Portfile will run port lint on it. If there are errors a > quickfix window will open and display them. As port lint doesn't > report line numbers for errors right now, there is no support for > directly jumping to the errorneous lines yet. We could either always print line numbers or add a --line-numbers switch to port lint. But note that some messages lint reports are about missing statements or variables. What should the format be like if there is no line number to print? > Anyway, if you want to check it out, you can get the source with "svn > co https://svn.macports.org/repository/macports/users/mnick/macports.vim" > Just copy everything in that directory into your ~/.vim directory and > you should be set Are we allowed to also make changes? :-) I suggest to move that to contrib/, as there is also already a language module for BBEdit/TextWrangler. Would probably make sense to move these into contrib/editors/ to keep some logical grouping. User directories are the private area in the repo and I don't like editing there. > I've not yet decided how to exactly color the syntax, so if you have > suggestions i'd be happy to hear them, along with any other > suggestions. Some phases and common options are missing yet (tests.* and livecheck.*). But do we really want to list each and every port option or would it be enough to color anything that starts with the name of a phase followed by a dot (${phase}.*), depends_*, use_* and the usual port options like name, version, maintainer, etc.? Rainer From mnick at macports.org Thu Jul 23 12:19:31 2009 From: mnick at macports.org (Maximilian Nickel) Date: Thu, 23 Jul 2009 21:19:31 +0200 Subject: Fwd: Vim MacPorts support In-Reply-To: <7bad5d350907231218l6ed1fc37nfbfec94242d83716@mail.gmail.com> References: <7bad5d350907231102gceb7d5fsc81431415a478679@mail.gmail.com> <4A68B125.9050104@macports.org> <7bad5d350907231218l6ed1fc37nfbfec94242d83716@mail.gmail.com> Message-ID: <7bad5d350907231219w869f1b6j7fa764fdc843166e@mail.gmail.com> Fwding since i forgot to press reply all.... ---------- Forwarded message ---------- From: Maximilian Nickel Date: Thu, Jul 23, 2009 at 9:18 PM Subject: Re: Vim MacPorts support To: Rainer M?ller Rainer M?ller wrote: > We could either always print line numbers or add a --line-numbers switch > to port lint. Both options are fine for me. Some statements in lint already print linenumbers btw, just the errors and warning are missing it. > But note that some messages lint reports are about missing statements or > variables. What should the format be like if there is no line number to > print? It's ok if some messages don't report linenumbers. vim's errorformat accepts multiple formats, so we can just supply a parse-string for both and let vim do the rest. >> Anyway, if you want to check it out, you can get the source with "svn >> co https://svn.macports.org/repository/macports/users/mnick/macports.vim" >> Just copy everything in that directory into your ~/.vim directory and >> you should be set > > Are we allowed to also make changes? :-) Sure, go ahead :) > I suggest to move that to contrib/, as there is also already a language > module for BBEdit/TextWrangler. Would probably make sense to move these > into contrib/editors/ to keep some logical grouping. User directories > are the private area in the repo and I don't like editing there. Fine for me, i just thought the best starting point would be my user dir >> I've not yet decided how to exactly color the syntax, so if you have >> suggestions i'd be happy to hear them, along with any other >> suggestions. > > Some phases and common options are missing yet (tests.* and livecheck.*). Yes i didnt get around to add them yet. I didnt find a way to automatically create some of the regex's (like -append/delete), as vim's only accepts something like syn match "some_string" and not something like syn match fun("some_string"), so it's a lot of manual work. > But do we really want to list each and every port option or would it be > enough to color anything that starts with the name of a phase followed > by a dot (${phase}.*), depends_*, use_* and the usual port options like > name, version, maintainer, etc.? Yes, i started with that too. I switched to the more precise coloring since i see syntax coloring also as an easy way to avoid typo's. And typos can and, in some cases, are even more likely to occur in the * part. We could just color for example depends_ but this looks awkward imo. And coloring the whole depends_* string even when it's not correct syntax seemed wrong to me too. I will not be able to work on this much the next days, so just apply the changes you feel are necessary if you like. Cheers, Max P.S. For those using snipMate (http://www.vim.org/scripts/script.php?script_id=2540). Some other thing i'd like to add is snippets support. Something like new will create a Portfile skeleton in the buffer. variant creates a variant skeleton etc. From talklists at newgeo.com Thu Jul 23 12:43:32 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 23 Jul 2009 12:43:32 -0700 Subject: livecheck Message-ID: <7FB41248-7A0E-4896-ACC2-C732A90D4570@newgeo.com> Hello, I worked on the memtest port a while back. I was talking with the author the other day and after he saw the port, he notices the livecheck option. His concern was that of course, it downloads the entire page, and uses regex to parse out the important bits. He was willing to create a current-version.txt file that he maintains, as he was worried about bandwidth. I see this as a semi valid concern. But I also do not see it as a lot different than a user going to a Web site and manually checking the version in a browser. What are fellow port developers opinions on this matter? I am not aware of any scheduled and routine hits that live check is going to make, it is a on user demand feature. If I have this incorrect, please let me know, as I do feel it is important to play nice to the developers of software for which ports are made. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Thu Jul 23 13:01:39 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 23 Jul 2009 15:01:39 -0500 Subject: livecheck In-Reply-To: <7FB41248-7A0E-4896-ACC2-C732A90D4570@newgeo.com> References: <7FB41248-7A0E-4896-ACC2-C732A90D4570@newgeo.com> Message-ID: On Jul 23, 2009, at 14:43, Scott Haneda wrote: > Hello, I worked on the memtest port a while back. I was talking > with the author the other day and after he saw the port, he notices > the livecheck option. > > His concern was that of course, it downloads the entire page, and > uses regex to parse out the important bits. He was willing to > create a current-version.txt file that he maintains, as he was > worried about bandwidth. > > I see this as a semi valid concern. But I also do not see it as a > lot different than a user going to a Web site and manually checking > the version in a browser. > > What are fellow port developers opinions on this matter? I am not > aware of any scheduled and routine hits that live check is going to > make, it is a on user demand feature. > > If I have this incorrect, please let me know, as I do feel it is > important to play nice to the developers of software for which > ports are made. True, livecheck will only be used when a user types "port livecheck". Most often this would only be the port maintainer. For example I run livecheck on the ports I maintain to see if I have to update any of them. I try to write my livechecks to use the smallest web page available that will answer the question. I wish more developers provided a current-version.txt or something like that. It sure would save on bandwidth and make things faster. From raimue at macports.org Thu Jul 23 13:05:27 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 23 Jul 2009 22:05:27 +0200 Subject: livecheck In-Reply-To: <7FB41248-7A0E-4896-ACC2-C732A90D4570@newgeo.com> References: <7FB41248-7A0E-4896-ACC2-C732A90D4570@newgeo.com> Message-ID: <4A68C287.6050803@macports.org> On 2009-07-23 21:43 , Scott Haneda wrote: > His concern was that of course, it downloads the entire page, and uses > regex to parse out the important bits. He was willing to create a > current-version.txt file that he maintains, as he was worried about > bandwidth. > I see this as a semi valid concern. But I also do not see it as a lot > different than a user going to a Web site and manually checking the > version in a browser. Traffic for livecheck is even lower than checking by hand with a browser as it does not load images, stylesheets and other data referenced from the site. General speaking, it should be low traffic compared to regular users. If he is really concerned, MacPorts sends the User-Agent header in the form "MacPorts $mpversion libcurl/$curlversion". So if he likes he can check his logs how much traffic is accounted for that on the homepage URL (without counting distfiles). > What are fellow port developers opinions on this matter? I am not > aware of any scheduled and routine hits that live check is going to > make, it is a on user demand feature. No, there is no scheduled livecheck for all ports. Maintainers may have set that up for their own ports, but that's not something we control. Also any user could run livecheck to see if MacPorts is still at the latest version for this port. Rainer From jeremy at lavergne.gotdns.org Thu Jul 23 14:37:06 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 23 Jul 2009 17:37:06 -0400 Subject: livecheck In-Reply-To: <7FB41248-7A0E-4896-ACC2-C732A90D4570@newgeo.com> References: <7FB41248-7A0E-4896-ACC2-C732A90D4570@newgeo.com> Message-ID: <98537AC4-A354-4521-B822-5903B8890280@lavergne.gotdns.org> If he's worried about bandwidth from people pulling a page of HTML (no images, no scripts, no css files) then he's got a lot more problems than MacPorts users visiting his site. On Jul 23, 2009, at 3:43 PM, Scott Haneda wrote: > Hello, I worked on the memtest port a while back. I was talking > with the author the other day and after he saw the port, he notices > the livecheck option. > > His concern was that of course, it downloads the entire page, and > uses regex to parse out the important bits. He was willing to > create a current-version.txt file that he maintains, as he was > worried about bandwidth. > > I see this as a semi valid concern. But I also do not see it as a > lot different than a user going to a Web site and manually checking > the version in a browser. > > What are fellow port developers opinions on this matter? I am not > aware of any scheduled and routine hits that live check is going to > make, it is a on user demand feature. > > If I have this incorrect, please let me know, as I do feel it is > important to play nice to the developers of software for which ports > are made. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From dweber at macports.org Thu Jul 23 16:50:18 2009 From: dweber at macports.org (Darren Weber) Date: Thu, 23 Jul 2009 16:50:18 -0700 Subject: Vim MacPorts support In-Reply-To: <7bad5d350907231102gceb7d5fsc81431415a478679@mail.gmail.com> References: <7bad5d350907231102gceb7d5fsc81431415a478679@mail.gmail.com> Message-ID: I've found that MacVim provides fairly useful tcl highlighting just by using the mode line that is suggested here: http://guide.macports.org/#development.practices That is, # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 If this mode line is adopted as a best practice, will it over-ride any of the settings in the ~/.vim path? It seems to do so on my system, so even if I install these new files, it continues to use these mode line specifications. My 2c, Darren On Thu, Jul 23, 2009 at 11:02 AM, Maximilian Nickel wrote: > Hi everyone, > i've started work on MacPorts support for Vim. Right now it consists > of syntax coloring for Portfiles, lint support and autoloading stuff. > Syntax coloring is still in early stages, down to the configure phase > most stuff should work though. > Lint support is implemented through Vim's compiler. Running :make when > editing a Portfile will run port lint on it. If there are errors a > quickfix window will open and display them. As port lint doesn't > report line numbers for errors right now, there is no support for > directly jumping to the errorneous lines yet. > > Anyway, if you want to check it out, you can get the source with "svn > co https://svn.macports.org/repository/macports/users/mnick/macports.vim" > Just copy everything in that directory into your ~/.vim directory and > you should be set > > I've not yet decided how to exactly color the syntax, so if you have > suggestions i'd be happy to hear them, along with any other > suggestions. > > Cheers, > Max > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimue at macports.org Thu Jul 23 17:18:44 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Fri, 24 Jul 2009 02:18:44 +0200 Subject: Vim MacPorts support In-Reply-To: References: <7bad5d350907231102gceb7d5fsc81431415a478679@mail.gmail.com> Message-ID: <4A68FDE4.3080800@macports.org> On 2009-07-24 01:50 , Darren Weber wrote: > I've found that MacVim provides fairly useful tcl highlighting just by > using the mode line that is suggested here: > http://guide.macports.org/#development.practices > > That is, > > # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 > > > If this mode line is adopted as a best practice, will it over-ride any > of the settings in the ~/.vim path? Yes, the modeline overwrites settings from .vimrc and the .vim directory. As you noticed that on files with this modeline only: to enable Tcl syntax highlighting on all Portfiles regardless of the modeline, add this line to your .vim/filetype.vim: au BufRead,BufNewFile Portfile setfiletype tcl But what Max provides here offers much more than just syntax highlighting in Tcl style. It offers validation of Portfile options as different syntax highlighting and supports lint directly from vim. As soon as it is improved and thoroughly tested, I would like to include it in the vim ports. Then we could change that modeline to use ft=portfile instead of ft=tcl and recommend installing vim from MacPorts ( > It seems to do so on my system, so > even if I install these new files, it continues to use these mode line > specifications. Use :set nomodeline :e to temporary disable modelines and reload the file which will apply the settings from the .vim directory. Rainer From blb at macports.org Thu Jul 23 23:01:58 2009 From: blb at macports.org (Bryan Blackburn) Date: Fri, 24 Jul 2009 00:01:58 -0600 Subject: [54124] trunk/dports/graphics/tiff/Portfile In-Reply-To: <22204C6F-CC7F-4F6A-B008-F78C7D125BF4@macports.org> References: <20090721181939.7B747214748B@beta.macosforge.org> <20090722020952.GI16057@ninagal.withay.com> <20090722214503.GF23655@ninagal.withay.com> <22204C6F-CC7F-4F6A-B008-F78C7D125BF4@macports.org> Message-ID: <20090724060158.GN41349@ninagal.withay.com> On Wed, Jul 22, 2009 at 09:59:00PM -0500, Ryan Schmidt said: > On Jul 22, 2009, at 16:45, Bryan Blackburn wrote: [...] > >I believe the plan is to be able to abstract out the specific > >location so we > >can support various locations of Xcode (which would probably be > >good for > >anyone with multiple versions installed as well). > > So are you saying we want to be able to access the *nix-level tools > within the Xcode install location instead of within /usr? Good question, I think the initial stuff was partly just a way of avoiding having more hardcoded paths, with the potential to more easily do something more intelligent with it in the future. [...] > >Note that the SDKs are technically not for universal (except as you > >note, on > >10.4/PPC) but are for targetting a certain OS version. I'd really > >like to > >see any and all use of the SDKs removed since the official MacPorts > >policy is that we don't support cross-platform development. > > For some meaning of the word "support", we have been supporting the > universal variant with i386 ppc for some time, which counts as cross- > compiling. Admittedly it often doesn't work. Sorry, I was a bit imprecise; the SDK stuff is for targetting a specific version of Mac OS X, which MacPorts definitely can't do currently. So, other than 10.4/PPC, why are we referencing the SDKs at all? Universal (i386+ppc, i386+x86_64, etc) don't need the SDKs to do that (again, other than 10.4/PPC). > > >And further to > >that, I'd also really like to see +universal removed completely > >until it can > >be done more cleanly, since that definitely seems to be a major > >cause of > >tickets & support issues. Things like keeping track of actual > >build archs > >instead of just noting +universal would be a necessity if we really > >want it > >to work; we currently just say "you need to make sure everything is > >built > >the same" but that'd be better done by port. > > > >Though I'm guessing we're going to need to revamp the registry > >first in > >order to properly store these settings... > > While I'm not happy with our universal support yet, removing it would > limit a user to choosing either all 32-bit or all 64-bit software. We currently have the issue where all dependencies must be built +universal to make a port itself work with +universal, so aren't we already there? And if someone builds +universal with universal_archs set to 'i386 ppc' and later changes it to 'i386 x86_64', what happens? > Since build_arch was only just added to MacPorts trunk, and Snow > Leopard, which is the first version to build 64-bit by default, is > not released yet, I doubt the majority of ports have been tested for > 64-bit compatibility, so I bet we have some ports that don't build > 64-bit. (wine springs to mind, last time I checked.) Many people have > so far been using universal as a way to get 64-bit, setting > universal_archs to i386 x86_64. For ports that cannot build 64-bit, > you simply don't install it universal, and it builds 32-bit, using > the 32-bit part of its dependencies. If we remove universal, you > would either choose 64-bit software and then not use those 32-bit- > only ports at all (since the dependencies would be 64-bit only), or > you use only 32-bit software. That seems worse than what we have now, > which lets the user use 64-bit for the ports where it's possible and > 32-bit for those where it's not. Again, except for dependencies. Universal is great when you distribute binaries, but of course MacPorts doesn't do that currently. I realize one nicety to universal is that people can build on a fast (Intel) machine and then share the result with a slower (G4) machine to avoid slow build times. Outside of that, since we still build from source otherwise, what are the advantages? The disadvantages are all the various tickets for universal support (57 currently open with 'universal' in the summary, 248 total), the ongoing changes to try and make it work, the muniversal port group, etc. Doing it right with all this baggage just complicates an already difficult task for too few of us working on base, so do we want to continue this route, or stop and try to actually find a better, cleaner, maintainable way? Maybe I'm just in the minority here and everyone else thinks it's fine, so perhaps I'm just missing something? Bryan From blb at macports.org Thu Jul 23 23:12:14 2009 From: blb at macports.org (Bryan Blackburn) Date: Fri, 24 Jul 2009 00:12:14 -0600 Subject: [54124] trunk/dports/graphics/tiff/Portfile In-Reply-To: References: <20090721181939.7B747214748B@beta.macosforge.org> <20090722020952.GI16057@ninagal.withay.com> Message-ID: <20090724061214.GO41349@ninagal.withay.com> On Thu, Jul 23, 2009 at 02:49:00AM -0500, Ryan Schmidt said: > > On Jul 22, 2009, at 15:41, Ryan Schmidt wrote: > > >>This is probably abusing port groups some, but can we move the > >>check to one > >>so we don't have all this code repeated in these "over a dozen > >>other ports" > >>until the check can be done within base instead? > > > >That could be possible. I will look into it. > > How's this? > > http://trac.macports.org/ticket/20408 > > I don't think the code that reads MacPorts trunk's developer_dir > variable is right. It doesn't seem to be using the value I put in > macports.conf. It shouldn't be using the macports:: namespace stuff, since that is aliased into ports in macports.tcl. Otherwise it seems to work here. > > I also haven't tested on Leopard. 'tis where I tested, fine with requiring 3.1 with my 3.1.3, fails when I try to require 3.2, as expected. Bryan From ryandesign at macports.org Fri Jul 24 01:26:54 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 24 Jul 2009 03:26:54 -0500 Subject: [54124] trunk/dports/graphics/tiff/Portfile In-Reply-To: <20090724061214.GO41349@ninagal.withay.com> References: <20090721181939.7B747214748B@beta.macosforge.org> <20090722020952.GI16057@ninagal.withay.com> <20090724061214.GO41349@ninagal.withay.com> Message-ID: On Jul 24, 2009, at 01:12, Bryan Blackburn wrote: > On Thu, Jul 23, 2009 at 02:49:00AM -0500, Ryan Schmidt said: > >> I don't think the code that reads MacPorts trunk's developer_dir >> variable is right. It doesn't seem to be using the value I put in >> macports.conf. > > It shouldn't be using the macports:: namespace stuff, since that is > aliased > into ports in macports.tcl. Otherwise it seems to work here. Tcl namespaces are still mysterious to me. Not using "macports::" didn't seem to make a difference for me. If you can find a change that allows the developer_dir value from macports.conf to be used, please commit it. From ryandesign at macports.org Fri Jul 24 01:53:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 24 Jul 2009 03:53:42 -0500 Subject: [54124] trunk/dports/graphics/tiff/Portfile In-Reply-To: <20090724060158.GN41349@ninagal.withay.com> References: <20090721181939.7B747214748B@beta.macosforge.org> <20090722020952.GI16057@ninagal.withay.com> <20090722214503.GF23655@ninagal.withay.com> <22204C6F-CC7F-4F6A-B008-F78C7D125BF4@macports.org> <20090724060158.GN41349@ninagal.withay.com> Message-ID: On Jul 24, 2009, at 01:01, Bryan Blackburn wrote: > Sorry, I was a bit imprecise; the SDK stuff is for targetting a > specific > version of Mac OS X, which MacPorts definitely can't do currently. > So, > other than 10.4/PPC, why are we referencing the SDKs at all? > Universal > (i386+ppc, i386+x86_64, etc) don't need the SDKs to do that (again, > other > than 10.4/PPC). With MacPorts 1.7.1, a user can specify an alternate Mac OS X deployment target and SDK in macports.conf. Admittedly a lot of software didn't like this, and since this feature has already been removed from trunk I won't belabor it. >> While I'm not happy with our universal support yet, removing it would >> limit a user to choosing either all 32-bit or all 64-bit software. > > We currently have the issue where all dependencies must be built > +universal > to make a port itself work with +universal, so aren't we already > there? And > if someone builds +universal with universal_archs set to 'i386 ppc' > and > later changes it to 'i386 x86_64', what happens? > >> Since build_arch was only just added to MacPorts trunk, and Snow >> Leopard, which is the first version to build 64-bit by default, is >> not released yet, I doubt the majority of ports have been tested for >> 64-bit compatibility, so I bet we have some ports that don't build >> 64-bit. (wine springs to mind, last time I checked.) Many people have >> so far been using universal as a way to get 64-bit, setting >> universal_archs to i386 x86_64. For ports that cannot build 64-bit, >> you simply don't install it universal, and it builds 32-bit, using >> the 32-bit part of its dependencies. If we remove universal, you >> would either choose 64-bit software and then not use those 32-bit- >> only ports at all (since the dependencies would be 64-bit only), or >> you use only 32-bit software. That seems worse than what we have now, >> which lets the user use 64-bit for the ports where it's possible and >> 32-bit for those where it's not. > > Again, except for dependencies. Universal is great when you > distribute > binaries, but of course MacPorts doesn't do that currently. I > realize one > nicety to universal is that people can build on a fast (Intel) > machine and > then share the result with a slower (G4) machine to avoid slow > build times. > Outside of that, since we still build from source otherwise, what > are the > advantages? My above example was meant to illustrate the problems of a single user running software on a single Mac. Let me give a concrete example. Imagine a user wants to install a 64-bit version of mysql5 to allow it to use more than 4G of RAM, but also wants to install wine. Wine cannot be built 64-bit (last I checked). Both ports depend on zlib. With today's universal support, the user can build an i386/ x86_64 universal version of zlib. He can then build mysql5 64-bit only, and it will use the 64-bit parts of zlib, and he can build wine 32-bit only, and it will use the 32-bit parts of zlib. If you remove universal support from MacPorts, the user must either not use wine at all, or must live with a 32-bit mysql5, or must manage two MacPorts prefixes, one for 32-bit and one for 64-bit software. > The disadvantages are all the various tickets for universal support > (57 > currently open with 'universal' in the summary, 248 total), the > ongoing > changes to try and make it work, the muniversal port group, etc. > Doing it > right with all this baggage just complicates an already difficult > task for > too few of us working on base, so do we want to continue this > route, or stop > and try to actually find a better, cleaner, maintainable way? > > Maybe I'm just in the minority here and everyone else thinks it's > fine, so > perhaps I'm just missing something? No, I fully agree, we have some problems. I'm in favor of finding a better, cleaner, maintainable way. Do we have any idea what that might be? I still promote the idea that MacPorts should build for a single arch. We now even have a means of specifying that arch with the build_arch variable. Our hypothetical Intel build server would build once for i386, then build again separately for x86_64. If we have a PowerPC build server, it would build once for ppc, then build again separately for ppc64. All these parts would be shuffled to one machine, which would merge them together and produce a universal binary that our hypothetical binary support would download and install on user machines. Clearly this relies on a lot of parts that aren't built yet. And it also assumes that a bunch of separate installs can be merged into a single one without further input. We already know this is isn't so; we will need a way for ports to indicate what to do with non-binary files which are different. That's what a bunch of the code in muniversal is there for. Ports still need a way to specify what architectures they can build for, since not all ports can build for all architectures. muniversal introduced a way to do that but it's not integrated with MacPorts base and isn't used when not building universal. I feel like I'm about to go off on a tangent about binaries so I'll stop here and wait to hear what other ideas there are about new universal support, or more thoughts on whether or not universal support is still necessary in MacPorts now. From ryandesign at macports.org Fri Jul 24 03:07:46 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 24 Jul 2009 05:07:46 -0500 Subject: Allowing more non-maintainer updates In-Reply-To: <20090722213459.GE23655@ninagal.withay.com> References: <20090722213459.GE23655@ninagal.withay.com> Message-ID: <207440A9-DF52-4C08-BA00-1FBAC845DB4A@macports.org> On Jul 22, 2009, at 16:34, Bryan Blackburn wrote: > On Wed, Jul 22, 2009 at 03:57:30PM -0500, Ryan Schmidt said: >> The Non-Maintainer Port Updates section of the guide lists conditions >> when we may update ports that have a maintainer: >> >> http://guide.macports.org/#project.update-policies.nonmaintainer >> >> The existing conditions are: >> >> * The maintainer does not respond within 72 hours >> * A port is abandoned by its current maintainer >> * A critical port is broken that affects many users >> >> There are some conditions I would like to add to these: > > The NewCommittersGuide page documents such things to some degree: > > Ok, I had forgotten about NewCommittersGuide. It says you may fix a broken port. The Guide only says you may fix a broken port if it is "critical" and affects many users. So these documents somewhat contradict each other. We need to document committer guidelines in a single place, not two. If we're going to allow fixing any broken port, we need to define what constitutes "broken". I also want to allow some changes to ports that are not "broken". >> * Required port variable missing (e.g. platforms or long_description) > > If required, I'd technically call that broken. A port missing the platforms line will still install fine. AFAIK no part of MacPorts currently uses it. But lint will complain about it and documentation says it must be there and MacPorts base might use it in the future so we should be allowed to add it to portfiles without consulting the maintainer. >> * Syntax error > > If it causes something like PortIndex to fail, again, broken. Right, that's what I meant. In addition to syntax errors, I'm thinking of an update which didn't test every available variant, leaving a problem in one of the variants, for example a patchfile that no longer applies. >> * Spelling or grammar error in comments, descriptions, etc. > > That's pretty cosmetic, so definitely not broken, not sure this > would really > be a big deal unless it makes things like 'port search' not find > proper > ports. Yes, it's cosmetic. But if it's an obvious typo, or if the wording doesn't make sense, I think we should be allowed to fix it without having to contact the maintainer. What is the likelihood the maintainer would reply "No, I want that typo to be there"? >> * Hardcoded /opt/local > > Again, broken. Yes, of course only for the minority of users running in a nonstandard MacPorts prefix. >> * Forgot to bump revision or epoch after change that requires it > > I'd call that broken as well. The port isn't broken as such, but whatever update was committed before won't be propagated to users who already had the port installed. So maybe one could say broadly that "the system" is broken. >> * No $Id$ tag >> * No svn:keywords or svn:eol-style properties > > Hmm, policy failures but the port should be working; I'd say for > non-committer maintainers, perhaps go ahead and change it... In fact I have been periodically fixing these issues across all ports for years now, not really considering those aspects to be part of the portfile, but realizing now that perhaps allowing these changes should be codified. Nobody has ever complained to me about making these changes, and I would be surprised to hear any complaint about it, since it is documented that we require these. I don't see a point in filing a ticket to fix these, since I don't see any valid reason for a maintainer to refuse such a change. >> * Build fix for pre-release Mac OS X version > > Broken, just for that platform, so anything outside making that > work would > be off limits. Agreed. >> * Removing code for very old versions of Mac OS X (I would currently >> limit this to Jaguar and earlier; once MacPorts 1.8.0 is released, >> make this Panther and earlier) > > To avoid any possible confusion (eg, seeing that there's a platform > variant > for something and thinking that means it will work) this makes > sense to > remove. And to simplify the port. There's no point having a darwin 6 section in a port if MacPorts cannot be installed on darwin 6 anymore. Presumably anyone wanting to use MacPorts on darwin 6 today would have to get a historical version of MacPorts from that period, and a ports tree to match. >> * Removing code for ports which will be deleted (e.g. removing mysql3 >> variants since I want to remove mysql3 port) > > Removal would then cause those ports referencing it to be broken. Well true... though ideally one would want to remove all references to a port first before removing it. Hence the desire to call out this case specifically. >> Thoughts? Additions? > > These policies have been listed on the NewCommittersGuide page for > ages so > perhaps they should be moved to the guide? There hasn't been a > huge amount > of changes to it lately, so it may be safe (after the above updates). I agree NewCommittersGuide should be merged into the Guide. >> I'm thinking about whether we should also allow changes which >> simplify ports, e.g. if a port sets distfiles and worksrcdir but this >> could be changed to just set distname, or if a port uses "system" to >> call some utility but the same could be achieved with a Tcl command, >> or if a port overrides a phase but the same could be accomplished by >> setting phase variables. But I'm not sure how to word it so as not to >> be too ambiguous. > > I'd call that making the Portfile more efficient, since it > technically works > but could work better. Some of these would be obvious (system install > changed to use xinstall, for example) but others may end up being > somewhat > subjective. Many cases simply tend to be lack of awareness of what > all can > be used in a Portfile, so I'd guess that many would welcome the > improvement > on the port. I agree it's subjective which is why I'm hesitant. But my motivation is as you say, maintainers not being aware of what's possible, and doing something a complicated way when it can be done more simply. And since maintainers often look at other ports to see how to do things, we would want to get unnecessarily complicated code out of portfiles so those methods aren't then learned and copied by others. >> I might also want to allow changes which implement common MacPorts >> idioms, e.g. defining and using a ${branch} variable. > > Or perhaps any of the various bits on the PortfileRecipes wiki page? That could be a good idea, yes. From ryandesign at macports.org Fri Jul 24 03:13:59 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 24 Jul 2009 05:13:59 -0500 Subject: Allowing more non-maintainer updates In-Reply-To: <8965CA8E-2832-4CF4-BD0F-FEC97D17817B@lavergne.gotdns.org> References: <8965CA8E-2832-4CF4-BD0F-FEC97D17817B@lavergne.gotdns.org> Message-ID: On Jul 22, 2009, at 16:30, Jeremy Lavergne wrote: > I like the idea. > > How about we add removing changes that were rolled back previously > that were accidentally/blindly reinstated? Is this what you mean? 1. if a port update is committed, but that update inadvertently undoes changes that were previously committed, we could reinstate those changes 2. if a port update is committed, but unrelated changes to another port are inadvertently committed as well, we could undo those inadvertent changes I would agree to allowing those changes without prior maintainer approval. > adding comments? Perhaps... We have so few comments in portfiles now. Much of it is probably self-explanatory but maybe some of it could do with some documentation. > We might consider expanding the "hardcoded" section to include > other items, such as moving ports off of about-to-be abandoned > packages (e.g., python24) or changes to base (e.g., `default > parallel_build yes`). Ah yes, there is of course also /Applications/MacPorts which should be switched to ${applications_dir} We should allow adding parallel_build yes or no to any port And moving ports off of soon-to-be-abandoned ports, yes, that's what I was thinking of with my mysql3 example. > We might also consider upgrading PortGroups, if that day ever comes > to pass. How do you mean? The cmake portgroup is new, and we have ports using cmake manually; do you mean updating such ports to use the cmake portgroup? From ryandesign at macports.org Fri Jul 24 03:16:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 24 Jul 2009 05:16:03 -0500 Subject: Allowing more non-maintainer updates In-Reply-To: <4A6872A5.8070602@macports.org> References: <4A6872A5.8070602@macports.org> Message-ID: On Jul 23, 2009, at 09:24, Joshua Root wrote: > On 2009-7-23 06:57, Ryan Schmidt wrote: >> The Non-Maintainer Port Updates section of the guide lists conditions >> when we may update ports that have a maintainer: >> >> http://guide.macports.org/#project.update-policies.nonmaintainer >> >> The existing conditions are: >> >> * The maintainer does not respond within 72 hours >> * A port is abandoned by its current maintainer >> * A critical port is broken that affects many users >> >> There are some conditions I would like to add to these: > [...] > > Maintainership was never meant to stop other people from fixing > things, > so we should indeed make this clear in the docs. All the things you > list > are valid reasons for others to fix a port. However, I would tend to > agree with Bryan that perhaps amending the third bullet point above to > "A port is obviously broken" might be more succinct. That wording is good, though I would still like the documentation to define "broken", and to allow the types of changes I mentioned to ports that are not technically broken. From jmr at macports.org Fri Jul 24 04:08:47 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 24 Jul 2009 21:08:47 +1000 Subject: [54124] trunk/dports/graphics/tiff/Portfile In-Reply-To: References: <20090721181939.7B747214748B@beta.macosforge.org> <20090722020952.GI16057@ninagal.withay.com> <20090724061214.GO41349@ninagal.withay.com> Message-ID: <4A69963F.6080506@macports.org> On 2009-7-24 18:26, Ryan Schmidt wrote: > > On Jul 24, 2009, at 01:12, Bryan Blackburn wrote: > >> On Thu, Jul 23, 2009 at 02:49:00AM -0500, Ryan Schmidt said: >> >>> I don't think the code that reads MacPorts trunk's developer_dir >>> variable is right. It doesn't seem to be using the value I put in >>> macports.conf. >> >> It shouldn't be using the macports:: namespace stuff, since that is >> aliased >> into ports in macports.tcl. Otherwise it seems to work here. > > Tcl namespaces are still mysterious to me. Not using "macports::" didn't > seem to make a difference for me. If you can find a change that allows > the developer_dir value from macports.conf to be used, please commit it. Works fine here after r54278. - Josh From dluke at geeklair.net Fri Jul 24 06:28:29 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 24 Jul 2009 09:28:29 -0400 Subject: Allowing more non-maintainer updates In-Reply-To: <207440A9-DF52-4C08-BA00-1FBAC845DB4A@macports.org> References: <20090722213459.GE23655@ninagal.withay.com> <207440A9-DF52-4C08-BA00-1FBAC845DB4A@macports.org> Message-ID: <54027A19-8F92-4FFE-B184-1471FFABC584@geeklair.net> On Jul 24, 2009, at 6:07 AM, Ryan Schmidt wrote: >>> * Required port variable missing (e.g. platforms or >>> long_description) >> >> If required, I'd technically call that broken. > > A port missing the platforms line will still install fine. AFAIK no > part of MacPorts currently uses it. But lint will complain about it > and documentation says it must be there and MacPorts base might use > it in the future so we should be allowed to add it to portfiles > without consulting the maintainer. ... but as for right now, if the port isn't broken it doesn't really hurt to open a ticket for the maintainer to look at (you can offer in the ticket to commit the change if you want). Without communication, the maintainer may never really realize that he or she forgot something. [snip] > I agree it's subjective which is why I'm hesitant. But my motivation > is as you say, maintainers not being aware of what's possible, and > doing something a complicated way when it can be done more simply. > And since maintainers often look at other ports to see how to do > things, we would want to get unnecessarily complicated code out of > portfiles so those methods aren't then learned and copied by others. In this case, I think it's even more clear that the maintainer should be communicated with as we want to be spreading around this kind of knowledge as much as possible. ... and again, if the port is working, it's not really hurting end- users, so I think it's OK for there to be some small delay in getting it updated. Perhaps the guideline of how long we wait for maintainer timeouts needs to be adjusted (or adjusted for this case?), but I would still like to see communication for this kind of thing (so we can all learn from each other). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jeremy at lavergne.gotdns.org Fri Jul 24 12:35:09 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 24 Jul 2009 15:35:09 -0400 Subject: Allowing more non-maintainer updates In-Reply-To: References: <8965CA8E-2832-4CF4-BD0F-FEC97D17817B@lavergne.gotdns.org> Message-ID: <8E893AF5-F958-444C-825E-60D2BBA79951@lavergne.gotdns.org> On Jul 24, 2009, at 6:13 AM, Ryan Schmidt wrote: >> I like the idea. >> >> How about we add removing changes that were rolled back previously >> that were accidentally/blindly reinstated? > > Is this what you mean? > > 1. if a port update is committed, but that update inadvertently > undoes changes that were previously committed, we could reinstate > those changes > > 2. if a port update is committed, but unrelated changes to another > port are inadvertently committed as well, we could undo those > inadvertent changes > > I would agree to allowing those changes without prior maintainer > approval. > > >> adding comments? > > Perhaps... We have so few comments in portfiles now. Much of it is > probably self-explanatory but maybe some of it could do with some > documentation. Putting comments in the portfiles would help avoid the two instances above regarding reinstatement of changes. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Fri Jul 24 12:37:29 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 24 Jul 2009 15:37:29 -0400 Subject: Allowing more non-maintainer updates In-Reply-To: References: <8965CA8E-2832-4CF4-BD0F-FEC97D17817B@lavergne.gotdns.org> Message-ID: <0B6A199E-CB86-40AB-9135-A8E89F37849A@lavergne.gotdns.org> On Jul 24, 2009, at 6:13 AM, Ryan Schmidt wrote: >> We might also consider upgrading PortGroups, if that day ever comes >> to pass. > > How do you mean? > > The cmake portgroup is new, and we have ports using cmake manually; > do you mean updating such ports to use the cmake portgroup? This point is two-fold: adding portgroups that can now apply significantly decreases bad habits in ports by allowing people to use approved methods defined in the portgroups, and sometimes we need to move people from portgroup python24 to python25. So it is both similar to you understood my question and following your mysql3 example again. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Sat Jul 25 17:22:01 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 25 Jul 2009 19:22:01 -0500 Subject: [54378] trunk/base/src In-Reply-To: <20090725213152.53BD221B4EEB@beta.macosforge.org> References: <20090725213152.53BD221B4EEB@beta.macosforge.org> Message-ID: <0454FD03-FB2A-4C96-BC85-B07A46295F3C@macports.org> On Jul 25, 2009, at 16:31, jmr at macports.org wrote: > Revision: 54378 > http://trac.macports.org/changeset/54378 > Author: jmr at macports.org > Date: 2009-07-25 14:31:51 -0700 (Sat, 25 Jul 2009) > Log Message: > ----------- > Add 'replaced_by' portfile option to allow renaming or replacing > ports. Also add a --no-replace option to upgrade to stop it from > doing the replacements. Closes #20157. Wow. Thanks! This is fantastic. From blu.dark at gmail.com Sat Jul 25 17:25:21 2009 From: blu.dark at gmail.com (martin krastev) Date: Sat, 25 Jul 2009 20:25:21 -0400 Subject: apple-gcc42-devel on tiger/ppc Message-ID: <80caf8ca0907251725j6566953j42587d11d03c1829@mail.gmail.com> hi porters, for the past few months now i have not been able to build apple-gcc42-devel under darwin8.11 ppc. As the port does have a darwin_8 variant, am i assuming wrong that it should generally be supported under tiger/ppc? just asking before i spam you with the actual error logs. regards, martin From ryandesign at macports.org Sat Jul 25 17:38:39 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 25 Jul 2009 19:38:39 -0500 Subject: [54368] trunk/base/src/port1.0 In-Reply-To: <20090725170312.79A0421AEF98@beta.macosforge.org> References: <20090725170312.79A0421AEF98@beta.macosforge.org> Message-ID: On Jul 25, 2009, at 12:03, mcalhoun at macports.org wrote: > Revision: 54368 > http://trac.macports.org/changeset/54368 > Author: mcalhoun at macports.org > Date: 2009-07-25 10:03:12 -0700 (Sat, 25 Jul 2009) > Log Message: > ----------- > Some ports assume that any necessary header and library files are > found by default by the compiler (e.g. in /usr/include or /usr/ > local/include). > Changing -I${prefix}/include to -isystem{prefix}/include usually > fixes the problem (See r49050, r42207, r49018, r39803, and r47699). > Setting environmental variables CPATH and LIBRARY_PATH should make > setting -isystem unnecessary. > Deleting -I${prefix}/include is only required. Wait, what? In this commit I see you adding CPATH and LIBRARY_PATH but I don't see you deleting the -I and -L stuff. I thought it was an either/or thing -- either you use -I and -L or you use CPATH and LIBRARY_PATH. Is that not right? How does it all interact if you use all of them at once like this? How did you find that this is better than the other proposal of changing -I to -isystem? http://lists.macosforge.org/pipermail/macports-dev/2009-April/ 008148.html From toby at macports.org Sat Jul 25 18:03:08 2009 From: toby at macports.org (Toby Peterson) Date: Sat, 25 Jul 2009 18:03:08 -0700 Subject: [54368] trunk/base/src/port1.0 In-Reply-To: References: <20090725170312.79A0421AEF98@beta.macosforge.org> Message-ID: <74c219d30907251803g67833b56v449f52872600da40@mail.gmail.com> On Sat, Jul 25, 2009 at 17:38, Ryan Schmidt wrote: > > On Jul 25, 2009, at 12:03, mcalhoun at macports.org wrote: > >> Revision: 54368 >> ? ? ? ? ?http://trac.macports.org/changeset/54368 >> Author: ? mcalhoun at macports.org >> Date: ? ? 2009-07-25 10:03:12 -0700 (Sat, 25 Jul 2009) >> Log Message: >> ----------- >> Some ports assume that any necessary header and library files are found by >> default by the compiler (e.g. in /usr/include or /usr/local/include). >> Changing -I${prefix}/include to -isystem{prefix}/include usually fixes the >> problem (See r49050, r42207, r49018, r39803, and r47699). >> Setting environmental variables CPATH and LIBRARY_PATH should make setting >> -isystem unnecessary. >> Deleting -I${prefix}/include is only required. > > Wait, what? In this commit I see you adding CPATH and LIBRARY_PATH but I > don't see you deleting the -I and -L stuff. I thought it was an either/or > thing -- either you use -I and -L or you use CPATH and LIBRARY_PATH. Is that > not right? How does it all interact if you use all of them at once like > this? How did you find that this is better than the other proposal of > changing -I to -isystem? This change is pretty risky - I think we should do additional testing before making such a fundamental change to how ports are built. - Toby From ryandesign at macports.org Sun Jul 26 04:40:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 26 Jul 2009 06:40:40 -0500 Subject: apple-gcc42-devel on tiger/ppc In-Reply-To: <80caf8ca0907251725j6566953j42587d11d03c1829@mail.gmail.com> References: <80caf8ca0907251725j6566953j42587d11d03c1829@mail.gmail.com> Message-ID: On Jul 25, 2009, at 19:25, martin krastev wrote: > for the past few months now i have not been able to build > apple-gcc42-devel under darwin8.11 ppc. As the port does have a > darwin_8 variant, am i assuming wrong that it should generally be > supported under tiger/ppc? just asking before i spam you with the > actual error logs. I recommend you file a ticket for this issue so that it can be properly tracked. From takeshi at macports.org Sun Jul 26 14:57:57 2009 From: takeshi at macports.org (Takeshi Enomoto) Date: Mon, 27 Jul 2009 06:57:57 +0900 Subject: portname with + Message-ID: <2dc53b910907261457p7b34d809t4dd3475ff97cc269@mail.gmail.com> Hello, I maintain vis5d+. I am writing another package that depends on vis5d+. With vis5d+ in depends_lib, port (1.7.1) command gives error. DEBUG: can't set "depends_lib": invalid depspec: port:vis5d+ port lint does not gives error. Should I report this as a port bug or change the name "vis5d+"? I would be grateful for your help. Takeshi From toby at apple.com Sun Jul 26 15:49:11 2009 From: toby at apple.com (Toby Peterson) Date: Sun, 26 Jul 2009 15:49:11 -0700 Subject: portname with + In-Reply-To: <2dc53b910907261457p7b34d809t4dd3475ff97cc269@mail.gmail.com> References: <2dc53b910907261457p7b34d809t4dd3475ff97cc269@mail.gmail.com> Message-ID: <9307372D-2C91-4211-923D-6C79CCDEAFF9@apple.com> Same problem with pcre++, see http://trac.macports.org/ticket/20046 You should rename the port, perhaps just 'vis5dplus'. - Toby On Jul 26, 2009, at 2:57 PM, Takeshi Enomoto wrote: > Hello, > > I maintain vis5d+. I am writing another package that depends on vis5d > +. > With vis5d+ in depends_lib, port (1.7.1) command gives error. > > DEBUG: can't set "depends_lib": invalid depspec: port:vis5d+ > > port lint does not gives error. > > Should I report this as a port bug or change the name "vis5d+"? > > I would be grateful for your help. > > Takeshi > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From mcalhoun at macports.org Sun Jul 26 16:27:58 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Sun, 26 Jul 2009 23:27:58 +0000 (UTC) Subject: [54368] trunk/base/src/port1.0 References: <20090725170312.79A0421AEF98@beta.macosforge.org> Message-ID: Ryan Schmidt writes: > > > On Jul 25, 2009, at 12:03, mcalhoun at ... wrote: > > > Revision: 54368 > > http://trac.macports.org/changeset/54368 > > Author: mcalhoun at ... > > Date: 2009-07-25 10:03:12 -0700 (Sat, 25 Jul 2009) > > Log Message: > > ----------- > > Wait, what? In this commit I see you adding CPATH and LIBRARY_PATH > but I don't see you deleting the -I and -L stuff. I thought it was an > either/or thing -- either you use -I and -L or you use CPATH and > LIBRARY_PATH. Is that not right? How does it all interact if you use > all of them at once like this? How did you find that this is better > than the other proposal of changing -I to -isystem? > > http://lists.macosforge.org/pipermail/macports-dev/2009-April/ > 008148.html > > I do not think there is any harm in having both -I,-L and CPATH,LIBRARY_PATH. I have not found any problems at least. I did not delete -I${prefix}/include and -L${prefix}/lib because something similar caused problems with qt4-mac (see r54186), and I was afraid it might have broken other packages which have their own build programs. I used CPATH instead of -isystem because, as for as I know, there is no matching -lsystem which would appends to the library search path like -isystem appends to the include search paths. CPATH on the other hand has an equivalent LIBRARY_PATH. -Marcus From takeshi at enomosphere.net Mon Jul 27 06:05:41 2009 From: takeshi at enomosphere.net (Takeshi Enomoto) Date: Mon, 27 Jul 2009 22:05:41 +0900 Subject: portname with + In-Reply-To: <9307372D-2C91-4211-923D-6C79CCDEAFF9@apple.com> References: <2dc53b910907261457p7b34d809t4dd3475ff97cc269@mail.gmail.com> <9307372D-2C91-4211-923D-6C79CCDEAFF9@apple.com> Message-ID: <2dc53b910907270605l5e4c24e4s8b553108843d022@mail.gmail.com> Toby, 2009/7/27 Toby Peterson : > Same problem with pcre++, see http://trac.macports.org/ticket/20046 Thank you for pointing to this information. I will change the port name. I will just leave + out. It would be nice if port lint could check characters port name may use. Takeshi From ryandesign at macports.org Mon Jul 27 06:47:18 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 27 Jul 2009 08:47:18 -0500 Subject: portname with + In-Reply-To: <2dc53b910907270605l5e4c24e4s8b553108843d022@mail.gmail.com> References: <2dc53b910907261457p7b34d809t4dd3475ff97cc269@mail.gmail.com> <9307372D-2C91-4211-923D-6C79CCDEAFF9@apple.com> <2dc53b910907270605l5e4c24e4s8b553108843d022@mail.gmail.com> Message-ID: <8DA5933A-264F-4945-9A5B-CFB15A59EA80@macports.org> On Jul 27, 2009, at 08:05, Takeshi Enomoto wrote: > 2009/7/27 Toby Peterson : >> Same problem with pcre++, see http://trac.macports.org/ticket/20046 > > Thank you for pointing to this information. > > I will change the port name. I will just leave + out. The convention so far has been to change the "+" to an "x". (port echo name:xx will show you some of them.) But I see you've already renamed the port "vis5d". Note that changing a port's name is a problem for anyone who had the port installed under its old name. They will not know that you have changed the port's name and will not be informed of any updates under the new name. You could leave a "vis5d+" stub port that installs only a read me. There are some other stub ports around you could copy from. MacPorts 1.8.0 will have a "replaced_by" keyword which will make stub ports simpler. > It would be nice if port lint could check characters port name may > use. That would be a good idea. Could you file a ticket for that? I imagine lint also needs changes for "replaced_by" -- if a port has "replaced_by" I expect a lot of our other requirements for what a port must have no longer apply. From mnick at macports.org Mon Jul 27 14:31:09 2009 From: mnick at macports.org (Maximilian Nickel) Date: Mon, 27 Jul 2009 23:31:09 +0200 Subject: Vim MacPorts support In-Reply-To: <4A68FDE4.3080800@macports.org> References: <7bad5d350907231102gceb7d5fsc81431415a478679@mail.gmail.com> <4A68FDE4.3080800@macports.org> Message-ID: <7bad5d350907271431r12732d9clea81882bc7dd3453@mail.gmail.com> On Fri, Jul 24, 2009 at 2:18 AM, Rainer M?ller wrote: > As soon as it is improved and thoroughly tested, I would like to include > it in the vim ports. Then we could change that modeline to use > ft=portfile instead of ft=tcl and recommend installing vim from MacPorts ( Right now i'm setting the filetype for any file named Portfile automatically to portfile in ftdetect, so probably the ft part in the modeline could be removed completly. All the code is in contrib/mpvim now and most of the syntax from the guide should be covered. Support for snippets as described in my last mail has also been added. The README should explain most stuff Cheers Max From kimuraw at macports.org Mon Jul 27 22:40:48 2009 From: kimuraw at macports.org (kimura wataru) Date: Tue, 28 Jul 2009 14:40:48 +0900 Subject: suggestion: split rb-gnome into rb-glib2, rb-pango, ... Message-ID: <20090728144048351418.81d4ecf1@macports.org> Hi, port:rb-gnome contains many ruby libraries and its dependencies are so many. I think that is not convenient such as install gnome-session to use ruby/gtk2. I'm planning to split rb-gnome into each library (like rb-glib2, rb-pango, ...). http://trac.macports.org/browser/users/kimuraw/rb-gnome This port tree contains the following 20 ports. rb-glib2, rb-atk, rb-pango, rb-gtk2, rb-gconf, rb-libgnome, rb-gnomecanvas, rb-gnomeprint, rb-gnomeprintui, rb-gnomevfs, rb-gtkhtml, rb-gtkglext, rb-libart, rb-libglade2, rb-rsvg, rb-poppler, rb-vte, rb-gstreamer, rb-gtksourceview2, rb-gnome-panel I have two questions. (1) port:rb-gnome is nomaintainer. who allows me to split the port? (2) in my plan, port:rb-gnome becomes a meta port like port:gnustep. (rename rb-gnome-all of my personal port to rb-gnome) How about this? -- kimura wataru From ryandesign at macports.org Tue Jul 28 00:01:45 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 28 Jul 2009 02:01:45 -0500 Subject: suggestion: split rb-gnome into rb-glib2, rb-pango, ... In-Reply-To: <20090728144048351418.81d4ecf1@macports.org> References: <20090728144048351418.81d4ecf1@macports.org> Message-ID: On Jul 28, 2009, at 00:40, kimura wataru wrote: > port:rb-gnome contains many ruby libraries and its dependencies > are so many. I think that is not convenient such as install > gnome-session to use ruby/gtk2. > I'm planning to split rb-gnome into each library (like rb-glib2, rb- > pango, ...). > > http://trac.macports.org/browser/users/kimuraw/rb-gnome > > This port tree contains the following 20 ports. > rb-glib2, rb-atk, rb-pango, rb-gtk2, rb-gconf, rb-libgnome, > rb-gnomecanvas, rb-gnomeprint, rb-gnomeprintui, rb-gnomevfs, > rb-gtkhtml, rb-gtkglext, rb-libart, rb-libglade2, rb-rsvg, > rb-poppler, rb-vte, rb-gstreamer, rb-gtksourceview2, rb-gnome-panel > > I have two questions. > > (1) port:rb-gnome is nomaintainer. who allows me to split the port? > > (2) in my plan, port:rb-gnome becomes a meta port like port:gnustep. > (rename rb-gnome-all of my personal port to rb-gnome) > How about this? I don't know about ruby software, so I defer to someone who does -- if you think this makes more sense, by all means please go ahead and do it. From ryandesign at macports.org Wed Jul 29 04:43:36 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 29 Jul 2009 06:43:36 -0500 Subject: [54134] trunk/dports/python In-Reply-To: <20090721213541.12752214A211@beta.macosforge.org> References: <20090721213541.12752214A211@beta.macosforge.org> Message-ID: <4367F139-9E6F-4A8D-95AB-F5545BB54A55@macports.org> On Jul 21, 2009, at 16:35, mnick at macports.org wrote: > Added: trunk/dports/python/py26-pymc/Portfile [snip] > +variant gcc42 description {create Fortran wrappers using gcc42} > conflicts gcc43 g95 { > + depends_lib-append port:gcc42 > + set fc ${prefix}/bin/gfortran-mp-4.2 > + build.env-append F77=${fc} F90=${fc} > +} > + > +variant gcc43 description {create Fortran wrappers using gcc43} > conflicts gcc42 g95 { > + depends_lib-append port:gcc43 > + set fc ${prefix}/bin/gfortran-mp-4.3 > + build.env-append F77=${fc} F90=${fc} > +} > + > +variant g95 description {create Fortran wrappers using f95} > conflicts gcc42 gcc43 { > + depends_lib-append port:g95 > + set fc ${prefix}/bin/g95 > + build.env-append F77=${fc} F90=${fc} > +} > + > +default_variants +gcc43 gcc43 should only be the default variant if no other conflicting variant has already been selected. See the pdftk port for an example. You want something like: if {![variant_isset gcc42] && ![variant_isset g95]} { default_variants +gcc43 } From ryandesign at macports.org Wed Jul 29 05:38:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 29 Jul 2009 07:38:35 -0500 Subject: [51027] trunk/dports/devel In-Reply-To: <74c219d30905161240u2ce39257p81e04b49f07d9ba9@mail.gmail.com> References: <20090515185534.411FA1A0CFDD@beta.macosforge.org> <178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org> <74c219d30905160057t2a8f8d2cn18a1881c82f81c3a@mail.gmail.com> <147D87D8-6AEA-4CCC-9C26-E659190588D2@macports.org> <4A0E81C8.5030707@macports.org> <74c219d30905161240u2ce39257p81e04b49f07d9ba9@mail.gmail.com> Message-ID: <9871D200-B789-4D36-AEC6-3C6C4FE1318C@macports.org> On May 16, 2009, at 14:40, Toby Peterson wrote: >>> On May 16, 2009, at 02:57, Toby Peterson wrote: >>> >>>> Most configure scripts will just use "$CC -E" if CPP isn't >>>> specified >>>> explicitly, which is what I'm taking advantage of there. And, if >>>> you >>>> run nearly any configure script with no special setup: >>>> >>>> checking how to run the C preprocessor... gcc -E >>>> >>>> I'd vote for just never setting CPP, but setting it to "$CC -E" >>>> would >>>> probably work too. > > Many/most ports that do use $CPP probably only run it on one file, in > which case it will behave as expected. Also, I have run into this > before: http://trac.macports.org/changeset/40070 Ok, I didn't realize. r40070 clears configure.cpp for sdcc. In r51272 I see you removed setting CPP in base for gcc 4.2 only. This surprised me because we never talked about removing this for gcc 4.2 only; I thought we were talking about making or not making general changes to MacPorts. And I'm worried r51272 will break ports that try to use ${configure.cpp} -- we currently have a few that do, in an effort to ensure they are using the right compiler: http://trac.macports.org/wiki/UsingTheRightCompiler We were pondering recently why Xorg software looks for the variable RAWCPP instead of CPP: http://trac.macports.org/ticket/20190 It dawned on me that this probably is related to what you were saying. What if MacPorts were to grow a new variable, configure.rawcpp, containing the path to cpp (i.e. what configure.cpp has been thus far), and change configure.cpp to be "${configure.cc} - E"? Would that be consistent with the intended use of these environment variables? From toby at apple.com Wed Jul 29 09:35:59 2009 From: toby at apple.com (Toby Peterson) Date: Wed, 29 Jul 2009 09:35:59 -0700 Subject: [51027] trunk/dports/devel In-Reply-To: <9871D200-B789-4D36-AEC6-3C6C4FE1318C@macports.org> References: <20090515185534.411FA1A0CFDD@beta.macosforge.org> <178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org> <74c219d30905160057t2a8f8d2cn18a1881c82f81c3a@mail.gmail.com> <147D87D8-6AEA-4CCC-9C26-E659190588D2@macports.org> <4A0E81C8.5030707@macports.org> <74c219d30905161240u2ce39257p81e04b49f07d9ba9@mail.gmail.com> <9871D200-B789-4D36-AEC6-3C6C4FE1318C@macports.org> Message-ID: <4A618261-BE70-40C8-8FC7-3693AAE7FF36@apple.com> On Jul 29, 2009, at 5:38 AM, Ryan Schmidt wrote: > On May 16, 2009, at 14:40, Toby Peterson wrote: > >>>> On May 16, 2009, at 02:57, Toby Peterson wrote: >>>> >>>>> Most configure scripts will just use "$CC -E" if CPP isn't >>>>> specified >>>>> explicitly, which is what I'm taking advantage of there. And, if >>>>> you >>>>> run nearly any configure script with no special setup: >>>>> >>>>> checking how to run the C preprocessor... gcc -E >>>>> >>>>> I'd vote for just never setting CPP, but setting it to "$CC -E" >>>>> would >>>>> probably work too. >> >> Many/most ports that do use $CPP probably only run it on one file, in >> which case it will behave as expected. Also, I have run into this >> before: http://trac.macports.org/changeset/40070 > > Ok, I didn't realize. r40070 clears configure.cpp for sdcc. > > In r51272 I see you removed setting CPP in base for gcc 4.2 only. > This surprised me because we never talked about removing this for > gcc 4.2 only; I thought we were talking about making or not making > general changes to MacPorts. And I'm worried r51272 will break ports > that try to use ${configure.cpp} -- we currently have a few that do, > in an effort to ensure they are using the right compiler: > > http://trac.macports.org/wiki/UsingTheRightCompiler > > We were pondering recently why Xorg software looks for the variable > RAWCPP instead of CPP: > > http://trac.macports.org/ticket/20190 > > It dawned on me that this probably is related to what you were > saying. What if MacPorts were to grow a new variable, > configure.rawcpp, containing the path to cpp (i.e. what > configure.cpp has been thus far), and change configure.cpp to be "$ > {configure.cc} -E"? Would that be consistent with the intended use > of these environment variables? Setting CPP explicitly qualifies as "trying too hard". Nearly every port in existence will use "$(CC) -E", so setting CC is sufficient. The intended use of the CPP environment variable is to not set it at all. :) I changed it for gcc-4.2 only, so as to not affect current behavior on older OS releases. - Toby From ryandesign at macports.org Wed Jul 29 13:30:15 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 29 Jul 2009 15:30:15 -0500 Subject: [51027] trunk/dports/devel In-Reply-To: <4A618261-BE70-40C8-8FC7-3693AAE7FF36@apple.com> References: <20090515185534.411FA1A0CFDD@beta.macosforge.org> <178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org> <74c219d30905160057t2a8f8d2cn18a1881c82f81c3a@mail.gmail.com> <147D87D8-6AEA-4CCC-9C26-E659190588D2@macports.org> <4A0E81C8.5030707@macports.org> <74c219d30905161240u2ce39257p81e04b49f07d9ba9@mail.gmail.com> <9871D200-B789-4D36-AEC6-3C6C4FE1318C@macports.org> <4A618261-BE70-40C8-8FC7-3693AAE7FF36@apple.com> Message-ID: <850D2660-187E-4738-859C-9286E79D3B41@macports.org> On Jul 29, 2009, at 11:35, Toby Peterson wrote: > Setting CPP explicitly qualifies as "trying too hard". Nearly every > port in existence will use "$(CC) -E", so setting CC is sufficient. > The intended use of the CPP environment variable is to not set it > at all. :) > > I changed it for gcc-4.2 only, so as to not affect current behavior > on older OS releases. I don't think this needs to be something that varies by OS version. If you say setting CPP is not necessary, and will not result in more ports trying to use "cpp" or "gcc", then how about we just rename configure.cpp to configure.rawcpp (so MacPorts sets RAWCPP and not CPP)? We would need to handle the existing ports that use configure.cpp carefully but long-term does this sound like an ok plan? From toby at apple.com Wed Jul 29 13:38:59 2009 From: toby at apple.com (Toby Peterson) Date: Wed, 29 Jul 2009 13:38:59 -0700 Subject: [51027] trunk/dports/devel In-Reply-To: <850D2660-187E-4738-859C-9286E79D3B41@macports.org> References: <20090515185534.411FA1A0CFDD@beta.macosforge.org> <178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org> <74c219d30905160057t2a8f8d2cn18a1881c82f81c3a@mail.gmail.com> <147D87D8-6AEA-4CCC-9C26-E659190588D2@macports.org> <4A0E81C8.5030707@macports.org> <74c219d30905161240u2ce39257p81e04b49f07d9ba9@mail.gmail.com> <9871D200-B789-4D36-AEC6-3C6C4FE1318C@macports.org> <4A618261-BE70-40C8-8FC7-3693AAE7FF36@apple.com> <850D2660-187E-4738-859C-9286E79D3B41@macports.org> Message-ID: On Jul 29, 2009, at 1:30 PM, Ryan Schmidt wrote: > On Jul 29, 2009, at 11:35, Toby Peterson wrote: > >> Setting CPP explicitly qualifies as "trying too hard". Nearly every >> port in existence will use "$(CC) -E", so setting CC is sufficient. >> The intended use of the CPP environment variable is to not set it >> at all. :) >> >> I changed it for gcc-4.2 only, so as to not affect current behavior >> on older OS releases. > > I don't think this needs to be something that varies by OS version. > > If you say setting CPP is not necessary, and will not result in more > ports trying to use "cpp" or "gcc", then how about we just rename > configure.cpp to configure.rawcpp (so MacPorts sets RAWCPP and not > CPP)? We would need to handle the existing ports that use > configure.cpp carefully but long-term does this sound like an ok plan? I'd be in favor of not setting CPP at all, and setting RAWCPP makes even less sense considering that only a few ports use it. If we want to make sure the configure.cpp variable is set, we can keep it set (to "${configure.cc} -E") and just not set the environment variable. - Toby From msavory1 at nzbox.com Wed Jul 29 17:17:01 2009 From: msavory1 at nzbox.com (Mike Savory) Date: Wed, 29 Jul 2009 17:17:01 -0700 Subject: [MacPorts] #18156: scapy still depends on Python 2.4 In-Reply-To: <063.29e26cf6868dcdc69bfcdcbe2ed8762f@macports.org> References: <054.dfa7510912a50ba4183b907aad4c4389@macports.org> <063.29e26cf6868dcdc69bfcdcbe2ed8762f@macports.org> Message-ID: <297485D7-169B-47E5-9AC0-5A344248192F@nzbox.com> Good point, the reinplaces will fail Scapy 2 is now a Framework, and actually needs to be installed, whereas 1.2 was just a single python file. This goes back to my suggestion to have a new scapy2 port Mike On Jul 29, 2009, at 8:16 AM, MacPorts wrote: > #18156: scapy still depends on Python 2.4 > -------------------------------- > +------------------------------------------- > Reporter: jwiegley@? | Owner: pmq@? > Type: update | Status: assigned > Priority: Normal | Milestone: > Component: ports | Version: 1.7.1 > Keywords: | Port: scapy > -------------------------------- > +------------------------------------------- > > Comment(by pmq@?): > > Diff looks fine to me. Unsure wether the reinplaces still work. > > -- > Ticket URL: > MacPorts > Ports system for Mac OS > From ryandesign at macports.org Thu Jul 30 00:05:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 30 Jul 2009 02:05:38 -0500 Subject: [51027] trunk/dports/devel In-Reply-To: References: <20090515185534.411FA1A0CFDD@beta.macosforge.org> <178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org> <74c219d30905160057t2a8f8d2cn18a1881c82f81c3a@mail.gmail.com> <147D87D8-6AEA-4CCC-9C26-E659190588D2@macports.org> <4A0E81C8.5030707@macports.org> <74c219d30905161240u2ce39257p81e04b49f07d9ba9@mail.gmail.com> <9871D200-B789-4D36-AEC6-3C6C4FE1318C@macports.org> <4A618261-BE70-40C8-8FC7-3693AAE7FF36@apple.com> <850D2660-187E-4738-859C-9286E79D3B41@macports.org> Message-ID: On Jul 29, 2009, at 15:38, Toby Peterson wrote: > On Jul 29, 2009, at 1:30 PM, Ryan Schmidt wrote: > >> On Jul 29, 2009, at 11:35, Toby Peterson wrote: >> >>> If you say setting CPP is not necessary, and will not result in >>> more ports trying to use "cpp" or "gcc", then how about we just >>> rename configure.cpp to configure.rawcpp (so MacPorts sets RAWCPP >>> and not CPP)? We would need to handle the existing ports that use >>> configure.cpp carefully but long-term does this sound like an ok >>> plan? > > I'd be in favor of not setting CPP at all, and setting RAWCPP makes > even less sense considering that only a few ports use it. > > If we want to make sure the configure.cpp variable is set, we can > keep it set (to "${configure.cc} -E") and just not set the > environment variable. I don't care what variables are set to what; I care that a port that needs to know where cpp is will be able to find it. If we don't set CPP or RAWCPP, how will we tell e.g. the xorg ports where cpp is? To take an example, edit the xorg-server port and replace configure.env-append \ RAWCPP=${configure.cpp} with configure.env-append \ RAWCPP="${configure.cc} -E" and it will no longer work. As far as I can tell xorg-server and other xorg ports need access to cpp, not $CC -E, and for the reasons outlined in UsingTheRightCompiler we don't want them to use "cpp" (which is what they will use if we do not set RAWCPP as we do in the port); we want them to use the correct version of cpp that matches configure.compiler, e.g. the path we currently define in configure.cpp and which I'm proposing we move to configure.rawcpp. From toby at apple.com Thu Jul 30 00:36:41 2009 From: toby at apple.com (Toby Peterson) Date: Thu, 30 Jul 2009 00:36:41 -0700 Subject: [51027] trunk/dports/devel In-Reply-To: References: <20090515185534.411FA1A0CFDD@beta.macosforge.org> <178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org> <74c219d30905160057t2a8f8d2cn18a1881c82f81c3a@mail.gmail.com> <147D87D8-6AEA-4CCC-9C26-E659190588D2@macports.org> <4A0E81C8.5030707@macports.org> <74c219d30905161240u2ce39257p81e04b49f07d9ba9@mail.gmail.com> <9871D200-B789-4D36-AEC6-3C6C4FE1318C@macports.org> <4A618261-BE70-40C8-8FC7-3693AAE7FF36@apple.com> <850D2660-187E-4738-859C-9286E79D3B41@macports.org> Message-ID: <76CF494E-621D-4AA1-8C3C-8D32A4AD8A36@apple.com> On Jul 30, 2009, at 12:05 AM, Ryan Schmidt wrote: > On Jul 29, 2009, at 15:38, Toby Peterson wrote: > >> On Jul 29, 2009, at 1:30 PM, Ryan Schmidt wrote: >> >>> On Jul 29, 2009, at 11:35, Toby Peterson wrote: >>> >>>> If you say setting CPP is not necessary, and will not result in >>>> more ports trying to use "cpp" or "gcc", then how about we just >>>> rename configure.cpp to configure.rawcpp (so MacPorts sets RAWCPP >>>> and not CPP)? We would need to handle the existing ports that use >>>> configure.cpp carefully but long-term does this sound like an ok >>>> plan? >> >> I'd be in favor of not setting CPP at all, and setting RAWCPP makes >> even less sense considering that only a few ports use it. >> >> If we want to make sure the configure.cpp variable is set, we can >> keep it set (to "${configure.cc} -E") and just not set the >> environment variable. > > I don't care what variables are set to what; I care that a port that > needs to know where cpp is will be able to find it. If we don't set > CPP or RAWCPP, how will we tell e.g. the xorg ports where cpp is? > > To take an example, edit the xorg-server port and replace > > configure.env-append \ > RAWCPP=${configure.cpp} > > with > > configure.env-append \ > RAWCPP="${configure.cc} -E" > > and it will no longer work. As far as I can tell xorg-server and > other xorg ports need access to cpp, not $CC -E, and for the reasons > outlined in UsingTheRightCompiler we don't want them to use > "cpp" (which is what they will use if we do not set RAWCPP as we do > in the port); we want them to use the correct version of cpp that > matches configure.compiler, e.g. the path we currently define in > configure.cpp and which I'm proposing we move to configure.rawcpp. Just use ${configure.cpp} - see fix in http://trac.macports.org/changeset/54609 - Toby From jameskyle at macports.org Thu Jul 30 17:11:44 2009 From: jameskyle at macports.org (James Kyle) Date: Thu, 30 Jul 2009 17:11:44 -0700 Subject: Install phase changes permissions Message-ID: <7C652451-B5C8-4A2E-B1D3-3DFBB1288A60@macports.org> It appears the install phase is changing file and directory ownership from that specified and assigned in the destroot. For example: sudo port destroot backuppc ls -ld work/destroot/${destroot}${prefix}/var/backups drwxrwx--- 7 backuppc backuppc 272 Jul 30 17:08 work/destroot/$ {destroot}${prefix}/var/backups And after install: ls -ld ${prefix}/var/backups drwxrwx--- 7 root backuppc 272 Jul 30 17:09 ${prefix}/var/backups How can I prevent this? Do I need to do a post-install and change the permissions manually? -james From anil at recoil.org Thu Jul 30 07:39:36 2009 From: anil at recoil.org (Anil Madhavapeddy) Date: Thu, 30 Jul 2009 15:39:36 +0100 Subject: -j2 default and sudo usage Message-ID: <72C85ABB-6D99-4F7A-ACD9-F09549093A28@recoil.org> Couple of questions: Just installed the svn macports, and ports seem to build with -j2 now by default. Is this a recent change, since loads of OCaml ports break with a parallel build. Should I go around setting each individual port to have a -j1 in the Portfile, or is there some other way to force a non-parallel build with a variable? Also, how do folks typically do non-root builds to ensure stuff isn't sneaking out of the fakeroot? I've chowned a bunch of directories to my user, and manually invoking fakeroot works; it would be nice if sudo were automatically called when required (e.g. for install). Is there a knob for this, or do you generally just invoke targets manually and add sudo when required? -anil From jeremy at lavergne.gotdns.org Thu Jul 30 19:27:29 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 30 Jul 2009 22:27:29 -0400 Subject: -j2 default and sudo usage In-Reply-To: <72C85ABB-6D99-4F7A-ACD9-F09549093A28@recoil.org> References: <72C85ABB-6D99-4F7A-ACD9-F09549093A28@recoil.org> Message-ID: <87157531-070B-4739-BBFC-35FDB40A2C49@lavergne.gotdns.org> On Jul 30, 2009, at 10:39 AM, Anil Madhavapeddy wrote: > Couple of questions: > > Just installed the svn macports, and ports seem to build with -j2 > now by default. Is this a recent change, since loads of OCaml ports > break with a parallel build. Should I go around setting each > individual port to have a -j1 in the Portfile, or is there some > other way to force a non-parallel build with a variable? MacPorts figures out how many cores are available and uses them. Disable this by using `use_parallel_build no` -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From toby at apple.com Thu Jul 30 19:52:20 2009 From: toby at apple.com (Toby Peterson) Date: Thu, 30 Jul 2009 19:52:20 -0700 Subject: -j2 default and sudo usage In-Reply-To: <72C85ABB-6D99-4F7A-ACD9-F09549093A28@recoil.org> References: <72C85ABB-6D99-4F7A-ACD9-F09549093A28@recoil.org> Message-ID: If you run across ports that don't build in parallel, they should have "use_parallel_build no" set. If you don't want to bother modifying (and reporting) those ports, you can set "buildmakejobs 1" in macports.conf - Toby On Jul 30, 2009, at 7:39 AM, Anil Madhavapeddy wrote: > Couple of questions: > > Just installed the svn macports, and ports seem to build with -j2 > now by default. Is this a recent change, since loads of OCaml ports > break with a parallel build. Should I go around setting each > individual port to have a -j1 in the Portfile, or is there some > other way to force a non-parallel build with a variable? > > Also, how do folks typically do non-root builds to ensure stuff > isn't sneaking out of the fakeroot? I've chowned a bunch of > directories to my user, and manually invoking fakeroot works; it > would be nice if sudo were automatically called when required (e.g. > for install). Is there a knob for this, or do you generally just > invoke targets manually and add sudo when required? > > -anil > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From talklists at newgeo.com Thu Jul 30 20:05:38 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 30 Jul 2009 20:05:38 -0700 Subject: memtester diff has been submitted Message-ID: I have updated memtesters port to the newest release. This has been tested and builds locally as it did before. Initially it did not, but I worked with the developer to get it to build clean on Mac OS X. https://trac.macports.org/ticket/20493 -- Scott * If you contact me off list replace talklists@ with scott@ * From jmr at macports.org Thu Jul 30 22:19:05 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 31 Jul 2009 15:19:05 +1000 Subject: -j2 default and sudo usage In-Reply-To: References: <72C85ABB-6D99-4F7A-ACD9-F09549093A28@recoil.org> Message-ID: <4A727EC9.3040306@macports.org> On 2009-7-31 12:52, Toby Peterson wrote: > If you run across ports that don't build in parallel, they should have > "use_parallel_build no" set. If you don't want to bother modifying (and > reporting) those ports, you can set "buildmakejobs 1" in macports.conf Please do report them if you've got the time though. We may yet change the default buildmakejobs back to 1 on the upcoming 1.8 branch, since people don't necessarily want port building to use all of their system resources. - Josh From toby at apple.com Thu Jul 30 22:36:16 2009 From: toby at apple.com (Toby Peterson) Date: Thu, 30 Jul 2009 22:36:16 -0700 Subject: -j2 default and sudo usage In-Reply-To: <72C85ABB-6D99-4F7A-ACD9-F09549093A28@recoil.org> References: <72C85ABB-6D99-4F7A-ACD9-F09549093A28@recoil.org> Message-ID: <00BD7403-7885-4638-8BE4-2445F02CF16A@apple.com> On Jul 30, 2009, at 7:39 AM, Anil Madhavapeddy wrote: > Also, how do folks typically do non-root builds to ensure stuff > isn't sneaking out of the fakeroot? I've chowned a bunch of > directories to my user, and manually invoking fakeroot works; it > would be nice if sudo were automatically called when required (e.g. > for install). Is there a knob for this, or do you generally just > invoke targets manually and add sudo when required? We do attempt to drop privileges when possible, but ports may still end up writing to incorrect places during certain phases. If I'm feeling particularly paranoid, I do the following: port -d destroot sudo port -d install - Toby From takeshi at macports.org Fri Jul 31 06:05:41 2009 From: takeshi at macports.org (Takeshi Enomoto) Date: Fri, 31 Jul 2009 22:05:41 +0900 Subject: portname with + In-Reply-To: <8DA5933A-264F-4945-9A5B-CFB15A59EA80@macports.org> References: <2dc53b910907261457p7b34d809t4dd3475ff97cc269@mail.gmail.com> <9307372D-2C91-4211-923D-6C79CCDEAFF9@apple.com> <2dc53b910907270605l5e4c24e4s8b553108843d022@mail.gmail.com> <8DA5933A-264F-4945-9A5B-CFB15A59EA80@macports.org> Message-ID: <2dc53b910907310605m6feb782emf72b7e4f84682d16@mail.gmail.com> Ryan, Thank you for your comments. > MacPorts 1.8.0 will have a "replaced_by" keyword which will make stub ports simpler. I myself experienced problem of conflicts between vis5d and vis5d+ but I don't think there are many users of this package so I can handle if a user email me. I used port 1.8.0 for a while but I reinstalled 1.7.1 since -arch options and default parallel build can cause problems. >> It would be nice if port lint could check characters port name may use. > > That would be a good idea. Could you file a ticket for that? I will. From ryandesign at macports.org Fri Jul 31 10:48:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 31 Jul 2009 12:48:13 -0500 Subject: [51027] trunk/dports/devel In-Reply-To: <76CF494E-621D-4AA1-8C3C-8D32A4AD8A36@apple.com> References: <20090515185534.411FA1A0CFDD@beta.macosforge.org> <178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org> <74c219d30905160057t2a8f8d2cn18a1881c82f81c3a@mail.gmail.com> <147D87D8-6AEA-4CCC-9C26-E659190588D2@macports.org> <4A0E81C8.5030707@macports.org> <74c219d30905161240u2ce39257p81e04b49f07d9ba9@mail.gmail.com> <9871D200-B789-4D36-AEC6-3C6C4FE1318C@macports.org> <4A618261-BE70-40C8-8FC7-3693AAE7FF36@apple.com> <850D2660-187E-4738-859C-9286E79D3B41@macports.org> <76CF494E-621D-4AA1-8C3C-8D32A4AD8A36@apple.com> Message-ID: On Jul 30, 2009, at 02:36, Toby Peterson wrote: > Just use ${configure.cpp} - see fix in http://trac.macports.org/ > changeset/54609 Thanks, that's even easier in that we won't have to touch the ports that already use ${configure.cpp}. From anil at recoil.org Fri Jul 31 07:57:13 2009 From: anil at recoil.org (Anil Madhavapeddy) Date: Fri, 31 Jul 2009 15:57:13 +0100 Subject: -j2 default and sudo usage In-Reply-To: <00BD7403-7885-4638-8BE4-2445F02CF16A@apple.com> References: <72C85ABB-6D99-4F7A-ACD9-F09549093A28@recoil.org> <00BD7403-7885-4638-8BE4-2445F02CF16A@apple.com> Message-ID: <20090731145713.GB165@fork.recoil.org> On Thu, Jul 30, 2009 at 10:36:16PM -0700, Toby Peterson wrote: > On Jul 30, 2009, at 7:39 AM, Anil Madhavapeddy wrote: > >> Also, how do folks typically do non-root builds to ensure stuff isn't >> sneaking out of the fakeroot? I've chowned a bunch of directories to my >> user, and manually invoking fakeroot works; it would be nice if sudo were >> automatically called when required (e.g. for install). Is there a knob >> for this, or do you generally just invoke targets manually and add sudo >> when required? > > We do attempt to drop privileges when possible, but ports may still end up > writing to incorrect places during certain phases. If I'm feeling > particularly paranoid, I do the following: > > port -d destroot > > sudo port -d install I'm having an utterly bizarre issue while porting ocsigen. If I run the whole port build under sudo, it does something which results in: shock avsm$ sudo ls Illegal instruction shock avsm$ md5 /usr/bin/sudo md5: /usr/bin/sudo: Permission denied shock avsm$ ls -la /usr/bin/sudo -r-s--x--x 1 root wheel 211232 24 Sep 2007 /usr/bin/sudo shock avsm$ ls -la /dev/null ls: /dev/null: No such file or directory A reboot corrects the issue, and it happens every time. If I run the port destroot target without sudo, then it works fine and doesn't appear to have any denied commands; so I was looking for a way to explictly raise privileges and examine the command before it was run as root. Does this sort of problem ring any bells with anyone? -- Anil Madhavapeddy http://anil.recoil.org From anil at recoil.org Fri Jul 31 07:52:50 2009 From: anil at recoil.org (Anil Madhavapeddy) Date: Fri, 31 Jul 2009 15:52:50 +0100 Subject: -j2 default and sudo usage In-Reply-To: References: <72C85ABB-6D99-4F7A-ACD9-F09549093A28@recoil.org> Message-ID: <20090731145250.GA165@fork.recoil.org> That works great; I've left my global setting at the default 0. The problem with leaving this the release default is that lots of my ports (but I bet others too) fail silently if using recursive sub-makes and only install a partial collection of files and a broken port. I'll submit tickets to mark my relevant ports correctly as single-build only. -anil On Thu, Jul 30, 2009 at 07:52:20PM -0700, Toby Peterson wrote: > If you run across ports that don't build in parallel, they should have > "use_parallel_build no" set. If you don't want to bother modifying (and > reporting) those ports, you can set "buildmakejobs 1" in macports.conf > > - Toby > > On Jul 30, 2009, at 7:39 AM, Anil Madhavapeddy wrote: > >> Couple of questions: >> >> Just installed the svn macports, and ports seem to build with -j2 now by >> default. Is this a recent change, since loads of OCaml ports break with a >> parallel build. Should I go around setting each individual port to have a >> -j1 in the Portfile, or is there some other way to force a non-parallel >> build with a variable? >> >> Also, how do folks typically do non-root builds to ensure stuff isn't >> sneaking out of the fakeroot? I've chowned a bunch of directories to my >> user, and manually invoking fakeroot works; it would be nice if sudo were >> automatically called when required (e.g. for install). Is there a knob >> for this, or do you generally just invoke targets manually and add sudo >> when required? >> >> -anil >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -- Anil Madhavapeddy http://anil.recoil.org From ryandesign at macports.org Fri Jul 31 13:30:19 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 31 Jul 2009 15:30:19 -0500 Subject: -j2 default and sudo usage In-Reply-To: <20090731145713.GB165@fork.recoil.org> References: <72C85ABB-6D99-4F7A-ACD9-F09549093A28@recoil.org> <00BD7403-7885-4638-8BE4-2445F02CF16A@apple.com> <20090731145713.GB165@fork.recoil.org> Message-ID: <31CABBD3-95B1-483F-8201-CAE6758910BD@macports.org> On Jul 31, 2009, at 09:57, Anil Madhavapeddy wrote: > shock avsm$ ls -la /dev/null > ls: /dev/null: No such file or directory > > A reboot corrects the issue, and it happens every time. [snip] > Does this sort of problem ring any bells with anyone? Yes, installing mysql5-devel +innodb would do this too if I had not applied this patch: http://trac.macports.org/browser/trunk/dports/databases/mysql5-devel/ files/patch-storage-innobase-Makefile.in.diff?rev=50049 Check if your software is compiling anything like that, using "-o / dev/null". Apparently at least on Mac OS X, when this fails, /dev/ null gets deleted, causing great problems of course. From ryandesign at macports.org Fri Jul 31 13:53:19 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 31 Jul 2009 15:53:19 -0500 Subject: [54617] trunk/dports/sysutils In-Reply-To: <20090730130257.A8DC72253080@beta.macosforge.org> References: <20090730130257.A8DC72253080@beta.macosforge.org> Message-ID: These comments apply to the five ports added recently in r54617 (log4shib), r54618 (xercesc3), r54619 (xml-security-c), r54621 (xmltooling), and r54623 (opensaml). On Jul 30, 2009, at 08:02, snc at macports.org wrote: > +revision 1 Don't change it now, but keep in mind for the future that the first revision of any given version of a port should be zero, not one. You can either write "revision 0" or leave out the revision line altogether. > +platform darwin 8 { > + configure.env-append MACOSX_DEPLOYMENT_TARGET=10.4 > + build.env-append MACOSX_DEPLOYMENT_TARGET=10.4 > + destroot.env-append MACOSX_DEPLOYMENT_TARGET=10.4 > +} MacPorts automatically sets MACOSX_DEPLOYMENT_TARGET to 10.4 on Mac OS X 10.4 so this block is unnecessary and should be removed. > +platform darwin 9 { > + configure.env-append MACOSX_DEPLOYMENT_TARGET=10.4 > + build.env-append MACOSX_DEPLOYMENT_TARGET=10.4 > + destroot.env-append MACOSX_DEPLOYMENT_TARGET=10.4 > +} The more straightforward way to set MACOSX_DEPLOYMENT_TARGET to 10.4 on Mac OS X 10.5 would be to use configure.macosx_deployment_target 10.4 But I wanted to ask if it's really necessary to do this. Do all of these ports really not work with MACOSX_DEPLOYMENT_TARGET set to the default value of 10.5 on Mac OS X 10.5? They all installed for me even if I removed this block. From anil at recoil.org Fri Jul 31 14:06:15 2009 From: anil at recoil.org (Anil Madhavapeddy) Date: Fri, 31 Jul 2009 22:06:15 +0100 Subject: -j2 default and sudo usage In-Reply-To: <31CABBD3-95B1-483F-8201-CAE6758910BD@macports.org> References: <72C85ABB-6D99-4F7A-ACD9-F09549093A28@recoil.org> <00BD7403-7885-4638-8BE4-2445F02CF16A@apple.com> <20090731145713.GB165@fork.recoil.org> <31CABBD3-95B1-483F-8201-CAE6758910BD@macports.org> Message-ID: <569DA4FF-DCC3-41E1-A8C2-C456D492A229@recoil.org> On 31 Jul 2009, at 21:30, Ryan Schmidt wrote: > > Yes, installing mysql5-devel +innodb would do this too if I had not > applied this patch: > > http://trac.macports.org/browser/trunk/dports/databases/mysql5-devel/files/patch-storage-innobase-Makefile.in.diff?rev=50049 > > Check if your software is compiling anything like that, using "-o / > dev/null". Apparently at least on Mac OS X, when this fails, /dev/ > null gets deleted, causing great problems of course. > Ahh, thats exactly what it was... in the configure script. Thanks! -anil -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at lavergne.gotdns.org Fri Jul 31 17:06:43 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 31 Jul 2009 20:06:43 -0400 Subject: [54617] trunk/dports/sysutils In-Reply-To: References: <20090730130257.A8DC72253080@beta.macosforge.org> Message-ID: On Jul 31, 2009, at 4:53 PM, Ryan Schmidt wrote: > These comments apply to the five ports added recently in r54617 > (log4shib), r54618 (xercesc3), r54619 (xml-security-c), r54621 > (xmltooling), and r54623 (opensaml). > > On Jul 30, 2009, at 08:02, snc at macports.org wrote: > >> +revision 1 > > Don't change it now, but keep in mind for the future that the first > revision of any given version of a port should be zero, not one. You > can either write "revision 0" or leave out the revision line > altogether. I did this on purpose to give users increased versions from what was manually installed per the port's homepage install instructions. Users presently have these portfiles installed manually in a local tree with revision 1. By using revision 1 on our own ports that are presently identical, any updates will result in revision 2 -- allowing ours to take over upon upgrade. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Fri Jul 31 23:00:25 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 1 Aug 2009 01:00:25 -0500 Subject: [54617] trunk/dports/sysutils In-Reply-To: References: <20090730130257.A8DC72253080@beta.macosforge.org> Message-ID: <1C72F3A3-CC8F-4BD9-B65B-5DA5AF4B13C0@macports.org> On Jul 31, 2009, at 19:06, Jeremy Lavergne wrote: > On Jul 31, 2009, at 4:53 PM, Ryan Schmidt wrote: >> These comments apply to the five ports added recently in r54617 >> (log4shib), r54618 (xercesc3), r54619 (xml-security-c), r54621 >> (xmltooling), and r54623 (opensaml). >> >> On Jul 30, 2009, at 08:02, snc at macports.org wrote: >> >>> +revision 1 >> >> Don't change it now, but keep in mind for the future that the >> first revision of any given version of a port should be zero, not >> one. You can either write "revision 0" or leave out the revision >> line altogether. > > I did this on purpose to give users increased versions from what > was manually installed per the port's homepage install > instructions. Users presently have these portfiles installed > manually in a local tree with revision 1. By using revision 1 on > our own ports that are presently identical, any updates will result > in revision 2 -- allowing ours to take over upon upgrade. Gotcha. I didn't know these ports had been distributed outside the ports tree already.