From ryandesign at macports.org Fri Jan 1 17:55:10 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 1 Jan 2010 19:55:10 -0600 Subject: [62252] trunk/dports/science In-Reply-To: <20100101231727.834CE3A18556@beta.macosforge.org> References: <20100101231727.834CE3A18556@beta.macosforge.org> Message-ID: <0BF37D73-F5B3-4E9F-893E-746D1C5EAEDD@macports.org> On Jan 1, 2010, at 17:17, adfernandes at macports.org wrote: > Revision: 62252 > http://trac.macports.org/changeset/62252 > Author: adfernandes at macports.org > Date: 2010-01-01 15:17:23 -0800 (Fri, 01 Jan 2010) > Log Message: > ----------- > Closes #23088 - building for 64-bit SL and adds openmpi variant as per #21922 > +platform darwin 10 { > + configure.args-append --enable-apple-64bit > +} This is not a good way to address this problem. What about 32-bit builds on Snow Leopard -- for 32-bit CPUs, or for people selecting i386 build_arch in macports.conf? What about 64-bit builds on Leopard? What about the OS that comes after Snow Leopard? Instead, you should inspect the configure.build_arch variable and enable 64-bit if the build_arch requests it. Note this is only good for non-universal builds. For universal builds, you need to instead inspect configure.universal_archs. Actually, you probably want to use the muniversal portgroup so that you can pass --enable-apple-64bit to the 64-bit builds and not pass it to the 32-bit builds. There are some example ports that do this kind of thing. From jeremy at lavergne.gotdns.org Fri Jan 1 20:31:05 2010 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 1 Jan 2010 23:31:05 -0500 Subject: [62252] trunk/dports/science In-Reply-To: <0BF37D73-F5B3-4E9F-893E-746D1C5EAEDD@macports.org> References: <20100101231727.834CE3A18556@beta.macosforge.org> <0BF37D73-F5B3-4E9F-893E-746D1C5EAEDD@macports.org> Message-ID: <666F2E26-5C27-4896-A64B-47833C1C3CA7@lavergne.gotdns.org> > This is not a good way to address this problem. What about 32-bit builds on Snow Leopard -- for 32-bit CPUs, or for people selecting i386 build_arch in macports.conf? What about 64-bit builds on Leopard? What about the OS that comes after Snow Leopard? Instead, you should inspect the configure.build_arch variable and enable 64-bit if the build_arch requests it. Note this is only good for non-universal builds. For universal builds, you need to instead inspect configure.universal_archs. Actually, you probably want to use the muniversal portgroup so that you can pass --enable-apple-64bit to the 64-bit builds and not pass it to the 32-bit builds. There are some example ports that do this kind of thing. Try some sort of it not universal and if not configure.build_arch ppc/386 ... then do 64-bit else fail build. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jmr at macports.org Fri Jan 1 22:24:20 2010 From: jmr at macports.org (Joshua Root) Date: Sat, 02 Jan 2010 17:24:20 +1100 Subject: MacPorts 1.8.2 has been released Message-ID: <4B3EE694.10209@macports.org> The MacPorts Project is pleased to announce the release of version 1.8.2. This is a bugfix release with small changes only. See the ChangeLog [1] for the list of changes. If you already have MacPorts installed, the preferred method for updating is to run: sudo port selfupdate For new installs, there are also package installers in disk images available for 10.4, 10.5, and 10.6 (all universal builds, the first two i386/ppc and the latter i386/x86_64) at [2]. The source is also available as tarballs compressed with gzip or bzip2, or from the subversion tag [3]. Detached PGP signatures for the disk images and source tarballs have been made with my key, which is available on the keyservers and my MacPorts wiki page [4], the fingerprint being: 0xB70C8867DCDBFF26: B6D0 0D4B 209D 03FF 2BCE B77F B70C 8867 DCDB FF26 Josh (on behalf of the MacPorts Port Managers) [1] [2] [3] [4] From jkh at apple.com Sat Jan 2 00:35:01 2010 From: jkh at apple.com (Jordan K. Hubbard) Date: Sat, 2 Jan 2010 00:35:01 -0800 Subject: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?] In-Reply-To: <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> Message-ID: <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> On Jun 6, 2009, at 3:21 PM, C. Florian Ebeling wrote: > I have secretly been working on a build server I call Portmill, which polls the svn, and builds every > port that changes. Results get posted to a web app which presents them, together with build logs (tails) for the ones that fail How's this coming along? I just thought I'd raise the topic again now that we're in a new decade. :-) - Jordan From ryandesign at macports.org Sun Jan 3 01:41:24 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 3 Jan 2010 03:41:24 -0600 Subject: php5 extensions' versions In-Reply-To: <88B94086-B2D0-4496-821B-DAEF9BA2FA58@macports.org> References: <88B94086-B2D0-4496-821B-DAEF9BA2FA58@macports.org> Message-ID: <8C2D0729-54CD-4E8F-9F87-D158F4B22F74@macports.org> On Dec 27, 2009, at 17:08, Ryan Schmidt wrote: > On Dec 27, 2009, at 17:00, nox wrote: > >> Is there a particular reason as for why php5-zip (and possibly other extensions) follows php5 versioning even though >> they have their own versioning through PECL [1]? >> >> Regards. >> >> [1] http://pecl.php.net/package/zip > > Exclusively because I was not aware the zip extension existed in PECL. > > For other extensions that I have found in PECL, they were older versions than the ones available in the PHP source; I understood that the versions in PECL were no longer being maintained, and that the latest version was available in the PHP source. > > If that's not the case for zip and other extensions, they can be changed to use the source from PECL. Please file tickets if that's the case. I'm just confused as to why the developers of PHP still bundle it with the PHP source, if newer versions are available elsewhere. Upon further investigation, it seems that the PECL version of the zip extension is recommended for use with PHP 4: http://us.php.net/manual/en/zip.installation.php For PHP 5.3, the version in the PHP source archive should be fine. I've compared the source of the zip extension in the php-5.3.1 and zip-1.10.2 archives and they're similar, but slightly different. It's hard to tell, but I believe the version in the PHP source is newer than the one in the standalone extension source, so I don't believe a change is needed in the php5-zip port at this time. Of course if you have information to the contrary please let me know. From florian.ebeling at gmail.com Sun Jan 3 03:45:04 2010 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Sun, 3 Jan 2010 12:45:04 +0100 Subject: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?] In-Reply-To: <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> Message-ID: <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> Hi Jordan, >> I have secretly been working on a build server I call Portmill, which polls the svn, and builds every >> port that changes. Results get posted to a web app which presents them, together with build logs (tails) for the ones that fail > > How's this coming along? ?I just thought I'd raise the topic again now that we're in a new decade. :-) thanks for showing interest in it. I have to admit, though, that this little project is very far away for me right now. My life changed over completely, I spare you the details here, but I'm more interested in other projects nowadays. I think I should be honest about this. If somebody wanted to work on Portmill I offer my help with getting started, and answer questions possibly coming up. It is all still on my github account, but I haven't touched it in the last half a year. Sorry to give this probably disappointing answer. Florian -- Florian Ebeling florian.ebeling at gmail.com From nox at macports.org Sun Jan 3 04:38:23 2010 From: nox at macports.org (nox) Date: Sun, 3 Jan 2010 13:38:23 +0100 Subject: php5 extensions' versions In-Reply-To: <8C2D0729-54CD-4E8F-9F87-D158F4B22F74@macports.org> References: <88B94086-B2D0-4496-821B-DAEF9BA2FA58@macports.org> <8C2D0729-54CD-4E8F-9F87-D158F4B22F74@macports.org> Message-ID: <65EC0864-6377-4AC1-803C-9B3EB49F3E97@macports.org> Le 3 janv. 2010 ? 10:41, Ryan Schmidt a ?crit : > > On Dec 27, 2009, at 17:08, Ryan Schmidt wrote: > >> On Dec 27, 2009, at 17:00, nox wrote: >> >>> Is there a particular reason as for why php5-zip (and possibly other extensions) follows php5 versioning even though >>> they have their own versioning through PECL [1]? >>> >>> Regards. >>> >>> [1] http://pecl.php.net/package/zip >> >> Exclusively because I was not aware the zip extension existed in PECL. >> >> For other extensions that I have found in PECL, they were older versions than the ones available in the PHP source; I understood that the versions in PECL were no longer being maintained, and that the latest version was available in the PHP source. >> >> If that's not the case for zip and other extensions, they can be changed to use the source from PECL. Please file tickets if that's the case. I'm just confused as to why the developers of PHP still bundle it with the PHP source, if newer versions are available elsewhere. > > Upon further investigation, it seems that the PECL version of the zip extension is recommended for use with PHP 4: > > http://us.php.net/manual/en/zip.installation.php > > For PHP 5.3, the version in the PHP source archive should be fine. > > I've compared the source of the zip extension in the php-5.3.1 and zip-1.10.2 archives and they're similar, but slightly different. It's hard to tell, but I believe the version in the PHP source is newer than the one in the standalone extension source, so I don't believe a change is needed in the php5-zip port at this time. Of course if you have information to the contrary please let me know. > You're totally right, it seems there are some memory leaks fixed in src/ext/ which are not in pecl/. From ryandesign at macports.org Sun Jan 3 05:02:27 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 3 Jan 2010 07:02:27 -0600 Subject: [62294] trunk/dports/databases/mysql5/files/patch-mysql_secure_installation .sh.diff In-Reply-To: <20100103124800.3D9DE3A2B178@beta.macosforge.org> References: <20100103124800.3D9DE3A2B178@beta.macosforge.org> Message-ID: On Jan 3, 2010, at 06:47, nox at macports.org wrote: > Revision: 62294 > http://trac.macports.org/changeset/62294 > Author: nox at macports.org > Date: 2010-01-03 04:47:59 -0800 (Sun, 03 Jan 2010) > Log Message: > ----------- > Fix mysql5 patch which was not updated for 5.1.42 Thanks -- that's the problem when you do "svn ci $(port file mysql5)"... Gotta remember to do "svn ci $(port dir mysql5)" instead. From jkh at apple.com Sun Jan 3 23:57:55 2010 From: jkh at apple.com (Jordan K. Hubbard) Date: Sun, 3 Jan 2010 23:57:55 -0800 Subject: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?] In-Reply-To: <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> Message-ID: <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> On Jan 3, 2010, at 3:45 AM, C. Florian Ebeling wrote: > If somebody wanted to work on Portmill I offer my help with getting > started, and answer questions possibly coming up. It is all still on > my github account, but I haven't touched it in the last half a year. > Sorry to give this probably disappointing answer. Florian, Hey, that's life - things change! Thanks for being honest about it, in any case, since I think that leaves the door open for any volunteer(s) who still want to see package building / regression testing sometime in the future. Anyone out there interested? The Mayans supposedly predicted that the world is going to end in 2012, so there isn't a lot of time left... ;-) Thanks, - Jordan From afb at macports.org Mon Jan 4 01:00:54 2010 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 4 Jan 2010 10:00:54 +0100 Subject: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?] In-Reply-To: <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> Message-ID: Jordan K. Hubbard wrote: > Hey, that's life - things change! Thanks for being honest about > it, in any case, since I think that leaves the door open for any > volunteer(s) who still want to see package building / regression > testing sometime in the future. Anyone out there interested? How does it make it from the destroot building, to the supposed "package" (whatever that means here) ? Regression testing and build logs are nice either way, but rather far from MacPorts providing binary packages. I'm assuming that this is only about the archives, since there's no apparent interest in including a package manager (such as rpm, or even installer) with MacPorts. Didn't hear anything on "xpkg"* either... * xpkg is a simplistic xar/xml archive, instead of the xar versions of .rpm (rpm5) or .pkg (flat) packages "port archive" can make those with a portarchivetype of xpkg (included since a year ago, in MacPorts 1.8.0) > The Mayans supposedly predicted that the world is going to end in > 2012, so there isn't a lot of time left... ;-) I thought that was the Emmerichs ? But there's still Y2K38... --anders From jim at geekdaily.org Tue Jan 5 09:45:09 2010 From: jim at geekdaily.org (Jim Meyer) Date: Tue, 05 Jan 2010 09:45:09 -0800 Subject: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?] In-Reply-To: <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> Message-ID: <4B437AA5.7000408@geekdaily.org> On 1/3/10 11:57 PM, Jordan K. Hubbard wrote: > > On Jan 3, 2010, at 3:45 AM, C. Florian Ebeling wrote: > >> If somebody wanted to work on Portmill I offer my help with getting >> started, and answer questions possibly coming up. It is all still on >> my github account, but I haven't touched it in the last half a year. >> Sorry to give this probably disappointing answer. > > Florian, > > Hey, that's life - things change! Thanks for being honest about it, in any case, since I think that leaves the door open for any volunteer(s) who still want to see package building / regression testing sometime in the future. Anyone out there interested? The Mayans supposedly predicted that the world is going to end in 2012, so there isn't a lot of time left... ;-) I've looked at this a couple of times. Unfortunately, I wasn't able to get CouchDB and the will_paginate gem to play nice (which Florian was obviously able to do =) and have never had time to chase that down fully. I keep thinking "this must be really simple" which prevents me from flipping it back to ActiveRecord and making it go. Florian, if you've a thought on this, please chime in. Otherwise, I'm likely to just put AR back in place in the name of keeping this moving. --j From ryandesign at macports.org Tue Jan 5 15:17:09 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 5 Jan 2010 17:17:09 -0600 Subject: [62370] trunk/dports/java/glassfishv3/Portfile In-Reply-To: <20100105154638.543313A658C6@beta.macosforge.org> References: <20100105154638.543313A658C6@beta.macosforge.org> Message-ID: <02603352-2E8A-4B28-8CD4-1E2CD0F5A0F9@macports.org> On Jan 5, 2010, at 09:46, krischik at macports.org wrote: > Revision: 62370 > http://trac.macports.org/changeset/62370 > Author: krischik at macports.org > Date: 2010-01-05 07:46:34 -0800 (Tue, 05 Jan 2010) > Log Message: > ----------- > Final release. > > Modified Paths: > -------------- > trunk/dports/java/glassfishv3/Portfile > > Modified: trunk/dports/java/glassfishv3/Portfile > =================================================================== > --- trunk/dports/java/glassfishv3/Portfile 2010-01-05 12:54:32 UTC (rev 62369) > +++ trunk/dports/java/glassfishv3/Portfile 2010-01-05 15:46:34 UTC (rev 62370) > @@ -6,8 +6,7 @@ > > name glassfishv3 > version 3 > -epoch 62 > -revision 2 > +revision 3 You can't ever remove the epoch line from a portfile because "port outdated" would then not report the port as being outdated. I put it back in r62382, and put it before the version line, to indicate that it has a higher precedence. From florian.ebeling at gmail.com Tue Jan 5 15:38:57 2010 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Wed, 6 Jan 2010 00:38:57 +0100 Subject: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?] In-Reply-To: <4B437AA5.7000408@geekdaily.org> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> <4B437AA5.7000408@geekdaily.org> Message-ID: <5cbbe4ae1001051538p3245c205tdc564c52ee6fd686@mail.gmail.com> > I've looked at this a couple of times. Unfortunately, I wasn't able to get > CouchDB and the will_paginate gem to play nice (which Florian was obviously > able to do =) and have never had time to chase that down fully. I keep > thinking "this must be really simple" which prevents me from flipping it > back to ActiveRecord and making it go. > > Florian, if you've a thought on this, please chime in. Otherwise, I'm likely > to just put AR back in place in the name of keeping this moving. When I implemented this, couch_potato was moving quite quickly, and I used a patched version myself. And I didn't keep on rebasing and integrating changes from the github master since, so it is quite likely that there happened some bit rot. My main reason for using CouchDB was that I wanted to spice up the project by using a technology that thrilled me. If you are immediately productive with a straightforward AR solution you should probably switch over and focus on the actual features you want. William Siegrist who looks after the other MP systems was pushing into the direction of MySQL anyway, so that might just make things easier for everyone. I wont be offended if you switch :) Quite to the contrary, I'm happy if this project lives on. Florian -- Florian Ebeling florian.ebeling at gmail.com From jmr at macports.org Tue Jan 5 15:52:45 2010 From: jmr at macports.org (Joshua Root) Date: Wed, 06 Jan 2010 10:52:45 +1100 Subject: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?] In-Reply-To: <5cbbe4ae1001051538p3245c205tdc564c52ee6fd686@mail.gmail.com> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> <4B437AA5.7000408@geekdaily.org> <5cbbe4ae1001051538p3245c205tdc564c52ee6fd686@mail.gmail.com> Message-ID: <4B43D0CD.4060800@macports.org> On 2010-1-6 10:38 , C. Florian Ebeling wrote: > William Siegrist who looks after the other MP systems was > pushing into the direction of MySQL anyway I don't remember it that way. He was against adding Yet Another DBMS to the server without a good reason. MySQL was simply mentioned as what currently runs ports.php, and I don't recall anyone saying that ditching it wouldn't be possible. Portmill and (the hypothetical future) MPWA should probably use the same back end. If there was to be a Grand Unified DB, it would most likely be Postgres since that's what runs Trac (and I understand that isn't likely to change). - Josh From florian.ebeling at gmail.com Tue Jan 5 16:14:40 2010 From: florian.ebeling at gmail.com (Caspar Florian Ebeling) Date: Wed, 6 Jan 2010 01:14:40 +0100 Subject: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?] In-Reply-To: <4B43D0CD.4060800@macports.org> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> <4B437AA5.7000408@geekdaily.org> <5cbbe4ae1001051538p3245c205tdc564c52ee6fd686@mail.gmail.com> <4B43D0CD.4060800@macports.org> Message-ID: Yes, I think you're right. Using an AR data persistence model that shouldn't make a big difference, though. Florian On 06.01.2010, at 00:52, Joshua Root wrote: > On 2010-1-6 10:38 , C. Florian Ebeling wrote: >> William Siegrist who looks after the other MP systems was >> pushing into the direction of MySQL anyway > > I don't remember it that way. He was against adding Yet Another DBMS > to > the server without a good reason. MySQL was simply mentioned as what > currently runs ports.php, and I don't recall anyone saying that > ditching > it wouldn't be possible. Portmill and (the hypothetical future) MPWA > should probably use the same back end. > > If there was to be a Grand Unified DB, it would most likely be > Postgres > since that's what runs Trac (and I understand that isn't likely to > change). > > - Josh From ryandesign at macports.org Tue Jan 5 16:14:54 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 5 Jan 2010 18:14:54 -0600 Subject: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?] In-Reply-To: <4B43D0CD.4060800@macports.org> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> <4B437AA5.7000408@geekdaily.org> <5cbbe4ae1001051538p3245c205tdc564c52ee6fd686@mail.gmail.com> <4B43D0CD.4060800@macports.org> Message-ID: <47667C95-0D00-45DA-A1A2-C1D79F93B727@macports.org> On Jan 5, 2010, at 17:52, Joshua Root wrote: > On 2010-1-6 10:38 , C. Florian Ebeling wrote: >> William Siegrist who looks after the other MP systems was >> pushing into the direction of MySQL anyway > > I don't remember it that way. He was against adding Yet Another DBMS to > the server without a good reason. MySQL was simply mentioned as what > currently runs ports.php, and I don't recall anyone saying that ditching > it wouldn't be possible. Portmill and (the hypothetical future) MPWA > should probably use the same back end. He may have been remembering my comments instead of William's. I did recommend using MySQL instead of CouchDB, if only because I have used MySQL for years, and know nothing about CouchDB other than its name. http://lists.macosforge.org/pipermail/macports-dev/2009-June/008939.html From wsiegrist at apple.com Tue Jan 5 16:40:12 2010 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 5 Jan 2010 16:40:12 -0800 Subject: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?] In-Reply-To: <4B43D0CD.4060800@macports.org> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> <4B437AA5.7000408@geekdaily.org> <5cbbe4ae1001051538p3245c205tdc564c52ee6fd686@mail.gmail.com> <4B43D0CD.4060800@macports.org> Message-ID: <6E0C9A9D-E9E2-4CA0-BF94-111BABDAD578@apple.com> On Jan 5, 2010, at 3:52 PM, Joshua Root wrote: > On 2010-1-6 10:38 , C. Florian Ebeling wrote: >> William Siegrist who looks after the other MP systems was >> pushing into the direction of MySQL anyway > > I don't remember it that way. He was against adding Yet Another DBMS to > the server without a good reason. MySQL was simply mentioned as what > currently runs ports.php, and I don't recall anyone saying that ditching > it wouldn't be possible. Portmill and (the hypothetical future) MPWA > should probably use the same back end. > > If there was to be a Grand Unified DB, it would most likely be Postgres > since that's what runs Trac (and I understand that isn't likely to change). > If you want this system to eventually run alongside the rest of the macports.org infrastructure, you should stick to standard SQL. It would end up being served by postgres most likely. We're moving away from MySQL. -Bill From ryandesign at macports.org Tue Jan 5 16:47:50 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 5 Jan 2010 18:47:50 -0600 Subject: Moving away from MySQL (2010 the year for package builds?) In-Reply-To: <6E0C9A9D-E9E2-4CA0-BF94-111BABDAD578@apple.com> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> <4B437AA5.7000408@geekdaily.org> <5cbbe4ae1001051538p3245c205tdc564c52ee6fd686@mail.gmail.com> <4B43D0CD.4060800@macports.org> <6E0C9A9D-E9E2-4CA0-BF94-111BABDAD578@apple.com> Message-ID: <9FEBD59E-4EA9-410A-847C-9A98E5A37BD6@macports.org> On Jan 5, 2010, at 18:40, William Siegrist wrote: > It would end up being served by postgres most likely. We're moving away from MySQL. Why, out of curiosity? I know there are pros and cons to any database, but I'm curious what your current objections to MySQL are; maybe I should be moving away from it for my own projects too. From wsiegrist at apple.com Tue Jan 5 17:02:54 2010 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 5 Jan 2010 17:02:54 -0800 Subject: Moving away from MySQL (2010 the year for package builds?) In-Reply-To: <9FEBD59E-4EA9-410A-847C-9A98E5A37BD6@macports.org> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> <4B437AA5.7000408@geekdaily.org> <5cbbe4ae1001051538p3245c205tdc564c52ee6fd686@mail.gmail.com> <4B43D0CD.4060800@macports.org> <6E0C9A9D-E9E2-4CA0-BF94-111BABDAD578@apple.com> <9FEBD59E-4EA9-410A-847C-9A98E5A37BD6@macports.org> Message-ID: On Jan 5, 2010, at 4:47 PM, Ryan Schmidt wrote: > > On Jan 5, 2010, at 18:40, William Siegrist wrote: > >> It would end up being served by postgres most likely. We're moving away from MySQL. > > Why, out of curiosity? I know there are pros and cons to any database, but I'm curious what your current objections to MySQL are; maybe I should be moving away from it for my own projects too. > We had a mysql db lose a bunch of data a while back, and we'd rather not run >1 DBMS anyway, so we picked postgres. -Bill From evan.mcclain at gatech.edu Tue Jan 5 17:56:19 2010 From: evan.mcclain at gatech.edu (Evan McClain) Date: Tue, 5 Jan 2010 20:56:19 -0500 Subject: mutt-devel +gpgme (#22009) Message-ID: <20100106015619.GA17530@Evan-McClains-MacBook.local> I have been using the patch attached to #22009 (https://trac.macports.org/ticket/22009) with no issues for about a week. I'm not too familiar with macports development, but I wanted to ping this list to see if there is anything else needed to actually get the patch committed. Thanks. -- Evan McClain Aerospace Engineering Graduate Student Senator . evan.mcclain at gatech.edu ..: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 268 bytes Desc: not available URL: From toby at macports.org Tue Jan 5 19:46:42 2010 From: toby at macports.org (Toby Peterson) Date: Tue, 5 Jan 2010 19:46:42 -0800 Subject: mutt-devel +gpgme (#22009) In-Reply-To: <20100106015619.GA17530@Evan-McClains-MacBook.local> References: <20100106015619.GA17530@Evan-McClains-MacBook.local> Message-ID: <8D5137ED-1C0F-41B8-8BE3-F6CD0EAB19F6@macports.org> Committed r62386... shouldn't you be watching football? - Toby On Jan 5, 2010, at 5:56 PM, Evan McClain wrote: > I have been using the patch attached to #22009 > (https://trac.macports.org/ticket/22009) with no issues for about a > week. > > I'm not too familiar with macports development, but I wanted to ping > this list to see if there is anything else needed to actually get the > patch committed. > > Thanks. > -- > Evan McClain > Aerospace Engineering > Graduate Student Senator . > evan.mcclain at gatech.edu ..: > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From evan.mcclain at gatech.edu Tue Jan 5 19:49:59 2010 From: evan.mcclain at gatech.edu (Evan McClain) Date: Tue, 5 Jan 2010 22:49:59 -0500 Subject: mutt-devel +gpgme (#22009) In-Reply-To: <8D5137ED-1C0F-41B8-8BE3-F6CD0EAB19F6@macports.org> References: <20100106015619.GA17530@Evan-McClains-MacBook.local> <8D5137ED-1C0F-41B8-8BE3-F6CD0EAB19F6@macports.org> Message-ID: <20100106034959.GA85860@aeroevan.local> On Tue, Jan 05, 2010 at 07:46:42PM -0800, Toby Peterson wrote: > Committed r62386... shouldn't you be watching football? Thanks. And don't worry, I am :) -- Evan McClain Aerospace Engineering Graduate Student Senator . evan.mcclain at gatech.edu ..: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 268 bytes Desc: not available URL: From stefan.van.der.eijk at gmail.com Wed Jan 6 02:55:54 2010 From: stefan.van.der.eijk at gmail.com (Stefan van der Eijk) Date: Wed, 6 Jan 2010 11:55:54 +0100 Subject: Fwd: [MacPorts] #22950: asterisk-1.6.1.12 In-Reply-To: <074.14fdec1cfc8e38fdca0a30294f91dd7e@macports.org> References: <065.51a9ffdbbe35c26553bcb422f305b302@macports.org> <074.14fdec1cfc8e38fdca0a30294f91dd7e@macports.org> Message-ID: <47cd6f1d1001060255r241b78ceq1f87abf02d046de2@mail.gmail.com> Please commit the updates. The maintainer hasn't responded in 72 hours. ---------- Forwarded message ---------- From: MacPorts Date: Sat, Dec 19, 2009 at 21:09 Subject: Re: [MacPorts] #22950: asterisk-1.6.1.12 To: stefan.van.der.eijk at gmail.com, marc.blanchet at viagente.ca Cc: macports-tickets at lists.macosforge.org, mr_bond at macports.org #22950: asterisk-1.6.1.12 -------------------------------------------+-------------------------------- Reporter: stefan.van.der.eijk@? | Owner: marc.blanchet@? Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: haspatch | Port: asterisk -------------------------------------------+-------------------------------- Changes (by macsforever2000@?): * cc: mr_bond@? (added) * keywords: => haspatch * version: 1.8.1 => * owner: macports-tickets@? => marc.blanchet@? -- Ticket URL: MacPorts Ports system for Mac OS -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at geekdaily.org Wed Jan 6 07:49:28 2010 From: jim at geekdaily.org (Jim Meyer) Date: Wed, 06 Jan 2010 07:49:28 -0800 Subject: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?] In-Reply-To: <6E0C9A9D-E9E2-4CA0-BF94-111BABDAD578@apple.com> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> <4B437AA5.7000408@geekdaily.org> <5cbbe4ae1001051538p3245c205tdc564c52ee6fd686@mail.gmail.com> <4B43D0CD.4060800@macports.org> <6E0C9A9D-E9E2-4CA0-BF94-111BABDAD578@apple.com> Message-ID: <4B44B108.4020009@geekdaily.org> I've converted my fork of portmill to being a postgres app: http://github.com/purp/portmill All specs pass, coverage is still 100% (not hard for a trivial app =). Bill, I'd need to work with you to tweak the database and deployment host info. Florian, do you have a separate process that's injecting the build results into the system? --j From nox at macports.org Wed Jan 6 08:06:14 2010 From: nox at macports.org (nox) Date: Wed, 6 Jan 2010 17:06:14 +0100 Subject: Warning: Line X seems to hardcode the version number, consider using ${version} instead Message-ID: <41AFCCF9-AF82-4C8B-8872-1D4441546C09@macports.org> Hi, Is there anyone strongly against the idea of moving this warning to the nitpicking ones? Every lint report I've received with this warning so far has been a false positive (e.g. docbook-xml-5.0). Regards. From ryandesign at macports.org Wed Jan 6 08:59:11 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 6 Jan 2010 10:59:11 -0600 Subject: Warning: Line X seems to hardcode the version number, consider using ${version} instead In-Reply-To: <41AFCCF9-AF82-4C8B-8872-1D4441546C09@macports.org> References: <41AFCCF9-AF82-4C8B-8872-1D4441546C09@macports.org> Message-ID: <3A02A2FA-252D-4106-804D-088C220FF7B9@macports.org> On Jan 6, 2010, at 10:06, nox wrote: > Is there anyone strongly against the idea of moving this warning to the nitpicking ones? Every lint report I've received with this warning so far has been a false positive (e.g. docbook-xml-5.0). I don't know. I do agree it could stand to be refined somewhat. In the case of docbook-xml-5.0, it complains that the version (5.0) is part of the "name" line; we could grant an exclusion for that line. And in the case of graphviz-oldgui, the version is an integer (16) which appears in several unrelated places in the portfile (as part of a checksum, and of "rmd160", and of "UTF-16"); here I was thinking of skipping the check unless version isn't an integer. I don't think it needs to be our goal that every port passes every lint test; some of the things it says are just suggestions. But I agree it's annoying to repeatedly receive the same lint reports by email for things one has decided not to fix. From wsiegrist at apple.com Wed Jan 6 09:00:04 2010 From: wsiegrist at apple.com (William Siegrist) Date: Wed, 6 Jan 2010 09:00:04 -0800 Subject: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?] In-Reply-To: <4B44B108.4020009@geekdaily.org> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> <4B437AA5.7000408@geekdaily.org> <5cbbe4ae1001051538p3245c205tdc564c52ee6fd686@mail.gmail.com> <4B43D0CD.4060800@macports.org> <6E0C9A9D-E9E2-4CA0-BF94-111BABDAD578@apple.com> <4B44B108.4020009@geekdaily.org> Message-ID: On Jan 6, 2010, at 7:49 AM, Jim Meyer wrote: > I've converted my fork of portmill to being a postgres app: > > http://github.com/purp/portmill > > All specs pass, coverage is still 100% (not hard for a trivial app =). > > Bill, I'd need to work with you to tweak the database and deployment host info. Florian, do you have a separate process that's injecting the build results into the system? > I think the next step is coming up with a Passenger portfile. Does anyone have one handy? -Bill From talklists at newgeo.com Wed Jan 6 10:33:12 2010 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 6 Jan 2010 10:33:12 -0800 Subject: mysql5 server and plain Message-ID: I posted a little MAMP tutorial the other day. While I think it is valuable to the end user, I also think it is not going to be received well by MP in general, as they are going to want to follow a stricter set of steps than the direction I went in. I took a lot of liberties just to get it all working. I want to start in a different way, which would be to write new data for each respective port, which in the end, could be chained together to provide a user with the steps needed to get MAMP up and running. So I will start with MySql, which in my opinion, is one of the harder ones to get running on MacPorts. This is because MacPorts sort of stops at the install part. It does a fine job at that. However, there are ui messages that ask the user to do things that either do not work, are pointing to files I can not find, or in general, cause confusion. Before I outline those issues, I wanted to bring up the very first thing I was thinking. Why is there a mysql plain and mysql server version? This seems to come up often enough that it is worth discussion. The only difference I see is the startup item, is that correct? If that is the case, I do not see any reason why the port is not just "mysql5". It would install the launchd or startup item, and be in a disabled state. The user gets mysql, if they want to turn it into a server, they can run one command to do so. This could be a ui message. I do not think that having one extra small file on the system is a huge deal, for removing a good deal of confusion. How many times has someone posted that they just installed mysql, to learn they need to go back and install mysql5-server? Is this a way off base suggestion? It seems so much simpler, just merge the two ports into one, if a user wants it to be a server, run the single command to enable the startup of it. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Wed Jan 6 11:27:42 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 6 Jan 2010 13:27:42 -0600 Subject: mysql5 server and plain In-Reply-To: References: Message-ID: On Jan 6, 2010, at 12:33, Scott Haneda wrote: > I posted a little MAMP tutorial the other day. While I think it is valuable to the end user, I also think it is not going to be received well by MP in general, as they are going to want to follow a stricter set of steps than the direction I went in. I took a lot of liberties just to get it all working. > > I want to start in a different way, which would be to write new data for each respective port, which in the end, could be chained together to provide a user with the steps needed to get MAMP up and running. > > So I will start with MySql, which in my opinion, is one of the harder ones to get running on MacPorts. This is because MacPorts sort of stops at the install part. It does a fine job at that. However, there are ui messages that ask the user to do things that either do not work, are pointing to files I can not find, or in general, cause confusion. If there are wrong or incomplete ui_msgs please file tickets so I can fix them. > Before I outline those issues, I wanted to bring up the very first thing I was thinking. > > Why is there a mysql plain and mysql server version? > This seems to come up often enough that it is worth discussion. > > The only difference I see is the startup item, is that correct? If that is the case, I do not see any reason why the port is not just "mysql5". It would install the launchd or startup item, and be in a disabled state. > > The user gets mysql, if they want to turn it into a server, they can run one command to do so. This could be a ui message. I do not think that having one extra small file on the system is a huge deal, for removing a good deal of confusion. How many times has someone posted that they just installed mysql, to learn they need to go back and install mysql5-server? > > Is this a way off base suggestion? It seems so much simpler, just merge the two ports into one, if a user wants it to be a server, run the single command to enable the startup of it. mysql5 installs the client and server software. mysql5-server installs the launchd plist and the directories a server would need. This mirrors the postgresql ports. There used to just be a mysql5 port with a +server variant, but this was awful because when installed as a dependency, or by someone who didn't yet understand variants, the port would be installed without the server launchd plist, and to get it, the user would have to recompile all of mysql5, which wasted a lot of time. *This* came up all the time for years and was worth discussion and resulted in what we have now. You might think just having a mysql5 port and making it always install the launchd plist would be better. But remember that it's not just the launchd plist: it's also the directories, which need to be owned by the mysql user. The user might be installing in a non-root prefix, might only need the client portion, and would not have permission to install the launchd plist nor to set the ownership of directories to a system user. Such a user could work around the launchd plist issue by setting startupitem_type to none in macports.conf, but the port would still have to know not to install the directories. Can a port query the startupitem type the user requested? If so, the port could do so and omit installing the server directories if ${startupitem.type} is none. In the end, however, you must admit this reduces transparency: Before, it was clear if you installed "mysql5 +server" you got a server, if you installed "mysql5" you didn't. Currently, if you install "mysql5-server" you get a server, if you just install "mysql5" you don't. But if we change the port to infer things based on the startupitem type, and you look at "port installed" and see "mysql5", you don't know whether it has server parts or not. I suppose (and I apologize, I'm thinking this through as I'm typing) the startupitem.type-based detection could lead to the port auto-selecting (or not) (using default_variants) the +server variant. Hmm..... You know, that might work. If we're thinking of removing mysql5-server, we should have similar thoughts about the postgresql and other ports that do this, and also about removing the +no_startupitem variant from ports like apache2, since a user who wants to install a purely server software like apache without a launchd plist is a) strange and apparently running with diminished privileges, and therefore b) must logically want the same for all other ports as well, and c) can achieve this in macports.conf. From ryandesign at macports.org Wed Jan 6 11:48:47 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 6 Jan 2010 13:48:47 -0600 Subject: [62404] trunk/dports/games/fife/Portfile In-Reply-To: <20100106194341.2226A3AB9280@beta.macosforge.org> References: <20100106194341.2226A3AB9280@beta.macosforge.org> Message-ID: <40803E7D-0726-4818-AFCF-7736CBABD0C0@macports.org> On Jan 6, 2010, at 13:43, tommyd at macports.org wrote: > Revision: 62404 > http://trac.macports.org/changeset/62404 > Author: tommyd at macports.org > Date: 2010-01-06 11:43:38 -0800 (Wed, 06 Jan 2010) > Log Message: > ----------- > * new prelimninary svn version uploaded which fixes a couple of issues The distfile has changed but its filename is still the same? That's a bad idea. That's what we call a "stealth upgrade". If you can change the filename to something new, please do. If the same filename is necessary, though, then you must change the dist_subdir from its default ${name} to something else, preferably still beginning ${name} and including the version and revision, such as dist_subdir ${name}/${version}_${revision} This way, a user who had already downloaded the previous distfile with the previous checksums will not now encounter a checksum error when trying to upgrade. > Modified Paths: > -------------- > trunk/dports/games/fife/Portfile > > Modified: trunk/dports/games/fife/Portfile > =================================================================== > --- trunk/dports/games/fife/Portfile 2010-01-06 18:54:26 UTC (rev 62403) > +++ trunk/dports/games/fife/Portfile 2010-01-06 19:43:38 UTC (rev 62404) > @@ -4,6 +4,7 @@ > > name fife > version 0.2.999 > +revision 1 > maintainers tommyd > categories games python > platforms darwin > @@ -16,9 +17,9 @@ > master_sites http://thomaskeller.biz/stuff > use_bzip2 yes > > -checksums md5 28e772860b3bff9f41dd07e5415f6d1e \ > - sha1 88afd8578079651f98f0d3c63a7fc8892c83b645 \ > - rmd160 6e796b97805b92803bb15034c3db0cc9d3cf1b36 > +checksums md5 9704aa6d1bdc21d3be810035c9156c93 \ > + sha1 854a6e3e6cbada6dd60e038f7b67781a50944f58 \ > + rmd160 f828f8e43440375ba93a758e1b51f13488e39b90 > > depends_build port:scons From nox at macports.org Wed Jan 6 12:01:12 2010 From: nox at macports.org (nox) Date: Wed, 6 Jan 2010 21:01:12 +0100 Subject: Warning: Line X seems to hardcode the version number, consider using ${version} instead In-Reply-To: <3A02A2FA-252D-4106-804D-088C220FF7B9@macports.org> References: <41AFCCF9-AF82-4C8B-8872-1D4441546C09@macports.org> <3A02A2FA-252D-4106-804D-088C220FF7B9@macports.org> Message-ID: <90E8BC04-FD27-4C11-885D-F00AE3D8C35B@macports.org> On a side note, we should really have a procedure which escapes characters bearing special meaning in regard to regular expressions. Le 6 janv. 2010 ? 17:59, Ryan Schmidt a ?crit : > On Jan 6, 2010, at 10:06, nox wrote: > >> Is there anyone strongly against the idea of moving this warning to the nitpicking ones? Every lint report I've received with this warning so far has been a false positive (e.g. docbook-xml-5.0). > > I don't know. I do agree it could stand to be refined somewhat. In the case of docbook-xml-5.0, it complains that the version (5.0) is part of the "name" line; we could grant an exclusion for that line. And in the case of graphviz-oldgui, the version is an integer (16) which appears in several unrelated places in the portfile (as part of a checksum, and of "rmd160", and of "UTF-16"); here I was thinking of skipping the check unless version isn't an integer. > > I don't think it needs to be our goal that every port passes every lint test; some of the things it says are just suggestions. But I agree it's annoying to repeatedly receive the same lint reports by email for things one has decided not to fix. > > From ryandesign at macports.org Wed Jan 6 12:14:16 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 6 Jan 2010 14:14:16 -0600 Subject: Warning: Line X seems to hardcode the version number, consider using ${version} instead In-Reply-To: <90E8BC04-FD27-4C11-885D-F00AE3D8C35B@macports.org> References: <41AFCCF9-AF82-4C8B-8872-1D4441546C09@macports.org> <3A02A2FA-252D-4106-804D-088C220FF7B9@macports.org> <90E8BC04-FD27-4C11-885D-F00AE3D8C35B@macports.org> Message-ID: <7BEC068F-36C2-4A6F-A0FA-057F981F2ECE@macports.org> On Jan 6, 2010, at 14:01, nox wrote: > On a side note, we should really have a procedure which escapes characters bearing special meaning in regard to regular expressions. http://trac.macports.org/changeset/34667/trunk/base/src/port1.0/portutil.tcl From florian.ebeling at gmail.com Wed Jan 6 12:28:14 2010 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Wed, 6 Jan 2010 21:28:14 +0100 Subject: 2010 the year for package builds? [was Re: Is it time to start regression testing yet?] In-Reply-To: <4B44B108.4020009@geekdaily.org> References: <5BF3CAD7-092F-4E57-A921-AE9600513C15@apple.com> <5cbbe4ae0906061521v1c5da68bie46e91890e5460c7@mail.gmail.com> <2F9EADB8-EF60-4B47-AA09-93294EB0597E@apple.com> <5cbbe4ae1001030345y79c539d9t3e1cbb7dfb027cce@mail.gmail.com> <89D28382-ECB6-4406-87A2-4A522B4E41FB@apple.com> <4B437AA5.7000408@geekdaily.org> <5cbbe4ae1001051538p3245c205tdc564c52ee6fd686@mail.gmail.com> <4B43D0CD.4060800@macports.org> <6E0C9A9D-E9E2-4CA0-BF94-111BABDAD578@apple.com> <4B44B108.4020009@geekdaily.org> Message-ID: <5cbbe4ae1001061228h8c7d4axef4155d4c8620a79@mail.gmail.com> > Bill, I'd need to work with you to tweak the database and deployment host > info. Florian, do you have a separate process that's injecting the build > results into the system? Yes, of course :) That part is the mpbuildserver package, which in turn depends on mpab (MacPorts Autobuild). http://github.com/febeling/mpbuildserver http://svn.macports.org/repository/macports/contrib/mpab (web: http://trac.macports.org/browser/contrib/mpab) The Rails app can run somewhere centrally, and the mpbuildserver (which could be named buildclient, buildbox or buildslave more aptly, but that's another discussion) runs on a Mac OS X machine dedicated to building the packages. mpbuildserver polls the svn repo and checks out of changes are found. Those get copied into the mpab chroot and the build is initiated. Once done, the logs and some metadata get send to the portmill API for storing. Quite straightforward. mpab is Bryan Blackburns work, with only a few small changes by me to make the build server task easier or faster. It creates a chroot environment and runs port commands inside that, so that the host system does not get compromised if builds go awry. Florian -- Florian Ebeling florian.ebeling at gmail.com From nox at macports.org Wed Jan 6 13:39:05 2010 From: nox at macports.org (nox) Date: Wed, 6 Jan 2010 22:39:05 +0100 Subject: Warning: Line X seems to hardcode the version number, consider using ${version} instead In-Reply-To: <7BEC068F-36C2-4A6F-A0FA-057F981F2ECE@macports.org> References: <41AFCCF9-AF82-4C8B-8872-1D4441546C09@macports.org> <3A02A2FA-252D-4106-804D-088C220FF7B9@macports.org> <90E8BC04-FD27-4C11-885D-F00AE3D8C35B@macports.org> <7BEC068F-36C2-4A6F-A0FA-057F981F2ECE@macports.org> Message-ID: Oh, I didn't know about that. Thanks for telling me. Back on the topic, I just got a fugly idea, we could create a special command, which would just executes its arguments, and uses its name an unconditional exception for whatever warning triggered on the same line. Something like: stop_with_that_crap_lint name docbook-xml-5.0 Le 6 janv. 2010 ? 21:14, Ryan Schmidt a ?crit : > > On Jan 6, 2010, at 14:01, nox wrote: > >> On a side note, we should really have a procedure which escapes characters bearing special meaning in regard to regular expressions. > > http://trac.macports.org/changeset/34667/trunk/base/src/port1.0/portutil.tcl > From plulli at gmail.com Wed Jan 6 15:29:39 2010 From: plulli at gmail.com (paolo lulli) Date: Thu, 7 Jan 2010 00:29:39 +0100 Subject: [MacPorts-Dev] About email subjects Message-ID: <7bfb8c411001061529n6adace80od0e876346b4f55c4@mail.gmail.com> Hi there, I think it could be a great thing if the mailing list could be setup to prefix subject of the email with something like this one: [MacPorts-Dev] Eitherwise it is nearly impossible to distinguish between list messages and personal ones. I think it something easily accomplishable. Regards, Paolo From evan.mcclain at gatech.edu Wed Jan 6 15:38:38 2010 From: evan.mcclain at gatech.edu (Evan McClain) Date: Wed, 6 Jan 2010 18:38:38 -0500 Subject: [MacPorts-Dev] About email subjects In-Reply-To: <7bfb8c411001061529n6adace80od0e876346b4f55c4@mail.gmail.com> References: <7bfb8c411001061529n6adace80od0e876346b4f55c4@mail.gmail.com> Message-ID: <20100106233838.GA94805@lawn-128-61-118-138.lawn.gatech.edu> On Thu, Jan 07, 2010 at 12:29:39AM +0100, paolo lulli wrote: > Hi there, > > I think it could be a great thing if the mailing list could be setup > to prefix subject of the email with something like this one: > > [MacPorts-Dev] > > Eitherwise it is nearly impossible to distinguish between list > messages and personal ones. > I think it something easily accomplishable. There is already a List-Id message header which can be used for filtering and identifying which list the email is from, but some email clients don't really let you see email headers or know how to deal with mailing lists. I guess that's why I'm still using mutt :P -- Evan McClain Aerospace Engineering Graduate Student Senator . evan.mcclain at gatech.edu ..: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 268 bytes Desc: not available URL: From jim at geekdaily.org Wed Jan 6 15:46:27 2010 From: jim at geekdaily.org (Jim Meyer) Date: Wed, 06 Jan 2010 15:46:27 -0800 Subject: [MacPorts-Dev] About email subjects In-Reply-To: <20100106233838.GA94805@lawn-128-61-118-138.lawn.gatech.edu> References: <7bfb8c411001061529n6adace80od0e876346b4f55c4@mail.gmail.com> <20100106233838.GA94805@lawn-128-61-118-138.lawn.gatech.edu> Message-ID: <4B4520D3.4070906@geekdaily.org> On 1/6/10 3:38 PM, Evan McClain wrote: > On Thu, Jan 07, 2010 at 12:29:39AM +0100, paolo lulli wrote: >> Hi there, >> >> I think it could be a great thing if the mailing list could be setup >> to prefix subject of the email with something like this one: >> >> [MacPorts-Dev] >> >> Eitherwise it is nearly impossible to distinguish between list >> messages and personal ones. >> I think it something easily accomplishable. I used to be a subject tag fan, but I'd much rather use that real estate for real subject line these days. I don't object to short ones (< 5 chars), but more than that is kinda painful, IMhO. > There is already a List-Id message header which can be used for > filtering and identifying which list the email is from, but some email > clients don't really let you see email headers or know how to deal with > mailing lists. I guess that's why I'm still using mutt :P Actually, almost all of them do, and many now let you set up mailing list filters or add custom headers to filter on. It doesn't yet pass my Mother-in-Law test*, but it should be within reach of anyone on this mailing list (again, IMhO). --j From nox at macports.org Wed Jan 6 15:48:35 2010 From: nox at macports.org (nox) Date: Thu, 7 Jan 2010 00:48:35 +0100 Subject: [MacPorts-Dev] About email subjects In-Reply-To: <4B4520D3.4070906@geekdaily.org> References: <7bfb8c411001061529n6adace80od0e876346b4f55c4@mail.gmail.com> <20100106233838.GA94805@lawn-128-61-118-138.lawn.gatech.edu> <4B4520D3.4070906@geekdaily.org> Message-ID: Now you've done it. You must tell us what that asterisk mean :D Le 7 janv. 2010 ? 00:46, Jim Meyer a ?crit : > On 1/6/10 3:38 PM, Evan McClain wrote: >> On Thu, Jan 07, 2010 at 12:29:39AM +0100, paolo lulli wrote: >>> Hi there, >>> >>> I think it could be a great thing if the mailing list could be setup >>> to prefix subject of the email with something like this one: >>> >>> [MacPorts-Dev] >>> >>> Eitherwise it is nearly impossible to distinguish between list >>> messages and personal ones. >>> I think it something easily accomplishable. > > I used to be a subject tag fan, but I'd much rather use that real estate for real subject line these days. I don't object to short ones (< 5 chars), but more than that is kinda painful, IMhO. > >> There is already a List-Id message header which can be used for >> filtering and identifying which list the email is from, but some email >> clients don't really let you see email headers or know how to deal with >> mailing lists. I guess that's why I'm still using mutt :P > > Actually, almost all of them do, and many now let you set up mailing list filters or add custom headers to filter on. It doesn't yet pass my Mother-in-Law test*, but it should be within reach of anyone on this mailing list (again, IMhO). > > --j > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From bforte at adelaide.on.net Wed Jan 6 15:49:42 2010 From: bforte at adelaide.on.net (Brian Forte) Date: Thu, 7 Jan 2010 09:49:42 +1000 Subject: [MacPorts-Dev] About email subjects In-Reply-To: <7bfb8c411001061529n6adace80od0e876346b4f55c4@mail.gmail.com> References: <7bfb8c411001061529n6adace80od0e876346b4f55c4@mail.gmail.com> Message-ID: Paolo, >I think it could be a great thing if the mailing list could be setup >to prefix subject of the email with something like this one: > >[MacPorts-Dev] > >Eitherwise it is nearly impossible to distinguish between list >messages and personal ones. Look in the headers of any message from the list. You'll find a bunch of 'List-*' headers including List-Id as follows: List-Id: MacPorts Project developers list Most modern mailing lists populate these headers with list-specific information and most modern e-mail clients can filter on any header, so you can use the contents of List-Id to filter mailing list traffic out from e-mail sent directly to you. FWIW, I prefer List-Id fields to adding a string to the Subject field for the same reason as I prefer Type codes or UTIs to file-name extensions. Overloading a single field with multiple information types is the very definition of bad database design. Hope this helps. Regards, Brian Forte. -- words, edits, type, layout, code From nox at macports.org Wed Jan 6 16:01:54 2010 From: nox at macports.org (nox) Date: Thu, 7 Jan 2010 01:01:54 +0100 Subject: Warning: Line X seems to hardcode the version number, consider using ${version} instead In-Reply-To: References: <41AFCCF9-AF82-4C8B-8872-1D4441546C09@macports.org> <3A02A2FA-252D-4106-804D-088C220FF7B9@macports.org> <90E8BC04-FD27-4C11-885D-F00AE3D8C35B@macports.org> <7BEC068F-36C2-4A6F-A0FA-057F981F2ECE@macports.org> Message-ID: <710897AA-09CF-4476-B227-B1650539C2CC@macports.org> Another one false positive is caused by the checksums from the verbose output of portchecksum when there is multiple distfiles (e.g. in zsh-devel). Le 6 janv. 2010 ? 22:39, nox a ?crit : > Oh, I didn't know about that. Thanks for telling me. > > Back on the topic, I just got a fugly idea, we could create a special command, which would just executes its arguments, and uses its name an unconditional exception for whatever warning triggered on the same line. > > Something like: > > stop_with_that_crap_lint name docbook-xml-5.0 > > Le 6 janv. 2010 ? 21:14, Ryan Schmidt a ?crit : > >> >> On Jan 6, 2010, at 14:01, nox wrote: >> >>> On a side note, we should really have a procedure which escapes characters bearing special meaning in regard to regular expressions. >> >> http://trac.macports.org/changeset/34667/trunk/base/src/port1.0/portutil.tcl >> > From jim at geekdaily.org Wed Jan 6 16:04:37 2010 From: jim at geekdaily.org (Jim Meyer) Date: Wed, 06 Jan 2010 16:04:37 -0800 Subject: [MacPorts-Dev] About email subjects In-Reply-To: References: <7bfb8c411001061529n6adace80od0e876346b4f55c4@mail.gmail.com> <20100106233838.GA94805@lawn-128-61-118-138.lawn.gatech.edu> <4B4520D3.4070906@geekdaily.org> Message-ID: <4B452515.5090905@geekdaily.org> On 1/6/10 3:48 PM, nox wrote: > Now you've done it. You must tell us what that asterisk mean :D My 68-year-old mother-in-law, Molly, loves to communicate and share; accordingly, she loves the internet and technology, though it frequently baffles her. For example, she's managed to lock up our Logitech remote more than once and couldn't explain how she got there. The Mother-in-Law Test is simple: if Molly can figure out or easily learn to use it, it passes. Bonus points if she can explain how something broke for her. Windows was massive FAIL. We bought her a Mac laptop to travel with and cut our phone support time by an order of magnitude. Total WIN. I use this as a design rule all the time. =] --j > Le 7 janv. 2010 ? 00:46, Jim Meyer a ?crit : > >> On 1/6/10 3:38 PM, Evan McClain wrote: >>> On Thu, Jan 07, 2010 at 12:29:39AM +0100, paolo lulli wrote: >>>> Hi there, >>>> >>>> I think it could be a great thing if the mailing list could be setup >>>> to prefix subject of the email with something like this one: >>>> >>>> [MacPorts-Dev] >>>> >>>> Eitherwise it is nearly impossible to distinguish between list >>>> messages and personal ones. >>>> I think it something easily accomplishable. >> >> I used to be a subject tag fan, but I'd much rather use that real estate for real subject line these days. I don't object to short ones (< 5 chars), but more than that is kinda painful, IMhO. >> >>> There is already a List-Id message header which can be used for >>> filtering and identifying which list the email is from, but some email >>> clients don't really let you see email headers or know how to deal with >>> mailing lists. I guess that's why I'm still using mutt :P >> >> Actually, almost all of them do, and many now let you set up mailing list filters or add custom headers to filter on. It doesn't yet pass my Mother-in-Law test*, but it should be within reach of anyone on this mailing list (again, IMhO). >> >> --j >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From ryandesign at macports.org Wed Jan 6 19:29:01 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 6 Jan 2010 21:29:01 -0600 Subject: Warning: Line X seems to hardcode the version number, consider using ${version} instead In-Reply-To: <710897AA-09CF-4476-B227-B1650539C2CC@macports.org> References: <41AFCCF9-AF82-4C8B-8872-1D4441546C09@macports.org> <3A02A2FA-252D-4106-804D-088C220FF7B9@macports.org> <90E8BC04-FD27-4C11-885D-F00AE3D8C35B@macports.org> <7BEC068F-36C2-4A6F-A0FA-057F981F2ECE@macports.org> <710897AA-09CF-4476-B227-B1650539C2CC@macports.org> Message-ID: <207254AC-4F00-4D54-8B75-238A09E4E54B@macports.org> On Jan 6, 2010, at 18:01, nox wrote: > Another one false positive is caused by the checksums from the verbose output of portchecksum when there is multiple distfiles (e.g. in zsh-devel). IMHO that's not a false positive; that's exactly the kind of place where lint is correct in suggesting that ${version} be used instead. Instead of checksums zsh-4.3.10.tar.bz2 \ use checksums zsh-${version}.tar.bz2 \ or checksums [suffix ${distname}] \ or set source_distfile [suffix ${distname}] checksums ${source_distfile} \ and then you can use ${source_distfile} also in the distfiles declaration, and define additional variables for each other distfile; I've done this in a few ports, like minivmac. minivmac also exemplifies another case where the lint version suggestion can be wrong, but there's no way lint could know that: set my_bootstrap_distfile ${my_name}-bootstrap-3.1.2_1.zip When minivmac was at version 3.1.2, lint would flag this line. But I specifically wanted the bootstrap to be 3.1.2, not ${version}; they just happened to be the same at that particular time. I ignored the lint warning until minivmac got updated to 3.1.3 and now it's not a problem anymore (until I next decide to update the bootstrap version). From talklists at newgeo.com Wed Jan 6 19:57:58 2010 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 6 Jan 2010 19:57:58 -0800 Subject: mysql5 server and plain In-Reply-To: References: Message-ID: <965E2FC4-0554-4FB8-8F29-64540397FBF8@newgeo.com> I am top posting, because you went over my head a little in that, so I am at least going to go over the top on something :) To be honest, I totally forgot that someone may want to instal just the mysql client, and may also do so without sudo involved. On a side note, you mention the mysql directories, which need to be _mysql owned, which I also find to be the case, is this done in the port or is this something the user is supposed to do? The MAMP page has the user doing it, if the port already does it, the MAMP page is redundant. You bring up great points, and I do not see any real perfect solutions to them. What about having a mysql-client port, that is obvious, then the mysql-server port, and that is it. That makes the most sense to me. I would make the server depend on the client, that is a liberty I would take, because they sort of go hand in hand. I agree with your comments about Apache, add to this, none of the plists are set to run, so they just sit there, the user had to load them. I do not see any reason to avoid putting them in place. Disc space is cheap, I could literally afford to store the plists for every MacPorts user there is :) There are a handful of softwares out there, seemingly the ones most people are going to be coming here for, that are just too hard for the average user to get up and running, I want to fix that. Have you seen a windows user get a AMP stack running, one download, one exe, and they are up and running, with a GUI app to go with it. This bothers me on so many levels, that they have this ease, on a platform that neither the A, the M, or the P were developed for when they first came out. I have some questions about the mysql5-server port, I will post a new message. Thanks for your excellent thoughts on this. P.S. that D-ports issue came up on the pure-ftpd mail list today. I had a user move over here to use MP for pure-ftpd, and he was confused. I have the emails flagged, and want to move back on that front again, but time is just not on my side these days. Just did not want you to think I flaked on your emails, they are all marked, and I will follow up on them eventually. Thanks Ryan. On Jan 6, 2010, at 11:27 AM, Ryan Schmidt wrote: > mysql5 installs the client and server software. mysql5-server installs the launchd plist and the directories a server would need. This mirrors the postgresql ports. > > There used to just be a mysql5 port with a +server variant, but this was awful because when installed as a dependency, or by someone who didn't yet understand variants, the port would be installed without the server launchd plist, and to get it, the user would have to recompile all of mysql5, which wasted a lot of time. *This* came up all the time for years and was worth discussion and resulted in what we have now. > > You might think just having a mysql5 port and making it always install the launchd plist would be better. But remember that it's not just the launchd plist: it's also the directories, which need to be owned by the mysql user. The user might be installing in a non-root prefix, might only need the client portion, and would not have permission to install the launchd plist nor to set the ownership of directories to a system user. Such a user could work around the launchd plist issue by setting startupitem_type to none in macports.conf, but the port would still have to know not to install the directories. Can a port query the startupitem type the user requested? If so, the port could do so and omit installing the server directories if ${startupitem.type} is none. In the end, however, you must admit this reduces transparency: Before, it was clear if you installed "mysql5 +server" you got a server, if you installed "mysql5" you didn't. Currently, if you install "mysql5-server" you get a server, if you just install "mysql5" you don't. But if we change the port to infer things based on the startupitem type, and you look at "port installed" and see "mysql5", you don't know whether it has server parts or not. I suppose (and I apologize, I'm thinking this through as I'm typing) the startupitem.type-based detection could lead to the port auto-selecting (or not) (using default_variants) the +server variant. Hmm..... You know, that might work. > > If we're thinking of removing mysql5-server, we should have similar thoughts about the postgresql and other ports that do this, and also about removing the +no_startupitem variant from ports like apache2, since a user who wants to install a purely server software like apache without a launchd plist is a) strange and apparently running with diminished privileges, and therefore b) must logically want the same for all other ports as well, and c) can achieve this in macports.conf. -- Scott * If you contact me off list replace talklists@ with scott@ * From dports at ambulatoryclam.net Wed Jan 6 19:59:26 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Wed, 6 Jan 2010 19:59:26 -0800 Subject: Warning: Line X seems to hardcode the version number, consider using ${version} instead In-Reply-To: <207254AC-4F00-4D54-8B75-238A09E4E54B@macports.org> References: <41AFCCF9-AF82-4C8B-8872-1D4441546C09@macports.org> <3A02A2FA-252D-4106-804D-088C220FF7B9@macports.org> <90E8BC04-FD27-4C11-885D-F00AE3D8C35B@macports.org> <7BEC068F-36C2-4A6F-A0FA-057F981F2ECE@macports.org> <710897AA-09CF-4476-B227-B1650539C2CC@macports.org> <207254AC-4F00-4D54-8B75-238A09E4E54B@macports.org> Message-ID: <20100107035926.GF82046@ambulatoryclam.net> On Wed, Jan 06, 2010 at 09:29:01PM -0600, Ryan Schmidt wrote: > Instead of > > checksums zsh-4.3.10.tar.bz2 \ > > use > > checksums zsh-${version}.tar.bz2 \ I don't understand this suggestion -- the checksums line is going to have to be regenerated anyway when the version changes, so why not hardcode the version number there? It is, after all, the checksum for zsh-4.3.10.tar.bz2, not any other version of zsh. Am I missing something? Dan -- Dan R. K. Ports Research Henchman Massachusetts Institute of Technology Computer Science and Artificial Intelligence Lab From talklists at newgeo.com Wed Jan 6 20:06:01 2010 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 6 Jan 2010 20:06:01 -0800 Subject: mysql5-server port - General Questions Message-ID: <00CCBD8F-310D-4AA0-8C73-B606098E6782@newgeo.com> Why does this need to be there: if {"darwin" == ${os.platform} && ${os.major} > 8} { set mysqluser _mysql } else { set mysqluser mysql } $sudo chown mysql:mysql something -rw-r--r-- 1 _mysql _mysql 0 Jan 6 19:59 something $sudo chown me:me something $sudo chown _mysql:_mysql something -rw-r--r-- 1 _mysql _mysql 0 Jan 6 19:59 something Seems to be, you can pretty safely just use mysql, and not worry about it. In the destroot phase, it looks like a mysql user and group is being added. I do not see any OS level conditions there, why is this happening? mysql has been a built in user on OS X since I believe 10.3, which should be about as far back as MacPorts is going to support? Why don't we chown the dirs for the user so they need not do so? From this page: http://trac.macports.org/wiki/howto/MAMP Step 3 sudo -u mysql mysql_install_db5 sudo chown -R mysql:mysql /opt/local/var/db/mysql5/ sudo chown -R mysql:mysql /opt/local/var/run/mysql5/ sudo chown -R mysql:mysql /opt/local/var/log/mysql5/ If that doesn?t work try this: sudo mysql_install_db5 sudo chown -R mysql:mysql /opt/local/var/db/mysql5/ sudo chown -R mysql:mysql /opt/local/var/run/mysql5/ First, what would cause the first set of steps to fail, and what can we do to make sure they do not? Second, other than the `mysql_install_db5`, I believe the rest of that work should be done in the Portfile, unless there is good reason not to. Thanks for any comments -- Scott * If you contact me off list replace talklists@ with scott@ * From brad at pixilla.com Wed Jan 6 20:30:39 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Wed, 6 Jan 2010 20:30:39 -0800 Subject: mysql5-server port - General Questions In-Reply-To: <00CCBD8F-310D-4AA0-8C73-B606098E6782@newgeo.com> References: <00CCBD8F-310D-4AA0-8C73-B606098E6782@newgeo.com> Message-ID: <64B1B83B-09DC-42B5-9C00-D9596CFD34C1@pixilla.com> On Jan 6, 2010, at 8:06 PM, Scott Haneda wrote: > Why does this need to be there: > if {"darwin" == ${os.platform} && ${os.major} > 8} { > set mysqluser _mysql > } else { > set mysqluser mysql > } > > $sudo chown mysql:mysql something > -rw-r--r-- 1 _mysql _mysql 0 Jan 6 19:59 something > > $sudo chown me:me something > $sudo chown _mysql:_mysql something > -rw-r--r-- 1 _mysql _mysql 0 Jan 6 19:59 something > > Seems to be, you can pretty safely just use mysql, and not worry > about it. > > In the destroot phase, it looks like a mysql user and group is being > added. I do not see any OS level conditions there, why is this > happening? mysql has been a built in user on OS X since I believe > 10.3, which should be about as far back as MacPorts is going to > support? I don't recall how far back, I think Leopard, Apple prefixed pretty much all these types of users with "_". Hence _www for apache. > Why don't we chown the dirs for the user so they need not do so? > >> From this page: > http://trac.macports.org/wiki/howto/MAMP > Step 3 > > sudo -u mysql mysql_install_db5 > sudo chown -R mysql:mysql /opt/local/var/db/mysql5/ > sudo chown -R mysql:mysql /opt/local/var/run/mysql5/ > sudo chown -R mysql:mysql /opt/local/var/log/mysql5/ > > If that doesn?t work try this: > > sudo mysql_install_db5 > sudo chown -R mysql:mysql /opt/local/var/db/mysql5/ > sudo chown -R mysql:mysql /opt/local/var/run/mysql5/ > > First, what would cause the first set of steps to fail, and what can > we do to make sure they do not? Second, other than the > `mysql_install_db5`, I believe the rest of that work should be done > in the Portfile, unless there is good reason not to. > > Thanks for any comments Maybe someone already has all the db's installed and they just want mysql5. They won't need and probably won't want to install/overwrite the mysql and information_schema tables. But maybe I don't understand what your getting at. // Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at pixilla.com Wed Jan 6 20:40:41 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Wed, 6 Jan 2010 20:40:41 -0800 Subject: mysql5 server and plain In-Reply-To: <965E2FC4-0554-4FB8-8F29-64540397FBF8@newgeo.com> References: <965E2FC4-0554-4FB8-8F29-64540397FBF8@newgeo.com> Message-ID: <520766D0-ED2A-456F-8881-5ACD2883EF9A@pixilla.com> On Jan 6, 2010, at 7:57 PM, Scott Haneda wrote: > I am top posting, because you went over my head a little in that, so > I am at least going to go over the top on something :) > > To be honest, I totally forgot that someone may want to instal just > the mysql client, and may also do so without sudo involved. > > On a side note, you mention the mysql directories, which need to be > _mysql owned, which I also find to be the case, is this done in the > port or is this something the user is supposed to do? The MAMP page > has the user doing it, if the port already does it, the MAMP page is > redundant. > > You bring up great points, and I do not see any real perfect > solutions to them. What about having a mysql-client port, that is > obvious, then the mysql-server port, and that is it. That makes the > most sense to me. I would make the server depend on the client, > that is a liberty I would take, because they sort of go hand in hand. > > I agree with your comments about Apache, add to this, none of the > plists are set to run, so they just sit there, the user had to load > them. I do not see any reason to avoid putting them in place. Disc > space is cheap, I could literally afford to store the plists for > every MacPorts user there is :) > > There are a handful of softwares out there, seemingly the ones most > people are going to be coming here for, that are just too hard for > the average user to get up and running, I want to fix that. Have > you seen a windows user get a AMP stack running, one download, one > exe, and they are up and running, with a GUI app to go with it. > This bothers me on so many levels, that they have this ease, on a > platform that neither the A, the M, or the P were developed for when > they first came out. Doesn't XAMP (apachefriends.com) and MAMP (mamp.info) both have double clickable installers for Mac OS X? > I have some questions about the mysql5-server port, I will post a > new message. Thanks for your excellent thoughts on this. > > P.S. that D-ports issue came up on the pure-ftpd mail list today. I > had a user move over here to use MP for pure-ftpd, and he was > confused. I have the emails flagged, and want to move back on that > front again, but time is just not on my side these days. Just did > not want you to think I flaked on your emails, they are all marked, > and I will follow up on them eventually. Thanks Ryan. > > On Jan 6, 2010, at 11:27 AM, Ryan Schmidt wrote: > >> mysql5 installs the client and server software. mysql5-server >> installs the launchd plist and the directories a server would need. >> This mirrors the postgresql ports. >> >> There used to just be a mysql5 port with a +server variant, but >> this was awful because when installed as a dependency, or by >> someone who didn't yet understand variants, the port would be >> installed without the server launchd plist, and to get it, the user >> would have to recompile all of mysql5, which wasted a lot of time. >> *This* came up all the time for years and was worth discussion and >> resulted in what we have now. >> >> You might think just having a mysql5 port and making it always >> install the launchd plist would be better. But remember that it's >> not just the launchd plist: it's also the directories, which need >> to be owned by the mysql user. The user might be installing in a >> non-root prefix, might only need the client portion, and would not >> have permission to install the launchd plist nor to set the >> ownership of directories to a system user. Such a user could work >> around the launchd plist issue by setting startupitem_type to none >> in macports.conf, but the port would still have to know not to >> install the directories. Can a port query the startupitem type the >> user requested? If so, the port could do so and omit installing the >> server directories if ${startupitem.type} is none. In the end, >> however, you must admit this reduces transparency: Before, it was >> clear if you installed "mysql5 +server" you got a server, if you >> installed "mysql5" you didn't. Currently, if you install "mysql5- >> server" you > get a server, if you just install "mysql5" you don't. But if we > change the port to infer things based on the startupitem type, and > you look at "port installed" and see "mysql5", you don't know > whether it has server parts or not. I suppose (and I apologize, I'm > thinking this through as I'm typing) the startupitem.type-based > detection could lead to the port auto-selecting (or not) (using > default_variants) the +server variant. Hmm..... You know, that might > work. >> >> If we're thinking of removing mysql5-server, we should have similar >> thoughts about the postgresql and other ports that do this, and >> also about removing the +no_startupitem variant from ports like >> apache2, since a user who wants to install a purely server software >> like apache without a launchd plist is a) strange and apparently >> running with diminished privileges, and therefore b) must logically >> want the same for all other ports as well, and c) can achieve this >> in macports.conf. > -- > Scott * If you contact me off list replace talklists@ with scott@ * > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Wed Jan 6 21:15:28 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 6 Jan 2010 23:15:28 -0600 Subject: Warning: Line X seems to hardcode the version number, consider using ${version} instead In-Reply-To: <20100107035926.GF82046@ambulatoryclam.net> References: <41AFCCF9-AF82-4C8B-8872-1D4441546C09@macports.org> <3A02A2FA-252D-4106-804D-088C220FF7B9@macports.org> <90E8BC04-FD27-4C11-885D-F00AE3D8C35B@macports.org> <7BEC068F-36C2-4A6F-A0FA-057F981F2ECE@macports.org> <710897AA-09CF-4476-B227-B1650539C2CC@macports.org> <207254AC-4F00-4D54-8B75-238A09E4E54B@macports.org> <20100107035926.GF82046@ambulatoryclam.net> Message-ID: On Jan 6, 2010, at 21:59, Dan Ports wrote: > On Wed, Jan 06, 2010 at 09:29:01PM -0600, Ryan Schmidt wrote: >> Instead of >> >> checksums zsh-4.3.10.tar.bz2 \ >> >> use >> >> checksums zsh-${version}.tar.bz2 \ > > I don't understand this suggestion -- the checksums line is going to > have to be regenerated anyway when the version changes, so why not > hardcode the version number there? It is, after all, the checksum for > zsh-4.3.10.tar.bz2, not any other version of zsh. > > Am I missing something? I prefer to update as few lines in the portfile for each update as possible, and update the same piece of information in as few places as possible. So I prefer to have the version number in one place in the portfile instead of two. From ryandesign at macports.org Wed Jan 6 21:23:29 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 6 Jan 2010 23:23:29 -0600 Subject: mysql5 server and plain In-Reply-To: <965E2FC4-0554-4FB8-8F29-64540397FBF8@newgeo.com> References: <965E2FC4-0554-4FB8-8F29-64540397FBF8@newgeo.com> Message-ID: On Jan 6, 2010, at 21:57, Scott Haneda wrote: > On a side note, you mention the mysql directories, which need to be _mysql owned, which I also find to be the case, is this done in the port or is this something the user is supposed to do? The MAMP page has the user doing it, if the port already does it, the MAMP page is redundant. That particular directive on the MAMP page may well be redundant. I did not write that page and have not attempted to follow the instructions myself from a fresh install. The mysql5-server port does the following: xinstall -m 755 -o ${mysqluser} -g ${mysqluser} -d \ ${destroot}${dbdir} \ ${destroot}${prefix}/var/log/${mysql} \ ${destroot}${prefix}/var/run/${mysql} So the directories should definitely be getting changed to the correct owner by the port automatically. > You bring up great points, and I do not see any real perfect solutions to them. What about having a mysql-client port, that is obvious, then the mysql-server port, and that is it. That makes the most sense to me. I would make the server depend on the client, that is a liberty I would take, because they sort of go hand in hand. This was originally suggested as well; see the ticket. One big reason I didn't do it at the time is that MacPorts did not have the "replaced_by" command so it was perhaps impossible to effect a smooth transition for a user who already had the mysql5 port installed to the new mysql5-client port. This reason no longer applies, but the mysql5 port installs both the client and server software, so it's not really accurate to name it "mysql5-client". > I agree with your comments about Apache, add to this, none of the plists are set to run, so they just sit there, the user had to load them. I do not see any reason to avoid putting them in place. Disc space is cheap, I could literally afford to store the plists for every MacPorts user there is :) Yes, certainly disk space was never the reason for this variant. Plists are only a few K. The variant was added to apache2 in r22490 to "[prevent] the automatic startup of the Apache web server" but as you've pointed out, the server does not automatically start up; you have to activate the plist manually. So that reason is not valid. > There are a handful of softwares out there, seemingly the ones most people are going to be coming here for, that are just too hard for the average user to get up and running, I want to fix that. Have you seen a windows user get a AMP stack running, one download, one exe, and they are up and running, with a GUI app to go with it. This bothers me on so many levels, that they have this ease, on a platform that neither the A, the M, or the P were developed for when they first came out. There are probably other methods of getting this software on a Mac that are "easier". Certainly apache and php already comes with Mac OS X so that's easy, and there's a binary of MySQL from the manufacturer. MacPorts gives you more options, and with that comes more complexity. From talklists at newgeo.com Wed Jan 6 22:18:11 2010 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 6 Jan 2010 22:18:11 -0800 Subject: mysql5-server port - General Questions In-Reply-To: <64B1B83B-09DC-42B5-9C00-D9596CFD34C1@pixilla.com> References: <00CCBD8F-310D-4AA0-8C73-B606098E6782@newgeo.com> <64B1B83B-09DC-42B5-9C00-D9596CFD34C1@pixilla.com> Message-ID: >> Why don't we chown the dirs for the user so they need not do so? >> >>> From this page: >> http://trac.macports.org/wiki/howto/MAMP >> Step 3 >> >> sudo -u mysql mysql_install_db5 >> sudo chown -R mysql:mysql /opt/local/var/db/mysql5/ >> sudo chown -R mysql:mysql /opt/local/var/run/mysql5/ >> sudo chown -R mysql:mysql /opt/local/var/log/mysql5/ >> >> If that doesn?t work try this: >> >> sudo mysql_install_db5 >> sudo chown -R mysql:mysql /opt/local/var/db/mysql5/ >> sudo chown -R mysql:mysql /opt/local/var/run/mysql5/ >> >> First, what would cause the first set of steps to fail, and what can we do to make sure they do not? Second, other than the `mysql_install_db5`, I believe the rest of that work should be done in the Portfile, unless there is good reason not to. >> >> Thanks for any comments > > Maybe someone already has all the db's installed and they just want mysql5. They won't need and probably won't want to install/overwrite the mysql and information_schema tables. But maybe I don't understand what your getting at. Not the way I would approach it, but a valid point. I would install first, them move the Db's in place. Ports would over-write data in a unintall and reinstall? What I am getting at is the MAMP wiki has a "if that doesn't work" clause, and I hear from too many people they can not get MAMP running, I want to help solve that. The MAMP page is entirely tailored to a first time install, so the u:g should probably be set in one of the phases of the install that MacPorts is doing. It is an entire 5 lines of tutorial steps that could be removed. -- Scott * If you contact me off list replace talklists@ with scott@ * From nox at macports.org Thu Jan 7 03:24:26 2010 From: nox at macports.org (nox) Date: Thu, 7 Jan 2010 12:24:26 +0100 Subject: Warning: Line X seems to hardcode the version number, consider using ${version} instead In-Reply-To: References: <41AFCCF9-AF82-4C8B-8872-1D4441546C09@macports.org> <3A02A2FA-252D-4106-804D-088C220FF7B9@macports.org> <90E8BC04-FD27-4C11-885D-F00AE3D8C35B@macports.org> <7BEC068F-36C2-4A6F-A0FA-057F981F2ECE@macports.org> <710897AA-09CF-4476-B227-B1650539C2CC@macports.org> <207254AC-4F00-4D54-8B75-238A09E4E54B@macports.org> <20100107035926.GF82046@ambulatoryclam.net> Message-ID: And I prefer to not have to do more than just copy and paste a few lines generated by portchecksum itself. Le 7 janv. 2010 ? 06:15, Ryan Schmidt a ?crit : > > On Jan 6, 2010, at 21:59, Dan Ports wrote: > >> On Wed, Jan 06, 2010 at 09:29:01PM -0600, Ryan Schmidt wrote: >>> Instead of >>> >>> checksums zsh-4.3.10.tar.bz2 \ >>> >>> use >>> >>> checksums zsh-${version}.tar.bz2 \ >> >> I don't understand this suggestion -- the checksums line is going to >> have to be regenerated anyway when the version changes, so why not >> hardcode the version number there? It is, after all, the checksum for >> zsh-4.3.10.tar.bz2, not any other version of zsh. >> >> Am I missing something? > > I prefer to update as few lines in the portfile for each update as possible, and update the same piece of information in as few places as possible. So I prefer to have the version number in one place in the portfile instead of two. > > > From ryandesign at macports.org Thu Jan 7 18:25:36 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 7 Jan 2010 20:25:36 -0600 Subject: mysql5-server port - General Questions In-Reply-To: <00CCBD8F-310D-4AA0-8C73-B606098E6782@newgeo.com> References: <00CCBD8F-310D-4AA0-8C73-B606098E6782@newgeo.com> Message-ID: <4FE03983-0F92-4AE7-AF1D-D408744B51C6@macports.org> On Jan 6, 2010, at 22:06, Scott Haneda wrote: > Why does this need to be there: > if {"darwin" == ${os.platform} && ${os.major} > 8} { > set mysqluser _mysql > } else { > set mysqluser mysql > } > > $sudo chown mysql:mysql something > -rw-r--r-- 1 _mysql _mysql 0 Jan 6 19:59 something > > $sudo chown me:me something > $sudo chown _mysql:_mysql something > -rw-r--r-- 1 _mysql _mysql 0 Jan 6 19:59 something > > Seems to be, you can pretty safely just use mysql, and not worry about it. That's what I had been doing, but someone reported a bug about it. As you can see from "svn blame $(port file mysql5-server)" (assuming your ports tree is a Subversion working copy) these lines were changed in r60468, and as you can see from "svn log -r 60468 $(port file mysql5-server)" this was to fix #13705 of which duplicate #22472 reported that yes, this did actually cause problems. I did not understand how but didn't feel like arguing and just made the change. > In the destroot phase, it looks like a mysql user and group is being added. I do not see any OS level conditions there, why is this happening? mysql has been a built in user on OS X since I believe 10.3, which should be about as far back as MacPorts is going to support? > > Why don't we chown the dirs for the user so they need not do so? >> As I previously said, I believe that the port already does this. I showed you the xinstall command that should do this. If it does not actually work, please let me know. > From this page: > http://trac.macports.org/wiki/howto/MAMP > Step 3 > > sudo -u mysql mysql_install_db5 > sudo chown -R mysql:mysql /opt/local/var/db/mysql5/ > sudo chown -R mysql:mysql /opt/local/var/run/mysql5/ > sudo chown -R mysql:mysql /opt/local/var/log/mysql5/ > > If that doesn?t work try this: > > sudo mysql_install_db5 > sudo chown -R mysql:mysql /opt/local/var/db/mysql5/ > sudo chown -R mysql:mysql /opt/local/var/run/mysql5/ > > First, what would cause the first set of steps to fail, and what can we do to make sure they do not? Second, other than the `mysql_install_db5`, I believe the rest of that work should be done in the Portfile, unless there is good reason not to. The "If that doesn't work" bit has always irritated me rather a lot. It's stupid. If you have time to figure it out, please do and correct the instructions. But as you say, it should be possible to delete the whole section, since it's telling you to do things the port already does -- the port already sets the permissions, and it already prints a message telling you to run mysql_install_db5; I'm in favor of having the installation documented either in the port's post-install or on a web page but not both. From ryandesign at macports.org Thu Jan 7 18:37:08 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 7 Jan 2010 20:37:08 -0600 Subject: [62430] trunk/dports/devel/griffon/Portfile In-Reply-To: <20100107183332.CCF283ADC5F5@beta.macosforge.org> References: <20100107183332.CCF283ADC5F5@beta.macosforge.org> Message-ID: <1C06E84B-7F70-41F4-983C-2763212D3BB3@macports.org> On Jan 7, 2010, at 12:33, breskeby at macports.org wrote: > Revision: 62430 > http://trac.macports.org/changeset/62430 > Author: breskeby at macports.org > Date: 2010-01-07 10:33:31 -0800 (Thu, 07 Jan 2010) > Log Message: > ----------- > version bump to 0.2.1 You also undid my changes from r59916. I re-did them in r62436. From talklists at newgeo.com Thu Jan 7 18:49:32 2010 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 7 Jan 2010 18:49:32 -0800 Subject: mysql5-server port - General Questions In-Reply-To: <4FE03983-0F92-4AE7-AF1D-D408744B51C6@macports.org> References: <00CCBD8F-310D-4AA0-8C73-B606098E6782@newgeo.com> <4FE03983-0F92-4AE7-AF1D-D408744B51C6@macports.org> Message-ID: Ryan, the below and your other comments, I will work on a machine in which I have some luxuries to do clean installs and wipe prefix at my leisure. I will see what I can do to present a clean and clear update to the wiki. I think this should be in the wiki, just so you guys get the google love out of it, rather than in the port port-install messages, which will do no good to get any visibility in google, which is still a problem for MP's. I will start with MySql, and work my way through each of the ports, until we have sectional installs for AM and P, then see how I can logically chain those instructions together into the MAMP wiki pages. Thanks. -- Scott * If you contact me off list replace talklists@ with scott@ * On Jan 7, 2010, at 6:25 PM, Ryan Schmidt wrote: >> >> From this page: >> http://trac.macports.org/wiki/howto/MAMP >> Step 3 >> >> sudo -u mysql mysql_install_db5 >> sudo chown -R mysql:mysql /opt/local/var/db/mysql5/ >> sudo chown -R mysql:mysql /opt/local/var/run/mysql5/ >> sudo chown -R mysql:mysql /opt/local/var/log/mysql5/ >> >> If that doesn?t work try this: >> >> sudo mysql_install_db5 >> sudo chown -R mysql:mysql /opt/local/var/db/mysql5/ >> sudo chown -R mysql:mysql /opt/local/var/run/mysql5/ >> >> First, what would cause the first set of steps to fail, and what can we do to make sure they do not? Second, other than the `mysql_install_db5`, I believe the rest of that work should be done in the Portfile, unless there is good reason not to. > > The "If that doesn't work" bit has always irritated me rather a lot. It's stupid. If you have time to figure it out, please do and correct the instructions. But as you say, it should be possible to delete the whole section, since it's telling you to do things the port already does -- the port already sets the permissions, and it already prints a message telling you to run mysql_install_db5; I'm in favor of having the installation documented either in the port's post-install or on a web page but not both. From ryandesign at macports.org Thu Jan 7 19:25:46 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 7 Jan 2010 21:25:46 -0600 Subject: mysql5-server port - General Questions In-Reply-To: References: <00CCBD8F-310D-4AA0-8C73-B606098E6782@newgeo.com> <4FE03983-0F92-4AE7-AF1D-D408744B51C6@macports.org> Message-ID: On Jan 7, 2010, at 20:49, Scott Haneda wrote: > Ryan, the below and your other comments, I will work on a machine in which I have some luxuries to do clean installs and wipe prefix at my leisure. I will see what I can do to present a clean and clear update to the wiki. > > I think this should be in the wiki, just so you guys get the google love out of it, rather than in the port port-install messages, which will do no good to get any visibility in google, which is still a problem for MP's. > > I will start with MySql, and work my way through each of the ports, until we have sectional installs for AM and P, then see how I can logically chain those instructions together into the MAMP wiki pages. Google searchability -- good observation. Some ports go a little overboard with how much info they print. Others like mysql probably print not enough information. I think it would be great if ports that have setup instructions would either put them in a file and then just tell the user where that file is, or like you say put it on a wiki page and then just print the url to the wiki page. This would be cleaner than printing a bunch at post-install time which it's hard for a user to review after installation. From brad at pixilla.com Fri Jan 8 08:38:11 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 8 Jan 2010 08:38:11 -0800 Subject: port message Message-ID: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> Is there a port command for just printing out the port ui_mesg? If not this might be simple to implement and useful. // Brad From talklists at newgeo.com Fri Jan 8 09:03:34 2010 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 8 Jan 2010 09:03:34 -0800 Subject: port message In-Reply-To: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> References: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> Message-ID: <2436C780-ACFA-4DD4-805B-F77664510F6C@newgeo.com> I hope there is. My method is always port edit and read them there. Seems there is always good data in the port messages at the end, that I need later. I like your idea, or, logging the install to a known location so I can go back and look at it. -- Scott (Sent from a mobile device) On Jan 8, 2010, at 8:38 AM, Bradley Giesbrecht wrote: > Is there a port command for just printing out the port ui_mesg? > > If not this might be simple to implement and useful. From jmr at macports.org Fri Jan 8 09:21:17 2010 From: jmr at macports.org (Joshua Root) Date: Sat, 09 Jan 2010 04:21:17 +1100 Subject: port message In-Reply-To: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> References: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> Message-ID: <4B47698D.4060008@macports.org> On 2010-1-9 03:38 , Bradley Giesbrecht wrote: > Is there a port command for just printing out the port ui_mesg? > > If not this might be simple to implement and useful. Well, ui_msg is just a procedure and as such can be called conditionally, so there's no such thing as "the" ui_msg for a port. Anything the user might want to see again should be done with the 'notes' feature introduced in 1.8. - Josh From brad at pixilla.com Fri Jan 8 14:34:33 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 8 Jan 2010 14:34:33 -0800 Subject: port message In-Reply-To: <2436C780-ACFA-4DD4-805B-F77664510F6C@newgeo.com> References: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> <2436C780-ACFA-4DD4-805B-F77664510F6C@newgeo.com> Message-ID: On Jan 8, 2010, at 9:03 AM, Scott Haneda wrote: > I hope there is. My method is always port edit and read them there. > Seems there is always good data in the port messages at the end, > that I need later. You might use port cat instead. And "port cat php5 | grep ui_msg" kinda works but I bet you can use \ line continuation which this will not help you with. I was hoping for port message to print all the ui_msg's from the port and all deps. This is where it makes the most sense to me or do as I suggested a while back and store the ui_msg till the end of the port process and print them all together. Otherwise you will probably never see "with -v or -d anyways" the ui_msg's for any ports other then the last. // Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at pixilla.com Fri Jan 8 14:40:06 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 8 Jan 2010 14:40:06 -0800 Subject: port message In-Reply-To: <4B47698D.4060008@macports.org> References: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> <4B47698D.4060008@macports.org> Message-ID: <49DDCF2F-3CE9-496B-BDFF-5ED163AAC0A8@pixilla.com> On Jan 8, 2010, at 9:21 AM, Joshua Root wrote: > On 2010-1-9 03:38 , Bradley Giesbrecht wrote: >> Is there a port command for just printing out the port ui_mesg? >> >> If not this might be simple to implement and useful. > > Well, ui_msg is just a procedure and as such can be called > conditionally, so there's no such thing as "the" ui_msg for a port. > Anything the user might want to see again should be done with the > 'notes' feature introduced in 1.8. I haven't seen 'notes' in a portfile yet. Is the idea that most of the stuff that is currently in ui_msg should be moved to notes? Can you give me an example of the Portfile variable and port command usage for notes? // Brad From talklists at newgeo.com Fri Jan 8 15:26:59 2010 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 8 Jan 2010 15:26:59 -0800 Subject: port message In-Reply-To: References: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> <2436C780-ACFA-4DD4-805B-F77664510F6C@newgeo.com> Message-ID: On Jan 8, 2010, at 2:34 PM, Bradley Giesbrecht wrote: > On Jan 8, 2010, at 9:03 AM, Scott Haneda wrote: > >> I hope there is. My method is always port edit and read them there. >> Seems there is always good data in the port messages at the end, >> that I need later. > > You might use port cat instead. > > And "port cat php5 | grep ui_msg" kinda works but I bet you can use > \ line continuation which this will not help you with. > > I was hoping for port message to print all the ui_msg's from the > port and all deps. This is where it makes the most sense to me or do > as I suggested a while back and store the ui_msg till the end of the > port process and print them all together. Otherwise you will > probably never see "with -v or -d anyways" the ui_msg's for any > ports other then the last. Maybe you could solve this on your own, at least with ports you maintain. Normal ui messages in any phase could be appended to an array. At the end of the install If debug flag is on repeat secondary array Print array item line end repeat End if It's not going to help much other than for your own ports, but maybe a few test cases and the value of it, along with recursion into deps, could make it into core as a single command or built in feature. -- Scott (Sent from a mobile device) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmr at macports.org Fri Jan 8 15:39:31 2010 From: jmr at macports.org (Joshua Root) Date: Sat, 09 Jan 2010 10:39:31 +1100 Subject: port message In-Reply-To: <49DDCF2F-3CE9-496B-BDFF-5ED163AAC0A8@pixilla.com> References: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> <4B47698D.4060008@macports.org> <49DDCF2F-3CE9-496B-BDFF-5ED163AAC0A8@pixilla.com> Message-ID: <4B47C233.1000805@macports.org> On 2010-1-9 09:40 , Bradley Giesbrecht wrote: > On Jan 8, 2010, at 9:21 AM, Joshua Root wrote: > >> On 2010-1-9 03:38 , Bradley Giesbrecht wrote: >>> Is there a port command for just printing out the port ui_mesg? >>> >>> If not this might be simple to implement and useful. >> >> Well, ui_msg is just a procedure and as such can be called >> conditionally, so there's no such thing as "the" ui_msg for a port. >> Anything the user might want to see again should be done with the >> 'notes' feature introduced in 1.8. > > I haven't seen 'notes' in a portfile yet. > > Is the idea that most of the stuff that is currently in ui_msg should be > moved to notes? > > Can you give me an example of the Portfile variable and port command > usage for notes? color-theme-mode.el was the first example I found. Usage is just "port notes " - Josh From brad at pixilla.com Fri Jan 8 16:20:05 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 8 Jan 2010 16:20:05 -0800 Subject: port message In-Reply-To: <4B47C233.1000805@macports.org> References: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> <4B47698D.4060008@macports.org> <49DDCF2F-3CE9-496B-BDFF-5ED163AAC0A8@pixilla.com> <4B47C233.1000805@macports.org> Message-ID: <0BF0C0C9-57BA-4F8C-9EF0-A8D9EA8259A7@pixilla.com> Since nothing I have installed has any notes in the portfile but many of them have ui_msg could we possibly add a flag or another command to print the ui_msg as well? port notes apache2 :ui_msg // Brad On Jan 8, 2010, at 3:39 PM, Joshua Root wrote: > On 2010-1-9 09:40 , Bradley Giesbrecht wrote: >> On Jan 8, 2010, at 9:21 AM, Joshua Root wrote: >> >>> On 2010-1-9 03:38 , Bradley Giesbrecht wrote: >>>> Is there a port command for just printing out the port ui_mesg? >>>> >>>> If not this might be simple to implement and useful. >>> >>> Well, ui_msg is just a procedure and as such can be called >>> conditionally, so there's no such thing as "the" ui_msg for a port. >>> Anything the user might want to see again should be done with the >>> 'notes' feature introduced in 1.8. >> >> I haven't seen 'notes' in a portfile yet. >> >> Is the idea that most of the stuff that is currently in ui_msg >> should be >> moved to notes? >> >> Can you give me an example of the Portfile variable and port command >> usage for notes? > > color-theme-mode.el was the first example I found. Usage is just > "port notes " > > - Josh From ryandesign at macports.org Fri Jan 8 17:02:27 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 8 Jan 2010 19:02:27 -0600 Subject: port message In-Reply-To: <0BF0C0C9-57BA-4F8C-9EF0-A8D9EA8259A7@pixilla.com> References: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> <4B47698D.4060008@macports.org> <49DDCF2F-3CE9-496B-BDFF-5ED163AAC0A8@pixilla.com> <4B47C233.1000805@macports.org> <0BF0C0C9-57BA-4F8C-9EF0-A8D9EA8259A7@pixilla.com> Message-ID: <64466FA3-7144-4563-B794-74AE36865006@macports.org> On Jan 8, 2010, at 18:20, Bradley Giesbrecht wrote: > Since nothing I have installed has any notes in the portfile but many of them have ui_msg could we possibly add a flag or another command to print the ui_msg as well? > > port notes apache2 :ui_msg Which ui_msgs? As explained, ui_msg can appear anywhere in a portfile, inside if clauses, inside phases, inside variants, etc. I would rather ports be modified to start using the notes feature. From brad at pixilla.com Fri Jan 8 18:22:06 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 8 Jan 2010 18:22:06 -0800 Subject: port message In-Reply-To: <64466FA3-7144-4563-B794-74AE36865006@macports.org> References: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> <4B47698D.4060008@macports.org> <49DDCF2F-3CE9-496B-BDFF-5ED163AAC0A8@pixilla.com> <4B47C233.1000805@macports.org> <0BF0C0C9-57BA-4F8C-9EF0-A8D9EA8259A7@pixilla.com> <64466FA3-7144-4563-B794-74AE36865006@macports.org> Message-ID: On Jan 8, 2010, at 5:02 PM, Ryan Schmidt wrote: > > On Jan 8, 2010, at 18:20, Bradley Giesbrecht wrote: > >> Since nothing I have installed has any notes in the portfile but >> many of them have ui_msg could we possibly add a flag or another >> command to print the ui_msg as well? >> >> port notes apache2 :ui_msg > > Which ui_msgs? As explained, ui_msg can appear anywhere in a > portfile, inside if clauses, inside phases, inside variants, etc. > > I would rather ports be modified to start using the notes feature. I understand but there is a lot of valuable information in the existing ui_msg. I was thinking parse the file as a normal "port upgrade" but don't actually execute anything other then step into variant blocks so you pick up the ui_msg for the variants in use. // Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at pixilla.com Fri Jan 8 18:29:05 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 8 Jan 2010 18:29:05 -0800 Subject: port message In-Reply-To: <64466FA3-7144-4563-B794-74AE36865006@macports.org> References: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> <4B47698D.4060008@macports.org> <49DDCF2F-3CE9-496B-BDFF-5ED163AAC0A8@pixilla.com> <4B47C233.1000805@macports.org> <0BF0C0C9-57BA-4F8C-9EF0-A8D9EA8259A7@pixilla.com> <64466FA3-7144-4563-B794-74AE36865006@macports.org> Message-ID: <193C34A0-6789-4D35-B93B-C520E1B4FF8C@pixilla.com> On Jan 8, 2010, at 5:02 PM, Ryan Schmidt wrote: > > On Jan 8, 2010, at 18:20, Bradley Giesbrecht wrote: > >> Since nothing I have installed has any notes in the portfile but >> many of them have ui_msg could we possibly add a flag or another >> command to print the ui_msg as well? >> >> port notes apache2 :ui_msg > > Which ui_msgs? As explained, ui_msg can appear anywhere in a > portfile, inside if clauses, inside phases, inside variants, etc. All the ui_msgs excluding non-selected variants. > I would rather ports be modified to start using the notes feature. Haven't you ever installed a port with -v that had deps, sometimes a lot of them, and wonder if there were any ui_msg for the deps that were important? I find many things more fun then searching through miles of scroll buffer. // Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde at gmail.com Fri Jan 8 18:36:41 2010 From: n.oxyde at gmail.com (nox) Date: Sat, 9 Jan 2010 03:36:41 +0100 Subject: port message In-Reply-To: <193C34A0-6789-4D35-B93B-C520E1B4FF8C@pixilla.com> References: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> <4B47698D.4060008@macports.org> <49DDCF2F-3CE9-496B-BDFF-5ED163AAC0A8@pixilla.com> <4B47C233.1000805@macports.org> <0BF0C0C9-57BA-4F8C-9EF0-A8D9EA8259A7@pixilla.com> <64466FA3-7144-4563-B794-74AE36865006@macports.org> <193C34A0-6789-4D35-B93B-C520E1B4FF8C@pixilla.com> Message-ID: <4C16EBC1-96FA-46C5-AA65-D0C69629DDFC@gmail.com> At the core, portfiles are TCL scripts. And excluding anything except ui_msg, any called procedure except ui_msg would be to transformed into a no-op. This can't be done at runtime, and we can't possibly write a list of those procedures. So your idea is unrealisable. Le 9 janv. 2010 ? 03:29, Bradley Giesbrecht a ?crit : > > On Jan 8, 2010, at 5:02 PM, Ryan Schmidt wrote: > >> >> On Jan 8, 2010, at 18:20, Bradley Giesbrecht wrote: >> >>> Since nothing I have installed has any notes in the portfile but many of them have ui_msg could we possibly add a flag or another command to print the ui_msg as well? >>> >>> port notes apache2 :ui_msg >> >> Which ui_msgs? As explained, ui_msg can appear anywhere in a portfile, inside if clauses, inside phases, inside variants, etc. > > All the ui_msgs excluding non-selected variants. > >> I would rather ports be modified to start using the notes feature. > > > Haven't you ever installed a port with -v that had deps, sometimes a lot of them, and wonder if there were any ui_msg for the deps that were important? > > I find many things more fun then searching through miles of scroll buffer. > > > // Brad > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From ryandesign at macports.org Fri Jan 8 20:31:45 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 8 Jan 2010 22:31:45 -0600 Subject: port message In-Reply-To: <4C16EBC1-96FA-46C5-AA65-D0C69629DDFC@gmail.com> References: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> <4B47698D.4060008@macports.org> <49DDCF2F-3CE9-496B-BDFF-5ED163AAC0A8@pixilla.com> <4B47C233.1000805@macports.org> <0BF0C0C9-57BA-4F8C-9EF0-A8D9EA8259A7@pixilla.com> <64466FA3-7144-4563-B794-74AE36865006@macports.org> <193C34A0-6789-4D35-B93B-C520E1B4FF8C@pixilla.com> <4C16EBC1-96FA-46C5-AA65-D0C69629DDFC@gmail.com> Message-ID: On Jan 8, 2010, at 20:36, nox wrote: > At the core, portfiles are TCL scripts. And excluding anything except ui_msg, any called procedure except ui_msg would be to transformed into a no-op. This can't be done at runtime, and we can't possibly write a list of those procedures. So your idea is unrealisable. Maybe not in the form he suggested, but it would certainly be possible to modify ui_msg so that in addition to printing a message, it keeps it in an array, and prints them again at the end if in debug mode. But I think we may be trying to solve the wrong problem. MacPorts 1.9.0 will introduce logging, so I think this makes most of the reasons one would use debug mode go away. The problem is not "There's too much information in debug mode and I can't see the stuff that's relevant to me"; the problem is "We ask users to run in debug mode." With logging, we no longer need to ask users to run in debug mode. So do we then really still need to change how messages are printed? From brad at pixilla.com Fri Jan 8 20:52:48 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 8 Jan 2010 20:52:48 -0800 Subject: port message In-Reply-To: References: <9A4CCA08-D349-4DB7-BF6E-46DD53323DC3@pixilla.com> <4B47698D.4060008@macports.org> <49DDCF2F-3CE9-496B-BDFF-5ED163AAC0A8@pixilla.com> <4B47C233.1000805@macports.org> <0BF0C0C9-57BA-4F8C-9EF0-A8D9EA8259A7@pixilla.com> <64466FA3-7144-4563-B794-74AE36865006@macports.org> <193C34A0-6789-4D35-B93B-C520E1B4FF8C@pixilla.com> <4C16EBC1-96FA-46C5-AA65-D0C69629DDFC@gmail.com> Message-ID: <04A6C1B6-75C7-4778-8F6C-C4BB51A5009B@pixilla.com> On Jan 8, 2010, at 8:31 PM, Ryan Schmidt wrote: > > On Jan 8, 2010, at 20:36, nox wrote: > >> At the core, portfiles are TCL scripts. And excluding anything >> except ui_msg, any called procedure except ui_msg would be to >> transformed into a no-op. This can't be done at runtime, and we >> can't possibly write a list of those procedures. So your idea is >> unrealisable. > > Maybe not in the form he suggested, but it would certainly be > possible to modify ui_msg so that in addition to printing a message, > it keeps it in an array, and prints them again at the end if in > debug mode. > > But I think we may be trying to solve the wrong problem. MacPorts > 1.9.0 will introduce logging, so I think this makes most of the > reasons one would use debug mode go away. The problem is not > "There's too much information in debug mode and I can't see the > stuff that's relevant to me"; the problem is "We ask users to run in > debug mode." With logging, we no longer need to ask users to run in > debug mode. So do we then really still need to change how messages > are printed? When I'm working updating or creating a new portfile I use -v pretty much all the time because if something fails I want to see what stop me. So I almost always have to much output to see the ui_msg. It's the deps that I find a pain. Trying to look through the whole deps chain to see if there is anything I should do after install is not smooth. Collecting into an array was my original suggestion months back and I think in -v or -d mode could be useful. I don't see how this could be all that difficult to do but things work the way they are so I'm not complaining. I thought if enough other people liked the idea it might return value to put a little time into collecting the ui_msg to print at end. Let's all move along, we have better things to do. // Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Sat Jan 9 02:03:03 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 9 Jan 2010 04:03:03 -0600 Subject: [62487] trunk/dports/python In-Reply-To: <20100109092441.208A43B2E01B@beta.macosforge.org> References: <20100109092441.208A43B2E01B@beta.macosforge.org> Message-ID: <562B96F8-71B4-4CC0-A7E1-62F6CFDB3455@macports.org> On Jan 9, 2010, at 03:24, stromnov at macports.org wrote: > Revision: 62487 > http://trac.macports.org/changeset/62487 > Author: stromnov at macports.org > Date: 2010-01-09 01:24:37 -0800 (Sat, 09 Jan 2010) > Log Message: > ----------- > py26-pyproj: New port (from existing py25-pyproj) That's great, but when you do so, please don't also change the port's whitespace. Whitespace changes should always be made in a separate commit from functional changes. And if you're going to change one port for a given piece of software (e.g. py26-pyproj) you should make the same changes to all other ports for that software (e.g. py25-pyproj) -- having first cleared it with the maintainer, of course. Different ports for the same piece of software should be kept as similar as possible. I should be able to "diff -u $(port file py2{5,6}-pyproj)" and see only the changes necessary to turn the one into the other, not differences on every line due to whitespace. From nox at macports.org Sat Jan 9 11:14:13 2010 From: nox at macports.org (nox) Date: Sat, 9 Jan 2010 20:14:13 +0100 Subject: License option Message-ID: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> I see a lot of ports with license options like "GPLv2/LGPLv2". The "v" and "/" seem ugly to me, especially with licenses like Apache, where we end up with "Apachev2". Shouldn't we write something more beautiful like: license LGPL-2 Apache-2 MIT BSD DWTFYWL-42 Regards, Anthony. From jmr at macports.org Sat Jan 9 11:30:09 2010 From: jmr at macports.org (Joshua Root) Date: Sun, 10 Jan 2010 06:30:09 +1100 Subject: License option In-Reply-To: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> Message-ID: <4B48D941.3040202@macports.org> On 2010-1-10 06:14 , nox wrote: > I see a lot of ports with license options like "GPLv2/LGPLv2". The "v" and "/" seem ugly to me, especially with licenses like Apache, where we end up with "Apachev2". Shouldn't we write something more beautiful like: > > license LGPL-2 Apache-2 MIT BSD DWTFYWL-42 Whether that is more beautiful is no doubt subjective. :-) I think the important thing is to make it easily machine-readable so that an automated binary-building system can know which ports we are allowed to distribute in binary form, while keeping it human readable. Note that no structure is currently imposed on the license field. - Josh From nox at macports.org Sat Jan 9 11:38:36 2010 From: nox at macports.org (nox) Date: Sat, 9 Jan 2010 20:38:36 +0100 Subject: License option In-Reply-To: <4B48D941.3040202@macports.org> References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B48D941.3040202@macports.org> Message-ID: <629AE7BF-B86C-4267-8963-7EE22ABA15E8@macports.org> Well, I have nothing against using "v", but it is not really human-readable when the license name is a word, thus it's less beautiful. And using slashes makes the parsing less straightforward. Le 9 janv. 2010 ? 20:30, Joshua Root a ?crit : > On 2010-1-10 06:14 , nox wrote: >> I see a lot of ports with license options like "GPLv2/LGPLv2". The "v" and "/" seem ugly to me, especially with licenses like Apache, where we end up with "Apachev2". Shouldn't we write something more beautiful like: >> >> license LGPL-2 Apache-2 MIT BSD DWTFYWL-42 > > Whether that is more beautiful is no doubt subjective. :-) > > I think the important thing is to make it easily machine-readable so > that an automated binary-building system can know which ports we are > allowed to distribute in binary form, while keeping it human readable. > > Note that no structure is currently imposed on the license field. > > - Josh From danchr at gmail.com Mon Jan 11 00:29:42 2010 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Mon, 11 Jan 2010 09:29:42 +0100 Subject: License option In-Reply-To: <629AE7BF-B86C-4267-8963-7EE22ABA15E8@macports.org> References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B48D941.3040202@macports.org> <629AE7BF-B86C-4267-8963-7EE22ABA15E8@macports.org> Message-ID: On 9 Jan 2010, at 20:38, nox wrote: > Well, I have nothing against using "v", but it is not really human-readable when the license name is a word, thus it's less beautiful. And using slashes makes the parsing less straightforward. Might I suggest the following syntax? license GPL-2.0 LGPL-2.1 Whatever-3.2.1 As another point, it might be worthwhile to use something like ?Permissive? as a catch-all for BSD, X11, zlib/libpng, MIT and similar licences. In practice, the distinction between them is unlikely to have any practical significance whatsoever? (As long as ?BSD? doesn't imply old-style BSD with an advertising clause, that is.) -- Dan Villiom Podlaski Christiansen danchr at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1943 bytes Desc: not available URL: From sharky at macports.org Mon Jan 11 01:49:02 2010 From: sharky at macports.org (=?iso-8859-1?Q?Jeremy_Lain=E9?=) Date: Mon, 11 Jan 2010 10:49:02 +0100 Subject: Dropping qt4-kde? Message-ID: <5E97E87A-8202-4498-A7A1-B6311918D2D8@macports.org> I am trying to work my way through issues reported against qt4, and one of the things which is making things a bit awkward is the fact that there are too many qt4-* ports. Does anyone use qt4-kde (which is lagging behind qt4-mac) or can it safely be dropped? Cheers, Jeremy From cristiano.fontana at gmail.com Mon Jan 11 04:47:18 2010 From: cristiano.fontana at gmail.com (Cristiano Fontana) Date: Mon, 11 Jan 2010 13:47:18 +0100 Subject: Portfile for iAIDA and CLHEP Message-ID: <66A8DCD5-AE30-4E89-ACE4-9F0F83292066@gmail.com> Hello, this is my first try in writing a portfile. Unfortunately this was an unsuccessful one, so I would like to have some help from some more experienced users. I tried to write a portfile for a library used in High Energy Physics: CLHEP. It seemed pretty straightforward since the installation procedure is the canonical configure; make; make install, but it does not want to compile. Same problem with iAIDA. I attached both the portfiles. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 629 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 789 bytes Desc: not available URL: From raimue at macports.org Mon Jan 11 05:39:10 2010 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 11 Jan 2010 14:39:10 +0100 Subject: Dropping qt4-kde? In-Reply-To: <5E97E87A-8202-4498-A7A1-B6311918D2D8@macports.org> References: <5E97E87A-8202-4498-A7A1-B6311918D2D8@macports.org> Message-ID: <4B4B29FE.20709@macports.org> On 2010-01-11 10:49 , Jeremy Lain? wrote: > I am trying to work my way through issues reported against qt4, and one of the things which is making things a bit awkward is the fact that there are too many qt4-* ports. > > Does anyone use qt4-kde (which is lagging behind qt4-mac) or can it safely be dropped? There is actually no dependent. Only qtscriptgenerator has some code to either use qt4-kde or qt4-mac... Could easily be I think this port was created back then there still existed some problems between qt4-kde and KDE 4. That seems to be resolved, so please let us drop it. Rainer From raimue at macports.org Mon Jan 11 05:50:22 2010 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 11 Jan 2010 14:50:22 +0100 Subject: /opt/local/lib/libgcc_s.1.dylib, binutils, llvm-gcc42 In-Reply-To: <20091217043734.GD28726@ambulatoryclam.net> References: <20091217004322.GC28726@ambulatoryclam.net> <1FA59F8E-E0C2-410B-B54A-DF0B76A1DC90@macports.org> <20091217043734.GD28726@ambulatoryclam.net> Message-ID: <4B4B2C9E.7090705@macports.org> On 2009-12-17 05:37 , Dan Ports wrote: > On Wed, Dec 16, 2009 at 09:04:13PM -0600, Ryan Schmidt wrote: >> My recommendation is to not install llvm-gcc42 until this issue is resolved. If anyone can assist in resolving this issue, it would be appreciated. > > Isn't the solution to both of these problems (libiberty & libgcc_s) just a > matter of adding > --libdir=${prefix}/lib/${name} > --libexecdir=${prefix}/libexec/${name} > --includedir=${prefix}/include/${name} > to configure.args? I agree with Dan. This is also what we do for gcc4* ports to avoid conflicts, so it would be consequent to do the same for llvm-gcc42. Rainer From raimue at macports.org Mon Jan 11 06:10:44 2010 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 11 Jan 2010 15:10:44 +0100 Subject: launch4j port In-Reply-To: References: Message-ID: <4B4B3164.40402@macports.org> On 2009-12-22 19:41 , Panayotis Katsaloulis wrote: > Hello > I have created a new port for launch4j a week ago, but there is no feedback. > The ticket is here > http://trac.macports.org/ticket/22914 > > Could you have a look? Committed in r62576. Thanks for your submission! To file updates in the future, please use the same method and file a ticket in Trac. And at best also mention that it is a maintainer update in the description. Rainer From sharky at macports.org Mon Jan 11 07:34:38 2010 From: sharky at macports.org (=?iso-8859-1?Q?Jeremy_Lain=E9?=) Date: Mon, 11 Jan 2010 16:34:38 +0100 Subject: Dropping qt4-kde? In-Reply-To: <4B4B29FE.20709@macports.org> References: <5E97E87A-8202-4498-A7A1-B6311918D2D8@macports.org> <4B4B29FE.20709@macports.org> Message-ID: <1DD7709C-73FF-4BBB-93C2-F71F3F4FF707@macports.org> On Jan 11, 2010, at 2:39 PM, Rainer M?ller wrote: > On 2010-01-11 10:49 , Jeremy Lain? wrote: >> I am trying to work my way through issues reported against qt4, and one of the things which is making things a bit awkward is the fact that there are too many qt4-* ports. >> >> Does anyone use qt4-kde (which is lagging behind qt4-mac) or can it safely be dropped? > > There is actually no dependent. Only qtscriptgenerator has some code to > either use qt4-kde or qt4-mac... Could easily be > > I think this port was created back then there still existed some > problems between qt4-kde and KDE 4. That seems to be resolved, so please > let us drop it. OK, say goodbye to qt4-kde! I have simplified the qtscriptgenerator Portfile accordingly. Jeremy From cristiano.fontana at gmail.com Mon Jan 11 10:50:06 2010 From: cristiano.fontana at gmail.com (Cristiano Fontana) Date: Mon, 11 Jan 2010 19:50:06 +0100 Subject: Portfile for iAIDA and CLHEP In-Reply-To: <9bfc77171001110736m570d6df8g47946cd16c6c93e4@mail.gmail.com> References: <66A8DCD5-AE30-4E89-ACE4-9F0F83292066@gmail.com> <9bfc77171001110736m570d6df8g47946cd16c6c93e4@mail.gmail.com> Message-ID: <9CF65A0E-F815-470A-8DEB-A80D1C4D429C@gmail.com> Thank you! iAIDA seems to work now so I submitted a ticket for proposing the portfile: https://trac.macports.org/ticket/23238 Now I must work on CLHEP... Il giorno 11/gen/2010, alle ore 16.36, Andrew Stromnov ha scritto: > Hi! > > iAIDA compiles perfectly, but installed into the wrong place: > ${prefix} instead of ${destroot}${prefix}. > > Try to adjust Makefile.in files (./Makefile.in, ./src/Makefile.in and > others) by reinplacing '@PREFIX_DIR@' with ${destroot}${prefix}. > > So, native build system of iAIDA installs all data into > ${destroot}${prefix}, and then macports install system maps > ${destroot}${prefix} to ${prefix}. > > Note: after installation aida-config script MUST point to ${prefix}, > not ${destroot}${prefix} > > On Mon, Jan 11, 2010 at 15:47, Cristiano Fontana > wrote: >> Hello, >> >> this is my first try in writing a portfile. Unfortunately this was an unsuccessful one, so I would like to have some help from some more experienced users. >> I tried to write a portfile for a library used in High Energy Physics: CLHEP. It seemed pretty straightforward since the installation procedure is the canonical configure; make; make install, but it does not want to compile. >> Same problem with iAIDA. >> I attached both the portfiles. >> >> Thanks! >> >> _______________________________________________ >> 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 Jan 11 12:30:07 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 11 Jan 2010 12:30:07 -0800 Subject: port_cutleaves Message-ID: <1D4FAFD8-9DEC-4BAD-A618-31C1207B17D9@pixilla.com> Does port_cutleaves ignore ports I installed as opposed to ports that were installed by port to satisfy deps? Does the port registry keep track of ports that were installed via the port install/upgrade command vs satisfying deps? // Brad From jeremy at lavergne.gotdns.org Mon Jan 11 12:35:03 2010 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 11 Jan 2010 15:35:03 -0500 Subject: port_cutleaves In-Reply-To: <1D4FAFD8-9DEC-4BAD-A618-31C1207B17D9@pixilla.com> References: <1D4FAFD8-9DEC-4BAD-A618-31C1207B17D9@pixilla.com> Message-ID: <315826D9-3BEC-4967-909E-596F7F3DB46F@lavergne.gotdns.org> > Does port_cutleaves ignore ports I installed as opposed to ports that were installed by port to satisfy deps? No. port_cutleaves merely goes through the dependency tree finding leaves. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From mdcrawford at gmail.com Mon Jan 11 14:08:49 2010 From: mdcrawford at gmail.com (Michael Crawford) Date: Mon, 11 Jan 2010 14:08:49 -0800 Subject: License option In-Reply-To: References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B48D941.3040202@macports.org> <629AE7BF-B86C-4267-8963-7EE22ABA15E8@macports.org> Message-ID: Y'all should have a look at the RDF (XML Resource Description Framework) that Creative Commons uses to mark CC-licensed work. You can get examples by selecting a license at http://creativecommons.org/ or view the source of my page here: http://www.geometricvisions.com/music/manifesto/ Note that the DOCTYPE of that page is XHTML+RDFa, not just XHTML: Hope That Helps. Mike -- Michael David Crawford mdcrawford at gmail dot com GoingWare's Bag of Programming Tricks http://www.goingware.com/tips/ From brad at pixilla.com Mon Jan 11 12:38:10 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 11 Jan 2010 12:38:10 -0800 Subject: cleaning up Message-ID: When an install/upgrade of forced with -f port renames the existing file appending and extension .mp_, correct? Is a timestamp or something else? Is there a port command for cleaning/deleting these files? I'm looking to delete all these files but I would want to stay in the macports directories and not delete anything that may have installed outside macports in error. // Brad From jeremy at lavergne.gotdns.org Mon Jan 11 14:28:18 2010 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 11 Jan 2010 17:28:18 -0500 Subject: cleaning up In-Reply-To: References: Message-ID: > When an install/upgrade of forced with -f port renames the existing file appending and extension .mp_, correct? Yup. > Is a timestamp or something else? Yup. > Is there a port command for cleaning/deleting these files? Nope, try: find $prefix -name *.mp -exec rm -rf {} \; -------------- 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 Mon Jan 11 15:40:25 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 11 Jan 2010 15:40:25 -0800 Subject: cleaning up In-Reply-To: References: Message-ID: On Jan 11, 2010, at 2:28 PM, Jeremy Lavergne wrote: >> When an install/upgrade of forced with -f port renames the existing >> file appending and extension .mp_, correct? > > Yup. > >> Is a timestamp or something else? > > Yup. > >> Is there a port command for cleaning/deleting these files? > > Nope, try: > find $prefix -name *.mp -exec rm -rf {} \; Thanks, this works. Does this look safe? find -E $prefix -regex .*.mp_[0-9]* -exec rm -f {} \; I'd rather not remove directories so I replace rm -rf with rm -f. The thing I don't like about this approach is what if I have a database named mp_somedb or mp_somedb.mp_sometable in /opt/local/var/ db/mysql5/? To be safer yet is the timestamp always x digits long? I'd rather use [0-9]{10}. I don't really think there is any safe way to do this. I'd like to see port keep track of these renames in a registry. I would really need to move all my data (apache, dovecot, postfix, mysql ) outside /opt/local to feel safe with a "find . *.mp* rm" approach. // Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at lavergne.gotdns.org Mon Jan 11 15:55:49 2010 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 11 Jan 2010 18:55:49 -0500 Subject: cleaning up In-Reply-To: References: Message-ID: <6D206160-3DDE-4AAD-B541-B67D786848E1@lavergne.gotdns.org> > find -E $prefix -regex .*.mp_[0-9]* -exec rm -f {} \; No worse than what I had suggested, but feels like it has a lot more overhead for no reason. > I'd rather not remove directories so I replace rm -rf with rm -f. Why not avoid directories all together and use -type f in find? > The thing I don't like about this approach is what if I have a database named mp_somedb or mp_somedb.mp_sometable in /opt/local/var/db/mysql5/? > > To be safer yet is the timestamp always x digits long? I'd rather use [0-9]{10}. Likely they are all the same size. > I don't really think there is any safe way to do this. I'd like to see port keep track of these renames in a registry. Well, the best way to be clean up anytime you do a force activate. Having a naming scheme overlap isn't exactly MacPorts' fault. You could name your db /opt/local/bin/port for we know. > I would really need to move all my data (apache, dovecot, postfix, mysql ) outside /opt/local to feel safe with a "find . *.mp* rm" approach. Don't name anything with mp in it? Backup? -------------- 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 Mon Jan 11 16:22:00 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 11 Jan 2010 16:22:00 -0800 Subject: cleaning up In-Reply-To: <6D206160-3DDE-4AAD-B541-B67D786848E1@lavergne.gotdns.org> References: <6D206160-3DDE-4AAD-B541-B67D786848E1@lavergne.gotdns.org> Message-ID: <94B1499E-F557-4168-AE6C-FFCAF4232280@pixilla.com> On Jan 11, 2010, at 3:55 PM, Jeremy Lavergne wrote: >> I'd rather not remove directories so I replace rm -rf with rm -f. > > Why not avoid directories all together and use -type f in find? Much better. That's what I ended up with. >> The thing I don't like about this approach is what if I have a >> database named mp_somedb or mp_somedb.mp_sometable in /opt/local/ >> var/db/mysql5/? >> >> To be safer yet is the timestamp always x digits long? I'd rather >> use [0-9]{10}. > > Likely they are all the same size. > >> I don't really think there is any safe way to do this. I'd like to >> see port keep track of these renames in a registry. > > Well, the best way to be clean up anytime you do a force activate. > Having a naming scheme overlap isn't exactly MacPorts' fault. You > could name your db /opt/local/bin/port for we know. True, it's not MacPorts' fault. Nor is it my fault. It's not practical to safely avoid .mp for the beginnings of all things. Users can create imap mail boxes and name them what they like. I just want to safely remove a slug of files that MacPorts put on my system and then forgot about. Those files are there because at times it's been the only way to get things installed/upgraded using MacPorts. I'm happy that MacPorts didn't just clobber them but at some point I think I want these removed from places like $prefix/bin/*.mp*. I'm just looking for an easy and safe way to do this and find -name *.mp* rm scares me. It's easy but not safe. >> I would really need to move all my data (apache, dovecot, postfix, >> mysql ) outside /opt/local to feel safe with a "find . *.mp* rm" >> approach. > > Don't name anything with mp in it? Backup? Restoring from a backup is a terrible solution. I make nightly backups of my databases but loosing a days worth of data will make me very unpopular. Likewise losing all the emails in an imap mailbox would make me equally unpopular. I think for me it's best to just move user data outside /opt/local. I already moved it all to a subdir of /opt/local/ var I should have just moved it outside /opt/local altogether and I wouldn't be worried about find $prefix -exec rm commands. // Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at lavergne.gotdns.org Mon Jan 11 16:30:50 2010 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 11 Jan 2010 19:30:50 -0500 Subject: cleaning up In-Reply-To: <94B1499E-F557-4168-AE6C-FFCAF4232280@pixilla.com> References: <6D206160-3DDE-4AAD-B541-B67D786848E1@lavergne.gotdns.org> <94B1499E-F557-4168-AE6C-FFCAF4232280@pixilla.com> Message-ID: <34EA7C56-55EE-4FB8-A3B7-B9C8D126E191@lavergne.gotdns.org> > Restoring from a backup is a terrible solution. I make nightly backups of my databases but loosing a days worth of data will make me very unpopular. > Likewise losing all the emails in an imap mailbox would make me equally unpopular. I think for me it's best to just move user data outside /opt/local. I already moved it all to a subdir of /opt/local/var I should have just moved it outside /opt/local altogether and I wouldn't be worried about find $prefix -exec rm commands. If it's all in $prefix/var, just run a find command for bin, etc, include, lib, and share. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jmr at macports.org Mon Jan 11 16:50:16 2010 From: jmr at macports.org (Joshua Root) Date: Tue, 12 Jan 2010 11:50:16 +1100 Subject: cleaning up In-Reply-To: References: Message-ID: <4B4BC748.9040406@macports.org> On 2010-1-12 10:40 , Bradley Giesbrecht wrote: > > I'd like to see > port keep track of these renames in a registry. It does if the renamed files belong to a port. - Josh From brad at pixilla.com Mon Jan 11 17:15:39 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 11 Jan 2010 17:15:39 -0800 Subject: cleaning up In-Reply-To: <34EA7C56-55EE-4FB8-A3B7-B9C8D126E191@lavergne.gotdns.org> References: <6D206160-3DDE-4AAD-B541-B67D786848E1@lavergne.gotdns.org> <94B1499E-F557-4168-AE6C-FFCAF4232280@pixilla.com> <34EA7C56-55EE-4FB8-A3B7-B9C8D126E191@lavergne.gotdns.org> Message-ID: <79002738-0989-45B5-8CEF-2CAD443F50A9@pixilla.com> On Jan 11, 2010, at 4:30 PM, Jeremy Lavergne wrote: >> Restoring from a backup is a terrible solution. I make nightly >> backups of my databases but loosing a days worth of data will make >> me very unpopular. >> Likewise losing all the emails in an imap mailbox would make me >> equally unpopular. I think for me it's best to just move user data >> outside /opt/local. I already moved it all to a subdir of /opt/ >> local/var I should have just moved it outside /opt/local altogether >> and I wouldn't be worried about find $prefix -exec rm commands. > > If it's all in $prefix/var, just run a find command for bin, etc, > include, lib, and share. Good idea. I couldn't manage to get find -path '/opt/local/var' -prune to work but ! seems to work. sudo find /opt/local \( ! -path "/opt/local/var/*" -a ! -path "/opt/ local/apache2/*" -a ! -path "/opt/local/www/*" \) -name *.mp_* I think these are two other directories that some of the ports may park user files like some of the web frameworks that allow user uploads. // brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdcrawford at gmail.com Mon Jan 11 17:55:53 2010 From: mdcrawford at gmail.com (Michael Crawford) Date: Mon, 11 Jan 2010 17:55:53 -0800 Subject: cleaning up In-Reply-To: <79002738-0989-45B5-8CEF-2CAD443F50A9@pixilla.com> References: <6D206160-3DDE-4AAD-B541-B67D786848E1@lavergne.gotdns.org> <94B1499E-F557-4168-AE6C-FFCAF4232280@pixilla.com> <34EA7C56-55EE-4FB8-A3B7-B9C8D126E191@lavergne.gotdns.org> <79002738-0989-45B5-8CEF-2CAD443F50A9@pixilla.com> Message-ID: If you're worried about losing your payload data, rather than having find delete all the renamed files automatically, have it generate a list of the renamed files that you redirect into a text file. Examine that file by eye, manually remove any lines containing files that you don't want deleted, then delete the files named in the list by using the backquote shell construction: $ find BLAH > deleteme.txt (edit deleteme.txt, remove files that aren't to be deleted) $ rm `cat deleteme.txt` note that those are backquotes and not apostrophes. What backquotes do is run a command in a subshell, with its output being placed on the command line. If there are newlines in that output, they are replaced with spaces, so multi-line output gets put on just one line. I'll send you my bill in the mail. :-D Mike -- Michael David Crawford mdcrawford at gmail dot com GoingWare's Bag of Programming Tricks http://www.goingware.com/tips/ From brad at pixilla.com Mon Jan 11 19:04:01 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 11 Jan 2010 19:04:01 -0800 Subject: cleaning up In-Reply-To: References: <6D206160-3DDE-4AAD-B541-B67D786848E1@lavergne.gotdns.org> <94B1499E-F557-4168-AE6C-FFCAF4232280@pixilla.com> <34EA7C56-55EE-4FB8-A3B7-B9C8D126E191@lavergne.gotdns.org> <79002738-0989-45B5-8CEF-2CAD443F50A9@pixilla.com> Message-ID: <1B2EA9E3-6B80-42AA-A834-E9344D0E34A0@pixilla.com> On Jan 11, 2010, at 5:55 PM, Michael Crawford wrote: > If you're worried about losing your payload data, rather than having > find delete all the renamed files automatically, have it generate a > list of the renamed files that you redirect into a text file. Examine > that file by eye, manually remove any lines containing files that you > don't want deleted, then delete the files named in the list by using > the backquote shell construction: > > $ find BLAH > deleteme.txt > > (edit deleteme.txt, remove files that aren't to be deleted) > > $ rm `cat deleteme.txt` That is an easy and safe approach and the list is not all that long this satisfies my needs. In the future I'll also use mv instead of rm incase things go really wrong. If things are ok after a couple weeks I'll rm them. Thank you, Brad From talklists at newgeo.com Mon Jan 11 19:06:00 2010 From: talklists at newgeo.com (Scott Haneda) Date: Mon, 11 Jan 2010 19:06:00 -0800 Subject: cleaning up In-Reply-To: <94B1499E-F557-4168-AE6C-FFCAF4232280@pixilla.com> References: <6D206160-3DDE-4AAD-B541-B67D786848E1@lavergne.gotdns.org> <94B1499E-F557-4168-AE6C-FFCAF4232280@pixilla.com> Message-ID: <935E41A1-3BAA-4AE0-860C-CFC1DC03BF56@newgeo.com> You can also exclude from the find command I believe, so for example, to find all files that are dot files, but leave .htaccess files alone, not that this would be anywhere near a safe idea, but it shows the process: find . -type f \( -iname ".*" ! -iname ".htaccess" \) -- Scott * If you contact me off list replace talklists@ with scott@ * On Jan 11, 2010, at 4:22 PM, Bradley Giesbrecht wrote: > True, it's not MacPorts' fault. Nor is it my fault. It's not practical to safely avoid .mp for the beginnings of all things. Users can create imap mail boxes and name them what they like. > > I just want to safely remove a slug of files that MacPorts put on my system and then forgot about. Those files are there because at times it's been the only way to get things installed/upgraded using MacPorts. I'm happy that MacPorts didn't just clobber them but at some point I think I want these removed from places like $prefix/bin/*.mp*. I'm just looking for an easy and safe way to do this and find -name *.mp* rm scares me. It's easy but not safe. From talklists at newgeo.com Mon Jan 11 19:20:44 2010 From: talklists at newgeo.com (Scott Haneda) Date: Mon, 11 Jan 2010 19:20:44 -0800 Subject: cleaning up In-Reply-To: <1B2EA9E3-6B80-42AA-A834-E9344D0E34A0@pixilla.com> References: <6D206160-3DDE-4AAD-B541-B67D786848E1@lavergne.gotdns.org> <94B1499E-F557-4168-AE6C-FFCAF4232280@pixilla.com> <34EA7C56-55EE-4FB8-A3B7-B9C8D126E191@lavergne.gotdns.org> <79002738-0989-45B5-8CEF-2CAD443F50A9@pixilla.com> <1B2EA9E3-6B80-42AA-A834-E9344D0E34A0@pixilla.com> Message-ID: <9F6A3AFB-3667-409A-8CA0-1EBBBAAD9B30@newgeo.com> On Jan 11, 2010, at 7:04 PM, Bradley Giesbrecht wrote: > On Jan 11, 2010, at 5:55 PM, Michael Crawford wrote: > >> If you're worried about losing your payload data, rather than having >> find delete all the renamed files automatically, have it generate a >> list of the renamed files that you redirect into a text file. Examine >> that file by eye, manually remove any lines containing files that you >> don't want deleted, then delete the files named in the list by using >> the backquote shell construction: >> >> $ find BLAH > deleteme.txt >> >> (edit deleteme.txt, remove files that aren't to be deleted) >> >> $ rm `cat deleteme.txt` > > That is an easy and safe approach and the list is not all that long this satisfies my needs. > > In the future I'll also use mv instead of rm incase things go really wrong. If things are ok after a couple weeks I'll rm them. Be careful with mv, it has caused me great pain in the past. mv can overwrite a file with no prompt if you tell it to do so, which I did. On a server, there tends to be a lot of files with the same names, so I ended up with the last file mv'd, and not the hundred of files I thought I was going to end up with. Just thought I would mention it, it bit me once, which is usually all it takes before I learn my lesson. -- Scott * If you contact me off list replace talklists@ with scott@ * From mdcrawford at gmail.com Mon Jan 11 20:28:36 2010 From: mdcrawford at gmail.com (Michael Crawford) Date: Mon, 11 Jan 2010 20:28:36 -0800 Subject: Updating MacPorts with Quartz GnuCash Message-ID: A while back I followed the instructions given in this list to build GnuCash as a Mac OS X-Native Quartz application rather than an X11 application. This required configuring the build a certain way and then applying a patch that fixed a build problem that occured with the unpatched MacPorts source. I'd like to update my MacPorts installation to the latest versions of everything. Do I need to be concerned about this clobbering my Quartz GnuCash, or about those Quartz build settings interfering with the build of the latest MacPorts code? I have come to depend on GnuCash heavily for managing both my business and personal finances, so I don't want to risk screwing it up. An alternative is that there is now a Drag-n-Drop installer of OS X GnuCash available at http://www.gnucash.org/ Would I be better off to use that rather than the MacPorts version? If so, then I'll uninstall the GnuCash I have now before I update MacPorts. Thanks for your help! Mike -- Michael David Crawford mdcrawford at gmail dot com GoingWare's Bag of Programming Tricks http://www.goingware.com/tips/ From brad at pixilla.com Mon Jan 11 20:40:27 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 11 Jan 2010 20:40:27 -0800 Subject: Updating MacPorts with Quartz GnuCash In-Reply-To: References: Message-ID: <3F0EDCA5-9AA9-450A-8FA3-9711BFC9F5CC@pixilla.com> On Jan 11, 2010, at 8:28 PM, Michael Crawford wrote: > A while back I followed the instructions given in this list to build > GnuCash as a Mac OS X-Native Quartz application rather than an X11 > application. This required configuring the build a certain way and > then applying a patch that fixed a build problem that occured with the > unpatched MacPorts source. > > I'd like to update my MacPorts installation to the latest versions of > everything. Do I need to be concerned about this clobbering my Quartz > GnuCash, or about those Quartz build settings interfering with the > build of > the latest MacPorts code? > > I have come to depend on GnuCash heavily for managing both my business > and personal finances, so I don't want to risk screwing it up. > > An alternative is that there is now a Drag-n-Drop installer of > OS X GnuCash available at http://www.gnucash.org/ Would I be better > off to use that rather than the MacPorts version? If so, then I'll > uninstall the GnuCash I have now before I update MacPorts. Did you create a private repository for your macports/guncash portfile? If so then I doubt you'll have any issues unless something gnucash depends on gets update to a version that gnucash can't work with. Others may know but I don't so I'll ask. What Quartz build settings did you alter? // Brad From cristiano.fontana at gmail.com Tue Jan 12 03:43:18 2010 From: cristiano.fontana at gmail.com (Cristiano Fontana) Date: Tue, 12 Jan 2010 12:43:18 +0100 Subject: Portfile for iAIDA and CLHEP In-Reply-To: <9bfc77171001110736m570d6df8g47946cd16c6c93e4@mail.gmail.com> References: <66A8DCD5-AE30-4E89-ACE4-9F0F83292066@gmail.com> <9bfc77171001110736m570d6df8g47946cd16c6c93e4@mail.gmail.com> Message-ID: I found the problem in CLHEP! The compiler set in the configure phase is g++-4.2 and the configure did not recognized it. So I patched all the configures and now it seems to work. I am putting the portfile to the trac page. Il giorno 11/gen/2010, alle ore 16.36, Andrew Stromnov ha scritto: > Hi! > > iAIDA compiles perfectly, but installed into the wrong place: > ${prefix} instead of ${destroot}${prefix}. > > Try to adjust Makefile.in files (./Makefile.in, ./src/Makefile.in and > others) by reinplacing '@PREFIX_DIR@' with ${destroot}${prefix}. > > So, native build system of iAIDA installs all data into > ${destroot}${prefix}, and then macports install system maps > ${destroot}${prefix} to ${prefix}. > > Note: after installation aida-config script MUST point to ${prefix}, > not ${destroot}${prefix} > > On Mon, Jan 11, 2010 at 15:47, Cristiano Fontana > wrote: >> Hello, >> >> this is my first try in writing a portfile. Unfortunately this was an unsuccessful one, so I would like to have some help from some more experienced users. >> I tried to write a portfile for a library used in High Energy Physics: CLHEP. It seemed pretty straightforward since the installation procedure is the canonical configure; make; make install, but it does not want to compile. >> Same problem with iAIDA. >> I attached both the portfiles. >> >> Thanks! >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> >> From sharky at macports.org Tue Jan 12 06:42:46 2010 From: sharky at macports.org (=?iso-8859-1?Q?Jeremy_Lain=E9?=) Date: Tue, 12 Jan 2010 15:42:46 +0100 Subject: Dropping qt4-kde? In-Reply-To: <1DD7709C-73FF-4BBB-93C2-F71F3F4FF707@macports.org> References: <5E97E87A-8202-4498-A7A1-B6311918D2D8@macports.org> <4B4B29FE.20709@macports.org> <1DD7709C-73FF-4BBB-93C2-F71F3F4FF707@macports.org> Message-ID: <23263D02-7655-46C0-A0BB-182FE6387432@macports.org> In the spirit of trying to keep qt4-mac as simple as possible to reduce the maintenance load, would anybody oppose: - making cocoa the default and thus dropping the "cocoa" variant - dropping the "noframework" variant The only downside I can see is that we will lose support for OS X 10.4, but to my knowledge 10.4 is no longer part of the supported versions. Jeremy From ryandesign at macports.org Tue Jan 12 07:02:21 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 12 Jan 2010 16:02:21 +0100 Subject: Dropping qt4-kde? In-Reply-To: <1DD7709C-73FF-4BBB-93C2-F71F3F4FF707@macports.org> References: <5E97E87A-8202-4498-A7A1-B6311918D2D8@macports.org> <4B4B29FE.20709@macports.org> <1DD7709C-73FF-4BBB-93C2-F71F3F4FF707@macports.org> Message-ID: <20100112160221.118078dbj2vw86ko@webmail.df.eu> Quoting Jeremy Lain?: > OK, say goodbye to qt4-kde! It would be better to keep a stub qt4-kde port around, with the version upgraded to 4.6.0, with a pre-configure phase explaining that qt4-mac should be used instead, and marked as "replaced_by qt4-mac" so that anybody who still has the port installed will be auto-upgraded to qt4-mac and won't be left with this old port installed. See examples in ports like php5-zlib and pureftpd. The stub port can be removed after a reasonable amount of time (my intention is to remove my stub ports after 1 year). From ryandesign at macports.org Tue Jan 12 07:06:45 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 12 Jan 2010 16:06:45 +0100 Subject: Dropping qt4-kde? In-Reply-To: <23263D02-7655-46C0-A0BB-182FE6387432@macports.org> References: <5E97E87A-8202-4498-A7A1-B6311918D2D8@macports.org> <4B4B29FE.20709@macports.org> <1DD7709C-73FF-4BBB-93C2-F71F3F4FF707@macports.org> <23263D02-7655-46C0-A0BB-182FE6387432@macports.org> Message-ID: <20100112160645.214813by9i6aw16o@webmail.df.eu> Quoting Jeremy Lain? : > In the spirit of trying to keep qt4-mac as simple as possible to > reduce the maintenance load, would anybody oppose: > > - making cocoa the default and thus dropping the "cocoa" variant > - dropping the "noframework" variant > > The only downside I can see is that we will lose support for OS X > 10.4, but to my knowledge 10.4 is no longer part of the supported > versions. We still provide MacPorts DMGs for 10.4 and I would prefer not to prevent 10.4 users from having all the ports that depend on qt4-mac. You're welcome to make +cocoa the default variant for 10.5 and up (instead of on 10.6 only as the port currently does), assuming adding +cocoa has no negative side effects for 10.5 and up. Or, you can remove the cocoa variant and integrate its functionality for 10.5 and up in other ways, for example by putting -cocoa in the global configure.args and adding a "platform darwin 8" section that removes it again. Such a change should be accompanied by a revbump since this will affect how the port builds on 10.5. From ryandesign at macports.org Tue Jan 12 07:32:10 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 12 Jan 2010 16:32:10 +0100 Subject: cleaning up In-Reply-To: <6D206160-3DDE-4AAD-B541-B67D786848E1@lavergne.gotdns.org> References: <6D206160-3DDE-4AAD-B541-B67D786848E1@lavergne.gotdns.org> Message-ID: <20100112163210.404393htf8qpyj22@webmail.df.eu> Quoting Jeremy Lavergne: >> To be safer yet is the timestamp always x digits long? I'd rather >> use [0-9]{10}. > > Likely they are all the same size. It's a standard UNIX timestamp: the number of seconds since the epoch of UNIX time: 01 Jan 1970 00:00:00 UTC. The first ten-digit timestamp (1000000000) occurred 09 Sep 2001 01:46:40 UTC, and the last will be the end of UNIX time on 19 Jan 2038 03:14:07 UTC (since the timestamp is a signed 32-bit integer and thus has a maximum value of 2^31 - 1 or 2147483647). http://en.wikipedia.org/wiki/Year_2038_problem From ryandesign at macports.org Tue Jan 12 07:33:53 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 12 Jan 2010 16:33:53 +0100 Subject: cleaning up In-Reply-To: <4B4BC748.9040406@macports.org> References: <4B4BC748.9040406@macports.org> Message-ID: <20100112163353.11907fckjuuut8kk@webmail.df.eu> Quoting Joshua Root: > On 2010-1-12 10:40 , Bradley Giesbrecht wrote: > >> I'd like to see >> port keep track of these renames in a registry. > > It does if the renamed files belong to a port. It has been my experience that using "sudo port -f activate" will move any conflicting files out of the way, renaming them with a .mp_${timestamp} suffix, and that these renamed files are not registered to any port nor tracked anywhere, and are left for the user to remove manually. From danchr at gmail.com Tue Jan 12 08:57:12 2010 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Tue, 12 Jan 2010 17:57:12 +0100 Subject: cleaning up In-Reply-To: <79002738-0989-45B5-8CEF-2CAD443F50A9@pixilla.com> References: <6D206160-3DDE-4AAD-B541-B67D786848E1@lavergne.gotdns.org> <94B1499E-F557-4168-AE6C-FFCAF4232280@pixilla.com> <34EA7C56-55EE-4FB8-A3B7-B9C8D126E191@lavergne.gotdns.org> <79002738-0989-45B5-8CEF-2CAD443F50A9@pixilla.com> Message-ID: <1F4FFEC8-29D6-4C63-A631-BCA010A77EC2@gmail.com> On 12 Jan 2010, at 02:15, Bradley Giesbrecht wrote: > > On Jan 11, 2010, at 4:30 PM, Jeremy Lavergne wrote: > >>> Restoring from a backup is a terrible solution. I make nightly backups of my databases but loosing a days worth of data will make me very unpopular. >>> Likewise losing all the emails in an imap mailbox would make me equally unpopular. I think for me it's best to just move user data outside /opt/local. I already moved it all to a subdir of /opt/local/var I should have just moved it outside /opt/local altogether and I wouldn't be worried about find $prefix -exec rm commands. >> >> If it's all in $prefix/var, just run a find command for bin, etc, include, lib, and share. > > Good idea. > > I couldn't manage to get find -path '/opt/local/var' -prune to work but ! seems to work. > > sudo find /opt/local \( ! -path "/opt/local/var/*" -a ! -path "/opt/local/apache2/*" -a ! -path "/opt/local/www/*" \) -name *.mp_* > > I think these are two other directories that some of the ports may park user files like some of the web frameworks that allow user uploads. After a bit of tweaking, I'd suggest: sudo find /opt/local -regex '.*/[^/]\{1,\}\.mp_[[:digit:]]\{9,10\}' -print -delete If you don't have any very old files, or files which were created when the clock was reset: sudo find /opt/local -regex '.*/[^/]\{1,\}\.mp_[[:digit:]]\{10\}' -print -delete Or, if you want to ignore anything in a ?var? directory: sudo find /opt/local \( -not -path '*/var/*' \) -regex '.*/[^/]\{1,\}\.mp_[[:digit:]]\{9,10\}' -print -delete The first one should be quite safe; user files are unlikely to end with ?.mp_? followed by 9?10 digits ;-) -- Dan Villiom Podlaski Christiansen danchr at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1943 bytes Desc: not available URL: From brad at pixilla.com Tue Jan 12 09:12:34 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 12 Jan 2010 09:12:34 -0800 Subject: cleaning up In-Reply-To: <1F4FFEC8-29D6-4C63-A631-BCA010A77EC2@gmail.com> References: <6D206160-3DDE-4AAD-B541-B67D786848E1@lavergne.gotdns.org> <94B1499E-F557-4168-AE6C-FFCAF4232280@pixilla.com> <34EA7C56-55EE-4FB8-A3B7-B9C8D126E191@lavergne.gotdns.org> <79002738-0989-45B5-8CEF-2CAD443F50A9@pixilla.com> <1F4FFEC8-29D6-4C63-A631-BCA010A77EC2@gmail.com> Message-ID: On Jan 12, 2010, at 8:57 AM, Dan Villiom Podlaski Christiansen wrote: > On 12 Jan 2010, at 02:15, Bradley Giesbrecht wrote: > >> >> On Jan 11, 2010, at 4:30 PM, Jeremy Lavergne wrote: >> >>>> Restoring from a backup is a terrible solution. I make nightly >>>> backups of my databases but loosing a days worth of data will >>>> make me very unpopular. >>>> Likewise losing all the emails in an imap mailbox would make me >>>> equally unpopular. I think for me it's best to just move user >>>> data outside /opt/local. I already moved it all to a subdir of / >>>> opt/local/var I should have just moved it outside /opt/local >>>> altogether and I wouldn't be worried about find $prefix -exec rm >>>> commands. >>> >>> If it's all in $prefix/var, just run a find command for bin, etc, >>> include, lib, and share. >> >> Good idea. >> >> I couldn't manage to get find -path '/opt/local/var' -prune to work >> but ! seems to work. >> >> sudo find /opt/local \( ! -path "/opt/local/var/*" -a ! -path "/opt/ >> local/apache2/*" -a ! -path "/opt/local/www/*" \) -name *.mp_* >> >> I think these are two other directories that some of the ports may >> park user files like some of the web frameworks that allow user >> uploads. > > After a bit of tweaking, I'd suggest: > > sudo find /opt/local -regex '.*/[^/]\{1,\}\.mp_[[:digit:]]\{9,10\}' - > print -delete > > If you don't have any very old files, or files which were created > when the clock was reset: > > sudo find /opt/local -regex '.*/[^/]\{1,\}\.mp_[[:digit:]]\{10\}' - > print -delete > > Or, if you want to ignore anything in a ?var? directory: > > sudo find /opt/local \( -not -path '*/var/*' \) -regex '.*/[^/] > \{1,\}\.mp_[[:digit:]]\{9,10\}' -print -delete > > The first one should be quite safe; user files are unlikely to end > with ?.mp_? followed by 9?10 digits ;-) I agree and this is safer. How about: sudo find /opt/local \( -not -path '*/var/*' \) -regex '.*/[^/]\{1,\} \.mp_[[:digit:]]\{9,10\}\$' -print Will this limit it further to only files that end with 9,10 digits? If I leave off the -delete then I can first print the list or redirect it to a file and use that file to move the files out of the way and after a time delete them. On systems with many users real/virtual and different forms methods for write access db/ftp/http/mail I need this to be as safe as reasonably possible. I don't mind a little litter but having that litter in my env path was annoying. Thank you everyone for your contributions, Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmr at macports.org Tue Jan 12 11:36:16 2010 From: jmr at macports.org (Joshua Root) Date: Wed, 13 Jan 2010 06:36:16 +1100 Subject: cleaning up In-Reply-To: <20100112163353.11907fckjuuut8kk@webmail.df.eu> References: <4B4BC748.9040406@macports.org> <20100112163353.11907fckjuuut8kk@webmail.df.eu> Message-ID: <4B4CCF30.1030609@macports.org> On 2010-1-13 02:33 , Ryan Schmidt wrote: > Quoting Joshua Root: > >> On 2010-1-12 10:40 , Bradley Giesbrecht wrote: >> >>> I'd like to see >>> port keep track of these renames in a registry. >> >> It does if the renamed files belong to a port. > > It has been my experience that using "sudo port -f activate" will move > any conflicting files out of the way, renaming them with a > .mp_${timestamp} suffix, and that these renamed files are not registered > to any port nor tracked anywhere, and are left for the user to remove > manually. - Josh From jmr at macports.org Tue Jan 12 11:49:42 2010 From: jmr at macports.org (Joshua Root) Date: Wed, 13 Jan 2010 06:49:42 +1100 Subject: cleaning up In-Reply-To: <4B4CCF30.1030609@macports.org> References: <4B4BC748.9040406@macports.org> <20100112163353.11907fckjuuut8kk@webmail.df.eu> <4B4CCF30.1030609@macports.org> Message-ID: <4B4CD256.2030009@macports.org> On 2010-1-13 06:36 , Joshua Root wrote: > On 2010-1-13 02:33 , Ryan Schmidt wrote: >> Quoting Joshua Root: >> >>> On 2010-1-12 10:40 , Bradley Giesbrecht wrote: >>> >>>> I'd like to see >>>> port keep track of these renames in a registry. >>> >>> It does if the renamed files belong to a port. >> >> It has been my experience that using "sudo port -f activate" will move >> any conflicting files out of the way, renaming them with a >> .mp_${timestamp} suffix, and that these renamed files are not registered >> to any port nor tracked anywhere, and are left for the user to remove >> manually. > > But you're right, the check there is incorrect. Fixed in r62631. Apparently it's been broken since r7620 and nobody noticed... - Josh From dports at ambulatoryclam.net Tue Jan 12 11:56:42 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Tue, 12 Jan 2010 11:56:42 -0800 Subject: Updating MacPorts with Quartz GnuCash In-Reply-To: References: Message-ID: <20100112195642.GD76618@ambulatoryclam.net> On Mon, Jan 11, 2010 at 08:28:36PM -0800, Michael Crawford wrote: > A while back I followed the instructions given in this list to build > GnuCash as a Mac OS X-Native Quartz application rather than an X11 > application. This required configuring the build a certain way and > then applying a patch that fixed a build problem that occured with the > unpatched MacPorts source. I have no insight into your actual question, but -- as someone else who uses gnucash pretty heavily (in my case, under X) -- I'd certainly be interested to hear about how you built it as a Quartz app. Perhaps we can even get it integrated into the port... Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ From brad at pixilla.com Tue Jan 12 12:16:53 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 12 Jan 2010 12:16:53 -0800 Subject: php5.3 upgrade or php5.2 with CRYPT_MD5 Message-ID: <09A7636F-E196-44E2-BEF4-A3E2746EFEE4@pixilla.com> I am needing to use php5 crypt() with CRYPT_MD5. I have 5.3 on my dev machine and crypt() with CRYPT_MD5 is working fine while on my server with php 5.2.11 has CRYPT_MD5 = 0. Does anyone know of a way to get "CRYPT_MD5 = 1" with macports php5.2.11? Trying to upgrade to php5.3 on my server results in an error trying to build help2man. ## bash-3.2# port upgrade help2man ... /usr/bin/gcc-4.0 -o bindtextdomain.so -fPIC -bundle bindtextdomain.c - lintl ld: library not found for -lintl collect2: ld returned 1 exit status make: *** [bindtextdomain.so] Error 1 Error: Unable to upgrade port: 1 ## I don't have the time to track this down right now. If someone has a quick fix great. // Brad From ryandesign at macports.org Tue Jan 12 12:26:36 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 12 Jan 2010 21:26:36 +0100 Subject: php5.3 upgrade or php5.2 with CRYPT_MD5 In-Reply-To: <09A7636F-E196-44E2-BEF4-A3E2746EFEE4@pixilla.com> References: <09A7636F-E196-44E2-BEF4-A3E2746EFEE4@pixilla.com> Message-ID: <20100112212636.137668c1cdno2l0c@webmail.df.eu> Quoting Bradley Giesbrecht: > I am needing to use php5 crypt() with CRYPT_MD5. > > I have 5.3 on my dev machine and crypt() with CRYPT_MD5 is working > fine while on my server with php 5.2.11 has CRYPT_MD5 = 0. > > Does anyone know of a way to get "CRYPT_MD5 = 1" with macports php5.2.11? The PHP page about crypt says "As of PHP 5.3.0, PHP contains its own implementation and will use that if the system lacks of support for one or more of the algorithms." I see the two DES algorithms are supported but the MD5 and Blowfish ones aren't. So presumably support for those is not in "the system". I'll try to figure out what library would provide these algorithms for PHP 5.2. > Trying to upgrade to php5.3 on my server results in an error trying > to build help2man. > > ## > bash-3.2# port upgrade help2man > ... > /usr/bin/gcc-4.0 -o bindtextdomain.so -fPIC -bundle bindtextdomain.c -lintl > ld: library not found for -lintl > collect2: ld returned 1 exit status > make: *** [bindtextdomain.so] Error 1 > > Error: Unable to upgrade port: 1 > ## > > I don't have the time to track this down right now. If someone has a > quick fix great. This was supposed to have been fixed two weeks ago: http://trac.macports.org/ticket/23050 If you still see the problem after "sudo port selfupdate" let us know. From n.oxyde at gmail.com Tue Jan 12 12:26:54 2010 From: n.oxyde at gmail.com (nox) Date: Tue, 12 Jan 2010 21:26:54 +0100 Subject: php5.3 upgrade or php5.2 with CRYPT_MD5 In-Reply-To: <09A7636F-E196-44E2-BEF4-A3E2746EFEE4@pixilla.com> References: <09A7636F-E196-44E2-BEF4-A3E2746EFEE4@pixilla.com> Message-ID: <107CCDD0-A5EC-4224-8981-14C8F0B4F6D0@gmail.com> You should file a ticket on Trac, but as a quickfix try again after running: sudo sh -c 'echo configure.cc-append -L\${prefix}/lib >> $(port file help2man)' Le 12 janv. 2010 ? 21:16, Bradley Giesbrecht a ?crit : > I am needing to use php5 crypt() with CRYPT_MD5. > > I have 5.3 on my dev machine and crypt() with CRYPT_MD5 is working fine while on my server with php 5.2.11 has CRYPT_MD5 = 0. > > Does anyone know of a way to get "CRYPT_MD5 = 1" with macports php5.2.11? > > > Trying to upgrade to php5.3 on my server results in an error trying to build help2man. > > ## > bash-3.2# port upgrade help2man > ... > /usr/bin/gcc-4.0 -o bindtextdomain.so -fPIC -bundle bindtextdomain.c -lintl > ld: library not found for -lintl > collect2: ld returned 1 exit status > make: *** [bindtextdomain.so] Error 1 > > Error: Unable to upgrade port: 1 > ## > > I don't have the time to track this down right now. If someone has a quick fix great. > > > > // Brad > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From nox at macports.org Tue Jan 12 12:28:55 2010 From: nox at macports.org (nox) Date: Tue, 12 Jan 2010 21:28:55 +0100 Subject: php5.3 upgrade or php5.2 with CRYPT_MD5 In-Reply-To: <20100112212636.137668c1cdno2l0c@webmail.df.eu> References: <09A7636F-E196-44E2-BEF4-A3E2746EFEE4@pixilla.com> <20100112212636.137668c1cdno2l0c@webmail.df.eu> Message-ID: <0ACB40AE-0D5D-4002-993A-21E97A867DE0@macports.org> Olol. I knew I had fixed something like that bug but I didn't know it was that very one ^^' Le 12 janv. 2010 ? 21:26, Ryan Schmidt a ?crit : > > Quoting Bradley Giesbrecht: > >> I am needing to use php5 crypt() with CRYPT_MD5. >> >> I have 5.3 on my dev machine and crypt() with CRYPT_MD5 is working fine while on my server with php 5.2.11 has CRYPT_MD5 = 0. >> >> Does anyone know of a way to get "CRYPT_MD5 = 1" with macports php5.2.11? > > The PHP page about crypt says "As of PHP 5.3.0, PHP contains its own implementation and will use that if the system lacks of support for one or more of the algorithms." I see the two DES algorithms are supported but the MD5 and Blowfish ones aren't. So presumably support for those is not in "the system". I'll try to figure out what library would provide these algorithms for PHP 5.2. > > >> Trying to upgrade to php5.3 on my server results in an error trying to build help2man. >> >> ## >> bash-3.2# port upgrade help2man >> ... >> /usr/bin/gcc-4.0 -o bindtextdomain.so -fPIC -bundle bindtextdomain.c -lintl >> ld: library not found for -lintl >> collect2: ld returned 1 exit status >> make: *** [bindtextdomain.so] Error 1 >> >> Error: Unable to upgrade port: 1 >> ## >> >> I don't have the time to track this down right now. If someone has a quick fix great. > > This was supposed to have been fixed two weeks ago: > > http://trac.macports.org/ticket/23050 > > If you still see the problem after "sudo port selfupdate" let us know. > > > > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From ryandesign at macports.org Tue Jan 12 12:47:09 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 12 Jan 2010 21:47:09 +0100 Subject: php5.3 upgrade or php5.2 with CRYPT_MD5 In-Reply-To: <20100112212636.137668c1cdno2l0c@webmail.df.eu> References: <09A7636F-E196-44E2-BEF4-A3E2746EFEE4@pixilla.com> <20100112212636.137668c1cdno2l0c@webmail.df.eu> Message-ID: <20100112214708.51277kcv9c4mtag4@webmail.df.eu> Quoting myself: > Quoting Bradley Giesbrecht: > >> I am needing to use php5 crypt() with CRYPT_MD5. >> >> I have 5.3 on my dev machine and crypt() with CRYPT_MD5 is working >> fine while on my server with php 5.2.11 has CRYPT_MD5 = 0. >> >> Does anyone know of a way to get "CRYPT_MD5 = 1" with macports php5.2.11? > > The PHP page about crypt says "As of PHP 5.3.0, PHP contains its own > implementation and will use that if the system lacks of support for > one or more of the algorithms." I see the two DES algorithms are > supported but the MD5 and Blowfish ones aren't. So presumably > support for those is not in "the system". I'll try to figure out > what library would provide these algorithms for PHP 5.2. "The system" in this case refers to the crypt function, which on other operating systems is the crypt library but which on Mac OS X is built into the C library. It appears Mac OS X's crypt function doesn't support MD5 and Blowfish, so that's why it doesn't work in PHP. It could possibly be fixed by backporting PHP 5.3's implementation of these functions to PHP 5.2, but that's more effort than I'm going to put in right now. My recommendation is to use PHP 5.3.x. From brad at pixilla.com Tue Jan 12 13:21:58 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 12 Jan 2010 13:21:58 -0800 Subject: php5.3 upgrade or php5.2 with CRYPT_MD5 In-Reply-To: <107CCDD0-A5EC-4224-8981-14C8F0B4F6D0@gmail.com> References: <09A7636F-E196-44E2-BEF4-A3E2746EFEE4@pixilla.com> <107CCDD0-A5EC-4224-8981-14C8F0B4F6D0@gmail.com> Message-ID: The addition from nox worked for me. http://trac.macports.org/ticket/23256 // Brad On Jan 12, 2010, at 12:26 PM, nox wrote: > You should file a ticket on Trac, but as a quickfix try again after > running: > sudo sh -c 'echo configure.cc-append -L\${prefix}/lib >> $(port file > help2man)' > > Le 12 janv. 2010 ? 21:16, Bradley Giesbrecht a ?crit : > >> I am needing to use php5 crypt() with CRYPT_MD5. >> >> I have 5.3 on my dev machine and crypt() with CRYPT_MD5 is working >> fine while on my server with php 5.2.11 has CRYPT_MD5 = 0. >> >> Does anyone know of a way to get "CRYPT_MD5 = 1" with macports >> php5.2.11? >> >> >> Trying to upgrade to php5.3 on my server results in an error trying >> to build help2man. >> >> ## >> bash-3.2# port upgrade help2man >> ... >> /usr/bin/gcc-4.0 -o bindtextdomain.so -fPIC -bundle >> bindtextdomain.c -lintl >> ld: library not found for -lintl >> collect2: ld returned 1 exit status >> make: *** [bindtextdomain.so] Error 1 >> >> Error: Unable to upgrade port: 1 >> ## >> >> I don't have the time to track this down right now. If someone has >> a quick fix great. >> >> >> >> // Brad >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From cristiano.fontana at gmail.com Wed Jan 13 11:48:44 2010 From: cristiano.fontana at gmail.com (Cristiano Fontana) Date: Wed, 13 Jan 2010 20:48:44 +0100 Subject: Portfile for GEANT4 Message-ID: <87DE7456-78E0-4A9E-92A3-2113A464AD81@gmail.com> Hello, I am having problems writing a Portfile of GEANT4. Since these are my first Portfiles, I am not an expert so I need some help. GEANT4 is a toolkit for simulating the interaction of radiation through matter. It is one of the most important piece of software for Particle Physicist because it is a very complex tool that can simulate about anything. Unfortunately it has a weird configure script that aconfigures, builds and install everything. So to install it is not just a standard configure; make; make install (why the heck do not they use standard tools?!). I spent the last days working on this without any success and I am getting a little bit frustrated. What I am trying is to execute their configure script through port so I defined the following phases: build { catch { exec /bin/sh -c "cd ${worksrcpath}; ${worksrcpath}/Configure -build -d -f ${worksrcpath}/config.sh" } } destroot { catch { exec /bin/sh -c "cd ${worksrcpath}; ${worksrcpath}/Configure -install" } } But this way I have no output during building so I am not able to figure out if it is working. As a matter of fact I tried to build it, but it is taking hours and hours... Thanks in advance, Cristiano -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 2836 bytes Desc: not available URL: From dports at ambulatoryclam.net Wed Jan 13 11:57:26 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Wed, 13 Jan 2010 11:57:26 -0800 Subject: Commit emacs updates? (#23165) Message-ID: <20100113195726.GG76618@ambulatoryclam.net> The emacs port is currently abandoned, a major version out of date, *and* doesn't compile under Snow Leopard. I've submitted a patch in ticket #23165 that addresses all three issues. Can I pester someone into committing the patch? (As noted in the ticket, it should also close a couple other tickets.) Thanks, Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ From jmr at macports.org Wed Jan 13 12:49:57 2010 From: jmr at macports.org (Joshua Root) Date: Thu, 14 Jan 2010 07:49:57 +1100 Subject: Portfile for GEANT4 In-Reply-To: <87DE7456-78E0-4A9E-92A3-2113A464AD81@gmail.com> References: <87DE7456-78E0-4A9E-92A3-2113A464AD81@gmail.com> Message-ID: <4B4E31F5.7080100@macports.org> On 2010-1-14 06:48 , Cristiano Fontana wrote: > Hello, > I am having problems writing a Portfile of GEANT4. Since these are my first Portfiles, I am not an expert so I need some help. > > GEANT4 is a toolkit for simulating the interaction of radiation through matter. > It is one of the most important piece of software for Particle Physicist because it is a very complex tool that can simulate about anything. > Unfortunately it has a weird configure script that aconfigures, builds and install everything. So to install it is not just a standard configure; make; make install (why the heck do not they use standard tools?!). > I spent the last days working on this without any success and I am getting a little bit frustrated. > > What I am trying is to execute their configure script through port so I defined the following phases: > > build { > catch { exec /bin/sh -c "cd ${worksrcpath}; ${worksrcpath}/Configure -build -d -f ${worksrcpath}/config.sh" } > } > > destroot { > catch { exec /bin/sh -c "cd ${worksrcpath}; ${worksrcpath}/Configure -install" } > } You should use the 'system' procedure to run shell commands. Like so: build { system "cd ${worksrcpath} && ./Configure -build -d -f config.sh" } destroot { system "cd ${worksrcpath} && ./Configure -install" } } You could also achieve the same effect by setting build.cmd, build.args, build.target, etc. as needed, but this is so different to a standard autotools build that that is probably the messier route. - Josh From blair at orcaware.com Wed Jan 13 13:12:43 2010 From: blair at orcaware.com (Blair Zajac) Date: Wed, 13 Jan 2010 13:12:43 -0800 Subject: Commit emacs updates? (#23165) In-Reply-To: <20100113195726.GG76618@ambulatoryclam.net> References: <20100113195726.GG76618@ambulatoryclam.net> Message-ID: <4B4E374B.7010709@orcaware.com> On 01/13/2010 11:57 AM, Dan Ports wrote: > The emacs port is currently abandoned, a major version out of date, > *and* doesn't compile under Snow Leopard. I've submitted a patch in > ticket #23165 that addresses all three issues. > > Can I pester someone into committing the patch? > > (As noted in the ticket, it should also close a couple other tickets.) I just built both ports on SL and it built. I haven't done any testing besides that, but I'll commit them. I'd like to add openmaintainer to the maintainer fields to make it easier for other people to commit since you don't have commit rights (yet). Let me know what you think. Regards, Blair From ryandesign at macports.org Wed Jan 13 13:43:52 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 13 Jan 2010 15:43:52 -0600 Subject: Portfile for GEANT4 In-Reply-To: <4B4E31F5.7080100@macports.org> References: <87DE7456-78E0-4A9E-92A3-2113A464AD81@gmail.com> <4B4E31F5.7080100@macports.org> Message-ID: <7E1A4DA2-E695-4972-A390-2D8073125CB8@macports.org> On Jan 13, 2010, at 14:49, Joshua Root wrote: > On 2010-1-14 06:48 , Cristiano Fontana wrote: > >> What I am trying is to execute their configure script through port so I defined the following phases: >> >> build { >> catch { exec /bin/sh -c "cd ${worksrcpath}; ${worksrcpath}/Configure -build -d -f ${worksrcpath}/config.sh" } >> } >> >> destroot { >> catch { exec /bin/sh -c "cd ${worksrcpath}; ${worksrcpath}/Configure -install" } >> } > > You should use the 'system' procedure to run shell commands. Like so: > > build { > system "cd ${worksrcpath} && ./Configure -build -d -f config.sh" > } > > destroot { > system "cd ${worksrcpath} && ./Configure -install" } > } > > You could also achieve the same effect by setting build.cmd, build.args, > build.target, etc. as needed, but this is so different to a standard > autotools build that that is probably the messier route. Personally, I would highly recommend trying to use build.cmd, build.args, etc, instead of overriding the phases. From ryandesign at macports.org Wed Jan 13 13:45:01 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 13 Jan 2010 15:45:01 -0600 Subject: License option In-Reply-To: References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B48D941.3040202@macports.org> <629AE7BF-B86C-4267-8963-7EE22ABA15E8@macports.org> Message-ID: <40231641-2AF3-4958-95BB-B3B925D1C89F@macports.org> On Jan 11, 2010, at 16:08, Michael Crawford wrote: > Y'all should have a look at the RDF (XML Resource Description > Framework) that Creative Commons uses to mark CC-licensed work. You > can get examples by selecting a license at http://creativecommons.org/ > or view the source of my page here: > > http://www.geometricvisions.com/music/manifesto/ > > Note that the DOCTYPE of that page is XHTML+RDFa, not just XHTML: > > "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"> > > Hope That Helps. I don't have time to read through those right now. Could you sum up your specific suggestion for how this would apply to MacPorts? From dports at ambulatoryclam.net Wed Jan 13 13:50:44 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Wed, 13 Jan 2010 13:50:44 -0800 Subject: Commit emacs updates? (#23165) In-Reply-To: <4B4E374B.7010709@orcaware.com> References: <20100113195726.GG76618@ambulatoryclam.net> <4B4E374B.7010709@orcaware.com> Message-ID: <20100113215044.GI76618@ambulatoryclam.net> On Wed, Jan 13, 2010 at 01:12:43PM -0800, Blair Zajac wrote: > I just built both ports on SL and it built. I haven't done any testing > besides that, but I'll commit them. Thanks! > I'd like to add openmaintainer to the maintainer fields to make it > easier for other people to commit since you don't have commit rights > (yet). Let me know what you think. OK with me -- one of my main concerns is that such an important (IMO) port not be abandoned, and that should help. Incidentally, I should point out that I expect to someday add a emacs-devel that builds a CVS snapshot and can also be installed concurrently (in the same way that both emacs and emacs22 can be installed). I haven't yet gotten around to it since emacs23 is a recent release so there hasn't been much of a need for something newer. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ From ryandesign at macports.org Wed Jan 13 13:55:57 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 13 Jan 2010 15:55:57 -0600 Subject: License option In-Reply-To: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> Message-ID: On Jan 9, 2010, at 13:14, nox wrote: > I see a lot of ports with license options like "GPLv2/LGPLv2". The "v" and "/" seem ugly to me, especially with licenses like Apache, where we end up with "Apachev2". Shouldn't we write something more beautiful like: > > license LGPL-2 Apache-2 MIT BSD DWTFYWL-42 The "v" in the licenses has slightly bugged me. Using a "-" instead would improve readability. Using "/" to separate multiple licenses is probably incorrect. This is a normal MacPorts field, which means it can be treated as a list/array and appended to or deleted from using license-append and license-delete. In some ports that combine software from multiple sources, it might even be necessary to modify the license field in a variant; I'm thinking of ffmpeg here. As such, multiple values should be separated by spaces, not slashes, as for any other MacPorts field. license GPL-2 LGPL-2.1 One other comment that wasn't mentioned yet in this thread: Some licenses have been specified using a "+", e.g. "GPLv2+". I don't feel this is necessary. The terms of the GPL state that any later version may be used. So no additional information is conveyed by putting the "+" into the license field. Anybody familiar with the GPL knows any later version is acceptable, and anybody unfamiliar but looking to comply with the license will be reading its text anyway and will learn this. I move to remove "+" from the license fields. (Or, add it everywhere it applies. We just need to be consistent.) From ryandesign at macports.org Wed Jan 13 13:59:58 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 13 Jan 2010 15:59:58 -0600 Subject: Commit emacs updates? (#23165) In-Reply-To: <20100113215044.GI76618@ambulatoryclam.net> References: <20100113195726.GG76618@ambulatoryclam.net> <4B4E374B.7010709@orcaware.com> <20100113215044.GI76618@ambulatoryclam.net> Message-ID: On Jan 13, 2010, at 15:50, Dan Ports wrote: > Incidentally, I should point out that I expect to someday add a > emacs-devel that builds a CVS snapshot and can also be installed > concurrently (in the same way that both emacs and emacs22 can be > installed). I haven't yet gotten around to it since emacs23 is a > recent release so there hasn't been much of a need for something newer. A port named emacs-devel should install to the same place as a port called emacs. It should not be possible for both to be installed simultaneously. That is how our existing -devel/non-devel ports work. See the "documentation" here: http://trac.macports.org/ticket/14540 If you want simultaneously-installable ports, the names should be different, e.g. by naming the new one emacs23. From jmr at macports.org Wed Jan 13 14:22:06 2010 From: jmr at macports.org (Joshua Root) Date: Thu, 14 Jan 2010 09:22:06 +1100 Subject: License option In-Reply-To: References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> Message-ID: <4B4E478E.4000709@macports.org> On 2010-1-14 08:55 , Ryan Schmidt wrote: > > The terms of the GPL state that any later version may be used. No they don't. - Josh From ryandesign at macports.org Wed Jan 13 14:37:39 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 13 Jan 2010 16:37:39 -0600 Subject: License option In-Reply-To: <4B4E478E.4000709@macports.org> References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B4E478E.4000709@macports.org> Message-ID: On Jan 13, 2010, at 16:22, Joshua Root wrote: > On 2010-1-14 08:55 , Ryan Schmidt wrote: >> >> The terms of the GPL state that any later version may be used. > > No they don't. I was under the impression that they do. http://www.gnu.org/licenses/gpl.html Section 14 of the GPL v3 says: Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License ?or any later version? applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation. From ryandesign at macports.org Wed Jan 13 14:39:51 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 13 Jan 2010 16:39:51 -0600 Subject: [62666] trunk/dports/devel/git-core/Portfile In-Reply-To: <20100113172551.84CC53C2BE14@beta.macosforge.org> References: <20100113172551.84CC53C2BE14@beta.macosforge.org> Message-ID: <62588784-8618-46C1-A41F-A0B7A6B5C6E8@macports.org> On Jan 13, 2010, at 11:25, sharky at macports.org wrote: > set CFLAGS "-Wall -O2 -I${prefix}/include ${configure.cc_archflags}" > -set LDFLAGS "-L${prefix}/lib ${configure.ld_archflags}" > +set LDFLAGS "-L${prefix}/lib" > > build.args CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" \ > CC=${configure.cc} \ I'm curious why you're setting new variables CFLAGS and LDFLAGS, and not using the variables that already exist for this purpose, namely configure.cflags, configure.cppflags, configure.cxxflags, configure.ldflags, etc. From wsiegrist at apple.com Wed Jan 13 14:43:44 2010 From: wsiegrist at apple.com (William Siegrist) Date: Wed, 13 Jan 2010 14:43:44 -0800 Subject: License option In-Reply-To: References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B4E478E.4000709@macports.org> Message-ID: <41467859-42EB-4A28-94B2-60DDBD2D6C73@apple.com> On Jan 13, 2010, at 2:37 PM, Ryan Schmidt wrote: > > On Jan 13, 2010, at 16:22, Joshua Root wrote: > >> On 2010-1-14 08:55 , Ryan Schmidt wrote: >>> >>> The terms of the GPL state that any later version may be used. >> >> No they don't. > > I was under the impression that they do. > > http://www.gnu.org/licenses/gpl.html > > Section 14 of the GPL v3 says: > > Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License ?or any later version? applies to it As it says above, projects opt into this by adding "or any later version". It is not automatic. -Bill From toby at macports.org Wed Jan 13 14:49:58 2010 From: toby at macports.org (Toby Peterson) Date: Wed, 13 Jan 2010 14:49:58 -0800 Subject: License option In-Reply-To: References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> Message-ID: <41F37976-9BA9-4B94-B7B0-5517D6B4F016@macports.org> On Jan 13, 2010, at 1:55 PM, Ryan Schmidt wrote: > One other comment that wasn't mentioned yet in this thread: Some licenses have been specified using a "+", e.g. "GPLv2+". I don't feel this is necessary. The terms of the GPL state that any later version may be used. So no additional information is conveyed by putting the "+" into the license field. Anybody familiar with the GPL knows any later version is acceptable, and anybody unfamiliar but looking to comply with the license will be reading its text anyway and will learn this. I move to remove "+" from the license fields. (Or, add it everywhere it applies. We just need to be consistent.) The distinction between GPLv2 and GPLv2+ (i.e. "or any later version") is fairly significant. - Toby From ryandesign at macports.org Wed Jan 13 15:29:23 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 13 Jan 2010 17:29:23 -0600 Subject: License option In-Reply-To: <41467859-42EB-4A28-94B2-60DDBD2D6C73@apple.com> References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B4E478E.4000709@macports.org> <41467859-42EB-4A28-94B2-60DDBD2D6C73@apple.com> Message-ID: <24733D3F-0FDD-4A25-9485-31DFBAD5595E@macports.org> On Jan 13, 2010, at 16:43, William Siegrist wrote: > On Jan 13, 2010, at 2:37 PM, Ryan Schmidt wrote: > >> On Jan 13, 2010, at 16:22, Joshua Root wrote: >> >>> On 2010-1-14 08:55 , Ryan Schmidt wrote: >> >>> >>>> The terms of the GPL state that any later version may be used. >>> >>> No they don't. >> >> I was under the impression that they do. >> >> http://www.gnu.org/licenses/gpl.html >> >> Section 14 of the GPL v3 says: >> >> Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License ?or any later version? applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation. > > As it says above, projects opt into this by adding "or any later version". It is not automatic. As far as I can tell, the distinction then is between "this version or any later version" or "this version or any later or earlier version." (I restored my full quote above which I believe says this, though IANAL.) I don't see any option that means "this version and no other version". Is that your interpretation as well? And do we really need to distinguish between those cases in the portfiles? If so, I have to review all my portfiles, and other maintainers who were not aware of the distinction would have to also. From jmr at macports.org Wed Jan 13 15:35:02 2010 From: jmr at macports.org (Joshua Root) Date: Thu, 14 Jan 2010 10:35:02 +1100 Subject: License option In-Reply-To: <24733D3F-0FDD-4A25-9485-31DFBAD5595E@macports.org> References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B4E478E.4000709@macports.org> <41467859-42EB-4A28-94B2-60DDBD2D6C73@apple.com> <24733D3F-0FDD-4A25-9485-31DFBAD5595E@macports.org> Message-ID: <4B4E58A6.40904@macports.org> On 2010-1-14 10:29 , Ryan Schmidt wrote: > > On Jan 13, 2010, at 16:43, William Siegrist wrote: > >> On Jan 13, 2010, at 2:37 PM, Ryan Schmidt wrote: >> >>> Section 14 of the GPL v3 says: >>> >>> Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License ?or any later version? applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation. >> >> As it says above, projects opt into this by adding "or any later version". It is not automatic. > > As far as I can tell, the distinction then is between "this version or any later version" or "this version or any later or earlier version." (I restored my full quote above which I believe says this, though IANAL.) I don't see any option that means "this version and no other version". Is that your interpretation as well? And do we really need to distinguish between those cases in the portfiles? If so, I have to review all my portfiles, and other maintainers who were not aware of the distinction would have to also. The rather straightforward third option is to specify a version but not say "or any later version", in which case neither of these sentences applies. - Josh From ryandesign at macports.org Wed Jan 13 15:47:30 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 13 Jan 2010 17:47:30 -0600 Subject: License option In-Reply-To: <4B4E58A6.40904@macports.org> References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B4E478E.4000709@macports.org> <41467859-42EB-4A28-94B2-60DDBD2D6C73@apple.com> <24733D3F-0FDD-4A25-9485-31DFBAD5595E@macports.org> <4B4E58A6.40904@macports.org> Message-ID: <1F8CE5FD-5137-44FE-9216-A3E8045E978D@macports.org> On Jan 13, 2010, at 17:35, Joshua Root wrote: > On 2010-1-14 10:29 , Ryan Schmidt wrote: >> > >> As far as I can tell, the distinction then is between "this version or any later version" or "this version or any later or earlier version." (I restored my full quote above which I believe says this, though IANAL.) I don't see any option that means "this version and no other version". Is that your interpretation as well? And do we really need to distinguish between those cases in the portfiles? If so, I have to review all my portfiles, and other maintainers who were not aware of the distinction would have to also. > > The rather straightforward third option is to specify a version but not > say "or any later version", in which case neither of these sentences > applies. That sounds surprisingly reasonable. :) I'll check my ports. http://trac.macports.org/ticket/23279 From ryandesign at macports.org Wed Jan 13 16:01:24 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 13 Jan 2010 18:01:24 -0600 Subject: [62541] trunk/dports/net/openvpn2/Portfile In-Reply-To: <20100110190011.23A783B89B62@beta.macosforge.org> References: <20100110190011.23A783B89B62@beta.macosforge.org> Message-ID: <29C2B9A8-A0E3-41AB-8340-C803C359FC22@macports.org> On Jan 10, 2010, at 13:00, pmq at macports.org wrote: > post-destroot { > - set docdir ${destroot}/${prefix}/share/doc/${name} > + set docdir ${destroot}/${prefix}/share/doc/${name}-${version} Actually we decided we don't want versioned documentation directories: http://lists.macosforge.org/pipermail/macports-dev/2009-October/010526.html > - foreach file "AUTHORS INSTALL NEWS PORTS README" { > + foreach file "AUTHORS COPYING INSTALL NEWS PORTS README" { I usually recommend not installing the INSTALL file, since its only purpose is to tell you how to install the software, a task MacPorts has already accomplished by the time these files are installed. https://trac.macports.org/wiki/PortfileRecipes#doc From roederja at ethz.ch Wed Jan 13 16:14:40 2010 From: roederja at ethz.ch (=?UTF-8?B?SmFubiBSw7ZkZXI=?=) Date: Thu, 14 Jan 2010 01:14:40 +0100 Subject: ActiveMQ port submission Message-ID: Hi, somebody created a port for ActiveMQ: http://trac.macports.org/ticket/23143 . The port however has the problem that non-root users cannot run it since it wants to write to /opt/local/share/java/activemq . I told the submitter that he has to install a config file so that the port works out of the box for non-root users and doesn't write to /opt/local/share/java/activemq. What is the official policy for such things? Do ports have to work out of the box? Best regards, Jann From jmr at macports.org Wed Jan 13 16:18:52 2010 From: jmr at macports.org (Joshua Root) Date: Thu, 14 Jan 2010 11:18:52 +1100 Subject: ActiveMQ port submission In-Reply-To: References: Message-ID: <4B4E62EC.6070005@macports.org> On 2010-1-14 11:14 , Jann R?der wrote: > Hi, > somebody created a port for ActiveMQ: > http://trac.macports.org/ticket/23143 . The port however has the problem > that non-root users cannot run it since it wants to write to > /opt/local/share/java/activemq . I told the submitter that he has to > install a config file so that the port works out of the box for non-root > users and doesn't write to /opt/local/share/java/activemq. What is the > official policy for such things? Do ports have to work out of the box? Working out of the box is greatly preferable but we don't demand that everything does. If setup is required, there should be a notes entry explaining that. - Josh From dports at ambulatoryclam.net Wed Jan 13 16:27:29 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Wed, 13 Jan 2010 16:27:29 -0800 Subject: License option In-Reply-To: <4B4E58A6.40904@macports.org> References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B4E478E.4000709@macports.org> <41467859-42EB-4A28-94B2-60DDBD2D6C73@apple.com> <24733D3F-0FDD-4A25-9485-31DFBAD5595E@macports.org> <4B4E58A6.40904@macports.org> Message-ID: <20100113235729.GJ76618@ambulatoryclam.net> On Thu, Jan 14, 2010 at 10:35:02AM +1100, Joshua Root wrote: > The rather straightforward third option is to specify a version but not > say "or any later version", in which case neither of these sentences > applies. And indeed there is much software that does just that -- IIRC the Linux kernel is a prominent example. Dan (who has a new appreciation for the complexity of today's licensing state of affairs) -- Dan R. K. Ports MIT CSAIL http://drkp.net/ From dports at ambulatoryclam.net Wed Jan 13 16:38:08 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Wed, 13 Jan 2010 16:38:08 -0800 Subject: Simultaneous -devel and non-devel In-Reply-To: References: <20100113195726.GG76618@ambulatoryclam.net> <4B4E374B.7010709@orcaware.com> <20100113215044.GI76618@ambulatoryclam.net> Message-ID: <20100114003808.GB63911@ambulatoryclam.net> On Wed, Jan 13, 2010 at 03:59:58PM -0600, Ryan Schmidt wrote: > A port named emacs-devel should install to the same place as a port called emacs. It should not be possible for both to be installed simultaneously. That is how our existing -devel/non-devel ports work. See the "documentation" here: Interesting, thanks for bringing that to my attention (esp. the link and associated email thread.) Let me add a few more words of explanation about what I was thinking, and see what makes sense re: naming. I submitted an emacs22 port in addition to the existing emacs port (which is now emacs 23.) I consider it important to be able to have the two installed simultaneously -- e.g. for using elisp packages that break under one or the other, testing packages on both versions, or compatiblity with other systems. Hence, emacs22 installs itself so that it doesn't conflict with emacs. (This is mostly a matter of renaming a few binaries, e.g. emacs -> emacs22, since much of emacs is already versioned, e.g. /usr/share/emacs/22.3.) Now, for a while before emacs 23.1 was released I ran a cvs snapshot to pick up a few bug fixes I cared about -- sounds like a perfect reason to have a -devel port! Since we can install emacs22 and emacs at once, why not be able to install the release and devel versions together too? Now I am learning that -devel and non-devel ports should install into the same place, which does makes sense, and thus conflict -- which I consider undesirable. What are your thoughts on the best way to handle this? Is something like python_select (which I am admittedly not at all familiar with!) needed? Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ From dports at ambulatoryclam.net Wed Jan 13 17:10:45 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Wed, 13 Jan 2010 17:10:45 -0800 Subject: Java port questions (Re: ActiveMQ port submission) In-Reply-To: References: Message-ID: <20100114011045.GC63911@ambulatoryclam.net> On Thu, Jan 14, 2010 at 01:14:40AM +0100, Jann R??der wrote: > Hi, > somebody created a port for ActiveMQ: > http://trac.macports.org/ticket/23143 . The port however has the problem > that non-root users cannot run it since it wants to write to > /opt/local/share/java/activemq . I told the submitter that he has to > install a config file so that the port works out of the box for non-root > users and doesn't write to /opt/local/share/java/activemq. What is the > official policy for such things? Do ports have to work out of the box? I submitted that portfile, so feel compelled to respond -- but note that I have no real familiarity with ActiveMQ other than offering to help write a portfile. Being a Java-based port, it brought up a few other issues that I didn't have a good answer to. I tried to resolve them based on a (highly scientific) study of some other random Java ports. But it's probably worth clarifying policy on these: - ActiveMQ has both a source and binary distribution. Which should we use? I went with the binary not just out of simple laziness but also because it depended on some Java packages that we didn't already have ports for. (I guess that'd be a more sophisticated form of laziness.) I found a bunch of ports of each type: source or binary installs. If going with a binary install, then: - the binary install is designed to be run out of its directory, so the port puts a bunch of stuff in /opt/local/share/java/activemq. I agree with Jann that some of it really doesn't belong there, including apparently logfiles. But I'm not entirely clear on what should be moved and where. - the binary distribution includes all of its library dependencies, leading to a bunch of jar files in /opt/local/share/java/activemq/lib. Some are also provided by ports, like commons-*. Should we do something about that? I was pretty troubled by the duplication, but they *are* included in the binary dist, and the activemq folks told me they were worried about version mismatches with already-installed libraries. Note that some other ports (I think maven is one?) also wind up installing some of the same libraries so there is a danger we'll wind up with a bunch of copies. - I originally put in a dependency on bin:java:kaffe, but Jann pointed out that this is silly since Java has been included in OS X at least as far back as I can remember. A lot of other ports have this same dependency. What's up with that? Should they be changed? Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ From jmr at macports.org Wed Jan 13 17:20:17 2010 From: jmr at macports.org (Joshua Root) Date: Thu, 14 Jan 2010 12:20:17 +1100 Subject: Java port questions (Re: ActiveMQ port submission) In-Reply-To: <20100114011045.GC63911@ambulatoryclam.net> References: <20100114011045.GC63911@ambulatoryclam.net> Message-ID: <4B4E7151.5010800@macports.org> On 2010-1-14 12:10 , Dan Ports wrote: > - I originally put in a dependency on bin:java:kaffe, but Jann pointed > out that this is silly since Java has been included in OS X at least > as far back as I can remember. A lot of other ports have this same > dependency. What's up with that? Should they be changed? It's for (mostly theoretical) portability. I don't think PureDarwin comes with Java for example. - Josh From mdcrawford at gmail.com Wed Jan 13 17:58:54 2010 From: mdcrawford at gmail.com (Michael Crawford) Date: Wed, 13 Jan 2010 17:58:54 -0800 Subject: License option In-Reply-To: <20100113235729.GJ76618@ambulatoryclam.net> References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B4E478E.4000709@macports.org> <41467859-42EB-4A28-94B2-60DDBD2D6C73@apple.com> <24733D3F-0FDD-4A25-9485-31DFBAD5595E@macports.org> <4B4E58A6.40904@macports.org> <20100113235729.GJ76618@ambulatoryclam.net> Message-ID: Ever since the GPL version 3 was released, a whole bunch of projects altered their license notices to specifically require GPL version 2 and no other. There is a huge problem, because one cannot include GPLv2 and GPLv3 code in the same binary. The two GPL versions are *completely* incompatible with each other. GPLv2+ code is compatible with GPLv3, because one can then exercise the option to use the later version. GPLv2 code - without the plus - does not permit one that option. The GPL is not just one license; in reality we have four licenses whose terms and compatibilities are quite significantly different from each other: GPL version 2 GPL version 2 or any later version GPL version 3 GPL version 3 or any later version It is a huge can of worms, and it's just going to get worse because so many naive and innocent developers don't understand all the legal ramifications of all the different GPL varieties. I'm working on a GPL audio application called Ogg Frog. I haven't released anything at all yet, but the sources in my private repository are all very specific that they require GPL version 2 and no other. It's not so much that I object to GPL version 3 - I understand what it was meant to accomplish, and I enthusiastically support all those goals. The reason that I don't permit GPL version 3 is that I find the license document utterly beyond my comprehension. I have asked for advice on numerous forums, including in particular Debian-Legal, but all the explanations and arguments that result just make my head spin. Until I can understand in a deep and fundamental way what it would mean for my code to have GPL version 3, I simply do not feel comfortable using it. Mike -- Michael David Crawford mdcrawford at gmail dot com GoingWare's Bag of Programming Tricks http://www.goingware.com/tips/ From blair at orcaware.com Wed Jan 13 18:47:29 2010 From: blair at orcaware.com (Blair Zajac) Date: Wed, 13 Jan 2010 18:47:29 -0800 Subject: Commit emacs updates? (#23165) In-Reply-To: <20100113215044.GI76618@ambulatoryclam.net> References: <20100113195726.GG76618@ambulatoryclam.net> <4B4E374B.7010709@orcaware.com> <20100113215044.GI76618@ambulatoryclam.net> Message-ID: <02350069-9992-4AB0-B2F9-38F87288FCEC@orcaware.com> On Jan 13, 2010, at 1:50 PM, Dan Ports wrote: > On Wed, Jan 13, 2010 at 01:12:43PM -0800, Blair Zajac wrote: >> I just built both ports on SL and it built. I haven't done any testing >> besides that, but I'll commit them. > > Thanks! > >> I'd like to add openmaintainer to the maintainer fields to make it >> easier for other people to commit since you don't have commit rights >> (yet). Let me know what you think. > > OK with me -- one of my main concerns is that such an important (IMO) > port not be abandoned, and that should help. > > Incidentally, I should point out that I expect to someday add a > emacs-devel that builds a CVS snapshot and can also be installed > concurrently (in the same way that both emacs and emacs22 can be > installed). I haven't yet gotten around to it since emacs23 is a > recent release so there hasn't been much of a need for something newer. Dan, You know what else would be useful is for emacs and emacs-app to share the same emacs tarball. Right now one is gzip and the other is bzip2 and they are dropped into different distfile directories. That would save an additional download. Regards, Blair From blair at orcaware.com Wed Jan 13 21:49:44 2010 From: blair at orcaware.com (Blair Zajac) Date: Wed, 13 Jan 2010 21:49:44 -0800 Subject: Java port questions (Re: ActiveMQ port submission) In-Reply-To: <20100114011045.GC63911@ambulatoryclam.net> References: <20100114011045.GC63911@ambulatoryclam.net> Message-ID: <4B4EB078.6080203@orcaware.com> Dan Ports wrote: > On Thu, Jan 14, 2010 at 01:14:40AM +0100, Jann R??der wrote: >> Hi, >> somebody created a port for ActiveMQ: >> http://trac.macports.org/ticket/23143 . The port however has the problem >> that non-root users cannot run it since it wants to write to >> /opt/local/share/java/activemq . I told the submitter that he has to >> install a config file so that the port works out of the box for non-root >> users and doesn't write to /opt/local/share/java/activemq. What is the >> official policy for such things? Do ports have to work out of the box? > > I submitted that portfile, so feel compelled to respond -- but note > that I have no real familiarity with ActiveMQ other than offering to > help write a portfile. > > Being a Java-based port, it brought up a few other issues that I didn't > have a good answer to. I tried to resolve them based on a (highly > scientific) study of some other random Java ports. But it's probably > worth clarifying policy on these: > > - ActiveMQ has both a source and binary distribution. Which should we > use? I went with the binary not just out of simple laziness but also > because it depended on some Java packages that we didn't already have > ports for. (I guess that'd be a more sophisticated form of laziness.) > I found a bunch of ports of each type: source or binary installs. For Java ports I never have a problem installing the binaries unless a patch is needed. I don't see why people like to recompile Java packages from source. > > If going with a binary install, then: > > - the binary install is designed to be run out of its directory, so the > port puts a bunch of stuff in > /opt/local/share/java/activemq. I agree with Jann that some of it really > doesn't belong there, including apparently logfiles. But I'm not > entirely clear on what should be moved and where. log files should go into $prefix/var/log. > - the binary distribution includes all of its library dependencies, > leading to a bunch of jar files in > /opt/local/share/java/activemq/lib. Some are also provided by ports, > like commons-*. Should we do something about that? I was pretty > troubled by the duplication, but they *are* included in the binary > dist, and the activemq folks told me they were worried about version > mismatches with already-installed libraries. > > Note that some other ports (I think maven is one?) also wind up > installing some of the same libraries so there is a danger we'll wind > up with a bunch of copies. Well, I would keep those jars there and not let any other packages use their dependency jars. Blair From nox at macports.org Wed Jan 13 23:03:34 2010 From: nox at macports.org (nox) Date: Thu, 14 Jan 2010 08:03:34 +0100 Subject: share/examples In-Reply-To: <20100113212556.A0B293C300D0@beta.macosforge.org> References: <20100113212556.A0B293C300D0@beta.macosforge.org> Message-ID: Since when do we put examples in their own share/ directory? I've only one port (of 444) installing things there and that's jakarta-taglibs-standard-11. Regards. From afb at macports.org Wed Jan 13 23:59:06 2010 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 14 Jan 2010 08:59:06 +0100 Subject: share/examples In-Reply-To: References: <20100113212556.A0B293C300D0@beta.macosforge.org> Message-ID: nox wrote: > Since when do we put examples in their own share/ directory? I've > only one port (of 444) installing things there and that's jakarta- > taglibs-standard-11. The directory is there since http://trac.macports.org/changeset/3664, not many use it. Others normally use share/doc/${name}/examples (or some variation thereof) instead... --anders From danchr at gmail.com Thu Jan 14 00:59:26 2010 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Thu, 14 Jan 2010 09:59:26 +0100 Subject: License option In-Reply-To: References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B4E478E.4000709@macports.org> <41467859-42EB-4A28-94B2-60DDBD2D6C73@apple.com> <24733D3F-0FDD-4A25-9485-31DFBAD5595E@macports.org> <4B4E58A6.40904@macports.org> <20100113235729.GJ76618@ambulatoryclam.net> Message-ID: <43DE0236-B356-42D0-AD7C-19D50A115013@gmail.com> On 14 Jan 2010, at 02:58, Michael Crawford wrote: > The GPL is not just one license; in reality we have four licenses > whose terms and compatibilities are quite significantly different from > each other: > > GPL version 2 > GPL version 2 or any later version > GPL version 3 > GPL version 3 or any later version Another approach would be to consider GPLv2+ code as dual licensed; that is, list the licences as: license GPL-2.0 GPL-3.0 Should a GPLv3.1 or GPLv4 ever appear, it can be added to the list on if/when needed. -- Dan Villiom Podlaski Christiansen danchr at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1943 bytes Desc: not available URL: From pmq at macports.org Thu Jan 14 01:25:11 2010 From: pmq at macports.org (Pierre Queinnec) Date: Thu, 14 Jan 2010 10:25:11 +0100 Subject: [62541] trunk/dports/net/openvpn2/Portfile In-Reply-To: <29C2B9A8-A0E3-41AB-8340-C803C359FC22@macports.org> References: <20100110190011.23A783B89B62@beta.macosforge.org> <29C2B9A8-A0E3-41AB-8340-C803C359FC22@macports.org> Message-ID: <4B4EE2F7.80605@macports.org> Thanks for the heads-up. Should be corrected in r62709. -- Pierre Ryan Schmidt wrote: > On Jan 10, 2010, at 13:00, pmq at macports.org wrote: > >> post-destroot { >> - set docdir ${destroot}/${prefix}/share/doc/${name} >> + set docdir ${destroot}/${prefix}/share/doc/${name}-${version} > > Actually we decided we don't want versioned documentation directories: > > http://lists.macosforge.org/pipermail/macports-dev/2009-October/010526.html > > >> - foreach file "AUTHORS INSTALL NEWS PORTS README" { >> + foreach file "AUTHORS COPYING INSTALL NEWS PORTS README" { > > I usually recommend not installing the INSTALL file, since its only purpose is to tell you how to install the software, a task MacPorts has already accomplished by the time these files are installed. > > https://trac.macports.org/wiki/PortfileRecipes#doc > From ryandesign at macports.org Thu Jan 14 14:42:03 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 14 Jan 2010 16:42:03 -0600 Subject: License option In-Reply-To: <43DE0236-B356-42D0-AD7C-19D50A115013@gmail.com> References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B4E478E.4000709@macports.org> <41467859-42EB-4A28-94B2-60DDBD2D6C73@apple.com> <24733D3F-0FDD-4A25-9485-31DFBAD5595E@macports.org> <4B4E58A6.40904@macports.org> <20100113235729.GJ76618@ambulatoryclam.net> <43DE0236-B356-42D0-AD7C-19D50A115013@gmail.com> Message-ID: <92A43828-C837-4A59-83C1-F7F479694D93@macports.org> On Jan 14, 2010, at 02:59, Dan Villiom Podlaski Christiansen wrote: > On 14 Jan 2010, at 02:58, Michael Crawford wrote: > >> The GPL is not just one license; in reality we have four licenses >> whose terms and compatibilities are quite significantly different from >> each other: >> >> GPL version 2 >> GPL version 2 or any later version >> GPL version 3 >> GPL version 3 or any later version And finally: GPL any version whatsoever, for software licensed under "GPL" without stating what version. > Another approach would be to consider GPLv2+ code as dual licensed; that is, list the licences as: > > license GPL-2.0 GPL-3.0 > > Should a GPLv3.1 or GPLv4 ever appear, it can be added to the list on if/when needed. Except "the list" is in every port, so we currently have 183 ports that indicate they use some kind of GPL or LGPL, and we only just started indicating ports' licenses so there are probably a thousand or more additional ports that are GPL-licensed that just don't say so. So this would impose a burden to need to keep on top of updating license information in ports, and to keep aware of when new license versions come about. Many maintainers aren't that active or dedicated, and 40% of our ports don't have a maintainer at all. Only 5% of our ports indicate their license. Granted new license versions don't come out that frequently so the burden perhaps isn't so big. But consider also the case of software licensed under "GPL 3 or any later version". There isn't a later version today. If we go by your plan, we'd have to write GPL-3.0 in the license field. If tomorrow a GPL-3.1 or GPL-4.0 comes out, we'd have to review all ports that claim to use GPL-3.0 to see if that meant GPL 3.0 only or GPL 3.0 and any later version. From brad at pixilla.com Thu Jan 14 15:02:43 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 14 Jan 2010 15:02:43 -0800 Subject: License option In-Reply-To: <92A43828-C837-4A59-83C1-F7F479694D93@macports.org> References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B4E478E.4000709@macports.org> <41467859-42EB-4A28-94B2-60DDBD2D6C73@apple.com> <24733D3F-0FDD-4A25-9485-31DFBAD5595E@macports.org> <4B4E58A6.40904@macports.org> <20100113235729.GJ76618@ambulatoryclam.net> <43DE0236-B356-42D0-AD7C-19D50A115013@gmail.com> <92A43828-C837-4A59-83C1-F7F479694D93@macports.org> Message-ID: <03821286-98A6-4930-9A6D-0E1D650DE1C4@pixilla.com> On Jan 14, 2010, at 2:42 PM, Ryan Schmidt wrote: > On Jan 14, 2010, at 02:59, Dan Villiom Podlaski Christiansen wrote: > >> On 14 Jan 2010, at 02:58, Michael Crawford wrote: >> >>> The GPL is not just one license; in reality we have four licenses >>> whose terms and compatibilities are quite significantly different >>> from >>> each other: >>> >>> GPL version 2 >>> GPL version 2 or any later version >>> GPL version 3 >>> GPL version 3 or any later version > > And finally: > > GPL any version whatsoever, for software licensed under "GPL" > without stating what version. Possibly be brief and add a url to the projects license page. BSD http://someproject/ GPL http://anotherproject/ // Brad From jeremy at lavergne.gotdns.org Thu Jan 14 15:07:03 2010 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 14 Jan 2010 18:07:03 -0500 Subject: License option In-Reply-To: <92A43828-C837-4A59-83C1-F7F479694D93@macports.org> References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B4E478E.4000709@macports.org> <41467859-42EB-4A28-94B2-60DDBD2D6C73@apple.com> <24733D3F-0FDD-4A25-9485-31DFBAD5595E@macports.org> <4B4E58A6.40904@macports.org> <20100113235729.GJ76618@ambulatoryclam.net> <43DE0236-B356-42D0-AD7C-19D50A115013@gmail.com> <92A43828-C837-4A59-83C1-F7F479694D93@macports.org> Message-ID: > Except "the list" is in every port, so we currently have 183 ports that indicate they use some kind of GPL or LGPL, and we only just started indicating ports' licenses so there are probably a thousand or more additional ports that are GPL-licensed that just don't say so. So this would impose a burden to need to keep on top of updating license information in ports, and to keep aware of when new license versions come about. Many maintainers aren't that active or dedicated, and 40% of our ports don't have a maintainer at all. Only 5% of our ports indicate their license. Granted new license versions don't come out that frequently so the burden perhaps isn't so big. > > But consider also the case of software licensed under "GPL 3 or any later version". There isn't a later version today. If we go by your plan, we'd have to write GPL-3.0 in the license field. If tomorrow a GPL-3.1 or GPL-4.0 comes out, we'd have to review all ports that claim to use GPL-3.0 to see if that meant GPL 3.0 only or GPL 3.0 and any later version. That's pretty straightforward for SourceForge projects: we can write a licensecheck just like livecheck. -------------- 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 Jan 14 18:13:02 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 14 Jan 2010 20:13:02 -0600 Subject: [62712] trunk/dports/lang/slime/Portfile In-Reply-To: <20100114110536.6D6CE3C42134@beta.macosforge.org> References: <20100114110536.6D6CE3C42134@beta.macosforge.org> Message-ID: <2DF9179B-D712-43A2-92F1-391CC6A97F4B@macports.org> On Jan 14, 2010, at 05:05, easieste at macports.org wrote: > Revision: 62712 > http://trac.macports.org/changeset/62712 > Author: easieste at macports.org > Date: 2010-01-14 03:05:34 -0800 (Thu, 14 Jan 2010) > Log Message: > ----------- > Update to slime-20100113. > > Update message and variants about currently working MacPorts Lisp implementation. > +variant abcl description "Require lang/abcl for SLIME" { > + depends_run-append port:abcl > +} > + > +variant abcl description "Require lang/ccl for SLIME" { > + depends_run-append port:ccl > +} > + > +variant abcl description "Require lang/ecl for SLIME" { > + depends_run-append port:ccl > +} You have some variant-duplication and -description issues here. From brooks at clarksonline.net Thu Jan 14 18:42:09 2010 From: brooks at clarksonline.net (M. Brooks Clark) Date: Thu, 14 Jan 2010 20:42:09 -0600 Subject: [MacPorts] #23297: wview-5.12.1 -- updated portfile for latest release In-Reply-To: <059.05488b4f032a8ac959f15fa6db350392@macports.org> References: <059.05488b4f032a8ac959f15fa6db350392@macports.org> Message-ID: <406B3090-6165-48BD-A264-2C28B7D4562F@clarksonline.net> I posted an updated portfile for wview. I would appreciate it if someone would be kind enough to commit the new file. https://trac.macports.org/ticket/23297 Brooks http://www.clarkwx.net ________________________ From brooks at clarksonline.net Thu Jan 14 18:50:35 2010 From: brooks at clarksonline.net (M. Brooks Clark) Date: Thu, 14 Jan 2010 20:50:35 -0600 Subject: Request for commit rights In-Reply-To: <059.dbf3fc37ccc2af610e3b8031583e10f9@macports.org> References: <059.dbf3fc37ccc2af610e3b8031583e10f9@macports.org> Message-ID: <5D4321DB-B791-4A3F-92E4-8237073E98C9@clarksonline.net> I put together and have been maintaining the ports for radlib and wview for several years now, and I'd like to request permission to commit updated portfiles to the MacPorts distribution so I don't have to keep bugging folks on the list. Handle: mbclark e-mail: brooks at clarksonline.net Brooks http://www.clarkwx.net ________________________ From toby at macports.org Thu Jan 14 19:27:08 2010 From: toby at macports.org (Toby Peterson) Date: Thu, 14 Jan 2010 19:27:08 -0800 Subject: Request for commit rights In-Reply-To: <5D4321DB-B791-4A3F-92E4-8237073E98C9@clarksonline.net> References: <059.dbf3fc37ccc2af610e3b8031583e10f9@macports.org> <5D4321DB-B791-4A3F-92E4-8237073E98C9@clarksonline.net> Message-ID: wrong list http://guide.macports.org/#project.membership - Toby On Jan 14, 2010, at 6:50 PM, M. Brooks Clark wrote: > I put together and have been maintaining the ports for radlib and wview for several years now, and I'd like to request permission to commit updated portfiles to the MacPorts distribution so I don't have to keep bugging folks on the list. > > Handle: mbclark > > e-mail: brooks at clarksonline.net > > > Brooks > > http://www.clarkwx.net > ________________________ > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From evenson at panix.com Thu Jan 14 23:01:59 2010 From: evenson at panix.com (Mark Evenson) Date: Fri, 15 Jan 2010 08:01:59 +0100 Subject: [62712] trunk/dports/lang/slime/Portfile In-Reply-To: <2DF9179B-D712-43A2-92F1-391CC6A97F4B@macports.org> References: <20100114110536.6D6CE3C42134@beta.macosforge.org> <2DF9179B-D712-43A2-92F1-391CC6A97F4B@macports.org> Message-ID: <4B5012E7.4060107@panix.com> On 1/15/10 3:13 AM, Ryan Schmidt wrote: > > On Jan 14, 2010, at 05:05, easieste at macports.org wrote: > >> Revision: 62712 >> http://trac.macports.org/changeset/62712 >> Author: easieste at macports.org >> Date: 2010-01-14 03:05:34 -0800 (Thu, 14 Jan 2010) [?] > > You have some variant-duplication and -description issues here. > Fixed in svn r62730. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." From cristiano.fontana at gmail.com Fri Jan 15 03:31:36 2010 From: cristiano.fontana at gmail.com (Cristiano Fontana) Date: Fri, 15 Jan 2010 12:31:36 +0100 Subject: Portfile for GEANT4 In-Reply-To: <7E1A4DA2-E695-4972-A390-2D8073125CB8@macports.org> References: <87DE7456-78E0-4A9E-92A3-2113A464AD81@gmail.com> <4B4E31F5.7080100@macports.org> <7E1A4DA2-E695-4972-A390-2D8073125CB8@macports.org> Message-ID: Thank you! Now I am trying for the n-th time to compile GEANT and see if the installation gets to the end. While I am waiting I will post another question. Is there a way to set some environment variables that should be set at the beginning of any shell session? GEANT to work needs some variables to be set and provides a script that is supposed to be executed in the .porfile Do the uses has to put the script by hand in the .profile? Cristiano Il giorno 13/gen/2010, alle ore 22.43, Ryan Schmidt ha scritto: > > On Jan 13, 2010, at 14:49, Joshua Root wrote: > >> On 2010-1-14 06:48 , Cristiano Fontana wrote: >> >>> What I am trying is to execute their configure script through port so I defined the following phases: >>> >>> build { >>> catch { exec /bin/sh -c "cd ${worksrcpath}; ${worksrcpath}/Configure -build -d -f ${worksrcpath}/config.sh" } >>> } >>> >>> destroot { >>> catch { exec /bin/sh -c "cd ${worksrcpath}; ${worksrcpath}/Configure -install" } >>> } >> >> You should use the 'system' procedure to run shell commands. Like so: >> >> build { >> system "cd ${worksrcpath} && ./Configure -build -d -f config.sh" >> } >> >> destroot { >> system "cd ${worksrcpath} && ./Configure -install" } >> } >> >> You could also achieve the same effect by setting build.cmd, build.args, >> build.target, etc. as needed, but this is so different to a standard >> autotools build that that is probably the messier route. > > Personally, I would highly recommend trying to use build.cmd, build.args, etc, instead of overriding the phases. > > From raimue at macports.org Fri Jan 15 04:26:29 2010 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 15 Jan 2010 13:26:29 +0100 Subject: License option In-Reply-To: References: <710429CA-D407-4F02-B165-E31A50A3E488@macports.org> <4B4E478E.4000709@macports.org> <41467859-42EB-4A28-94B2-60DDBD2D6C73@apple.com> <24733D3F-0FDD-4A25-9485-31DFBAD5595E@macports.org> <4B4E58A6.40904@macports.org> <20100113235729.GJ76618@ambulatoryclam.net> <43DE0236-B356-42D0-AD7C-19D50A115013@gmail.com> <92A43828-C837-4A59-83C1-F7F479694D93@macports.org> Message-ID: <4B505EF5.7020007@macports.org> On 15.01.2010 00:07, Jeremy Lavergne wrote: > That's pretty straightforward for SourceForge projects: we can write > a licensecheck just like livecheck. What about something like "lint --guess"? It would try to find missing values (could also be used in the same way for other mandatory fields like categories or homepage). Although this still needs to be verified to be really sure, as a project might have left sf.net/freshmeat with incomplete/incorrect values. I don't think we really need yet another command just for this. Rainer From roederja at ethz.ch Fri Jan 15 06:32:27 2010 From: roederja at ethz.ch (=?UTF-8?B?SmFubiBSw7ZkZXI=?=) Date: Fri, 15 Jan 2010 15:32:27 +0100 Subject: Portfile for GEANT4 In-Reply-To: References: <87DE7456-78E0-4A9E-92A3-2113A464AD81@gmail.com> <4B4E31F5.7080100@macports.org> <7E1A4DA2-E695-4972-A390-2D8073125CB8@macports.org> Message-ID: One of my ports has the same problem, I just use a ui_msg in post-activate to tell the user about this. Since you don't know which shell a user is using (it's probably bash, but still) it will be quite hard to do this automatically, not to mention the trouble when upgrading or uninstalling the port. Jann Am 15.01.10 12:31, schrieb Cristiano Fontana: > Thank you! > Now I am trying for the n-th time to compile GEANT and see if the installation gets to the end. > While I am waiting I will post another question. > > Is there a way to set some environment variables that should be set at the beginning of any shell session? > GEANT to work needs some variables to be set and provides a script that is supposed to be executed in the .porfile > Do the uses has to put the script by hand in the .profile? > > Cristiano > > Il giorno 13/gen/2010, alle ore 22.43, Ryan Schmidt ha scritto: > >> >> On Jan 13, 2010, at 14:49, Joshua Root wrote: >> >>> On 2010-1-14 06:48 , Cristiano Fontana wrote: >>> >>>> What I am trying is to execute their configure script through port so I defined the following phases: >>>> >>>> build { >>>> catch { exec /bin/sh -c "cd ${worksrcpath}; ${worksrcpath}/Configure -build -d -f ${worksrcpath}/config.sh" } >>>> } >>>> >>>> destroot { >>>> catch { exec /bin/sh -c "cd ${worksrcpath}; ${worksrcpath}/Configure -install" } >>>> } >>> >>> You should use the 'system' procedure to run shell commands. Like so: >>> >>> build { >>> system "cd ${worksrcpath} && ./Configure -build -d -f config.sh" >>> } >>> >>> destroot { >>> system "cd ${worksrcpath} && ./Configure -install" } >>> } >>> >>> You could also achieve the same effect by setting build.cmd, build.args, >>> build.target, etc. as needed, but this is so different to a standard >>> autotools build that that is probably the messier route. >> >> Personally, I would highly recommend trying to use build.cmd, build.args, etc, instead of overriding the phases. >> >> > From raimue at macports.org Fri Jan 15 07:12:58 2010 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Fri, 15 Jan 2010 16:12:58 +0100 Subject: [62692] trunk/base/src/registry1.0/receipt_sqlite.tcl In-Reply-To: <20100113230712.566123C32BEC@beta.macosforge.org> References: <20100113230712.566123C32BEC@beta.macosforge.org> Message-ID: <4B5085FA.1000009@macports.org> On 2010-01-14 00:07 , jmr at macports.org wrote: > Revision: 62692 > http://trac.macports.org/changeset/62692 > Author: jmr at macports.org > Date: 2010-01-13 15:07:10 -0800 (Wed, 13 Jan 2010) > Log Message: > ----------- > remove receipt_sqlite.tcl > > Removed Paths: > ------------- > trunk/base/src/registry1.0/receipt_sqlite.tcl This means we need a special upgrade procedure for 1.9 to get rid of this file on systems where MacPorts was already installed, right? Rainer From jeremy at lavergne.gotdns.org Fri Jan 15 11:07:43 2010 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 15 Jan 2010 14:07:43 -0500 Subject: [62748] trunk/dports/aqua/qt4-mac/Portfile In-Reply-To: <20100115161323.A794C3C5C982@beta.macosforge.org> References: <20100115161323.A794C3C5C982@beta.macosforge.org> Message-ID: > Added (build) conflict with kdelibs4. If kdelibs4 depends on qt4-mac ... how can qt4-mac conflict with kdelibs4? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Fri Jan 15 11:36:51 2010 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 15 Jan 2010 14:36:51 -0500 Subject: Ports to Include with MacPorts Installer Image Message-ID: Have we considered bundling any packages with the MacPorts disk images that most packages use? Does anyone run any statistics on what are the most depended packages? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From macsforever2000 at macports.org Fri Jan 15 12:23:23 2010 From: macsforever2000 at macports.org (Frank Schima) Date: Fri, 15 Jan 2010 13:23:23 -0700 Subject: [62748] trunk/dports/aqua/qt4-mac/Portfile In-Reply-To: References: <20100115161323.A794C3C5C982@beta.macosforge.org> Message-ID: <61415DAF-939B-4711-9BC1-A35A8A1159BA@macports.org> On Jan 15, 2010, at 12:07 PM, Jeremy Lavergne wrote: >> Added (build) conflict with kdelibs4. > > If kdelibs4 depends on qt4-mac ... how can qt4-mac conflict with kdelibs4? Well unfortunately if kdelibs4 is active when qt4-mac is being built, qt4-mac will fail to build. The workaround is to deactivate kdelibs4 temporarily. See Cheers! Frank From jmr at macports.org Fri Jan 15 15:43:57 2010 From: jmr at macports.org (Joshua Root) Date: Sat, 16 Jan 2010 10:43:57 +1100 Subject: [62692] trunk/base/src/registry1.0/receipt_sqlite.tcl In-Reply-To: <4B5085FA.1000009@macports.org> References: <20100113230712.566123C32BEC@beta.macosforge.org> <4B5085FA.1000009@macports.org> Message-ID: <4B50FDBD.5060706@macports.org> On 2010-1-16 02:12 , Rainer M?ller wrote: > On 2010-01-14 00:07 , jmr at macports.org wrote: >> Revision: 62692 >> http://trac.macports.org/changeset/62692 >> Author: jmr at macports.org >> Date: 2010-01-13 15:07:10 -0800 (Wed, 13 Jan 2010) >> Log Message: >> ----------- >> remove receipt_sqlite.tcl >> >> Removed Paths: >> ------------- >> trunk/base/src/registry1.0/receipt_sqlite.tcl > > This means we need a special upgrade procedure for 1.9 to get rid of > this file on systems where MacPorts was already installed, right? I'd be inclined to just leave it, it's not like it's hurting anything. I'm pretty sure other files get left over from previous versions anyway. - Josh From jmr at macports.org Fri Jan 15 15:44:38 2010 From: jmr at macports.org (Joshua Root) Date: Sat, 16 Jan 2010 10:44:38 +1100 Subject: Portfile for GEANT4 In-Reply-To: References: <87DE7456-78E0-4A9E-92A3-2113A464AD81@gmail.com> <4B4E31F5.7080100@macports.org> <7E1A4DA2-E695-4972-A390-2D8073125CB8@macports.org> Message-ID: <4B50FDE6.7080307@macports.org> On 2010-1-16 01:32 , Jann R?der wrote: > One of my ports has the same problem, > I just use a ui_msg in post-activate to tell the user about this. You should actually use notes for this these days. - Josh From ryandesign at macports.org Fri Jan 15 22:59:07 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 16 Jan 2010 00:59:07 -0600 Subject: Ports to Include with MacPorts Installer Image In-Reply-To: References: Message-ID: <08CFEEBF-48FC-4955-ACF8-8ACD7196EF2E@macports.org> On Jan 15, 2010, at 13:36, Jeremy Lavergne wrote: > Have we considered bundling any packages with the MacPorts disk images that most packages use? No, I don't think we've considered that. What would be the benefit? Ports aren't hard to compile the usual way... > Does anyone run any statistics on what are the most depended packages? The port command doesn't collect statistics, and since we don't get distfiles from a central location, we don't have download statistics for those. We could add up the download statistics from each distfiles mirror (if we had logs available) to get part of the picture. But if the goal of getting that picture is to bundle pre-built packages with base, then I don't think we should be doing that. I'd rather we look into providing binaries of any package. From ryandesign at macports.org Fri Jan 15 23:10:22 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 16 Jan 2010 01:10:22 -0600 Subject: [62712] trunk/dports/lang/slime/Portfile In-Reply-To: <4B5012E7.4060107@panix.com> References: <20100114110536.6D6CE3C42134@beta.macosforge.org> <2DF9179B-D712-43A2-92F1-391CC6A97F4B@macports.org> <4B5012E7.4060107@panix.com> Message-ID: <09C8801C-5896-4681-A81A-B13ADE7A64FE@macports.org> On Jan 15, 2010, at 01:01, Mark Evenson wrote: > On 1/15/10 3:13 AM, Ryan Schmidt wrote: >> > >> On Jan 14, 2010, at 05:05, easieste at macports.org wrote: >> >>> Revision: 62712 >>> http://trac.macports.org/changeset/62712 >>> Author: easieste at macports.org >>> Date: 2010-01-14 03:05:34 -0800 (Thu, 14 Jan 2010) > [?] >> >> You have some variant-duplication and -description issues here. > > Fixed in svn r62730. Almost! But you still have two "abcl" variants. From cristiano.fontana at gmail.com Sat Jan 16 05:16:54 2010 From: cristiano.fontana at gmail.com (Cristiano Fontana) Date: Sat, 16 Jan 2010 14:16:54 +0100 Subject: Portfile for GEANT4 In-Reply-To: <4B50FDE6.7080307@macports.org> References: <87DE7456-78E0-4A9E-92A3-2113A464AD81@gmail.com> <4B4E31F5.7080100@macports.org> <7E1A4DA2-E695-4972-A390-2D8073125CB8@macports.org> <4B50FDE6.7080307@macports.org> Message-ID: What are notes how can I use them? Another question: I have a bunch of data files that geant needs. Each of those files has a version number on it so I wanted to use a variable to define the version. I tried with: # Data files versions G4NDL_v 3.13 G4EMLOW_v 6.9 PhotonEvaporation_v 2.0 RadioactiveDecay_v 3.2 G4ABLA_v 3.0 RealSurface_v 1.0 distfiles geant${version}.tar.gz \ G4NDL.${G4NDL_v}.tar.gz \ G4EMLOW.${G4EMLOW_v}.tar.gz \ PhotonEvaporation.${PhotonEvaporation_v}.tar.gz \ G4RadioactiveDecay.${RadioactiveDecay_v}.tar.gz \ G4ABLA.${G4ABLA_v}.tar.gz \ RealSurface.${RealSurface_v}.tar.gz but i get the error: invalid command name "G4NDL_v" Il giorno 16/gen/2010, alle ore 00.44, Joshua Root ha scritto: > On 2010-1-16 01:32 , Jann R?der wrote: >> One of my ports has the same problem, >> I just use a ui_msg in post-activate to tell the user about this. > > You should actually use notes for this these days. > > - Josh > _______________________________________________ > 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 Sat Jan 16 08:25:25 2010 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 16 Jan 2010 11:25:25 -0500 Subject: Ports to Include with MacPorts Installer Image In-Reply-To: <08CFEEBF-48FC-4955-ACF8-8ACD7196EF2E@macports.org> References: <08CFEEBF-48FC-4955-ACF8-8ACD7196EF2E@macports.org> Message-ID: >> Have we considered bundling any packages with the MacPorts disk images that most packages use? > > No, I don't think we've considered that. What would be the benefit? Ports aren't hard to compile the usual way... Example: if zlib is required by 90% of the ports we have, we should go ahead and bundle it with the installer. >> Does anyone run any statistics on what are the most depended packages? > > The port command doesn't collect statistics, and since we don't get distfiles from a central location, we don't have download statistics for those. We could add up the download statistics from each distfiles mirror (if we had logs available) to get part of the picture. But if the goal of getting that picture is to bundle pre-built packages with base, then I don't think we should be doing that. I'd rather we look into providing binaries of any package. You don't need download statistics: just look at the portfile dependencies and see what ends up being required the most. I'm thinking zlib is likely to be one. -------------- 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 Jan 16 10:56:15 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 16 Jan 2010 12:56:15 -0600 Subject: Ports to Include with MacPorts Installer Image In-Reply-To: References: <08CFEEBF-48FC-4955-ACF8-8ACD7196EF2E@macports.org> Message-ID: <67ADA893-3784-40EF-89AF-14AFE278F20A@macports.org> On Jan 16, 2010, at 10:25, Jeremy Lavergne wrote: >>> Have we considered bundling any packages with the MacPorts disk images that most packages use? >> >> No, I don't think we've considered that. What would be the benefit? Ports aren't hard to compile the usual way... > > Example: if zlib is required by 90% of the ports we have, we should go ahead and bundle it with the installer. > I'm thinking zlib is likely to be one. Probably. zlib also doesn't change often, which would be good for this application; if the dependency you bundle with MacPorts is updated often, like say sqlite3, then bundling it is pointless, because the user will likely be upgrading it right away anyway. But zlib is also small and only takes seconds to build. We don't have any mechanism in place to allow ports to come pre-installed. I have a feeling it would take more time and effort to create all that infrastructure than it would save. From ryandesign at macports.org Sat Jan 16 10:57:35 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 16 Jan 2010 12:57:35 -0600 Subject: Portfile for GEANT4 In-Reply-To: References: <87DE7456-78E0-4A9E-92A3-2113A464AD81@gmail.com> <4B4E31F5.7080100@macports.org> <7E1A4DA2-E695-4972-A390-2D8073125CB8@macports.org> <4B50FDE6.7080307@macports.org> Message-ID: On Jan 16, 2010, at 07:16, Cristiano Fontana wrote: > What are notes how can I use them? Just like the description or long_description. Put the word "notes" followed by your notes, using backslash to continue onto additional lines if desired. > Another question: > I have a bunch of data files that geant needs. Each of those files has a version number on it so I wanted to use a variable to define the version. > I tried with: > # Data files versions > G4NDL_v 3.13 > G4EMLOW_v 6.9 > PhotonEvaporation_v 2.0 > RadioactiveDecay_v 3.2 > G4ABLA_v 3.0 > RealSurface_v 1.0 > > distfiles geant${version}.tar.gz \ > G4NDL.${G4NDL_v}.tar.gz \ > G4EMLOW.${G4EMLOW_v}.tar.gz \ > PhotonEvaporation.${PhotonEvaporation_v}.tar.gz \ > G4RadioactiveDecay.${RadioactiveDecay_v}.tar.gz \ > G4ABLA.${G4ABLA_v}.tar.gz \ > RealSurface.${RealSurface_v}.tar.gz > > but i get the error: > invalid command name "G4NDL_v" Non-built-in variables must be set with the "set" command. set G4NDL_v 3.13 set G4EMLOW_v 6.9 set PhotonEvaporation_v 2.0 etc. From nox at macports.org Sat Jan 16 11:21:16 2010 From: nox at macports.org (nox) Date: Sat, 16 Jan 2010 20:21:16 +0100 Subject: Ports to Include with MacPorts Installer Image In-Reply-To: <67ADA893-3784-40EF-89AF-14AFE278F20A@macports.org> References: <08CFEEBF-48FC-4955-ACF8-8ACD7196EF2E@macports.org> <67ADA893-3784-40EF-89AF-14AFE278F20A@macports.org> Message-ID: If we ever go that way, let's borrow the package set concept of Portage. Le 16 janv. 2010 ? 19:56, Ryan Schmidt a ?crit : > > On Jan 16, 2010, at 10:25, Jeremy Lavergne wrote: > >>>> Have we considered bundling any packages with the MacPorts disk images that most packages use? >>> >>> No, I don't think we've considered that. What would be the benefit? Ports aren't hard to compile the usual way... >> >> Example: if zlib is required by 90% of the ports we have, we should go ahead and bundle it with the installer. > >> I'm thinking zlib is likely to be one. > > Probably. zlib also doesn't change often, which would be good for this application; if the dependency you bundle with MacPorts is updated often, like say sqlite3, then bundling it is pointless, because the user will likely be upgrading it right away anyway. > > But zlib is also small and only takes seconds to build. We don't have any mechanism in place to allow ports to come pre-installed. I have a feeling it would take more time and effort to create all that infrastructure than it would save. > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From cristiano.fontana at gmail.com Sat Jan 16 15:45:00 2010 From: cristiano.fontana at gmail.com (Cristiano Fontana) Date: Sun, 17 Jan 2010 00:45:00 +0100 Subject: Portfile for GEANT4 In-Reply-To: References: <87DE7456-78E0-4A9E-92A3-2113A464AD81@gmail.com> <4B4E31F5.7080100@macports.org> <7E1A4DA2-E695-4972-A390-2D8073125CB8@macports.org> <4B50FDE6.7080307@macports.org> Message-ID: <445C5431-26B0-4172-A32E-73133F79D165@gmail.com> Thank you again! I am working on the destroot phase now but I could not get xinstall to install full directory trees. Since xinstall complains if asked to install a directory I can not use it. Is there a simple way to do it? I tried with the suggestion of the guide: eval xinstall [glob ${workpath}/G4NDL${G4NDL_v}/*] ${destroot}${prefix}/share/geant4/data/G4NDL${G4NDL_v} But it did not work: Error: Target org.macports.destroot returned: xinstall: Inappropriate file type: /opt/local/var/macports/build/_Users_fontana_ports_science_geant4/work/G4NDL3.13/Capture because that capture is a directory. So I tried with some loops: foreach data {G4NDL${G4NDL_v} \ G4EMLOW${G4EMLOW_v} \ PhotonEvaporation${PhotonEvaporation_v} \ RadioactiveDecay${RadioactiveDecay_v} \ G4ABLA${G4ABLA_v} \ RealSurface${RealSurface_v}} { puts "-> Installing ${data}" foreach directory [exec find ${workpath}/${data}/ -type d ] { puts "--> Creating ${prefix}/share/geant4/data/${directory}" xinstall -d ${destroot}${prefix}/share/geant4/data/${directory} foreach file [glob -nocomplain -type f ${directory}/*] { puts "---> Installing ${file} to ${prefix}/share/geant4/data/${directory}" xinstall ${file} ${destroot}${prefix}/share/geant4/data/${directory}" } } } but this works only if the current directory is the one that contains the directories: G4NDL${G4NDL_v} G4EMLOW${G4EMLOW_v} ... Besides, the interpreter does not substitute the variables ${G4NDL_v} with their values: Error: Target org.macports.destroot returned: find: /opt/local/var/macports/build/_Users_fontana_ports_science_geant4/work/G4NDL${G4NDL_v}/: No such file or directory But if I put a line like: puts "G4NDL${G4NDL_v} G4EMLOW${G4EMLOW_v} PhotonEvaporation${PhotonEvaporation_v} RadioactiveDecay${RadioactiveDecay_v} G4ABLA${G4ABLA_v} RealSurface${RealSurface_v}" it gives the expected result: G4NDL3.13 G4EMLOW6.9 PhotonEvaporation2.0 RadioactiveDecay3.2 G4ABLA3.0 RealSurface1.0 I am sorry for all these questions but it is kinda hard to get my grip on MacPorts scripts... Il giorno 16/gen/2010, alle ore 19.57, Ryan Schmidt ha scritto: > > On Jan 16, 2010, at 07:16, Cristiano Fontana wrote: > >> What are notes how can I use them? > > Just like the description or long_description. Put the word "notes" followed by your notes, using backslash to continue onto additional lines if desired. > > >> Another question: >> I have a bunch of data files that geant needs. Each of those files has a version number on it so I wanted to use a variable to define the version. >> I tried with: >> # Data files versions >> G4NDL_v 3.13 >> G4EMLOW_v 6.9 >> PhotonEvaporation_v 2.0 >> RadioactiveDecay_v 3.2 >> G4ABLA_v 3.0 >> RealSurface_v 1.0 >> >> distfiles geant${version}.tar.gz \ >> G4NDL.${G4NDL_v}.tar.gz \ >> G4EMLOW.${G4EMLOW_v}.tar.gz \ >> PhotonEvaporation.${PhotonEvaporation_v}.tar.gz \ >> G4RadioactiveDecay.${RadioactiveDecay_v}.tar.gz \ >> G4ABLA.${G4ABLA_v}.tar.gz \ >> RealSurface.${RealSurface_v}.tar.gz >> >> but i get the error: >> invalid command name "G4NDL_v" > > Non-built-in variables must be set with the "set" command. > > set G4NDL_v 3.13 > set G4EMLOW_v 6.9 > set PhotonEvaporation_v 2.0 > > etc. > From ryandesign at macports.org Sat Jan 16 15:58:28 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 16 Jan 2010 17:58:28 -0600 Subject: Portfile for GEANT4 In-Reply-To: <445C5431-26B0-4172-A32E-73133F79D165@gmail.com> References: <87DE7456-78E0-4A9E-92A3-2113A464AD81@gmail.com> <4B4E31F5.7080100@macports.org> <7E1A4DA2-E695-4972-A390-2D8073125CB8@macports.org> <4B50FDE6.7080307@macports.org> <445C5431-26B0-4172-A32E-73133F79D165@gmail.com> Message-ID: <7BBB005F-F9A1-49E5-8F83-4132B602494A@macports.org> On Jan 16, 2010, at 17:45, Cristiano Fontana wrote: > Thank you again! > > I am working on the destroot phase now but I could not get xinstall to install full directory trees. > Since xinstall complains if asked to install a directory I can not use it. > Is there a simple way to do it? > I tried with the suggestion of the guide: > > eval xinstall [glob ${workpath}/G4NDL${G4NDL_v}/*] ${destroot}${prefix}/share/geant4/data/G4NDL${G4NDL_v} > > But it did not work: > > Error: Target org.macports.destroot returned: xinstall: Inappropriate file type: /opt/local/var/macports/build/_Users_fontana_ports_science_geant4/work/G4NDL3.13/Capture > > because that capture is a directory. Right, xinstall copies files only, not directories. Try file copy: file copy ${workpath}/G4NDL${G4NDL_v} ${destroot}${prefix}/share/geant4/data > So I tried with some loops: > > foreach data {G4NDL${G4NDL_v} \ > G4EMLOW${G4EMLOW_v} \ > PhotonEvaporation${PhotonEvaporation_v} \ > RadioactiveDecay${RadioactiveDecay_v} \ > G4ABLA${G4ABLA_v} \ > RealSurface${RealSurface_v}} { > > puts "-> Installing ${data}" > foreach directory [exec find ${workpath}/${data}/ -type d ] { > puts "--> Creating ${prefix}/share/geant4/data/${directory}" > xinstall -d ${destroot}${prefix}/share/geant4/data/${directory} > foreach file [glob -nocomplain -type f ${directory}/*] { > puts "---> Installing ${file} to ${prefix}/share/geant4/data/${directory}" > xinstall ${file} ${destroot}${prefix}/share/geant4/data/${directory}" > } > } > } > > but this works only if the current directory is the one that contains the directories: G4NDL${G4NDL_v} G4EMLOW${G4EMLOW_v} ... > > Besides, the interpreter does not substitute the variables ${G4NDL_v} with their values: > > Error: Target org.macports.destroot returned: find: /opt/local/var/macports/build/_Users_fontana_ports_science_geant4/work/G4NDL${G4NDL_v}/: No such file or directory > > But if I put a line like: > > puts "G4NDL${G4NDL_v} G4EMLOW${G4EMLOW_v} PhotonEvaporation${PhotonEvaporation_v} RadioactiveDecay${RadioactiveDecay_v} G4ABLA${G4ABLA_v} RealSurface${RealSurface_v}" > > it gives the expected result: > > G4NDL3.13 G4EMLOW6.9 PhotonEvaporation2.0 RadioactiveDecay3.2 G4ABLA3.0 RealSurface1.0 Variables expand inside double-quoted strings: "variables expand here: ${name}" but not inside curly-bracket-quoted strings: {variables don't expand here: ${name}} > I am sorry for all these questions but it is kinda hard to get my grip on MacPorts scripts... No problem! Ask away. From talklists at newgeo.com Sat Jan 16 19:44:31 2010 From: talklists at newgeo.com (Scott Haneda) Date: Sat, 16 Jan 2010 19:44:31 -0800 Subject: How to add universal support to a portfile? Message-ID: <75DB9644-E124-45F0-86C5-406B2721B8E8@newgeo.com> I asked this on the users list, either I missed the rely, or my post got missed, but I am genuinely curious.. How do I adjust portfiles to be able to support +universal? $port info php5-mcrypt Variants: debug, universal I do not see anything in that Portfile that has debug or universal. When I compare that to a simple Portfile of my own, memtester: $port info memtester memtester @4.1.2 (sysutils) Description: A userspace utility for testing the memory subsystem for faults. Homepage: http://pyropus.ca/software/memtester/ Platforms: darwin License: unknown I am not sure how you get universal and debug into your Portfile, since there is no explicit code that is offering it. I would like to allow memtester to be built as universal, I just do not know what to add to the Portfile to make that a variant option. Thanks. -- Scott * If you contact me off list replace talklists@ with scott@ * From jmr at macports.org Sat Jan 16 20:09:48 2010 From: jmr at macports.org (Joshua Root) Date: Sun, 17 Jan 2010 15:09:48 +1100 Subject: How to add universal support to a portfile? In-Reply-To: <75DB9644-E124-45F0-86C5-406B2721B8E8@newgeo.com> References: <75DB9644-E124-45F0-86C5-406B2721B8E8@newgeo.com> Message-ID: <4B528D8C.6090200@macports.org> On 2010-1-17 14:44 , Scott Haneda wrote: > I asked this on the users list, either I missed the rely, or my post got missed, but I am genuinely curious.. > > How do I adjust portfiles to be able to support +universal? > > $port info php5-mcrypt > Variants: debug, universal > > I do not see anything in that Portfile that has debug or universal. When I compare that to a simple Portfile of my own, memtester: The debug variant is added in the php5extension portgroup. > $port info memtester > memtester @4.1.2 (sysutils) > > Description: A userspace utility for testing the memory subsystem for > faults. > Homepage: http://pyropus.ca/software/memtester/ > > Platforms: darwin > License: unknown > > I am not sure how you get universal and debug into your Portfile, since there is no explicit code that is offering it. > > I would like to allow memtester to be built as universal, I just do not know what to add to the Portfile to make that a variant option. For memtester, debug mode says: DEBUG: not using configure, so not adding the default universal variant The default universal variant can only work if the port uses a configure script (or xcodebuild). Exactly what needs to be done to make a port build universal varies greatly, but usually boils down to somehow getting the build system to use the right flags: You add the code to make it do this in a universal variant. - Josh From sharky at macports.org Sun Jan 17 08:26:28 2010 From: sharky at macports.org (=?ISO-8859-1?Q?Jeremy_Lain=E9?=) Date: Sun, 17 Jan 2010 17:26:28 +0100 Subject: [62666] trunk/dports/devel/git-core/Portfile In-Reply-To: <62588784-8618-46C1-A41F-A0B7A6B5C6E8@macports.org> References: <20100113172551.84CC53C2BE14@beta.macosforge.org> <62588784-8618-46C1-A41F-A0B7A6B5C6E8@macports.org> Message-ID: <4B533A34.9060401@macports.org> Ryan Schmidt wrote: > On Jan 13, 2010, at 11:25, sharky at macports.org wrote: > >> set CFLAGS "-Wall -O2 -I${prefix}/include ${configure.cc_archflags}" >> -set LDFLAGS "-L${prefix}/lib ${configure.ld_archflags}" >> +set LDFLAGS "-L${prefix}/lib" >> >> build.args CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" \ >> CC=${configure.cc} \ > > I'm curious why you're setting new variables CFLAGS and LDFLAGS, and not using the variables that already exist for this purpose, namely configure.cflags, configure.cppflags, configure.cxxflags, configure.ldflags, etc. I did not write the original recipe, I just wanted it to compile when archflags are set. Your way sounds better though! Jeremy From cristiano.fontana at gmail.com Sun Jan 17 12:08:34 2010 From: cristiano.fontana at gmail.com (Cristiano Fontana) Date: Sun, 17 Jan 2010 21:08:34 +0100 Subject: Portfile for GEANT4 In-Reply-To: <7BBB005F-F9A1-49E5-8F83-4132B602494A@macports.org> References: <87DE7456-78E0-4A9E-92A3-2113A464AD81@gmail.com> <4B4E31F5.7080100@macports.org> <7E1A4DA2-E695-4972-A390-2D8073125CB8@macports.org> <4B50FDE6.7080307@macports.org> <445C5431-26B0-4172-A32E-73133F79D165@gmail.com> <7BBB005F-F9A1-49E5-8F83-4132B602494A@macports.org> Message-ID: <7357F2B1-E984-4CF4-B1F9-E0C1C5C9C4C4@gmail.com> I did it! :D I finally managed to get the Portfile to work! Now I need someone to test and check it. https://trac.macports.org/ticket/23323 Il giorno 17/gen/2010, alle ore 00.58, Ryan Schmidt ha scritto: > On Jan 16, 2010, at 17:45, Cristiano Fontana wrote: > >> Thank you again! >> >> I am working on the destroot phase now but I could not get xinstall to install full directory trees. >> Since xinstall complains if asked to install a directory I can not use it. >> Is there a simple way to do it? > >> I tried with the suggestion of the guide: >> >> eval xinstall [glob ${workpath}/G4NDL${G4NDL_v}/*] ${destroot}${prefix}/share/geant4/data/G4NDL${G4NDL_v} >> >> But it did not work: >> >> Error: Target org.macports.destroot returned: xinstall: Inappropriate file type: /opt/local/var/macports/build/_Users_fontana_ports_science_geant4/work/G4NDL3.13/Capture >> >> because that capture is a directory. > > Right, xinstall copies files only, not directories. Try file copy: > > file copy ${workpath}/G4NDL${G4NDL_v} ${destroot}${prefix}/share/geant4/data > > >> So I tried with some loops: >> >> foreach data {G4NDL${G4NDL_v} \ >> G4EMLOW${G4EMLOW_v} \ >> PhotonEvaporation${PhotonEvaporation_v} \ >> RadioactiveDecay${RadioactiveDecay_v} \ >> G4ABLA${G4ABLA_v} \ >> RealSurface${RealSurface_v}} { >> >> puts "-> Installing ${data}" >> foreach directory [exec find ${workpath}/${data}/ -type d ] { >> puts "--> Creating ${prefix}/share/geant4/data/${directory}" >> xinstall -d ${destroot}${prefix}/share/geant4/data/${directory} >> foreach file [glob -nocomplain -type f ${directory}/*] { >> puts "---> Installing ${file} to ${prefix}/share/geant4/data/${directory}" >> xinstall ${file} ${destroot}${prefix}/share/geant4/data/${directory}" >> } >> } >> } >> >> but this works only if the current directory is the one that contains the directories: G4NDL${G4NDL_v} G4EMLOW${G4EMLOW_v} ... >> >> Besides, the interpreter does not substitute the variables ${G4NDL_v} with their values: >> >> Error: Target org.macports.destroot returned: find: /opt/local/var/macports/build/_Users_fontana_ports_science_geant4/work/G4NDL${G4NDL_v}/: No such file or directory >> >> But if I put a line like: >> >> puts "G4NDL${G4NDL_v} G4EMLOW${G4EMLOW_v} PhotonEvaporation${PhotonEvaporation_v} RadioactiveDecay${RadioactiveDecay_v} G4ABLA${G4ABLA_v} RealSurface${RealSurface_v}" >> >> it gives the expected result: >> >> G4NDL3.13 G4EMLOW6.9 PhotonEvaporation2.0 RadioactiveDecay3.2 G4ABLA3.0 RealSurface1.0 > > Variables expand inside double-quoted strings: > > "variables expand here: ${name}" > > but not inside curly-bracket-quoted strings: > > {variables don't expand here: ${name}} > > >> I am sorry for all these questions but it is kinda hard to get my grip on MacPorts scripts... > > No problem! Ask away. > From ryandesign at macports.org Mon Jan 18 16:03:59 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 18 Jan 2010 18:03:59 -0600 Subject: [62834] trunk/dports/sysutils/backuppc/Portfile In-Reply-To: <20100118230440.428673CBB6D4@beta.macosforge.org> References: <20100118230440.428673CBB6D4@beta.macosforge.org> Message-ID: On Jan 18, 2010, at 17:04, jameskyle at macports.org wrote: > Revision: 62834 > http://trac.macports.org/changeset/62834 > Author: jameskyle at macports.org > Date: 2010-01-18 15:04:36 -0800 (Mon, 18 Jan 2010) > Log Message: > ----------- > Corrected dependencies for port change from p5-compress-zlib to p5-compress-raw-zlib. Ticket #22477. Please remember to make whitespace changes separately from functional changes in the future. This makes diffs much easier to look at. Thanks. From ryandesign at macports.org Tue Jan 19 12:22:02 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 19 Jan 2010 14:22:02 -0600 Subject: [62767] trunk/dports/math/atlas In-Reply-To: <20100116201912.291893C7C9C5@beta.macosforge.org> References: <20100116201912.291893C7C9C5@beta.macosforge.org> Message-ID: <5509F413-210C-444B-906A-D9A2F5757375@macports.org> On Jan 16, 2010, at 14:19, jameskyle at macports.org wrote: > Modified Paths: > -------------- > trunk/dports/math/atlas/Portfile > trunk/dports/math/atlas/files/Portfile Why is there a files/Portfile? Can it be removed? From dports at ambulatoryclam.net Wed Jan 20 17:32:39 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Wed, 20 Jan 2010 17:32:39 -0800 Subject: dbus and launchd Message-ID: <20100121013239.GA8656@ambulatoryclam.net> I've been having a bunch of problems with dbus launching lately. Based on the number of tickets I found, I haven't been the only one. I finally found some time to look into it. In my case at least, there were a couple independent problems. For reference, dbus starts both a "system bus" which is one-per-host, and a "session bus" which is per-user (i.e. per-login-session). 1) The dbus system bus creates a pidfile, /opt/local/var/run/dbus/pid, meaning that if the system crashes and the pidfile isn't removed, it fails to restart. This is exactly ticket #15081, which is resolved fixed, but the problem persists. I believe the solution here is to not use a pidfile since it's not needed under launchd -- I've posted a patch in that ticket. 2) The dbus session bus, which is looked up via launchd, is inaccessible from within screen. I think this is because the session bus gets started as part of an Aqua session, and screen moves to a background session when launching. (I could have something wrong here -- I haven't found much documentation on the launchd changes in 10.6, and Apple has patched screen to undocumented private launchd methods.) I think starting the dbus launchd job in a Background session instead of Aqua would solve my particular problem, but is probably the wrong thing to do. IIRC, dbus is supposed to be per-GUI-session. I suspect the real problem here is with screen, but I don't see how to fix it either way. Does anyone have any insights? 3) Both launchd jobs have launch-on-demand disabled, I think because it didn't work correctly on Tiger. Now that Tiger is borderline unsupported, should we reconsider this? (We can make it a platform variant to keep from breaking TIger unnecessarily) Moving to on-demand would also make it pretty reasonable in my view to enable the launchd jobs on port install, eliminating the need for users to run two launchctl load commands (of which one needs to be run as root and the other *not* as root!) Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ From ryandesign at macports.org Wed Jan 20 22:12:17 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 21 Jan 2010 00:12:17 -0600 Subject: dbus and launchd In-Reply-To: <20100121013239.GA8656@ambulatoryclam.net> References: <20100121013239.GA8656@ambulatoryclam.net> Message-ID: <8D686DE0-3433-4635-91D3-4B5AC0508DBF@macports.org> On Jan 20, 2010, at 19:32, Dan Ports wrote: > 3) Both launchd jobs have launch-on-demand disabled, I think because it > didn't work correctly on Tiger. Now that Tiger is borderline > unsupported, should we reconsider this? (We can make it a platform > variant to keep from breaking TIger unnecessarily) > > Moving to on-demand would also make it pretty reasonable in my view > to enable the launchd jobs on port install, eliminating the need for > users to run two launchctl load commands (of which one needs to be > run as root and the other *not* as root!) On-demand launching has been requested in some of my ports (see tickets) but I declined, saying it should be handled in base. I haven't used on-demand plists so I don't know about any bugs involved. Are there any downsides to on-demand launching? Should it be an option in macports.conf? From raimue at macports.org Thu Jan 21 05:26:44 2010 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 21 Jan 2010 14:26:44 +0100 Subject: dbus and launchd In-Reply-To: <8D686DE0-3433-4635-91D3-4B5AC0508DBF@macports.org> References: <20100121013239.GA8656@ambulatoryclam.net> <8D686DE0-3433-4635-91D3-4B5AC0508DBF@macports.org> Message-ID: <4B585614.5050401@macports.org> On 2010-01-21 07:12 , Ryan Schmidt wrote: >> Moving to on-demand would also make it pretty reasonable in my >> view to enable the launchd jobs on port install, eliminating the >> need for users to run two launchctl load commands (of which one >> needs to be run as root and the other *not* as root!) > > On-demand launching has been requested in some of my ports (see > tickets) but I declined, saying it should be handled in base. I > haven't used on-demand plists so I don't know about any bugs > involved. Are there any downsides to on-demand launching? Should it > be an option in macports.conf? First of all, the documentation for launchd files can be found in the man page launchd.plist(5), which might have instant answers to any questions coming up. OnDemand is a deprecated key from <=10.4 and has been replaced with KeepAlive as of 10.5. It specifies if a daemon should be kept running all the time (false) or only started when necessary based on network state, sockets, file paths, ... (true). KeepAlive was introduced to support some more fine-grained conditions. launchd files created by MacPorts always set OnDemand to false. Note that all files are being installed with Disabled set to true, so that the user needs to load the file manually. This is a reasonable decision as the user might want to edit the configuration in /opt/local/etc before running the daemon. As it might open ports and provide services on the network it should not do this without approval of the user in general. Rainer From dports at ambulatoryclam.net Thu Jan 21 11:06:48 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Thu, 21 Jan 2010 11:06:48 -0800 Subject: dbus and launchd In-Reply-To: <4B585614.5050401@macports.org> References: <20100121013239.GA8656@ambulatoryclam.net> <8D686DE0-3433-4635-91D3-4B5AC0508DBF@macports.org> <4B585614.5050401@macports.org> Message-ID: <20100121190648.GB8656@ambulatoryclam.net> On Thu, Jan 21, 2010 at 02:26:44PM +0100, Rainer M?ller wrote: > OnDemand is a deprecated key from <=10.4 and has been replaced with > KeepAlive as of 10.5. It specifies if a daemon should be kept running > all the time (false) or only started when necessary based on network > state, sockets, file paths, ... (true). KeepAlive was introduced to > support some more fine-grained conditions. launchd files created by > MacPorts always set OnDemand to false. > Note that all files are being installed with Disabled set to true, so > that the user needs to load the file manually. This is a reasonable > decision as the user might want to edit the configuration in > /opt/local/etc before running the daemon. As it might open ports and > provide services on the network it should not do this without approval > of the user in general. This is one of the things I was wondering about -- what the policy is (if one exists) for ports with launchd plists. I think it's quite reasonable that externally-accessible network services shouldn't be enabled by default. (Note, though, that this isn't universally agreed -- on Debian/Ubuntu, for example, installing a package enables it and starts it up right away. I find this slightly alarming!) It may be useful to distinguish services that are only accessible locally. For these, it makes some sense to enable them by default if their default configuration is reasonable. Especially so if launchd can start them on-demand, keeping the overhead to a minimum if not actually used. dbus is the main example that comes to mind here, though there are probably others. My thinking is "would I want this enabled if it got sucked in as a dependency and I had no idea it was installed?". For dbus, I'd say my answer is yes -- there's not much downside since it's not accessible over the network and can be started on demand, and without it loaded, dependent apps don't work. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ From dports at ambulatoryclam.net Thu Jan 21 11:23:46 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Thu, 21 Jan 2010 11:23:46 -0800 Subject: dbus and launchd In-Reply-To: <8D686DE0-3433-4635-91D3-4B5AC0508DBF@macports.org> References: <20100121013239.GA8656@ambulatoryclam.net> <8D686DE0-3433-4635-91D3-4B5AC0508DBF@macports.org> Message-ID: <20100121192346.GC8656@ambulatoryclam.net> On Thu, Jan 21, 2010 at 12:12:17AM -0600, Ryan Schmidt wrote: > On-demand launching has been requested in some of my ports (see tickets) but I declined, saying it should be handled in base. I haven't used on-demand plists so I don't know about any bugs involved. Are there any downsides to on-demand launching? Should it be an option in macports.conf? I can't claim any expertise with on-demand launching, although it sounds like a great feature to me. I don't know the details of how on-demand was broken in 10.4 other than that I saw the claim repeatedly in reference to dbus, but launchd definitely changed substantially in 10.5: in particular, OnDemand became the more flexible KeepAlive. Which suggests to me that being compatible with both Tiger and later versions would at least be non-trivial, though perhaps that's not such an issue anymore. Besides Rainer's suggestion of launchd.plist(5), another useful reference is TN2083 "Daemons and Agents": http://developer.apple.com/mac/library/technotes/tn2005/tn2083.html but unfortunately it doesn't seem to have been updated for 10.6. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ From ryandesign at macports.org Thu Jan 21 12:45:08 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 21 Jan 2010 14:45:08 -0600 Subject: [MacPorts] Migration modified In-Reply-To: <20100121200141.C140F8121435@mail-out3.apple.com> References: <20100121200141.C140F8121435@mail-out3.apple.com> Message-ID: On Jan 21, 2010, at 14:01, MacPorts wrote: > Changed page "Migration" by lemontea_cafe at mac.com from 17.208.104.133* > Page URL: > Diff URL: > Revision 19 > > -------8<------8<------8<------8<------8<------8<------8<------8<-------- > Index: Migration > ========================================================================= > --- Migration (version: 18) > +++ Migration (version: 19) > @@ -27,3 +27,6 @@ > sudo port install portname +variant1 +variant2 ... > }}} > Note that if you have specified variants which are not the default, you may need to install ports in an order other than the alphabetical order recorded in `myports.txt`. > + > +=== Automated script === > +Attached is a shell script that automatically does the above and reinstall back the active ports. I don't think we want this shell script. Certainly its position in the wiki makes it look official, and I can't endorse it. It doesn't, for example, take into account three important aspects of the Migration process: 1. "install the ports that you actually want to use (as opposed to those that are only needed as dependencies)" (it installs all ports), 2. "remembering to specify the appropriate variants" (it discards variants), and 3. "if you have specified variants which are not the default, you may need to install ports in an order other than the alphabetical order recorded in myports.txt" (it installs them in alphabetical order) It also has "MacPorts" misspelled... From dports at ambulatoryclam.net Thu Jan 21 13:06:13 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Thu, 21 Jan 2010 13:06:13 -0800 Subject: [MacPorts] Migration modified In-Reply-To: References: <20100121200141.C140F8121435@mail-out3.apple.com> Message-ID: <20100121210613.GF8656@ambulatoryclam.net> On Thu, Jan 21, 2010 at 02:45:08PM -0600, Ryan Schmidt wrote: > I don't think we want this shell script. Certainly its position in the wiki makes it look official, and I can't endorse it. It doesn't, for example, take into account three important aspects of the Migration process: I'll take your word on this particular shell script (I haven't looked at it) -- but I think that such a script, if done right, would be a great thing to have. When I upgraded to Snow Leopard, I found the migration process about as far from user-friendly as possible. Aside from the (understandable) need to rebuild everything, the instructions weren't easy to follow with a lot of ports installed: - what are the ports I actually want to use vs dependencies? Easy to miss some when picking them out of a list of hundreds of installed ports. - what are the non-default variants I specified? I wound up searching for '+'s to find them, but that also matches +darwin, etc. - what order to install them? I don't know the entire dependency tree offhand... These seem like they'd be comparatively easy to track/compute programatically, especially if someday port can keep track of what's installed by explicit request vs dependencies. I realize that this is probably an issue of time rather than anything else, but I just wanted to throw my experiences out there. Perhaps someday I'll actually find time to do something about it. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ From blair at orcaware.com Thu Jan 21 13:08:10 2010 From: blair at orcaware.com (Blair Zajac) Date: Thu, 21 Jan 2010 13:08:10 -0800 Subject: [MacPorts] Migration modified In-Reply-To: <20100121210613.GF8656@ambulatoryclam.net> References: <20100121200141.C140F8121435@mail-out3.apple.com> <20100121210613.GF8656@ambulatoryclam.net> Message-ID: <4B58C23A.2070909@orcaware.com> On 01/21/2010 01:06 PM, Dan Ports wrote: > On Thu, Jan 21, 2010 at 02:45:08PM -0600, Ryan Schmidt wrote: >> I don't think we want this shell script. Certainly its position in the wiki makes it look official, and I can't endorse it. It doesn't, for example, take into account three important aspects of the Migration process: > > I'll take your word on this particular shell script (I haven't looked > at it) -- but I think that such a script, if done right, would be a > great thing to have. > > When I upgraded to Snow Leopard, I found the migration process about as > far from user-friendly as possible. Aside from the (understandable) > need to rebuild everything, the instructions weren't easy to follow > with a lot of ports installed: > > - what are the ports I actually want to use vs dependencies? Easy to > miss some when picking them out of a list of hundreds of installed > ports. > - what are the non-default variants I specified? I wound up searching > for '+'s to find them, but that also matches +darwin, etc. > - what order to install them? I don't know the entire dependency tree > offhand... > > These seem like they'd be comparatively easy to track/compute > programatically, especially if someday port can keep track of what's > installed by explicit request vs dependencies. > > I realize that this is probably an issue of time rather than anything > else, but I just wanted to throw my experiences out there. Perhaps > someday I'll actually find time to do something about it. I would also suggest just dropping all the variants into the $prefix/etc/macports/variants.conf instead of doing to the work in keeping each variant around. Blair From ryandesign at macports.org Thu Jan 21 13:30:29 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 21 Jan 2010 15:30:29 -0600 Subject: [MacPorts] Migration modified In-Reply-To: <20100121210613.GF8656@ambulatoryclam.net> References: <20100121200141.C140F8121435@mail-out3.apple.com> <20100121210613.GF8656@ambulatoryclam.net> Message-ID: <3B50E909-9838-4EB6-97C7-90C6D84D67B6@macports.org> On Jan 21, 2010, at 15:06, Dan Ports wrote: > I'll take your word on this particular shell script (I haven't looked > at it) -- but I think that such a script, if done right, would be a > great thing to have. No doubt. But I claim there isn't a way to do such a script properly. Well, maybe there is, with proper hooks into the MacPorts dependency architecture, but this 20-line shell script doesn't do that. > When I upgraded to Snow Leopard, I found the migration process about as > far from user-friendly as possible. Aside from the (understandable) > need to rebuild everything, the instructions weren't easy to follow > with a lot of ports installed: > > - what are the ports I actually want to use vs dependencies? Easy to > miss some when picking them out of a list of hundreds of installed > ports. Look at each port in the list. Is it specifically something you want? For example, when I see "apache2" my brain says "A-ha! That's the Apache web server. I am a web developer and I use this every day. I'd better reinstall that." Whereas when I see "apr-util" my brain might say "I have no idea what that is" and I wouldn't install it. It happens to be an apache2 dependency so it would get reinstalled anyway. But a port might also be something I no longer need. > - what are the non-default variants I specified? I wound up searching > for '+'s to find them, but that also matches +darwin, etc. Only you can know which variants you requested when installing a port. Request the same variants again. Or consult "port variants" to see all the variants that are available for a port. Maybe the variant descriptions will jog your memory. > - what order to install them? I don't know the entire dependency tree > offhand... Agreed, this point in the migration instructions is vague, IMHO deliberately so. It is a rather big problem for the user to unravel. "port deps" and the "port-rdeps" script are tools that can be used to learn the dependency tree. A partial solution is for port authors to get rid of variants wherever possible and move them to separate ports. Another good idea is for ports to check that the required variants of their dependencies are installed. But when port authors have not taken these steps, users must watch out for these issues on their own. > These seem like they'd be comparatively easy to track/compute > programatically, especially if someday port can keep track of what's > installed by explicit request vs dependencies. You may recall we used to have an automated process documented in the wiki, around the time Snow Leopard was released. (Or maybe that was before your involvement in MacPorts.) But there were so many cases where it failed, because ports did not declare all their dependencies. And I don't even think the ports are wrong in the way they're not declaring them. For example, most ports use autoconf, and most autoconf configure scripts will look for standard utilities, like grep, sed, etc., but most ports don't declare dependencies on the grep or gsed ports because the versions of grep and sed provided by Mac OS X in /usr/bin work fine, and in some cases because the software in question doesn't even care to use those utilities (autoconf just checks for them anyway). But if the user had the grep or gsed ports installed, they would usually fail in a migration scenario, because they depend on gettext. So you rebuild gettext so it's x86_64, and then grep and gsed break because they're i386 and can't link with an x86_64 library. So our instructions were changed to uninstall grep and gsed first. But additional cases like this kept cropping up and it became a support nightmare so the instructions were removed entirely, leaving only the manual method, which is inconvenient but at least it always works. > I realize that this is probably an issue of time rather than anything > else, but I just wanted to throw my experiences out there. Perhaps > someday I'll actually find time to do something about it. IMHO it's an issue of this being a situation that a user will encounter only once every few years, when they upgrade their OS. There are much more frequent tasks the user will perform with MacPorts, and we have plenty of improvements to make in these areas that will more greatly benefit users. But certainly, if someone were to come up with an automated rebuild solution for OS migrations that actually works and implement it properly in MacPorts, we would be happy to have it. From talklists at newgeo.com Thu Jan 21 13:43:12 2010 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 21 Jan 2010 13:43:12 -0800 Subject: [MacPorts] Migration modified In-Reply-To: <3B50E909-9838-4EB6-97C7-90C6D84D67B6@macports.org> References: <20100121200141.C140F8121435@mail-out3.apple.com> <20100121210613.GF8656@ambulatoryclam.net> <3B50E909-9838-4EB6-97C7-90C6D84D67B6@macports.org> Message-ID: <2E14ECA3-09BC-49A7-B155-5CE377FE867A@newgeo.com> On the simple side, what about an install log. Plain text file that simply lists the commands you issued when installing software. Sort of like a grep 'port install' .bash_history that lasted a little longer. This would omit all dependencies and leave you a chronological list of what you did since dat one. -- Scott (Sent from a mobile device) On Jan 21, 2010, at 1:30 PM, Ryan Schmidt wrote: > But certainly, if someone were to come up with an automated rebuild > solution for OS migrations that actually works and implement it > properly in MacPorts, we would be happy to have it. From jm at poure.com Thu Jan 21 13:47:32 2010 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Thu, 21 Jan 2010 22:47:32 +0100 Subject: Leaving MacPorts, thanks Message-ID: <1264110452.7285.12.camel@acer> Dear Friends, Due to a lack of time, I am leaving MacPorts and I will not be able to maintain my port files with author: jmpoure. I would like to thank you all for your time and efforts. This was a great pleasure to discuss with you. Bye, Jean-Michel From ryandesign at macports.org Thu Jan 21 13:59:18 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 21 Jan 2010 15:59:18 -0600 Subject: Leaving MacPorts, thanks In-Reply-To: <1264110452.7285.12.camel@acer> References: <1264110452.7285.12.camel@acer> Message-ID: <7FD21CE6-E88C-4439-ACB6-67CB39DC7B6A@macports.org> On Jan 21, 2010, at 15:47, Jean-Michel Pour? wrote: > Due to a lack of time, I am leaving MacPorts and I will not be able to > maintain my port files with author: jmpoure. > > I would like to thank you all for your time and efforts. > This was a great pleasure to discuss with you. Jean-Michel, Thanks for helping out while you could! We appreciate it. I've nomaintainer'd your ports and assigned away your tickets. -Ryan From dports at ambulatoryclam.net Thu Jan 21 14:27:26 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Thu, 21 Jan 2010 14:27:26 -0800 Subject: [MacPorts] Migration modified In-Reply-To: <3B50E909-9838-4EB6-97C7-90C6D84D67B6@macports.org> References: <20100121200141.C140F8121435@mail-out3.apple.com> <20100121210613.GF8656@ambulatoryclam.net> <3B50E909-9838-4EB6-97C7-90C6D84D67B6@macports.org> Message-ID: <20100121222726.GG8656@ambulatoryclam.net> On Thu, Jan 21, 2010 at 03:30:29PM -0600, Ryan Schmidt wrote: > No doubt. But I claim there isn't a way to do such a script properly. Well, maybe there is, with proper hooks into the MacPorts dependency architecture, but this 20-line shell script doesn't do that. It wouldn't necessarily be a simple thing to do, but surely it must be possible. It *would* have to be something aware of dependencies. > > - what are the ports I actually want to use vs dependencies? Easy to > > miss some when picking them out of a list of hundreds of installed > > ports. > > Look at each port in the list. Is it specifically something you want? For example, when I see "apache2" my brain says "A-ha! That's the Apache web server. I am a web developer and I use this every day. I'd better reinstall that." Whereas when I see "apr-util" my brain might say "I have no idea what that is" and I wouldn't install it. It happens to be an apache2 dependency so it would get reinstalled anyway. But a port might also be something I no longer need. Obviously, I *can* identify ports I want, but it is silly that I should have to when this is something that could be automated. I am not claiming that anything is impossible here, just unnecessarily difficult. I have about 500 ports installed. Looking through the full list is a pretty tedious process. > > - what are the non-default variants I specified? I wound up searching > > for '+'s to find them, but that also matches +darwin, etc. > > Only you can know which variants you requested when installing a port. Request the same variants again. Or consult "port variants" to see all the variants that are available for a port. Maybe the variant descriptions will jog your memory. Huh? Of course the system can know which variants I requested -- they're the variants on the ports currently installed, excluding default (and platform) variants. Again, I can certainly figure out the list of installed ports with non-default variants by hand, but why should I have to? > > - what order to install them? I don't know the entire dependency tree > > offhand... > > Agreed, this point in the migration instructions is vague, IMHO deliberately so. It is a rather big problem for the user to unravel. "port deps" and the "port-rdeps" script are tools that can be used to learn the dependency tree. Are you suggesting that the solution is that I *should* have the dependency tree memorized? > > These seem like they'd be comparatively easy to track/compute > > programatically, especially if someday port can keep track of what's > > installed by explicit request vs dependencies. > > You may recall we used to have an automated process documented in the wiki, around the time Snow Leopard was released. (Or maybe that was before your involvement in MacPorts.) But there were so many cases where it failed, because ports did not declare all their dependencies. And I don't even think the ports are wrong in the way they're not declaring them. For example, most ports use autoconf, and most autoconf configure scripts will look for standard utilities, like grep, sed, etc., but most ports don't declare dependencies on the grep or gsed ports because the versions of grep and sed provided by Mac OS X in /usr/bin work fine, and in some cases because the software in question doesn't even care to use those utilities (autoconf just checks for them anyway). But if the user had the grep or gsed ports installed, they would usually fail in a migration scenario, because they depend on gettext. So you rebuild gettext so it's x86_64, and then grep and gsed break because they're i386 and can't link with an x86_64 > library. So our instructions were changed to uninstall grep and gsed first. But additional cases like this kept cropping up and it became a support nightmare so the instructions were removed entirely, leaving only the manual method, which is inconvenient but at least it always works. I do remember the automated process (it was to use upgrade --force, right?), but I never tried it myself (I upgraded to Snow Leopard relatively late). I'm not sure how undeclared dependencies can be considered anything other than a bug, although gsed etc are an interesting case. autotools might be another example. I'm not arguing that uninstalling and reinstalling all ports on an OS upgrade is a bad idea, especially when things can change so drastically as the build architecture. What I would like is for MacPorts to give a little more support in the process -- say, by printing the list of "port install" commands I'll need to run to get all of my old ports installed with the same variants. > > I realize that this is probably an issue of time rather than anything > > else, but I just wanted to throw my experiences out there. Perhaps > > someday I'll actually find time to do something about it. > > IMHO it's an issue of this being a situation that a user will encounter only once every few years, when they upgrade their OS. There are much more frequent tasks the user will perform with MacPorts, and we have plenty of improvements to make in these areas that will more greatly benefit users. Agreed that this is not the highest priority issue around, but it has certainly been a rough edge in my experience. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ From ryandesign at macports.org Thu Jan 21 14:37:52 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 21 Jan 2010 16:37:52 -0600 Subject: [MacPorts] Migration modified In-Reply-To: <4B58C23A.2070909@orcaware.com> References: <20100121200141.C140F8121435@mail-out3.apple.com> <20100121210613.GF8656@ambulatoryclam.net> <4B58C23A.2070909@orcaware.com> Message-ID: <066D84EE-0A73-4C9E-AB97-F256D9372CAA@macports.org> On Jan 21, 2010, at 15:08, Blair Zajac wrote: > I would also suggest just dropping all the variants into the $prefix/etc/macports/variants.conf instead of doing to the work in keeping each variant around. A curious idea. I tend to keep my variants.conf extremely sparse, containing only +universal at this time. Since those variants are added to all ports, I use it only for variants that are expected to exist in all ports. I suppose you could add every variant you've ever used to it. But for example, just because I want the +server variant of one port doesn't necessarily mean I want the +server variant of a different port. From talklists at newgeo.com Thu Jan 21 14:41:40 2010 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 21 Jan 2010 14:41:40 -0800 Subject: Leaving MacPorts, thanks In-Reply-To: <7FD21CE6-E88C-4439-ACB6-67CB39DC7B6A@macports.org> References: <1264110452.7285.12.camel@acer> <7FD21CE6-E88C-4439-ACB6-67CB39DC7B6A@macports.org> Message-ID: On Jan 21, 2010, at 1:59 PM, Ryan Schmidt wrote: > On Jan 21, 2010, at 15:47, Jean-Michel Pour? wrote: > >> Due to a lack of time, I am leaving MacPorts and I will not be able to >> maintain my port files with author: jmpoure. >> >> I would like to thank you all for your time and efforts. >> This was a great pleasure to discuss with you. > > > Jean-Michel, > > Thanks for helping out while you could! We appreciate it. > > I've nomaintainer'd your ports and assigned away your tickets. Well, that makes sense why this was not working: sudo port echo maintainer:jmpoure Though I did not do a selfudpate or sync, so should I not have the old data still? I wanted a list of ports to see if there was anything I could perhaps contribute to. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Thu Jan 21 14:44:32 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 21 Jan 2010 16:44:32 -0600 Subject: Leaving MacPorts, thanks In-Reply-To: References: <1264110452.7285.12.camel@acer> <7FD21CE6-E88C-4439-ACB6-67CB39DC7B6A@macports.org> Message-ID: On Jan 21, 2010, at 16:41, Scott Haneda wrote: > Well, that makes sense why this was not working: > sudo port echo maintainer:jmpoure > > Though I did not do a selfudpate or sync, so should I not have the old data still? I wanted a list of ports to see if there was anything I could perhaps contribute to. It's the list of ports modified by this revision: http://trac.macports.org/changeset/62915 He wasn't a committer so his ports were maintained by "poure.com:jm" not "jmpoure". From talklists at newgeo.com Thu Jan 21 15:07:56 2010 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 21 Jan 2010 15:07:56 -0800 Subject: [MacPorts] Migration modified In-Reply-To: <20100121210613.GF8656@ambulatoryclam.net> References: <20100121200141.C140F8121435@mail-out3.apple.com> <20100121210613.GF8656@ambulatoryclam.net> Message-ID: <9557E757-3136-456D-969C-D56F5DD7127B@newgeo.com> On Jan 21, 2010, at 1:06 PM, Dan Ports wrote: > I'll take your word on this particular shell script (I haven't looked > at it) -- but I think that such a script, if done right, would be a > great thing to have. I agree. I just looked at it, comments below the script, for what they are worth. #!/bin/sh # instructions found @ http://trac.macports.org/wiki/Migration #written by Liquan Tan set -e echo "***** 1. Self updating Macport" sudo port selfupdate echo "***** 1. Saving the list of installed ports: ***** " port installed > ~/myports.txt echo "***** 2. Uninstalling all installed ports: ***** " sudo port -f uninstall installed echo "***** 3. Clean any partially-completed builds and remove any archives: *****" sudo port clean --work --archive all echo "***** 4. Reinstalling previous active ports: *****" REINSTALL_LIST=`cat ~/myports.txt | awk '/(active)/ {print $1}' | tr '\n' ' '` echo $REINSTALL_LIST sudo port install $REINSTALL_LIST -- ** -- port installed > ~/myports.txt I would at least put this in ~/tmp/.macports or similar You never know what people have in their home dir, and you never want to take the chance of writing over their data. This does not append >> but overwrites > and there are plenty of other places it can be stored where the chances of writing over someones data is less likely, even though this is not all that likely. Step #4, I just can not see this going without trouble. At that point, what state is the user left in? If anything, this needs to be more interactive. Just running a quick test: port installed >> ~/Desktop/myports.txt cat ~/Desktop/myports.txt | awk '/(active)/ {print $1}' | tr '\n' ' ' There is just no way that I am going to get a clean install of the list of 100 or so ports in the myports.txt file. If this script were more interactive, and stepped me through each one: -- About to install $portname, do you want to continue -- $portname installed clean, with no errors, do you want to continue -- $portname failed, myports.txt has been edited to list only the remaining ports that need installing, fix the error with $portname, and run the script again That is the only simple way I see this being helpful to people. There are just too many reasons a port is not going to install, and far too little error checking in this script. My .02. * Not bashing the effort here, I just do not think in the long run this will do more than cause more of of a support burden. At least when doing this by hand, it is something you can work on an issue until solved, and then move on. I would still like a text file archive of all the ports I have installed, in the order they were installed, which would list my posts, and not the variants and dependencies that they installed along with the parent port. There is also the issue of local port files that I am working on myself. They may have been installed at one time, and even working, but there is no guarantee that my local postfiles even exist any longer, which would generate error for this script to tell me that the port does not even exist. With some work, I think it would be valuable, as it stands, I agree with some of the other sentiments here. Perhaps look to a different approach. -- Scott * If you contact me off list replace talklists@ with scott@ * From jmr at macports.org Thu Jan 21 17:42:36 2010 From: jmr at macports.org (Joshua Root) Date: Fri, 22 Jan 2010 12:42:36 +1100 Subject: [MacPorts] Migration modified In-Reply-To: <20100121210613.GF8656@ambulatoryclam.net> References: <20100121200141.C140F8121435@mail-out3.apple.com> <20100121210613.GF8656@ambulatoryclam.net> Message-ID: <4B59028C.7030606@macports.org> On 2010-1-22 08:06 , Dan Ports wrote: > On Thu, Jan 21, 2010 at 02:45:08PM -0600, Ryan Schmidt wrote: >> I don't think we want this shell script. Certainly its position in the wiki makes it look official, and I can't endorse it. It doesn't, for example, take into account three important aspects of the Migration process: > > I'll take your word on this particular shell script (I haven't looked > at it) -- but I think that such a script, if done right, would be a > great thing to have. Someone actually did do it right at one point IIRC. You should be able to find their script in the list archives. - Josh From ryandesign at macports.org Thu Jan 21 22:27:56 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 22 Jan 2010 00:27:56 -0600 Subject: Before reporting a bug Message-ID: <3863BE5C-19FF-42F2-9DF3-3326C5AB0C5D@macports.org> MacPorts now prints this message when something fails: Before reporting a bug, first run the command again with the -d flag to get complete output. But I'd like to modify that recommendation. First, I'd like the user to clean before trying again, otherwise I don't get the full output. Second, I'd like the user to build with build.jobs=1, that way I can do a line-for-line comparison with output from my system. (If either of us use parallel building, the build lines have no chance of matching up.) Ideally the instructions we print should show exactly what port commands the user needs to run. Do we have access to that information at the time of the error message -- i.e. whether it was install or upgrade, what the port was, what other command line options they supplied -- so that we can show them the corrected command? We also print the URL to the guide with instructions for ticket reporting. How would you feel about changing it to the URL of the relevant page in the chunked version? From dluke at geeklair.net Fri Jan 22 07:14:23 2010 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 22 Jan 2010 10:14:23 -0500 Subject: Before reporting a bug In-Reply-To: <3863BE5C-19FF-42F2-9DF3-3326C5AB0C5D@macports.org> References: <3863BE5C-19FF-42F2-9DF3-3326C5AB0C5D@macports.org> Message-ID: <4467D32D-2963-4B28-BD47-AEE4B201E908@geeklair.net> On Jan 22, 2010, at 1:27 AM, Ryan Schmidt wrote: > Second, I'd like the user to build with build.jobs=1, that way I can do a line-for-line comparison with output from my system. ... but that also means that parallel build problems that the maintainer doesn't notice probably won't get reported (as the end user will rebuild without parallel build, it will work, and they'll have no reason to report it). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From jmr at macports.org Fri Jan 22 08:08:11 2010 From: jmr at macports.org (Joshua Root) Date: Sat, 23 Jan 2010 03:08:11 +1100 Subject: [MacPorts] Migration modified In-Reply-To: <4B59028C.7030606@macports.org> References: <20100121200141.C140F8121435@mail-out3.apple.com> <20100121210613.GF8656@ambulatoryclam.net> <4B59028C.7030606@macports.org> Message-ID: <4B59CD6B.1040204@macports.org> On 2010-1-22 12:42 , Joshua Root wrote: > On 2010-1-22 08:06 , Dan Ports wrote: >> On Thu, Jan 21, 2010 at 02:45:08PM -0600, Ryan Schmidt wrote: >>> I don't think we want this shell script. Certainly its position in the wiki makes it look official, and I can't endorse it. It doesn't, for example, take into account three important aspects of the Migration process: >> >> I'll take your word on this particular shell script (I haven't looked >> at it) -- but I think that such a script, if done right, would be a >> great thing to have. > > Someone actually did do it right at one point IIRC. You should be able > to find their script in the list archives. So, here's a first pass at a Tcl version that could be integrated into port(1) eventually: Lightly tested, definitely has bugs, exercise caution. :-) - Josh From jmr at macports.org Sun Jan 24 02:46:18 2010 From: jmr at macports.org (Joshua Root) Date: Sun, 24 Jan 2010 21:46:18 +1100 Subject: binary links in python26 portgroup Message-ID: <4B5C24FA.308@macports.org> I've added a new option "python.link_binaries" to the python26 portgroup, on by default, which in post-destroot will create version-suffixed links in ${prefix}/bin/ to everything installed by the port in ${python.prefix}/bin/. I've adapted all py26-* ports that appeared to be affected by this change, but if you maintain a port that uses the python26 group you may wish to double check that it still does the right thing. - Josh From raimue at macports.org Sun Jan 24 12:59:16 2010 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 24 Jan 2010 21:59:16 +0100 Subject: binary links in python26 portgroup In-Reply-To: <4B5C24FA.308@macports.org> References: <4B5C24FA.308@macports.org> Message-ID: <4B5CB4A4.9020707@macports.org> On 2010-01-24 11:46 , Joshua Root wrote: > I've added a new option "python.link_binaries" to the python26 > portgroup, on by default, which in post-destroot will create > version-suffixed links in ${prefix}/bin/ to everything installed by the > port in ${python.prefix}/bin/. I think we should do the same for ${python.prefix}/share/man/. Standalone ports which are not python modules but make use of the python26 port group should disable this feature. Rainer From tomldavis at verizon.net Mon Jan 25 13:16:08 2010 From: tomldavis at verizon.net (Tom Davis) Date: Mon, 25 Jan 2010 15:16:08 -0600 Subject: Library search paths, daemon startupitem and launchd Message-ID: Hello, I'm trying to write a portfile for iguanaIR (http://iguanaworks.net/projects/IguanaIR). I'm having difficulties starting a daemon using startupitem.executable. When I try to start the daemon with: sudo launchctl load -w /Library/LaunchDaemons/org.macports.iguanaIR.plist igdaemon crashes. Here's part of the CrashReporter log: Dyld Error Message: Library not loaded: libiguanaIR.dylib Referenced from: /opt/local/bin/igdaemon Reason: image not found The libiguanaIR.dylib library is part of the iguanaIR distribution and is in /opt/local/lib after a port install. otool shows that libiguanaIR.dylib is the only library without an absolute path: Rett:~ tom$ otool -L /opt/local/bin/igdaemon /opt/local/bin/igdaemon: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.13.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) libiguanaIR.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libpopt.0.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libusb-0.1.4.dylib (compatibility version 9.0.0, current version 9.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) I'm guessing this is because it's not linked with the -l switch because libiguanaIR.dylib is not installed at the time igdaemon is built. My .profile is setup to search /opt/local/lib for libraries: Rett:~ tom$ env | grep LIB DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib: LIBRARY_PATH=/opt/local/lib DYLD_LIBRARY_PATH=/Applications/MATLAB_R2009a.app/bin/mac:/Applications/MATLAB_R2009a.app/sys/os/mac: If I run igdaemon from the command line, everything works fine. If I copy libiguanaIR.dylib to /usr/local/lib and use launchctl, everything works fine. If I add the following lines to org.macports.iguanaIR.plist: EnvironmentVariables DYLD_FALLBACK_LIBRARY_PATH /opt/local/lib or WorkingDirectory /opt/local/lib then everything works fine. /Library/LaunchDaemons must be started by sudo, But sudo strips environmental variables such as DYLD_FALLBACK_LIBRARY_PATH for security reasons. So, what is the correct way to get a daemon to search /op/local/lib? Is there a way to add the EnvironmentVariables key to the launchctl plist using portfile settings? Tom From brad at pixilla.com Mon Jan 25 13:23:22 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 25 Jan 2010 13:23:22 -0800 Subject: Library search paths, daemon startupitem and launchd In-Reply-To: References: Message-ID: <132E5E55-50B7-4E53-AF10-852306D034FF@pixilla.com> On Jan 25, 2010, at 1:16 PM, Tom Davis wrote: > Hello, > > I'm trying to write a portfile for iguanaIR (http://iguanaworks.net/projects/IguanaIR > ). I'm having difficulties starting a daemon using > startupitem.executable. When I try to start the daemon with: > > sudo launchctl load -w /Library/LaunchDaemons/ > org.macports.iguanaIR.plist > > igdaemon crashes. Here's part of the CrashReporter log: > > Dyld Error Message: > Library not loaded: libiguanaIR.dylib > Referenced from: /opt/local/bin/igdaemon > Reason: image not found > > The libiguanaIR.dylib library is part of the iguanaIR distribution > and is in /opt/local/lib after a port install. otool shows that > libiguanaIR.dylib is the only library without an absolute path: > > Rett:~ tom$ otool -L /opt/local/bin/igdaemon > /opt/local/bin/igdaemon: > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/ > CoreFoundation (compatibility version 150.0.0, current version > 550.13.0) > /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit > (compatibility version 1.0.0, current version 275.0.0) > libiguanaIR.dylib (compatibility version 1.0.0, current version > 1.0.0) > /opt/local/lib/libpopt.0.dylib (compatibility version 1.0.0, > current version 1.0.0) > /opt/local/lib/libusb-0.1.4.dylib (compatibility version 9.0.0, > current version 9.4.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 125.0.0) > > I'm guessing this is because it's not linked with the -l switch > because libiguanaIR.dylib is not installed at the time igdaemon is > built. > > My .profile is setup to search /opt/local/lib for libraries: > > Rett:~ tom$ env | grep LIB > DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib: > LIBRARY_PATH=/opt/local/lib > DYLD_LIBRARY_PATH=/Applications/MATLAB_R2009a.app/bin/mac:/ > Applications/MATLAB_R2009a.app/sys/os/mac: > > If I run igdaemon from the command line, everything works fine. > > If I copy libiguanaIR.dylib to /usr/local/lib and use launchctl, > everything works fine. If I add the following lines to > org.macports.iguanaIR.plist: > > EnvironmentVariables > > DYLD_FALLBACK_LIBRARY_PATH /opt/local/lib string> > > > or > WorkingDirectory > /opt/local/lib > > then everything works fine. > > /Library/LaunchDaemons must be started by sudo, But sudo strips > environmental variables such as DYLD_FALLBACK_LIBRARY_PATH for > security reasons. > > So, what is the correct way to get a daemon to search /op/local/lib? > Is there a way to add the EnvironmentVariables key to the launchctl > plist using portfile settings? Don't know but greping turns up things like this that might be a direction to look in: grep -R startupitem /opt/local/var/macports/sources/rsync.macports.org/ release/ports/ /opt/local/var/macports/sources/rsync.macports.org/release/ports/ databases/openldap/Portfile:startupitem.init "PID=${prefix}/var/run/ slapd.pid" /opt/local/var/macports/sources/rsync.macports.org/release/ports/ databases/openldap/Portfile:startupitem.start "${prefix}/libexec/ slapd -u ldap -f ${prefix}/etc/openldap/slapd.conf" Also might look at "man portfile". // Brad From jeremy at lavergne.gotdns.org Mon Jan 25 13:41:18 2010 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 25 Jan 2010 16:41:18 -0500 Subject: Library search paths, daemon startupitem and launchd In-Reply-To: References: Message-ID: <32F18A6F-9771-4E53-A485-CBDF1C3EBC82@lavergne.gotdns.org> It sounds like putting the DYLIB in the launchd.plist entirely avoids this problem for you though. As Bradley suggested, checkout man launchd.plist for the settings afforded to you through the plist. If it cannot help you, create a wrapper script that sets up your environment and then launches the binary. On Jan 25, 2010, at 4:16 PM, Tom Davis wrote: > Hello, > > I'm trying to write a portfile for iguanaIR (http://iguanaworks.net/projects/IguanaIR). I'm having difficulties starting a daemon using startupitem.executable. When I try to start the daemon with: > > sudo launchctl load -w /Library/LaunchDaemons/org.macports.iguanaIR.plist > > igdaemon crashes. Here's part of the CrashReporter log: > > Dyld Error Message: > Library not loaded: libiguanaIR.dylib > Referenced from: /opt/local/bin/igdaemon > Reason: image not found > > The libiguanaIR.dylib library is part of the iguanaIR distribution and is in /opt/local/lib after a port install. otool shows that libiguanaIR.dylib is the only library without an absolute path: > > Rett:~ tom$ otool -L /opt/local/bin/igdaemon > /opt/local/bin/igdaemon: > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.13.0) > /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) > libiguanaIR.dylib (compatibility version 1.0.0, current version 1.0.0) > /opt/local/lib/libpopt.0.dylib (compatibility version 1.0.0, current version 1.0.0) > /opt/local/lib/libusb-0.1.4.dylib (compatibility version 9.0.0, current version 9.4.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) > > I'm guessing this is because it's not linked with the -l switch because libiguanaIR.dylib is not installed at the time igdaemon is built. > > My .profile is setup to search /opt/local/lib for libraries: > > Rett:~ tom$ env | grep LIB > DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib: > LIBRARY_PATH=/opt/local/lib > DYLD_LIBRARY_PATH=/Applications/MATLAB_R2009a.app/bin/mac:/Applications/MATLAB_R2009a.app/sys/os/mac: > > If I run igdaemon from the command line, everything works fine. > > If I copy libiguanaIR.dylib to /usr/local/lib and use launchctl, everything works fine. If I add the following lines to org.macports.iguanaIR.plist: > > EnvironmentVariables > > DYLD_FALLBACK_LIBRARY_PATH /opt/local/lib > > > or > WorkingDirectory > /opt/local/lib > > then everything works fine. > > /Library/LaunchDaemons must be started by sudo, But sudo strips environmental variables such as DYLD_FALLBACK_LIBRARY_PATH for security reasons. > > So, what is the correct way to get a daemon to search /op/local/lib? Is there a way to add the EnvironmentVariables key to the launchctl plist using portfile settings? > > Tom > > > > > > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Mon Jan 25 15:47:28 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 25 Jan 2010 17:47:28 -0600 Subject: Library search paths, daemon startupitem and launchd In-Reply-To: References: Message-ID: <88A376D5-53A8-4810-86BC-52F0473B85DF@macports.org> On Jan 25, 2010, at 15:16, Tom Davis wrote: > Dyld Error Message: > Library not loaded: libiguanaIR.dylib > Referenced from: /opt/local/bin/igdaemon > Reason: image not found > > The libiguanaIR.dylib library is part of the iguanaIR distribution and is in /opt/local/lib after a port install. otool shows that libiguanaIR.dylib is the only library without an absolute path: > > Rett:~ tom$ otool -L /opt/local/bin/igdaemon > /opt/local/bin/igdaemon: > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.13.0) > /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) > libiguanaIR.dylib (compatibility version 1.0.0, current version 1.0.0) ^^^^^^ Right, this line is the problem. For correct functionality, it should list the full path to the library, i.e. /opt/local/lib/libiguanaIR.dylib (compatibility version 1.0.0, current version 1.0.0) I don't know how to achieve that, however, and I don't know if it's the fault of libiguanaIR.dylib or the program using it. From david.osguthorpe at gmail.com Mon Jan 25 16:22:56 2010 From: david.osguthorpe at gmail.com (David Osguthorpe) Date: Mon, 25 Jan 2010 17:22:56 -0700 Subject: Library search paths, daemon startupitem and launchd In-Reply-To: <88A376D5-53A8-4810-86BC-52F0473B85DF@macports.org> References: <88A376D5-53A8-4810-86BC-52F0473B85DF@macports.org> Message-ID: <20100126002256.GB667@mactelhm.local> On Mon, Jan 25, 2010 at 04:47:28PM -0700, Ryan Schmidt wrote: > > Right, this line is the problem. For correct functionality, it should list the full path to the library, i.e. > > /opt/local/lib/libiguanaIR.dylib (compatibility version 1.0.0, current version 1.0.0) > > I don't know how to achieve that, however, and I don't know if it's the fault of libiguanaIR.dylib or the program using it. > use the apple supplied install_name_tool - grep for install_name_tool in the Portfiles - there are a fair number of ports which use this to fix library paths after the fact in the destroot stage David From jkh at apple.com Mon Jan 25 16:56:34 2010 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon, 25 Jan 2010 16:56:34 -0800 Subject: Library search paths, daemon startupitem and launchd In-Reply-To: <88A376D5-53A8-4810-86BC-52F0473B85DF@macports.org> References: <88A376D5-53A8-4810-86BC-52F0473B85DF@macports.org> Message-ID: On Jan 25, 2010, at 3:47 PM, Ryan Schmidt wrote: > I don't know how to achieve that, however, and I don't know if it's the fault of libiguanaIR.dylib or the program using it. Sounds to me like the install_name of libiguanaR.dylib is simply incorrect or unset. What does otool -D on the libiguanaR.dylib reveal? If not an absolute path under ${prefix}, it's wrong. - Jordan From tomldavis at verizon.net Mon Jan 25 21:12:25 2010 From: tomldavis at verizon.net (Tom Davis) Date: Mon, 25 Jan 2010 23:12:25 -0600 Subject: Library search paths, daemon startupitem and launchd In-Reply-To: References: <88A376D5-53A8-4810-86BC-52F0473B85DF@macports.org> Message-ID: <787895DA-C505-4F74-A0A7-317A84D62874@verizon.net> Rett:~ tom$ otool -D /opt/local/lib/libiguanaIR.dylib /opt/local/lib/libiguanaIR.dylib: libiguanaIR.dylib How do I get it to have an absolute path? libiguanaIR.dylib is built at the same time as igdaemon. So gcc doesn't know where its going to end up the directory structure. Can I assign it an absolute path somehow? Right now I'm trying to patch the launchctl plist file to add an EnvironmentVariables key for DYLD_FALLBACK_LIBRARY_PATH: set plistDir ${prefix}/etc/LaunchDaemons/org.macports.iguanaIR pre-install { system "cd ${destroot}${plistDir}; patch < ${filespath}/patch-org.macports.iguanaIR.plist.diff" } It's not working yet, but I've found other ports that patch the launchctl plist. Is this bad form? I'm really surprised others haven't run into this problem. Searches of the archive and Google don't seem to turn up anything I can use. Tom On Jan 25, 2010, at 6:56 PM, Jordan K. Hubbard wrote: > > On Jan 25, 2010, at 3:47 PM, Ryan Schmidt wrote: > >> I don't know how to achieve that, however, and I don't know if it's the fault of libiguanaIR.dylib or the program using it. > > Sounds to me like the install_name of libiguanaR.dylib is simply incorrect or unset. What does otool -D on the libiguanaR.dylib reveal? If not an absolute path under ${prefix}, it's wrong. > > - Jordan > From tomldavis at verizon.net Mon Jan 25 21:52:31 2010 From: tomldavis at verizon.net (Tom Davis) Date: Mon, 25 Jan 2010 23:52:31 -0600 Subject: Library search paths, daemon startupitem and launchd In-Reply-To: <32F18A6F-9771-4E53-A485-CBDF1C3EBC82@lavergne.gotdns.org> References: <32F18A6F-9771-4E53-A485-CBDF1C3EBC82@lavergne.gotdns.org> Message-ID: <0F72DB51-96E3-4AC7-BFD2-F7D95AC88761@verizon.net> So you're suggesting patching the launchd plist? That's the route I'm going down now, but I just don't know if its the "right" way. I have found a few ports that patch or create their own plist, but it doesn't seem very common. I'm a real newbie to MacPorts and don't know the rules (both written and unwritten). Tom On Jan 25, 2010, at 3:41 PM, Jeremy Lavergne wrote: > It sounds like putting the DYLIB in the launchd.plist entirely avoids this problem for you though. > > As Bradley suggested, checkout man launchd.plist for the settings afforded to you through the plist. If it cannot help you, create a wrapper script that sets up your environment and then launches the binary. > > On Jan 25, 2010, at 4:16 PM, Tom Davis wrote: > >> Hello, >> >> I'm trying to write a portfile for iguanaIR (http://iguanaworks.net/projects/IguanaIR). I'm having difficulties starting a daemon using startupitem.executable. When I try to start the daemon with: >> >> sudo launchctl load -w /Library/LaunchDaemons/org.macports.iguanaIR.plist >> >> igdaemon crashes. Here's part of the CrashReporter log: >> >> Dyld Error Message: >> Library not loaded: libiguanaIR.dylib >> Referenced from: /opt/local/bin/igdaemon >> Reason: image not found >> >> The libiguanaIR.dylib library is part of the iguanaIR distribution and is in /opt/local/lib after a port install. otool shows that libiguanaIR.dylib is the only library without an absolute path: >> >> Rett:~ tom$ otool -L /opt/local/bin/igdaemon >> /opt/local/bin/igdaemon: >> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.13.0) >> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) >> libiguanaIR.dylib (compatibility version 1.0.0, current version 1.0.0) >> /opt/local/lib/libpopt.0.dylib (compatibility version 1.0.0, current version 1.0.0) >> /opt/local/lib/libusb-0.1.4.dylib (compatibility version 9.0.0, current version 9.4.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.0) >> >> I'm guessing this is because it's not linked with the -l switch because libiguanaIR.dylib is not installed at the time igdaemon is built. >> >> My .profile is setup to search /opt/local/lib for libraries: >> >> Rett:~ tom$ env | grep LIB >> DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib: >> LIBRARY_PATH=/opt/local/lib >> DYLD_LIBRARY_PATH=/Applications/MATLAB_R2009a.app/bin/mac:/Applications/MATLAB_R2009a.app/sys/os/mac: >> >> If I run igdaemon from the command line, everything works fine. >> >> If I copy libiguanaIR.dylib to /usr/local/lib and use launchctl, everything works fine. If I add the following lines to org.macports.iguanaIR.plist: >> >> EnvironmentVariables >> >> DYLD_FALLBACK_LIBRARY_PATH /opt/local/lib >> >> >> or >> WorkingDirectory >> /opt/local/lib >> >> then everything works fine. >> >> /Library/LaunchDaemons must be started by sudo, But sudo strips environmental variables such as DYLD_FALLBACK_LIBRARY_PATH for security reasons. >> >> So, what is the correct way to get a daemon to search /op/local/lib? Is there a way to add the EnvironmentVariables key to the launchctl plist using portfile settings? >> >> Tom >> >> >> >> >> >> >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> > From tomldavis at verizon.net Mon Jan 25 21:57:31 2010 From: tomldavis at verizon.net (Tom Davis) Date: Mon, 25 Jan 2010 23:57:31 -0600 Subject: Library search paths, daemon startupitem and launchd In-Reply-To: <20100126002256.GB667@mactelhm.local> References: <88A376D5-53A8-4810-86BC-52F0473B85DF@macports.org> <20100126002256.GB667@mactelhm.local> Message-ID: <2C71F608-2A53-4621-847D-67ADDD08264B@verizon.net> Thanks. This looks like a winner. Tom On Jan 25, 2010, at 6:22 PM, David Osguthorpe wrote: > On Mon, Jan 25, 2010 at 04:47:28PM -0700, Ryan Schmidt wrote: >> >> Right, this line is the problem. For correct functionality, it should list the full path to the library, i.e. >> >> /opt/local/lib/libiguanaIR.dylib (compatibility version 1.0.0, current version 1.0.0) >> >> I don't know how to achieve that, however, and I don't know if it's the fault of libiguanaIR.dylib or the program using it. >> > > use the apple supplied install_name_tool - grep for install_name_tool in the Portfiles - there are a > fair number of ports which use this to fix library paths after the fact in the destroot stage > > David From ryandesign at macports.org Mon Jan 25 22:12:16 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 26 Jan 2010 00:12:16 -0600 Subject: [63093] trunk/dports/www/firefox-x11-devel/Portfile In-Reply-To: <20100126055733.61EAB3D7ECD7@beta.macosforge.org> References: <20100126055733.61EAB3D7ECD7@beta.macosforge.org> Message-ID: On Jan 25, 2010, at 23:57, jeremyhu at macports.org wrote: > Revision: 63093 > http://trac.macports.org/changeset/63093 > Author: jeremyhu at macports.org > Date: 2010-01-25 21:57:31 -0800 (Mon, 25 Jan 2010) > Log Message: > ----------- > firefox-x11-devel: Add some arch checking to the internal_dependencies variant You're going to need to add the archcheck portgroup, either globally or in the variant, for that to work. Currently: $ port info +internal_dependencies Error: firefox-x11-devel: Error executing internal_dependencies: invalid command name "archcheck.files-append" Error: Unable to open port: Error evaluating variants From cristiano.fontana at gmail.com Tue Jan 26 03:10:54 2010 From: cristiano.fontana at gmail.com (Cristiano Fontana) Date: Tue, 26 Jan 2010 12:10:54 +0100 Subject: Installation of Java libraries Message-ID: I recently wrote a Portfile for AIDA (http://aida.freehep.org/) that is a collection of abstract interfaces written in C++ and Java libraries. For the C++ header files I had no problems in the installation but I do not know Java, so I do not know where libraries are supposed to be put. Can you suggest me where to put those? Thanks, Cristiano From nox at macports.org Tue Jan 26 05:32:49 2010 From: nox at macports.org (nox) Date: Tue, 26 Jan 2010 14:32:49 +0100 Subject: Installation of Java libraries In-Reply-To: References: Message-ID: <27223346-70BF-467D-904C-7C4866E7A6CE@macports.org> It should install a jar in ${prefix}/share/java Le 26 janv. 2010 ? 12:10, Cristiano Fontana a ?crit : > I recently wrote a Portfile for AIDA (http://aida.freehep.org/) that is a collection of abstract interfaces written in C++ and Java libraries. > For the C++ header files I had no problems in the installation but I do not know Java, so I do not know where libraries are supposed to be put. > > Can you suggest me where to put those? > > Thanks, > Cristiano > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From vincent-opdarw at vinc17.org Tue Jan 26 15:14:22 2010 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Wed, 27 Jan 2010 00:14:22 +0100 Subject: executable LaunchDaemons plist Message-ID: <20100126231422.GW4677@prunille.vinc17.org> With smartmontools @5.39_0+darwin, I can see: -rwxr-xr-x 2 root admin 404 2010-01-26 23:48:21 /Library/LaunchDaemons/net.sourceforge.smartmontools.smartd.plist Is it normal that this file is executable? Similarly, org.freedesktop.avahi-daemon.plist and org.freedesktop.avahi-dnsconfd.plist are also executable. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Ar?naire project (LIP, ENS-Lyon) From talklists at newgeo.com Tue Jan 26 16:33:01 2010 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 26 Jan 2010 16:33:01 -0800 Subject: executable LaunchDaemons plist In-Reply-To: <20100126231422.GW4677@prunille.vinc17.org> References: <20100126231422.GW4677@prunille.vinc17.org> Message-ID: On Jan 26, 2010, at 3:14 PM, Vincent Lefevre wrote: > With smartmontools @5.39_0+darwin, I can see: > > -rwxr-xr-x 2 root admin 404 2010-01-26 23:48:21 /Library/LaunchDaemons/net.sourceforge.smartmontools.smartd.plist I do not know about this one, all my non MacPorts installed lists are not +x > Is it normal that this file is executable? > > Similarly, org.freedesktop.avahi-daemon.plist and > org.freedesktop.avahi-dnsconfd.plist are also executable. These are usually symbolic links, and not the actual files. For example: $ls -la /opt/local/etc/LaunchDaemons/org.macports.apache2/ -rwxr-xr-x 2 root wheel 607 Jan 24 03:10 apache2.wrapper -rw-r--r-- 2 root wheel 987 Jan 24 03:10 org.macports.apache2.plist Why the symbolic links is executable? Maybe they have to be, just like a directory has to be. -- Scott * If you contact me off list replace talklists@ with scott@ * From toby at macports.org Tue Jan 26 16:55:52 2010 From: toby at macports.org (Toby Peterson) Date: Tue, 26 Jan 2010 16:55:52 -0800 Subject: executable LaunchDaemons plist In-Reply-To: <20100126231422.GW4677@prunille.vinc17.org> References: <20100126231422.GW4677@prunille.vinc17.org> Message-ID: <39648CFC-A953-468B-BEBB-FDCAEA2A66FD@macports.org> Just default xinstall behavior, fixed in r63121 - Toby On Jan 26, 2010, at 3:14 PM, Vincent Lefevre wrote: > With smartmontools @5.39_0+darwin, I can see: > > -rwxr-xr-x 2 root admin 404 2010-01-26 23:48:21 /Library/LaunchDaemons/net.sourceforge.smartmontools.smartd.plist > > Is it normal that this file is executable? > > Similarly, org.freedesktop.avahi-daemon.plist and > org.freedesktop.avahi-dnsconfd.plist are also executable. > > -- > Vincent Lef?vre - Web: > 100% accessible validated (X)HTML - Blog: > Work: CR INRIA - computer arithmetic / Ar?naire project (LIP, ENS-Lyon) > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From vincent-opdarw at vinc17.org Tue Jan 26 18:37:29 2010 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Wed, 27 Jan 2010 03:37:29 +0100 Subject: executable LaunchDaemons plist In-Reply-To: References: <20100126231422.GW4677@prunille.vinc17.org> Message-ID: <20100127023728.GX4677@prunille.vinc17.org> On 2010-01-26 16:33:01 -0800, Scott Haneda wrote: > On Jan 26, 2010, at 3:14 PM, Vincent Lefevre wrote: > > Similarly, org.freedesktop.avahi-daemon.plist and > > org.freedesktop.avahi-dnsconfd.plist are also executable. > > These are usually symbolic links, and not the actual files. These ones are *not* symbolic links on my machine. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Ar?naire project (LIP, ENS-Lyon) From ryandesign at macports.org Tue Jan 26 19:55:07 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 26 Jan 2010 21:55:07 -0600 Subject: executable LaunchDaemons plist In-Reply-To: <20100127023728.GX4677@prunille.vinc17.org> References: <20100126231422.GW4677@prunille.vinc17.org> <20100127023728.GX4677@prunille.vinc17.org> Message-ID: On Jan 26, 2010, at 20:37, Vincent Lefevre wrote: > On 2010-01-26 16:33:01 -0800, Scott Haneda wrote: >> On Jan 26, 2010, at 3:14 PM, Vincent Lefevre wrote: >>> Similarly, org.freedesktop.avahi-daemon.plist and >>> org.freedesktop.avahi-dnsconfd.plist are also executable. >> >> These are usually symbolic links, and not the actual files. > > These ones are *not* symbolic links on my machine. Right, those are not installed by MacPorts like most ports' launchd plists; those are installed by avahi itself. I have filed a bug report for you with the developers of avahi: http://avahi.org/ticket/301 It's not a major problem, though, that these files are executable. There's merely nothing in them that could be executed, so there's no reason for them to have the execute bit. From mdcrawford at gmail.com Tue Jan 26 22:42:00 2010 From: mdcrawford at gmail.com (Michael Crawford) Date: Tue, 26 Jan 2010 22:42:00 -0800 Subject: executable LaunchDaemons plist In-Reply-To: References: <20100126231422.GW4677@prunille.vinc17.org> <20100127023728.GX4677@prunille.vinc17.org> Message-ID: Just for grins I just tried the following on Ubuntu: $ cat runme.plist This is some text But this isn't $ chmod +x runme.plist $ ./runme.plist ./runme.plist: line 1: syntax error near unexpected token `newline' ./runme.plist: line 1: `' I would expect Mac OS X to complain in a similar way. Strictly speaking, executable programs on *NIX systems are expected to begin with a "Magic Number" that identifies the type of executable machine code they consist of. In my younger, less bald and overweight days I did tech support at Microport Systems. Our founder Chuck Hickey had ported AT&T SystemV UNIX to the 80286 AT. Our SystemV/AT ran 16-bit UNIX code that worked much like 16-bit DOS code - there was small model, and large model, and huge model, and segment and offset registers and so on. (Be grateful for the good things you have, kids.) We were always fielding calls about the error message "Bad Magic". True to UNIX tradition, it identified the problem without giving you the first clue as to what went wrong or what to do about it. "Bad Magic" meant that you were trying to link two or more object files or libraries that were built with different memory models, and so had different Magic Numbers. Anyway, the Magic Number for a script that is to be executed by some kind of interpreter is, when expressed as ASCII: #! Immediately following the Magic Number was required to be the path to the interpreter's executable file: #!/bin/sh or #!/usr/bin/perl The interpreter would then be exec'ed and fed the script as its input. Somehow though #! lost all its Magic somewhere along the way. I don't think the kernel uses it as a binary executable Magic Number at all anymore. So my guess is that if an executable doesn't start out with one of the well-known machine code Magic Numbers, and it doesn't start out with Pound-Sign Bang Path Name, then the kernel just assumes it's a Bourne Shell script. So to the extent that your property lists don't run when executed by the Bourne Shell or by Bash, there shouldn't be any problems. Hope That Helps, Mike -- Michael David Crawford mdcrawford at gmail dot com GoingWare's Bag of Programming Tricks http://www.goingware.com/tips/ From vincent-opdarw at vinc17.org Wed Jan 27 05:04:44 2010 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Wed, 27 Jan 2010 14:04:44 +0100 Subject: executable LaunchDaemons plist In-Reply-To: References: <20100126231422.GW4677@prunille.vinc17.org> <20100127023728.GX4677@prunille.vinc17.org> Message-ID: <20100127130444.GY4677@prunille.vinc17.org> On 2010-01-26 22:42:00 -0800, Michael Crawford wrote: > Just for grins I just tried the following on Ubuntu: > > $ cat runme.plist > > > This is some text > But this isn't > > > $ chmod +x runme.plist > $ ./runme.plist > ./runme.plist: line 1: syntax error near unexpected token `newline' > ./runme.plist: line 1: `' > > I would expect Mac OS X to complain in a similar way. Yes, fortunately, XML files trigger a syntax error very early. In the past, I ran a text file (incorrectly marked as executable) by mistake because of completion, and many files where created because of a ">" character in many lines. > So my guess is that if an executable doesn't start out with one of the > well-known machine code Magic Numbers, and it doesn't start out with > Pound-Sign Bang Path Name, then the kernel just assumes it's a Bourne > Shell script. Yes, and I hate this useless feature. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Ar?naire project (LIP, ENS-Lyon) From talklists at newgeo.com Wed Jan 27 12:12:11 2010 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 27 Jan 2010 12:12:11 -0800 Subject: +universal help Message-ID: <72AEADE7-9DF1-476D-AEE2-4D80413D19F7@newgeo.com> Hello, I am working on adding +universal to memtester, which is a "configure no" style portfile. Not using MacPorts, I just figured out how to get this to built out universal. There are two files in the source conf-cc conf-ld If I edit them to this: head -n1 conf-cc /usr/bin/gcc -O2 -DPOSIX -c -arch x86_64 -arch i386 head -n1 conf-ld /usr/bin/cc -s -arch x86_64 -arch i386 Previous pre-edit of the files were lacking the full path, and of course, lacking the string "-arch x86_64 -arch i386" Do I need to add ppc and the rest of the -arch's? What is the full list I should be adding? Just adding those will not get +universal to show up in `port info`, can someone guide me with that part? What is the best way to reinplace the data I need to? Here is what I get after running `make`: $file memtester memtester: Mach-O universal binary with 2 architectures memtester (for architecture x86_64): Mach-O 64-bit executable x86_64 memtester (for architecture i386): Mach-O executable i386 My guess would be to add: platform darwin 10 { # Reinplace foo to alter the above two files } * If I do add -arch ppc and -arch ppc64, I get a bunch of errors, the main one being: ld: symbol(s) not found for architecture ppc64 collect2: ld returned 1 exit status lipo: can't open input file: /var/tmp//ccpg8LXX.out (No such file or directory) make: *** [memtester] Error 1 I just tried to built the current port on a PPC machine, and I get: $sudo port install memtester Password: Warning: Can't open index file for source: file:///Users/me/macports Error: Port memtester not found Thanks -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Wed Jan 27 16:48:15 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 27 Jan 2010 18:48:15 -0600 Subject: [63132] trunk/dports/aqua/qt4-mac-devel In-Reply-To: <20100127145822.2183B3DA507E@beta.macosforge.org> References: <20100127145822.2183B3DA507E@beta.macosforge.org> Message-ID: On Jan 27, 2010, at 08:58, sharky at macports.org wrote: > Revision: 63132 > http://trac.macports.org/changeset/63132 > Author: sharky at macports.org > Date: 2010-01-27 06:58:21 -0800 (Wed, 27 Jan 2010) > Log Message: > ----------- > qt4-mac-devel: update to version 4.6.1 (#23379) > > Modified Paths: > -------------- > trunk/dports/aqua/qt4-mac-devel/Portfile > > Removed Paths: > ------------- > trunk/dports/aqua/qt4-mac-devel/files/patch-configure.diff > trunk/dports/aqua/qt4-mac-devel/files/patch-network.pro.diff > > Modified: trunk/dports/aqua/qt4-mac-devel/Portfile > =================================================================== > --- trunk/dports/aqua/qt4-mac-devel/Portfile 2010-01-27 14:54:31 UTC (rev 63131) > +++ trunk/dports/aqua/qt4-mac-devel/Portfile 2010-01-27 14:58:21 UTC (rev 63132) > @@ -4,10 +4,8 @@ > PortSystem 1.0 > > name qt4-mac-devel > -conflicts qt4-mac kdelibs3 libevent > -epoch 1 > -version 4.6.0 > -revision 2 > +conflicts qt4-mac kdelibs3 kdelibs4 libevent > +version 4.6.1 The epoch can never decrease or disappear from a portfile. I put it back in r63159. From ryandesign at macports.org Wed Jan 27 17:08:10 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 27 Jan 2010 19:08:10 -0600 Subject: [MacPorts] #18483: p5-perlmagick no longer compiles In-Reply-To: <855b90561001271658p7cc8ab8kf24651b9a5474162@mail.gmail.com> References: <059.17dd5b8b2877cd51167eed1ed89c6000@macports.org> <068.5268e97bb87e3794c888c6d35ade404f@macports.org> <855b90561001271658p7cc8ab8kf24651b9a5474162@mail.gmail.com> Message-ID: <73B9F233-56F9-4DF5-AF6B-0B31FFF95A1F@macports.org> On Jan 27, 2010, at 18:58, Matthew Hilliard wrote: > I seriously doubt they care. No idea why. I apologize if I've given the impression of not caring by not doing anything about this bug. I'm not sure what I should do. I think I should either delete the p5-perlmagick port and let users install perlmagick using the +perl variant of the ImageMagick port, or preferably modify the p5-perlmagick port so it does what the +perl variant of the ImageMagick port does now and then delete the +perl variant of the ImageMagick port. The latter would be preferable, for all the usual reasons why separate ports are preferred to variants, but I don't know how difficult it will be to do. I admit I have not looked into it yet. From ryandesign at macports.org Wed Jan 27 17:16:28 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 27 Jan 2010 19:16:28 -0600 Subject: +universal help In-Reply-To: <72AEADE7-9DF1-476D-AEE2-4D80413D19F7@newgeo.com> References: <72AEADE7-9DF1-476D-AEE2-4D80413D19F7@newgeo.com> Message-ID: <29A89BA7-66F3-482C-9F8F-53BB3DE27095@macports.org> On Jan 27, 2010, at 14:12, Scott Haneda wrote: > Hello, I am working on adding +universal to memtester, which is a "configure no" style portfile. > > Not using MacPorts, I just figured out how to get this to built out universal. There are two files in the source > conf-cc > conf-ld Yes, sorry, I was going to suggest to you that you modify conf-cc and conf-ld but I hadn't quite gotten everything to work yet. > If I edit them to this: > > head -n1 conf-cc > /usr/bin/gcc -O2 -DPOSIX -c -arch x86_64 -arch i386 > > head -n1 conf-ld > /usr/bin/cc -s -arch x86_64 -arch i386 > > Previous pre-edit of the files were lacking the full path, and of course, lacking the string "-arch x86_64 -arch i386" > > Do I need to add ppc and the rest of the -arch's? What is the full list I should be adding? You need to add the archs the user has requested via the universal_archs variable in macports.conf, accessible in the portfile via the ${configure.universal_archs} variable. MacPorts has already assembled the string with all the arch flags for you. It's in the variable ${configure.universal_cflags}. memtester also doesn't support selecting a different build_arch in macports.conf (portfile variable: ${configure.build_arch}). This is to be expected, since that also happens in a way that assumes a configure-based script; ports that don't use the default universal variant don't by default get build_arch support either. The solution is similar, and the pre-made architecture flag is in the variable ${configure.cc_archflags}. > Just adding those will not get +universal to show up in `port info`, can someone guide me with that part? Declare a universal variant. variant universal { ... } > What is the best way to reinplace the data I need to? > > Here is what I get after running `make`: > $file memtester > memtester: Mach-O universal binary with 2 architectures > memtester (for architecture x86_64): Mach-O 64-bit executable x86_64 > memtester (for architecture i386): Mach-O executable i386 > > My guess would be to add: > platform darwin 10 { > # Reinplace foo to alter the above two files > } This has nothing to do with Snow Leopard specifically so there's no call for a platform darwin 10 section. > * If I do add -arch ppc and -arch ppc64, I get a bunch of errors, the main one being: > ld: symbol(s) not found for architecture ppc64 > collect2: ld returned 1 exit status > lipo: can't open input file: /var/tmp//ccpg8LXX.out (No such file or directory) > make: *** [memtester] Error 1 > > I just tried to built the current port on a PPC machine, and I get: > $sudo port install memtester > Password: > Warning: Can't open index file for source: file:///Users/me/macports > Error: Port memtester not found Attached is a patch that allows memtester to build universal and for a non-default build_arch. It seems to build fine on Snow Leopard (x86_64 only, i386 only, x86_64/i386 universal) and Leopard on a G4 (ppc only, ppc/i386 universal). -------------- next part -------------- A non-text attachment was scrubbed... Name: memtester.diff Type: application/octet-stream Size: 730 bytes Desc: not available URL: From brad at pixilla.com Wed Jan 27 20:41:25 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Wed, 27 Jan 2010 20:41:25 -0800 Subject: [MacPorts] #22993: new port for dovecot-sieve In-Reply-To: <061.3867e8b3c4cbd7bd7f0b0392bcd8c7ba@macports.org> References: <052.5fe92354dbf97059986f620cb0ca2cee@macports.org> <061.3867e8b3c4cbd7bd7f0b0392bcd8c7ba@macports.org> Message-ID: <1A8EE870-5428-4610-912A-EAF051D35953@pixilla.com> On Jan 27, 2010, at 8:06 PM, MacPorts wrote: > #22993: new port for dovecot-sieve > ------------------------------ > +--------------------------------------------- > Reporter: brad@? | Owner: macports-tickets@? > Type: submission | Status: new > Priority: Normal | Milestone: > Component: ports | Version: > Keywords: | Port: dovecot dovecot-sieve > ------------------------------ > +--------------------------------------------- > Changes (by ryandesign@?): > > * cc: ryandesign@? (added) > > > Comment: > > The attached patch to update dovecot contains tons of irrelevancies. > Could > you or someone try again, submitting a diff that makes only the > relevant > changes to update to the latest version? Note that I've made many > changes > to dovecot today, and that 1.2.10 is now the latest version available. Since Ryan already updated dovecot to 1.2.10 there is no need, right? As for the dovecot-sieve portfile I don't know how to do it any better. I could not get it to build without the dovecot sources. I think that was due to dovecot not including headers in it's install. Anyways, I've done what I have time to do. If someone knows how to remove tons of irrelevancies from this teach this puppy a new trick. // Brad # -*- 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 dovecot-sieve epoch 20091222 version 0.1.14 set dovecot_major_version 1.2 set dovecot_minor_version ${dovecot_major_version}.9 categories mail maintainers nomaintainer platforms darwin description The Dovecot Sieve plugin provides mail filtering facilities \ at time of final message delivery long_description The Dovecot Sieve plugin provides mail filtering facilities \ at time of final message delivery using the Sieve (RFC 5228) \ language. By writing Sieve scripts, users can customize how \ messages are delivered, e.g. whether they are forwarded or \ stored in special folders. The Sieve language is meant to be \ simple, extensible and system independent. And, unlike most \ other mail filtering script languages, it does not allow \ users to execute arbitrary programs. This is particularly \ useful to prevent virtual users from having full access to \ the mail store. The intention of the language is to make it \ impossible for users to do anything more complex \ (and dangerous) than write simple mail filters homepage http://pigeonhole.dovecot.org/ master_sites http://www.rename-it.nl/dovecot/$ {dovecot_major_version} \ http://dovecot.org/releases/$ {dovecot_major_version} distname dovecot-${dovecot_major_version}-sieve-${version} extract.suffix tar.gz distfiles dovecot-${dovecot_major_version}-sieve-${version}.$ {extract.suffix} \ dovecot-${dovecot_minor_version}.${extract.suffix} checksums dovecot-${dovecot_major_version}-sieve-${version}.$ {extract.suffix} \ md5 01a92883fde76a5f985b0343e81b0c3d \ sha1 2ba2b4208fa9ed341c38ec8e918b4a87e46b8367 \ rmd160 b61c9448c876062f2b1fd3d1cf72cbc430c5a82e \ dovecot-${dovecot_minor_version}.$ {extract.suffix} \ md5 036ff97fb248dae3bd4b796a0644634f \ sha1 7c1013a1bc856a4366f76ac1f40e856185695e20 \ rmd160 fa17bafabdd6fab69c22d617deff368a4bc165d1 extract.only dovecot-${dovecot_major_version}-sieve-${version}.$ {extract.suffix} post-extract { system "cd ${workpath} && tar xzf ${distpath}/dovecot-$ {dovecot_minor_version}.${extract.suffix}" system "cd ${workpath}/dovecot-${dovecot_minor_version} && ./ configure --prefix=${prefix} && make" } depends_lib port:dovecot configure.args --prefix=${prefix} \ --mandir=${prefix}/share/man \ --with-dovecot=../dovecot-${dovecot_minor_version}/ livecheck.type regex livecheck.url ${master_sites} livecheck.regex "dovecot-${dovecot_major_version}-sieve-(\\d+\\.\\d +(\\.\\d+)?).${extract.suffix}" From ryandesign at macports.org Wed Jan 27 22:00:51 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 28 Jan 2010 00:00:51 -0600 Subject: [63176] users/ged/databases/openldap24 In-Reply-To: <20100128053700.636183DB748C@beta.macosforge.org> References: <20100128053700.636183DB748C@beta.macosforge.org> Message-ID: On Jan 27, 2010, at 23:36, ged at macports.org wrote: > Revision: 63176 > http://trac.macports.org/changeset/63176 > Author: ged at macports.org > Date: 2010-01-27 21:36:56 -0800 (Wed, 27 Jan 2010) > Log Message: > ----------- > First working version of experimental openldap24 port I already updated the openldap port to 2.4.21 a week ago. See r62920 and #21279. From talklists at newgeo.com Wed Jan 27 22:28:36 2010 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 27 Jan 2010 22:28:36 -0800 Subject: +universal help In-Reply-To: <29A89BA7-66F3-482C-9F8F-53BB3DE27095@macports.org> References: <72AEADE7-9DF1-476D-AEE2-4D80413D19F7@newgeo.com> <29A89BA7-66F3-482C-9F8F-53BB3DE27095@macports.org> Message-ID: Trac of patch file has been posted: http://trac.macports.org/ticket/23453 Comments interspersed below... On Jan 27, 2010, at 5:16 PM, Ryan Schmidt wrote: > On Jan 27, 2010, at 14:12, Scott Haneda wrote: > >> Hello, I am working on adding +universal to memtester, which is a "configure no" style portfile. >> >> Not using MacPorts, I just figured out how to get this to built out universal. There are two files in the source >> conf-cc >> conf-ld > > Yes, sorry, I was going to suggest to you that you modify conf-cc and conf-ld but I hadn't quite gotten everything to work yet. No problem, in a way I am glad you did not, as I had to trudge through it :) I looked at those files before, and noticed they had random comments below line #1. I always wondered how that worked. I explored the source and saw there are `head -n1` lines that read those two files in, which now makes sense to me. From there, I figured to check the difference in gcc/cc $which cc /usr/bin/cc $which gcc /usr/bin/gcc Learning those are just links to gcc-4.2 lrwxr-xr-x 1 root wheel 7 Jan 22 03:06 /usr/bin/cc -> gcc-4.2 lrwxr-xr-x 1 root wheel 7 Jan 22 03:06 /usr/bin/gcc -> gcc-4.2 And I also found: -rwxr-xr-x 1 root wheel 97392 May 18 2009 /usr/bin/gcc-4.0 Not sure why 4.0 is kept around, but at least I know there is that option available just in case some day, it may be needed. I thought to point this out in case it would be helpful to anyone else in this same "configure no" scenario. >> If I edit them to this: >> >> head -n1 conf-cc >> /usr/bin/gcc -O2 -DPOSIX -c -arch x86_64 -arch i386 >> >> head -n1 conf-ld >> /usr/bin/cc -s -arch x86_64 -arch i386 >> >> Previous pre-edit of the files were lacking the full path, and of course, lacking the string "-arch x86_64 -arch i386" >> >> Do I need to add ppc and the rest of the -arch's? What is the full list I should be adding? > > You need to add the archs the user has requested via the universal_archs variable in macports.conf, accessible in the portfile via the ${configure.universal_archs} variable. MacPorts has already assembled the string with all the arch flags for you. It's in the variable ${configure.universal_cflags}. Ahhh, ok, I get it. So ${configure.universal_archs} and ${configure.universal_cflags} are sort of dynamic variables, in that, at install time of MacPorts, they will get set to sane defaults for that architecture/flags. I need not really think about adding in the arch's, especially not to add in archs for example, for ppc or ppc64, since in my case, I am on Intel. However, someone on PPC, when they installed, they would have entirely different defaults in macports.conf, and they would inherit those into those variables. This actually clears up the last bits of confusion I had with my thread the other day on configuring and setting up macports.conf on a new install. And I am quite please to be able to show: $port installed | wc -l 45 So 44 ports installed (line one does not count) on this new system install. I am a little confused about: $port installed | grep -v 'universal' The following ports are currently installed: autoconf @2.65_1 (active) autoconf213 @2.13_1 (active) curl-ca-bundle @7.19.7_1 (active) mysql5 @5.1.42_0 (active) mysql5-server @5.1.42_0 (active) p5-locale-gettext @1.05_2 (active) perl5 @5.8.9_0 (active) I never explicitly installed any of those, (sans Mysql) so they came along with Apache2, or php5, or some other software. Am I just getting lucky that the universal builds are working with these? Or is it that as long as those are all the *same* arch, I am fine? $file `which mysql5` /opt/local/bin/mysql5: Mach-O 64-bit executable x86_64 Is this the relevant reason for MySql not being able to have a universal variant: http://bugs.mysql.com/bug.php?id=47360 I also found this ticket: http://trac.macports.org/changeset/62287 Since it does not appear there is going to be a timely fix on MySql's part for this, at least, in reading over the bugs.mysql.com thread, would taking the suggestion to use lipo and stuff them together be an option, or does lipo add more build time than is desired, that being the only downside I can estimate. Just curious, as it does not effect me at this time. > memtester also doesn't support selecting a different build_arch in macports.conf (portfile variable: ${configure.build_arch}). This is to be expected, since that also happens in a way that assumes a configure-based script; ports that don't use the default universal variant don't by default get build_arch support either. The solution is similar, and the pre-made architecture flag is in the variable ${configure.cc_archflags}. In regards to the lack of a configure script, why would a developer chose omit it? How exactly are configure scripts made? I am assuming that they are not hand coded, but perhaps tuned by hand at some point? Looking over a few, they look more machine written than hand written. That being the case, I fail to see why one wold chose to not have a configure step. >> Just adding those will not get +universal to show up in `port info`, can someone guide me with that part? > > Declare a universal variant. > > variant universal { > ... > } Yep, got it, thanks! >> What is the best way to reinplace the data I need to? >> >> Here is what I get after running `make`: >> $file memtester >> memtester: Mach-O universal binary with 2 architectures >> memtester (for architecture x86_64): Mach-O 64-bit executable x86_64 >> memtester (for architecture i386): Mach-O executable i386 >> >> My guess would be to add: >> platform darwin 10 { >> # Reinplace foo to alter the above two files >> } > > This has nothing to do with Snow Leopard specifically so there's no call for a platform darwin 10 section. Yeah I was sort of stumbling along at this point, using `mtr` and a grep for 'configure no' through all the ports. I still do not entirely understand the platform "phase"?, but am gathering, it is how you do specific things for specific platforms. So darwin 10 == 10.6 and darwin 9 == 10.5 etc etc. If there is ever call for special scenarios just for that OS release, this is where you would do it? For example, `mtr` needs "configure.env-append LIBS=-lresolv" for 10.6, but apparently does not need it for lesser versioned OS's? Or I must have this wrong, as `port info mtr` lists "darwin_10" as a variant, implying I can apply that to any version OS I desire. So yeah, still a little muddled in this area. >> * If I do add -arch ppc and -arch ppc64, I get a bunch of errors, the main one being: >> ld: symbol(s) not found for architecture ppc64 >> collect2: ld returned 1 exit status >> lipo: can't open input file: /var/tmp//ccpg8LXX.out (No such file or directory) >> make: *** [memtester] Error 1 >> >> I just tried to built the current port on a PPC machine, and I get: >> $sudo port install memtester >> Password: >> Warning: Can't open index file for source: file:///Users/me/macports >> Error: Port memtester not found > > Attached is a patch that allows memtester to build universal and for a non-default build_arch. It seems to build fine on Snow Leopard (x86_64 only, i386 only, x86_64/i386 universal) and Leopard on a G4 (ppc only, ppc/i386 universal). I tested it on: $uname -a Darwin foo.example.com 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh Which is also a pretty aged PPC machine, humping along on 10.5 somehow. Thank you for putting in the work of the diff/patch, it was very helpful in my understanding this process. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Wed Jan 27 22:51:19 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 28 Jan 2010 00:51:19 -0600 Subject: +universal help In-Reply-To: References: <72AEADE7-9DF1-476D-AEE2-4D80413D19F7@newgeo.com> <29A89BA7-66F3-482C-9F8F-53BB3DE27095@macports.org> Message-ID: <9FDEF252-2AE6-41F1-8036-37776579B581@macports.org> On Jan 28, 2010, at 00:28, Scott Haneda wrote: > Trac of patch file has been posted: > http://trac.macports.org/ticket/23453 Committed. >>> Not using MacPorts, I just figured out how to get this to built out universal. There are two files in the source >>> conf-cc >>> conf-ld >> >> Yes, sorry, I was going to suggest to you that you modify conf-cc and conf-ld but I hadn't quite gotten everything to work yet. > > No problem, in a way I am glad you did not, as I had to trudge through it :) I looked at those files before, and noticed they had random comments below line #1. I always wondered how that worked. > > I explored the source and saw there are `head -n1` lines that read those two files in, which now makes sense to me. From there, I figured to check the difference in gcc/cc > > $which cc > /usr/bin/cc > $which gcc > /usr/bin/gcc > > Learning those are just links to gcc-4.2 > > lrwxr-xr-x 1 root wheel 7 Jan 22 03:06 /usr/bin/cc -> gcc-4.2 > lrwxr-xr-x 1 root wheel 7 Jan 22 03:06 /usr/bin/gcc -> gcc-4.2 > > And I also found: > > -rwxr-xr-x 1 root wheel 97392 May 18 2009 /usr/bin/gcc-4.0 > > Not sure why 4.0 is kept around, but at least I know there is that option available just in case some day, it may be needed. > > I thought to point this out in case it would be helpful to anyone else in this same "configure no" scenario. Right. Different versions of GCC are default on different versions of Mac OS X: Mac OS X 10.3: GCC 3.3 Mac OS X 10.4: GCC 4.0 Mac OS X 10.5: GCC 4.0 Mac OS X 10.6: GCC 4.2 Most software builds with any version of GCC. Some require a specific version of GCC. That's why Tiger and Leopard still ship with GCC 3.3, and why Snow Leopard still ships with GCC 4.0 -- if some old software isn't ready for the new version of GCC yet, it can use the older one. In MacPorts, ${configure.cc} represents the suggested compiler to use for the current version of Mac OS X. MacPorts automatically sets the CC variable to ${configure.cc} so most autoconf-based ports should just work and pick up this compiler. > Ahhh, ok, I get it. So ${configure.universal_archs} and ${configure.universal_cflags} are sort of dynamic variables, in that, at install time of MacPorts, they will get set to sane defaults for that architecture/flags. I need not really think about adding in the arch's, especially not to add in archs for example, for ppc or ppc64, since in my case, I am on Intel. However, someone on PPC, when they installed, they would have entirely different defaults in macports.conf, and they would inherit those into those variables. ${configure.universal_cflags} is not set at install time; it's set every time you run the port command. Same with all other variables in the port. In this case, ${configure.universal_cflags} variable you can access in a portfile is set by MacPorts from the value of the universal_cflags setting in macports.conf. MacPorts does set this value differently in macports.conf at install time based on your OS version. But the user can change it at any time. > This actually clears up the last bits of confusion I had with my thread the other day on configuring and setting up macports.conf on a new install. > > And I am quite please to be able to show: > $port installed | wc -l > 45 > > So 44 ports installed (line one does not count) on this new system install. > > I am a little confused about: > > $port installed | grep -v 'universal' > The following ports are currently installed: > autoconf @2.65_1 (active) > autoconf213 @2.13_1 (active) > curl-ca-bundle @7.19.7_1 (active) > mysql5 @5.1.42_0 (active) > mysql5-server @5.1.42_0 (active) > p5-locale-gettext @1.05_2 (active) > perl5 @5.8.9_0 (active) > > I never explicitly installed any of those, (sans Mysql) so they came along with Apache2, or php5, or some other software. Am I just getting lucky that the universal builds are working with these? Or is it that as long as those are all the *same* arch, I am fine? Build dependencies don't need to be universal, generally. Library and runtime dependencies do. autoconf (and the older version autoconf213 which is needed by php5) are build dependencies only so it doesn't matter if they're universal. curl-ca-bundle does not install compiled software; it only installs a text file. Therefore it has no universal variant. Same with mysql5-server, which installs only directories and plists. p5-locale-gettext is a perl module, using the perl5 portgroup. The perl5 portgroup specifies "universal_variant no"; presumably there is some problem endemic to perl modules preventing them from building universal, so it's turned off for all of them at the source. Perhaps the reason is that perl5.8 itself could not build universal until ten days ago (see r62847). Perhaps it's now possible to build perl modules universal as well. Someone should test that. Note that perl5 is a stub port, doing nothing more than depending on perl5.8 or perl5.10 where the actual software is installed. Since perl5 installs no files, it has no universal variant. > $file `which mysql5` > /opt/local/bin/mysql5: Mach-O 64-bit executable x86_64 > > Is this the relevant reason for MySql not being able to have a universal variant: > http://bugs.mysql.com/bug.php?id=47360 > > I also found this ticket: > http://trac.macports.org/changeset/62287 > > Since it does not appear there is going to be a timely fix on MySql's part for this, at least, in reading over the bugs.mysql.com thread, would taking the suggestion to use lipo and stuff them together be an option, or does lipo add more build time than is desired, that being the only downside I can estimate. > > Just curious, as it does not effect me at this time. We could try the muniversal portgroup for the mysql5 port. However I would prefer the developers of MySQL fix this properly upstream. It also works fine if you just disable the embedded server, which most people don't need. That's the +no_embedded_server variant. Then you can use the +universal variant. The embedded server is built by default solely for the benefit of amarok. I am inclined to not build the embedded server by default, and change the +no_embedded_server variant into an +embedded_server variant, so that mysql5 can build universal by default. >> memtester also doesn't support selecting a different build_arch in macports.conf (portfile variable: ${configure.build_arch}). This is to be expected, since that also happens in a way that assumes a configure-based script; ports that don't use the default universal variant don't by default get build_arch support either. The solution is similar, and the pre-made architecture flag is in the variable ${configure.cc_archflags}. > > In regards to the lack of a configure script, why would a developer chose omit it? How exactly are configure scripts made? I am assuming that they are not hand coded, but perhaps tuned by hand at some point? Looking over a few, they look more machine written than hand written. That being the case, I fail to see why one wold chose to not have a configure step. Most configure scripts are machine-generated by a program called autoconf. The developer writes an automake file called configure.am, which gets turned into configure.in, which gets turned into configure, which is what the user runs. autoconf is a very complex program by now with tons of cruft in it; you've seen how large and unwieldy the configure scripts it generates get. Some developers can't tolerate autoconf's bloat, complexity and general not-the-best-way-of-doing-things-ness and either roll their own configure scripts, use a competing product (e.g. cmake), or if their software is simple enough (few files to compile, few dependencies) they can get away with just writing a Makefile and forgoing the configure script entirely. Except that then in MacPorts we have to manually handle CC, CXX, CPP, CFLAGS, CPPFLAGS ,CXXFLAGS, LDFLAGS and other variables, since MacPorts only passes them to the configure script; if there isn't a configure script, then the variables don't get passed anywhere, and if there's a homegrown configure script, it may not respect these variables. >>> My guess would be to add: >>> platform darwin 10 { >>> # Reinplace foo to alter the above two files >>> } >> >> This has nothing to do with Snow Leopard specifically so there's no call for a platform darwin 10 section. > > Yeah I was sort of stumbling along at this point, using `mtr` and a grep for 'configure no' through all the ports. I still do not entirely understand the platform "phase"? It's not a phase; it's basically a variant that MacPorts auto-selects for you based on the current OS. > but am gathering, it is how you do specific things for specific platforms. So darwin 10 == 10.6 and darwin 9 == 10.5 etc etc. Yes. > If there is ever call for special scenarios just for that OS release, this is where you would do it? Yes. > For example, `mtr` needs "configure.env-append LIBS=-lresolv" for 10.6, but apparently does not need it for lesser versioned OS's? Presumably that's correct. Looking through the log, I added this in r56011 specifically to fix Snow Leopard, as reported on the list: http://lists.macosforge.org/pipermail/macports-users/2009-August/016147.html > Or I must have this wrong, as `port info mtr` lists "darwin_10" as a variant, implying I can apply that to any version OS I desire. So yeah, still a little muddled in this area. You should not try to select +darwin_10 on any other platform. In fact, MacPorts will prevent you from doing so: $ sudo port install mtr +darwin_10 Password: Warning: Implicit variants should not be explicitly set or unset. darwin_10 will be ignored. ---> Computing dependencies for mtr ---> Fetching mtr ^C From talklists at newgeo.com Wed Jan 27 23:31:00 2010 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 27 Jan 2010 23:31:00 -0800 Subject: +universal help In-Reply-To: <9FDEF252-2AE6-41F1-8036-37776579B581@macports.org> References: <72AEADE7-9DF1-476D-AEE2-4D80413D19F7@newgeo.com> <29A89BA7-66F3-482C-9F8F-53BB3DE27095@macports.org> <9FDEF252-2AE6-41F1-8036-37776579B581@macports.org> Message-ID: On Jan 27, 2010, at 10:51 PM, Ryan Schmidt wrote: > On Jan 28, 2010, at 00:28, Scott Haneda wrote: > >> Trac of patch file has been posted: >> http://trac.macports.org/ticket/23453 > > Committed. Thanks. When one says "committed" does that mean I can run `port -d sync` and I should see that new port, and any others come in? I forgot the -d and got blank, so I could not answer that one on my own this time around. I suppose there are various rsync servers I may have to wait on to grab it from, but in most cases, "committed" means, sync and you should have it, relatively soon? >> This actually clears up the last bits of confusion I had with my thread the other day on configuring and setting up macports.conf on a new install. >> >> And I am quite please to be able to show: >> $port installed | wc -l >> 45 >> >> So 44 ports installed (line one does not count) on this new system install. >> >> I am a little confused about: >> >> $port installed | grep -v 'universal' >> The following ports are currently installed: >> autoconf @2.65_1 (active) >> autoconf213 @2.13_1 (active) >> curl-ca-bundle @7.19.7_1 (active) >> mysql5 @5.1.42_0 (active) >> mysql5-server @5.1.42_0 (active) >> p5-locale-gettext @1.05_2 (active) >> perl5 @5.8.9_0 (active) >> >> I never explicitly installed any of those, (sans Mysql) so they came along with Apache2, or php5, or some other software. Am I just getting lucky that the universal builds are working with these? Or is it that as long as those are all the *same* arch, I am fine? > > Build dependencies don't need to be universal, generally. Library and runtime dependencies do. > > autoconf (and the older version autoconf213 which is needed by php5) are build dependencies only so it doesn't matter if they're universal. Can build dependencies be uninstalled with no harm, as they are only needed during build time? > curl-ca-bundle does not install compiled software; it only installs a text file. Therefore it has no universal variant. > > Same with mysql5-server, which installs only directories and plists. Understood on that one. > p5-locale-gettext is a perl module, using the perl5 portgroup. The perl5 portgroup specifies "universal_variant no"; presumably there is some problem endemic to perl modules preventing them from building universal, so it's turned off for all of them at the source. Got it. > Perhaps the reason is that perl5.8 itself could not build universal until ten days ago (see r62847). Perhaps it's now possible to build perl modules universal as well. Someone should test that. Is that a possibility for me to test if it is disabled at the source? > Note that perl5 is a stub port, doing nothing more than depending on perl5.8 or perl5.10 where the actual software is installed. Since perl5 installs no files, it has no universal variant. Noted, thanks. >> $file `which mysql5` >> /opt/local/bin/mysql5: Mach-O 64-bit executable x86_64 >> >> Is this the relevant reason for MySql not being able to have a universal variant: >> http://bugs.mysql.com/bug.php?id=47360 >> >> I also found this ticket: >> http://trac.macports.org/changeset/62287 >> >> Since it does not appear there is going to be a timely fix on MySql's part for this, at least, in reading over the bugs.mysql.com thread, would taking the suggestion to use lipo and stuff them together be an option, or does lipo add more build time than is desired, that being the only downside I can estimate. >> >> Just curious, as it does not effect me at this time. > > We could try the muniversal portgroup for the mysql5 port. However I would prefer the developers of MySQL fix this properly upstream. Me too. > It also works fine if you just disable the embedded server, which most people don't need. That's the +no_embedded_server variant. Then you can use the +universal variant. The embedded server is built by default solely for the benefit of amarok. I am inclined to not build the embedded server by default, and change the +no_embedded_server variant into an +embedded_server variant, so that mysql5 can build universal by default. I do not know what amarok, but if they made concessions for one feature for one application or service, that seems silly. I completely agree with you that it should be a +embedded_server variant instead, that makes a heck of a lot more sense. However, then that build bug never gets any more attention. :( >>> memtester also doesn't support selecting a different build_arch in macports.conf (portfile variable: ${configure.build_arch}). This is to be expected, since that also happens in a way that assumes a configure-based script; ports that don't use the default universal variant don't by default get build_arch support either. The solution is similar, and the pre-made architecture flag is in the variable ${configure.cc_archflags}. >> >> In regards to the lack of a configure script, why would a developer chose omit it? How exactly are configure scripts made? I am assuming that they are not hand coded, but perhaps tuned by hand at some point? Looking over a few, they look more machine written than hand written. That being the case, I fail to see why one wold chose to not have a configure step. > > Most configure scripts are machine-generated by a program called autoconf. The developer writes an automake file called configure.am, which gets turned into configure.in, which gets turned into configure, which is what the user runs. autoconf is a very complex program by now with tons of cruft in it; you've seen how large and unwieldy the configure scripts it generates get. Indeed, which is why I assumed, no mere mortal was writing those :) > Some developers can't tolerate autoconf's bloat, complexity and general not-the-best-way-of-doing-things-ness and either roll their own configure scripts, use a competing product (e.g. cmake), or if their software is simple enough (few files to compile, few dependencies) they can get away with just writing a Makefile and forgoing the configure script entirely. Except that then in MacPorts we have to manually handle CC, CXX, CPP, CFLAGS, CPPFLAGS ,CXXFLAGS, LDFLAGS and other variables, since MacPorts only passes them to the configure script; if there isn't a configure script, then the variables don't get passed anywhere, and if there's a homegrown configure script, it may not respect these variables. Really quickly, Xcode just has a "Build" or "Build and Go" button I think. I have only poked at it a second or two. Does all this magic happen behind the scenes, or does an xcode style, or I guess I should say, Mac OS X GUI based desktop app, not use the above explained autoconf mechanism? >>>> My guess would be to add: >>>> platform darwin 10 { >>>> # Reinplace foo to alter the above two files >>>> } >>> >>> This has nothing to do with Snow Leopard specifically so there's no call for a platform darwin 10 section. >> >> Yeah I was sort of stumbling along at this point, using `mtr` and a grep for 'configure no' through all the ports. I still do not entirely understand the platform "phase"? > > It's not a phase; it's basically a variant that MacPorts auto-selects for you based on the current OS. Ok. >> but am gathering, it is how you do specific things for specific platforms. So darwin 10 == 10.6 and darwin 9 == 10.5 etc etc. > > Yes. > >> If there is ever call for special scenarios just for that OS release, this is where you would do it? > > Yes. > >> For example, `mtr` needs "configure.env-append LIBS=-lresolv" for 10.6, but apparently does not need it for lesser versioned OS's? > > Presumably that's correct. Looking through the log, I added this in r56011 specifically to fix Snow Leopard, as reported on the list: > > http://lists.macosforge.org/pipermail/macports-users/2009-August/016147.html Is your name not attached to everything I seem to need to get my hands on :) Any handy tools as a every day developer / small ISP system admin that I am missing out on that I may not know about? >> Or I must have this wrong, as `port info mtr` lists "darwin_10" as a variant, implying I can apply that to any version OS I desire. So yeah, still a little muddled in this area. > > You should not try to select +darwin_10 on any other platform. In fact, MacPorts will prevent you from doing so: > > $ sudo port install mtr +darwin_10 > Password: > Warning: Implicit variants should not be explicitly set or unset. darwin_10 will be ignored. > ---> Computing dependencies for mtr > ---> Fetching mtr > ^C Then why is it shown as a variant, that is confusing? This makes the most sense, but I rarely use the variants keyword to port. $port variants mtr mtr has the variants: darwin_10: Platform variant, selected automatically universal: Build for multiple architectures I usually use the info keyword: $port info mtr mtr @0.75 (net) Variants: darwin_10, universal That would make me, and I suspect most others, believe that `port install mtr +darwin_10` is a viable option. Would a condition of if current_platform in variant_list then remove_current_platform_variant. Or you get the idea. Thank you again Ryan. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Wed Jan 27 23:47:25 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 28 Jan 2010 01:47:25 -0600 Subject: +universal help In-Reply-To: References: <72AEADE7-9DF1-476D-AEE2-4D80413D19F7@newgeo.com> <29A89BA7-66F3-482C-9F8F-53BB3DE27095@macports.org> <9FDEF252-2AE6-41F1-8036-37776579B581@macports.org> Message-ID: <65C96783-C6F7-411F-99A3-89EE93CFD1CB@macports.org> On Jan 28, 2010, at 01:31, Scott Haneda wrote: > On Jan 27, 2010, at 10:51 PM, Ryan Schmidt wrote: > >> Committed. > > Thanks. When one says "committed" does that mean I can run `port -d sync` and I should see that new port, and any others come in? I forgot the -d and got blank, so I could not answer that one on my own this time around. > > I suppose there are various rsync servers I may have to wait on to grab it from, but in most cases, "committed" means, sync and you should have it, relatively soon? If your dports are using rsync (which is the default method of syncing), you'll get the change as soon as the rsync server syncs with the Subversion repository, which happens every half hour. If your dports are using Subversion, you can get the change immediately after it's committed. > Can build dependencies be uninstalled with no harm, as they are only needed during build time? Yes. MacPorts permits you to uninstall build dependencies, but prevents you from uninstalling library and runtime dependencies. >> Perhaps the reason is that perl5.8 itself could not build universal until ten days ago (see r62847). Perhaps it's now possible to build perl modules universal as well. Someone should test that. > > Is that a possibility for me to test if it is disabled at the source? You can remove "universal_variant no" from the portgroup and then test if the ports in that portgroup can build universal. >> It also works fine if you just disable the embedded server, which most people don't need. That's the +no_embedded_server variant. Then you can use the +universal variant. The embedded server is built by default solely for the benefit of amarok. I am inclined to not build the embedded server by default, and change the +no_embedded_server variant into an +embedded_server variant, so that mysql5 can build universal by default. > > I do not know what amarok, but if they made concessions for one feature for one application or service, that seems silly. I completely agree with you that it should be a +embedded_server variant instead, that makes a heck of a lot more sense. Well, it started out as a variant in mysql5-devel. Then it became the default in mysql5-devel. As I recall, these changes were made by the maintainer of amarok, not me. Then when mysql5 was updated to 5.1, I copied every change from mysql5-devel, including those. Then when I became aware of how this was preventing universal builds, I added the no_embedded_server variant. But, I would really like to go back to the way it was originally, where the embedded server is not built by default, since most users don't need it and it breaks the universal build. > However, then that build bug never gets any more attention. :( If MySQL AB is in the habit of ignoring submitted bugs, then that's true. However, I hope they are not in that habit. >> Some developers can't tolerate autoconf's bloat, complexity and general not-the-best-way-of-doing-things-ness and either roll their own configure scripts, use a competing product (e.g. cmake), or if their software is simple enough (few files to compile, few dependencies) they can get away with just writing a Makefile and forgoing the configure script entirely. Except that then in MacPorts we have to manually handle CC, CXX, CPP, CFLAGS, CPPFLAGS ,CXXFLAGS, LDFLAGS and other variables, since MacPorts only passes them to the configure script; if there isn't a configure script, then the variables don't get passed anywhere, and if there's a homegrown configure script, it may not respect these variables. > > Really quickly, Xcode just has a "Build" or "Build and Go" button I think. I have only poked at it a second or two. Does all this magic happen behind the scenes, or does an xcode style, or I guess I should say, Mac OS X GUI based desktop app, not use the above explained autoconf mechanism? Correct, Xcode projects are another alternative to configure scripts. >>> For example, `mtr` needs "configure.env-append LIBS=-lresolv" for 10.6, but apparently does not need it for lesser versioned OS's? >> >> Presumably that's correct. Looking through the log, I added this in r56011 specifically to fix Snow Leopard, as reported on the list: >> >> http://lists.macosforge.org/pipermail/macports-users/2009-August/016147.html > > Is your name not attached to everything I seem to need to get my hands on :) Any handy tools as a every day developer / small ISP system admin that I am missing out on that I may not know about? Not sure. :) >>> Or I must have this wrong, as `port info mtr` lists "darwin_10" as a variant, implying I can apply that to any version OS I desire. So yeah, still a little muddled in this area. >> >> You should not try to select +darwin_10 on any other platform. In fact, MacPorts will prevent you from doing so: >> >> $ sudo port install mtr +darwin_10 >> Password: >> Warning: Implicit variants should not be explicitly set or unset. darwin_10 will be ignored. >> ---> Computing dependencies for mtr >> ---> Fetching mtr >> ^C > > Then why is it shown as a variant, that is confusing? > > This makes the most sense, but I rarely use the variants keyword to port. > $port variants mtr > mtr has the variants: > darwin_10: Platform variant, selected automatically > universal: Build for multiple architectures > > I usually use the info keyword: > $port info mtr > mtr @0.75 (net) > Variants: darwin_10, universal > > That would make me, and I suspect most others, believe that `port install mtr +darwin_10` is a viable option. Would a condition of if current_platform in variant_list then remove_current_platform_variant. Or you get the idea. I don't know how to answer you, other than to say that platform variants and regular variants share a lot of code in MacPorts base. They're quite similar in most ways. The differences are that platform variants can have more than one word for their name (i.e. "darwin 10") whereas normal variants can only have a single word; and platform variants are automatically selected by MacPorts. Apologies if it appears from the output of "port info" or "port variants" that you should or can select such variants manually, but that is not the case. At least we have now fixed the problem such that selecting (or deselecting) a platform variant now prints an error message and is ignored; MacPorts used to let you select (or deselect) these manually, which was of course detrimental to the correct functioning of the port. From ryandesign at macports.org Wed Jan 27 23:52:07 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 28 Jan 2010 01:52:07 -0600 Subject: [MacPorts] #22993: new port for dovecot-sieve In-Reply-To: <1A8EE870-5428-4610-912A-EAF051D35953@pixilla.com> References: <052.5fe92354dbf97059986f620cb0ca2cee@macports.org> <061.3867e8b3c4cbd7bd7f0b0392bcd8c7ba@macports.org> <1A8EE870-5428-4610-912A-EAF051D35953@pixilla.com> Message-ID: On Jan 27, 2010, at 22:41, Bradley Giesbrecht wrote: > On Jan 27, 2010, at 8:06 PM, MacPorts wrote: > >> #22993: new port for dovecot-sieve >> ------------------------------+--------------------------------------------- >> Reporter: brad@? | Owner: macports-tickets@? >> Type: submission | Status: new >> Priority: Normal | Milestone: >> Component: ports | Version: >> Keywords: | Port: dovecot dovecot-sieve >> ------------------------------+--------------------------------------------- >> Changes (by ryandesign@?): >> >> * cc: ryandesign@? (added) >> >> >> Comment: >> >> The attached patch to update dovecot contains tons of irrelevancies. Could >> you or someone try again, submitting a diff that makes only the relevant >> changes to update to the latest version? Note that I've made many changes >> to dovecot today, and that 1.2.10 is now the latest version available. > > > Since Ryan already updated dovecot to 1.2.10 there is no need, right? I have not updated dovecot to 1.2.10 yet. > As for the dovecot-sieve portfile I don't know how to do it any better. I haven't even begun to look at your dovecot-sieve portfile yet; I was just interested in getting dovecot updated to 1.2.10. I was referring to irrelevancies in the patch that was supplied in this ticket to perform that update: http://trac.macports.org/attachment/ticket/22993/patch-Portfile For example, it changes the Id line, it changes the branch variable name to major_version, it introduces a typo in the long_description, it adds an unnecessary distname directive, it changes pkgconfig from a build to a library dependency, it adds Darwin 7 blocks when MacPorts now requires Darwin 8 or newer, it changes the formatting of the rawlog and ldap variants.... Why were all these changes made and what do they have with updating the port to 1.2.10? From ryandesign at macports.org Thu Jan 28 00:00:02 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 28 Jan 2010 02:00:02 -0600 Subject: [MacPorts] #22993: new port for dovecot-sieve In-Reply-To: References: <052.5fe92354dbf97059986f620cb0ca2cee@macports.org> <061.3867e8b3c4cbd7bd7f0b0392bcd8c7ba@macports.org> <1A8EE870-5428-4610-912A-EAF051D35953@pixilla.com> Message-ID: <6BCD50FE-01C3-4A38-AAFD-C244B422ECAF@macports.org> On Jan 28, 2010, at 01:52, Ryan Schmidt wrote: > I haven't even begun to look at your dovecot-sieve portfile yet; I was just interested in getting dovecot updated to 1.2.10. I was referring to irrelevancies in the patch that was supplied in this ticket to perform that update: > > http://trac.macports.org/attachment/ticket/22993/patch-Portfile > > For example, it changes the Id line, it changes the branch variable name to major_version, it introduces a typo in the long_description, it adds an unnecessary distname directive, it changes pkgconfig from a build to a library dependency, it adds Darwin 7 blocks when MacPorts now requires Darwin 8 or newer, it changes the formatting of the rawlog and ldap variants.... Why were all these changes made and what do they have with updating the port to 1.2.10? To answer this question a bit more clearly, I don't believe you deliberately made these changes. Your change to the Id line reveals what I believe happened: -# $Id: Portfile 60534 2009-11-14 23:10:00Z ryandesign at macports.org $ +# $Id: Portfile 39958 2008-09-14 03:40:17Z jberry at macports.org $ I assume you took the original Portfile at revision 39958 and made some changes to it. But then you made a diff between the original Portfile at revision 60534 and your changed one which was based on the Portfile at revision 39958. Thus, your diff undid all the changes that have been made to the Portfile in the repository between r39958 and r60534. We probably don't want all those changes undone. Therefore, please submit a diff between the original Portfile at revision 39958 and your changed one, or much more preferably submit a diff between the original Portfile at the current HEAD revision and a new changed version that you create based on the current HEAD revision. From cristiano.fontana at gmail.com Thu Jan 28 01:53:09 2010 From: cristiano.fontana at gmail.com (Cristiano Fontana) Date: Thu, 28 Jan 2010 10:53:09 +0100 Subject: build.env in post-build Message-ID: It seems that in the post-build phase the environment of build.env is not set. How can I set it? Cristiano From ryandesign at macports.org Thu Jan 28 02:30:32 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 28 Jan 2010 04:30:32 -0600 Subject: build.env in post-build In-Reply-To: References: Message-ID: On Jan 28, 2010, at 03:53, Cristiano Fontana wrote: > It seems that in the post-build phase the environment of build.env is not set. > How can I set it? Can you show us a portfile that demonstrates this problem? From jmr at macports.org Thu Jan 28 02:42:17 2010 From: jmr at macports.org (Joshua Root) Date: Thu, 28 Jan 2010 21:42:17 +1100 Subject: build.env in post-build In-Reply-To: References: Message-ID: <4B616A09.3030401@macports.org> On 2010-1-28 21:30 , Ryan Schmidt wrote: > > On Jan 28, 2010, at 03:53, Cristiano Fontana wrote: > >> It seems that in the post-build phase the environment of build.env is not set. >> How can I set it? > > Can you show us a portfile that demonstrates this problem? It's not a bug, build.env only gets used when you "command_exec build", just like build.args, build.cmd, et al. You probably want something like: system "cd $somewhere && env ${build.env} mycommand ..." - Josh From ryandesign at macports.org Thu Jan 28 07:24:40 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 28 Jan 2010 09:24:40 -0600 Subject: Peer review request: changes to portutil.tcl Message-ID: <7BF43CB7-AA37-426D-B261-4CD965E7ED89@macports.org> Could I get another pair of eyes to review my proposed changes? http://trac.macports.org/ticket/23456 I'm changing a fundamental function in MacPorts base, with the intended result that arguments should retain any quoting. It seems to work for me for the case I'm interested in at the moment, but I haven't tested all other cases, and I'm confused why the code was written the way it was before, and why this problem hasn't come up before. Landon, I'm Cc'ing you specifically because my proposed change seems to undo r628 which you committed 7 years ago; if you can recall the reasoning behind your commit that might help evaluate this proposed change. From ndiscreet at gmail.com Thu Jan 28 12:36:16 2010 From: ndiscreet at gmail.com (Altoine Barker) Date: Thu, 28 Jan 2010 14:36:16 -0600 Subject: XCode Project Portfile Question Message-ID: <4B61F540.9060504@GmAiL.cOm> I'm trying to build a Portfile based off of an xcode project but I need to ask a few questions. 1. How do you build -alltargets like this command example: xcodebuild -project myProject -alltargets 2. How do you include cmake commands in a portfile like the following example: cmake -DPYTHON_INC=/opt/local/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1 -G Xcode ../myProject 3. How do you detect an arch and include it in a Portfile made for an xcode project? 4. Will this be made further complex by pulling the source from an svn source? I apologize for disturbing you all but I have read all over the place and before I dive in and start doing the ol' trial and error, I had hoped that I could avoid the arduous process of reinventing the wheel if avoidable. TIA -Altoine From dports at ambulatoryclam.net Thu Jan 28 14:26:00 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Thu, 28 Jan 2010 14:26:00 -0800 Subject: Can't access configure.env in portfile In-Reply-To: References: <947340C9-EDDB-4279-9CCE-8FF09D761EE1@macports.org> <4B22BA95.1010102@macports.org> Message-ID: <20100128222600.GB44140@ambulatoryclam.net> On Fri, Dec 11, 2009 at 04:12:30PM -0600, Ryan Schmidt wrote: > > On Dec 11, 2009, at 15:33, Rainer M?ller wrote: > > > On 2009-11-29 15:33 , Ryan Schmidt wrote: > > > >> See, both before and after the configure phase, configure.env only > >> contains the "FOO=bar" variable I added. But what I actually want to > >> know about are the CFLAGS, CPPFLAGS, CXXFLAGS, etc. that MacPorts > >> sets automatically. Yes, I know we have separate variables > >> ${configure.cflags}, ${configure.cppflags}, ${configure.cxxflags}, > >> etc. for most (all?) of those, but I'd rather not have to enumerate > >> over them myself since to my mind MacPorts should have already done > >> so for me somewhere. > > > > If you want to get better results for debugging use: > > configure.cmd /usr/bin/env > > My reasons for asking were not for debugging but for a reworking of the php5extension portgroup. I've found out what I was doing wrong though and will be able to commit my update soon. What solution did you wind up with? I'm wondering if it might be useful for a problem I'm having with the mit-scheme port where I also wanted to get ahold of configure.env: The port needs to run configure/make more than once, as part of a bootstrapping process, so it skips configure and runs a (provided) shell script for the build phase. But then it doesn't get the configure environment -- currently the port build.env to have CC=${configure.cc}, but it's still missing out on CFLAGS and the rest, which is definitely a bug. I wanted to deal with this basically by setting build.env = configure.env, but there's no obvious way to do that... Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ From brooks at clarksonline.net Thu Jan 28 19:07:11 2010 From: brooks at clarksonline.net (M. Brooks Clark) Date: Thu, 28 Jan 2010 21:07:11 -0600 Subject: Updated portfile for wview 5.12.5 -- Please commit Message-ID: <9CF1EA98-6E23-497A-8700-F89E730C67A4@clarksonline.net> Can someone please commit the updated portfile for wview? Thanks. https://trac.macports.org/ticket/23463 From macsforever2000 at macports.org Thu Jan 28 19:49:11 2010 From: macsforever2000 at macports.org (Frank Schima) Date: Thu, 28 Jan 2010 20:49:11 -0700 Subject: Updated portfile for wview 5.12.5 -- Please commit In-Reply-To: <9CF1EA98-6E23-497A-8700-F89E730C67A4@clarksonline.net> References: <9CF1EA98-6E23-497A-8700-F89E730C67A4@clarksonline.net> Message-ID: On Jan 28, 2010, at 8:07 PM, M. Brooks Clark wrote: > Can someone please commit the updated portfile for wview? Thanks. > > https://trac.macports.org/ticket/23463 Done! Cheers! Frank From ryandesign at macports.org Thu Jan 28 22:50:25 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 29 Jan 2010 00:50:25 -0600 Subject: Can't access configure.env in portfile In-Reply-To: <20100128222600.GB44140@ambulatoryclam.net> References: <947340C9-EDDB-4279-9CCE-8FF09D761EE1@macports.org> <4B22BA95.1010102@macports.org> <20100128222600.GB44140@ambulatoryclam.net> Message-ID: On Jan 28, 2010, at 16:26, Dan Ports wrote: > On Fri, Dec 11, 2009 at 04:12:30PM -0600, Ryan Schmidt wrote: >> > >> On Dec 11, 2009, at 15:33, Rainer M?ller wrote: >> >>> On 2009-11-29 15:33 , Ryan Schmidt wrote: >>> >>>> See, both before and after the configure phase, configure.env only >>>> contains the "FOO=bar" variable I added. But what I actually want to >>>> know about are the CFLAGS, CPPFLAGS, CXXFLAGS, etc. that MacPorts >>>> sets automatically. Yes, I know we have separate variables >>>> ${configure.cflags}, ${configure.cppflags}, ${configure.cxxflags}, >>>> etc. for most (all?) of those, but I'd rather not have to enumerate >>>> over them myself since to my mind MacPorts should have already done >>>> so for me somewhere. >>> >>> If you want to get better results for debugging use: >>> configure.cmd /usr/bin/env >> >> My reasons for asking were not for debugging but for a reworking of the php5extension portgroup. I've found out what I was doing wrong though and will be able to commit my update soon. > > What solution did you wind up with? I'm wondering if it might be useful > for a problem I'm having with the mit-scheme port where I also wanted > to get ahold of configure.env: You can see what I ended up doing by reading the php5extension portgroup. I had been trying to use a technique I had first employed in the php5 port, in which, in order to build both an apache module and the fastcgi binary, it was necessary to run configure and make a second time. There, I have the port run "command_exec configure" and "command_exec build" directly in the destroot phase, after the port has already configured and built once. This is not recommended in ports because this is not part of the portfile vocabulary -- it's an internal MacPorts command that may change in the future (and indeed did already change once since I started making use of it in php5, breaking the port for awhile). I decided to use it anyway because I work on MacPorts daily and would be able to react quickly to fix the port if a change in base broke it. For the php5extension portgroup, I noticed that running "command_exec" didn't set the environment variables. Trying to set them manually, I noticed that configure.env doesn't actually contain the default configure environment variables, which surprised me a little but that's just how it works. After looking through the muniversal portgroup and examining the base code for awhile, I instead went with portconfigure::configure_main, portconfigure::build_main and portconfigure::destroot_main, which do set the env variables first. These also probably shouldn't be used by a port for the same reasons as above. But portgroups used to be part of base, and other portgroups like muniversal already use these, so I felt ok about using them in this portgroup. I don't think this will necessarily translate into something you should do for mit-scheme, but read on: > The port needs to run configure/make more than once, as part of a > bootstrapping process, so it skips configure and runs a (provided) > shell script for the build phase. But then it doesn't get the > configure environment -- currently the port build.env to have > CC=${configure.cc}, but it's still missing out on CFLAGS and the rest, > which is definitely a bug. > > I wanted to deal with this basically by setting build.env = > configure.env, but there's no obvious way to do that... Yes, it may be simplest to just manually pass in all the relevant variables to build.env. Or, you could write your own configure script that does nothing but grab the environment and make it available to the build script. Attached is a diff that does this, but I haven't tested whether that helps the build in any way. (I wasn't sure what problem you were encountering by not having the environment variables set.) -------------- next part -------------- A non-text attachment was scrubbed... Name: mit-scheme-env.diff Type: application/octet-stream Size: 1531 bytes Desc: not available URL: From ryandesign at macports.org Thu Jan 28 22:54:54 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 29 Jan 2010 00:54:54 -0600 Subject: [63189] trunk/dports/_resources/port1.0/group In-Reply-To: <20100128224125.174493DC3399@beta.macosforge.org> References: <20100128224125.174493DC3399@beta.macosforge.org> Message-ID: On Jan 28, 2010, at 16:41, snc at macports.org wrote: > Revision: 63189 > http://trac.macports.org/changeset/63189 > Author: snc at macports.org > Date: 2010-01-28 14:41:21 -0800 (Thu, 28 Jan 2010) > Log Message: > ----------- > change portgroups from ui_msg to notes I fear these changes are largely incorrect. ui_msg is a command, while notes is a variable (much like description and long_description). So you can't simply replace occurrences of ui_msg with notes and have things work properly. The idea is that notes is used for additional information the port may want to inform the user about after installation, and that the user can later type "port notes portname" to see them again if he's forgotten. Since I don't believe most of your changes meet that goal, I think you should probably revert most or all of this revision. From brad at pixilla.com Thu Jan 28 23:12:32 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 28 Jan 2010 23:12:32 -0800 Subject: port configure dovecot Message-ID: <1B1FAEB4-4D0E-49B5-BE61-EBD9DAAF987E@pixilla.com> Why would the current dovecot Portfile want to build mysql5 when I do "port configure dovecot +mysql5"? brad at trex ~ $ port installed mysql5 The following ports are currently installed: mysql5 @5.1.41_0 (active) brad at trex ~ $ file /opt/local/bin/mysql_config5 /opt/local/bin/mysql_config5: symbolic link to `/opt/local/lib/mysql5/ bin/mysql_config' brad at trex ~ $ file /opt/local/lib/mysql5/mysql/libmysqlclient.dylib /opt/local/lib/mysql5/mysql/libmysqlclient.dylib: symbolic link to `libmysqlclient.16.dylib' From dovecot:Portfile variant mysql5 description {Enable MySQL support} { depends_lib-append path:bin/mysql_config5:mysql5 archcheck.files-append lib/mysql5/mysql/libmysqlclient.dylib configure.args-append --with-mysql configure.ldflags-append -L${prefix}/lib/mysql5/mysql configure.cppflags-append -I${prefix}/include/mysql5/mysql } // Brad From ryandesign at macports.org Thu Jan 28 23:20:36 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 29 Jan 2010 01:20:36 -0600 Subject: Can't access configure.env in portfile In-Reply-To: <4B22C97C.8030108@macports.org> References: <947340C9-EDDB-4279-9CCE-8FF09D761EE1@macports.org> <4B22BA95.1010102@macports.org> <4B22C97C.8030108@macports.org> Message-ID: On Dec 11, 2009, at 16:36, Joshua Root wrote: >> Yes, but if you set (rather than append to) configure.env in a portfile, you overwrite the default environment. > > Can't say I've ever encountered this. Steps to reproduce? Just to provide closure on this question, I was wrong about my statement above. There was a disconnect between my mental model of how configure.env works and how it actually works. I had assumed it behaved like our other variables -- like configure.universal_args, build.target, destroot.destdir, distfiles, and so forth -- which come pre-populated with some default value, which can be overwritten by the portfile if necessary, or appended to or deleted from. Similarly, portgroups often set up dependencies, as does MacPorts base itself if you use directives like use_autoconf, which ports can append to or delete from. Portfile authors must be careful, however, not to overwrite dependencies or other settings made by a portgroup. Presumably this danger is a reason why we have variables like configure.pre_args; if we didn't, and instead we had set the default --prefix argument in configure.args, portfile authors would overwrite configure.args instead of appending to it and the default prefix argument would be lost. So I needed to adjust my conceptions to realize that configure.env serves a similar function to configure.args: where configure.args is for portfile-specific configure arguments, which don't overwrite the standard configure arguments in configure.pre_args, so, too, configure.env is for portfile-specific environment variables, which don't overwrite the standard environment variables -- which, unlike the standard configure arguments, unfortunately aren't represented by any portfile-accessible variable. I note, though, that the consequence of a portfile inadvertently overwriting the standard --prefix argument would be immediately noticeable by the software appearing in /usr/local instead of prefix. In contrast, the consequence of a portfile inadvertently overwriting dependencies or other settings made by a portgroup are much more likely to go unnoticed; I'm sure we have lots of ports in our tree right now that use a portgroup and overwrite a vital setting without realizing it. It's probably a good thing that MacPorts handles the default environment variables outside of configure.env, since overwriting them could have similarly hard-to-notice consequences. But I do sometimes wish for the ability to access them from a portfile, for example through something like a configure.pre_env variable. (A similar solution could be considered for base- and portgroup-declared dependencies: pre_depends_lib, anyone?) From ryandesign at macports.org Thu Jan 28 23:21:34 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 29 Jan 2010 01:21:34 -0600 Subject: port configure dovecot In-Reply-To: <1B1FAEB4-4D0E-49B5-BE61-EBD9DAAF987E@pixilla.com> References: <1B1FAEB4-4D0E-49B5-BE61-EBD9DAAF987E@pixilla.com> Message-ID: <4F3521B2-0950-4B8C-B19F-0EDDD355AF17@macports.org> On Jan 29, 2010, at 01:12, Bradley Giesbrecht wrote: > Why would the current dovecot Portfile want to build mysql5 when I do "port configure dovecot +mysql5"? > > brad at trex ~ $ port installed mysql5 > The following ports are currently installed: > mysql5 @5.1.41_0 (active) It's probably upgrading you to mysql5 @5.1.42_0. From reid at orthogonalspace.ca Thu Jan 28 23:23:22 2010 From: reid at orthogonalspace.ca (Reid Nichol) Date: Fri, 29 Jan 2010 07:23:22 -0000 (Canada/Mountain) Subject: port configure dovecot In-Reply-To: <1B1FAEB4-4D0E-49B5-BE61-EBD9DAAF987E@pixilla.com> References: <1B1FAEB4-4D0E-49B5-BE61-EBD9DAAF987E@pixilla.com> Message-ID: <63378.68.147.209.140.1264749802.squirrel@mail.orthogonalspace.ca> > Why would the current dovecot Portfile want to build mysql5 when I do > "port configure dovecot +mysql5"? I think it does that when a port is out of date. Does mysql5 show up in that (i.e. port outdated) output? -Reid From brad at pixilla.com Thu Jan 28 23:23:20 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 28 Jan 2010 23:23:20 -0800 Subject: port configure dovecot In-Reply-To: <4F3521B2-0950-4B8C-B19F-0EDDD355AF17@macports.org> References: <1B1FAEB4-4D0E-49B5-BE61-EBD9DAAF987E@pixilla.com> <4F3521B2-0950-4B8C-B19F-0EDDD355AF17@macports.org> Message-ID: <23DB3F9D-2E64-4835-88EC-23662B27D053@pixilla.com> On Jan 28, 2010, at 11:21 PM, Ryan Schmidt wrote: > > On Jan 29, 2010, at 01:12, Bradley Giesbrecht wrote: > >> Why would the current dovecot Portfile want to build mysql5 when I >> do "port configure dovecot +mysql5"? >> >> brad at trex ~ $ port installed mysql5 >> The following ports are currently installed: >> mysql5 @5.1.41_0 (active) > > It's probably upgrading you to mysql5 @5.1.42_0. Why is it doing that? I didn't do port upgrade outdated. Is this the default behavior of macports? I forget. But now that I think of it I remember getting bit by the openssl 1.0 upgrade and I think that may have been an automatic build as well. // Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Thu Jan 28 23:30:08 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 29 Jan 2010 01:30:08 -0600 Subject: port configure dovecot In-Reply-To: <23DB3F9D-2E64-4835-88EC-23662B27D053@pixilla.com> References: <1B1FAEB4-4D0E-49B5-BE61-EBD9DAAF987E@pixilla.com> <4F3521B2-0950-4B8C-B19F-0EDDD355AF17@macports.org> <23DB3F9D-2E64-4835-88EC-23662B27D053@pixilla.com> Message-ID: On Jan 29, 2010, at 01:23, Bradley Giesbrecht wrote: > On Jan 28, 2010, at 11:21 PM, Ryan Schmidt wrote: > >> On Jan 29, 2010, at 01:12, Bradley Giesbrecht wrote: >> >>> Why would the current dovecot Portfile want to build mysql5 when I do "port configure dovecot +mysql5"? >>> >>> brad at trex ~ $ port installed mysql5 >>> The following ports are currently installed: >>> mysql5 @5.1.41_0 (active) >> >> It's probably upgrading you to mysql5 @5.1.42_0. > > Why is it doing that? I didn't do port upgrade outdated. > > Is this the default behavior of macports? I forget. But now that I think of it I remember getting bit by the openssl 1.0 upgrade and I think that may have been an automatic build as well. MacPorts now upgrades your dependencies during install. I believe this changed in MacPorts 1.7 or 1.8 but I can't find it in the ChangeLog. You can prevent this using the -n switch. From ryandesign at macports.org Thu Jan 28 23:39:31 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 29 Jan 2010 01:39:31 -0600 Subject: XCode Project Portfile Question In-Reply-To: <4B61F540.9060504@GmAiL.cOm> References: <4B61F540.9060504@GmAiL.cOm> Message-ID: On Jan 28, 2010, at 14:36, Altoine Barker wrote: > I'm trying to build a Portfile based off of an xcode project but I > need to ask a few questions. So presumably you'd use the xcode portgroup. > 1. How do you build -alltargets like this command example: > xcodebuild -project myProject -alltargets Reading through the xcode portgroup, it looks like that's accomplished by clearing build.target. > 2. How do you include cmake commands in a portfile like the following > example: > cmake > -DPYTHON_INC=/opt/local/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1 > -G Xcode ../myProject Well, we also have a cmake portgroup, which handles cmake's peculiarities for you. You set your additional -D options in configure.args. So, this project uses both xcode and cmake? It looks like cmake is firing off the xcode build? If so, then you'll want the cmake portgroup, not the xcode portgroup. > 3. How do you detect an arch and include it in a Portfile made for an > xcode project? I'm not sure what you mean exactly. The xcode portgroup should already know what architectures the user wants to build for (using their settings of build_arch and universal_archs from macports.conf and whether or not the user requested the +universal variant) and do the right thing. The cmake portgroup should do the same. Of course, if you have some parts of a project that need xcodebuild and others that need cmake, this is harder because you'll have to one of them manually. Perhaps you could consider splitting the project into two ports, one of which uses the xcode portgroup, the other of which uses the cmake portgroup. > 4. Will this be made further complex by pulling the source from an svn > source? That shouldn't cause any problems. We have many ports that fetch from svn, and this process is documented in teh guide. You can look at my pure-devel portfile if you want to see an example. From brad at pixilla.com Thu Jan 28 23:39:15 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 28 Jan 2010 23:39:15 -0800 Subject: port configure dovecot In-Reply-To: References: <1B1FAEB4-4D0E-49B5-BE61-EBD9DAAF987E@pixilla.com> <4F3521B2-0950-4B8C-B19F-0EDDD355AF17@macports.org> <23DB3F9D-2E64-4835-88EC-23662B27D053@pixilla.com> Message-ID: <85BC108D-FE45-4A3E-9531-4BEAA85F4143@pixilla.com> On Jan 28, 2010, at 11:30 PM, Ryan Schmidt wrote: > On Jan 29, 2010, at 01:23, Bradley Giesbrecht wrote: > >> On Jan 28, 2010, at 11:21 PM, Ryan Schmidt wrote: >> >>> On Jan 29, 2010, at 01:12, Bradley Giesbrecht wrote: >>> >>>> Why would the current dovecot Portfile want to build mysql5 when >>>> I do "port configure dovecot +mysql5"? >>>> >>>> brad at trex ~ $ port installed mysql5 >>>> The following ports are currently installed: >>>> mysql5 @5.1.41_0 (active) >>> >>> It's probably upgrading you to mysql5 @5.1.42_0. >> >> Why is it doing that? I didn't do port upgrade outdated. >> >> Is this the default behavior of macports? I forget. But now that I >> think of it I remember getting bit by the openssl 1.0 upgrade and I >> think that may have been an automatic build as well. > > MacPorts now upgrades your dependencies during install. I believe > this changed in MacPorts 1.7 or 1.8 but I can't find it in the > ChangeLog. You can prevent this using the -n switch. What exactly does port -n do? I don't see it explained in man port. // Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at pixilla.com Thu Jan 28 23:42:52 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 28 Jan 2010 23:42:52 -0800 Subject: port configure dovecot In-Reply-To: <85BC108D-FE45-4A3E-9531-4BEAA85F4143@pixilla.com> References: <1B1FAEB4-4D0E-49B5-BE61-EBD9DAAF987E@pixilla.com> <4F3521B2-0950-4B8C-B19F-0EDDD355AF17@macports.org> <23DB3F9D-2E64-4835-88EC-23662B27D053@pixilla.com> <85BC108D-FE45-4A3E-9531-4BEAA85F4143@pixilla.com> Message-ID: <38014B4B-E3C5-4C7A-960E-708939F939B9@pixilla.com> On Jan 28, 2010, at 11:39 PM, Bradley Giesbrecht wrote: > > On Jan 28, 2010, at 11:30 PM, Ryan Schmidt wrote: > >> On Jan 29, 2010, at 01:23, Bradley Giesbrecht wrote: >> >>> On Jan 28, 2010, at 11:21 PM, Ryan Schmidt wrote: >>> >>>> On Jan 29, 2010, at 01:12, Bradley Giesbrecht wrote: >>>> >>>>> Why would the current dovecot Portfile want to build mysql5 when >>>>> I do "port configure dovecot +mysql5"? >>>>> >>>>> brad at trex ~ $ port installed mysql5 >>>>> The following ports are currently installed: >>>>> mysql5 @5.1.41_0 (active) >>>> >>>> It's probably upgrading you to mysql5 @5.1.42_0. >>> >>> Why is it doing that? I didn't do port upgrade outdated. >>> >>> Is this the default behavior of macports? I forget. But now that I >>> think of it I remember getting bit by the openssl 1.0 upgrade and >>> I think that may have been an automatic build as well. >> >> MacPorts now upgrades your dependencies during install. I believe >> this changed in MacPorts 1.7 or 1.8 but I can't find it in the >> ChangeLog. You can prevent this using the -n switch. > > What exactly does port -n do? > > I don't see it explained in man port. Never mind, I'm blind. I even did man port and /-n to search for it and didn't see. // Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmr at macports.org Fri Jan 29 00:08:28 2010 From: jmr at macports.org (Joshua Root) Date: Fri, 29 Jan 2010 19:08:28 +1100 Subject: [63189] trunk/dports/_resources/port1.0/group In-Reply-To: References: <20100128224125.174493DC3399@beta.macosforge.org> Message-ID: <4B62977C.40301@macports.org> On 2010-1-29 17:54 , Ryan Schmidt wrote: > > On Jan 28, 2010, at 16:41, snc at macports.org wrote: > >> Revision: 63189 >> http://trac.macports.org/changeset/63189 >> Author: snc at macports.org >> Date: 2010-01-28 14:41:21 -0800 (Thu, 28 Jan 2010) >> Log Message: >> ----------- >> change portgroups from ui_msg to notes > > I fear these changes are largely incorrect. ui_msg is a command, while notes is a variable (much like description and long_description). So you can't simply replace occurrences of ui_msg with notes and have things work properly. The idea is that notes is used for additional information the port may want to inform the user about after installation, and that the user can later type "port notes portname" to see them again if he's forgotten. Since I don't believe most of your changes meet that goal, I think you should probably revert most or all of this revision. Reverted. Clear breakage in the ports tree needs to be reverted on the spot, it's pushed live to users after all. In portgroups doubly so, since they are used by multiple ports. Better still, test sufficiently and don't commit broken code in the first place. - Josh From brad at pixilla.com Fri Jan 29 00:08:26 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 29 Jan 2010 00:08:26 -0800 Subject: [MacPorts] #22993: new port for dovecot-sieve In-Reply-To: References: <052.5fe92354dbf97059986f620cb0ca2cee@macports.org> <061.3867e8b3c4cbd7bd7f0b0392bcd8c7ba@macports.org> <1A8EE870-5428-4610-912A-EAF051D35953@pixilla.com> Message-ID: <1E10510B-B7EC-4DF2-84A3-F1FA2665F27F@pixilla.com> I just uploaded a new diff. This is a diff from the current macports Portfile and only required a version number and checksum change. I'm running on my production server now and mail seems to be flowing normally. I was already at 1.2.9 so this was a minor upgrade. Others may have to change some configs to go from 1.1.6 to 1.2.x. I had to make some changes to my system when I made the upgrade a while back. // Brad On Jan 27, 2010, at 11:52 PM, Ryan Schmidt wrote: > > On Jan 27, 2010, at 22:41, Bradley Giesbrecht wrote: > >> On Jan 27, 2010, at 8:06 PM, MacPorts wrote: >> >>> #22993: new port for dovecot-sieve >>> ------------------------------ >>> +--------------------------------------------- >>> Reporter: brad@? | Owner: macports-tickets@? >>> Type: submission | Status: new >>> Priority: Normal | Milestone: >>> Component: ports | Version: >>> Keywords: | Port: dovecot dovecot-sieve >>> ------------------------------ >>> +--------------------------------------------- >>> Changes (by ryandesign@?): >>> >>> * cc: ryandesign@? (added) >>> >>> >>> Comment: >>> >>> The attached patch to update dovecot contains tons of >>> irrelevancies. Could >>> you or someone try again, submitting a diff that makes only the >>> relevant >>> changes to update to the latest version? Note that I've made many >>> changes >>> to dovecot today, and that 1.2.10 is now the latest version >>> available. >> >> >> Since Ryan already updated dovecot to 1.2.10 there is no need, right? > > I have not updated dovecot to 1.2.10 yet. > > >> As for the dovecot-sieve portfile I don't know how to do it any >> better. > > I haven't even begun to look at your dovecot-sieve portfile yet; I > was just interested in getting dovecot updated to 1.2.10. I was > referring to irrelevancies in the patch that was supplied in this > ticket to perform that update: > > http://trac.macports.org/attachment/ticket/22993/patch-Portfile > > For example, it changes the Id line, it changes the branch variable > name to major_version, it introduces a typo in the long_description, > it adds an unnecessary distname directive, it changes pkgconfig from > a build to a library dependency, it adds Darwin 7 blocks when > MacPorts now requires Darwin 8 or newer, it changes the formatting > of the rawlog and ldap variants.... Why were all these changes made > and what do they have with updating the port to 1.2.10? > > From jmr at macports.org Fri Jan 29 06:07:38 2010 From: jmr at macports.org (Joshua Root) Date: Sat, 30 Jan 2010 01:07:38 +1100 Subject: [MacPorts] Migration modified In-Reply-To: <20100129122402.E89D28291AF0@mail-out3.apple.com> References: <20100129122402.E89D28291AF0@mail-out3.apple.com> Message-ID: <4B62EBAA.1030901@macports.org> On 2010-1-29 23:24 , MacPorts wrote: > Changed page "Migration" by stig at stigbakken.com from 193.91.206.170* > Page URL: > Diff URL: > Revision 19 > > -------8<------8<------8<------8<------8<------8<------8<------8<-------- > Index: Migration > ========================================================================= > --- Migration (version: 18) > +++ Migration (version: 19) > @@ -27,3 +27,22 @@ > sudo port install portname +variant1 +variant2 ... > }}} > Note that if you have specified variants which are not the default, you may need to install ports in an order other than the alphabetical order recorded in `myports.txt`. > + > +=== Automatically reinstall ports === #autoinstall > + > +If you want to do the whole procedure automatically instead, including handling dependencies, you can run the following commands to build a Makefile for running the reinstalls in the right order. (Not needed If you already ran the steps in the previous section.) > +{{{ > +port installed |grep -v '^The following' | awk '{print $1}' > myports.txt > +}}} > +{{{ > +echo "all: $(cat myports.txt|tr '\n' ' ')" > Makefile.portsupgrade > +}}} > +{{{ > +for port in $(cat myports.txt); do > + echo "$port: $(port deps $port|grep Dependencies:|sed -e 's/.*Dependencies: *//;s/,//g'|tr '\n' ' ')" > + printf "\tport -f uninstall $port\n\tport install $port\n" > +done | tee -a Makefile.portsupgrade > +}}} > +{{{ > +make -f Makefile.portsupgrade > +}}} Doesn't this have the same problems as the previously featured automatic method, `sudo port upgrade --force installed`? BTW, I wrote a (not yet very well tested) script that restores a set of installed ports given `port installed` output: - Josh From ryandesign at macports.org Fri Jan 29 06:19:08 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 29 Jan 2010 08:19:08 -0600 Subject: [MacPorts] Migration modified In-Reply-To: <4B62EBAA.1030901@macports.org> References: <20100129122402.E89D28291AF0@mail-out3.apple.com> <4B62EBAA.1030901@macports.org> Message-ID: <7E9F3895-4B4C-44CC-8467-81AC9E98B676@macports.org> On Jan 29, 2010, at 08:07, Joshua Root wrote: > On 2010-1-29 23:24 , MacPorts wrote: >> Changed page "Migration" by stig at stigbakken.com from 193.91.206.170* >> Page URL: >> Diff URL: >> Revision 19 >> >> -------8<------8<------8<------8<------8<------8<------8<------8<-------- >> Index: Migration >> ========================================================================= >> --- Migration (version: 18) >> +++ Migration (version: 19) >> @@ -27,3 +27,22 @@ >> sudo port install portname +variant1 +variant2 ... >> }}} >> Note that if you have specified variants which are not the default, you may need to install ports in an order other than the alphabetical order recorded in `myports.txt`. >> + >> +=== Automatically reinstall ports === #autoinstall >> + >> +If you want to do the whole procedure automatically instead, including handling dependencies, you can run the following commands to build a Makefile for running the reinstalls in the right order. (Not needed If you already ran the steps in the previous section.) >> +{{{ >> +port installed |grep -v '^The following' | awk '{print $1}' > myports.txt >> +}}} >> +{{{ >> +echo "all: $(cat myports.txt|tr '\n' ' ')" > Makefile.portsupgrade >> +}}} >> +{{{ >> +for port in $(cat myports.txt); do >> + echo "$port: $(port deps $port|grep Dependencies:|sed -e 's/.*Dependencies: *//;s/,//g'|tr '\n' ' ')" >> + printf "\tport -f uninstall $port\n\tport install $port\n" >> +done | tee -a Makefile.portsupgrade >> +}}} >> +{{{ >> +make -f Makefile.portsupgrade >> +}}} > > Doesn't this have the same problems as the previously featured automatic > method, `sudo port upgrade --force installed`? I believe it does, and the same problems as the previous automatic upgrade script posted last week, about which I posted comments here: http://lists.macosforge.org/pipermail/macports-dev/2010-January/011131.html > BTW, I wrote a (not yet very well tested) script that restores a set of > installed ports given `port installed` output: > I saw you commit that, and I'm interested to see how it works out. From jmr at macports.org Fri Jan 29 06:48:11 2010 From: jmr at macports.org (Joshua Root) Date: Sat, 30 Jan 2010 01:48:11 +1100 Subject: [MacPorts] Migration modified In-Reply-To: <7E9F3895-4B4C-44CC-8467-81AC9E98B676@macports.org> References: <20100129122402.E89D28291AF0@mail-out3.apple.com> <4B62EBAA.1030901@macports.org> <7E9F3895-4B4C-44CC-8467-81AC9E98B676@macports.org> Message-ID: <4B62F52B.6070506@macports.org> On 2010-1-30 01:19 , Ryan Schmidt wrote: > > On Jan 29, 2010, at 08:07, Joshua Root wrote: > >> Doesn't this have the same problems as the previously featured automatic >> method, `sudo port upgrade --force installed`? > > I believe it does, and the same problems as the previous automatic upgrade script posted last week, about which I posted comments here: > > http://lists.macosforge.org/pipermail/macports-dev/2010-January/011131.html Ah, indeed, at first glance I thought this new method made some attempt to preserve variants, but I see now it doesn't. I've changed Migration to mention restore_ports, but clearly marked that it is experimental. - Josh From dports at ambulatoryclam.net Fri Jan 29 12:47:33 2010 From: dports at ambulatoryclam.net (Dan Ports) Date: Fri, 29 Jan 2010 12:47:33 -0800 Subject: Can't access configure.env in portfile In-Reply-To: References: <947340C9-EDDB-4279-9CCE-8FF09D761EE1@macports.org> <4B22BA95.1010102@macports.org> <20100128222600.GB44140@ambulatoryclam.net> Message-ID: <20100129204733.GD44140@ambulatoryclam.net> On Fri, Jan 29, 2010 at 12:50:25AM -0600, Ryan Schmidt wrote: > > I wanted to deal with this basically by setting build.env = > > configure.env, but there's no obvious way to do that... > > Yes, it may be simplest to just manually pass in all the relevant variables to build.env. Or, you could write your own configure script that does nothing but grab the environment and make it available to the build script. Attached is a diff that does this, but I haven't tested whether that helps the build in any way. (I wasn't sure what problem you were encountering by not having the environment variables set.) Specifically, the problem I ran into is that it doesn't get CFLAGS from the environment, so it doesn't use whatever -arch settings MacPorts provides. I'll give the patch you provided a try -- thanks! I do wonder if having a more convenient way to use the configure environment during the build phase would be a useful thing to have for other ports. It seems like it might, say for non-autoconf makefiles that still use CC, or ports with build scripts that explicitly run configure (like mit-scheme). But if it hasn't come up before, then maybe not... Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ From brad at pixilla.com Fri Jan 29 14:55:04 2010 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 29 Jan 2010 14:55:04 -0800 Subject: dovecot bump 22993 Message-ID: Someone with commit please take a look at Portfile-dovecot.diff attached to: http://trac.macports.org/attachment/ticket/22993/Portfile-dovecot.diff Also please look at the new port dovecot-sieve. http://trac.macports.org/attachment/ticket/22993/Portfile Thanks, Bradley Giesbrecht From ryandesign at macports.org Fri Jan 29 15:50:00 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 29 Jan 2010 17:50:00 -0600 Subject: Can't access configure.env in portfile In-Reply-To: <20100129204733.GD44140@ambulatoryclam.net> References: <947340C9-EDDB-4279-9CCE-8FF09D761EE1@macports.org> <4B22BA95.1010102@macports.org> <20100128222600.GB44140@ambulatoryclam.net> <20100129204733.GD44140@ambulatoryclam.net> Message-ID: <23371AF6-8AA2-4862-98D8-E01BCAC0051C@macports.org> On Jan 29, 2010, at 14:47, Dan Ports wrote: > I do wonder if having a more convenient way to use the configure > environment during the build phase would be a useful thing to have for > other ports. It seems like it might, say for non-autoconf makefiles > that still use CC, or ports with build scripts that explicitly run > configure (like mit-scheme). But if it hasn't come up before, then > maybe not... I have often wondered why we can't just pass all the configure environment to the build phase as well. :/ From ryandesign at macports.org Fri Jan 29 22:14:02 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 30 Jan 2010 00:14:02 -0600 Subject: [63213] trunk/dports/editors/vim/Portfile In-Reply-To: <20100129175638.F34163DCF295@beta.macosforge.org> References: <20100129175638.F34163DCF295@beta.macosforge.org> Message-ID: <5512EB46-021E-41E2-A0C9-2E07A221301B@macports.org> On Jan 29, 2010, at 11:56, raimue at macports.org wrote: > Revision: 63213 > http://trac.macports.org/changeset/63213 > Author: raimue at macports.org > Date: 2010-01-29 09:56:38 -0800 (Fri, 29 Jan 2010) > Log Message: > ----------- > editors/vim, editors/vim-app: > Applying #22433, new variant +x, "Build CLI version with X support" Don't we typically call such a variant "x11" not "x"? From ryandesign at macports.org Sat Jan 30 09:11:05 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 30 Jan 2010 11:11:05 -0600 Subject: [63246] trunk/dports/editors In-Reply-To: <20100130160609.B943F3DE2E8C@beta.macosforge.org> References: <20100130160609.B943F3DE2E8C@beta.macosforge.org> Message-ID: On Jan 30, 2010, at 10:06, and.damore at macports.org wrote: > Revision: 63246 > http://trac.macports.org/changeset/63246 > Author: and.damore at macports.org > Date: 2010-01-30 08:06:09 -0800 (Sat, 30 Jan 2010) > Log Message: > ----------- > Added wordgrinder, a Lua based console text editor > + CBUILDFLAGS = { > + '-Wall', > +- '--std=c99' > ++ '--std=c99', > ++ '-L/opt/local/lib' > + } You've got /opt/local/lib hardcoded in your patchfile. From raimue at macports.org Sat Jan 30 11:23:53 2010 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 30 Jan 2010 20:23:53 +0100 Subject: [63213] trunk/dports/editors/vim/Portfile In-Reply-To: <5512EB46-021E-41E2-A0C9-2E07A221301B@macports.org> References: <20100129175638.F34163DCF295@beta.macosforge.org> <5512EB46-021E-41E2-A0C9-2E07A221301B@macports.org> Message-ID: <4B648749.5010809@macports.org> On 2010-01-30 07:14 , Ryan Schmidt wrote: > On Jan 29, 2010, at 11:56, raimue at macports.org wrote: > >> Revision: 63213 >> http://trac.macports.org/changeset/63213 >> Author: raimue at macports.org >> Date: 2010-01-29 09:56:38 -0800 (Fri, 29 Jan 2010) >> Log Message: >> ----------- >> editors/vim, editors/vim-app: >> Applying #22433, new variant +x, "Build CLI version with X support" > > Don't we typically call such a variant "x11" not "x"? Actually there is only the port "aee" with a +x11 variant. But +no_x11 is a common variant name. For consistency, I renamed the variant for vim to +x11. Rainer From raimue at macports.org Sat Jan 30 16:59:50 2010 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 31 Jan 2010 01:59:50 +0100 Subject: [63213] trunk/dports/editors/vim/Portfile In-Reply-To: <4B648749.5010809@macports.org> References: <20100129175638.F34163DCF295@beta.macosforge.org> <5512EB46-021E-41E2-A0C9-2E07A221301B@macports.org> <4B648749.5010809@macports.org> Message-ID: <4B64D606.801@macports.org> On 2010-01-30 20:23 , Rainer M?ller wrote: > On 2010-01-30 07:14 , Ryan Schmidt wrote: >> On Jan 29, 2010, at 11:56, raimue at macports.org wrote: >> >>> Revision: 63213 >>> http://trac.macports.org/changeset/63213 >>> Author: raimue at macports.org >>> Date: 2010-01-29 09:56:38 -0800 (Fri, 29 Jan 2010) >>> Log Message: >>> ----------- >>> editors/vim, editors/vim-app: >>> Applying #22433, new variant +x, "Build CLI version with X support" >> >> Don't we typically call such a variant "x11" not "x"? > > Actually there is only the port "aee" with a +x11 variant. That's totally wrong. I relied on 'port echo variant:^x11$', but actually this is not what I was after as the pseudo-port regex is matched against the list of variants not each individually. There are plenty of ports using +x11. Rainer From ryandesign at macports.org Sun Jan 31 02:22:27 2010 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 31 Jan 2010 04:22:27 -0600 Subject: [63274] trunk/dports/aqua/pgAdmin3/Portfile In-Reply-To: <20100131100232.60A563DF2C75@beta.macosforge.org> References: <20100131100232.60A563DF2C75@beta.macosforge.org> Message-ID: <40982849-DB18-465D-A096-57EBDDB0B171@macports.org> On Jan 31, 2010, at 04:02, jwa at macports.org wrote: > Revision: 63274 > http://trac.macports.org/changeset/63274 > Author: jwa at macports.org > Date: 2010-01-31 02:02:28 -0800 (Sun, 31 Jan 2010) > Log Message: > ----------- > version bump to 1.10.1, making it 32-bit on 10.6 > +platform darwin 10 { > + configure.build_arch i386 > + configure.cppflags "-arch i386" > + configure.ldflags "-arch i386" > +} Shouldn't you rather make it i386 when build_arch is x86_64, and ppc when build_arch is ppc64? It doesn't necessarily have anything to do with the OS version. I'm also surprised you need to manually set cppflags and ldflags; in my experience, MacPorts takes care of that for you. Also, you need to consider any implications for the universal variant. From and.damore at macports.org Sun Jan 31 04:51:32 2010 From: and.damore at macports.org (Andrea D'Amore) Date: Sun, 31 Jan 2010 13:51:32 +0100 Subject: Snow Leopard and build env Message-ID: Hello, I looked at a couple debug output from wordgrinder on Snow Leo from different peopland I noticed that build phase had only DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.6' while I had instead DEBUG: Environment: CPATH='/opt/local/include' LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.5' Why does the environment change from Leopard to Snow Leopard using the same Portfile? port was 1.8.2 on both the SL systems and updated trunk on my computer. -- Andrea From jmr at macports.org Sun Jan 31 04:58:59 2010 From: jmr at macports.org (Joshua Root) Date: Sun, 31 Jan 2010 23:58:59 +1100 Subject: Snow Leopard and build env In-Reply-To: References: Message-ID: <4B657E93.8060507@macports.org> On 2010-1-31 23:51 , Andrea D'Amore wrote: > Hello, > I looked at a couple debug output from wordgrinder on Snow Leo from > different peopland I noticed that build phase had only > DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.6' > while I had instead > DEBUG: Environment: CPATH='/opt/local/include' > LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.5' > > Why does the environment change from Leopard to Snow Leopard using the > same Portfile? > > port was 1.8.2 on both the SL systems and updated trunk on my computer. Only trunk sets CPATH and LIBRARY_PATH. - Josh From nox at macports.org Sun Jan 31 06:40:56 2010 From: nox at macports.org (nox) Date: Sun, 31 Jan 2010 15:40:56 +0100 Subject: Small output level change request Message-ID: Hi there, Could someone fluent enough with base/ code change the output level of the commands run by port(1)? I'd like them to be moved from debug to verbose output. I'm talking about these bits: :debug:configure Environment: CPATH='/opt/local/include' CFLAGS='-pipe -O2 -arch x86_64' CPPFLAGS='-I/opt/local/include' CXXFLAGS='-pipe -O2 -arch x86_64' LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.6' CXX='ccache /usr/bin/g++-4.2' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_nox_src_MacPorts_dports_graphics_libpng/work/.CC_PRINT_OPTIONS' F90FLAGS='-pipe -O2 -arch x86_64' LDFLAGS='-L/opt/local/lib -arch x86_64' OBJC='ccache /usr/bin/gcc-4.2' FCFLAGS='-pipe -O2 -arch x86_64' INSTALL='/usr/bin/install -c' OBJCFLAGS='-pipe -O2 -arch x86_64' FFLAGS='-pipe -O2 -arch x86_64' CC_PRINT_OPTIONS='YES' CC='ccache /usr/bin/gcc-4.2' :debug:configure Assembled command: 'cd "/opt/local/var/macports/build/_Users_nox_src_MacPorts_dports_graphics_libpng/work/libpng-1.4.0-x86_64" && ./configure --prefix=/opt/local --disable-dependency-tracking --disable-dependency-tracking ' I hate to have to enable debug output or open the log file to just see the environment and configure args. Regards, Anthony.