From blb at macports.org Sun Feb 1 00:38:43 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 1 Feb 2009 01:38:43 -0700 Subject: [46233] trunk/dports/math In-Reply-To: <20090201082920.AE044E10DBB@beta.macosforge.org> References: <20090201082920.AE044E10DBB@beta.macosforge.org> Message-ID: <20090201083843.GL897@ninagal.withay.com> On Sun, Feb 01, 2009 at 12:29:16AM -0800, jmpp at macports.org said: > Revision: 46233 > http://trac.macports.org/changeset/46233 > Author: jmpp at macports.org > Date: 2009-02-01 00:29:04 -0800 (Sun, 01 Feb 2009) > Log Message: > ----------- > New port: mapm 4.9.5, (yet another) arbitrary precision math library in C. [...] > +name mapm > +version 4.9.5 > +categories math science > +platforms darwin > +maintainers jmpp at opendarwin.org I know you've not been too active lately but I'm pretty sure you're aware of the new domain by now...but of course you can just use jmpp anyway. > + > +description A Portable Arbitrary Precision Math Library in C. > +long_description MAMP is a set of functions that allow the user \ MAMP or MAPM? Bryan From ryandesign at macports.org Sun Feb 1 00:51:53 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 1 Feb 2009 02:51:53 -0600 Subject: [46233] trunk/dports/math In-Reply-To: <60979761-CE4E-4CAC-BC23-B60420037826@macports.org> References: <20090201082920.AE044E10DBB@beta.macosforge.org> <60979761-CE4E-4CAC-BC23-B60420037826@macports.org> Message-ID: On Feb 1, 2009, at 02:36, Juan Manuel Palacios wrote: > Hey Ryan! A quick favor I wanted to ask you, if I may. > > I just added the Portfile below to the repo, but my Portfile > writing skills are a bit rusty so I wanted to ask you, if I may, to > please give it a look and let me know if I made any obvious boo- > boos or if there's anything in it that could be achieved in a > simpler way. Of course! I was just about to anyway. :) > Begin forwarded message: > >> From: jmpp at macports.org >> Date: February 1, 2009 3:59:16 AM GMT-04:30 >> To: macports-changes at lists.macosforge.org >> Subject: [46233] trunk/dports/math >> Reply-To: macports-dev at lists.macosforge.org, jmpp at macports.org >> >> Revision >> 46233 >> Author >> jmpp at macports.org >> Date >> 2009-02-01 00:29:04 -0800 (Sun, 01 Feb 2009) >> Log Message >> >> New port: mapm 4.9.5, (yet another) arbitrary precision math >> library in C. >> Added Paths >> >> trunk/dports/math/mapm/ >> trunk/dports/math/mapm/Portfile >> Diff >> >> Added: trunk/dports/math/mapm/Portfile (0 => 46233) >> --- trunk/dports/math/mapm/Portfile (rev 0) >> +++ trunk/dports/math/mapm/Portfile 2009-02-01 08:29:04 UTC (rev >> 46233) >> @@ -0,0 +1,39 @@ >> +# $Id$ >> + >> +PortSystem 1.0 >> + >> +name mapm >> +version 4.9.5 >> +categories math science >> +platforms darwin >> +maintainers jmpp at opendarwin.org >> + >> +description A Portable Arbitrary Precision Math Library in C. >> +long_description MAMP is a set of functions that allow the user \ >> + to perform math to any level of accuracy that >> is desired. \ >> + The precision of a number is only limited by >> 'INT_MAX' \ >> + and available memory. >> + >> +homepage http://www.tc.umn.edu/~ringx004/mapm-main.html >> +master_sites http://www.tc.umn.edu/~ringx004 >> +checksums md5 a92ff86b6240f78f882661e0b1c11920 \ >> + sha1 99dab13404ee30e7a830204da0a66cbae265a8b5 \ >> + rmd160 f4e39962410ea4f9a0d85a3e07b7421e9795d6cb >> + >> +use_configure no >> + >> +worksrcdir ${name}_${version} >> +build.cmd make -f makefile.osx I think this would work better if you replace the build.cmd line with: build.args -f makefile.osx because we currently have the bug/feature that if build.cmd has a space in it, then we never attempt to run the command through "nice"; that was the "fix" for #16091: http://trac.macports.org/ticket/16091 >> +destroot { >> + copy ${worksrcpath}/m_apm.h ${destroot}${prefix}/include >> + copy ${worksrcpath}/libmapm.a ${destroot}${prefix}/lib >> + xinstall -d -m 755 ${destroot}${prefix}/share/${name} >> + copy ${worksrcpath}/DOCS ${destroot}${prefix}/share/${name}/ >> + copy ${worksrcpath}/MULTI_THREAD ${destroot}${prefix}/share/$ >> {name}/ >> + copy ${worksrcpath}/PI_DEMO ${destroot}${prefix}/share/${name}/ >> + copy ${worksrcpath}/README ${destroot}${prefix}/share/${name} >> + foreach prog {calc primenum validate} { >> + copy ${worksrcpath}/$prog ${destroot}${prefix}/bin >> + } >> +} Docs should go in ${prefix}/share/doc/${name} (or perhaps ${prefix}/ share/doc/${name}-${version} -- there was a push for that last year (or before?) but I'm not sure the justification was totally sound). I tend to use "xinstall" in the destroot phase and "copy" in other phases. There's not much difference, I think, in the outcome. But using xinstall you can simplify the above to: destroot { xinstall -m 755 -W ${worksrcpath} \ calc primenum validate \ ${destroot}${prefix}/bin xinstall -m 644 -W ${worksrcpath} m_apm.h ${destroot}${prefix}/include xinstall -m 644 -W ${worksrcpath} libmapm.a ${destroot}${prefix}/lib xinstall -d -m 755 ${destroot}${prefix}/share/doc/${name}-${version} xinstall -m 644 -W ${worksrcpath} \ DOCS MULTI_THREAD PI_DEMO README \ ${destroot}${prefix}/share/doc/${name}-${version} } (Not tested; typos possible...) If you do this change, since it causes the docs to go to a different place, the revision should be incremented. From ryandesign at macports.org Sun Feb 1 01:08:33 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 1 Feb 2009 03:08:33 -0600 Subject: texlive_base: Duplicate symbols in libXt, libXaw In-Reply-To: References: <49770CD6.7070407@macports.org> Message-ID: <1BC236D7-D43E-40B8-AC54-FCA3A6CE4978@macports.org> On Feb 1, 2009, at 00:48, Matthew D. Swank wrote: > Joshua Root writes: > >> Upgrading the outdated ports on a ppc Tiger machine went fine, >> pulling >> in the new X libs, until it got to texlive_base, which failed > > I am also having this problem (Tiger, PPC32). TEX is a reasonably > important > package for me; is there another place we should be reporting this? It has already been reported in the MacPorts issue tracker here: http://trac.macports.org/ticket/18166 There is a patch attached. I will try it now and if it works I will commit it. From jm at poure.com Sun Feb 1 01:21:30 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sun, 01 Feb 2009 10:21:30 +0100 Subject: Help with MacOsX native encoding when using SSH Message-ID: <1233480090.10701.1.camel@debian> Dear friends, I am connecting to a remove MacOsX computer using SSH from a GNU/Linux Debian station. Accents are not displayed well. When I try to svn diff in the SVN tree to send patches, it answers: Ordinateur-de-Bruno:/opt/mports/trunk/dports/audio/libsamplerate kdenlive$ svn diff Index: Portfile =================================================================== svn: Impossible de convertir la cha?\195?\174ne de 'UTF-8' vers l'encodage natif: svn: --- Portfile (r?\195?\169vision 46176) +++ Portfile (copie de travail) How can I connect using MacOsX native encoding in SSH. Any idea? Kind regards, Jean-Michel From ryandesign at macports.org Sun Feb 1 02:25:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 1 Feb 2009 04:25:13 -0600 Subject: Help with MacOsX native encoding when using SSH In-Reply-To: <1233480090.10701.1.camel@debian> References: <1233480090.10701.1.camel@debian> Message-ID: <17F283BA-AD9A-42ED-9CFD-D4A4F36DA167@macports.org> On Feb 1, 2009, at 03:21, Jean-Michel Pour? wrote: > I am connecting to a remove MacOsX computer using SSH from a GNU/Linux > Debian station. > > Accents are not displayed well. When I try to svn diff in the SVN tree > to send patches, it answers: > > Ordinateur-de-Bruno:/opt/mports/trunk/dports/audio/libsamplerate > kdenlive$ svn diff > Index: Portfile > =================================================================== > svn: Impossible de convertir la cha?\195?\174ne de 'UTF-8' vers > l'encodage natif: > svn: --- Portfile (r?\195?\169vision 46176) > +++ Portfile (copie de travail) > > How can I connect using MacOsX native encoding in SSH. Any idea? Set the LANG environment variable to the correct value. On my Tiger system, I set it to "en_US.UTF-8"; you may wish to use a different locale. The encoding of the locale (UTF-8, in my case) must match the encoding that your terminal expects. I have configured my Terminal.app in Tiger to expect UTF-8; check your ssh client to see what encoding it expects. From ryandesign at macports.org Sun Feb 1 02:36:43 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 1 Feb 2009 04:36:43 -0600 Subject: [46233] trunk/dports/math In-Reply-To: References: <20090201082920.AE044E10DBB@beta.macosforge.org> <60979761-CE4E-4CAC-BC23-B60420037826@macports.org> Message-ID: On Feb 1, 2009, at 02:51, Ryan Schmidt wrote: > On Feb 1, 2009, at 02:36, Juan Manuel Palacios wrote: > >>> +destroot { >>> + copy ${worksrcpath}/m_apm.h ${destroot}${prefix}/include >>> + copy ${worksrcpath}/libmapm.a ${destroot}${prefix}/lib >>> + xinstall -d -m 755 ${destroot}${prefix}/share/${name} >>> + copy ${worksrcpath}/DOCS ${destroot}${prefix}/share/${name}/ >>> + copy ${worksrcpath}/MULTI_THREAD ${destroot}${prefix}/share/$ >>> {name}/ >>> + copy ${worksrcpath}/PI_DEMO ${destroot}${prefix}/share/${name}/ >>> + copy ${worksrcpath}/README ${destroot}${prefix}/share/${name} >>> + foreach prog {calc primenum validate} { >>> + copy ${worksrcpath}/$prog ${destroot}${prefix}/bin >>> + } >>> +} > > Docs should go in ${prefix}/share/doc/${name} (or perhaps ${prefix}/ > share/doc/${name}-${version} -- there was a push for that last year > (or before?) but I'm not sure the justification was totally sound). > > I tend to use "xinstall" in the destroot phase and "copy" in other > phases. There's not much difference, I think, in the outcome. But > using xinstall you can simplify the above to: > > destroot { > xinstall -m 755 -W ${worksrcpath} \ > calc primenum validate \ > ${destroot}${prefix}/bin > xinstall -m 644 -W ${worksrcpath} m_apm.h ${destroot}${prefix}/ > include > xinstall -m 644 -W ${worksrcpath} libmapm.a ${destroot}${prefix}/lib > xinstall -d -m 755 ${destroot}${prefix}/share/doc/${name}-${version} > xinstall -m 644 -W ${worksrcpath} \ > DOCS MULTI_THREAD PI_DEMO README \ > ${destroot}${prefix}/share/doc/${name}-${version} > } > > (Not tested; typos possible...) Ok, I'm wrong here in that I thought those all-caps items were files, but in fact DOCS MULTI_THREAD and PI_DEMO are directories and README is a symlink, so xinstall won't work. In that case you will have to use "copy" after all. But you could do it in a foreach loop to simplify it from what you had before. You could symlink DOCS into ${prefix}/share/doc/${name} in case someone is looking for documentation there. There's an additional problem I didn't notice before, which is that it builds using "gcc" but you should fix it so that it builds with whatever's in ${configure.cc}. Adding this to build.args seems to work. Consider enabling the parallel build. It works fine for me. See attached patch. Actually tested this time. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: mapm.diff Type: application/octet-stream Size: 1701 bytes Desc: not available URL: From ryandesign at macports.org Sun Feb 1 02:37:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 1 Feb 2009 04:37:08 -0600 Subject: [46176] trunk/dports/net/wget/Portfile In-Reply-To: <49841445.80800@macports.org> References: <20090131081106.3CA8ADECC6A@beta.macosforge.org> <49841445.80800@macports.org> Message-ID: <4B5A2916-E786-4045-9B5A-ED1BC5920ED7@macports.org> On Jan 31, 2009, at 03:05, Rainer M?ller wrote: > ryandesign at macports.org wrote: > >> +# So that +universal can use gettext and openssl on Tiger; see >> #18276. >> +configure.ldflags-append -liconv >> +if {![variant_isset no_ssl]} { >> + depends_build-append port:pkgconfig >> + configure.ldflags-append [exec ${prefix}/bin/pkg-config -- >> libs libssl] >> +} >> + > > This is not a good idea as you need pkgconfig now installed to parse > this Portfile. The last PortIndex failed because of this. Eep! So sorry. Fixed it. From jm at poure.com Sun Feb 1 04:45:56 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sun, 01 Feb 2009 13:45:56 +0100 Subject: Help with MacOsX native encoding when using SSH In-Reply-To: <17F283BA-AD9A-42ED-9CFD-D4A4F36DA167@macports.org> References: <1233480090.10701.1.camel@debian> <17F283BA-AD9A-42ED-9CFD-D4A4F36DA167@macports.org> Message-ID: <1233492356.6735.0.camel@debian> On Sun, 2009-02-01 at 04:25 -0600, Ryan Schmidt wrote: > > Set the LANG environment variable to the correct value. On my Tiger > system, I set it to "en_US.UTF-8"; you may wish to use a different > locale. Thanks. It works very well now. From jm at poure.com Sun Feb 1 07:20:49 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sun, 01 Feb 2009 16:20:49 +0100 Subject: Installing MacPorts on pure Darwin Message-ID: <1233501649.14232.2.camel@debian> Hello, I would like to set up a dedicated box to manage MacPorts packages. Unfortunately I don't own a MacOsX computer. Can I install MacOsX on a pure Darwin platform? This is not explained on the http://guide.macports.org. But I can read most packages are pure "Darwin", so It may be implicit. Kind regards, Jean-Michel From illogical1 at gmail.com Sun Feb 1 10:41:47 2009 From: illogical1 at gmail.com (Orville Bennett) Date: Sun, 1 Feb 2009 13:41:47 -0500 Subject: [46178] trunk/dports/archivers In-Reply-To: References: <20090131091141.CDFADDED117@beta.macosforge.org> Message-ID: <06A4FBC5-7801-4095-9E0B-A21ED8F8F4E8@gmail.com> On Feb 1, 2009, at 12:50 AM, Ryan Schmidt wrote: > > On Jan 31, 2009, at 03:11, illogic-al at macports.org wrote: > >> Revision: 46178 >> http://trac.macports.org/changeset/46178 >> Author: illogic-al at macports.org >> Date: 2009-01-31 01:11:38 -0800 (Sat, 31 Jan 2009) >> Log Message: >> ----------- >> New portfile libzip. Whatever could that mean? > > I don't know. What does that mean? It means a new dependency for kdeutils4 is up! Something weird though. Whenever I 'sudo port sync' I don't see it in my local ports collection. From jm at poure.com Sun Feb 1 11:46:50 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sun, 01 Feb 2009 20:46:50 +0100 Subject: [MacPorts] #18312: amrwb 7.0.0.2 In-Reply-To: <057.e0e78ffacff1f5ddc9e50cb8bcbdc365@macports.org> References: <048.c34e329320ec26174fc037477ec9e090@macports.org> <057.e0e78ffacff1f5ddc9e50cb8bcbdc365@macports.org> Message-ID: <1233517610.14447.0.camel@debian> On Sun, 2009-02-01 at 17:31 +0000, MacPorts wrote: > Same legal problems as amr-nb. See #16074 and the "Important Legal > Notice" > at [http://www.penguin.cz/~utx/amr] Thanks. From blb at macports.org Sun Feb 1 12:41:10 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 1 Feb 2009 13:41:10 -0700 Subject: [46178] trunk/dports/archivers In-Reply-To: <06A4FBC5-7801-4095-9E0B-A21ED8F8F4E8@gmail.com> References: <20090131091141.CDFADDED117@beta.macosforge.org> <06A4FBC5-7801-4095-9E0B-A21ED8F8F4E8@gmail.com> Message-ID: <20090201204110.GF813@ninagal.withay.com> On Sun, Feb 01, 2009 at 01:41:47PM -0500, Orville Bennett said: > > On Feb 1, 2009, at 12:50 AM, Ryan Schmidt wrote: > >> >> On Jan 31, 2009, at 03:11, illogic-al at macports.org wrote: >> >>> Revision: 46178 >>> http://trac.macports.org/changeset/46178 >>> Author: illogic-al at macports.org >>> Date: 2009-01-31 01:11:38 -0800 (Sat, 31 Jan 2009) >>> Log Message: >>> ----------- >>> New portfile libzip. Whatever could that mean? >> >> I don't know. What does that mean? > It means a new dependency for kdeutils4 is up! Something weird though. > Whenever I 'sudo port sync' I don't see it in my local ports collection. How do you have your MacPorts repository setup, rsync: or file: (with svn)? If the latter, maybe it isn't updating PortIndex due to conflicts perhaps? You can also use 'sudo port -d sync' to see what's going on. Also, FWIW, I see libzip here just fine. Bryan From jmpp at macports.org Sun Feb 1 13:19:47 2009 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun, 1 Feb 2009 16:49:47 -0430 Subject: [46233] trunk/dports/math In-Reply-To: <20090201083843.GL897@ninagal.withay.com> References: <20090201082920.AE044E10DBB@beta.macosforge.org> <20090201083843.GL897@ninagal.withay.com> Message-ID: <89ECE030-7B43-4258-A0A8-96949F3440D8@macports.org> On Feb 1, 2009, at 4:08 AM, Bryan Blackburn wrote: > On Sun, Feb 01, 2009 at 12:29:16AM -0800, jmpp at macports.org said: >> Revision: 46233 >> http://trac.macports.org/changeset/46233 >> Author: jmpp at macports.org >> Date: 2009-02-01 00:29:04 -0800 (Sun, 01 Feb 2009) >> Log Message: >> ----------- >> New port: mapm 4.9.5, (yet another) arbitrary precision math >> library in C. > [...] >> +name mapm >> +version 4.9.5 >> +categories math science >> +platforms darwin >> +maintainers jmpp at opendarwin.org > > I know you've not been too active lately but I'm pretty sure you're > aware of > the new domain by now...but of course you can just use jmpp anyway. Heh, I should be aware, given I wrote all of dp2mp... that should teach me to commit anything at 4:30am, when I'm having trouble understanding even the simplest of installation instructions! (/me takes the opportunity to update his years-old-and-long-since-used Portfile_template file he uses to create ports from scratch.) Corrected in r46254. > > >> + >> +description A Portable Arbitrary Precision Math Library in C. >> +long_description MAMP is a set of functions that allow the user \ > > MAMP or MAPM? Thanks for noticing, I'll correct it in a bit, along with Ryan's suggestions. > > > Bryan > -jmpp From ryandesign at macports.org Sun Feb 1 13:34:01 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 1 Feb 2009 15:34:01 -0600 Subject: free42 (was: Re: [46154] trunk/dports/emulators) In-Reply-To: <20090130172524.79B9ADDDE2B@beta.macosforge.org> References: <20090130172524.79B9ADDDE2B@beta.macosforge.org> Message-ID: <115306A2-EDDB-4540-87CD-B9F481E1B37A@macports.org> On Jan 30, 2009, at 11:25, krischik at macports.org wrote: > Revision: 46154 > http://trac.macports.org/changeset/46154 > Author: krischik at macports.org > Date: 2009-01-30 09:25:19 -0800 (Fri, 30 Jan 2009) > Log Message: > ----------- > Ticket #18207: Free HP-42s Simulator. [snip] > +depends_lib port:gtk2 \ > + path:${prefix}/bin/zsh:zsh This line must read "path:bin/zsh:zsh" to work as intended because variables are not expanded in depspecs. [snip] > + xinstall -m 755 \ > + -W ${filespath} \ > + Free42-Decimal.command.in \ > + ${destroot}${applications_dir}/Free42-Decimal.command > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Free42-Decimal.command > + system "SetFile -a E ${destroot}${applications_dir}/Free42- > Decimal.command" > + xinstall -m 755 \ > + -W ${filespath} \ > + Free42-Binary.command.in \ > + ${destroot}${applications_dir}/Free42-Binary.command > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Free42-Binary.command > + system "SetFile -a E ${destroot}${applications_dir}/Free42- > Binary.command" When I try to install the port I get: sh: line 1: SetFile: command not found Error: Target org.macports.destroot returned: shell command "SetFile - a E /mp/var/macports/build/ _Users_rschmidt_macports_dports_emulators_free42/work/destroot/ Applications/mp/Free42-Decimal.command" returned error 127 Command output: sh: line 1: SetFile: command not found SetFile is not in any of the usual paths but in /Developer/Tools so you'll have to call it by that absolute path if you want to use it. But why do you want to use it? It looks like you're making files invisible. Is that because they look unsightly in the Applications directory? If so, then why are the files there and not placed in a less-visible MacPorts directory, e.g. ${prefix}/libexec/${name}? It looks like these .command files are wrapper scripts around the real program. Wrapper scripts are fine; I do it in the wine port too. But I suggest you change it in this way: 1) Install the wrapper script as ${prefix}/bin/free42. Install the real binary in ${prefix}/libexec/${name}/free42. That way anyone who just types "free42" in the Terminal access your wrapper too. 2) If you want to make the program available in ${applications_dir}, make a minimal application bundle. See for example the post-destroot section of the port lbreakout2. 3) Rewrite the wrapper in sh so that a dependency on the zsh port is not necessary. > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=4 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=tcl foldmethod=marker nospell : We already have the modeline in the first line of the portfile. If these lines are adding things that we don't have in the modeline, what are they and would they be useful to consider adding to our recommended modeline? > Added: trunk/dports/emulators/free42/files/Free42-Binary.command.in > =================================================================== > --- trunk/dports/emulators/free42/files/Free42- > Binary.command.in (rev 0) > +++ trunk/dports/emulators/free42/files/Free42-Binary.command.in > 2009-01-30 17:25:19 UTC (rev 46154) > @@ -0,0 +1,21 @@ > +#!@PREFIX@/bin/zsh > +############################################################## > {{{1 ########## > +# $Author: krischik at users.sourceforge.net $ > +# $Revision: 26 $ > +# $Date: 2009-01-26 19:02:17 +0100 (Mo, 26 Jan 2009) $ > +# $HeadURL: https://macport-staging.googlecode.com/svn/trunk/ > ports/emulators/free42/files/Free42-Binary.command.in $ > +############################################################## }}} > 1 ########## This header is a bit heavy. Other files in MacPorts just use the $Id$ keyword. From ryandesign at macports.org Sun Feb 1 13:36:34 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 1 Feb 2009 15:36:34 -0600 Subject: Installing MacPorts on pure Darwin In-Reply-To: <1233501649.14232.2.camel@debian> References: <1233501649.14232.2.camel@debian> Message-ID: On Feb 1, 2009, at 09:20, Jean-Michel Pour? wrote: > I would like to set up a dedicated box to manage MacPorts packages. > Unfortunately I don't own a MacOsX computer. > > Can I install MacOsX on a pure Darwin platform? > This is not explained on the http://guide.macports.org. > > But I can read most packages are pure "Darwin", so It may be implicit. I assume you mean "Can I install MacPorts on pure Darwin?" The answer is yes, but note that the name of the project was changed from DarwinPorts to MacPorts some time ago to emphasize the fact that it is designed for and tested on Mac OS X, not Darwin. Many ports should work on Darwin, and if you find one that doesn't but should, please file a ticket. To install, I believe you will have to download the source and compile it. There should be instructions for that in the FAQ. From ryandesign at macports.org Sun Feb 1 13:56:15 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 1 Feb 2009 15:56:15 -0600 Subject: [46122] trunk/dports/databases In-Reply-To: <20090129235306.32756DC911F@beta.macosforge.org> References: <20090129235306.32756DC911F@beta.macosforge.org> Message-ID: <2EB046F3-5F27-4AD8-984A-7ABE9DF62B07@macports.org> On Jan 29, 2009, at 17:53, dweber at macports.org wrote: > Revision: 46122 > http://trac.macports.org/changeset/46122 > Author: dweber at macports.org > Date: 2009-01-29 15:53:05 -0800 (Thu, 29 Jan 2009) > Log Message: > ----------- > New port for prior version of libpqxx 2.6.9 > > Added Paths: > ----------- > trunk/dports/databases/libpqxx26/ > trunk/dports/databases/libpqxx26/Portfile [snip] > +depends_lib port:pkgconfig \ > + port:${server} Does this work? I don't think variables are expanded here. From jm at poure.com Sun Feb 1 14:09:33 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sun, 01 Feb 2009 23:09:33 +0100 Subject: [MacPorts] #18316: texlive fails to build while trying to install dirac In-Reply-To: <057.2e303332421032483b426ac507a0c4a7@macports.org> References: <048.cb3730141910a357c458564a209ebba6@macports.org> <057.2e303332421032483b426ac507a0c4a7@macports.org> Message-ID: <1233526173.21974.1.camel@debian> On Sun, 2009-02-01 at 22:01 +0000, MacPorts wrote: > > I'd suggest trying > {{{ > sudo port clean texlive-base > }}} > > and trying again. sudo port clean texlive-base Error: Port texlive-base not found Dear Devans, The problem is that dirac used to build during the week-end and then suddenly it did not build. At the same time libdirac was added to ffmpeg-devel, so I suggest that ffmpeg-devel is not build against dirac at the moment. We cannot break ffmpeg-devel just because something goes wrong. The dirac dependency to ffmpeg-devel is only hours old so it wron't break anything to remove dirac until dependency until the dust comes down in texlive-base. From jeremyhu at macports.org Sun Feb 1 14:09:48 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 1 Feb 2009 14:09:48 -0800 Subject: Installing MacPorts on pure Darwin In-Reply-To: References: <1233501649.14232.2.camel@debian> Message-ID: <60AA081E-7BB0-4206-8A45-6BE2A3C7615A@macports.org> On Feb 1, 2009, at 13:36, Ryan Schmidt wrote: > On Feb 1, 2009, at 09:20, Jean-Michel Pour? wrote: > >> I would like to set up a dedicated box to manage MacPorts packages. >> Unfortunately I don't own a MacOsX computer. >> >> Can I install MacOsX on a pure Darwin platform? >> This is not explained on the http://guide.macports.org. >> >> But I can read most packages are pure "Darwin", so It may be >> implicit. > > I assume you mean "Can I install MacPorts on pure Darwin?" The > answer is yes, but note that the name of the project was changed > from DarwinPorts to MacPorts some time ago to emphasize the fact > that it is designed for and tested on Mac OS X, not Darwin. Many > ports should work on Darwin, and if you find one that doesn't but > should, please file a ticket. One such caveat will likely be X11. The client libs and apps will build, but xorg-server is just for building XQuartz (the "pure" darwin DDX bitrotted and was punted out of xorg-server), so you'll probably need to also install the XFree86 package to get an X11 server. I have no idea if it will work or not. From afb at macports.org Sun Feb 1 14:29:40 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 1 Feb 2009 23:29:40 +0100 Subject: Installing MacPorts on pure Darwin In-Reply-To: <60AA081E-7BB0-4206-8A45-6BE2A3C7615A@macports.org> References: <1233501649.14232.2.camel@debian> <60AA081E-7BB0-4206-8A45-6BE2A3C7615A@macports.org> Message-ID: Jeremy Huddleston: >> I assume you mean "Can I install MacPorts on pure Darwin?" The >> answer is yes, but note that the name of the project was changed >> from DarwinPorts to MacPorts some time ago to emphasize the fact >> that it is designed for and tested on Mac OS X, not Darwin. Many >> ports should work on Darwin, and if you find one that doesn't but >> should, please file a ticket. > > One such caveat will likely be X11. The client libs and apps will > build, but xorg-server is just for building XQuartz (the "pure" > darwin DDX bitrotted and was punted out of xorg-server), so you'll > probably need to also install the XFree86 package to get an X11 > server. I have no idea if it will work or not. There was a system X11 on Darwin 7, and the XFree86 port works fine on Darwin 8. 47M packages/darwin/x86/XFree86-4.5.0_2+puredarwin.x86.tgz 47M packages/darwin/x86/XFree86-4.7.0_0+puredarwin.x86.tgz See the wiki page for Darwin 9... --anders From jonbrenner at gmail.com Sun Feb 1 14:44:30 2009 From: jonbrenner at gmail.com (Jonathon Brenner) Date: Sun, 1 Feb 2009 17:44:30 -0500 Subject: [MacPorts] #18314: ruby19 nosuffix variant In-Reply-To: <065.dcd30d48ab2b33cd594a8f974dd5aef4@macports.org> References: <056.5c3bfeda439d13147db34e37fae1e300@macports.org> <065.dcd30d48ab2b33cd594a8f974dd5aef4@macports.org> Message-ID: I used a "conflicts ruby" directive to prevent problems when the 1.8 port is active on a system. Would that work? I'm new to macports and wasn't sure whether the directive signals conflicts with other ports or just variants. Why would the variant get lost with the next update? As for the reason behind it, I am running 1.9 exclusively and prefer to have no program suffix. I thought the variant was a clean and appropriate way to accomplish that without managing symlinks to each binary distributed with the package (ruby, rdoc, rake, gem, ri, etc.). Jon On Sun, Feb 1, 2009 at 5:27 PM, MacPorts wrote: > #18314: ruby19 nosuffix variant > > ----------------------------------+----------------------------------------- > Reporter: jonbrenner@? | Owner: febeling@? > Type: enhancement | Status: new > Priority: Normal | Milestone: Port Enhancements > Component: ports | Version: 1.7.0 > Keywords: ruby19 suffix | Port: ruby19 > > ----------------------------------+----------------------------------------- > > Comment(by febeling@?): > > There are 2 reasons why I'm not so fond of that idea: > > - It would conflict with ruby 1.8 port > - As things are, the variant would be lost with the next update, and that > would mean the names of executables change with an upgrade. > > Are there strong reasons to add this still? > > -- > Ticket URL: > MacPorts > Ports system for Mac OS > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blb at macports.org Sun Feb 1 14:57:52 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 1 Feb 2009 15:57:52 -0700 Subject: free42 (was: Re: [46154] trunk/dports/emulators) In-Reply-To: <115306A2-EDDB-4540-87CD-B9F481E1B37A@macports.org> References: <20090130172524.79B9ADDDE2B@beta.macosforge.org> <115306A2-EDDB-4540-87CD-B9F481E1B37A@macports.org> Message-ID: <20090201225752.GK813@ninagal.withay.com> On Sun, Feb 01, 2009 at 03:34:01PM -0600, Ryan Schmidt said: [...] > When I try to install the port I get: > > sh: line 1: SetFile: command not found > Error: Target org.macports.destroot returned: shell command "SetFile -a E > /mp/var/macports/build/ > _Users_rschmidt_macports_dports_emulators_free42/work/destroot/ > Applications/mp/Free42-Decimal.command" returned error 127 > Command output: sh: line 1: SetFile: command not found > > SetFile is not in any of the usual paths but in /Developer/Tools so > you'll have to call it by that absolute path if you want to use it. Is that on 10.4? I see SetFile in /usr/bin on 10.5.6, Xcode 3.1.2. So it may only be needed in a darwin 8 platform section if it turns out to be needed. Bryan [...] From blb at macports.org Sun Feb 1 14:59:55 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 1 Feb 2009 15:59:55 -0700 Subject: [46122] trunk/dports/databases In-Reply-To: <2EB046F3-5F27-4AD8-984A-7ABE9DF62B07@macports.org> References: <20090129235306.32756DC911F@beta.macosforge.org> <2EB046F3-5F27-4AD8-984A-7ABE9DF62B07@macports.org> Message-ID: <20090201225955.GL813@ninagal.withay.com> On Sun, Feb 01, 2009 at 03:56:15PM -0600, Ryan Schmidt said: > > On Jan 29, 2009, at 17:53, dweber at macports.org wrote: > >> Revision: 46122 >> http://trac.macports.org/changeset/46122 >> Author: dweber at macports.org >> Date: 2009-01-29 15:53:05 -0800 (Thu, 29 Jan 2009) >> Log Message: >> ----------- >> New port for prior version of libpqxx 2.6.9 >> >> Added Paths: >> ----------- >> trunk/dports/databases/libpqxx26/ >> trunk/dports/databases/libpqxx26/Portfile > > [snip] > >> +depends_lib port:pkgconfig \ >> + port:${server} > > Does this work? I don't think variables are expanded here. Looks like it works fine, 'port info libpqxx26' shows postgresql83 as a dependency, and PortIndex has depends_lib {port:pkgconfig port:postgresql83} Bryan From jmr at macports.org Sun Feb 1 15:01:56 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 02 Feb 2009 10:01:56 +1100 Subject: [46122] trunk/dports/databases In-Reply-To: <2EB046F3-5F27-4AD8-984A-7ABE9DF62B07@macports.org> References: <20090129235306.32756DC911F@beta.macosforge.org> <2EB046F3-5F27-4AD8-984A-7ABE9DF62B07@macports.org> Message-ID: <498629E4.7040305@macports.org> Ryan Schmidt wrote: > > On Jan 29, 2009, at 17:53, dweber at macports.org wrote: > >> Revision: 46122 >> http://trac.macports.org/changeset/46122 >> Author: dweber at macports.org >> Date: 2009-01-29 15:53:05 -0800 (Thu, 29 Jan 2009) >> Log Message: >> ----------- >> New port for prior version of libpqxx 2.6.9 >> >> Added Paths: >> ----------- >> trunk/dports/databases/libpqxx26/ >> trunk/dports/databases/libpqxx26/Portfile > > [snip] > >> +depends_lib port:pkgconfig \ >> + port:${server} > > Does this work? I don't think variables are expanded here. It's only prefix that isn't expanded, and then only in the PortIndex. Other variables will be expanded, but their expanded values in the index will reflect the setup of the system where the index was generated rather than the system at the time of use. - Josh From ryandesign at macports.org Sun Feb 1 15:38:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 1 Feb 2009 17:38:29 -0600 Subject: [46122] trunk/dports/databases In-Reply-To: <498629E4.7040305@macports.org> References: <20090129235306.32756DC911F@beta.macosforge.org> <2EB046F3-5F27-4AD8-984A-7ABE9DF62B07@macports.org> <498629E4.7040305@macports.org> Message-ID: On Feb 1, 2009, at 17:01, Joshua Root wrote: > Ryan Schmidt wrote: > >> On Jan 29, 2009, at 17:53, dweber at macports.org wrote: >> >>> Revision: 46122 >>> http://trac.macports.org/changeset/46122 >>> Author: dweber at macports.org >>> Date: 2009-01-29 15:53:05 -0800 (Thu, 29 Jan 2009) >>> Log Message: >>> ----------- >>> New port for prior version of libpqxx 2.6.9 >>> >>> Added Paths: >>> ----------- >>> trunk/dports/databases/libpqxx26/ >>> trunk/dports/databases/libpqxx26/Portfile >> >> [snip] >> >>> +depends_lib port:pkgconfig \ >>> + port:${server} >> >> Does this work? I don't think variables are expanded here. > > It's only prefix that isn't expanded, Oh, I didn't know that. > and then only in the PortIndex. > Other variables will be expanded, but their expanded values in the > index > will reflect the setup of the system where the index was generated > rather than the system at the time of use. Ow. That's almost worse than not expanding (because it might sort of give the impression of working, for now). I mean for example if you want to use ${x11prefix} in a depspec, then that will break for users of Tiger and earlier the instant we upgrade the portindex machine to Leopard or later since x11prefix will change to something that doesn't exist on Tiger and earlier... From ryandesign at macports.org Sun Feb 1 15:40:00 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 1 Feb 2009 17:40:00 -0600 Subject: free42 (was: Re: [46154] trunk/dports/emulators) In-Reply-To: <20090201225752.GK813@ninagal.withay.com> References: <20090130172524.79B9ADDDE2B@beta.macosforge.org> <115306A2-EDDB-4540-87CD-B9F481E1B37A@macports.org> <20090201225752.GK813@ninagal.withay.com> Message-ID: <2D23063B-1976-4E52-ADCB-ACBE8A476CC8@macports.org> On Feb 1, 2009, at 16:57, Bryan Blackburn wrote: > On Sun, Feb 01, 2009 at 03:34:01PM -0600, Ryan Schmidt said: > [...] >> When I try to install the port I get: >> >> sh: line 1: SetFile: command not found >> Error: Target org.macports.destroot returned: shell command >> "SetFile -a E >> /mp/var/macports/build/ >> _Users_rschmidt_macports_dports_emulators_free42/work/destroot/ >> Applications/mp/Free42-Decimal.command" returned error 127 >> Command output: sh: line 1: SetFile: command not found >> >> SetFile is not in any of the usual paths but in /Developer/Tools so >> you'll have to call it by that absolute path if you want to use it. > > Is that on 10.4? I see SetFile in /usr/bin on 10.5.6, Xcode > 3.1.2. So it > may only be needed in a darwin 8 platform section if it turns out > to be > needed. Yes, this is on Tiger. From ryandesign at macports.org Sun Feb 1 15:40:37 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 1 Feb 2009 17:40:37 -0600 Subject: [MacPorts] #18316: texlive fails to build while trying to install dirac In-Reply-To: <1233526173.21974.1.camel@debian> References: <048.cb3730141910a357c458564a209ebba6@macports.org> <057.2e303332421032483b426ac507a0c4a7@macports.org> <1233526173.21974.1.camel@debian> Message-ID: <1B63DD36-5733-4DCA-AFB5-4A6D24531EAA@macports.org> On Feb 1, 2009, at 16:09, Jean-Michel Pour? wrote: > On Sun, 2009-02-01 at 22:01 +0000, MacPorts wrote: > >> I'd suggest trying >> {{{ >> sudo port clean texlive-base >> }}} >> >> and trying again. > > sudo port clean texlive-base > Error: Port texlive-base not found > > Dear Devans, > > The problem is that dirac used to build during the week-end and then > suddenly it did not build. At the same time libdirac was added to > ffmpeg-devel, so I suggest that ffmpeg-devel is not build against > dirac > at the moment. We cannot break ffmpeg-devel just because something > goes > wrong. The dirac dependency to ffmpeg-devel is only hours old so it > wron't break anything to remove dirac until dependency until the dust > comes down in texlive-base. The port name is texlive_base, not texlive-base. From jmpp at macports.org Sun Feb 1 19:09:56 2009 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun, 1 Feb 2009 22:39:56 -0430 Subject: [46233] trunk/dports/math In-Reply-To: References: <20090201082920.AE044E10DBB@beta.macosforge.org> <60979761-CE4E-4CAC-BC23-B60420037826@macports.org> Message-ID: <1645226A-44CD-4F6C-A192-6CCF0CF0FEE0@macports.org> On Feb 1, 2009, at 6:06 AM, Ryan Schmidt wrote: > Ok, I'm wrong here in that I thought those all-caps items were > files, but in fact DOCS MULTI_THREAD and PI_DEMO are directories and > README is a symlink, so xinstall won't work. In that case you will > have to use "copy" after all. But you could do it in a foreach loop > to simplify it from what you had before. > > You could symlink DOCS into ${prefix}/share/doc/${name} in case > someone is looking for documentation there. > > There's an additional problem I didn't notice before, which is that > it builds using "gcc" but you should fix it so that it builds with > whatever's in ${configure.cc}. Adding this to build.args seems to > work. > > Consider enabling the parallel build. It works fine for me. > > See attached patch. Actually tested this time. :) > Thanks for the patch Ryan, I incorporated most of it and also tested a parallel build, which worked just fine for me too! The only thing I changed from your patch were the two lines: xinstall -m 644 ${worksrcpath}/m_apm.h ${destroot}${prefix}/include xinstall -m 644 ${worksrcpath}/libmapm.a ${destroot}${prefix}/lib since in each I'm only installing a single file so there's no need for xinstall's -W chdir (as opposed to the installation of the three binaries in a single line). Thanks again! Regards,... -jmpp From jm at poure.com Sun Feb 1 23:52:43 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Mon, 02 Feb 2009 08:52:43 +0100 Subject: [MacPorts] #18316: texlive fails to build while trying to install dirac In-Reply-To: <1B63DD36-5733-4DCA-AFB5-4A6D24531EAA@macports.org> References: <048.cb3730141910a357c458564a209ebba6@macports.org> <057.2e303332421032483b426ac507a0c4a7@macports.org> <1233526173.21974.1.camel@debian> <1B63DD36-5733-4DCA-AFB5-4A6D24531EAA@macports.org> Message-ID: <1233561163.6267.1.camel@debian> On Sun, 2009-02-01 at 17:40 -0600, Ryan Schmidt wrote: > > The port name is texlive_base, not texlive-base. > See my bug reports. I cleaned and rebuilt texlive_base and it failed in the end. My macport installation is up to date. x86. I don't care about texlive_base, I am only interested in not breaking ffmpeg-devel. From jeremyhu at macports.org Mon Feb 2 01:20:20 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Mon, 2 Feb 2009 01:20:20 -0800 Subject: Problem installing xorg-server on Tiger In-Reply-To: <20090131204620.GA3021@ruderich.org> References: <20090131204620.GA3021@ruderich.org> Message-ID: Ok, so I played a bit on my Tiger box, and this is a bit odd. As a workaround for now, you can drop x11/xorg-libXfont to version 1.3.3. It's weird because if you autoreconf before compiling, this bug is triggered... which means there's something odd happening in libtool somewhere... hrm... On Jan 31, 2009, at 12:46, Simon Ruderich wrote: > Hi, > > Today I tried to install xorg-server on my Intel Tiger. The > installation worked fine, but when I want to start X11.app in > /Applications/MacPorts I get the following error: > > X11.app: main(): argc=1 > argv[0] = /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin > Waiting for startup parameters via Mach IPC. > X11.app: Could not connect to server (DISPLAY is not set). Starting > X server. > X11.app: Launching /opt/local/bin/startx: > argv[0] = /bin/sh > argv[1] = -c > argv[2] = /opt/local/bin/startx > bootstrap_look_up(): 1102l > font_cache: Scanning user font directories to generate X11 font caches > font_cache: Updating FC cache > /opt/local/bin/font_cache: line 197: /opt/local/bin/fc-cache: No > such file or directory > font_cache: Done > xauth: creating new authority file /Users/simonruderich/.serverauth. > 3088 > > X11.app: do_start_x11_server(): argc=6 > argv[0] = /opt/local/bin/X > argv[1] = :1 > argv[2] = -nolisten > argv[3] = tcp > argv[4] = -auth > argv[5] = /Users/simonruderich/.serverauth.3088 > X11.app: Debug Info: kKLuchrData failed, trying kKLKCHRData. > If you are using a 3rd party keyboard layout, please see http://xquartz.macosforge.org/trac/ticket/154 > Xquartz starting: > X.Org X Server 1.4.2-apple31 > Build Date: 20090131 > (EE) XKB: Couldn't open rules file /opt/local/share/X11/xkb/rules/base > (EE) XKB: Couldn't open rules file /opt/local/share/X11/xkb/rules/base > Could not init font path element /opt/local/share/fonts/misc/, > removing from list! > Could not init font path element /opt/local/share/fonts/TTF/, > removing from list! > Could not init font path element /opt/local/share/fonts/OTF, > removing from list! > Could not init font path element /opt/local/share/fonts/Type1/, > removing from list! > Could not init font path element /opt/local/share/fonts/100dpi/, > removing from list! > Could not init font path element /opt/local/share/fonts/75dpi/, > removing from list! > Could not init font path element /Library/Fonts, removing from list! > Could not init font path element /System/Library/Fonts, removing > from list! > > Fatal server error: > could not open default font 'fixed' > AbortDDX > Quitting Xquartz... > Xquartz: start_x11_server: (ipc/mig) server died > giving up. > xinit: Connection refused (errno 61): unable to connect to X server > xinit: No such process (errno 3): Server error. > > The first error (X11.app: Debug Info: kKLuchrData failed, trying > kKLKCHRData.) can be fixed by using a US keyboard layout (I use a > German one). But I have no idea how to fix the others. > > Thanks for your help, > Simon > -- > + privacy is necessary > + using http://gnupg.org > + public key id: 0x6115F804EFB33229 > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From jeremyhu at macports.org Mon Feb 2 02:15:58 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Mon, 2 Feb 2009 02:15:58 -0800 Subject: Problem installing xorg-server on Tiger In-Reply-To: References: <20090131204620.GA3021@ruderich.org> Message-ID: Ok, after a bit more poking, this seems to be a fairly annoying bug with glibtool. Minimizing any chance of conflict, I have a working build using the libtool provided by configure in the tarball, and I have a broken build if I replace it with port:glibtool1's glibtool. The delta between the verbose output of the builds is below. For those not willing to go crosseyed looking for the difference, it's just a single -Wl,-single_module being added to the linking in the 'broken' build. This is not my area of expertise... so if someone could fill me in on why that is winding up in LDFLAGS and why it's causing up problems, I'd appreciate it... --- vanilla.log 2009-02-02 02:08:20.000000000 -0800 +++ libtool1.log 2009-02-02 02:02:01.000000000 -0800 @@ -811,7 +811,9 @@ rm -fr .libs/libXfont.lax/libspeedo.a mkdir .libs/libXfont.lax/libspeedo.a Extracting /opt/local/var/macports/build/_Users_jeremy_src_macports- trunk_dports_x11_xorg-libXfont/work/libXfont-1.3.3/src/Speedo/.libs/ libspeedo.a (cd .libs/libXfont.lax/libspeedo.a && ar x /opt/local/var/macports/ build/_Users_jeremy_src_macports-trunk_dports_x11_xorg-libXfont/work/ libXfont-1.3.3/src/Speedo/.libs/libspeedo.a) -/usr/bin/gcc-4.0 -dynamiclib -o .libs/libXfont.1.4.1.dylib .libs/ dummy.o .libs/libXfont.lax/libfontfile.a/bitsource.o .libs/ libXfont.lax/libfontfile.a/bufio.o .libs/libXfont.lax/libfontfile.a/ catalogue.o .libs/libXfont.lax/libfontfile.a/decompress.o .libs/ libXfont.lax/libfontfile.a/defaults.o .libs/libXfont.lax/libfontfile.a/ dirfile.o .libs/libXfont.lax/libfontfile.a/ffcheck.o .libs/ libXfont.lax/libfontfile.a/fileio.o .libs/libXfont.lax/libfontfile.a/ filewr.o .libs/libXfont.lax/libfontfile.a/fontdir.o .libs/libXfont.lax/ libfontfile.a/fontencc.o .libs/libXfont.lax/libfontfile.a/ fontfile.o .libs/libXfont.lax/libfontfile.a/fontscale.o .libs/ libXfont.lax/libfontfile.a/gunzip.o .libs/libXfont.lax/libfontfile.a/ printerfont.o .libs/libXfont.lax/libfontfile.a/register.o .libs/ libXfont.lax/libfontfile.a/renderers.o .libs/libXfont.lax/libft.a/ ftenc.o .libs/libXfont.lax/libft.a/ftfuncs.o .libs/libXfont.lax/ libft.a/fttools.o .libs/libXfont.lax/libft.a/xttcap.o .libs/ libXfont.lax/libbitmap.a/bdfread.o .libs/libXfont.lax/libbitmap.a/ bdfutils.o .libs/libXfont.lax/libbitmap.a/bitmap.o .libs/libXfont.lax/ libbitmap.a/bitmapfunc.o .libs/libXfont.lax/libbitmap.a/ bitmaputil.o .libs/libXfont.lax/libbitmap.a/bitscale.o .libs/ libXfont.lax/libbitmap.a/fontink.o .libs/libXfont.lax/libbitmap.a/ pcfread.o .libs/libXfont.lax/libbitmap.a/pcfwrite.o .libs/libXfont.lax/ libbitmap.a/snfread.o .libs/libXfont.lax/libbuiltins.a/dir.o .libs/ libXfont.lax/libbuiltins.a/file.o .libs/libXfont.lax/libbuiltins.a/ fonts.o .libs/libXfont.lax/libbuiltins.a/fpe.o .libs/libXfont.lax/ libbuiltins.a/render.o .libs/libXfont.lax/libfc.a/fsconvert.o .libs/ libXfont.lax/libfc.a/fserve.o .libs/libXfont.lax/libfc.a/fsio.o .libs/ libXfont.lax/libfc.a/fstrans.o .libs/libXfont.lax/libutil.a/ atom.o .libs/libXfont.lax/libutil.a/fontaccel.o .libs/libXfont.lax/ libutil.a/fontnames.o .libs/libXfont.lax/libutil.a/fontutil.o .libs/ libXfont.lax/libutil.a/fontxlfd.o .libs/libXfont.lax/libutil.a/ format.o .libs/libXfont.lax/libutil.a/miscutil.o .libs/libXfont.lax/ libutil.a/patcache.o .libs/libXfont.lax/libutil.a/private.o .libs/ libXfont.lax/libutil.a/utilbitmap.o .libs/libXfont.lax/libstubs.a/ cauthgen.o .libs/libXfont.lax/libstubs.a/csignal.o .libs/libXfont.lax/ libstubs.a/delfntcid.o .libs/libXfont.lax/libstubs.a/errorf.o .libs/ libXfont.lax/libstubs.a/fatalerror.o .libs/libXfont.lax/libstubs.a/ findoldfnt.o .libs/libXfont.lax/libstubs.a/fontmod.o .libs/ libXfont.lax/libstubs.a/getcres.o .libs/libXfont.lax/libstubs.a/ getdefptsize.o .libs/libXfont.lax/libstubs.a/getnewfntcid.o .libs/ libXfont.lax/libstubs.a/gettime.o .libs/libXfont.lax/libstubs.a/ initfshdl.o .libs/libXfont.lax/libstubs.a/regfpefunc.o .libs/ libXfont.lax/libstubs.a/rmfshdl.o .libs/libXfont.lax/libstubs.a/ servclient.o .libs/libXfont.lax/libstubs.a/setfntauth.o .libs/ libXfont.lax/libstubs.a/stfntcfnt.o .libs/libXfont.lax/libstubs.a/ xpstubs.o .libs/libXfont.lax/libfontcache.a/fontcache.o .libs/ libXfont.lax/libtype1.a/arith.o .libs/libXfont.lax/libtype1.a/ curves.o .libs/libXfont.lax/libtype1.a/fontfcn.o .libs/libXfont.lax/ libtype1.a/hints.o .libs/libXfont.lax/libtype1.a/lines.o .libs/ libXfont.lax/libtype1.a/objects.o .libs/libXfont.lax/libtype1.a/ paths.o .libs/libXfont.lax/libtype1.a/regions.o .libs/libXfont.lax/ libtype1.a/scanfont.o .libs/libXfont.lax/libtype1.a/spaces.o .libs/ libXfont.lax/libtype1.a/t1funcs.o .libs/libXfont.lax/libtype1.a/ t1info.o .libs/libXfont.lax/libtype1.a/t1io.o .libs/libXfont.lax/ libtype1.a/t1malloc.o .libs/libXfont.lax/libtype1.a/t1snap.o .libs/ libXfont.lax/libtype1.a/t1unicode.o .libs/libXfont.lax/libtype1.a/ token.o .libs/libXfont.lax/libtype1.a/type1.o .libs/libXfont.lax/ libtype1.a/util.o .libs/libXfont.lax/libspeedo.a/bics-unicode.o .libs/ libXfont.lax/libspeedo.a/do_char.o .libs/libXfont.lax/libspeedo.a/ do_trns.o .libs/libXfont.lax/libspeedo.a/out_bl2d.o .libs/libXfont.lax/ libspeedo.a/out_blk.o .libs/libXfont.lax/libspeedo.a/out_outl.o .libs/ libXfont.lax/libspeedo.a/out_scrn.o .libs/libXfont.lax/libspeedo.a/ out_util.o .libs/libXfont.lax/libspeedo.a/reset.o .libs/libXfont.lax/ libspeedo.a/set_spcs.o .libs/libXfont.lax/libspeedo.a/set_trns.o .libs/ libXfont.lax/libspeedo.a/spencode.o .libs/libXfont.lax/libspeedo.a/ sperr.o .libs/libXfont.lax/libspeedo.a/spfile.o .libs/libXfont.lax/ libspeedo.a/spfont.o .libs/libXfont.lax/libspeedo.a/spfuncs.o .libs/ libXfont.lax/libspeedo.a/spglyph.o .libs/libXfont.lax/libspeedo.a/ spinfo.o -L/opt/local/lib /opt/local/lib/libfreetype.dylib /opt/ local/lib/libz.dylib -lz -lm /opt/local/lib/libfontenc.dylib -Wl,- flat_namespace -Wl,-framework -Wl,CoreServices -Wl,-framework - Wl,ApplicationServices -install_name /opt/local/lib/libXfont.1.dylib - compatibility_version 6 -current_version 6.1 +/usr/bin/gcc-4.0 -dynamiclib -o .libs/libXfont.1.4.1.dylib .libs/ dummy.o .libs/libXfont.lax/libfontfile.a/bitsource.o .libs/ libXfont.lax/libfontfile.a/bufio.o .libs/libXfont.lax/libfontfile.a/ catalogue.o .libs/libXfont.lax/libfontfile.a/decompress.o .libs/ libXfont.lax/libfontfile.a/defaults.o .libs/libXfont.lax/libfontfile.a/ dirfile.o .libs/libXfont.lax/libfontfile.a/ffcheck.o .libs/ libXfont.lax/libfontfile.a/fileio.o .libs/libXfont.lax/libfontfile.a/ filewr.o .libs/libXfont.lax/libfontfile.a/fontdir.o .libs/libXfont.lax/ libfontfile.a/fontencc.o .libs/libXfont.lax/libfontfile.a/ fontfile.o .libs/libXfont.lax/libfontfile.a/fontscale.o .libs/ libXfont.lax/libfontfile.a/gunzip.o .libs/libXfont.lax/libfontfile.a/ printerfont.o .libs/libXfont.lax/libfontfile.a/register.o .libs/ libXfont.lax/libfontfile.a/renderers.o .libs/libXfont.lax/libft.a/ ftenc.o .libs/libXfont.lax/libft.a/ftfuncs.o .libs/libXfont.lax/ libft.a/fttools.o .libs/libXfont.lax/libft.a/xttcap.o .libs/ libXfont.lax/libbitmap.a/bdfread.o .libs/libXfont.lax/libbitmap.a/ bdfutils.o .libs/libXfont.lax/libbitmap.a/bitmap.o .libs/libXfont.lax/ libbitmap.a/bitmapfunc.o .libs/libXfont.lax/libbitmap.a/ bitmaputil.o .libs/libXfont.lax/libbitmap.a/bitscale.o .libs/ libXfont.lax/libbitmap.a/fontink.o .libs/libXfont.lax/libbitmap.a/ pcfread.o .libs/libXfont.lax/libbitmap.a/pcfwrite.o .libs/libXfont.lax/ libbitmap.a/snfread.o .libs/libXfont.lax/libbuiltins.a/dir.o .libs/ libXfont.lax/libbuiltins.a/file.o .libs/libXfont.lax/libbuiltins.a/ fonts.o .libs/libXfont.lax/libbuiltins.a/fpe.o .libs/libXfont.lax/ libbuiltins.a/render.o .libs/libXfont.lax/libfc.a/fsconvert.o .libs/ libXfont.lax/libfc.a/fserve.o .libs/libXfont.lax/libfc.a/fsio.o .libs/ libXfont.lax/libfc.a/fstrans.o .libs/libXfont.lax/libutil.a/ atom.o .libs/libXfont.lax/libutil.a/fontaccel.o .libs/libXfont.lax/ libutil.a/fontnames.o .libs/libXfont.lax/libutil.a/fontutil.o .libs/ libXfont.lax/libutil.a/fontxlfd.o .libs/libXfont.lax/libutil.a/ format.o .libs/libXfont.lax/libutil.a/miscutil.o .libs/libXfont.lax/ libutil.a/patcache.o .libs/libXfont.lax/libutil.a/private.o .libs/ libXfont.lax/libutil.a/utilbitmap.o .libs/libXfont.lax/libstubs.a/ cauthgen.o .libs/libXfont.lax/libstubs.a/csignal.o .libs/libXfont.lax/ libstubs.a/delfntcid.o .libs/libXfont.lax/libstubs.a/errorf.o .libs/ libXfont.lax/libstubs.a/fatalerror.o .libs/libXfont.lax/libstubs.a/ findoldfnt.o .libs/libXfont.lax/libstubs.a/fontmod.o .libs/ libXfont.lax/libstubs.a/getcres.o .libs/libXfont.lax/libstubs.a/ getdefptsize.o .libs/libXfont.lax/libstubs.a/getnewfntcid.o .libs/ libXfont.lax/libstubs.a/gettime.o .libs/libXfont.lax/libstubs.a/ initfshdl.o .libs/libXfont.lax/libstubs.a/regfpefunc.o .libs/ libXfont.lax/libstubs.a/rmfshdl.o .libs/libXfont.lax/libstubs.a/ servclient.o .libs/libXfont.lax/libstubs.a/setfntauth.o .libs/ libXfont.lax/libstubs.a/stfntcfnt.o .libs/libXfont.lax/libstubs.a/ xpstubs.o .libs/libXfont.lax/libfontcache.a/fontcache.o .libs/ libXfont.lax/libtype1.a/arith.o .libs/libXfont.lax/libtype1.a/ curves.o .libs/libXfont.lax/libtype1.a/fontfcn.o .libs/libXfont.lax/ libtype1.a/hints.o .libs/libXfont.lax/libtype1.a/lines.o .libs/ libXfont.lax/libtype1.a/objects.o .libs/libXfont.lax/libtype1.a/ paths.o .libs/libXfont.lax/libtype1.a/regions.o .libs/libXfont.lax/ libtype1.a/scanfont.o .libs/libXfont.lax/libtype1.a/spaces.o .libs/ libXfont.lax/libtype1.a/t1funcs.o .libs/libXfont.lax/libtype1.a/ t1info.o .libs/libXfont.lax/libtype1.a/t1io.o .libs/libXfont.lax/ libtype1.a/t1malloc.o .libs/libXfont.lax/libtype1.a/t1snap.o .libs/ libXfont.lax/libtype1.a/t1unicode.o .libs/libXfont.lax/libtype1.a/ token.o .libs/libXfont.lax/libtype1.a/type1.o .libs/libXfont.lax/ libtype1.a/util.o .libs/libXfont.lax/libspeedo.a/bics-unicode.o .libs/ libXfont.lax/libspeedo.a/do_char.o .libs/libXfont.lax/libspeedo.a/ do_trns.o .libs/libXfont.lax/libspeedo.a/out_bl2d.o .libs/libXfont.lax/ libspeedo.a/out_blk.o .libs/libXfont.lax/libspeedo.a/out_outl.o .libs/ libXfont.lax/libspeedo.a/out_scrn.o .libs/libXfont.lax/libspeedo.a/ out_util.o .libs/libXfont.lax/libspeedo.a/reset.o .libs/libXfont.lax/ libspeedo.a/set_spcs.o .libs/libXfont.lax/libspeedo.a/set_trns.o .libs/ libXfont.lax/libspeedo.a/spencode.o .libs/libXfont.lax/libspeedo.a/ sperr.o .libs/libXfont.lax/libspeedo.a/spfile.o .libs/libXfont.lax/ libspeedo.a/spfont.o .libs/libXfont.lax/libspeedo.a/spfuncs.o .libs/ libXfont.lax/libspeedo.a/spglyph.o .libs/libXfont.lax/libspeedo.a/ spinfo.o -L/opt/local/lib /opt/local/lib/libfreetype.dylib /opt/ local/lib/libz.dylib -lz -lm /opt/local/lib/libfontenc.dylib -Wl,- flat_namespace -Wl,-framework -Wl,CoreServices -Wl,-framework - Wl,ApplicationServices -install_name /opt/local/lib/libXfont.1.dylib - compatibility_version 6 -current_version 6.1 -Wl,-single_module +dsymutil .libs/libXfont.1.4.1.dylib || : +warning: no debug map in executable (-arch ppc) (cd .libs && rm -f libXfont.1.dylib && ln -s libXfont.1.4.1.dylib libXfont.1.dylib) (cd .libs && rm -f libXfont.dylib && ln -s libXfont.1.4.1.dylib libXfont.dylib) rm -fr .libs/libXfont.lax On Feb 2, 2009, at 01:20, Jeremy Huddleston wrote: > Ok, so I played a bit on my Tiger box, and this is a bit odd. As a > workaround for now, you can drop x11/xorg-libXfont to version 1.3.3. > > It's weird because if you autoreconf before compiling, this bug is > triggered... which means there's something odd happening in libtool > somewhere... hrm... > > > On Jan 31, 2009, at 12:46, Simon Ruderich wrote: > >> Hi, >> >> Today I tried to install xorg-server on my Intel Tiger. The >> installation worked fine, but when I want to start X11.app in >> /Applications/MacPorts I get the following error: >> >> X11.app: main(): argc=1 >> argv[0] = /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin >> Waiting for startup parameters via Mach IPC. >> X11.app: Could not connect to server (DISPLAY is not set). >> Starting X server. >> X11.app: Launching /opt/local/bin/startx: >> argv[0] = /bin/sh >> argv[1] = -c >> argv[2] = /opt/local/bin/startx >> bootstrap_look_up(): 1102l >> font_cache: Scanning user font directories to generate X11 font >> caches >> font_cache: Updating FC cache >> /opt/local/bin/font_cache: line 197: /opt/local/bin/fc-cache: No >> such file or directory >> font_cache: Done >> xauth: creating new authority file /Users/ >> simonruderich/.serverauth.3088 >> >> X11.app: do_start_x11_server(): argc=6 >> argv[0] = /opt/local/bin/X >> argv[1] = :1 >> argv[2] = -nolisten >> argv[3] = tcp >> argv[4] = -auth >> argv[5] = /Users/simonruderich/.serverauth.3088 >> X11.app: Debug Info: kKLuchrData failed, trying kKLKCHRData. >> If you are using a 3rd party keyboard layout, please see http://xquartz.macosforge.org/trac/ticket/154 >> Xquartz starting: >> X.Org X Server 1.4.2-apple31 >> Build Date: 20090131 >> (EE) XKB: Couldn't open rules file /opt/local/share/X11/xkb/rules/ >> base >> (EE) XKB: Couldn't open rules file /opt/local/share/X11/xkb/rules/ >> base >> Could not init font path element /opt/local/share/fonts/misc/, >> removing from list! >> Could not init font path element /opt/local/share/fonts/TTF/, >> removing from list! >> Could not init font path element /opt/local/share/fonts/OTF, >> removing from list! >> Could not init font path element /opt/local/share/fonts/Type1/, >> removing from list! >> Could not init font path element /opt/local/share/fonts/100dpi/, >> removing from list! >> Could not init font path element /opt/local/share/fonts/75dpi/, >> removing from list! >> Could not init font path element /Library/Fonts, removing from list! >> Could not init font path element /System/Library/Fonts, removing >> from list! >> >> Fatal server error: >> could not open default font 'fixed' >> AbortDDX >> Quitting Xquartz... >> Xquartz: start_x11_server: (ipc/mig) server died >> giving up. >> xinit: Connection refused (errno 61): unable to connect to X server >> xinit: No such process (errno 3): Server error. >> >> The first error (X11.app: Debug Info: kKLuchrData failed, trying >> kKLKCHRData.) can be fixed by using a US keyboard layout (I use a >> German one). But I have no idea how to fix the others. >> >> Thanks for your help, >> Simon >> -- >> + privacy is necessary >> + using http://gnupg.org >> + public key id: 0x6115F804EFB33229 >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From simon at ruderich.org Mon Feb 2 05:47:24 2009 From: simon at ruderich.org (Simon Ruderich) Date: Mon, 2 Feb 2009 14:47:24 +0100 Subject: Problem installing xorg-server on Tiger In-Reply-To: References: <20090131204620.GA3021@ruderich.org> Message-ID: <20090202134724.GA7245@ruderich.org> On Mon, Feb 02, 2009 at 01:20:20AM -0800, Jeremy Huddleston wrote: > Ok, so I played a bit on my Tiger box, and this is a bit odd. As a > workaround for now, you can drop x11/xorg-libXfont to version 1.3.3. > > It's weird because if you autoreconf before compiling, this bug is > triggered... which means there's something odd happening in libtool > somewhere... hrm... Thank you very much, installing xorg-libXfont 1.3.3 worked fine. X11.app is running now. But I have another problem. According to top and "Activity Monitor" X11.bin needs 130-170% cpu all the time. The xterm window is also sometimes not responsible for 1 to 2 seconds, after that it gets activated. With the default X11 binary it worked fine. Any ideas? Thanks, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From yves at macports.org Mon Feb 2 06:36:26 2009 From: yves at macports.org (Yves de Champlain) Date: Mon, 2 Feb 2009 09:36:26 -0500 Subject: Problem installing xorg-server on Tiger In-Reply-To: <20090202134724.GA7245@ruderich.org> References: <20090131204620.GA3021@ruderich.org> <20090202134724.GA7245@ruderich.org> Message-ID: <310537F0-23E5-4C5B-98EB-C367B29BB1E1@macports.org> Same happens on Leopard, but I have not tried the workaround yet http://trac.macports.org/ticket/18310 yves Le 09-02-02 ? 08:47, Simon Ruderich a ?crit : > On Mon, Feb 02, 2009 at 01:20:20AM -0800, Jeremy Huddleston wrote: >> Ok, so I played a bit on my Tiger box, and this is a bit odd. As a >> workaround for now, you can drop x11/xorg-libXfont to version 1.3.3. >> >> It's weird because if you autoreconf before compiling, this bug is >> triggered... which means there's something odd happening in libtool >> somewhere... hrm... > > Thank you very much, installing xorg-libXfont 1.3.3 worked fine. > X11.app is running now. > > But I have another problem. According to top and "Activity > Monitor" X11.bin needs 130-170% cpu all the time. The xterm > window is also sometimes not responsible for 1 to 2 seconds, > after that it gets activated. > > With the default X11 binary it worked fine. > > Any ideas? > > Thanks, > Simon > -- > + privacy is necessary > + using http://gnupg.org > + public key id: 0x6115F804EFB33229 > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From milosh at macports.org Mon Feb 2 07:15:40 2009 From: milosh at macports.org (Emmanuel Hainry) Date: Mon, 2 Feb 2009 16:15:40 +0100 Subject: [MacPorts] #18316: texlive fails to build while trying to install dirac In-Reply-To: <1233561163.6267.1.camel@debian> References: <048.cb3730141910a357c458564a209ebba6@macports.org> <057.2e303332421032483b426ac507a0c4a7@macports.org> <1233526173.21974.1.camel@debian> <1B63DD36-5733-4DCA-AFB5-4A6D24531EAA@macports.org> <1233561163.6267.1.camel@debian> Message-ID: <20090202151540.GA4633@weetamoe.loria.fr> Citando Jean-Michel Pour? : > On Sun, 2009-02-01 at 17:40 -0600, Ryan Schmidt wrote: > > See my bug reports. I cleaned and rebuilt texlive_base and it failed in > the end. My macport installation is up to date. x86. I don't care about > texlive_base, I am only interested in not breaking ffmpeg-devel. > I think it is probably a good place to have a +doxygen variant. So that you can build dirac without texlive and doxygen by default and use those dependencies (that are not little things) only if needed. Best, Emmanuel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From jm at poure.com Mon Feb 2 08:08:49 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Mon, 02 Feb 2009 17:08:49 +0100 Subject: [MacPorts] #18316: texlive fails to build while trying to install dirac In-Reply-To: <20090202151540.GA4633@weetamoe.loria.fr> References: <048.cb3730141910a357c458564a209ebba6@macports.org> <057.2e303332421032483b426ac507a0c4a7@macports.org> <1233526173.21974.1.camel@debian> <1B63DD36-5733-4DCA-AFB5-4A6D24531EAA@macports.org> <1233561163.6267.1.camel@debian> <20090202151540.GA4633@weetamoe.loria.fr> Message-ID: <1233590929.22107.0.camel@debian> On Mon, 2009-02-02 at 16:15 +0100, Emmanuel Hainry wrote: > I think it is probably a good place to have a +doxygen variant. So > that > you can build dirac without texlive and doxygen by default and use > those > dependencies (that are not little things) only if needed. This morning I updated, cleaned and recompiled and it worked. Happy ending. Fine. Thanks. From jeremyhu at macports.org Mon Feb 2 10:19:35 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Mon, 2 Feb 2009 10:19:35 -0800 Subject: Problem installing xorg-server on Tiger In-Reply-To: <310537F0-23E5-4C5B-98EB-C367B29BB1E1@macports.org> References: <20090131204620.GA3021@ruderich.org> <20090202134724.GA7245@ruderich.org> <310537F0-23E5-4C5B-98EB-C367B29BB1E1@macports.org> Message-ID: <42990F53-0243-44DC-ADF5-CA03AE94D008@macports.org> xorg-libXfont @1.3.4_1 should solve the problem now... On Feb 2, 2009, at 06:36, Yves de Champlain wrote: > Same happens on Leopard, but I have not tried the workaround yet > > http://trac.macports.org/ticket/18310 > > yves > > Le 09-02-02 ? 08:47, Simon Ruderich a ?crit : > >> On Mon, Feb 02, 2009 at 01:20:20AM -0800, Jeremy Huddleston wrote: >>> Ok, so I played a bit on my Tiger box, and this is a bit odd. As a >>> workaround for now, you can drop x11/xorg-libXfont to version 1.3.3. >>> >>> It's weird because if you autoreconf before compiling, this bug is >>> triggered... which means there's something odd happening in libtool >>> somewhere... hrm... >> >> Thank you very much, installing xorg-libXfont 1.3.3 worked fine. >> X11.app is running now. >> >> But I have another problem. According to top and "Activity >> Monitor" X11.bin needs 130-170% cpu all the time. The xterm >> window is also sometimes not responsible for 1 to 2 seconds, >> after that it gets activated. >> >> With the default X11 binary it worked fine. >> >> Any ideas? >> >> Thanks, >> Simon >> -- >> + privacy is necessary >> + using http://gnupg.org >> + public key id: 0x6115F804EFB33229 >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From jeremy at lavergne.gotdns.org Mon Feb 2 12:09:02 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 2 Feb 2009 15:09:02 -0500 Subject: Python PortGroups Message-ID: In regards to ticket #18325. What should be done when a portfile is submitted three times --- one for each version of python (24, 25, 26), using its respective PortGroup? The only difference between the versions are four lines: PortGroup, name, depends_lib, and a post-destroot move. I believe these could all be combined into one portfile, however I do not know how to handle the PortGroup settings then. Does anyone have any ports they might send my way for ideas? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From rasmus at macports.org Mon Feb 2 12:23:35 2009 From: rasmus at macports.org (Rasmus Andersson) Date: Mon, 2 Feb 2009 21:23:35 +0100 Subject: Python PortGroups In-Reply-To: References: Message-ID: That would be really nice. Maybe a solution like Debian use? (A single package may include programs for several Python versions). On Mon, Feb 2, 2009 at 21:09, Jeremy Lavergne wrote: > In regards to ticket #18325. > > What should be done when a portfile is submitted three times --- one for > each version of python (24, 25, 26), using its respective PortGroup? The > only difference between the versions are four lines: PortGroup, name, > depends_lib, and a post-destroot move. > > I believe these could all be combined into one portfile, however I do not > know how to handle the PortGroup settings then. Does anyone have any ports > they might send my way for ideas? > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > -- Rasmus Andersson From jmr at macports.org Mon Feb 2 12:33:22 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 03 Feb 2009 07:33:22 +1100 Subject: Python PortGroups In-Reply-To: References: Message-ID: <49875892.6030500@macports.org> Rasmus Andersson wrote: > That would be really nice. Maybe a solution like Debian use? (A single > package may include programs for several Python versions). > > On Mon, Feb 2, 2009 at 21:09, Jeremy Lavergne > wrote: >> In regards to ticket #18325. >> >> What should be done when a portfile is submitted three times --- one for >> each version of python (24, 25, 26), using its respective PortGroup? The >> only difference between the versions are four lines: PortGroup, name, >> depends_lib, and a post-destroot move. >> >> I believe these could all be combined into one portfile, however I do not >> know how to handle the PortGroup settings then. Does anyone have any ports >> they might send my way for ideas? You can't do this in the general case without a fix for . See . - Josh From simon at ruderich.org Mon Feb 2 12:46:33 2009 From: simon at ruderich.org (Simon Ruderich) Date: Mon, 2 Feb 2009 21:46:33 +0100 Subject: Problem installing xorg-server on Tiger In-Reply-To: <42990F53-0243-44DC-ADF5-CA03AE94D008@macports.org> References: <20090131204620.GA3021@ruderich.org> <20090202134724.GA7245@ruderich.org> <310537F0-23E5-4C5B-98EB-C367B29BB1E1@macports.org> <42990F53-0243-44DC-ADF5-CA03AE94D008@macports.org> Message-ID: <20090202204633.GA12364@ruderich.org> On Mon, Feb 02, 2009 at 10:19:35AM -0800, Jeremy Huddleston wrote: > xorg-libXfont @1.3.4_1 should solve the problem now... Thanks Jeremy, it works perfectly now. Even the CPU load is back to normal (no idea why, but I'm happy ;-)). Thanks again, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From simon at ruderich.org Mon Feb 2 12:49:08 2009 From: simon at ruderich.org (Simon Ruderich) Date: Mon, 2 Feb 2009 21:49:08 +0100 Subject: Problem installing xorg-server on Tiger In-Reply-To: <20090202204633.GA12364@ruderich.org> References: <20090131204620.GA3021@ruderich.org> <20090202134724.GA7245@ruderich.org> <310537F0-23E5-4C5B-98EB-C367B29BB1E1@macports.org> <42990F53-0243-44DC-ADF5-CA03AE94D008@macports.org> <20090202204633.GA12364@ruderich.org> Message-ID: <20090202204908.GB12364@ruderich.org> On Mon, Feb 02, 2009 at 09:46:33PM +0100, Simon Ruderich wrote: > On Mon, Feb 02, 2009 at 10:19:35AM -0800, Jeremy Huddleston wrote: >> xorg-libXfont @1.3.4_1 should solve the problem now... > > Thanks Jeremy, it works perfectly now. Even the CPU load is back > to normal (no idea why, but I'm happy ;-)). Well, at least I thought so. 10 seconds after I sent this mail it got up to 150% again :-/ Any idea what's causing this high CPU load? Thanks, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From jeremyhu at macports.org Mon Feb 2 12:59:51 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Mon, 2 Feb 2009 12:59:51 -0800 Subject: Problem installing xorg-server on Tiger In-Reply-To: <20090202204908.GB12364@ruderich.org> References: <20090131204620.GA3021@ruderich.org> <20090202134724.GA7245@ruderich.org> <310537F0-23E5-4C5B-98EB-C367B29BB1E1@macports.org> <42990F53-0243-44DC-ADF5-CA03AE94D008@macports.org> <20090202204633.GA12364@ruderich.org> <20090202204908.GB12364@ruderich.org> Message-ID: <1E556356-B5AD-47A9-98EB-DF8972672E90@macports.org> One other user is actually reporting odd CPU usage issues on Leopard. Would you mind joining xquartz-dev to jump in that thread: http://lists.macosforge.org/mailman/listinfo/xquartz-dev http://lists.macosforge.org/pipermail/xquartz-dev/2009-January/001952.html http://lists.macosforge.org/pipermail/xquartz-dev/2009-January/002042.html http://lists.macosforge.org/pipermail/xquartz-dev/2009-January/002044.html On Feb 2, 2009, at 12:49, Simon Ruderich wrote: > On Mon, Feb 02, 2009 at 09:46:33PM +0100, Simon Ruderich wrote: >> On Mon, Feb 02, 2009 at 10:19:35AM -0800, Jeremy Huddleston wrote: >>> xorg-libXfont @1.3.4_1 should solve the problem now... >> >> Thanks Jeremy, it works perfectly now. Even the CPU load is back >> to normal (no idea why, but I'm happy ;-)). > > Well, at least I thought so. 10 seconds after I sent this mail it > got up to 150% again :-/ > > Any idea what's causing this high CPU load? > > Thanks, > Simon > -- > + privacy is necessary > + using http://gnupg.org > + public key id: 0x6115F804EFB33229 From jm at poure.com Mon Feb 2 13:17:53 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Mon, 02 Feb 2009 22:17:53 +0100 Subject: [MacPorts] #18248: frei0r-plugins 1.2.2 In-Reply-To: <057.7c0670cd31a7ced723b962164273d410@macports.org> References: <048.dfd2ce7bf66549b14f9da2d350031b2b@macports.org> <057.7c0670cd31a7ced723b962164273d410@macports.org> Message-ID: <1233609473.1320.4.camel@debian> On Mon, 2009-02-02 at 21:12 +0000, MacPorts wrote: > Yes, PortSystem is all that is in error. Fixing and committing as > r46329. Thanks. For information, a small reminder is here on the advance of MLT/Kdenlive compiling: http://www.kdenlive.org/forum/kdenlive-macosx-packages It is far from perfect, but it serves as my personal guidelines. You may look at it and maybe help us. I had to change gcc42 compiler options in several kde4 packages and I would like to know your point of view. Kind regards, Jean-Michel From ryandesign at macports.org Mon Feb 2 14:29:37 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 2 Feb 2009 16:29:37 -0600 Subject: MacPorts wrapper script question In-Reply-To: <1528AAAC-CE89-4C91-B9F7-3B29B703477C@lavergne.gotdns.org> References: <1528AAAC-CE89-4C91-B9F7-3B29B703477C@lavergne.gotdns.org> Message-ID: On Feb 2, 2009, at 16:08, Jeremy Lavergne wrote: > I'm going through my pspp portfile again and trying to implement > the wrapper the way you had suggested in wine. > > Should I continue writing my wrapper script in the portfile, rather > than including it in pspp/files? > > I've got rename setup correctly, but I'm unsure of how to use > xinstall to set the permissions for the way I have the wrappers > generated from the portfile. If you have the time can you review > the following part that I'm constructing (notice I'm also adding > the conditional for the gui variant). Thanks! > > if {[variant_isset gui]} { > ln -s ${prefix}/lib/pspp/libpsppire.dylib \ > ${destroot}${prefix}/lib/pspp/libpsppire.so > ln -s ${prefix}/lib/pspp/libpsppwidgets.dylib \ > ${destroot}${prefix}/lib/pspp/libpsppwidgets.so > > file rename ${destroot}${prefix}/bin/psppire ${destroot}${prefix}/ > libexec/${name}/psppire > > set script [open ${destroot}${prefix}/bin/psppire w+] > puts $script "#!/bin/bash" > puts $script "export OLDPWD=`pwd`" > puts $script "cd /tmp" > puts $script "LD_LIBRARY_PATH=${prefix}/lib/pspp ${prefix}/libexec/ > ${name}/psppire" > puts $script "cd \$OLDPWD" > close $script > > xinstall -m 755 ${destroot}${prefix}/bin/psppire > #system "chmod 755 ${destroot}${prefix}/bin/psppire" > } I recommend you do it the way wine does, putting the wrapper script into the files directory. It's easier to read the script that way, and easier to edit. The script would then be "psppire.in" and would look like this: #!/bin/bash export OLDPWD=`pwd` cd /tmp LD_LIBRARY_PATH=@PREFIX@/lib/pspp ${prefix}/libexec/pspp/psppire cd $OLDPWD In the post-destroot you would use xinstall -m 755 to put it into $ {destroot}${prefix}/bin/psppire with the right permissions and then use reinplace to change @PREFIX@ to the real install prefix. Do you ever need to pass command line arguments to the psppire program? If so, see how the wine port handles that. From alakazam at macports.org Mon Feb 2 14:43:00 2009 From: alakazam at macports.org (Olivier Le Floch) Date: Mon, 2 Feb 2009 23:43:00 +0100 Subject: [46331] trunk/dports/mail/postfix/Portfile In-Reply-To: <20090202214821.B7359E41D4B@beta.macosforge.org> References: <20090202214821.B7359E41D4B@beta.macosforge.org> Message-ID: <19191BD3-DBC4-4E46-A2D1-0A0EA41DE899@macports.org> > Revision: 46331 > http://trac.macports.org/changeset/46331 > Author: ryandesign at macports.org > Date: 2009-02-02 13:48:21 -0800 (Mon, 02 Feb 2009) > Log Message: > ----------- > postfix: allow mysql5-devel to satisfy the mysql5 dependency > - depends_lib-append port:mysql5 > + depends_lib-append path:bin/mysql_config5:mysql5 I have a question regarding this depends_lib syntax : how does macports decide which port to install to satisfy this dependency if a port providing mysql5 is not already installed ? From wsiegrist at apple.com Mon Feb 2 14:47:16 2009 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 02 Feb 2009 14:47:16 -0800 Subject: [46331] trunk/dports/mail/postfix/Portfile In-Reply-To: <19191BD3-DBC4-4E46-A2D1-0A0EA41DE899@macports.org> References: <20090202214821.B7359E41D4B@beta.macosforge.org> <19191BD3-DBC4-4E46-A2D1-0A0EA41DE899@macports.org> Message-ID: On Feb 2, 2009, at 2:43 PM, Olivier Le Floch wrote: >> Revision: 46331 >> http://trac.macports.org/changeset/46331 >> Author: ryandesign at macports.org >> Date: 2009-02-02 13:48:21 -0800 (Mon, 02 Feb 2009) >> Log Message: >> ----------- >> postfix: allow mysql5-devel to satisfy the mysql5 dependency > >> - depends_lib-append port:mysql5 >> + depends_lib-append path:bin/mysql_config5:mysql5 > > I have a question regarding this depends_lib syntax : how does > macports decide which port to install to satisfy this dependency if > a port providing mysql5 is not already installed ? The last "mysql5" in that line specifies the port to install if the binary is not found. http://guide.macports.org/#reference.dependencies.types -Bill From davidstuartbruce at gmail.com Mon Feb 2 18:01:16 2009 From: davidstuartbruce at gmail.com (David Bruce) Date: Mon, 2 Feb 2009 21:01:16 -0500 Subject: Help with cross-platform wchar_t to utf8 conversion Message-ID: <9a3504f50902021801y53f39cc9u5f2ace6fb7692a1@mail.gmail.com> Hi, I'm the upstream maintainer for Tux Math and Tux Typing. I just contributed a current portfile for tuxmath, and would like to add tuxtype as well. The tuxtype port is almost ready to go, but a significan part of the game doesn't work because the existing code to convert a wchar_t string to utf8 doesn't work as built by macports. Tuxtype is a C program that uses SDL, without any Mac-specific libraries. The existing conversion uses iconv, with a check to take into account Microsoft's two-byte wchar_t. I had assumed the Mac would work just like Linux in this regard, but so far it hasn't. The relevant OS-specific part works like this: //Microsoft uses a different wchar_t from the rest of the world - grrr... #ifdef WIN32 DEBUGCODE {fprintf(stderr, "WIN32, using UTF-16LE for wchar_t\n");} conv_descr = iconv_open("UTF-8", "UTF-16LE"); #else conv_descr = iconv_open("UTF-8", "UTF-32"); #endif bytes_converted = iconv(conv_descr, &wchar_t_Start, &in_length, &UTF8_Start, &out_length); and so forth. On Mac, the UTF-32 version gets selected, but it doesn't work. So, as a quick fix: 1. is a Mac wchar_t string UTF-32BE, UTF-32LE, or something else? 2. what is the best preprocessor symbol to test for (i.e. __APPLE__, MACOSX, etc) to know if we are building for the Mac? This same code may also be built with CMake. I realize that in the long run it is better to get away from wchar_t, and that it is generally better to test directly for features a la Autoconf rather than just checking for a platform symbol. But if anyone knows these details offhand, I could have a functioning tuxtype port tonight. Thanks for any help, David Bruce (p.s. I tried to send this to the list about an hour ago and got a bounce - I apologize if you got a duplicate) From jmr at macports.org Mon Feb 2 22:34:43 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 03 Feb 2009 17:34:43 +1100 Subject: Help with cross-platform wchar_t to utf8 conversion In-Reply-To: <9a3504f50902021801y53f39cc9u5f2ace6fb7692a1@mail.gmail.com> References: <9a3504f50902021801y53f39cc9u5f2ace6fb7692a1@mail.gmail.com> Message-ID: <4987E583.8000809@macports.org> David Bruce wrote: > Hi, > > I'm the upstream maintainer for Tux Math and Tux Typing. I just > contributed a current portfile for tuxmath, and would like to add > tuxtype as well. The tuxtype port is almost ready to go, but a > significan part of the game doesn't work because the existing code to > convert a wchar_t string to utf8 doesn't work as built by macports. > > Tuxtype is a C program that uses SDL, without any Mac-specific > libraries. The existing conversion uses iconv, with a check to take > into account Microsoft's two-byte wchar_t. I had assumed the Mac > would work just like Linux in this regard, but so far it hasn't. > > The relevant OS-specific part works like this: > > //Microsoft uses a different wchar_t from the rest of the world - grrr... > #ifdef WIN32 > DEBUGCODE {fprintf(stderr, "WIN32, using UTF-16LE for wchar_t\n");} > conv_descr = iconv_open("UTF-8", "UTF-16LE"); > #else > conv_descr = iconv_open("UTF-8", "UTF-32"); > #endif > > bytes_converted = iconv(conv_descr, > &wchar_t_Start, &in_length, > &UTF8_Start, &out_length); > > and so forth. > > On Mac, the UTF-32 version gets selected, but it doesn't work. > > So, as a quick fix: > 1. is a Mac wchar_t string UTF-32BE, UTF-32LE, or something else? > 2. what is the best preprocessor symbol to test for (i.e. __APPLE__, > MACOSX, etc) to know if we are building for the Mac? This same code > may also be built with CMake. It seems like having to know this stuff a priori would partly defeat the purpose of having iconv? According to the iconv_open man page, you can pass "wchar_t" as tocode or fromcode and it will be interpreted as defined by the machine, OS and current locale. - Josh From davidstuartbruce at gmail.com Tue Feb 3 06:11:19 2009 From: davidstuartbruce at gmail.com (David Bruce) Date: Tue, 3 Feb 2009 08:11:19 -0600 Subject: Solved - Re: Help with cross-platform wchar_t to utf8 conversion Message-ID: <9a3504f50902030611g1d4c2b26g104052fac5991338@mail.gmail.com> Hi, > It seems like having to know this stuff a priori would partly defeat the > purpose of having iconv? According to the iconv_open man page, you can > pass "wchar_t" as tocode or fromcode and it will be interpreted as > defined by the machine, OS and current locale. > > - Josh Wow, that was easy! I should have been able to figure that one out. This will probably eliminate the ugly #ifdef WIN32 as well... Anyway, expect a portfile for tuxtype as soon as I get the fixed upstream tarball posted. Thanks, David Bruce From devans at macports.org Tue Feb 3 07:19:04 2009 From: devans at macports.org (David Evans) Date: Tue, 03 Feb 2009 07:19:04 -0800 Subject: Removing variants Message-ID: <49886068.2050704@macports.org> Using the trunk version of MacPorts, I have seen a lot of the following type of error message recently. Warning: Skipping upgrade since libiconv 1.12_2 >= libiconv 1.12_2, even though installed variant +darwin_8 does not match . Specify -f to force upgrade. This is a consequence of removing an existing variant without changing the version or incrementing the revision. (This phenomenon is not restricted to libiconv -- libiconv is just the most recent occurrence.) Since it seems desirable to upgrade the port in this circumstance so that the installed variants match the current port variants, I would like to suggest that at least the revision number be incremented when removing a variant so that a forced operation is not required. From jmr at macports.org Tue Feb 3 09:16:30 2009 From: jmr at macports.org (Joshua Root) Date: Wed, 04 Feb 2009 04:16:30 +1100 Subject: Removing variants In-Reply-To: <49886068.2050704@macports.org> References: <49886068.2050704@macports.org> Message-ID: <49887BEE.1010702@macports.org> David Evans wrote: > Using the trunk version of MacPorts, I have seen a lot of the following > type of error message recently. > > Warning: Skipping upgrade since libiconv 1.12_2 >= libiconv 1.12_2, even > though installed variant +darwin_8 does not match . Specify -f to force > upgrade. > > This is a consequence of removing an existing variant without changing > the version or incrementing the revision. (This phenomenon is > not restricted to libiconv -- libiconv is just the most recent occurrence.) > > Since it seems desirable to upgrade the port in this circumstance so > that the installed variants match the current port variants, I would like > to suggest that at least the revision number be incremented when > removing a variant so that a forced operation is not required. The rule for bumping the revision is the same whether a variant has been removed or not: do it if and only if the files installed by the port have changed. If the removed variant only did something like setting MDT for pre-1.7 compatibility, then there is no need to bump the rev. - Josh From jm at poure.com Tue Feb 3 12:34:51 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Tue, 03 Feb 2009 21:34:51 +0100 Subject: How to modify and test port1.0/group/kde4-1.0.tcl Message-ID: <1233693291.16601.4.camel@debian> Hello, I would like to modify and test the KDE4 group configuration. I modified the following file: /opt/mports/trunk/dports/_resources/port1.0/group/kde4-1.0.tcl. My sources.conf configuration is: file:///opt/mports/trunk/dports [default] Now, how do I enable my local modifications for testing? I tried sudo port -d selfupdate, which updated the SVN tree. I also recompiled and installed port from SVN. How to test my kde4-1..0.tcl configuration file? The old configuration is still present. I am stuck and I would like to help in the KDE4 compilation. Kind regards, Jean-Michel From rasmus at macports.org Tue Feb 3 15:50:45 2009 From: rasmus at macports.org (Rasmus Andersson) Date: Wed, 4 Feb 2009 00:50:45 +0100 Subject: py25-jinja violates the layout of the ports-filesystems Message-ID: ... ---> Staging py25-jinja into destroot Warning: violation by /opt/local/docs Warning: py25-jinja 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! ---> Installing py25-jinja @1.2_0 ... This should probably be fixed. I've CC:ed the maintainer. -- Rasmus Andersson From ryandesign at macports.org Tue Feb 3 19:46:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 3 Feb 2009 21:46:24 -0600 Subject: How to modify and test port1.0/group/kde4-1.0.tcl In-Reply-To: <1233693291.16601.4.camel@debian> References: <1233693291.16601.4.camel@debian> Message-ID: On Feb 3, 2009, at 14:34, Jean-Michel Pour? wrote: > I would like to modify and test the KDE4 group configuration. > > I modified the following file: > /opt/mports/trunk/dports/_resources/port1.0/group/kde4-1.0.tcl. > > My sources.conf configuration is: > file:///opt/mports/trunk/dports [default] > > Now, how do I enable my local modifications for testing? Editing the file should be all you need to do. > I tried sudo port > -d selfupdate, which updated the SVN tree. > > I also recompiled and installed port from SVN. > > How to test my kde4-1..0.tcl configuration file? > The old configuration is still present. If you edited the correct file (and based on the path of the file you say you edited, and the value you say is in your sources.conf, it looks like you did) then your changes should be active. > I am stuck and I would like to help in the KDE4 compilation. From ryandesign at macports.org Tue Feb 3 19:47:31 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 3 Feb 2009 21:47:31 -0600 Subject: py25-jinja violates the layout of the ports-filesystems In-Reply-To: References: Message-ID: <5038D5CF-B002-4E3F-88FD-9D3F06DF7C33@macports.org> On Feb 3, 2009, at 17:50, Rasmus Andersson wrote: > ... > ---> Staging py25-jinja into destroot > Warning: violation by /opt/local/docs > Warning: py25-jinja 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! > ---> Installing py25-jinja @1.2_0 > ... > > This should probably be fixed. I've CC:ed the maintainer. Bugs should be reported in the issue tracker. This bug has already been filed: http://trac.macports.org/ticket/16498 Since I reported this five months ago and the maintainer has not yet responded, anybody else should feel free to fix it at this point. From ryandesign at macports.org Tue Feb 3 19:53:59 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 3 Feb 2009 21:53:59 -0600 Subject: [46393] trunk/dports/python In-Reply-To: <20090204034813.7AE1EE612FA@beta.macosforge.org> References: <20090204034813.7AE1EE612FA@beta.macosforge.org> Message-ID: On Feb 3, 2009, at 21:48, blb at macports.org wrote: > +distfiles PyWavelets-${version}.tar.gz > +worksrcdir PyWavelets-${version} Can we simplify these two lines to just: distname PyWavelets-${version} ? From jm at poure.com Wed Feb 4 01:28:16 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Wed, 04 Feb 2009 10:28:16 +0100 Subject: How to modify and test port1.0/group/kde4-1.0.tcl In-Reply-To: References: <1233693291.16601.4.camel@debian> Message-ID: <1233739696.10868.1.camel@debian> On Tue, 2009-02-03 at 21:46 -0600, Ryan Schmidt wrote: > > I modified the following file: > > /opt/mports/trunk/dports/_resources/port1.0/group/kde4-1.0.tcl. > > > > My sources.conf configuration is: > > file:///opt/mports/trunk/dports [default] > > > > Now, how do I enable my local modifications for testing? > > Editing the file should be all you need to do. Unfortunately not. Can anyone someone try to modify: /opt/mports/trunk/dports/_resources/port1.0/group/kde4-1.0.tcl. and report back. On my computer it does not work. From ryandesign at macports.org Wed Feb 4 02:06:53 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 4 Feb 2009 04:06:53 -0600 Subject: [46043] trunk/dports In-Reply-To: References: <20090127212434.B08B6D8BDBC@beta.macosforge.org> Message-ID: <72EF3293-9084-49A4-ADCE-7A2864887939@macports.org> On Jan 27, 2009, at 22:12, Ryan Schmidt wrote: > On Jan 27, 2009, at 15:24, illogic-al at macports.org wrote: > >> -default_variants +docs >> - >> -variant docs description "Install documentation" { >> - depends_lib port:doxygen >> - configure.args-append -DBUILD_doc=ON >> +variant no_docs description "Does not install documentation" { >> + depends_lib-delete port:doxygen >> + configure.args-delete -DBUILD_doc=ON >> + configure.args-append -DBUILD_doc=OFF >> } > > Remember, variant descriptions should read like radio buttons. So > "Don't install documentation" or "Omit documentation" would be > preferable to "Does not install documentation". I fixed it in r46411. From ryandesign at macports.org Wed Feb 4 02:09:18 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 4 Feb 2009 04:09:18 -0600 Subject: [46081] trunk/dports/kde/kdelibs4/Portfile In-Reply-To: <72AC3C61-C925-436C-819D-B05777DCD320@macports.org> References: <20090128214208.D56EBDACE09@beta.macosforge.org> <72AC3C61-C925-436C-819D-B05777DCD320@macports.org> Message-ID: On Jan 28, 2009, at 17:11, Ryan Schmidt wrote: >> + ui_msg "# 'sudo chown -R $USER ~/Library/Preferences/KDE' #" >> + ui_msg "# replacing $USER with your username, followed by #" >> + ui_msg "# 'open /Applications/Macports/KDE4/kdeinit4.app' #" > > Use ${applications_dir} here. I fixed this in r46410. From jm at poure.com Wed Feb 4 02:23:48 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Wed, 04 Feb 2009 11:23:48 +0100 Subject: [46043] trunk/dports In-Reply-To: <72EF3293-9084-49A4-ADCE-7A2864887939@macports.org> References: <20090127212434.B08B6D8BDBC@beta.macosforge.org> <72EF3293-9084-49A4-ADCE-7A2864887939@macports.org> Message-ID: <1233743028.23285.0.camel@debian> On Wed, 2009-02-04 at 04:06 -0600, Ryan Schmidt wrote: > >> - depends_lib port:doxygen Please note that depends_build may need the reference to a default compiler. If you specify a compiler, you must require it during compilation. Otherwize, it breaks all Kde packages. From ryandesign at macports.org Wed Feb 4 02:33:19 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 4 Feb 2009 04:33:19 -0600 Subject: [46043] trunk/dports In-Reply-To: <1233743028.23285.0.camel@debian> References: <20090127212434.B08B6D8BDBC@beta.macosforge.org> <72EF3293-9084-49A4-ADCE-7A2864887939@macports.org> <1233743028.23285.0.camel@debian> Message-ID: On Feb 4, 2009, at 04:23, Jean-Michel Pour? wrote: > On Wed, 2009-02-04 at 04:06 -0600, Ryan Schmidt wrote: >>>> - depends_lib port:doxygen > > Please note that depends_build may need the reference to a default > compiler. If you specify a compiler, you must require it during > compilation. Otherwize, it breaks all Kde packages. The specified compiler is gcc-4.2, which is not provided by a port but by Xcode 3. The issue that gcc-4.2 is not available on Tiger or earlier is brought up in this ticket: http://trac.macports.org/ticket/17562#comment:20 From jm at poure.com Wed Feb 4 02:43:40 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Wed, 04 Feb 2009 11:43:40 +0100 Subject: [46043] trunk/dports In-Reply-To: References: <20090127212434.B08B6D8BDBC@beta.macosforge.org> <72EF3293-9084-49A4-ADCE-7A2864887939@macports.org> <1233743028.23285.0.camel@debian> Message-ID: <1233744220.23285.4.camel@debian> On Wed, 2009-02-04 at 04:33 -0600, Ryan Schmidt wrote: > The specified compiler is gcc-4.2, which is not provided by a port > but by Xcode 3. I have latest Xcode available. > The issue that gcc-4.2 is not available on Tiger or earlier is > brought up in this ticket: > > http://trac.macports.org/ticket/17562#comment:20 > Please use this ticket: http://trac.macports.org/ticket/18306 ---> Configuring automoc CMake Error at /opt/local/share/cmake-2.6/Modules/CMakeDetermineCCompiler.cmake:31 (MESSAGE): Could not find compiler set in environment variable CC: /usr/bin/gcc-4.2. Call Stack (most recent call first): CMakeLists.txt:1 (project) This happens for every single KDE4 package. I gess that if you ask for gcc-42 in configure, you should add depends_build dependencies accordingly. From jm at poure.com Wed Feb 4 03:08:37 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Wed, 04 Feb 2009 12:08:37 +0100 Subject: How to modify and test port1.0/group/kde4-1.0.tcl In-Reply-To: References: <1233693291.16601.4.camel@debian> Message-ID: <1233745717.26564.0.camel@debian> On Tue, 2009-02-03 at 21:46 -0600, Ryan Schmidt wrote: > If you edited the correct file (and based on the path of the file > you > say you edited, and the value you say is in your sources.conf, it > looks like you did) then your changes should be active. No it isn't. Here is what happens without modification, on pure SVN. Ordinateur-de-Bruno:~ kdenlive$ sudo port -v install kdesdk4 ---> Configuring automoc CMake Error at /opt/local/share/cmake-2.6/Modules/CMakeDetermineCCompiler.cmake:31 (MESSAGE): Could not find compiler set in environment variable CC: /usr/bin/gcc-4.2. Call Stack (most recent call first): CMakeLists.txt:1 (project) CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_C_COMPILER_ENV_VAR CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_C_COMPILER CMake Error: Could not find cmake module file:/opt/local/var/macports/build/_opt_mports_trunk_dports_devel_automoc/work/build/CMakeFiles/CMakeCCompiler.cmake CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_COMPILER_ENV_VAR CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_COMPILER CMake Error: Could not find cmake module file:/opt/local/var/macports/build/_opt_mports_trunk_dports_devel_automoc/work/build/CMakeFiles/CMakeCXXCompiler.cmake CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage -- Configuring incomplete, errors occurred! Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_mports_trunk_dports_devel_automoc/work/build" && cmake -DCMAKE_INSTALL_PREFIX=/opt/local -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON -DCMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.4u.sdk -DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr" -DQT_QMAKE_EXECUTABLE=/opt/local/libexec/qt4-mac/bin/qmake -Wno-dev ../automoc4-0.9.87 " returned error 1 Command output: CMake Error at /opt/local/share/cmake-2.6/Modules/CMakeDetermineCCompiler.cmake:31 (MESSAGE): Could not find compiler set in environment variable CC: /usr/bin/gcc-4.2. Call Stack (most recent call first): CMakeLists.txt:1 (project) CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_C_COMPILER_ENV_VAR CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_C_COMPILER CMake Error: Could not find cmake module file:/opt/local/var/macports/build/_opt_mports_trunk_dports_devel_automoc/work/build/CMakeFiles/CMakeCCompiler.cmake CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_COMPILER_ENV_VAR CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_COMPILER CMake Error: Could not find cmake module file:/opt/local/var/macports/build/_opt_mports_trunk_dports_devel_automoc/work/build/CMakeFiles/CMakeCXXCompiler.cmake CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage -- Configuring incomplete, errors occurred! Warning: the following items did not execute (for automoc): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.install Error: The following dependencies failed to build: automoc kdebase4-runtime kdelibs4 phonon soprano kdepimlibs4 akonadi qimageblitz Error: Status 1 encountered during processing. From illogical1 at gmail.com Wed Feb 4 06:24:09 2009 From: illogical1 at gmail.com (Orville Bennett) Date: Wed, 4 Feb 2009 09:24:09 -0500 Subject: How to modify and test port1.0/group/kde4-1.0.tcl In-Reply-To: <1233745717.26564.0.camel@debian> References: <1233693291.16601.4.camel@debian> <1233745717.26564.0.camel@debian> Message-ID: On Feb 4, 2009, at 6:08 AM, Jean-Michel Pour? wrote: > On Tue, 2009-02-03 at 21:46 -0600, Ryan Schmidt wrote: >> If you edited the correct file (and based on the path of the file >> you >> say you edited, and the value you say is in your sources.conf, it >> looks like you did) then your changes should be active. > > No it isn't. Here is what happens without modification, on pure SVN. > > Ordinateur-de-Bruno:~ kdenlive$ sudo port -v install kdesdk4 > ---> Configuring automoc > CMake Error > at /opt/local/share/cmake-2.6/Modules/CMakeDetermineCCompiler.cmake:31 I think I see your problem. You're editing a file in /opt/mports instead of /opt/local (which is where the port command you're using knows about). Try finding the kde4-1.0.tcl file in /opt/local/var/macports/sources/ /Mine/ is in /opt/local/var/macports/sources/rsync.macports.org/ release/ports/ I suspect this would go much faster if you tried #macports on irc.freenode.net > >>snip I should be available ~8 hours from now. From jm at poure.com Wed Feb 4 06:26:32 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Wed, 04 Feb 2009 15:26:32 +0100 Subject: How to modify and test port1.0/group/kde4-1.0.tcl In-Reply-To: References: <1233693291.16601.4.camel@debian> <1233745717.26564.0.camel@debian> Message-ID: <1233757592.8332.1.camel@debian> On Wed, 2009-02-04 at 09:24 -0500, Orville Bennett wrote: > I think I see your problem. You're editing a file in /opt/mports > instead of /opt/local (which is where the port command you're using > knows about). > Try finding the kde4-1.0.tcl file in /opt/local/var/macports/sources/ > /Mine/ is in /opt/local/var/macports/sources/rsync.macports.org/ > release/ports/ > I suspect this would go much faster if you tried #macports on > irc.freenode.net Thanks for the tip. I will connect on IRC when I have questions. Sorry for the confusion. From cedric.lists at gmail.com Wed Feb 4 07:46:41 2009 From: cedric.lists at gmail.com (=?ISO-8859-1?Q?C=E9dric_Luthi?=) Date: Wed, 4 Feb 2009 16:46:41 +0100 Subject: libxml2 2.7.3 update patch Message-ID: <32ba1ee20902040746l2bcafa02k4136062662f10b87@mail.gmail.com> Hello, I just submitted a patch to update libxml2 from version 2.7.2 to version 2.7.3: https://trac.macports.org/attachment/ticket/18360/libxml2-2.7.3.diff Please be kind enough to review and commit. C?dric Luthi PS: is it still recommended to ping the mailing list with such requests? From florian.ebeling at gmail.com Wed Feb 4 10:09:06 2009 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Wed, 4 Feb 2009 19:09:06 +0100 Subject: Deps charts Message-ID: <7E203257-E625-4BE6-A13C-882FCA6B50A3@gmail.com> Wasn't there a chart with the whole dependecy graph someplace, for all ports? -- Florian Ebeling florian.ebeling at gmail.com From jmr at macports.org Wed Feb 4 11:23:02 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 05 Feb 2009 06:23:02 +1100 Subject: Deps charts In-Reply-To: <7E203257-E625-4BE6-A13C-882FCA6B50A3@gmail.com> References: <7E203257-E625-4BE6-A13C-882FCA6B50A3@gmail.com> Message-ID: <4989EB16.3050005@macports.org> Florian Ebeling wrote: > Wasn't there a chart with the whole dependecy graph someplace, for all > ports? I doubt it, that would be huge and would quickly become stale. There's just the port-rdeps script which produces dependency charts on demand. - Josh From florian.ebeling at gmail.com Wed Feb 4 11:54:56 2009 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Wed, 4 Feb 2009 20:54:56 +0100 Subject: Deps charts In-Reply-To: <4989EB16.3050005@macports.org> References: <7E203257-E625-4BE6-A13C-882FCA6B50A3@gmail.com> <4989EB16.3050005@macports.org> Message-ID: <5cbbe4ae0902041154u75197c39haacf8228e6a28be4@mail.gmail.com> >> Wasn't there a chart with the whole dependecy graph someplace, for all >> ports? > > I doubt it, that would be huge and would quickly become stale. There's > just the port-rdeps script which produces dependency charts on demand. well, the ability to generate any branch is even better, I'd say: port-rdeps -d py-simplejson|dot -Tpng -o py-simplejson.png && open py-simplejson.png quite nice, should become more visible. -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From blb at macports.org Wed Feb 4 13:08:28 2009 From: blb at macports.org (Bryan Blackburn) Date: Wed, 4 Feb 2009 14:08:28 -0700 Subject: [46419] trunk/dports/python/py25-numarray/Portfile In-Reply-To: <20090204183302.C6E5EE6D6F4@beta.macosforge.org> References: <20090204183302.C6E5EE6D6F4@beta.macosforge.org> Message-ID: <20090204210828.GA638@ninagal.withay.com> On Wed, Feb 04, 2009 at 10:33:02AM -0800, devans at macports.org said: > Revision: 46419 > http://trac.macports.org/changeset/46419 > Author: devans at macports.org > Date: 2009-02-04 10:33:01 -0800 (Wed, 04 Feb 2009) > Log Message: > ----------- > py25-numarray: remove PortGroup provided --no-user-cfg from build and destroot commands as port chokes on it. It numarray not actually using distutils then? Bryan [...] From illogical1 at gmail.com Wed Feb 4 13:18:11 2009 From: illogical1 at gmail.com (Orville Bennett) Date: Wed, 4 Feb 2009 16:18:11 -0500 Subject: [46081] trunk/dports/kde/kdelibs4/Portfile In-Reply-To: References: <20090128214208.D56EBDACE09@beta.macosforge.org> <72AC3C61-C925-436C-819D-B05777DCD320@macports.org> Message-ID: <39BE0FC5-F928-4E63-ACE9-CA4B0DC2AC16@gmail.com> On Feb 4, 2009, at 5:09 AM, Ryan Schmidt wrote: > > On Jan 28, 2009, at 17:11, Ryan Schmidt wrote: > >>> + ui_msg "# 'sudo chown -R $USER ~/Library/Preferences/KDE' #" >>> + ui_msg "# replacing $USER with your username, followed by #" >>> + ui_msg "# 'open /Applications/Macports/KDE4/kdeinit4.app' #" >> >> Use ${applications_dir} here. > > I fixed this in r46410. Thanks. Forgot about this and the other one. > > From ryandesign at macports.org Wed Feb 4 18:41:09 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 4 Feb 2009 20:41:09 -0600 Subject: Deps charts In-Reply-To: <5cbbe4ae0902041154u75197c39haacf8228e6a28be4@mail.gmail.com> References: <7E203257-E625-4BE6-A13C-882FCA6B50A3@gmail.com> <4989EB16.3050005@macports.org> <5cbbe4ae0902041154u75197c39haacf8228e6a28be4@mail.gmail.com> Message-ID: <01A06313-209B-45E2-81AA-9A1032176AFD@macports.org> On Feb 4, 2009, at 13:54, C. Florian Ebeling wrote: >>> Wasn't there a chart with the whole dependecy graph someplace, >>> for all >>> ports? >> >> I doubt it, that would be huge and would quickly become stale. >> There's >> just the port-rdeps script which produces dependency charts on >> demand. > > well, the ability to generate any branch is even better, I'd say: > > port-rdeps -d py-simplejson|dot -Tpng -o py-simplejson.png && open > py-simplejson.png > > quite nice, should become more visible. I have not tried port-rdeps yet, but I had written a PHP script for this purpose. It requires a web server with PHP loaded, and Graphviz. You can download it here: http://ryandesign.com/tmp/portviz.tar.bz2 From ryandesign at macports.org Wed Feb 4 19:09:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 4 Feb 2009 21:09:03 -0600 Subject: [46417] trunk/dports/python/py25-numarray/Portfile In-Reply-To: <20090204180437.B6D57E6CF4B@beta.macosforge.org> References: <20090204180437.B6D57E6CF4B@beta.macosforge.org> Message-ID: <770DF072-8625-453A-9D5C-04D95CF170C2@macports.org> On Feb 4, 2009, at 12:04, devans at macports.org wrote: > +variant smp description {Enable smp} { Can the description be enhanced to explain what smp is? (I assume this is symmetric multiprocessing?) "Enable smp" doesn't tell the user any more than just the "smp" variant name. From ryandesign at macports.org Wed Feb 4 19:10:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 4 Feb 2009 21:10:08 -0600 Subject: [46420] trunk/dports/x11/mesa/Portfile In-Reply-To: <20090204184725.31A66E6D8E8@beta.macosforge.org> References: <20090204184725.31A66E6D8E8@beta.macosforge.org> Message-ID: <311F7825-C497-49B8-8CAD-52A8A5EA2C26@macports.org> On Feb 4, 2009, at 12:47, jeremyhu at macports.org wrote: > +variant hw_render conflicts system_x11 description {Install a > libGL.dylib that} { that what? :) From ryandesign at macports.org Wed Feb 4 21:23:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 4 Feb 2009 23:23:40 -0600 Subject: patching in general In-Reply-To: <47DF238F-2125-49FB-B567-2489155E4042@pixilla.com> References: <729142F4-B2B5-4DEF-9044-1D0CEBB79A30@pixilla.com> <96106973-B2A2-4F6C-A372-F5662324605B@macports.org> <3232FFBB-F0C4-4A5C-86A6-DEE10BD58402@pixilla.com> <757ADC59-F209-4E7F-8790-F30389210984@macports.org> <8BA6E8B2-3F70-4112-828E-84F8307036C5@pixilla.com> <11959794-9585-41C5-884C-CF3CBDE53082@macports.org> <47DF238F-2125-49FB-B567-2489155E4042@pixilla.com> Message-ID: <5BFE8733-B624-4731-9AE3-36F424CD65ED@macports.org> On Feb 4, 2009, at 09:54, Bradley Giesbrecht wrote: > The method macports uses to enable package versioning breaks > virtually every --with-mysql script I know of. Yeah... The kicker is that for all mysql5's gyrations, it still doesn't enable you to install multiple versions of MySQL simultaneously. http://trac.macports.org/ticket/4115 > Patching things isn't all that big a deal but I recently patched > bind9 to (+dlz-mysql) and I used the method used in php5 to help > bind9 find the mysql libs and headers. > Basically symlink the mysql dirs into ./work/. It's kinda clever, isn't it? But also a bit annoying that it's necessary. > Daniel (dluke) is not fond of that approach I saw that, but wasn't sure why, since it seems to me to be the easiest and least-intrusive way to make it work, short of changing the layout of the mysql5 port (which I'm not opposed to if someone makes a reasonable proposal). > and asked me if I could find another way to pass the libs and > includes to configure. The way the configure script is written for > bind9 this isn't possible. It does file exists tests with the > common locations if you don't pass in a path. If you pass in a path > it assumes this path is the install prefix and looks for lib/mysql > and include/mysql from there. Some configure scripts may let you separately indicate the library and include dirs, but for those that don't, and that don't use mysql_config, this is a problem. > In macports the fact that they are in lib/mysql5/mysql and include/ > mysql5/mysql will break every configure script I can think of. > > I really don't mind patching, I'm kinda used to it on osx although > I do not claim to be an expert, but it would be nice if there was a > macports best practice or something so if a person takes the time > to add a some functionality there is the best chance that it will > be acceptable to the maintainer. Best practice specifically for linking a port with MacPorts mysql5? Or were you looking for something more general? > For instance, some guidance on reinplace vs patch files. Use of > symlinks vs patching configure. I say use a patchfile when possible, so that if and when the upstream source changes and your patch breaks, you'll have the context of the patchfile to know whether you need to update or remove the patchfile. Use reinplace to replace things like ${prefix} and ${x11prefix} and other variables that can be different on different users' systems, but ideally first have a patchfile that changes the prefix to "@PREFIX@", then use reinplace to change "@PREFIX@" to "${prefix}". > Example, since you are the maintainer for php5 you probably > wouldn't have objected to me linking /opt/loca/lib/mysql5/mysql > and /opt/local/include/mysql5/mysql into bind9 ./work. > > I'm thinking of just gutting the mysql section of all configure > scripts and adding compatibility for passing the path to > mysql_config to each port I work on. Something I can almost do > without paying attention. And if sent upstream it might stand a > chance of making it into the source distribution. Yes, it would be nice of configure scripts would support mysql_config; sending such patches upstream would be great. > If you want to post this message to the list or ignore it > altogether that's fine. I know it's a rant and I don't want to be a > complainer. You've probably had these discussions a thousand times. > > Sorry, macports is great, your great, Daniel's great and you all > deserve and have my praise. > > I need to add mysql support to pureftpd and I have the same issue > with configure not working out of the box. I guess I could just put > in a feature request and patch my own locally until the maintainer > adds mysql support. I then could offer my patch and not take > offense if the maintainer doesn't like my method and move on. > > I really need to stop typing this horse to death;) It does help to type things out sometimes, and I certainly welcome your suggestions for improving the ports. Sometimes the only reason something is the way it is is because nobody has questioned it... From ryandesign at macports.org Thu Feb 5 01:08:09 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 5 Feb 2009 03:08:09 -0600 Subject: [46468] trunk/dports/audio/sox/Portfile In-Reply-To: <20090205090445.B1A90E7AF20@beta.macosforge.org> References: <20090205090445.B1A90E7AF20@beta.macosforge.org> Message-ID: <1557910C-2204-4EFD-B25A-FD6E112CEE00@macports.org> On Feb 5, 2009, at 03:04, devans at macports.org wrote: > Revision: 46468 > http://trac.macports.org/changeset/46468 > Author: devans at macports.org > Date: 2009-02-05 01:04:45 -0800 (Thu, 05 Feb 2009) > Log Message: > ----------- > sox: per maintainers request, change style of dependency on ffmpeg > from port to lib to allow either ffmpeg or ffmpeg-devel to satisfy > the dependency. Closes #18339. > > Modified Paths: > -------------- > trunk/dports/audio/sox/Portfile > > Modified: trunk/dports/audio/sox/Portfile > =================================================================== > --- trunk/dports/audio/sox/Portfile 2009-02-05 08:57:44 UTC (rev > 46467) > +++ trunk/dports/audio/sox/Portfile 2009-02-05 09:04:45 UTC (rev > 46468) > @@ -22,7 +22,7 @@ > port:libid3tag \ > port:libsamplerate \ > port:libvorbis \ > - port:ffmpeg \ > + lib:libavcodec:ffmpeg \ This would also allow a libavcodec installed outside of the MacPorts prefix to satisfy the dependency, which we do not want. Therefore this should be declared as a path:-style dependency, e.g. "path:lib/ libavcodec.dylib:ffmpeg" From brad at pixilla.com Thu Feb 5 06:11:51 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 5 Feb 2009 06:11:51 -0800 Subject: patching in general In-Reply-To: <5BFE8733-B624-4731-9AE3-36F424CD65ED@macports.org> References: <729142F4-B2B5-4DEF-9044-1D0CEBB79A30@pixilla.com> <96106973-B2A2-4F6C-A372-F5662324605B@macports.org> <3232FFBB-F0C4-4A5C-86A6-DEE10BD58402@pixilla.com> <757ADC59-F209-4E7F-8790-F30389210984@macports.org> <8BA6E8B2-3F70-4112-828E-84F8307036C5@pixilla.com> <11959794-9585-41C5-884C-CF3CBDE53082@macports.org> <47DF238F-2125-49FB-B567-2489155E4042@pixilla.com> <5BFE8733-B624-4731-9AE3-36F424CD65ED@macports.org> Message-ID: On Feb 4, 2009, at 9:23 PM, Ryan Schmidt wrote: > On Feb 4, 2009, at 09:54, Bradley Giesbrecht wrote: >> ............... >> Patching things isn't all that big a deal but I recently patched >> bind9 to (+dlz-mysql) and I used the method used in php5 to help >> bind9 find the mysql libs and headers. >> Basically symlink the mysql dirs into ./work/. > > It's kinda clever, isn't it? But also a bit annoying that it's > necessary. I thought so. It makes the fewest changes to files and goes away after install. >> In macports the fact that they are in lib/mysql5/mysql and include/ >> mysql5/mysql will break every configure script I can think of. >> >> I really don't mind patching, I'm kinda used to it on osx although >> I do not claim to be an expert, but it would be nice if there was a >> macports best practice or something so if a person takes the time >> to add a some functionality there is the best chance that it will >> be acceptable to the maintainer. > > Best practice specifically for linking a port with MacPorts mysql5? > Or were you looking for something more general? In general. >> For instance, some guidance on reinplace vs patch files. Use of >> symlinks vs patching configure. > > I say use a patchfile when possible, so that if and when the > upstream source changes and your patch breaks, you'll have the > context of the patchfile to know whether you need to update or > remove the patchfile. Use reinplace to replace things like ${prefix} > and ${x11prefix} and other variables that can be different on > different users' systems, but ideally first have a patchfile that > changes the prefix to "@PREFIX@", then use reinplace to change > "@PREFIX@" to "${prefix}". This is the type of guidance I was thinking of. Preferred method for fixing paths. 1. Patch files with "@PREFIX@" or "@X11PREFIX@" and use reinplace "$ {prefix}" or "${x11prefix}". Preferred method for fixing libs and includes. 1. Check if configure.ldflags-append and configure.cppflags-append will work. 2. Patch file. Preferred method for removing incompatible flags. 1. Example mysql, -lcrypt. reinplace " -lcrypt" It's important for me to thank you and the entire macports community for your work. I may be getting behind on my projects by trying to use and contribute to macports but I wouldn't even be attempting to do this on a mac if projects like macports didn't exist. And I am so happy to be typing this on my Macbook running Leopard rather then a FreeBsd desktop or always needing a remote shell. Thank you, thank you all!!! //Brad From markd at macports.org Thu Feb 5 08:34:41 2009 From: markd at macports.org (markd at macports.org) Date: Thu, 05 Feb 2009 08:34:41 -0800 Subject: patching in general Message-ID: >> I say use a patchfile when possible, so that if and when the >> upstream source changes and your patch breaks, you'll have the >> context of the patchfile to know whether you need to update or >> remove the patchfile. Use reinplace to replace things like ${prefix} >> and ${x11prefix} and other variables that can be different on >> different users' systems, but ideally first have a patchfile that >> changes the prefix to "@PREFIX@", then use reinplace to change >> "@PREFIX@" to "${prefix}". > >This is the type of guidance I was thinking of. > >Preferred method for fixing paths. > 1. Patch files with "@PREFIX@" or "@X11PREFIX@" and use reinplace >"$ >{prefix}" or "${x11prefix}". >Preferred method for fixing libs and includes. > 1. Check if configure.ldflags-append and >configure.cppflags-append >will work. > 2. Patch file. >Preferred method for removing incompatible flags. > 1. Example mysql, -lcrypt. reinplace " -lcrypt" > I wonder if some macro would be useful that would automatically parse patched files for a set of standard names (highly unique) to be replaced according to defaults ( '__mports__prefix__' -> ${prefix} etc.) that could be overridden. Maybe that is too complex, but sometimes I think the current patch-and-reinplace way does seem like a cumbersome (though not difficult) way to do it. Mark From afb at macports.org Thu Feb 5 08:47:34 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 5 Feb 2009 17:47:34 +0100 Subject: patching in general In-Reply-To: References: Message-ID: <159F408E-C3A7-4998-8F2F-4EF803008C8D@macports.org> >>> Preferred method for fixing paths. >> 1. Patch files with "@PREFIX@" or "@X11PREFIX@" and use >> reinplace >> "$ >> {prefix}" or "${x11prefix}". >> Preferred method for fixing libs and includes. >> 1. Check if configure.ldflags-append and >> configure.cppflags-append >> will work. >> 2. Patch file. >> Preferred method for removing incompatible flags. >> 1. Example mysql, -lcrypt. reinplace " -lcrypt" >> > I wonder if some macro would be useful that would automatically parse > patched files for a set of standard names (highly unique) to be > replaced > according to defaults ( '__mports__prefix__' -> ${prefix} etc.) > that could > be overridden. Maybe that is too complex, but sometimes I think the > current patch-and-reinplace way does seem like a cumbersome (though > not > difficult) way to do it. Yeah, it's especially painful when you have to extract the list of all files touched from the patch and then duplicate that list in the Portfile for reinplace... That's why some ports use a custom patch{} phase instead, to filter the patch accordingly before applying it. Like yum, http://trac.macports.org/browser/trunk/dports/sysutils/yum/ ? Having such a patch-filter built-in to port would be nice. --anders From markd at macports.org Thu Feb 5 10:12:10 2009 From: markd at macports.org (markd at macports.org) Date: Thu, 05 Feb 2009 10:12:10 -0800 Subject: patching in general Message-ID: >> I wonder if some macro would be useful that would automatically parse >> patched files for a set of standard names (highly unique) to be >> replaced >> according to defaults ( '__mports__prefix__' -> ${prefix} etc.) >> that could >> be overridden. Maybe that is too complex, but sometimes I think the >> current patch-and-reinplace way does seem like a cumbersome (though >> not >> difficult) way to do it. > >Yeah, it's especially painful when you have to extract >the list of all files touched from the patch and then >duplicate that list in the Portfile for reinplace... > >That's why some ports use a custom patch{} phase instead, >to filter the patch accordingly before applying it. Like yum, >http://trac.macports.org/browser/trunk/dports/sysutils/yum/ ? > >Having such a patch-filter built-in to port would be nice. > >--anders >patch { > foreach patch $patchfiles { > system "cd '${workpath}/${distname}' && \ > sed -e 's#@@PREFIX@@#${prefix}#g' -e >'s#@@PYTHON@@#${prefix}/bin/python2.4#g' >'${portpath}/${filesdir}/${patch}' | patch -p0" > } > } I see. That would be a cool macro, say 'fixpatchfiles' with a standard table of default mappings that could be augmented or overridden. To do the latter in a portfile, a table could be provided: 'fixpatchfiles __macports__prefix__:${prefix}/bin \ __macports__foo__:${whatever}' But then we could probably do with a lot of macros that we don't have now. Things like portage has (dobin, dodoc, etc.) would be a higher stage of development that we may get to someday. Mark From davidstuartbruce at gmail.com Thu Feb 5 10:44:55 2009 From: davidstuartbruce at gmail.com (David Bruce) Date: Thu, 5 Feb 2009 12:44:55 -0600 Subject: Various questions In-Reply-To: <2D3C00CE7C20D638782134B2@lewes.staff.uscs.susx.ac.uk> References: <1233313159.15944.7.camel@debian> <5cbbe4ae0901300625r61509ba1p8ef36cdd8b5fb2a9@mail.gmail.com> <2D3C00CE7C20D638782134B2@lewes.staff.uscs.susx.ac.uk> Message-ID: <9a3504f50902051044v2bfc3c39q24d39c7254c835e8@mail.gmail.com> Hi, On Fri, Jan 30, 2009 at 10:39 AM, Ian Eiloart wrote: > If that last question doesn't scare anyone, can I become maintainer of the > mail/exim and mail/mailman ports, please? I'd also like to create ports for > libspf2 and dkim libraries. > On a similar note, I wouldn't mind taking care of the tuxmath and tuxtype ports, assuming someone gets around to committing the latter. I'm the upstream maintainer for both projects. I contributed the tuxmath port last year, and no one has touched it since until I submitted an update last week. I submitted the tuxtype portfile a couple of days ago and am waiting for it to be committed. I'm happy to do the commits myself if given access, and I'd have no intention of touching anything outside of my own portfiles. Cheers, David Bruce From raimue at macports.org Thu Feb 5 14:31:41 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Thu, 05 Feb 2009 23:31:41 +0100 Subject: [46493] trunk/dports/fuse In-Reply-To: <20090205195809.AD92DE88B89@beta.macosforge.org> References: <20090205195809.AD92DE88B89@beta.macosforge.org> Message-ID: <498B68CD.6060203@macports.org> snc at macports.org wrote: > Revision: 46493 > http://trac.macports.org/changeset/46493 > Author: snc at macports.org > Date: 2009-02-05 11:58:08 -0800 (Thu, 05 Feb 2009) > Log Message: > ----------- > created mp3fs, ticket #18381 > > Added Paths: > ----------- > trunk/dports/fuse/mp3fs/ > trunk/dports/fuse/mp3fs/Portfile > > Added: trunk/dports/fuse/mp3fs/Portfile > =================================================================== > --- trunk/dports/fuse/mp3fs/Portfile (rev 0) > +++ trunk/dports/fuse/mp3fs/Portfile 2009-02-05 19:58:08 UTC (rev 46493) > @@ -0,0 +1,46 @@ > +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 > +# $Id$ > + > +PortSystem 1.0 > + > +name mp3fs > +version 0.13 > +categories fuse > +platforms darwin > + > +maintainers mail at uwe-arzt.de > + > +description A flac to mp3 (read-only) filesystem for FUSE > +long_description This is a file system for converting flac files \ > + to mp3 files on the fly. This is useful, if you \ > + archive your music in flac format, but some \ > + program (i.e. iTunes) are not capable reading \ > + flac, but mp3. > + > +homepage http://mp3fs.sourceforge.net/ > + > +distname mp3fs-${version} > +master_sites sourceforge:mp3fs > +checksums ${distfiles} md5 fb9b5eb4fb6f69f35430ff7e93a84e0b \ > + sha1 b246bd747a32256cb8364b7ac0cc8b7a4e1d3f74 > + > +livecheck.distname mp3fs You don't need to set livecheck.distname for sourceforge. > + > +depends_lib port:macfuse \ > + port:flac \ > + port:pkgconfig \ > + port:lame \ > + port:libid3tag I am pretty sure, pkgconfig is a build dependency, not library. It should be in depends_build. > +configure.post_args-append "id3tag_CFLAGS=-I/opt/local/include id3tag_LIBS='-L/opt/local/lib /opt/local/lib/libid3tag.dylib'" Replace /opt/local with ${prefix}. > +platform darwin { > + patch_sites http://www.uwe-arzt.de/files/mp3fs > + patchfiles mp3fs-${version}-macosx.patch > + checksums-append mp3fs-${version}-macosx.patch md5 3c14c714c9ff9fc39586cfb50ac6f3d2 \ > + sha1 3f46e4292a0dac0b0f9d3b8f01b76ff3315b3169 > + > + # override patch.pre_args since it defaults to -p0 > + patch.pre_args -R -p1 > +} Adding non-official patches from the maintainer to the files/ directory should be preferred. Rainer From ryandesign at macports.org Thu Feb 5 17:17:26 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 5 Feb 2009 19:17:26 -0600 Subject: patching in general In-Reply-To: References: <729142F4-B2B5-4DEF-9044-1D0CEBB79A30@pixilla.com> <96106973-B2A2-4F6C-A372-F5662324605B@macports.org> <3232FFBB-F0C4-4A5C-86A6-DEE10BD58402@pixilla.com> <757ADC59-F209-4E7F-8790-F30389210984@macports.org> <8BA6E8B2-3F70-4112-828E-84F8307036C5@pixilla.com> <11959794-9585-41C5-884C-CF3CBDE53082@macports.org> <47DF238F-2125-49FB-B567-2489155E4042@pixilla.com> <5BFE8733-B624-4731-9AE3-36F424CD65ED@macports.org> Message-ID: <0A3973E4-BED4-4AF9-9782-D97D9CCF0807@macports.org> On Feb 5, 2009, at 08:11, Bradley Giesbrecht wrote: >>> I really don't mind patching, I'm kinda used to it on osx >>> although I do not claim to be an expert, but it would be nice if >>> there was a macports best practice or something so if a person >>> takes the time to add a some functionality there is the best >>> chance that it will be acceptable to the maintainer. >> >> Best practice specifically for linking a port with MacPorts >> mysql5? Or were you looking for something more general? > > In general. > >>> For instance, some guidance on reinplace vs patch files. Use of >>> symlinks vs patching configure. >> >> I say use a patchfile when possible, so that if and when the >> upstream source changes and your patch breaks, you'll have the >> context of the patchfile to know whether you need to update or >> remove the patchfile. Use reinplace to replace things like $ >> {prefix} and ${x11prefix} and other variables that can be >> different on different users' systems, but ideally first have a >> patchfile that changes the prefix to "@PREFIX@", then use >> reinplace to change "@PREFIX@" to "${prefix}". > > This is the type of guidance I was thinking of. > > Preferred method for fixing paths. > 1. Patch files with "@PREFIX@" or "@X11PREFIX@" and use reinplace > "${prefix}" or "${x11prefix}". 1. Do nothing, because MacPorts already puts "--prefix=${prefix}" in configure.pre_args and most software uses configure scripts and most configure scripts understand that flag. 2. If there is another flag you need to use instead, overwrite configure.pre_args. 3. If there is no flag to do this, try an environment variable. ("configure.env-append PREFIX=${prefix}"). 4. If no environment variable exists for this, then patch. To this I would add: Preferred method for getting software to install into the destroot. 1. Do nothing, because MacPorts already puts DESTROOT=${destroot}$ {prefix} into destroot.destdir and most Makefiles support this. 2. If there is another variable you need to use, overwrite destroot.destdir (perhaps "destroot.destdir INSTALL_ROOT=${destroot}$ {prefix}" or "destroot.destdir PREFIX=${destroot}${prefix}"). 3. If the Makefile doesn't support DESTROOT, request from the author that they do. If they won't or you can't wait for their fix, patch the Makefile to support DESTROOT, or override the destroot phase entirely and xinstall the files into place in the portfile. 4. Sometimes in post-destroot you have to "reinplace s|${destroot}|| somefiles" because the destroot path has gotten inserted into them. > Preferred method for fixing libs and includes. > 1. Check if configure.ldflags-append and configure.cppflags-append > will work. > 2. Patch file. 1. Do nothing, as MacPorts already puts -L${prefix}/lib in configure.ldflags and -I${prefix}/include in configure.cflags so that most MacPorts software should be automatically found. 2. If not, look for a --with-foo=path configure option, such that you could for example "configure.args-append --with-zlib=${prefix}". 3. Sometimes software responds to specific environment variables, e.g. for graphviz you could "configure.env-append FONTCONFIG_CFLAGS=-I ${prefix}/include FONTCONFIG_LIBS=-L${prefix}/lib". 4. You could add nonstandard library paths to the CPPFLAGS and LDFLAGS globally with "configure.cppflags-append -I${prefix}/include/ something" and "configure.ldflags-append -L${prefix}/include/something". 5. If there's really no other way, patch. > Preferred method for removing incompatible flags. > 1. Example mysql, -lcrypt. reinplace " -lcrypt" I wouldn't have made a separate section on removing incompatible flags, as for me it just falls under patching. I would not use reinplace to remove a flag like -lcrypt; I would use a patchfile so that if upstream ever fixes their software to not use -lcrypt and your patch then breaks, you'll be able to tell why. -lcrypt specifically is a flag you find in some Linux software but which is incompatible with and unnecessary on Mac OS X. If software tries to use that flag on Mac OS X, you would write a patchfile to remove that option, but only apply the patchfile on platform darwin. (MacPorts could be installed on a non-Mac operating system and you wouldn't want this particular patch to be applied there.) Ideally you would report the problem to the author of the software and they would fix their configure script or whatever, so that Mac users who are not using MacPorts will also benefit from what we discovered and we can remove our patch with the next release. Sometimes software authors have no interest in making such changes to their software (whois). That's their prerogative. In that case, we maintain the patchfile in MacPorts forever. > It's important for me to thank you and the entire macports > community for your work. I may be getting behind on my projects by > trying to use and contribute to macports but I wouldn't even be > attempting to do this on a mac if projects like macports didn't > exist. And I am so happy to be typing this on my Macbook running > Leopard rather then a FreeBsd desktop or always needing a remote > shell. It is nice that there is a single place (MacPorts) where you can go for all your software compilation needs, where someone else has already done (a lot of) the work of getting stuff to compile right on the Mac. Sometimes it's straightforward to do it by hand but sometimes it's not, and it's good that not everyone has to figure that out for themselves. I'm glad you've found MacPorts to be useful. From ryandesign at macports.org Thu Feb 5 17:44:07 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 5 Feb 2009 19:44:07 -0600 Subject: [46493] trunk/dports/fuse In-Reply-To: <498B68CD.6060203@macports.org> References: <20090205195809.AD92DE88B89@beta.macosforge.org> <498B68CD.6060203@macports.org> Message-ID: <82C85B5E-9535-4788-903E-7AB357403612@macports.org> On Feb 5, 2009, at 16:31, Rainer M?ller wrote: > snc at macports.org wrote: >> Revision: 46493 >> http://trac.macports.org/changeset/46493 >> Author: snc at macports.org >> Date: 2009-02-05 11:58:08 -0800 (Thu, 05 Feb 2009) >> Log Message: >> ----------- >> created mp3fs, ticket #18381 >> >> Added Paths: >> ----------- >> trunk/dports/fuse/mp3fs/ >> trunk/dports/fuse/mp3fs/Portfile >> >> Added: trunk/dports/fuse/mp3fs/Portfile >> =================================================================== >> --- trunk/dports/fuse/mp3fs/Portfile (rev 0) >> +++ trunk/dports/fuse/mp3fs/Portfile 2009-02-05 19:58:08 UTC (rev >> 46493) >> @@ -0,0 +1,46 @@ >> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: >> nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 >> +# $Id$ >> + >> +PortSystem 1.0 >> + >> +name mp3fs >> +version 0.13 >> +categories fuse >> +platforms darwin >> + >> +maintainers mail at uwe-arzt.de >> + >> +description A flac to mp3 (read-only) filesystem for FUSE >> +long_description This is a file system for converting flac >> files \ >> + to mp3 files on the fly. This is useful, if >> you \ >> + archive your music in flac format, but some \ >> + program (i.e. iTunes) are not capable reading \ >> + flac, but mp3. >> + >> +homepage http://mp3fs.sourceforge.net/ >> + >> +distname mp3fs-${version} This distname line should be removed because that is the default value. From brad at pixilla.com Thu Feb 5 18:10:33 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 5 Feb 2009 18:10:33 -0800 Subject: Step though fetch and others In-Reply-To: <0A3973E4-BED4-4AF9-9782-D97D9CCF0807@macports.org> References: <729142F4-B2B5-4DEF-9044-1D0CEBB79A30@pixilla.com> <96106973-B2A2-4F6C-A372-F5662324605B@macports.org> <3232FFBB-F0C4-4A5C-86A6-DEE10BD58402@pixilla.com> <757ADC59-F209-4E7F-8790-F30389210984@macports.org> <8BA6E8B2-3F70-4112-828E-84F8307036C5@pixilla.com> <11959794-9585-41C5-884C-CF3CBDE53082@macports.org> <47DF238F-2125-49FB-B567-2489155E4042@pixilla.com> <5BFE8733-B624-4731-9AE3-36F424CD65ED@macports.org> <0A3973E4-BED4-4AF9-9782-D97D9CCF0807@macports.org> Message-ID: <82065647-10A5-4320-BB43-BBDFC49387AD@pixilla.com> I want to contribute a port and I picked dbmail. I installed macports via svn. /opt/local/etc/macports/sources.conf: file:///Users/brad/misc/MacPorts/ports [nosync] file:///opt/mports/trunk/dports [default] This seemed like the way to go to add my own ports. Am I wrong? With this configuration, if I do "port selfupdate" will macports check out or update from svn trunk? I was mostly worried about having my own ports wiped out by updates but now I don't think that's an issue because, I just added them to my local repository, right? So I have local_repo/mail/dbmail/Portfile: name dbmail version 2.2.11 homepage http://www.dbmail.org master_sites http://www.dbmail.org/download/2.2/ checksums md5 d535587973d73b85469d92a35f52133b \ sha1 7b9c19de7ca14d849e8388377b8aa941f3f3538b \ rmd160 e8a506b850d1610b66059b685b7a2318ce5e37a9 According to what I've read it should be fetching from: ${master_sites}${name}-${version}.tar.gz Well, there is definitely a file at that address. But I'm getting a html page download that's failing checksum besides not being what I want. How do I step through the fetch process? Or print to console the vars fetch is using? Thank you all, Brad From ryandesign at macports.org Thu Feb 5 18:17:50 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 5 Feb 2009 20:17:50 -0600 Subject: patching in general In-Reply-To: References: Message-ID: On Feb 5, 2009, at 12:12, markd at macports.org wrote: > But then we could probably do with a lot of macros that we don't > have now. > Things like portage has (dobin, dodoc, etc.) would be a higher > stage of > development that we may get to someday. Could you describe what these do? All I know about portage is that it's a package manager for Gentoo Linux, but I don't know how it works inside. From ryandesign at macports.org Thu Feb 5 18:25:44 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 5 Feb 2009 20:25:44 -0600 Subject: Step though fetch and others In-Reply-To: <82065647-10A5-4320-BB43-BBDFC49387AD@pixilla.com> References: <729142F4-B2B5-4DEF-9044-1D0CEBB79A30@pixilla.com> <96106973-B2A2-4F6C-A372-F5662324605B@macports.org> <3232FFBB-F0C4-4A5C-86A6-DEE10BD58402@pixilla.com> <757ADC59-F209-4E7F-8790-F30389210984@macports.org> <8BA6E8B2-3F70-4112-828E-84F8307036C5@pixilla.com> <11959794-9585-41C5-884C-CF3CBDE53082@macports.org> <47DF238F-2125-49FB-B567-2489155E4042@pixilla.com> <5BFE8733-B624-4731-9AE3-36F424CD65ED@macports.org> <0A3973E4-BED4-4AF9-9782-D97D9CCF0807@macports.org> <82065647-10A5-4320-BB43-BBDFC49387AD@pixilla.com> Message-ID: <879ECE8E-0FD0-4D18-A699-162A4722E020@macports.org> On Feb 5, 2009, at 20:10, Bradley Giesbrecht wrote: > I want to contribute a port and I picked dbmail. We appreciate it! :) > I installed macports via svn. > /opt/local/etc/macports/sources.conf: > file:///Users/brad/misc/MacPorts/ports [nosync] > file:///opt/mports/trunk/dports [default] > > This seemed like the way to go to add my own ports. > Am I wrong? That seems ok. I've never bothered with the "local repository" setup myself, though it's what the Guide recommends. I just have a single working copy of trunk/dports which I use for everything. It can get a bit messy but it works for me. > With this configuration, if I do "port selfupdate" will macports > check out or update from svn trunk? If /opt/mports/trunk/dports is a Subversion working copy, then "port sync" and "port selfupdate" will update that working copy with new portfiles. Nothing will change about how "port selfupdate" access the MacPorts base code, which will still come via rsync and will still be the released 1.7.0 version. If you want to build MacPorts base from trunk, read this how-to: http://trac.macports.org/wiki/howto/RunningTrunk > I was mostly worried about having my own ports wiped out by updates > but now I don't think that's an issue because, I just added them to > my local repository, right? If you use a local dports repository, as you have, then port sync won't wipe out your changes. Also, if you use a Subversion working copy, as I do, then port sync uses svn update instead of rsync and it won't wipe out your changes either. > So I have local_repo/mail/dbmail/Portfile: > name dbmail > version 2.2.11 > homepage http://www.dbmail.org > master_sites http://www.dbmail.org/download/2.2/ A construct we like to use in these situations is: set branch [join [lrange [split ${version} .] 0 1] .] master_sites http://www.dbmail.org/download/${branch} That way you don't have to update master_sites when the version changes. > checksums md5 d535587973d73b85469d92a35f52133b \ > sha1 7b9c19de7ca14d849e8388377b8aa941f3f3538b \ > rmd160 e8a506b850d1610b66059b685b7a2318ce5e37a9 > > According to what I've read it should be fetching from: > ${master_sites}${name}-${version}.tar.gz In the end, yes. More specifically, it fetches from ${master_sites}${distfiles} (assuming master_sites and distfiles are both only a single item, which they are in your case) ${distfiles} defaults to ${distname}${extract.suffix}. ${distname} defaults to ${name}-${version} ${extract.suffix} defaults to .tar.gz > Well, there is definitely a file at that address. But I'm getting a > html page download that's failing checksum besides not being what I > want. > > How do I step through the fetch process? > > Or print to console the vars fetch is using? You can enable debug mode with the -d switch: cd path/to/dbmail sudo port clean sudo port -d fetch You can also get the full URLs MacPorts wants to download from by using port distfiles From ryandesign at macports.org Thu Feb 5 18:39:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 5 Feb 2009 20:39:41 -0600 Subject: [46497] trunk/dports/multimedia/dirac/Portfile In-Reply-To: <20090205204704.076DCE89B96@beta.macosforge.org> References: <20090205204704.076DCE89B96@beta.macosforge.org> Message-ID: <6648BC18-562F-4BC1-AEB7-6DB841E25BA3@macports.org> On Feb 5, 2009, at 14:47, devans at macports.org wrote: > Revision: 46497 > http://trac.macports.org/changeset/46497 > Author: devans at macports.org > Date: 2009-02-05 12:46:59 -0800 (Thu, 05 Feb 2009) > Log Message: > ----------- > dirac: add +doc variant. > > Modified Paths: > -------------- > trunk/dports/multimedia/dirac/Portfile > > Modified: trunk/dports/multimedia/dirac/Portfile > =================================================================== > --- trunk/dports/multimedia/dirac/Portfile 2009-02-05 20:36:57 UTC > (rev 46496) > +++ trunk/dports/multimedia/dirac/Portfile 2009-02-05 20:46:59 UTC > (rev 46497) > @@ -29,13 +29,20 @@ > sha1 5e7106947fdc99a3cc24e8f7c5b9496244870d55 \ > rmd160 bcdcbde268cf4e28ee1c9b47ca70f823a55affb7 > > -patchfiles patch-doc-Makefile.in.diff \ > - patch-Makefile.in.diff > +patchfiles patch-Makefile.in.diff > > depends_lib port:cppunit > > test.run yes > > +variant doc description {Build Dirac reference documentation} { > + patchfiles patch-doc-Makefile.in.diffs > + depends_build-append \ > + port:doxygen \ > + port:graphviz \ Could you please change this to "path:bin/dot:graphviz" so that graphviz-devel could satisfy the dependency? Thanks. > + path:bin/latex:texlive > +} From ryandesign at macports.org Thu Feb 5 18:42:00 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 5 Feb 2009 20:42:00 -0600 Subject: [46491] trunk/dports/games In-Reply-To: <20090205191738.45E2CE887ED@beta.macosforge.org> References: <20090205191738.45E2CE887ED@beta.macosforge.org> Message-ID: <44804840-BA1B-4427-99D3-56DCB7981763@macports.org> On Feb 5, 2009, at 13:17, snc at macports.org wrote: > Revision: 46491 > http://trac.macports.org/changeset/46491 > Author: snc at macports.org > Date: 2009-02-05 11:17:36 -0800 (Thu, 05 Feb 2009) > Log Message: > ----------- > created tuxtype, ticket #18356 > > Added Paths: > ----------- > trunk/dports/games/tuxtype/ > trunk/dports/games/tuxtype/Portfile > > Added: trunk/dports/games/tuxtype/Portfile > =================================================================== > --- trunk/dports/games/tuxtype/Portfile > (rev 0) > +++ trunk/dports/games/tuxtype/Portfile 2009-02-05 19:17:36 UTC > (rev 46491) > @@ -0,0 +1,40 @@ > +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: > nil; \ > +c-basic-offset: 4 -*- vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 > +# $Id$ > + > +PortSystem 1.0 > + > +name tuxtype > +version 1.7.3 > +revision 0 > +categories games education > +platforms darwin > +maintainers gmail.com:davidstuartbruce > + > +description Learn to type with Tux, the Linux Penguin! > +long_description Tux Typing is an SDL-based educational game > intended for children but fun for all ages. \ > + The program includes two video game-styled > activities for typing individual words, \ > + as well as a phrase/sentence typing activity > that displays accuracy and words per \ > + minute. > + > +homepage http://www.tux4kids.com > +master_sites http://alioth.debian.org/frs/download.php/2767/ > +distname ${name}_w_fonts-${version} > + > +checksums md5 9b76e5ebb3daf3d93545dc561229e2a5 \ > + sha1 8029c5484e1fac2bea764b9eef6f9845d0c725ce \ > + rmd160 b7e10052582c894c272f591c5c907ae56a03b926 > + > +depends_lib port:libsdl \ > + port:libsdl_image \ > + port:libsdl_mixer \ > + port:libsdl_ttf \ > + port:libsdl_pango \ > + port:gettext > + > +platform darwin { > + post-destroot { > + xinstall -m 755 -d ${destroot}/Applications/MacPorts/ > TuxType.app/Contents/MacOS > + ln -s ${prefix}/bin/tuxtype ${destroot}/Applications/ > MacPorts/TuxType.app/Contents/MacOS/TuxType Please use ${applications_dir} instead of /Applications/Macports. From brad at pixilla.com Thu Feb 5 18:47:13 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 5 Feb 2009 18:47:13 -0800 Subject: Step though fetch and others In-Reply-To: <879ECE8E-0FD0-4D18-A699-162A4722E020@macports.org> References: <729142F4-B2B5-4DEF-9044-1D0CEBB79A30@pixilla.com> <96106973-B2A2-4F6C-A372-F5662324605B@macports.org> <3232FFBB-F0C4-4A5C-86A6-DEE10BD58402@pixilla.com> <757ADC59-F209-4E7F-8790-F30389210984@macports.org> <8BA6E8B2-3F70-4112-828E-84F8307036C5@pixilla.com> <11959794-9585-41C5-884C-CF3CBDE53082@macports.org> <47DF238F-2125-49FB-B567-2489155E4042@pixilla.com> <5BFE8733-B624-4731-9AE3-36F424CD65ED@macports.org> <0A3973E4-BED4-4AF9-9782-D97D9CCF0807@macports.org> <82065647-10A5-4320-BB43-BBDFC49387AD@pixilla.com> <879ECE8E-0FD0-4D18-A699-162A4722E020@macports.org> Message-ID: <2A39848A-F9E0-4C28-8817-FBA29361DF8C@pixilla.com> On Feb 5, 2009, at 6:25 PM, Ryan Schmidt wrote: >> So I have local_repo/mail/dbmail/Portfile: >> name dbmail >> version 2.2.11 >> homepage http://www.dbmail.org >> master_sites http://www.dbmail.org/download/2.2/ > > A construct we like to use in these situations is: > > set branch [join [lrange [split ${version} .] 0 1] .] > master_sites http://www.dbmail.org/download/${branch} > > That way you don't have to update master_sites when the version > changes. > >> checksums md5 d535587973d73b85469d92a35f52133b \ >> sha1 7b9c19de7ca14d849e8388377b8aa941f3f3538b \ >> rmd160 e8a506b850d1610b66059b685b7a2318ce5e37a9 >> >> According to what I've read it should be fetching from: >> ${master_sites}${name}-${version}.tar.gz > > In the end, yes. > > More specifically, it fetches from ${master_sites}${distfiles} > (assuming master_sites and distfiles are both only a single item, > which they are in your case) > > ${distfiles} defaults to ${distname}${extract.suffix}. > ${distname} defaults to ${name}-${version} > ${extract.suffix} defaults to .tar.gz > > >> Well, there is definitely a file at that address. But I'm getting a >> html page download that's failing checksum besides not being what I >> want. >> >> How do I step through the fetch process? >> >> Or print to console the vars fetch is using? > > You can enable debug mode with the -d switch: > > cd path/to/dbmail > sudo port clean > sudo port -d fetch Which is what I was doing and debug does not print the protocol or url. Maybe it should? > You can also get the full URLs MacPorts wants to download from by > using > > port distfiles This does what I was looking for and has me puzzled. If I copy and paste the first url from the (port distfiles) list into my browser I get the file I want downloaded. If I md5 the file the checksums match. If I do: file dbmail-2.2.11.tar.gz dbmail-2.2.11.tar.gz: gzip compressed data, from Unix, last modified: Mon Feb 2 06:26:11 2009 But if I do: file /opt/local/var/macports/distfiles/dbmail/dbmail-2.2.11.tar.gz /opt/local/var/macports/distfiles/dbmail/dbmail-2.2.11.tar.gz: HTML document text I'm at a lose without stepping through fetch. And I am not familiar with tcl but probably will be someday:) //Brad From ryandesign at macports.org Thu Feb 5 18:54:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 5 Feb 2009 20:54:05 -0600 Subject: [46495] trunk/dports/python In-Reply-To: <20090205202628.A6A38E89235@beta.macosforge.org> References: <20090205202628.A6A38E89235@beta.macosforge.org> Message-ID: On Feb 5, 2009, at 14:26, snc at macports.org wrote: > Revision: 46495 > http://trac.macports.org/changeset/46495 > Author: snc at macports.org > Date: 2009-02-05 12:26:28 -0800 (Thu, 05 Feb 2009) > Log Message: > ----------- > created dot2tex, ticket #18195 > > Added Paths: > ----------- > trunk/dports/python/dot2tex/ > trunk/dports/python/dot2tex/Portfile > > Added: trunk/dports/python/dot2tex/Portfile > =================================================================== > --- trunk/dports/python/dot2tex/Portfile > (rev 0) > +++ trunk/dports/python/dot2tex/Portfile 2009-02-05 20:26:28 UTC > (rev 46495) > @@ -0,0 +1,49 @@ > +# $Id$ > + > +PortSystem 1.0 > + > +name dot2tex > +version 2.8.4 > +categories graphics print python > +platforms darwin > +maintainers nomaintainer > +description Convert graphs generated by Graphviz to LaTeX > friendly formats > +long_description \ > + The purpose of dot2tex is to give graphs generated by Graphviz > a more \ > + LaTeX friendly look and feel. This is accomplished by > converting xdot \ > + output from Graphviz to a series of PSTricks or PGF/TikZ commands. > + > +homepage http://www.fauskes.net/code/dot2tex/ > +master_sites googlecode:dot2tex If the part after the colon is the same as ${name} then you don't need to list it. > +distname dot2tex-${version} This line can be removed because it is the default. > +checksums md5 e63d164fad5722290646cb200dcfcb61 \ > + sha1 > 0b091309857278126a09fb4f15cda5ed3b3d1020 \ > + rmd160 4ed95632f9d356e070fe361e1c07b98da36cfed2 > + > +livecheck.regex + > +depends_run bin:dot:graphviz bin:latex:texlive > bin:pdflatex:texlive > > +default_variants +python25 Default variants should not be used in this way. It makes it difficult to select anything else. (You would have to specify "sudo port install dot2tex +python24 -python25" in order to deselect the default variant, and every time you want to upgrade the port you would have to remember to "sudo port upgrade dot2tex -python25" to deselect the default variant.) Instead please do what e.g. the minivmac port does, and use the default variant only if another variant has not already been selected. > +variant python24 conflicts python25 python26 { > + PortGroup python24 1.0 > + depends_lib-append port:py-parsing > +} > + > +variant python25 conflicts python24 python26 { > + PortGroup python25 1.0 > + depends_lib-append port:py25-parsing > +} > + > +variant python26 conflicts python24 python25 { > + PortGroup python26 1.0 > + depends_lib-append port:py26-parsing > +} I must admit I have never seen a PortGroup defined in a variant before. Does this work? Can anyone think of a problem with this? From ryandesign at macports.org Thu Feb 5 19:00:43 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 5 Feb 2009 21:00:43 -0600 Subject: Step though fetch and others In-Reply-To: <2A39848A-F9E0-4C28-8817-FBA29361DF8C@pixilla.com> References: <729142F4-B2B5-4DEF-9044-1D0CEBB79A30@pixilla.com> <96106973-B2A2-4F6C-A372-F5662324605B@macports.org> <3232FFBB-F0C4-4A5C-86A6-DEE10BD58402@pixilla.com> <757ADC59-F209-4E7F-8790-F30389210984@macports.org> <8BA6E8B2-3F70-4112-828E-84F8307036C5@pixilla.com> <11959794-9585-41C5-884C-CF3CBDE53082@macports.org> <47DF238F-2125-49FB-B567-2489155E4042@pixilla.com> <5BFE8733-B624-4731-9AE3-36F424CD65ED@macports.org> <0A3973E4-BED4-4AF9-9782-D97D9CCF0807@macports.org> <82065647-10A5-4320-BB43-BBDFC49387AD@pixilla.com> <879ECE8E-0FD0-4D18-A699-162A4722E020@macports.org> <2A39848A-F9E0-4C28-8817-FBA29361DF8C@pixilla.com> Message-ID: <55BE1304-FBFB-4D5D-8D5B-744A510A96F6@macports.org> On Feb 5, 2009, at 20:47, Bradley Giesbrecht wrote: >> You can enable debug mode with the -d switch: >> >> cd path/to/dbmail >> sudo port clean >> sudo port -d fetch > > Which is what I was doing and debug does not print the protocol or > url. > > Maybe it should? It does print download progress including the URL (well, sort of) if it needs to download something, but not if it thinks it already has the file. Try cleaning the distfiles too. cd path/to/dbmail sudo port clean --all sudo port -d fetch >> You can also get the full URLs MacPorts wants to download from by >> using >> >> port distfiles > > This does what I was looking for and has me puzzled. > > If I copy and paste the first url from the (port distfiles) list > into my browser I get the file I want downloaded. > > If I md5 the file the checksums match. > > If I do: > file dbmail-2.2.11.tar.gz > dbmail-2.2.11.tar.gz: gzip compressed data, from Unix, last > modified: Mon Feb 2 06:26:11 2009 > > But if I do: > file /opt/local/var/macports/distfiles/dbmail/dbmail-2.2.11.tar.gz > /opt/local/var/macports/distfiles/dbmail/dbmail-2.2.11.tar.gz: HTML > document text > > I'm at a lose without stepping through fetch. And I am not familiar > with tcl but probably will be someday:) It works for me using your portfile. Maybe their server had a momentary difficulty. Or maybe your ISP's DNS server returns incorrect results (i.e. a search page) when a hostname is not found. What is in the HTML file you downloaded? $ port -d fetch DEBUG: Changing to port directory: /private/tmp/dbmail 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 dbmail. DEBUG: Requested variant i386 is not provided by port dbmail. DEBUG: Requested variant macosx is not provided by port dbmail. DEBUG: Changing to port directory: /private/tmp/dbmail 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 dbmail. DEBUG: Requested variant i386 is not provided by port dbmail. DEBUG: Requested variant macosx is not provided by port dbmail. DEBUG: Executing org.macports.main (dbmail) ---> Fetching dbmail DEBUG: Executing org.macports.fetch (dbmail) ---> dbmail-2.2.11.tar.gz doesn't seem to exist in /mp/var/macports/ distfiles/dbmail DEBUG: Pinging www.dbmail.org... DEBUG: Pinging distfiles.macports.org... DEBUG: Pinging trd.no.distfiles.macports.org... DEBUG: Pinging arn.se.distfiles.macports.org... DEBUG: www.dbmail.org ping time is 170.158 DEBUG: distfiles.macports.org ping time is 64.357 DEBUG: trd.no.distfiles.macports.org ping time is 185.161 DEBUG: arn.se.distfiles.macports.org ping time is 154.452 ---> Attempting to fetch dbmail-2.2.11.tar.gz from http:// distfiles.macports.org/dbmail % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 DEBUG: Fetching failed:: HTTP response code said error ---> Attempting to fetch dbmail-2.2.11.tar.gz from http:// arn.se.distfiles.macports.org/dbmail % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 DEBUG: Fetching failed:: HTTP response code said error ---> Attempting to fetch dbmail-2.2.11.tar.gz from http:// www.dbmail.org/download/2.2/ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 880k 100 880k 0 0 44495 0 0:00:20 0:00:20 --:--:-- 56464 $ port checksum ---> Verifying checksum(s) for dbmail $ From ryandesign at macports.org Thu Feb 5 19:08:30 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 5 Feb 2009 21:08:30 -0600 Subject: [46483] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: <20090205164718.6BEABE8106E@beta.macosforge.org> References: <20090205164718.6BEABE8106E@beta.macosforge.org> Message-ID: On Feb 5, 2009, at 10:47, mcalhoun at macports.org wrote: > + # user has specified that build platform must be able to run > binaries for supported architectures > + if { ${merger_must_run_binaries}=="yes" } { > + if { ${os.arch}=="i386" } { > + set universal_archs_supported [ldelete $ > {universal_archs_supported} "ppc64"] > + } else { > + set universal_archs_supported [ldelete $ > {universal_archs_supported} "i386"] > + set universal_archs_supported [ldelete $ > {universal_archs_supported} "x86_64"] > + } > + } Shouldn't care also be taken so that if one is on a 32-bit computer (PowerPC G3 or G4, or Intel Core), the 64-bit architectures are removed? I still totally dislike that any combination of architectures is still called "universal" and the user has no way of identifying in the "port installed" list what architectures are actually included in the port. From jmr at macports.org Thu Feb 5 19:49:50 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 06 Feb 2009 14:49:50 +1100 Subject: [46483] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: References: <20090205164718.6BEABE8106E@beta.macosforge.org> Message-ID: <498BB35E.2080600@macports.org> Ryan Schmidt wrote: > I still totally dislike that any combination of architectures is still > called "universal" and the user has no way of identifying in the "port > installed" list what architectures are actually included in the port. Yet another thing for which we need registry2.0. - Josh From ryandesign at macports.org Thu Feb 5 19:52:44 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 5 Feb 2009 21:52:44 -0600 Subject: [46483] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: <498BB35E.2080600@macports.org> References: <20090205164718.6BEABE8106E@beta.macosforge.org> <498BB35E.2080600@macports.org> Message-ID: On Feb 5, 2009, at 21:49, Joshua Root wrote: > Ryan Schmidt wrote: >> I still totally dislike that any combination of architectures is >> still >> called "universal" and the user has no way of identifying in the >> "port >> installed" list what architectures are actually included in the port. > > Yet another thing for which we need registry2.0. I want a lava lamp and a ham sandwich. Can we please add that to the registry2.0 roadmap too? From mcalhoun at macports.org Thu Feb 5 21:07:14 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Fri, 6 Feb 2009 05:07:14 +0000 (UTC) Subject: [46483] =?utf-8?b?dHJ1bmsvZHBvcnRzL19yZXNvdXJjZXMvcG9ydDEuMC9ncm91cC9tdW5pdmVyc2FsLTEuMC50Y2w=?= References: <20090205164718.6BEABE8106E@beta.macosforge.org> Message-ID: Ryan Schmidt writes: > Shouldn't care also be taken so that if one is on a 32-bit computer > (PowerPC G3 or G4, or Intel Core), the 64-bit architectures are removed? As far as I know, there is no way to get this information from MacPorts. Is there a command available on all these system which will provide this information? From jmr at macports.org Thu Feb 5 21:16:46 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 06 Feb 2009 16:16:46 +1100 Subject: [46483] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: References: <20090205164718.6BEABE8106E@beta.macosforge.org> Message-ID: <498BC7BE.5020802@macports.org> Marcus Calhoun-Lopez wrote: > Ryan Schmidt writes: > >> Shouldn't care also be taken so that if one is on a 32-bit computer >> (PowerPC G3 or G4, or Intel Core), the 64-bit architectures are removed? > As far as I know, there is no way to get this information from MacPorts. > Is there a command available on all these system which will provide > this information? There's the hw.cpu64bit_capable sysctl variable, on Leopard. - Josh From ryandesign at macports.org Thu Feb 5 21:44:56 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 5 Feb 2009 23:44:56 -0600 Subject: Ports recommending other ports Message-ID: It might be nice if a port could recommend the user install another port in addition, via some new keyword. For example, graphviz could recommend the user install graphviz-gui as well. postgresql83 could recommend the user install postgresql83-server. port could output these recommendations at the end of the installation. ("You may wish to install graphviz-gui as well.") The advantage over just printing a message at post-install time would be that port or a MacPorts GUI could offer the user the choice to install those recommended ports too ("Would you like to install graphviz-gui now?") and could know to omit the suggestion if the suggested port is already installed. There could be another new keyword for recommended alternatives to a given port. For example, on Leopard and later, graphviz-gui is a better choice than graphviz-oldgui (which is required on Tiger and earlier). ("You may wish to install graphviz-gui instead of graphviz- oldgui.") Hypothetical addition to port graphviz: if {${os.platform} == "darwin"} { if {${os.major} >= 9} { suggest_supplements-append port:graphviz-gui } else { suggest_supplements-append port:graphviz-oldgui } } Hypothetical additions to port graphviz-oldgui: if {${os.major} >= 9} { suggest_alternatives-append port:graphviz-gui } (I used "suggest" instead of "recommend" in the keyword names because people have more trouble spelling "recommend".) From mcalhoun at macports.org Thu Feb 5 22:01:06 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Fri, 6 Feb 2009 06:01:06 +0000 (UTC) Subject: [46483] =?utf-8?b?dHJ1bmsvZHBvcnRzL19yZXNvdXJjZXMvcG9ydDEuMC9ncm91cC9tdW5pdmVyc2FsLTEuMC50Y2w=?= References: <20090205164718.6BEABE8106E@beta.macosforge.org> <498BC7BE.5020802@macports.org> Message-ID: Joshua Root writes: > There's the hw.cpu64bit_capable sysctl variable, on Leopard. Just what I was looking for. Thank you. I only have Leopard machines to test on, however. Does anyone know if the code: if { [exec "/usr/sbin/sysctl" "-n" "hw.cpu64bit_capable"] != "1" } { . . . } works on all platforms where universal binaries might be built? -Marcus From ryandesign at macports.org Thu Feb 5 22:51:06 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 6 Feb 2009 00:51:06 -0600 Subject: [46483] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: References: <20090205164718.6BEABE8106E@beta.macosforge.org> <498BC7BE.5020802@macports.org> Message-ID: <0B078615-CF2B-4660-BE26-C676C89E6CDD@macports.org> On Feb 6, 2009, at 00:01, Marcus Calhoun-Lopez wrote: > Joshua Root writes: > >> There's the hw.cpu64bit_capable sysctl variable, on Leopard. > > Just what I was looking for. > Thank you. > > I only have Leopard machines to test on, however. > Does anyone know if the code: > if { [exec "/usr/sbin/sysctl" "-n" "hw.cpu64bit_capable"] != "1" } { > . > . > . > } > works on all platforms where universal binaries might be built? Hmm. Well, on Tiger it says: /usr/sbin/sysctl -n hw.cpu64bit_capable second level name cpu64bit_capable in hw.cpu64bit_capable is invalid So if you were to write code around that response, you would presumably assume that 64-bit binaries cannot be built on Tiger, which isn't necessarily so. Maybe there's a way we can ask about the processor family. From jm at poure.com Thu Feb 5 23:49:08 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Fri, 06 Feb 2009 08:49:08 +0100 Subject: Problems building KDE4 Message-ID: <1233906548.7833.3.camel@debian> Hello, I spent more than 30 hours tryine to compile KDE4. Of course, I did not stay all this time in front of the computer. Would it be possible to help me compiling KDE4. Illogical, KDE4 maintainer was not able to understand why compilation breaks. Connecting on FreeNode, most KDE-MAC developers told me they were able to compile. So would it be possible to help me find the tiny little thing that make everything crash. 1. As I am connecting remotely to the MacOsX computer, how can I know which version of MacOs. 10.4 or 10.5? 2. How can I verify that Apple gcc42 is installed. Where should it reside. 3. Was anyone succesfull running this command in the past 7 days: sudo port -v install kdesdk4. Then we can go on and study further. Kind regards, Jean-Michel Pour? From ryandesign at macports.org Thu Feb 5 23:59:19 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 6 Feb 2009 01:59:19 -0600 Subject: Problems building KDE4 In-Reply-To: <1233906548.7833.3.camel@debian> References: <1233906548.7833.3.camel@debian> Message-ID: <296DAC23-A600-44A4-A542-784F0E4B9DDD@macports.org> On Feb 6, 2009, at 01:49, Jean-Michel Pour? wrote: > I spent more than 30 hours tryine to compile KDE4. Of course, I did > not > stay all this time in front of the computer. > > Would it be possible to help me compiling KDE4. Illogical, KDE4 > maintainer was not able to understand why compilation breaks. > Connecting > on FreeNode, most KDE-MAC developers told me they were able to > compile. > > So would it be possible to help me find the tiny little thing that > make > everything crash. I know this is frustrating. I hope someone will be able to help you soon. > 1. As I am connecting remotely to the MacOsX computer, how can I know > which version of MacOs. 10.4 or 10.5? uname -a On my system: Darwin seven.local 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 To get the Mac OS X version from the Darwin version, subtract 4 from the darwin version and prepend "10.", so Darwin 8.11 is Mac OS X 10.4.11. > 2. How can I verify that Apple gcc42 is installed. Where should it > reside. ls -l /usr/bin/gcc-4.2 On my system: ls: /usr/bin/gcc-4.2: No such file or directory (gcc-4.2 does not exist on Mac OS X 10.4 and earlier) > 3. Was anyone succesfull running this command in the past 7 days: sudo > port -v install kdesdk4. I have not tried, but I can try now. From jm at poure.com Fri Feb 6 00:10:31 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Fri, 06 Feb 2009 09:10:31 +0100 Subject: Compiler configuration Message-ID: <1233907831.9152.2.camel@debian> Dear friends, Most MacPorts packages do not carry a reference to a specific gcc version. As a result, Apple gcc installed in Xcode is used. I am just a beginner, but wouldn't it be a more stable solution to rely only on GNU gcc 2.4 and gcc-4.2 and 4.3 using MacPorts packages. Kind regards, Jean-Michel From afb at macports.org Fri Feb 6 00:34:52 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri, 6 Feb 2009 09:34:52 +0100 Subject: Compiler configuration In-Reply-To: <1233907831.9152.2.camel@debian> References: <1233907831.9152.2.camel@debian> Message-ID: <952B8EC4-22ED-4799-9162-9E0A6B7EE480@macports.org> Jean-Michel Pour? wrote: > Most MacPorts packages do not carry a reference to a specific gcc > version. As a result, Apple gcc installed in Xcode is used. > > I am just a beginner, but wouldn't it be a more stable solution to > rely > only on GNU gcc 2.4 and gcc-4.2 and 4.3 using MacPorts packages. In a word: no. :-) Even using the "apple-gcc*" ports would be more of a hassle than just using /usr/bin/gcc*. And using GNU/FSF version of GCC would be worse... Theoretically, you are right - owning the ports allows for more control. But in practice the usual approach is to use Xcode for GCC and make etc. Other systems do it differently, but MacPorts usually recommends several things to be present on the system before installing base/port(1) itself. Like: GCC etc, X11, Tcl, Foundation, mtree, rsync, curl, ssl and more... Some of these can be replaced with the versions from MacPorts, later on. I'd go with the vendor GCC unless you need a feature that is not present, like support for Java (GCJ) or Fortran or desires to play with GCC 4.3 ? And, yes, this the opposite approach as being used for Perl/Python/ Ruby... There MacPorts version are preferred. It's a little inconsistent, that way. --anders From florian.ebeling at gmail.com Fri Feb 6 01:36:55 2009 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Fri, 6 Feb 2009 10:36:55 +0100 Subject: Various questions In-Reply-To: <2D3C00CE7C20D638782134B2@lewes.staff.uscs.susx.ac.uk> References: <1233313159.15944.7.camel@debian> <5cbbe4ae0901300625r61509ba1p8ef36cdd8b5fb2a9@mail.gmail.com> <2D3C00CE7C20D638782134B2@lewes.staff.uscs.susx.ac.uk> Message-ID: <5cbbe4ae0902060136y7e6f8eacu3a48ddc5caed2f62@mail.gmail.com> >>> * How to become MacPorts maintainer. I checked out the SVN tree. I would >>> like to apply for maintenance of sox, mlt, gavl, frei0r, ladspa-sdk and >>> kdenlive. Please contact me if you need my SSH pub key. I manage >>> kdenlive.org website and you don't have to worry. >> >> The official version of the project rules are in the guide: >> http://guide.macports.org/#project.contributing > > Ah, this'll be a spur to action for me. > > A couple of years ago, I acquired the handle ianeiloart at macports.org > However, I was never able to get logged in to trac. That problem seems to > have gone away. I've also noticed that there is no longer a maintainer for > the "exim" port, which is my main interest. > > Does having the handle mean that I have commit rights? > > Is there a beginners guide to making a commit for a single portfile? That's what the macports guide is for, mostly. It's quite a few things you have to watch for. Most important is an understand of installing software manually and remodel that in a mostly declarative fashion in Tcl. And than lots of diligence to make sure things really work and keep working. But once you have seen a couple of Portfiles you also see lots of recurring patterns. Fundamental style guidelines are in a special section in the guide as well. Also, when you begin everyone knows your not an expert. It is very valuable for the project if someone takes over reponsibility for a nomaintainer port. Maybe you have to ask a lot of questions in the beginning, but the second time around you know it yourself already. And you will get reviews of changes, if you want or not :) So I'd like to encourage you. Don't really know about your handle and it's state. Dig in your mail or ask Bill for that. But iirc, when you have an email address you also have commit bit. > If that last question doesn't scare anyone, can I become maintainer of the > mail/exim and mail/mailman ports, please? I'd also like to create ports for > libspf2 and dkim libraries. The guide is quite clear here. If there is no maintainer, you can take over maintainership. In the worst case, your changes get rejected by other committers, but if so then probably for a good reason. You should be aware though that some people really rely on certain ports, and if you break it, you break if for many people. So just create patches and get feedback, and you will probably know when you can just commit yourself after a short while. Florian -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From iane at sussex.ac.uk Fri Feb 6 04:10:38 2009 From: iane at sussex.ac.uk (Ian Eiloart) Date: Fri, 06 Feb 2009 12:10:38 +0000 Subject: Various questions In-Reply-To: <5cbbe4ae0902060136y7e6f8eacu3a48ddc5caed2f62@mail.gmail.com> References: <1233313159.15944.7.camel@debian> <5cbbe4ae0901300625r61509ba1p8ef36cdd8b5fb2a9@mail.gmail.com> <2D3C00CE7C20D638782134B2@lewes.staff.uscs.susx.ac.uk> <5cbbe4ae0902060136y7e6f8eacu3a48ddc5caed2f62@mail.gmail.com> Message-ID: <0637D81318C3584C95A5D55F@lewes.staff.uscs.susx.ac.uk> >> >> Is there a beginners guide to making a commit for a single portfile? > > That's what the macports guide is for, mostly. It's quite a few things > you have to watch for. Most important is an understand of installing > software manually and remodel that in a mostly declarative fashion in Tcl. > And than lots of diligence to make sure things really work and keep > working. But once you have seen a couple of Portfiles you also see > lots of recurring patterns. Yes, I've read the guide. I'm referring to the "making a commit" bit. The guide covers fetching the files, and how to make portfiles, but not how to submit the changes. I guess it's obvious to someone who's familiar with subversion, but I'm not. As a Port prospective port maintainer, I've actually got some working updates in a local source directory. I just don't know how to commit them. Often, all that's required is an update of a version number and md5 hash. A worked example in the guide would be really useful. -- Ian Eiloart IT Services, University of Sussex x3148 From jeremy at lavergne.gotdns.org Fri Feb 6 04:22:16 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 6 Feb 2009 07:22:16 -0500 Subject: [46483] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: <0B078615-CF2B-4660-BE26-C676C89E6CDD@macports.org> References: <20090205164718.6BEABE8106E@beta.macosforge.org> <498BC7BE.5020802@macports.org> <0B078615-CF2B-4660-BE26-C676C89E6CDD@macports.org> Message-ID: <7EAEBB7E-A11F-4C09-926E-84FD923A3956@lavergne.gotdns.org> the machine command: machine i486 machine ppc7450 also, running file on the binaries will tell you what architectures are inside: file `whereis ls` /bin/ls: Mach-O universal binary with 2 architectures /bin/ls (for architecture i386): Mach-O executable i386 /bin/ls (for architecture ppc7400): Mach-O executable ppc On Feb 6, 2009, at 1:51 AM, Ryan Schmidt wrote: Maybe there's a way we can ask about the processor family. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From toby at macports.org Fri Feb 6 05:41:26 2009 From: toby at macports.org (Toby Peterson) Date: Fri, 6 Feb 2009 05:41:26 -0800 Subject: [46483] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: <0B078615-CF2B-4660-BE26-C676C89E6CDD@macports.org> References: <20090205164718.6BEABE8106E@beta.macosforge.org> <498BC7BE.5020802@macports.org> <0B078615-CF2B-4660-BE26-C676C89E6CDD@macports.org> Message-ID: <74c219d30902060541i67ece841t758bd0b0479f41f3@mail.gmail.com> On Thu, Feb 5, 2009 at 10:51 PM, Ryan Schmidt wrote: > > On Feb 6, 2009, at 00:01, Marcus Calhoun-Lopez wrote: > >> Joshua Root writes: >> >>> There's the hw.cpu64bit_capable sysctl variable, on Leopard. >> >> Just what I was looking for. >> Thank you. >> >> I only have Leopard machines to test on, however. >> Does anyone know if the code: >> if { [exec "/usr/sbin/sysctl" "-n" "hw.cpu64bit_capable"] != "1" } { >> . >> . >> . >> } >> works on all platforms where universal binaries might be built? > > Hmm. Well, on Tiger it says: > > /usr/sbin/sysctl -n hw.cpu64bit_capable > second level name cpu64bit_capable in hw.cpu64bit_capable is invalid > > So if you were to write code around that response, you would presumably > assume that 64-bit binaries cannot be built on Tiger, which isn't > necessarily so. > > Maybe there's a way we can ask about the processor family. I think the easiest solution is to simply match the architectures of libSystem. - Toby From florian.ebeling at gmail.com Fri Feb 6 06:24:30 2009 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Fri, 6 Feb 2009 15:24:30 +0100 Subject: Various questions In-Reply-To: <0637D81318C3584C95A5D55F@lewes.staff.uscs.susx.ac.uk> References: <1233313159.15944.7.camel@debian> <5cbbe4ae0901300625r61509ba1p8ef36cdd8b5fb2a9@mail.gmail.com> <2D3C00CE7C20D638782134B2@lewes.staff.uscs.susx.ac.uk> <5cbbe4ae0902060136y7e6f8eacu3a48ddc5caed2f62@mail.gmail.com> <0637D81318C3584C95A5D55F@lewes.staff.uscs.susx.ac.uk> Message-ID: <5cbbe4ae0902060624r7b815f46h21034b54bd76b87e@mail.gmail.com> > Yes, I've read the guide. I'm referring to the "making a commit" bit. The > guide covers fetching the files, and how to make portfiles, but not how to > submit the changes. I guess it's obvious to someone who's familiar with > subversion, but I'm not. The first step is to move your configuration from the rsynced one to one you check out from the mp svn. The command is svn checkout http://svn.macports.org/repository/macports/trunk/dports Then you edit /opt/local/etc/macports/sources.conf so that the line ending in [default], probably the last one points to the directory from the above checkout. >From that moment on, you should make your changes in this directory tree. It carries the svn metadata used for tracking and committing changes. At this point you should a decent svn tutorial and learn about update, add, remove, revert, log, commit, and diff sub-commands. Those are the ones you will use most of the time, and you need to know them quite good. If you have a locally changed Portfile you can just copy it over to the svn tree. From there you commit, make a diff/patch, etc. > As a Port prospective port maintainer, I've actually got some working > updates in a local source directory. I just don't know how to commit them. > Often, all that's required is an update of a version number and md5 hash. A > worked example in the guide would be really useful. That's basically handling of svn and not mp specific, so that wuold not make a whole lot of sense. Fortunately svn is in wide-spread use, and there are many places to learn about it. E.g. here: http://artis.imag.fr/~Xavier.Decoret/resources/svn/index.html Florian -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From jmr at macports.org Fri Feb 6 09:57:24 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 07 Feb 2009 04:57:24 +1100 Subject: [46483] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: <74c219d30902060541i67ece841t758bd0b0479f41f3@mail.gmail.com> References: <20090205164718.6BEABE8106E@beta.macosforge.org> <498BC7BE.5020802@macports.org> <0B078615-CF2B-4660-BE26-C676C89E6CDD@macports.org> <74c219d30902060541i67ece841t758bd0b0479f41f3@mail.gmail.com> Message-ID: <498C7A04.6@macports.org> Toby Peterson wrote: > On Thu, Feb 5, 2009 at 10:51 PM, Ryan Schmidt wrote: >> On Feb 6, 2009, at 00:01, Marcus Calhoun-Lopez wrote: >> >>> Joshua Root writes: >>> >>>> There's the hw.cpu64bit_capable sysctl variable, on Leopard. >>> Just what I was looking for. >>> Thank you. >>> >>> I only have Leopard machines to test on, however. >>> Does anyone know if the code: >>> if { [exec "/usr/sbin/sysctl" "-n" "hw.cpu64bit_capable"] != "1" } { >>> . >>> . >>> . >>> } >>> works on all platforms where universal binaries might be built? >> Hmm. Well, on Tiger it says: >> >> /usr/sbin/sysctl -n hw.cpu64bit_capable >> second level name cpu64bit_capable in hw.cpu64bit_capable is invalid >> >> So if you were to write code around that response, you would presumably >> assume that 64-bit binaries cannot be built on Tiger, which isn't >> necessarily so. >> >> Maybe there's a way we can ask about the processor family. > > I think the easiest solution is to simply match the architectures of libSystem. No good, it has ppc64 even on a G4. - Josh From ryandesign at macports.org Fri Feb 6 12:02:06 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 6 Feb 2009 14:02:06 -0600 Subject: [46541] trunk/dports/textproc In-Reply-To: <20090206162354.DA5FCE98EC2@beta.macosforge.org> References: <20090206162354.DA5FCE98EC2@beta.macosforge.org> Message-ID: <4BF552E3-B52A-40E1-9E32-C707C2BB8CDA@macports.org> On Feb 6, 2009, at 10:23, snc at macports.org wrote: > Revision: 46541 > http://trac.macports.org/changeset/46541 > Author: snc at macports.org > Date: 2009-02-06 08:23:53 -0800 (Fri, 06 Feb 2009) > Log Message: > ----------- > created pxsl-tools > > Added Paths: > ----------- > trunk/dports/textproc/pxsl-tools/ > trunk/dports/textproc/pxsl-tools/Portfile > > Added: trunk/dports/textproc/pxsl-tools/Portfile > =================================================================== > --- trunk/dports/textproc/pxsl-tools/ > Portfile (rev 0) > +++ trunk/dports/textproc/pxsl-tools/Portfile 2009-02-06 16:23:53 > UTC (rev 46541) > @@ -0,0 +1,42 @@ > +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: > nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 > +# $Id$ > + > +PortSystem 1.0 > + > +name pxsl-tools > +version 1.0 > +categories textproc > +maintainers snc, openmaintainer > +description A convenient shorthand for writing markup- > heavy XML \ > + documents. > +long_description PXSL ("pixel") is a convenient shorthand for > writing \ > + markup-heavy XML documents. It provides XML > authors and \ > + programmers with a simple, concise syntax that > they can \ > + use to create XML documents. For more advanced > users, PXSL \ > + offers customizable shortcuts and sophisticated \ > + refactoring tools like functional macros that > can markedly \ > + reduce the size and complexity of markup-dense > XML \ > + documents. > + > +platforms darwin freebsd > +use_parallel_build yes > +homepage http://community.moertel.com/ss/space/PXSL > +master_sites http://community.moertel.com/pxsl/sources/ > + > +checksums md5 f136de0a05aa26e605579ff48730be3c \ > + sha1 3afb794a7e6b7f1b356f63252a374206a7aa7cb8 \ > + rmd160 fd4727cbb6255f8b7c6da9005042ea75c3df4586 > + > +depends_build port:ghc > + > +configure { > + system "cd ${worksrcpath} && runhaskell Setup.lhs configure -- > prefix=${destroot}${prefix}" > +} > + > +build { > + system "cd ${worksrcpath} && runhaskell Setup.lhs build" > +} > + > +destroot { > + system "cd ${worksrcpath} && runhaskell Setup.lhs install" > +} Did you check if perhaps the haskell portgroup could be used to simplify this portfile? If it doesn't work for this port, maybe take it up with Bryan; the haskell portgroup was only recently added and may still require some tweaking. From apple at frinabulax.org Fri Feb 6 14:24:46 2009 From: apple at frinabulax.org (robert delius royar) Date: Fri, 6 Feb 2009 17:24:46 -0500 Subject: Cannot upgrade mercurial (macports wants to reinstall latest dependencies) Ticket #18408 Message-ID: I filed this as Ticket #18408 because the attachments were too long for the list to accept. I tried to upgrade mercurial today, but the upgrade gets into a situation where it wants to install ports that are already installed and that are not outdated and ports that are installed and depenedences that are not the latest versions but are according to the mercurial port file acceptable. I have tried a number of ways to get the install to work beginning with 'port upgrade mercurial', next 'port -n upgrade mercurial', 'port -fn upgrade mercurial' and 'port -f upgrade mercurial' In all cases, I either get to a place where some dependency of a dependency will not uninstall because it is required for other ports and the whole thing fails, or I get to a place where gettext (which I know is up to date) keeps being refetched, re-everything, fails to re-install and MP either fails or tries again. Here is what 'port installed' and 'port outdated' say before I try to upgrade: grendel% port installed mercurial The following ports are currently installed: mercurial @0.9.5_0 grendel% port outdated mercurial The following installed ports are outdated: mercurial 0.9.5_0 < 1.1.2_0 grendel% port installed gperf The following ports are currently installed: gperf @3.0.3_0 grendel% port outdated gperf No installed ports are outdated. grendel% port installed bzip2 The following ports are currently installed: bzip2 @1.0.5_1 grendel% port outdated bzip2 No installed ports are outdated. grendel% port installed gettext The following ports are currently installed: gettext @0.17_4 grendel% port outdated gettext No installed ports are outdated. grendel% port installed zlib The following ports are currently installed: zlib @1.2.3_2 grendel% port outdated zlib No installed ports are outdated. grendel% port installed python25 The following ports are currently installed: python25 @2.5.2_1+darwin_9 grendel% port outdated python25 The following installed ports are outdated: python25 2.5.2_1 < 2.5.4_0 grendel% port installed expat The following ports are currently installed: expat @2.0.1_0 grendel% port outdated expat No installed ports are outdated. grendel% port installed libiconv The following ports are currently installed: libiconv @1.12_2 grendel% port outdated libiconv No installed ports are outdated. Here are some captures of the output from the commands. There are a number of cannot find receipt errors below, but when I search the /opt/local/var/macports/receipts directories, I find what looks like receipts for those ports: grendel% ll /opt/local/var/macports/receipts/libiconv/1.12_2/ total 4 -rw-r--r-- 1 royar admin 1187 2009-02-06 16:05 receipt.bz2 [All attachments are at http://trac.macports.org/ticket/18408 ] bash-3.2$ port -d upgrade mercurial &> /tmp/debug [attached as debug.gz] bash-3.2$ port -df upgrade mercurial &> /tmp/debug1 [attached as debug1.gz] bash-3.2$ port -dn upgrade mercurial &> /tmp/debug2 [attached as debug2.gz] bash-3.2$ port -dfn upgrade mercurial &> /tmp/debug3 [attached as debug3.gz] -- Dr. Robert Delius Royar Associate Professor of English Morehead State University Morehead, Kentucky From toby at macports.org Fri Feb 6 14:31:02 2009 From: toby at macports.org (Toby Peterson) Date: Fri, 6 Feb 2009 14:31:02 -0800 Subject: [46483] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: <498C7A04.6@macports.org> References: <20090205164718.6BEABE8106E@beta.macosforge.org> <498BC7BE.5020802@macports.org> <0B078615-CF2B-4660-BE26-C676C89E6CDD@macports.org> <74c219d30902060541i67ece841t758bd0b0479f41f3@mail.gmail.com> <498C7A04.6@macports.org> Message-ID: <74c219d30902061431i53cd1adcr1e88c425af6689b7@mail.gmail.com> On Fri, Feb 6, 2009 at 9:57 AM, Joshua Root wrote: > Toby Peterson wrote: >> On Thu, Feb 5, 2009 at 10:51 PM, Ryan Schmidt wrote: >>> On Feb 6, 2009, at 00:01, Marcus Calhoun-Lopez wrote: >>> >>>> Joshua Root writes: >>>> >>>>> There's the hw.cpu64bit_capable sysctl variable, on Leopard. >>>> Just what I was looking for. >>>> Thank you. >>>> >>>> I only have Leopard machines to test on, however. >>>> Does anyone know if the code: >>>> if { [exec "/usr/sbin/sysctl" "-n" "hw.cpu64bit_capable"] != "1" } { >>>> . >>>> . >>>> . >>>> } >>>> works on all platforms where universal binaries might be built? >>> Hmm. Well, on Tiger it says: >>> >>> /usr/sbin/sysctl -n hw.cpu64bit_capable >>> second level name cpu64bit_capable in hw.cpu64bit_capable is invalid >>> >>> So if you were to write code around that response, you would presumably >>> assume that 64-bit binaries cannot be built on Tiger, which isn't >>> necessarily so. >>> >>> Maybe there's a way we can ask about the processor family. >> >> I think the easiest solution is to simply match the architectures of libSystem. > > No good, it has ppc64 even on a G4. Eh, I guess I missed the point of this thread. Ignore me. - Toby From markd at macports.org Fri Feb 6 17:18:44 2009 From: markd at macports.org (markd at macports.org) Date: Fri, 06 Feb 2009 17:18:44 -0800 Subject: patching in general Message-ID: >On Feb 5, 2009, at 12:12, markd at macports.org wrote: > >> But then we could probably do with a lot of macros that we don't >> have now. >> Things like portage has (dobin, dodoc, etc.) would be a higher >> stage of >> development that we may get to someday. > >Could you describe what these do? All I know about portage is that >it's a package manager for Gentoo Linux, but I don't know how it >works inside. Hi Ryan, Well I've never used Portage, but I have looked at their portfiles (emerge or whatever they are called) sometimes in the past to check out how their port authors did a given port, or to see if they had useful patches. All I can say is that I remember they have 'dodoc' and 'dobin' (seems like they could've used better names), which I think installs the given files into the standard doc and bin locations. That's really all I know about it. Mark From raimue at macports.org Fri Feb 6 17:48:31 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 07 Feb 2009 02:48:31 +0100 Subject: patching in general In-Reply-To: References: Message-ID: <498CE86F.3030205@macports.org> markd at macports.org wrote: > Well I've never used Portage, but I have looked at their portfiles (emerge > or whatever they are called) sometimes in the past to check out how their > port authors did a given port, or to see if they had useful patches. All > I can say is that I remember they have 'dodoc' and 'dobin' (seems like > they could've used better names), which I think installs the given files > into the standard doc and bin locations. That's really all I know about > it. I don't know that much about ebuilds in portage in detail although I already used it. If dobin and dodoc simply copy the file over without additional logic, these would just be aliases for xinstall in our case: dobin: xinstall -m 755 foo ${destroot}${prefix}/bin dodoc: xinstall -m 644 foo ${destroot}${prefix}/share/doc/${name} We could create such aliases if there is really a need for it. Most ports simply use the 'make install' of the software anyway and we already have a much more general approach with xinstall. But if we are going to do it, I don't like these names do* very much, I think xinstall-bin/xinstall-doc would be better. Do you think we need something like this at all? Rainer From ryandesign at macports.org Fri Feb 6 23:16:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Feb 2009 01:16:02 -0600 Subject: Problems building KDE4 In-Reply-To: <296DAC23-A600-44A4-A542-784F0E4B9DDD@macports.org> References: <1233906548.7833.3.camel@debian> <296DAC23-A600-44A4-A542-784F0E4B9DDD@macports.org> Message-ID: On Feb 6, 2009, at 01:59, Ryan Schmidt wrote: > On Feb 6, 2009, at 01:49, Jean-Michel Pour? wrote: > >> 3. Was anyone succesfull running this command in the past 7 days: >> sudo >> port -v install kdesdk4. > > I have not tried, but I can try now. It took awhile, but yes, I was able to install kdesdk4 on Mac OS X 10.5.6 Intel with Xcode 3.1.2. I can try on PowerPC too if you need, but it will probably take a week to compile; my Power Mac G4 is a lot slower than my MacBook Pro. From jm at poure.com Sat Feb 7 01:23:26 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sat, 07 Feb 2009 10:23:26 +0100 Subject: [46539] trunk/dports/multimedia/frei0r-plugins/Portfile In-Reply-To: <20090206150334.B8179E984BA@beta.macosforge.org> References: <20090206150334.B8179E984BA@beta.macosforge.org> Message-ID: <1233998606.6012.1.camel@debian> On Fri, 2009-02-06 at 07:03 -0800, devans at macports.org wrote: > +livecheck.check regex > +livecheck.url http://propirate.net/frei0r/ > +livecheck.regex "${name}-(\\d+(?:\\.\\d+)*)${extract.suffix}" Thanks. This is okay. Sorry, I did not notice your message and hence could not know the timeout. Besides, I am still stuck on kde4 compiling loosing one hour everyday trying to figure out how to compile it. From apple at frinabulax.org Sat Feb 7 05:12:36 2009 From: apple at frinabulax.org (robert delius royar) Date: Sat, 7 Feb 2009 08:12:36 -0500 Subject: [MacPorts] #18408: Cannot upgrade mercurial (macports wants to reinstall latest dependencies) In-Reply-To: <065.48278d077476f5b62311283683e58920@macports.org> References: <056.f0f7c014bc687e6f5cb8d4fab8b9a7b5@macports.org> <065.48278d077476f5b62311283683e58920@macports.org> Message-ID: Sat, 7 Feb 2009 (03:11 -0000 UTC) MacPorts wrote: > #18408: Cannot upgrade mercurial (macports wants to reinstall latest dependencies) > ----------------------------------+----------------------------------------- > Reporter: apple@? | Owner: deric@? > Type: defect | Status: new > Priority: Normal | Milestone: Port Bugs > Component: ports | Version: 1.7.0 > Keywords: | Port: mercurial > ----------------------------------+----------------------------------------- > Changes (by macsforever2000@?): > > * owner: macports-tickets@? => deric@? > * port: => mercurial > > > Comment: > > Try the following: > > {{{ > sudo port selfupdate > sudo port upgrade mercurial > }}} > > If it fails, just attach the output in your reply. The portfile was the latest because I ran selfupdate before I tried to upgrade initially. grendel% port selfupdate MacPorts base version 1.700 installed Downloaded MacPorts base version 1.700 The MacPorts installation is not outdated so it was not updated grendel% diff /DooDad/Backups.backupdb/grendel/2009-02-06-003745/Bede/opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/mercurial/Portfile /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/mercurial/Portfile grendel% DooDad is my Timemachine drive By the way, I finally did a manual upgrade of the port (stepping through each phase of the build and discovered that configure is not in the the tarball for the port. But macports calls it anyway. Stopping the build. The prefix variable in the mercurial Makefile and setup.py is still set to /usr/local (there are no patches). I think the problem I am having is at a lower level than the mercurial port, but the port itself does not appear to be correct for the tarball being downloaded. -- Dr. Robert Delius Royar Associate Professor of English Morehead State University Morehead, Kentucky From illogical1 at gmail.com Sat Feb 7 05:50:54 2009 From: illogical1 at gmail.com (O) Date: Sat, 7 Feb 2009 08:50:54 -0500 Subject: Compiler configuration In-Reply-To: <952B8EC4-22ED-4799-9162-9E0A6B7EE480@macports.org> References: <1233907831.9152.2.camel@debian> <952B8EC4-22ED-4799-9162-9E0A6B7EE480@macports.org> Message-ID: <797cc39c0902070550v63136ba8j2bc8883bc237b20e@mail.gmail.com> On Fri, Feb 6, 2009 at 3:34 AM, Anders F Bj?rklund wrote: > Jean-Michel Pour? wrote: > >> Most MacPorts packages do not carry a reference to a specific gcc >> version. As a result, Apple gcc installed in Xcode is used. >> >> I am just a beginner, but wouldn't it be a more stable solution to rely >> only on GNU gcc 2.4 and gcc-4.2 and 4.3 using MacPorts packages. More stable? Maybe. Viable? Unfortunately no. There are instances where apple's version of the compiler is _required_ to compile programs. This happens when some extensions/features which are present, and used in apple's version of gcc were not (and likely never will be) included into the official gnu version. > > > In a word: no. :-) > > Even using the "apple-gcc*" ports would be more of a hassle than just > using /usr/bin/gcc*. And using GNU/FSF version of GCC would be worse... > Theoretically, you are right - owning the ports allows for more control. > But in practice the usual approach is to use Xcode for GCC and make etc. > > Other systems do it differently, but MacPorts usually recommends several > things to be present on the system before installing base/port(1) itself. > Like: GCC etc, X11, Tcl, Foundation, mtree, rsync, curl, ssl and more... > Some of these can be replaced with the versions from MacPorts, later on. > > > I'd go with the vendor GCC unless you need a feature that is not present, > like support for Java (GCJ) or Fortran or desires to play with GCC 4.3 ? > > And, yes, this the opposite approach as being used for Perl/Python/Ruby... > There MacPorts version are preferred. It's a little inconsistent, that way. > > --anders > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From illogical1 at gmail.com Sat Feb 7 06:47:08 2009 From: illogical1 at gmail.com (O) Date: Sat, 7 Feb 2009 09:47:08 -0500 Subject: [46548] trunk/dports/databases/mysql5-devel/Portfile In-Reply-To: <20090206194202.E7E97E9AE23@beta.macosforge.org> References: <20090206194202.E7E97E9AE23@beta.macosforge.org> Message-ID: <797cc39c0902070647p74429524nc23582eb01e500b4@mail.gmail.com> On Fri, Feb 6, 2009 at 2:42 PM, wrote: > Revision 46548 Author jwa at macports.org Date 2009-02-06 11:41:58 -0800 (Fri, > 06 Feb 2009) > > Log Message > > version bump to 5.1.31 Hey, I'd like to add libmysqld.a to the default installation of mysql5-devel. I've been using the library for a while now in amarok and it's fine and doesn't interfere with anything else. Is this OK? From illogical1 at gmail.com Sat Feb 7 06:48:22 2009 From: illogical1 at gmail.com (O) Date: Sat, 7 Feb 2009 09:48:22 -0500 Subject: [46548] trunk/dports/databases/mysql5-devel/Portfile In-Reply-To: <797cc39c0902070647p74429524nc23582eb01e500b4@mail.gmail.com> References: <20090206194202.E7E97E9AE23@beta.macosforge.org> <797cc39c0902070647p74429524nc23582eb01e500b4@mail.gmail.com> Message-ID: <797cc39c0902070648w2e6fb7a1y94a826572703412f@mail.gmail.com> On Sat, Feb 7, 2009 at 9:47 AM, O wrote: > On Fri, Feb 6, 2009 at 2:42 PM, wrote: >> Revision 46548 Author jwa at macports.org Date 2009-02-06 11:41:58 -0800 (Fri, >> 06 Feb 2009) >> >> Log Message >> >> version bump to 5.1.31 > Hey, I'd like to add libmysqld.a to the default installation of > mysql5-devel. I've been using the library for a while now in amarok > and it's fine and doesn't interfere with anything else. Is this OK? > I meant building mysql with the -fPIC flag doesn't interfere with anything else (from what I can see) From mdcrawford at gmail.com Sat Feb 7 07:44:33 2009 From: mdcrawford at gmail.com (Michael Crawford) Date: Sat, 7 Feb 2009 07:44:33 -0800 Subject: Compiler configuration In-Reply-To: <797cc39c0902070550v63136ba8j2bc8883bc237b20e@mail.gmail.com> References: <1233907831.9152.2.camel@debian> <952B8EC4-22ED-4799-9162-9E0A6B7EE480@macports.org> <797cc39c0902070550v63136ba8j2bc8883bc237b20e@mail.gmail.com> Message-ID: On Sat, Feb 7, 2009 at 5:50 AM, O wrote: > This happens when some extensions/features which are present, and used > in apple's version of gcc were not (and likely never will be) included > into the official gnu version. Richard Stallman has always griped about #pragma, and I understand has specifically threatened to remove support for #import from Objective-C preprocessing. While strictly speaking I think he's correct, to act on this would break mountains of existing source code. Mike -- Michael David Crawford mdcrawford at gmail dot com I'm looking for a job in Silicon Valley: http://www.goingware.com/resume/cover-letter.html From jm at poure.com Sat Feb 7 09:35:26 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sat, 07 Feb 2009 18:35:26 +0100 Subject: Problems building KDE4 In-Reply-To: References: <1233906548.7833.3.camel@debian> <296DAC23-A600-44A4-A542-784F0E4B9DDD@macports.org> Message-ID: <1234028126.22178.0.camel@debian> On Sat, 2009-02-07 at 01:16 -0600, Ryan Schmidt wrote: > It took awhile, but yes, I was able to install kdesdk4 on Mac OS X > 10.5.6 Intel with Xcode 3.1.2. > Thanks for testing. It appear that I am running MacOsX 10.4 and Xcode 2.5. Will get back. Can anyone with the same profile compile kdesdk4. Kind regards, JM From jm at poure.com Sat Feb 7 09:38:18 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sat, 07 Feb 2009 18:38:18 +0100 Subject: doxygen Message-ID: <1234028298.22454.0.camel@debian> Just a quick note that doxygen is still broken. Kind regards, JM From ryandesign at macports.org Sat Feb 7 09:54:58 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Feb 2009 11:54:58 -0600 Subject: Problems building KDE4 In-Reply-To: <1234028126.22178.0.camel@debian> References: <1233906548.7833.3.camel@debian> <296DAC23-A600-44A4-A542-784F0E4B9DDD@macports.org> <1234028126.22178.0.camel@debian> Message-ID: <3359FCA1-35BB-4B59-875D-67FD56279E20@macports.org> On Feb 7, 2009, at 11:35, Jean-Michel Pour? wrote: > On Sat, 2009-02-07 at 01:16 -0600, Ryan Schmidt wrote: >> It took awhile, but yes, I was able to install kdesdk4 on Mac OS X >> 10.5.6 Intel with Xcode 3.1.2. > > Thanks for testing. > > It appear that I am running MacOsX 10.4 and Xcode 2.5. > > Will get back. Can anyone with the same profile compile kdesdk4. Unlikely, since the kde4 portgroup relies on Apple's gcc 4.2, which is only available in Xcode 3+ which is only available on Mac OS X 10.5 +. The kde4 portgroup should be changed to output a message that it requires Mac OS X 10.5 or greater, until the way to make it work on 10.4 can be found. From ryandesign at macports.org Sat Feb 7 09:55:33 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Feb 2009 11:55:33 -0600 Subject: doxygen In-Reply-To: <1234028298.22454.0.camel@debian> References: <1234028298.22454.0.camel@debian> Message-ID: On Feb 7, 2009, at 11:38, Jean-Michel Pour? wrote: > Just a quick note that doxygen is still broken. In what way? doxygen @1.5.8_1 builds on all my systems (10.4 and 10.5, Intel and PowerPC). From raimue at macports.org Sat Feb 7 10:02:55 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 07 Feb 2009 19:02:55 +0100 Subject: doxygen In-Reply-To: <1234028298.22454.0.camel@debian> References: <1234028298.22454.0.camel@debian> Message-ID: <498DCCCF.8030202@macports.org> Jean-Michel Pour? wrote: > Just a quick note that doxygen is still broken. Ticket id? Debug log? Patch? How is your quick note supposed to be helpful? This is a quick note that doxygen @1.5.8_1 builds fine or me on Mac OS X 10.5.6 Leopard on Intel ;-) Rainer From jm at poure.com Sat Feb 7 10:09:52 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sat, 07 Feb 2009 19:09:52 +0100 Subject: doxygen In-Reply-To: <498DCCCF.8030202@macports.org> References: <1234028298.22454.0.camel@debian> <498DCCCF.8030202@macports.org> Message-ID: <1234030192.23582.0.camel@debian> On Sat, 2009-02-07 at 19:02 +0100, Rainer M?ller wrote: > > Ticket id? Debug log? Patch? > How is your quick note supposed to be helpful? > > This is a quick note that doxygen @1.5.8_1 builds fine or me on > Mac OS X 10.5.6 Leopard on Intel ;-) Sorry I created a ticket on doxygen a few days ago but I cannot find it. Here is the crash: gmake[2]: quittant le r'epertoire << /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/libmd5 >> gmake[1]: quittant le r'epertoire << /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/libmd5 >> /opt/local/bin/gmake -C src gmake[1]: entrant dans le r'epertoire << /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/src >> env TMAKEPATH=/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/lib/macosx-c++ /opt/local/bin/perl /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/bin/tmake libdoxygen.pro >Makefile.libdoxygen env TMAKEPATH=/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/lib/macosx-c++ /opt/local/bin/perl /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/bin/tmake libdoxycfg.pro >Makefile.libdoxycfg env TMAKEPATH=/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/lib/macosx-c++ /opt/local/bin/perl /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/bin/tmake doxygen.pro >Makefile.doxygen env TMAKEPATH=/opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/lib/macosx-c++ /opt/local/bin/perl /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/bin/tmake doxytag.pro >Makefile.doxytag /opt/local/bin/gmake -f Makefile.libdoxycfg PERL=/opt/local/bin/perl all gmake[2]: entrant dans le r'epertoire << /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/src >> flex -PconfigYY -t config.l >config.cpp /usr/bin/g++-4.0 -I/opt/local/include -c -pipe -D__FreeBSD__=6 -Wall -W -O2 -I../qtools -o ../objects/config.o config.cpp /usr/bin/g++-4.0 -I/opt/local/include -c -pipe -D__FreeBSD__=6 -Wall -W -O2 -I../qtools -o ../objects/configoptions.o configoptions.cpp /usr/bin/g++-4.0 -I/opt/local/include -c -pipe -D__FreeBSD__=6 -Wall -W -O2 -I../qtools -o ../objects/portable.o portable.cpp portable.cpp: In function 'size_t portable_iconv(void*, const char**, size_t*, char**, size_t*)': portable.cpp:392: error: invalid conversion from 'char**' to 'const char**' portable.cpp:392: error: initializing argument 2 of 'size_t libiconv(void*, const char**, size_t*, char**, size_t*)' gmake[2]: *** [../objects/portable.o] Erreur 1 gmake[2]: quittant le r'epertoire << /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/src >> gmake[1]: *** [all] Erreur 2 gmake[1]: quittant le r'epertoire << /opt/local/var/macports/build/_opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/src >> make: *** [all] Error 2 From ryandesign at macports.org Sat Feb 7 10:11:19 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Feb 2009 12:11:19 -0600 Subject: [46483] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: <7EAEBB7E-A11F-4C09-926E-84FD923A3956@lavergne.gotdns.org> References: <20090205164718.6BEABE8106E@beta.macosforge.org> <498BC7BE.5020802@macports.org> <0B078615-CF2B-4660-BE26-C676C89E6CDD@macports.org> <7EAEBB7E-A11F-4C09-926E-84FD923A3956@lavergne.gotdns.org> Message-ID: On Feb 6, 2009, at 06:22, Jeremy Lavergne wrote: > the machine command: > machine > i486 > > machine > ppc7450 Ok, on my Intel Core 2 Duo MacBook Pro "machine" says "i486". What does "machine" say on an Intel Core Mac? Does anyone have a 1st- generation Intel Mac to try that out? (I have a feeling it will also say "i486" and thus not help us differentiating.) There must be a way to do this; Apple clearly does in System Profiler. I guess if worst came to worst we could extract the cpu_type out of "system_profiler -xml SPHardwareDataType". We wouldn't need any big database of processor types, since there was just one 64-bit PowerPC processor (the G5), and just one non-64-bit Intel processor (the Intel Core). From illogical1 at gmail.com Sat Feb 7 10:13:50 2009 From: illogical1 at gmail.com (O) Date: Sat, 7 Feb 2009 13:13:50 -0500 Subject: Problems building KDE4 In-Reply-To: <1233906548.7833.3.camel@debian> References: <1233906548.7833.3.camel@debian> Message-ID: <797cc39c0902071013i13c870f8jab4d757e5ee38aa0@mail.gmail.com> On Fri, Feb 6, 2009 at 2:49 AM, Jean-Michel Pour? wrote: > Hello, > > I spent more than 30 hours tryine to compile KDE4. Of course, I did not > stay all this time in front of the computer. > > Would it be possible to help me compiling KDE4. Illogical, KDE4 > maintainer was not able to understand why compilation breaks. Connecting > on FreeNode, most KDE-MAC developers told me they were able to compile. I've tried to explain this multiple times but I must be doing a pretty bad job. So let me try this again. 1. KDE 4.anything in macports will only compile properly using _apple's_ gcc, version 4.2. 2. GNU's GCC 4.2 will not work because of its inability to compilation code in Apple's SDK. 3. GCC 3.anything, from apple or otherwise is _probably_ too old. 4. GCC 4.0 works, but only up until a certain point because of bugs in the compiler. 5. You're probably on 10.4 using gcc 4.0 or GNU's gcc 4.2 and they won't work. :-/ I was able to compile on everything in 10.4 by manually installing apple-gcc42 using the (rather poor) instructions here: http://techbase.kde.org/Projects/KDE_on_Mac_OS_X/Macbook_Manifesto#Tiger But I haven't had time or resources to work on this further as my partition with 10.4 on it died. From ryandesign at macports.org Sat Feb 7 10:13:58 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Feb 2009 12:13:58 -0600 Subject: [MacPorts] #18408: Cannot upgrade mercurial (macports wants to reinstall latest dependencies) In-Reply-To: References: <056.f0f7c014bc687e6f5cb8d4fab8b9a7b5@macports.org> <065.48278d077476f5b62311283683e58920@macports.org> Message-ID: <2411664D-08E1-4A84-88DF-8D2C99627C1F@macports.org> On Feb 7, 2009, at 07:12, robert delius royar wrote: > By the way, I finally did a manual upgrade of the port (stepping > through each phase of the build and discovered that configure is > not in the the tarball for the port. But macports calls it anyway. > Stopping the build. The prefix variable in the mercurial Makefile > and setup.py is still set to /usr/local (there are no patches). I > think the problem I am having is at a lower level than the > mercurial port, but the port itself does not appear to be correct > for the tarball being downloaded. Just a quick note to say mercurial @1.1.2_0 installs fine for me on Mac OS X 10.4 Intel. From jm at poure.com Sat Feb 7 10:16:35 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sat, 07 Feb 2009 19:16:35 +0100 Subject: Problems building KDE4 In-Reply-To: <3359FCA1-35BB-4B59-875D-67FD56279E20@macports.org> References: <1233906548.7833.3.camel@debian> <296DAC23-A600-44A4-A542-784F0E4B9DDD@macports.org> <1234028126.22178.0.camel@debian> <3359FCA1-35BB-4B59-875D-67FD56279E20@macports.org> Message-ID: <1234030595.23582.5.camel@debian> On Sat, 2009-02-07 at 11:54 -0600, Ryan Schmidt wrote: > Unlikely, since the kde4 portgroup relies on Apple's gcc 4.2, which > is only available in Xcode 3+ which is only available on Mac OS X > 10.5 > +. The kde4 portgroup should be changed to output a message that it > requires Mac OS X 10.5 or greater, until the way to make it work on > 10.4 can be found. apple-gcc42 is present as a Port. I could compile it. Can it work on 10.4? From jm at poure.com Sat Feb 7 10:20:17 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sat, 07 Feb 2009 19:20:17 +0100 Subject: Problems building KDE4 In-Reply-To: <797cc39c0902071013i13c870f8jab4d757e5ee38aa0@mail.gmail.com> References: <1233906548.7833.3.camel@debian> <797cc39c0902071013i13c870f8jab4d757e5ee38aa0@mail.gmail.com> Message-ID: <1234030817.23582.8.camel@debian> On Sat, 2009-02-07 at 13:13 -0500, O wrote: > I was able to compile on everything in 10.4 by manually installing > apple-gcc42 using the (rather poor) instructions here: > http://techbase.kde.org/Projects/KDE_on_Mac_OS_X/Macbook_Manifesto#Tiger > But I haven't had time or resources to work on this further as my > partition with 10.4 on it died. If we compile MLT and KDEnlive, then apple-gcc42 new portfile should be commited to SVN. At least this enable people to test Apple GCC 42 on 10.4. Including me :) I am testing right now. Kind regards, Jean-Michel From ryandesign at macports.org Sat Feb 7 10:30:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Feb 2009 12:30:23 -0600 Subject: Problems building KDE4 In-Reply-To: <1234030595.23582.5.camel@debian> References: <1233906548.7833.3.camel@debian> <296DAC23-A600-44A4-A542-784F0E4B9DDD@macports.org> <1234028126.22178.0.camel@debian> <3359FCA1-35BB-4B59-875D-67FD56279E20@macports.org> <1234030595.23582.5.camel@debian> Message-ID: <1F9D7561-F403-4B05-AFB3-DF6138893A10@macports.org> On Feb 7, 2009, at 12:16, Jean-Michel Pour? wrote: > On Sat, 2009-02-07 at 11:54 -0600, Ryan Schmidt wrote: >> Unlikely, since the kde4 portgroup relies on Apple's gcc 4.2, which >> is only available in Xcode 3+ which is only available on Mac OS X >> 10.5 >> +. The kde4 portgroup should be changed to output a message that it >> requires Mac OS X 10.5 or greater, until the way to make it work on >> 10.4 can be found. > > apple-gcc42 is present as a Port. I could compile it. Can it work on > 10.4? Apparently not until http://trac.macports.org/ticket/16666 is resolved. There is a patch there, and we have reached maintainer timeout, but I have some concerns about the changes, which I've noted in the ticket. From ryandesign at macports.org Sat Feb 7 10:32:55 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Feb 2009 12:32:55 -0600 Subject: doxygen In-Reply-To: <1234030192.23582.0.camel@debian> References: <1234028298.22454.0.camel@debian> <498DCCCF.8030202@macports.org> <1234030192.23582.0.camel@debian> Message-ID: <0EDF4D7D-355A-4E27-9B5D-44FE9A70C66C@macports.org> On Feb 7, 2009, at 12:09, Jean-Michel Pour? wrote: > On Sat, 2009-02-07 at 19:02 +0100, Rainer M?ller wrote: >> >> Ticket id? Debug log? Patch? >> How is your quick note supposed to be helpful? >> >> This is a quick note that doxygen @1.5.8_1 builds fine or me on >> Mac OS X 10.5.6 Leopard on Intel ;-) > > Sorry I created a ticket on doxygen a few days ago but I cannot > find it. > > Here is the crash: > > gmake[2]: quittant le r'epertoire > << /opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/libmd5 >> > gmake[1]: quittant le r'epertoire > << /opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/libmd5 >> > /opt/local/bin/gmake -C src > gmake[1]: entrant dans le r'epertoire > << /opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/src >> > env > TMAKEPATH=/opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/ > lib/macosx-c++ /opt/local/bin/perl /opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/ > bin/tmake libdoxygen.pro >Makefile.libdoxygen > env > TMAKEPATH=/opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/ > lib/macosx-c++ /opt/local/bin/perl /opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/ > bin/tmake libdoxycfg.pro >Makefile.libdoxycfg > env > TMAKEPATH=/opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/ > lib/macosx-c++ /opt/local/bin/perl /opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/ > bin/tmake doxygen.pro >Makefile.doxygen > env > TMAKEPATH=/opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/ > lib/macosx-c++ /opt/local/bin/perl /opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/tmake/ > bin/tmake doxytag.pro >Makefile.doxytag > /opt/local/bin/gmake -f Makefile.libdoxycfg PERL=/opt/local/bin/ > perl all > gmake[2]: entrant dans le r'epertoire > << /opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/src >> > flex -PconfigYY -t config.l >config.cpp > /usr/bin/g++-4.0 -I/opt/local/include -c -pipe -D__FreeBSD__=6 - > Wall -W > -O2 -I../qtools -o ../objects/config.o config.cpp > /usr/bin/g++-4.0 -I/opt/local/include -c -pipe -D__FreeBSD__=6 - > Wall -W > -O2 -I../qtools -o ../objects/configoptions.o configoptions.cpp > /usr/bin/g++-4.0 -I/opt/local/include -c -pipe -D__FreeBSD__=6 - > Wall -W > -O2 -I../qtools -o ../objects/portable.o portable.cpp > portable.cpp: In function 'size_t portable_iconv(void*, const char**, > size_t*, char**, size_t*)': > portable.cpp:392: error: invalid conversion from 'char**' to 'const > char**' > portable.cpp:392: error: initializing argument 2 of 'size_t > libiconv(void*, const char**, size_t*, char**, size_t*)' > gmake[2]: *** [../objects/portable.o] Erreur 1 > gmake[2]: quittant le r'epertoire > << /opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/src >> > gmake[1]: *** [all] Erreur 2 > gmake[1]: quittant le r'epertoire > << /opt/local/var/macports/build/ > _opt_mports_trunk_dports_textproc_doxygen/work/doxygen-1.5.8/src >> > make: *** [all] Error 2 Sorry -- I was wrong when I said I could build doxygen on all four OSes. It does fail for me on 10.4 PPC, but succeeds on the three others. See http://trac.macports.org/ticket/18258 (I see you're already Cc'd on that ticket) From apple at frinabulax.org Sat Feb 7 11:22:12 2009 From: apple at frinabulax.org (robert delius royar) Date: Sat, 7 Feb 2009 14:22:12 -0500 Subject: [MacPorts] #18408: Cannot upgrade mercurial (macports wants to reinstall latest dependencies) In-Reply-To: <2411664D-08E1-4A84-88DF-8D2C99627C1F@macports.org> References: <056.f0f7c014bc687e6f5cb8d4fab8b9a7b5@macports.org> <065.48278d077476f5b62311283683e58920@macports.org> <2411664D-08E1-4A84-88DF-8D2C99627C1F@macports.org> Message-ID: Sat, 7 Feb 2009 (12:13 -0600 UTC) Ryan Schmidt wrote: > > On Feb 7, 2009, at 07:12, robert delius royar wrote: > >> By the way, I finally did a manual upgrade of the port (stepping through >> each phase of the build and discovered that configure is not in the the >> tarball for the port. But macports calls it anyway. Stopping the build. >> The prefix variable in the mercurial Makefile and setup.py is still set to >> /usr/local (there are no patches). I think the problem I am having is at a >> lower level than the mercurial port, but the port itself does not appear to >> be correct for the tarball being downloaded. > > Just a quick note to say mercurial @1.1.2_0 installs fine for me on Mac OS X > 10.4 Intel. It looks as though the only way I can get mercurial to upgrade is to first uninstall mercurial, then uninstall python25, then install mercurial which reinstalls python25. I also had to manually delete the receipt for mercurial in /opt/local/var/receipts otherwise the install for mercurial would fail saying it was installed. Is it possible that there is something in 1.7.0 mp that has trouble with ports that use the PortGroup directive *and* are on a direct installation? I have other ports that do not show these problems, but the perl5 ports are other that I have seen this desire to reinstall (perl5 in that case). -- Dr. Robert Delius Royar Associate Professor of English Morehead State University Morehead, Kentucky From ryandesign at macports.org Sat Feb 7 11:40:04 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Feb 2009 13:40:04 -0600 Subject: [MacPorts] #18408: Cannot upgrade mercurial (macports wants to reinstall latest dependencies) In-Reply-To: References: <056.f0f7c014bc687e6f5cb8d4fab8b9a7b5@macports.org> <065.48278d077476f5b62311283683e58920@macports.org> <2411664D-08E1-4A84-88DF-8D2C99627C1F@macports.org> Message-ID: <0F69B553-9286-4F53-9B15-2E8D5A1C7F63@macports.org> On Feb 7, 2009, at 13:22, robert delius royar wrote: > Sat, 7 Feb 2009 (12:13 -0600 UTC) Ryan Schmidt wrote: > >> On Feb 7, 2009, at 07:12, robert delius royar wrote: >> >>> By the way, I finally did a manual upgrade of the port (stepping >>> through each phase of the build and discovered that configure is >>> not in the the tarball for the port. But macports calls it >>> anyway. Stopping the build. The prefix variable in the mercurial >>> Makefile and setup.py is still set to /usr/local (there are no >>> patches). I think the problem I am having is at a lower level >>> than the mercurial port, but the port itself does not appear to >>> be correct for the tarball being downloaded. >> >> Just a quick note to say mercurial @1.1.2_0 installs fine for me >> on Mac OS X 10.4 Intel. > > It looks as though the only way I can get mercurial to upgrade is > to first uninstall mercurial, then uninstall python25, then install > mercurial which reinstalls python25. I also had to manually delete > the receipt for mercurial in /opt/local/var/receipts otherwise the > install for mercurial would fail saying it was installed. Is it > possible that there is something in 1.7.0 mp that has trouble with > ports that use the PortGroup directive *and* are on a direct > installation? I have other ports that do not show these problems, > but the perl5 ports are other that I have seen this desire to > reinstall (perl5 in that case). I don't really understand the symptoms you are reporting. I see in the debug log you attached to the ticket that receipts do not exist for some of mercurial's dependencies: DEBUG: Didn't find receipt, going to depspec regex for: gettext DEBUG: Didn't find receipt, going to depspec regex for: libiconv DEBUG: Didn't find receipt, going to depspec regex for: python25 DEBUG: Didn't find receipt, going to depspec regex for: zlib DEBUG: Didn't find receipt, going to depspec regex for: bzip2 DEBUG: Didn't find receipt, going to depspec regex for: py25-zlib DEBUG: Didn't find receipt, going to depspec regex for: py25-hashlib DEBUG: Didn't find receipt, going to depspec regex for: py25-bz2 However, MacPorts then goes on to say that some of these are already installed: DEBUG: Skipping org.macports.main (libiconv) since this port is already installed DEBUG: Skipping org.macports.main (bzip2) since this port is already installed What is installed? Can you please show us the output of "port installed"? From devans at macports.org Sat Feb 7 13:29:08 2009 From: devans at macports.org (David Evans) Date: Sat, 07 Feb 2009 13:29:08 -0800 Subject: [MacPorts] #8221: RFE: port upgrade should consider variants when computing dependencies In-Reply-To: <068.ec5b3c356c7bcf1a1c6723c5cc58e253@macports.org> References: <059.84a5e0e5519aa71cf04ea9d33912dad6@macports.org> <068.ec5b3c356c7bcf1a1c6723c5cc58e253@macports.org> Message-ID: <498DFD24.3060701@macports.org> MacPorts wrote: > #8221: RFE: port upgrade should consider variants when computing dependencies > --------------------------------------+------------------------------------- > Reporter: ryandesign@? | Owner: gwhitney@? > Type: enhancement | Status: reopened > Priority: Normal | Milestone: MacPorts 1.8.0 > Component: base | Version: > Resolution: | Keywords: > Port: | > --------------------------------------+------------------------------------- > > Comment(by gwhitney@?): > > Indeed, trunk/base/src does not contain the string "dependencies on" -- it > was removed in r44362. So, devans, please could you try > rebuilding/reinstalling port from trunk and see if the problem goes away? > > Yes, my face is red. Have updated to latest trunk (really this time -- apparently I missed this particular mp instance). Am retesting now but looks good so far. Thanks for your work in resolving this issue. Please accept my apologies. From ryandesign at macports.org Sat Feb 7 15:13:10 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Feb 2009 17:13:10 -0600 Subject: [46582] trunk/dports/ruby/rb-mysql/Portfile In-Reply-To: <20090207213820.17046EA9BCF@beta.macosforge.org> References: <20090207213820.17046EA9BCF@beta.macosforge.org> Message-ID: <6F098E2B-0375-4A29-AFC0-ADA88EF6802C@macports.org> On Feb 7, 2009, at 15:38, febeling at macports.org wrote: > Revision: 46582 > http://trac.macports.org/changeset/46582 > Author: febeling at macports.org > Date: 2009-02-07 13:38:18 -0800 (Sat, 07 Feb 2009) > Log Message: > ----------- > ruby/rb-mysql: Change dependency on mysql to a path dependency, so > that mysql5 and mysql5-devel can provide it. (Port mysql (4.1) can > be used with the variant mysql4.) > > Modified Paths: > -------------- > trunk/dports/ruby/rb-mysql/Portfile > > Modified: trunk/dports/ruby/rb-mysql/Portfile > =================================================================== > --- trunk/dports/ruby/rb-mysql/Portfile 2009-02-07 21:14:37 UTC > (rev 46581) > +++ trunk/dports/ruby/rb-mysql/Portfile 2009-02-07 21:38:18 UTC > (rev 46582) > @@ -18,14 +18,14 @@ > checksums md5 4e42869196aa84ca17e70ab2287f8830 > platforms darwin > > -depends_lib port:mysql5 > +depends_lib path:bin/mysql_config5:mysql5 > depends_build port:ruby > configure.args --with-mysql-config=${prefix}/bin/mysql_config5 > > variant mysql4 description "Build using MySQL 4.1 client library" { > - depends_lib-delete port:mysql5 > + depends_lib-delete path:bin/mysql_config5:mysql5 > configure.args-delete --with-mysql-config=${prefix}/bin/ > mysql_config5 > > - depends_lib-append port:mysql4 > + depends_lib-append path:bin/mysql_config:mysql5 This last change is a typo, right? It shouldn't have been changed from "port:mysql4". From febeling at macports.org Sat Feb 7 15:54:37 2009 From: febeling at macports.org (C. Florian Ebeling) Date: Sun, 8 Feb 2009 00:54:37 +0100 Subject: [46582] trunk/dports/ruby/rb-mysql/Portfile In-Reply-To: <6F098E2B-0375-4A29-AFC0-ADA88EF6802C@macports.org> References: <20090207213820.17046EA9BCF@beta.macosforge.org> <6F098E2B-0375-4A29-AFC0-ADA88EF6802C@macports.org> Message-ID: <5cbbe4ae0902071554r55b1942fo4e6b360c2c64cc7a@mail.gmail.com> >> variant mysql4 description "Build using MySQL 4.1 client library" { >> - depends_lib-delete port:mysql5 >> + depends_lib-delete path:bin/mysql_config5:mysql5 >> configure.args-delete >> --with-mysql-config=${prefix}/bin/mysql_config5 >> >> - depends_lib-append port:mysql4 >> + depends_lib-append path:bin/mysql_config:mysql5 > > This last change is a typo, right? It shouldn't have been changed from > "port:mysql4". Indeed. Thanks. -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From weakish at gmail.com Sun Feb 8 08:06:20 2009 From: weakish at gmail.com (weakish jiang) Date: Mon, 9 Feb 2009 00:06:20 +0800 Subject: request the update of offlineimap be committed In-Reply-To: <700384770902080751u376b83a9t23ee6a0c81f4477b@mail.gmail.com> References: <700384770902080751u376b83a9t23ee6a0c81f4477b@mail.gmail.com> Message-ID: <700384770902080806r775e249ayc1306f1aee1c9ce0@mail.gmail.com> I submited the patch of offlineimap 7 days ago, and the maintainer does not respond within 72 hours. Thus I ask a review and commit(I am not a committer.) Ticket url: http://trac.macports.org/ticket/15978 Patch url: http://trac.macports.org/attachment/ticket/15978/offlineimap.patch From raimue at macports.org Sun Feb 8 09:19:15 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 08 Feb 2009 18:19:15 +0100 Subject: request the update of offlineimap be committed In-Reply-To: <700384770902080806r775e249ayc1306f1aee1c9ce0@mail.gmail.com> References: <700384770902080751u376b83a9t23ee6a0c81f4477b@mail.gmail.com> <700384770902080806r775e249ayc1306f1aee1c9ce0@mail.gmail.com> Message-ID: <498F1413.7010902@macports.org> weakish jiang wrote: > I submited the patch of offlineimap 7 days ago, and the maintainer > does not respond within > 72 hours. Thus I ask a review and commit(I am not a committer.) > > Ticket url: > http://trac.macports.org/ticket/15978 > > Patch url: > http://trac.macports.org/attachment/ticket/15978/offlineimap.patch Committed by Jeremy Lavergne (snc@) in r46593 [1]. Rainer [1] http://trac.macports.org/changeset/46593 From ryandesign at macports.org Sun Feb 8 13:04:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 8 Feb 2009 15:04:23 -0600 Subject: [46595] trunk/dports/kde/kdenetwork4/Portfile In-Reply-To: <20090208181527.E2898EC1864@beta.macosforge.org> References: <20090208181527.E2898EC1864@beta.macosforge.org> Message-ID: <867BE77A-3D2C-4CE5-9356-425E743318EE@macports.org> On Feb 8, 2009, at 12:15, illogic-al at macports.org wrote: > configure.args-append ../${distname} \ > + -DBUILD_kopete=ON -DWITH_jabber=OFF \ > -DQCA2_LIBRARIES=${prefix}/lib/libqca. > 2.dylib \ > -DQCA2_INCLUDE_DIR=${prefix}/include/QtCrypto > > -variant no_kopete { > - depends_lib-delete port:qca port:speex > +variant no_kopete description "Do not install Kopete instant > messaging client" { > + depends_lib-delete port:qca port:speex libotr > configure.args-delete -DBUILD_kopete=ON > configure.args-append -DBUILD_kopete=OFF > } > + > +variant jabber description "Enable jabber support in kopete" { > + configure.args-delete -DWITH_jabber=OFF > + configure.args-append -DWITH_jabber=ON > +} Can the +jabber and +no_kopete variants be used at the same time? Based on the descriptions I'm guessing not. If not, then the variants should be marked as conflicting with one another. variant no_kopete conflicts jabber description ... variant jabber conflicts no_kopete description ... From simon at ruderich.org Sun Feb 8 14:26:33 2009 From: simon at ruderich.org (Simon Ruderich) Date: Sun, 8 Feb 2009 23:26:33 +0100 Subject: Problem installing xorg-server on Tiger In-Reply-To: <1E556356-B5AD-47A9-98EB-DF8972672E90@macports.org> References: <20090131204620.GA3021@ruderich.org> <20090202134724.GA7245@ruderich.org> <310537F0-23E5-4C5B-98EB-C367B29BB1E1@macports.org> <42990F53-0243-44DC-ADF5-CA03AE94D008@macports.org> <20090202204633.GA12364@ruderich.org> <20090202204908.GB12364@ruderich.org> <1E556356-B5AD-47A9-98EB-DF8972672E90@macports.org> Message-ID: <20090208222633.GC18279@ruderich.org> On Mon, Feb 02, 2009 at 12:59:51PM -0800, Jeremy Huddleston wrote: > One other user is actually reporting odd CPU usage issues on Leopard. > Would you mind joining xquartz-dev to jump in that thread: > > http://lists.macosforge.org/mailman/listinfo/xquartz-dev > > http://lists.macosforge.org/pipermail/xquartz-dev/2009-January/001952.html > http://lists.macosforge.org/pipermail/xquartz-dev/2009-January/002042.html > http://lists.macosforge.org/pipermail/xquartz-dev/2009-January/002044.html Sorry for the late reply. I just joined the list and described them the problem. Thanks, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From billitch at gmail.com Sun Feb 8 19:24:55 2009 From: billitch at gmail.com (Thomas de Grivel) Date: Mon, 9 Feb 2009 04:24:55 +0100 Subject: Ports recommending other ports In-Reply-To: References: Message-ID: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> 2009/2/6 Ryan Schmidt : > It might be nice if a port could recommend the user install another port in > addition, via some new keyword. For example, graphviz could recommend the > user install graphviz-gui as well. postgresql83 could recommend the user > install postgresql83-server. port could output these recommendations at the > end of the installation. ("You may wish to install graphviz-gui as well.") > The advantage over just printing a message at post-install time would be > that port or a MacPorts GUI could offer the user the choice to install those > recommended ports too ("Would you like to install graphviz-gui now?") and > could know to omit the suggestion if the suggested port is already > installed. > > There could be another new keyword for recommended alternatives to a given > port. For example, on Leopard and later, graphviz-gui is a better choice > than graphviz-oldgui (which is required on Tiger and earlier). ("You may > wish to install graphviz-gui instead of graphviz-oldgui.") > > Hypothetical addition to port graphviz: > > if {${os.platform} == "darwin"} { > if {${os.major} >= 9} { > suggest_supplements-append port:graphviz-gui > } else { > suggest_supplements-append port:graphviz-oldgui > } > } > > Hypothetical additions to port graphviz-oldgui: > > if {${os.major} >= 9} { > suggest_alternatives-append port:graphviz-gui > } > > (I used "suggest" instead of "recommend" in the keyword names because people > have more trouble spelling "recommend".) just thinking out loud : maybe we could suggest variants as well ? and propose building (or even rebuilding) ports with more sensible variants according to installed ones ? -- Thomas de Grivel http://b.lowh.net/billitch/ From blu.dark at gmail.com Sun Feb 8 19:30:02 2009 From: blu.dark at gmail.com (martin krastev) Date: Sun, 8 Feb 2009 22:30:02 -0500 Subject: current libiconv port gets unnecessary upgrade, fails building Message-ID: <80caf8ca0902081930r1b92a886t1a8d9b4a689b406f@mail.gmail.com> platform: powerpc-apple-darwin8.11.0 macports libiconv fails at build stage. Possibly garbled makefile: $ sudo port -u upgrade libiconv Warning: Group file could not be located. Warning: Group file could not be located. ---> Fetching libiconv ---> Verifying checksum(s) for libiconv ---> Extracting libiconv ---> Applying patches to libiconv ---> Configuring libiconv ---> Building libiconv with target all Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_libiconv/work/libiconv-1.12" && make CC= -f Makefile.devel && make all " returned error 2 Command output: O lib/genaliases.c -o genaliases make: O: Command not found make: [lib/aliases.h] Error 127 (ignored) ./genaliases > lib/aliases.gperf 3> canonical.sh 4> canonical_local.sh /bin/sh: line 1: ./genaliases: No such file or directory make: *** [lib/aliases.h] Error 127 Error: Unable to upgrade port: 1 The peculiar thing is that the reported sync'ed port version is 1.12, and so is the actual installed version, but an upgrade is still attempted: $ port list installed .. libiconv @1.12 textproc/libiconv $ port list all .. libiconv @1.12 textproc/libiconv From blb at macports.org Sun Feb 8 19:47:06 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 8 Feb 2009 20:47:06 -0700 Subject: current libiconv port gets unnecessary upgrade, fails building In-Reply-To: <80caf8ca0902081930r1b92a886t1a8d9b4a689b406f@mail.gmail.com> References: <80caf8ca0902081930r1b92a886t1a8d9b4a689b406f@mail.gmail.com> Message-ID: <20090209034706.GH1047@ninagal.withay.com> On Sun, Feb 08, 2009 at 10:30:02PM -0500, martin krastev said: > platform: powerpc-apple-darwin8.11.0 > > macports libiconv fails at build stage. Possibly garbled makefile: > > $ sudo port -u upgrade libiconv > Warning: Group file could not be located. > Warning: Group file could not be located. This sounds like either your ports tree is incomplete (libiconv uses the new group muniversal) or your sources.conf wasn't properly upgraded. Does your /opt/local/etc/macports/sources.conf file have a line like rsync://rsync.macports.org/release/ports/ [default] or is the "[default]" missing? If missing, add it. > ---> Fetching libiconv > ---> Verifying checksum(s) for libiconv > ---> Extracting libiconv > ---> Applying patches to libiconv > ---> Configuring libiconv > ---> Building libiconv with target all > Error: Target org.macports.build returned: shell command " cd > "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_libiconv/work/libiconv-1.12" > && make CC= -f Makefile.devel && make all " returned error 2 > Command output: O lib/genaliases.c -o genaliases > make: O: Command not found What is the output from 'port version'? > make: [lib/aliases.h] Error 127 (ignored) > ./genaliases > lib/aliases.gperf 3> canonical.sh 4> canonical_local.sh > /bin/sh: line 1: ./genaliases: No such file or directory > make: *** [lib/aliases.h] Error 127 > > Error: Unable to upgrade port: 1 > > The peculiar thing is that the reported sync'ed port version is 1.12, > and so is the actual installed version, but an upgrade is still > attempted: > > $ port list installed > .. > libiconv @1.12 textproc/libiconv Better is to use 'port installed libiconv' which will tell you the actual version; 'list installed' will only confuse you. > > $ port list all > .. > libiconv @1.12 textproc/libiconv You can also use 'port info libiconv' for details on just that one port. Bryan From blu.dark at gmail.com Sun Feb 8 20:19:53 2009 From: blu.dark at gmail.com (martin krastev) Date: Sun, 8 Feb 2009 23:19:53 -0500 Subject: current libiconv port gets unnecessary upgrade, fails building In-Reply-To: <20090209034706.GH1047@ninagal.withay.com> References: <80caf8ca0902081930r1b92a886t1a8d9b4a689b406f@mail.gmail.com> <20090209034706.GH1047@ninagal.withay.com> Message-ID: <80caf8ca0902082019l19bfe2d0t6ded04fce158115c@mail.gmail.com> Thank you, Bryan. Here are the details as you advised: On Sun, Feb 8, 2009 at 10:47 PM, Bryan Blackburn wrote: > On Sun, Feb 08, 2009 at 10:30:02PM -0500, martin krastev said: >> platform: powerpc-apple-darwin8.11.0 >> >> macports libiconv fails at build stage. Possibly garbled makefile: >> >> $ sudo port -u upgrade libiconv >> Warning: Group file could not be located. >> Warning: Group file could not be located. > > This sounds like either your ports tree is incomplete (libiconv uses the new > group muniversal) or your sources.conf wasn't properly upgraded. Does your > /opt/local/etc/macports/sources.conf file have a line like > > rsync://rsync.macports.org/release/ports/ [default] > > or is the "[default]" missing? If missing, add it. It did not have it originally, but now it's been added. See for results below. >> ---> Fetching libiconv >> ---> Verifying checksum(s) for libiconv >> ---> Extracting libiconv >> ---> Applying patches to libiconv >> ---> Configuring libiconv >> ---> Building libiconv with target all >> Error: Target org.macports.build returned: shell command " cd >> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_libiconv/work/libiconv-1.12" >> && make CC= -f Makefile.devel && make all " returned error 2 >> Command output: O lib/genaliases.c -o genaliases >> make: O: Command not found > > What is the output from 'port version'? $ port version Warning: /opt/local/etc/macports/sources.conf source 'rsync://rsync.macports.org/release/ports/ [default]' specifies invalid flag 'default' Version: 1.600 >> make: [lib/aliases.h] Error 127 (ignored) >> ./genaliases > lib/aliases.gperf 3> canonical.sh 4> canonical_local.sh >> /bin/sh: line 1: ./genaliases: No such file or directory >> make: *** [lib/aliases.h] Error 127 >> >> Error: Unable to upgrade port: 1 >> >> The peculiar thing is that the reported sync'ed port version is 1.12, >> and so is the actual installed version, but an upgrade is still >> attempted: >> >> $ port list installed >> .. >> libiconv @1.12 textproc/libiconv > > Better is to use 'port installed libiconv' which will tell you the actual > version; 'list installed' will only confuse you. Warning: /opt/local/etc/macports/sources.conf source 'rsync://rsync.macports.org/release/ports/ [default]' specifies invalid flag 'default' The following ports are currently installed: libiconv @1.12_0+darwin_8 (active) >> $ port list all >> .. >> libiconv @1.12 textproc/libiconv > > You can also use 'port info libiconv' for details on just that one port. $ port info libiconv Warning: /opt/local/etc/macports/sources.conf source 'rsync://rsync.macports.org/release/ports/ [default]' specifies invalid flag 'default' Warning: Group file could not be located. libiconv 1.12, Revision 2, textproc/libiconv (Variants: universal, freebsd, linux, disable_utf8mac, disable_extra_encodings, enable_cp932fix) http://www.gnu.org/software/libiconv/ A character-set conversion library which implements the iconv() API for dealing with unicode and other types of conversion. Build Dependencies: gperf Platforms: darwin freebsd linux Maintainers: ryandesign at macports.org >From the above, I suspect that my macports may be outdated - shall I proceed with a selfupdate? -martin From ryandesign at macports.org Sun Feb 8 20:28:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 8 Feb 2009 22:28:08 -0600 Subject: [46627] trunk/base/doc/portfile.7 In-Reply-To: <20090209040629.CE24BED3F31@beta.macosforge.org> References: <20090209040629.CE24BED3F31@beta.macosforge.org> Message-ID: On Feb 8, 2009, at 22:06, blb at macports.org wrote: > Revision: 46627 > http://trac.macports.org/changeset/46627 > Author: blb at macports.org > Date: 2009-02-08 20:06:21 -0800 (Sun, 08 Feb 2009) > Log Message: > ----------- > portfile.7 - add documentation for startupitem.netchange Goodness! I totally forgot that was in MacPorts already. I suppose that should be added to all ports that have startupitems that use the network? From blb at macports.org Sun Feb 8 20:38:54 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 8 Feb 2009 21:38:54 -0700 Subject: [46627] trunk/base/doc/portfile.7 In-Reply-To: References: <20090209040629.CE24BED3F31@beta.macosforge.org> Message-ID: <20090209043854.GI1047@ninagal.withay.com> On Sun, Feb 08, 2009 at 10:28:08PM -0600, Ryan Schmidt said: > > On Feb 8, 2009, at 22:06, blb at macports.org wrote: > >> Revision: 46627 >> http://trac.macports.org/changeset/46627 >> Author: blb at macports.org >> Date: 2009-02-08 20:06:21 -0800 (Sun, 08 Feb 2009) >> Log Message: >> ----------- >> portfile.7 - add documentation for startupitem.netchange > > Goodness! I totally forgot that was in MacPorts already. I suppose that > should be added to all ports that have startupitems that use the network? Yeah, I noticed it was in the guide but not in portfile(7) hence I added it (since I use 'man portfile' more than the guide for referencing such stuff). As far as adding it to ports, it should definitely be added to any that will have issues when such changes occur (eg bind9, but that already has it). apache2, for example, doesn't seem to have an issue with it, though that could be because I have it set to listen on * instead of specific IPs. Bryan From blb at macports.org Sun Feb 8 20:53:38 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 8 Feb 2009 21:53:38 -0700 Subject: current libiconv port gets unnecessary upgrade, fails building In-Reply-To: <80caf8ca0902082019l19bfe2d0t6ded04fce158115c@mail.gmail.com> References: <80caf8ca0902081930r1b92a886t1a8d9b4a689b406f@mail.gmail.com> <20090209034706.GH1047@ninagal.withay.com> <80caf8ca0902082019l19bfe2d0t6ded04fce158115c@mail.gmail.com> Message-ID: <20090209045338.GJ1047@ninagal.withay.com> On Sun, Feb 08, 2009 at 11:19:53PM -0500, martin krastev said: > Thank you, Bryan. Here are the details as you advised: [...] > > $ port version > Warning: /opt/local/etc/macports/sources.conf source > 'rsync://rsync.macports.org/release/ports/ [default]' specifies > invalid flag 'default' > Version: 1.600 [...] > > From the above, I suspect that my macports may be outdated - shall I > proceed with a selfupdate? Most definitely, 1.7 fixes an issue (the Tcl env bug) which is probably what you were originally seeing, as well as many other improvements (and will also fix the 'Group not found'). So definitely run selfupdate, then clean libiconv (sudo port clean libiconv) and try again. Bryan > > -martin From blu.dark at gmail.com Sun Feb 8 21:14:14 2009 From: blu.dark at gmail.com (martin krastev) Date: Mon, 9 Feb 2009 00:14:14 -0500 Subject: current libiconv port gets unnecessary upgrade, fails building In-Reply-To: <20090209045338.GJ1047@ninagal.withay.com> References: <80caf8ca0902081930r1b92a886t1a8d9b4a689b406f@mail.gmail.com> <20090209034706.GH1047@ninagal.withay.com> <80caf8ca0902082019l19bfe2d0t6ded04fce158115c@mail.gmail.com> <20090209045338.GJ1047@ninagal.withay.com> Message-ID: <80caf8ca0902082114n3544f357o424c3cffe3f4bfa8@mail.gmail.com> On Sun, Feb 8, 2009 at 11:53 PM, Bryan Blackburn wrote: > Most definitely, 1.7 fixes an issue (the Tcl env bug) which is probably what > you were originally seeing, as well as many other improvements (and will also > fix the 'Group not found'). > > So definitely run selfupdate, then clean libiconv (sudo port clean libiconv) > and try again. ports selfupdate to 1.700 and subsequent libiconv cleanup and upgrade passed successfully. Thank you for your time, Bryan, Jeremy. From ryandesign at macports.org Sun Feb 8 21:30:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 8 Feb 2009 23:30:24 -0600 Subject: Ports recommending other ports In-Reply-To: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> Message-ID: <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> On Feb 8, 2009, at 21:24, Thomas de Grivel wrote: > just thinking out loud : > maybe we could suggest variants as well ? I would say no to this suggestion, because a port should already come pre-configured for the recommended setup out-of-the-box without needing to select any variants. There may be variants to turn off certain recommendations if appropriate, but the user can find all that out by typing "port variants ". But there is no command that a user can type today to get a list of other ports that are recommended in combination with a given port. In the cases I cited (graphviz and postgresql) the user can type "port search " and see those other ports, because they contain the original port's name, but that may not always be the case. > and propose building (or even rebuilding) ports with more sensible > variants according to installed ones ? Could you elaborate or give an example? From raimue at macports.org Mon Feb 9 04:10:06 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 09 Feb 2009 13:10:06 +0100 Subject: Ports recommending other ports In-Reply-To: References: Message-ID: <49901D1E.5030005@macports.org> Ryan Schmidt wrote: > It might be nice if a port could recommend the user install another > port in addition, via some new keyword. For example, graphviz could > recommend the user install graphviz-gui as well. postgresql83 could > recommend the user install postgresql83-server. port could output > these recommendations at the end of the installation. ("You may wish > to install graphviz-gui as well.") The advantage over just printing a > message at post-install time would be that port or a MacPorts GUI > could offer the user the choice to install those recommended ports > too ("Would you like to install graphviz-gui now?") and could know to > omit the suggestion if the suggested port is already installed. This could become a useful future addition, as currently all port commands are non-interactive. > There could be another new keyword for recommended alternatives to a > given port. For example, on Leopard and later, graphviz-gui is a > better choice than graphviz-oldgui (which is required on Tiger and > earlier). ("You may wish to install graphviz-gui instead of graphviz- > oldgui.") While I like the recommends feature, I don't think alternatives are that good proposed. If they recommend alternatives for the current port one should see them before installing this port at all. For example at the 'port info' output and then we can simply write such a sentence into the long_description. After installing a port it is too late to inform about alternatives. > Hypothetical addition to port graphviz: > > if {${os.platform} == "darwin"} { > if {${os.major} >= 9} { > suggest_supplements-append port:graphviz-gui > } else { > suggest_supplements-append port:graphviz-oldgui > } > } > > Hypothetical additions to port graphviz-oldgui: > > if {${os.major} >= 9} { > suggest_alternatives-append port:graphviz-gui > } > > (I used "suggest" instead of "recommend" in the keyword names because > people have more trouble spelling "recommend".) If people have problems spelling "recommend", they will probably also have problems with "supplements"? Rainer From vincent-opdarw at vinc17.org Mon Feb 9 05:47:24 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Mon, 9 Feb 2009 14:47:24 +0100 Subject: Ports recommending other ports In-Reply-To: <49901D1E.5030005@macports.org> References: <49901D1E.5030005@macports.org> Message-ID: <20090209134724.GA2378@prunille.vinc17.org> On 2009-02-09 13:10:06 +0100, Rainer M?ller wrote: > Ryan Schmidt wrote: > > It might be nice if a port could recommend the user install another > > port in addition, via some new keyword. For example, graphviz could > > recommend the user install graphviz-gui as well. postgresql83 could > > recommend the user install postgresql83-server. port could output > > these recommendations at the end of the installation. ("You may wish > > to install graphviz-gui as well.") The advantage over just printing a > > message at post-install time would be that port or a MacPorts GUI > > could offer the user the choice to install those recommended ports > > too ("Would you like to install graphviz-gui now?") and could know to > > omit the suggestion if the suggested port is already installed. > > This could become a useful future addition, as currently all port > commands are non-interactive. There could also be a config option to install recommendations by default (like in Debian, which does in fact the opposite: an option not to install the recommendations). -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From jeremy at lavergne.gotdns.org Mon Feb 9 06:21:39 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 9 Feb 2009 09:21:39 -0500 Subject: launchd startup items Message-ID: <674ADC4C-7F8E-4950-B100-A23F5DADB8A2@lavergne.gotdns.org> I have two question to pose this morning; hope you don't need too much coffee to respond coherently! Question 1: Why do launchd startup items use daemondo? Question 2: Is it frowned upon to include launchd plist files that don't use daemondo? Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From raimue at macports.org Mon Feb 9 06:58:32 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 09 Feb 2009 15:58:32 +0100 Subject: launchd startup items In-Reply-To: <674ADC4C-7F8E-4950-B100-A23F5DADB8A2@lavergne.gotdns.org> References: <674ADC4C-7F8E-4950-B100-A23F5DADB8A2@lavergne.gotdns.org> Message-ID: <49904498.7050608@macports.org> Jeremy Lavergne wrote: > Question 1: Why do launchd startup items use daemondo? daemondo is a wrapper around init scripts used on other systems. These use start/stop/restart arguments which are not compatible with launchd. daemondo allows to use these scripts without the need for a rewrite. > Question 2: Is it frowned upon to include launchd plist files that > don't use daemondo? No, if for example a port already provides a working launchd plist file it is fine to use it. Rainer From jeremy at lavergne.gotdns.org Mon Feb 9 09:54:18 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 9 Feb 2009 12:54:18 -0500 Subject: help on python, ticket #17433 Message-ID: <879DABD6-B1A7-4F7D-9C31-1AFE4DC194DE@lavergne.gotdns.org> There's a python portfile that is installing docs in an inappropriate location. It seems the installer merely mimics the directory structure from the port's download (as detailed by documentation_path = 'docs/_build/html' in setup.py --- which I assume is getting used). Do we have a python guru who can assert this is the case? The ticket is #17433: http://trac.macports.org/ticket/17433 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From dluke at geeklair.net Mon Feb 9 10:31:14 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon, 9 Feb 2009 13:31:14 -0500 Subject: [MacPorts] #18408: Cannot upgrade mercurial (macports wants to reinstall latest dependencies) In-Reply-To: <0F69B553-9286-4F53-9B15-2E8D5A1C7F63@macports.org> References: <056.f0f7c014bc687e6f5cb8d4fab8b9a7b5@macports.org> <065.48278d077476f5b62311283683e58920@macports.org> <2411664D-08E1-4A84-88DF-8D2C99627C1F@macports.org> <0F69B553-9286-4F53-9B15-2E8D5A1C7F63@macports.org> Message-ID: <9DE14AAF-93BC-41FF-8A56-529B405B20EA@geeklair.net> On Feb 7, 2009, at 2:40 PM, Ryan Schmidt wrote: > I don't really understand the symptoms you are reporting. Robert said before that he was using 'direct' mode (+ archivemode), and this looks a lot like the current problems with it. -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From brad at pixilla.com Mon Feb 9 12:21:33 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Feb 2009 12:21:33 -0800 Subject: tcl or portfile keyword for alias Message-ID: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> Does anyone know a simple way to env alias a command like mysql_config=/opt/local/bin/mysql_config5? I have a lib I'm porting "libzdb" that uses "mysql_config --libs $LDFLAGS". I'm trying to find a way to make this build without patching. Thanks, Brad From jeremy at lavergne.gotdns.org Mon Feb 9 12:24:48 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 9 Feb 2009 15:24:48 -0500 Subject: tcl or portfile keyword for alias In-Reply-To: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> Message-ID: Can you use reinplace for this? reinplace s|FIND|REPLACE|[g] it's driven by sed... On Feb 9, 2009, at 3:21 PM, Bradley Giesbrecht wrote: Does anyone know a simple way to env alias a command like mysql_config=/opt/local/bin/mysql_config5? I have a lib I'm porting "libzdb" that uses "mysql_config --libs $LDFLAGS". I'm trying to find a way to make this build without patching. Thanks, Brad -------------- 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 Mon Feb 9 13:05:25 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Feb 2009 15:05:25 -0600 Subject: Ports recommending other ports In-Reply-To: <49901D1E.5030005@macports.org> References: <49901D1E.5030005@macports.org> Message-ID: On Feb 9, 2009, at 06:10, Rainer M?ller wrote: > Ryan Schmidt wrote: >> It might be nice if a port could recommend the user install another >> port in addition, via some new keyword. For example, graphviz could >> recommend the user install graphviz-gui as well. postgresql83 could >> recommend the user install postgresql83-server. port could output >> these recommendations at the end of the installation. ("You may wish >> to install graphviz-gui as well.") The advantage over just printing a >> message at post-install time would be that port or a MacPorts GUI >> could offer the user the choice to install those recommended ports >> too ("Would you like to install graphviz-gui now?") and could know to >> omit the suggestion if the suggested port is already installed. > > This could become a useful future addition, as currently all port > commands are non-interactive. > >> There could be another new keyword for recommended alternatives to a >> given port. For example, on Leopard and later, graphviz-gui is a >> better choice than graphviz-oldgui (which is required on Tiger and >> earlier). ("You may wish to install graphviz-gui instead of graphviz- >> oldgui.") > > While I like the recommends feature, I don't think alternatives are > that > good proposed. If they recommend alternatives for the current port one > should see them before installing this port at all. For example at the > 'port info' output and then we can simply write such a sentence > into the > long_description. After installing a port it is too late to inform > about > alternatives. Oh yes, I would want it shown in "port info" too. I'm just thinking a user may decide they need a port and they'll install it without ever consulting "port info", so if that's the only place the alternatives are shown then they'd never know. If we show it during installation, they still have a chance to ^C the installation and pick the other port. The way I envision a MacPorts GUI, it would have a queue of tasks to be done, so while port is busy installing one port, it can display a message to the user asking if they would like to queue the installation of some additional recommended port. The user can then think about that question while the computer is busy with the first installation. >> Hypothetical addition to port graphviz: >> >> if {${os.platform} == "darwin"} { >> if {${os.major} >= 9} { >> suggest_supplements-append port:graphviz-gui >> } else { >> suggest_supplements-append port:graphviz-oldgui >> } >> } >> >> Hypothetical additions to port graphviz-oldgui: >> >> if {${os.major} >= 9} { >> suggest_alternatives-append port:graphviz-gui >> } >> >> (I used "suggest" instead of "recommend" in the keyword names because >> people have more trouble spelling "recommend".) > > If people have problems spelling "recommend", they will probably also > have problems with "supplements"? No kidding. Got any better ideas? From jeremy at lavergne.gotdns.org Mon Feb 9 13:09:17 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 9 Feb 2009 16:09:17 -0500 Subject: Ports recommending other ports In-Reply-To: References: <49901D1E.5030005@macports.org> Message-ID: <9916FE90-0FEB-459A-B59B-6B9393210D47@lavergne.gotdns.org> >>> Hypothetical addition to port graphviz: >>> >>> if {${os.platform} == "darwin"} { >>> if {${os.major} >= 9} { >>> suggest_supplements-append port:graphviz-gui >>> } else { >>> suggest_supplements-append port:graphviz-oldgui >>> } >>> } >>> >>> Hypothetical additions to port graphviz-oldgui: >>> >>> if {${os.major} >= 9} { >>> suggest_alternatives-append port:graphviz-gui >>> } >>> >>> (I used "suggest" instead of "recommend" in the keyword names >>> because >>> people have more trouble spelling "recommend".) >> >> If people have problems spelling "recommend", they will probably also >> have problems with "supplements"? > > No kidding. Got any better ideas? Seeing as people have to read the site on how to create portfiles anyways, why not create easily-typed abbreviations? suggest_alternatives -> alts, suggest_supplements -> sups -------------- 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 Mon Feb 9 13:11:20 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 9 Feb 2009 16:11:20 -0500 Subject: Ports recommending other ports In-Reply-To: References: <49901D1E.5030005@macports.org> Message-ID: <912DA94F-21D5-4668-8E1E-336C9A374397@lavergne.gotdns.org> >>> Hypothetical addition to port graphviz: >>> >>> if {${os.platform} == "darwin"} { >>> if {${os.major} >= 9} { >>> suggest_supplements-append port:graphviz-gui >>> } else { >>> suggest_supplements-append port:graphviz-oldgui >>> } >>> } >>> >>> Hypothetical additions to port graphviz-oldgui: >>> >>> if {${os.major} >= 9} { >>> suggest_alternatives-append port:graphviz-gui >>> } >>> >>> (I used "suggest" instead of "recommend" in the keyword names >>> because >>> people have more trouble spelling "recommend".) >> >> If people have problems spelling "recommend", they will probably also >> have problems with "supplements"? > > No kidding. Got any better ideas? Or --- even more scarily --- produce an IDE for creating portfiles. I'm sure someone could create an emacs or vi file for this pretty quickly: Keywords can be autocompleted, and those that are misspelled will not be syntax highlighted so they should stand out. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From apple at frinabulax.org Mon Feb 9 13:16:47 2009 From: apple at frinabulax.org (robert delius royar) Date: Mon, 9 Feb 2009 16:16:47 -0500 Subject: [MacPorts] #18408: Cannot upgrade mercurial (macports wants to reinstall latest dependencies) In-Reply-To: <9DE14AAF-93BC-41FF-8A56-529B405B20EA@geeklair.net> References: <056.f0f7c014bc687e6f5cb8d4fab8b9a7b5@macports.org> <065.48278d077476f5b62311283683e58920@macports.org> <2411664D-08E1-4A84-88DF-8D2C99627C1F@macports.org> <0F69B553-9286-4F53-9B15-2E8D5A1C7F63@macports.org> <9DE14AAF-93BC-41FF-8A56-529B405B20EA@geeklair.net> Message-ID: Mon, 9 Feb 2009 (13:31 -0500 UTC) Daniel J. Luke wrote: > On Feb 7, 2009, at 2:40 PM, Ryan Schmidt wrote: >> I don't really understand the symptoms you are reporting. > > Robert said before that he was using 'direct' mode (+ archivemode), and this > looks a lot like the current problems with it. That is correct, except I have -archivemode (not using archivemode). BTW, I finally uninstalled gettext, libiconv, python25, and mercurial then reinstalled pyhton25 (which led to gettext and libiconv reinstalling). Then mercurial installed OK. It wanted to clean gettext and libiconv again at the outset, however, which seemed odd. One thing that I do not like about the current python25 is that it no longer works with readline (eventhough I have readline installed via Macports). The version 3 patches earlier did support readline which meant I could edit interactive commands. I do not use python interactively very often, so it is no big issue. The rationale for not supporting readline in the Python docs says it is because of problems with Apple's 10.4. And the Port file adds --without-readline. But even removing that from the Port file configuration does not get readline back. I guess that is an upstream issue. > > -- > 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. | > +========================================================+ > > > > -- Dr. Robert Delius Royar Associate Professor of English Morehead State University Morehead, Kentucky Making meaning one message at a time. Computers are potentially the most addictive drug yet devised. -R. U. Sirius 16:08 up 13 days, 5:31, 1 user, load averages: 0.12 0.27 0.29 From brad at pixilla.com Mon Feb 9 13:37:42 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Feb 2009 13:37:42 -0800 Subject: libzdb help! In-Reply-To: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> Message-ID: I'm really confused. I went ahead and patched this file. If I do: # port clean --all # port patch # port configure configure fails but # port clean --all # port patch # cd work/libzdb/ # ./configure configure succeeds. I dumbed this port file down and I just don't get why it's failing. -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 1476 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-configure Type: application/octet-stream Size: 420 bytes Desc: not available URL: -------------- next part -------------- //brad On Feb 9, 2009, at 12:21 PM, Bradley Giesbrecht wrote: > Does anyone know a simple way to env alias a command like > mysql_config=/opt/local/bin/mysql_config5? > > I have a lib I'm porting "libzdb" that uses "mysql_config --libs > $LDFLAGS". > > I'm trying to find a way to make this build without patching. > > Thanks, > > Brad > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From illogical1 at gmail.com Mon Feb 9 13:42:01 2009 From: illogical1 at gmail.com (O) Date: Mon, 9 Feb 2009 16:42:01 -0500 Subject: libzdb help! In-Reply-To: References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> Message-ID: <797cc39c0902091342h3a1737c7h8dcf8df61360d45d@mail.gmail.com> Macports' default configure line passes options along too so just doing './configure' wouldn't replicate that. do 'port -d configure' to view the debug output and get an idea of what's going on you can add the -d option at anytime to get a more complete view of what's going on. On Mon, Feb 9, 2009 at 4:37 PM, Bradley Giesbrecht wrote: > I'm really confused. > > I went ahead and patched this file. > > If I do: > # port clean --all > # port patch > # port configure > > configure fails > > but > # port clean --all > # port patch > # cd work/libzdb/ > # ./configure > > configure succeeds. > > I dumbed this port file down and I just don't get why it's failing. > > > > > > > > > //brad > > On Feb 9, 2009, at 12:21 PM, Bradley Giesbrecht wrote: > >> Does anyone know a simple way to env alias a command like >> mysql_config=/opt/local/bin/mysql_config5? >> >> I have a lib I'm porting "libzdb" that uses "mysql_config --libs >> $LDFLAGS". >> >> I'm trying to find a way to make this build without patching. >> >> Thanks, >> >> Brad >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > From brad at pixilla.com Mon Feb 9 14:01:51 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Feb 2009 14:01:51 -0800 Subject: libzdb help! In-Reply-To: <797cc39c0902091342h3a1737c7h8dcf8df61360d45d@mail.gmail.com> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <797cc39c0902091342h3a1737c7h8dcf8df61360d45d@mail.gmail.com> Message-ID: <21123584-42E7-42B3-B8B8-2CF2C2680F87@pixilla.com> Been doing that. I can find nothing interesting with -d. //Brad On Feb 9, 2009, at 1:42 PM, O wrote: > Macports' default configure line passes options along too so just > doing './configure' wouldn't replicate that. > > do 'port -d configure' to view the debug output and get an idea of > what's going on > you can add the -d option at anytime to get a more complete view of > what's going on. > > On Mon, Feb 9, 2009 at 4:37 PM, Bradley Giesbrecht > wrote: >> I'm really confused. >> >> I went ahead and patched this file. >> >> If I do: >> # port clean --all >> # port patch >> # port configure >> >> configure fails >> >> but >> # port clean --all >> # port patch >> # cd work/libzdb/ >> # ./configure >> >> configure succeeds. >> >> I dumbed this port file down and I just don't get why it's failing. >> >> >> >> >> >> >> >> >> //brad >> >> On Feb 9, 2009, at 12:21 PM, Bradley Giesbrecht wrote: >> >>> Does anyone know a simple way to env alias a command like >>> mysql_config=/opt/local/bin/mysql_config5? >>> >>> I have a lib I'm porting "libzdb" that uses "mysql_config --libs >>> $LDFLAGS". >>> >>> I'm trying to find a way to make this build without patching. >>> >>> Thanks, >>> >>> Brad >>> _______________________________________________ >>> 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 brad at pixilla.com Mon Feb 9 14:02:18 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Feb 2009 14:02:18 -0800 Subject: libzdb help! In-Reply-To: References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> Message-ID: <385BE47B-B69A-4974-B66A-5CA14FA022F6@pixilla.com> The file I'm patching is named "configure" hence patch-configure. My patches are in ./files. The patch is being applied, and after I let macports apply the patch if I cd into the worksrcdir and do ./configure it works. But not with macports. //Brad On Feb 9, 2009, at 1:41 PM, Jeremy Lavergne wrote: > Probably unrelated, it's a good idea to have your patch files (which > are suppose to be in ./files) match this naming scheme: > patch-FILENAME.diff > > On Feb 9, 2009, at 4:37 PM, Bradley Giesbrecht wrote: > > > From toby at macports.org Mon Feb 9 14:18:52 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 9 Feb 2009 14:18:52 -0800 Subject: libzdb help! In-Reply-To: <385BE47B-B69A-4974-B66A-5CA14FA022F6@pixilla.com> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <385BE47B-B69A-4974-B66A-5CA14FA022F6@pixilla.com> Message-ID: <74c219d30902091418g7934987fv40f2ba2021f5fc6a@mail.gmail.com> On Mon, Feb 9, 2009 at 2:02 PM, Bradley Giesbrecht wrote: > The file I'm patching is named "configure" hence patch-configure. > > My patches are in ./files. > > The patch is being applied, and after I let macports apply the patch if I cd > into the worksrcdir and do ./configure it works. > > But not with macports. "port configure" does not simply run ./configure... it sets some environment variables, and uses --prefix (possibly other args too). port -d configure should show you what it's doing. - Toby From jmr at macports.org Mon Feb 9 14:24:53 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 10 Feb 2009 09:24:53 +1100 Subject: libzdb help! In-Reply-To: <385BE47B-B69A-4974-B66A-5CA14FA022F6@pixilla.com> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <385BE47B-B69A-4974-B66A-5CA14FA022F6@pixilla.com> Message-ID: <4990AD35.9030201@macports.org> Bradley Giesbrecht wrote: > The patch is being applied, and after I let macports apply the patch if > I cd into the worksrcdir and do ./configure it works. > > But not with macports. As was previously pointed out, `./configure` is NOT the command that MP runs. At the very least it will be something like `./configure --prefix=/opt/local`, and a lot of environment variables will most likely be different too, like PATH, CC, CFLAGS, etc. - Josh From jmr at macports.org Mon Feb 9 14:25:46 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 10 Feb 2009 09:25:46 +1100 Subject: [MacPorts] #18408: Cannot upgrade mercurial (macports wants to reinstall latest dependencies) In-Reply-To: References: <056.f0f7c014bc687e6f5cb8d4fab8b9a7b5@macports.org> <065.48278d077476f5b62311283683e58920@macports.org> <2411664D-08E1-4A84-88DF-8D2C99627C1F@macports.org> <0F69B553-9286-4F53-9B15-2E8D5A1C7F63@macports.org> <9DE14AAF-93BC-41FF-8A56-529B405B20EA@geeklair.net> Message-ID: <4990AD6A.6000809@macports.org> robert delius royar wrote: > One thing that I do not like about the current python25 is that it no > longer works with readline (eventhough I have readline installed via > Macports). The version 3 patches earlier did support readline which > meant I could edit interactive commands. I do not use python > interactively very often, so it is no big issue. The rationale for not > supporting readline in the Python docs says it is because of problems > with Apple's 10.4. And the Port file adds --without-readline. But even > removing that from the Port file configuration does not get readline > back. I guess that is an upstream issue. Are you sure you don't just need to install py25-readline? - Josh From raimue at macports.org Mon Feb 9 14:34:01 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 09 Feb 2009 23:34:01 +0100 Subject: Ports recommending other ports In-Reply-To: References: <49901D1E.5030005@macports.org> Message-ID: <4990AF59.30205@macports.org> Ryan Schmidt wrote: >>> (I used "suggest" instead of "recommend" in the keyword names because >>> people have more trouble spelling "recommend".) >> If people have problems spelling "recommend", they will probably also >> have problems with "supplements"? > > No kidding. Got any better ideas? I don't know if people have problems spelling "recommends", but in general I am for easy terms. And I can't think of anything more easy to remember than "recommends" or "recommendations" as it is exactly what it is supposed to to. Rainer From ryandesign at macports.org Mon Feb 9 15:53:46 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Feb 2009 17:53:46 -0600 Subject: tcl or portfile keyword for alias In-Reply-To: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> Message-ID: On Feb 9, 2009, at 14:21, Bradley Giesbrecht wrote: > Does anyone know a simple way to env alias a command like > mysql_config=/opt/local/bin/mysql_config5? > > I have a lib I'm porting "libzdb" that uses "mysql_config --libs > $LDFLAGS". > > I'm trying to find a way to make this build without patching. You could prepend ${prefix}/lib/mysql5/bin to the PATH. That's where the program "mysql_config" lives. configure.env-append PATH=${prefix}/lib/mysql5/bin:$env(PATH) From ryandesign at macports.org Mon Feb 9 16:18:07 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Feb 2009 18:18:07 -0600 Subject: tcl or portfile keyword for alias In-Reply-To: References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> Message-ID: <9375E787-2352-423A-8333-95F90AA2C1E3@macports.org> On Feb 9, 2009, at 17:53, Ryan Schmidt wrote: > On Feb 9, 2009, at 14:21, Bradley Giesbrecht wrote: > >> Does anyone know a simple way to env alias a command like >> mysql_config=/opt/local/bin/mysql_config5? >> >> I have a lib I'm porting "libzdb" that uses "mysql_config --libs >> $LDFLAGS". >> >> I'm trying to find a way to make this build without patching. > > You could prepend ${prefix}/lib/mysql5/bin to the PATH. That's > where the program "mysql_config" lives. > > > configure.env-append PATH=${prefix}/lib/mysql5/bin:$env(PATH) The reason it then still doesn't work is because libzdb is calling mysql_config incorrectly. As you note, it uses "mysql_config --libs $LDFLAGS". It is not correct to put "$LDFLAGS" at the end of that command invocation. The correct way to call it is just "mysql_config --libs". It works for you on the command line because LDFLAGS is empty by default, but MacPorts fills it with a value, so when run within MacPorts, it fails. If you look in the config.log, you see that mysql_config is printing its usage message, showing that the way it is being used is not correct. Attached is a Portfile and patch that work for me. You should send the patchfile to the author of libzdb. In the Portfile, I also added a dependency on mysql5, and added configure arguments to disable postgresql and sqlite. If you want to enable postgresql or sqlite, remove the corresponding configure argument and add the required dependency. -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 1655 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-configure Type: application/octet-stream Size: 392 bytes Desc: not available URL: From ryandesign at macports.org Mon Feb 9 16:32:30 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Feb 2009 18:32:30 -0600 Subject: [46548] trunk/dports/databases/mysql5-devel/Portfile In-Reply-To: <797cc39c0902070647p74429524nc23582eb01e500b4@mail.gmail.com> References: <20090206194202.E7E97E9AE23@beta.macosforge.org> <797cc39c0902070647p74429524nc23582eb01e500b4@mail.gmail.com> Message-ID: <8F4C0CFF-BF73-4FB1-A229-E90485C16D03@macports.org> On Feb 7, 2009, at 08:47, O wrote: > On Fri, Feb 6, 2009 at 2:42 PM, wrote: >> Revision 46548 Author jwa at macports.org Date 2009-02-06 11:41:58 >> -0800 (Fri, >> 06 Feb 2009) >> >> Log Message >> >> version bump to 5.1.31 > Hey, I'd like to add libmysqld.a to the default installation of > mysql5-devel. I've been using the library for a while now in amarok > and it's fine and doesn't interfere with anything else. Is this OK? I filed a ticket for this request: http://trac.macports.org/ticket/18434 From ryandesign at macports.org Mon Feb 9 16:39:10 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Feb 2009 18:39:10 -0600 Subject: [46647] trunk/dports/games In-Reply-To: <20090209155820.BD7D8EDEA5C@beta.macosforge.org> References: <20090209155820.BD7D8EDEA5C@beta.macosforge.org> Message-ID: On Feb 9, 2009, at 09:58, snc at macports.org wrote: > Revision: 46647 > http://trac.macports.org/changeset/46647 > Author: snc at macports.org > Date: 2009-02-09 07:58:20 -0800 (Mon, 09 Feb 2009) > Log Message: > ----------- > created gtkevemon, ticket #18020 > > Added Paths: > ----------- > trunk/dports/games/gtkevemon/ > trunk/dports/games/gtkevemon/Portfile > > Added: trunk/dports/games/gtkevemon/Portfile > =================================================================== > --- trunk/dports/games/gtkevemon/Portfile > (rev 0) > +++ trunk/dports/games/gtkevemon/Portfile 2009-02-09 15:58:20 UTC > (rev 46647) > @@ -0,0 +1,48 @@ > +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: > nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 > +# $Id$ > + > +PortSystem 1.0 > + > +name gtkevemon > +version 82 > +categories games > +maintainers mellon85 at gmail.com > +description GTK Eve-Online monitor > +long_description GtkEveMon is a skill monitoring standalone > application \ > + for GNU/Linux systems. With GtkEveMon you can > monitor \ > + your current skills and your skill training > process \ > + without starting EVE-Online. \ > + > +homepage http://gtkevemon.battleclinic.com/ > +use_parallel_build yes > +worksrcdir gtkevemon > +master_sites > +distfiles > + > +depends_build bin:svn:subversion > + > +depends_lib port:gtkmm port:libxml2 > + > +pre-fetch { > + if {[file isdirectory ${workpath}/gtkevemon]} { > + if {![file isdirectory ${workpath}/gtkevemon/.svn]} { > + file delete -force ${workpath}/gtkevemon > + } > + } > +} > + > +fetch { > + system "cd ${workpath} && svn co -r${version} svn:// > gtkevemon.battleclinic.com/GTKEVEMon/trunk/gtkevemon" > +} Why is this portfile not using the svn fetchtype? From ryandesign at macports.org Mon Feb 9 17:03:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Feb 2009 19:03:28 -0600 Subject: [46644] trunk/dports/security In-Reply-To: <20090209153026.E70DDEDE7D1@beta.macosforge.org> References: <20090209153026.E70DDEDE7D1@beta.macosforge.org> Message-ID: On Feb 9, 2009, at 09:30, snc at macports.org wrote: > Revision: 46644 > http://trac.macports.org/changeset/46644 > Author: snc at macports.org > Date: 2009-02-09 07:30:24 -0800 (Mon, 09 Feb 2009) > Log Message: > ----------- > create logwatch, ticket #18021 > > Added Paths: > ----------- > trunk/dports/security/logwatch/ > trunk/dports/security/logwatch/Portfile > trunk/dports/security/logwatch/files/ > trunk/dports/security/logwatch/files/org.macports.logwatch.plist > > Added: trunk/dports/security/logwatch/Portfile > =================================================================== > --- trunk/dports/security/logwatch/Portfile > (rev 0) > +++ trunk/dports/security/logwatch/Portfile 2009-02-09 15:30:24 UTC > (rev 46644) > @@ -0,0 +1,64 @@ > +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: > nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 > +# $Id$ > + > +PortSystem 1.0 > + > +name logwatch > +version 7.3.6 > +distname logwatch-${version} The distname line can be removed because that is already the default. > +categories security > +maintainers lassi.tuura at cern.ch > +description system log analyzer and reporter > +long_description \ > + Logwatch is a customizable log analysis > system. Logwatch \ > + parses through your system's logs for a given > period of \ > + time and creates a report analyzing areas that > you \ > + specify, in as much detail as you require. > Logwatch is \ > + easy to use and will work right out of the > package on most \ > + systems. > + > +homepage http://www.logwatch.org > +master_sites ftp://ftp.kaybee.org/pub/linux Is there an http master site that could be added? Some users, including our own distfiles mirror, cannot fetch from ftp sites. > +platforms darwin > +checksums md5 937d982006b2a76a83edfcfd2e5a9d7d > + > +use_configure no > +build { } > +destroot { > + > + reinplace s|/usr/share/${name}|${prefix}/share/${name}|g $ > {worksrcpath}/scripts/logwatch.pl > + reinplace s|/var/cache/${name}|${prefix}/var/cache/${name}|g $ > {worksrcpath}/scripts/logwatch.pl > + reinplace s|/var/cache/${name}|${prefix}/var/cache/${name}|g $ > {worksrcpath}/conf/logwatch.conf > + reinplace s|messages|system|g ${worksrcpath}/conf/logfiles/ > messages.conf I suppose technically this reinplace business might be more appropriate in the otherwise-empty build phase. > + file mkdir ${destroot}${prefix}/etc/${name}/scripts > + file mkdir ${destroot}${prefix}/etc/${name}/conf/logfiles > + file mkdir ${destroot}${prefix}/etc/${name}/conf/services > + file mkdir ${destroot}${prefix}/share/${name}/dist.conf/logfiles > + file mkdir ${destroot}${prefix}/var/cache/${name} > + touch ${destroot}${prefix}/var/cache/.turd destroot.keepdirs should be used for this instead of calling touch. > + file copy ${worksrcpath}/conf ${destroot}${prefix}/share/$ > {name}/default.conf > + file copy ${worksrcpath}/scripts ${destroot}${prefix}/share/$ > {name}/scripts > + file copy ${worksrcpath}/lib ${destroot}${prefix}/share/$ > {name}/lib > + > + ln -s ../share/${name}/scripts/logwatch.pl ${destroot}$ > {prefix}/bin/logwatch > + > + # startup item > + file delete /Library/LaunchDaemons/org.macports.${name}.plist Why is the port removing a file that's outside of the destroot? > + file mkdir ${destroot}${prefix}/etc/LaunchDaemons/${name} > + file copy files/org.macports.${name}.plist ${destroot}$ > {prefix}/etc/LaunchDaemons/${name}/org.macports.${name}.plist > + reinplace s|@PREFIX@|${prefix}|g ${destroot}${prefix}/etc/ > LaunchDaemons/${name}/org.macports.${name}.plist > +} > + > +post-destroot { > + ln -s ${prefix}/etc/LaunchDaemons/${name}/org.macports.$ > {name}.plist /Library/LaunchDaemons More importantly, why is the port creating a file that's outside of the destroot? > + ui_msg > "###########################################################" > + ui_msg "# A startup item has been generated that will aid in" > + ui_msg "# starting dnsmasq with launcd. It is disabled" > + ui_msg "# by default. Execute the following command to start it," > + ui_msg "# and to cause it to launch at startup:" > + ui_msg "#" > + ui_msg "# sudo launchctl load -w /Library/LaunchDaemons/ > org.macports.dnsmasq.plist" > + ui_msg > "###########################################################" > +} From illogical1 at gmail.com Mon Feb 9 17:24:53 2009 From: illogical1 at gmail.com (Orville Bennett) Date: Mon, 9 Feb 2009 20:24:53 -0500 Subject: Ports recommending other ports In-Reply-To: <4990AF59.30205@macports.org> References: <49901D1E.5030005@macports.org> <4990AF59.30205@macports.org> Message-ID: On Feb 9, 2009, at 5:34 PM, Rainer M?ller wrote: > Ryan Schmidt wrote: >>>> (I used "suggest" instead of "recommend" in the keyword names >>>> because >>>> people have more trouble spelling "recommend".) >>> If people have problems spelling "recommend", they will probably >>> also >>> have problems with "supplements"? >> >> No kidding. Got any better ideas? > > I don't know if people have problems spelling "recommends", but in > general I am for easy terms. And I can't think of anything more easy > to > remember than "recommends" or "recommendations" as it is exactly > what it > is supposed to to. ++ Just because people will have problem speeling isn't a good reason to not use a word. We can all learn. Or use lint :-) > > > Rainer > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From brad at pixilla.com Mon Feb 9 18:51:28 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Feb 2009 18:51:28 -0800 Subject: tcl or portfile keyword for alias In-Reply-To: References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> Message-ID: <866F64EF-E60D-4DE3-8493-157CADB61D4C@pixilla.com> On Feb 9, 2009, at 3:53 PM, Ryan Schmidt wrote: > > On Feb 9, 2009, at 14:21, Bradley Giesbrecht wrote: > >> Does anyone know a simple way to env alias a command like >> mysql_config=/opt/local/bin/mysql_config5? >> >> I have a lib I'm porting "libzdb" that uses "mysql_config --libs >> $LDFLAGS". >> >> I'm trying to find a way to make this build without patching. > > You could prepend ${prefix}/lib/mysql5/bin to the PATH. That's where > the program "mysql_config" lives. > > > configure.env-append PATH=${prefix}/lib/mysql5/bin:$env(PATH) Well, I'll be. I have never bothered to check if mysql_config5 was a symlink. Nice to know. Some scripts accept paths to mysql_config dir. I should have checked that out. From brad at pixilla.com Mon Feb 9 19:12:30 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Feb 2009 19:12:30 -0800 Subject: libzdb help! In-Reply-To: <74c219d30902091418g7934987fv40f2ba2021f5fc6a@mail.gmail.com> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <385BE47B-B69A-4974-B66A-5CA14FA022F6@pixilla.com> <74c219d30902091418g7934987fv40f2ba2021f5fc6a@mail.gmail.com> Message-ID: I am familiar with -d. Been running it all day. I have tried to find a way to influance the configure script without patching but I gave up and patched it. # port configure // fails # cd work/libzdb-2.3/ && ./configure --prefix=/opt/local // works As far as I know --prefix typically influences the install dir and not the finding of libs or includes. But I'm not a strong unix admin. Just try the scripts I attached. Takes about a minute or two to add them to a local repo. I have the scripts dumbed down on purpose. Running ./configure with no args (or with prefix=/opt/local if you prefer) from ${worksrcdir} or what ever that var is named works. Running "port configure" does not work. //brad On Feb 9, 2009, at 2:18 PM, Toby Peterson wrote: > On Mon, Feb 9, 2009 at 2:02 PM, Bradley Giesbrecht > wrote: >> The file I'm patching is named "configure" hence patch-configure. >> >> My patches are in ./files. >> >> The patch is being applied, and after I let macports apply the >> patch if I cd >> into the worksrcdir and do ./configure it works. >> >> But not with macports. > > "port configure" does not simply run ./configure... it sets some > environment variables, and uses --prefix (possibly other args too). > > port -d configure should show you what it's doing. > > - Toby From brad at pixilla.com Mon Feb 9 20:04:48 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Feb 2009 20:04:48 -0800 Subject: Ports recommending other ports In-Reply-To: References: <49901D1E.5030005@macports.org> <4990AF59.30205@macports.org> Message-ID: <58F1BF97-1890-42B9-AC64-23BABB5C99CB@pixilla.com> On Feb 9, 2009, at 5:24 PM, Orville Bennett wrote: > > On Feb 9, 2009, at 5:34 PM, Rainer M?ller wrote: > >> Ryan Schmidt wrote: >>>>> (I used "suggest" instead of "recommend" in the keyword names >>>>> because >>>>> people have more trouble spelling "recommend".) >>>> If people have problems spelling "recommend", they will probably >>>> also >>>> have problems with "supplements"? >>> >>> No kidding. Got any better ideas? >> >> I don't know if people have problems spelling "recommends", but in >> general I am for easy terms. And I can't think of anything more >> easy to >> remember than "recommends" or "recommendations" as it is exactly >> what it >> is supposed to to. > ++ > Just because people will have problem speeling isn't a good reason > to not use a word. > We can all learn. Or use lint :- I like lint and I like var names that mean something to humans unless humans don't need to use them. I also am not a fan of the plural form. In my applications I would probably use "recommendation" Let the app add the "s". foreach (something as thing) add recommendation[thing]. user table vs users table. What variant or you talking about vs what variants are you talking about. It's a variant not a variants. It's a recommendation not a recommendations. usersnames groupsnames And I will be so totally happy with any var that works so I'll shut up now. And I have had some wine;) //brad From brad at pixilla.com Mon Feb 9 20:07:11 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Feb 2009 20:07:11 -0800 Subject: tcl or portfile keyword for alias In-Reply-To: References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> Message-ID: <9A2EBD71-9715-4C22-978F-998FE1DE43B2@pixilla.com> Yes, I could use reinplace. But unless I don't know how reinplace might effect other process I dont think reinplace would do anything my patch is not doing. reinplace s|something_not_in_my_patch|with_something_else|g //brad On Feb 9, 2009, at 12:24 PM, Jeremy Lavergne wrote: > Can you use reinplace for this? > > reinplace s|FIND|REPLACE|[g] > it's driven by sed... > > On Feb 9, 2009, at 3:21 PM, Bradley Giesbrecht wrote: > > Does anyone know a simple way to env alias a command like > mysql_config=/opt/local/bin/mysql_config5? > > I have a lib I'm porting "libzdb" that uses "mysql_config --libs > $LDFLAGS". > > I'm trying to find a way to make this build without patching. > > Thanks, > > Brad > From ryandesign at macports.org Mon Feb 9 20:15:27 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Feb 2009 22:15:27 -0600 Subject: tcl or portfile keyword for alias In-Reply-To: <9A2EBD71-9715-4C22-978F-998FE1DE43B2@pixilla.com> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <9A2EBD71-9715-4C22-978F-998FE1DE43B2@pixilla.com> Message-ID: <81148C63-FFE1-44E6-A8F4-5247D8B5A70D@macports.org> Did you get my earlier message with the solution to your problem? http://lists.macosforge.org/pipermail/macports-dev/2009-February/ 007324.html On Feb 9, 2009, at 22:07, Bradley Giesbrecht wrote: > Yes, I could use reinplace. > > But unless I don't know how reinplace might effect other process I > dont think reinplace would do anything my patch is not doing. > > reinplace s|something_not_in_my_patch|with_something_else|g > > //brad > > On Feb 9, 2009, at 12:24 PM, Jeremy Lavergne wrote: > >> Can you use reinplace for this? >> >> reinplace s|FIND|REPLACE|[g] >> it's driven by sed... >> >> On Feb 9, 2009, at 3:21 PM, Bradley Giesbrecht wrote: >> >> Does anyone know a simple way to env alias a command like >> mysql_config=/opt/local/bin/mysql_config5? >> >> I have a lib I'm porting "libzdb" that uses "mysql_config --libs >> $LDFLAGS". >> >> I'm trying to find a way to make this build without patching. From ryandesign at macports.org Mon Feb 9 20:18:50 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Feb 2009 22:18:50 -0600 Subject: Ports recommending other ports In-Reply-To: <58F1BF97-1890-42B9-AC64-23BABB5C99CB@pixilla.com> References: <49901D1E.5030005@macports.org> <4990AF59.30205@macports.org> <58F1BF97-1890-42B9-AC64-23BABB5C99CB@pixilla.com> Message-ID: <16E1F850-D12A-4CDC-8362-D8AF6D41E472@macports.org> On Feb 9, 2009, at 22:04, Bradley Giesbrecht wrote: > I like lint and I like var names that mean something to humans > unless humans don't need to use them. > > I also am not a fan of the plural form. > > In my applications I would probably use "recommendation" > > Let the app add the "s". > > foreach (something as thing) add recommendation[thing]. > > user table vs users table. > > What variant or you talking about vs what variants are you talking > about. > > It's a variant not a variants. > > It's a recommendation not a recommendations. > > usersnames > groupsnames I was going for consistency with the existing variable names we have in portfiles: categories platforms master_sites checksums patchfiles configure.args depends_lib These are already plural, and in each case, each one can have multiple values. A port can be in multiple categories, work on multiple platforms, be downloaded from multiple master_sites, etc., just as a port could offer multiple recommendations for supplemental ports, and conceivably also for alternative ports. From brad at pixilla.com Mon Feb 9 20:34:35 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Feb 2009 20:34:35 -0800 Subject: tcl or portfile keyword for alias In-Reply-To: <9375E787-2352-423A-8333-95F90AA2C1E3@macports.org> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <9375E787-2352-423A-8333-95F90AA2C1E3@macports.org> Message-ID: <6ADE31F5-29EB-4A55-96FB-D94B0FFFA00E@pixilla.com> On Feb 9, 2009, at 4:18 PM, Ryan Schmidt wrote: > > On Feb 9, 2009, at 17:53, Ryan Schmidt wrote: > >> On Feb 9, 2009, at 14:21, Bradley Giesbrecht wrote: >> >>> Does anyone know a simple way to env alias a command like >>> mysql_config=/opt/local/bin/mysql_config5? >>> >>> I have a lib I'm porting "libzdb" that uses "mysql_config --libs >>> $LDFLAGS". >>> >>> I'm trying to find a way to make this build without patching. >> >> You could prepend ${prefix}/lib/mysql5/bin to the PATH. That's >> where the program "mysql_config" lives. >> >> >> configure.env-append PATH=${prefix}/lib/mysql5/bin:$env(PATH) > > The reason it then still doesn't work is because libzdb is calling > mysql_config incorrectly. As you note, it uses "mysql_config --libs > $LDFLAGS". It is not correct to put "$LDFLAGS" at the end of that > command invocation. The correct way to call it is just "mysql_config > --libs". It works for you on the command line because LDFLAGS is > empty by default, but MacPorts fills it with a value, so when run > within MacPorts, it fails. If you look in the config.log, you see > that mysql_config is printing its usage message, showing that the > way it is being used is not correct. Attached is a Portfile and > patch that work for me. You should send the patchfile to the author > of libzdb. > > In the Portfile, I also added a dependency on mysql5, and added > configure arguments to disable postgresql and sqlite. If you want to > enable postgresql or sqlite, remove the corresponding configure > argument and add the required dependency. I had a more complex Portfile which I trimmed down before posting to make it simple to try. I guess I'm old school that way. The patch Portfile attached to your email removed the patch file. I like it but it didn't work. If I add the patch and remove the $LDFLAGS in the patch "mysql_config --libs $LDFLAGS" to "mysql_config --libs" it works. Thanks a ton. You are a stud! //Brad From ryandesign at macports.org Mon Feb 9 20:41:07 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Feb 2009 22:41:07 -0600 Subject: tcl or portfile keyword for alias In-Reply-To: <6ADE31F5-29EB-4A55-96FB-D94B0FFFA00E@pixilla.com> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <9375E787-2352-423A-8333-95F90AA2C1E3@macports.org> <6ADE31F5-29EB-4A55-96FB-D94B0FFFA00E@pixilla.com> Message-ID: On Feb 9, 2009, at 22:34, Bradley Giesbrecht wrote: > On Feb 9, 2009, at 4:18 PM, Ryan Schmidt wrote: > >> On Feb 9, 2009, at 17:53, Ryan Schmidt wrote: >> >>> You could prepend ${prefix}/lib/mysql5/bin to the PATH. That's >>> where the program "mysql_config" lives. >>> >>> configure.env-append PATH=${prefix}/lib/mysql5/bin:$env(PATH) >> >> The reason it then still doesn't work is because libzdb is calling >> mysql_config incorrectly. As you note, it uses "mysql_config -- >> libs $LDFLAGS". It is not correct to put "$LDFLAGS" at the end of >> that command invocation. The correct way to call it is just >> "mysql_config --libs". It works for you on the command line >> because LDFLAGS is empty by default, but MacPorts fills it with a >> value, so when run within MacPorts, it fails. If you look in the >> config.log, you see that mysql_config is printing its usage >> message, showing that the way it is being used is not correct. >> Attached is a Portfile and patch that work for me. You should send >> the patchfile to the author of libzdb. >> >> In the Portfile, I also added a dependency on mysql5, and added >> configure arguments to disable postgresql and sqlite. If you want >> to enable postgresql or sqlite, remove the corresponding configure >> argument and add the required dependency. > > I had a more complex Portfile which I trimmed down before posting > to make it simple to try. > > I guess I'm old school that way. > > The patch Portfile attached to your email removed the patch file. I > like it but it didn't work. > If I add the patch and remove the $LDFLAGS in the patch > "mysql_config --libs $LDFLAGS" to "mysql_config --libs" it works. But... the Portfile I attached said patchfiles patch-configure And I attached my revised patch-configure which said - LDFLAGS=`mysql_config --libs $LDFLAGS` - CPPFLAGS=`mysql_config --include $CPPFLAGS` + LDFLAGS="`mysql_config --libs` $LDFLAGS" + CPPFLAGS="`mysql_config --include` $CPPFLAGS" to fix the problem with calling mysql_config. My Portfile also fixed the PATH in the configure phase with configure.env-append PATH=${prefix}/lib/mysql5/bin:$env(PATH) so that mysql_config could be found. I tested this before attaching it to the email and it worked for me as sent. From toby at macports.org Mon Feb 9 21:21:18 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 9 Feb 2009 21:21:18 -0800 Subject: libzdb help! In-Reply-To: References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <385BE47B-B69A-4974-B66A-5CA14FA022F6@pixilla.com> <74c219d30902091418g7934987fv40f2ba2021f5fc6a@mail.gmail.com> Message-ID: <74c219d30902092121rb01874dh760add293e7c8c24@mail.gmail.com> On Mon, Feb 9, 2009 at 7:12 PM, Bradley Giesbrecht wrote: > I am familiar with -d. Been running it all day. > > I have tried to find a way to influance the configure script without > patching but I gave up and patched it. > > # port configure // fails > > # cd work/libzdb-2.3/ && ./configure --prefix=/opt/local // works > > As far as I know --prefix typically influences the install dir and not the > finding of libs or includes. > But I'm not a strong unix admin. > > Just try the scripts I attached. Takes about a minute or two to add them to > a local repo. > > I have the scripts dumbed down on purpose. Running ./configure with no args > (or with prefix=/opt/local if you prefer) from ${worksrcdir} or what ever > that var is named works. > Running "port configure" does not work. Probably environment variables, then. I'll take a look later if I have time. - Toby From ryandesign at macports.org Mon Feb 9 21:57:12 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Feb 2009 23:57:12 -0600 Subject: tcl or portfile keyword for alias In-Reply-To: <4B114D73-20C4-47F1-9B60-C5EA1CCC5E44@pixilla.com> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <9375E787-2352-423A-8333-95F90AA2C1E3@macports.org> <6ADE31F5-29EB-4A55-96FB-D94B0FFFA00E@pixilla.com> <4B114D73-20C4-47F1-9B60-C5EA1CCC5E44@pixilla.com> Message-ID: <55EF773E-46F0-45C5-9A8C-297EEDA4DD6D@macports.org> On Feb 9, 2009, at 22:52, Bradley Giesbrecht wrote: > On Feb 9, 2009, at 8:41 PM, Ryan Schmidt wrote: > >> On Feb 9, 2009, at 22:34, Bradley Giesbrecht wrote: >> >>> On Feb 9, 2009, at 4:18 PM, Ryan Schmidt wrote: >>> >>>> On Feb 9, 2009, at 17:53, Ryan Schmidt wrote: >>>> >>>>> You could prepend ${prefix}/lib/mysql5/bin to the PATH. That's >>>>> where the program "mysql_config" lives. >>>>> >>>>> configure.env-append PATH=${prefix}/lib/mysql5/bin:$env(PATH) >>>> >>>> The reason it then still doesn't work is because libzdb is >>>> calling mysql_config incorrectly. As you note, it uses >>>> "mysql_config --libs $LDFLAGS". It is not correct to put >>>> "$LDFLAGS" at the end of that command invocation. The correct >>>> way to call it is just "mysql_config --libs". It works for you >>>> on the command line because LDFLAGS is empty by default, but >>>> MacPorts fills it with a value, so when run within MacPorts, it >>>> fails. If you look in the config.log, you see that mysql_config >>>> is printing its usage message, showing that the way it is being >>>> used is not correct. Attached is a Portfile and patch that work >>>> for me. You should send the patchfile to the author of libzdb. >>>> >>>> In the Portfile, I also added a dependency on mysql5, and added >>>> configure arguments to disable postgresql and sqlite. If you >>>> want to enable postgresql or sqlite, remove the corresponding >>>> configure argument and add the required dependency. >>> >>> I had a more complex Portfile which I trimmed down before posting >>> to make it simple to try. >>> >>> I guess I'm old school that way. >>> >>> The patch Portfile attached to your email removed the patch file. >>> I like it but it didn't work. >>> If I add the patch and remove the $LDFLAGS in the patch >>> "mysql_config --libs $LDFLAGS" to "mysql_config --libs" it works. >> >> But... the Portfile I attached said >> >> patchfiles patch-configure >> >> And I attached my revised patch-configure which said >> >> - LDFLAGS=`mysql_config --libs $LDFLAGS` >> - CPPFLAGS=`mysql_config --include $CPPFLAGS` >> + LDFLAGS="`mysql_config --libs` $LDFLAGS" >> + CPPFLAGS="`mysql_config --include` $CPPFLAGS" >> >> to fix the problem with calling mysql_config. My Portfile also >> fixed the PATH in the configure phase with >> >> configure.env-append PATH=${prefix}/lib/mysql5/bin:$env(PATH) >> >> so that mysql_config could be found. I tested this before >> attaching it to the email and it worked for me as sent. > > Reading your comment " It is not correct to put "$LDFLAGS" at the > end of that command invocation." and without looking in > "config.log" personally I assumed you meant to remove the > "$LDFLAGS" from "mysql_config --libs $LDFLAGS" in the patch. > > I just copied your revised Portfile and patch-configure file and > ran "port clean --all" and "port configure" and it failed. > > Altering the patch to remove ""$LDFLAGS"" fixed the configure > problems. > > Anyways, without looking at the configure.log I believe you are > right and that is very cool. I will pass your/our patch upstream. LDFLAGS should not be inside the backticks, but should presumably be outside the backticks. The way the developer had it, he was saying "set LDFLAGS to the value of the program invocation `mysql_config -- libs $LDFLAGS`" and that's not a valid invocation of mysql_config if $LDFLAGS is nonempty. I changed it to say "set LDFLAGS to the value of the program invocation `mysql_config --libs` and then a space and then whatever was already in $LDFLAGS" which I think is what the developer was trying to say, but maybe he never tested with LDFLAGS nonempty. I just tried again with the files I sent earlier and it works fine. Make a directory libzdb, put Portfile in it, make a files directory in it, put patch-configure in the files directory, cd to the libzdb directory, and run port -d configure. For me it says: checking for mysql... checking for mysql_init in -lmysqlclient... yes checking mysql version... checking mysql.h usability... yes checking mysql.h presence... yes checking for mysql.h... yes ok And then | SQLite3: DISABLED | | Mysql: ENABLED | | PostgreSQL: DISABLED | I've attached my debug log so you can compare it to yours; maybe that will point out what's different. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: libzdb.txt URL: From toby at macports.org Mon Feb 9 22:28:38 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 9 Feb 2009 22:28:38 -0800 Subject: libzdb help! In-Reply-To: References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <385BE47B-B69A-4974-B66A-5CA14FA022F6@pixilla.com> <74c219d30902091418g7934987fv40f2ba2021f5fc6a@mail.gmail.com> Message-ID: <74c219d30902092228ya3d2547x7f81669c5cb94e21@mail.gmail.com> On Mon, Feb 9, 2009 at 7:12 PM, Bradley Giesbrecht wrote: > I am familiar with -d. Been running it all day. > > I have tried to find a way to influance the configure script without > patching but I gave up and patched it. > > # port configure // fails > > # cd work/libzdb-2.3/ && ./configure --prefix=/opt/local // works > > As far as I know --prefix typically influences the install dir and not the > finding of libs or includes. > But I'm not a strong unix admin. > > Just try the scripts I attached. Takes about a minute or two to add them to > a local repo. > > I have the scripts dumbed down on purpose. Running ./configure with no args > (or with prefix=/opt/local if you prefer) from ${worksrcdir} or what ever > that var is named works. > Running "port configure" does not work. OK, I see why it doesn't work. This was mentioned previously. We set LDFLAGS/CPPFLAGS (and other variables) in the environment, which breaks the following command: mysql_config5 --libs $LDFLAGS Normally LDFLAGS is empty, so it doesn't affect this. Anyway, easy enough fix to patch-configure .... + LDFLAGS=`/opt/local/bin/mysql_config5 --libs $LDFLAGS` + CPPFLAGS=`/opt/local/bin/mysql_config5 --include $CPPFLAGS` should be + LDFLAGS=`/opt/local/bin/mysql_config5 --libs` $LDFLAGS + CPPFLAGS=`/opt/local/bin/mysql_config5 --include` $CPPFLAGS That should get things working, to some extent. I have some other complaints about your Portfile, but let's get this thing compiling first. :) - Toby From jm at poure.com Mon Feb 9 23:41:25 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Tue, 10 Feb 2009 08:41:25 +0100 Subject: [46678] trunk/dports/kde/kdepim4 In-Reply-To: <20090210055102.2E276EEB077@beta.macosforge.org> References: <20090210055102.2E276EEB077@beta.macosforge.org> Message-ID: <1234251685.5845.1.camel@debian> On Mon, 2009-02-09 at 21:51 -0800, illogic-al at macports.org wrote: > I cheated by disabling some kresource named "featureplan". I hate it and it hates me. > Also added necessary link to QtNetwork for kleopatra. At this point all KDE4 portfiles build completely, if xcode's gcc4.2 is present, even if only with some nasty patches some places. > Super, thanks. Under 10.4, /usr/bin/gcc42 is not present. I recompiled recently modified Apple-gcc-42 port file (still not commited to SVN). How do you set apple-gcc-4.2 compiler option in the kde4 group file? Kind regards, Jean-Michel From ryandesign at macports.org Tue Feb 10 01:12:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Feb 2009 03:12:29 -0600 Subject: [46678] trunk/dports/kde/kdepim4 In-Reply-To: <1234251685.5845.1.camel@debian> References: <20090210055102.2E276EEB077@beta.macosforge.org> <1234251685.5845.1.camel@debian> Message-ID: <098D49E5-18D6-4E30-9E61-398764B45E4F@macports.org> On Feb 10, 2009, at 01:41, Jean-Michel Pour? wrote: > On Mon, 2009-02-09 at 21:51 -0800, illogic-al at macports.org wrote: > >> I cheated by disabling some kresource named "featureplan". I hate >> it and it hates me. >> Also added necessary link to QtNetwork for kleopatra. At this >> point all KDE4 portfiles build completely, if xcode's gcc4.2 is >> present, even if only with some nasty patches some places. > > Super, thanks. Under 10.4, /usr/bin/gcc42 is not present. I recompiled > recently modified Apple-gcc-42 port file (still not commited to SVN). It is still not committed because I still have reservations about the method that was used to update it. I will add my comments to ticket #16666 shortly. > How do you set apple-gcc-4.2 compiler option in the kde4 group file? See my existing note in ticket #16666. You would set: configure.cc ${prefix}/wherever/cc/is configure.cxx ${prefix}/wherever/cxx/is configure.cpp ${prefix}/wherever/cpp/is You can use "port contents apple-gcc42" to see the contents of the port after it's installed and figure out where it puts cc, cxx and cpp, and fill those in above. From ryandesign at macports.org Tue Feb 10 01:21:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Feb 2009 03:21:08 -0600 Subject: [46644] trunk/dports/security In-Reply-To: References: <20090209153026.E70DDEDE7D1@beta.macosforge.org> Message-ID: <7F41FC87-39D5-472C-A8DC-328D88CF5F2E@macports.org> On Feb 10, 2009, at 02:45, Lassi A. Tuura wrote: >>> +homepage http://www.logwatch.org >>> +master_sites ftp://ftp.kaybee.org/pub/linux >> >> Is there an http master site that could be added? Some users, >> including our own distfiles mirror, cannot fetch from ftp sites. > > Not that I know of. A web search on the archive name returns 'hey > get files and ads from us' sites; do you trust such secondary file > sources? The only other alternative I can think of is CVS checkout > using "rel7_3_6" tag, which lacks a few files but otherwise seems > like the tar ball (checkout misses "License" and > "logwatch-7.3.6.spec"). Ok, then we'll leave it. I recall now that only Apple's mirror in California has this inability to fetch from ftp. We have two other mirrors now in other countries that can fetch from ftp. And all the mirrors are accessible via http. So that should be sufficient. >>> + # startup item >>> + file delete /Library/LaunchDaemons/org.macports.${name}.plist >> >> Why is the port removing a file that's outside of the destroot? > > The program is expected to be run daily as root. If a launch item > in /Library is not an option, what would be the MacPorts > convention? Linux would use /etc/cron.daily/logwatch. There is no problem with the port installing a file in /Library/ LaunchDaemons; the problem is that it is not doing so as part of the destroot. The port should, in the destroot (or post-destroot) phase, put the file in ${destroot}/Library/LaunchDaemons so that during the install and activate phases MacPorts will automatically put it where it belongs in /Library/LaunchDaemons, just like it puts all the other files in the destroot where they belong under ${prefix}. This also enables MacPorts to uninstall the port's files when you "port uninstall logwatch". This is the purpose of putting files in the destroot. > For other changes: thanks for your comments, I'd be happy to apply > to them, just am not sure which of us is supposed to respond -- > this would be my first contributed port file. I've only submitted > the port to trac (http://trac.macports.org/ticket/18021). As the maintainer of the port, all changes must be run by you first for approval. You're a new maintainer and Jeremy is a new committer, so it's fine that you're not yet familiar with all the intricacies of portfile writing. And I'm a manager of MacPorts, so it's my job to point these things out and make sure we all are in the habit of following the same portfile writing conventions. If you're ok with the proposed changes, you could submit a diff and Jeremy or another committer could commit it. From jmr at macports.org Tue Feb 10 01:34:23 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 10 Feb 2009 20:34:23 +1100 Subject: [46644] trunk/dports/security In-Reply-To: <7F41FC87-39D5-472C-A8DC-328D88CF5F2E@macports.org> References: <20090209153026.E70DDEDE7D1@beta.macosforge.org> <7F41FC87-39D5-472C-A8DC-328D88CF5F2E@macports.org> Message-ID: <49914A1F.9000107@macports.org> > On Feb 10, 2009, at 02:45, Lassi A. Tuura wrote: >>> Is there an http master site that could be added? Some users, >>> including our own distfiles mirror, cannot fetch from ftp sites. >> >> Not that I know of. A web search on the archive name returns 'hey get >> files and ads from us' sites; do you trust such secondary file >> sources? The sites don't have to be trusted, if the file has been modified then the checksums won't match. - Josh From shreevatsa.public at gmail.com Tue Feb 10 02:58:12 2009 From: shreevatsa.public at gmail.com (Shreevatsa R) Date: Tue, 10 Feb 2009 05:58:12 -0500 Subject: Ports recommending other ports In-Reply-To: <58F1BF97-1890-42B9-AC64-23BABB5C99CB@pixilla.com> References: <49901D1E.5030005@macports.org> <4990AF59.30205@macports.org> <58F1BF97-1890-42B9-AC64-23BABB5C99CB@pixilla.com> Message-ID: <20090210105812.GA55224@NORTHWEST-THIRTYFIVE-THREE-SEVENTY-SIX.MIT.EDU> On Mon, Feb 09, 2009 at 08:04:48PM -0800, Bradley Giesbrecht wrote: > I also am not a fan of the plural form. > > In my applications I would probably use "recommendation" This doesn't make much sense: "recommends" is not a plural noun. That would be "recommendations". Like "requires" and "depends", "recommends" is a verb (and one which goes with *singular* nouns at that). So the most consistent way to handle this (hypothetical) "recommends" feature would be to use syntax similar to that of "depends": as if in some sense, recommending is a weak form of depending. Anyway, it might be somewhat premature to discuss such fine details. :-) From billitch at gmail.com Tue Feb 10 02:58:43 2009 From: billitch at gmail.com (Thomas de Grivel) Date: Tue, 10 Feb 2009 11:58:43 +0100 Subject: Ports recommending other ports In-Reply-To: <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> Message-ID: <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> 2009/2/9 Ryan Schmidt : > > On Feb 8, 2009, at 21:24, Thomas de Grivel wrote: > >> just thinking out loud : >> maybe we could suggest variants as well ? > > I would say no to this suggestion, because a port should already come > pre-configured for the recommended setup out-of-the-box without needing to > select any variants. There may be variants to turn off certain > recommendations if appropriate, but the user can find all that out by typing > "port variants ". But there is no command that a user can type > today to get a list of other ports that are recommended in combination with > a given port. In the cases I cited (graphviz and postgresql) the user can > type "port search " and see those other ports, because they > contain the original port's name, but that may not always be the case. I meant that a port "A" suggest other ports like in your proposition but possibly with variants. Like that you could recommend a port with appropriate variant that make sense when "A" is installed. For instance the port for mpd (the music player daemon) has a variant flac which allows to play .flac files. Suppose that the flac port recommends using mpd : recommending mpd alone would not make any sense. Instead if the port could add variants to recommendations, it would recommend mpd+flac which would be greatly useful. >> and propose building (or even rebuilding) ports with more sensible >> variants according to installed ones ? > > Could you elaborate or give an example? To complete the above example, someone who has mpd installed without flac support one day installs the flac port and would be recommended to rebuild mpd with flac variant. I realize it may not be trivial or realizable in short term but, like you say : ports should build out of the box without too much user configuration. It would definitely be useful to recommend variants because currently in order to install a port I am typing "port info", checking which variants are useful according to what's already installed and what I want and then "port install ...". That's when I am not lazy because most of the time I feel confident that ports build ok and then realize I have to rebuild it because some variant was missing. It would be much simpler if just before installation a recommendation like : "the ports installed on your system recommends adding these variants : +flac +aac" (when installing mpd) And when installing flac , at the end of installation another message like : "you may want to rebuild or install these ports : mpd+flac, abcde+flac, " etc But as I said I was just thinking out loud ;) -- Thomas de Grivel http://b.lowh.net/billitch/ From cssdev at mac.com Tue Feb 10 03:54:20 2009 From: cssdev at mac.com (cssdev at mac.com) Date: Tue, 10 Feb 2009 06:54:20 -0500 Subject: doxygen In-Reply-To: <0EDF4D7D-355A-4E27-9B5D-44FE9A70C66C@macports.org> References: <1234028298.22454.0.camel@debian> <498DCCCF.8030202@macports.org> <1234030192.23582.0.camel@debian> <0EDF4D7D-355A-4E27-9B5D-44FE9A70C66C@macports.org> Message-ID: <63C5755D-689B-4484-B5F8-DACD78AF807D@mac.com> On Feb 7, 2009, at 1:32 PM, Ryan Schmidt wrote: > On Feb 7, 2009, at 12:09, Jean-Michel Pour? wrote: > >> On Sat, 2009-02-07 at 19:02 +0100, Rainer M?ller wrote: >>> >>> Ticket id? Debug log? Patch? >>> How is your quick note supposed to be helpful? >>> >>> This is a quick note that doxygen @1.5.8_1 builds fine or me on >>> Mac OS X 10.5.6 Leopard on Intel ;-) >> >> Sorry I created a ticket on doxygen a few days ago but I cannot >> find it. >> >> Here is the crash: >> >> Sorry -- I was wrong when I said I could build doxygen on all four >> OSes. It does fail for me on 10.4 PPC, but succeeds on the three >> others. See > > http://trac.macports.org/ticket/18258 > > (I see you're already Cc'd on that ticket) Just FYI for others on the list, this is the result of a fun change Apple made in an iconv() parameter between Tiger and Leopard. I'm checking upstream on a fix so that we hopefully don't need to keep around a custom MacPorts-only patch. (Or we could patch libiconv for the POSIX compliant parameters used on Leopard, but that might cascade to a whole host of other changes.) Chris From jeremy at lavergne.gotdns.org Tue Feb 10 06:02:15 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 10 Feb 2009 09:02:15 -0500 Subject: Ports recommending other ports In-Reply-To: <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> Message-ID: <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> > On Feb 10, 2009, at 5:58 AM, Thomas de Grivel wrote: > > 2009/2/9 Ryan Schmidt : >> >> On Feb 8, 2009, at 21:24, Thomas de Grivel wrote: >>> >>> and propose building (or even rebuilding) ports with more sensible >>> variants according to installed ones ? >> >> Could you elaborate or give an example? > > To complete the above example, someone who has mpd installed without > flac support one day installs the flac port and would be recommended > to rebuild mpd with flac variant. > > I realize it may not be trivial or realizable in short term but, like > you say : ports should build out of the box without too much user > configuration. It would definitely be useful to recommend variants > because currently in order to install a port I am typing "port info", > checking which variants are useful according to what's already > installed and what I want and then "port install ...". That's when I > am not lazy because most of the time I feel confident that ports build > ok and then realize I have to rebuild it because some variant was > missing. > > It would be much simpler if just before installation a recommendation > like : "the ports installed on your system recommends adding these > variants : +flac +aac" (when installing mpd) > > And when installing flac , at the end of installation another message > like : "you may want to rebuild or install these ports : mpd+flac, > abcde+flac, " etc Would running into collisions be easily solved with that "we recommend" messages? For example, some program may want PHP +apache2 and another could want PHP +no_web. Should the recommend message also explain how to switch between two versions of a port on their system (deactivate/activate)? -------------- 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 Tue Feb 10 06:22:40 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue, 10 Feb 2009 15:22:40 +0100 Subject: Ports recommending other ports In-Reply-To: <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> Message-ID: <20090210142240.GW2378@prunille.vinc17.org> On 2009-02-10 09:02:15 -0500, Jeremy Lavergne wrote: > Would running into collisions be easily solved with that "we recommend" > messages? For example, some program may want PHP +apache2 and another > could want PHP +no_web. One should never recommend a port with a negative variant. This does not make sense. However, when a port is installed through a recommendation, additional features (provided by variants) need not be enabled (unless these variants are recommended). -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From jeremy at lavergne.gotdns.org Tue Feb 10 06:26:56 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 10 Feb 2009 09:26:56 -0500 Subject: Ports recommending other ports In-Reply-To: <20090210142240.GW2378@prunille.vinc17.org> References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> <20090210142240.GW2378@prunille.vinc17.org> Message-ID: > On Feb 10, 2009, at 9:22 AM, Vincent Lefevre wrote: > >> Would running into collisions be easily solved with that "we >> recommend" >> messages? For example, some program may want PHP +apache2 and >> another >> could want PHP +no_web. > > One should never recommend a port with a negative variant. This > does not make sense. However, when a port is installed through a > recommendation, additional features (provided by variants) need > not be enabled (unless these variants are recommended). Let me reword this, as I meant to question, "What happens when the recommended variants conflict?" -------------- 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 Feb 10 07:07:55 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 10 Feb 2009 10:07:55 -0500 Subject: overriding variant universal Message-ID: <8799865E-78E2-4474-AFC5-D55FBC718BAB@lavergne.gotdns.org> I'm presently working with a portfile that has lots of values defined by the submitted --- mostly set to defaults. It also seems that all dependents are missing (though apple's built-in stuff will end up satisfying it's needs, it seems). http://trac.macports.org/ticket/17900 Anywho, the real problem I'm having is that he has the universal variant overridden. According to the guide, this is a no-no unless the port won't build. Is this another instance of where the submitted created the defaults? Any insight from those experiened would be appreciated! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From brad at pixilla.com Tue Feb 10 09:59:08 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 10 Feb 2009 09:59:08 -0800 Subject: tcl or portfile keyword for alias In-Reply-To: <55EF773E-46F0-45C5-9A8C-297EEDA4DD6D@macports.org> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <9375E787-2352-423A-8333-95F90AA2C1E3@macports.org> <6ADE31F5-29EB-4A55-96FB-D94B0FFFA00E@pixilla.com> <4B114D73-20C4-47F1-9B60-C5EA1CCC5E44@pixilla.com> <55EF773E-46F0-45C5-9A8C-297EEDA4DD6D@macports.org> Message-ID: <7859EA73-8D77-435E-BACF-B19C135A2631@pixilla.com> On Feb 9, 2009, at 9:57 PM, Ryan Schmidt wrote: > > On Feb 9, 2009, at 22:52, Bradley Giesbrecht wrote: > >> On Feb 9, 2009, at 8:41 PM, Ryan Schmidt wrote: >> >>> On Feb 9, 2009, at 22:34, Bradley Giesbrecht wrote: >>> >>>> On Feb 9, 2009, at 4:18 PM, Ryan Schmidt wrote: >>>> >>>>> On Feb 9, 2009, at 17:53, Ryan Schmidt wrote: >>>>> >>>>>> You could prepend ${prefix}/lib/mysql5/bin to the PATH. That's >>>>>> where the program "mysql_config" lives. >>>>>> >>>>>> configure.env-append PATH=${prefix}/lib/mysql5/bin:$env(PATH) >>>>> >>>>> The reason it then still doesn't work is because libzdb is >>>>> calling mysql_config incorrectly. As you note, it uses >>>>> "mysql_config --libs $LDFLAGS". It is not correct to put >>>>> "$LDFLAGS" at the end of that command invocation. The correct >>>>> way to call it is just "mysql_config --libs". It works for you >>>>> on the command line because LDFLAGS is empty by default, but >>>>> MacPorts fills it with a value, so when run within MacPorts, it >>>>> fails. If you look in the config.log, you see that mysql_config >>>>> is printing its usage message, showing that the way it is being >>>>> used is not correct. Attached is a Portfile and patch that work >>>>> for me. You should send the patchfile to the author of libzdb. >>>>> >>>>> In the Portfile, I also added a dependency on mysql5, and added >>>>> configure arguments to disable postgresql and sqlite. If you >>>>> want to enable postgresql or sqlite, remove the corresponding >>>>> configure argument and add the required dependency. >>>> >>>> I had a more complex Portfile which I trimmed down before posting >>>> to make it simple to try. >>>> >>>> I guess I'm old school that way. >>>> >>>> The patch Portfile attached to your email removed the patch file. >>>> I like it but it didn't work. >>>> If I add the patch and remove the $LDFLAGS in the patch >>>> "mysql_config --libs $LDFLAGS" to "mysql_config --libs" it works. >>> >>> But... the Portfile I attached said >>> >>> patchfiles patch-configure >>> >>> And I attached my revised patch-configure which said >>> >>> - LDFLAGS=`mysql_config --libs $LDFLAGS` >>> - CPPFLAGS=`mysql_config --include $CPPFLAGS` >>> + LDFLAGS="`mysql_config --libs` $LDFLAGS" >>> + CPPFLAGS="`mysql_config --include` $CPPFLAGS" >>> >>> to fix the problem with calling mysql_config. My Portfile also >>> fixed the PATH in the configure phase with >>> >>> configure.env-append PATH=${prefix}/lib/mysql5/bin:$env(PATH) >>> >>> so that mysql_config could be found. I tested this before >>> attaching it to the email and it worked for me as sent. >> >> Reading your comment " It is not correct to put "$LDFLAGS" at the >> end of that command invocation." and without looking in >> "config.log" personally I assumed you meant to remove the >> "$LDFLAGS" from "mysql_config --libs $LDFLAGS" in the patch. >> >> I just copied your revised Portfile and patch-configure file and >> ran "port clean --all" and "port configure" and it failed. >> >> Altering the patch to remove ""$LDFLAGS"" fixed the configure >> problems. >> >> Anyways, without looking at the configure.log I believe you are >> right and that is very cool. I will pass your/our patch upstream. > > LDFLAGS should not be inside the backticks, but should presumably be > outside the backticks. The way the developer had it, he was saying > "set LDFLAGS to the value of the program invocation `mysql_config -- > libs $LDFLAGS`" and that's not a valid invocation of mysql_config if > $LDFLAGS is nonempty. I changed it to say "set LDFLAGS to the value > of the program invocation `mysql_config --libs` and then a space and > then whatever was already in $LDFLAGS" which I think is what the > developer was trying to say, but maybe he never tested with LDFLAGS > nonempty. > > I just tried again with the files I sent earlier and it works fine. > Make a directory libzdb, put Portfile in it, make a files directory > in it, put patch-configure in the files directory, cd to the libzdb > directory, and run port -d configure. For me it says: I appologize. I may have not noticed the change you made to the patch to move the $LDFLAGS outside the backticks. Your right, your files work. Thank you for your help. Now I need to finish the Portfile so I can continue with the dbmail- devel port. Since libzdb may be used by someone else some day I'm trying to think what to do with it. Should I make variants for sqlite, mysql and postgresql or just let the configure script look for all three and fail with a message if it finds nothing? I remember you (Ryan) saying it's nice to keep the variant count to a minimum. //Brad From brad at pixilla.com Tue Feb 10 10:07:34 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 10 Feb 2009 10:07:34 -0800 Subject: libzdb help! In-Reply-To: <74c219d30902092228ya3d2547x7f81669c5cb94e21@mail.gmail.com> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <385BE47B-B69A-4974-B66A-5CA14FA022F6@pixilla.com> <74c219d30902091418g7934987fv40f2ba2021f5fc6a@mail.gmail.com> <74c219d30902092228ya3d2547x7f81669c5cb94e21@mail.gmail.com> Message-ID: On Feb 9, 2009, at 10:28 PM, Toby Peterson wrote: > On Mon, Feb 9, 2009 at 7:12 PM, Bradley Giesbrecht > wrote: >> I am familiar with -d. Been running it all day. >> >> I have tried to find a way to influance the configure script without >> patching but I gave up and patched it. >> >> # port configure // fails >> >> # cd work/libzdb-2.3/ && ./configure --prefix=/opt/local // works >> >> As far as I know --prefix typically influences the install dir and >> not the >> finding of libs or includes. >> But I'm not a strong unix admin. >> >> Just try the scripts I attached. Takes about a minute or two to add >> them to >> a local repo. >> >> I have the scripts dumbed down on purpose. Running ./configure with >> no args >> (or with prefix=/opt/local if you prefer) from ${worksrcdir} or >> what ever >> that var is named works. >> Running "port configure" does not work. > > OK, I see why it doesn't work. This was mentioned previously. We set > LDFLAGS/CPPFLAGS (and other variables) in the environment, which > breaks the following command: > > mysql_config5 --libs $LDFLAGS > > Normally LDFLAGS is empty, so it doesn't affect this. Anyway, easy > enough fix to patch-configure .... > > + LDFLAGS=`/opt/local/bin/mysql_config5 --libs $LDFLAGS` > + CPPFLAGS=`/opt/local/bin/mysql_config5 --include $CPPFLAGS` > > should be > > + LDFLAGS=`/opt/local/bin/mysql_config5 --libs` $LDFLAGS > + CPPFLAGS=`/opt/local/bin/mysql_config5 --include` $CPPFLAGS > > That should get things working, to some extent. I have some other > complaints about your Portfile, but let's get this thing compiling > first. :) Yes, you and Ryan both had this figured correctly. It's now compiling. Thanks. I had reduced the Portfile to it's bare minimum in my attempt to find what was wrong. Should I make variants for sqlite, mysql and postgresql or just let the configure script look for all three and fail with a message if it finds nothing? I also planned on adding a couple configure options like these three: --enable-optimized Build software optimized --enable-zild Reduce visbility of objects for linking with zild. Require gcc version 4.x --enable-protected Package protect non-api objects. Require gcc version 4.x This option hide objects in the DSO which are not part of the api and not to be exported. The rationale is to optimize the ABI and protect non-public methods of the DSO and thereby reduce the potential for namespace conflicts for clients linking with the library. Recommend //Brad From jmr at macports.org Tue Feb 10 13:15:01 2009 From: jmr at macports.org (Joshua Root) Date: Wed, 11 Feb 2009 08:15:01 +1100 Subject: libzdb help! In-Reply-To: References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <385BE47B-B69A-4974-B66A-5CA14FA022F6@pixilla.com> <74c219d30902091418g7934987fv40f2ba2021f5fc6a@mail.gmail.com> <74c219d30902092228ya3d2547x7f81669c5cb94e21@mail.gmail.com> Message-ID: <4991EE55.1080703@macports.org> Bradley Giesbrecht wrote: > Should I make variants for sqlite, mysql and postgresql or just let the > configure script look for all three and fail with a message if it finds > nothing? Definitely not the latter. Installing a port with any given set of variants (including none) should produce the same result for every user, regardless of which ports they happened to have installed before installing this one. Either always depend on libs that could be detected and used, or always disable their use. Optionally, add variants that add a dependency and turn the feature back on. - Josh From ryandesign at macports.org Tue Feb 10 04:22:37 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Feb 2009 06:22:37 -0600 Subject: doxygen In-Reply-To: <63C5755D-689B-4484-B5F8-DACD78AF807D@mac.com> References: <1234028298.22454.0.camel@debian> <498DCCCF.8030202@macports.org> <1234030192.23582.0.camel@debian> <0EDF4D7D-355A-4E27-9B5D-44FE9A70C66C@macports.org> <63C5755D-689B-4484-B5F8-DACD78AF807D@mac.com> Message-ID: <2F5A6E00-7C2E-4A3F-A270-D609C23C8ABD@macports.org> On Feb 10, 2009, at 05:54, cssdev at mac.com wrote: > On Feb 7, 2009, at 1:32 PM, Ryan Schmidt wrote: > >> http://trac.macports.org/ticket/18258 >> >> (I see you're already Cc'd on that ticket) > > Just FYI for others on the list, this is the result of a fun change > Apple made in an iconv() parameter between Tiger and Leopard. I'm > checking upstream on a fix so that we hopefully don't need to keep > around a custom MacPorts-only patch. (Or we could patch libiconv > for the POSIX compliant parameters used on Leopard, but that might > cascade to a whole host of other changes.) Yes, in reading up on this issue myself, Apple changed the iconv() parameter in Leopard for POSIX compliance. And it appears to be the intention of libiconv to mimic the system's iconv() function, whatever it may be. This is explained in libiconv's iconv.h: /* We would like to #include any system header file which could define iconv_t, 1. in order to eliminate the risk that the user gets compilation errors because some other system header file includes /usr/ include/iconv.h which defines iconv_t or declares iconv after this file, 2. when compiling for LIBICONV_PLUG, we need the proper iconv_t type in order to produce binary compatible code. But gcc's #include_next is not portable. Thus, once libiconv's iconv.h has been installed in /usr/local/include, there is no way any more to include the original /usr/include/iconv.h. We simply have to get away without it. Ad 1. The risk that a system header file does #include "iconv.h" or #include_next "iconv.h" is small. They all do #include . Ad 2. The iconv_t type is a pointer type in all cases I have seen. (It has to be a scalar type because (iconv_t)(-1) is a possible return value from iconv_open().) */ So I don't think I want to change libiconv to always be POSIX- compliant, even if the OS is not, because that appears to contradict the intentions of the developer of libiconv, whom I am in no place to second-guess. doxygen's portable.cpp has this code for determining which iconv() function prototype to use: // libiconv is a mess. For some platforms/version the prototype of inbuf is // "const char **", for others it is "char **". C++ requires the proper cast to // avoid a compile error, that is were the CASTNEEDED is for. #if ((defined(_LIBICONV_VERSION) && (_LIBICONV_VERSION>=0x0109) && \ !((defined(_OS_MAC_) || defined(Q_OS_MACX) )&& (_LIBICONV_VERSION==0x010B))) \ || defined(_OS_SOLARIS_) \ || defined(_OS_NETBSD_) \ ) #define CASTNEEDED(x) (x) #else #define CASTNEEDED(x) (char **)(x) #endif This code would appear to be incorrect, because it is based only on the libiconv version and the OS, with no apparent differentiation for the OS version (i.e. Tiger vs. Leopard in our case, who knows what else on other OSes). The m4 macro I referenced earlier incorporates a test into your autoconf-based configure script to figure out what's in use on your OS. Unfortunately doxygen's configure script appears not to be autoconf-based. Note that our libiconv port has some issues of its own when it comes to 64-bit universal binaries which I've filed here: http://trac.macports.org/ticket/18440 From brad at pixilla.com Tue Feb 10 13:50:08 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 10 Feb 2009 13:50:08 -0800 Subject: libzdb help! In-Reply-To: <4991EE55.1080703@macports.org> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <385BE47B-B69A-4974-B66A-5CA14FA022F6@pixilla.com> <74c219d30902091418g7934987fv40f2ba2021f5fc6a@mail.gmail.com> <74c219d30902092228ya3d2547x7f81669c5cb94e21@mail.gmail.com> <4991EE55.1080703@macports.org> Message-ID: <71D38C3B-C615-4B63-ACED-3D05C5511FA3@pixilla.com> libzdb does nothing without one of the three supported dbs installed. And know one will probably want it unless they are already installing something else that needs it. But if I add it as a dependancy to dbmail-devel (I'm porting this now) and dbmail-devel needs one of the same three db's I could maybe just combine the two distributions and configure libzdb for what ever db backend variants were chosen for dbmail-devel? Because if I just add libzdb as a dependancy for dbmail-devel I won't have control over variant's for libzdb. Right? That's why I was thinking of just letting libzdb find the available db's on it's own since at least one of the db's variants in dbmail- devel MUST be chosen so there will always be at least one. //Brad On Feb 10, 2009, at 1:15 PM, Joshua Root wrote: > Bradley Giesbrecht wrote: >> Should I make variants for sqlite, mysql and postgresql or just let >> the >> configure script look for all three and fail with a message if it >> finds >> nothing? > > Definitely not the latter. Installing a port with any given set of > variants (including none) should produce the same result for every > user, > regardless of which ports they happened to have installed before > installing this one. > > Either always depend on libs that could be detected and used, or > always > disable their use. Optionally, add variants that add a dependency and > turn the feature back on. > > - Josh From blb at macports.org Tue Feb 10 14:03:52 2009 From: blb at macports.org (Bryan Blackburn) Date: Tue, 10 Feb 2009 15:03:52 -0700 Subject: [46699] trunk/dports/devel In-Reply-To: <20090210213513.02849EFDAB9@beta.macosforge.org> References: <20090210213513.02849EFDAB9@beta.macosforge.org> Message-ID: <20090210220352.GE662@ninagal.withay.com> On Tue, Feb 10, 2009 at 01:35:12PM -0800, snc at macports.org said: > Revision: 46699 > http://trac.macports.org/changeset/46699 > Author: snc at macports.org > Date: 2009-02-10 13:35:11 -0800 (Tue, 10 Feb 2009) > Log Message: > ----------- > after getting requested portgroup haskell patch, created hs-parsec, ticket #17924 > > Added Paths: > ----------- > trunk/dports/devel/hs-parsec/ > trunk/dports/devel/hs-parsec/Portfile > trunk/dports/devel/hs-parsec/work You definitely want to get rid of the work symlink here, it may very well confuse port. Bryan [...] From jeremy at lavergne.gotdns.org Tue Feb 10 14:07:06 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 10 Feb 2009 17:07:06 -0500 Subject: [46699] trunk/dports/devel In-Reply-To: <20090210220352.GE662@ninagal.withay.com> References: <20090210213513.02849EFDAB9@beta.macosforge.org> <20090210220352.GE662@ninagal.withay.com> Message-ID: > On Feb 10, 2009, at 5:03 PM, Bryan Blackburn wrote: > > On Tue, Feb 10, 2009 at 01:35:12PM -0800, snc at macports.org said: >> Revision: 46699 >> http://trac.macports.org/changeset/46699 >> Author: snc at macports.org >> Date: 2009-02-10 13:35:11 -0800 (Tue, 10 Feb 2009) >> ... >> Added Paths: >> ----------- >> ... >> trunk/dports/devel/hs-parsec/work > > You definitely want to get rid of the work symlink here, it may very > well > confuse port. Thanks, fixed in r46701. -------------- 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 Tue Feb 10 15:07:39 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Feb 2009 17:07:39 -0600 Subject: tcl or portfile keyword for alias In-Reply-To: <7859EA73-8D77-435E-BACF-B19C135A2631@pixilla.com> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <9375E787-2352-423A-8333-95F90AA2C1E3@macports.org> <6ADE31F5-29EB-4A55-96FB-D94B0FFFA00E@pixilla.com> <4B114D73-20C4-47F1-9B60-C5EA1CCC5E44@pixilla.com> <55EF773E-46F0-45C5-9A8C-297EEDA4DD6D@macports.org> <7859EA73-8D77-435E-BACF-B19C135A2631@pixilla.com> Message-ID: <91778398-8C4E-4179-8148-C94373E0414C@macports.org> On Feb 10, 2009, at 11:59, Bradley Giesbrecht wrote: > > On Feb 9, 2009, at 9:57 PM, Ryan Schmidt wrote: > >> >> On Feb 9, 2009, at 22:52, Bradley Giesbrecht wrote: >> >>> On Feb 9, 2009, at 8:41 PM, Ryan Schmidt wrote: >>> >>>> On Feb 9, 2009, at 22:34, Bradley Giesbrecht wrote: >>>> >>>>> On Feb 9, 2009, at 4:18 PM, Ryan Schmidt wrote: >>>>> >>>>>> On Feb 9, 2009, at 17:53, Ryan Schmidt wrote: >>>>>> >>>>>>> You could prepend ${prefix}/lib/mysql5/bin to the PATH. >>>>>>> That's where the program "mysql_config" lives. >>>>>>> >>>>>>> configure.env-append PATH=${prefix}/lib/mysql5/bin:$env(PATH) >>>>>> >>>>>> The reason it then still doesn't work is because libzdb is >>>>>> calling mysql_config incorrectly. As you note, it uses >>>>>> "mysql_config --libs $LDFLAGS". It is not correct to put >>>>>> "$LDFLAGS" at the end of that command invocation. The correct >>>>>> way to call it is just "mysql_config --libs". It works for you >>>>>> on the command line because LDFLAGS is empty by default, but >>>>>> MacPorts fills it with a value, so when run within MacPorts, >>>>>> it fails. If you look in the config.log, you see that >>>>>> mysql_config is printing its usage message, showing that the >>>>>> way it is being used is not correct. Attached is a Portfile >>>>>> and patch that work for me. You should send the patchfile to >>>>>> the author of libzdb. >>>>>> >>>>>> In the Portfile, I also added a dependency on mysql5, and >>>>>> added configure arguments to disable postgresql and sqlite. If >>>>>> you want to enable postgresql or sqlite, remove the >>>>>> corresponding configure argument and add the required dependency. >>>>> >>>>> I had a more complex Portfile which I trimmed down before >>>>> posting to make it simple to try. >>>>> >>>>> I guess I'm old school that way. >>>>> >>>>> The patch Portfile attached to your email removed the patch >>>>> file. I like it but it didn't work. >>>>> If I add the patch and remove the $LDFLAGS in the patch >>>>> "mysql_config --libs $LDFLAGS" to "mysql_config --libs" it works. >>>> >>>> But... the Portfile I attached said >>>> >>>> patchfiles patch-configure >>>> >>>> And I attached my revised patch-configure which said >>>> >>>> - LDFLAGS=`mysql_config --libs $LDFLAGS` >>>> - CPPFLAGS=`mysql_config --include $CPPFLAGS` >>>> + LDFLAGS="`mysql_config --libs` $LDFLAGS" >>>> + CPPFLAGS="`mysql_config --include` $CPPFLAGS" >>>> >>>> to fix the problem with calling mysql_config. My Portfile also >>>> fixed the PATH in the configure phase with >>>> >>>> configure.env-append PATH=${prefix}/lib/mysql5/bin:$env >>>> (PATH) >>>> >>>> so that mysql_config could be found. I tested this before >>>> attaching it to the email and it worked for me as sent. >>> >>> Reading your comment " It is not correct to put "$LDFLAGS" at the >>> end of that command invocation." and without looking in >>> "config.log" personally I assumed you meant to remove the >>> "$LDFLAGS" from "mysql_config --libs $LDFLAGS" in the patch. >>> >>> I just copied your revised Portfile and patch-configure file and >>> ran "port clean --all" and "port configure" and it failed. >>> >>> Altering the patch to remove ""$LDFLAGS"" fixed the configure >>> problems. >>> >>> Anyways, without looking at the configure.log I believe you are >>> right and that is very cool. I will pass your/our patch upstream. >> >> LDFLAGS should not be inside the backticks, but should presumably >> be outside the backticks. The way the developer had it, he was >> saying "set LDFLAGS to the value of the program invocation >> `mysql_config --libs $LDFLAGS`" and that's not a valid invocation >> of mysql_config if $LDFLAGS is nonempty. I changed it to say "set >> LDFLAGS to the value of the program invocation `mysql_config -- >> libs` and then a space and then whatever was already in $LDFLAGS" >> which I think is what the developer was trying to say, but maybe >> he never tested with LDFLAGS nonempty. >> >> I just tried again with the files I sent earlier and it works >> fine. Make a directory libzdb, put Portfile in it, make a files >> directory in it, put patch-configure in the files directory, cd to >> the libzdb directory, and run port -d configure. For me it says: > > I appologize. I may have not noticed the change you made to the > patch to move the $LDFLAGS outside the backticks. > > Your right, your files work. Thank you for your help. > > Now I need to finish the Portfile so I can continue with the dbmail- > devel port. > > Since libzdb may be used by someone else some day I'm trying to > think what to do with it. > > Should I make variants for sqlite, mysql and postgresql or just let > the configure script look for all three and fail with a message if > it finds nothing? > > I remember you (Ryan) saying it's nice to keep the variant count to > a minimum. True, fewer variants are better. However, it is not ok for a port to use whatever it finds and fail if it finds nothing. A port must declare dependencies on all ports it uses. So you must either force the port to use specific versions of mysql, postgresql and/or sqlite, or force the port not to use mysql, postgresql and/or sqlite. For now it's probably fine to just make the port do whatever you need it to do for your purposes. If someone else needs it to support other database systems in the future, they can file a ticket in Trac. From ryandesign at macports.org Tue Feb 10 15:11:34 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Feb 2009 17:11:34 -0600 Subject: libzdb help! In-Reply-To: <71D38C3B-C615-4B63-ACED-3D05C5511FA3@pixilla.com> References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <385BE47B-B69A-4974-B66A-5CA14FA022F6@pixilla.com> <74c219d30902091418g7934987fv40f2ba2021f5fc6a@mail.gmail.com> <74c219d30902092228ya3d2547x7f81669c5cb94e21@mail.gmail.com> <4991EE55.1080703@macports.org> <71D38C3B-C615-4B63-ACED-3D05C5511FA3@pixilla.com> Message-ID: <8B820CA6-3AE3-4129-9A43-FA878B87FA46@macports.org> On Feb 10, 2009, at 15:50, Bradley Giesbrecht wrote: > libzdb does nothing without one of the three supported dbs installed. > > And know one will probably want it unless they are already > installing something else that needs it. > > But if I add it as a dependancy to dbmail-devel (I'm porting this > now) and dbmail-devel needs one of the same three db's I could > maybe just combine the two distributions and configure libzdb for > what ever db backend variants were chosen for dbmail-devel? > > Because if I just add libzdb as a dependancy for dbmail-devel I > won't have control over variant's for libzdb. Right? > > That's why I was thinking of just letting libzdb find the available > db's on it's own since at least one of the db's variants in dbmail- > devel MUST be chosen so there will always be at least one. If you have database variants in dbmail-devel, then put those same variants into libzdb. When a user installs dbmail-devel with one of those variants, if libzdb was not already installed, MacPorts will pass those variant selections to libzdb and it will be installed with the same variants. There is a potential problem if libzdb was already installed with a different set of variants, but that can perhaps be addressed later. From ryandesign at macports.org Tue Feb 10 15:12:55 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Feb 2009 17:12:55 -0600 Subject: libzdb help! In-Reply-To: References: <60FC3949-3C44-4DF7-988F-74A9BB77FA1F@pixilla.com> <385BE47B-B69A-4974-B66A-5CA14FA022F6@pixilla.com> <74c219d30902091418g7934987fv40f2ba2021f5fc6a@mail.gmail.com> <74c219d30902092228ya3d2547x7f81669c5cb94e21@mail.gmail.com> Message-ID: <9BD3AD05-3B50-468B-9FF2-EA694AD376AF@macports.org> On Feb 10, 2009, at 12:07, Bradley Giesbrecht wrote: > I also planned on adding a couple configure options like these three: > --enable-optimized Build software optimized Sounds like it could be a good idea. > --enable-zild Reduce visbility of objects for linking with zild. > Require gcc version 4.x > --enable-protected Package protect non-api objects. Require gcc > version > 4.x This option hide objects in the DSO which are > not part of the api and not to be exported. The > rationale is to optimize the ABI and protect > non-public methods of the DSO and thereby reduce the > potential for namespace conflicts for clients > linking with the library. Recommend If the software will still work without these options, consider adding them only on Tiger and above, since Panther has gcc 3.3. From ryandesign at macports.org Tue Feb 10 15:18:47 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Feb 2009 17:18:47 -0600 Subject: overriding variant universal In-Reply-To: <8799865E-78E2-4474-AFC5-D55FBC718BAB@lavergne.gotdns.org> References: <8799865E-78E2-4474-AFC5-D55FBC718BAB@lavergne.gotdns.org> Message-ID: <937EB610-8EF4-46CA-B3A3-665037F8656C@macports.org> On Feb 10, 2009, at 09:07, Jeremy Lavergne wrote: > I'm presently working with a portfile that has lots of values > defined by the submitted --- mostly set to defaults. It also seems > that all dependents are missing (though apple's built-in stuff will > end up satisfying it's needs, it seems). > > http://trac.macports.org/ticket/17900 > > Anywho, the real problem I'm having is that he has the universal > variant overridden. According to the guide, this is a no-no unless > the port won't build. Is this another instance of where the > submitted created the defaults? Any insight from those experiened > would be appreciated! Looks like you've already made progress on this in the ticket and noted that this port uses cmake. The default universal variant is designed for autoconf/automake ports and does not work with cmake, so that's probably why the portfile was submitted with an overridden universal variant. You're probably right that the cmake portgroup could be used instead, which already provides an overridden universal variant. The ruby variant claims to build a ruby extension, but does not declare a dependency on a ruby port. How does this work, and where does the extension go? The demos variant says it installs a demo... Does the demo take a lot of time to build or is it very large? If not, remove the variant and make the port always build and install the demo. Fewer variants / maximal functionality up front is better; disk space is cheap. :) From ryandesign at macports.org Tue Feb 10 16:55:47 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Feb 2009 18:55:47 -0600 Subject: [46647] trunk/dports/games In-Reply-To: <1C882848-69EC-4EE5-8402-99174ADAFAE6@lavergne.gotdns.org> References: <20090209155820.BD7D8EDEA5C@beta.macosforge.org> <1C882848-69EC-4EE5-8402-99174ADAFAE6@lavergne.gotdns.org> Message-ID: On Feb 10, 2009, at 07:32, Jeremy Lavergne wrote: > On Feb 9, 2009, at 7:39 PM, Ryan Schmidt wrote: > >> On Feb 9, 2009, at 09:58, snc at macports.org wrote: >> >>> +pre-fetch { >>> + if {[file isdirectory ${workpath}/gtkevemon]} { >>> + if {![file isdirectory ${workpath}/gtkevemon/.svn]} { >>> + file delete -force ${workpath}/gtkevemon >>> + } >>> + } >>> +} >>> + >>> +fetch { >>> + system "cd ${workpath} && svn co -r${version} svn:// >>> gtkevemon.battleclinic.com/GTKEVEMon/trunk/gtkevemon" >>> +} >> >> Why is this portfile not using the svn fetchtype? > > > Does this address all the svn issues? > http://trac.macports.org/attachment/ticket/18441/patch-gtkevemon.diff I see you already committed this, but does applying this change cause the files installed by the port to be different in some way? If not, the revision should not have been increased. (Don't decrease it now, but for future reference.) Also, what is the purpose of the pre-fetch block which is still there? It looks like this was copied from the ffmpeg port, which has specific reasons for not using the svn fetchtype, related to pinning the revision of an svn:externals definition ffmpeg's repository uses. The line "extract {}" should be removed; you should not override the standard extract phase. Using the svn fetchtype will cause the extract phase to do nothing, at the moment, but that could change in a future version of MacPorts, e.g. via #16373, and you don't want your port to stop working then. http://trac.macports.org/ticket/16373 In the destroot phase, the lines file mkdir ${destroot} file mkdir ${destroot}${prefix}/bin are unnecessary; MacPorts creates those directories for you before the destroot phase runs. And in the destroot phase we prefer to use xinstall, so the line file copy ${worksrcpath}/src/gtkevemon ${destroot}${prefix}/bin/ gtkevemon would become xinstall -W ${worksrcpath}/src -m 755 gtkevemon ${destroot}$ {prefix}/bin From ryandesign at macports.org Tue Feb 10 16:58:53 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Feb 2009 18:58:53 -0600 Subject: How distfiles mirrors know to fetch new files Message-ID: <5998833B-8C92-4E9C-97CC-3EDE283A5E65@macports.org> We have three distfiles mirrors, in the US, Norway and Sweden: US: http://distfiles.macports.org/ NO: http://trd.no.distfiles.macports.org/ SE: http://arn.se.distfiles.macports.org/ In /graphviz the US mirror has distfiles up to the current port version, graphviz-2.21.20090209.0545.tar.gz. But Sweden only has files up to graphviz-2.21.20090106.0545.tar.gz. Norway only has files up to graphviz-2.21.20081216.0545.tar.gz. I believe the US mirror, which runs right next to the Subversion repository, gets updated in a post-commit hook, so as soon as someone commits a new version of a port, the mirror fetches the new file. How do Norway and Sweden get informed that they should fetch new files? I fear they're not getting informed at all. From ryandesign at macports.org Tue Feb 10 17:15:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Feb 2009 19:15:38 -0600 Subject: [46696] trunk/dports/www In-Reply-To: <20090210202127.81D19EFC9BB@beta.macosforge.org> References: <20090210202127.81D19EFC9BB@beta.macosforge.org> Message-ID: <06D3701B-8A1C-4A9A-8895-074F43F2EEE1@macports.org> On Feb 10, 2009, at 14:21, snc at macports.org wrote: > Revision: 46696 > http://trac.macports.org/changeset/46696 > Author: snc at macports.org > Date: 2009-02-10 12:21:26 -0800 (Tue, 10 Feb 2009) > Log Message: > ----------- > created wikkawiki, ticket #17724 > > Added Paths: > ----------- > trunk/dports/www/wikkawiki/ > trunk/dports/www/wikkawiki/Portfile > > Added: trunk/dports/www/wikkawiki/Portfile > =================================================================== > --- trunk/dports/www/wikkawiki/Portfile > (rev 0) > +++ trunk/dports/www/wikkawiki/Portfile 2009-02-10 20:21:26 UTC > (rev 46696) > @@ -0,0 +1,82 @@ > +# c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 If possible, please use the standard modeline defined in the Guide. > +# $Id$ > + > +PortSystem 1.0 > + > +name wikkawiki > +set major_version 1.1.6 > +version ${major_version}.5 > +categories www php > +maintainers wikkawiki.org:brian > +description WikkaWiki is a flexible, standards-compliant > and lightweight wiki engine. > +long_description WikkaWiki is a flexible, standards-compliant > and \ > + lightweight wiki engine written in PHP, which > uses MySQL \ > + to store pages. Forked from WakkaWiki. > Designed for \ > + speed, extensibility, and security. For > installation \ > + instructions, visit http://docs.wikkawiki.org/ > MacportInstall > +homepage http://www.wikkawiki.org > +distname Wikka-${version} > +master_sites http://wikkawiki.org/downloads/ > +checksums md5 e1f3b98b98ff5fb6b22fa4848b54317b \ > + sha1 2d2e114d69223f759a5e0261887748112eba24b2 > +platforms darwin freebsd > + > +depends_lib \ > + port:php4 \ > + port:mysql4 > + > +variant php5 description {Use php5 instead of php4 (not fully > tested)} { > + depends_lib-append port:php5 Dependency on php5 should be written "path:bin/php:php5" so that php5- devel could satisfy the dependency. > + depends_lib-delete port:php4 > +} > + > +variant mysql5 description {Use mysql5 instead of mysql4 (not > fully tested)} { > + depends_lib-append port:mysql5 Dependency on mysql5 should be written "path:bin/ mysql_config5:mysql5" so that mysql5-devel could satisfy the dependency. However, does wikkawiki really require a MySQL server to be present on the same computer? Is it not sufficient to access a MySQL server on another computer? If so, no dependency on a MySQL port should be stated. > + depends_lib-delete port:mysql4 > +} > + > +variant nodeps description {Use existing php/mysql libs} { > + depends_lib-delete port:php4 > + depends_lib-delete port:mysql4 > +} > + > +variant use_osx_docroot conflicts php5 mysql5 requires nodeps > description {Create link to /Library/WebServer/Documents} {} > + > +use_configure no > +build {} > + > +set wikkapath ${destroot}${prefix}/www/wikka > +set osxdocpath /Library/WebServer/Documents > + > +destroot { > + xinstall -d -m 0755 ${wikkapath} > + eval file copy [glob ${worksrcpath}/*] ${wikkapath} > + xinstall -m 0666 ${worksrcpath}/.htaccess ${wikkapath} > + touch ${wikkapath}/wikka.config.php > + file attributes ${wikkapath}/wikka.config.php -permissions 0666 > + > + if {[variant_isset use_osx_docroot]} { > + file delete -force ${osxdocpath}/wikka > + ln -s ${prefix}/www/wikka ${osxdocpath}/wikka > + } > +} The port should not be manipulating files outside of the destroot. Please rework the destroot phase so that the symlink in the osxdocpath is created inside the destroot. It's also clearer if you put variant tasks in the variant itself. So remove the "if {[variant_isset use_osx_docroot]}" section from the global destroot proc, and change the use_osx_docroot variant to something like this: variant use_osx_docroot conflicts php5 mysql5 requires nodeps description {Create link in /Library/WebServer/Documents} { post-destroot { xinstall -d ${destroot}/Library xinstall -d ${destroot}/Library/WebServer xinstall -d ${destroot}/Library/WebServer/Documents ln -s ${prefix}/www/wikka ${destroot}/Library/WebServer/ Documents/wikka } } From wsiegrist at apple.com Tue Feb 10 18:07:21 2009 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 10 Feb 2009 18:07:21 -0800 Subject: How distfiles mirrors know to fetch new files In-Reply-To: <5998833B-8C92-4E9C-97CC-3EDE283A5E65@macports.org> References: <5998833B-8C92-4E9C-97CC-3EDE283A5E65@macports.org> Message-ID: On Feb 10, 2009, at 4:58 PM, Ryan Schmidt wrote: > We have three distfiles mirrors, in the US, Norway and Sweden: > > US: http://distfiles.macports.org/ > NO: http://trd.no.distfiles.macports.org/ > SE: http://arn.se.distfiles.macports.org/ > > In /graphviz the US mirror has distfiles up to the current port > version, graphviz-2.21.20090209.0545.tar.gz. > > But Sweden only has files up to graphviz-2.21.20090106.0545.tar.gz. > > Norway only has files up to graphviz-2.21.20081216.0545.tar.gz. > > I believe the US mirror, which runs right next to the Subversion > repository, gets updated in a post-commit hook, so as soon as > someone commits a new version of a port, the mirror fetches the new > file. > > How do Norway and Sweden get informed that they should fetch new > files? I fear they're not getting informed at all. You might want to CC the mirror owners, but in any case, they have to poll for changes (via RSS, mailing list, whatever) or just perform full "port mirror " runs periodically. -Bill From jeremyhu at macports.org Wed Feb 11 01:52:19 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Wed, 11 Feb 2009 01:52:19 -0800 Subject: [46727] trunk/dports/x11/xorg-libXfont In-Reply-To: <20090211075602.8BBA1F0A371@beta.macosforge.org> References: <20090211075602.8BBA1F0A371@beta.macosforge.org> Message-ID: <84CE797F-86F9-4FF7-813B-0654CE9D1AFC@macports.org> Reverted. This was necessary and intentional for weak symbols provided by the Xserver to override the stubs in libXfont. On Feb 10, 2009, at 23:56, jmr at macports.org wrote: > Revision: 46727 > http://trac.macports.org/changeset/46727 > Author: jmr at macports.org > Date: 2009-02-10 23:56:01 -0800 (Tue, 10 Feb 2009) > Log Message: > ----------- > xorg-libXfont: don't force flat namespace > > Modified Paths: > -------------- > trunk/dports/x11/xorg-libXfont/Portfile > > Added Paths: > ----------- > trunk/dports/x11/xorg-libXfont/files/configure.ac.diff > > Modified: trunk/dports/x11/xorg-libXfont/Portfile > =================================================================== > --- trunk/dports/x11/xorg-libXfont/Portfile 2009-02-11 07:54:14 UTC > (rev 46726) > +++ trunk/dports/x11/xorg-libXfont/Portfile 2009-02-11 07:56:01 UTC > (rev 46727) > @@ -40,7 +40,8 @@ > > configure.args --with-bzip2 > > -patchfiles f2b116ce5205d0fb8247f76fddb072e9141c62b7.patch > +patchfiles f2b116ce5205d0fb8247f76fddb072e9141c62b7.patch \ > + configure.ac.diff > > use_autoreconf yes > autoreconf.args -fvi > > Added: trunk/dports/x11/xorg-libXfont/files/configure.ac.diff > =================================================================== > --- trunk/dports/x11/xorg-libXfont/files/ > configure.ac.diff (rev 0) > +++ trunk/dports/x11/xorg-libXfont/files/configure.ac.diff > 2009-02-11 07:56:01 UTC (rev 46727) > @@ -0,0 +1,11 @@ > +--- configure.ac.orig 2008-12-20 10:05:34.000000000 +1100 > ++++ configure.ac 2009-02-11 18:48:27.000000000 +1100 > +@@ -219,7 +219,7 @@ > + OS_CFLAGS="-D_XOPEN_SOURCE" > + ;; > + darwin*) > +- OS_CFLAGS="-Wl,-flat_namespace" > ++ OS_CFLAGS= > + ;; > + *) > + OS_CFLAGS= > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes From jeremy at lavergne.gotdns.org Wed Feb 11 06:31:17 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 11 Feb 2009 09:31:17 -0500 Subject: overriding variant universal In-Reply-To: <937EB610-8EF4-46CA-B3A3-665037F8656C@macports.org> References: <8799865E-78E2-4474-AFC5-D55FBC718BAB@lavergne.gotdns.org> <937EB610-8EF4-46CA-B3A3-665037F8656C@macports.org> Message-ID: <5C626332-1DBC-432D-8AD2-BC7D4E6CCCA6@lavergne.gotdns.org> The demo variant is the only binary-producing portion of that port; the rest are a series of header files and hooks for ruby. Do you still feel the demo variant should be phased in since it's easily built? On Feb 10, 2009, at 6:18 PM, Ryan Schmidt wrote: The demos variant says it installs a demo... Does the demo take a lot of time to build or is it very large? If not, remove the variant and make the port always build and install the demo. Fewer variants / maximal functionality up front is better; disk space is cheap. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jm at poure.com Wed Feb 11 06:31:38 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Wed, 11 Feb 2009 15:31:38 +0100 Subject: libiconv Message-ID: <1234362698.28608.0.camel@debian> Hello, I have a applied a patch on libiconv, which works fine, but cannot find the ticket. Is this still open: Index: textproc/libiconv/Portfile =================================================================== --- textproc/libiconv/Portfile (revision 46735) +++ textproc/libiconv/Portfile (working copy) @@ -5,7 +5,7 @@ name libiconv version 1.12 -revision 2 +revision 3 categories textproc maintainers ryandesign platforms darwin freebsd linux @@ -54,6 +54,11 @@ --disable-nls \ --enable-extra-encodings +post-patch { + # make iconv prototype the same on all platforms + reinplace "s|am_cv_proto_iconv_arg1=\"const\"| am_cv_proto_iconv_arg1=\"\"|" ${worksrcpath}/configure +} + if {![variant_isset disable_utf8mac] || [variant_isset enable_cp932fix]} { build.cmd ${build.cmd} CC=${configure.cc} -f Makefile.devel && ${build.cmd} } From jeremy at lavergne.gotdns.org Wed Feb 11 07:02:21 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 11 Feb 2009 10:02:21 -0500 Subject: more on trunk/dports/www/wikkawiki/Portfile Message-ID: I've got a few more questions relevant to wikkawiki's portfile. There's a post-activate section to show a ui_msg, should that just be post-destroot? Also, can xinstall replace the following line from the destroot phase? #file attributes ${wikkapath}/wikka.config.php -permissions 0666 xinstall -m 0666 {$wikkapath}/wikka.config.php -------------- 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 Feb 11 07:05:14 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 11 Feb 2009 10:05:14 -0500 Subject: [46696] trunk/dports/www In-Reply-To: <06D3701B-8A1C-4A9A-8895-074F43F2EEE1@macports.org> References: <20090210202127.81D19EFC9BB@beta.macosforge.org> <06D3701B-8A1C-4A9A-8895-074F43F2EEE1@macports.org> Message-ID: <62AA26B3-39B0-4C6D-95A9-DC8698473C76@lavergne.gotdns.org> > variant use_osx_docroot conflicts php5 mysql5 requires nodeps > description {Create link in /Library/WebServer/Documents} { > post-destroot { > xinstall -d ${destroot}/Library > xinstall -d ${destroot}/Library/WebServer > xinstall -d ${destroot}/Library/WebServer/Documents > ln -s ${prefix}/www/wikka ${destroot}/Library/WebServer/ > Documents/wikka > } > } I believe xinstall creates parent directories, so that can be shrunk down to just one xinstall line. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From illogical1 at gmail.com Wed Feb 11 07:19:51 2009 From: illogical1 at gmail.com (Orville Bennett) Date: Wed, 11 Feb 2009 10:19:51 -0500 Subject: libiconv In-Reply-To: <1234362698.28608.0.camel@debian> References: <1234362698.28608.0.camel@debian> Message-ID: On Feb 11, 2009, at 9:31 AM, Jean-Michel Pour? wrote: > Hello, > > I have a applied a patch on libiconv, which works fine, but cannot > find > the ticket. Is this still open: > > Index: textproc/libiconv/Portfile > =================================================================== > --- textproc/libiconv/Portfile (revision 46735) > +++ textproc/libiconv/Portfile (working copy) > @@ -5,7 +5,7 @@ > > name libiconv > version 1.12 > -revision 2 > +revision 3 > categories textproc > maintainers ryandesign > platforms darwin freebsd linux > @@ -54,6 +54,11 @@ > --disable-nls \ > --enable-extra-encodings > > +post-patch { > + # make iconv prototype the same on all platforms > + reinplace "s|am_cv_proto_iconv_arg1=\"const\"| > am_cv_proto_iconv_arg1=\"\"|" ${worksrcpath}/configure > +} What, exactly, does this do? And why is it needed? > > + > if {![variant_isset disable_utf8mac] || [variant_isset > enable_cp932fix]} { > build.cmd ${build.cmd} CC=${configure.cc} -f Makefile.devel && > ${build.cmd} > } > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From jeremy at lavergne.gotdns.org Wed Feb 11 08:15:09 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 11 Feb 2009 11:15:09 -0500 Subject: darwin variants to deal with 10.4/10.5 libraries Message-ID: <070781C6-060C-416B-A850-A26CB254BF8D@lavergne.gotdns.org> I'm working on creating a new binary installer for pspp (mpkg) but I've come across a build issue on the 10.4 box. It says symbols are defined twice, but if I comment them out (and make extern) then the 10.5 box says it's undefined. Are the variants and patchfile directive meant to work together like this, ergo simply do patchfiles-delete for the 10.4 version? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Wed Feb 11 08:37:10 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 11 Feb 2009 10:37:10 -0600 Subject: darwin variants to deal with 10.4/10.5 libraries In-Reply-To: <070781C6-060C-416B-A850-A26CB254BF8D@lavergne.gotdns.org> References: <070781C6-060C-416B-A850-A26CB254BF8D@lavergne.gotdns.org> Message-ID: <119DA162-540A-465C-94C9-C50B68647799@macports.org> On Feb 11, 2009, at 10:15, Jeremy Lavergne wrote: > I'm working on creating a new binary installer for pspp (mpkg) but > I've come across a build issue on the 10.4 box. It says symbols > are defined twice, but if I comment them out (and make extern) then > the 10.5 box says it's undefined. > > Are the variants and patchfile directive meant to work together > like this, ergo simply do patchfiles-delete for the 10.4 version? You could do that, yes. From ryandesign at macports.org Wed Feb 11 08:41:32 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 11 Feb 2009 10:41:32 -0600 Subject: libiconv In-Reply-To: References: <1234362698.28608.0.camel@debian> Message-ID: On Feb 11, 2009, at 09:19, Orville Bennett wrote: > On Feb 11, 2009, at 9:31 AM, Jean-Michel Pour? wrote: > >> I have a applied a patch on libiconv, which works fine, but cannot >> find >> the ticket. Is this still open: >> >> Index: textproc/libiconv/Portfile >> =================================================================== >> --- textproc/libiconv/Portfile (revision 46735) >> +++ textproc/libiconv/Portfile (working copy) >> @@ -5,7 +5,7 @@ >> >> name libiconv >> version 1.12 >> -revision 2 >> +revision 3 >> categories textproc >> maintainers ryandesign >> platforms darwin freebsd linux >> @@ -54,6 +54,11 @@ >> --disable-nls \ >> --enable-extra-encodings >> >> +post-patch { >> + # make iconv prototype the same on all platforms >> + reinplace "s|am_cv_proto_iconv_arg1=\"const\"| >> am_cv_proto_iconv_arg1=\"\"|" ${worksrcpath}/configure >> +} > What, exactly, does this do? And why is it needed? I believe that is the patch mentioned here to make the libiconv function prototype always POSIX compliant: http://trac.macports.org/ticket/18258#comment:22 http://trac.macports.org/attachment/ticket/18258/Portfile.diff And I believe that conflicts with the wishes of the developer of libiconv so I do not intend to apply such a patch to the portfile: http://trac.macports.org/ticket/18440 From ryandesign at macports.org Wed Feb 11 08:44:14 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 11 Feb 2009 10:44:14 -0600 Subject: [46696] trunk/dports/www In-Reply-To: <62AA26B3-39B0-4C6D-95A9-DC8698473C76@lavergne.gotdns.org> References: <20090210202127.81D19EFC9BB@beta.macosforge.org> <06D3701B-8A1C-4A9A-8895-074F43F2EEE1@macports.org> <62AA26B3-39B0-4C6D-95A9-DC8698473C76@lavergne.gotdns.org> Message-ID: <726009F2-881D-4031-AC48-C8CB3CE81C6F@macports.org> On Feb 11, 2009, at 09:05, Jeremy Lavergne wrote: >> variant use_osx_docroot conflicts php5 mysql5 requires nodeps >> description {Create link in /Library/WebServer/Documents} { >> post-destroot { >> xinstall -d ${destroot}/Library >> xinstall -d ${destroot}/Library/WebServer >> xinstall -d ${destroot}/Library/WebServer/Documents >> ln -s ${prefix}/www/wikka ${destroot}/Library/WebServer/ >> Documents/wikka >> } >> } > > I believe xinstall creates parent directories, so that can be > shrunk down to just one xinstall line. I just tried it and you're right. The Guide even says so: xinstall -d [-o owner] [-g group] [-m mode] directory Create a directory including parent directories if necessary. That's good to know! I was wondering why we didn't have a "mkdir -p" facility... I guess "xinstall -d" is it! From ryandesign at macports.org Wed Feb 11 08:49:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 11 Feb 2009 10:49:29 -0600 Subject: more on trunk/dports/www/wikkawiki/Portfile In-Reply-To: References: Message-ID: <9FFE1B6F-47FD-4D58-AE07-A367DD645287@macports.org> On Feb 11, 2009, at 09:02, Jeremy Lavergne wrote: > I've got a few more questions relevant to wikkawiki's portfile. > > There's a post-activate section to show a ui_msg, should that just > be post-destroot? Messages usually should get shown at post-activate or maybe post- install time. I think the idea is that you get to see the messages even if you are just activating a previously deactivated port, though that appears to be broken at the moment: http://trac.macports.org/ticket/18273 > Also, can xinstall replace the following line from the destroot phase? > #file attributes ${wikkapath}/wikka.config.php -permissions 0666 > xinstall -m 0666 {$wikkapath}/wikka.config.php "file attributes" sets the attributes of a file. It's like "chmod" on the command line. "xinstall" copies a file from one place to another, and if you use the "-m" switch, also sets the permissions of the copy. So if you were copying a file into the destroot and wanted to set its permissions in some way, then xinstall can do both of those things in one command. In this case I see the port does: touch ${wikkapath}/wikka.config.php file attributes ${wikkapath}/wikka.config.php -permissions 0666 So it looks like it's creating an empty file and making sure it's writable. Is wikka.config.php a file the user is expected to edit? If so, the port should not provide it. Otherwise, the user would edit it, and at the next upgrade of the port, the user's edits will be destroyed. Instead, the port should provide a sample config file in a file of another name (e.g. wikka.config.php.sample) and advise the user to copy this to wikka.config.php and edit it. From ryandesign at macports.org Wed Feb 11 08:51:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 11 Feb 2009 10:51:28 -0600 Subject: overriding variant universal In-Reply-To: <5C626332-1DBC-432D-8AD2-BC7D4E6CCCA6@lavergne.gotdns.org> References: <8799865E-78E2-4474-AFC5-D55FBC718BAB@lavergne.gotdns.org> <937EB610-8EF4-46CA-B3A3-665037F8656C@macports.org> <5C626332-1DBC-432D-8AD2-BC7D4E6CCCA6@lavergne.gotdns.org> Message-ID: <87492337-5A2D-4A83-9AAC-5C7A4BC5D241@macports.org> On Feb 11, 2009, at 08:31, Jeremy Lavergne wrote: > On Feb 10, 2009, at 6:18 PM, Ryan Schmidt wrote: > >> The demos variant says it installs a demo... Does the demo take a >> lot of time to build or is it very large? If not, remove the >> variant and make the port always build and install the demo. Fewer >> variants / maximal functionality up front is better; disk space is >> cheap. :) > > > The demo variant is the only binary-producing portion of that port; > the rest are a series of header files and hooks for ruby. > > Do you still feel the demo variant should be phased in since it's > easily built? I don't know. Possibly yes? Any opinions from anyone else here? :) From ryandesign at macports.org Wed Feb 11 08:59:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 11 Feb 2009 10:59:24 -0600 Subject: [46735] trunk/dports/devel In-Reply-To: <20090211142238.A83FFF0DA22@beta.macosforge.org> References: <20090211142238.A83FFF0DA22@beta.macosforge.org> Message-ID: On Feb 11, 2009, at 08:22, snc at macports.org wrote: > +configure.args-append ../${distname} \ > + -DCMAKE_INSTALL_PREFIX=${prefix} \ > + -DCMAKE_OSX_SYSROOT=${sysroot} Are these lines necessary? The cmake portgroup already has -DCMAKE_INSTALL_PREFIX=${prefix} in configure.pre_args and -DCMAKE_OSX_SYSROOT=${universal_sysroot} in configure.args. I believe ${universal_sysroot} and ${sysroot} have the same value. So the only difference in the portfile is ../${distname} which I'm not sure about. From jeremy at lavergne.gotdns.org Wed Feb 11 11:02:20 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 11 Feb 2009 14:02:20 -0500 Subject: [46735] trunk/dports/devel In-Reply-To: References: <20090211142238.A83FFF0DA22@beta.macosforge.org> Message-ID: <7623F5F1-EAB9-47E5-9FB4-0BB0F02048B3@lavergne.gotdns.org> >> +configure.args-append ../${distname} \ >> + -DCMAKE_INSTALL_PREFIX=${prefix} \ >> + -DCMAKE_OSX_SYSROOT=${sysroot} > > Are these lines necessary? > > The cmake portgroup already has > > -DCMAKE_INSTALL_PREFIX=${prefix} > > in configure.pre_args and > > -DCMAKE_OSX_SYSROOT=${universal_sysroot} > > in configure.args. I believe ${universal_sysroot} and ${sysroot} > have the same value. So the only difference in the portfile is > > ../${distname} > > which I'm not sure about. I went ahead and removed the latter lines (openmaintainer), leaving the ../{$distname}. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From raimue at macports.org Wed Feb 11 13:14:05 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Wed, 11 Feb 2009 22:14:05 +0100 Subject: [46741] trunk/dports/multimedia/ffmpeg/Portfile In-Reply-To: <20090211210011.C44CAF15ACE@beta.macosforge.org> References: <20090211210011.C44CAF15ACE@beta.macosforge.org> Message-ID: <49933F9D.9070701@macports.org> devans at macports.org wrote: > Revision: 46741 > http://trac.macports.org/changeset/46741 > Author: devans at macports.org > Date: 2009-02-11 13:00:11 -0800 (Wed, 11 Feb 2009) > Log Message: > ----------- > ffmpeg: remove --enable--nonfree configure option and +no_nonfree variants as nonfree applies only to libamr-nb and libamr-wb which are not provided by MacPorts due to license/patent issues (#16074), default install is now licensed under GPL. Disabling x264 support which is broken in this revision. > > Modified Paths: > -------------- > trunk/dports/multimedia/ffmpeg/Portfile > > Modified: trunk/dports/multimedia/ffmpeg/Portfile > =================================================================== > --- trunk/dports/multimedia/ffmpeg/Portfile 2009-02-11 20:52:14 UTC (rev 46740) > +++ trunk/dports/multimedia/ffmpeg/Portfile 2009-02-11 21:00:11 UTC (rev 46741) [...] > -variant no_gpl conflicts a52 description {disallow use of GPL code, license will be LGPL if +no_nonfree is selected} { > +variant no_gpl conflicts a52 description {disallow use of GPL code, license will be LGPL} { > configure.args-delete --enable-gpl > configure.args-delete --enable-postproc > configure.args-delete --enable-swscale > configure.args-delete --enable-libfaad > depends_lib-delete port:faad2 > - configure.args-delete --enable-libx264 > - depends_build-delete port:x264 > +# configure.args-delete --enable-libx264 > +# depends_build-delete port:x264 > configure.args-delete --enable-libxvid > depends_lib-delete port:XviD > } Either remove these lines or remove the comment, but please do not leave such commented lines in Portfiles. Later authors might not have any clue what is meant by that. Rainer From devans at macports.org Wed Feb 11 13:33:16 2009 From: devans at macports.org (David Evans) Date: Wed, 11 Feb 2009 13:33:16 -0800 Subject: [46741] trunk/dports/multimedia/ffmpeg/Portfile In-Reply-To: <49933F9D.9070701@macports.org> References: <20090211210011.C44CAF15ACE@beta.macosforge.org> <49933F9D.9070701@macports.org> Message-ID: <4993441C.1080504@macports.org> Rainer M?ller wrote: > devans at macports.org wrote: > >> Revision: 46741 >> http://trac.macports.org/changeset/46741 >> Author: devans at macports.org >> Date: 2009-02-11 13:00:11 -0800 (Wed, 11 Feb 2009) >> Log Message: >> ----------- >> ffmpeg: remove --enable--nonfree configure option and +no_nonfree variants as nonfree applies only to libamr-nb and libamr-wb which are not provided by MacPorts due to license/patent issues (#16074), default install is now licensed under GPL. Disabling x264 support which is broken in this revision. >> >> Modified Paths: >> -------------- >> trunk/dports/multimedia/ffmpeg/Portfile >> >> Modified: trunk/dports/multimedia/ffmpeg/Portfile >> =================================================================== >> --- trunk/dports/multimedia/ffmpeg/Portfile 2009-02-11 20:52:14 UTC (rev 46740) >> +++ trunk/dports/multimedia/ffmpeg/Portfile 2009-02-11 21:00:11 UTC (rev 46741) >> > > [...] > > >> -variant no_gpl conflicts a52 description {disallow use of GPL code, license will be LGPL if +no_nonfree is selected} { >> +variant no_gpl conflicts a52 description {disallow use of GPL code, license will be LGPL} { >> configure.args-delete --enable-gpl >> configure.args-delete --enable-postproc >> configure.args-delete --enable-swscale >> configure.args-delete --enable-libfaad >> depends_lib-delete port:faad2 >> - configure.args-delete --enable-libx264 >> - depends_build-delete port:x264 >> +# configure.args-delete --enable-libx264 >> +# depends_build-delete port:x264 >> configure.args-delete --enable-libxvid >> depends_lib-delete port:XviD >> } >> > > Either remove these lines or remove the comment, but please do not leave > such commented lines in Portfiles. Later authors might not have any clue > what is meant by that. > > Rainer > > Fixed in r46743. Thanks. From illogical1 at gmail.com Wed Feb 11 16:13:21 2009 From: illogical1 at gmail.com (O) Date: Wed, 11 Feb 2009 19:13:21 -0500 Subject: [MacPorts] #18461: kdelibs3 kdelibs4 conflict In-Reply-To: <063.71e5411cf84fa7e886c9ed5e47bf3b94@macports.org> References: <054.c2d5420b13cc34595e4fb702f37cc6c5@macports.org> <063.71e5411cf84fa7e886c9ed5e47bf3b94@macports.org> Message-ID: <797cc39c0902111613w6f4d921ehb2d761e4b6a247e9@mail.gmail.com> On Wed, Feb 11, 2009 at 3:08 PM, MacPorts wrote: > #18461: kdelibs3 kdelibs4 conflict Is there any way to define this in the portfile? > --------------------------------+------------------------------------------- > Reporter: sergio.roa@? | Owner: illogic-al@? > Type: defect | Status: new > Priority: Normal | Milestone: Port Bugs > Component: ports | Version: 1.7.0 > Keywords: | Port: kdelibs3 kdelibs4 > --------------------------------+------------------------------------------- > Changes (by macsforever2000@?): > > * owner: macports-tickets@? => illogic-al@? > * port: => kdelibs3 kdelibs4 > > > -- > Ticket URL: > MacPorts > Ports system for Mac OS > From ryandesign at macports.org Wed Feb 11 21:32:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 11 Feb 2009 23:32:42 -0600 Subject: [MacPorts] #18461: kdelibs3 kdelibs4 conflict In-Reply-To: <797cc39c0902111613w6f4d921ehb2d761e4b6a247e9@mail.gmail.com> References: <054.c2d5420b13cc34595e4fb702f37cc6c5@macports.org> <063.71e5411cf84fa7e886c9ed5e47bf3b94@macports.org> <797cc39c0902111613w6f4d921ehb2d761e4b6a247e9@mail.gmail.com> Message-ID: <7AC09A95-7367-4B10-97B9-62F53247F8D9@macports.org> On Feb 11, 2009, at 18:13, O wrote: > On Wed, Feb 11, 2009 at 3:08 PM, MacPorts > wrote: >> #18461: kdelibs3 kdelibs4 conflict > Is there any way to define this in the portfile? That a port conflicts with another? No, there's no syntax for that. It's probably fine to leave the port the way it is, and require the user to realize that they must deactivate kdelibs3 before they can install kdelibs4. If you want to be extra nice, you could include a check perhaps in the pre-activate phase for the presence of a file that only kdelibs3 installs, and if it's present, you can return -code error "Please deactivate kdelibs3 before installing kdelibs4" But we don't do that now for any of the -devel ports, for example. From jm at poure.com Thu Feb 12 00:15:02 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Thu, 12 Feb 2009 09:15:02 +0100 Subject: Fetching and compiling two sources in a single Portfile Message-ID: <1234426502.7772.3.camel@debian> Dear Friends, Under GNU/Linux, MLT and MLT++ are two seperate packages. MLT++ providse C++ wrapping for MLT libraries. Maybe this could be provided as one single package in MacPorts. Could you outline examples explaining how to fetch two sources in one single package? Kind regards, Jean-Michel From raimue at macports.org Thu Feb 12 00:24:59 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 12 Feb 2009 09:24:59 +0100 Subject: Fetching and compiling two sources in a single Portfile In-Reply-To: <1234426502.7772.3.camel@debian> References: <1234426502.7772.3.camel@debian> Message-ID: <4993DCDB.3030905@macports.org> Jean-Michel Pour? wrote: > Under GNU/Linux, MLT and MLT++ are two seperate packages. MLT++ providse > C++ wrapping for MLT libraries. If these are distributed as separate packages it might be for a reason. A quick check in other distributions shows they all have this separated. > Maybe this could be provided as one single package in MacPorts. Why? Would there be any advantage over creating two ports? A solution would be to create mlt-c and mlt-cxx and let mlt depend on both. Rainer From billitch at gmail.com Thu Feb 12 00:30:35 2009 From: billitch at gmail.com (Thomas de Grivel) Date: Thu, 12 Feb 2009 09:30:35 +0100 Subject: Ports recommending other ports In-Reply-To: References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> <20090210142240.GW2378@prunille.vinc17.org> Message-ID: <4ec7f0880902120030n2c98ed96o61c506d4658cd7ef@mail.gmail.com> 2009/2/10 Jeremy Lavergne : > Let me reword this, as I meant to question, "What happens when the > recommended variants conflict?" I think these are just recommendations, or suggestions. In the end the user should be the one to decide. But actually I do not want to divert us from the original proposition by Ryan. It just came to my mind that variants could be suggested as well in a very useful way. -- Thomas de Grivel http://b.lowh.net/billitch/ From jm at poure.com Thu Feb 12 01:17:38 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Thu, 12 Feb 2009 10:17:38 +0100 Subject: Fetching and compiling two sources in a single Portfile In-Reply-To: <4993DCDB.3030905@macports.org> References: <1234426502.7772.3.camel@debian> <4993DCDB.3030905@macports.org> Message-ID: <1234430258.10883.1.camel@debian> On Thu, 2009-02-12 at 09:24 +0100, Rainer M?ller wrote: > A solution would be to create mlt-c and mlt-cxx and let mlt depend on > both. In fact, most applications depend on mlt++. mlt++ depends on mlt. So installing Kdenlive would install mlt++ and trigger installation of mlt. Like this is the case under other systems. I am going to create a separate package for mlt++. Kind regards, Jean-Michel From ryandesign at macports.org Thu Feb 12 02:29:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 12 Feb 2009 04:29:41 -0600 Subject: Webserver ports Message-ID: I think our web server ports are a bit of a mess. We have apache, apache2, apache20 and lighttpd, that I know of. They each have their default htdocs and cgi-bin directories in different places: apache: ${prefix}/var/www/data/data (weird), ${prefix}/var/www/cgi-bin apache +apache_layout: ${prefix}/apache/htdocs, ${prefix}/apache/cgi-bin apache2: ${prefix}/apache2/htdocs, ${prefix}/apache2/cgi-bin apache20: ${prefix}/apache20/htdocs, ${prefix}/apache20/cgi-bin lighttpd: /srv/www/htdocs (very weird), no cgi-bin directory defined Or perhaps you want to use Apple's web server: /Library/WebServer/Documents, /Library/WebServer/CGI-Executables So what if you want to write a port that needs to install HTML and/or CGI files that need to be served by a web server but you don't care which one? You have to write variants for each of the above possibilities, then the user has to remember to select the right variant, and if you ever want to try a different web server, you have to reinstall all your web app ports. We have several ports that install into either subdirectories of or directly into ${prefix}/www, such as bugzilla, viewcvs, awstats, gallery, htdig, mediawiki, phpbb, phpmyadmin, squirrelmail and wordpress. I propose: * All web server ports should come with config files set to serve files from the document root ${prefix}/www/htdocs and CGIs from $ {prefix}/www/cgi-bin * There should be a meta port called "webserver" which has variants for each of the four web servers mentioned above, defaulting to the most popular, apache2 * There should be a portgroup called "webapp" which sets up common webapp tasks, like having no configure or build phases, depending on port:webserver, and offering a variant "apple_webserver" to change the install location from a MacPorts web server to the Apple one (what do you think about this variant idea?) * All web app ports can be changed to use the "webapp" portgroup and can remove any variants they have for fiddling with install location or web server dependencies Also: * The "webserver" port can install a pretty MacPorts default index.html page, like the default "It works!" page Apache provides, but tailored to MacPorts From brad at pixilla.com Thu Feb 12 07:29:56 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 12 Feb 2009 07:29:56 -0800 Subject: Webserver ports In-Reply-To: References: Message-ID: On Feb 12, 2009, at 2:29 AM, Ryan Schmidt wrote: > I think our web server ports are a bit of a mess. We have apache, > apache2, apache20 and lighttpd, that I know of. They each have their > default htdocs and cgi-bin directories in different places: > > apache: ${prefix}/var/www/data/data (weird), ${prefix}/var/www/cgi-bin > apache +apache_layout: ${prefix}/apache/htdocs, ${prefix}/apache/cgi- > bin > apache2: ${prefix}/apache2/htdocs, ${prefix}/apache2/cgi-bin > apache20: ${prefix}/apache20/htdocs, ${prefix}/apache20/cgi-bin > lighttpd: /srv/www/htdocs (very weird), no cgi-bin directory defined > > Or perhaps you want to use Apple's web server: > /Library/WebServer/Documents, /Library/WebServer/CGI-Executables > > So what if you want to write a port that needs to install HTML and/ > or CGI files that need to be served by a web server but you don't > care which one? You have to write variants for each of the above > possibilities, then the user has to remember to select the right > variant, and if you ever want to try a different web server, you > have to reinstall all your web app ports. > > We have several ports that install into either subdirectories of or > directly into ${prefix}/www, such as bugzilla, viewcvs, awstats, > gallery, htdig, mediawiki, phpbb, phpmyadmin, squirrelmail and > wordpress. > > I propose: > > * All web server ports should come with config files set to serve > files from the document root ${prefix}/www/htdocs and CGIs from $ > {prefix}/www/cgi-bin > * There should be a meta port called "webserver" which has variants > for each of the four web servers mentioned above, defaulting to the > most popular, apache2 > * There should be a portgroup called "webapp" which sets up common > webapp tasks, like having no configure or build phases, depending on > port:webserver, and offering a variant "apple_webserver" to change > the install location from a MacPorts web server to the Apple one > (what do you think about this variant idea?) > * All web app ports can be changed to use the "webapp" portgroup and > can remove any variants they have for fiddling with install location > or web server dependencies > > Also: > > * The "webserver" port can install a pretty MacPorts default > index.html page, like the default "It works!" page Apache provides, > but tailored to MacPorts I thought /opt/local/apache2 was strange compared to where the majority of other ports park stuff. After dependancy management I think the big advantages of an excellent software manager (port) is the logical and consistent layout and nice config files to get you started. I could use some guidance regarding logging. /var/log is outside prefix but I don't see Apple removing it. The postfix port appears to log to /var/log/mail unless I somehow mucked the install which is possible. Though /var/log is outside /opt/local is this an acceptable target for logs? Oh, and what if changes need to be made to /etc/sysctl.conf? I don't know that macosx 10.5 reads /etc/sysctl.conf anymore but the idea is still there. Oh, after looking I guess it does. What if you need to change kern.maxfilesperproc? It wasn't my intention but it looks like I strayed from the subject:) //Brad From brad at pixilla.com Thu Feb 12 07:42:09 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 12 Feb 2009 07:42:09 -0800 Subject: Ports recommending other ports In-Reply-To: <4ec7f0880902120030n2c98ed96o61c506d4658cd7ef@mail.gmail.com> References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> <20090210142240.GW2378@prunille.vinc17.org> <4ec7f0880902120030n2c98ed96o61c506d4658cd7ef@mail.gmail.com> Message-ID: On Feb 12, 2009, at 12:30 AM, Thomas de Grivel wrote: > 2009/2/10 Jeremy Lavergne : >> Let me reword this, as I meant to question, "What happens when the >> recommended variants conflict?" > > I think these are just recommendations, or suggestions. In the end the > user should be the one to decide. But actually I do not want to divert > us from the original proposition by Ryan. It just came to my mind that > variants could be suggested as well in a very useful way. I really like freebsd ports "make config" or "make config install". Could be "port config install". Simple and effective. //Brad From blair at orcaware.com Thu Feb 12 08:19:07 2009 From: blair at orcaware.com (Blair Zajac) Date: Thu, 12 Feb 2009 08:19:07 -0800 Subject: Webserver ports In-Reply-To: References: Message-ID: On Feb 12, 2009, at 2:29 AM, Ryan Schmidt wrote: > I think our web server ports are a bit of a mess. We have apache, > apache2, apache20 and lighttpd, that I know of. They each have their > default htdocs and cgi-bin directories in different places: One should ignore the apache20 port unless one explicitly needs that version. We needed it to support PPC Macs with Zend's binary Zend Optimizer module. Unless one has a binary third-party module that requires Apache 2.0.x, people should really use the apache2 port. Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From ryandesign at macports.org Thu Feb 12 12:38:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 12 Feb 2009 14:38:49 -0600 Subject: Ports recommending other ports In-Reply-To: References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> <20090210142240.GW2378@prunille.vinc17.org> <4ec7f0880902120030n2c98ed96o61c506d4658cd7ef@mail.gmail.com> Message-ID: On Feb 12, 2009, at 09:42, Bradley Giesbrecht wrote: > I really like freebsd ports "make config" or "make config install". > > Could be "port config install". > > Simple and effective. I'm not familiar with FreeBSD ports... what does "make config" or "make config install" do? From ryandesign at macports.org Thu Feb 12 12:40:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 12 Feb 2009 14:40:38 -0600 Subject: Fetching and compiling two sources in a single Portfile In-Reply-To: <1234430258.10883.1.camel@debian> References: <1234426502.7772.3.camel@debian> <4993DCDB.3030905@macports.org> <1234430258.10883.1.camel@debian> Message-ID: <0D781B96-D156-4EDF-8814-A4F83778B3E5@macports.org> On Feb 12, 2009, at 03:17, Jean-Michel Pour? wrote: > On Thu, 2009-02-12 at 09:24 +0100, Rainer M?ller wrote: >> A solution would be to create mlt-c and mlt-cxx and let mlt depend on >> both. > > In fact, most applications depend on mlt++. mlt++ depends on mlt. So > installing Kdenlive would install mlt++ and trigger installation of > mlt. > Like this is the case under other systems. > > I am going to create a separate package for mlt++. A port can easily fetch multiple distfiles if necessary, however MacPorts only runs each phase (configure, build, destroot) once, and making it issue multiple configure and make commands in multiple directories basically requires reimplementing those phases yourself in the portfile, which is a lot of work to do correctly, taking into account all the features we have in MacPorts for nice builds and parallel builds and universal binaries and such. Easier to just make them two separate ports as you said. From perry at macports.org Thu Feb 12 12:42:43 2009 From: perry at macports.org (Perry Lee) Date: Thu, 12 Feb 2009 12:42:43 -0800 Subject: Ports recommending other ports In-Reply-To: References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> <20090210142240.GW2378@prunille.vinc17.org> <4ec7f0880902120030n2c98ed96o61c506d4658cd7ef@mail.gmail.com> Message-ID: <2726BACE-C468-465C-BCF9-B65227ADAB50@macports.org> On Feb 12, 2009, at 12:38 PM, Ryan Schmidt wrote: > I'm not familiar with FreeBSD ports... what does "make config" or > "make config install" do? `make config` displays a menu from which you can select build options (sorta like MacPorts' variants). `make config install` shows the menu then starts the installation right after. From ryandesign at macports.org Thu Feb 12 13:05:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 12 Feb 2009 15:05:05 -0600 Subject: [46763] trunk/dports/kde In-Reply-To: <20090212125551.1A352F27897@beta.macosforge.org> References: <20090212125551.1A352F27897@beta.macosforge.org> Message-ID: <78CC1EB2-A4A2-499B-B843-812FF9E86C1F@macports.org> On Feb 12, 2009, at 06:55, illogic-al at macports.org wrote: > Revision: 46763 > http://trac.macports.org/changeset/46763 > Author: illogic-al at macports.org > Date: 2009-02-12 04:55:50 -0800 (Thu, 12 Feb 2009) > Log Message: > ----------- > Re-add new port choqok. The "alias" part is actually required. >_< The "alias" part? From ryandesign at macports.org Thu Feb 12 13:05:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 12 Feb 2009 15:05:38 -0600 Subject: [46759] trunk/dports/databases/postgresql7/Portfile In-Reply-To: <20090212120653.B508AF2744B@beta.macosforge.org> References: <20090212120653.B508AF2744B@beta.macosforge.org> Message-ID: On Feb 12, 2009, at 06:06, mww at macports.org wrote: > Revision: 46759 > http://trac.macports.org/changeset/46759 > Author: mww at macports.org > Date: 2009-02-12 04:06:51 -0800 (Thu, 12 Feb 2009) > Log Message: > ----------- > version 7.4.24, add warning about Mac OS X Intel incompatibility to > long_description What would you think about adding a ui_warn in the pre-fetch phase to print this info? Users could easily miss it in the long description, or they might not even read the info, especially if postgresql7 is installed as a dependency. I think this should do it: pre-fetch { if {"darwin" == ${os.platform} && "little" != ${os.endian}} { ui_warn "${name} does not work well on Mac OS X Intel. Try postgresql83 instead." } } > Modified Paths: > -------------- > trunk/dports/databases/postgresql7/Portfile > > Modified: trunk/dports/databases/postgresql7/Portfile > =================================================================== > --- trunk/dports/databases/postgresql7/Portfile 2009-02-12 11:52:47 > UTC (rev 46758) > +++ trunk/dports/databases/postgresql7/Portfile 2009-02-12 12:06:51 > UTC (rev 46759) > @@ -3,7 +3,7 @@ > PortSystem 1.0 > > name postgresql7 > -version 7.4.21 > +version 7.4.24 > categories databases > platforms darwin > maintainers mww jwa > @@ -12,14 +12,16 @@ > It supports almost all SQL constructs, including transactions, \ > subselects, and user-defined types and functions. Write-ahead \ > logging means increased performance while retaining data \ > - integrity. > + integrity. \ > + This version does not work on Mac OS X Intel! From joshcp at gmail.com Thu Feb 12 14:16:23 2009 From: joshcp at gmail.com (Josh Price) Date: Fri, 13 Feb 2009 09:16:23 +1100 Subject: JRuby 1.1.6 port update forgotten? Message-ID: What's the best way to get this 2 month old ticket closed? https://trac.macports.org/ticket/17699 Thanks in advance, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkh at apple.com Thu Feb 12 14:44:01 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Thu, 12 Feb 2009 14:44:01 -0800 Subject: Ports recommending other ports In-Reply-To: <2726BACE-C468-465C-BCF9-B65227ADAB50@macports.org> References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> <20090210142240.GW2378@prunille.vinc17.org> <4ec7f0880902120030n2c98ed96o61c506d4658cd7ef@mail.gmail.com> <2726BACE-C468-465C-BCF9-B65227ADAB50@macports.org> Message-ID: <4B51EDCB-3949-4654-A431-F42EBBD4E56A@apple.com> On Feb 12, 2009, at 12:42 PM, Perry Lee wrote: > `make config` displays a menu from which you can select build > options (sorta like MacPorts' variants). `make config install` > shows the menu then starts the installation right after. "config" is already pretty close to "configure", which MacPorts already exposes as a discrete step (and I don't believe FreeBSD ports does) - perhaps this could be called "customize" or "custom"? Then you could say things like: "port custom build" or "port custom install" and get a customization screen of some sort which lets you select from the available variants, also showing you (through checked items in the menu) which variants were already on by default. That would be pretty cool, and fairly easy to whip up by adding a curses- using extension to the ui_* procedures (ui_menu perhaps) and the requisite glue to support the new "custom" target. Sounds like a great intern project. Got any? :-) - Jordan From brad at pixilla.com Thu Feb 12 18:58:58 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 12 Feb 2009 18:58:58 -0800 Subject: Ports recommending other ports In-Reply-To: <4B51EDCB-3949-4654-A431-F42EBBD4E56A@apple.com> References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> <20090210142240.GW2378@prunille.vinc17.org> <4ec7f0880902120030n2c98ed96o61c506d4658cd7ef@mail.gmail.com> <2726BACE-C468-465C-BCF9-B65227ADAB50@macports.org> <4B51EDCB-3949-4654-A431-F42EBBD4E56A@apple.com> Message-ID: <7EA9A4AF-175A-44F4-85F7-E6786E34B37A@pixilla.com> On Feb 12, 2009, at 4:24 PM, Jordan K. Hubbard wrote: > > On Feb 12, 2009, at 3:00 PM, Bradley Giesbrecht wrote: > >> >> On Feb 12, 2009, at 2:44 PM, Jordan K. Hubbard wrote: >> >>> >>> On Feb 12, 2009, at 12:42 PM, Perry Lee wrote: >>> >>>> `make config` displays a menu from which you can select build >>>> options (sorta like MacPorts' variants). `make config install` >>>> shows the menu then starts the installation right after. >>> >>> "config" is already pretty close to "configure", which MacPorts >>> already exposes as a discrete step (and I don't believe FreeBSD >>> ports does) - perhaps this could be called "customize" or >>> "custom"? Then you could say things like: "port custom build" or >>> "port custom install" and get a customization screen of some sort >>> which lets you select from the available variants, also showing >>> you (through checked items in the menu) which variants were >>> already on by default. That would be pretty cool, and fairly easy >>> to whip up by adding a curses-using extension to the ui_* >>> procedures (ui_menu perhaps) and the requisite glue to support the >>> new "custom" target. >>> >>> Sounds like a great intern project. Got any? :-) >> >> And you could preclude selecting incompatible variants by turning >> them off, making them un-selectable. > > Yep! > >> You might also have the variant "description" if any and the >> proposed "recommendations" message. > > That would be the description line of the menu item, e.g. > > [ ] mysql Enable MySQL support for the connector function. > [ ] universal Build Universal Binaries > [X] SSL Support SSL connections Thanks for the ascii. Let me borrow it. variants [ ] mysql Enable MySQL support for the connector function. [ ] universal Build Universal Binaries [X] SSL Support SSL connections Other port that work well with [ ] HTML interface to manage But now, if you do a build on should you use "menu config", as I think it's called on gentoo, after the first port run, on the checked "Other ports that work well with "? And possibly descend into some ongoing hell? Maybe a: [ ] Continue to build selected ports [ ] I'm done for now dialog before proceeding to additional port installs. I don't know how macports handles upgrades with respect to etc file changes but gentoo has a nice "etc-update" program that allows you replace, merge or ignore etc config files. This CAN be important. But gentoo portage is also managing the "world" and thankfully we have Apple taking care of basics. I mean, merging etc files remotely can be hair raising. Especially when gentoo will upgrade everyFREAKINGthing if you don't tell it not to and there are etc updates for like 30 files from fstab on. Who wants to recompile gcc for every minor update? And have it go wrong? Remotely? That said, I love gentoo but moved to freebsd so I would have a "base" that wasn't so fragile. But gentoo has many nice things about it. Everything I will ever say will seem like child's play to some but I frequently hear on this list things like "I've never used FreeBSD Ports or I'm unfamiliar with Gentoo ebuild" so I'm just sharing what little I know. I love Macs and I love macports! Sad to say I will be retiring my last Beige G3 running macos9 very soon. Good news is, it's being replaced with Leopard and MacPorts on a G5. Sad Yay! Boy did I get off target. //Brad From ryandesign at macports.org Thu Feb 12 19:32:58 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 12 Feb 2009 21:32:58 -0600 Subject: port info long description not formatted correctly in trunk Message-ID: <702DF6D9-FC5E-4355-B2CE-07795A7FA4CE@macports.org> We have a regression from 1.7.0 on trunk when the ${description} variable is included in the long_description. Now, it's surrounded by curly braces, but this was not the case with 1.7.0. I filed a bug here: http://trac.macports.org/ticket/18482 Perhaps someone knows how to fix this. From ryandesign at macports.org Thu Feb 12 20:54:11 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 12 Feb 2009 22:54:11 -0600 Subject: Webserver ports In-Reply-To: References: Message-ID: <9F01DF33-930E-47A1-A3E7-0EBDDC806BC1@macports.org> On Feb 12, 2009, at 09:29, Bradley Giesbrecht wrote: > I thought /opt/local/apache2 was strange compared to where the > majority of other ports park stuff. > > After dependancy management I think the big advantages of an > excellent software manager (port) is the logical and consistent > layout and nice config files to get you started. We could consider totally rearranging the layout of apache2, apache20 and apache to better fit into the standard MacPorts directories. However, at the moment I'm just concerned with making all the web server ports use the same document root and cgi directory by default, so that any port that requires a web server will know where to put its files. That's the issue I'm currently facing as I make a port for webdot. http://trac.macports.org/ticket/18458 > I could use some guidance regarding logging. > > /var/log is outside prefix but I don't see Apple removing it. The > postfix port appears to log to /var/log/mail unless I somehow > mucked the install which is possible. > > Though /var/log is outside /opt/local is this an acceptable target > for logs? Using ${prefix}/var/log is recommended. > Oh, and what if changes need to be made to /etc/sysctl.conf? > I don't know that macosx 10.5 reads /etc/sysctl.conf anymore but > the idea is still there. > Oh, after looking I guess it does. > > What if you need to change kern.maxfilesperproc? The ports postgresql8{0,1,2,3}-server output this message to the user: To tweak your DBMS, consider increasing kern.sysv.shmmax\ by adding an increased kern.sysv.shmmax .. to /etc/sysctl.conf I don't see any other references to sysctl.conf in any ports. I'm not really familiar with these kernel options and haven't had occasion to need to change them myself so hopefully there will not be many ports that need to recommend it. > It wasn't my intention but it looks like I strayed from the subject:) It happens :) From ryandesign at macports.org Thu Feb 12 21:01:07 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 12 Feb 2009 23:01:07 -0600 Subject: Ports recommending other ports In-Reply-To: <7EA9A4AF-175A-44F4-85F7-E6786E34B37A@pixilla.com> References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> <20090210142240.GW2378@prunille.vinc17.org> <4ec7f0880902120030n2c98ed96o61c506d4658cd7ef@mail.gmail.com> <2726BACE-C468-465C-BCF9-B65227ADAB50@macports.org> <4B51EDCB-3949-4654-A431-F42EBBD4E56A@apple.com> <7EA9A4AF-175A-44F4-85F7-E6786E34B37A@pixilla.com> Message-ID: <17DE49D5-6F64-42A3-8E70-7CD47ACBBF87@macports.org> On Feb 12, 2009, at 20:58, Bradley Giesbrecht wrote: > Thanks for the ascii. Let me borrow it. > > variants > [ ] mysql Enable MySQL support for the connector function. > [ ] universal Build Universal Binaries > [X] SSL Support SSL connections > Other port that work well with > [ ] HTML interface to manage > > > But now, if you do a build on should you use > "menu config", as I think it's called on gentoo, after the first > port run, on the checked "Other ports that work well with port>"? > > And possibly descend into some ongoing hell? > > Maybe a: > [ ] Continue to build selected ports > [ ] I'm done for now > > dialog before proceeding to additional port installs. Before we get into too many specifics about how this interactive ncurses interface would look, I'd be more interested in getting some more non-interactive commands added to MacPorts that would provide the information on which such an interactive interface would be based. To start with, in order to properly render the variants, we need MacPorts to be able to tell us not only what variants are available, but also what variants conflict with what other variants; what variants the port wants as defaults; and what variants the user wants as defaults. Aaand looking at the ChangeLog, it looks like that's already in 1.8.0, except for the default variants bit. So that's helpful. Do I have to parse the output of "port variants" to get it or is there more of an API that can be used? > I don't know how macports handles upgrades with respect to etc file > changes but gentoo has a nice "etc-update" program that allows you > replace, merge or ignore etc config files. This CAN be important. > But gentoo portage is also managing the "world" and thankfully we > have Apple taking care of basics. > > I mean, merging etc files remotely can be hair raising. Especially > when gentoo will upgrade everyFREAKINGthing if you don't tell it > not to and there are etc updates for like 30 files from fstab on. > Who wants to recompile gcc for every minor update? > And have it go wrong? > Remotely? MacPorts does nothing to help the user upgrade their config files in / etc. If a port is nice, it installs template config files the user can copy. If not, it installs the config file with its real name so that any port upgrade will wipe out the user's changes... > That said, I love gentoo but moved to freebsd so I would have a > "base" that wasn't so fragile. But gentoo has many nice things > about it. > > Everything I will ever say will seem like child's play to some but > I frequently hear on this list things like "I've never used FreeBSD > Ports or I'm unfamiliar with Gentoo ebuild" so I'm just sharing > what little I know. I appreciate your verbosity. :) From jmr at macports.org Thu Feb 12 21:13:21 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 13 Feb 2009 16:13:21 +1100 Subject: Ports recommending other ports In-Reply-To: <17DE49D5-6F64-42A3-8E70-7CD47ACBBF87@macports.org> References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> <20090210142240.GW2378@prunille.vinc17.org> <4ec7f0880902120030n2c98ed96o61c506d4658cd7ef@mail.gmail.com> <2726BACE-C468-465C-BCF9-B65227ADAB50@macports.org> <4B51EDCB-3949-4654-A431-F42EBBD4E56A@apple.com> <7EA9A4AF-175A-44F4-85F7-E6786E34B37A@pixilla.com> <17DE49D5-6F64-42A3-8E70-7CD47ACBBF87@macports.org> Message-ID: <49950171.9050702@macports.org> Ryan Schmidt wrote: > Before we get into too many specifics about how this interactive ncurses > interface would look, I'd be more interested in getting some more > non-interactive commands added to MacPorts that would provide the > information on which such an interactive interface would be based. To > start with, in order to properly render the variants, we need MacPorts > to be able to tell us not only what variants are available, but also > what variants conflict with what other variants; what variants the port > wants as defaults; and what variants the user wants as defaults. > > Aaand looking at the ChangeLog, it looks like that's already in 1.8.0, > except for the default variants bit. So that's helpful. Do I have to > parse the output of "port variants" to get it or is there more of an API > that can be used? What about default variants is missing? The variant metadata is available as $PortInfo(vinfo). - Josh From ryandesign at macports.org Thu Feb 12 21:23:34 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 12 Feb 2009 23:23:34 -0600 Subject: Ports recommending other ports In-Reply-To: <49950171.9050702@macports.org> References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> <20090210142240.GW2378@prunille.vinc17.org> <4ec7f0880902120030n2c98ed96o61c506d4658cd7ef@mail.gmail.com> <2726BACE-C468-465C-BCF9-B65227ADAB50@macports.org> <4B51EDCB-3949-4654-A431-F42EBBD4E56A@apple.com> <7EA9A4AF-175A-44F4-85F7-E6786E34B37A@pixilla.com> <17DE49D5-6F64-42A3-8E70-7CD47ACBBF87@macports.org> <49950171.9050702@macports.org> Message-ID: On Feb 12, 2009, at 23:13, Joshua Root wrote: > Ryan Schmidt wrote: >> Before we get into too many specifics about how this interactive >> ncurses >> interface would look, I'd be more interested in getting some more >> non-interactive commands added to MacPorts that would provide the >> information on which such an interactive interface would be based. To >> start with, in order to properly render the variants, we need >> MacPorts >> to be able to tell us not only what variants are available, but also >> what variants conflict with what other variants; what variants the >> port >> wants as defaults; and what variants the user wants as defaults. >> >> Aaand looking at the ChangeLog, it looks like that's already in >> 1.8.0, >> except for the default variants bit. So that's helpful. Do I have to >> parse the output of "port variants" to get it or is there more of >> an API >> that can be used? > > What about default variants is missing? The variant metadata is > available as $PortInfo(vinfo). I meant, can I access this information from a language that is not tcl? From brad at pixilla.com Thu Feb 12 22:54:12 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 12 Feb 2009 22:54:12 -0800 Subject: Webserver ports In-Reply-To: <9F01DF33-930E-47A1-A3E7-0EBDDC806BC1@macports.org> References: <9F01DF33-930E-47A1-A3E7-0EBDDC806BC1@macports.org> Message-ID: <96450969-CDB3-4B70-BB13-FF90BADAC6AF@pixilla.com> On Feb 12, 2009, at 8:54 PM, Ryan Schmidt wrote: > On Feb 12, 2009, at 09:29, Bradley Giesbrecht wrote: > >> I thought /opt/local/apache2 was strange compared to where the >> majority of other ports park stuff. >> >> After dependancy management I think the big advantages of an >> excellent software manager (port) is the logical and consistent >> layout and nice config files to get you started. > > We could consider totally rearranging the layout of apache2, > apache20 and apache to better fit into the standard MacPorts > directories. However, at the moment I'm just concerned with making > all the web server ports use the same document root and cgi > directory by default, so that any port that requires a web server > will know where to put its files. That's the issue I'm currently > facing as I make a port for webdot. > > http://trac.macports.org/ticket/18458 That's pretty damn cool! Have you used ming? >> I could use some guidance regarding logging. >> >> /var/log is outside prefix but I don't see Apple removing it. The >> postfix port appears to log to /var/log/mail unless I somehow >> mucked the install which is possible. >> >> Though /var/log is outside /opt/local is this an acceptable target >> for logs? > > Using ${prefix}/var/log is recommended. Thanks, I'll use that then. >> Oh, and what if changes need to be made to /etc/sysctl.conf? >> I don't know that macosx 10.5 reads /etc/sysctl.conf anymore but >> the idea is still there. >> Oh, after looking I guess it does. >> >> What if you need to change kern.maxfilesperproc? > > The ports postgresql8{0,1,2,3}-server output this message to the user: > > To tweak your DBMS, consider increasing kern.sysv.shmmax\ > by adding an increased kern.sysv.shmmax .. to /etc/sysctl.conf > > I don't see any other references to sysctl.conf in any ports. I'm > not really familiar with these kernel options and haven't had > occasion to need to change them myself so hopefully there will not > be many ports that need to recommend it. Oracle and Postgres both have these types of recommendations. Unfortunately mysql didn't benefit from much tweaking. Mysql is really built for Linux threads. It suffers on bsd's. Probably Solaris and Windows two but I don't have much experience to go on. Dovecot requires knocking down process or bumping up file descriptors. I think a message should be added to the dovecot port explaining how to do it. I've just realize no one has correct spelling or grammar on this list. How refreshing:) Oh, and no "top post" nazis either. Hell, I can read backwards if I have to:) How would I do a search for sysctl using port? I have not figured out the "port echo" usage yet but would love to. //Brad From ryandesign at macports.org Thu Feb 12 23:06:26 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 13 Feb 2009 01:06:26 -0600 Subject: Webserver ports In-Reply-To: <96450969-CDB3-4B70-BB13-FF90BADAC6AF@pixilla.com> References: <9F01DF33-930E-47A1-A3E7-0EBDDC806BC1@macports.org> <96450969-CDB3-4B70-BB13-FF90BADAC6AF@pixilla.com> Message-ID: On Feb 13, 2009, at 00:54, Bradley Giesbrecht wrote: > On Feb 12, 2009, at 8:54 PM, Ryan Schmidt wrote: > >> We could consider totally rearranging the layout of apache2, >> apache20 and apache to better fit into the standard MacPorts >> directories. However, at the moment I'm just concerned with making >> all the web server ports use the same document root and cgi >> directory by default, so that any port that requires a web server >> will know where to put its files. That's the issue I'm currently >> facing as I make a port for webdot. >> >> http://trac.macports.org/ticket/18458 > > That's pretty damn cool! > Have you used ming? I have not been able to use ming with Graphviz, and I haven't tried using ming with anything else. Someone else added the ming variant to the graphviz port. I tried to use it before, but no matter what I did, Graphviz would say it did not support the output format. > Dovecot requires knocking down process or bumping up file descriptors. > I think a message should be added to the dovecot port explaining > how to do it. Could you file a ticket for that please and assign it to dovecot's maintainer? > I've just realize no one has correct spelling or grammar on this > list. How refreshing:) I try! > Oh, and no "top post" nazis either. Hell, I can read backwards if I > have to:) > > How would I do a search for sysctl using port? > I have not figured out the "port echo" usage yet but would love to. I searched for "sysctl" in all Portfiles like this: port cddir && grep sysctl */*/Portfile "port cddir" is my own shell function which is in my ~/.bashrc and which looks something like this: port() { case "$1" in cddir) if [ -z "$2" ]; then cd $(command port dir MacPorts)/../.. else cd $(command port dir "$2") fi ;; *) command port "$@" ;; esac } Then you can say "port cddir graphviz" to change to the graphviz port's directory, or just "port cddir" to change to the directory two directories up from that. From brad at pixilla.com Thu Feb 12 23:10:00 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 12 Feb 2009 23:10:00 -0800 Subject: Ports recommending other ports In-Reply-To: <17DE49D5-6F64-42A3-8E70-7CD47ACBBF87@macports.org> References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> <20090210142240.GW2378@prunille.vinc17.org> <4ec7f0880902120030n2c98ed96o61c506d4658cd7ef@mail.gmail.com> <2726BACE-C468-465C-BCF9-B65227ADAB50@macports.org> <4B51EDCB-3949-4654-A431-F42EBBD4E56A@apple.com> <7EA9A4AF-175A-44F4-85F7-E6786E34B37A@pixilla.com> <17DE49D5-6F64-42A3-8E70-7CD47ACBBF87@macports.org> Message-ID: >> I don't know how macports handles upgrades with respect to etc file >> changes but gentoo has a nice "etc-update" program that allows you >> replace, merge or ignore etc config files. This CAN be important. >> But gentoo portage is also managing the "world" and thankfully we >> have Apple taking care of basics. >> >> I mean, merging etc files remotely can be hair raising. Especially >> when gentoo will upgrade everyFREAKINGthing if you don't tell it >> not to and there are etc updates for like 30 files from fstab on. >> Who wants to recompile gcc for every minor update? >> And have it go wrong? >> Remotely? > > MacPorts does nothing to help the user upgrade their config files > in /etc. If a port is nice, it installs template config files the > user can copy. If not, it installs the config file with its real > name so that any port upgrade will wipe out the user's changes... Ouch. And did I mention OUCH. Damn, how about moving same file names in ${prefix}/etc out of the way with a timestamp appended? Something! That's really a possibility? Maybe it's possible and just doesn't happen. Man, that scares me. I wonder how hard it would be to use something like rsnapshot (never used it, just did port search snapshot) on etc before port install. That would be an option I'd probably turn on. Guess I could just wing my own. Or just pray more. //Brad From ryandesign at macports.org Thu Feb 12 23:23:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 13 Feb 2009 01:23:28 -0600 Subject: Ports recommending other ports In-Reply-To: References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> <20090210142240.GW2378@prunille.vinc17.org> <4ec7f0880902120030n2c98ed96o61c506d4658cd7ef@mail.gmail.com> <2726BACE-C468-465C-BCF9-B65227ADAB50@macports.org> <4B51EDCB-3949-4654-A431-F42EBBD4E56A@apple.com> <7EA9A4AF-175A-44F4-85F7-E6786E34B37A@pixilla.com> <17DE49D5-6F64-42A3-8E70-7CD47ACBBF87@macports.org> Message-ID: On Feb 13, 2009, at 01:10, Bradley Giesbrecht wrote: >>> I don't know how macports handles upgrades with respect to etc >>> file changes but gentoo has a nice "etc-update" program that >>> allows you replace, merge or ignore etc config files. This CAN be >>> important. But gentoo portage is also managing the "world" and >>> thankfully we have Apple taking care of basics. >>> >>> I mean, merging etc files remotely can be hair raising. >>> Especially when gentoo will upgrade everyFREAKINGthing if you >>> don't tell it not to and there are etc updates for like 30 files >>> from fstab on. >>> Who wants to recompile gcc for every minor update? >>> And have it go wrong? >>> Remotely? >> >> MacPorts does nothing to help the user upgrade their config files >> in /etc. If a port is nice, it installs template config files the >> user can copy. If not, it installs the config file with its real >> name so that any port upgrade will wipe out the user's changes... > > Ouch. And did I mention OUCH. > > Damn, how about moving same file names in ${prefix}/etc out of the > way with a timestamp appended? > > Something! > > That's really a possibility? > > Maybe it's possible and just doesn't happen. Man, that scares me. If you find a port that installs a config file that the user is expected to edit with the actual name the program expects to find, that is a bug, and you should file a ticket for that port in the issue tracker so that the issue can be corrected. From illogical1 at gmail.com Thu Feb 12 23:45:09 2009 From: illogical1 at gmail.com (O) Date: Fri, 13 Feb 2009 02:45:09 -0500 Subject: [46763] trunk/dports/kde In-Reply-To: <78CC1EB2-A4A2-499B-B843-812FF9E86C1F@macports.org> References: <20090212125551.1A352F27897@beta.macosforge.org> <78CC1EB2-A4A2-499B-B843-812FF9E86C1F@macports.org> Message-ID: <797cc39c0902122345o3ab7b782jf25ec45ddf32ac95@mail.gmail.com> On Thu, Feb 12, 2009 at 4:05 PM, Ryan Schmidt wrote: > > On Feb 12, 2009, at 06:55, illogic-al at macports.org wrote: > >> Revision: 46763 >> http://trac.macports.org/changeset/46763 >> Author: illogic-al at macports.org >> Date: 2009-02-12 04:55:50 -0800 (Thu, 12 Feb 2009) >> Log Message: >> ----------- >> Re-add new port choqok. The "alias" part is actually required. >_< > > The "alias" part? in the client first-run configuration. From brad at pixilla.com Fri Feb 13 00:03:04 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 13 Feb 2009 00:03:04 -0800 Subject: Ports recommending other ports In-Reply-To: References: <4ec7f0880902081924v489d5c0fp2be0100c6b1c72ec@mail.gmail.com> <47E0A78E-07B9-44FA-B3FB-2A5AA0DDE3AD@macports.org> <4ec7f0880902100258w1e335fcr44fd9f08abacd2a8@mail.gmail.com> <6D4399C4-5AC1-44EC-A608-25F99F8EBCF2@lavergne.gotdns.org> <20090210142240.GW2378@prunille.vinc17.org> <4ec7f0880902120030n2c98ed96o61c506d4658cd7ef@mail.gmail.com> <2726BACE-C468-465C-BCF9-B65227ADAB50@macports.org> <4B51EDCB-3949-4654-A431-F42EBBD4E56A@apple.com> <7EA9A4AF-175A-44F4-85F7-E6786E34B37A@pixilla.com> <17DE49D5-6F64-42A3-8E70-7CD47ACBBF87@macports.org> Message-ID: <85B71AE0-3003-4701-A904-4D2DC6FBDA2D@pixilla.com> On Feb 12, 2009, at 11:23 PM, Ryan Schmidt wrote: > > On Feb 13, 2009, at 01:10, Bradley Giesbrecht wrote: > >>>> I don't know how macports handles upgrades with respect to etc >>>> file changes but gentoo has a nice "etc-update" program that >>>> allows you replace, merge or ignore etc config files. This CAN be >>>> important. But gentoo portage is also managing the "world" and >>>> thankfully we have Apple taking care of basics. >>>> >>>> I mean, merging etc files remotely can be hair raising. >>>> Especially when gentoo will upgrade everyFREAKINGthing if you >>>> don't tell it not to and there are etc updates for like 30 files >>>> from fstab on. >>>> Who wants to recompile gcc for every minor update? >>>> And have it go wrong? >>>> Remotely? >>> >>> MacPorts does nothing to help the user upgrade their config files >>> in /etc. If a port is nice, it installs template config files the >>> user can copy. If not, it installs the config file with its real >>> name so that any port upgrade will wipe out the user's changes... >> >> Ouch. And did I mention OUCH. >> >> Damn, how about moving same file names in ${prefix}/etc out of the >> way with a timestamp appended? >> >> Something! >> >> That's really a possibility? >> >> Maybe it's possible and just doesn't happen. Man, that scares me. > > If you find a port that installs a config file that the user is > expected to edit with the actual name the program expects to find, > that is a bug, and you should file a ticket for that port in the > issue tracker so that the issue can be corrected. If that ever happens I hope I'm not the one reporting it:) It's not like etc changes all the time. I just need to make sure I take some snapshots every so often. Thanks for sharing your insights Ryan. //Brad From blb at macports.org Fri Feb 13 01:44:41 2009 From: blb at macports.org (Bryan Blackburn) Date: Fri, 13 Feb 2009 02:44:41 -0700 Subject: Whitespace and config values Message-ID: <20090213094441.GI1100@ninagal.withay.com> Does anyone see any issue with the attached patch? It seems that parsing macports.conf will leave trailing whitespace on values, hence some things won't match "yes" because they are "yes " (see ticket #18460). I ask in case someone is aware of any possible reason to keep trailing whitespace within values... Bryan -------------- next part -------------- Index: src/macports1.0/macports.tcl =================================================================== --- src/macports1.0/macports.tcl (revision 46782) +++ src/macports1.0/macports.tcl (working copy) @@ -380,7 +380,7 @@ while {[gets $fd line] >= 0} { if {[regexp {^(\w+)([ \t]+(.*))?$} $line match option ignore val] == 1} { if {[lsearch $bootstrap_options $option] >= 0} { - set macports::$option $val + set macports::$option [string trim $val] global macports::$option } } From weakish at gmail.com Fri Feb 13 09:17:15 2009 From: weakish at gmail.com (weakish jiang) Date: Sat, 14 Feb 2009 01:17:15 +0800 Subject: request review/commit of the port update: py25-gdata Message-ID: <700384770902130917k716b6083o946467003f21596e@mail.gmail.com> Reason: maintainer timeout Ticket #18422 http://trac.macports.org/ticket/18422 Patch http://trac.macports.org/attachment/ticket/18422/Portfile.patch From markd at macports.org Fri Feb 13 12:16:50 2009 From: markd at macports.org (markd at macports.org) Date: Fri, 13 Feb 2009 12:16:50 -0800 Subject: Macros? ... was patching in general Message-ID: >> Well I've never used Portage, but I have looked at their portfiles >(emerge >> or whatever they are called) sometimes in the past to check out how >their >> port authors did a given port, or to see if they had useful patches. > All >> I can say is that I remember they have 'dodoc' and 'dobin' (seems like >> they could've used better names), which I think installs the given files >> into the standard doc and bin locations. That's really all I know about >> it. > >I don't know that much about ebuilds in portage in detail although I >already used it. If dobin and dodoc simply copy the file over without >additional logic, these would just be aliases for xinstall in our case: > >dobin: xinstall -m 755 foo ${destroot}${prefix}/bin >dodoc: xinstall -m 644 foo ${destroot}${prefix}/share/doc/${name} > >We could create such aliases if there is really a need for it. Most >ports simply use the 'make install' of the software anyway and we >already have a much more general approach with xinstall. > >But if we are going to do it, I don't like these names do* very much, I >think xinstall-bin/xinstall-doc would be better. Do you think we need >something like this at all? > >Rainer Hi Ranier, I think that jberry had said some macros were desireable at one point, and I had thoudht the portage 'dodoc' & 'dobin' were good examples of this, except for the naming. But I'm not sure of that. I suppose we should see what others think. Or maybe if we are going to do macros, we should think about what would be the most important ones. Mark From markd at macports.org Fri Feb 13 12:23:19 2009 From: markd at macports.org (markd at macports.org) Date: Fri, 13 Feb 2009 12:23:19 -0800 Subject: Troubleshooting bus errors Message-ID: The app 'uplog' does not work on OS X 10.5 Intel or PPC. It works on 10.4/PPC. Does this crash log tell anything to help troubleshoot it? Or is there a tool that might help to pass information to the developer to fix it? Thanks. Mark Process: uplog [6127] Path: /opt/local/bin/uplog Identifier: uplog Version: ??? (???) Code Type: X86 (Native) Parent Process: bash [6030] Date/Time: 2009-02-13 11:15:44.678 -0800 OS Version: Mac OS X 10.5.5 (9F33) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 Crashed Thread: 0 Thread 0 Crashed: 0 libSystem.B.dylib 0x951091e5 strtol_l + 52 1 libSystem.B.dylib 0x9511c59c strtol + 67 2 uplog 0x00001c51 main + 401 3 uplog 0x0000186e start + 54 Thread 0 crashed with X86 Thread State (32-bit): eax: 0xa05dbda0 ebx: 0x951091c2 ecx: 0x00000070 edx: 0x00000068 edi: 0x00000000 esi: 0x00000000 ebp: 0xbfffec28 esp: 0xbfffebe0 ss: 0x0000001f efl: 0x00010293 eip: 0x951091e5 cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x00000000 Binary Images: 0x1000 - 0x3ffd +uplog ??? (???) <1998cadfd7def01ff6dea6706b1a7d86> /opt/local/bin/uplog 0x8fe00000 - 0x8fe2da53 dyld 96.2 (???) <7af47d3b00b2268947563c7fa8c59a07> /usr/lib/dyld 0x94cfc000 - 0x94d03fe9 libgcc_s.1.dylib ??? (???) /usr/lib/libgcc_s.1.dylib 0x950e1000 - 0x95241ff3 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib 0x95d33000 - 0x95d37fff libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib From loshea at gmail.com Fri Feb 13 21:30:02 2009 From: loshea at gmail.com (Luis O'Shea) Date: Sat, 14 Feb 2009 00:30:02 -0500 Subject: Port update needs committing Message-ID: <47ED4074-711A-474C-95AB-280D8FFE1A53@gmail.com> Can someone please commit http://trac.macports.org/ticket/18401 (updates the asymptote port). Thanks, Luis From jeremy at lavergne.gotdns.org Sat Feb 14 07:05:22 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 14 Feb 2009 10:05:22 -0500 Subject: Calling Python Guru! Message-ID: <85984ED4-502E-4B3D-B7A3-EB302EEA0CCC@lavergne.gotdns.org> Ticket #16400 is a python2.5 module that I seem to have working on my dev box but the maintainer is unable to get functioning as well. I managed to get it working with the addition of the cocoa bindings for pyobjc. Can you please take a look at our conversations and port files and offer some suggestions? http://trac.macports.org/ticket/16400 Thanks! -------------- 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 Feb 14 14:23:25 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 14 Feb 2009 16:23:25 -0600 Subject: [46832] trunk/dports/www/wikkawiki/Portfile In-Reply-To: <20090214145601.29BAEF5C6CB@beta.macosforge.org> References: <20090214145601.29BAEF5C6CB@beta.macosforge.org> Message-ID: On Feb 14, 2009, at 08:56, snc at macports.org wrote: > Revision: 46832 > http://trac.macports.org/changeset/46832 > Author: snc at macports.org > Date: 2009-02-14 06:55:57 -0800 (Sat, 14 Feb 2009) > Log Message: > ----------- > further cleanup of wikkawiki, ticket #18455 > + post-activate { > + } You can probably remove these two lines since they do nothing. From ryandesign at macports.org Sat Feb 14 14:25:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 14 Feb 2009 16:25:49 -0600 Subject: [46830] trunk/dports/emulators/simh In-Reply-To: <20090214132018.D894FF5BB28@beta.macosforge.org> References: <20090214132018.D894FF5BB28@beta.macosforge.org> Message-ID: <20172412-EF5D-4A6F-B7CB-F121E3A238DC@macports.org> On Feb 14, 2009, at 07:20, gwright at macports.org wrote: > Revision: 46830 > http://trac.macports.org/changeset/46830 > Author: gwright at macports.org > Date: 2009-02-14 05:20:16 -0800 (Sat, 14 Feb 2009) > Log Message: > ----------- > Miscellaneous cleanups, including fixing a lint warning. > > Modified Paths: > -------------- > trunk/dports/emulators/simh/Portfile > > Removed Paths: > ------------- > trunk/dports/emulators/simh/files/ > > Modified: trunk/dports/emulators/simh/Portfile > =================================================================== > --- trunk/dports/emulators/simh/Portfile 2009-02-14 12:55:37 UTC > (rev 46829) > +++ trunk/dports/emulators/simh/Portfile 2009-02-14 13:20:16 UTC > (rev 46830) > @@ -4,9 +4,10 @@ > > name simh > version v38-1 > +revision 1 > categories emulators > platforms darwin > -maintainers gwright at macports.org > +maintainers gwright > description A highly portable, multi-system simulator. > long_description \ > The Computer History Simulation Project is a loose \ > @@ -28,7 +29,7 @@ > use_zip yes > distname ${name}${version} > worksrcdir . > -configure {} > +use_configure no It doesn't look like this changed the files installed by the port at all, so in that case you shouldn't increase the port's revision. (Don't decrease it again now, just keep in mind for the future.) From ryandesign at macports.org Sat Feb 14 16:04:12 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 14 Feb 2009 18:04:12 -0600 Subject: MacPorts trunk is deactivating universal and activating non-universal ports Message-ID: Why is MacPorts trunk deactivating my universal ports and activating my non-universal ports? $ port installed rpm51 The following ports are currently installed: rpm51 @5.1.6_1 (active) $ port -ux upgrade rpm51 ---> Deactivating libiconv @1.12_2+universal ---> Activating libiconv @1.12_2 ---> Deactivating bzip2 @1.0.5_2+universal ---> Activating bzip2 @1.0.5_2 ---> Fetching rpm51 ---> Verifying checksum(s) for rpm51 ---> Extracting rpm51 ---> Applying patches to rpm51 ---> Configuring rpm51 ^C $ During rpm51 configuration, gettext programs crash, because gettext is compiled 4-way universal but now that gettext's dependency libiconv has been switched to non-universal, gettext can't function. This behavior is new for trunk. MacPorts 1.7.0 would deactivate the universal version, then reactivate the universal version, which was dumb but at least didn't break anything. This was described here: http://trac.macports.org/ticket/16085 Anyone know why this changed in trunk? From ryandesign at macports.org Sat Feb 14 16:06:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 14 Feb 2009 18:06:49 -0600 Subject: [MacPorts] #18493: problem with installation of ImageMagick-6.4.9-1 on powerpc running osx 10.5.6 In-Reply-To: References: <062.95b8c0d1fccd0a90392e2194cccf0573@macports.org> <071.9647628880268ad4445cd87ab53e2bb5@macports.org> Message-ID: <7C8AC8CE-8795-4128-80A0-DFA78A7A9D39@macports.org> On Feb 14, 2009, at 11:00, Bruce Draine wrote: > I have only tried to use two of the newly-installed ImageMagick tools > (I am running X11 on a powerpc running osx 10.5.6). > > convert appears to work more-or-less OK > but at least one problem: > convert file.eps file.png > added a gray background (this doesn't happen on a linux > system where I use "convert") > > display has at least two problems: > 1. every time I start "display" on my mac, I get a warning > Xlib: extension "Generic Event Extension" missing on > display > "/tmp/launch-ogw8t2/:0" > although .pdf images appear to display OK > 2. when I try to look at a xxx.eps or xxx.png image that > should > have a white background, > I instead see a checkerboard background > > I don't know if these are ImageMagick bugs, or the result of > some problem with the install process. For these issues, I would recommend writing to the ImageMagick bugs mailing list, and supplying the input and output files. http://www.imagemagick.org/mailman/listinfo/magick-bugs From brad at pixilla.com Sun Feb 15 14:58:09 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sun, 15 Feb 2009 14:58:09 -0800 Subject: port install targets Message-ID: Port mail/dbmail Port mail/dbmail-devel `port dir dbmail`/work/dbmail-2.2.11/configure --help Fine tuning of the installation directories: --bindir=DIR user executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIR program executables [EPREFIX/libexec] --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIR man documentation [DATAROOTDIR/man] --docdir=DIR documentation root [DATAROOTDIR/doc/PACKAGE] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIR dvi documentation [DOCDIR] --pdfdir=DIR pdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR] Should I make most of the PREFIX/xxx into ${prefix}/dbmail22/xxx? I seem to see a lot of that in macports. What about DATAROOTDIR? Thanks, Brad From raimue at macports.org Sun Feb 15 15:12:23 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 16 Feb 2009 00:12:23 +0100 Subject: port install targets In-Reply-To: References: Message-ID: <4998A157.4040905@macports.org> Bradley Giesbrecht wrote: > Should I make most of the PREFIX/xxx into ${prefix}/dbmail22/xxx? > > I seem to see a lot of that in macports. PREFIX is a variable for whatever you pass to --prefix in configure. As this is not known when you ran --help it is not replaced. --prefix=${prefix} is the default for configure.pre_args, so that will automatically be set when running the configure phase using MacPorts. You should be aware that MacPorts also exports environment variables and that running configure manually might result in different results than with MacPorts. > What about DATAROOTDIR? The default value for DATAROOTDIR is PREFIX/share in configure itself. As --prefix is given by MacPorts, this will be the correct value. Rainer From simon at ruderich.org Sun Feb 15 16:18:37 2009 From: simon at ruderich.org (Simon Ruderich) Date: Mon, 16 Feb 2009 01:18:37 +0100 Subject: Problem installing xorg-server on Tiger In-Reply-To: <20090208222633.GC18279@ruderich.org> References: <20090131204620.GA3021@ruderich.org> <20090202134724.GA7245@ruderich.org> <310537F0-23E5-4C5B-98EB-C367B29BB1E1@macports.org> <42990F53-0243-44DC-ADF5-CA03AE94D008@macports.org> <20090202204633.GA12364@ruderich.org> <20090202204908.GB12364@ruderich.org> <1E556356-B5AD-47A9-98EB-DF8972672E90@macports.org> <20090208222633.GC18279@ruderich.org> Message-ID: <20090216001837.GA23230@ruderich.org> On Sun, Feb 08, 2009 at 11:26:33PM +0100, Simon Ruderich wrote: > On Mon, Feb 02, 2009 at 12:59:51PM -0800, Jeremy Huddleston wrote: > > One other user is actually reporting odd CPU usage issues on Leopard. > > Would you mind joining xquartz-dev to jump in that thread: > > > > http://lists.macosforge.org/mailman/listinfo/xquartz-dev > > > > http://lists.macosforge.org/pipermail/xquartz-dev/2009-January/001952.html > > http://lists.macosforge.org/pipermail/xquartz-dev/2009-January/002042.html > > http://lists.macosforge.org/pipermail/xquartz-dev/2009-January/002044.html > > Sorry for the late reply. I just joined the list and described > them the problem. For everybody not reading xquartz-dev: Disabling the Pasteboard in Preferences->Pasteboard worked for me in Tiger. But this fix doesn't seem to work on Leopard. Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From jm at poure.com Mon Feb 16 01:58:15 2009 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Mon, 16 Feb 2009 10:58:15 +0100 Subject: Installing Gimp triggers installation of ffmeg Message-ID: <1234778295.12268.1.camel@debian> Hello, We had this discussion before, but I still don't understan why installing Gimp triggers after several dependencies ffmpeg. sudo port -u upgrade gimp ---> Activating ffmpeg @15261_3+a52+darwin_i386 Error: Activating ffmpeg @15261_3 failed: Image error: /opt/local/bin/ffmpeg is being used by the active ffmpeg-devel port. Please deactivate this port first, or use the -f flag to force the activation. ---> Fetching gimp2 ---> Attempting to fetch gimp-2.6.5.tar.bz2 from http://gimp.krecio.pl/gimp/v2.6/ ---> Attempting to fetch gimp-2.6.5.tar.bz2 from ftp://ftp.snt.utwente.nl/pub/software/gimp/gimp/v2.6/ ---> Attempting to fetch gimp-2.6.5.tar.bz2 from http://ftp.snt.utwente.nl/pub/software/gimp/gimp/v2.6/ ---> Attempting to fetch gimp-2.6.5.tar.bz2 from http://ftp.iut-bm.univ-fcomte.fr/gimp/gimp/v2.6/ ---> Attempting to fetch gimp-2.6.5.tar.bz2 from ftp://ftp.esat.net/mirrors/ftp.gimp.org/pub/gimp/v2.6/ Kind regards, Jean-Michel From devans at macports.org Mon Feb 16 11:11:00 2009 From: devans at macports.org (David Evans) Date: Mon, 16 Feb 2009 11:11:00 -0800 Subject: Installing Gimp triggers installation of ffmeg In-Reply-To: <1234778295.12268.1.camel@debian> References: <1234778295.12268.1.camel@debian> Message-ID: <4999BA44.5080509@macports.org> Jean-Michel Pour? wrote: > Hello, > > We had this discussion before, but I still don't understan why > installing Gimp triggers after several dependencies ffmpeg. > > sudo port -u upgrade gimp > ---> Activating ffmpeg @15261_3+a52+darwin_i386 > Error: Activating ffmpeg @15261_3 failed: Image > error: /opt/local/bin/ffmpeg is being used by the active ffmpeg-devel > port. Please deactivate this port first, or use the -f flag to force > the activation. > ---> Fetching gimp2 > ---> Attempting to fetch gimp-2.6.5.tar.bz2 from > http://gimp.krecio.pl/gimp/v2.6/ > ---> Attempting to fetch gimp-2.6.5.tar.bz2 from > ftp://ftp.snt.utwente.nl/pub/software/gimp/gimp/v2.6/ > ---> Attempting to fetch gimp-2.6.5.tar.bz2 from > http://ftp.snt.utwente.nl/pub/software/gimp/gimp/v2.6/ > ---> Attempting to fetch gimp-2.6.5.tar.bz2 from > http://ftp.iut-bm.univ-fcomte.fr/gimp/gimp/v2.6/ > ---> Attempting to fetch gimp-2.6.5.tar.bz2 from > ftp://ftp.esat.net/mirrors/ftp.gimp.org/pub/gimp/v2.6/ > > Kind regards, > Jean-Michel > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > JM, Gimp requires gegl which depends on ffmpeg (to read multimedia formats for image processing). Gimp development is moving in the direction of using gegl exclusively for image processing functions. Looks like you need to sync your ports as the latest version of gegl uses a path dependency rather than a port dependency so that either ffmpeg or ffmpeg-devel can satisfy the dependency. This is now true of all ports that depend on ffmpeg (except transcode which is in testing yet). However, since ffmpeg and ffmpeg-devel are not binary compatible (avcode vers 51 vs vers 52) then you need to make sure that you compile gegl against ffmpeg-devel so you don't get runtime dynamic linking errors. Dave From ryandesign at macports.org Mon Feb 16 15:58:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 16 Feb 2009 17:58:49 -0600 Subject: [46883] trunk/dports/devel/tailor/Portfile In-Reply-To: <20090216174219.A51EFF912EA@beta.macosforge.org> References: <20090216174219.A51EFF912EA@beta.macosforge.org> Message-ID: <4FB9BCDF-5927-4236-8904-21794270B69A@macports.org> On Feb 16, 2009, at 11:42, deric at macports.org wrote: > Revision: 46883 > http://trac.macports.org/changeset/46883 > Author: deric at macports.org > Date: 2009-02-16 09:42:19 -0800 (Mon, 16 Feb 2009) > Log Message: > ----------- > Update URL to homepage. > > Modified Paths: > -------------- > trunk/dports/devel/tailor/Portfile > > Modified: trunk/dports/devel/tailor/Portfile > =================================================================== > --- trunk/dports/devel/tailor/Portfile 2009-02-16 17:39:05 UTC (rev > 46882) > +++ trunk/dports/devel/tailor/Portfile 2009-02-16 17:42:19 UTC (rev > 46883) > @@ -5,6 +5,7 @@ > > name tailor > version 0.9.35 > +revision 1 > categories devel python > maintainers deric at macports.org > description Tailor is a tool to migrate changesets between > different \ > @@ -14,7 +15,7 @@ > Monotone, Subversion and Tla repositories. It > is \ > implemented in Python. > > -homepage http://www.darcs.net/DarcsWiki/Tailor > +homepage http://wiki.darcs.net/DarcsWiki/Tailor > master_sites http://darcs.arstecnica.it/ > checksums md5 58a6bc1c1d922b0b1e4579c6440448d1 \ > sha1 442d1d11bf4ba5d54684f78783f94f753a02292e \ FYI: The old homepage does not exist, therefore nobody could have installed the port before. Since this change does not change what files are installed on the user's computer, there's no need to increase the revision in this case. Don't decrease it again now, just keep it in mind for the future. From jmr at macports.org Mon Feb 16 16:01:37 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 17 Feb 2009 11:01:37 +1100 Subject: [46883] trunk/dports/devel/tailor/Portfile In-Reply-To: <4FB9BCDF-5927-4236-8904-21794270B69A@macports.org> References: <20090216174219.A51EFF912EA@beta.macosforge.org> <4FB9BCDF-5927-4236-8904-21794270B69A@macports.org> Message-ID: <4999FE61.40204@macports.org> Ryan Schmidt wrote: > > On Feb 16, 2009, at 11:42, deric at macports.org wrote: >> -homepage http://www.darcs.net/DarcsWiki/Tailor >> +homepage http://wiki.darcs.net/DarcsWiki/Tailor >> master_sites http://darcs.arstecnica.it/ >> checksums md5 58a6bc1c1d922b0b1e4579c6440448d1 \ >> sha1 442d1d11bf4ba5d54684f78783f94f753a02292e \ > > FYI: The old homepage does not exist, therefore nobody could have > installed the port before. Since this change does not change what files > are installed on the user's computer, there's no need to increase the > revision in this case. Don't decrease it again now, just keep it in mind > for the future. While the conclusion that that rev didn't need to be bumped is correct, people could still install the port with the old homepage value... - Josh From ryandesign at macports.org Mon Feb 16 21:32:01 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 16 Feb 2009 23:32:01 -0600 Subject: port install targets In-Reply-To: References: Message-ID: On Feb 15, 2009, at 16:58, Bradley Giesbrecht wrote: > Port mail/dbmail > Port mail/dbmail-devel > > `port dir dbmail`/work/dbmail-2.2.11/configure --help > > Fine tuning of the installation directories: > --bindir=DIR user executables [EPREFIX/bin] > --sbindir=DIR system admin executables [EPREFIX/sbin] > --libexecdir=DIR program executables [EPREFIX/libexec] > --sysconfdir=DIR read-only single-machine data [PREFIX/etc] > --sharedstatedir=DIR modifiable architecture-independent data > [PREFIX/com] > --localstatedir=DIR modifiable single-machine data [PREFIX/var] > --libdir=DIR object code libraries [EPREFIX/lib] > --includedir=DIR C header files [PREFIX/include] > --oldincludedir=DIR C header files for non-gcc [/usr/include] > --datarootdir=DIR read-only arch.-independent data root > [PREFIX/share] > --datadir=DIR read-only architecture-independent data > [DATAROOTDIR] > --infodir=DIR info documentation [DATAROOTDIR/info] > --localedir=DIR locale-dependent data [DATAROOTDIR/locale] > --mandir=DIR man documentation [DATAROOTDIR/man] > --docdir=DIR documentation root [DATAROOTDIR/doc/PACKAGE] > --htmldir=DIR html documentation [DOCDIR] > --dvidir=DIR dvi documentation [DOCDIR] > --pdfdir=DIR pdf documentation [DOCDIR] > --psdir=DIR ps documentation [DOCDIR] > > > Should I make most of the PREFIX/xxx into ${prefix}/dbmail22/xxx? > > I seem to see a lot of that in macports. Where do you see that? I would say you should not insert an additional directory "dbmail22" into the hierarchy unless you need to support multiple ports for multiple versions of the software active simultaneously. But if you're only talking about dbmail and dbmail-devel, then it is not expected to be able to use them simultaneously; it is expected for both to install files to the same places and for only one to be active simultaneously. From ryandesign at macports.org Mon Feb 16 22:21:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 17 Feb 2009 00:21:02 -0600 Subject: [46869] trunk/dports/devel In-Reply-To: <20090216124906.DE16DF8D403@beta.macosforge.org> References: <20090216124906.DE16DF8D403@beta.macosforge.org> Message-ID: <6B4D4D5B-F506-42AB-BAC0-46B9E3E6A82C@macports.org> On Feb 16, 2009, at 06:49, krischik at macports.org wrote: > +distfiles bc-${version}.7z > +worksrcdir bc-${version} Instead, you should specify: distname bc-${version} extract.suffix .7z MacPorts will then compute distfiles and worksrcdir from these. > +use_bzip2 yes This port is not using bzip2 distfiles so you should remove this line. > +depends_build port:p7zip > + > +extract { > + system " > + pushd ${workpath}; > + 7za x ${distpath}/${distfile}; > + popd; > + " > +} pushd and popd are not necessary since the shell only exists for the duration of the "system" command. If you need to override a phase, then the customary method is: system "cd ${worksrcpath} && whatever" But you don't need to (and shouldn't) override the extract phase. Just specify your desired extract.cmd and extract.pre_args. By default MacPorts wants to pipe the output through tar, which isn't necessary here, so set extract.post_args to empty. I added a "use_7z" option just now so once MacPorts 1.8.0 is out you can switch to that. http://trac.macports.org/ticket/18521 For now, use: # Replace these with "use_7z yes" with MacPorts 1.8.0 depends_build port:p7zip extract.cmd ${prefix}/bin/7za extract.pre_args x extract.post_args > +build { > + system " > + pushd ${workpath}/${worksrcdir}/GNAT; > + gnumake release; > + gnumake debug; > + popd; > + " > +} I don't think you need to override the build phase either. gnumake is the default make command that MacPort uses anyway. (See the documentation of "build.type" in the Guide.) The default target is "all"; if you want "release" and "debug" instead then you say: build.target release debug If you want this to occur in the GNAT subdirectory instead, then you say: build.dir ${worksrcpath}/GNAT Note I have not tested these changes because I have not built the gnat-gcc dependency. > +destroot { > + xinstall -m 775 -d ${destroot}/${prefix}/lib/booch > + xinstall -m 775 -d ${destroot}/${prefix}/include/booch/src > + xinstall -m 775 -d ${destroot}/${prefix}/include/booch/GNAT > + xinstall -m 775 -d ${destroot}/${prefix}/include/booch/GNAT/ > Darwin-i686-Release > + xinstall -m 775 -d ${destroot}/${prefix}/include/booch/GNAT/ > Darwin-i686-Release/obj > + xinstall -m 775 -d ${destroot}/${prefix}/include/booch/GNAT/ > Darwin-i686-Release/lib > + xinstall -m 775 -d ${destroot}/${prefix}/include/booch/GNAT/ > Darwin-i686-Debug > + xinstall -m 775 -d ${destroot}/${prefix}/include/booch/GNAT/ > Darwin-i686-Debug/obj > + xinstall -m 775 -d ${destroot}/${prefix}/include/booch/GNAT/ > Darwin-i686-Debug/lib You should not put a slash before ${prefix} because ${prefix} already begins with a slash. > + eval xinstall -m 664 [glob ${workpath}/${worksrcdir}/GNAT/Darwin- > i686-Release/lib/*] ${destroot}/${prefix}/lib/booch > + eval xinstall -m 664 [glob ${workpath}/${worksrcdir}/src/ > *] ${destroot}/${prefix}/include/booch/src > + eval xinstall -m 664 [glob ${workpath}/${worksrcdir}/GNAT/ > Makefile] ${destroot}/${prefix}/include/booch/GNAT > + eval xinstall -m 664 [glob ${workpath}/${worksrcdir}/GNAT/ > booch_95.gpr] ${destroot}/${prefix}/include/booch/GNAT > + eval xinstall -m 664 [glob ${workpath}/${worksrcdir}/GNAT/Darwin- > i686-Release/obj/*] ${destroot}/${prefix}/include/booch/GNAT/Darwin- > i686-Release/obj > + eval xinstall -m 664 [glob ${workpath}/${worksrcdir}/GNAT/Darwin- > i686-Release/lib/*] ${destroot}/${prefix}/include/booch/GNAT/Darwin- > i686-Release/lib > + eval xinstall -m 664 [glob ${workpath}/${worksrcdir}/GNAT/Darwin- > i686-Debug/obj/*] ${destroot}/${prefix}/include/booch/GNAT/Darwin- > i686-Debug/obj > + eval xinstall -m 664 [glob ${workpath}/${worksrcdir}/GNAT/Darwin- > i686-Debug/lib/*] ${destroot}/${prefix}/include/booch/GNAT/Darwin- > i686-Debug/lib > +} Note that ${workpath}/${worksrcdir} can be simplified to ${worksrcpath}. From raimue at macports.org Mon Feb 16 23:20:28 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Tue, 17 Feb 2009 08:20:28 +0100 Subject: [MacPorts] #15868: port-1.600: port sync fails with "please get a newer Subversion client" In-Reply-To: <065.84a3ff39061f0741c1cbc5c83a749ca8@macports.org> References: <056.02eb3cda03e95963cbae276c3a4f179b@macports.org> <065.84a3ff39061f0741c1cbc5c83a749ca8@macports.org> Message-ID: <499A653C.7080102@macports.org> MacPorts wrote: > #15868: port-1.600: port sync fails with "please get a newer Subversion client" > ----------------------------------+----------------------------------------- > Reporter: kimuraw@? | Owner: raimue@? > Type: defect | Status: assigned > Priority: Normal | Milestone: MacPorts 1.7.1 > Component: base | Version: 1.6.0 > Keywords: | Port: > ----------------------------------+----------------------------------------- > > Comment(by blb@?): > > Then we need a list of those programs which must always be from the system > and path those, since I think that would be the better direction than > trying to list those which shouldn't be pathed. So bzip2, cvs, open, and > rsync should be right? What about mtree and xar? I am bringing this up on the mailing list, as this is the better place for discussions than Trac. In my opinion binaries which are vital for the operation of MacPorts should be used from an absolute path. As far as I see, this is only bzip2 in registry1.0 as you cannot activate/deactivate ports anymore when bzip2 is broken. 'port deactivate' can most probably fix easily all other issues introduced by broken binaries in PATH. In release_1_7 this is also 'rm' and 'ln' which were replaced on trunk in r45851 [1] (should we merge this?). For syncing I see no problem in using PATH for svn and rsync. Especially it solves the svn issue and users could benefit from rsync 3.x. Also note that there is no svn pre-installed on Tiger, so there has to be at least a fallback to PATH. For fetching there are no issues with svn, as we will always call the same version. git is not pre-installed, but it has a fallback to PATH which should be fine enough. For packaging and archiving currently all tools are used from PATH and I don't think we need to use autoconfed paths. Is there a port providing mtree at all? We should also think about tracemode. The current prefix is automatically in the sandbox, but I don't know if other paths from binpath are considered. Oh, and note that by PATH above I mean what port uses, namely the binpath from macports.conf. It is not the user environment. Rainer [1] https://trac.macports.org/changeset/45851 From ryandesign at macports.org Tue Feb 17 04:19:16 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 17 Feb 2009 06:19:16 -0600 Subject: [46919] trunk/dports/sysutils/zmq/Portfile In-Reply-To: <20090217062220.7145EF9D67E@beta.macosforge.org> References: <20090217062220.7145EF9D67E@beta.macosforge.org> Message-ID: <67571877-DFD4-4C62-98A1-73E13D71977C@macports.org> On Feb 17, 2009, at 00:22, brett at macports.org wrote: > Revision: 46919 > http://trac.macports.org/changeset/46919 > Author: brett at macports.org > Date: 2009-02-16 22:22:19 -0800 (Mon, 16 Feb 2009) > Log Message: > ----------- > update zmq to 0.5 > > Modified Paths: > -------------- > trunk/dports/sysutils/zmq/Portfile > > Modified: trunk/dports/sysutils/zmq/Portfile > =================================================================== > --- trunk/dports/sysutils/zmq/Portfile 2009-02-17 06:11:22 UTC (rev > 46918) > +++ trunk/dports/sysutils/zmq/Portfile 2009-02-17 06:22:19 UTC (rev > 46919) > @@ -2,17 +2,33 @@ > > PortSystem 1.0 > > -name zmq > -version 0.3 > -description Ultra-fast AMQP-compliant messaging server > -long_description 0MQ is a lightweight messaging kernel. It > achieves 25 \ > - microsecond end-to-end latencies and 2.8 million messages \ > - per second. It is intended to be fully AMQP-compliant. > -maintainers brett at macports.org > -categories sysutils > -platforms darwin > -homepage http://www.zeromq.org/ > -master_sites http://www.zeromq.org/local--files/area:download-v03 > -checksums sha1 9c12e9862db1aa85461515b70d3ca69abae72e9b > -configure.args --mandir=${prefix}/share/man > +name zmq > +version 0.5 > +description Ultra-fast AMQP-compliant messaging server > +long_description 0MQ is a lightweight messaging kernel. It > achieves 25 \ > + microsecond end-to-end latencies and 2.8 > million messages \ > + per second. It is intended to be fully > AMQP-compliant. > +maintainers openmaintainer brett at macports.org > +categories sysutils net > +platforms darwin > +homepage http://www.zeromq.org/ > +master_sites http://www.zeromq.org/local--files/ > area:download/ > +checksums sha1 2059e2118b357a491415eca4f2b8e0414466655d > +configure.args --mandir=${prefix}/share/man > > +variant c description {build c language binding} { > + configure.args-append --with-c > +} Is there a reason this is not enabled all the time? > +variant python description {build Python language binding} { > + configure.args-append --with-python > +} Which python is this built for? > +variant java description {build Java language binding} { > + depends_lib-append bin:java:kaffe > + configure.args-append --with-java > +} > + > +variant amqp description {build libzmq with AMQP extension} { > + configure.args-append --with-c > +} This is the same thing as the c variant? From ryandesign at macports.org Tue Feb 17 04:41:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 17 Feb 2009 06:41:49 -0600 Subject: [MacPorts] #15868: port-1.600: port sync fails with "please get a newer Subversion client" In-Reply-To: <499A653C.7080102@macports.org> References: <056.02eb3cda03e95963cbae276c3a4f179b@macports.org> <065.84a3ff39061f0741c1cbc5c83a749ca8@macports.org> <499A653C.7080102@macports.org> Message-ID: <09EEA8C8-CEBD-4041-B340-807733710505@macports.org> On Feb 17, 2009, at 01:20, Rainer M?ller wrote: >> Comment(by blb@?): >> >> Then we need a list of those programs which must always be from >> the system >> and path those, since I think that would be the better direction >> than >> trying to list those which shouldn't be pathed. So bzip2, cvs, >> open, and >> rsync should be right? What about mtree and xar? > > I am bringing this up on the mailing list, as this is the better place > for discussions than Trac. > > In my opinion binaries which are vital for the operation of MacPorts > should be used from an absolute path. As far as I see, this is only > bzip2 in registry1.0 as you cannot activate/deactivate ports anymore > when bzip2 is broken. 'port deactivate' can most probably fix > easily all > other issues introduced by broken binaries in PATH. bzip2 is essential for dealing with receipts, yes, but bzip2, gzip and tar are also essential for decompressing the vast majority of distfiles. We've seen failures at extract time when a user migrated a bzip2 from a previous Mac's MacPorts installation that got broken. > In release_1_7 this is also 'rm' and 'ln' which were replaced on trunk > in r45851 [1] (should we merge this?). Not yet, because it caused this: http://trac.macports.org/ticket/18489 From raimue at macports.org Tue Feb 17 09:58:56 2009 From: raimue at macports.org (=?windows-1252?Q?Rainer_M=FCller?=) Date: Tue, 17 Feb 2009 18:58:56 +0100 Subject: [MacPorts] #15868: port-1.600: port sync fails with "please get a newer Subversion client" In-Reply-To: <09EEA8C8-CEBD-4041-B340-807733710505@macports.org> References: <056.02eb3cda03e95963cbae276c3a4f179b@macports.org> <065.84a3ff39061f0741c1cbc5c83a749ca8@macports.org> <499A653C.7080102@macports.org> <09EEA8C8-CEBD-4041-B340-807733710505@macports.org> Message-ID: <499AFAE0.8050707@macports.org> Ryan Schmidt wrote: > On Feb 17, 2009, at 01:20, Rainer M?ller wrote: >> In my opinion binaries which are vital for the operation of MacPorts >> should be used from an absolute path. As far as I see, this is only >> bzip2 in registry1.0 as you cannot activate/deactivate ports anymore >> when bzip2 is broken. 'port deactivate' can most probably fix >> easily all >> other issues introduced by broken binaries in PATH. > > bzip2 is essential for dealing with receipts, yes, but bzip2, gzip > and tar are also essential for decompressing the vast majority of > distfiles. We've seen failures at extract time when a user migrated a > bzip2 from a previous Mac's MacPorts installation that got broken. In my opinion decompressing distfiles is not vital. When the registry is broken, it is hard to get it fixed agin. But if a decompressor (tar, gzip, bzip2) is broken, it's easy to deactivate this port and use the one from the system. Rainer From brad at pixilla.com Tue Feb 17 10:51:16 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 17 Feb 2009 10:51:16 -0800 Subject: port install targets In-Reply-To: References: Message-ID: <0AF4C145-ED90-4A2C-A4CC-52D7FF448BA4@pixilla.com> On Feb 16, 2009, at 9:32 PM, Ryan Schmidt wrote: > > On Feb 15, 2009, at 16:58, Bradley Giesbrecht wrote: > >> Port mail/dbmail >> Port mail/dbmail-devel >> >> `port dir dbmail`/work/dbmail-2.2.11/configure --help >> >> Fine tuning of the installation directories: >> --bindir=DIR user executables [EPREFIX/bin] >> --sbindir=DIR system admin executables [EPREFIX/sbin] >> --libexecdir=DIR program executables [EPREFIX/libexec] >> --sysconfdir=DIR read-only single-machine data [PREFIX/etc] >> --sharedstatedir=DIR modifiable architecture-independent data >> [PREFIX/com] >> --localstatedir=DIR modifiable single-machine data [PREFIX/var] >> --libdir=DIR object code libraries [EPREFIX/lib] >> --includedir=DIR C header files [PREFIX/include] >> --oldincludedir=DIR C header files for non-gcc [/usr/include] >> --datarootdir=DIR read-only arch.-independent data root >> [PREFIX/share] >> --datadir=DIR read-only architecture-independent data >> [DATAROOTDIR] >> --infodir=DIR info documentation [DATAROOTDIR/info] >> --localedir=DIR locale-dependent data [DATAROOTDIR/locale] >> --mandir=DIR man documentation [DATAROOTDIR/man] >> --docdir=DIR documentation root [DATAROOTDIR/doc/PACKAGE] >> --htmldir=DIR html documentation [DOCDIR] >> --dvidir=DIR dvi documentation [DOCDIR] >> --pdfdir=DIR pdf documentation [DOCDIR] >> --psdir=DIR ps documentation [DOCDIR] >> >> >> Should I make most of the PREFIX/xxx into ${prefix}/dbmail22/xxx? >> >> I seem to see a lot of that in macports. > > Where do you see that? mysql. > I would say you should not insert an additional directory "dbmail22" > into the hierarchy unless you need to support multiple ports for > multiple versions of the software active simultaneously. But if > you're only talking about dbmail and dbmail-devel, then it is not > expected to be able to use them simultaneously; it is expected for > both to install files to the same places and for only one to be > active simultaneously. Thanks. From ryandesign at macports.org Tue Feb 17 11:32:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 17 Feb 2009 13:32:40 -0600 Subject: port install targets In-Reply-To: <0AF4C145-ED90-4A2C-A4CC-52D7FF448BA4@pixilla.com> References: <0AF4C145-ED90-4A2C-A4CC-52D7FF448BA4@pixilla.com> Message-ID: <506AE65F-9522-4DCA-B5C5-1C50639E14DD@macports.org> On Feb 17, 2009, at 12:51, Bradley Giesbrecht wrote: >>> Should I make most of the PREFIX/xxx into ${prefix}/dbmail22/xxx? >>> >>> I seem to see a lot of that in macports. >> >> Where do you see that? > > mysql. Probably an attempt to allow mysql3, mysql4 and mysql5 to be installed simultaneously. Unfortunately even that did not succeed: http://trac.macports.org/ticket/4115 From ryandesign at macports.org Tue Feb 17 11:34:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 17 Feb 2009 13:34:38 -0600 Subject: [MacPorts] #15868: port-1.600: port sync fails with "please get a newer Subversion client" In-Reply-To: <499AFAE0.8050707@macports.org> References: <056.02eb3cda03e95963cbae276c3a4f179b@macports.org> <065.84a3ff39061f0741c1cbc5c83a749ca8@macports.org> <499A653C.7080102@macports.org> <09EEA8C8-CEBD-4041-B340-807733710505@macports.org> <499AFAE0.8050707@macports.org> Message-ID: On Feb 17, 2009, at 11:58, Rainer M?ller wrote: > Ryan Schmidt wrote: >> > >> bzip2 is essential for dealing with receipts, yes, but bzip2, gzip >> and tar are also essential for decompressing the vast majority of >> distfiles. We've seen failures at extract time when a user migrated a >> bzip2 from a previous Mac's MacPorts installation that got broken. > > In my opinion decompressing distfiles is not vital. When the > registry is > broken, it is hard to get it fixed agin. But if a decompressor (tar, > gzip, bzip2) is broken, it's easy to deactivate this port and use the > one from the system. However, MacPorts does not issue an error message if the decompressor fails. The first error message the user sees is during the configure phase when it can't find the files that should be there. This is confusing. http://trac.macports.org/ticket/16223 From macsforever2000 at macports.org Tue Feb 17 20:29:24 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Tue, 17 Feb 2009 21:29:24 -0700 Subject: [46937] trunk/dports/sysutils/zmq/Portfile In-Reply-To: <20090218040629.E9E57FBD3C0@beta.macosforge.org> References: <20090218040629.E9E57FBD3C0@beta.macosforge.org> Message-ID: <359B7502-0845-4F96-9A4E-6E8DE2D7FC33@macports.org> On Feb 17, 2009, at 9:06 PM, brett at macports.org wrote: > Revision > 46937 > Author > brett at macports.org > Date > 2009-02-17 20:06:29 -0800 (Tue, 17 Feb 2009) > Log Message > > add python depend > Modified Paths > > trunk/dports/sysutils/zmq/Portfile > Diff > > Modified: trunk/dports/sysutils/zmq/Portfile (46936 => 46937) > --- trunk/dports/sysutils/zmq/Portfile 2009-02-18 03:52:32 UTC (rev > 46936) > +++ trunk/dports/sysutils/zmq/Portfile 2009-02-18 04:06:29 UTC (rev > 46937) > @@ -18,7 +18,8 @@ > --with-c > > variant python description {build Python language binding} { > - configure.args-append --with-python > + depends_lib-append port:python26 > + configure.args-append --with-python > } > > variant java description {build Java language binding} { Can this be changed to port:python_select so that any python version will satisfy the dependency? -------------- next part -------------- An HTML attachment was scrubbed... URL: From blb at macports.org Tue Feb 17 21:03:42 2009 From: blb at macports.org (Bryan Blackburn) Date: Tue, 17 Feb 2009 22:03:42 -0700 Subject: [46937] trunk/dports/sysutils/zmq/Portfile In-Reply-To: <359B7502-0845-4F96-9A4E-6E8DE2D7FC33@macports.org> References: <20090218040629.E9E57FBD3C0@beta.macosforge.org> <359B7502-0845-4F96-9A4E-6E8DE2D7FC33@macports.org> Message-ID: <20090218050342.GM741@ninagal.withay.com> On Tue, Feb 17, 2009 at 09:29:24PM -0700, Frank Schima said: > > On Feb 17, 2009, at 9:06 PM, brett at macports.org wrote: [...] >> >> variant python description {build Python language binding} { >> - configure.args-append --with-python >> + depends_lib-append port:python26 >> + configure.args-append --with-python >> } >> >> variant java description {build Java language binding} { > > Can this be changed to port:python_select so that any python version will > satisfy the dependency? Since python_select has no python* dependencies itself, depending on it wouldn't actually cause any python to be installed. Since each python* port doesn't install the same file, a path:...:python26 dependency can't be used either. Until tickets #126 and #16723 are handled, this remains either messy (with python25, python26, etc as variants for each) or by simply picking one. Bryan From ryandesign at macports.org Tue Feb 17 21:29:17 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 17 Feb 2009 23:29:17 -0600 Subject: [46935] trunk/dports/sysutils/zmq/Portfile In-Reply-To: <20090218033638.95DBDFBD0B4@beta.macosforge.org> References: <20090218033638.95DBDFBD0B4@beta.macosforge.org> Message-ID: <06931725-6843-4D74-8DB9-F5B141F60DB0@macports.org> On Feb 17, 2009, at 21:36, brett at macports.org wrote: > Revision: 46935 > http://trac.macports.org/changeset/46935 > Author: brett at macports.org > Date: 2009-02-17 19:36:37 -0800 (Tue, 17 Feb 2009) > Log Message: > ----------- > cleanup: build clib default, fix copy paste error > > Modified Paths: > -------------- > trunk/dports/sysutils/zmq/Portfile > > Modified: trunk/dports/sysutils/zmq/Portfile > =================================================================== > --- trunk/dports/sysutils/zmq/Portfile 2009-02-18 01:52:31 UTC (rev > 46934) > +++ trunk/dports/sysutils/zmq/Portfile 2009-02-18 03:36:37 UTC (rev > 46935) > @@ -14,12 +14,9 @@ > homepage http://www.zeromq.org/ > master_sites http://www.zeromq.org/local--files/ > area:download/ > checksums sha1 2059e2118b357a491415eca4f2b8e0414466655d > -configure.args --mandir=${prefix}/share/man > +configure.args --mandir=${prefix}/share/man \ > + --with-c > > -variant c description {build c language binding} { > - configure.args-append --with-c > -} Does that change what files are installed by the port? If so, you should increase the revision. From ryandesign at macports.org Wed Feb 18 01:03:48 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 18 Feb 2009 03:03:48 -0600 Subject: MacPorts 1.7.1 Message-ID: <465D826E-7631-41EC-958C-8478DCAD809E@macports.org> Has anyone been running the 1.7 branch? Found any problems with it? Should we release MacPorts 1.7.1 soonish? It's been two months since 1.7.0. You know what they say: release early, release often! We have these changes on the 1.7 branch already: - Add 'apple-gcc-4.2' option to configure.compiler (#18426, ryandesign) - Create ${applications_dir} and ${frameworks_dir} in destroot automatically (r45614, raimue) - Make the postflight procedure a bit smarter about which login files to update for bash and tcsh (#17588) - Add error messages to package installers when the wrong OS package is being installed (#13141) We could merge in these additional small changes that are on trunk: - Add new "use_7z yes" port option to allow distfiles in 7z format (#18521, ryandesign) - port lint no longer requires variable master_sites if the port has no distfiles (#18479, ryandesign) - Upgrade will no longer accept ports that are not installed (but it still installs new ports as dependencies if needed). In particular, this means that "port upgrade all" will no longer proceed to install every available port. (jmr in r46052) - Add mkdtemp Tcl command to create temporary directories. (#17181, perry) These are the remaining changes on trunk that are described in the ChangeLog; not sure whether should merge these. In particular I would like to not merge changes that significantly change the output of a port command (like #11891). - Add several new options to port search (#15434, raimue) - Add xpkg archive type, xar-based format with XML. (afb) - Split portpkg creation out from portsubmit phase. (afb) - Make dependencies displayed in port info respect variants specified in variants.conf; collapse port deps to be an alias for port info with appropriate flags. Note this changes output format of port deps somewhat. (#11891, gwhitney) - Make dependencies in port upgrade respect variants as specified (in order of precedence) on command line, latest installed version, or variants.conf . (#8221, gwhitney) - Add select action, which integrates *_select tools into port. (#17477, perry) - The variants action additionally shows default variants, conflicting variants and variants' dependencies. (#14178, #15628, perry) - Implicit variants (e.g., darwin) can no longer be explicitly set/unset. (#12563, perry) There are probably also other changes on trunk that are not described in the ChangeLog. From jmr at macports.org Wed Feb 18 01:42:04 2009 From: jmr at macports.org (Joshua Root) Date: Wed, 18 Feb 2009 20:42:04 +1100 Subject: gsoc08-privileges branch merged Message-ID: <499BD7EC.9090701@macports.org> I just finished merging the changes from the gsoc08-privileges branch back into trunk. This of course has the potential for breakage, though I changed the default back to running as root, so you should hopefully not see any problems unless you pass --with-macports-user=you to configure. The privilege dropping has its issues. For example, if you start port with sudo, the configure and build phases will be run as root. But then root privileges will be dropped by the time it tries to clean after installing, with predictable results. So there's still some tweaking to be done, but I figured the sooner it was merged, the less bitrot there'd be to deal with. - Josh From pmagrath at macports.org Wed Feb 18 02:14:03 2009 From: pmagrath at macports.org (Paul Magrath) Date: Wed, 18 Feb 2009 10:14:03 +0000 Subject: gsoc08-privileges branch merged In-Reply-To: <499BD7EC.9090701@macports.org> References: <499BD7EC.9090701@macports.org> Message-ID: Hey Josh, If you have any questions, give me a shout. I'm still around I just haven't had much time - I'm in final year of my Computer Science course and workload is crazy. > I just finished merging the changes from the gsoc08-privileges branch > back into trunk. This of course has the potential for breakage, > though I > changed the default back to running as root, so you should hopefully > not > see any problems unless you pass --with-macports-user=you to > configure. > > The privilege dropping has its issues. For example, if you start port > with sudo, the configure and build phases will be run as root. But > then > root privileges will be dropped by the time it tries to clean after > installing, with predictable results. I was aware of this problem. The solution is to elevate privileges if clean fails, which I thought I'd written code to do so. However, as I'm sure you noticed, I haven't had time to keep the branch up to date so it is entirely possible that the code has been bypassed in the flow of control somehow. > So there's still some tweaking to be done, but I figured the sooner it > was merged, the less bitrot there'd be to deal with. Agreed, thanks actually for going ahead. I had meant to get it merged into trunk at the end of the summer but with all the v1.7 release stuff and the change in port managers, it didn't really seem the best time to merge in a large amount of code. I amn't sure if you have seen: https://trac.macports.org/wiki/gsoc08-privileges , if not it might be worth a read. Regards, Paul. From ryandesign at macports.org Wed Feb 18 03:03:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 18 Feb 2009 05:03:24 -0600 Subject: gsoc08-privileges branch merged In-Reply-To: <499BD7EC.9090701@macports.org> References: <499BD7EC.9090701@macports.org> Message-ID: <10CED60C-A72F-46C2-B357-9FD706CB9FCA@macports.org> On Feb 18, 2009, at 03:42, Joshua Root wrote: > I just finished merging the changes from the gsoc08-privileges branch > back into trunk. Oh right! That bit. > Modified: trunk/base/ChangeLog > =================================================================== > --- trunk/base/ChangeLog 2009-02-18 09:03:06 UTC (rev 46953) > +++ trunk/base/ChangeLog 2009-02-18 09:32:43 UTC (rev 46954) > @@ -5,6 +5,43 @@ > > > Release 1.8.0 (unreleased): > + - MacPorts now performs fetch, extract, patch, configure and > build in a > + user rather than system owned location. By default, this is > + ~/.macports/opt. This allows MacPorts to do all but the > install of the > + port without root privileges. (gsoc08-privileges) You know, I was never comfortable with this default location. It perpetuates the misperception that MacPorts installs into /opt when in fact it installs into /opt/local. But making the default location for non-root activities ~/.macports/opt/local doesn't make sense either, does it? Sigh. :-/ From devans at macports.org Wed Feb 18 07:01:07 2009 From: devans at macports.org (David Evans) Date: Wed, 18 Feb 2009 07:01:07 -0800 Subject: MacPorts 1.7.1 In-Reply-To: <465D826E-7631-41EC-958C-8478DCAD809E@macports.org> References: <465D826E-7631-41EC-958C-8478DCAD809E@macports.org> Message-ID: <499C22B3.9090204@macports.org> Ryan Schmidt wrote: > Has anyone been running the 1.7 branch? Found any problems with it? > Should we release MacPorts 1.7.1 soonish? It's been two months since > 1.7.0. You know what they say: release early, release often! > > - Make dependencies in port upgrade respect variants as specified > (in order of precedence) on command line, latest installed > version, or variants.conf . (#8221, gwhitney) > I'd like to make a strong pitch to add this one as without it it is impossible to correctly upgrade custom MacPorts installations that depend on on global variants such as +no_x11 or +system_x11. Without being able to upgrade, the global variants are next to useless. From florian.ebeling at gmail.com Wed Feb 18 07:27:24 2009 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Wed, 18 Feb 2009 16:27:24 +0100 Subject: MacPorts 1.7.1 In-Reply-To: <499C22B3.9090204@macports.org> References: <465D826E-7631-41EC-958C-8478DCAD809E@macports.org> <499C22B3.9090204@macports.org> Message-ID: <5cbbe4ae0902180727i16aa7c7due2efb12b52f0f613@mail.gmail.com> On Wed, Feb 18, 2009 at 4:01 PM, David Evans wrote: > Ryan Schmidt wrote: >> Has anyone been running the 1.7 branch? Found any problems with it? Should >> we release MacPorts 1.7.1 soonish? It's been two months since 1.7.0. You >> know what they say: release early, release often! >> >> - Make dependencies in port upgrade respect variants as specified >> (in order of precedence) on command line, latest installed >> version, or variants.conf . (#8221, gwhitney) >> > I'd like to make a strong pitch to add this one as without it it is > impossible to correctly upgrade custom MacPorts installations that depend on > on global variants such as +no_x11 or +system_x11. Without being able to > upgrade, the global variants are next to useless. Another option is to not create a teeny release and go straight to 1.8, isn't it? Then it would not matter as much if output changes. At least I'd like to +1 David here, but the other additions sound also very good. -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From raimue at macports.org Wed Feb 18 07:34:49 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 18 Feb 2009 16:34:49 +0100 Subject: MacPorts 1.7.1 In-Reply-To: <5cbbe4ae0902180727i16aa7c7due2efb12b52f0f613@mail.gmail.com> References: <465D826E-7631-41EC-958C-8478DCAD809E@macports.org> <499C22B3.9090204@macports.org> <5cbbe4ae0902180727i16aa7c7due2efb12b52f0f613@mail.gmail.com> Message-ID: <499C2A99.2000505@macports.org> C. Florian Ebeling wrote: > Another option is to not create a teeny release and go straight to > 1.8, isn't it? Then it would not matter as much if output changes. trunk now has the new root privileges escalation which is not tested thoroughly. I am for releasing 1.7.1 with what we got so far and stabilize trunk before releasing 1.8.0. Rainer From wsiegrist at apple.com Wed Feb 18 07:41:03 2009 From: wsiegrist at apple.com (William Siegrist) Date: Wed, 18 Feb 2009 07:41:03 -0800 Subject: gsoc08-privileges branch merged In-Reply-To: <10CED60C-A72F-46C2-B357-9FD706CB9FCA@macports.org> References: <499BD7EC.9090701@macports.org> <10CED60C-A72F-46C2-B357-9FD706CB9FCA@macports.org> Message-ID: <2715115E-620C-4723-B831-9DF11D29576A@apple.com> On Feb 18, 2009, at 3:03 AM, Ryan Schmidt wrote: > > On Feb 18, 2009, at 03:42, Joshua Root wrote: > >> I just finished merging the changes from the gsoc08-privileges branch >> back into trunk. > > Oh right! That bit. > > >> Modified: trunk/base/ChangeLog >> =================================================================== >> --- trunk/base/ChangeLog 2009-02-18 09:03:06 UTC (rev 46953) >> +++ trunk/base/ChangeLog 2009-02-18 09:32:43 UTC (rev 46954) >> @@ -5,6 +5,43 @@ >> >> >> Release 1.8.0 (unreleased): >> + - MacPorts now performs fetch, extract, patch, configure and >> build in a >> + user rather than system owned location. By default, this is >> + ~/.macports/opt. This allows MacPorts to do all but the >> install of the >> + port without root privileges. (gsoc08-privileges) > > > You know, I was never comfortable with this default location. It > perpetuates the misperception that MacPorts installs into /opt when > in fact it installs into /opt/local. But making the default location > for non-root activities ~/.macports/opt/local doesn't make sense > either, does it? Sigh. :-/ > > Why not just ~/.macports? That would seem to match other software, like ssh and subversion. -Bill From raimue at macports.org Wed Feb 18 07:42:42 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 18 Feb 2009 16:42:42 +0100 Subject: MacPorts 1.7.1 In-Reply-To: <465D826E-7631-41EC-958C-8478DCAD809E@macports.org> References: <465D826E-7631-41EC-958C-8478DCAD809E@macports.org> Message-ID: <499C2C72.7080808@macports.org> Ryan Schmidt wrote: > Has anyone been running the 1.7 branch? Found any problems with it? > Should we release MacPorts 1.7.1 soonish? It's been two months since > 1.7.0. You know what they say: release early, release often! Yes, that's exactly what I thought as I brought the pathing discussion to the list again. The milestone 1.7.1 [1] has only 4 open tickets left. > We could merge in these additional small changes that are on trunk: > > > - Add new "use_7z yes" port option to allow distfiles in 7z format > (#18521, ryandesign) > > - port lint no longer requires variable master_sites if the port > has no > distfiles (#18479, ryandesign) > > - Upgrade will no longer accept ports that are not installed > (but it still > installs new ports as dependencies if needed). In particular, > this means > that "port upgrade all" will no longer proceed to install every > available port. (jmr in r46052) I would be fine with merging these three above. > - Add mkdtemp Tcl command to create temporary directories. > (#17181, perry) Is there anything using this? This is base internal code, so I don't think it is reasonable to merge this without merging code which uses it. > These are the remaining changes on trunk that are described in the > ChangeLog; not sure whether should merge these. In particular I would > like to not merge changes that significantly change the output of a > port command (like #11891). > [...] Most of these are new features and the like. Do not merge them. > There are probably also other changes on trunk that are not described > in the ChangeLog. Anything that has changed and was not added to the ChangeLog is usually not worth for merging. Rainer [1] http://trac.macports.org/query?status=assigned&status=new&status=reopened&group=status&milestone=MacPorts+1.7.1 From raimue at macports.org Wed Feb 18 07:46:39 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 18 Feb 2009 16:46:39 +0100 Subject: gsoc08-privileges branch merged In-Reply-To: <2715115E-620C-4723-B831-9DF11D29576A@apple.com> References: <499BD7EC.9090701@macports.org> <10CED60C-A72F-46C2-B357-9FD706CB9FCA@macports.org> <2715115E-620C-4723-B831-9DF11D29576A@apple.com> Message-ID: <499C2D5F.3010104@macports.org> William Siegrist wrote: > On Feb 18, 2009, at 3:03 AM, Ryan Schmidt wrote: >> You know, I was never comfortable with this default location. It >> perpetuates the misperception that MacPorts installs into /opt when >> in fact it installs into /opt/local. But making the default location >> for non-root activities ~/.macports/opt/local doesn't make sense >> either, does it? Sigh. :-/ >> >> > > Why not just ~/.macports? That would seem to match other software, > like ssh and subversion. To support multiple installs of MacPorts on the same machine the path has to be unique. The best to come up with is ~/.macports/${prefix} as ${prefix} is unique to each installation. Rainer From ryandesign at macports.org Wed Feb 18 09:41:56 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 18 Feb 2009 11:41:56 -0600 Subject: [46948] trunk/dports/mail/dovecot/Portfile In-Reply-To: References: <20090218082551.09456FBE784@beta.macosforge.org> Message-ID: On Feb 18, 2009, at 08:46, Daniel J. Luke wrote: > On Feb 18, 2009, at 3:25 AM, ryandesign at macports.org wrote: >> dovecot: whitespace changes (tabs to spaces) >> Modified Paths >> ? trunk/dports/mail/dovecot/Portfile >> Diff >> Modified: trunk/dports/mail/dovecot/Portfile (46947 => 46948) > > > ouch, whitespace changes on someone else's Portfile after > maintainer timeout? Well, yes, I know... :/ I usually complain about that when other people do it, don't I? In my defense, the portfile was already mostly space-indented, there were just a few tab-indented lines which felt wrong. From mcalhoun at macports.org Wed Feb 18 10:06:17 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Wed, 18 Feb 2009 18:06:17 +0000 (UTC) Subject: MacPorts 1.7.1 References: <465D826E-7631-41EC-958C-8478DCAD809E@macports.org> <499C2C72.7080808@macports.org> Message-ID: Rainer M?ller writes: > > Ryan Schmidt wrote: > > > - Add mkdtemp Tcl command to create temporary directories. > > (#17181, perry) > > Is there anything using this? This is base internal code, so I don't > think it is reasonable to merge this without merging code which uses it. I would like to try to use mkdtemp in the muniversal PortGroup. I can not seem to find a consistent way on all platforms to test if certain binaries can run on a given platform (e.g. G4 processors can't run ppc64 code). In the directory created by mkdtemp, I was thinking of compiling a trivial program and seeing if it ran. -Marcus From ryandesign at macports.org Wed Feb 18 10:20:15 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 18 Feb 2009 12:20:15 -0600 Subject: MacPorts 1.7.1 In-Reply-To: References: <465D826E-7631-41EC-958C-8478DCAD809E@macports.org> <499C2C72.7080808@macports.org> Message-ID: <8E2B2694-DCBA-458D-ACA1-FC25FABBE71B@macports.org> On Feb 18, 2009, at 12:06, Marcus Calhoun-Lopez wrote: > Rainer M?ller writes: > >> Ryan Schmidt wrote: >> >>> - Add mkdtemp Tcl command to create temporary directories. >>> (#17181, perry) >> >> Is there anything using this? This is base internal code, so I don't >> think it is reasonable to merge this without merging code which >> uses it. > > I would like to try to use mkdtemp in the muniversal PortGroup. > I can not seem to find a consistent way on all platforms to test if > certain > binaries can run on a given platform (e.g. G4 processors can't run > ppc64 code). > > In the directory created by mkdtemp, I was thinking of compiling a > trivial > program and seeing if it ran. I will use mkdtemp in the use_dmg code in base, and there is one port where I create a temporary directory to mount a disk image. http://trac.macports.org/browser/users/ryandesign/minivmac/Portfile I figured adding mkdtemp to 1.7.1 wouldn't hurt anything since it's a new function so it shouldn't hurt any existing code. From perry at macports.org Wed Feb 18 10:47:19 2009 From: perry at macports.org (Perry Lee) Date: Wed, 18 Feb 2009 10:47:19 -0800 Subject: MacPorts 1.7.1 In-Reply-To: <465D826E-7631-41EC-958C-8478DCAD809E@macports.org> References: <465D826E-7631-41EC-958C-8478DCAD809E@macports.org> Message-ID: On Feb 18, 2009, at 1:03 AM, Ryan Schmidt wrote: > There are probably also other changes on trunk that are not > described in the ChangeLog. You may also want to merge in r46810 (it fixes a bug in wrapline). As far as I can tell, it applies to the 1.7 branch as well. From ryandesign at macports.org Wed Feb 18 16:18:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 18 Feb 2009 18:18:08 -0600 Subject: [46975] trunk/base/portmgr/packaging/packageall.tcl In-Reply-To: <20090218222122.6FEA6FCFBC5@beta.macosforge.org> References: <20090218222122.6FEA6FCFBC5@beta.macosforge.org> Message-ID: On Feb 18, 2009, at 16:21, raimue at macports.org wrote: > Revision: 46975 > http://trac.macports.org/changeset/46975 > Author: raimue at macports.org > Date: 2009-02-18 14:21:21 -0800 (Wed, 18 Feb 2009) > Log Message: > ----------- > portmgr/packaging/packageall.tcl: > Fix typo introduced in r46958 Well good grief. :) Thanks for noticing. > Modified Paths: > -------------- > trunk/base/portmgr/packaging/packageall.tcl > > Modified: trunk/base/portmgr/packaging/packageall.tcl > =================================================================== > --- trunk/base/portmgr/packaging/packageall.tcl 2009-02-18 22:09:20 > UTC (rev 46974) > +++ trunk/base/portmgr/packaging/packageall.tcl 2009-02-18 22:21:21 > UTC (rev 46975) > @@ -262,7 +262,7 @@ > # - keep distfiles outside /opt/local so we don't have to keep > fetching them. > # - send out an email to the maintainer if any errors occurred. > > - ui_msg "removing /optlocal" > + ui_msg "removing /opt/local" > #unset ui_options(ports_verbose) > if {[catch {system "rm -Rf /opt/local"} error]} { > puts stderr "Internal error: $error" From blb at macports.org Wed Feb 18 16:56:01 2009 From: blb at macports.org (Bryan Blackburn) Date: Wed, 18 Feb 2009 17:56:01 -0700 Subject: gsoc08-privileges branch merged In-Reply-To: <499BD7EC.9090701@macports.org> References: <499BD7EC.9090701@macports.org> Message-ID: <20090219005601.GH1058@ninagal.withay.com> On Wed, Feb 18, 2009 at 08:42:04PM +1100, Joshua Root said: > I just finished merging the changes from the gsoc08-privileges branch > back into trunk. This of course has the potential for breakage, though I > changed the default back to running as root, so you should hopefully not > see any problems unless you pass --with-macports-user=you to configure. My initial observations: - the added 'make group' is Darwin-specific since it uses dseditgroup, do we want to make that more portable or document it's Darwin-only? Or Mac-only if it isn't available on puredarwin either. - from MP_CHECK_NOROOTPRIVILEGES, when I use --with-no-root-privileges and user/group selections, I get an error: checking for Tcl package directory... ./configure: line 6995: ~blb/Library/Tcl: No such file or directory ~blb/Library/Tcl but since I also used --with-tclpackage it used that and installed fine. - in MP_CHECK_RUNUSER - since RUNUSR is currently hardcoded as root, should we disable the configure option for now? Also, remove it from macports.conf.in, until it works (so nobody sees it there and thinks they can change it) - shall we remove all the '# start/end gsoc08-privileges' comments? - in portutil.tcl: should we use 'file nativename ~${username}' instead of guessing /Users or /home? Bryan [...] > - Josh From jmr at macports.org Wed Feb 18 17:18:50 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 19 Feb 2009 12:18:50 +1100 Subject: gsoc08-privileges branch merged In-Reply-To: References: <499BD7EC.9090701@macports.org> Message-ID: <499CB37A.5000500@macports.org> Paul Magrath wrote: > Hey Josh, > > If you have any questions, give me a shout. I'm still around I just > haven't had much time - I'm in final year of my Computer Science course > and workload is crazy. Sure, no worries. >> I just finished merging the changes from the gsoc08-privileges branch >> back into trunk. This of course has the potential for breakage, though I >> changed the default back to running as root, so you should hopefully not >> see any problems unless you pass --with-macports-user=you to configure. >> >> The privilege dropping has its issues. For example, if you start port >> with sudo, the configure and build phases will be run as root. But then >> root privileges will be dropped by the time it tries to clean after >> installing, with predictable results. > > I was aware of this problem. The solution is to elevate privileges if > clean fails, which I thought I'd written code to do so. However, as I'm > sure you noticed, I haven't had time to keep the branch up to date so it > is entirely possible that the code has been bypassed in the flow of > control somehow. Seems like it would also make sense to drop privileges for configure and build if possible? >> So there's still some tweaking to be done, but I figured the sooner it >> was merged, the less bitrot there'd be to deal with. > > Agreed, thanks actually for going ahead. I had meant to get it merged > into trunk at the end of the summer but with all the v1.7 release stuff > and the change in port managers, it didn't really seem the best time to > merge in a large amount of code. I amn't sure if you have seen: > https://trac.macports.org/wiki/gsoc08-privileges , if not it might be > worth a read. Right, it made sense to wait to merge this until after 1.7 was branched off. Feel free to improve things directly on trunk now, if you ever have a spare moment. :-) - Josh From jmr at macports.org Wed Feb 18 17:50:40 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 19 Feb 2009 12:50:40 +1100 Subject: MacPorts 1.7.1 In-Reply-To: <499C22B3.9090204@macports.org> References: <465D826E-7631-41EC-958C-8478DCAD809E@macports.org> <499C22B3.9090204@macports.org> Message-ID: <499CBAF0.4050609@macports.org> David Evans wrote: > Ryan Schmidt wrote: >> Has anyone been running the 1.7 branch? Found any problems with it? >> Should we release MacPorts 1.7.1 soonish? It's been two months since >> 1.7.0. You know what they say: release early, release often! The roadmap gives a good idea of what we want to go into 1.7.1, and if it doesn't, it should. :-) I was hoping to take care of #16085 for 1.7.1. >> - Make dependencies in port upgrade respect variants as specified >> (in order of precedence) on command line, latest installed >> version, or variants.conf . (#8221, gwhitney) >> > I'd like to make a strong pitch to add this one as without it it is > impossible to correctly upgrade custom MacPorts installations that > depend on > on global variants such as +no_x11 or +system_x11. Without being able > to upgrade, the global variants are next to useless. The next release is going to have to wait a while if the fix for #8221 is going to be in it. It may sound like "just a bugfix", but it changes a lot of code, and it has not yet been sufficiently debugged. - Josh From shreevatsa.public at gmail.com Thu Feb 19 05:32:46 2009 From: shreevatsa.public at gmail.com (Shreevatsa R) Date: Thu, 19 Feb 2009 08:32:46 -0500 Subject: Trac displaying .diff files strangely? Message-ID: <7675454e0902190532j2eece9a8lea5b21d5f52d0fb8@mail.gmail.com> Hello, Did something change in Trac recently that makes it show files of some types differently? For example if I look at http://trac.macports.org/browser/trunk/dports/editors/vim/Portfile or http://trac.macports.org/browser/trunk/dports/editors/vim/files/patchlist I see a proper Trac page with line numbers and colours and the MacPorts logo at the top and everything, but if I look at http://trac.macports.org/browser/trunk/dports/editors/vim/files/patch-src_auto_configure.diff it shows me a bare HTML page. Most importantly, it is missing the link at the bottom that provides a download in the original format. Similarly with http://trac.macports.org/browser/trunk/dports/net/pidgin/files/autogen.sh (shown as a proper Trac page) and http://trac.macports.org/browser/trunk/dports/net/pidgin/files/gtkdocklet-quartz.diff (shown as a bare page). (The pattern seems to be ".diff", but I don't know what to make of it.) This makes it much harder to download the patches over the web; it would be nice if this were changed back. Thanks, -Shreevatsa From shreevatsa.public at gmail.com Thu Feb 19 05:35:50 2009 From: shreevatsa.public at gmail.com (Shreevatsa R) Date: Thu, 19 Feb 2009 08:35:50 -0500 Subject: Trac displaying .diff files strangely? In-Reply-To: <7675454e0902190532j2eece9a8lea5b21d5f52d0fb8@mail.gmail.com> References: <7675454e0902190532j2eece9a8lea5b21d5f52d0fb8@mail.gmail.com> Message-ID: <7675454e0902190535w477a6456s3690309e3aabda0e@mail.gmail.com> Looking at the source more carefully, it seems the difference is that with the .diff files, the source of the HTML page contains only a
...
, not the rest of the page. I still don't know an explanation for this behaviour. On Thu, Feb 19, 2009 at 8:32 AM, Shreevatsa R wrote: > Hello, > > Did something change in Trac recently that makes it show files of some > types differently? > > For example if I look at > http://trac.macports.org/browser/trunk/dports/editors/vim/Portfile or > http://trac.macports.org/browser/trunk/dports/editors/vim/files/patchlist > I see a proper Trac page with line numbers and colours and the > MacPorts logo at the top and everything, but if I look at > http://trac.macports.org/browser/trunk/dports/editors/vim/files/patch-src_auto_configure.diff > it shows me a bare HTML page. Most importantly, it is missing the link > at the bottom that provides a download in the original format. > Similarly with http://trac.macports.org/browser/trunk/dports/net/pidgin/files/autogen.sh > (shown as a proper Trac page) and > http://trac.macports.org/browser/trunk/dports/net/pidgin/files/gtkdocklet-quartz.diff > (shown as a bare page). (The pattern seems to be ".diff", but I don't > know what to make of it.) > > This makes it much harder to download the patches over the web; it > would be nice if this were changed back. > > Thanks, > -Shreevatsa > From jmr at macports.org Thu Feb 19 06:35:58 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 20 Feb 2009 01:35:58 +1100 Subject: Trac displaying .diff files strangely? In-Reply-To: <7675454e0902190532j2eece9a8lea5b21d5f52d0fb8@mail.gmail.com> References: <7675454e0902190532j2eece9a8lea5b21d5f52d0fb8@mail.gmail.com> Message-ID: <499D6E4E.8020709@macports.org> Shreevatsa R wrote: > Hello, > > Did something change in Trac recently that makes it show files of some > types differently? > > For example if I look at > http://trac.macports.org/browser/trunk/dports/editors/vim/Portfile or > http://trac.macports.org/browser/trunk/dports/editors/vim/files/patchlist > I see a proper Trac page with line numbers and colours and the > MacPorts logo at the top and everything, but if I look at > http://trac.macports.org/browser/trunk/dports/editors/vim/files/patch-src_auto_configure.diff > it shows me a bare HTML page. Most importantly, it is missing the link > at the bottom that provides a download in the original format. > Similarly with http://trac.macports.org/browser/trunk/dports/net/pidgin/files/autogen.sh > (shown as a proper Trac page) and > http://trac.macports.org/browser/trunk/dports/net/pidgin/files/gtkdocklet-quartz.diff > (shown as a bare page). (The pattern seems to be ".diff", but I don't > know what to make of it.) Seems fine here. - Josh From wsiegrist at apple.com Thu Feb 19 07:49:45 2009 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 19 Feb 2009 07:49:45 -0800 Subject: Trac displaying .diff files strangely? In-Reply-To: <499D6E4E.8020709@macports.org> References: <7675454e0902190532j2eece9a8lea5b21d5f52d0fb8@mail.gmail.com> <499D6E4E.8020709@macports.org> Message-ID: <7F3DB321-7023-47C2-837E-A7CFEEA7F1DC@apple.com> On Feb 19, 2009, at 6:35 AM, Joshua Root wrote: > Shreevatsa R wrote: >> Hello, >> >> Did something change in Trac recently that makes it show files of >> some >> types differently? >> >> For example if I look at >> http://trac.macports.org/browser/trunk/dports/editors/vim/Portfile or >> http://trac.macports.org/browser/trunk/dports/editors/vim/files/patchlist >> I see a proper Trac page with line numbers and colours and the >> MacPorts logo at the top and everything, but if I look at >> http://trac.macports.org/browser/trunk/dports/editors/vim/files/patch-src_auto_configure.diff >> it shows me a bare HTML page. Most importantly, it is missing the >> link >> at the bottom that provides a download in the original format. >> Similarly with http://trac.macports.org/browser/trunk/dports/net/pidgin/files/autogen.sh >> (shown as a proper Trac page) and >> http://trac.macports.org/browser/trunk/dports/net/pidgin/files/gtkdocklet-quartz.diff >> (shown as a bare page). (The pattern seems to be ".diff", but I don't >> know what to make of it.) > > Seems fine here. > Also fine when I view them... Nothing has changed recently for Trac except for some server-side caching changes. Do the pages still look wrong to you? What browser? Version? OS? etc. Thanks -Bill From shreevatsa.public at gmail.com Thu Feb 19 08:26:31 2009 From: shreevatsa.public at gmail.com (Shreevatsa R) Date: Thu, 19 Feb 2009 11:26:31 -0500 Subject: Trac displaying .diff files strangely? In-Reply-To: <7F3DB321-7023-47C2-837E-A7CFEEA7F1DC@apple.com> References: <7675454e0902190532j2eece9a8lea5b21d5f52d0fb8@mail.gmail.com> <499D6E4E.8020709@macports.org> <7F3DB321-7023-47C2-837E-A7CFEEA7F1DC@apple.com> Message-ID: <7675454e0902190826u2a3f8df7p8e806b7c0dd70210@mail.gmail.com> On Thu, Feb 19, 2009 at 10:49 AM, William Siegrist wrote: > On Feb 19, 2009, at 6:35 AM, Joshua Root wrote: > >> Shreevatsa R wrote: >>> >>> Hello, >>> >>> Did something change in Trac recently that makes it show files of some >>> types differently? >>> >>> For example if I look at >>> http://trac.macports.org/browser/trunk/dports/editors/vim/Portfile or >>> http://trac.macports.org/browser/trunk/dports/editors/vim/files/patchlist >>> I see a proper Trac page with line numbers and colours and the >>> MacPorts logo at the top and everything, but if I look at >>> >>> http://trac.macports.org/browser/trunk/dports/editors/vim/files/patch-src_auto_configure.diff >>> it shows me a bare HTML page. Most importantly, it is missing the link >>> at the bottom that provides a download in the original format. >>> Similarly with >>> http://trac.macports.org/browser/trunk/dports/net/pidgin/files/autogen.sh >>> (shown as a proper Trac page) and >>> >>> http://trac.macports.org/browser/trunk/dports/net/pidgin/files/gtkdocklet-quartz.diff >>> (shown as a bare page). (The pattern seems to be ".diff", but I don't >>> know what to make of it.) >> >> Seems fine here. >> > > Also fine when I view them... Nothing has changed recently for Trac except > for some server-side caching changes. Do the pages still look wrong to you? > What browser? Version? OS? etc. Yes, it still looks wrong to me, both on my (Mac) laptop and using curl/wget on an unrelated Linux machine over SSH (the source starts with " References: <7675454e0902190532j2eece9a8lea5b21d5f52d0fb8@mail.gmail.com> <499D6E4E.8020709@macports.org> <7F3DB321-7023-47C2-837E-A7CFEEA7F1DC@apple.com> <7675454e0902190826u2a3f8df7p8e806b7c0dd70210@mail.gmail.com> Message-ID: <499D8BB5.4070308@macports.org> Shreevatsa R wrote: > Yes, it still looks wrong to me, both on my (Mac) laptop and using > curl/wget on an unrelated Linux machine over SSH (the source starts > with " thought it might be some higher-level cache, but I asked my friend in > Waterloo (Canada) to check and he also sees the same results as I do. > So perhaps it's something to do with Trac's server-side caching after all? I was able to reproduce this when using curl, but when I viewed the page in Firefox/Safari everything was alright. The problem is that Trac changes content depending on whether you are logged in or not. Now I can also reproduce the behavior in Firefox/Safari when I am logged out. Rainer From jmr at macports.org Thu Feb 19 08:42:30 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 20 Feb 2009 03:42:30 +1100 Subject: Trac displaying .diff files strangely? In-Reply-To: <7675454e0902190826u2a3f8df7p8e806b7c0dd70210@mail.gmail.com> References: <7675454e0902190532j2eece9a8lea5b21d5f52d0fb8@mail.gmail.com> <499D6E4E.8020709@macports.org> <7F3DB321-7023-47C2-837E-A7CFEEA7F1DC@apple.com> <7675454e0902190826u2a3f8df7p8e806b7c0dd70210@mail.gmail.com> Message-ID: <499D8BF6.1010203@macports.org> Shreevatsa R wrote: > On Thu, Feb 19, 2009 at 10:49 AM, William Siegrist wrote: >> Also fine when I view them... Nothing has changed recently for Trac except >> for some server-side caching changes. Do the pages still look wrong to you? >> What browser? Version? OS? etc. > > Yes, it still looks wrong to me, both on my (Mac) laptop and using > curl/wget on an unrelated Linux machine over SSH (the source starts > with " thought it might be some higher-level cache, but I asked my friend in > Waterloo (Canada) to check and he also sees the same results as I do. > So perhaps it's something to do with Trac's server-side caching after all? OK, I see the problem if I'm not logged in. - Josh From wsiegrist at apple.com Thu Feb 19 08:44:22 2009 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 19 Feb 2009 08:44:22 -0800 Subject: Trac displaying .diff files strangely? In-Reply-To: <7675454e0902190826u2a3f8df7p8e806b7c0dd70210@mail.gmail.com> References: <7675454e0902190532j2eece9a8lea5b21d5f52d0fb8@mail.gmail.com> <499D6E4E.8020709@macports.org> <7F3DB321-7023-47C2-837E-A7CFEEA7F1DC@apple.com> <7675454e0902190826u2a3f8df7p8e806b7c0dd70210@mail.gmail.com> Message-ID: <6E7C7FC0-635D-4ADE-8896-76C8E790991E@apple.com> On Feb 19, 2009, at 8:26 AM, Shreevatsa R wrote: > On Thu, Feb 19, 2009 at 10:49 AM, William Siegrist > wrote: >> On Feb 19, 2009, at 6:35 AM, Joshua Root wrote: >> >>> Shreevatsa R wrote: >>>> >>>> Hello, >>>> >>>> Did something change in Trac recently that makes it show files of >>>> some >>>> types differently? >>>> >>>> For example if I look at >>>> http://trac.macports.org/browser/trunk/dports/editors/vim/ >>>> Portfile or >>>> http://trac.macports.org/browser/trunk/dports/editors/vim/files/patchlist >>>> I see a proper Trac page with line numbers and colours and the >>>> MacPorts logo at the top and everything, but if I look at >>>> >>>> http://trac.macports.org/browser/trunk/dports/editors/vim/files/patch-src_auto_configure.diff >>>> it shows me a bare HTML page. Most importantly, it is missing the >>>> link >>>> at the bottom that provides a download in the original format. >>>> Similarly with >>>> http://trac.macports.org/browser/trunk/dports/net/pidgin/files/autogen.sh >>>> (shown as a proper Trac page) and >>>> >>>> http://trac.macports.org/browser/trunk/dports/net/pidgin/files/gtkdocklet-quartz.diff >>>> (shown as a bare page). (The pattern seems to be ".diff", but I >>>> don't >>>> know what to make of it.) >>> >>> Seems fine here. >>> >> >> Also fine when I view them... Nothing has changed recently for Trac >> except >> for some server-side caching changes. Do the pages still look wrong >> to you? >> What browser? Version? OS? etc. > > Yes, it still looks wrong to me, both on my (Mac) laptop and using > curl/wget on an unrelated Linux machine over SSH (the source starts > with " thought it might be some higher-level cache, but I asked my friend in > Waterloo (Canada) to check and he also sees the same results as I do. > So perhaps it's something to do with Trac's server-side caching > after all? > Which browser? Which version of Mac OS? Can you send a screenshot? -Bill From wsiegrist at apple.com Thu Feb 19 08:47:23 2009 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 19 Feb 2009 08:47:23 -0800 Subject: Trac displaying .diff files strangely? In-Reply-To: <499D8BF6.1010203@macports.org> References: <7675454e0902190532j2eece9a8lea5b21d5f52d0fb8@mail.gmail.com> <499D6E4E.8020709@macports.org> <7F3DB321-7023-47C2-837E-A7CFEEA7F1DC@apple.com> <7675454e0902190826u2a3f8df7p8e806b7c0dd70210@mail.gmail.com> <499D8BF6.1010203@macports.org> Message-ID: On Feb 19, 2009, at 8:42 AM, Joshua Root wrote: > Shreevatsa R wrote: >> On Thu, Feb 19, 2009 at 10:49 AM, William Siegrist > > wrote: >>> Also fine when I view them... Nothing has changed recently for >>> Trac except >>> for some server-side caching changes. Do the pages still look >>> wrong to you? >>> What browser? Version? OS? etc. >> >> Yes, it still looks wrong to me, both on my (Mac) laptop and using >> curl/wget on an unrelated Linux machine over SSH (the source starts >> with "> thought it might be some higher-level cache, but I asked my friend in >> Waterloo (Canada) to check and he also sees the same results as I do. >> So perhaps it's something to do with Trac's server-side caching >> after all? > > OK, I see the problem if I'm not logged in. > Ok yes, thats a bug in the caching plugin. I'll clean it up. -Bill From wsiegrist at apple.com Thu Feb 19 09:06:30 2009 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 19 Feb 2009 09:06:30 -0800 Subject: Trac displaying .diff files strangely? In-Reply-To: References: <7675454e0902190532j2eece9a8lea5b21d5f52d0fb8@mail.gmail.com> <499D6E4E.8020709@macports.org> <7F3DB321-7023-47C2-837E-A7CFEEA7F1DC@apple.com> <7675454e0902190826u2a3f8df7p8e806b7c0dd70210@mail.gmail.com> <499D8BF6.1010203@macports.org> Message-ID: On Feb 19, 2009, at 8:47 AM, William Siegrist wrote: > > On Feb 19, 2009, at 8:42 AM, Joshua Root wrote: > >> Shreevatsa R wrote: >>> On Thu, Feb 19, 2009 at 10:49 AM, William Siegrist >> > wrote: >>>> Also fine when I view them... Nothing has changed recently for >>>> Trac except >>>> for some server-side caching changes. Do the pages still look >>>> wrong to you? >>>> What browser? Version? OS? etc. >>> >>> Yes, it still looks wrong to me, both on my (Mac) laptop and using >>> curl/wget on an unrelated Linux machine over SSH (the source starts >>> with ">> thought it might be some higher-level cache, but I asked my friend >>> in >>> Waterloo (Canada) to check and he also sees the same results as I >>> do. >>> So perhaps it's something to do with Trac's server-side caching >>> after all? >> >> OK, I see the problem if I'm not logged in. >> > > > Ok yes, thats a bug in the caching plugin. I'll clean it up. > I fixed the plugin. Please verify that it works for you now. Thanks, -Bill From shreevatsa.public at gmail.com Thu Feb 19 09:31:54 2009 From: shreevatsa.public at gmail.com (Shreevatsa R) Date: Thu, 19 Feb 2009 12:31:54 -0500 Subject: Trac displaying .diff files strangely? In-Reply-To: References: <7675454e0902190532j2eece9a8lea5b21d5f52d0fb8@mail.gmail.com> <499D6E4E.8020709@macports.org> <7F3DB321-7023-47C2-837E-A7CFEEA7F1DC@apple.com> <7675454e0902190826u2a3f8df7p8e806b7c0dd70210@mail.gmail.com> <499D8BF6.1010203@macports.org> Message-ID: <7675454e0902190931qb2d1698r3711cce219cd8f6d@mail.gmail.com> On Thu, Feb 19, 2009 at 12:06 PM, William Siegrist wrote: > On Feb 19, 2009, at 8:47 AM, William Siegrist wrote: [...] >> Ok yes, thats a bug in the caching plugin. I'll clean it up. >> > > > I fixed the plugin. Please verify that it works for you now. Yes, it works fine now. Thanks! From jeremy at lavergne.gotdns.org Thu Feb 19 11:05:33 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 19 Feb 2009 14:05:33 -0500 Subject: [47003] trunk/dports/python In-Reply-To: <20090219190146.24301FE89DC@beta.macosforge.org> References: <20090219190146.24301FE89DC@beta.macosforge.org> Message-ID: Just noticed I've got some /opt/local paths hardcoded in this one. Hopping on them. On Feb 19, 2009, at 2:01 PM, snc at macports.org wrote: Revision47003Authorsnc at macports.orgDate2009-02-19 11:01:44 -0800 (Thu, 19 Feb 2009)Log Message created py25-shogun, ticket #16852 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Thu Feb 19 11:09:22 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 19 Feb 2009 14:09:22 -0500 Subject: wiki links: trac:path Message-ID: <7C1C38EF-657B-4A8E-9014-ABB9909084B3@lavergne.gotdns.org> These are linking to edgewall.org presently. anyone able to fix it? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Thu Feb 19 11:11:01 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 19 Feb 2009 14:11:01 -0500 Subject: wiki links: trac:path In-Reply-To: <7C1C38EF-657B-4A8E-9014-ABB9909084B3@lavergne.gotdns.org> References: <7C1C38EF-657B-4A8E-9014-ABB9909084B3@lavergne.gotdns.org> Message-ID: Oh I'm crazy. I should be using source:path instead of trac:path. False alarm! On Feb 19, 2009, at 2:09 PM, Jeremy Lavergne wrote: These are linking to edgewall.org presently. anyone able to fix it? -------------- 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 Feb 19 13:18:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 19 Feb 2009 15:18:24 -0600 Subject: [47001] trunk/dports/lang/gnat-gcc/Portfile In-Reply-To: <20090219171132.D0001FE81EB@beta.macosforge.org> References: <20090219171132.D0001FE81EB@beta.macosforge.org> Message-ID: <17554EA6-7649-410B-964A-1151EBA2F683@macports.org> On Feb 19, 2009, at 11:11, krischik at macports.org wrote: > Revision: 47001 > http://trac.macports.org/changeset/47001 > Author: krischik at macports.org > Date: 2009-02-19 09:11:31 -0800 (Thu, 19 Feb 2009) > Log Message: > ----------- > Fix file names > > Modified Paths: > -------------- > trunk/dports/lang/gnat-gcc/Portfile > > Modified: trunk/dports/lang/gnat-gcc/Portfile > =================================================================== > --- trunk/dports/lang/gnat-gcc/Portfile 2009-02-19 16:46:21 UTC > (rev 47000) > +++ trunk/dports/lang/gnat-gcc/Portfile 2009-02-19 17:11:31 UTC > (rev 47001) > @@ -5,7 +5,7 @@ > > name gnat-gcc > version 4.3.3 > -revision 3 > +revision 4 > platforms darwin > categories lang > maintainers macports.org:krischik > @@ -46,6 +46,8 @@ > > worksrcdir build > > +build.args --jobs=4 Is this for parallel building? If so, would there be a way to respect the user's choice of build_make_jobs from macports.conf? > pre-configure { > file mkdir ${worksrcpath} > } > @@ -139,10 +141,8 @@ > # Ada is the only language apart from C which is self hosted - > meaning: you need > # an ada compiler to compile ada. hence it is just a variant. > # > -variant > macada \ > - description "Adds Ada support using the MacAda compiler to > bootstrap!" { > - #configure.args-delete --enable-languages=c,c++,objc,obj-c+ > +,java,fortran > - #configure.args-append --enable-languages=c,c++,ada,objc,obj- > c++,java,fortran > +variant macada \ > + description "Uses MacAda compiler to bootstrap!" { > configure.cc /usr/local/ada-4.3/bin/gcc > configure.cpp /usr/local/ada-4.3/bin/cpp > configure.cxx /usr/local/ada-4.3/bin/g++ > @@ -152,14 +152,12 @@ > configure.env-append GNATBIND=/usr/local/ada-4.3/bin/gnatbind > } > > -variant > ada > \ > - description "Adds Ada support using the MacPorts Ada compiler > to bootstrap!" { > - #configure.args-delete --enable-languages=c,c++,objc,obj-c+ > +,java,fortran > - #configure.args-append --enable-languages=c,c++,ada,objc,obj- > c++,java,fortran > - configure.cc /opt/local/bin/gcc-mp-4.3 > - configure.cpp /opt/local/bin/cpp-mp-4.3 > - configure.cxx /opt/local/bin/g++-mp-4.3 > - configure.objc /opt/local/bin/gcc-mp-4.3 > +variant ada \ > + description "Uses the MacPorts Ada compiler to bootstrap!" { > + configure.cc /opt/local/bin/gcc-gnat-4.3 > + configure.cpp /opt/local/bin/cpp-gnat-4.3 > + configure.cxx /opt/local/bin/g++-gnat-4.3 > + configure.objc /opt/local/bin/gcc-gnat-4.3 > configure.env-append PATH=/opt/local/bin:$env(PATH) > configure.env-append GNATMAKE=/opt/local/bin/gnatmake > configure.env-append GNATBIND=/opt/local/bin/gnatbind I didn't see this before, but please use ${prefix} instead of /opt/ local. MacPorts might be installed elsewhere. From raimue at macports.org Thu Feb 19 13:38:52 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 19 Feb 2009 22:38:52 +0100 Subject: [47001] trunk/dports/lang/gnat-gcc/Portfile In-Reply-To: <17554EA6-7649-410B-964A-1151EBA2F683@macports.org> References: <20090219171132.D0001FE81EB@beta.macosforge.org> <17554EA6-7649-410B-964A-1151EBA2F683@macports.org> Message-ID: <499DD16C.7030307@macports.org> Ryan Schmidt wrote: > On Feb 19, 2009, at 11:11, krischik at macports.org wrote: [...] >> +build.args --jobs=4 > > Is this for parallel building? If so, would there be a way to respect > the user's choice of build_make_jobs from macports.conf? build.args --jobs=${build.jobs} Rainer From raimue at macports.org Thu Feb 19 16:51:48 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Fri, 20 Feb 2009 01:51:48 +0100 Subject: [47019] trunk/dports/sysutils/zmq/Portfile In-Reply-To: <20090220004058.2CF16FEEB73@beta.macosforge.org> References: <20090220004058.2CF16FEEB73@beta.macosforge.org> Message-ID: <499DFEA4.9030202@macports.org> brett at macports.org wrote: > --- trunk/dports/sysutils/zmq/Portfile 2009-02-19 23:52:17 UTC (rev 47018) > +++ trunk/dports/sysutils/zmq/Portfile 2009-02-20 00:40:57 UTC (rev 47019) > @@ -18,7 +18,7 @@ > --with-c > > variant python description {build Python language binding} { > - depends_lib-append port:python26 > + depends_lib-append port:python_select > configure.args-append --with-python > } As Bryan already pointed out, python_select itself does not depend on any python version, so this dependency is not going to work. There is currently no better way than picking a specific python version. Rainer From ryandesign at macports.org Thu Feb 19 21:01:19 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 19 Feb 2009 23:01:19 -0600 Subject: [47020] trunk/dports/python In-Reply-To: <20090220015402.73CE5FF019E@beta.macosforge.org> References: <20090220015402.73CE5FF019E@beta.macosforge.org> Message-ID: <92BE9DA0-9212-4968-B804-F1CC904A8370@macports.org> On Feb 19, 2009, at 19:54, deric at macports.org wrote: > Revision: 47020 > http://trac.macports.org/changeset/47020 > Author: deric at macports.org > Date: 2009-02-19 17:54:01 -0800 (Thu, 19 Feb 2009) > Log Message: > ----------- > New port: py-icalendar for the python2.6 PortGroup. [snip] > +post-destroot { > + # install docs > + xinstall -m 644 -W ${worksrcpath}/ CHANGES.txt CREDITS.txt > HISTORY.txt INSTALL.txt LICENSE.txt README.txt TODO.txt \ > + ${destroot}/${prefix}/share/doc/${name} > + > + xinstall -m 644 -W ${worksrcpath}/doc example.txt > groupscheduled.ics groupscheduled.txt multiple.ics multiple.txt > small.ics small.txt \ > + ${destroot}/${prefix}/share/doc/${name} > +} Please remove the slash before ${prefix}. (${prefix} already begins with a slash.) From jmr at macports.org Thu Feb 19 21:21:11 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 20 Feb 2009 16:21:11 +1100 Subject: PortInfo lookup performance patch Message-ID: <499E3DC7.4000306@macports.org> I think the patch in is just about ready to go in. Does anyone have any suggestions or comments before it does? It won't be set in stone until 1.8 is released, but it would still be good to catch any issues sooner rather than later. - Josh From afb at macports.org Thu Feb 19 23:13:21 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri, 20 Feb 2009 08:13:21 +0100 Subject: [47019] trunk/dports/sysutils/zmq/Portfile In-Reply-To: <499DFEA4.9030202@macports.org> References: <20090220004058.2CF16FEEB73@beta.macosforge.org> <499DFEA4.9030202@macports.org> Message-ID: Rainer M?ller wrote: >> variant python description {build Python language binding} { >> - depends_lib-append port:python26 >> + depends_lib-append port:python_select >> configure.args-append --with-python >> } > > As Bryan already pointed out, python_select itself does not depend on > any python version, so this dependency is not going to work. There is > currently no better way than picking a specific python version. python_select does provide a "python" binary. It does this by using pythonXY-apple, probably not a _good_ idea but it should "work"... If you do pick a specific python version, then you need to patch out "python" with "pythonX.Y" everywhere - which might be very tedious. --anders From blb at macports.org Thu Feb 19 23:56:22 2009 From: blb at macports.org (Bryan Blackburn) Date: Fri, 20 Feb 2009 00:56:22 -0700 Subject: Whitespace and config values In-Reply-To: <20090213094441.GI1100@ninagal.withay.com> References: <20090213094441.GI1100@ninagal.withay.com> Message-ID: <20090220075622.GK675@ninagal.withay.com> On Fri, Feb 13, 2009 at 02:44:41AM -0700, Bryan Blackburn said: > Does anyone see any issue with the attached patch? It seems that parsing > macports.conf will leave trailing whitespace on values, hence some things > won't match "yes" because they are "yes " (see ticket #18460). I ask in > case someone is aware of any possible reason to keep trailing whitespace > within values... FYI, patched in r47034 on trunk and r47035 for 1.7 branch. > > Bryan > From ryandesign at macports.org Fri Feb 20 02:54:09 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 20 Feb 2009 04:54:09 -0600 Subject: [47019] trunk/dports/sysutils/zmq/Portfile In-Reply-To: References: <20090220004058.2CF16FEEB73@beta.macosforge.org> <499DFEA4.9030202@macports.org> Message-ID: <60F7D378-500A-4701-9942-E053B071E749@macports.org> On Feb 20, 2009, at 01:13, Anders F Bj?rklund wrote: > Rainer M?ller wrote: > >>> variant python description {build Python language binding} { >>> - depends_lib-append port:python26 >>> + depends_lib-append port:python_select >>> configure.args-append --with-python >>> } >> >> As Bryan already pointed out, python_select itself does not depend on >> any python version, so this dependency is not going to work. There is >> currently no better way than picking a specific python version. > > python_select does provide a "python" binary. It does this by using > pythonXY-apple, probably not a _good_ idea but it should "work"... > > If you do pick a specific python version, then you need to patch out > "python" with "pythonX.Y" everywhere - which might be very tedious. Perhaps tedious, but isn't it the only correct solution? Imagine I want to use port foo which requires python 2.5, and I also want to use port bar which requires python 2.4. If both ports use "python" (or "${prefix}/bin/python") then one or the other will break regardless of what I python_select, not to mention that as a user of foo or bar I don't want to have to python_select anything; I just want it to work out of the box. From afb at macports.org Fri Feb 20 03:28:27 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri, 20 Feb 2009 12:28:27 +0100 Subject: [47019] trunk/dports/sysutils/zmq/Portfile In-Reply-To: <60F7D378-500A-4701-9942-E053B071E749@macports.org> References: <20090220004058.2CF16FEEB73@beta.macosforge.org> <499DFEA4.9030202@macports.org> <60F7D378-500A-4701-9942-E053B071E749@macports.org> Message-ID: Ryan Schmidt wrote: >> If you do pick a specific python version, then you need to patch out >> "python" with "pythonX.Y" everywhere - which might be very tedious. > > Perhaps tedious, but isn't it the only correct solution? > > Imagine I want to use port foo which requires python 2.5, and I > also want to use port bar which requires python 2.4. If both ports > use "python" (or "${prefix}/bin/python") then one or the other will > break regardless of what I python_select, not to mention that as a > user of foo or bar I don't want to have to python_select anything; > I just want it to work out of the box. Sure, but if you just have something that requires any Python version then it would work with either version and "python" would be fine... You would still have to rebuild the port if you python_select another, but that's a different story. (other systems record python ABI used) --anders From captsolo at gmail.com Fri Feb 20 04:45:26 2009 From: captsolo at gmail.com (Uldis Bojars) Date: Fri, 20 Feb 2009 12:45:26 +0000 Subject: How to adapt ports to different versions of Python Message-ID: <64c81f720902200445i1b2592dat6fba24c063ee2be0@mail.gmail.com> Hi, I'd like to update py-rdflib, which is a pure-Python RDF library, to a new version. But currently it is set to use python24 via "PortGroup python24 1.0" which is not useful for me. What one is the right way for creating a port that works w python25: a) create a new port py25-rdflib and make it use "PortGroup python25" ? b) remove PortGroup from py-rdflib and add variants "python24" and "python25" to it ? Thanks, Uldis [ http://captsolo.net/info/ ] From rasmus at macports.org Fri Feb 20 05:36:42 2009 From: rasmus at macports.org (Rasmus Andersson) Date: Fri, 20 Feb 2009 14:36:42 +0100 Subject: How to adapt ports to different versions of Python In-Reply-To: <64c81f720902200445i1b2592dat6fba24c063ee2be0@mail.gmail.com> References: <64c81f720902200445i1b2592dat6fba24c063ee2be0@mail.gmail.com> Message-ID: I have the same question for my upcoming py-smisk package ? should I go with one package (py-smisk) having three variants (python24, python25, python26) or should I go with three different packages (py24-smisk, py25-smisk, py26-smisk)? Personally I would prefer to have a way of installing one package but getting support for several python versions. Dunno if variants would be the best way though (as the package would need to be part of one of the python groups). On Fri, Feb 20, 2009 at 13:45, Uldis Bojars wrote: > Hi, > > I'd like to update py-rdflib, which is a pure-Python RDF library, to a > new version. > But currently it is set to use python24 via "PortGroup python24 1.0" > which is not useful for me. > > What one is the right way for creating a port that works w python25: > > a) create a new port py25-rdflib and make it use "PortGroup python25" ? > > b) remove PortGroup from py-rdflib and add variants "python24" and > "python25" to it ? > > Thanks, > Uldis > > [ http://captsolo.net/info/ ] > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -- Rasmus Andersson From jmr at macports.org Fri Feb 20 06:23:21 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 21 Feb 2009 01:23:21 +1100 Subject: [47004] trunk/dports/games/gtkevemon/Portfile In-Reply-To: <20090219191444.9D143FE8ADD@beta.macosforge.org> References: <20090219191444.9D143FE8ADD@beta.macosforge.org> Message-ID: <499EBCD9.3060409@macports.org> snc at macports.org wrote: > Revision: 47004 > http://trac.macports.org/changeset/47004 > Author: snc at macports.org > Date: 2009-02-19 11:14:44 -0800 (Thu, 19 Feb 2009) > Log Message: > ----------- > cleaned up gtkevemon, maintainer timeout, ticket #18454 > > Modified Paths: > -------------- > trunk/dports/games/gtkevemon/Portfile > > Modified: trunk/dports/games/gtkevemon/Portfile > =================================================================== > --- trunk/dports/games/gtkevemon/Portfile 2009-02-19 19:01:44 UTC (rev 47003) > +++ trunk/dports/games/gtkevemon/Portfile 2009-02-19 19:14:44 UTC (rev 47004) > @@ -28,21 +28,10 @@ > svn.url svn://gtkevemon.battleclinic.com/GTKEVEMon/trunk/gtkevemon > svn.tag ${version} > > -pre-fetch { > - if {[file isdirectory ${workpath}/gtkevemon]} { > - if {![file isdirectory ${workpath}/gtkevemon/.svn]} { > - file delete -force ${workpath}/gtkevemon > - } > - } > -} > - > destroot { > - file mkdir ${destroot} > - file mkdir ${destroot}${prefix}/bin > - file copy ${worksrcpath}/src/gtkevemon ${destroot}${prefix}/bin/gtkevemon > + xinstall -W ${worksrcpath}/src -m 755 ${destroot}${prefix}/bin > } Please test before you commit; this changeset broke the port. - Josh From raimue at macports.org Fri Feb 20 06:49:26 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 20 Feb 2009 15:49:26 +0100 Subject: [47019] trunk/dports/sysutils/zmq/Portfile In-Reply-To: References: <20090220004058.2CF16FEEB73@beta.macosforge.org> <499DFEA4.9030202@macports.org> Message-ID: <499EC2F6.5050405@macports.org> Anders F Bj?rklund wrote: > Rainer M?ller wrote: > >>> variant python description {build Python language binding} { >>> - depends_lib-append port:python26 >>> + depends_lib-append port:python_select >>> configure.args-append --with-python >>> } >> As Bryan already pointed out, python_select itself does not depend on >> any python version, so this dependency is not going to work. There is >> currently no better way than picking a specific python version. > > python_select does provide a "python" binary. It does this by using > pythonXY-apple, probably not a _good_ idea but it should "work"... > > If you do pick a specific python version, then you need to patch out > "python" with "pythonX.Y" everywhere - which might be very tedious. This is marked as depends_lib so I assume it does more than just running python. If you just wanted to run something, it should be in depends_run and should be using bin: style dependency - if a binary of the system is also fine. But we prefer our own python over the system provided python and you have to pick a version. Rainer From macsforever2000 at macports.org Fri Feb 20 09:00:54 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Fri, 20 Feb 2009 10:00:54 -0700 Subject: How to adapt ports to different versions of Python In-Reply-To: <64c81f720902200445i1b2592dat6fba24c063ee2be0@mail.gmail.com> References: <64c81f720902200445i1b2592dat6fba24c063ee2be0@mail.gmail.com> Message-ID: <48940B6B-AFA0-443F-ACD5-CF49AACFEB0C@macports.org> On Feb 20, 2009, at 5:45 AM, Uldis Bojars wrote: > Hi, > > I'd like to update py-rdflib, which is a pure-Python RDF library, to a > new version. > But currently it is set to use python24 via "PortGroup python24 1.0" > which is not useful for me. > > What one is the right way for creating a port that works w python25: > > a) create a new port py25-rdflib and make it use "PortGroup > python25" ? This is the right way to go because it is a python library. > b) remove PortGroup from py-rdflib and add variants "python24" and > "python25" to it ? > > Thanks, > Uldis Cheers! Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From macsforever2000 at macports.org Fri Feb 20 09:01:15 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Fri, 20 Feb 2009 10:01:15 -0700 Subject: How to adapt ports to different versions of Python In-Reply-To: References: <64c81f720902200445i1b2592dat6fba24c063ee2be0@mail.gmail.com> Message-ID: On Feb 20, 2009, at 6:36 AM, Rasmus Andersson wrote: > I have the same question for my upcoming py-smisk package ? should I > go with one package (py-smisk) having three variants (python24, > python25, python26) or should I go with three different packages > (py24-smisk, py25-smisk, py26-smisk)? Without knowing anything about smisk, I would say you need to make three different ports. If the port was called "py-smisk", then it should only be for python 2.4 by convention. > > Personally I would prefer to have a way of installing one package but > getting support for several python versions. Dunno if variants would > be the best way though (as the package would need to be part of one of > the python groups). Cheers! Frank From captsolo at gmail.com Fri Feb 20 14:45:57 2009 From: captsolo at gmail.com (Uldis Bojars) Date: Fri, 20 Feb 2009 22:45:57 +0000 Subject: How to adapt ports to different versions of Python In-Reply-To: <48940B6B-AFA0-443F-ACD5-CF49AACFEB0C@macports.org> References: <64c81f720902200445i1b2592dat6fba24c063ee2be0@mail.gmail.com> <48940B6B-AFA0-443F-ACD5-CF49AACFEB0C@macports.org> Message-ID: <64c81f720902201445q6ae00b84keb25e55faa5cd049@mail.gmail.com> On Fri, Feb 20, 2009 at 5:00 PM, Frank Schima wrote: > What one is the right way for creating a port that works w python25: > a) create a new port py25-rdflib and make it use "PortGroup python25" ? > > This is the right way to go because it is a python library. > > b) remove PortGroup from py-rdflib and add variants "python24" and > "python25" to it ? Thanks, that's clear. I was hoping to keep one portfile instead of creating new for each version of python. Some ports (for example [1]) use variants python24, python25, ... instead of PortGroups. Could you please tell what is wrong with the other approach (used by ports such as [1])? [1] http://trac.macports.org/browser/trunk/dports/www/redland-bindings/Portfile Uldis [ http://captsolo.net/info/ ] From blb at macports.org Fri Feb 20 15:05:54 2009 From: blb at macports.org (Bryan Blackburn) Date: Fri, 20 Feb 2009 16:05:54 -0700 Subject: How to adapt ports to different versions of Python In-Reply-To: <64c81f720902201445q6ae00b84keb25e55faa5cd049@mail.gmail.com> References: <64c81f720902200445i1b2592dat6fba24c063ee2be0@mail.gmail.com> <48940B6B-AFA0-443F-ACD5-CF49AACFEB0C@macports.org> <64c81f720902201445q6ae00b84keb25e55faa5cd049@mail.gmail.com> Message-ID: <20090220230554.GE483@ninagal.withay.com> On Fri, Feb 20, 2009 at 10:45:57PM +0000, Uldis Bojars said: > On Fri, Feb 20, 2009 at 5:00 PM, Frank Schima wrote: > > > What one is the right way for creating a port that works w python25: > > a) create a new port py25-rdflib and make it use "PortGroup python25" ? > > > > This is the right way to go because it is a python library. > > > > b) remove PortGroup from py-rdflib and add variants "python24" and > > "python25" to it ? > > Thanks, that's clear. > > I was hoping to keep one portfile instead of creating new for each > version of python. > > Some ports (for example [1]) use variants python24, python25, ... > instead of PortGroups. Could you please tell what is wrong with the > other approach (used by ports such as [1])? redland-bindings doesn't use a python port group; if you do use a port group you have to break out the port into multiple (py-, py25-, etc). This is unfortunately the way it is for now, until ticket #16723 is implemented: Bryan > > [1] http://trac.macports.org/browser/trunk/dports/www/redland-bindings/Portfile > > Uldis > > [ http://captsolo.net/info/ ] From captsolo at gmail.com Fri Feb 20 15:37:41 2009 From: captsolo at gmail.com (Uldis Bojars) Date: Fri, 20 Feb 2009 23:37:41 +0000 Subject: How to adapt ports to different versions of Python In-Reply-To: <20090220230554.GE483@ninagal.withay.com> References: <64c81f720902200445i1b2592dat6fba24c063ee2be0@mail.gmail.com> <48940B6B-AFA0-443F-ACD5-CF49AACFEB0C@macports.org> <64c81f720902201445q6ae00b84keb25e55faa5cd049@mail.gmail.com> <20090220230554.GE483@ninagal.withay.com> Message-ID: <64c81f720902201537l41e53487n85323db44f63e78a@mail.gmail.com> On Fri, Feb 20, 2009 at 11:05 PM, Bryan Blackburn wrote: >> > b) remove PortGroup from py-rdflib and add variants "python24" and >> > "python25" to it ? >> >> Some ports (for example [1]) use variants python24, python25, ... >> instead of PortGroups. Could you please tell what is wrong with the >> other approach (used by ports such as [1])? > > redland-bindings doesn't use a python port group; if you do use a port group > you have to break out the port into multiple (py-, py25-, etc). This is > unfortunately the way it is for now, until ticket #16723 is implemented: Why do you need port groups? If you create variants for different variants then you would need to remove port from a port group. Fine. What I am trying to understand here is if there is anything wrong with doing that - does a port break if changed this way? Thanks, Uldis [ http://captsolo.net/info/ ] From blb at macports.org Fri Feb 20 15:55:12 2009 From: blb at macports.org (Bryan Blackburn) Date: Fri, 20 Feb 2009 16:55:12 -0700 Subject: How to adapt ports to different versions of Python In-Reply-To: <64c81f720902201537l41e53487n85323db44f63e78a@mail.gmail.com> References: <64c81f720902200445i1b2592dat6fba24c063ee2be0@mail.gmail.com> <48940B6B-AFA0-443F-ACD5-CF49AACFEB0C@macports.org> <64c81f720902201445q6ae00b84keb25e55faa5cd049@mail.gmail.com> <20090220230554.GE483@ninagal.withay.com> <64c81f720902201537l41e53487n85323db44f63e78a@mail.gmail.com> Message-ID: <20090220235512.GF483@ninagal.withay.com> On Fri, Feb 20, 2009 at 11:37:41PM +0000, Uldis Bojars said: > On Fri, Feb 20, 2009 at 11:05 PM, Bryan Blackburn wrote: > >> > b) remove PortGroup from py-rdflib and add variants "python24" and > >> > "python25" to it ? > >> > >> Some ports (for example [1]) use variants python24, python25, ... > >> instead of PortGroups. Could you please tell what is wrong with the > >> other approach (used by ports such as [1])? > > > > redland-bindings doesn't use a python port group; if you do use a port group > > you have to break out the port into multiple (py-, py25-, etc). This is > > unfortunately the way it is for now, until ticket #16723 is implemented: > > Why do you need port groups? They simplify a port, as they allow centralization of the work into the one file (the one implementing the given group). For python* groups, they aren't really too complicated, but for some groups they do quite a bit of work, and drastically cut a Portfile in size. > > If you create variants for different variants then you would need to > remove port from a port group. Fine. What I am trying to understand > here is if there is anything wrong with doing that - does a port break > if changed this way? You can do this, and would need to make sure to properly select the right python bits the port needs in the +python* variant as needed. But also note that if you're looking at a port which is currently names py-something (or py##-something), you should also rename it, as those prefixes have meaning. Also note that renaming ports is messy as there's no way to ease into the new name. Otherwise, there are definitely ports which use variants instead of duplication to do that, as these are unfortunately the only choices for now (until #16723). Note though that you can't then depend on the port +python25 for example, as that is ticket #126 (and a blocker for #16723). This is one of the useful bits of having py-something and py25-something, so you can specifically depend on the python 2.5 one, for example. Bryan > > Thanks, > Uldis > > [ http://captsolo.net/info/ ] From ryandesign at macports.org Fri Feb 20 23:50:45 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 21 Feb 2009 01:50:45 -0600 Subject: How distfiles mirrors know to fetch new files In-Reply-To: References: <5998833B-8C92-4E9C-97CC-3EDE283A5E65@macports.org> Message-ID: <52B13690-A05C-4D5C-823F-34D962E99F3B@macports.org> Dear admins of the European MacPorts distfiles mirrors, It appears that the files on the mirrors are going stale, that is, files for newly-added or updated ports are not appearing on your mirrors. Do you have any mechanism in place to periodically update your mirrors? William Siegrist suggests that you should poll for changes or just run "port mirror all" from time to time. The California mirror is kept up to date via a post-commit script that runs as soon as anything is committed to the repository. I imagine this is possible because the repository server and the mirror server are near one another, but perhaps there would be a more general way to have the repository server ping all the mirrors to tell them it's time to re-fetch a given port, for example by simply accessing a URL like http:///refetch.php/ refetch.php could be written to only accept connections from the repository server to prevent abuse. On Feb 10, 2009, at 20:07, William Siegrist wrote: > On Feb 10, 2009, at 4:58 PM, Ryan Schmidt wrote: > >> We have three distfiles mirrors, in the US, Norway and Sweden: >> >> US: http://distfiles.macports.org/ >> NO: http://trd.no.distfiles.macports.org/ >> SE: http://arn.se.distfiles.macports.org/ >> >> In /graphviz the US mirror has distfiles up to the current port >> version, graphviz-2.21.20090209.0545.tar.gz. >> >> But Sweden only has files up to graphviz-2.21.20090106.0545.tar.gz. >> >> Norway only has files up to graphviz-2.21.20081216.0545.tar.gz. >> >> I believe the US mirror, which runs right next to the Subversion >> repository, gets updated in a post-commit hook, so as soon as >> someone commits a new version of a port, the mirror fetches the >> new file. >> >> How do Norway and Sweden get informed that they should fetch new >> files? I fear they're not getting informed at all. > > You might want to CC the mirror owners, but in any case, they have > to poll for changes (via RSS, mailing list, whatever) or just > perform full "port mirror " runs periodically. From ryandesign at macports.org Sat Feb 21 14:09:18 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 21 Feb 2009 16:09:18 -0600 Subject: How distfiles mirrors know to fetch new files In-Reply-To: <7E95D8DB-0D0D-4EA0-8CB3-C08A0391F04B@mojo.net> References: <5998833B-8C92-4E9C-97CC-3EDE283A5E65@macports.org> <52B13690-A05C-4D5C-823F-34D962E99F3B@macports.org> <7E95D8DB-0D0D-4EA0-8CB3-C08A0391F04B@mojo.net> Message-ID: <2A08AF91-3488-447D-88A4-EC543BF5B442@macports.org> On Feb 21, 2009, at 09:05, David Bannister wrote: > I update everyday at 2100 EST from the california site, the update > is via wget and rysnc. That sounds like it should work. Any ideas why not all of the files from the California mirror are appearing on yours then? See for example the directories dcraw, graphviz, lighttpd, xorg-libX11... > The server is based on FreeBSD 7.1, if someone would like to clean > up the macports package to compile successfully on that platform > then I would be happy to run 'port mirror all.' I wasn't aware we had problems compiling on FreeBSD. Are tickets already filed for the problems you're encountering? If not, could you go into more detail? As you know, the vast majority of MacPorts users and developers have Macs and don't have access to other systems like FreeBSD to test on. > On Feb 21, 2009, at 2:50 AM, Ryan Schmidt wrote: > >> Dear admins of the European MacPorts distfiles mirrors, >> >> It appears that the files on the mirrors are going stale, that is, >> files for newly-added or updated ports are not appearing on your >> mirrors. Do you have any mechanism in place to periodically update >> your mirrors? William Siegrist suggests that you should poll for >> changes or just run "port mirror all" from time to time. >> >> The California mirror is kept up to date via a post-commit script >> that runs as soon as anything is committed to the repository. I >> imagine this is possible because the repository server and the >> mirror server are near one another, but perhaps there would be a >> more general way to have the repository server ping all the >> mirrors to tell them it's time to re-fetch a given port, for >> example by simply accessing a URL like >> >> http:///refetch.php/ >> >> refetch.php could be written to only accept connections from the >> repository server to prevent abuse. >> >> >> On Feb 10, 2009, at 20:07, William Siegrist wrote: >> >>> On Feb 10, 2009, at 4:58 PM, Ryan Schmidt wrote: >>> >>>> We have three distfiles mirrors, in the US, Norway and Sweden: >>>> >>>> US: http://distfiles.macports.org/ >>>> NO: http://trd.no.distfiles.macports.org/ >>>> SE: http://arn.se.distfiles.macports.org/ >>>> >>>> In /graphviz the US mirror has distfiles up to the current port >>>> version, graphviz-2.21.20090209.0545.tar.gz. >>>> >>>> But Sweden only has files up to graphviz-2.21.20090106.0545.tar.gz. >>>> >>>> Norway only has files up to graphviz-2.21.20081216.0545.tar.gz. >>>> >>>> I believe the US mirror, which runs right next to the Subversion >>>> repository, gets updated in a post-commit hook, so as soon as >>>> someone commits a new version of a port, the mirror fetches the >>>> new file. >>>> >>>> How do Norway and Sweden get informed that they should fetch new >>>> files? I fear they're not getting informed at all. >>> >>> You might want to CC the mirror owners, but in any case, they >>> have to poll for changes (via RSS, mailing list, whatever) or >>> just perform full "port mirror " runs periodically. From jmr at macports.org Sat Feb 21 23:26:49 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 22 Feb 2009 18:26:49 +1100 Subject: PortInfo lookup performance patch In-Reply-To: <499E3DC7.4000306@macports.org> References: <499E3DC7.4000306@macports.org> Message-ID: <49A0FE39.2010601@macports.org> Joshua Root wrote: > I think the patch in is just > about ready to go in. Does anyone have any suggestions or comments > before it does? It won't be set in stone until 1.8 is released, but it > would still be good to catch any issues sooner rather than later. Well, I got no comments, so the code must be perfect. ;-) Committed: - Josh From ryandesign at macports.org Sun Feb 22 01:36:48 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Feb 2009 03:36:48 -0600 Subject: [46149] trunk/dports In-Reply-To: <20090130165307.5151CDDD085@beta.macosforge.org> References: <20090130165307.5151CDDD085@beta.macosforge.org> Message-ID: <68A29C4A-3C20-45BC-9421-4C995EB58B57@macports.org> Martin, please note my comments below: On Jan 30, 2009, at 10:52, krischik at macports.org wrote: > Revision: 46149 > http://trac.macports.org/changeset/46149 > Author: krischik at macports.org > Date: 2009-01-30 08:52:45 -0800 (Fri, 30 Jan 2009) > Log Message: > ----------- > O dear - nrg4iso is of course a sysutil and not an emulator. It is > in fact a better nrg2iso. > > Modified Paths: > -------------- > trunk/dports/sysutils/nrg4iso/Portfile > > Added Paths: > ----------- > trunk/dports/sysutils/nrg4iso/ > > Removed Paths: > ------------- > trunk/dports/emulators/nrg4iso/ > > Property Changed: > ---------------- > trunk/dports/sysutils/nrg4iso/Portfile > > > Property changes on: trunk/dports/sysutils/nrg4iso > ___________________________________________________________________ > Added: svn:ignore > + .backups We don't use a directory called ".backups" so there's no need to add such an svn:ignore property. If you personally use a directory of that name in the course of your work, you should add it to your Subversion client's global-ignores instead. > Added: svn:mergeinfo > + > > Modified: trunk/dports/sysutils/nrg4iso/Portfile > =================================================================== > --- trunk/dports/emulators/nrg4iso/Portfile 2009-01-30 13:13:42 UTC > (rev 46146) > +++ trunk/dports/sysutils/nrg4iso/Portfile 2009-01-30 16:52:45 UTC > (rev 46149) > @@ -5,9 +5,10 @@ > > name nrg4iso > version 1.0.1 > +revision 1 Unless your changes cause different files to be installed on the user's system, you should not increase the revision. You shouldn't decrease it again now, but keep it in mind for future changes. > platforms darwin > -categories emulators > -maintainers me.com:krischik > +categories sysutils > +maintainers macports:macports.org The correct maintainer address would be "macports.org:krischik" or just "krischik". I fixed this in r47113. > Property changes on: trunk/dports/sysutils/nrg4iso/Portfile > ___________________________________________________________________ > Modified: svn:keywords > - Id > + Author Date Id Revision HeadURL > Modified: svn:eol-style > - native > + LF > Added: svn:executable > + * > Added: svn:mime-type > + text/x-shellscript A portfile is not a shell script and is not executable. Note also that we use svn:eol-style native and svn:keywords Id. We don't use the other keywords you added. You may wish to set your Subversion client's auto-props to automatically add the correct svn:eol-style and svn:keywords to portfiles. I fixed the properties in r47112. From ryandesign at macports.org Sun Feb 22 01:48:31 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Feb 2009 03:48:31 -0600 Subject: free42 (was: Re: [46154] trunk/dports/emulators) In-Reply-To: <2D23063B-1976-4E52-ADCB-ACBE8A476CC8@macports.org> References: <20090130172524.79B9ADDDE2B@beta.macosforge.org> <115306A2-EDDB-4540-87CD-B9F481E1B37A@macports.org> <20090201225752.GK813@ninagal.withay.com> <2D23063B-1976-4E52-ADCB-ACBE8A476CC8@macports.org> Message-ID: <067263BC-A5AF-41C7-B1C3-E116F516FA15@macports.org> On Feb 1, 2009, at 17:40, Ryan Schmidt wrote: > On Feb 1, 2009, at 16:57, Bryan Blackburn wrote: > >> On Sun, Feb 01, 2009 at 03:34:01PM -0600, Ryan Schmidt said: >> >>> When I try to install the port I get: >>> >>> sh: line 1: SetFile: command not found >>> Error: Target org.macports.destroot returned: shell command >>> "SetFile -a E >>> /mp/var/macports/build/ >>> _Users_rschmidt_macports_dports_emulators_free42/work/destroot/ >>> Applications/mp/Free42-Decimal.command" returned error 127 >>> Command output: sh: line 1: SetFile: command not found >>> >>> SetFile is not in any of the usual paths but in /Developer/Tools so >>> you'll have to call it by that absolute path if you want to use it. >> >> Is that on 10.4? I see SetFile in /usr/bin on 10.5.6, Xcode >> 3.1.2. So it >> may only be needed in a darwin 8 platform section if it turns out >> to be >> needed. > > Yes, this is on Tiger. I have now filed a ticket for this issue so it is not forgotten: http://trac.macports.org/ticket/18591 From krischik at macports.org Sun Feb 22 09:50:19 2009 From: krischik at macports.org (Martin Krischik) Date: Sun, 22 Feb 2009 18:50:19 +0100 Subject: free42 (was: Re: [46154] trunk/dports/emulators) In-Reply-To: <115306A2-EDDB-4540-87CD-B9F481E1B37A@macports.org> References: <20090130172524.79B9ADDDE2B@beta.macosforge.org> <115306A2-EDDB-4540-87CD-B9F481E1B37A@macports.org> Message-ID: <49A1905B.4020302@macports.org> Am 01.02.2009 um 22:34 schrieb Ryan Schmidt: > On Jan 30, 2009, at 11:25, krischik at macports.org wrote: > >> Revision: 46154 >> http://trac.macports.org/changeset/46154 >> Author: krischik at macports.org >> Date: 2009-01-30 09:25:19 -0800 (Fri, 30 Jan 2009) >> Log Message: >> ----------- >> Ticket #18207: Free HP-42s Simulator. > > [snip] > >> +depends_lib port:gtk2 \ >> + path:${prefix}/bin/zsh:zsh > > This line must read "path:bin/zsh:zsh" to work as intended because > variables are not expanded in depspecs. > > [snip] > >> + xinstall -m 755 \ >> + -W ${filespath} \ >> + Free42-Decimal.command.in \ >> + ${destroot}${applications_dir}/Free42-Decimal.command >> + reinplace \ >> + s|@PREFIX@|${prefix}|g \ >> + ${destroot}${applications_dir}/Free42-Decimal.command >> + system "SetFile -a E ${destroot}${applications_dir}/Free42- >> Decimal.command" >> + xinstall -m 755 \ >> + -W ${filespath} \ >> + Free42-Binary.command.in \ >> + ${destroot}${applications_dir}/Free42-Binary.command >> + reinplace \ >> + s|@PREFIX@|${prefix}|g \ >> + ${destroot}${applications_dir}/Free42-Binary.command >> + system "SetFile -a E ${destroot}${applications_dir}/Free42- >> Binary.command" > > When I try to install the port I get: > > sh: line 1: SetFile: command not found > Error: Target org.macports.destroot returned: shell command "SetFile > -a E /mp/var/macports/build/ > _Users_rschmidt_macports_dports_emulators_free42/work/destroot/ > Applications/mp/Free42-Decimal.command" returned error 127 > Command output: sh: line 1: SetFile: command not found > > SetFile is not in any of the usual paths but in /Developer/Tools so > you'll have to call it by that absolute path if you want to use it. > > But why do you want to use it? It looks like you're making files > invisible. No, I make the extension (.command) invisible. > Is that because they look unsightly in the Applications directory? > If so, then why are the files there and not placed in a less-visible > MacPorts directory, e.g. ${prefix}/libexec/${name}? It is the right place as - only the .command is ugly. > It looks like these .command files are wrapper scripts around the > real program. Wrapper scripts are fine; I do it in the wine port > too. But I suggest you change it in this way: > )1) Install the wrapper script as ${prefix}/bin/free42. Install the > real binary in ${prefix}/libexec/${name}/free42. That way anyone who > just types "free42" in the Terminal access your wrapper too. Start via Terminal is what I want to avoid. I find I rather sad that so few applications provide start-up via application icon. The command file was a first attempt to provide easy access to the application. Not perfect yet - I am still working on it. > 2) If you want to make the program available in ${applications_dir}, > make a minimal application bundle. See for example the post-destroot > section of the port lbreakout2. That's the way to go indeed. > 3) Rewrite the wrapper in sh so that a dependency on the zsh port is > not necessary. grumlgrumldon'tlikebashgrumlgruml >> +############################################################ {{{1 >> ########### >> +# vim: set nowrap tabstop=4 shiftwidth=4 softtabstop=4 noexpandtab : >> +# vim: set textwidth=0 filetype=tcl foldmethod=marker nospell : > > We already have the modeline in the first line of the portfile. If > these lines are adding things that we don't have in the modeline, > what are they and would they be useful to consider adding to our > recommended modeline? First and foremost they use the full names of the settings instead of abbreviations. So lets compare: 1) fenc=utf-8 fileencoding 2) ft=tcl filetype 3) et expandtab 4) sw=4 shiftwidth 5) ts=4 tabstop 6) sts=4 softtabstop No. 3 and 5 contradict each other - if tabs are expanded to spaces you don't need to set the physical tab stops. My Suggestion is tabstop=8 noexpandtab - most terminals set the tabstop to 8. I also have foldmethod=marker which might be helpful for very large Portfiles - you can then fold parts of the source with {{{ and }}}. textwidth=0 is actually wrong - better would be textwidth=78 - one can then format comments with the "gq" command. Martin -- Martin Krischik krischik at users.sourceforge.net From raimue at macports.org Sun Feb 22 11:09:02 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 22 Feb 2009 20:09:02 +0100 Subject: Default modeline (was: Re: free42) In-Reply-To: <49A1905B.4020302@macports.org> References: <20090130172524.79B9ADDDE2B@beta.macosforge.org> <115306A2-EDDB-4540-87CD-B9F481E1B37A@macports.org> <49A1905B.4020302@macports.org> Message-ID: <49A1A2CE.10905@macports.org> Martin Krischik wrote: > Am 01.02.2009 um 22:34 schrieb Ryan Schmidt: [...] >>> +############################################################ {{{1 >>> ########### >>> +# vim: set nowrap tabstop=4 shiftwidth=4 softtabstop=4 noexpandtab : >>> +# vim: set textwidth=0 filetype=tcl foldmethod=marker nospell : >> We already have the modeline in the first line of the portfile. If >> these lines are adding things that we don't have in the modeline, >> what are they and would they be useful to consider adding to our >> recommended modeline? > > First and foremost they use the full names of the settings instead of > abbreviations. So lets compare: > > 1) fenc=utf-8 fileencoding > 2) ft=tcl filetype > 3) et expandtab > 4) sw=4 shiftwidth > 5) ts=4 tabstop > 6) sts=4 softtabstop > > No. 3 and 5 contradict each other - if tabs are expanded to spaces you > don't need to set the physical tab stops. My Suggestion is tabstop=8 > noexpandtab - most terminals set the tabstop to 8. I agree. Usually when using vim tabstop should not be changed, only shiftwidth. I am not sure if using softtabstop is "compatible" with other editors. Most other editors are not able to make a difference between tabs at indentation level and somewhere else in the file. This could be the reason why our default modeline is changing tabstop. > I also have foldmethod=marker which might be helpful for very large > Portfiles - you can then fold parts of the source with {{{ and }}}. Useless if not also using foldenable. I would leave this for everyone to add in their .vim/filetype.vim. Some people do not like folding. For example: au BufRead,BufNewFile Portfile setlocal foldenable foldmethod=marker > textwidth=0 is actually wrong - better would be textwidth=78 - one can > then format comments with the "gq" command. I have that set for all text/code files anyway. I don't think we should enforce a specific textwidth for Portfiles. For example commands in destroot phases or variant lines with descriptions are often longer than 80 characters. Rainer From raimue at macports.org Sun Feb 22 11:33:52 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 22 Feb 2009 20:33:52 +0100 Subject: Creating application bundles (was: Re: free42) In-Reply-To: <49A1905B.4020302@macports.org> References: <20090130172524.79B9ADDDE2B@beta.macosforge.org> <115306A2-EDDB-4540-87CD-B9F481E1B37A@macports.org> <49A1905B.4020302@macports.org> Message-ID: <49A1A8A0.2030700@macports.org> Martin Krischik wrote: > Am 01.02.2009 um 22:34 schrieb Ryan Schmidt: [...] >> It looks like these .command files are wrapper scripts around the >> real program. Wrapper scripts are fine; I do it in the wine port >> too. But I suggest you change it in this way: >> )1) Install the wrapper script as ${prefix}/bin/free42. Install the >> real binary in ${prefix}/libexec/${name}/free42. That way anyone who >> just types "free42" in the Terminal access your wrapper too. > > Start via Terminal is what I want to avoid. I find I rather sad that > so few applications provide start-up via application icon. The command > file was a first attempt to provide easy access to the application. > Not perfect yet - I am still working on it. > >>> 2) If you want to make the program available in ${applications_dir}, >>> make a minimal application bundle. See for example the post-destroot >>> section of the port lbreakout2. >> >> That's the way to go indeed. I already began working on a port group to support something like this some time ago. See ticket #14557 [1]. I am trying to create .app bundles with minimal effort. I uploaded a preliminary port group which resembles the commands being used in tuxmath, lbreakout2 and maybe others. If the binary has the same name as the port, all you need is to add 'PortGroup appbundle 1.0' to your port and it will automatically create an .app bundle at ${applications_dir}. But it does not provide all the features I would like to see, for example custom icons. It seems like that absolutely requires a Info.plist for them. We could use a XML template and replace some values in the port group on destroot. I am currently using platform macosx, would this be valid on all darwin variants? I see other ports defining this for darwin. Rainer [1] https://trac.macports.org/ticket/14557 From somaen at pvv.ntnu.no Sun Feb 22 13:49:37 2009 From: somaen at pvv.ntnu.no (=?ISO-8859-1?Q?Einar_Johan_S=F8m=E5en?=) Date: Sun, 22 Feb 2009 22:49:37 +0100 Subject: How distfiles mirrors know to fetch new files In-Reply-To: <52B13690-A05C-4D5C-823F-34D962E99F3B@macports.org> References: <5998833B-8C92-4E9C-97CC-3EDE283A5E65@macports.org> <52B13690-A05C-4D5C-823F-34D962E99F3B@macports.org> Message-ID: I run the mirror-ports script I was told to run, daily. And rsync the rest. Den 21. feb.. 2009 kl. 08.50 skrev Ryan Schmidt: > Dear admins of the European MacPorts distfiles mirrors, > > It appears that the files on the mirrors are going stale, that is, > files for newly-added or updated ports are not appearing on your > mirrors. Do you have any mechanism in place to periodically update > your mirrors? William Siegrist suggests that you should poll for > changes or just run "port mirror all" from time to time. > > The California mirror is kept up to date via a post-commit script > that runs as soon as anything is committed to the repository. I > imagine this is possible because the repository server and the > mirror server are near one another, but perhaps there would be a > more general way to have the repository server ping all the mirrors > to tell them it's time to re-fetch a given port, for example by > simply accessing a URL like > > http:///refetch.php/ > > refetch.php could be written to only accept connections from the > repository server to prevent abuse. > > > On Feb 10, 2009, at 20:07, William Siegrist wrote: > >> On Feb 10, 2009, at 4:58 PM, Ryan Schmidt wrote: >> >>> We have three distfiles mirrors, in the US, Norway and Sweden: >>> >>> US: http://distfiles.macports.org/ >>> NO: http://trd.no.distfiles.macports.org/ >>> SE: http://arn.se.distfiles.macports.org/ >>> >>> In /graphviz the US mirror has distfiles up to the current port >>> version, graphviz-2.21.20090209.0545.tar.gz. >>> >>> But Sweden only has files up to graphviz-2.21.20090106.0545.tar.gz. >>> >>> Norway only has files up to graphviz-2.21.20081216.0545.tar.gz. >>> >>> I believe the US mirror, which runs right next to the Subversion >>> repository, gets updated in a post-commit hook, so as soon as >>> someone commits a new version of a port, the mirror fetches the >>> new file. >>> >>> How do Norway and Sweden get informed that they should fetch new >>> files? I fear they're not getting informed at all. >> >> You might want to CC the mirror owners, but in any case, they have >> to poll for changes (via RSS, mailing list, whatever) or just >> perform full "port mirror " runs periodically. > > From ryandesign at macports.org Sun Feb 22 14:03:07 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Feb 2009 16:03:07 -0600 Subject: How distfiles mirrors know to fetch new files In-Reply-To: References: <5998833B-8C92-4E9C-97CC-3EDE283A5E65@macports.org> <52B13690-A05C-4D5C-823F-34D962E99F3B@macports.org> Message-ID: <898B0634-A013-4B46-9756-BB10F776F9F0@macports.org> Ok, I don't recall that script. Could you show it to me or remind me where it came from? Thanks. On Feb 22, 2009, at 15:49, Einar Johan S?m?en wrote: > I run the mirror-ports script I was told to run, daily. And rsync > the rest. > > > Den 21. feb.. 2009 kl. 08.50 skrev Ryan Schmidt: > >> Dear admins of the European MacPorts distfiles mirrors, >> >> It appears that the files on the mirrors are going stale, that is, >> files for newly-added or updated ports are not appearing on your >> mirrors. Do you have any mechanism in place to periodically update >> your mirrors? William Siegrist suggests that you should poll for >> changes or just run "port mirror all" from time to time. >> >> The California mirror is kept up to date via a post-commit script >> that runs as soon as anything is committed to the repository. I >> imagine this is possible because the repository server and the >> mirror server are near one another, but perhaps there would be a >> more general way to have the repository server ping all the >> mirrors to tell them it's time to re-fetch a given port, for >> example by simply accessing a URL like >> >> http:///refetch.php/ >> >> refetch.php could be written to only accept connections from the >> repository server to prevent abuse. >> >> >> On Feb 10, 2009, at 20:07, William Siegrist wrote: >> >>> On Feb 10, 2009, at 4:58 PM, Ryan Schmidt wrote: >>> >>>> We have three distfiles mirrors, in the US, Norway and Sweden: >>>> >>>> US: http://distfiles.macports.org/ >>>> NO: http://trd.no.distfiles.macports.org/ >>>> SE: http://arn.se.distfiles.macports.org/ >>>> >>>> In /graphviz the US mirror has distfiles up to the current port >>>> version, graphviz-2.21.20090209.0545.tar.gz. >>>> >>>> But Sweden only has files up to graphviz-2.21.20090106.0545.tar.gz. >>>> >>>> Norway only has files up to graphviz-2.21.20081216.0545.tar.gz. >>>> >>>> I believe the US mirror, which runs right next to the Subversion >>>> repository, gets updated in a post-commit hook, so as soon as >>>> someone commits a new version of a port, the mirror fetches the >>>> new file. >>>> >>>> How do Norway and Sweden get informed that they should fetch new >>>> files? I fear they're not getting informed at all. >>> >>> You might want to CC the mirror owners, but in any case, they >>> have to poll for changes (via RSS, mailing list, whatever) or >>> just perform full "port mirror " runs periodically. From somaen at pvv.ntnu.no Sun Feb 22 14:17:23 2009 From: somaen at pvv.ntnu.no (=?ISO-8859-1?Q?Einar_Johan_S=F8m=E5en?=) Date: Sun, 22 Feb 2009 23:17:23 +0100 Subject: How distfiles mirrors know to fetch new files In-Reply-To: <898B0634-A013-4B46-9756-BB10F776F9F0@macports.org> References: <5998833B-8C92-4E9C-97CC-3EDE283A5E65@macports.org> <52B13690-A05C-4D5C-823F-34D962E99F3B@macports.org> <898B0634-A013-4B46-9756-BB10F776F9F0@macports.org> Message-ID: <662FACFB-6ED6-4EEA-BC8E-B36007B3FC43@pvv.ntnu.no> Dug the link out of the Re: [macports-mgr] Mirror at PVV at NTNU in Norway thread: > http://trac.macports.org/browser/trunk/base/portmgr/jobs/mirror_macports.sh Den 22. feb.. 2009 kl. 23.03 skrev Ryan Schmidt: > Ok, I don't recall that script. Could you show it to me or remind me > where it came from? Thanks. > > > On Feb 22, 2009, at 15:49, Einar Johan S?m?en wrote: > >> I run the mirror-ports script I was told to run, daily. And rsync >> the rest. >> >> >> Den 21. feb.. 2009 kl. 08.50 skrev Ryan Schmidt: >> >>> Dear admins of the European MacPorts distfiles mirrors, >>> >>> It appears that the files on the mirrors are going stale, that is, >>> files for newly-added or updated ports are not appearing on your >>> mirrors. Do you have any mechanism in place to periodically update >>> your mirrors? William Siegrist suggests that you should poll for >>> changes or just run "port mirror all" from time to time. >>> >>> The California mirror is kept up to date via a post-commit script >>> that runs as soon as anything is committed to the repository. I >>> imagine this is possible because the repository server and the >>> mirror server are near one another, but perhaps there would be a >>> more general way to have the repository server ping all the >>> mirrors to tell them it's time to re-fetch a given port, for >>> example by simply accessing a URL like >>> >>> http:///refetch.php/ >>> >>> refetch.php could be written to only accept connections from the >>> repository server to prevent abuse. >>> >>> >>> On Feb 10, 2009, at 20:07, William Siegrist wrote: >>> >>>> On Feb 10, 2009, at 4:58 PM, Ryan Schmidt wrote: >>>> >>>>> We have three distfiles mirrors, in the US, Norway and Sweden: >>>>> >>>>> US: http://distfiles.macports.org/ >>>>> NO: http://trd.no.distfiles.macports.org/ >>>>> SE: http://arn.se.distfiles.macports.org/ >>>>> >>>>> In /graphviz the US mirror has distfiles up to the current port >>>>> version, graphviz-2.21.20090209.0545.tar.gz. >>>>> >>>>> But Sweden only has files up to >>>>> graphviz-2.21.20090106.0545.tar.gz. >>>>> >>>>> Norway only has files up to graphviz-2.21.20081216.0545.tar.gz. >>>>> >>>>> I believe the US mirror, which runs right next to the Subversion >>>>> repository, gets updated in a post-commit hook, so as soon as >>>>> someone commits a new version of a port, the mirror fetches the >>>>> new file. >>>>> >>>>> How do Norway and Sweden get informed that they should fetch new >>>>> files? I fear they're not getting informed at all. >>>> >>>> You might want to CC the mirror owners, but in any case, they >>>> have to poll for changes (via RSS, mailing list, whatever) or >>>> just perform full "port mirror " runs periodically. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Sun Feb 22 14:34:10 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Feb 2009 16:34:10 -0600 Subject: How distfiles mirrors know to fetch new files In-Reply-To: <662FACFB-6ED6-4EEA-BC8E-B36007B3FC43@pvv.ntnu.no> References: <5998833B-8C92-4E9C-97CC-3EDE283A5E65@macports.org> <52B13690-A05C-4D5C-823F-34D962E99F3B@macports.org> <898B0634-A013-4B46-9756-BB10F776F9F0@macports.org> <662FACFB-6ED6-4EEA-BC8E-B36007B3FC43@pvv.ntnu.no> Message-ID: <05830D23-66EB-4662-B3AE-7115331904F1@macports.org> Ah yes, ok, that script I do recall. Does it produce any error messages in the error log? If not, do you have any idea why your mirror does not appear to have all files on it that it should? Compare for example the dcraw, graphviz and winetricks directories on your mirror and the California one. I've checked several other paths, and I can't find any files added to your mirror after December of last year. On Feb 22, 2009, at 16:17, Einar Johan S?m?en wrote: > Dug the link out of the Re: [macports-mgr] Mirror at PVV at NTNU in > Norway thread: > >> http://trac.macports.org/browser/trunk/base/portmgr/jobs/ >> mirror_macports.sh > > Den 22. feb.. 2009 kl. 23.03 skrev Ryan Schmidt: > >> Ok, I don't recall that script. Could you show it to me or remind >> me where it came from? Thanks. >> >> >> On Feb 22, 2009, at 15:49, Einar Johan S?m?en wrote: >> >>> I run the mirror-ports script I was told to run, daily. And rsync >>> the rest. >>> >>> >>> Den 21. feb.. 2009 kl. 08.50 skrev Ryan Schmidt: >>> >>>> Dear admins of the European MacPorts distfiles mirrors, >>>> >>>> It appears that the files on the mirrors are going stale, that >>>> is, files for newly-added or updated ports are not appearing on >>>> your mirrors. Do you have any mechanism in place to periodically >>>> update your mirrors? William Siegrist suggests that you should >>>> poll for changes or just run "port mirror all" from time to time. >>>> >>>> The California mirror is kept up to date via a post-commit >>>> script that runs as soon as anything is committed to the >>>> repository. I imagine this is possible because the repository >>>> server and the mirror server are near one another, but perhaps >>>> there would be a more general way to have the repository server >>>> ping all the mirrors to tell them it's time to re-fetch a given >>>> port, for example by simply accessing a URL like >>>> >>>> http:///refetch.php/ >>>> >>>> refetch.php could be written to only accept connections from the >>>> repository server to prevent abuse. >>>> >>>> >>>> On Feb 10, 2009, at 20:07, William Siegrist wrote: >>>> >>>>> On Feb 10, 2009, at 4:58 PM, Ryan Schmidt wrote: >>>>> >>>>>> We have three distfiles mirrors, in the US, Norway and Sweden: >>>>>> >>>>>> US: http://distfiles.macports.org/ >>>>>> NO: http://trd.no.distfiles.macports.org/ >>>>>> SE: http://arn.se.distfiles.macports.org/ >>>>>> >>>>>> In /graphviz the US mirror has distfiles up to the current >>>>>> port version, graphviz-2.21.20090209.0545.tar.gz. >>>>>> >>>>>> But Sweden only has files up to >>>>>> graphviz-2.21.20090106.0545.tar.gz. >>>>>> >>>>>> Norway only has files up to graphviz-2.21.20081216.0545.tar.gz. >>>>>> >>>>>> I believe the US mirror, which runs right next to the >>>>>> Subversion repository, gets updated in a post-commit hook, so >>>>>> as soon as someone commits a new version of a port, the mirror >>>>>> fetches the new file. >>>>>> >>>>>> How do Norway and Sweden get informed that they should fetch >>>>>> new files? I fear they're not getting informed at all. >>>>> >>>>> You might want to CC the mirror owners, but in any case, they >>>>> have to poll for changes (via RSS, mailing list, whatever) or >>>>> just perform full "port mirror " runs periodically. From somaen at pvv.ntnu.no Sun Feb 22 15:09:23 2009 From: somaen at pvv.ntnu.no (=?ISO-8859-1?Q?Einar_Johan_S=F8m=E5en?=) Date: Mon, 23 Feb 2009 00:09:23 +0100 Subject: How distfiles mirrors know to fetch new files In-Reply-To: <05830D23-66EB-4662-B3AE-7115331904F1@macports.org> References: <5998833B-8C92-4E9C-97CC-3EDE283A5E65@macports.org> <52B13690-A05C-4D5C-823F-34D962E99F3B@macports.org> <898B0634-A013-4B46-9756-BB10F776F9F0@macports.org> <662FACFB-6ED6-4EEA-BC8E-B36007B3FC43@pvv.ntnu.no> <05830D23-66EB-4662-B3AE-7115331904F1@macports.org> Message-ID: <4C29E645-CAB7-4E24-A294-78CA191629E8@pvv.ntnu.no> Hmm, I'll have a look at it tomorrow, I suspect that there might be some permission-problems for the script. Den 22. feb.. 2009 kl. 23.34 skrev Ryan Schmidt: > Ah yes, ok, that script I do recall. Does it produce any error > messages in the error log? If not, do you have any idea why your > mirror does not appear to have all files on it that it should? > Compare for example the dcraw, graphviz and winetricks directories > on your mirror and the California one. I've checked several other > paths, and I can't find any files added to your mirror after > December of last year. > > > On Feb 22, 2009, at 16:17, Einar Johan S?m?en wrote: > >> Dug the link out of the Re: [macports-mgr] Mirror at PVV at NTNU in >> Norway thread: >> >>> http://trac.macports.org/browser/trunk/base/portmgr/jobs/mirror_macports.sh >> >> Den 22. feb.. 2009 kl. 23.03 skrev Ryan Schmidt: >> >>> Ok, I don't recall that script. Could you show it to me or remind >>> me where it came from? Thanks. >>> >>> >>> On Feb 22, 2009, at 15:49, Einar Johan S?m?en wrote: >>> >>>> I run the mirror-ports script I was told to run, daily. And rsync >>>> the rest. >>>> >>>> >>>> Den 21. feb.. 2009 kl. 08.50 skrev Ryan Schmidt: >>>> >>>>> Dear admins of the European MacPorts distfiles mirrors, >>>>> >>>>> It appears that the files on the mirrors are going stale, that >>>>> is, files for newly-added or updated ports are not appearing on >>>>> your mirrors. Do you have any mechanism in place to periodically >>>>> update your mirrors? William Siegrist suggests that you should >>>>> poll for changes or just run "port mirror all" from time to time. >>>>> >>>>> The California mirror is kept up to date via a post-commit >>>>> script that runs as soon as anything is committed to the >>>>> repository. I imagine this is possible because the repository >>>>> server and the mirror server are near one another, but perhaps >>>>> there would be a more general way to have the repository server >>>>> ping all the mirrors to tell them it's time to re-fetch a given >>>>> port, for example by simply accessing a URL like >>>>> >>>>> http:///refetch.php/ >>>>> >>>>> refetch.php could be written to only accept connections from the >>>>> repository server to prevent abuse. >>>>> >>>>> >>>>> On Feb 10, 2009, at 20:07, William Siegrist wrote: >>>>> >>>>>> On Feb 10, 2009, at 4:58 PM, Ryan Schmidt wrote: >>>>>> >>>>>>> We have three distfiles mirrors, in the US, Norway and Sweden: >>>>>>> >>>>>>> US: http://distfiles.macports.org/ >>>>>>> NO: http://trd.no.distfiles.macports.org/ >>>>>>> SE: http://arn.se.distfiles.macports.org/ >>>>>>> >>>>>>> In /graphviz the US mirror has distfiles up to the current >>>>>>> port version, graphviz-2.21.20090209.0545.tar.gz. >>>>>>> >>>>>>> But Sweden only has files up to >>>>>>> graphviz-2.21.20090106.0545.tar.gz. >>>>>>> >>>>>>> Norway only has files up to graphviz-2.21.20081216.0545.tar.gz. >>>>>>> >>>>>>> I believe the US mirror, which runs right next to the >>>>>>> Subversion repository, gets updated in a post-commit hook, so >>>>>>> as soon as someone commits a new version of a port, the mirror >>>>>>> fetches the new file. >>>>>>> >>>>>>> How do Norway and Sweden get informed that they should fetch >>>>>>> new files? I fear they're not getting informed at all. >>>>>> >>>>>> You might want to CC the mirror owners, but in any case, they >>>>>> have to poll for changes (via RSS, mailing list, whatever) or >>>>>> just perform full "port mirror " runs periodically. > > From ryandesign at macports.org Sun Feb 22 15:34:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Feb 2009 17:34:28 -0600 Subject: [47138] trunk/dports/devel In-Reply-To: <20090222162656.5CFC3103B91B@beta.macosforge.org> References: <20090222162656.5CFC3103B91B@beta.macosforge.org> Message-ID: <4F6BDB1E-BAA2-46F8-A6AB-3DBD8AABC0A3@macports.org> On Feb 22, 2009, at 10:26, krischik at macports.org wrote: > Revision: 47138 > http://trac.macports.org/changeset/47138 > Author: krischik at macports.org > Date: 2009-02-22 08:26:55 -0800 (Sun, 22 Feb 2009) > Log Message: > ----------- > GPRbuild automates the construction of multi-language systems [snip] > -use_bzip2 yes > -use_parallel_build yes > -use_configure yes > +use_parallel_build yes > +use_configure yes > > -depends_lib port:gnat-gcc > +depends_lib port:gnat-gcc > > +build.args --jobs=4 Again, as I mentioned for the gnat-gcc port, I'm concerned about this build argument. When you specify "use_parallel_build yes" in your portfile, MacPorts automatically adds "-j${build.jobs}" to the build.args, where ${build.jobs} is specified in macports.conf. So you should not manually specify "--jobs=anything" in your portfile, unless your software does not respond to "-j" but does respond to "-- jobs" (is that the case?) From ryandesign at macports.org Sun Feb 22 16:33:09 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Feb 2009 18:33:09 -0600 Subject: [46921] trunk/dports/devel In-Reply-To: <20090217084909.D2665FA0B55@beta.macosforge.org> References: <20090217084909.D2665FA0B55@beta.macosforge.org> Message-ID: <74AA30D7-8FD8-4495-8606-CCC00AED670F@macports.org> On Feb 17, 2009, at 02:49, krischik at macports.org wrote: > --- trunk/dports/devel/gnat-xmlada/Portfile > (rev 0) > +++ trunk/dports/devel/gnat-xmlada/Portfile 2009-02-17 08:49:06 UTC > (rev 46921) > @@ -0,0 +1,42 @@ > +# -*- coding: utf-8; mode: tcl; tab-width: 4; truncate-lines: t; > indent-tabs-mode: nil; c-basic-offset: 4 -*- > +# $Id$ > + > +PortSystem 1.0 > + > +name gnat-xmlada > +version 3.1 > +epoch 20090126 > +revision 1 Note that the initial revision of any given version of a port should be 0, not 1. This can be achieved by writing "revision 0" or by omitting the revision line entirely. Don't decrease it now, but keep this in mind for future port updates and submissions. [snip] > +distfiles xmlada-${version}-${epoch}.tar.bz2 > +worksrcdir xmlada-${version}-${epoch} You can simplify these two lines to: distname xmlada-${version}-${epoch} Note that it's not usual to include the epoch in the distfile name. In particular, you are using the epoch as if it is of less significance than the version number, but in fact, MacPorts treats the epoch as having the highest significance, more significant than the version or revision. The order of significance is epoch, then version, then revision. The point of the epoch is so that you can downgrade a port to a previous version, if upstream mandates that e.g. due to a severe bug found in a new release, and still allow "port outdated" to work correctly, since "port outdated" (intentionally) only shows you ports that are "newer" than the version you have installed. There is a flag you can pass to "port outdated" to change that, but I forget what it is, and most users will not be using it, nor should they have to. Another reason to use epoch is for ports that do not follow the customary version numbering scheme, e.g. ports that consider the version to be a floating point number instead of a dotted decimal. Most perl ports are in this situation. So for example MacPorts considers (dotted decimal) 1.10 to be greater than (dotted decimal) 1.2 (because 10 is greater than 2), but in perl versioning, (floating point) 1.10 is less than (floating point) 1.2. So if you ever need to update a port from version 1.10 to version 1.2, you need to increase the epoch so MacPorts knows the new version is newer. At least until we have a more intelligent way of dealing with this, as proposed here: http://trac.macports.org/ticket/11873 So, with that understanding of what the epoch is really for, you may want to consider including the date in the version instead, e.g.: version 3.1-20090126 That way, if you need to update the port to 3.1-20090205, say, the user will see that in the output of "port outdated" (they will see "3.1-20090126 < 3.1-20090205"), whereas if you just change the epoch, the user will see "3.1 < 3.1" which will be confusing. Consider the gcc44 or graphviz-devel ports which include the date in the version string. In this case, you would change the line to just: distname xmlada-${version} Note that you cannot remove or decrease the epoch, however; once a port has an epoch, it can never be removed or decreased, or else "port outdated" would not show new versions of the port to users who already had it installed. > +use_bzip2 yes > +use_parallel_build yes > +use_configure yes You can remove that last line since "use_configure yes" is the default when you do not use a portgroup (or even when you do use most portgroups, but for example the xcode portgroup defaults to "use_configure no" so you would have to specify "use_configure yes" if you wanted to override that). From raimue at macports.org Sun Feb 22 20:10:36 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Mon, 23 Feb 2009 05:10:36 +0100 Subject: [MacPorts] #18602: Prevent MacPorts from being configured with --prefix=/usr/local In-Reply-To: <059.da3053b394f63ca52b512dc50bef8d26@macports.org> References: <059.da3053b394f63ca52b512dc50bef8d26@macports.org> Message-ID: <49A221BC.10504@macports.org> MacPorts wrote: > #18602: Prevent MacPorts from being configured with --prefix=/usr/local > -------------------------------------+-------------------------------------- > Reporter: ryandesign@? | Owner: macports-tickets@? > Type: defect | Status: new > Priority: Normal | Milestone: MacPorts 1.8.0 > Component: base | Version: 1.7.0 > Keywords: | Port: > -------------------------------------+-------------------------------------- > MacPorts should not allow users to configure it with > `--prefix=/usr/local`. Doing so surely breaks some ports, such as > [comment:ticket:15778:3 macfuse]. I don't think we should forbid it completely. Adding a warning and a link to the appropriate FAQ entry should be enough. The port macfuse is broken in a very different way, it's not respecting ${prefix} at all, but hardcoding /opt/local. The problem in the proposed patch is that it is making assumptions about paths which it should not be doing. Imagine it would be untaring to ${destpath}/opt/local by default, there would be the same problem just with another path. And I am pretty sure you don't want to forbid that path being used as a prefix. Forbidding paths being used as prefix is not the proper solution to fix the macfuse port. The problem can be overcome by comparing "/usr/local" to the current prefix, rename it to a temporary filename before renaming to the real target or untar only parts of the tarball to the correct location right away. This would work: tar -xjf $tarname -C ${destpath}${prefix} --strip-components 2 usr/local tar -xjf $tarname -C ${destpath} Library Rainer From raimue at macports.org Sun Feb 22 20:15:17 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Mon, 23 Feb 2009 05:15:17 +0100 Subject: [MacPorts] #18602: Prevent MacPorts from being configured with --prefix=/usr/local In-Reply-To: <49A221BC.10504@macports.org> References: <059.da3053b394f63ca52b512dc50bef8d26@macports.org> <49A221BC.10504@macports.org> Message-ID: <49A222D5.4@macports.org> Rainer M?ller wrote: > The problem can be overcome by comparing "/usr/local" to the current > prefix, rename it to a temporary filename before renaming to the real > target or untar only parts of the tarball to the correct location right > away. > > [...] Nevermind, I see you already found a much simpler solution by deleting ${destpath}${prefix} for macfuse. :-) Rainer From ryandesign at macports.org Sun Feb 22 21:54:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Feb 2009 23:54:29 -0600 Subject: [MacPorts] #18602: Prevent MacPorts from being configured with --prefix=/usr/local In-Reply-To: <49A221BC.10504@macports.org> References: <059.da3053b394f63ca52b512dc50bef8d26@macports.org> <49A221BC.10504@macports.org> Message-ID: <3ED4E609-3B80-4D69-8673-2901A6D86074@macports.org> On Feb 22, 2009, at 22:10, Rainer M?ller wrote: >> #18602: Prevent MacPorts from being configured with --prefix=/usr/ >> local >> ------------------------------------- >> +-------------------------------------- >> Reporter: ryandesign@? | Owner: macports- >> tickets@? >> Type: defect | Status: new >> Priority: Normal | Milestone: MacPorts 1.8.0 >> Component: base | Version: 1.7.0 >> Keywords: | Port: >> ------------------------------------- >> +-------------------------------------- >> MacPorts should not allow users to configure it with >> `--prefix=/usr/local`. Doing so surely breaks some ports, such as >> [comment:ticket:15778:3 macfuse]. > > I don't think we should forbid it completely. Adding a warning and a > link to the appropriate FAQ entry should be enough. The most compelling reason I can think of to forbid prefix from being /usr/local is that most software installs there by default when configured without specifying a prefix. This means it would be very easy for someone to overwrite something installed by MacPorts, or at least to install software into the MacPorts prefix, if they configured something by hand and forgot to (or did not know they should) specify a different prefix. There are also binary packages that install into /usr/local. MySQL and Graphviz come to mind. Ok, the MySQL binary installs into /usr/ local/mysql-${version} so it won't conflict with MacPorts software, but that's still under /usr/local. Graphviz installs to prefix /usr/ local. I asked them not to do this but I was unable to dissuade them. From jmr at macports.org Sun Feb 22 22:10:21 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 23 Feb 2009 17:10:21 +1100 Subject: [MacPorts] #18602: Prevent MacPorts from being configured with --prefix=/usr/local In-Reply-To: <3ED4E609-3B80-4D69-8673-2901A6D86074@macports.org> References: <059.da3053b394f63ca52b512dc50bef8d26@macports.org> <49A221BC.10504@macports.org> <3ED4E609-3B80-4D69-8673-2901A6D86074@macports.org> Message-ID: <49A23DCD.4090100@macports.org> Ryan Schmidt wrote: > On Feb 22, 2009, at 22:10, Rainer M?ller wrote: > >>> #18602: Prevent MacPorts from being configured with --prefix=/usr/local >>> -------------------------------------+-------------------------------------- >>> >>> Reporter: ryandesign@? | Owner: macports-tickets@? >>> Type: defect | Status: new >>> Priority: Normal | Milestone: MacPorts 1.8.0 >>> Component: base | Version: 1.7.0 >>> Keywords: | Port: >>> -------------------------------------+-------------------------------------- >>> >>> MacPorts should not allow users to configure it with >>> `--prefix=/usr/local`. Doing so surely breaks some ports, such as >>> [comment:ticket:15778:3 macfuse]. >> >> I don't think we should forbid it completely. Adding a warning and a >> link to the appropriate FAQ entry should be enough. > > > > The most compelling reason I can think of to forbid prefix from being > /usr/local is that most software installs there by default when > configured without specifying a prefix. This means it would be very easy > for someone to overwrite something installed by MacPorts, or at least to > install software into the MacPorts prefix, if they configured something > by hand and forgot to (or did not know they should) specify a different > prefix. > > There are also binary packages that install into /usr/local. MySQL and > Graphviz come to mind. Ok, the MySQL binary installs into > /usr/local/mysql-${version} so it won't conflict with MacPorts software, > but that's still under /usr/local. Graphviz installs to prefix > /usr/local. I asked them not to do this but I was unable to dissuade them. You couldn't dissuade them because /usr/local is in fact the correct place to install non-vendor-supplied software that should be available to all users of the machine. The issue for us is that it's hard to get configure scripts to not look there. I really don't think we should be trying to save users from themselves to this extent. If they really want to shoot themselves in the foot, that's their choice. We should, however, make it very clear that that is what they are doing. - Josh From ryandesign at macports.org Sun Feb 22 22:53:55 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 23 Feb 2009 00:53:55 -0600 Subject: [MacPorts] #18602: Prevent MacPorts from being configured with --prefix=/usr/local In-Reply-To: <49A23DCD.4090100@macports.org> References: <059.da3053b394f63ca52b512dc50bef8d26@macports.org> <49A221BC.10504@macports.org> <3ED4E609-3B80-4D69-8673-2901A6D86074@macports.org> <49A23DCD.4090100@macports.org> Message-ID: <13BC65A0-07D2-4A98-85E2-A5BAA5ACC92A@macports.org> On Feb 23, 2009, at 00:10, Joshua Root wrote: > Ryan Schmidt wrote: > >> On Feb 22, 2009, at 22:10, Rainer M?ller wrote: >> >>>> #18602: Prevent MacPorts from being configured with --prefix=/ >>>> usr/local >>>> ------------------------------------- >>>> +-------------------------------------- >>>> >>>> Reporter: ryandesign@? | Owner: macports- >>>> tickets@? >>>> Type: defect | Status: new >>>> Priority: Normal | Milestone: MacPorts 1.8.0 >>>> Component: base | Version: 1.7.0 >>>> Keywords: | Port: >>>> ------------------------------------- >>>> +-------------------------------------- >>>> >>>> MacPorts should not allow users to configure it with >>>> `--prefix=/usr/local`. Doing so surely breaks some ports, such as >>>> [comment:ticket:15778:3 macfuse]. >>> >>> I don't think we should forbid it completely. Adding a warning and a >>> link to the appropriate FAQ entry should be enough. >> >> The most compelling reason I can think of to forbid prefix from being >> /usr/local is that most software installs there by default when >> configured without specifying a prefix. This means it would be >> very easy >> for someone to overwrite something installed by MacPorts, or at >> least to >> install software into the MacPorts prefix, if they configured >> something >> by hand and forgot to (or did not know they should) specify a >> different >> prefix. >> >> There are also binary packages that install into /usr/local. MySQL >> and >> Graphviz come to mind. Ok, the MySQL binary installs into >> /usr/local/mysql-${version} so it won't conflict with MacPorts >> software, >> but that's still under /usr/local. Graphviz installs to prefix >> /usr/local. I asked them not to do this but I was unable to >> dissuade them. > > You couldn't dissuade them because /usr/local is in fact the correct > place to install non-vendor-supplied software that should be available > to all users of the machine. So then Graphviz will not be alone in having chosen this location for their binary installer, and any number of software packages' binary installers could thus cause harm to a user's MacPorts installation if they have used prefix /usr/local. > The issue for us is that it's hard to get > configure scripts to not look there. Right, and if some ports were to try to implement measures to specifically ignore /usr/local, well then that could easily cause problems if the prefix were in fact /usr/local. > I really don't think we should be trying to save users from themselves > to this extent. If they really want to shoot themselves in the foot, > that's their choice. We should, however, make it very clear that > that is > what they are doing. There's an infinite number of other prefixes the user could choose that would work fine. Why allow the user to use this prefix which will quite probably cause them problems in the future? What benefit can be obtained from using MacPorts with prefix /usr/local that cannot be achieved with other prefixes? For good measure, we should prevent installation with prefix / or / usr as well, and, why not, /sw. I've worked in tech support, and from that standpoint, I'd like to do what we can to reduce our email support volume. Preventing user actions which have no discernible benefit but which have a strong possibility of detriment seems like a win to me. If we went with a warning instead of preventing the use of these prefixes outright, when would it be printed? My concern is that there is already so much output produced by configure, make and make install that it's easy to overlook things. To expand on what I said before, we have a policy of telling users not to install software manually into the MacPorts prefix. Yet you know users just can't stop installing software separately from MacPorts. It's bad enough when users install software manually in / usr/local when they're using MacPorts in another prefix, but at least then we can tell them "delete /usr/local". Allowing users to get into a situation where they are likely to mix these in the same prefix is even worse, because then the answer is "delete /usr/local and reinstall MacPorts and all your ports". And you know a user who encounters problems will not begin their email with "I installed MacPorts into /usr/local and then installed some other software package that installs into /usr/local". It'll be many messages later before that information is finally extracted. Which will be time that could have been better spent on other issues to which we do not already know solutions. This issue already has a solution, which is "don't use /usr/local as your prefix" so I support enforcing this solution. On Panther, libpixman requires Xcode 1.5. On Tiger, cairo requires Xcode 2.4.1+. On Leopard, graphviz requires Xcode 3.1+. If a user were to try with earlier Xcode, they would get an error. Yes, we already state those are the minimum versions required by MacPorts, but users don't read that, and they assume Software Update will update Xcode for them, which it won't. So the portfiles enforce this requirement with an error message telling them exactly what's wrong, instead of letting them proceed anyway to inevitably fail. Ok, maybe that's not a great comparison, since using an earlier Xcode with these ports will 100% definitely prevent them from installing, whereas using prefix /usr/local will not 100% definitely cause the user problems. But still it's a much greater chance of badness than with most other prefixes. One could argue this makes preventing /usr/ local et al all the more important: if I did not have Xcode version checks in libpixman, cairo and graphviz, it would merely waste a little of the user's time now while their computer compiles until it encounters one of several now well-known errors, they would either look it up or ask the list and be told to upgrade Xcode and would be on their way. Whereas installing with prefix /usr/local is a time bomb waiting to explode later when the user has long forgotten a warning printed during MacPorts installation. That's what I think about it anyway. I do go on, don't I? From raimue at macports.org Mon Feb 23 00:57:30 2009 From: raimue at macports.org (=?windows-1252?Q?Rainer_M=FCller?=) Date: Mon, 23 Feb 2009 09:57:30 +0100 Subject: [MacPorts] #18602: Prevent MacPorts from being configured with --prefix=/usr/local In-Reply-To: <13BC65A0-07D2-4A98-85E2-A5BAA5ACC92A@macports.org> References: <059.da3053b394f63ca52b512dc50bef8d26@macports.org> <49A221BC.10504@macports.org> <3ED4E609-3B80-4D69-8673-2901A6D86074@macports.org> <49A23DCD.4090100@macports.org> <13BC65A0-07D2-4A98-85E2-A5BAA5ACC92A@macports.org> Message-ID: <49A264FA.90503@macports.org> Ryan Schmidt wrote: > There's an infinite number of other prefixes the user could choose > that would work fine. Why allow the user to use this prefix which > will quite probably cause them problems in the future? What benefit > can be obtained from using MacPorts with prefix /usr/local that > cannot be achieved with other prefixes? Creating disk images/installers which install to /usr/local? ;-) > For good measure, we should prevent installation with prefix / or / > usr as well, and, why not, /sw. I think these are only invalid on Mac OS X, PureDarwin users (or users of other OS) could use /usr, right? Not that this is common, just for compatibility. > [...] > If we went with a warning instead of preventing the use of these > prefixes outright, when would it be printed? My concern is that there > is already so much output produced by configure, make and make > install that it's easy to overlook things. We could add checks which abort with a big fat warning on such paths, but can be avoided by additionally using --enable-unsafe-prefix. Would this be a good consensus? Rainer From kngspook at gmail.com Mon Feb 23 01:29:50 2009 From: kngspook at gmail.com (Neil) Date: Mon, 23 Feb 2009 04:29:50 -0500 Subject: gcc_select confusion Message-ID: <77e4079b0902230129q1c8a8a33jd95b66be1e82d212@mail.gmail.com> I'm slightly confused as to the *_select naming, particularly for gcc... For example: The built-in python is selected with "python25-apple". The port python25 is selected with "python25". But with gcc_select, "gcc40-apple" refers to the port gcc40-apple...so how do I select between the built-in/Xcode gcc40, the gcc40-apple port, and the vanilla gcc40 port? From raimue at macports.org Mon Feb 23 02:03:16 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 23 Feb 2009 11:03:16 +0100 Subject: gcc_select confusion In-Reply-To: <77e4079b0902230129q1c8a8a33jd95b66be1e82d212@mail.gmail.com> References: <77e4079b0902230129q1c8a8a33jd95b66be1e82d212@mail.gmail.com> Message-ID: <49A27464.7000904@macports.org> Neil wrote: > I'm slightly confused as to the *_select naming, particularly for gcc... > > For example: > The built-in python is selected with "python25-apple". > The port python25 is selected with "python25". > > But with gcc_select, "gcc40-apple" refers to the port gcc40-apple...so > how do I select between the built-in/Xcode gcc40, the gcc40-apple > port, and the vanilla gcc40 port? It's true, that's quite confusing. This has it's historic reasoning as /usr/bin/gcc has ever been the default compiler, so gcc4x actually refers to gcc versions provided by Xcode. To select versions installed by MacPorts, you need to use mp-gcc4x. You can use 'gcc_select -l' to see all versions currently available on your system. Rainer From krischik at macports.org Mon Feb 23 05:20:45 2009 From: krischik at macports.org (Martin Krischik) Date: Mon, 23 Feb 2009 14:20:45 +0100 Subject: Default modeline In-Reply-To: <49A1A2CE.10905@macports.org> References: <20090130172524.79B9ADDDE2B@beta.macosforge.org> <115306A2-EDDB-4540-87CD-B9F481E1B37A@macports.org> <49A1905B.4020302@macports.org> <49A1A2CE.10905@macports.org> Message-ID: <49A2A2AD.5010100@macports.org> Rainer M?ller schrieb: > Martin Krischik wrote: >> Am 01.02.2009 um 22:34 schrieb Ryan Schmidt: > [...] >>>> +############################################################ {{{1 >>>> ########### >>>> +# vim: set nowrap tabstop=4 shiftwidth=4 softtabstop=4 noexpandtab : >>>> +# vim: set textwidth=0 filetype=tcl foldmethod=marker nospell : >>> We already have the modeline in the first line of the portfile. If >>> these lines are adding things that we don't have in the modeline, >>> what are they and would they be useful to consider adding to our >>> recommended modeline? >> First and foremost they use the full names of the settings instead of >> abbreviations. So lets compare: >> >> 1) fenc=utf-8 fileencoding >> 2) ft=tcl filetype >> 3) et expandtab >> 4) sw=4 shiftwidth >> 5) ts=4 tabstop >> 6) sts=4 softtabstop >> >> No. 3 and 5 contradict each other - if tabs are expanded to spaces you >> don't need to set the physical tab stops. My Suggestion is tabstop=8 >> noexpandtab - most terminals set the tabstop to 8. > I agree. Usually when using vim tabstop should not be changed, only > shiftwidth. I am not sure if using softtabstop is "compatible" with > other editors. Most other editors are not able to make a difference > between tabs at indentation level and somewhere else in the file. This > could be the reason why our default modeline is changing tabstop. Out of the top of my head: Vim can do it, Emacs can do it, IBMs LXPM can do it, the Microsofts Programmers-Workbench can do it. Most editors I have used over time could distinguish between softtabstops (what happens when you press TAB) and hardtabstops (what happens when you save the file). >> I also have foldmethod=marker which might be helpful for very large >> Portfiles - you can then fold parts of the source with {{{ and }}}. > > Useless if not also using foldenable. I would leave this for everyone to > add in their .vim/filetype.vim. Some people do not like folding. foldmakers won't activate foldenable - it only tells which fold method the author used inside the file. Note that I don't set foldenable itself. > For example: > au BufRead,BufNewFile Portfile setlocal foldenable foldmethod=marker That suggest that you think that marker is the only possible options an no one will ever create syntax or expression folding for tcl? >> textwidth=0 is actually wrong - better would be textwidth=78 - one can >> then format comments with the "gq" command. > > I have that set for all text/code files anyway. I don't think we should > enforce a specific textwidth for Portfiles. For example commands in > destroot phases or variant lines with descriptions are often longer than > 80 characters. True, in addition to "gq" you also get unwanted new lines. And with Portfile you do need long lines most of the time. Martin -- Martin Krischik krischik at users.sourceforge.net From kngspook at gmail.com Mon Feb 23 16:55:27 2009 From: kngspook at gmail.com (Neil) Date: Mon, 23 Feb 2009 19:55:27 -0500 Subject: gcc_select confusion In-Reply-To: <49A27464.7000904@macports.org> References: <77e4079b0902230129q1c8a8a33jd95b66be1e82d212@mail.gmail.com> <49A27464.7000904@macports.org> Message-ID: <77e4079b0902231655y7883e28sb12442555365e180@mail.gmail.com> On Mon, Feb 23, 2009 at 5:03 AM, Rainer M?ller wrote: > Neil wrote: > > I'm slightly confused as to the *_select naming, particularly for gcc... > > > > For example: > > The built-in python is selected with "python25-apple". > > The port python25 is selected with "python25". > > > > But with gcc_select, "gcc40-apple" refers to the port gcc40-apple...so > > how do I select between the built-in/Xcode gcc40, the gcc40-apple > > port, and the vanilla gcc40 port? > > It's true, that's quite confusing. This has it's historic reasoning as > /usr/bin/gcc has ever been the default compiler, so gcc4x actually > refers to gcc versions provided by Xcode. To select versions installed > by MacPorts, you need to use mp-gcc4x. > > Should I perhaps open a ticket to standardize it a bit, or are people happy with the way things are now? One thought I had, which might make a bit of sense, is to just have a 'system' selection. Simple, intuitive, uniform, and roughly corresponds with things like the variant +system_x11. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimue at macports.org Mon Feb 23 18:31:39 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 24 Feb 2009 03:31:39 +0100 Subject: gcc_select confusion In-Reply-To: <77e4079b0902231655y7883e28sb12442555365e180@mail.gmail.com> References: <77e4079b0902230129q1c8a8a33jd95b66be1e82d212@mail.gmail.com> <49A27464.7000904@macports.org> <77e4079b0902231655y7883e28sb12442555365e180@mail.gmail.com> Message-ID: <49A35C0B.7040708@macports.org> Neil wrote: > Should I perhaps open a ticket to standardize it a bit, or are people > happy with the way things are now? Standardizing is a good idea. But discussion about the topic should happen on the mailing list. > One thought I had, which might make a bit of sense, is to just have a > 'system' selection. Simple, intuitive, uniform, and roughly corresponds > with things like the variant +system_x11. In case of gcc where the system provides more than one version just 'system' is not sufficient. Also, the preferred gcc is the one from the system/Xcode/Apple, that's why the versions from MacPorts have the prefixed names. Rainer From kngspook at gmail.com Mon Feb 23 19:14:41 2009 From: kngspook at gmail.com (Neil) Date: Mon, 23 Feb 2009 22:14:41 -0500 Subject: gcc_select confusion In-Reply-To: <49A35C0B.7040708@macports.org> References: <77e4079b0902230129q1c8a8a33jd95b66be1e82d212@mail.gmail.com> <49A27464.7000904@macports.org> <77e4079b0902231655y7883e28sb12442555365e180@mail.gmail.com> <49A35C0B.7040708@macports.org> Message-ID: <77e4079b0902231914k750dd783v65d113a572f25766@mail.gmail.com> On Mon, Feb 23, 2009 at 9:31 PM, Rainer M?ller wrote: > Neil wrote: > > Should I perhaps open a ticket to standardize it a bit, or are people > > happy with the way things are now? > > Standardizing is a good idea. But discussion about the topic should > happen on the mailing list. Kay. > > One thought I had, which might make a bit of sense, is to just have a > > 'system' selection. Simple, intuitive, uniform, and roughly corresponds > > with things like the variant +system_x11. > > In case of gcc where the system provides more than one version just > 'system' is not sufficient. Also, the preferred gcc is the one from the > system/Xcode/Apple, that's why the versions from MacPorts have the > prefixed names. > On my system, only gcc-4.0 shows up in gcc_select (though in Xcode I have a selection of 5 different ones); how would I get others to show up in gcc_select? I suppose in that case, we could use "-system" (or "-builtin" or "-distrib" or something else) as a prefix/suffix. But I feel like it's counter-intuitive to have "python25-apple" be the built-in/system python, and "gcc40-apple" be something installed by MacPorts (which confused me for quite some time). And it seems inconsistent to label the MP's gcc's "mp-gcc40", but MP's Pythons a prefix-less "python25". (I suppose that last paragraph was a little redundant...) -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimue at macports.org Mon Feb 23 19:44:22 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 24 Feb 2009 04:44:22 +0100 Subject: gcc_select confusion In-Reply-To: <77e4079b0902231914k750dd783v65d113a572f25766@mail.gmail.com> References: <77e4079b0902230129q1c8a8a33jd95b66be1e82d212@mail.gmail.com> <49A27464.7000904@macports.org> <77e4079b0902231655y7883e28sb12442555365e180@mail.gmail.com> <49A35C0B.7040708@macports.org> <77e4079b0902231914k750dd783v65d113a572f25766@mail.gmail.com> Message-ID: <49A36D16.5080405@macports.org> Neil wrote: > On my system, only gcc-4.0 shows up in gcc_select (though in Xcode I > have a selection of 5 different ones); how would I get others to show up > in gcc_select? What other versions do you see in Xcode? I assume gcc 4.2 and llvm-gcc 4.2 at least, what else? I submitted a ticket some time ago to add gcc42 and llvm-gcc42. http://trac.macports.org/ticket/17458 > I suppose in that case, we could use "-system" (or "-builtin" or > "-distrib" or something else) as a prefix/suffix. > > But I feel like it's counter-intuitive to have "python25-apple" be the > built-in/system python, and "gcc40-apple" be something installed by > MacPorts (which confused me for quite some time). And it seems > inconsistent to label the MP's gcc's "mp-gcc40", but MP's Pythons a > prefix-less "python25". The problem is we have a different policy for python than for gcc. We prefer python from MacPorts, but gcc from Xcode. Rainer From ryandesign at macports.org Tue Feb 24 00:03:46 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 24 Feb 2009 02:03:46 -0600 Subject: [47207] trunk/dports/emulators/atari800 In-Reply-To: <20090223135800.E89DD105397F@beta.macosforge.org> References: <20090223135800.E89DD105397F@beta.macosforge.org> Message-ID: <9ED574E1-C8C6-4721-BC44-6423EA5FD52E@macports.org> On Feb 23, 2009, at 07:58, krischik at macports.org wrote: > --- trunk/dports/emulators/atari800/files/Atari320XE.app/Contents/ > MacOS/Atari320XE.command (rev 0) > +++ trunk/dports/emulators/atari800/files/Atari320XE.app/Contents/ > MacOS/Atari320XE.command 2009-02-23 13:58:00 UTC (rev 47207) > @@ -0,0 +1,43 @@ > +#!/bin/zsh > +############################################################## > {{{1 ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}} > 1 ########## > + > +local User_Data="${HOME}/Library/Application Support/Atari800" > +local System_Data="/opt/local/share/atari800"; In this revision, you've hardcoded /opt/local in several places again. This needs to be fixed to work with any prefix again. From ryandesign at macports.org Tue Feb 24 00:07:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 24 Feb 2009 02:07:23 -0600 Subject: [47216] trunk/dports/science/gwyddion/Portfile In-Reply-To: <20090223182946.95460105C873@beta.macosforge.org> References: <20090223182946.95460105C873@beta.macosforge.org> Message-ID: <867B8214-B767-4F1C-A147-B85A110A8086@macports.org> On Feb 23, 2009, at 12:29, rowue at macports.org wrote: > +# deactivation because of gtkglext problems > +# platform darwin 9 { > +# if {[variant_isset system_x11]} { > +# set darwin_9_glpath /System/Library/Frameworks/ > OpenGL.framework/Versions/ > +# configure.ldflags-append -Wl,-dylib_file,$ > {darwin_9_glpath}/A/Libraries/libGL.dylib:\ > +# ${darwin_9_glpath}/A/Libraries/libGL.dylib > +# } > +# } I don't understand this comment above this disabled platform variant. Because all that the code in the platform variant is doing is working around a bug in Xcode 3.0 on Leopard which has been fixed in Xcode 3.1. So it should be safe to remove that entire block. Ideally you would replace it with a check to make sure the user has Xcode 3.1, like this: http://trac.macports.org/changeset/47091 From ryandesign at macports.org Tue Feb 24 00:12:32 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 24 Feb 2009 02:12:32 -0600 Subject: [47209] trunk/dports/emulators/free42/Portfile In-Reply-To: <20090223140017.1FF221053B3D@beta.macosforge.org> References: <20090223140017.1FF221053B3D@beta.macosforge.org> Message-ID: <4B213EF4-DE4B-4B4A-9BCE-EDBF1C1AAD04@macports.org> On Feb 23, 2009, at 08:00, krischik at macports.org wrote: > Revision: 47209 > http://trac.macports.org/changeset/47209 > Author: krischik at macports.org > Date: 2009-02-23 06:00:16 -0800 (Mon, 23 Feb 2009) > Log Message: > ----------- > Using application bundles to start the program - id. You also added --jobs=${build.jobs} to the build.args without noting it in your commit message. I've asked about this in responses to previous commits where you added this option to other ports. In free42 it's even more puzzling, since you override the build phase entirely, thus the build.args aren't used at all and parallel building does not happen. Neither does "nice" building for that matter, two reasons why it's best not to override the build phase if possible, since we want users to be able to set these options in macports.conf and have them take effect for all ports. One solution could be to let the build phase run as usual to build the binary version, and in post-build you could build again for the decimal version. I'm hesitant to suggest this, but you could do it the way the php5 portfile manages to build both fastcgi and apache2 modules at the same time. php5's makefile unfortunately does not allow this -- it's an either/or choice, just like for free42 binary vs. decimal appears to be an either/or choice -- but I wanted the user to be able to select both +apache2 and +fastcgi variants at the same time. So if the user chooses both, I run the build once normally, then add more configure arguments and run it a second time with command_exec. command_exec is supposed to be an internal MacPorts command not to be used by portfiles, and php5 and php5-devel are the only ports that use it, but I felt it was better to use command_exec, which properly implements all the complexities of executing a command, including setting the environment, adding arguments and outputting debug messages, than implementing all that logic again in the portfile. Further comments on your portfile. You set "-DNO_SINCOS" in the build phase and add some LIBS to the build.env globally but the README that comes with the software only mentions these being needed on Mac OS X. Thus you should do this only in a "platform darwin" block. It should also occur in the patch phase not the build phase. Depending on how many places in the source this replacement needs to be done, it might be better to make it a patchfile instead of a reinplace. (If many, I can see that a patchfile could grow large and unwieldy, but if only one or a few places, then a patchfile has the advantage of providing context assistance when the upstream source changes and you have to modify the portfile to follow.) I'm attaching a patchfile implementing my suggestions. I also had to disable parallel build, actually, since it failed with "No rule to make target `skin2cc.cc', needed by `skin2cc'" when I left it enabled. Now all that remains is that the items you install in $ {applications_dir} don't actually open the calculator. They appear in the Dock for a split-second, then disappear. When I tried running $ {prefix}/bin/free42dec directly I noticed one problem was that X11 was not started. I'm on Tiger, and X11 only auto-starts on Leopard and later, so on Tiger and earlier, you have to start X11 first. But even if X11 is started, your application wrappers do not open the calculator when double-clicked. They do open the calculator when I run ${applications_dir}/Free42-Decimal.app/Contents/MacOS/Free42- Decimal.command from the Terminal. So I'm not sure what's up. > Modified Paths: > -------------- > trunk/dports/emulators/free42/Portfile > > Modified: trunk/dports/emulators/free42/Portfile > =================================================================== > --- trunk/dports/emulators/free42/Portfile 2009-02-23 13:59:42 UTC > (rev 47208) > +++ trunk/dports/emulators/free42/Portfile 2009-02-23 14:00:16 UTC > (rev 47209) > @@ -1,6 +1,6 @@ > # -*- coding: utf-8; mode: tcl; tab-width: 4; truncate-lines: t; > indent-tabs-mode: nil; c-basic-offset: 4; -*- > +# $Id$ > # vim: set fileencoding=utf-8 tabstop=4 shiftwidth=4 softtabstop=4 > noexpandtab filetype=tcl : > -# $Id$ > > PortSystem 1.0 > > @@ -37,8 +37,10 @@ > > worksrcdir ${name} > use_parallel_build yes > +build.args --jobs=${build.jobs} > use_configure no > > + > post-extract { > system "unzip -q ${distpath}/${skin} -d ${workpath}/skin" > } -------------- next part -------------- A non-text attachment was scrubbed... Name: free42.diff Type: application/octet-stream Size: 1454 bytes Desc: not available URL: From ryandesign at macports.org Tue Feb 24 00:46:36 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 24 Feb 2009 02:46:36 -0600 Subject: [47239] trunk/dports/audio/mpd In-Reply-To: <20090224014857.C6B651066DF4@beta.macosforge.org> References: <20090224014857.C6B651066DF4@beta.macosforge.org> Message-ID: On Feb 23, 2009, at 19:48, rmsfisher at macports.org wrote: > platform macosx { > configure.args-delete --enable-ao > depends_lib-delete port:libao > + startupitem.create yes > + startupitem.start "${prefix}/bin/mpd --no-daemon ${prefix}/ > etc/mpd.conf" > + startupitem.stop "${prefix}/bin/mpd --kill" > } Is there a special reason you're restricting startupitem creation to Mac OS X? As far as I know, startupitem.create is supposed to work on other operating systems too. Of course it does not use launchd or StartupItems on other systems as it does on Mac OS X >=10.4.x or <=10.3.x respectively. I suppose we should update the Guide, which implies only launchd plists are created. From krischik at macports.org Tue Feb 24 01:29:58 2009 From: krischik at macports.org (Martin Krischik) Date: Tue, 24 Feb 2009 10:29:58 +0100 Subject: [47209] trunk/dports/emulators/free42/Portfile In-Reply-To: <4B213EF4-DE4B-4B4A-9BCE-EDBF1C1AAD04@macports.org> References: <20090223140017.1FF221053B3D@beta.macosforge.org> <4B213EF4-DE4B-4B4A-9BCE-EDBF1C1AAD04@macports.org> Message-ID: <49A3BE16.1080503@macports.org> Ryan Schmidt schrieb: > > On Feb 23, 2009, at 08:00, krischik at macports.org wrote: > >> Revision: 47209 >> http://trac.macports.org/changeset/47209 >> Author: krischik at macports.org >> Date: 2009-02-23 06:00:16 -0800 (Mon, 23 Feb 2009) >> Log Message: >> ----------- >> Using application bundles to start the program - id. [... skip Portfile fine tuning - patches are applied] > Now all that remains is that the items you install in > ${applications_dir} don't actually open the calculator. They appear in > the Dock for a split-second, then disappear. That is normal behaviour - note the & at the end of "/opt/local/bin/free42bin &". If you remove the & then you get an bouncy icon. But thinking of it a little more: If gtk2 is build with +quarz then the & is wrong (see start-up script for the atar800). How could one detect that? > When I tried running > ${prefix}/bin/free42dec directly I noticed one problem was that X11 was > not started. Adding an X-Server autostart to the *.commands would not be a problem. There is a TCP packet for Z-Shell - I could check for the existence of an X-Server and start when needed. Just 2 Problems: 1) Does the Z-Shell which comes with Tiger include /usr/lib/zsh/4.3.4/zsh/net/tcp.so ? 2) What about users which compiled gtk2 with +quarz variant? > I'm on Tiger, and X11 only auto-starts on Leopard and > later, so on Tiger and earlier, you have to start X11 first. But even if > X11 is started, your application wrappers do not open the calculator > when double-clicked. They do open the calculator when I run > ${applications_dir}/Free42-Decimal.app/Contents/MacOS/Free42-Decimal.command > from the Terminal. So I'm not sure what's up. That is tricky indeed. Maybe Tiger does not support application bundles with shell scripts. One can create an application bundle with AppleScript - but that leaves two icons on the dock. Not so nice. One could also remove the command file and link the executable itself. But then you would be left with the two default skins. And it does not solve the X-Server problem. BTW: did you try: "open ${applications_dir}/Free42-Decimal.app" on the terminal? *Sometimes* it gives helpful error message. Martin -- Martin Krischik krischik at users.sourceforge.net From raimue at macports.org Tue Feb 24 01:47:17 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 24 Feb 2009 10:47:17 +0100 Subject: [47216] trunk/dports/science/gwyddion/Portfile In-Reply-To: <867B8214-B767-4F1C-A147-B85A110A8086@macports.org> References: <20090223182946.95460105C873@beta.macosforge.org> <867B8214-B767-4F1C-A147-B85A110A8086@macports.org> Message-ID: <49A3C225.4020805@macports.org> Ryan Schmidt wrote: > [...] > So it should be safe to remove that entire block. Ideally you > would replace it with a check to make sure the user has Xcode 3.1, > like this: > > http://trac.macports.org/changeset/47091 I think Xcode 3.x allows to install the applications to other paths than /Developer/Applications. Although this might be rare, this check isn't error proof for all users. But I don't know a better way to check for the Xcode version either. The workaround for Xcode 3.0 should not do any harm in Xcode 3.1, so it should be safe to apply it without checks. Rainer From ryandesign at macports.org Tue Feb 24 03:46:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 24 Feb 2009 05:46:13 -0600 Subject: [47216] trunk/dports/science/gwyddion/Portfile In-Reply-To: <49A3C225.4020805@macports.org> References: <20090223182946.95460105C873@beta.macosforge.org> <867B8214-B767-4F1C-A147-B85A110A8086@macports.org> <49A3C225.4020805@macports.org> Message-ID: <91182DF9-0535-4276-BFD8-240CDDED199A@macports.org> On Feb 24, 2009, at 03:47, Rainer M?ller wrote: > Ryan Schmidt wrote: >> [...] >> So it should be safe to remove that entire block. Ideally you >> would replace it with a check to make sure the user has Xcode 3.1, >> like this: >> >> http://trac.macports.org/changeset/47091 > > I think Xcode 3.x allows to install the applications to other paths > than > /Developer/Applications. Although this might be rare, this check isn't > error proof for all users. But I don't know a better way to check for > the Xcode version either. MacPorts base includes code to check the Xcode version too (at configure time), and it also checks in /Developer/Applications. I don't know how to support other Xcode install locations and I'm not going to spend time now figuring it out. I haven't seen any messages on the mailing list about problems regarding this, so I guess nobody using MacPorts installs their Xcode elsewhere. > The workaround for Xcode 3.0 should not do any harm in Xcode 3.1, > so it > should be safe to apply it without checks. Yes, however I've seen many commits go by already in which the Xcode 3.0 libGL workaround was removed from ports for the reason that it has been fixed in Xcode 3.1. :-/ I think it is reasonable to require Xcode 3.1+ on Leopard, 2.4.1+ on Tiger, and 1.5 on Panther. MacPorts base should do this, however, and not leave it to the portfiles. #12794 should get resolved. http://trac.macports.org/ticket/12794 From ryandesign at macports.org Tue Feb 24 03:52:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 24 Feb 2009 05:52:35 -0600 Subject: [47216] trunk/dports/science/gwyddion/Portfile In-Reply-To: <2C396498-6E49-43A9-B81B-179EEDE62231@macports.org> References: <20090223182946.95460105C873@beta.macosforge.org> <867B8214-B767-4F1C-A147-B85A110A8086@macports.org> <2C396498-6E49-43A9-B81B-179EEDE62231@macports.org> Message-ID: <79A474DE-15BA-472F-91C0-DF88C4D61152@macports.org> On Feb 24, 2009, at 02:24, Rolf W?rdemann wrote: > Am 24.02.2009 um 09:07 schrieb Ryan Schmidt: > >> On Feb 23, 2009, at 12:29, rowue at macports.org wrote: >> >>> +# deactivation because of gtkglext problems >>> +# platform darwin 9 { >>> +# if {[variant_isset system_x11]} { >>> +# set darwin_9_glpath /System/Library/Frameworks/ >>> OpenGL.framework/Versions/ >>> +# configure.ldflags-append -Wl,-dylib_file,$ >>> {darwin_9_glpath}/A/Libraries/libGL.dylib:\ >>> +# ${darwin_9_glpath}/A/Libraries/libGL.dylib >>> +# } >>> +# } >> >> I don't understand this comment above this disabled platform >> variant. Because all that the code in the platform variant is >> doing is working around a bug in Xcode 3.0 on Leopard which has >> been fixed in Xcode 3.1. So it should be safe to remove that >> entire block. Ideally you would replace it with a check to make >> sure the user has Xcode 3.1, like this: >> >> http://trac.macports.org/changeset/47091 > > At first: thanks! > > is XCode submitted to everybody (via Update?) - or did people have > to submit to ADC to get this? Apple does not provide an automatic software update mechanism for Xcode. You must update Xcode by logging in to ADC, downloading a disk image, and installing the package from the disk image. Accessing ADC requires a membership, but basic membership is free. From mark at dxradio.demon.co.uk Tue Feb 24 03:55:40 2009 From: mark at dxradio.demon.co.uk (Mark Hattam) Date: Tue, 24 Feb 2009 11:55:40 +0000 Subject: [47259] trunk/dports/x11/xorg-libs/Portfile In-Reply-To: <20090224080924.79B2C106E76F@beta.macosforge.org> References: <20090224080924.79B2C106E76F@beta.macosforge.org> Message-ID: On 24 Feb 2009, at 08:09, jeremyhu at macports.org wrote: > Revision47259Authorjeremyhu at macports.orgDate2009-02-24 00:09:23 > -0800 (Tue, 24 Feb 2009)Log Message > xorg-libs: Force mesa, now that Tiger has HW rendering in our libGL > Modified Paths > ? trunk/dports/x11/xorg-libs/Portfile > Diff > Modified: trunk/dports/x11/xorg-libs/Portfile (47258 => 47259) > --- trunk/dports/x11/xorg-libs/Portfile 2009-02-24 08:08:32 UTC (rev > 47258) > +++ trunk/dports/x11/xorg-libs/Portfile 2009-02-24 08:09:23 UTC (rev > 47259) > @@ -3,7 +3,7 @@ > PortSystem 1.0 > > name xorg-libs > -version 20090105 > +version 20090224 > categories x11 devel > maintainers jeremyhu openmaintainer > description X.org lib meta-package > @@ -14,7 +14,7 @@ > > depends_lib \ > port:Xft2 \ > - lib:libGLU.1:mesa \ > + port:mesa \ > port:xorg-libAppleWM \ > port:xorg-libFS \ > port:xorg-libX11 \ This seems to have got in a catch 22 scenario ... iMac:~ mark$ sudo port selfupdate MacPorts base version 1.700 installed Downloaded MacPorts base version 1.700 The MacPorts installation is not outdated so it was not updated iMac:~ mark$ sudo port outdated The following installed ports are outdated: xorg-libs 20090105_0 < 20090224_0 iMac:~ mark$ sudo port upgrade outdated ---> Activating mesa @7.2_5+hw_render Error: Activating mesa @7.2_5 failed: Image error: /opt/local/include/ GL/glxint.h is being used by the active xorg-glproto port. Please deactivate this port first, or use the -f flag to force the activation. ---> Activating mesa @7.2_5+hw_render Error: Target org.macports.activate returned: Image error: /opt/local/ include/GL/glxint.h is being used by the active xorg-glproto port. Please deactivate this port first, or use the -f flag to force the activation. Error: The following dependencies failed to build: mesa Error: Unable to upgrade port: 1 iMac:~ mark$ sudo port deactivate xorg-glproto ---> Deactivating xorg-glproto iMac:~ mark$ sudo port upgrade outdated ---> Activating mesa @7.2_5+hw_render ---> Activating xorg-glproto @1.4.9_0 Error: Activating xorg-glproto @1.4.9_0 failed: Image error: /opt/ local/include/GL/glxint.h is being used by the active mesa port. Please deactivate this port first, or use the -f flag to force the activation. ---> Fetching xorg-libs ---> Verifying checksum(s) for xorg-libs ---> Extracting xorg-libs ---> Configuring xorg-libs ---> Building xorg-libs ---> Staging xorg-libs into destroot ---> Deactivating xorg-libs @20090105_0 ---> Installing xorg-libs @20090224_0 ---> Activating xorg-libs @20090224_0 ---> Cleaning xorg-libs iMac:~ mark$ sudo port activate xorg-glproto ---> Activating xorg-glproto Error: port activate failed: Image error: /opt/local/include/GL/ glxint.h is being used by the active mesa port. Please deactivate this port first, or use the -f flag to force the activation. It looks like glxint.h is not preventing these xorg things working together. Mark From krischik at macports.org Tue Feb 24 11:50:51 2009 From: krischik at macports.org (Martin Krischik) Date: Tue, 24 Feb 2009 20:50:51 +0100 Subject: How to force exactly one variant. Message-ID: <49A44F9B.5000303@macports.org> Hello, I have a little problem gnat-gcc port: You need to specify a bootstrap compiler - that is exactly one. Which leaves me with two problems: 1) if no bootstrap compiler is specified I would like to display a helpful description. 2) If two bootstrap compiler are chosen then an error should be displayed Any ideas from the Portfile gurus? Martin -- Martin Krischik krischik at users.sourceforge.net From kngspook at gmail.com Tue Feb 24 12:06:23 2009 From: kngspook at gmail.com (Neil) Date: Tue, 24 Feb 2009 15:06:23 -0500 Subject: gcc_select confusion In-Reply-To: <49A36D16.5080405@macports.org> References: <77e4079b0902230129q1c8a8a33jd95b66be1e82d212@mail.gmail.com> <49A27464.7000904@macports.org> <77e4079b0902231655y7883e28sb12442555365e180@mail.gmail.com> <49A35C0B.7040708@macports.org> <77e4079b0902231914k750dd783v65d113a572f25766@mail.gmail.com> <49A36D16.5080405@macports.org> Message-ID: <77e4079b0902241206w1312a7f5w6c77cc19a45e0fe0@mail.gmail.com> On Mon, Feb 23, 2009 at 10:44 PM, Rainer M?ller wrote: > Neil wrote: > > On my system, only gcc-4.0 shows up in gcc_select (though in Xcode I > > have a selection of 5 different ones); how would I get others to show up > > in gcc_select? > > What other versions do you see in Xcode? > I assume gcc 4.2 and llvm-gcc 4.2 at least, what else? > > I submitted a ticket some time ago to add gcc42 and llvm-gcc42. > http://trac.macports.org/ticket/17458 > On Xcode 3.1.2 (with iPhone DevKit, though I highly doubt that matters), I see: GCC 3.3, GCC 4.0, GCC 4.2, GCC System Version (4.0), LLVM-GCC 4.2. I not installed any GCCs from MacPorts, and I'm not quite sure what the difference is between GCC 4.0 and GCC System Version (4.0)... (I actually hadn't noticed that until now...) > > > I suppose in that case, we could use "-system" (or "-builtin" or > > "-distrib" or something else) as a prefix/suffix. > > > > But I feel like it's counter-intuitive to have "python25-apple" be the > > built-in/system python, and "gcc40-apple" be something installed by > > MacPorts (which confused me for quite some time). And it seems > > inconsistent to label the MP's gcc's "mp-gcc40", but MP's Pythons a > > prefix-less "python25". > > The problem is we have a different policy for python than for gcc. We > prefer python from MacPorts, but gcc from Xcode. > Do you think we need to change the naming conventions for that though? -------------- next part -------------- An HTML attachment was scrubbed... URL: From blb at macports.org Tue Feb 24 12:56:21 2009 From: blb at macports.org (Bryan Blackburn) Date: Tue, 24 Feb 2009 13:56:21 -0700 Subject: How to force exactly one variant. In-Reply-To: <49A44F9B.5000303@macports.org> References: <49A44F9B.5000303@macports.org> Message-ID: <20090224205621.GC986@ninagal.withay.com> On Tue, Feb 24, 2009 at 08:50:51PM +0100, Martin Krischik said: > Hello, > > I have a little problem gnat-gcc port: You need to specify a bootstrap > compiler - that is exactly one. Which leaves me with two problems: > > 1) if no bootstrap compiler is specified I would like to display a > helpful description. (Note, untested) pre-fetch { if {![variant_isset choice1] && ![variant_isset choice2]} { return -code error "You must choose choice1 or choice2" } } > > 2) If two bootstrap compiler are chosen then an error should be displayed variant choice1 conflicts choice2 {} variant choice2 conflicts choice1 {} port should then handle pointing out the problem if someone tries both +choice1 and +choice2. Bryan > > Any ideas from the Portfile gurus? > > Martin > -- > Martin Krischik > krischik at users.sourceforge.net From ryandesign at macports.org Tue Feb 24 17:31:34 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 24 Feb 2009 19:31:34 -0600 Subject: [47283] trunk/dports/lang/gnat-gcc/Portfile In-Reply-To: <20090224194619.13A6510789A6@beta.macosforge.org> References: <20090224194619.13A6510789A6@beta.macosforge.org> Message-ID: <122343D2-FDBF-43E5-8866-A382BB8D78D0@macports.org> On Feb 24, 2009, at 13:46, krischik at macports.org wrote: > Revision: 47283 > http://trac.macports.org/changeset/47283 > Author: krischik at macports.org > Date: 2009-02-24 11:46:15 -0800 (Tue, 24 Feb 2009) > Log Message: > ----------- > Use prefix for ada variant, add gnuada variant. [snip] > @@ -142,7 +142,7 @@ > # an ada compiler to compile ada. hence it is just a variant. > # > variant macada \ > - description "Uses MacAda compiler to bootstrap!" { > + description "Uses MacAda compiler (http://www.macada.org) to > bootstrap!" { > configure.cc /usr/local/ada-4.3/bin/gcc > configure.cpp /usr/local/ada-4.3/bin/cpp > configure.cxx /usr/local/ada-4.3/bin/g++ > @@ -152,8 +152,8 @@ > configure.env-append GNATBIND=/usr/local/ada-4.3/bin/gnatbind > } > > -variant ada \ > - description "Uses the MacPorts Ada compiler to bootstrap!" { > +variant gnuada \ > + description "Uses the GnuAda (http://gnuada.sourceforge.net/) > compiler to bootstrap!" { > configure.cc /opt/local/bin/gcc-gnat-4.3 > configure.cpp /opt/local/bin/cpp-gnat-4.3 > configure.cxx /opt/local/bin/g++-gnat-4.3 > @@ -163,9 +163,17 @@ > configure.env-append GNATBIND=/opt/local/bin/gnatbind > } > > +variant ada \ > + description "Uses the MacPorts Ada compiler to bootstrap!" { > + configure.cc ${prefix}/bin/gcc-gnat-4.3 > + configure.cpp ${prefix}/bin/cpp-gnat-4.3 > + configure.cxx ${prefix}/bin/g++-gnat-4.3 > + configure.objc ${prefix}/bin/gcc-gnat-4.3 > + configure.env-append PATH=${prefix}/bin:$env(PATH) > + configure.env-append GNATMAKE=${prefix}/bin/gnatmake > + configure.env-append GNATBIND=${prefix}/bin/gnatbind > +} What is the difference between the ada and gnuada variants? It looks like the ada variant uses an ada compiler provided by MacPorts (if so, there should be a dependency on a MacPorts port in that variant), and the gnuada variant uses an ada compiler provided by someone else in binary form which installs into /opt/local? If that's correct, then that's very disconcerting; we should not be encouraging users to install something that puts files into /opt/local without using MacPorts to do so. And the gnuada folks should not be distributing binaries that install things into the MacPorts /opt/local prefix. From jeremyhu at macports.org Tue Feb 24 18:24:23 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Tue, 24 Feb 2009 18:24:23 -0800 Subject: [47259] trunk/dports/x11/xorg-libs/Portfile In-Reply-To: References: <20090224080924.79B2C106E76F@beta.macosforge.org> Message-ID: Yeah, there were some headers conflicting... sorry... should be fixed now. On Feb 24, 2009, at 03:55, Mark Hattam wrote: > > On 24 Feb 2009, at 08:09, jeremyhu at macports.org wrote: > >> Revision47259Authorjeremyhu at macports.orgDate2009-02-24 00:09:23 >> -0800 (Tue, 24 Feb 2009)Log Message >> xorg-libs: Force mesa, now that Tiger has HW rendering in our libGL >> Modified Paths >> ? trunk/dports/x11/xorg-libs/Portfile >> Diff >> Modified: trunk/dports/x11/xorg-libs/Portfile (47258 => 47259) >> --- trunk/dports/x11/xorg-libs/Portfile 2009-02-24 08:08:32 UTC >> (rev 47258) >> +++ trunk/dports/x11/xorg-libs/Portfile 2009-02-24 08:09:23 UTC >> (rev 47259) >> @@ -3,7 +3,7 @@ >> PortSystem 1.0 >> >> name xorg-libs >> -version 20090105 >> +version 20090224 >> categories x11 devel >> maintainers jeremyhu openmaintainer >> description X.org lib meta-package >> @@ -14,7 +14,7 @@ >> >> depends_lib \ >> port:Xft2 \ >> - lib:libGLU.1:mesa \ >> + port:mesa \ >> port:xorg-libAppleWM \ >> port:xorg-libFS \ >> port:xorg-libX11 \ > > This seems to have got in a catch 22 scenario ... > > iMac:~ mark$ sudo port selfupdate > > MacPorts base version 1.700 installed > Downloaded MacPorts base version 1.700 > > The MacPorts installation is not outdated so it was not updated > > iMac:~ mark$ sudo port outdated > The following installed ports are outdated: > xorg-libs 20090105_0 < 20090224_0 > iMac:~ mark$ sudo port upgrade outdated > ---> Activating mesa @7.2_5+hw_render > Error: Activating mesa @7.2_5 failed: Image error: /opt/local/ > include/GL/glxint.h is being used by the active xorg-glproto port. > Please deactivate this port first, or use the -f flag to force the > activation. > ---> Activating mesa @7.2_5+hw_render > Error: Target org.macports.activate returned: Image error: /opt/ > local/include/GL/glxint.h is being used by the active xorg-glproto > port. Please deactivate this port first, or use the -f flag to > force the activation. > Error: The following dependencies failed to build: mesa > Error: Unable to upgrade port: 1 > > iMac:~ mark$ sudo port deactivate xorg-glproto > ---> Deactivating xorg-glproto > > iMac:~ mark$ sudo port upgrade outdated > ---> Activating mesa @7.2_5+hw_render > ---> Activating xorg-glproto @1.4.9_0 > Error: Activating xorg-glproto @1.4.9_0 failed: Image error: /opt/ > local/include/GL/glxint.h is being used by the active mesa port. > Please deactivate this port first, or use the -f flag to force the > activation. > ---> Fetching xorg-libs > ---> Verifying checksum(s) for xorg-libs > ---> Extracting xorg-libs > ---> Configuring xorg-libs > ---> Building xorg-libs > ---> Staging xorg-libs into destroot > ---> Deactivating xorg-libs @20090105_0 > ---> Installing xorg-libs @20090224_0 > ---> Activating xorg-libs @20090224_0 > ---> Cleaning xorg-libs > > iMac:~ mark$ sudo port activate xorg-glproto > ---> Activating xorg-glproto > Error: port activate failed: Image error: /opt/local/include/GL/ > glxint.h is being used by the active mesa port. Please deactivate > this port first, or use the -f flag to force the activation. > > > > It looks like glxint.h is not preventing these xorg things working > together. > > Mark From febeling at macports.org Wed Feb 25 01:14:34 2009 From: febeling at macports.org (C. Florian Ebeling) Date: Wed, 25 Feb 2009 10:14:34 +0100 Subject: Unprivilged install regression? Message-ID: <5cbbe4ae0902250114h53dd49b5ma80032df39a0ca6d@mail.gmail.com> Using trunk, I have encountered what looks like a regression from the Unprivileged Install patch. When working with the couchdb portfile, I found that directories installed using xinstall -o user -g group NAME don't have the user ownership they should have anylonger. I haven't investigated properly, but but I thought I still give quick a headsup. The group is still the expected one, but user was root, which is the default one I reckon. -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From ryandesign at macports.org Wed Feb 25 15:17:48 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 25 Feb 2009 17:17:48 -0600 Subject: [47283] trunk/dports/lang/gnat-gcc/Portfile In-Reply-To: <49A59BAE.2070100@macports.org> References: <20090224194619.13A6510789A6@beta.macosforge.org> <122343D2-FDBF-43E5-8866-A382BB8D78D0@macports.org> <49A59BAE.2070100@macports.org> Message-ID: <46EC5066-5615-4633-A3BB-76EFA32758E3@macports.org> On Feb 25, 2009, at 13:27, Martin Krischik wrote: > Ryan Schmidt schrieb: > >> What is the difference between the ada and gnuada variants? > > sudo port install gnat-gcc +ada > > vs. > > sudo port dmg gnat-gcc +ada > > ;-) > >> It looks >> like the ada variant uses an ada compiler provided by MacPorts (if >> so, >> there should be a dependency on a MacPorts port in that variant), > > As with all self hosting compiler: They depend on them-self. You > use an > older version to create a new version. > >> and >> the gnuada variant uses an ada compiler provided by someone else in >> binary form which installs into /opt/local? > > Not someone else - by me. I created that version using "port dmg" as a > one way to break the recursive dependency. And how were you able to build the port in order to create the dmg? Did you have a compiler in /usr/local for this? >> If that's correct, then >> that's very disconcerting; we should not be encouraging users to >> install >> something that puts files into /opt/local without using MacPorts >> to do >> so. And the gnuada folks should not be distributing binaries that >> install things into the MacPorts /opt/local prefix. > > Well, as I said: I am the "gnuada folks". Note that already > consider to > use a different prefix for the "port dmg" installation but I am not > yet > sure which disadvantage that would bring. And any gcc related test > takes > several hours - even on my MacPro - even with setting --jobs to > make use > of the 8 cores. I would prefer if the port handled everything itself, like other ports do. I acknowledge that the need for a bootstrap compiler complicates things. But a port should not depend on a previous version of itself being installed. And a port should not use a previous version of itself if installed. A port should work the same on every user's system, regardless what ports they already have installed (modulo Mac OS X version and processor architecture). You could have the port download a compiler binary to use for bootstrapping (either the one you made, or the one that installs in / usr/local that you used to make yours.) Put that binary somewhere in the work directory and use it to build the real compiler. Possibly you would need to use DYLD_FALLBACK_LIBRARY_PATH to help it find its libraries in their unusual location in the work directory. You probably wouldn't need to update the version of the bootstrap compiler very often so it's just a one-time extra download for users, one which they would need to do manually anyway in your current setup. The incomplete port for minivmac 3 does something like this. minivmac is a Mac Plus emulator. As of version 3, minivmac's configure phase has been replaced by a program (called "Build") that needs to be run from within minivmac 3. (Brilliant!) So the port needs to download a binary of minivmac 3, and a disk image with "Build" on it, and a disk image with the operating system on it, and set up the disks to auto- run "Build" when the OS is booted (this is the part that's still incomplete). http://trac.macports.org/browser/users/ryandesign/minivmac/Portfile The port is very nasty but it does demonstrate the bootstrap compiler situation. Another (more traditional) example would be ghc. It has the unenviable problem of having to deal with four different bootstrap compilers -- one each for Tiger PPC, Tiger Intel, Leopard PPC and Leopard Intel. With minivmac fortunately I was able to use just a single universal version. From raimue at macports.org Wed Feb 25 20:38:15 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Thu, 26 Feb 2009 05:38:15 +0100 Subject: [29641] trunk/base/src/port1.0/porttrace.tcl In-Reply-To: <20071004124405.1010C836AE5@cvs.opensource.apple.com> References: <20071004124405.1010C836AE5@cvs.opensource.apple.com> Message-ID: <49A61CB7.2070106@macports.org> source_changes at macosforge.org wrote: > Revision: 29641 > http://trac.macosforge.org/projects/macports/changeset/29641 > Author: epimenov at macports.org > Date: 2007-10-04 05:44:04 -0700 (Thu, 04 Oct 2007) > > Log Message: > ----------- > Adding portpath, /etc/passwd and /etc/localtime into trace sandbox > > Modified Paths: > -------------- > trunk/base/src/port1.0/porttrace.tcl Hello Eugene and Paul, So I know this commit is very old. But I have a question which does not seem to be documented anywhere and I even searched the macports-dev archive from the time back then. As I was investigating our test suite I found the test "trace" which tries to create/delete/access/etc. files inside the $portpath and it expects failures due to trace mode being used. I wanted to adapt that to the current state of trunk, but then I found out that the $portpath is explicitely inside the sandbox. And I can't think of any reason why $portpath should be whitelisted. What was the motivation of adding $portpath to the sandbox here? Rainer From raimue at macports.org Thu Feb 26 02:15:08 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 26 Feb 2009 11:15:08 +0100 Subject: Webserver ports In-Reply-To: References: Message-ID: <49A66BAC.2080701@macports.org> Ryan Schmidt wrote: > I think our web server ports are a bit of a mess. We have apache, > apache2, apache20 and lighttpd, that I know of. They each have their > default htdocs and cgi-bin directories in different places: > > apache: ${prefix}/var/www/data/data (weird), ${prefix}/var/www/cgi-bin > apache +apache_layout: ${prefix}/apache/htdocs, ${prefix}/apache/cgi-bin > apache2: ${prefix}/apache2/htdocs, ${prefix}/apache2/cgi-bin > apache20: ${prefix}/apache20/htdocs, ${prefix}/apache20/cgi-bin > lighttpd: /srv/www/htdocs (very weird), no cgi-bin directory defined /srv is part of the Filesystem Hierarchy Standard. Some Linux distributions switched from /var/www to /srv/www. > [...] > We have several ports that install into either subdirectories of or > directly into ${prefix}/www, such as bugzilla, viewcvs, awstats, > gallery, htdig, mediawiki, phpbb, phpmyadmin, squirrelmail and > wordpress. > > I propose: > > * All web server ports should come with config files set to serve > files from the document root ${prefix}/www/htdocs and CGIs from $ > {prefix}/www/cgi-bin I would prefer ${prefix}/var/www being used. The path ${prefix}/www is just another violation of our mtree layout. Looking in porthier(7), it already contains ${prefix}/var/www and denotes it for files being served by a webserver. For compatibility to existing ports, we could add a small port (like compat-www-symlink) which just contains a symlink from ${prefix}/www to ${prefix}/var/www. The existing ports installing to ${prefix}/www would be changed to ${prefix}/var/www and declare dependency on compat-www-symlink. This way, existing configurations should not break. After some time compat-www-symlink can be removed after announcement on macports-users. > * There should be a meta port called "webserver" which has variants > for each of the four web servers mentioned above, defaulting to the > most popular, apache2 > * There should be a portgroup called "webapp" which sets up common > webapp tasks, like having no configure or build phases, depending on > port:webserver, and offering a variant "apple_webserver" to change > the install location from a MacPorts web server to the Apple one > (what do you think about this variant idea?) > * All web app ports can be changed to use the "webapp" portgroup and > can remove any variants they have for fiddling with install location > or web server dependencies Nice idea, I like this approach. > Also: > > * The "webserver" port can install a pretty MacPorts default > index.html page, like the default "It works!" page Apache provides, > but tailored to MacPorts That would only be a bonus ;-) Sorry for the late reply to this thread, the recent discussion on macports-users about the apache2 layout brought it back to my attention. Rainer From ryandesign at macports.org Thu Feb 26 02:22:25 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 26 Feb 2009 04:22:25 -0600 Subject: [47306] trunk/dports/aqua/qt4-mac/Portfile In-Reply-To: <20090225204008.5F8031092493@beta.macosforge.org> References: <20090225204008.5F8031092493@beta.macosforge.org> Message-ID: <5F9D0380-92C8-4D47-88FF-3CDC8A618356@macports.org> On Feb 25, 2009, at 14:40, raimue at macports.org wrote: > Revision: 47306 > http://trac.macports.org/changeset/47306 > Author: raimue at macports.org > Date: 2009-02-25 12:40:07 -0800 (Wed, 25 Feb 2009) > Log Message: > ----------- > aqua/qt4-mac: > Also allow mysql5-devel to satisfy the mysql5 dependency > > Modified Paths: > -------------- > trunk/dports/aqua/qt4-mac/Portfile > > Modified: trunk/dports/aqua/qt4-mac/Portfile > =================================================================== > --- trunk/dports/aqua/qt4-mac/Portfile 2009-02-25 18:52:30 UTC (rev > 47305) > +++ trunk/dports/aqua/qt4-mac/Portfile 2009-02-25 20:40:07 UTC (rev > 47306) > @@ -33,7 +33,7 @@ > port:jpeg \ > port:dbus \ > port:unixODBC \ > - port:mysql5 \ > + path:lib/mysql5:mysql5 \ I thought path:-style dependencies had to specify a file; ${prefix}/ lib/mysql5 is a directory. Do we know whether using a directory works? From ryandesign at macports.org Thu Feb 26 03:09:43 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 26 Feb 2009 05:09:43 -0600 Subject: Webserver ports In-Reply-To: <49A66BAC.2080701@macports.org> References: <49A66BAC.2080701@macports.org> Message-ID: <8576E0DD-719A-4616-AFAC-4518703908BB@macports.org> On Feb 26, 2009, at 04:15, Rainer M?ller wrote: > Ryan Schmidt wrote: >> I think our web server ports are a bit of a mess. We have apache, >> apache2, apache20 and lighttpd, that I know of. They each have their >> default htdocs and cgi-bin directories in different places: >> >> apache: ${prefix}/var/www/data/data (weird), ${prefix}/var/www/cgi- >> bin >> apache +apache_layout: ${prefix}/apache/htdocs, ${prefix}/apache/ >> cgi-bin >> apache2: ${prefix}/apache2/htdocs, ${prefix}/apache2/cgi-bin >> apache20: ${prefix}/apache20/htdocs, ${prefix}/apache20/cgi-bin >> lighttpd: /srv/www/htdocs (very weird), no cgi-bin directory defined > > /srv is part of the Filesystem Hierarchy Standard. Some Linux > distributions switched from /var/www to /srv/www. I meant it was weird in that /srv is not part of the MacPorts hierarchy. But I admit it's not like the port maintainer put that there; it's just what was in the upstream file. Quite a few changes need to be made to the default configuration lighttpd provides to match what MacPorts users expect. I believe there are some tickets on this already. >> [...] >> We have several ports that install into either subdirectories of or >> directly into ${prefix}/www, such as bugzilla, viewcvs, awstats, >> gallery, htdig, mediawiki, phpbb, phpmyadmin, squirrelmail and >> wordpress. >> >> I propose: >> >> * All web server ports should come with config files set to serve >> files from the document root ${prefix}/www/htdocs and CGIs from $ >> {prefix}/www/cgi-bin > > I would prefer ${prefix}/var/www being used. The path ${prefix}/www is > just another violation of our mtree layout. Looking in porthier(7), it > already contains ${prefix}/var/www and denotes it for files being > served > by a webserver. As far as I can see in porthier(7), it mentions ${prefix}/www and does not mention ${prefix}/var/www. From raimue at macports.org Thu Feb 26 03:46:27 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 26 Feb 2009 12:46:27 +0100 Subject: Webserver ports In-Reply-To: <8576E0DD-719A-4616-AFAC-4518703908BB@macports.org> References: <49A66BAC.2080701@macports.org> <8576E0DD-719A-4616-AFAC-4518703908BB@macports.org> Message-ID: <49A68113.1020406@macports.org> Ryan Schmidt wrote: > On Feb 26, 2009, at 04:15, Rainer M?ller wrote: >> Ryan Schmidt wrote: >>> * All web server ports should come with config files set to serve >>> files from the document root ${prefix}/www/htdocs and CGIs from $ >>> {prefix}/www/cgi-bin >> I would prefer ${prefix}/var/www being used. The path ${prefix}/www is >> just another violation of our mtree layout. Looking in porthier(7), it >> already contains ${prefix}/var/www and denotes it for files being >> served >> by a webserver. > > As far as I can see in porthier(7), it mentions ${prefix}/www and > does not mention ${prefix}/var/www. You are absolutely correct. I should get a bigger terminal, seems like I was misinterpreting the horizontal alignment... :-/ Excuse my mistake. So as our hierarchy guidelines already include ${prefix}/www we should most probably go with it. The usage of this path was unknown to me before, but I assume it was borrowed from FreeBSD. Sorry for the noise, but at least we talked about it in case someone else asks why we aren't using ${prefix}/var/www. Rainer From raimue at macports.org Thu Feb 26 04:06:47 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 26 Feb 2009 13:06:47 +0100 Subject: [47306] trunk/dports/aqua/qt4-mac/Portfile In-Reply-To: <5F9D0380-92C8-4D47-88FF-3CDC8A618356@macports.org> References: <20090225204008.5F8031092493@beta.macosforge.org> <5F9D0380-92C8-4D47-88FF-3CDC8A618356@macports.org> Message-ID: <49A685D7.6060402@macports.org> Ryan Schmidt wrote: >> Modified: trunk/dports/aqua/qt4-mac/Portfile >> =================================================================== >> --- trunk/dports/aqua/qt4-mac/Portfile 2009-02-25 18:52:30 UTC (rev >> 47305) >> +++ trunk/dports/aqua/qt4-mac/Portfile 2009-02-25 20:40:07 UTC (rev >> 47306) >> @@ -33,7 +33,7 @@ >> port:jpeg \ >> port:dbus \ >> port:unixODBC \ >> - port:mysql5 \ >> + path:lib/mysql5:mysql5 \ > > I thought path:-style dependencies had to specify a file; ${prefix}/ > lib/mysql5 is a directory. Do we know whether using a directory works? Yes, it works with directories: --- snip --- DEBUG: Searching for dependency: mysql5 DEBUG: Didn't find receipt, going to depspec regex for: mysql5 DEBUG: Found Dependency: path: /opt/local/lib filename: mysql5 regex: ^mysql5$ --- snap --- Rainer From ryandesign at macports.org Fri Feb 27 17:26:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 27 Feb 2009 19:26:40 -0600 Subject: [47216] trunk/dports/science/gwyddion/Portfile In-Reply-To: <25FAFAF9-0683-4D1A-8678-C6EE3E5D3FC8@gmail.com> References: <20090223182946.95460105C873@beta.macosforge.org> <867B8214-B767-4F1C-A147-B85A110A8086@macports.org> <2C396498-6E49-43A9-B81B-179EEDE62231@macports.org> <79A474DE-15BA-472F-91C0-DF88C4D61152@macports.org> <396F34A5-188A-4E98-8E9B-AEAE8EB32209@gmail.com> <25FAFAF9-0683-4D1A-8678-C6EE3E5D3FC8@gmail.com> Message-ID: <3D73CC61-2B0C-4508-98C8-51FBFE2EC663@macports.org> On Feb 27, 2009, at 18:44, Orville Bennett wrote: > On Feb 27, 2009, at 7:41 PM, Orville Bennett wrote: > >> On Feb 24, 2009, at 6:52 AM, Ryan Schmidt wrote: >> >>> Apple does not provide an automatic software update mechanism for >>> Xcode. You must update Xcode by logging in to ADC, downloading a >>> disk image, and installing the package from the disk image. >>> Accessing ADC requires a membership, but basic membership is free. >> >> but finding anything but the most recent version of xcode is hard. > > Well that was a mostly useless comment. Let's try again: > > but finding anything but the most recent version of xcode is hard. > How about adding a link to each version needed in the ui message? In another thread I mentioned the desire to make all MacPorts error messages short and sweet, and include a URL to a wiki page explaining the message further. So I would be against any change that makes the error messages themselves much longer or include URLs to Xcode downloads. We want users to use the most recent version of Xcode for their OS. Links to the latest version for Leopard, Tiger and Panther are in the Guide: http://guide.macports.org/#installing.xcode From illogical1 at gmail.com Sat Feb 28 06:07:34 2009 From: illogical1 at gmail.com (Orville Bennett) Date: Sat, 28 Feb 2009 09:07:34 -0500 Subject: [47216] trunk/dports/science/gwyddion/Portfile In-Reply-To: <3D73CC61-2B0C-4508-98C8-51FBFE2EC663@macports.org> References: <20090223182946.95460105C873@beta.macosforge.org> <867B8214-B767-4F1C-A147-B85A110A8086@macports.org> <2C396498-6E49-43A9-B81B-179EEDE62231@macports.org> <79A474DE-15BA-472F-91C0-DF88C4D61152@macports.org> <396F34A5-188A-4E98-8E9B-AEAE8EB32209@gmail.com> <25FAFAF9-0683-4D1A-8678-C6EE3E5D3FC8@gmail.com> <3D73CC61-2B0C-4508-98C8-51FBFE2EC663@macports.org> Message-ID: <9052CD31-34DD-4B6C-945B-C05A0F537E99@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 27, 2009, at 8:26 PM, Ryan Schmidt wrote: > On Feb 27, 2009, at 18:44, Orville Bennett wrote: > >> On Feb 27, 2009, at 7:41 PM, Orville Bennett wrote: >> >>> On Feb 24, 2009, at 6:52 AM, Ryan Schmidt wrote: >>> >>>> Apple does not provide an automatic software update mechanism for >>>> Xcode. You must update Xcode by logging in to ADC, downloading a >>>> disk image, and installing the package from the disk image. >>>> Accessing ADC requires a membership, but basic membership is free. >>> >>> but finding anything but the most recent version of xcode is hard. >> >> Well that was a mostly useless comment. Let's try again: >> >> but finding anything but the most recent version of xcode is hard. >> How about adding a link to each version needed in the ui message? > > In another thread I mentioned the desire to make all MacPorts error > messages short and sweet, and include a URL to a wiki page > explaining the message further. So I would be against any change > that makes the error messages themselves much longer or include URLs > to Xcode downloads. > > We want users to use the most recent version of Xcode for their OS. > Links to the latest version for Leopard, Tiger and Panther are in > the Guide: > > http://guide.macports.org/#installing.xcode That's absolutely fine as well. I'd just like there to be more information provided than "you need this" and then have the user hunt it down. If the error messages are too short then they become not so sweet :-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmpRSYACgkQ2yWVgjgEOKQ3LACfSHc1Xpz48ax1y/ClXtVIRGT9 5TkAoIJOJc+Vu7jn0Aj6J3UzocpFbkJL =rDnx -----END PGP SIGNATURE----- From blb at macports.org Sat Feb 28 13:16:26 2009 From: blb at macports.org (Bryan Blackburn) Date: Sat, 28 Feb 2009 14:16:26 -0700 Subject: [47503] trunk/dports/science/gdal/Portfile In-Reply-To: <20090228201740.5567710E9E27@beta.macosforge.org> References: <20090228201740.5567710E9E27@beta.macosforge.org> Message-ID: <20090228211626.GC885@ninagal.withay.com> On Sat, Feb 28, 2009 at 12:17:40PM -0800, jeremyhu at macports.org said: > Revision: 47503 > http://trac.macports.org/changeset/47503 > Author: jeremyhu at macports.org > Date: 2009-02-28 12:17:39 -0800 (Sat, 28 Feb 2009) > Log Message: > ----------- > gdal: Updated giflib dependence to be ok with libungif Why? libungif has been superceded by giflib upstream [1], so shouldn't we be preferring giflib in all cases now? Bryan [1] - > > Modified Paths: > -------------- > trunk/dports/science/gdal/Portfile > > Modified: trunk/dports/science/gdal/Portfile > =================================================================== > --- trunk/dports/science/gdal/Portfile 2009-02-28 20:17:10 UTC (rev 47502) > +++ trunk/dports/science/gdal/Portfile 2009-02-28 20:17:39 UTC (rev 47503) > @@ -22,7 +22,7 @@ > sha1 cae5a891231ee5794350d1626a688d802a429423 > > depends_lib port:zlib port:libpng port:tiff port:libgeotiff port:jpeg \ > - port:giflib port:proj > + path:include/gif_lib.h:giflib port:proj > > configure.args --with-local=${prefix} --with-libz=${prefix} \ > --with-png=${prefix} \ From markd at macports.org Sat Feb 28 13:17:52 2009 From: markd at macports.org (markd at macports.org) Date: Sat, 28 Feb 2009 13:17:52 -0800 Subject: [47462] trunk/dports/net/scotty/Portfile Message-ID: Hi Jeremy, I see that the 'lib:libX11.6:XFree86' dependency was removed a month ago in the Scotty port in favor of 'port:xorg-libs', and now the latter has been removed. I don't remember much about the Scotty port, but the latest change simply says xorg-libs is unneeded. Can you give some more explanation on the reasons for the two changes? Mark >Date: Sat, 28 Feb 2009 02:02:51 -0800 (PST) >From: jeremyhu at macports.org >Subject: [47462] trunk/dports/net/scotty/Portfile >To: macports-changes at lists.macosforge.org >Message-ID: <20090228100251.6375910E267A at beta.macosforge.org> >Content-Type: text/plain; charset="utf-8" > >Revision: 47462 > http://trac.macports.org/changeset/47462 >Author: jeremyhu at macports.org >Date: 2009-02-28 02:02:51 -0800 (Sat, 28 Feb 2009) >Log Message: >----------- >scotty: Remove unneded dependncy on xorg-libs > >Modified Paths: >-------------- > trunk/dports/net/scotty/Portfile > >Modified: trunk/dports/net/scotty/Portfile >=================================================================== >--- trunk/dports/net/scotty/Portfile 2009-02-28 10:01:05 UTC (rev >47461) >+++ trunk/dports/net/scotty/Portfile 2009-02-28 10:02:51 UTC (rev >47462) >@@ -24,8 +24,7 @@ > #svn.url >https://subversion.eecs.iu-bremen.de/svn/schoenw/src/scotty > #depends_build port:subversion > >-depends_lib port:xorg-libs \ >- port:tcl \ >+depends_lib port:tcl \ > port:tk > > patchfiles patch-Makefile.in \ >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: > > From jeremyhu at macports.org Sat Feb 28 13:29:29 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 28 Feb 2009 13:29:29 -0800 Subject: [47503] trunk/dports/science/gdal/Portfile In-Reply-To: <20090228211626.GC885@ninagal.withay.com> References: <20090228201740.5567710E9E27@beta.macosforge.org> <20090228211626.GC885@ninagal.withay.com> Message-ID: <6A295BF0-4A48-4E57-8045-109020F435C3@macports.org> On Feb 28, 2009, at 13:16, Bryan Blackburn wrote: > On Sat, Feb 28, 2009 at 12:17:40PM -0800, jeremyhu at macports.org said: >> Revision: 47503 >> http://trac.macports.org/changeset/47503 >> Author: jeremyhu at macports.org >> Date: 2009-02-28 12:17:39 -0800 (Sat, 28 Feb 2009) >> Log Message: >> ----------- >> gdal: Updated giflib dependence to be ok with libungif > > Why? libungif has been superceded by giflib upstream [1], so > shouldn't we > be preferring giflib in all cases now? Yeah, we're PREFERRING giflib. As long as libungif remains in the tree, we need to avoid the conflict. Hence: path:include/gif_lib.h:giflib If someone wants to nuke port:libungif (make it a stub that just pulls in giflib), I'll support that. --Jeremy From blb at macports.org Sat Feb 28 13:35:34 2009 From: blb at macports.org (Bryan Blackburn) Date: Sat, 28 Feb 2009 14:35:34 -0700 Subject: [47462] trunk/dports/net/scotty/Portfile In-Reply-To: References: Message-ID: <20090228213534.GD885@ninagal.withay.com> On Sat, Feb 28, 2009 at 01:17:52PM -0800, markd at macports.org said: > Hi Jeremy, > > I see that the 'lib:libX11.6:XFree86' dependency was removed a month ago > in the Scotty port in favor of 'port:xorg-libs', and now the latter has > been removed. I don't remember much about the Scotty port, but the latest > change simply says xorg-libs is unneeded. Can you give some more > explanation on the reasons for the two changes? It looks like scotty only links to tk, so it seems it doesn't need any specific X11 deps at all. However, at least here, it actually builds against the system tcl/tk and not MacPorts even though it claims dependencies on both: tnm.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl (compatibility version 8.4.0, current version 8.4.0) /System/Library/Frameworks/Tk.framework/Versions/8.4/Tk (compatibility version 8.4.0, current version 8.4.0) ... Bryan > > Mark > From macsforever2000 at macports.org Sat Feb 28 13:37:35 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Sat, 28 Feb 2009 14:37:35 -0700 Subject: [47503] trunk/dports/science/gdal/Portfile In-Reply-To: <6A295BF0-4A48-4E57-8045-109020F435C3@macports.org> References: <20090228201740.5567710E9E27@beta.macosforge.org> <20090228211626.GC885@ninagal.withay.com> <6A295BF0-4A48-4E57-8045-109020F435C3@macports.org> Message-ID: On Feb 28, 2009, at 2:29 PM, Jeremy Huddleston wrote: > > On Feb 28, 2009, at 13:16, Bryan Blackburn wrote: > >> On Sat, Feb 28, 2009 at 12:17:40PM -0800, jeremyhu at macports.org said: >>> Revision: 47503 >>> http://trac.macports.org/changeset/47503 >>> Author: jeremyhu at macports.org >>> Date: 2009-02-28 12:17:39 -0800 (Sat, 28 Feb 2009) >>> Log Message: >>> ----------- >>> gdal: Updated giflib dependence to be ok with libungif >> >> Why? libungif has been superceded by giflib upstream [1], so >> shouldn't we >> be preferring giflib in all cases now? > > Yeah, we're PREFERRING giflib. As long as libungif remains in the > tree, we need to avoid the conflict. > > Hence: path:include/gif_lib.h:giflib > > If someone wants to nuke port:libungif (make it a stub that just > pulls in giflib), I'll support that. There's a ticket [1] on this subject. There's still a few ports left that depend on libungif that need to be switched. I couldn't get at least one of them to compile when I switched the dependency though. [1] Cheers! Frank From jeremyhu at macports.org Sat Feb 28 14:27:29 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 28 Feb 2009 14:27:29 -0800 Subject: [47462] trunk/dports/net/scotty/Portfile In-Reply-To: References: Message-ID: <398FBDDF-E570-41C4-9259-93961D828CFC@macports.org> It doesn't actually use X11. It draws using wish. On Feb 28, 2009, at 13:17, markd at macports.org wrote: > Hi Jeremy, > > I see that the 'lib:libX11.6:XFree86' dependency was removed a month > ago > in the Scotty port in favor of 'port:xorg-libs', and now the latter > has > been removed. I don't remember much about the Scotty port, but the > latest > change simply says xorg-libs is unneeded. Can you give some more > explanation on the reasons for the two changes? > > Mark > >> Date: Sat, 28 Feb 2009 02:02:51 -0800 (PST) >> From: jeremyhu at macports.org >> Subject: [47462] trunk/dports/net/scotty/Portfile >> To: macports-changes at lists.macosforge.org >> Message-ID: <20090228100251.6375910E267A at beta.macosforge.org> >> Content-Type: text/plain; charset="utf-8" >> >> Revision: 47462 >> http://trac.macports.org/changeset/47462 >> Author: jeremyhu at macports.org >> Date: 2009-02-28 02:02:51 -0800 (Sat, 28 Feb 2009) >> Log Message: >> ----------- >> scotty: Remove unneded dependncy on xorg-libs >> >> Modified Paths: >> -------------- >> trunk/dports/net/scotty/Portfile >> >> Modified: trunk/dports/net/scotty/Portfile >> =================================================================== >> --- trunk/dports/net/scotty/Portfile 2009-02-28 10:01:05 UTC (rev >> 47461) >> +++ trunk/dports/net/scotty/Portfile 2009-02-28 10:02:51 UTC (rev >> 47462) >> @@ -24,8 +24,7 @@ >> #svn.url >> https://subversion.eecs.iu-bremen.de/svn/schoenw/src/scotty >> #depends_build port:subversion >> >> -depends_lib port:xorg-libs \ >> - port:tcl \ >> +depends_lib port:tcl \ >> port:tk >> >> patchfiles patch-Makefile.in \ >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> > > >> > From jeremyhu at macports.org Sat Feb 28 14:28:22 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 28 Feb 2009 14:28:22 -0800 Subject: [47503] trunk/dports/science/gdal/Portfile In-Reply-To: References: <20090228201740.5567710E9E27@beta.macosforge.org> <20090228211626.GC885@ninagal.withay.com> <6A295BF0-4A48-4E57-8045-109020F435C3@macports.org> Message-ID: <89BDFF9B-A47B-4B59-A1D7-F567BBD62F3D@macports.org> Ok, I'll take a look at that ticket once I finish working through the xorg-libs stragglers... On Feb 28, 2009, at 13:37, Frank Schima wrote: > > On Feb 28, 2009, at 2:29 PM, Jeremy Huddleston wrote: > >> >> On Feb 28, 2009, at 13:16, Bryan Blackburn wrote: >> >>> On Sat, Feb 28, 2009 at 12:17:40PM -0800, jeremyhu at macports.org >>> said: >>>> Revision: 47503 >>>> http://trac.macports.org/changeset/47503 >>>> Author: jeremyhu at macports.org >>>> Date: 2009-02-28 12:17:39 -0800 (Sat, 28 Feb 2009) >>>> Log Message: >>>> ----------- >>>> gdal: Updated giflib dependence to be ok with libungif >>> >>> Why? libungif has been superceded by giflib upstream [1], so >>> shouldn't we >>> be preferring giflib in all cases now? >> >> Yeah, we're PREFERRING giflib. As long as libungif remains in the >> tree, we need to avoid the conflict. >> >> Hence: path:include/gif_lib.h:giflib >> >> If someone wants to nuke port:libungif (make it a stub that just >> pulls in giflib), I'll support that. > > There's a ticket [1] on this subject. There's still a few ports left > that depend on libungif that need to be switched. I couldn't get at > least one of them to compile when I switched the dependency though. > > > [1] > > > Cheers! > Frank > From jeremyhu at macports.org Sat Feb 28 15:00:07 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 28 Feb 2009 15:00:07 -0800 Subject: xorg-libs as a dependency Message-ID: xorg-libs is a metaport for all the X11 libs. All the old XFree86 dependencies were changed to a port:xorg-libs dependency simultaneously about 1-2 months ago. Nothing should really depend on xorg-libs directly. ports should depend on the specific libs they actually need. To that end, I've gone through the tree and updated most ports that were using xorg-libs to instead depend on the specific libs necessary. These two have xorg-libs dependencies, but I can't see why: swi-prolog swi-prolog-devel The following ports are still unchanged because they failed to compile: arts basiliskii blt elvis mit-scheme oleo pgplot pnetlib tkman vice vtk vtk5 wap11gui xaos xli xrmap These two are unchanged because I've been working on ppc. I'll fix them when I get back to using an intel box. kinput2-macim mono If you use any of the above ports, I suggest you fix them on your own. They require a nontrivial amount of work to fix, so I gave up or didn't bother. --Jeremy From ryandesign at macports.org Sat Feb 28 17:03:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 28 Feb 2009 19:03:03 -0600 Subject: [47516] trunk/dports/aqua/osx2x/Portfile In-Reply-To: <20090228213155.AEB0810EA85C@beta.macosforge.org> References: <20090228213155.AEB0810EA85C@beta.macosforge.org> Message-ID: <591A1399-FD56-4382-834D-8DCDA6DE8435@macports.org> On Feb 28, 2009, at 15:31, jeremyhu at macports.org wrote: > Revision: 47516 > http://trac.macports.org/changeset/47516 > Author: jeremyhu at macports.org > Date: 2009-02-28 13:31:54 -0800 (Sat, 28 Feb 2009) > Log Message: > ----------- > osx2x: Link against MacPorts X11 libs. Update X11 dependencies. > Update checksums since dist tarball updated upstream > > Modified Paths: > -------------- > trunk/dports/aqua/osx2x/Portfile > > Modified: trunk/dports/aqua/osx2x/Portfile > =================================================================== > --- trunk/dports/aqua/osx2x/Portfile 2009-02-28 21:29:56 UTC (rev > 47515) > +++ trunk/dports/aqua/osx2x/Portfile 2009-02-28 21:31:54 UTC (rev > 47516) > @@ -6,7 +6,7 @@ > > name osx2x > version 2.4.0 > -revision 1 > +revision 2 > set git_hash 3cc708236898ab789bb99a5fba7420ff76ede9f7 > platforms darwin > maintainers nomaintainer > @@ -27,20 +27,23 @@ > > worksrcdir mdales-${name}-${git_hash} > > -checksums \ > - md5 897cf872c4006d4173b3c6ff046b0c44 \ > - sha1 1014e0ac22b0c00b47dde2b0f7f44eaa676acc7e \ > - rmd160 cc2a63b9dbfd9485c039fc989bbab96e6cf919ac > +checksums md5 fd13fd638a380d29b55eec07e930aa85 \ > + sha1 > 764c74f298374f05f7fba6e5d35d98636e754bf6 \ > + rmd160 7add82e2ac2d0c5fd6258ce77d6297502c395370 If you change a port's checksums for an upstream "stealth upgrade" you must change the dist_subdir otherwise users who had already downloaded the old file or who get it from one of our distfiles mirrors will now get a checksum mismatch. In this case, the file with the original checksums is still available here: http://arn.se.distfiles.macports.org/osx2x/osx2x-2.4.tar.gz However the real problem seems to be that osx2x uses github for downloads, which I imagine is generating the tarball on the fly as it's requested, hence it's always different. The checksum I got when I fetched now was different from the one you updated the portfile to. The tarball is always the same, but the gzip format must use entropy so its output is different every time for the same input data. github seems to cache the tar.gz for awhile, but after that it'll toss it and make a new one if it's requested again. I think this means we simply cannot use github in master_sites in any port. I changed the port in r47558 to use the old checksums again and download from the arn.se distfiles mirror. By doing this, the California and trd.no mirrors should also pick up that file. The only other port using github in master_sites is webarchiver. I'll fix that in a moment. From ryandesign at macports.org Sat Feb 28 17:21:45 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 28 Feb 2009 19:21:45 -0600 Subject: [47561] trunk/dports/net/ns-2/Portfile In-Reply-To: <20090301010201.C88FC10F1E54@beta.macosforge.org> References: <20090301010201.C88FC10F1E54@beta.macosforge.org> Message-ID: <5744C59F-146C-4760-A2EA-EE0C505C734E@macports.org> On Feb 28, 2009, at 19:02, jeremyhu at macports.org wrote: > Revision: 47561 > http://trac.macports.org/changeset/47561 > Author: jeremyhu at macports.org > Date: 2009-02-28 17:02:01 -0800 (Sat, 28 Feb 2009) > Log Message: > ----------- > ns-2: Cleanup X11 linking... I could not compile this package due > to some tcl issues... so I can't verify it... hopefully someone > fill fix the tcl issues, and I'll verify it. Yes, ns-2 is in a sorry state. http://trac.macports.org/ticket/13535 From ryandesign at macports.org Sat Feb 28 17:23:54 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 28 Feb 2009 19:23:54 -0600 Subject: [47409] trunk/dports/gnome/gnome-desktop/Portfile In-Reply-To: <20090228014701.2849810DBABA@beta.macosforge.org> References: <20090228014701.2849810DBABA@beta.macosforge.org> Message-ID: <387B89DF-7F32-46A8-ACF4-2FA35B054D83@macports.org> On Feb 27, 2009, at 19:47, jeremyhu at macports.org wrote: > Revision: 47409 > http://trac.macports.org/changeset/47409 > Author: jeremyhu at macports.org > Date: 2009-02-27 17:47:00 -0800 (Fri, 27 Feb 2009) > Log Message: > ----------- > gnome-desktop: Nuke unneeded dependency on xorg-libs > > Modified Paths: > -------------- > trunk/dports/gnome/gnome-desktop/Portfile > > Modified: trunk/dports/gnome/gnome-desktop/Portfile > =================================================================== > --- trunk/dports/gnome/gnome-desktop/Portfile 2009-02-28 01:43:41 > UTC (rev 47408) > +++ trunk/dports/gnome/gnome-desktop/Portfile 2009-02-28 01:47:00 > UTC (rev 47409) > @@ -94,7 +94,7 @@ > } > > variant x11 conflicts quartz description {Enable rendering in X11 > (default)} { > - depends_lib-append port:xorg-libs > + # GTK pulls in our dependencies > } Does this mean the x11 variant can be deleted? It doesn't seem to do anything anymore. This port is particularly confusing in that it also has a no_x11 variant -- which also does nothing. From jeremyhu at macports.org Sat Feb 28 17:43:41 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 28 Feb 2009 17:43:41 -0800 Subject: [47409] trunk/dports/gnome/gnome-desktop/Portfile In-Reply-To: <387B89DF-7F32-46A8-ACF4-2FA35B054D83@macports.org> References: <20090228014701.2849810DBABA@beta.macosforge.org> <387B89DF-7F32-46A8-ACF4-2FA35B054D83@macports.org> Message-ID: <3117C04C-5DA4-46B7-B6C2-131076A93D38@macports.org> On Feb 28, 2009, at 17:23, Ryan Schmidt wrote: > On Feb 27, 2009, at 19:47, jeremyhu at macports.org wrote: >> variant x11 conflicts quartz description {Enable rendering in X11 >> (default)} { >> - depends_lib-append port:xorg-libs >> + # GTK pulls in our dependencies >> } > > Does this mean the x11 variant can be deleted? It doesn't seem to do > anything anymore. > > This port is particularly confusing in that it also has a no_x11 > variant -- which also does nothing. I was trying to figure out what all that was about. I think I cleaned it up in r47577, but I still don't like how "no_x11" and "quartz" are essentially the same...