From ryandesign at macports.org Sun Mar 1 02:21:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 1 Mar 2009 04:21:42 -0600 Subject: Files disappearing from distfiles mirror Message-ID: What would cause a file to disappear from our distfiles mirrors? I thought they were supposed to be a more or less permanent archive of all distfiles over time. I know we have a policy of not mirroring some ports, but that's not this. According to Google, the Norwegian mirror had the file osx2x-2.4.tar.gz with a modification date of October 31, 2008: http://www.google.com/search?q=site%3Adistfiles.macports.org +osx2x-2.4.tar.gz In case Google has updated its listing, this is what the above URL shows as I write this email: Index of /osx2x Parent Directory, -. osx2x-2.4.tar.gz, 31-Oct-2008 08:03, 200K. Apache/2.2.9 (Debian) Server at trd.no.distfiles.macports.org Port 80. trd.no.distfiles.macports.org/osx2x/?C=D;O=A If I look at that URL today, there is nothing there. There was also nothing on distfiles.macports.org yesterday. The file is back on the California mirror now, and will be on the Norwegian mirror again soon, because I committed r47558: http://trac.macports.org/changeset/47558 But I would like to know how it came to be that the file was on all of our mirrors in October 2008 but then disappeared from two of them since then. From jmr at macports.org Sun Mar 1 02:27:28 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 01 Mar 2009 21:27:28 +1100 Subject: Files disappearing from distfiles mirror In-Reply-To: References: Message-ID: <49AA6310.6050704@macports.org> Ryan Schmidt wrote: > What would cause a file to disappear from our distfiles mirrors? I > thought they were supposed to be a more or less permanent archive of all > distfiles over time. I know we have a policy of not mirroring some > ports, but that's not this. > > According to Google, the Norwegian mirror had the file osx2x-2.4.tar.gz > with a modification date of October 31, 2008: > > http://www.google.com/search?q=site%3Adistfiles.macports.org+osx2x-2.4.tar.gz > > > In case Google has updated its listing, this is what the above URL shows > as I write this email: > > Index of /osx2x > Parent Directory, -. osx2x-2.4.tar.gz, 31-Oct-2008 08:03, 200K. > Apache/2.2.9 (Debian) Server at trd.no.distfiles.macports.org Port 80. > trd.no.distfiles.macports.org/osx2x/?C=D;O=A > > If I look at that URL today, there is nothing there. There was also > nothing on distfiles.macports.org yesterday. The file is back on the > California mirror now, and will be on the Norwegian mirror again soon, > because I committed r47558: > > http://trac.macports.org/changeset/47558 > > But I would like to know how it came to be that the file was on all of > our mirrors in October 2008 but then disappeared from two of them since > then. Portmirror deletes files when the checksums don't match. - Josh From rasmus at macports.org Sun Mar 1 17:20:16 2009 From: rasmus at macports.org (Rasmus Andersson) Date: Mon, 2 Mar 2009 02:20:16 +0100 Subject: Python 3.0 gone? Message-ID: Have Python 3.0 been removed from MacPorts? I can't find any information indicating that is the case, although no py30- ports no longer exist. Anyone care to shed some light on this? Thank you guys. -- Rasmus Andersson From blb at macports.org Sun Mar 1 17:31:22 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 1 Mar 2009 18:31:22 -0700 Subject: Python 3.0 gone? In-Reply-To: References: Message-ID: <20090302013122.GC917@ninagal.withay.com> On Mon, Mar 02, 2009 at 02:20:16AM +0100, Rasmus Andersson said: > Have Python 3.0 been removed from MacPorts? > I can't find any information indicating that is the case, although no > py30- ports no longer exist. > > Anyone care to shed some light on this? The base py30 modules which are now part of the python30 port (just like with python26) were removed in r46202 [1], and I don't think any other py30 ports have been added as yet. How many work with 3.0 at this point? Bryan [1] - > > Thank you guys. > > -- > Rasmus Andersson From rasmus at macports.org Sun Mar 1 18:20:45 2009 From: rasmus at macports.org (Rasmus Andersson) Date: Mon, 2 Mar 2009 03:20:45 +0100 Subject: Python 3.0 gone? In-Reply-To: <20090302013122.GC917@ninagal.withay.com> References: <20090302013122.GC917@ninagal.withay.com> Message-ID: On Mon, Mar 2, 2009 at 02:31, Bryan Blackburn wrote: > On Mon, Mar 02, 2009 at 02:20:16AM +0100, Rasmus Andersson said: >> Have Python 3.0 been removed from MacPorts? >> I can't find any information indicating that is the case, although no >> py30- ports no longer exist. >> >> Anyone care to shed some light on this? > > The base py30 modules which are now part of the python30 port (just like > with python26) were removed in r46202 [1], and I don't think any other py30 > ports have been added as yet. ?How many work with 3.0 at this point? > > Bryan > > [1] - > Thanks Bryan, I'm adding a py30-port right now and found a bug in the python30 group file: set python.prefix ${frameworks_dir}/Python.framework/Versions/${python.branch} which is later used: destroot.destdir --prefix=${python.prefix} --root=${destroot} does not point to the canonical path, but rather the symlink in PREFIX/Library/Frameworks/Python.framework... I'm taking the liberty of committing the changes (tested in my local repository with success) ... Earlier I sent from another address and as Google mail work, I missed the error replies. Here are my other messages: ... The main reason for solving this bug is that installing ports in that group fails with Error: Target org.macports.activate returned: Not a directory Error: Status 1 encountered during processing. (the error occurs post-activation thus you are left with a working port) ... Done in [47615] http://trac.macports.org/changeset/47615 From rasmus at macports.org Sun Mar 1 18:23:29 2009 From: rasmus at macports.org (Rasmus Andersson) Date: Mon, 2 Mar 2009 03:23:29 +0100 Subject: Python 3.0 gone? In-Reply-To: References: <20090302013122.GC917@ninagal.withay.com> Message-ID: On Mon, Mar 2, 2009 at 03:20, Rasmus Andersson wrote: > On Mon, Mar 2, 2009 at 02:31, Bryan Blackburn wrote: >> On Mon, Mar 02, 2009 at 02:20:16AM +0100, Rasmus Andersson said: >>> Have Python 3.0 been removed from MacPorts? >>> I can't find any information indicating that is the case, although no >>> py30- ports no longer exist. >>> >>> Anyone care to shed some light on this? >> >> The base py30 modules which are now part of the python30 port (just like >> with python26) were removed in r46202 [1], and I don't think any other py30 >> ports have been added as yet. ?How many work with 3.0 at this point? >> >> Bryan >> >> [1] - >> > > Thanks Bryan, > > I'm adding a py30-port right now and found a bug in the python30 group file: > set python.prefix > ${frameworks_dir}/Python.framework/Versions/${python.branch} > which is later used: > destroot.destdir ? ? ? ?--prefix=${python.prefix} --root=${destroot} > does not point to the canonical path, but rather the symlink in > PREFIX/Library/Frameworks/Python.framework... > > I'm taking the liberty of committing the changes (tested in my local > repository with success) > > ... > > Earlier I sent from another address and as Google mail work, I missed > the error replies. Here are my other messages: > > ... > > The main reason for solving this bug is that installing ports in that > group fails with > Error: Target org.macports.activate returned: Not a directory > Error: Status 1 encountered during processing. > (the error occurs post-activation thus you are left with a working port) > > ... > > Done in [47615] > > http://trac.macports.org/changeset/47615 > Just got an idea: Did someone change the python30 group to install itself into prefix/Library/Frameworks/Python.framework... ina an effort to make some sort of transition? If so, I'm sorry if I messed things up, but I could not find any information on this so I have to assume it was a "bug". -- Rasmus Andersson From blb at macports.org Sun Mar 1 19:42:20 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 1 Mar 2009 20:42:20 -0700 Subject: Python 3.0 gone? In-Reply-To: References: <20090302013122.GC917@ninagal.withay.com> Message-ID: <20090302034220.GH917@ninagal.withay.com> On Mon, Mar 02, 2009 at 03:23:29AM +0100, Rasmus Andersson said: > On Mon, Mar 2, 2009 at 03:20, Rasmus Andersson wrote: [...] > > The main reason for solving this bug is that installing ports in that > > group fails with > > Error: Target org.macports.activate returned: Not a directory > > Error: Status 1 encountered during processing. > > (the error occurs post-activation thus you are left with a working port) > > > > ... > > > > Done in [47615] > > > > http://trac.macports.org/changeset/47615 > > > > Just got an idea: > > Did someone change the python30 group to install itself into > prefix/Library/Frameworks/Python.framework... ina an effort to make > some sort of transition? If so, I'm sorry if I messed things up, but I > could not find any information on this so I have to assume it was a > "bug". The python26 and python30 ports are now full framework installs, so the ${prefix}/Library/Frameworks/Python.framework is the correct location for everything; you'll note they do not install anything into ${prefix}/lib anymore, so those 'Not a directory' issues should not occur with either of them. python25 could be updated to be the same (and in theory should be) but that would require everyone with any py25 ports to uninstall those, upgrade python25, then reinstall the py25 ports. Also, the --no-user-cfg is still present in python30 (that's what patch-Lib-distutils-dist.py.diff does), so it should also be kept in the python30 group code. Bryan > > -- > Rasmus Andersson From rasmus at macports.org Sun Mar 1 20:12:45 2009 From: rasmus at macports.org (Rasmus Andersson) Date: Mon, 2 Mar 2009 05:12:45 +0100 Subject: Python 3.0 gone? In-Reply-To: <20090302034220.GH917@ninagal.withay.com> References: <20090302013122.GC917@ninagal.withay.com> <20090302034220.GH917@ninagal.withay.com> Message-ID: On Mon, Mar 2, 2009 at 04:42, Bryan Blackburn wrote: > On Mon, Mar 02, 2009 at 03:23:29AM +0100, Rasmus Andersson said: >> On Mon, Mar 2, 2009 at 03:20, Rasmus Andersson wrote: > [...] >> > The main reason for solving this bug is that installing ports in that >> > group fails with >> > Error: Target org.macports.activate returned: Not a directory >> > Error: Status 1 encountered during processing. >> > (the error occurs post-activation thus you are left with a working port) >> > >> > ... >> > >> > Done in [47615] >> > >> > http://trac.macports.org/changeset/47615 >> > >> >> Just got an idea: >> >> Did someone change the python30 group to install itself into >> prefix/Library/Frameworks/Python.framework... ina an effort to make >> some sort of transition? If so, I'm sorry if I messed things up, but I >> could not find any information on this so I have to assume it was a >> "bug". > > The python26 and python30 ports are now full framework installs, so the > ${prefix}/Library/Frameworks/Python.framework is the correct location for > everything; you'll note they do not install anything into ${prefix}/lib > anymore, so those 'Not a directory' issues should not occur with either of > them. > > python25 could be updated to be the same (and in theory should be) but that > would require everyone with any py25 ports to uninstall those, upgrade > python25, then reinstall the py25 ports. > > Also, the --no-user-cfg is still present in python30 (that's what > patch-Lib-distutils-dist.py.diff does), so it should also be kept in the > python30 group code. It is not a valid argument in the Python 3.0 I have got from MacPorts. Was this patched recently? (my installation might be about a month old) Gonna test this out more tomorrow ? please, be my guest and fix if you want to. There is a python30 port you can test with: py30-tc (It's 5 am here and I'm gonna go to work in 3 hours. yikes!) > > Bryan > - Show quoted text - > >> >> -- >> Rasmus Andersson > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -- Rasmus Andersson From blb at macports.org Sun Mar 1 20:50:30 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 1 Mar 2009 21:50:30 -0700 Subject: Python 3.0 gone? In-Reply-To: References: <20090302013122.GC917@ninagal.withay.com> <20090302034220.GH917@ninagal.withay.com> Message-ID: <20090302045030.GI917@ninagal.withay.com> On Mon, Mar 02, 2009 at 05:12:45AM +0100, Rasmus Andersson said: [...] > > It is not a valid argument in the Python 3.0 I have got from MacPorts. > Was this patched recently? (my installation might be about a month > old) Yeah, your python30 install is old, vast improvements were made in r46197 [1] and the revision increased in r46199 [2]. Those improvements do include the better framework build and --no-user-cfg. I've reverted the python30-1.0.tcl change, as py30-tc installs fine with one change: tc's setup.py has hardcoded /opt/local so that needs to be changed in the py*-tc Portfiles, I used: post-patch { reinplace "s|/opt/local|${prefix}|g" ${worksrcpath}/setup.py } After that py30-tc installed without issues into ${prefix}/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/site-packages Bryan [1] - [2] - > > Gonna test this out more tomorrow ? please, be my guest and fix if you > want to. There is a python30 port you can test with: py30-tc > > (It's 5 am here and I'm gonna go to work in 3 hours. yikes!) > > > -- > Rasmus Andersson From blb at macports.org Sun Mar 1 22:53:00 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 1 Mar 2009 23:53:00 -0700 Subject: trunk and 10.3 support Message-ID: <20090302065300.GK917@ninagal.withay.com> After the privsep GSoC stuff was merged to trunk [1], some ports failed due to the new feature changing file ownership [2,3]. I fixed this by instead using lchown() so that links themselves were updated, instead of their targets [4]. The problem is that 10.3 doesn't support lchown() which means that currently trunk fails to build there. Using a HAVE_LCHOWN test, we could fall back to using just chown() but then we're right back to the original problem but just for 10.3. Porting lchown() to 10.3 is not going to happen unless we start shipping a custom kernel for those machines. So the big question is, do we pull privsep or use this as a good point (1.8.0) to drop 10.3 support? Or complicate things to just not build the privsep on 10.3? Bryan [1] - [2] - [3] - [4] - From jkh at apple.com Sun Mar 1 23:38:41 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Sun, 1 Mar 2009 23:38:41 -0800 Subject: trunk and 10.3 support In-Reply-To: <20090302065300.GK917@ninagal.withay.com> References: <20090302065300.GK917@ninagal.withay.com> Message-ID: <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> On Mar 1, 2009, at 10:53 PM, Bryan Blackburn wrote: > The problem is that 10.3 doesn't support lchown() which means that > currently > trunk fails to build there. Using a HAVE_LCHOWN test, we could fall > back to > using just chown() but then we're right back to the original problem > but > just for 10.3. Porting lchown() to 10.3 is not going to happen > unless we > start shipping a custom kernel for those machines. You could also simply punt on the notion of link ownership for tiger (call chown() for non-links, do nothing for links) since I seem to recall that they inherited their ownership information from their containing directory on 10.3 anyway - links have been somewhat less "real" in prior releases than they are today. - Jordan From ryandesign at macports.org Mon Mar 2 00:15:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 2 Mar 2009 02:15:38 -0600 Subject: trunk and 10.3 support In-Reply-To: <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> References: <20090302065300.GK917@ninagal.withay.com> <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> Message-ID: <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> On Mar 2, 2009, at 01:38, Jordan K. Hubbard wrote: > On Mar 1, 2009, at 10:53 PM, Bryan Blackburn wrote: > >> The problem is that 10.3 doesn't support lchown() which means that >> currently >> trunk fails to build there. Using a HAVE_LCHOWN test, we could >> fall back to >> using just chown() but then we're right back to the original >> problem but >> just for 10.3. Porting lchown() to 10.3 is not going to happen >> unless we >> start shipping a custom kernel for those machines. > > You could also simply punt on the notion of link ownership for tiger Panther, not Tiger. > (call chown() for non-links, do nothing for links) since I seem to > recall that they inherited their ownership information from their > containing directory on 10.3 anyway - links have been somewhat less > "real" in prior releases than they are today. I found this page: http://www.jacek-dom.net/software/psync/readme.txt It says: "Note on Panther symlinks attributes: In older versions of BSD (and in OS X 10.2 and earlier) symbolic links did not have their own attributes (ownership and permissions) - they inherited attributes of objects they pointed to. In FreeBSD 5.1 (on which Panther is based in large part) symbolic links have their own attributes. However, Apple, while porting FreeBSD to Darwin, allowed symlinks to have its own attributes, but disabled all code that allowed to manipulate those attributes - the system calls that implement it (lchmod, lchown and lutimes) are commented out in source code (you can see for yourself: ). They did not remove it from documentation - so man pages for chmod, chown, chgrp and touch describe the new -h option that allows to modify symlink attributes, but it does not work. I am sure that they had a very good reason to do that :)." I have not tested whether this information is still accurate. But even if it is, I don't think this is any reason to kill all hopes of running MacPorts 1.8.0 on Panther, especially since it would be no different than any previous version of MacPorts in regard to symlink ownership. Also note that we have another feature in MacPorts already that does not work on Panther: the -E option to reinplace. Rather than cutting off Panther support entirely at that point, the solution that was implemented simply makes the -E option unavailable in reinplace on Panther. So any of the 67 ports that use that option won't work on Panther, but others will. Some of those ports probably don't even need to use the -E option; someone probably just copied it from another port and didn't know what it was for. In fact I would imagine any of them could be rewritten to not use the -E option if necessary. From jkh at apple.com Mon Mar 2 00:34:57 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon, 2 Mar 2009 00:34:57 -0800 Subject: trunk and 10.3 support In-Reply-To: <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> References: <20090302065300.GK917@ninagal.withay.com> <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> Message-ID: <1E667DA8-4B1B-4A2C-B102-8FEF0A6D43C8@apple.com> Thanks for the correction - I have a hard time keeping the various releases straight since they all seem to kind of blend into one another for some reason. :-) I don't think the question is "whether to exclude Panther" (though at almost 6 years old, one wonders how long users might expect open source projects to support it), but rather how much forward progress should be held hostage to releases like Panther. I believe the original question regarded the implementation of one of the GSoC projects and what to do in the case of an old release, for which my suggestion was simply "punt" given the low reward-to-effort ratio. - Jordan On Mar 2, 2009, at 12:15 AM, Ryan Schmidt wrote: > > On Mar 2, 2009, at 01:38, Jordan K. Hubbard wrote: > >> On Mar 1, 2009, at 10:53 PM, Bryan Blackburn wrote: >> >>> The problem is that 10.3 doesn't support lchown() which means that >>> currently >>> trunk fails to build there. Using a HAVE_LCHOWN test, we could >>> fall back to >>> using just chown() but then we're right back to the original >>> problem but >>> just for 10.3. Porting lchown() to 10.3 is not going to happen >>> unless we >>> start shipping a custom kernel for those machines. >> >> You could also simply punt on the notion of link ownership for tiger > > Panther, not Tiger. > >> (call chown() for non-links, do nothing for links) since I seem to >> recall that they inherited their ownership information from their >> containing directory on 10.3 anyway - links have been somewhat less >> "real" in prior releases than they are today. > > > I found this page: > > http://www.jacek-dom.net/software/psync/readme.txt > > It says: > > "Note on Panther symlinks attributes: In older versions of BSD (and > in OS X 10.2 and earlier) symbolic links did not have their own > attributes (ownership and permissions) - they inherited attributes > of objects they pointed to. In FreeBSD 5.1 (on which Panther is > based in large part) symbolic links have their own attributes. > However, Apple, while porting FreeBSD to Darwin, allowed symlinks to > have its own attributes, but disabled all code that allowed to > manipulate those attributes - the system calls that implement it > (lchmod, lchown and lutimes) are commented out in source code (you > can see for yourself: >). They did not remove it from documentation - so man pages for > chmod, chown, chgrp and touch describe the new -h option that allows > to modify symlink attributes, but it does not work. I am sure that > they had a very good reason to do that :)." > > I have not tested whether this information is still accurate. But > even if it is, I don't think this is any reason to kill all hopes of > running MacPorts 1.8.0 on Panther, especially since it would be no > different than any previous version of MacPorts in regard to symlink > ownership. > > Also note that we have another feature in MacPorts already that does > not work on Panther: the -E option to reinplace. Rather than cutting > off Panther support entirely at that point, the solution that was > implemented simply makes the -E option unavailable in reinplace on > Panther. So any of the 67 ports that use that option won't work on > Panther, but others will. Some of those ports probably don't even > need to use the -E option; someone probably just copied it from > another port and didn't know what it was for. In fact I would > imagine any of them could be rewritten to not use the -E option if > necessary. > > From ryandesign at macports.org Mon Mar 2 00:40:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 2 Mar 2009 02:40:35 -0600 Subject: Files disappearing from distfiles mirror In-Reply-To: <49AA6310.6050704@macports.org> References: <49AA6310.6050704@macports.org> Message-ID: On Mar 1, 2009, at 04:27, Joshua Root wrote: > Ryan Schmidt wrote: > >> But I would like to know how it came to be that the file was on >> all of >> our mirrors in October 2008 but then disappeared from two of them >> since >> then. > > Portmirror deletes files when the checksums don't match. Hmm. Well on the one hand that's a good thing: if someone commits a port update, and the distfiles mirror fetches the distfile, and the checksums don't match what's in the port, it's good that this file doesn't end up on the mirror. It would be great if the committer could be informed of this checksum mismatch but that's another matter. But on the other hand it's a bad thing: if someone discovers that an upstream stealth update has occurred and updates the port but does so by only changing the checksums (which is what we don't want maintainers to do), then several bad things happen: 1) Anyone who has the old distfiles with the old checksums on their hard drive already and tries to reinstall the port will now get a checksum error (this is why we don't want maintainers to only update the checksums but leave the distfile in the same place; instead maintainers should make sure the dist_subdir changes). 2) The distfiles mirror will -- do what? I don't know. It will either leave the old distfile in place, causing checksum errors for anyone downloading the new file, or it will delete the old distfile and download the new distfile, causing checksum errors for anyone who hasn't "port sync"'d yet, and it's also bad for anyone wanting to research what actually changed in the stealth upgrade because we've now nuked the only copy of that file that still existed. I would like for the distfiles mirrors to never delete older files. I think that was the original intent. How could we guarantee this I wonder? It would be nice if "portmirror" could get the new files into a temporary directory and then we could copy those into the real distfiles directory afterward, instead of letting portmirror loose on the real distfiles directory where it might possibly delete something irreplaceable. From blb at macports.org Mon Mar 2 00:47:20 2009 From: blb at macports.org (Bryan Blackburn) Date: Mon, 2 Mar 2009 01:47:20 -0700 Subject: trunk and 10.3 support In-Reply-To: <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> References: <20090302065300.GK917@ninagal.withay.com> <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> Message-ID: <20090302084720.GM917@ninagal.withay.com> On Mon, Mar 02, 2009 at 02:15:38AM -0600, Ryan Schmidt said: [...] > > I have not tested whether this information is still accurate. But even if > it is, I don't think this is any reason to kill all hopes of running > MacPorts 1.8.0 on Panther, especially since it would be no different than > any previous version of MacPorts in regard to symlink ownership. I definitely know lchown() is not on 10.3.9, since I stumbled onto this while trying to build trunk there. But the question is should we simply disable the chown portion in port (maybe noop'ing proc chown in portutil.tcl) for 10.3 or try and wrap all the privsep in a "not on 10.3" conditional block(s)? Disabling the chown means that other bits of the privsep stuff will probably have issues as well, so maybe there's a way to use the old method but ignore errors on symlinks? Bryan [...] From rasmus at macports.org Mon Mar 2 00:53:15 2009 From: rasmus at macports.org (Rasmus Andersson) Date: Mon, 2 Mar 2009 09:53:15 +0100 Subject: Python 3.0 gone? In-Reply-To: <20090302045030.GI917@ninagal.withay.com> References: <20090302013122.GC917@ninagal.withay.com> <20090302034220.GH917@ninagal.withay.com> <20090302045030.GI917@ninagal.withay.com> Message-ID: On Mon, Mar 2, 2009 at 05:50, Bryan Blackburn wrote: > On Mon, Mar 02, 2009 at 05:12:45AM +0100, Rasmus Andersson said: > [...] >> >> It is not a valid argument in the Python 3.0 I have got from MacPorts. >> Was this patched recently? (my installation might be about a month >> old) > > Yeah, your python30 install is old, vast improvements were made in r46197 > [1] and the revision increased in r46199 [2]. ?Those improvements do include > the better framework build and --no-user-cfg. ?I've reverted the > python30-1.0.tcl change, as py30-tc installs fine with one change: > > tc's setup.py has hardcoded /opt/local so that needs to be changed in the > py*-tc Portfiles, I used: > > post-patch { > ? ? ? ?reinplace "s|/opt/local|${prefix}|g" ${worksrcpath}/setup.py > } > > After that py30-tc installed without issues into > ${prefix}/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/site-packages > > Bryan > > [1] - > [2] - Thanks Bryan ? both for the info and for the quick revert of the group file. (Did a clean install, installing everything from scratch, and it worked like a charm). Have a great day everyone! > >> >> Gonna test this out more tomorrow ? please, be my guest and fix if you >> want to. There is a python30 port you can test with: py30-tc >> >> (It's 5 am here and I'm gonna go to work in 3 hours. yikes!) >> From jeremyhu at macports.org Mon Mar 2 00:54:02 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Mon, 2 Mar 2009 00:54:02 -0800 Subject: trunk and 10.3 support In-Reply-To: <1E667DA8-4B1B-4A2C-B102-8FEF0A6D43C8@apple.com> References: <20090302065300.GK917@ninagal.withay.com> <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> <1E667DA8-4B1B-4A2C-B102-8FEF0A6D43C8@apple.com> Message-ID: <86498427-6A03-4944-B1A3-37917E5D3BC6@macports.org> Isn't Panther *already* not "officially" supported anymore? http://www.macports.org says: """ We provide a single software tree that attempts to track the latest release of every software title (port) we distribute, without splitting them into ?stable? Vs. ?unstable? branches, targetting mainly the current Mac OS X release (10.5, A.K.A Leopard) and the immediately previous one (10.4, A.K.A. Tiger). """ To me, that implies that we try not to break older releases, but we won't bend over backwards to support them either. Add the HAVE_LCHOWN bits to configure.ac and let Panther users deal with the issue. They have thus far. --Jeremy On Mar 2, 2009, at 00:34, Jordan K. Hubbard wrote: > Thanks for the correction - I have a hard time keeping the various > releases straight since they all seem to kind of blend into one > another for some reason. :-) > > I don't think the question is "whether to exclude Panther" (though > at almost 6 years old, one wonders how long users might expect open > source projects to support it), but rather how much forward progress > should be held hostage to releases like Panther. I believe the > original question regarded the implementation of one of the GSoC > projects and what to do in the case of an old release, for which my > suggestion was simply "punt" given the low reward-to-effort ratio. > > - Jordan > > On Mar 2, 2009, at 12:15 AM, Ryan Schmidt wrote: > >> >> On Mar 2, 2009, at 01:38, Jordan K. Hubbard wrote: >> >>> On Mar 1, 2009, at 10:53 PM, Bryan Blackburn wrote: >>> >>>> The problem is that 10.3 doesn't support lchown() which means >>>> that currently >>>> trunk fails to build there. Using a HAVE_LCHOWN test, we could >>>> fall back to >>>> using just chown() but then we're right back to the original >>>> problem but >>>> just for 10.3. Porting lchown() to 10.3 is not going to happen >>>> unless we >>>> start shipping a custom kernel for those machines. >>> >>> You could also simply punt on the notion of link ownership for tiger >> >> Panther, not Tiger. >> >>> (call chown() for non-links, do nothing for links) since I seem to >>> recall that they inherited their ownership information from their >>> containing directory on 10.3 anyway - links have been somewhat >>> less "real" in prior releases than they are today. >> >> >> I found this page: >> >> http://www.jacek-dom.net/software/psync/readme.txt >> >> It says: >> >> "Note on Panther symlinks attributes: In older versions of BSD (and >> in OS X 10.2 and earlier) symbolic links did not have their own >> attributes (ownership and permissions) - they inherited attributes >> of objects they pointed to. In FreeBSD 5.1 (on which Panther is >> based in large part) symbolic links have their own attributes. >> However, Apple, while porting FreeBSD to Darwin, allowed symlinks >> to have its own attributes, but disabled all code that allowed to >> manipulate those attributes - the system calls that implement it >> (lchmod, lchown and lutimes) are commented out in source code (you >> can see for yourself: > >). They did not remove it from documentation - so man pages for >> chmod, chown, chgrp and touch describe the new -h option that >> allows to modify symlink attributes, but it does not work. I am >> sure that they had a very good reason to do that :)." >> >> I have not tested whether this information is still accurate. But >> even if it is, I don't think this is any reason to kill all hopes >> of running MacPorts 1.8.0 on Panther, especially since it would be >> no different than any previous version of MacPorts in regard to >> symlink ownership. >> >> Also note that we have another feature in MacPorts already that >> does not work on Panther: the -E option to reinplace. Rather than >> cutting off Panther support entirely at that point, the solution >> that was implemented simply makes the -E option unavailable in >> reinplace on Panther. So any of the 67 ports that use that option >> won't work on Panther, but others will. Some of those ports >> probably don't even need to use the -E option; someone probably >> just copied it from another port and didn't know what it was for. >> In fact I would imagine any of them could be rewritten to not use >> the -E option if necessary. >> >> > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From afb at macports.org Mon Mar 2 02:30:09 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 2 Mar 2009 11:30:09 +0100 Subject: trunk and 10.3 support In-Reply-To: <86498427-6A03-4944-B1A3-37917E5D3BC6@macports.org> References: <20090302065300.GK917@ninagal.withay.com> <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> <1E667DA8-4B1B-4A2C-B102-8FEF0A6D43C8@apple.com> <86498427-6A03-4944-B1A3-37917E5D3BC6@macports.org> Message-ID: Jeremy Huddleston wrote: > Isn't Panther *already* not "officially" supported anymore? > > http://www.macports.org says: > """ > We provide a single software tree that attempts to track the latest > release of every software title (port) we distribute, without > splitting them into ?stable? Vs. ?unstable? branches, targetting > mainly the current Mac OS X release (10.5, A.K.A Leopard) and the > immediately previous one (10.4, A.K.A. Tiger). > """ Last time this was discussed, the decision was that MacPorts 1.7.x would support Panther but not 1.8... For next release, it should drop 10.3 and add 10.6 At least as far as the DMG disk images go, that is... --anders From ryandesign at macports.org Mon Mar 2 03:08:56 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 2 Mar 2009 05:08:56 -0600 Subject: trunk and 10.3 support In-Reply-To: References: <20090302065300.GK917@ninagal.withay.com> <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> <1E667DA8-4B1B-4A2C-B102-8FEF0A6D43C8@apple.com> <86498427-6A03-4944-B1A3-37917E5D3BC6@macports.org> Message-ID: <1C4B4692-834F-42F9-8B08-E5AB9C986D72@macports.org> On Mar 2, 2009, at 04:30, Anders F Bj?rklund wrote: > Jeremy Huddleston wrote: > >> Isn't Panther *already* not "officially" supported anymore? >> >> http://www.macports.org says: >> """ >> We provide a single software tree that attempts to track the >> latest release of every software title (port) we distribute, >> without splitting them into ?stable? Vs. ?unstable? branches, >> targetting mainly the current Mac OS X release (10.5, A.K.A >> Leopard) and the immediately previous one (10.4, A.K.A. Tiger). >> """ Yes, Panther is not officially supported anymore. > Last time this was discussed, the decision was that > MacPorts 1.7.x would support Panther but not 1.8... > > For next release, it should drop 10.3 and add 10.6 > At least as far as the DMG disk images go, that is... I don't remember agreeing to drop Panther for MacPorts 1.8.0. :) Do you have a link handy to that discussion? From afb at macports.org Mon Mar 2 03:34:27 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 2 Mar 2009 12:34:27 +0100 Subject: trunk and 10.3 support In-Reply-To: <1C4B4692-834F-42F9-8B08-E5AB9C986D72@macports.org> References: <20090302065300.GK917@ninagal.withay.com> <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> <1E667DA8-4B1B-4A2C-B102-8FEF0A6D43C8@apple.com> <86498427-6A03-4944-B1A3-37917E5D3BC6@macports.org> <1C4B4692-834F-42F9-8B08-E5AB9C986D72@macports.org> Message-ID: <5ED18789-CEDE-4315-A04F-B54FC4CAAFD9@macports.org> Ryan Schmidt wrote: >> Last time this was discussed, the decision was that >> MacPorts 1.7.x would support Panther but not 1.8... >> >> For next release, it should drop 10.3 and add 10.6 >> At least as far as the DMG disk images go, that is... > > I don't remember agreeing to drop Panther for MacPorts 1.8.0. :) Do > you have a link handy to that discussion? It was on IRC #MacPorts iirc, might be in the logs somewhere... Either way, Panther support should be dropped - like Jaguar now ? --anders From ryandesign at macports.org Mon Mar 2 03:44:06 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 2 Mar 2009 05:44:06 -0600 Subject: trunk and 10.3 support In-Reply-To: <5ED18789-CEDE-4315-A04F-B54FC4CAAFD9@macports.org> References: <20090302065300.GK917@ninagal.withay.com> <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> <1E667DA8-4B1B-4A2C-B102-8FEF0A6D43C8@apple.com> <86498427-6A03-4944-B1A3-37917E5D3BC6@macports.org> <1C4B4692-834F-42F9-8B08-E5AB9C986D72@macports.org> <5ED18789-CEDE-4315-A04F-B54FC4CAAFD9@macports.org> Message-ID: <91E50098-B081-4EAD-9C77-6B7745A3F95F@macports.org> On Mar 2, 2009, at 05:34, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >>> Last time this was discussed, the decision was that >>> MacPorts 1.7.x would support Panther but not 1.8... >>> >>> For next release, it should drop 10.3 and add 10.6 >>> At least as far as the DMG disk images go, that is... >> >> I don't remember agreeing to drop Panther for MacPorts 1.8.0. :) >> Do you have a link handy to that discussion? > > It was on IRC #MacPorts iirc, might be in the logs somewhere... Ah! Well I've never been on the MacPorts IRC channel or read its logs. > Either way, Panther support should be dropped - like Jaguar now ? MacPorts itself hasn't built on Jaguar in some time. I tried it awhile ago and kept running into problems. Nobody has complained about it, that I know of, so I have no problem not supporting Jaguar. People do still write to the list about Panther problems though. From jmr at macports.org Mon Mar 2 05:39:50 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 03 Mar 2009 00:39:50 +1100 Subject: trunk and 10.3 support In-Reply-To: <1C4B4692-834F-42F9-8B08-E5AB9C986D72@macports.org> References: <20090302065300.GK917@ninagal.withay.com> <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> <1E667DA8-4B1B-4A2C-B102-8FEF0A6D43C8@apple.com> <86498427-6A03-4944-B1A3-37917E5D3BC6@macports.org> <1C4B4692-834F-42F9-8B08-E5AB9C986D72@macports.org> Message-ID: <49ABE1A6.1060505@macports.org> Ryan Schmidt wrote: > > On Mar 2, 2009, at 04:30, Anders F Bj?rklund wrote: > >> Last time this was discussed, the decision was that >> MacPorts 1.7.x would support Panther but not 1.8... Well, inasmuch as we "support" anything. The default response to Panther issues is "patches welcome", whereas it's "oh, we should fix that" for Tiger/Leopard. >> For next release, it should drop 10.3 and add 10.6 >> At least as far as the DMG disk images go, that is... > > I don't remember agreeing to drop Panther for MacPorts 1.8.0. :) I do. :-) Sorry, we forgot to tell you, all the *real* decisions are made on IRC. ;-) Seriously though, it's going to be up to whoever builds the dmgs in the end. IIRC, reasons given for not building a Panther dmg for 1.8 were that it confuses the 'supported' status already, and that Snow Leopard may well be imminent by then. - Josh From ryandesign at macports.org Mon Mar 2 05:49:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 2 Mar 2009 07:49:35 -0600 Subject: trunk and 10.3 support In-Reply-To: <49ABE1A6.1060505@macports.org> References: <20090302065300.GK917@ninagal.withay.com> <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> <1E667DA8-4B1B-4A2C-B102-8FEF0A6D43C8@apple.com> <86498427-6A03-4944-B1A3-37917E5D3BC6@macports.org> <1C4B4692-834F-42F9-8B08-E5AB9C986D72@macports.org> <49ABE1A6.1060505@macports.org> Message-ID: <7BBB7BCD-43D8-4C05-8D1A-2059273E3CF5@macports.org> On Mar 2, 2009, at 07:39, Joshua Root wrote: > Ryan Schmidt wrote: > >> On Mar 2, 2009, at 04:30, Anders F Bj?rklund wrote: >> >>> Last time this was discussed, the decision was that >>> MacPorts 1.7.x would support Panther but not 1.8... > > Well, inasmuch as we "support" anything. The default response to > Panther > issues is "patches welcome", whereas it's "oh, we should fix that" for > Tiger/Leopard. Sure. Oh, right: other issue that we have on Panther, that we've had since 1.6.0, is that debug/verbose mode doesn't print most of the info it should on Panther. Makes bug reports even harder! :) #15814. I at least was able to isolate the commit that caused this, though not to figure out enough of it to provide a fix. >>> For next release, it should drop 10.3 and add 10.6 >>> At least as far as the DMG disk images go, that is... >> >> I don't remember agreeing to drop Panther for MacPorts 1.8.0. :) > > I do. :-) > > Sorry, we forgot to tell you, all the *real* decisions are made on > IRC. ;-) Oh no. We're not having that again. :) This is sounding like my last job where all the real decisions were made outside on smoke breaks. As one of the only non-smokers, I was frequently out of the loop. > Seriously though, it's going to be up to whoever builds the dmgs in > the > end. I would say it's up to all of us developing the software up to the point when we want to make a release. The person packaging the release can't release a version for Panther, even if he wants to, if it doesn't compile on Panther. > IIRC, reasons given for not building a Panther dmg for 1.8 were > that it confuses the 'supported' status already, and that Snow Leopard > may well be imminent by then. Well, the existence of a new operating system version that only works on Intel Macs probably doesn't have much bearing on the OS upgrade priorities of someone who has a PowerPC Mac. From jmr at macports.org Mon Mar 2 06:18:56 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 03 Mar 2009 01:18:56 +1100 Subject: trunk and 10.3 support In-Reply-To: <7BBB7BCD-43D8-4C05-8D1A-2059273E3CF5@macports.org> References: <20090302065300.GK917@ninagal.withay.com> <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> <1E667DA8-4B1B-4A2C-B102-8FEF0A6D43C8@apple.com> <86498427-6A03-4944-B1A3-37917E5D3BC6@macports.org> <1C4B4692-834F-42F9-8B08-E5AB9C986D72@macports.org> <49ABE1A6.1060505@macports.org> <7BBB7BCD-43D8-4C05-8D1A-2059273E3CF5@macports.org> Message-ID: <49ABEAD0.3010009@macports.org> Ryan Schmidt wrote: > On Mar 2, 2009, at 07:39, Joshua Root wrote: >> Seriously though, it's going to be up to whoever builds the dmgs in the >> end. > > I would say it's up to all of us developing the software up to the point > when we want to make a release. The person packaging the release can't > release a version for Panther, even if he wants to, if it doesn't > compile on Panther. Right, I was assuming we weren't going to break MP on Panther entirely. >> IIRC, reasons given for not building a Panther dmg for 1.8 were >> that it confuses the 'supported' status already, and that Snow Leopard >> may well be imminent by then. > > Well, the existence of a new operating system version that only works on > Intel Macs probably doesn't have much bearing on the OS upgrade > priorities of someone who has a PowerPC Mac. It does make them that one step more obsolete, though. - Josh From markd at macports.org Mon Mar 2 09:10:03 2009 From: markd at macports.org (markd at macports.org) Date: Mon, 02 Mar 2009 09:10:03 -0800 Subject: [47462] trunk/dports/net/scotty/Portfile Message-ID: Hi Jeremy, Ok now I remember. There is a tkined X11 editor that gets installed by scotty. So I supposed that I should include it as a dependency, though I doubt anyone would use it these days anyway. But I didn't think that whether or not a port links against a library should determine whether it is a dependency or not. But at the time I probably didn't fully understand the difference between depends_lib and depends_run and I suppose it should have been the latter if anything. But I'm fine with dropping X11 as a dependency since I don't think anyone uses tkined anymore. Mark ----- Original Message ----- >It looks like scotty only links to tk, so it seems it doesn't need any >specific X11 deps at all. > >However, at least here, it actually builds against the system tcl/tk and >not >MacPorts even though it claims dependencies on both: > > tnm.dylib (compatibility version 0.0.0, current version 0.0.0) > /System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl >(compatibility version 8.4.0, current version 8.4.0) > /System/Library/Frameworks/Tk.framework/Versions/8.4/Tk >(compatibility version 8.4.0, current version 8.4.0) >Hi Jeremy, > >I see that the 'lib:libX11.6:XFree86' dependency was removed a month ago >in the Scotty port in favor of 'port:xorg-libs', and now the latter has >been removed. I don't remember much about the Scotty port, but the >latest change simply says xorg-libs is unneeded. Can you give some more >explanation on the reasons for the two changes? > >Mark >Date: Sat, 28 Feb 2009 02:02:51 -0800 (PST) >From: jeremyhu at macports.org >Subject: [47462] trunk/dports/net/scotty/Portfile >To: macports-changes at lists.macosforge.org >Message-ID: <20090228100251.6375910E267A at beta.macosforge.org> >Content-Type: text/plain; charset="utf-8" > >Revision: 47462 > http://trac.macports.org/changeset/47462 >Author: jeremyhu at macports.org >Date: 2009-02-28 02:02:51 -0800 (Sat, 28 Feb 2009) >Log Message: >----------- >scotty: Remove unneded dependncy on xorg-libs > >Modified Paths: >-------------- > trunk/dports/net/scotty/Portfile > >Modified: trunk/dports/net/scotty/Portfile >=================================================================== >--- trunk/dports/net/scotty/Portfile 2009-02-28 10:01:05 UTC (rev >47461) >+++ trunk/dports/net/scotty/Portfile 2009-02-28 10:02:51 UTC (rev >47462) >@@ -24,8 +24,7 @@ > #svn.url >https://subversion.eecs.iu-bremen.de/svn/schoenw/src/scotty > #depends_build port:subversion > >-depends_lib port:xorg-libs \ >- port:tcl \ >+depends_lib port:tcl \ > port:tk > > patchfiles patch-Makefile.in \ >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: > > From alakazam at macports.org Mon Mar 2 09:11:32 2009 From: alakazam at macports.org (Olivier Le Floch) Date: Mon, 2 Mar 2009 18:11:32 +0100 Subject: PHP5 update forces recompilation of php5-eaccelerator : should we bump revisions ? Message-ID: <18CE8501-357E-42A1-8CFB-332D18002C18@macports.org> Hi, The php5 port has recently been updated to version 5.2.9. Such an update forces users to recompile php5-eaccelerator for compatibility. Should we bump php5-eaccelerator's revision when updating php5's ? The same is probably true for php5-xdebug and other php5 extensions. If we do bump revisions, what would be the best way to not forget to do so ? Regards, -- Olivier Le Floch From jeremyhu at macports.org Mon Mar 2 11:47:50 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Mon, 2 Mar 2009 11:47:50 -0800 Subject: [47462] trunk/dports/net/scotty/Portfile In-Reply-To: References: Message-ID: <67F2C769-C133-4D9C-97B7-9D6AFC70EFC4@macports.org> Not exactly... tkined is just a wish script. It doesn't need anything from xorg-libs directly. It just needs wish. wish is provided by its other dependencies. In fact, tkined doesn't even run here. It tries to use the system wish (which isn't X11 based, btw) and fails with: /opt/local/bin $ ./tkined Error in startup script: can't find package Tkined 1.5.0 while executing "package require -exact Tkined 1.5.0" (file "./tkined" line 12) On Mar 2, 2009, at 09:10, markd at macports.org wrote: > Hi Jeremy, > > Ok now I remember. There is a tkined X11 editor that gets installed > by > scotty. So I supposed that I should include it as a dependency, > though I > doubt anyone would use it these days anyway. > > But I didn't think that whether or not a port links against a library > should determine whether it is a dependency or not. But at the time I > probably didn't fully understand the difference between depends_lib > and > depends_run and I suppose it should have been the latter if > anything. But > I'm fine with dropping X11 as a dependency since I don't think > anyone uses > tkined anymore. > > Mark > > ----- Original Message ----- > >> It looks like scotty only links to tk, so it seems it doesn't need >> any >> specific X11 deps at all. >> >> However, at least here, it actually builds against the system tcl/ >> tk and >> not >> MacPorts even though it claims dependencies on both: >> >> tnm.dylib (compatibility version 0.0.0, current version 0.0.0) >> /System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl >> (compatibility version 8.4.0, current version 8.4.0) >> /System/Library/Frameworks/Tk.framework/Versions/8.4/Tk >> (compatibility version 8.4.0, current version 8.4.0) > > >> Hi Jeremy, >> >> I see that the 'lib:libX11.6:XFree86' dependency was removed a >> month ago >> in the Scotty port in favor of 'port:xorg-libs', and now the latter >> has >> been removed. I don't remember much about the Scotty port, but the >> latest change simply says xorg-libs is unneeded. Can you give some >> more >> explanation on the reasons for the two changes? >> >> Mark > >> Date: Sat, 28 Feb 2009 02:02:51 -0800 (PST) >> From: jeremyhu at macports.org >> Subject: [47462] trunk/dports/net/scotty/Portfile >> To: macports-changes at lists.macosforge.org >> Message-ID: <20090228100251.6375910E267A at beta.macosforge.org> >> Content-Type: text/plain; charset="utf-8" >> >> Revision: 47462 >> http://trac.macports.org/changeset/47462 >> Author: jeremyhu at macports.org >> Date: 2009-02-28 02:02:51 -0800 (Sat, 28 Feb 2009) >> Log Message: >> ----------- >> scotty: Remove unneded dependncy on xorg-libs >> >> Modified Paths: >> -------------- >> trunk/dports/net/scotty/Portfile >> >> Modified: trunk/dports/net/scotty/Portfile >> =================================================================== >> --- trunk/dports/net/scotty/Portfile 2009-02-28 10:01:05 UTC (rev >> 47461) >> +++ trunk/dports/net/scotty/Portfile 2009-02-28 10:02:51 UTC (rev >> 47462) >> @@ -24,8 +24,7 @@ >> #svn.url >> https://subversion.eecs.iu-bremen.de/svn/schoenw/src/scotty >> #depends_build port:subversion >> >> -depends_lib port:xorg-libs \ >> - port:tcl \ >> +depends_lib port:tcl \ >> port:tk >> >> patchfiles patch-Makefile.in \ >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> > > >> > From blb at macports.org Mon Mar 2 13:07:41 2009 From: blb at macports.org (Bryan Blackburn) Date: Mon, 2 Mar 2009 14:07:41 -0700 Subject: trunk and 10.3 support In-Reply-To: <1E667DA8-4B1B-4A2C-B102-8FEF0A6D43C8@apple.com> References: <20090302065300.GK917@ninagal.withay.com> <3D82DDDB-79BD-45CB-ABB0-DAAAA94EE6B8@apple.com> <0FA07D7C-BA12-4809-9A5E-781519CF8167@macports.org> <1E667DA8-4B1B-4A2C-B102-8FEF0A6D43C8@apple.com> Message-ID: <20090302210741.GA1058@ninagal.withay.com> On Mon, Mar 02, 2009 at 12:34:57AM -0800, Jordan K. Hubbard said: > Thanks for the correction - I have a hard time keeping the various > releases straight since they all seem to kind of blend into one another > for some reason. :-) > > I don't think the question is "whether to exclude Panther" (though at > almost 6 years old, one wonders how long users might expect open source > projects to support it), but rather how much forward progress should be > held hostage to releases like Panther. I believe the original question > regarded the implementation of one of the GSoC projects and what to do in > the case of an old release, for which my suggestion was simply "punt" > given the low reward-to-effort ratio. Yup, forward progress is what's going to suffer by trying to continue to support older systems. Do we want to try and continue to ifdef new features in base which won't work on 10.3, until base becomes a mass of such backwards-compatibility ugliness? Given how few people we have working on base in the first place, plus how many of them actively use 10.3, trying to support it will just get worse. We can claim "we don't specifically drop support for it" but how many people know that to be true? I broke 10.3 with the use of lchown() 10 days ago and just noticed yesterday, only because I was curious whether or not something completely unrelated (ticket #18719) happened to fix #15814 (it didn't). Had I not done this exercise in curiosity, how long would it have been? Would it have been when someone finally went to build DMGs for 1.8.0 on 10.3? Given our limited resources, the best path I see is to simply drop 10.3 for trunk/1.8 and see if there are people willing to keep the 1.7 branch working for 10.3, including perhaps stubbing out Portfile features added in the future, or maybe even using older Portfiles since more and more ports will fail to build on 10.3 regardless of base's support for it. Bryan > > - Jordan > From blb at macports.org Mon Mar 2 13:09:06 2009 From: blb at macports.org (Bryan Blackburn) Date: Mon, 2 Mar 2009 14:09:06 -0700 Subject: PHP5 update forces recompilation of php5-eaccelerator : should we bump revisions ? In-Reply-To: <18CE8501-357E-42A1-8CFB-332D18002C18@macports.org> References: <18CE8501-357E-42A1-8CFB-332D18002C18@macports.org> Message-ID: <20090302210906.GB1058@ninagal.withay.com> On Mon, Mar 02, 2009 at 06:11:32PM +0100, Olivier Le Floch said: > Hi, > > The php5 port has recently been updated to version 5.2.9. Such an update > forces users to recompile php5-eaccelerator for compatibility. Should we > bump php5-eaccelerator's revision when updating php5's ? The same is > probably true for php5-xdebug and other php5 extensions. If we do bump > revisions, what would be the best way to not forget to do so ? Long-term would be to implement ticket #17473 For now perhaps a comment in the php5 Portfile as a reminder? Bryan > > Regards, > > -- > Olivier Le Floch > From ryandesign at macports.org Mon Mar 2 21:01:12 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 2 Mar 2009 23:01:12 -0600 Subject: [47635] trunk/dports/python/py-biggles/Portfile In-Reply-To: <20090302162407.AC9E3110BE55@beta.macosforge.org> References: <20090302162407.AC9E3110BE55@beta.macosforge.org> Message-ID: On Mar 2, 2009, at 10:24, deric at macports.org wrote: > +build.target build_ext > +build.args -I/opt/local/include You must not hard-code /opt/local into portfiles because MacPorts may be in a different prefix. Use ${prefix} instead. Also note -I${prefix}/include is really more of a C pre-processor directive than a build argument. So you may want to instead: build.env-append CPPFLAGS=-I${prefix}/include assuming the software supports CPPFLAGS. If not, try CFLAGS instead. The same feedback applies to py25-biggles from r47636. From deric.lists at gmail.com Mon Mar 2 22:28:07 2009 From: deric.lists at gmail.com (Daniel Ericsson) Date: Tue, 3 Mar 2009 07:28:07 +0100 Subject: [47635] trunk/dports/python/py-biggles/Portfile In-Reply-To: References: <20090302162407.AC9E3110BE55@beta.macosforge.org> Message-ID: <80bd4430903022228q3739f893j8ab791162a3ccafe@mail.gmail.com> On 3/3/09, Ryan Schmidt wrote: > > On Mar 2, 2009, at 10:24, deric at macports.org wrote: > > > +build.target build_ext > > +build.args -I/opt/local/include > > > > You must not hard-code /opt/local into portfiles because MacPorts may be in > a different prefix. Use ${prefix} instead. Fix in r47657. Seems I forgot to copy my final revision from my local repo to the one i keep the subversion checkout in, thanks for the heads up. > Also note -I${prefix}/include is really more of a C pre-processor directive > than a build argument. So you may want to instead: Right, the biggles INSTALL file have instructions for it as an argument to the distutils build script setup.py that's the reason I put it in build.args. Just wanted to follow upstream directions unless I had a good reason not to. -- Daniel From jeremy at lavergne.gotdns.org Tue Mar 3 07:39:55 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 3 Mar 2009 10:39:55 -0500 Subject: specifying a makefile Message-ID: How do I perform a "make -f FILE" in MacPorts? While I don't know if it's the way to do, I presently have this working: build.cmd "cd src && make -f makefile.osx" I did it that way because I didn't know how to get -f to work and build phase was ignoring the fact that I set the worksrcpath to inside src/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Tue Mar 3 08:33:15 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 3 Mar 2009 11:33:15 -0500 Subject: specifying a makefile In-Reply-To: <74c219d30903030815w6e8bce6dib99cabcc6e4d65eb@mail.gmail.com> References: <74c219d30903030815w6e8bce6dib99cabcc6e4d65eb@mail.gmail.com> Message-ID: >> How do I perform a "make -f FILE" in MacPorts? >> > > try something like this: > > build.dir ${worksrcpath}/src > build.args -f makefile.osx Thanks for the hints: Those got me through the build phase. Doing the same for the destroot phase got me finished. Is there a way of combining those 4 lines (since build.dir = destroot.dir, build.args = destroot.args) or must they each be set individually? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Tue Mar 3 08:42:03 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 3 Mar 2009 11:42:03 -0500 Subject: build.dir/destroot.dir quirkiness Message-ID: <477233E1-B64B-4C5E-BBB7-7A8B974DD090@lavergne.gotdns.org> While the Guide says these default to ${worksrcpath}, I just saw that they are only set to the initial value of that variable and not they were overridden as. I have to do the following to get the expected results: # this isn't saved into build or destroot.dir set worksrcpath ${worksrcpath}/src ... # reassigning build.dir ${worksrcpath} ... # reassinging destroot.dir ${worksrcpath} Is this expected behavior? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Tue Mar 3 08:45:09 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 3 Mar 2009 11:45:09 -0500 Subject: build.dir/destroot.dir quirkiness In-Reply-To: <477233E1-B64B-4C5E-BBB7-7A8B974DD090@lavergne.gotdns.org> References: <477233E1-B64B-4C5E-BBB7-7A8B974DD090@lavergne.gotdns.org> Message-ID: > While the Guide says these default to ${worksrcpath} I am sooo lying. Please ignore me (more than usual)! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From raimue at macports.org Tue Mar 3 08:45:54 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 03 Mar 2009 17:45:54 +0100 Subject: specifying a makefile In-Reply-To: References: <74c219d30903030815w6e8bce6dib99cabcc6e4d65eb@mail.gmail.com> Message-ID: <49AD5EC2.3070202@macports.org> Jeremy Lavergne wrote: >>> How do I perform a "make -f FILE" in MacPorts? >>> >> try something like this: >> >> build.dir ${worksrcpath}/src >> build.args -f makefile.osx > > Thanks for the hints: Those got me through the build phase. Doing > the same for the destroot phase got me finished. > > Is there a way of combining those 4 lines (since build.dir = > destroot.dir, build.args = destroot.args) or must they each be set > individually? The default for destroot.dir is already ${build.dir}. But there is no default for destroot.args. I am not sure if it would always make sense to use build.args by default. Rainer From raimue at macports.org Tue Mar 3 08:51:16 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 03 Mar 2009 17:51:16 +0100 Subject: build.dir/destroot.dir quirkiness In-Reply-To: <477233E1-B64B-4C5E-BBB7-7A8B974DD090@lavergne.gotdns.org> References: <477233E1-B64B-4C5E-BBB7-7A8B974DD090@lavergne.gotdns.org> Message-ID: <49AD6004.6020406@macports.org> Jeremy Lavergne wrote: > set worksrcpath ${worksrcpath}/src ${worksrcpath} is not an option and should not be changed. If you need a different subdirectory, use the worksrcdir option. Rainer From jeremy at lavergne.gotdns.org Tue Mar 3 09:11:58 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 3 Mar 2009 12:11:58 -0500 Subject: build.dir/destroot.dir quirkiness In-Reply-To: <49AD6004.6020406@macports.org> References: <477233E1-B64B-4C5E-BBB7-7A8B974DD090@lavergne.gotdns.org> <49AD6004.6020406@macports.org> Message-ID: >> set worksrcpath ${worksrcpath}/src > > ${worksrcpath} is not an option and should not be changed. If you > need a > different subdirectory, use the worksrcdir option. Thanks again for pointing that out. For others who might have this issue, here are my findings to the solution. At first, I figured I could just change all the worksrcpath to worksrcdir, unfortunately, I got this error: DEBUG: couldn't read file "edbrowse-3.4.3/src/makefile.osx": no such file or directory That path is way shorter than the usual, fully-qualified one. Digging through the Guide I found how each variable is composed: workpath = ${portbuildpath}/work worksrcdir = ${distname} worksrcpath = ${workpath}/${worksrcdir} Noticing which variables have what paths, I figured out what was wrong. I should have only changed "set worksrcpath", rather than changing all instances of worksrcpath as I would then use the worksrcpath variable in my phases. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From blb at macports.org Tue Mar 3 13:20:19 2009 From: blb at macports.org (Bryan Blackburn) Date: Tue, 3 Mar 2009 14:20:19 -0700 Subject: [47690] trunk/dports/www/edbrowse/Portfile In-Reply-To: <20090303200932.DFE5E112631E@beta.macosforge.org> References: <20090303200932.DFE5E112631E@beta.macosforge.org> Message-ID: <20090303212019.GD809@ninagal.withay.com> On Tue, Mar 03, 2009 at 12:09:32PM -0800, snc at macports.org said: > Revision: 47690 > http://trac.macports.org/changeset/47690 > Author: snc at macports.org > Date: 2009-03-03 12:09:31 -0800 (Tue, 03 Mar 2009) > Log Message: > ----------- > fixed worksrcpath/worksrcdir, removed default destroot.dir > > Modified Paths: > -------------- > trunk/dports/www/edbrowse/Portfile > > Modified: trunk/dports/www/edbrowse/Portfile > =================================================================== > --- trunk/dports/www/edbrowse/Portfile 2009-03-03 20:04:14 UTC (rev 47689) > +++ trunk/dports/www/edbrowse/Portfile 2009-03-03 20:09:31 UTC (rev 47690) > @@ -36,7 +36,7 @@ > sha1 fe9e27f9708731899803539f6e7272335faed791 \ > rmd160 01a0be54e33b17bc2a018cfac53c2037a39ab67f > > -set worksrcpath ${worksrcpath}/src > +set worksrcdir ${distname}/src Note that you should never use set on Portfile keywords like worksrcdir, so that should just be worksrcdir ${distname}/src More happens when you use this than just set. Using set for your own newly-created variables is fine, however. Bryan [...] From brad at pixilla.com Tue Mar 3 16:22:12 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 3 Mar 2009 16:22:12 -0800 Subject: perl5.8 fixup Message-ID: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> Situation: I removed macports and reinstalled using the macports wiki recommended methods. I installed perl5.8 and only perl5.8 using all variants. I looked for and found a p5 that thought would not activate without using -f. Seeing as threads along these lines are current I'm going to assume the readers of this message know something about what I'm talking about. Profession: I believe there is a problem with some port p5 modules that conflict with perl5.8 installed modules. Acknowledgments: I don't beleive I'm qualified to offer a solution for the p5 conflicts with perl5.8. Problems: Without the user adding another env var it appears the port perl5.8 modules may not be found. Some port p5 modules seem to collide with port pelr5.8 installed modules. Goal: Build consensus that there is a problem with port perl5.8 base modules not being available without adding another env var. Build consensus that some port p5 modules collide with port perl5.8 base modules. Move toward a solution. My comments: Listening to Vincent Lef?vre, who must know more then me about perl, I added PERL5LIB to my env and I think this is good way to go. I am going to suggest we add a port "macports-env" for setting macports env shell vars that are necessary for port and other software to run. If a port installs files that should be in env PATH then the Portfile could have a var like "macports-path /opt/local/bin/somepath" and this path would be added to the macports-env config file at /opt/local/etc/ macports/env.conf. I think some kind of a structure like ini might be nice for this file so items can be removed when a port is deactivated. Ok, that's my idea for env. Now for the perl5.8 p5 collisions. I have written three short scripts to try to find where the problems are. They are not pretty and probably not all that useful. I am going to add them here so people smarter then me can comment. Not being that familiar with perl and it's modules I will need to spend some time trying to match port perl5.8 module names with port p5 module names. Maybe some others can try these scripts and notice some obvious p5 ports that are not needed. I think some were added because without a proper PERL5LIB env other ports that were being submitted wouldn't run. If I'm way off on my presumptions I'll probably just give in to -f but if I'm not and others are interested in fixing this I want to help. BlackBook: root# cat *.sh #!/bin/sh # file name: porl5.8_installed_modules.sh # purpose: remove port p5 modules that are installed as part of perl5.8 base startdir=`pwd` p5dir=/opt/local/lib/perl5/5.8.9 cd $p5dir for p5_perl in $( ls *.pm | sed 's|.pm||g' ); do echo "${p5_perl}" if [ -d $p5_perl ]; then cd $p5_perl for p5_perl_file in $( ls *.pm | sed 's|.pm||g' ); do echo "${p5_perl},${p5_perl_file}" done cd $p5dir fi done cd $startdir # file name: porl5.8_installed_modules.sh #!/bin/sh # file name: port_p5_module_deps.sh # purpose: remove port p5 modules that are installed as part of perl5.8 base for p5_ports in $( ls /opt/local/var/macports/sources/ rsync.macports.org/release/ports/perl ); do for p5_deps in $( port deps $p5_ports | tail +2 ); do echo "${p5_ports},${p5_deps}" done done # file name: port_p5_module_deps.sh #!/bin/sh # file name: port_p5_modules.sh # purpose: remove port p5 modules that are installed as part of perl5.8 base startdir=`pwd` p5dir=/opt/local/var/macports/sources/rsync.macports.org/release/ports/ perl cd $p5dir for p5_perl in $( ls | sed 's|p5-||g' | sed 's|-|,|g' ); do echo "${p5_perl}" done cd $startdir # file name: port_p5_modules.sh BlackBook: root# From jmr at macports.org Tue Mar 3 20:20:58 2009 From: jmr at macports.org (Joshua Root) Date: Wed, 04 Mar 2009 15:20:58 +1100 Subject: build.dir/destroot.dir quirkiness In-Reply-To: References: <477233E1-B64B-4C5E-BBB7-7A8B974DD090@lavergne.gotdns.org> Message-ID: <49AE01AA.1000506@macports.org> Jeremy Lavergne wrote: >> While the Guide says these default to ${worksrcpath} > > I am sooo lying. Please ignore me (more than usual)! It's actually true, even if the guide doesn't say it. :-) - Josh From brad at pixilla.com Tue Mar 3 20:21:10 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 3 Mar 2009 20:21:10 -0800 Subject: perl5.8 fixup In-Reply-To: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> Message-ID: On Mar 3, 2009, at 4:22 PM, Bradley Giesbrecht wrote: > Situation: I removed macports and reinstalled using the macports > wiki recommended methods. > I installed perl5.8 and only perl5.8 using all variants. > I looked for and found a p5 that thought would not activate without > using -f. > Seeing as threads along these lines are current I'm going to assume > the readers of this message know something about what I'm talking > about. > > Profession: I believe there is a problem with some port p5 modules > that conflict with perl5.8 installed modules. > > Acknowledgments: I don't beleive I'm qualified to offer a solution > for the p5 conflicts with perl5.8. > > Problems: Without the user adding another env var it appears the > port perl5.8 modules may not be found. Some port p5 modules seem to > collide with port pelr5.8 installed modules. > > Goal: Build consensus that there is a problem with port perl5.8 base > modules not being available without adding another env var. Build > consensus that some port p5 modules collide with port perl5.8 base > modules. Move toward a solution. > > My comments: > Listening to Vincent Lef?vre, who must know more then me about perl, > I added PERL5LIB to my env and I think this is good way to go. > > I am going to suggest we add a port "macports-env" for setting > macports env shell vars that are necessary for port and other > software to run. > If a port installs files that should be in env PATH then the > Portfile could have a var like "macports-path /opt/local/bin/ > somepath" and this path would be added to the macports-env config > file at /opt/local/etc/macports/env.conf. I think some kind of a > structure like ini might be nice for this file so items can be > removed when a port is deactivated. > > Ok, that's my idea for env. > > Now for the perl5.8 p5 collisions. I have written three short > scripts to try to find where the problems are. They are not pretty > and probably not all that useful. I am going to add them here so > people smarter then me can comment. Not being that familiar with > perl and it's modules I will need to spend some time trying to match > port perl5.8 module names with port p5 module names. Maybe some > others can try these scripts and notice some obvious p5 ports that > are not needed. I think some were added because without a proper > PERL5LIB env other ports that were being submitted wouldn't run. > > If I'm way off on my presumptions I'll probably just give in to -f > but if I'm not and others are interested in fixing this I want to > help. > > BlackBook: root# cat *.sh > #!/bin/sh > # file name: porl5.8_installed_modules.sh > # purpose: remove port p5 modules that are installed as part of > perl5.8 base > > startdir=`pwd` > p5dir=/opt/local/lib/perl5/5.8.9 > > cd $p5dir > > for p5_perl in $( ls *.pm | sed 's|.pm||g' ); do > echo "${p5_perl}" > if [ -d $p5_perl ]; then > cd $p5_perl > for p5_perl_file in $( ls *.pm | sed 's|.pm||g' ); do > echo "${p5_perl},${p5_perl_file}" > done > cd $p5dir > fi > done > > cd $startdir > > # file name: porl5.8_installed_modules.sh > > #!/bin/sh > # file name: port_p5_module_deps.sh > # purpose: remove port p5 modules that are installed as part of > perl5.8 base > > for p5_ports in $( ls /opt/local/var/macports/sources/ > rsync.macports.org/release/ports/perl ); do > for p5_deps in $( port deps $p5_ports | tail +2 ); do > echo "${p5_ports},${p5_deps}" > done > done > > # file name: port_p5_module_deps.sh > > #!/bin/sh > # file name: port_p5_modules.sh > # purpose: remove port p5 modules that are installed as part of > perl5.8 base > > startdir=`pwd` > p5dir=/opt/local/var/macports/sources/rsync.macports.org/release/ > ports/perl > > cd $p5dir > > for p5_perl in $( ls | sed 's|p5-||g' | sed 's|-|,|g' ); do > echo "${p5_perl}" > done > > cd $startdir > > # file name: port_p5_modules.sh These p5 ports appear to be perl5.8 base modules as well. There may be more, this is just a first stab. port info p5-cgi port info p5-digest port info p5-next port info p5-test-harness port info p5-test-simple port install p5-cgi port install p5-digest port install p5-next port install p5-test-harness port install p5-test-simple port uninstall p5-cgi port uninstall p5-digest port uninstall p5-next port uninstall p5-test-harness port uninstall p5-test-simple These ports appear to depend on the above ports. p5-calendar-simple p5-curses-ui p5-dbix-class p5-gearman-client-async p5-html-scrubber p5-log-dispatch p5-mac-errors p5-math-bigint p5-moose p5-net p5-return-value p5-test-exception p5-test-longstring p5-test-memory-cycle p5-test-object p5-test-pod p5-test-pod-coverage p5-test-www-mechanize p5-text-wikiformat //Brad From ryandesign at macports.org Wed Mar 4 00:41:43 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 4 Mar 2009 02:41:43 -0600 Subject: [47678] trunk/dports/science/hdf5-18 In-Reply-To: <20090303172849.7E3B31122DAA@beta.macosforge.org> References: <20090303172849.7E3B31122DAA@beta.macosforge.org> Message-ID: On Mar 3, 2009, at 11:28, mmoll at macports.org wrote: > Revision: 47678 > http://trac.macports.org/changeset/47678 > Author: mmoll at macports.org > Date: 2009-03-03 09:28:49 -0800 (Tue, 03 Mar 2009) > Log Message: > ----------- > build hdf5-18 with dynamic libs instead of static libs Doesn't this change the files that get installed by the port? If so, the revision must be increased. > Modified: trunk/dports/science/hdf5-18/Portfile > =================================================================== > --- trunk/dports/science/hdf5-18/Portfile 2009-03-03 17:23:50 UTC > (rev 47677) > +++ trunk/dports/science/hdf5-18/Portfile 2009-03-03 17:28:49 UTC > (rev 47678) > @@ -20,12 +20,13 @@ > distname ${realname}-${version} > extract.suffix .tar.gz > depends_lib port:zlib port:szip port:openmpi > +patchfiles patch-config-apple.diff > > use_parallel_build yes > > configure.args --with-zlib=yes --with-szlib=yes --enable- > filters=all \ > --enable-production --enable-parallel -- > disable-fortran \ > - --disable-cxx > + --disable-cxx --enable-shared --disable-static > configure.cc ${prefix}/bin/openmpicc > configure.cxx ${prefix}/bin/openmpicxx > configure.fc ${prefix}/bin/openmpif77 From ryandesign at macports.org Wed Mar 4 00:46:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 4 Mar 2009 02:46:23 -0600 Subject: [47706] trunk/base In-Reply-To: <20090304044346.E5737112C554@beta.macosforge.org> References: <20090304044346.E5737112C554@beta.macosforge.org> Message-ID: On Mar 3, 2009, at 22:43, toby at macports.org wrote: > use sw_vers -productVersion (breaks jaguar compatibility) Please change this back to the way it was. I deliberately used a call that would work on all versions of Mac OS X that have ever existed so that users who attempt an install on an ancient Mac OS X at least get a sensible error message telling them their Mac OS X is too old, instead of seeing an error that sw_vers is being used incorrectly. Please see r37552. From toby at macports.org Wed Mar 4 06:30:58 2009 From: toby at macports.org (Toby Peterson) Date: Wed, 4 Mar 2009 06:30:58 -0800 Subject: [47706] trunk/base In-Reply-To: References: <20090304044346.E5737112C554@beta.macosforge.org> Message-ID: <74c219d30903040630s418e23evb302a133b183a50d@mail.gmail.com> On Wed, Mar 4, 2009 at 12:46 AM, Ryan Schmidt wrote: > > On Mar 3, 2009, at 22:43, toby at macports.org wrote: > >> use sw_vers -productVersion (breaks jaguar compatibility) > > Please change this back to the way it was. I deliberately used a call that > would work on all versions of Mac OS X that have ever existed so that users > who attempt an install on an ancient Mac OS X at least get a sensible error > message telling them their Mac OS X is too old, instead of seeing an error > that sw_vers is being used incorrectly. Please see r37552. If people are still using ridiculously old releases of Mac OS X, I think they *know* that. Works on Panther, which is already unsupported as it is. - Toby From mmoll at macports.org Wed Mar 4 06:16:48 2009 From: mmoll at macports.org (Mark Moll) Date: Wed, 4 Mar 2009 08:16:48 -0600 Subject: [47678] trunk/dports/science/hdf5-18 In-Reply-To: References: <20090303172849.7E3B31122DAA@beta.macosforge.org> Message-ID: <8F73BF90-7D4E-4B67-BAEF-DDD3010E0C9C@macports.org> On Mar 4, 2009, at 2:41 AM, Ryan Schmidt wrote: > > On Mar 3, 2009, at 11:28, mmoll at macports.org wrote: > >> Revision: 47678 >> http://trac.macports.org/changeset/47678 >> Author: mmoll at macports.org >> Date: 2009-03-03 09:28:49 -0800 (Tue, 03 Mar 2009) >> Log Message: >> ----------- >> build hdf5-18 with dynamic libs instead of static libs > > Doesn't this change the files that get installed by the port? If so, > the revision must be increased. Oops, yes. Fixed now. > > >> Modified: trunk/dports/science/hdf5-18/Portfile >> =================================================================== >> --- trunk/dports/science/hdf5-18/Portfile 2009-03-03 17:23:50 UTC >> (rev 47677) >> +++ trunk/dports/science/hdf5-18/Portfile 2009-03-03 17:28:49 UTC >> (rev 47678) >> @@ -20,12 +20,13 @@ >> distname ${realname}-${version} >> extract.suffix .tar.gz >> depends_lib port:zlib port:szip port:openmpi >> +patchfiles patch-config-apple.diff >> >> use_parallel_build yes >> >> configure.args --with-zlib=yes --with-szlib=yes --enable- >> filters=all \ >> --enable-production --enable-parallel --disable- >> fortran \ >> - --disable-cxx >> + --disable-cxx --enable-shared --disable-static >> configure.cc ${prefix}/bin/openmpicc >> configure.cxx ${prefix}/bin/openmpicxx >> configure.fc ${prefix}/bin/openmpif77 > -- Mark From mmoll at macports.org Wed Mar 4 06:16:48 2009 From: mmoll at macports.org (Mark Moll) Date: Wed, 4 Mar 2009 08:16:48 -0600 Subject: [47678] trunk/dports/science/hdf5-18 In-Reply-To: References: <20090303172849.7E3B31122DAA@beta.macosforge.org> Message-ID: <8F73BF90-7D4E-4B67-BAEF-DDD3010E0C9C@macports.org> On Mar 4, 2009, at 2:41 AM, Ryan Schmidt wrote: > > On Mar 3, 2009, at 11:28, mmoll at macports.org wrote: > >> Revision: 47678 >> http://trac.macports.org/changeset/47678 >> Author: mmoll at macports.org >> Date: 2009-03-03 09:28:49 -0800 (Tue, 03 Mar 2009) >> Log Message: >> ----------- >> build hdf5-18 with dynamic libs instead of static libs > > Doesn't this change the files that get installed by the port? If so, > the revision must be increased. Oops, yes. Fixed now. > > >> Modified: trunk/dports/science/hdf5-18/Portfile >> =================================================================== >> --- trunk/dports/science/hdf5-18/Portfile 2009-03-03 17:23:50 UTC >> (rev 47677) >> +++ trunk/dports/science/hdf5-18/Portfile 2009-03-03 17:28:49 UTC >> (rev 47678) >> @@ -20,12 +20,13 @@ >> distname ${realname}-${version} >> extract.suffix .tar.gz >> depends_lib port:zlib port:szip port:openmpi >> +patchfiles patch-config-apple.diff >> >> use_parallel_build yes >> >> configure.args --with-zlib=yes --with-szlib=yes --enable- >> filters=all \ >> --enable-production --enable-parallel --disable- >> fortran \ >> - --disable-cxx >> + --disable-cxx --enable-shared --disable-static >> configure.cc ${prefix}/bin/openmpicc >> configure.cxx ${prefix}/bin/openmpicxx >> configure.fc ${prefix}/bin/openmpif77 > -- Mark From jeremy at lavergne.gotdns.org Wed Mar 4 06:58:01 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 4 Mar 2009 09:58:01 -0500 Subject: building in parallel Message-ID: <32018B7E-0C40-4729-89C7-5B02555034B9@lavergne.gotdns.org> What's the policy for updating ports that build in parallel to use parallel_build yes? Should tickets be made for ones that are maintained or just slip that change in (given that you actually can build them in parallel)? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jmr at macports.org Wed Mar 4 07:19:28 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 05 Mar 2009 02:19:28 +1100 Subject: building in parallel In-Reply-To: <32018B7E-0C40-4729-89C7-5B02555034B9@lavergne.gotdns.org> References: <32018B7E-0C40-4729-89C7-5B02555034B9@lavergne.gotdns.org> Message-ID: <49AE9C00.5020007@macports.org> Jeremy Lavergne wrote: > What's the policy for updating ports that build in parallel to use > parallel_build yes? > > Should tickets be made for ones that are maintained or just slip that > change in (given that you actually can build them in parallel)? Go ahead if it's nomaintainer or openmaintainer, otherwise ask the maintainer's permission (not necessarily via a ticket). However, be aware that problems with parallel build are race conditions by their very nature, and thus don't show up on every configuration or even in every run on affected configurations. - Josh From ryandesign at macports.org Thu Mar 5 01:18:16 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 5 Mar 2009 03:18:16 -0600 Subject: [47752] trunk/dports/python/py26-macholib/Portfile In-Reply-To: <20090305085456.CE3C9114134B@beta.macosforge.org> References: <20090305085456.CE3C9114134B@beta.macosforge.org> Message-ID: <82A041F5-90BD-4134-94E6-46F0BCC8EAB4@macports.org> On Mar 5, 2009, at 02:54, phw at macports.org wrote: > Revision: 47752 > http://trac.macports.org/changeset/47752 > Author: phw at macports.org > Date: 2009-03-05 00:54:53 -0800 (Thu, 05 Mar 2009) > Log Message: > ----------- > Updated to new version, elseway py2app does not work on 10.5 any more > > Modified Paths: > -------------- > trunk/dports/python/py26-macholib/Portfile > > Modified: trunk/dports/python/py26-macholib/Portfile > =================================================================== > --- trunk/dports/python/py26-macholib/Portfile 2009-03-05 04:54:32 > UTC (rev 47751) > +++ trunk/dports/python/py26-macholib/Portfile 2009-03-05 08:54:53 > UTC (rev 47752) > @@ -5,7 +5,7 @@ > PortGroup python26 1.0 > > name py26-macholib > -version 1.1 > +version 1.2.1 > categories-append devel > maintainers jmr openmaintainer > description Mach-O header analysis and editing > @@ -19,6 +19,10 @@ > > platforms darwin > > +fetch.type svn > +svn.url http://svn.pythonmac.org/macholib/macholib/trunk/ > +worksrcdir trunk > + > homepage http://undefined.org/python/#macholib > master_sites http://pypi.python.org/packages/source/m/macholib/ > distname macholib-${version} This change is bad because a port must never pull from a Subversion trunk. Doing so means that users installing the port at different times get different versions of the software, as upstream continues their development. Please use a distfile if possible, as the port used to do before your change. If that's not possible and accessing Subversion is the only option, then you should use a tag URL if possible. I see upstream has not created a tag for 1.2.1. They don't have a tag for 1.2 either. 1.2 seems to be the version currently being developed on trunk. So I question your choice of version number in this update. Without a tag, you must at least pin the checkout to a particular revision. In this case, was r24 the change you were interested in? Then use "svn.tag 24". Or perhaps a better option would be to leave the port at version 1.1 and just apply the minimum patches necessary to make it work properly. From jmr at macports.org Thu Mar 5 04:09:55 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 05 Mar 2009 23:09:55 +1100 Subject: [47752] trunk/dports/python/py26-macholib/Portfile In-Reply-To: <82A041F5-90BD-4134-94E6-46F0BCC8EAB4@macports.org> References: <20090305085456.CE3C9114134B@beta.macosforge.org> <82A041F5-90BD-4134-94E6-46F0BCC8EAB4@macports.org> Message-ID: <49AFC113.7090308@macports.org> Ryan Schmidt wrote: > > On Mar 5, 2009, at 02:54, phw at macports.org wrote: > >> Revision: 47752 >> http://trac.macports.org/changeset/47752 >> Author: phw at macports.org >> Date: 2009-03-05 00:54:53 -0800 (Thu, 05 Mar 2009) >> Log Message: >> ----------- >> Updated to new version, elseway py2app does not work on 10.5 any more >> >> Modified Paths: >> -------------- >> trunk/dports/python/py26-macholib/Portfile >> >> Modified: trunk/dports/python/py26-macholib/Portfile >> =================================================================== >> --- trunk/dports/python/py26-macholib/Portfile 2009-03-05 04:54:32 >> UTC (rev 47751) >> +++ trunk/dports/python/py26-macholib/Portfile 2009-03-05 08:54:53 >> UTC (rev 47752) >> @@ -5,7 +5,7 @@ >> PortGroup python26 1.0 >> >> name py26-macholib >> -version 1.1 >> +version 1.2.1 >> categories-append devel >> maintainers jmr openmaintainer >> description Mach-O header analysis and editing >> @@ -19,6 +19,10 @@ >> >> platforms darwin >> >> +fetch.type svn >> +svn.url http://svn.pythonmac.org/macholib/macholib/trunk/ >> +worksrcdir trunk >> + >> homepage http://undefined.org/python/#macholib >> master_sites http://pypi.python.org/packages/source/m/macholib/ >> distname macholib-${version} > > This change is bad because a port must never pull from a Subversion > trunk. Doing so means that users installing the port at different times > get different versions of the software, as upstream continues their > development. Please use a distfile if possible, as the port used to do > before your change. If that's not possible and accessing Subversion is > the only option, then you should use a tag URL if possible. I see > upstream has not created a tag for 1.2.1. They don't have a tag for 1.2 > either. 1.2 seems to be the version currently being developed on trunk. > So I question your choice of version number in this update. Without a > tag, you must at least pin the checkout to a particular revision. In > this case, was r24 the change you were interested in? Then use "svn.tag > 24". Or perhaps a better option would be to leave the port at version > 1.1 and just apply the minimum patches necessary to make it work properly. I'd also appreciate being asked before you make large changes like this; openmaintainer does not mean carte blanche. There is a py25-macholib-devel port which is currently at version 1.2. Making a py26 version of this and having py2app depend on it seems like a better idea. Does py26-py2app need macholib 1.2, or just py26-py2app-devel? - Josh From jkh at apple.com Thu Mar 5 11:33:21 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Thu, 5 Mar 2009 11:33:21 -0800 Subject: [47752] trunk/dports/python/py26-macholib/Portfile In-Reply-To: <82A041F5-90BD-4134-94E6-46F0BCC8EAB4@macports.org> References: <20090305085456.CE3C9114134B@beta.macosforge.org> <82A041F5-90BD-4134-94E6-46F0BCC8EAB4@macports.org> Message-ID: On Mar 5, 2009, at 1:18 AM, Ryan Schmidt wrote: > This change is bad because a port must never pull from a Subversion > trunk. Doing so means that users installing the port at different > times get different versions of the software, as upstream continues > their development. Please use a distfile if possible, as the port > used to do before your change. If that's not possible and accessing > Subversion is the only option, then you should use a tag URL if > possible. I see upstream has not created a tag for 1.2.1. They don't > have a tag for 1.2 either. 1.2 seems to be the version currently > being developed on trunk. So I question your choice of version > number in this update. Without a tag, you must at least pin the > checkout to a particular revision. In this case, was r24 the change > you were interested in? Then use "svn.tag 24". Or perhaps a better > option would be to leave the port at version 1.1 and just apply the > minimum patches necessary to make it work properly. I believe Subversion also lets you check out by date. Therefore, if you (the portfile author) has confirmed that everything is just peachy at 3:02PM, March 3rd 2009, then just checkout with --revision set to that date. You don't have to go looking for a specific tag. - Jordan From opendarwin.org at darkart.com Thu Mar 5 13:43:57 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Thu, 5 Mar 2009 21:43:57 +0000 Subject: perl5.8 fixup In-Reply-To: References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> Message-ID: <20090305214357.GP27410@darkart.com> On Tue, Mar 03, 2009 at 08:21:10PM -0800, Bradley Giesbrecht wrote: > On Mar 3, 2009, at 4:22 PM, Bradley Giesbrecht wrote: > > >Situation: I removed macports and reinstalled using the macports > >wiki recommended methods. > >I installed perl5.8 and only perl5.8 using all variants. > >I looked for and found a p5 that thought would not activate without > >using -f. > >Seeing as threads along these lines are current I'm going to assume > >the readers of this message know something about what I'm talking > >about. > > > >Profession: I believe there is a problem with some port p5 modules > >that conflict with perl5.8 installed modules. > > > >Acknowledgments: I don't beleive I'm qualified to offer a solution > >for the p5 conflicts with perl5.8. > > > >Problems: Without the user adding another env var it appears the > >port perl5.8 modules may not be found. Some port p5 modules seem to > >collide with port pelr5.8 installed modules. > > > >Goal: Build consensus that there is a problem with port perl5.8 base > >modules not being available without adding another env var. Build > >consensus that some port p5 modules collide with port perl5.8 base > >modules. Move toward a solution. > > [snip] I think removing perl module ports that *currently* conflict with and match modules installed by the perl5 port is a bad idea. In particular, until perl5.8 @5.8.9, there were several perl modules installed by perl5.8 (@5.8.8 here, File::Temp for example) that were too old for some other modules and/or perl-based code/ports. Thus a newer version of the module needed to be installed in order for the higher-level ports to function. I fully expect this problem will occur again, and we need to be able to solve it. One of the ways is to invert the @INC tree (ala FreeBSD ports) so that macports installed perl modules (from p5-*) are found before the base perl modules (from the perl5.x port), thus the ports don't have to be set to overwrite the installed perl modules. The other problem is what to do with the man pages. This is a fairly recent problem (appeared around the time perl5.8 went to perl 5.8.9). I haven't come up with a satisfactory solution for this yet, the primary problem being that when a user types, for example, 'man CGI', how do we ensure that they get the "right" CGI man page? How do we ensure they get a mac-ports installed man page when they have perl5.8 installed, but not the p5-cgi port? And if they have both perl5.8 and p5-cgi, which man page should they get when they type 'man CGI'? Overall I agree there is a problem with the way that perl (at least perl5.8) and modules (p5-*) currently interact, and we need a good (great? sufficient?) solution for the problem. -eric From mcalhoun at macports.org Thu Mar 5 17:53:39 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Fri, 6 Mar 2009 01:53:39 +0000 (UTC) Subject: perl5.8 fixup References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> Message-ID: Eric Hall writes: > > I think removing perl module ports that *currently* conflict > with and match modules installed by the perl5 port is a bad idea. > In particular, until perl5.8 @5.8.9, there were several perl modules > installed by perl5.8 (@5.8.8 here, File::Temp for example) that were > too old for some other modules and/or perl-based code/ports. Thus > a newer version of the module needed to be installed in order for > the higher-level ports to function. I fully expect this problem will > occur again, and we need to be able to solve it. > > One of the ways is to invert the @INC tree (ala FreeBSD > ports) so that macports installed perl modules (from p5-*) are found > before the base perl modules (from the perl5.x port), thus the > ports don't have to be set to overwrite the installed perl modules. > > The other problem is what to do with the man pages. This is > a fairly recent problem (appeared around the time perl5.8 went to > perl 5.8.9). I haven't come up with a satisfactory solution for this > yet, the primary problem being that when a user types, for example, > 'man CGI', how do we ensure that they get the "right" CGI man page? > How do we ensure they get a mac-ports installed man page when they have > perl5.8 installed, but not the p5-cgi port? And if they have both > perl5.8 and p5-cgi, which man page should they get when they type > 'man CGI'? > > Overall I agree there is a problem with the way that > perl (at least perl5.8) and modules (p5-*) currently interact, and > we need a good (great? sufficient?) solution for the problem. > What about the following: * Do not overwrite any perl modules (no more -f) and have the perl5.8 modules found first (don't invert @INC). * If the module supplied by perl is sufficient, do not add it as a dependency. * If a newer version of the module is needed, patch the port use xxx; -> use lib 'dir_location'; use xxx; @INC = @lib::ORIG_INC; lib prepends dir_location to INC (see http://perldoc.perl.org/lib.html). * Append the version number to the man pages of conflicting p5-* ports so they no longer conflict. They will not be found by default, but neither will the perl modules. This assumes the number of ports which actually need the newer version is relatively small, so there would not be much patching involved. The advantages: - No more -f - Since @INC is not modified, invoking ${prefix}/bin/perl will be the same no matter if a newer p5-* port is installed or not. -Marcus From ryandesign at macports.org Fri Mar 6 08:52:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 6 Mar 2009 10:52:08 -0600 Subject: [47756] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <20090305152453.4F37B1144822@beta.macosforge.org> References: <20090305152453.4F37B1144822@beta.macosforge.org> Message-ID: <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> On Mar 5, 2009, at 09:24, jmr at macports.org wrote: > Revision: 47756 > http://trac.macports.org/changeset/47756 > Author: jmr at macports.org > Date: 2009-03-05 07:24:46 -0800 (Thu, 05 Mar 2009) > Log Message: > ----------- > upgrade: split upgrading dependencies into a separate proc, and use > it to make sure that before new ports are installed during upgrade, > their dependencies are upgraded. Now that's just fantastic! Thanks. From opendarwin.org at darkart.com Fri Mar 6 09:26:45 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Fri, 6 Mar 2009 17:26:45 +0000 Subject: perl5.8 fixup In-Reply-To: References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> Message-ID: <20090306172645.GR27410@darkart.com> On Fri, Mar 06, 2009 at 01:53:39AM +0000, Marcus Calhoun-Lopez wrote: > Eric Hall writes: [snip] > > Overall I agree there is a problem with the way that > > perl (at least perl5.8) and modules (p5-*) currently interact, and > > we need a good (great? sufficient?) solution for the problem. > > > > What about the following: > * Do not overwrite any perl modules (no more -f) > and have the perl5.8 modules found first (don't invert @INC). > * If the module supplied by perl is sufficient, do not add it as a dependency. > * If a newer version of the module is needed, patch the port > use xxx; -> use lib 'dir_location'; > use xxx; > @INC = @lib::ORIG_INC; > lib prepends dir_location to INC (see http://perldoc.perl.org/lib.html). > * Append the version number to the man pages of conflicting p5-* ports > so they no longer conflict. > They will not be found by default, but neither will the perl modules. > > This assumes the number of ports which actually need the newer version > is relatively small, so there would not be much patching involved. > > The advantages: > - No more -f > - Since @INC is not modified, invoking ${prefix}/bin/perl will be the same > no matter if a newer p5-* port is installed or not. > Have you tested the above idea? I think I've seen cases where that will fail, unfortunately its been long enough that I don't remember the exact particulars. The basic problem is: There are scripts and/or modules that require a certain minimum version of module X, but the (initial?) inclusion of the module X is made in some other module, thus patching the one that requires the particular version doesn't have effect, or there was some sort of collision between two versions of the same module. Sorry I don't remember the exact case, we'd have to test it out with both pure-perl modules and xs modules. Ah, another case where that can fail is if module Y requires module X at a particular version. If a calling script already imported module X (at a lower-than-required version), I don't think module Y will re-import the "right" version. Again, we should test to make sure that I've got it right (and/or to see if that's old behavior that has been changed/fixed). So far as appending the version number to the man pages, that seems like a reasonable way to avoid the man page file collision, though as you point out it still results in the man pages not being found. The other option is to do what perl5.10 does, and append the perl version number to the man pages installed by the perl5.8 port and not alter the filenames of the man pages installed by the p5-* ports. If we're going to alter the filenames, I like appending the perl version number as it makes things more consistent, people only have to learn one pattern to get the man pages (vs. finding the version number of every p5-* port that is installed and appending that particular version string to the man page request). -eric From illogical1 at gmail.com Fri Mar 6 13:37:01 2009 From: illogical1 at gmail.com (Orville Bennett) Date: Fri, 6 Mar 2009 16:37:01 -0500 Subject: [47756] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> References: <20090305152453.4F37B1144822@beta.macosforge.org> <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> Message-ID: <914D15A0-48BE-4A21-9402-74F994B4AAE8@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 6, 2009, at 11:52 AM, Ryan Schmidt wrote: > > On Mar 5, 2009, at 09:24, jmr at macports.org wrote: > >> Revision: 47756 >> http://trac.macports.org/changeset/47756 >> Author: jmr at macports.org >> Date: 2009-03-05 07:24:46 -0800 (Thu, 05 Mar 2009) >> Log Message: >> ----------- >> upgrade: split upgrading dependencies into a separate proc, and use >> it to make sure that before new ports are installed during upgrade, >> their dependencies are upgraded. > > Now that's just fantastic! Thanks. I'm a bit more apprehensive about the awesomeness of this. Is there some check which ensures that upgrading the dependency doesn't break the app that's updated? I already know the answer is no and that this is unlikely to happen. For those of us using macports for packaging though, a switch to turn this off would be welcome (please). Preferably in macports.conf "recursive_upgrade true/false" sounds nice :-) > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmxl30ACgkQ2yWVgjgEOKT71QCeIpnXhn2WHAoEIA0Q7AvWhEm7 3MkAnR1jl1euo6b60jmJemJtIXJoeEM7 =qHOB -----END PGP SIGNATURE----- From blb at macports.org Fri Mar 6 13:43:51 2009 From: blb at macports.org (Bryan Blackburn) Date: Fri, 6 Mar 2009 14:43:51 -0700 Subject: [47756] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <914D15A0-48BE-4A21-9402-74F994B4AAE8@gmail.com> References: <20090305152453.4F37B1144822@beta.macosforge.org> <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> <914D15A0-48BE-4A21-9402-74F994B4AAE8@gmail.com> Message-ID: <20090306214351.GE747@ninagal.withay.com> On Fri, Mar 06, 2009 at 04:37:01PM -0500, Orville Bennett said: > On Mar 6, 2009, at 11:52 AM, Ryan Schmidt wrote: >> On Mar 5, 2009, at 09:24, jmr at macports.org wrote: >> >>> Revision: 47756 >>> http://trac.macports.org/changeset/47756 >>> Author: jmr at macports.org >>> Date: 2009-03-05 07:24:46 -0800 (Thu, 05 Mar 2009) >>> Log Message: >>> ----------- >>> upgrade: split upgrading dependencies into a separate proc, and use >>> it to make sure that before new ports are installed during upgrade, >>> their dependencies are upgraded. >> >> Now that's just fantastic! Thanks. > I'm a bit more apprehensive about the awesomeness of this. > Is there some check which ensures that upgrading the dependency doesn't > break the app that's updated? > I already know the answer is no and that this is unlikely to happen. For > those of us using macports for packaging though, a switch to turn this off > would be welcome (please). Preferably in macports.conf > "recursive_upgrade true/false" sounds nice :-) 'man port' mentions -n, which should still work here, otherwise I'd call that a bug. Bryan From illogical1 at gmail.com Fri Mar 6 14:02:53 2009 From: illogical1 at gmail.com (Orville Bennett) Date: Fri, 6 Mar 2009 17:02:53 -0500 Subject: [47756] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <20090306214351.GE747@ninagal.withay.com> References: <20090305152453.4F37B1144822@beta.macosforge.org> <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> <914D15A0-48BE-4A21-9402-74F994B4AAE8@gmail.com> <20090306214351.GE747@ninagal.withay.com> Message-ID: <2FCAB212-412C-4117-83CB-2A2C88761961@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 6, 2009, at 4:43 PM, Bryan Blackburn wrote: > On Fri, Mar 06, 2009 at 04:37:01PM -0500, Orville Bennett said: >> On Mar 6, 2009, at 11:52 AM, Ryan Schmidt wrote: >>> On Mar 5, 2009, at 09:24, jmr at macports.org wrote: >>> >>>> Revision: 47756 >>>> http://trac.macports.org/changeset/47756 >>>> Author: jmr at macports.org >>>> Date: 2009-03-05 07:24:46 -0800 (Thu, 05 Mar 2009) >>>> Log Message: >>>> ----------- >>>> upgrade: split upgrading dependencies into a separate proc, and use >>>> it to make sure that before new ports are installed during upgrade, >>>> their dependencies are upgraded. >>> >>> Now that's just fantastic! Thanks. >> I'm a bit more apprehensive about the awesomeness of this. >> Is there some check which ensures that upgrading the dependency >> doesn't >> break the app that's updated? >> I already know the answer is no and that this is unlikely to >> happen. For >> those of us using macports for packaging though, a switch to turn >> this off >> would be welcome (please). Preferably in macports.conf >> "recursive_upgrade true/false" sounds nice :-) > > 'man port' mentions -n, which should still work here, otherwise I'd > call > that a bug. Thanks. This is much better than nothing, but is there some way to set it so that I don't need to remember every time I upgrade? alias port="port -n" is not the answer :-) > > Bryan > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmxnY0ACgkQ2yWVgjgEOKQnzACfRnXUzLhpkNYwvnOPTmtwJl7Q dZcAmwdNPzyA+4YvXa792V/OtF27RoHL =LzsW -----END PGP SIGNATURE----- From jmr at macports.org Fri Mar 6 15:44:52 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 07 Mar 2009 10:44:52 +1100 Subject: [47756] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> References: <20090305152453.4F37B1144822@beta.macosforge.org> <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> Message-ID: <49B1B574.3030002@macports.org> Ryan Schmidt wrote: > > On Mar 5, 2009, at 09:24, jmr at macports.org wrote: > >> Revision: 47756 >> http://trac.macports.org/changeset/47756 >> Author: jmr at macports.org >> Date: 2009-03-05 07:24:46 -0800 (Thu, 05 Mar 2009) >> Log Message: >> ----------- >> upgrade: split upgrading dependencies into a separate proc, and use it >> to make sure that before new ports are installed during upgrade, their >> dependencies are upgraded. > > Now that's just fantastic! Thanks. This has always been the intended and advertised behaviour, and I think it may have even worked this way in earlier versions, before some rearrangement of the upgrade code. Dependencies have always been upgraded first for existing ports BTW, this only affects new ports that are added during upgrade. - Josh From jeremyhu at macports.org Fri Mar 6 15:27:13 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Fri, 6 Mar 2009 18:27:13 -0500 Subject: [47762] trunk/dports/emulators/nonpareil In-Reply-To: <20090305192101.66859114889A@beta.macosforge.org> References: <20090305192101.66859114889A@beta.macosforge.org> Message-ID: Could we possibly make nonpareil a bit more light weight by adding the files/ stuff to a tarball on the mirrors... there's no need to clutter everyone's disk with these 9M ~/src/macports-trunk $ du -scm dports/emulators/nonpareil/files 9 dports/emulators/nonpareil/files 9 total On Mar 5, 2009, at 14:20, krischik at macports.org wrote: > Revision: 47762 > http://trac.macports.org/changeset/47762 > Author: krischik at macports.org > Date: 2009-03-05 11:20:57 -0800 (Thu, 05 Mar 2009) > Log Message: > ----------- > Add Icons for all emulated calculators. > > Modified Paths: > -------------- > trunk/dports/emulators/nonpareil/Portfile > trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/ > Info.plist > trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/ > Info.plist > trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/ > Info.plist > trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/ > Info.plist > trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/ > Info.plist > trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/ > Info.plist > trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/ > Info.plist > trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/ > Info.plist > trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/ > Info.plist > trunk/dports/emulators/nonpareil/files/HP-41CV.app/Contents/ > Info.plist > trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/ > Info.plist > trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/ > Info.plist > trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/ > Info.plist > > Added Paths: > ----------- > trunk/dports/emulators/nonpareil/files/HP-21.app/ > trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/MacOS/ > HP-21.command > trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/ > Resources/HP-21.icns > trunk/dports/emulators/nonpareil/files/HP-25.app/ > trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/MacOS/ > HP-25.command > trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/ > Resources/HP-25.icns > trunk/dports/emulators/nonpareil/files/HP-32E.app/ > trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/MacOS/ > HP-32E.command > trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/ > Resources/HP-32E.icns > trunk/dports/emulators/nonpareil/files/HP-33C.app/ > trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/MacOS/ > HP-33C.command > trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/ > Resources/HP-33C.icns > trunk/dports/emulators/nonpareil/files/HP-34C.app/ > trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/MacOS/ > HP-34C.command > trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/ > Resources/HP-34C.icns > trunk/dports/emulators/nonpareil/files/HP-35.app/ > trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/MacOS/ > HP-35.command > trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/ > Resources/HP-35.icns > trunk/dports/emulators/nonpareil/files/HP-37E.app/ > trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/MacOS/ > HP-37E.command > trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/ > Resources/HP-37E.icns > trunk/dports/emulators/nonpareil/files/HP-38C.app/ > trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/MacOS/ > HP-38C.command > trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/ > Resources/HP-38C.icns > trunk/dports/emulators/nonpareil/files/HP-38E.app/ > trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/MacOS/ > HP-38E.command > trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/ > Resources/HP-38E.icns > trunk/dports/emulators/nonpareil/files/HP-41CV.app/ > trunk/dports/emulators/nonpareil/files/HP-41CV.app/Contents/MacOS/ > HP-41CV.command > trunk/dports/emulators/nonpareil/files/HP-41CV.app/Contents/ > Resources/HP-41CV.icns > trunk/dports/emulators/nonpareil/files/HP-45.app/ > trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/MacOS/ > HP-45.command > trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/ > Resources/HP-45.icns > trunk/dports/emulators/nonpareil/files/HP-55.app/ > trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/MacOS/ > HP-55.command > trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/ > Resources/HP-55.icns > trunk/dports/emulators/nonpareil/files/HP-80.app/ > trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/MacOS/ > HP-80.command > trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/ > Resources/HP-80.icns > > Removed Paths: > ------------- > trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/ > Resources/HP-41CX.icns > trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/ > Resources/HP-41CX.icns > trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/ > Resources/HP-41CX.icns > trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/ > Resources/HP-41CX.icns > trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/ > Resources/HP-41CX.icns > trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/ > Resources/HP-41CX.icns > trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/ > Resources/HP-41CX.icns > trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/ > Resources/HP-41CX.icns > trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/ > Resources/HP-41CX.icns > trunk/dports/emulators/nonpareil/files/HP-41CV.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-41CV.app/Contents/ > Resources/HP-41CX.icns > trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/ > Resources/HP-41CX.icns > trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/ > Resources/HP-41CX.icns > trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/MacOS/ > HP-41CX.command > trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/ > Resources/HP-41CX.icns > > Property Changed: > ---------------- > trunk/dports/emulators/nonpareil/files/patch-src-util.diff > > Modified: trunk/dports/emulators/nonpareil/Portfile > =================================================================== > --- trunk/dports/emulators/nonpareil/Portfile 2009-03-05 18:52:17 > UTC (rev 47761) > +++ trunk/dports/emulators/nonpareil/Portfile 2009-03-05 19:20:57 > UTC (rev 47762) > @@ -58,6 +58,206 @@ > platform macosx { > post-destroot { > xinstall -m 775 -d ${destroot}${applications_dir} > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-21.app > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-21.app/Contents > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-21.app/Contents/MacOS > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-21.app/Contents/Resources > + > + xinstall -m 644 -W ${filespath} \ > + HP-21.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/Nonpareil/HP-21.app/Contents/ > Info.plist > + xinstall -m 644 -W ${filespath} \ > + HP-21.app/Contents/Resources/HP-21.icns \ > + ${destroot}${applications_dir}/Nonpareil/HP-21.app/Contents/ > Resources/HP-21.icns > + xinstall -m 755 -W ${filespath} \ > + HP-21.app/Contents/MacOS/HP-21.command \ > + ${destroot}${applications_dir}/Nonpareil/HP-21.app/Contents/MacOS/ > HP-21.command > + > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Nonpareil/HP-21.app/Contents/MacOS/ > HP-21.command > + > + xinstall -m 775 -d ${destroot}${applications_dir} > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-25.app > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-25.app/Contents > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-25.app/Contents/MacOS > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-25.app/Contents/Resources > + > + xinstall -m 644 -W ${filespath} \ > + HP-25.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/Nonpareil/HP-25.app/Contents/ > Info.plist > + xinstall -m 644 -W ${filespath} \ > + HP-25.app/Contents/Resources/HP-25.icns \ > + ${destroot}${applications_dir}/Nonpareil/HP-25.app/Contents/ > Resources/HP-25.icns > + xinstall -m 755 -W ${filespath} \ > + HP-25.app/Contents/MacOS/HP-25.command \ > + ${destroot}${applications_dir}/Nonpareil/HP-25.app/Contents/MacOS/ > HP-25.command > + > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Nonpareil/HP-25.app/Contents/MacOS/ > HP-25.command > + > + xinstall -m 775 -d ${destroot}${applications_dir} > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-32E.app > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-32E.app/Contents > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-32E.app/Contents/MacOS > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-32E.app/Contents/Resources > + > + xinstall -m 644 -W ${filespath} \ > + HP-32E.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/Nonpareil/HP-32E.app/Contents/ > Info.plist > + xinstall -m 644 -W ${filespath} \ > + HP-32E.app/Contents/Resources/HP-32E.icns \ > + ${destroot}${applications_dir}/Nonpareil/HP-32E.app/Contents/ > Resources/HP-32E.icns > + xinstall -m 755 -W ${filespath} \ > + HP-32E.app/Contents/MacOS/HP-32E.command \ > + ${destroot}${applications_dir}/Nonpareil/HP-32E.app/Contents/ > MacOS/HP-32E.command > + > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Nonpareil/HP-32E.app/Contents/ > MacOS/HP-32E.command > + > + xinstall -m 775 -d ${destroot}${applications_dir} > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-33C.app > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-33C.app/Contents > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-33C.app/Contents/MacOS > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-33C.app/Contents/Resources > + > + xinstall -m 644 -W ${filespath} \ > + HP-33C.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/Nonpareil/HP-33C.app/Contents/ > Info.plist > + xinstall -m 644 -W ${filespath} \ > + HP-33C.app/Contents/Resources/HP-33C.icns \ > + ${destroot}${applications_dir}/Nonpareil/HP-33C.app/Contents/ > Resources/HP-33C.icns > + xinstall -m 755 -W ${filespath} \ > + HP-33C.app/Contents/MacOS/HP-33C.command \ > + ${destroot}${applications_dir}/Nonpareil/HP-33C.app/Contents/ > MacOS/HP-33C.command > + > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Nonpareil/HP-33C.app/Contents/ > MacOS/HP-33C.command > + > + xinstall -m 775 -d ${destroot}${applications_dir} > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-34C.app > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-34C.app/Contents > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-34C.app/Contents/MacOS > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-34C.app/Contents/Resources > + > + xinstall -m 644 -W ${filespath} \ > + HP-34C.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/Nonpareil/HP-34C.app/Contents/ > Info.plist > + xinstall -m 644 -W ${filespath} \ > + HP-34C.app/Contents/Resources/HP-34C.icns \ > + ${destroot}${applications_dir}/Nonpareil/HP-34C.app/Contents/ > Resources/HP-34C.icns > + xinstall -m 755 -W ${filespath} \ > + HP-34C.app/Contents/MacOS/HP-34C.command \ > + ${destroot}${applications_dir}/Nonpareil/HP-34C.app/Contents/ > MacOS/HP-34C.command > + > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Nonpareil/HP-34C.app/Contents/ > MacOS/HP-34C.command > + > + xinstall -m 775 -d ${destroot}${applications_dir} > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-35.app > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-35.app/Contents > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-35.app/Contents/MacOS > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-35.app/Contents/Resources > + > + xinstall -m 644 -W ${filespath} \ > + HP-35.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/Nonpareil/HP-35.app/Contents/ > Info.plist > + xinstall -m 644 -W ${filespath} \ > + HP-35.app/Contents/Resources/HP-35.icns \ > + ${destroot}${applications_dir}/Nonpareil/HP-35.app/Contents/ > Resources/HP-35.icns > + xinstall -m 755 -W ${filespath} \ > + HP-35.app/Contents/MacOS/HP-35.command \ > + ${destroot}${applications_dir}/Nonpareil/HP-35.app/Contents/MacOS/ > HP-35.command > + > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Nonpareil/HP-35.app/Contents/MacOS/ > HP-35.command > + > + xinstall -m 775 -d ${destroot}${applications_dir} > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-37E.app > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-37E.app/Contents > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-37E.app/Contents/MacOS > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-37E.app/Contents/Resources > + > + xinstall -m 644 -W ${filespath} \ > + HP-37E.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/Nonpareil/HP-37E.app/Contents/ > Info.plist > + xinstall -m 644 -W ${filespath} \ > + HP-37E.app/Contents/Resources/HP-37E.icns \ > + ${destroot}${applications_dir}/Nonpareil/HP-37E.app/Contents/ > Resources/HP-37E.icns > + xinstall -m 755 -W ${filespath} \ > + HP-37E.app/Contents/MacOS/HP-37E.command \ > + ${destroot}${applications_dir}/Nonpareil/HP-37E.app/Contents/ > MacOS/HP-37E.command > + > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Nonpareil/HP-37E.app/Contents/ > MacOS/HP-37E.command > + > + xinstall -m 775 -d ${destroot}${applications_dir} > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-38C.app > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-38C.app/Contents > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-38C.app/Contents/MacOS > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-38C.app/Contents/Resources > + > + xinstall -m 644 -W ${filespath} \ > + HP-38C.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/Nonpareil/HP-38C.app/Contents/ > Info.plist > + xinstall -m 644 -W ${filespath} \ > + HP-38C.app/Contents/Resources/HP-38C.icns \ > + ${destroot}${applications_dir}/Nonpareil/HP-38C.app/Contents/ > Resources/HP-38C.icns > + xinstall -m 755 -W ${filespath} \ > + HP-38C.app/Contents/MacOS/HP-38C.command \ > + ${destroot}${applications_dir}/Nonpareil/HP-38C.app/Contents/ > MacOS/HP-38C.command > + > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Nonpareil/HP-38C.app/Contents/ > MacOS/HP-38C.command > + > + xinstall -m 775 -d ${destroot}${applications_dir} > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-38E.app > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-38E.app/Contents > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-38E.app/Contents/MacOS > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-38E.app/Contents/Resources > + > + xinstall -m 644 -W ${filespath} \ > + HP-38E.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/Nonpareil/HP-38E.app/Contents/ > Info.plist > + xinstall -m 644 -W ${filespath} \ > + HP-38E.app/Contents/Resources/HP-38E.icns \ > + ${destroot}${applications_dir}/Nonpareil/HP-38E.app/Contents/ > Resources/HP-38E.icns > + xinstall -m 755 -W ${filespath} \ > + HP-38E.app/Contents/MacOS/HP-38E.command \ > + ${destroot}${applications_dir}/Nonpareil/HP-38E.app/Contents/ > MacOS/HP-38E.command > + > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Nonpareil/HP-38E.app/Contents/ > MacOS/HP-38E.command > + > + xinstall -m 775 -d ${destroot}${applications_dir} > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-41CV.app > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-41CV.app/Contents > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-41CV.app/Contents/MacOS > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-41CV.app/Contents/Resources > + > + xinstall -m 644 -W ${filespath} \ > + HP-41CV.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/Nonpareil/HP-41CV.app/Contents/ > Info.plist > + xinstall -m 644 -W ${filespath} \ > + HP-41CV.app/Contents/Resources/HP-41CV.icns \ > + ${destroot}${applications_dir}/Nonpareil/HP-41CV.app/Contents/ > Resources/HP-41CV.icns > + xinstall -m 755 -W ${filespath} \ > + HP-41CV.app/Contents/MacOS/HP-41CV.command \ > + ${destroot}${applications_dir}/Nonpareil/HP-41CV.app/Contents/ > MacOS/HP-41CV.command > + > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Nonpareil/HP-41CV.app/Contents/ > MacOS/HP-41CV.command > + > + xinstall -m 775 -d ${destroot}${applications_dir} > xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-41CX.app > xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-41CX.app/Contents > xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-41CX.app/Contents/MacOS > @@ -76,6 +276,66 @@ > reinplace \ > s|@PREFIX@|${prefix}|g \ > ${destroot}${applications_dir}/Nonpareil/HP-41CX.app/Contents/ > MacOS/HP-41CX.command > + > + xinstall -m 775 -d ${destroot}${applications_dir} > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-45.app > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-45.app/Contents > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-45.app/Contents/MacOS > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-45.app/Contents/Resources > + > + xinstall -m 644 -W ${filespath} \ > + HP-45.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/Nonpareil/HP-45.app/Contents/ > Info.plist > + xinstall -m 644 -W ${filespath} \ > + HP-45.app/Contents/Resources/HP-45.icns \ > + ${destroot}${applications_dir}/Nonpareil/HP-45.app/Contents/ > Resources/HP-45.icns > + xinstall -m 755 -W ${filespath} \ > + HP-45.app/Contents/MacOS/HP-45.command \ > + ${destroot}${applications_dir}/Nonpareil/HP-45.app/Contents/MacOS/ > HP-45.command > + > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Nonpareil/HP-45.app/Contents/MacOS/ > HP-45.command > + > + xinstall -m 775 -d ${destroot}${applications_dir} > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-55.app > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-55.app/Contents > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-55.app/Contents/MacOS > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-55.app/Contents/Resources > + > + xinstall -m 644 -W ${filespath} \ > + HP-55.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/Nonpareil/HP-55.app/Contents/ > Info.plist > + xinstall -m 644 -W ${filespath} \ > + HP-55.app/Contents/Resources/HP-55.icns \ > + ${destroot}${applications_dir}/Nonpareil/HP-55.app/Contents/ > Resources/HP-55.icns > + xinstall -m 755 -W ${filespath} \ > + HP-55.app/Contents/MacOS/HP-55.command \ > + ${destroot}${applications_dir}/Nonpareil/HP-55.app/Contents/MacOS/ > HP-55.command > + > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Nonpareil/HP-55.app/Contents/MacOS/ > HP-55.command > + > + xinstall -m 775 -d ${destroot}${applications_dir} > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-80.app > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-80.app/Contents > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-80.app/Contents/MacOS > + xinstall -m 755 -d ${destroot}${applications_dir}/Nonpareil/ > HP-80.app/Contents/Resources > + > + xinstall -m 644 -W ${filespath} \ > + HP-80.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/Nonpareil/HP-80.app/Contents/ > Info.plist > + xinstall -m 644 -W ${filespath} \ > + HP-80.app/Contents/Resources/HP-80.icns \ > + ${destroot}${applications_dir}/Nonpareil/HP-80.app/Contents/ > Resources/HP-80.icns > + xinstall -m 755 -W ${filespath} \ > + HP-80.app/Contents/MacOS/HP-80.command \ > + ${destroot}${applications_dir}/Nonpareil/HP-80.app/Contents/MacOS/ > HP-80.command > + > + reinplace \ > + s|@PREFIX@|${prefix}|g \ > + ${destroot}${applications_dir}/Nonpareil/HP-80.app/Contents/MacOS/ > HP-80.command > } > } > > > > Property changes on: trunk/dports/emulators/nonpareil/files/HP-21.app > ___________________________________________________________________ > Added: svn:mergeinfo > + > > Modified: trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/ > Info.plist > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > Info.plist 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/ > Info.plist 2009-03-05 19:20:57 UTC (rev 47762) > @@ -7,11 +7,11 @@ > CFBundleDevelopmentRegion > English > CFBundleDisplayName > - HP-41CX > + HP-21 > CFBundleExecutable > - HP-41CX.command > + HP-21.command > CFBundleIconFile > - HP-41CX.icns > + HP-21.icns > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > > Copied: trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/ > MacOS/HP-21.command (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/MacOS/HP-41CX.command) > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/MacOS/ > HP-21.command (rev 0) > +++ trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/MacOS/ > HP-21.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -0,0 +1,15 @@ > +#!/bin/zsh > +############################################################## {{{1 > ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}}1 > ########## > + > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/21.kml & > +popd > + > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Deleted: trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/ > MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/MacOS/ > HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -1,13 +0,0 @@ > -#!/bin/zsh > -############################################################## {{{1 > ########## > -# $Author$ > -# $Revision$ > -# $Date$ > -# $HeadURL$ > -############################################################## }}}1 > ########## > - > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > - > -############################################################ {{{1 > ########### > -# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > -# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Copied: trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/ > Resources/HP-21.icns (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/Resources/HP-41CX.icns) > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-21.app/Contents/Resources/HP-21.icns > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > Added: svn:mergeinfo > + > > Deleted: trunk/dports/emulators/nonpareil/files/HP-21.app/Contents/ > Resources/HP-41CX.icns > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/HP-25.app > ___________________________________________________________________ > Added: svn:mergeinfo > + > > Modified: trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/ > Info.plist > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > Info.plist 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/ > Info.plist 2009-03-05 19:20:57 UTC (rev 47762) > @@ -7,11 +7,11 @@ > CFBundleDevelopmentRegion > English > CFBundleDisplayName > - HP-41CX > + HP-25 > CFBundleExecutable > - HP-41CX.command > + HP-25.command > CFBundleIconFile > - HP-41CX.icns > + HP-25.icns > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > > Copied: trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/ > MacOS/HP-25.command (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/MacOS/HP-41CX.command) > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/MacOS/ > HP-25.command (rev 0) > +++ trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/MacOS/ > HP-25.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -0,0 +1,15 @@ > +#!/bin/zsh > +############################################################## {{{1 > ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}}1 > ########## > + > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/25.kml & > +popd > + > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Deleted: trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/ > MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/MacOS/ > HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -1,13 +0,0 @@ > -#!/bin/zsh > -############################################################## {{{1 > ########## > -# $Author$ > -# $Revision$ > -# $Date$ > -# $HeadURL$ > -############################################################## }}}1 > ########## > - > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > - > -############################################################ {{{1 > ########### > -# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > -# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Copied: trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/ > Resources/HP-25.icns (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/Resources/HP-41CX.icns) > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-25.app/Contents/Resources/HP-25.icns > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > Added: svn:mergeinfo > + > > Deleted: trunk/dports/emulators/nonpareil/files/HP-25.app/Contents/ > Resources/HP-41CX.icns > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/HP-32E.app > ___________________________________________________________________ > Added: svn:mergeinfo > + > > Modified: trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/ > Info.plist > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > Info.plist 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/ > Info.plist 2009-03-05 19:20:57 UTC (rev 47762) > @@ -7,11 +7,11 @@ > CFBundleDevelopmentRegion > English > CFBundleDisplayName > - HP-41CX > + HP-32E > CFBundleExecutable > - HP-41CX.command > + HP-32E.command > CFBundleIconFile > - HP-41CX.icns > + HP-32E.icns > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > > Copied: trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/ > MacOS/HP-32E.command (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/MacOS/HP-41CX.command) > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/MacOS/ > HP-32E.command (rev 0) > +++ trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/MacOS/ > HP-32E.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -0,0 +1,15 @@ > +#!/bin/zsh > +############################################################## {{{1 > ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}}1 > ########## > + > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/32e.kml & > +popd > + > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Deleted: trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/ > MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/MacOS/ > HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -1,13 +0,0 @@ > -#!/bin/zsh > -############################################################## {{{1 > ########## > -# $Author$ > -# $Revision$ > -# $Date$ > -# $HeadURL$ > -############################################################## }}}1 > ########## > - > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > - > -############################################################ {{{1 > ########### > -# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > -# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Copied: trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/ > Resources/HP-32E.icns (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/Resources/HP-41CX.icns) > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-32E.app/Contents/Resources/HP-32E.icns > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > Added: svn:mergeinfo > + > > Deleted: trunk/dports/emulators/nonpareil/files/HP-32E.app/Contents/ > Resources/HP-41CX.icns > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/HP-33C.app > ___________________________________________________________________ > Added: svn:mergeinfo > + > > Modified: trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/ > Info.plist > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > Info.plist 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/ > Info.plist 2009-03-05 19:20:57 UTC (rev 47762) > @@ -7,11 +7,11 @@ > CFBundleDevelopmentRegion > English > CFBundleDisplayName > - HP-41CX > + HP-33C > CFBundleExecutable > - HP-41CX.command > + HP-33C.command > CFBundleIconFile > - HP-41CX.icns > + HP-33C.icns > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > > Copied: trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/ > MacOS/HP-33C.command (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/MacOS/HP-41CX.command) > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/MacOS/ > HP-33C.command (rev 0) > +++ trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/MacOS/ > HP-33C.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -0,0 +1,15 @@ > +#!/bin/zsh > +############################################################## {{{1 > ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}}1 > ########## > + > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/33c.kml & > +popd > + > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Deleted: trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/ > MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/MacOS/ > HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -1,13 +0,0 @@ > -#!/bin/zsh > -############################################################## {{{1 > ########## > -# $Author$ > -# $Revision$ > -# $Date$ > -# $HeadURL$ > -############################################################## }}}1 > ########## > - > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > - > -############################################################ {{{1 > ########### > -# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > -# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Copied: trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/ > Resources/HP-33C.icns (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/Resources/HP-41CX.icns) > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-33C.app/Contents/Resources/HP-33C.icns > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > Added: svn:mergeinfo > + > > Deleted: trunk/dports/emulators/nonpareil/files/HP-33C.app/Contents/ > Resources/HP-41CX.icns > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/HP-34C.app > ___________________________________________________________________ > Added: svn:mergeinfo > + > > Modified: trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/ > Info.plist > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > Info.plist 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/ > Info.plist 2009-03-05 19:20:57 UTC (rev 47762) > @@ -7,11 +7,11 @@ > CFBundleDevelopmentRegion > English > CFBundleDisplayName > - HP-41CX > + HP-34C > CFBundleExecutable > - HP-41CX.command > + HP-34C.command > CFBundleIconFile > - HP-41CX.icns > + HP-34C.icns > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > > Copied: trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/ > MacOS/HP-34C.command (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/MacOS/HP-41CX.command) > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/MacOS/ > HP-34C.command (rev 0) > +++ trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/MacOS/ > HP-34C.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -0,0 +1,15 @@ > +#!/bin/zsh > +############################################################## {{{1 > ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}}1 > ########## > + > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/34c.kml & > +popd > + > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Deleted: trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/ > MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/MacOS/ > HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -1,13 +0,0 @@ > -#!/bin/zsh > -############################################################## {{{1 > ########## > -# $Author$ > -# $Revision$ > -# $Date$ > -# $HeadURL$ > -############################################################## }}}1 > ########## > - > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > - > -############################################################ {{{1 > ########### > -# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > -# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Copied: trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/ > Resources/HP-34C.icns (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/Resources/HP-41CX.icns) > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-34C.app/Contents/Resources/HP-34C.icns > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > Added: svn:mergeinfo > + > > Deleted: trunk/dports/emulators/nonpareil/files/HP-34C.app/Contents/ > Resources/HP-41CX.icns > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/HP-35.app > ___________________________________________________________________ > Added: svn:mergeinfo > + > > Modified: trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/ > Info.plist > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > Info.plist 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/ > Info.plist 2009-03-05 19:20:57 UTC (rev 47762) > @@ -7,11 +7,11 @@ > CFBundleDevelopmentRegion > English > CFBundleDisplayName > - HP-41CX > + HP-35 > CFBundleExecutable > - HP-41CX.command > + HP-35.command > CFBundleIconFile > - HP-41CX.icns > + HP-35.icns > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > > Copied: trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/ > MacOS/HP-35.command (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/MacOS/HP-41CX.command) > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/MacOS/ > HP-35.command (rev 0) > +++ trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/MacOS/ > HP-35.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -0,0 +1,15 @@ > +#!/bin/zsh > +############################################################## {{{1 > ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}}1 > ########## > + > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/35.kml & > +popd > + > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Deleted: trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/ > MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/MacOS/ > HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -1,13 +0,0 @@ > -#!/bin/zsh > -############################################################## {{{1 > ########## > -# $Author$ > -# $Revision$ > -# $Date$ > -# $HeadURL$ > -############################################################## }}}1 > ########## > - > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > - > -############################################################ {{{1 > ########### > -# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > -# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Copied: trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/ > Resources/HP-35.icns (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/Resources/HP-41CX.icns) > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-35.app/Contents/Resources/HP-35.icns > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > Added: svn:mergeinfo > + > > Deleted: trunk/dports/emulators/nonpareil/files/HP-35.app/Contents/ > Resources/HP-41CX.icns > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/HP-37E.app > ___________________________________________________________________ > Added: svn:mergeinfo > + > > Modified: trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/ > Info.plist > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > Info.plist 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/ > Info.plist 2009-03-05 19:20:57 UTC (rev 47762) > @@ -7,11 +7,11 @@ > CFBundleDevelopmentRegion > English > CFBundleDisplayName > - HP-41CX > + HP-37E > CFBundleExecutable > - HP-41CX.command > + HP-37E.command > CFBundleIconFile > - HP-41CX.icns > + HP-37E.icns > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > > Copied: trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/ > MacOS/HP-37E.command (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/MacOS/HP-41CX.command) > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/MacOS/ > HP-37E.command (rev 0) > +++ trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/MacOS/ > HP-37E.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -0,0 +1,15 @@ > +#!/bin/zsh > +############################################################## {{{1 > ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}}1 > ########## > + > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/37e.kml & > +popd > + > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Deleted: trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/ > MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/MacOS/ > HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -1,13 +0,0 @@ > -#!/bin/zsh > -############################################################## {{{1 > ########## > -# $Author$ > -# $Revision$ > -# $Date$ > -# $HeadURL$ > -############################################################## }}}1 > ########## > - > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > - > -############################################################ {{{1 > ########### > -# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > -# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Copied: trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/ > Resources/HP-37E.icns (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/Resources/HP-41CX.icns) > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-37E.app/Contents/Resources/HP-37E.icns > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > Added: svn:mergeinfo > + > > Deleted: trunk/dports/emulators/nonpareil/files/HP-37E.app/Contents/ > Resources/HP-41CX.icns > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/HP-38C.app > ___________________________________________________________________ > Added: svn:mergeinfo > + > > Modified: trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/ > Info.plist > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > Info.plist 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/ > Info.plist 2009-03-05 19:20:57 UTC (rev 47762) > @@ -7,11 +7,11 @@ > CFBundleDevelopmentRegion > English > CFBundleDisplayName > - HP-41CX > + HP-38C > CFBundleExecutable > - HP-41CX.command > + HP-38C.command > CFBundleIconFile > - HP-41CX.icns > + HP-38C.icns > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > > Copied: trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/ > MacOS/HP-38C.command (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/MacOS/HP-41CX.command) > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/MacOS/ > HP-38C.command (rev 0) > +++ trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/MacOS/ > HP-38C.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -0,0 +1,15 @@ > +#!/bin/zsh > +############################################################## {{{1 > ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}}1 > ########## > + > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/38c.kml & > +popd > + > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Deleted: trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/ > MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/MacOS/ > HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -1,13 +0,0 @@ > -#!/bin/zsh > -############################################################## {{{1 > ########## > -# $Author$ > -# $Revision$ > -# $Date$ > -# $HeadURL$ > -############################################################## }}}1 > ########## > - > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > - > -############################################################ {{{1 > ########### > -# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > -# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Copied: trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/ > Resources/HP-38C.icns (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/Resources/HP-41CX.icns) > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-38C.app/Contents/Resources/HP-38C.icns > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > Added: svn:mergeinfo > + > > Deleted: trunk/dports/emulators/nonpareil/files/HP-38C.app/Contents/ > Resources/HP-41CX.icns > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/HP-38E.app > ___________________________________________________________________ > Added: svn:mergeinfo > + > > Modified: trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/ > Info.plist > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > Info.plist 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/ > Info.plist 2009-03-05 19:20:57 UTC (rev 47762) > @@ -7,11 +7,11 @@ > CFBundleDevelopmentRegion > English > CFBundleDisplayName > - HP-41CX > + HP-38E > CFBundleExecutable > - HP-41CX.command > + HP-38E.command > CFBundleIconFile > - HP-41CX.icns > + HP-38E.icns > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > > Copied: trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/ > MacOS/HP-38E.command (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/MacOS/HP-41CX.command) > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/MacOS/ > HP-38E.command (rev 0) > +++ trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/MacOS/ > HP-38E.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -0,0 +1,15 @@ > +#!/bin/zsh > +############################################################## {{{1 > ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}}1 > ########## > + > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/38e.kml & > +popd > + > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Deleted: trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/ > MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/MacOS/ > HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -1,13 +0,0 @@ > -#!/bin/zsh > -############################################################## {{{1 > ########## > -# $Author$ > -# $Revision$ > -# $Date$ > -# $HeadURL$ > -############################################################## }}}1 > ########## > - > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > - > -############################################################ {{{1 > ########### > -# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > -# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Copied: trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/ > Resources/HP-38E.icns (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/Resources/HP-41CX.icns) > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-38E.app/Contents/Resources/HP-38E.icns > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > Added: svn:mergeinfo > + > > Deleted: trunk/dports/emulators/nonpareil/files/HP-38E.app/Contents/ > Resources/HP-41CX.icns > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-41CV.app > ___________________________________________________________________ > Added: svn:mergeinfo > + > > Modified: trunk/dports/emulators/nonpareil/files/HP-41CV.app/ > Contents/Info.plist > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > Info.plist 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-41CV.app/Contents/ > Info.plist 2009-03-05 19:20:57 UTC (rev 47762) > @@ -7,11 +7,11 @@ > CFBundleDevelopmentRegion > English > CFBundleDisplayName > - HP-41CX > + HP-41CV > CFBundleExecutable > - HP-41CX.command > + HP-41CV.command > CFBundleIconFile > - HP-41CX.icns > + HP-41CV.icns > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > > Copied: trunk/dports/emulators/nonpareil/files/HP-41CV.app/Contents/ > MacOS/HP-41CV.command (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/MacOS/HP-41CX.command) > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CV.app/Contents/ > MacOS/HP-41CV.command (rev 0) > +++ trunk/dports/emulators/nonpareil/files/HP-41CV.app/Contents/ > MacOS/HP-41CV.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -0,0 +1,15 @@ > +#!/bin/zsh > +############################################################## {{{1 > ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}}1 > ########## > + > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cv.kml & > +popd > + > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Deleted: trunk/dports/emulators/nonpareil/files/HP-41CV.app/Contents/ > MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-41CV.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -1,13 +0,0 @@ > -#!/bin/zsh > -############################################################## {{{1 > ########## > -# $Author$ > -# $Revision$ > -# $Date$ > -# $HeadURL$ > -############################################################## }}}1 > ########## > - > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > - > -############################################################ {{{1 > ########### > -# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > -# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Copied: trunk/dports/emulators/nonpareil/files/HP-41CV.app/Contents/ > Resources/HP-41CV.icns (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/Resources/HP-41CX.icns) > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-41CV.app/Contents/Resources/HP-41CV.icns > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > Added: svn:mergeinfo > + > > Deleted: trunk/dports/emulators/nonpareil/files/HP-41CV.app/Contents/ > Resources/HP-41CX.icns > =================================================================== > (Binary files differ) > > Modified: trunk/dports/emulators/nonpareil/files/HP-41CX.app/ > Contents/MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:52:17 UTC (rev 47761) > +++ trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -6,7 +6,9 @@ > # $HeadURL$ > ############################################################## }}}1 > ########## > > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > +popd > > ############################################################ {{{1 > ########### > # vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > > > Property changes on: trunk/dports/emulators/nonpareil/files/HP-45.app > ___________________________________________________________________ > Added: svn:mergeinfo > + > > Modified: trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/ > Info.plist > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > Info.plist 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/ > Info.plist 2009-03-05 19:20:57 UTC (rev 47762) > @@ -7,11 +7,11 @@ > CFBundleDevelopmentRegion > English > CFBundleDisplayName > - HP-41CX > + HP-45 > CFBundleExecutable > - HP-41CX.command > + HP-45.command > CFBundleIconFile > - HP-41CX.icns > + HP-45.icns > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > > Deleted: trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/ > MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/MacOS/ > HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -1,13 +0,0 @@ > -#!/bin/zsh > -############################################################## {{{1 > ########## > -# $Author$ > -# $Revision$ > -# $Date$ > -# $HeadURL$ > -############################################################## }}}1 > ########## > - > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > - > -############################################################ {{{1 > ########### > -# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > -# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Copied: trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/ > MacOS/HP-45.command (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/MacOS/HP-41CX.command) > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/MacOS/ > HP-45.command (rev 0) > +++ trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/MacOS/ > HP-45.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -0,0 +1,15 @@ > +#!/bin/zsh > +############################################################## {{{1 > ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}}1 > ########## > + > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/45.kml & > +popd > + > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Deleted: trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/ > Resources/HP-41CX.icns > =================================================================== > (Binary files differ) > > Copied: trunk/dports/emulators/nonpareil/files/HP-45.app/Contents/ > Resources/HP-45.icns (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/Resources/HP-41CX.icns) > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-45.app/Contents/Resources/HP-45.icns > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > Added: svn:mergeinfo > + > > > Property changes on: trunk/dports/emulators/nonpareil/files/HP-55.app > ___________________________________________________________________ > Added: svn:mergeinfo > + > > Modified: trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/ > Info.plist > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > Info.plist 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/ > Info.plist 2009-03-05 19:20:57 UTC (rev 47762) > @@ -7,11 +7,11 @@ > CFBundleDevelopmentRegion > English > CFBundleDisplayName > - HP-41CX > + HP-55 > CFBundleExecutable > - HP-41CX.command > + HP-55.command > CFBundleIconFile > - HP-41CX.icns > + HP-55.icns > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > > Deleted: trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/ > MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/MacOS/ > HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -1,13 +0,0 @@ > -#!/bin/zsh > -############################################################## {{{1 > ########## > -# $Author$ > -# $Revision$ > -# $Date$ > -# $HeadURL$ > -############################################################## }}}1 > ########## > - > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > - > -############################################################ {{{1 > ########### > -# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > -# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Copied: trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/ > MacOS/HP-55.command (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/MacOS/HP-41CX.command) > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/MacOS/ > HP-55.command (rev 0) > +++ trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/MacOS/ > HP-55.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -0,0 +1,15 @@ > +#!/bin/zsh > +############################################################## {{{1 > ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}}1 > ########## > + > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/55.kml & > +popd > + > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Deleted: trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/ > Resources/HP-41CX.icns > =================================================================== > (Binary files differ) > > Copied: trunk/dports/emulators/nonpareil/files/HP-55.app/Contents/ > Resources/HP-55.icns (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/Resources/HP-41CX.icns) > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-55.app/Contents/Resources/HP-55.icns > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > Added: svn:mergeinfo > + > > > Property changes on: trunk/dports/emulators/nonpareil/files/HP-80.app > ___________________________________________________________________ > Added: svn:mergeinfo > + > > Modified: trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/ > Info.plist > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > Info.plist 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/ > Info.plist 2009-03-05 19:20:57 UTC (rev 47762) > @@ -7,11 +7,11 @@ > CFBundleDevelopmentRegion > English > CFBundleDisplayName > - HP-41CX > + HP-80 > CFBundleExecutable > - HP-41CX.command > + HP-80.command > CFBundleIconFile > - HP-41CX.icns > + HP-80.icns > CFBundleInfoDictionaryVersion > 6.0 > CFBundleName > > Deleted: trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/ > MacOS/HP-41CX.command > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-41CX.app/Contents/ > MacOS/HP-41CX.command 2009-03-05 18:01:45 UTC (rev 47759) > +++ trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/MacOS/ > HP-41CX.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -1,13 +0,0 @@ > -#!/bin/zsh > -############################################################## {{{1 > ########## > -# $Author$ > -# $Revision$ > -# $Date$ > -# $HeadURL$ > -############################################################## }}}1 > ########## > - > - at PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/41cx.kml & > - > -############################################################ {{{1 > ########### > -# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > -# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Copied: trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/ > MacOS/HP-80.command (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/MacOS/HP-41CX.command) > =================================================================== > --- trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/MacOS/ > HP-80.command (rev 0) > +++ trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/MacOS/ > HP-80.command 2009-03-05 19:20:57 UTC (rev 47762) > @@ -0,0 +1,15 @@ > +#!/bin/zsh > +############################################################## {{{1 > ########## > +# $Author$ > +# $Revision$ > +# $Date$ > +# $HeadURL$ > +############################################################## }}}1 > ########## > + > +pushd @PREFIX@/lib/nonpareil > + @PREFIX@/bin/nonpareil @PREFIX@/lib/nonpareil/80.kml & > +popd > + > +############################################################ {{{1 > ########### > +# vim: set nowrap tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab : > +# vim: set textwidth=0 filetype=zsh foldmethod=marker nospell : > > Deleted: trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/ > Resources/HP-41CX.icns > =================================================================== > (Binary files differ) > > Copied: trunk/dports/emulators/nonpareil/files/HP-80.app/Contents/ > Resources/HP-80.icns (from rev 47759, trunk/dports/emulators/ > nonpareil/files/HP-41CX.app/Contents/Resources/HP-41CX.icns) > =================================================================== > (Binary files differ) > > > Property changes on: trunk/dports/emulators/nonpareil/files/ > HP-80.app/Contents/Resources/HP-80.icns > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > Added: svn:mergeinfo > + > > > Property changes on: trunk/dports/emulators/nonpareil/files/patch- > src-util.diff > ___________________________________________________________________ > Added: svn:mime-type > + text/x-patch > Added: svn:eol-style > + LF > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes From jmr at macports.org Fri Mar 6 15:49:51 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 07 Mar 2009 10:49:51 +1100 Subject: [47756] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <20090306214351.GE747@ninagal.withay.com> References: <20090305152453.4F37B1144822@beta.macosforge.org> <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> <914D15A0-48BE-4A21-9402-74F994B4AAE8@gmail.com> <20090306214351.GE747@ninagal.withay.com> Message-ID: <49B1B69F.90105@macports.org> Bryan Blackburn wrote: > On Fri, Mar 06, 2009 at 04:37:01PM -0500, Orville Bennett said: >> On Mar 6, 2009, at 11:52 AM, Ryan Schmidt wrote: >>> On Mar 5, 2009, at 09:24, jmr at macports.org wrote: >>> >>>> Revision: 47756 >>>> http://trac.macports.org/changeset/47756 >>>> Author: jmr at macports.org >>>> Date: 2009-03-05 07:24:46 -0800 (Thu, 05 Mar 2009) >>>> Log Message: >>>> ----------- >>>> upgrade: split upgrading dependencies into a separate proc, and use >>>> it to make sure that before new ports are installed during upgrade, >>>> their dependencies are upgraded. >>> Now that's just fantastic! Thanks. >> I'm a bit more apprehensive about the awesomeness of this. >> Is there some check which ensures that upgrading the dependency doesn't >> break the app that's updated? >> I already know the answer is no and that this is unlikely to happen. For >> those of us using macports for packaging though, a switch to turn this off >> would be welcome (please). Preferably in macports.conf >> "recursive_upgrade true/false" sounds nice :-) > > 'man port' mentions -n, which should still work here, otherwise I'd call > that a bug. > > Bryan The new code can't be reached if -n used, so there's no need to check for it there. This did make me realise, though, that -R was not being handled correctly in the new code. Fixed now. :-) - Josh From brad at pixilla.com Fri Mar 6 18:22:07 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 6 Mar 2009 18:22:07 -0800 Subject: perl5.8 fixup In-Reply-To: <20090306172645.GR27410@darkart.com> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> Message-ID: <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> On Mar 6, 2009, at 9:26 AM, Eric Hall wrote: > On Fri, Mar 06, 2009 at 01:53:39AM +0000, Marcus Calhoun-Lopez wrote: >> Eric Hall writes: > [snip] > >>> Overall I agree there is a problem with the way that >>> perl (at least perl5.8) and modules (p5-*) currently interact, and >>> we need a good (great? sufficient?) solution for the problem. >>> >> >> What about the following: >> * Do not overwrite any perl modules (no more -f) >> and have the perl5.8 modules found first (don't invert >> @INC). >> * If the module supplied by perl is sufficient, do not add it as >> a dependency. >> * If a newer version of the module is needed, patch the port >> use xxx; -> use lib 'dir_location'; >> use xxx; >> @INC = @lib::ORIG_INC; >> lib prepends dir_location to INC (see http://perldoc.perl.org/lib.html) >> . >> * Append the version number to the man pages of conflicting p5-* >> ports >> so they no longer conflict. >> They will not be found by default, but neither will the perl >> modules. >> >> This assumes the number of ports which actually need the newer >> version >> is relatively small, so there would not be much patching involved. >> >> The advantages: >> - No more -f >> - Since @INC is not modified, invoking ${prefix}/bin/perl will be >> the same >> no matter if a newer p5-* port is installed or not. >> > > Have you tested the above idea? I think I've seen cases > where that will fail, unfortunately its been long enough that I > don't remember the exact particulars. The basic problem is: > There are scripts and/or modules that require a certain > minimum version of module X, but the (initial?) inclusion of the > module X > is made in some other module, thus patching the one that requires > the particular version doesn't have effect, or there was some sort > of collision between two versions of the same module. > Sorry I don't remember the exact case, we'd have to test it > out with both pure-perl modules and xs modules. > > Ah, another case where that can fail is if module Y requires > module X at a particular version. If a calling script already > imported > module X (at a lower-than-required version), I don't think module Y > will re-import the "right" version. Again, we should test to make > sure that I've got it right (and/or to see if that's old behavior > that has been changed/fixed). > > > So far as appending the version number to the man pages, that > seems like a reasonable way to avoid the man page file collision, > though > as you point out it still results in the man pages not being found. > The other option is to do what perl5.10 does, and append the perl > version number to the man pages installed by the perl5.8 port and > not alter the filenames of the man pages installed by the p5-* ports. > If we're going to alter the filenames, I like appending the > perl version number as it makes things more consistent, people only > have > to learn one pattern to get the man pages (vs. finding the version > number of every p5-* port that is installed and appending that > particular > version string to the man page request). How about creating a Portfile for ALL the perl5.8 modules, make them all depends of perl5.8, unregistering them from perl5.8 and registering the module on there own. Then those p5 modules that existed before can replace the ones created from the perl5.8 base modules with a higher revision number. Then a port upgrade installed should work to upgrade all the p5 modules with newer versions that have been added. //Brad From vincent-opdarw at vinc17.org Fri Mar 6 19:45:54 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Sat, 7 Mar 2009 04:45:54 +0100 Subject: p5-image-exiftool Message-ID: <20090307034554.GQ27518@prunille.vinc17.org> There's somthing strange: $ port cat p5-image-exiftool # $Id: Portfile 38454 2008-07-21 13:51:06Z blair at macports.org $ PortSystem 1.0 PortGroup perl5 1.0 perl5.setup Image-ExifTool 7.37 maintainers blair openmaintainer description Perl interface to EXIF metadata long_description ${description} platforms darwin checksums md5 9e214b3eba4ae3f1eadc4370da6cad70 homepage http://www.sno.phy.queensu.ca/~phil/exiftool/ master_sites ${homepage} depends_lib port:p5-digest-md5 \ port:p5-compress-zlib but this port is in graphics/exiftool! This is really misleading. Is this a bug? -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From jeremy at lavergne.gotdns.org Fri Mar 6 19:48:46 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 6 Mar 2009 22:48:46 -0500 Subject: p5-image-exiftool In-Reply-To: <20090307034554.GQ27518@prunille.vinc17.org> References: <20090307034554.GQ27518@prunille.vinc17.org> Message-ID: <349D1580-26BE-4830-AAC7-1C922BBB9E97@lavergne.gotdns.org> port lint --nitpick p5-image-exiftool ---> Verifying Portfile for p5-image-exiftool Warning: Line 5 should be a newline (after PortGroup) Error: Portfile parent directory graphics does not match primary category perl Error: Portfile directory exiftool does not match port name p5-image- exiftool ---> 2 errors and 1 warnings found. So that'd be a bug. On Mar 6, 2009, at 10:45 PM, Vincent Lefevre wrote: > There's somthing strange: > > $ port cat p5-image-exiftool > # $Id: Portfile 38454 2008-07-21 13:51:06Z blair at macports.org $ > > PortSystem 1.0 > PortGroup perl5 1.0 > perl5.setup Image-ExifTool 7.37 > maintainers blair openmaintainer > description Perl interface to EXIF metadata > long_description ${description} > > platforms darwin > > checksums md5 9e214b3eba4ae3f1eadc4370da6cad70 > > homepage http://www.sno.phy.queensu.ca/~phil/exiftool/ > master_sites ${homepage} > > depends_lib port:p5-digest-md5 \ > port:p5-compress-zlib > > but this port is in graphics/exiftool! This is really misleading. > Is this a bug? > > -- > Vincent Lef?vre - Web: > 100% accessible validated (X)HTML - Blog: blog/> > Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS- > Lyon) > _______________________________________________ > 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 mcalhoun at macports.org Fri Mar 6 22:17:38 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Sat, 7 Mar 2009 06:17:38 +0000 (UTC) Subject: perl5.8 fixup References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> Message-ID: Eric Hall writes: > Ah, another case where that can fail is if module Y requires > module X at a particular version. If a calling script already imported > module X (at a lower-than-required version), I don't think module Y > will re-import the "right" version. This seems to be correct. use YYY; use lib '${prefix}/lib/perl5/vendor_perl/'; use YYY VERSION; @INC = @lib::ORIG_INC; results in an error if VERSION is the newer version. In runs fine, however, if the first "use YYY" is commented out. I was hoping to avoid modifying @INC. It seemed that ${prefix}/bin/perl should not behave differently depending on which p5 ports are installed. I am out of ideas on how to make that happen however. How about this: * Modify @INC so the newer p5 ports are found first. * Do not add conflicting p5 port as dependencies unless the newer version is actually required (mitigate the potential problems). * Prepend p5- to the conflicting man pages. From ryandesign at macports.org Fri Mar 6 23:30:09 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 01:30:09 -0600 Subject: p5-image-exiftool In-Reply-To: <349D1580-26BE-4830-AAC7-1C922BBB9E97@lavergne.gotdns.org> References: <20090307034554.GQ27518@prunille.vinc17.org> <349D1580-26BE-4830-AAC7-1C922BBB9E97@lavergne.gotdns.org> Message-ID: To clarify, the fact that "port lint" has something to say doesn't automatically mean there's a bug in the portfile. It could instead mean there is a bug in lint. In this case, however, lint is right and something should be done to the port. The least intrusive thing to do is to move the port to the correct directory, and keep the port name as it is. DPORTS=http://svn.macosforge.org/repository/macports/trunk/dports svn mv $DPORTS/{graphics/exiftool,perl/p5-image-exiftool} On Mar 6, 2009, at 21:48, Jeremy Lavergne wrote: > port lint --nitpick p5-image-exiftool > ---> Verifying Portfile for p5-image-exiftool > Warning: Line 5 should be a newline (after PortGroup) > Error: Portfile parent directory graphics does not match primary > category perl > Error: Portfile directory exiftool does not match port name p5- > image-exiftool > ---> 2 errors and 1 warnings found. > > So that'd be a bug. > > > On Mar 6, 2009, at 10:45 PM, Vincent Lefevre wrote: > >> There's somthing strange: >> >> $ port cat p5-image-exiftool >> # $Id: Portfile 38454 2008-07-21 13:51:06Z blair at macports.org $ >> >> PortSystem 1.0 >> PortGroup perl5 1.0 >> perl5.setup Image-ExifTool 7.37 >> maintainers blair openmaintainer >> description Perl interface to EXIF metadata >> long_description ${description} >> >> platforms darwin >> >> checksums md5 9e214b3eba4ae3f1eadc4370da6cad70 >> >> homepage http://www.sno.phy.queensu.ca/~phil/exiftool/ >> master_sites ${homepage} >> >> depends_lib port:p5-digest-md5 \ >> port:p5-compress-zlib >> >> but this port is in graphics/exiftool! This is really misleading. >> Is this a bug? From ryandesign at macports.org Fri Mar 6 23:34:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 01:34:13 -0600 Subject: [47756] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <914D15A0-48BE-4A21-9402-74F994B4AAE8@gmail.com> References: <20090305152453.4F37B1144822@beta.macosforge.org> <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> <914D15A0-48BE-4A21-9402-74F994B4AAE8@gmail.com> Message-ID: On Mar 6, 2009, at 15:37, Orville Bennett wrote: > Is there some check which ensures that upgrading the dependency > doesn't break the app that's updated? I don't understand the scenario. Could you give an example? What the commit is supposed to fix is the following case: foo depends on bar. You already have bar 1.0 installed but you don't have foo installed. bar 1.2 is available in the ports tree. Prior to this commit, if you "port install foo", the latest version of foo gets installed but bar remains at 1.0. The latest version of foo may not be compatible with bar 1.0 but should be compatible with the latest version of bar, 1.2. After this commit, if you "port install foo", bar first gets updated to 1.2, then foo gets installed. From krischik at macports.org Fri Mar 6 23:56:04 2009 From: krischik at macports.org (Martin Krischik) Date: Sat, 07 Mar 2009 08:56:04 +0100 Subject: [47762] trunk/dports/emulators/nonpareil In-Reply-To: References: <20090305192101.66859114889A@beta.macosforge.org> Message-ID: <49B22894.9060005@macports.org> Jeremy Huddleston schrieb: > Could we possibly make nonpareil a bit more light weight by adding the > files/ stuff to a tarball on the mirrors... there's no need to clutter > everyone's disk with these 9M Shure - have you got a link for me on how to do it? Yes, I did search the guide and I did search the wiki but nothing useful turned up. Of course I might just have used the wrong search keywords. Suggestion: If there is no documentation yet then write a Wiki and send be the link only. And is there a place in the svn hierarchy where I can keep the files. It is helpful to keep the change history of command files and plists. Regards Martin -- Martin Krischik krischik at users.sourceforge.net From krischik at macports.org Sat Mar 7 00:32:51 2009 From: krischik at macports.org (Martin Krischik) Date: Sat, 07 Mar 2009 09:32:51 +0100 Subject: The Guide - again Message-ID: <49B23133.1000908@macports.org> Hello I know it has been discussed before but let me bring up the Guide again. There are few things which bug be: 1) One Guide for users and maintainer 2) Maintainer guide not all that complete. 3) The Guide not being updated all that often. Ok, 2 and three 3 imply each other. My suggestion - which is not that new either - is to move the maintainer guide into the Wiki. My hope is that the maintainer is updated and improved quicker and become more useful. Martin -- Martin Krischik mailto://krischik at macports.org http://trac.macports.org/wiki/krischik From ryandesign at macports.org Sat Mar 7 00:38:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 02:38:24 -0600 Subject: [47762] trunk/dports/emulators/nonpareil In-Reply-To: <49B22894.9060005@macports.org> References: <20090305192101.66859114889A@beta.macosforge.org> <49B22894.9060005@macports.org> Message-ID: On Mar 7, 2009, at 01:56, Martin Krischik wrote: > Jeremy Huddleston schrieb: > >> Could we possibly make nonpareil a bit more light weight by adding >> the >> files/ stuff to a tarball on the mirrors... there's no need to >> clutter >> everyone's disk with these 9M Agreed. Note it's really only 4MB for most people. (You're counting the redundant files that Subversion stores in working copies; most people use rsync for their dports tree and not Subversion.) But that's still excessive for one port. The entire dports tree is 51.6MB with the PortIndex occupying 3.2MB. We have ~5600 ports so the average size of a port is around 8KB, so nonpareil is 500 times larger than the average. > Shure - have you got a link for me on how to do it? Yes, I did search > the guide and I did search the wiki but nothing useful turned up. Of > course I might just have used the wrong search keywords. > > Suggestion: If there is no documentation yet then write a Wiki and > send > be the link only. > > And is there a place in the svn hierarchy where I can keep the > files. It > is helpful to keep the change history of command files and plists. I don't think there's any specific documentation on this topic. If you need documentation, please consider writing some, after you've learned the steps. It's hard for me to know what steps would be helpful to you. I recommend you copy the icons into your user directory in the repository, which you would first have to create. export REPO=http://svn.macosforge.org/repository/macports svn mkdir $REPO/users/krischik svn mkdir $REPO/users/krischik/nonpareil svn cp $REPO/trunk/dports/emulators/nonpareil/files \ $REPO/users/krischik/nonpareil/appbundles svn rm $REPO/users/kirschik/nonpareil/appbundles/patch-src-util.diff Now you can export that directory and compress it in the same format as your port's existing distfile, which is .tar.gz. Note you should "svn export" and not "svn checkout" because checking out will create a working copy with lots of redundant information in the .svn directories which is not appropriate in a distribution tarball. svn export $REPO/users/kirschik/nonpareil/appbundles \ nonpareil-appbundles tar czf nonpareil-appbundles-rREV.tar.gz nonpareil-appbundles where REV is the revision number that was exported, or some other unique identifier that is not necessarily tied to the version number of nonpareil. Now you can import that distfile into the repository. The distfiles directory would be a good place for it. You'll first have to make the directory for nonpareil. svn mkdir $REPO/distfiles/nonpareil svn import nonpareil-appbundles-rREV.tar.gz $REPO/distfiles/nonpareil Now you can go back to your dports working copy and edit the nonpareil portfile to download nonpareil-appbundles-rREV.tar.gz additionally, like this: Index: Portfile =================================================================== --- Portfile (revision 47813) +++ Portfile (working copy) @@ -22,13 +22,17 @@ algorithms from the calculator. homepage http://nonpareil.brouhaha.com/ -master_sites http://nonpareil.brouhaha.com/download +master_sites http://nonpareil.brouhaha.com/download:prog \ + macports:nonpareil:appbundles set prog nonpareil-${version}.tar.gz +set appbundles nonpareil-appbundles-rREV.tar.gz -distfiles ${prog} +distfiles ${prog}:prog \ + ${appbundles}:appbundles -checksums ${prog} sha1 83bc2f57e6ece9ce19e3449cce075ef246a9f4c2 +checksums ${prog} sha1 83bc2f57e6ece9ce19e3449cce075ef246a9f4c2 \ + ${appbundles} sha1 0123456789abcdef0123456789abcdef01234567 depends_lib port:bison \ port:flex \ It seems like you also can enormously simplify your "platform macosx" section to just this: platform macosx { post-destroot { xinstall -d ${destroot}${applications_dir}/Nonpareil foreach calc {HP-21 HP-25 HP-32E HP-33C HP-34C HP-34 HP-37E HP-38C HP-38E HP-41CV HP-41CX HP-45 HP-55 HP-80} { copy ${worksrcpath}/nonpareil-appbundles/${calc}.app ${destroot}$ {applications_dir}/Nonpareil reinplace s|@PREFIX@|${prefix}|g \ ${destroot}${applications_dir}/Nonpareil/${calc}.app/Contents/ MacOS/${calc}.command } } } And of course you'll want to then "svn rm" all the icons in the files directory before you commit. From ryandesign at macports.org Sat Mar 7 00:42:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 02:42:38 -0600 Subject: The Guide - again In-Reply-To: <49B23133.1000908@macports.org> References: <49B23133.1000908@macports.org> Message-ID: On Mar 7, 2009, at 02:32, Martin Krischik wrote: > I know it has been discussed before but let me bring up the Guide > again. > There are few things which bug be: > > 1) One Guide for users and maintainer > 2) Maintainer guide not all that complete. > 3) The Guide not being updated all that often. > > Ok, 2 and three 3 imply each other. My suggestion - which is not that > new either - is to move the maintainer guide into the Wiki. > > My hope is that the maintainer is updated and improved quicker and > become more useful. I agree it can be confusing that there is one guide that is trying to be useful to different classes of people (users vs. port maintainers vs. base developers). I do not believe that we need to separate these into different documents because there is overlap between these different peoples' needs. We could do a better job of indicating which sections are for which audience, or rearranging sections in the guide to group things by audience. I do not believe we need to move all or part of the guide to the wiki. Quite the opposite: documentation that's getting created in the wiki should get moved to the guide. If there are specific things missing from the guide, please file tickets requesting that documentation. Please file tickets for any issues you have with the guide content, in fact, including suggestions for rearranging or whatever. From krischik at macports.org Sat Mar 7 00:46:53 2009 From: krischik at macports.org (Martin Krischik) Date: Sat, 07 Mar 2009 09:46:53 +0100 Subject: MacPorts Mailing Lists Message-ID: <49B2347D.90607@macports.org> Hello, I noticed something annoying about the mailing list: Quite often when I hit reply the reply goes to the original author and not the mailing list. I did some experimenting and noticed that this happens when more then one address is added to "To" address. And this in turn happens when you just click reply on svn commits. Maybe we could fine-tune the svn commit posting so that this won't happen any more. Martin -- Martin Krischik mailto://krischik at macports.org http://trac.macports.org/wiki/krischik From ryandesign at macports.org Sat Mar 7 01:09:07 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 03:09:07 -0600 Subject: MacPorts Mailing Lists In-Reply-To: <49B2347D.90607@macports.org> References: <49B2347D.90607@macports.org> Message-ID: <3B3EBA7E-BA04-4B0B-967F-1D81C22EAC94@macports.org> On Mar 7, 2009, at 02:46, Martin Krischik wrote: > I noticed something annoying about the mailing list: Quite often > when I > hit reply the reply goes to the original author and not the mailing > list. This always occurs on macports-users and macports-dev. This is intentional, following this reasoning: http://www.unicom.com/pw/reply-to-harmful.html > I did some experimenting and noticed that this happens when more then > one address is added to "To" address. And this in turn happens when > you > just click reply on svn commits. > > Maybe we could fine-tune the svn commit posting so that this won't > happen any more. The lists are configured the way we want them. On the discussion lists (macports-users and macports-dev), to reply, you should almost always use the "Reply All" feature of your email program so that the reply goes both to the list and to the person who wrote the message you're replying to. If you just use the "Reply" feature your message will only go to the author and not to the list and the list won't benefit from the discussion. On macports-changes, the Reply-To is set so that you should just "Reply" and your reply will go to macports-dev and to the person who made the commit. It was deliberately set up this way because we want discussion of commits to occur on macports-dev, and just in case the committer is not on macports-dev, the message should go to the committer too. You should not post messages to macports-changes yourself (it is for automated messages from the Subversion repository only) so you should not use "Reply All" or manually address messages to macports-changes. I am not on macports-tickets so I don't know how it's set up. I would hope it's set up the same way as macports-changes. I'm not sure how macports-announce is set up. It's announce-only so most people don't have permission to post there. Hopefully that list's Reply To is set to macports-users. From ryandesign at macports.org Sat Mar 7 01:11:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 03:11:40 -0600 Subject: perl5.8 fixup In-Reply-To: <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> Message-ID: <07040059-F411-4C81-A2AE-627C71A42388@macports.org> On Mar 6, 2009, at 20:22, Bradley Giesbrecht wrote: > How about creating a Portfile for ALL the perl5.8 modules, Did you mean a single portfile containing all perl5.8 modules, or individual portfiles for each perl5.8 module? I would be in favor of the latter. > make them all depends of perl5.8, Did you mean that the perl5.8 port would declare dependencies on each of these perl5.8 module ports, e.g. "depends_lib-append p5-some- module"? If so, I don't think that can work, since the modules require perl5.8 to build. > unregistering them from perl5.8 and registering the module on there > own. > Then those p5 modules that existed before can replace the ones > created from the perl5.8 base modules with a higher revision number. > > Then a port upgrade installed should work to upgrade all the p5 > modules with newer versions that have been added. If we make perl5.8 install no modules of its own and move all modules to their own ports, then each port that uses any of the standard formerly-built-in modules will have to now declare dependencies on the formerly-built-in modules' new ports. From ryandesign at macports.org Sat Mar 7 01:11:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 03:11:49 -0600 Subject: [47804] trunk/dports/devel/cmake/Portfile In-Reply-To: <20090306214916.5B90B1159AEF@beta.macosforge.org> References: <20090306214916.5B90B1159AEF@beta.macosforge.org> Message-ID: On Mar 6, 2009, at 15:49, toby at macports.org wrote: > Revision: 47804 > http://trac.macports.org/changeset/47804 > Author: toby at macports.org > Date: 2009-03-06 13:49:15 -0800 (Fri, 06 Mar 2009) > Log Message: > ----------- > cmake 2.6.3 > > Modified Paths: > -------------- > trunk/dports/devel/cmake/Portfile > > Modified: trunk/dports/devel/cmake/Portfile > =================================================================== > --- trunk/dports/devel/cmake/Portfile 2009-03-06 20:52:30 UTC (rev > 47803) > +++ trunk/dports/devel/cmake/Portfile 2009-03-06 21:49:15 UTC (rev > 47804) > @@ -3,7 +3,7 @@ > PortSystem 1.0 > > name cmake > -version 2.6.2 > +version 2.6.3 > categories devel > maintainers css > description Cross-platform make [snip] Did the maintainer approve this update, or was there a ticket filed to which the maintainer did not respond within 72 hours? From ryandesign at macports.org Sat Mar 7 01:19:01 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 03:19:01 -0600 Subject: [47741] trunk/dports/audio/mpg123/Portfile In-Reply-To: <20090304212316.50795113A370@beta.macosforge.org> References: <20090304212316.50795113A370@beta.macosforge.org> Message-ID: <2ACFC064-1402-4310-BE66-CE2528F926F1@macports.org> On Mar 4, 2009, at 15:20, toby at macports.org wrote: > Revision: 47740 > http://trac.macports.org/changeset/47740 > Author: toby at macports.org > Date: 2009-03-04 13:20:43 -0800 (Wed, 04 Mar 2009) > Log Message: > ----------- > nuke broken i386 variant, remove unnecessary destroot.destdir On Mar 4, 2009, at 15:23, toby at macports.org wrote: > Revision: 47741 > http://trac.macports.org/changeset/47741 > Author: toby at macports.org > Date: 2009-03-04 13:23:15 -0800 (Wed, 04 Mar 2009) > Log Message: > ----------- > mpg123 1.6.4 Did the maintainer approve these update, or was there a ticket filed to which the maintainer did not respond? We do have a policy of allowing a port maintainer 72 hours to respond to port issues, and if they do not do so, then you may commit updates, but should indicate in your commit message that the maintainer timeout has occurred, or that the maintainer has approved your commit, unless such things are clear from the ticket whose number your commit message references. From jmr at macports.org Sat Mar 7 02:08:49 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 07 Mar 2009 21:08:49 +1100 Subject: [47756] trunk/base/src/macports1.0/macports.tcl In-Reply-To: References: <20090305152453.4F37B1144822@beta.macosforge.org> <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> <914D15A0-48BE-4A21-9402-74F994B4AAE8@gmail.com> Message-ID: <49B247B1.1070402@macports.org> Ryan Schmidt wrote: > > On Mar 6, 2009, at 15:37, Orville Bennett wrote: > >> Is there some check which ensures that upgrading the dependency >> doesn't break the app that's updated? > > I don't understand the scenario. Could you give an example? > > > What the commit is supposed to fix is the following case: > > foo depends on bar. > You already have bar 1.0 installed but you don't have foo installed. > bar 1.2 is available in the ports tree. > Prior to this commit, if you "port install foo", the latest version of > foo gets installed but bar remains at 1.0. > The latest version of foo may not be compatible with bar 1.0 but should > be compatible with the latest version of bar, 1.2. > After this commit, if you "port install foo", bar first gets updated to > 1.2, then foo gets installed. Not quite. The change doesn't affect the behaviour of 'port install'. The affected scenario is: You have A and C installed, but not B. A new version of A is available which adds a dependency on B. B depends on C. You run 'port upgrade A'. Old behaviour: B is installed, then C is upgraded (and finally A is upgraded). New behaviour: C is upgraded, then B is installed (and finally A is upgraded). I would not be opposed to making 'port install' behave the way you describe, however (provided it also gets support for -n). :-) - Josh From ryandesign at macports.org Sat Mar 7 04:13:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 06:13:42 -0600 Subject: [47762] trunk/dports/emulators/nonpareil In-Reply-To: References: <20090305192101.66859114889A@beta.macosforge.org> <49B22894.9060005@macports.org> Message-ID: <5415ABA9-4535-4F19-8A5B-9E14DE4B5106@macports.org> On Mar 7, 2009, at 02:38, Ryan Schmidt wrote: > I recommend you copy the icons into your user directory in the > repository, which you would first have to create. Now that I think about it, it would be better to copy *just* the icon files. Don't copy the .command files or the Info.plist files, since those are largely the same and could be better handled by having just a single template .command and Info.plist file in the files directory which you can modify for each calculator using reinplace. Don't have the appbundle directory structure in your icon distfile either; create it in the destroot like you were doing (though abstracted into a foreach loop like I showed). From krischik at macports.org Sat Mar 7 05:40:58 2009 From: krischik at macports.org (Martin Krischik) Date: Sat, 07 Mar 2009 14:40:58 +0100 Subject: [47762] trunk/dports/emulators/nonpareil In-Reply-To: <5415ABA9-4535-4F19-8A5B-9E14DE4B5106@macports.org> References: <20090305192101.66859114889A@beta.macosforge.org> <49B22894.9060005@macports.org> <5415ABA9-4535-4F19-8A5B-9E14DE4B5106@macports.org> Message-ID: <49B2796A.8050602@macports.org> Ryan Schmidt schrieb: > On Mar 7, 2009, at 02:38, Ryan Schmidt wrote: > >> I recommend you copy the icons into your user directory in the >> repository, which you would first have to create. > > Now that I think about it, it would be better to copy *just* the icon > files. Don't copy the .command files or the Info.plist files, since > those are largely the same and could be better handled by having just a > single template .command and Info.plist file in the files directory > which you can modify for each calculator using reinplace. Don't have the > appbundle directory structure in your icon distfile either; create it in > the destroot like you were doing (though abstracted into a foreach loop > like I showed). Indeed that would be better. But I am finished now. Maybe I re-factor when the next Nonpareil release comes out. Martin -- Martin Krischik mailto://krischik at macports.org http://trac.macports.org/wiki/krischik From brad at pixilla.com Sat Mar 7 08:17:29 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sat, 7 Mar 2009 08:17:29 -0800 Subject: perl5.8 fixup In-Reply-To: <07040059-F411-4C81-A2AE-627C71A42388@macports.org> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> Message-ID: <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> On Mar 7, 2009, at 1:11 AM, Ryan Schmidt wrote: > On Mar 6, 2009, at 20:22, Bradley Giesbrecht wrote: > >> How about creating a Portfile for ALL the perl5.8 modules, > > Did you mean a single portfile containing all perl5.8 modules, or > individual portfiles for each perl5.8 module? I would be in favor of > the latter. Individual port files. >> make them all depends of perl5.8, > > Did you mean that the perl5.8 port would declare dependencies on > each of these perl5.8 module ports, e.g. "depends_lib-append p5-some- > module"? If so, I don't think that can work, since the modules > require perl5.8 to build. True, so can we make a wrapper port that: depends_lib-append perl5 all_the_default_p5's So you can't run "port depends_lib-append" for post-destroot? >> unregistering them from perl5.8 and registering the module on there >> own. >> Then those p5 modules that existed before can replace the ones >> created from the perl5.8 base modules with a higher revision number. >> >> Then a port upgrade installed should work to upgrade all the p5 >> modules with newer versions that have been added. > > If we make perl5.8 install no modules of its own and move all > modules to their own ports, then each port that uses any of the > standard formerly-built-in modules will have to now declare > dependencies on the formerly-built-in modules' new ports. Make pseudo port perl5-p5-base. Installs all the formerly-built-in modules. Add port perl5-p5-base as a depends_lib to each and every p5 that is not in the perl5-p5-base group of ports. Over time it would be nice to have the non-base p5's depend directly on the p5 as opposed to the perl5-p5-base port. It would be nice to have a way of adding these types of modules (could also be python and others) in a post-destroot phase and not have them be required or registered to the port itself like so: perl5:Portfile default_variants +perl5-p5-base variant perl5-p5-base description {"Install default perl modules"} { set p5-base {"p5-mod1","p5-mod2"} } post-destroot { if {[variant_isset perl5-p5-base]} { foreach p5_module $p5-base} { port install $p5_module } } } //Brad From ryandesign at macports.org Sat Mar 7 09:55:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 11:55:24 -0600 Subject: perl5.8 fixup In-Reply-To: <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> Message-ID: <48C31427-A490-427E-8391-20291C81CBD3@macports.org> On Mar 7, 2009, at 10:17, Bradley Giesbrecht wrote: >> Did you mean that the perl5.8 port would declare dependencies on >> each of these perl5.8 module ports, e.g. "depends_lib-append p5- >> some-module"? If so, I don't think that can work, since the >> modules require perl5.8 to build. > > True, so can we make a wrapper port that: > depends_lib-append perl5 all_the_default_p5's We could... > So you can't run "port depends_lib-append" for post-destroot? I'm not sure what you mean. In a portfile, dependencies need to be declared outside of any phase so that MacPorts can compute a port's dependencies before it begins dealing with the port. > Make pseudo port perl5-p5-base. Installs all the formerly-built-in > modules. Add port perl5-p5-base as a depends_lib to each and every > p5 that is not in the perl5-p5-base group of ports. Over time it > would be nice to have the non-base p5's depend directly on the p5 > as opposed to the perl5-p5-base port. We could do this... It's probably easier to modify the perl5 portgroup to always depend on this perl5-p5-base port. That way no ports need to deal with it, except those few perl ports that don't use the perl5 portgroup (if there even are any like that). > It would be nice to have a way of adding these types of modules > (could also be python and others) in a post-destroot phase and not > have them be required or registered to the port itself like so: > > perl5:Portfile > > default_variants +perl5-p5-base > > variant perl5-p5-base description {"Install default perl modules"} { > set p5-base {"p5-mod1","p5-mod2"} > } > > post-destroot { > if {[variant_isset perl5-p5-base]} { > foreach p5_module $p5-base} { > port install $p5_module > } > } > } I'm not sure I follow. From illogical1 at gmail.com Sat Mar 7 10:15:20 2009 From: illogical1 at gmail.com (Orville Bennett) Date: Sat, 7 Mar 2009 13:15:20 -0500 Subject: [47756] trunk/base/src/macports1.0/macports.tcl In-Reply-To: References: <20090305152453.4F37B1144822@beta.macosforge.org> <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> <914D15A0-48BE-4A21-9402-74F994B4AAE8@gmail.com> Message-ID: <6D6DA720-443B-456F-BF22-F23C0404D9BC@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 7, 2009, at 2:34 AM, Ryan Schmidt wrote: > > On Mar 6, 2009, at 15:37, Orville Bennett wrote: > >> Is there some check which ensures that upgrading the dependency >> doesn't break the app that's updated? > > I don't understand the scenario. Could you give an example? You've compiled A and B. B gets upgraded in macports to a version which no longer works properly with A. A also gets updated but still doesn't work with the new B. If port upgrade A is done the new B gets upgraded too and A no longer works properly/compiles. B is boost if anyone was trying to guess :-) This is why I use 'port install' to "upgrade" to new software. Upgrade deletes the old version then installs the newer version. Being bitten by this in the past, I rather use port install which puts the newer versions into a new slot so I can test that they work together. It would be awesome if macports made it so that this wasn't necessary though. > > > What the commit is supposed to fix is the following case: > > foo depends on bar. > You already have bar 1.0 installed but you don't have foo installed. > bar 1.2 is available in the ports tree. > Prior to this commit, if you "port install foo", the latest version > of foo gets installed but bar remains at 1.0. > The latest version of foo may not be compatible with bar 1.0 but > should be compatible with the latest version of bar, 1.2. > After this commit, if you "port install foo", bar first gets updated > to 1.2, then foo gets installed. > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmyubgACgkQ2yWVgjgEOKRkBwCeOyYZ+v51T+1JJgKi1h8Br57a LqkAoIF/USDN+tSZVqFsuF8onu2FxAFP =pfT8 -----END PGP SIGNATURE----- From ryandesign at macports.org Sat Mar 7 10:29:27 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 12:29:27 -0600 Subject: [47756] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <6D6DA720-443B-456F-BF22-F23C0404D9BC@gmail.com> References: <20090305152453.4F37B1144822@beta.macosforge.org> <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> <914D15A0-48BE-4A21-9402-74F994B4AAE8@gmail.com> <6D6DA720-443B-456F-BF22-F23C0404D9BC@gmail.com> Message-ID: On Mar 7, 2009, at 12:15, Orville Bennett wrote: > On Mar 7, 2009, at 2:34 AM, Ryan Schmidt wrote: > >> On Mar 6, 2009, at 15:37, Orville Bennett wrote: >> >>> Is there some check which ensures that upgrading the dependency >>> doesn't break the app that's updated? >> >> I don't understand the scenario. Could you give an example? > > You've compiled A and B. > B gets upgraded in macports to a version which no longer works > properly with A. > A also gets updated but still doesn't work with the new B. > If port upgrade A is done the new B gets upgraded too and A no > longer works properly/compiles. > B is boost if anyone was trying to guess :-) If you want to upgrade A without upgrading B, use "sudo port -nf upgrade A" > This is why I use 'port install' to "upgrade" to new software. > Upgrade deletes the old version then installs the newer version. > Being bitten by this in the past, I rather use port install which > puts the newer versions into a new slot so I can test that they > work together. > It would be awesome if macports made it so that this wasn't > necessary though. "sudo port upgrade A" does not uninstall the old version of A. "sudo port -u upgrade A" does. If you don't want the old version to be uninstalled when you upgrade, don't use the -u flag. Caveat: "sudo port -nf upgrade A" does uninstall the old version of A. From ryandesign at macports.org Sat Mar 7 10:33:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 12:33:24 -0600 Subject: [47762] trunk/dports/emulators/nonpareil In-Reply-To: <49B2796A.8050602@macports.org> References: <20090305192101.66859114889A@beta.macosforge.org> <49B22894.9060005@macports.org> <5415ABA9-4535-4F19-8A5B-9E14DE4B5106@macports.org> <49B2796A.8050602@macports.org> Message-ID: <1370D703-0D7E-455A-8EAF-E6C992E8F86E@macports.org> On Mar 7, 2009, at 07:40, Martin Krischik wrote: > Ryan Schmidt schrieb: > >> On Mar 7, 2009, at 02:38, Ryan Schmidt wrote: >> >>> I recommend you copy the icons into your user directory in the >>> repository, which you would first have to create. >> >> Now that I think about it, it would be better to copy *just* the icon >> files. Don't copy the .command files or the Info.plist files, since >> those are largely the same and could be better handled by having >> just a >> single template .command and Info.plist file in the files directory >> which you can modify for each calculator using reinplace. Don't >> have the >> appbundle directory structure in your icon distfile either; create >> it in >> the destroot like you were doing (though abstracted into a foreach >> loop >> like I showed). > > Indeed that would be better. But I am finished now. Maybe I re-factor > when the next Nonpareil release comes out. Yes, I didn't see you had already committed things per my first suggestion. It's up to you how you do it, I just figure it's easier to maintain one Info.plist and one .command file instead of fourteen. From jmr at macports.org Sat Mar 7 10:39:14 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 08 Mar 2009 05:39:14 +1100 Subject: [47756] trunk/base/src/macports1.0/macports.tcl In-Reply-To: References: <20090305152453.4F37B1144822@beta.macosforge.org> <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> <914D15A0-48BE-4A21-9402-74F994B4AAE8@gmail.com> <6D6DA720-443B-456F-BF22-F23C0404D9BC@gmail.com> Message-ID: <49B2BF52.5090109@macports.org> Ryan Schmidt wrote: > On Mar 7, 2009, at 12:15, Orville Bennett wrote: > >> On Mar 7, 2009, at 2:34 AM, Ryan Schmidt wrote: >> >>> On Mar 6, 2009, at 15:37, Orville Bennett wrote: >>> >>>> Is there some check which ensures that upgrading the dependency >>>> doesn't break the app that's updated? >>> >>> I don't understand the scenario. Could you give an example? >> >> You've compiled A and B. >> B gets upgraded in macports to a version which no longer works >> properly with A. >> A also gets updated but still doesn't work with the new B. >> If port upgrade A is done the new B gets upgraded too and A no longer >> works properly/compiles. >> B is boost if anyone was trying to guess :-) > > If you want to upgrade A without upgrading B, use "sudo port -nf upgrade A" Why would -f be needed here? > >> This is why I use 'port install' to "upgrade" to new software. Upgrade >> deletes the old version then installs the newer version. Being bitten >> by this in the past, I rather use port install which puts the newer >> versions into a new slot so I can test that they work together. >> It would be awesome if macports made it so that this wasn't necessary >> though. > > "sudo port upgrade A" does not uninstall the old version of A. > > "sudo port -u upgrade A" does. > > If you don't want the old version to be uninstalled when you upgrade, > don't use the -u flag. > > Caveat: "sudo port -nf upgrade A" does uninstall the old version of A. But not in trunk any more, unless it really has to (when you're forcing an upgrade to a version that is already installed). - Josh From ryandesign at macports.org Sat Mar 7 10:44:56 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 12:44:56 -0600 Subject: [47741] trunk/dports/audio/mpg123/Portfile In-Reply-To: <15B7177D-E88A-4C77-9A1B-07954668F8FD@gmx.at> References: <20090304212316.50795113A370@beta.macosforge.org> <2ACFC064-1402-4310-BE66-CE2528F926F1@macports.org> <15B7177D-E88A-4C77-9A1B-07954668F8FD@gmx.at> Message-ID: <22624938-D0E8-4C75-8A23-5F45961C200A@macports.org> On Mar 7, 2009, at 08:22, Andreas Neustifter wrote: > On 07.03.2009, at 10:19, Ryan Schmidt wrote: > >> Did the maintainer approve these update, or was there a ticket >> filed to which the maintainer did not respond? We do have a policy >> of allowing a port maintainer 72 hours to respond to port issues, >> and if they do not do so, then you may commit updates, but should >> indicate in your commit message that the maintainer timeout has >> occurred, or that the maintainer has approved your commit, unless >> such things are clear from the ticket whose number your commit >> message references. > > I must admit that it was maybe a little ambitious to enter me as > maintainer, I will try to improve my response times. I was mostly just concerned with whether you had been asked about this change before it was made, since you are listed as its maintainer. If you would like we can add "openmaintainer" to mpg123, to indicate that anyone should feel free to update the port without asking you. Or we can keep it the way it is if you'd like to continue to have the first say in what goes on with the port. > The 1.6.4 builds and works (with a small test sample) on PowerPC, I > do not have a x86 machine to test. I tried it and it builds and correctly plays an mp3 on my MacBook Pro on Tiger. From ryandesign at macports.org Sat Mar 7 10:46:36 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 12:46:36 -0600 Subject: [47756] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <49B2BF52.5090109@macports.org> References: <20090305152453.4F37B1144822@beta.macosforge.org> <07EA8A0A-2A3D-4BA5-98D6-1D7C8489CE40@macports.org> <914D15A0-48BE-4A21-9402-74F994B4AAE8@gmail.com> <6D6DA720-443B-456F-BF22-F23C0404D9BC@gmail.com> <49B2BF52.5090109@macports.org> Message-ID: <07585828-FDC9-4106-9C7D-555692EC1B3A@macports.org> On Mar 7, 2009, at 12:39, Joshua Root wrote: > Ryan Schmidt wrote: > >> If you want to upgrade A without upgrading B, use "sudo port -nf >> upgrade A" > > Why would -f be needed here? Uh, force of habit. I usually use "port -nf upgrade" to rebuild a port at the same version. Presumably you don't need "-f" if the port version is different and MacPorts already thinks an upgrade is needed. >> Caveat: "sudo port -nf upgrade A" does uninstall the old version >> of A. > > But not in trunk any more, unless it really has to (when you're > forcing > an upgrade to a version that is already installed). Super! From loshea at gmail.com Sat Mar 7 10:56:44 2009 From: loshea at gmail.com (Luis O'Shea) Date: Sat, 7 Mar 2009 13:56:44 -0500 Subject: Port update (asymptote) needs commit Message-ID: See http://trac.macports.org/ticket/18664. Thanks, Luis From raimue at macports.org Sat Mar 7 12:16:16 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 07 Mar 2009 21:16:16 +0100 Subject: MacPorts Mailing Lists In-Reply-To: <3B3EBA7E-BA04-4B0B-967F-1D81C22EAC94@macports.org> References: <49B2347D.90607@macports.org> <3B3EBA7E-BA04-4B0B-967F-1D81C22EAC94@macports.org> Message-ID: <49B2D610.2010707@macports.org> Ryan Schmidt wrote: > On macports-changes, the Reply-To is set so that you should just > "Reply" and your reply will go to macports-dev and to the person who > made the commit. It was deliberately set up this way because we want > discussion of commits to occur on macports-dev, and just in case the > committer is not on macports-dev, the message should go to the > committer too. You should not post messages to macports-changes > yourself (it is for automated messages from the Subversion repository > only) so you should not use "Reply All" or manually address messages > to macports-changes. If you do not want to be on the reply list when other people hit the "Reply All" button on your messages, configure your mail client to set the Mail-Followup-To header [1] to the list address. Unfortunately, most mail clients are incapable to do so. Rainer [1] http://cr.yp.to/proto/replyto.html From raimue at macports.org Sat Mar 7 12:32:47 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 07 Mar 2009 21:32:47 +0100 Subject: perl5.8 fixup In-Reply-To: <48C31427-A490-427E-8391-20291C81CBD3@macports.org> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> Message-ID: <49B2D9EF.2060501@macports.org> Ryan Schmidt wrote: > On Mar 7, 2009, at 10:17, Bradley Giesbrecht wrote: > >>> Did you mean that the perl5.8 port would declare dependencies on >>> each of these perl5.8 module ports, e.g. "depends_lib-append p5- >>> some-module"? If so, I don't think that can work, since the >>> modules require perl5.8 to build. >> True, so can we make a wrapper port that: >> depends_lib-append perl5 all_the_default_p5's The port installing perl itself can not depend on any p5-* ports, as they require perl. Circular dependencies are not possible. There would have to be a split into e.g. perl5.8-core and a perl5.8 meta port. This meta port would depend on perl5.8-core and additional p5-* ports. Rainer From raimue at macports.org Sat Mar 7 12:33:20 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 07 Mar 2009 21:33:20 +0100 Subject: The Guide - again In-Reply-To: References: <49B23133.1000908@macports.org> Message-ID: <49B2DA10.8050008@macports.org> Ryan Schmidt wrote: > I do not believe that we need to separate these into different > documents because there is overlap between these different peoples' > needs. We could do a better job of indicating which sections are for > which audience, or rearranging sections in the guide to group things > by audience. I don't like the fact that the guide is one huge document. We discussed splitting the guide into single pages ('chunked' in docbook terms) before, but the majority was against it. In my opinion it would at least make sense to split the guide into pages each of them relevant for users, maintainers, base hackers. There is the MacPorts Internals documentation (API, registry etc.) which is not interesting for anyone else than base hackers. Maybe it should not be in the guide at all, but live in the repository as plain text only. > I do not believe we need to move all or part of the guide to the > wiki. Quite the opposite: documentation that's getting created in the > wiki should get moved to the guide. To be honest, editing the guide sucks. Contributing to the wiki is much easier. Especially if the concern is the guide being outdated, I see the problem in the guide format. We had the recent discussion to move the guide to another markup language but it was teared down. What else can we do to attract more people for writing documentation? Rainer From jmr at macports.org Sat Mar 7 12:42:25 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 08 Mar 2009 07:42:25 +1100 Subject: The Guide - again In-Reply-To: <49B2DA10.8050008@macports.org> References: <49B23133.1000908@macports.org> <49B2DA10.8050008@macports.org> Message-ID: <49B2DC31.5050009@macports.org> Rainer M?ller wrote: > Ryan Schmidt wrote: >> I do not believe that we need to separate these into different >> documents because there is overlap between these different peoples' >> needs. We could do a better job of indicating which sections are for >> which audience, or rearranging sections in the guide to group things >> by audience. > > I don't like the fact that the guide is one huge document. We discussed > splitting the guide into single pages ('chunked' in docbook terms) > before, but the majority was against it. In my opinion it would at least > make sense to split the guide into pages each of them relevant for > users, maintainers, base hackers. It does exist at . A decision on whether to change the default was postponed, IIRC. - Josh From brad at pixilla.com Sat Mar 7 13:49:27 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sat, 7 Mar 2009 13:49:27 -0800 Subject: perl5.8 fixup In-Reply-To: <49B2D9EF.2060501@macports.org> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> Message-ID: <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> On Mar 7, 2009, at 12:32 PM, Rainer M?ller wrote: > Ryan Schmidt wrote: >> On Mar 7, 2009, at 10:17, Bradley Giesbrecht wrote: >> >>>> Did you mean that the perl5.8 port would declare dependencies on >>>> each of these perl5.8 module ports, e.g. "depends_lib-append p5- >>>> some-module"? If so, I don't think that can work, since the >>>> modules require perl5.8 to build. >>> True, so can we make a wrapper port that: >>> depends_lib-append perl5 all_the_default_p5's > > The port installing perl itself can not depend on any p5-* ports, as > they require perl. Circular dependencies are not possible. > > There would have to be a split into e.g. perl5.8-core and a perl5.8 > meta > port. This meta port would depend on perl5.8-core and additional p5- > * ports. > > Rainer That sounds good. You wouldn't be able to uninstall p5's that are part of the perl5.8 meta port. Would you be able to upgrade the p5's in the perl5.8 meta port? I don't know how useful perl is with no modules but it sounds good to me to be able to install perl without them. perl5.8-core sounds appealing. //Brad From brad at pixilla.com Sat Mar 7 13:49:56 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sat, 7 Mar 2009 13:49:56 -0800 Subject: perl5.8 fixup In-Reply-To: <48C31427-A490-427E-8391-20291C81CBD3@macports.org> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> Message-ID: <39C61692-2CA8-4C9A-AA8F-0DBE14A9B4B9@pixilla.com> On Mar 7, 2009, at 9:55 AM, Ryan Schmidt wrote: > On Mar 7, 2009, at 10:17, Bradley Giesbrecht wrote: > >>> Did you mean that the perl5.8 port would declare dependencies on >>> each of these perl5.8 module ports, e.g. "depends_lib-append p5- >>> some-module"? If so, I don't think that can work, since the >>> modules require perl5.8 to build. >> >> True, so can we make a wrapper port that: >> depends_lib-append perl5 all_the_default_p5's > > We could... > >> So you can't run "port depends_lib-append" for post-destroot? > > I'm not sure what you mean. > > In a portfile, dependencies need to be declared outside of any phase > so that MacPorts can compute a port's dependencies before it begins > dealing with the port. I don't understand what I mean here either :) >> Make pseudo port perl5-p5-base. Installs all the formerly-built-in >> modules. Add port perl5-p5-base as a depends_lib to each and every >> p5 that is not in the perl5-p5-base group of ports. Over time it >> would be nice to have the non-base p5's depend directly on the p5 >> as opposed to the perl5-p5-base port. > > We could do this... It's probably easier to modify the perl5 > portgroup to always depend on this perl5-p5-base port. That way no > ports need to deal with it, except those few perl ports that don't > use the perl5 portgroup (if there even are any like that). Would this allow updating a p5 in the portgroup without -f? >> It would be nice to have a way of adding these types of modules >> (could also be python and others) in a post-destroot phase and not >> have them be required or registered to the port itself like so: >> >> perl5:Portfile >> >> default_variants +perl5-p5-base >> >> variant perl5-p5-base description {"Install default perl modules"} { >> set p5-base {"p5-mod1","p5-mod2"} >> } >> >> post-destroot { >> if {[variant_isset perl5-p5-base]} { >> foreach p5_module $p5-base} { >> port install $p5_module >> } >> } >> } > > I'm not sure I follow. Have the perl5 Portfile install the base p5's after perl5 activation so the p5's dependency on perl5 is met. I don't know if this can be done but it was my idea of how to have the p5's as seperate ports but still be installed with perl5. //Brad From cssdev at mac.com Sat Mar 7 14:50:09 2009 From: cssdev at mac.com (cssdev at mac.com) Date: Sat, 07 Mar 2009 17:50:09 -0500 Subject: [47804] trunk/dports/devel/cmake/Portfile In-Reply-To: References: <20090306214916.5B90B1159AEF@beta.macosforge.org> Message-ID: <08210248-EF74-4B82-AA00-1F46B1B2A76B@mac.com> On Mar 7, 2009, at 4:11 AM, Ryan Schmidt wrote: > On Mar 6, 2009, at 15:49, toby at macports.org wrote: > >> Revision: 47804 >> http://trac.macports.org/changeset/47804 >> Author: toby at macports.org >> Date: 2009-03-06 13:49:15 -0800 (Fri, 06 Mar 2009) >> Log Message: >> ----------- >> cmake 2.6.3 > > [snip] > > Did the maintainer approve this update, or was there a ticket filed > to which the maintainer did not respond within 72 hours? Neither. I've been checking some other build issues with CMake, but I would prefer that we follow the procedure of creating tickets, assigning them to maintainers, and referencing them in commit messages. Could we enable the Trac pre-commit-hook[1] that requires commit messages to reference open tickets? There have been a number of recent commits to ports without references to tickets, and that makes it hard to dig through Trac to find the background info for a particular commit. That's annoying for ports I maintain, especially without either any contact with me or tickets filed in Trac. (There have been some timeouts too, but that's part of the process. :) I think we should require port commits to reference existing, open Trac tickets. Chris [1]: http://trac.edgewall.org/browser/trunk/contrib/trac-pre-commit-hook From blb at macports.org Sat Mar 7 15:02:33 2009 From: blb at macports.org (Bryan Blackburn) Date: Sat, 7 Mar 2009 16:02:33 -0700 Subject: The Guide - again In-Reply-To: References: <49B23133.1000908@macports.org> Message-ID: <20090307230233.GE921@ninagal.withay.com> On Sat, Mar 07, 2009 at 02:42:38AM -0600, Ryan Schmidt said: > > On Mar 7, 2009, at 02:32, Martin Krischik wrote: > >> I know it has been discussed before but let me bring up the Guide >> again. >> There are few things which bug be: >> >> 1) One Guide for users and maintainer >> 2) Maintainer guide not all that complete. >> 3) The Guide not being updated all that often. Examples of not too often? The revision log shows it's not exactly untouched: [...] > > I do not believe that we need to separate these into different documents > because there is overlap between these different peoples' needs. We could > do a better job of indicating which sections are for which audience, or > rearranging sections in the guide to group things by audience. > > I do not believe we need to move all or part of the guide to the wiki. > Quite the opposite: documentation that's getting created in the wiki > should get moved to the guide. Starting new items on the wiki makes sense, but if it really should be in the guide, then once it's been fleshed out it should be moved over to the guide. This way the ease of the wiki can be used until it's (hopefully) good enough then can be put in the guide, since that's what we usually point to for documentation. Bryan [...] From blb at macports.org Sat Mar 7 15:06:43 2009 From: blb at macports.org (Bryan Blackburn) Date: Sat, 7 Mar 2009 16:06:43 -0700 Subject: [47804] trunk/dports/devel/cmake/Portfile In-Reply-To: <08210248-EF74-4B82-AA00-1F46B1B2A76B@mac.com> References: <20090306214916.5B90B1159AEF@beta.macosforge.org> <08210248-EF74-4B82-AA00-1F46B1B2A76B@mac.com> Message-ID: <20090307230643.GF921@ninagal.withay.com> On Sat, Mar 07, 2009 at 05:50:09PM -0500, cssdev at mac.com said: > On Mar 7, 2009, at 4:11 AM, Ryan Schmidt wrote: [...] >> >> Did the maintainer approve this update, or was there a ticket filed to >> which the maintainer did not respond within 72 hours? > > Neither. I've been checking some other build issues with CMake, but I > would prefer that we follow the procedure of creating tickets, assigning > them to maintainers, and referencing them in commit messages. > > Could we enable the Trac pre-commit-hook[1] that requires commit messages > to reference open tickets? There have been a number of recent commits to > ports without references to tickets, and that makes it hard to dig through > Trac to find the background info for a particular commit. That's annoying > for ports I maintain, especially without either any contact with me or > tickets filed in Trac. (There have been some timeouts too, but that's part > of the process. :) > > I think we should require port commits to reference existing, open Trac > tickets. For all commits? That would be horrible, then I'd have to create a ticket every time I wanted to update my own ports as well. For other's ports? Then the hook would need to be smart, checking maintainers, referencing that against the committer (and some people may use different accounts), as well as filtering out for openmaintainer... Considering that all you have to do is revert the commit, verses the amount of work this would entail for something that really doesn't happen too frequently, doesn't seem like the best choice. Bryan > > Chris > > [1]: http://trac.edgewall.org/browser/trunk/contrib/trac-pre-commit-hook > From ryandesign at macports.org Sat Mar 7 16:36:21 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 18:36:21 -0600 Subject: The Guide - again In-Reply-To: <49B2DA10.8050008@macports.org> References: <49B23133.1000908@macports.org> <49B2DA10.8050008@macports.org> Message-ID: <44D98670-1600-4587-B804-360BD7699873@macports.org> On Mar 7, 2009, at 14:33, Rainer M?ller wrote: >> I do not believe we need to move all or part of the guide to the >> wiki. Quite the opposite: documentation that's getting created in the >> wiki should get moved to the guide. > > To be honest, editing the guide sucks. Contributing to the wiki is > much > easier. > > Especially if the concern is the guide being outdated, I see the > problem > in the guide format. We had the recent discussion to move the guide to > another markup language but it was teared down. What else can we do to > attract more people for writing documentation? We don't want more people writing the Guide. It should stay as a coherent document authored by one or a few individuals who have a handle on the whole thing. I'm all for people adding documentation to the wiki, just to get it out there quickly, where it can be refined and polished until it's ready to be included in the Guide. From ryandesign at macports.org Sat Mar 7 16:40:50 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 18:40:50 -0600 Subject: perl5.8 fixup In-Reply-To: <6D29C8AD-D0A1-4C18-B039-DB3BAD26979A@pixilla.com> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <6D29C8AD-D0A1-4C18-B039-DB3BAD26979A@pixilla.com> Message-ID: On Mar 7, 2009, at 15:43, Bradley Giesbrecht wrote: >>> Make pseudo port perl5-p5-base. Installs all the formerly-built- >>> in modules. Add port perl5-p5-base as a depends_lib to each and >>> every p5 that is not in the perl5-p5-base group of ports. Over >>> time it would be nice to have the non-base p5's depend directly >>> on the p5 as opposed to the perl5-p5-base port. >> >> We could do this... It's probably easier to modify the perl5 >> portgroup to always depend on this perl5-p5-base port. That way no >> ports need to deal with it, except those few perl ports that don't >> use the perl5 portgroup (if there even are any like that). > > Would this allow updating a p5 in the portgroup without -f? If you change what dependencies are in the portgroup, then you would have to bump the revision of all ports using the portgroup.... That's messy.... but it would only be once to add the modules metaport to the portgroup. After that, any updates to the modules metaport or to the ports it depends on would work normally. > Have the perl5 Portfile install the base p5's after perl5 > activation so the p5's dependency on perl5 is met. > I don't know if this can be done but it was my idea of how to have > the p5's as seperate ports but still be installed with perl5. It can't be done that way. It would have to be done the way Rainer suggested, having a metaport which installs both the perl5 port and the new modules metaport. Or by having the portgroup depend on the modules metaport. From ryandesign at macports.org Sat Mar 7 16:44:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 18:44:41 -0600 Subject: perl5.8 fixup In-Reply-To: <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> Message-ID: <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> On Mar 7, 2009, at 15:49, Bradley Giesbrecht wrote: > I don't know how useful perl is with no modules but it sounds good > to me to be able to install perl without them. > perl5.8-core sounds appealing. I don't think there's a desire to allow perl5 to be installed without the modules, but there is a desire to have each of those modules represented by its own port where it can be separately updated and maintained and depended upon. There will of course be pain in switching from a perl5.8 port which installs perl to a perl5.8 port which installs no files and depends on a perl5.8-core port which installs the same files that perl5.8 used to install. From ryandesign at macports.org Sat Mar 7 16:48:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 7 Mar 2009 18:48:42 -0600 Subject: [47804] trunk/dports/devel/cmake/Portfile In-Reply-To: <20090307230643.GF921@ninagal.withay.com> References: <20090306214916.5B90B1159AEF@beta.macosforge.org> <08210248-EF74-4B82-AA00-1F46B1B2A76B@mac.com> <20090307230643.GF921@ninagal.withay.com> Message-ID: On Mar 7, 2009, at 17:06, Bryan Blackburn wrote: > On Sat, Mar 07, 2009 at 05:50:09PM -0500, cssdev at mac.com said: > >> Could we enable the Trac pre-commit-hook[1] that requires commit >> messages >> to reference open tickets? There have been a number of recent >> commits to >> ports without references to tickets, and that makes it hard to dig >> through >> Trac to find the background info for a particular commit. That's >> annoying >> for ports I maintain, especially without either any contact with >> me or >> tickets filed in Trac. (There have been some timeouts too, but >> that's part >> of the process. :) >> >> I think we should require port commits to reference existing, open >> Trac >> tickets. > > For all commits? That would be horrible, then I'd have to create a > ticket > every time I wanted to update my own ports as well. > > For other's ports? Then the hook would need to be smart, checking > maintainers, referencing that against the committer (and some > people may use > different accounts), as well as filtering out for openmaintainer... > > Considering that all you have to do is revert the commit, verses > the amount > of work this would entail for something that really doesn't happen too > frequently, doesn't seem like the best choice. After a little consideration I have to agree with Bryan. There are many times when I want to fix a port's whitespace, or fix a typo in a comment, or make another minor modification for which there's no ticket. Forcing me to make a ticket every time would be annoying. I agree there are some commits that have occurred without tickets where tickets would have been desirable, but I think the disadvantages of using this hook outweigh its benefits for MacPorts. From mcalhoun at macports.org Sat Mar 7 17:00:35 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Sun, 8 Mar 2009 01:00:35 +0000 (UTC) Subject: perl5.8 fixup References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> Message-ID: Ryan Schmidt writes: > On Mar 7, 2009, at 15:49, Bradley Giesbrecht wrote: > > > I don't know how useful perl is with no modules but it sounds good > > to me to be able to install perl without them. > > perl5.8-core sounds appealing. > > I don't think there's a desire to allow perl5 to be installed without > the modules, If I understand http://trac.macports.org/ticket/12710#comment:10 correctly, some modules are required. Please forgive me, but I am having a little trouble understanding what is being proposed with this meta-port suggestion. >but there is a desire to have each of those modules > represented by its own port where it can be separately updated and > maintained and depended upon. Isn't that what we have now? > > There will of course be pain in switching from a perl5.8 port which > installs perl to a perl5.8 port which installs no files and depends > on a perl5.8-core port which installs the same files that perl5.8 > used to install. If I understand what is being discussed (please correct me if I'm wrong), we would * copy perl5.8 -> perl5.8-core. * create a port which installs all the core p5 ports. * make perl5.8 do nothing except depend on perl5.8-core and the new p5 umbrella port. It seems that this does not buy us anything, so I fear I am missing something. -Marcus From illogical1 at gmail.com Sat Mar 7 17:08:29 2009 From: illogical1 at gmail.com (Orville Bennett) Date: Sat, 7 Mar 2009 20:08:29 -0500 Subject: [47804] trunk/dports/devel/cmake/Portfile In-Reply-To: <08210248-EF74-4B82-AA00-1F46B1B2A76B@mac.com> References: <20090306214916.5B90B1159AEF@beta.macosforge.org> <08210248-EF74-4B82-AA00-1F46B1B2A76B@mac.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 7, 2009, at 5:50 PM, cssdev at mac.com wrote: > On Mar 7, 2009, at 4:11 AM, Ryan Schmidt wrote: > >> On Mar 6, 2009, at 15:49, toby at macports.org wrote: >> >>> Revision: 47804 >>> http://trac.macports.org/changeset/47804 >>> Author: toby at macports.org >>> Date: 2009-03-06 13:49:15 -0800 (Fri, 06 Mar 2009) >>> Log Message: >>> ----------- >>> cmake 2.6.3 >> >> [snip] >> >> Did the maintainer approve this update, or was there a ticket filed >> to which the maintainer did not respond within 72 hours? I was about to say this change was fine by me, but then realized: I'm not the maintainer! Ha. *ahem* I'll go back to my room now. > > Neither. I've been checking some other build issues with CMake, but > I would prefer that we follow the procedure of creating tickets, > assigning them to maintainers, and referencing them in commit > messages. > > Could we enable the Trac pre-commit-hook[1] that requires commit > messages to reference open tickets? There have been a number of > recent commits to ports without references to tickets, and that > makes it hard to dig through Trac to find the background info for a > particular commit. That's annoying for ports I maintain, especially > without either any contact with me or tickets filed in Trac. (There > have been some timeouts too, but that's part of the process. :) > > I think we should require port commits to reference existing, open > Trac tickets. > > Chris > > [1]: http://trac.edgewall.org/browser/trunk/contrib/trac-pre-commit-hook > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmzGo0ACgkQ2yWVgjgEOKQcnQCglCsRXnet66Vi0y/WKD61jCZ3 0lQAoKUeJ6/3ss00gN5tcR3VtbGgjvFn =lV5j -----END PGP SIGNATURE----- From brad at pixilla.com Sat Mar 7 18:25:43 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sat, 7 Mar 2009 18:25:43 -0800 Subject: perl5.8 fixup In-Reply-To: References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> Message-ID: On Mar 7, 2009, at 5:00 PM, Marcus Calhoun-Lopez wrote: > Ryan Schmidt writes: > >> On Mar 7, 2009, at 15:49, Bradley Giesbrecht wrote: >> >>> I don't know how useful perl is with no modules but it sounds good >>> to me to be able to install perl without them. >>> perl5.8-core sounds appealing. >> >> I don't think there's a desire to allow perl5 to be installed without >> the modules, > If I understand http://trac.macports.org/ticket/12710#comment:10 > correctly, some modules are required. > > Please forgive me, but I am having a little trouble understanding > what is being proposed with this meta-port suggestion. > >> but there is a desire to have each of those modules >> represented by its own port where it can be separately updated and >> maintained and depended upon. > Isn't that what we have now? No, that's the problem. I removed and reinstalled macports. I only installed perl5.8. There are somewhere near a hundred perl pm files installed before installing one p5. Some of those modules are evidently too to work with other modules so people have added same module as a p5 port. But these p5 installs write to the same pm files and/or man pages and those files are registered to perl5.8 so you have to -f the p5 install. Then a bunch of other p5 ports put dependencies on these conflicting p5 ports so it because most common to have to -f p5 installs. At least thats been my experience . >> >> There will of course be pain in switching from a perl5.8 port which >> installs perl to a perl5.8 port which installs no files and depends >> on a perl5.8-core port which installs the same files that perl5.8 >> used to install. > > If I understand what is being discussed (please correct me if I'm > wrong), > we would > * copy perl5.8 -> perl5.8-core. > * create a port which installs all the core p5 ports. > * make perl5.8 do nothing except depend on perl5.8-core and the > new p5 umbrella port. > > It seems that this does not buy us anything, so I fear I am missing > something. It buys us perl modules as p5 ports that used to be part of perl5. This allows us to update those p5 ports to newer required versions without having to have a perl5 revision increment and upgrade perl5. I suppose getting rid of all the conflicting p5 ports and just updating perl5 everytime someone needs a newer version of a p5 could work. Here is an example I believe is true and common. Looks like these p5 ports depend on p5-test-simple which appears to be part of perl5.8 base. So all of these p5 modules require -f to install. p5-calendar-simple p5-curses-ui p5-dbix-class p5-gearman-client-async p5-html-scrubber p5-log-dispatch p5-mac-errors p5-math-bigint p5-moose p5-return-value p5-test-exception p5-test-longstring p5-test-memory-cycle p5-test-object p5-test-pod p5-test-pod-coverage p5-test-www-mechanize p5-text-wikiformat Going from the file system /opt/local/lib/perl5 and globbing *.pm and *.pm/*.pm I came up with this. I'm sure it's not entirely accurate but I've found a number of conflicting p5's using this list. I put it in sql and also loaded the list of p5 and joined them to get the p5-test conflicts. p5-AnyDBM_File p5-AutoLoader p5-AutoSplit p5-Benchmark p5-CGI p5-CGI-Apache p5-CGI-Carp p5-CGI-Cookie p5-CGI-Fast p5-CGI-Pretty p5-CGI-Push p5-CGI-Switch p5-CGI-Util p5-CPAN p5-CPAN-Debug p5-CPAN-DeferedCode p5-CPAN-Distroprefs p5-CPAN-FirstTime p5-CPAN-HandleConfig p5-CPAN-Kwalify p5-CPAN-Nox p5-CPAN-Queue p5-CPAN-Tarzip p5-CPAN-Version p5-Carp p5-Carp-Heavy p5-DB p5-DBM_Filter p5-DBM_Filter-compress p5-DBM_Filter-encode p5-DBM_Filter-int32 p5-DBM_Filter-null p5-DBM_Filter-utf8 p5-Digest p5-Digest-base p5-Digest-file p5-DirHandle p5-Dumpvalue p5-English p5-Env p5-Exporter p5-Exporter-Heavy p5-Fatal p5-FileCache p5-FileHandle p5-FindBin p5-Memoize p5-Memoize-AnyDBM_File p5-Memoize-Expire p5-Memoize-ExpireFile p5-Memoize-ExpireTest p5-Memoize-NDBM_File p5-Memoize-SDBM_File p5-Memoize-Storable p5-NEXT p5-PerlIO p5-SelectSaver p5-SelfLoader p5-Shell p5-Switch p5-Symbol p5-Test p5-Test-Builder p5-Test-Harness p5-Test-More p5-Test-Simple p5-Thread p5-Thread-Queue p5-Thread-Semaphore p5-UNIVERSAL p5-attributes p5-autouse p5-base p5-bigint p5-bignum p5-bigrat p5-blib p5-bytes p5-charnames p5-constant p5-diagnostics p5-fields p5-filetest p5-if p5-integer p5-less p5-locale p5-locale-Constants p5-locale-Country p5-locale-Currency p5-locale-Language p5-locale-Maketext p5-locale-Script p5-open p5-overload p5-sigtrap p5-sort p5-strict p5-subs p5-utf8 p5-vars p5-vmsish p5-warnings p5-warnings-register Some of these may not actually be perl modules but they do end with .pm. Like I have said repeatedly, I'm no perl expert but I AM willing to help make p5 -f a thing of the past. //Brad From mcalhoun at macports.org Sat Mar 7 18:41:50 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Sun, 8 Mar 2009 02:41:50 +0000 (UTC) Subject: perl5.8 fixup References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> Message-ID: Bradley Giesbrecht writes: Thank you for the clarification. > > If I understand what is being discussed (please correct me if I'm > > wrong), > > we would > > * copy perl5.8 -> perl5.8-core. > > * create a port which installs all the core p5 ports. > > * make perl5.8 do nothing except depend on perl5.8-core and the > > new p5 umbrella port. > > > > It seems that this does not buy us anything, so I fear I am missing > > something. > > It buys us perl modules as p5 ports that used to be part of perl5. > This allows us to update those p5 ports to newer required versions > without having to have a perl5 revision increment and upgrade perl5. It seems it would only do that if the @INC variable were modified or conflicting modules pruned from perl5.8. I would suggest that these goals could be accomplished more easily by the following (sorry for the duplication from an earlier message): * Modify @INC so the newer p5 ports are found first. * Do not add conflicting p5 port as dependencies unless the newer version is actually required (mitigate the potential problems). * Prepend p5- to the conflicting man pages. * Modify the -f p5 ports so they no longer install in the directory perl reserves for itself. This would require a minor change to perl5.8, a few minor changes to "-f" p5 ports and some cleanup to minimize dependencies. -Marcus From raimue at macports.org Sat Mar 7 21:09:52 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 08 Mar 2009 06:09:52 +0100 Subject: perl5.8 fixup In-Reply-To: References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> Message-ID: <49B35320.8060706@macports.org> Marcus Calhoun-Lopez wrote: > If I understand what is being discussed (please correct me if I'm wrong), > we would > * copy perl5.8 -> perl5.8-core. > * create a port which installs all the core p5 ports. Missing step: * Remove the conflicting modules from the perl5.8-core port > * make perl5.8 do nothing except depend on perl5.8-core and the new p5 umbrella port. > > It seems that this does not buy us anything, so I fear I am missing something. It allows to update/install p5-* ports without touching perl5.8-core, as they are no longer part of this port. I have to say, I did not test if this would work at all. Our install mechanism for p5-* requires a working perl, but I am not sure if perl5.8-core without modules would be enough for it to work. Testing required. Rainer From brad at pixilla.com Sat Mar 7 21:54:23 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sat, 7 Mar 2009 21:54:23 -0800 Subject: perl5.8 fixup In-Reply-To: References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> Message-ID: <7197DA2C-BC6B-44FF-87CE-54C9B7767118@pixilla.com> From what I have gathered from parsing the file system and p5 ports these are the conflicting ports: bash-3.2# cat perl58_meta_p5_module_list.txt p5-cgi p5-digest p5-next p5-test-harness p5-test-simple Using that list and this script which I think gets the job done more or less: bash-3.2# cat perl58_meta_p5_module_dep.sh #!/bin/sh echo perl5_meta_p5,p5_dep while read p5_name; do for p5_dep in $(port echo depends_lib:$p5_name[^-]); do echo $p5_name,$p5_dep done done < perl58_meta_p5_module_list.txt It looks like these are the only ports that are depending on these p5 ports directly: perl5_meta_p5,p5_dep p5-cgi,bugzilla p5-cgi,ikiwiki p5-cgi,monarch p5-cgi,sympa p5-digest,p5-net p5-test-simple,p5-curses-ui p5-test-simple,p5-dbix-class p5-test-simple,p5-moose p5-test-simple,p5-test-exception p5-test-simple,p5-test-memory-cycle If I nest the for loop in the script 5 times I end up with 66 ports depending directly or indirectly on those 5 conflicting p5 ports. If I'm close to correct, another approach that is not as slick as moving all the perl5 modules into p5 ports, but possibly much easier on porters and users, would be to remove the 5 or so p5 ports that are the root of the problem. Then remove those 5 or so p5 ports as dependancies for the 10 or so ports that depend on them. If any ports require a newer perl module then is installed by and registered to the perl58 port let the port author of that needs the newer module contact the maintainers of perl58 resolve the issure in the normal macports way. Have the perl58 port handle the update of the modules registered to it. And if for some reason the perl58 port can't upgrade the modules registered to it then let the port author include the newer module IN THEIR port and not put it in the path of the perl58 module. I'm willing to bet this can be done without much difficulty. Doesn't this sound right? Seems a lot less painful and probably doesn't break as much stuff nor require as much testing as moving all perl58 mods to p5's. Just an idea my friends. //Brad From brad at pixilla.com Sat Mar 7 22:06:33 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sat, 7 Mar 2009 22:06:33 -0800 Subject: perl5.8 fixup In-Reply-To: References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> Message-ID: <4DF5B819-92C8-49A5-B276-0CCE2319D1B2@pixilla.com> On Mar 7, 2009, at 6:41 PM, Marcus Calhoun-Lopez wrote: > Bradley Giesbrecht writes: > > Thank you for the clarification. > >>> If I understand what is being discussed (please correct me if I'm >>> wrong), >>> we would >>> * copy perl5.8 -> perl5.8-core. >>> * create a port which installs all the core p5 ports. >>> * make perl5.8 do nothing except depend on perl5.8-core and the >>> new p5 umbrella port. >>> >>> It seems that this does not buy us anything, so I fear I am missing >>> something. >> >> It buys us perl modules as p5 ports that used to be part of perl5. >> This allows us to update those p5 ports to newer required versions >> without having to have a perl5 revision increment and upgrade perl5. > > It seems it would only do that if the @INC variable were modified > or conflicting modules pruned from perl5.8. > > I would suggest that these goals could be accomplished more easily > by the following (sorry for the duplication from an earlier message): > * Modify @INC so the newer p5 ports are found first. > * Do not add conflicting p5 port as dependencies unless the newer > version is > actually required (mitigate the potential problems). > * Prepend p5- to the conflicting man pages. > * Modify the -f p5 ports so they no longer install in the directory > perl reserves for itself. > > This would require a minor change to perl5.8, a few minor > changes to "-f" p5 ports and some cleanup to minimize dependencies. Marcus, you seem to know perl much better then me. Please check out my last post on this subject. Is there any reason perl58 modules couldn't be upgraded to the newer version? If they could not, for the few ports that need the newer modules, couldn't those ports install the modules to a non-perl58 path and patch there port in one way or another to find the module they need? Seems this way the non-perl58 modules don't even need to be in the users @INC because the only port that needs it is going to include it in a non-standard place where it won't be found by other perl scripts. And no man pages would need to be installed so the man for the current perl58 module in @INC would be accurate for anyone who wanted to use the module. //Brad From markd at macports.org Sat Mar 7 22:59:28 2009 From: markd at macports.org (markd at macports.org) Date: Sat, 07 Mar 2009 22:59:28 -0800 Subject: The Guide - again Message-ID: >Message: 5 >Date: Sat, 07 Mar 2009 21:33:20 +0100 >From: Rainer M?ller >Subject: Re: The Guide - again >To: Ryan Schmidt >Cc: MacPorts Development >Message-ID: <49B2DA10.8050008 at macports.org> >Content-Type: text/plain; charset=ISO-8859-1 > >Ryan Schmidt wrote: >> I do not believe that we need to separate these into different >> documents because there is overlap between these different peoples' >> needs. We could do a better job of indicating which sections are for >> which audience, or rearranging sections in the guide to group things >> by audience. Hi Ranier, I think the distinction between types of users for documentation is problematic. But chunking documents into "topics" and assembling them into various docs as needed would at least allow it in theory. It is called DITA. Another XML standard. I know, ugh. But I just don't see how we can ditch XML and still do what we need to do. http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture But the guide is not complete yet. This summer I intend to make a final push to do it. Of course it will never be finished, but the big missing pieces can be filled in, and then sourcing the man pages out of it can happen. > >I don't like the fact that the guide is one huge document. We discussed >splitting the guide into single pages ('chunked' in docbook terms) >before, but the majority was against it. In my opinion it would at least >make sense to split the guide into pages each of them relevant for >users, maintainers, base hackers. > >There is the MacPorts Internals documentation (API, registry etc.) which >is not interesting for anyone else than base hackers. Maybe it should >not be in the guide at all, but live in the repository as plain text only. As Ryan mentioned, there is the chunked version. It could be that the internals section and the project section doesn't belong, and I think after finishing the major parts this summer we could discuss that as a "where do we want our docs to go now" discussion. > >> I do not believe we need to move all or part of the guide to the >> wiki. Quite the opposite: documentation that's getting created in the >> wiki should get moved to the guide. > >To be honest, editing the guide sucks. Contributing to the wiki is much >easier. > >Especially if the concern is the guide being outdated, I see the problem >in the guide format. We had the recent discussion to move the guide to >another markup language but it was teared down. What else can we do to >attract more people for writing documentation? But if we have more than a few people contributing anything other than incremental changes, we'd need to use the formal approval process we've already talked about. So I don't see how that solves anything. There is a natural tendency for people to throw all kinds of stuff into documents just because they can. I use text files in Textedit to flesh out documents and document structure so I don't understand why this is not acceptable to do this or any other technique and post it for review. Contributions don't need to be in XML. Mark From jmr at macports.org Sat Mar 7 23:48:43 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 08 Mar 2009 18:48:43 +1100 Subject: perl5.8 fixup In-Reply-To: <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> Message-ID: <49B3785B.9050402@macports.org> Ryan Schmidt wrote: > > On Mar 7, 2009, at 15:49, Bradley Giesbrecht wrote: > >> I don't know how useful perl is with no modules but it sounds good to >> me to be able to install perl without them. >> perl5.8-core sounds appealing. > > I don't think there's a desire to allow perl5 to be installed without > the modules, but there is a desire to have each of those modules > represented by its own port where it can be separately updated and > maintained and depended upon. > > There will of course be pain in switching from a perl5.8 port which > installs perl to a perl5.8 port which installs no files and depends on a > perl5.8-core port which installs the same files that perl5.8 used to > install. Not least of which will be the creation of circular dependencies in the registry, with perl5.8 depending on ports that used to depend on it. - Josh From blair at orcaware.com Sun Mar 8 04:09:20 2009 From: blair at orcaware.com (Blair Zajac) Date: Sun, 8 Mar 2009 04:09:20 -0700 Subject: [47804] trunk/dports/devel/cmake/Portfile In-Reply-To: References: <20090306214916.5B90B1159AEF@beta.macosforge.org> <08210248-EF74-4B82-AA00-1F46B1B2A76B@mac.com> <20090307230643.GF921@ninagal.withay.com> Message-ID: On Mar 7, 2009, at 4:48 PM, Ryan Schmidt wrote: > On Mar 7, 2009, at 17:06, Bryan Blackburn wrote: > >> On Sat, Mar 07, 2009 at 05:50:09PM -0500, cssdev at mac.com said: >> >>> Could we enable the Trac pre-commit-hook[1] that requires commit >>> messages >>> to reference open tickets? There have been a number of recent >>> commits to >>> ports without references to tickets, and that makes it hard to dig >>> through >>> Trac to find the background info for a particular commit. That's >>> annoying >>> for ports I maintain, especially without either any contact with >>> me or >>> tickets filed in Trac. (There have been some timeouts too, but >>> that's part >>> of the process. :) >>> >>> I think we should require port commits to reference existing, open >>> Trac >>> tickets. >> >> For all commits? That would be horrible, then I'd have to create a >> ticket >> every time I wanted to update my own ports as well. >> >> For other's ports? Then the hook would need to be smart, checking >> maintainers, referencing that against the committer (and some >> people may use >> different accounts), as well as filtering out for openmaintainer... >> >> Considering that all you have to do is revert the commit, verses >> the amount >> of work this would entail for something that really doesn't happen >> too >> frequently, doesn't seem like the best choice. > > After a little consideration I have to agree with Bryan. There are > many times when I want to fix a port's whitespace, or fix a typo in > a comment, or make another minor modification for which there's no > ticket. Forcing me to make a ticket every time would be annoying. I > agree there are some commits that have occurred without tickets > where tickets would have been desirable, but I think the > disadvantages of using this hook outweigh its benefits for MacPorts. +1. A little too much process there. The commit message should fully describe the change if there's no Trac ticket then. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From florian.ebeling at gmail.com Sun Mar 8 04:48:20 2009 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Sun, 8 Mar 2009 12:48:20 +0100 Subject: The Guide - again In-Reply-To: References: Message-ID: <5cbbe4ae0903080448h288ea4dau86700e25585ffef3@mail.gmail.com> >>> I do not believe that we need to separate these into different >>> documents because there is overlap between these different peoples' >>> needs. We could do a better job of indicating which sections are for >>> which audience, or rearranging sections in the guide to group things >>> by audience. > > I think the distinction between types of users for documentation is > problematic. ?But chunking documents into "topics" and assembling them > into various docs as needed would at least allow it in theory. ?It is > called DITA. ?Another XML standard. ?I know, ugh. ?But I just don't see > how we can ditch XML and still do what we need to do. > http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture So DITA is a OASIS-approved standard originating with IBM for doing documentation? Is there any reason to handle this with IBM-style complexity? > But the guide is not complete yet. ?This summer I intend to make a final > push to do it. ?Of course it will never be finished, but the big missing > pieces can be filled in, and then sourcing the man pages out of it can > happen. To me it would appear sensible to try to pull in more people into this endeavor. Otherwise you as a single final editor may easily become over capacity. One thing that might help with this would be to define "complete" for the guide? >>I don't like the fact that the guide is one huge document. We discussed >>splitting the guide into single pages ('chunked' in docbook terms) >>before, but the majority was against it. In my opinion it would at least >>make sense to split the guide into pages each of them relevant for >>users, maintainers, base hackers. >> >>There is the MacPorts Internals documentation (API, registry etc.) which >>is not interesting for anyone else than base hackers. Maybe it should >>not be in the guide at all, but live in the repository as plain text only. > > As Ryan mentioned, there is the chunked version. ?It could be that the > internals section and the project section doesn't belong, and I think > after finishing the major parts this summer we could discuss that as a > "where do we want our docs to go now" discussion. >> >>> I do not believe we need to move all or part of the guide to the >>> wiki. Quite the opposite: documentation that's getting created in the >>> wiki should get moved to the guide. >> >>To be honest, editing the guide sucks. Contributing to the wiki is much >>easier. >> >>Especially if the concern is the guide being outdated, I see the problem >>in the guide format. We had the recent discussion to move the guide to >>another markup language but it was teared down. What else can we do to >>attract more people for writing documentation? > > But if we have more than a few people contributing anything other than > incremental changes, we'd need to use the formal approval process we've > already talked about. ?So I don't see how that solves anything. ?There is > a natural tendency ?for people to throw all kinds of stuff into documents > just because they can. I don't think that macports committers would handle guide changes that mindlessly. And also there is this other pattern, at wikipedia and other places with the similar problem: some "expert" types throw in reliable content using sluggish markup, only to give room to "editors" who bring the detailed content into shiny shape. We could aim at something similar as well and see how good that works. So in my opinion this process of doc writing should not become a closed thing. It is a bit, because of the tools in place, but we should not go and even embrace that closedness. >?I use text files in Textedit to flesh out > documents and document structure so I don't understand why this is not > acceptable to do this or any other technique and post it for review. > Contributions don't need to be in XML. No offense, but that sounds quite unefficient. I mean I find it great that you offer to do all this work. But if much of it can be avoided, than that should probably happen. There are tools where you can avoid drafting in plain text and then go into the "documentation IDE" to "implement" it. Florian -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From krischik at macports.org Sun Mar 8 05:18:40 2009 From: krischik at macports.org (Martin Krischik) Date: Sun, 08 Mar 2009 13:18:40 +0100 Subject: The Guide - again In-Reply-To: References: <49B23133.1000908@macports.org> Message-ID: <49B3B7A0.6000600@macports.org> Ryan Schmidt schrieb: > If there are specific things missing from the guide, please file tickets > requesting that documentation. Please file tickets for any issues you > have with the guide content, in fact, including suggestions for > rearranging or whatever. I don't know - writing tickets with new ports attached did not work all that well. Why should tickets which new documentation attached be any better? Martin -- Martin Krischik mailto://krischik at macports.org http://trac.macports.org/wiki/krischik From krischik at macports.org Sun Mar 8 05:22:22 2009 From: krischik at macports.org (Martin Krischik) Date: Sun, 08 Mar 2009 13:22:22 +0100 Subject: The Guide - again In-Reply-To: <20090307230233.GE921@ninagal.withay.com> References: <49B23133.1000908@macports.org> <20090307230233.GE921@ninagal.withay.com> Message-ID: <49B3B87E.1080900@macports.org> Bryan Blackburn schrieb: > Starting new items on the wiki makes sense, but if it really should be in > the guide, then once it's been fleshed out it should be moved over to the > guide. This way the ease of the wiki can be used until it's (hopefully) > good enough then can be put in the guide, since that's what we usually point > to for documentation. That would be an idea and could well work out nicely. Martin -- Martin Krischik mailto://krischik at macports.org http://trac.macports.org/wiki/krischik From ryandesign at macports.org Sun Mar 8 09:01:57 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 8 Mar 2009 11:01:57 -0500 Subject: [47741] trunk/dports/audio/mpg123/Portfile In-Reply-To: <4B5CBE26-0F8F-4828-B4DB-452CD3B6412D@gmx.at> References: <20090304212316.50795113A370@beta.macosforge.org> <2ACFC064-1402-4310-BE66-CE2528F926F1@macports.org> <15B7177D-E88A-4C77-9A1B-07954668F8FD@gmx.at> <22624938-D0E8-4C75-8A23-5F45961C200A@macports.org> <4B5CBE26-0F8F-4828-B4DB-452CD3B6412D@gmx.at> Message-ID: <3B1CA9C3-AFA7-48C8-BAF0-ECCA31E6E387@macports.org> On Mar 8, 2009, at 05:51, Andreas Neustifter wrote: > On 07.03.2009, at 19:44, Ryan Schmidt wrote: > >> On Mar 7, 2009, at 08:22, Andreas Neustifter wrote: >> >>> On 07.03.2009, at 10:19, Ryan Schmidt wrote: >>> >>>> Did the maintainer approve these update, or was there a ticket >>>> filed to which the maintainer did not respond? We do have a >>>> policy of allowing a port maintainer 72 hours to respond to port >>>> issues, and if they do not do so, then you may commit updates, >>>> but should indicate in your commit message that the maintainer >>>> timeout has occurred, or that the maintainer has approved your >>>> commit, unless such things are clear from the ticket whose >>>> number your commit message references. >>> >>> I must admit that it was maybe a little ambitious to enter me as >>> maintainer, I will try to improve my response times. >> >> I was mostly just concerned with whether you had been asked about >> this change before it was made, since you are listed as its >> maintainer. If you would like we can add "openmaintainer" to >> mpg123, to indicate that anyone should feel free to update the >> port without asking you. Or we can keep it the way it is if you'd >> like to continue to have the first say in what goes on with the port. > > openmaintainer ist fine with me. Done in r47851. >>> The 1.6.4 builds and works (with a small test sample) on PowerPC, >>> I do not have a x86 machine to test. >> >> I tried it and it builds and correctly plays an mp3 on my MacBook >> Pro on Tiger. > Would you mind checking the config.log if the CPU optimisation is > dedected properly for x86? Then its possible to drop the platform > dependent sections alltogether and have a easy and nice to maintain > port. I'm not sure what I'm looking for so I'm attaching the config.log so you can have a look. -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.zip Type: application/zip Size: 12230 bytes Desc: not available URL: From ryandesign at macports.org Sun Mar 8 09:09:09 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 8 Mar 2009 11:09:09 -0500 Subject: The Guide - again In-Reply-To: <49B3B7A0.6000600@macports.org> References: <49B23133.1000908@macports.org> <49B3B7A0.6000600@macports.org> Message-ID: <90488D92-444F-4852-B916-46DEBC9B34A7@macports.org> On Mar 8, 2009, at 07:18, Martin Krischik wrote: > Ryan Schmidt schrieb: > >> If there are specific things missing from the guide, please file >> tickets >> requesting that documentation. Please file tickets for any issues you >> have with the guide content, in fact, including suggestions for >> rearranging or whatever. > > I don't know - writing tickets with new ports attached did not work > all > that well. That is our process. What about it didn't work well? > Why should tickets which new documentation attached be any > better? From ryandesign at macports.org Sun Mar 8 09:13:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 8 Mar 2009 11:13:02 -0500 Subject: perl5.8 fixup In-Reply-To: <49B3785B.9050402@macports.org> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> Message-ID: <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> On Mar 8, 2009, at 01:48, Joshua Root wrote: > Ryan Schmidt wrote: > >> On Mar 7, 2009, at 15:49, Bradley Giesbrecht wrote: >> >>> I don't know how useful perl is with no modules but it sounds >>> good to >>> me to be able to install perl without them. >>> perl5.8-core sounds appealing. >> >> I don't think there's a desire to allow perl5 to be installed without >> the modules, but there is a desire to have each of those modules >> represented by its own port where it can be separately updated and >> maintained and depended upon. >> >> There will of course be pain in switching from a perl5.8 port which >> installs perl to a perl5.8 port which installs no files and >> depends on a >> perl5.8-core port which installs the same files that perl5.8 used to >> install. > > Not least of which will be the creation of circular dependencies in > the > registry, with perl5.8 depending on ports that used to depend on it. So we may have to settle for a different name for the perl port, e.g. perl5.8meta. Also a mess to have to update that everywhere. But I guess we've already done it once recently with the perl5.8->perl5 switch. From ryandesign at macports.org Sun Mar 8 09:30:26 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 8 Mar 2009 11:30:26 -0500 Subject: The Guide - again In-Reply-To: References: Message-ID: On Mar 8, 2009, at 00:59, markd at macports.org wrote: >> Ryan Schmidt wrote: >>> I do not believe that we need to separate these into different >>> documents because there is overlap between these different peoples' >>> needs. We could do a better job of indicating which sections are for >>> which audience, or rearranging sections in the guide to group things >>> by audience. > > Hi Ranier, > > I think the distinction between types of users for documentation is > problematic. Problematic in what way? Do you mean you think it would be problematic to write the Guide to target different classes of users? Or do you mean you think users will currently find it problematic to identify which information in the Guide is applicable to them? I'm finding the latter. Here's how I see the Guide at this time w.r.t. what kind of person should read that section: 1. Introduction -- all users 2. Installing MacPorts -- all users 3. Using MacPorts -- all users 4. Portfile Development -- port maintainers 5. Portfile Reference -- port maintainers, except that regular users might well want to know about the different phases that MacPorts goes through to install a port; or that ports can have dependencies and what MacPorts does about that (i.e. it works out and installs the dependencies first in the correct order); or that ports can have startupitems and how that works 6. MacPorts Internals 6.1. File Hierarchy -- all users 6.2. Configuration Files -- advanced users 6.3. Port Images -- all users 6.4. APIs and Libs -- developers of GUI clients 6.5. The MacPorts Registry -- base developers 7. MacPorts Project -- all users 8. MacPorts Guide Terms Glossary -- no users (doesn't actually define any terms) From adambyrtek at gmail.com Sun Mar 8 09:30:45 2009 From: adambyrtek at gmail.com (Adam Byrtek) Date: Sun, 8 Mar 2009 17:30:45 +0100 Subject: Conventions when it comes to cron-like launchd items Message-ID: <670d23ff0903080930p6d6085a3gc79bb54b07110756@mail.gmail.com> I'm building a port file for Munin, an easy to use system monitoring tool. I'm almost done, everything works fine but before I submit a ticket I would like to make some final touches. I have two questions when it comes to this. 1. What is the policy when it comes to cron-like launchd items? The Guide covers only init.d-like launchd items. I've just created a launchd.plist with StartInterval and I symlink it to /Library/LaunchDaemons during post-activate. Should I invoke "launchdctl load" in the Portfile or should I inform the user that he should do this (like with standard launchd items)? I would prefer to do everything automatically if possible in order not to confuse users. 2. Munin consists of two components: munin-node that listens on a port and provides statistics and munin-server that polls every node every 5 minutes. Both are distributed in a single source distribution. I'm considering either creating two separate Portfiles (munin-server and munin-node) or using variants but in this case I'm not sure what variants to introduce. Any suggestions when it comes to this? Best regards, Adam -- Adam Byrtek From krischik at macports.org Sun Mar 8 09:51:24 2009 From: krischik at macports.org (Martin Krischik) Date: Sun, 08 Mar 2009 17:51:24 +0100 Subject: The Guide - again In-Reply-To: <90488D92-444F-4852-B916-46DEBC9B34A7@macports.org> References: <49B23133.1000908@macports.org> <49B3B7A0.6000600@macports.org> <90488D92-444F-4852-B916-46DEBC9B34A7@macports.org> Message-ID: <49B3F78C.20104@macports.org> Ryan Schmidt schrieb: > > On Mar 8, 2009, at 07:18, Martin Krischik wrote: > >> Ryan Schmidt schrieb: >> >>> If there are specific things missing from the guide, please file tickets >>> requesting that documentation. Please file tickets for any issues you >>> have with the guide content, in fact, including suggestions for >>> rearranging or whatever. >> >> I don't know - writing tickets with new ports attached did not work all >> that well. > > That is our process. What about it didn't work well? They sat there until I got commit right myself to apply them myself. Martin -- Martin Krischik mailto://krischik at macports.org http://trac.macports.org/wiki/krischik From jmr at macports.org Sun Mar 8 09:58:28 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 09 Mar 2009 03:58:28 +1100 Subject: [47741] trunk/dports/audio/mpg123/Portfile In-Reply-To: <3B1CA9C3-AFA7-48C8-BAF0-ECCA31E6E387@macports.org> References: <20090304212316.50795113A370@beta.macosforge.org> <2ACFC064-1402-4310-BE66-CE2528F926F1@macports.org> <15B7177D-E88A-4C77-9A1B-07954668F8FD@gmx.at> <22624938-D0E8-4C75-8A23-5F45961C200A@macports.org> <4B5CBE26-0F8F-4828-B4DB-452CD3B6412D@gmx.at> <3B1CA9C3-AFA7-48C8-BAF0-ECCA31E6E387@macports.org> Message-ID: <49B3F934.2050602@macports.org> Ryan Schmidt wrote: > On Mar 8, 2009, at 05:51, Andreas Neustifter wrote: >> Would you mind checking the config.log if the CPU optimisation is >> dedected properly for x86? Then its possible to drop the platform >> dependent sections alltogether and have a easy and nice to maintain port. > > I'm not sure what I'm looking for so I'm attaching the config.log so you > can have a look. The 'platform darwin i386' section was removed in r47740 because the port actually fails to link when --with-cpu=x86 is passed to configure: (from IRC on the 4th of March) - Josh From adambyrtek at gmail.com Sun Mar 8 10:16:35 2009 From: adambyrtek at gmail.com (Adam Byrtek) Date: Sun, 8 Mar 2009 18:16:35 +0100 Subject: Duplicate Perl 5.8 libraries Message-ID: <670d23ff0903081016vf51d3adp45a6b6eeb1bde85c@mail.gmail.com> When playing with dependencies for a new port that requires certain CPAN libraries I found out that there are multiple p5 ports containing libraries already included in perl5.8. I had this problem with the following ports: p5-time-hires p5-text-balanced p5-digest-md5 A sample error message looks like this: Target org.macports.activate returned: Image error: /opt/local/share/man/man3/Digest::MD5.3pm.gz is being used by the active perl5.8 port. Please deactivate this port first, or use the -f flag to force the activation. Does this duplications serve some purpose? If not, maybe those superfluous ports should be removed? This probably applies to more ports than just these mentioned above. Regards, Adam -- Adam Byrtek From raimue at macports.org Sun Mar 8 10:22:46 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 08 Mar 2009 18:22:46 +0100 Subject: Duplicate Perl 5.8 libraries In-Reply-To: <670d23ff0903081016vf51d3adp45a6b6eeb1bde85c@mail.gmail.com> References: <670d23ff0903081016vf51d3adp45a6b6eeb1bde85c@mail.gmail.com> Message-ID: <49B3FEE6.1000803@macports.org> Adam Byrtek wrote: > When playing with dependencies for a new port that requires certain > CPAN libraries I found out that there are multiple p5 ports containing > libraries already included in perl5.8. I had this problem with the > following ports: > p5-time-hires > p5-text-balanced > p5-digest-md5 Please see the recent thread "perl5.8 fixup" where exactly this problem is currently discussed. Subject: perl5.8 fixup From: Bradley Giesbrecht Date: Tue Mar 3 16:22:12 PST 2009 Archive: http://lists.macosforge.org/pipermail/macports-dev/2009-March/007594.html As of now, the only way to solve this is to use -f on activation. Rainer From raimue at macports.org Sun Mar 8 10:32:41 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 08 Mar 2009 18:32:41 +0100 Subject: Conventions when it comes to cron-like launchd items In-Reply-To: <670d23ff0903080930p6d6085a3gc79bb54b07110756@mail.gmail.com> References: <670d23ff0903080930p6d6085a3gc79bb54b07110756@mail.gmail.com> Message-ID: <49B40139.4000402@macports.org> Adam Byrtek wrote: > 1. What is the policy when it comes to cron-like launchd items? The > Guide covers only init.d-like launchd items. I've just created a > launchd.plist with StartInterval and I symlink it to > /Library/LaunchDaemons during post-activate. Should I invoke > "launchdctl load" in the Portfile or should I inform the user that he > should do this (like with standard launchd items)? I would prefer to > do everything automatically if possible in order not to confuse users. Please do not symlink it in post-activate, but make a copy/symlink in destroot already. Otherwise this symlink is not registered with the port and will not be removed on uninstall. In my opinion new installed services/daemons should not be started automatically. Most services need configuration and users should configure them first. Print a message how to load the LaunchDaemon in post-install (later as of 1.8.0 it can use the upcoming notes feature). Also note that post-activate is only run after 'port install', not on deactivate/activate later (#18273 [1]). > 2. Munin consists of two components: munin-node that listens on a port > and provides statistics and munin-server that polls every node every 5 > minutes. Both are distributed in a single source distribution. I'm > considering either creating two separate Portfiles (munin-server and > munin-node) or using variants but in this case I'm not sure what > variants to introduce. Any suggestions when it comes to this? As they are distributed in separate sources, it is much easier to create two ports. In this case, the long_description should recommend each other. Rainer [1] http://trac.macports.org/ticket/18273 From raimue at macports.org Sun Mar 8 11:00:35 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 08 Mar 2009 19:00:35 +0100 Subject: The Guide - again In-Reply-To: <44D98670-1600-4587-B804-360BD7699873@macports.org> References: <49B23133.1000908@macports.org> <49B2DA10.8050008@macports.org> <44D98670-1600-4587-B804-360BD7699873@macports.org> Message-ID: <49B407C3.9030007@macports.org> Ryan Schmidt wrote: >> Especially if the concern is the guide being outdated, I see the >> problem >> in the guide format. We had the recent discussion to move the guide to >> another markup language but it was teared down. What else can we do to >> attract more people for writing documentation? > > We don't want more people writing the Guide. It should stay as a > coherent document authored by one or a few individuals who have a > handle on the whole thing. I want more people writing the guide :-) At least I count some TODOs in the guide which are probably there for as long as I use MacPorts. Missing/Incomplete: * Some Tcl extensions * Global variant descriptions * /usr/local and its breakage * More about port groups * portindex * *-devel ports * It needs to be synchronized/merged with InstallingMacPorts [1] and UsingMacPortsQuickStart [2]. For most of these items have corresponding Trac tickets [3], some of them older than a year. >From this list it is clear for me that the current team of guide editors is not able to catch up. Don't understand me wrong, I appreciate the time investment and contributions from anyone, I just think we need to make it possible for more people to contribute to the guide. The open source contributors count on Mac OS X is very low in my opinion, so in order to attract more contributors we need to lower barriers. Rainer [1] http://trac.macports.org/wiki/InstallingMacPorts [2] http://trac.macports.org/wiki/UsingMacPortsQuickStart [3] http://trac.macports.org/query?status=assigned&status=new&status=reopened&group=status&component=guide&order=priority&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version From adambyrtek at gmail.com Sun Mar 8 11:15:24 2009 From: adambyrtek at gmail.com (Adam Byrtek) Date: Sun, 8 Mar 2009 19:15:24 +0100 Subject: Conventions when it comes to cron-like launchd items In-Reply-To: <49B40139.4000402@macports.org> References: <670d23ff0903080930p6d6085a3gc79bb54b07110756@mail.gmail.com> <49B40139.4000402@macports.org> Message-ID: <670d23ff0903081115o49d7f804of21d2a978f05fbaf@mail.gmail.com> On Sun, Mar 8, 2009 at 18:32, Rainer M?ller wrote: > Please do not symlink it in post-activate, but make a copy/symlink in > destroot already. Otherwise this symlink is not registered with the port > and will not be removed on uninstall. Thanks, sounds like a better idea. > In my opinion new installed services/daemons should not be started > automatically. Most services need configuration and users should > configure them first. Just to be sure, we are not speaking about service/daemon here, rather a cron-like recurring task. Is there any policy/convention/precedent when it comes to registering such recurring tasks by ports? >> 2. Munin consists of two components: munin-node that listens on a port >> and provides statistics and munin-server that polls every node every 5 >> minutes. Both are distributed in a single source distribution. I'm >> considering either creating two separate Portfiles (munin-server and >> munin-node) or using variants but in this case I'm not sure what >> variants to introduce. Any suggestions when it comes to this? > > As they are distributed in separate sources, it is much easier to create > two ports. In this case, the long_description should recommend each other. Looks like I wasn't clear enough, by "both are distributed in a single source distribution" I meant there is only one source archive for both :) Best regards, Adam -- Adam Byrtek From adambyrtek at gmail.com Sun Mar 8 11:25:54 2009 From: adambyrtek at gmail.com (Adam Byrtek) Date: Sun, 8 Mar 2009 19:25:54 +0100 Subject: Duplicate Perl 5.8 libraries In-Reply-To: <49B3FEE6.1000803@macports.org> References: <670d23ff0903081016vf51d3adp45a6b6eeb1bde85c@mail.gmail.com> <49B3FEE6.1000803@macports.org> Message-ID: <670d23ff0903081125u450225b6kc8198569568caea@mail.gmail.com> On Sun, Mar 8, 2009 at 18:22, Rainer M?ller wrote: > Please see the recent thread "perl5.8 fixup" where exactly this problem > is currently discussed. Sorry, I should have checked first (blush). I will track the thread then! Regards, Adam -- Adam Byrtek From raimue at macports.org Sun Mar 8 11:38:59 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 08 Mar 2009 19:38:59 +0100 Subject: Conventions when it comes to cron-like launchd items In-Reply-To: <670d23ff0903081115o49d7f804of21d2a978f05fbaf@mail.gmail.com> References: <670d23ff0903080930p6d6085a3gc79bb54b07110756@mail.gmail.com> <49B40139.4000402@macports.org> <670d23ff0903081115o49d7f804of21d2a978f05fbaf@mail.gmail.com> Message-ID: <49B410C3.20901@macports.org> Adam Byrtek wrote: > Just to be sure, we are not speaking about service/daemon here, rather > a cron-like recurring task. Is there any policy/convention/precedent > when it comes to registering such recurring tasks by ports? I don't see much difference for a service/daemon and a recurring task. I don't think there is any convention. I would prefer not to have anything running on my machine which I did not start epxlicitly - whether it's a daemon or a cron-like task. >>> 2. Munin consists of two components: munin-node that listens on a port >>> and provides statistics and munin-server that polls every node every 5 >>> minutes. Both are distributed in a single source distribution. I'm >>> considering either creating two separate Portfiles (munin-server and >>> munin-node) or using variants but in this case I'm not sure what >>> variants to introduce. Any suggestions when it comes to this? >> As they are distributed in separate sources, it is much easier to create >> two ports. In this case, the long_description should recommend each other. > > Looks like I wasn't clear enough, by "both are distributed in a single > source distribution" I meant there is only one source archive for both > :) Ah, sorry. I read that as 'each are distributed in a single source distribution' :-) As far as I know it is common to start munin-server on one machine and others report to this using munin-node over the network. So there is definitely the need to be able to install munin-node only. So the port munin could be the node only, and munin +server additionally installs the server. This would be reasonable as the node gets installed more often than the server. If you do this by variants or by separate ports does not matter that much, as I think two ports would not have conflicting files. The only thing you should note when using two ports is to set dist_subdir to the same value in both ports. This way users do not need to download it twice. Rainer From adambyrtek at gmail.com Sun Mar 8 11:51:15 2009 From: adambyrtek at gmail.com (Adam Byrtek) Date: Sun, 8 Mar 2009 19:51:15 +0100 Subject: Conventions when it comes to cron-like launchd items In-Reply-To: <49B410C3.20901@macports.org> References: <670d23ff0903080930p6d6085a3gc79bb54b07110756@mail.gmail.com> <49B40139.4000402@macports.org> <670d23ff0903081115o49d7f804of21d2a978f05fbaf@mail.gmail.com> <49B410C3.20901@macports.org> Message-ID: <670d23ff0903081151i650b8d62n3ace0b68a15d47fb@mail.gmail.com> On Sun, Mar 8, 2009 at 19:38, Rainer M?ller wrote: > I would prefer not to have anything running on my machine which I did > not start epxlicitly - whether it's a daemon or a cron-like task. OK, I will implement some informational ui_msg then. > As far as I know it is common to start munin-server on one machine and > others report to this using munin-node over the network. So there is > definitely the need to be able to install munin-node only. Exactly, I would say that a node is installed much more often than the server itself. > So the port munin could be the node only, and munin +server additionally > installs the server. This would be reasonable as the node gets installed > more often than the server. This was my initial idea, based on the mysql5 port. On the other hand the fact that the server was not there had been very confusing when I installed MySQL from MacPorts for the first time :) Anyway I think I will go in this direction, as the "server" variant is already known - I don't like variants that are used in only one package. By the way is there some description of popular global variants with explanation of their meaning? This would be very useful both for users and developers and would help maintain consistency. I have a feeling that there are too many mysterious variants out there... Regards, Adam -- Adam Byrtek From jmr at macports.org Sun Mar 8 11:58:05 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 09 Mar 2009 05:58:05 +1100 Subject: Conventions when it comes to cron-like launchd items In-Reply-To: <670d23ff0903081151i650b8d62n3ace0b68a15d47fb@mail.gmail.com> References: <670d23ff0903080930p6d6085a3gc79bb54b07110756@mail.gmail.com> <49B40139.4000402@macports.org> <670d23ff0903081115o49d7f804of21d2a978f05fbaf@mail.gmail.com> <49B410C3.20901@macports.org> <670d23ff0903081151i650b8d62n3ace0b68a15d47fb@mail.gmail.com> Message-ID: <49B4153D.40005@macports.org> Adam Byrtek wrote: > On Sun, Mar 8, 2009 at 19:38, Rainer M?ller wrote: >> So the port munin could be the node only, and munin +server additionally >> installs the server. This would be reasonable as the node gets installed >> more often than the server. > > This was my initial idea, based on the mysql5 port. On the other hand > the fact that the server was not there had been very confusing when I > installed MySQL from MacPorts for the first time :) MySQL 5 is an interesting case because the server variant only creates a startupitem. Normally something this inexpensive should not warrant a variant (and causes confusion as you note), but it does cause installing the port to require root. > Anyway I think I will go in this direction, as the "server" variant is > already known - I don't like variants that are used in only one > package. By the way is there some description of popular global > variants with explanation of their meaning? This would be very useful > both for users and developers and would help maintain consistency. I > have a feeling that there are too many mysterious variants out > there... There is _resources/port1.0/variant_descriptions.conf, which should be used whenever possible. - Josh From adambyrtek at gmail.com Sun Mar 8 12:05:07 2009 From: adambyrtek at gmail.com (Adam Byrtek) Date: Sun, 8 Mar 2009 20:05:07 +0100 Subject: Conventions when it comes to cron-like launchd items In-Reply-To: <49B4153D.40005@macports.org> References: <670d23ff0903080930p6d6085a3gc79bb54b07110756@mail.gmail.com> <49B40139.4000402@macports.org> <670d23ff0903081115o49d7f804of21d2a978f05fbaf@mail.gmail.com> <49B410C3.20901@macports.org> <670d23ff0903081151i650b8d62n3ace0b68a15d47fb@mail.gmail.com> <49B4153D.40005@macports.org> Message-ID: <670d23ff0903081205m637ddad5je53241d05fda228c@mail.gmail.com> On Sun, Mar 8, 2009 at 19:58, Joshua Root wrote: > There is _resources/port1.0/variant_descriptions.conf, which should be > used whenever possible. Do you mean this? https://trac.macports.org/browser/trunk/dports/_resources/port1.0/variant_descriptions.conf I would say it is not very comprehensive and/or informative. Also it is hard to find, I was rather thinking about something more accessible, like a Wiki page. Regards, Adam -- Adam Byrtek From jmr at macports.org Sun Mar 8 12:11:33 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 09 Mar 2009 06:11:33 +1100 Subject: Conventions when it comes to cron-like launchd items In-Reply-To: <670d23ff0903081205m637ddad5je53241d05fda228c@mail.gmail.com> References: <670d23ff0903080930p6d6085a3gc79bb54b07110756@mail.gmail.com> <49B40139.4000402@macports.org> <670d23ff0903081115o49d7f804of21d2a978f05fbaf@mail.gmail.com> <49B410C3.20901@macports.org> <670d23ff0903081151i650b8d62n3ace0b68a15d47fb@mail.gmail.com> <49B4153D.40005@macports.org> <670d23ff0903081205m637ddad5je53241d05fda228c@mail.gmail.com> Message-ID: <49B41865.6000604@macports.org> Adam Byrtek wrote: > On Sun, Mar 8, 2009 at 19:58, Joshua Root wrote: >> There is _resources/port1.0/variant_descriptions.conf, which should be >> used whenever possible. > > Do you mean this? > https://trac.macports.org/browser/trunk/dports/_resources/port1.0/variant_descriptions.conf > > I would say it is not very comprehensive and/or informative. Also it > is hard to find, I was rather thinking about something more > accessible, like a Wiki page. Ah, I thought you were asking for a way to specify variant descriptions globally. Yes, documentation would be good too. - Josh From adambyrtek at gmail.com Sun Mar 8 12:33:07 2009 From: adambyrtek at gmail.com (Adam Byrtek) Date: Sun, 8 Mar 2009 20:33:07 +0100 Subject: Conventions when it comes to cron-like launchd items In-Reply-To: <49B410C3.20901@macports.org> References: <670d23ff0903080930p6d6085a3gc79bb54b07110756@mail.gmail.com> <49B40139.4000402@macports.org> <670d23ff0903081115o49d7f804of21d2a978f05fbaf@mail.gmail.com> <49B410C3.20901@macports.org> Message-ID: <670d23ff0903081233u50dd51fcg85e4a0d66a8a983a@mail.gmail.com> On Sun, Mar 8, 2009 at 19:38, Rainer M?ller wrote: > So the port munin could be the node only, and munin +server additionally > installs the server. This would be reasonable as the node gets installed > more often than the server. Rainer, would you care to take a look at the port I created? https://trac.macports.org/ticket/18771 Let me know in case of comments and if everything is fine, feel free to commit. Regards, Adam -- Adam Byrtek From mcalhoun at macports.org Sun Mar 8 17:34:55 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Mon, 9 Mar 2009 00:34:55 +0000 (UTC) Subject: [47866] trunk/dports/aqua Message-ID: On Mar 8, 2009, at 7:39 PM, illogic-al at macports.org wrote: > Revision47866Authorillogic-al at macports.orgDate2009-03-08 16:39:51 -0700 > (Sun, 08 Mar 2009) >Log Message > Add Qt 4.5.0 as unstable portfile. > KDE 4.2.0 is reportedly more stable with Qt 4.4 so > we'll keep that as > main dependency now. >Also add to test KDE with raster graphics and using Qt's phonon. I would like to suggest that this not be the way we upgrade qt4-mac. If KDE needs 4.4, then we should create a compatibility port (call it qt4-mac-compat, qt4-kde, or something along those lines). qt4-mac should be the latest release version (4.5). Since qt4-mac is, for the most part, partitioned off to ${prefix}/libexec/${name} (to avoid conflict with qt4-x11), creating a compatibility port which does not conflict should be relatively easy. I have been working on an upgrade to 4.5, but it will take a little while. In any event, 4.5 is not a development, beta, or pre release, so the naming (qt4-mac-devel) is a bit awkward. I am very eager to get 4.5 up and running since it will make other parts of my work easier to build in 64-bit mode. -Marcus From illogical1 at gmail.com Sun Mar 8 17:57:17 2009 From: illogical1 at gmail.com (Orville Bennett) Date: Sun, 8 Mar 2009 20:57:17 -0400 Subject: [47866] trunk/dports/aqua In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 8, 2009, at 8:34 PM, Marcus Calhoun-Lopez wrote: > On Mar 8, 2009, at 7:39 PM, illogic-al at macports.org wrote: >> Revision47866Authorillogic-al at macports.orgDate2009-03-08 16:39:51 >> -0700 >> (Sun, 08 Mar 2009) >> Log Message >> Add Qt 4.5.0 as unstable portfile. >> KDE 4.2.0 is reportedly more stable with Qt 4.4 so >> we'll keep that as >> main dependency now. >> Also add to test KDE with raster graphics and using Qt's phonon. > > I would like to suggest that this not be the way we upgrade qt4-mac. > If KDE needs 4.4, then we should create a compatibility port > (call it qt4-mac-compat, qt4-kde, or something along those lines). > qt4-mac should be the latest release version (4.5). Totally Agreed. I prefer qt4-kde as I would like to test/add patches from kde development repo for Qt. > > Since qt4-mac is, for the most part, partitioned off to ${prefix}/ > libexec/${name} > (to avoid conflict with qt4-x11), creating a compatibility port > which does not > conflict should be relatively easy. > > I have been working on an upgrade to 4.5, but it will take a little > while. > > In any event, 4.5 is not a development, beta, or pre release, so the > naming > (qt4-mac-devel) is a bit awkward. Agreed again. > > I am very eager to get 4.5 up and running since it will make other > parts of my > work easier to build in 64-bit mode. I hope you don't mind terribly but I added the -devel portfile to test out the kinks, as it were, between kde programs and qt 4.5, sooner rather than later. As you can see all I did was copy the 4.4 portfile and add some variants, so all it really does is track the normal qt4-mac port. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkm0aW0ACgkQ2yWVgjgEOKROOQCgqrU1ICf0DUmmHCf5uuwt7EEJ KqYAnjtstyOrT3nSUsqO0QaShkNZoYuh =9RWy -----END PGP SIGNATURE----- From vincent-opdarw at vinc17.org Sun Mar 8 22:07:10 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Mon, 9 Mar 2009 06:07:10 +0100 Subject: Duplicate Perl 5.8 libraries In-Reply-To: <49B3FEE6.1000803@macports.org> References: <670d23ff0903081016vf51d3adp45a6b6eeb1bde85c@mail.gmail.com> <49B3FEE6.1000803@macports.org> Message-ID: <20090309050710.GG26613@prunille.vinc17.org> On 2009-03-08 18:22:46 +0100, Rainer M?ller wrote: > Adam Byrtek wrote: > > When playing with dependencies for a new port that requires certain > > CPAN libraries I found out that there are multiple p5 ports containing > > libraries already included in perl5.8. I had this problem with the > > following ports: > > p5-time-hires > > p5-text-balanced > > p5-digest-md5 > > Please see the recent thread "perl5.8 fixup" where exactly this problem > is currently discussed. There's no explanation of why these dependencies are needed. So, until any problem is found (which would be an upstream bug), these dependencies should be removed. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From mcalhoun at macports.org Sun Mar 8 22:19:35 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Mon, 9 Mar 2009 05:19:35 +0000 (UTC) Subject: Duplicate Perl 5.8 libraries References: <670d23ff0903081016vf51d3adp45a6b6eeb1bde85c@mail.gmail.com> <49B3FEE6.1000803@macports.org> <20090309050710.GG26613@prunille.vinc17.org> Message-ID: Vincent Lefevre writes: > > On 2009-03-08 18:22:46 +0100, Rainer M?ller wrote: > > Adam Byrtek wrote: > > > When playing with dependencies for a new port that requires certain > > > CPAN libraries I found out that there are multiple p5 ports containing > > > libraries already included in perl5.8. I had this problem with the > > > following ports: > > > p5-time-hires > > > p5-text-balanced > > > p5-digest-md5 > > > > Please see the recent thread "perl5.8 fixup" where exactly this problem > > is currently discussed. > > There's no explanation of why these dependencies are needed. So, > until any problem is found (which would be an upstream bug), these > dependencies should be removed. > There are several reasons why they might have been added: 1) The perl5.8 module became outdated and a newer one was needed. perl5.8 was recently updated, so this is probably no longer the case in most instances. 2) perl5.8 did not always provide the module. 3) The maintainer knew the module was needed and did not check if the perl5.8 version was recent enough to work. Whatever the historical reason, I agree that if the perl5.8 module suffices, the p5 version should not be a dependency. -Marcus From mcalhoun at macports.org Sun Mar 8 22:39:24 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Mon, 9 Mar 2009 05:39:24 +0000 (UTC) Subject: port commit not making it into rsync server Message-ID: Earlier, I committed a change to gmp (http://trac.macports.org/changeset/47853). It has been many hours, and the change has not shown up when I run port sync. I do not see the change to graphviz-devel either (http://trac.macports.org/changeset/47862). Can anyone guess why this might be happening? I see that something similar might have happened before: http://www.mail-archive.com/macports-dev at lists.macosforge.org/msg01713.html . Thanks, Marcus From raimue at macports.org Mon Mar 9 01:27:44 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Mon, 09 Mar 2009 09:27:44 +0100 Subject: [47871] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <20090309073825.89D17117AA43@beta.macosforge.org> References: <20090309073825.89D17117AA43@beta.macosforge.org> Message-ID: <49B4D300.3070601@macports.org> blb at macports.org wrote: > Revision: 47871 > http://trac.macports.org/changeset/47871 > Author: blb at macports.org > Date: 2009-03-09 00:38:20 -0700 (Mon, 09 Mar 2009) > Log Message: > ----------- > macports1.0/macports.tcl - don't bother with .quick work when the PortIndex > isn't available; without this running portindex dies since it tries to > run the 'file mtime' against PortIndex and that crashes when that file isn't > there > > Modified Paths: > -------------- > trunk/base/src/macports1.0/macports.tcl > > Modified: trunk/base/src/macports1.0/macports.tcl > =================================================================== > --- trunk/base/src/macports1.0/macports.tcl 2009-03-09 06:16:34 UTC (rev 47870) > +++ trunk/base/src/macports1.0/macports.tcl 2009-03-09 07:38:20 UTC (rev 47871) > @@ -1854,6 +1854,9 @@ > # chop off any tags > set source [lindex $source 0] > set index [macports::getindex $source] > + if {![file exists ${index}]} { > + continue > + } > if {![file exists ${index}.quick] || [file mtime ${index}] > [file mtime ${index}.quick]} { > # stale or nonexistent quick index file, so generate a new one > if {[catch {set quicklist [mports_generate_quickindex ${index}]}]} { Do we need to call mports_generate_quickindex here at all? portindex now already generates PortIndex.quick, so I can't think of a situation where a PortIndex would exist without a corresponding PortIndex.quick. Users are encouraged to re-index using the new version, of course. Rainer From jmr at macports.org Mon Mar 9 01:46:33 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 09 Mar 2009 19:46:33 +1100 Subject: [47871] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <49B4D300.3070601@macports.org> References: <20090309073825.89D17117AA43@beta.macosforge.org> <49B4D300.3070601@macports.org> Message-ID: <49B4D769.2050204@macports.org> Rainer M?ller wrote: > blb at macports.org wrote: >> Revision: 47871 >> http://trac.macports.org/changeset/47871 >> Author: blb at macports.org >> Date: 2009-03-09 00:38:20 -0700 (Mon, 09 Mar 2009) >> Log Message: >> ----------- >> macports1.0/macports.tcl - don't bother with .quick work when the PortIndex >> isn't available; without this running portindex dies since it tries to >> run the 'file mtime' against PortIndex and that crashes when that file isn't >> there >> >> Modified Paths: >> -------------- >> trunk/base/src/macports1.0/macports.tcl >> >> Modified: trunk/base/src/macports1.0/macports.tcl >> =================================================================== >> --- trunk/base/src/macports1.0/macports.tcl 2009-03-09 06:16:34 UTC (rev 47870) >> +++ trunk/base/src/macports1.0/macports.tcl 2009-03-09 07:38:20 UTC (rev 47871) >> @@ -1854,6 +1854,9 @@ >> # chop off any tags >> set source [lindex $source 0] >> set index [macports::getindex $source] >> + if {![file exists ${index}]} { >> + continue >> + } >> if {![file exists ${index}.quick] || [file mtime ${index}] > [file mtime ${index}.quick]} { >> # stale or nonexistent quick index file, so generate a new one >> if {[catch {set quicklist [mports_generate_quickindex ${index}]}]} { > > Do we need to call mports_generate_quickindex here at all? portindex now > already generates PortIndex.quick, so I can't think of a situation where > a PortIndex would exist without a corresponding PortIndex.quick. Users > are encouraged to re-index using the new version, of course. This is needed until PortIndex.quick is generated server-side. - Josh From vincent-opdarw at vinc17.org Mon Mar 9 03:36:28 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Mon, 9 Mar 2009 11:36:28 +0100 Subject: Duplicate Perl 5.8 libraries In-Reply-To: References: <670d23ff0903081016vf51d3adp45a6b6eeb1bde85c@mail.gmail.com> <49B3FEE6.1000803@macports.org> <20090309050710.GG26613@prunille.vinc17.org> Message-ID: <20090309103628.GI26613@prunille.vinc17.org> On 2009-03-09 05:19:35 +0000, Marcus Calhoun-Lopez wrote: > Vincent Lefevre writes: > > > On 2009-03-08 18:22:46 +0100, Rainer M?ller wrote: > > > Adam Byrtek wrote: > > > > When playing with dependencies for a new port that requires certain > > > > CPAN libraries I found out that there are multiple p5 ports containing > > > > libraries already included in perl5.8. I had this problem with the > > > > following ports: > > > > p5-time-hires > > > > p5-text-balanced > > > > p5-digest-md5 [...] > 2) perl5.8 did not always provide the module. Yes, this was at least the case of Digest::MD5 at least (and probably the other ones too since I did not have any conflict with perl5.8 before). But now, the dependencies can be removed. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From raimue at macports.org Mon Mar 9 07:51:37 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 09 Mar 2009 15:51:37 +0100 Subject: Google Summer of Code 2009: Mentors needed! Message-ID: <49B52CF9.7060905@macports.org> Hi, The MacPorts Project will apply again for the Google Summer of Code (GSoC) program this year. I think most of you will already have heard of it. Google pays students to work on various Open Source projects over the summer. It is also a good start for students into Open Source development. See also for more background information. MacPorts will apply to be one of the mentoring organizations. The students can propose their project ideas to us and we will choose the most appealing applications. Each student is supposed to work closely with a mentor who should guide the student through their project and the Open Source world. A mentor should have knowledge of the project and will communicate with the student over the summer to watch the progress and work out any problems. So, we need mentors from our MacPorts community who are willing to care for a student. Please participate! We have to move quickly, as we need to make our application very soon by deadline Friday, March 13th. Also, if you have a specific idea what could be improved in MacPorts, but you never had the time to do it yourself, please put a proposal on our ideas page. I already cleared up the list from the last year and there are still interesting and important projects on it. And we need mentors for these, of course. Ideas page: http://trac.macports.org/wiki/SummerOfCode I am going to be the administrator for GSoC for MacPorts this year, so I will handle the organization application etc. If you have any questions regarding GSoC, please don't hesitate to ask. Rainer From ryandesign at macports.org Mon Mar 9 09:37:52 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Mar 2009 11:37:52 -0500 Subject: Conventions when it comes to cron-like launchd items In-Reply-To: <49B4153D.40005@macports.org> References: <670d23ff0903080930p6d6085a3gc79bb54b07110756@mail.gmail.com> <49B40139.4000402@macports.org> <670d23ff0903081115o49d7f804of21d2a978f05fbaf@mail.gmail.com> <49B410C3.20901@macports.org> <670d23ff0903081151i650b8d62n3ace0b68a15d47fb@mail.gmail.com> <49B4153D.40005@macports.org> Message-ID: On Mar 8, 2009, at 13:58, Joshua Root wrote: > Adam Byrtek wrote: >> On Sun, Mar 8, 2009 at 19:38, Rainer M?ller >> wrote: >>> So the port munin could be the node only, and munin +server >>> additionally >>> installs the server. This would be reasonable as the node gets >>> installed >>> more often than the server. >> >> This was my initial idea, based on the mysql5 port. On the other hand >> the fact that the server was not there had been very confusing when I >> installed MySQL from MacPorts for the first time :) > > MySQL 5 is an interesting case because the server variant only > creates a > startupitem. Normally something this inexpensive should not warrant a > variant (and causes confusion as you note), but it does cause > installing > the port to require root. The +server variant will be removed from the mysql5 port and the mysql5 port will be split in two: mysql5 (installing all binaries needed to be a mysql client or server) and mysql5-server (installing just the startup item and creating the directories for storing your databases). http://trac.macports.org/ticket/12313 postgresql ports already do this. From ryandesign at macports.org Mon Mar 9 09:43:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Mar 2009 11:43:23 -0500 Subject: The Guide - again In-Reply-To: <49B407C3.9030007@macports.org> References: <49B23133.1000908@macports.org> <49B2DA10.8050008@macports.org> <44D98670-1600-4587-B804-360BD7699873@macports.org> <49B407C3.9030007@macports.org> Message-ID: On Mar 8, 2009, at 13:00, Rainer M?ller wrote: > Ryan Schmidt wrote: >>> Especially if the concern is the guide being outdated, I see the >>> problem >>> in the guide format. We had the recent discussion to move the >>> guide to >>> another markup language but it was teared down. What else can we >>> do to >>> attract more people for writing documentation? >> >> We don't want more people writing the Guide. It should stay as a >> coherent document authored by one or a few individuals who have a >> handle on the whole thing. > > I want more people writing the guide :-) > At least I count some TODOs in the guide which are probably there > for as > long as I use MacPorts. > > Missing/Incomplete: > * Some Tcl extensions > * Global variant descriptions > * /usr/local and its breakage > * More about port groups > * portindex > * *-devel ports > * It needs to be synchronized/merged with InstallingMacPorts [1] and > UsingMacPortsQuickStart [2]. > > For most of these items have corresponding Trac tickets [3], some of > them older than a year. > >> From this list it is clear for me that the current team of guide >> editors > is not able to catch up. Don't understand me wrong, I appreciate the > time investment and contributions from anyone, I just think we need to > make it possible for more people to contribute to the guide. > > The open source contributors count on Mac OS X is very low in my > opinion, so in order to attract more contributors we need to lower > barriers. Yeah. The Guide could also use some cleanup and clarification, probably all over. The problem is those of us who have been with MacPorts since before the Guide was written don't have much reason to read it, so we don't notice what's wrong or unclear or missing in it. From ryandesign at macports.org Mon Mar 9 09:44:51 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Mar 2009 11:44:51 -0500 Subject: The Guide - again In-Reply-To: <49B3F78C.20104@macports.org> References: <49B23133.1000908@macports.org> <49B3B7A0.6000600@macports.org> <90488D92-444F-4852-B916-46DEBC9B34A7@macports.org> <49B3F78C.20104@macports.org> Message-ID: On Mar 8, 2009, at 11:51, Martin Krischik wrote: > Ryan Schmidt schrieb: > >> On Mar 8, 2009, at 07:18, Martin Krischik wrote: >> >>> Ryan Schmidt schrieb: >>> >>>> If there are specific things missing from the guide, please file >>>> tickets >>>> requesting that documentation. Please file tickets for any >>>> issues you >>>> have with the guide content, in fact, including suggestions for >>>> rearranging or whatever. >>> >>> I don't know - writing tickets with new ports attached did not >>> work all >>> that well. >> >> That is our process. What about it didn't work well? > > They sat there until I got commit right myself to apply them myself. I apologize for that failure to get those ports committed. But I'm not sure what alternative to this method I can offer. We cannot grant commit access to just anybody. We must first be convinced that a person's contributions are good and correct and follow the guidelines that have been set up. I'm sure you can appreciate this, since even though you have been granted commit access already, you're still getting feedback about your commits on better ways some things can be done. To others who are not committers yet: If tickets you file do not get addressed in a timely manner, please notify the macports-dev list. It's easy for tickets to not get noticed, or to be forgotten. From raimue at macports.org Mon Mar 9 10:00:10 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 09 Mar 2009 18:00:10 +0100 Subject: The Guide - again In-Reply-To: References: <49B23133.1000908@macports.org> <49B3B7A0.6000600@macports.org> <90488D92-444F-4852-B916-46DEBC9B34A7@macports.org> <49B3F78C.20104@macports.org> Message-ID: <49B54B1A.9090502@macports.org> Ryan Schmidt wrote: > On Mar 8, 2009, at 11:51, Martin Krischik wrote: >> Ryan Schmidt schrieb: >>> On Mar 8, 2009, at 07:18, Martin Krischik wrote: >>>> I don't know - writing tickets with new ports attached did not >>>> work all >>>> that well. >>> That is our process. What about it didn't work well? >> They sat there until I got commit right myself to apply them myself. > > I apologize for that failure to get those ports committed. But I'm > not sure what alternative to this method I can offer. [...] I agree with Ryan, there is no better method for handling these than filing tickets. There are so many tickets that it is sometimes hard to keep track and it may happen that a ticket slips through. All you can do in this case is to post to macports-dev and request a commit. Rainer From mark at dxradio.demon.co.uk Mon Mar 9 10:32:00 2009 From: mark at dxradio.demon.co.uk (Mark Hattam) Date: Mon, 9 Mar 2009 17:32:00 +0000 Subject: Conventions when it comes to cron-like launchd items In-Reply-To: References: <670d23ff0903080930p6d6085a3gc79bb54b07110756@mail.gmail.com> <49B40139.4000402@macports.org> <670d23ff0903081115o49d7f804of21d2a978f05fbaf@mail.gmail.com> <49B410C3.20901@macports.org> <670d23ff0903081151i650b8d62n3ace0b68a15d47fb@mail.gmail.com> <49B4153D.40005@macports.org> Message-ID: <3709F729-7329-4667-BF73-575EA15ED1CD@dxradio.demon.co.uk> On 9 Mar 2009, at 16:37, Ryan Schmidt wrote: > > On Mar 8, 2009, at 13:58, Joshua Root wrote: > >> Adam Byrtek wrote: >>> On Sun, Mar 8, 2009 at 19:38, Rainer M?ller >>> wrote: >>>> So the port munin could be the node only, and munin +server >>>> additionally >>>> installs the server. This would be reasonable as the node gets >>>> installed >>>> more often than the server. >>> >>> This was my initial idea, based on the mysql5 port. On the other >>> hand >>> the fact that the server was not there had been very confusing >>> when I >>> installed MySQL from MacPorts for the first time :) >> >> MySQL 5 is an interesting case because the server variant only >> creates a >> startupitem. Normally something this inexpensive should not warrant a >> variant (and causes confusion as you note), but it does cause >> installing >> the port to require root. > > The +server variant will be removed from the mysql5 port and the > mysql5 port will be split in two: mysql5 (installing all binaries > needed to be a mysql client or server) and mysql5-server (installing > just the startup item and creating the directories for storing your > databases). > > http://trac.macports.org/ticket/12313 > > postgresql ports already do this. So now we will have to do mysql5-server instead of mysql5+server to get a MySQL server that runs at startup? Mark From ryandesign at macports.org Mon Mar 9 11:50:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Mar 2009 13:50:38 -0500 Subject: Conventions when it comes to cron-like launchd items In-Reply-To: <3709F729-7329-4667-BF73-575EA15ED1CD@dxradio.demon.co.uk> References: <670d23ff0903080930p6d6085a3gc79bb54b07110756@mail.gmail.com> <49B40139.4000402@macports.org> <670d23ff0903081115o49d7f804of21d2a978f05fbaf@mail.gmail.com> <49B410C3.20901@macports.org> <670d23ff0903081151i650b8d62n3ace0b68a15d47fb@mail.gmail.com> <49B4153D.40005@macports.org> <3709F729-7329-4667-BF73-575EA15ED1CD@dxradio.demon.co.uk> Message-ID: <3634E7CA-9F1F-4870-BEBE-8684BA1B122B@macports.org> On Mar 9, 2009, at 12:32, Mark Hattam wrote: > On 9 Mar 2009, at 16:37, Ryan Schmidt wrote: > >> On Mar 8, 2009, at 13:58, Joshua Root wrote: >> >>> Adam Byrtek wrote: >>>> On Sun, Mar 8, 2009 at 19:38, Rainer M?ller >>>> wrote: >>>>> So the port munin could be the node only, and munin +server >>>>> additionally >>>>> installs the server. This would be reasonable as the node gets >>>>> installed >>>>> more often than the server. >>>> >>>> This was my initial idea, based on the mysql5 port. On the other >>>> hand >>>> the fact that the server was not there had been very confusing >>>> when I >>>> installed MySQL from MacPorts for the first time :) >>> >>> MySQL 5 is an interesting case because the server variant only >>> creates a >>> startupitem. Normally something this inexpensive should not >>> warrant a >>> variant (and causes confusion as you note), but it does cause >>> installing >>> the port to require root. >> >> The +server variant will be removed from the mysql5 port and the >> mysql5 port will be split in two: mysql5 (installing all binaries >> needed to be a mysql client or server) and mysql5-server >> (installing just the startup item and creating the directories for >> storing your databases). >> >> http://trac.macports.org/ticket/12313 >> >> postgresql ports already do this. > > So now we will have to do mysql5-server instead of mysql5+server > to get a MySQL server that runs at startup? Right. It will be "sudo port install mysql5-server" instead of "sudo port install mysql5 +server". From anil at recoil.org Mon Mar 9 13:22:47 2009 From: anil at recoil.org (Anil Madhavapeddy) Date: Mon, 9 Mar 2009 20:22:47 +0000 Subject: ocaml port updates Message-ID: Hi, I have a macports repository up at: http://github.com/avsm/darwinports ... with a number of updates to ocaml-related ports (and also some new ports). Most of the ports involved are openmaintainers and the updates are a bit interlinked due to ocaml being updated to 3.11.0. What would be the best way to submit these changes... I was hoping to avoid creating individual Trac tickets for each update but can do so if that's the best way. Changes summarized below, and maintainers CCed also to this mail. UPDATE: lang/ocaml : to 3.11.0, with threading on MacOS fixed (backport from ocaml-cvs) NEW: devel/caml-json-static NEW: devel/caml-json-wheel UPDATE: caml-ocamlnet : patches to fix various bugs and enable building the nethttpd module UPDATE: caml-sqlite3: update to 1.4.0 upstream NEW: lang/caml-uuidm UPDATE: devel/cryptokit : to upstream 1.3, and findlib-compliant now UPDATE: devel/omake : fixed to work with ocaml-3.11.0 I use a bunch of these ports on the Mac at the moment for some other projects, so can help out with maintaining them if that would be useful. -anil From dluke at geeklair.net Mon Mar 9 13:36:45 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon, 9 Mar 2009 16:36:45 -0400 Subject: The Guide - again In-Reply-To: References: <49B23133.1000908@macports.org> <49B3B7A0.6000600@macports.org> <90488D92-444F-4852-B916-46DEBC9B34A7@macports.org> <49B3F78C.20104@macports.org> Message-ID: On Mar 9, 2009, at 12:44 PM, Ryan Schmidt wrote: > But I'm not sure what alternative to this method I can offer. At least not currently... But how about a future where things are somewhat different: - Portfiles are stored remotely - Portfiles can be submitted by anyone and submitting a portfile automatically causes a build farm to attempt to build a package (failures are noted automatically and portfiles are marked as having built successfully or not) - Portfiles are optionally tagged by trusted users (committers?) after review - Portfiles are optionally tagged by end-users if they work (or if they don't work). The end-user can then decide to have a port tree available that's similar to the current one (only look at portfiles that are tagged by the trusted users/committers), or have mild assurance of "OK" (works on the build farm), or anything that someone in the community says is OK, or anything that anyone has submitted. Of course, if we could eventually get Portfiles down to a state where they couldn't do anything to your system (limited tcl interpreter? somehow forcing them to be only declarative?), that would probably be helpful too ;-) -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From dluke at geeklair.net Mon Mar 9 13:38:30 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon, 9 Mar 2009 16:38:30 -0400 Subject: ocaml port updates In-Reply-To: References: Message-ID: On Mar 9, 2009, at 4:22 PM, Anil Madhavapeddy wrote: > Most of the ports involved are openmaintainers and the updates are a > bit interlinked due to ocaml being updated to 3.11.0. In a case like this, I would open one ticket and CC all of the maintainers of the various ports (and discuss there how to proceed). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From anil at recoil.org Mon Mar 9 13:45:30 2009 From: anil at recoil.org (Anil Madhavapeddy) Date: Mon, 9 Mar 2009 20:45:30 +0000 Subject: ocaml port updates In-Reply-To: References: Message-ID: <4A7BC281-83A4-429E-96C7-9566EF74BCB4@recoil.org> On 9 Mar 2009, at 20:38, Daniel J. Luke wrote: > On Mar 9, 2009, at 4:22 PM, Anil Madhavapeddy wrote: >> Most of the ports involved are openmaintainers and the updates are >> a bit interlinked due to ocaml being updated to 3.11.0. > > > In a case like this, I would open one ticket and CC all of the > maintainers of the various ports (and discuss there how to proceed). Sounds good; I stuck it up on http://trac.macports.org/ticket/18786 -anil From brad at pixilla.com Mon Mar 9 14:03:57 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Mar 2009 14:03:57 -0700 Subject: perl5.8 fixup In-Reply-To: <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <20090305214357.GP27410@darkart.com> <20090306172645.GR27410@darkart.com> <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> Message-ID: I have played around with my perl5.8 port and I have what appears to me to be a solution to the path collision/registry issue. I modified my perl5.8 Portfile like so: configure.args-append -D man1dir='/opt/local/share/man/man1' -D man1direxp='/opt/local/share/man/man1' -D man3dir='/opt/local/share/ man/man3' -D man3direxp='/opt/local/share/man/man3' -D installman1dir='/opt/local/share/man/man1perl58' -D installman3dir='/ opt/local/share/man/man3perl58' -D installsiteman1dir='/opt/local/ share/man/man1perl58' -D installsiteman3dir='/opt/local/share/man/ man3perl58' -D installvendorman1dir='/opt/local/share/man/man1perl58' - D installvendorman3dir='/opt/local/share/man/man3perl58' -D siteman1dir='/opt/local/share/man/man1perl58' -D siteman1direxp='/opt/ local/share/man/man1perl58' -D siteman3dir='/opt/local/share/man/ man3perl58' -D siteman3direxp='/opt/local/share/man/man3perl58' -D vendorman1dir='/opt/local/share/man/man1perl58' -D vendorman1direxp='/ opt/local/share/man/man1perl58' -D vendorman3dir='/opt/local/share/man/ man3perl58' -D vendorman3direxp='/opt/local/share/man/man3perl58' configure.args-append -D man1ext='1p58' -D man3ext='31p58' There may be more changes here then are necessary but I can confirm that just modifying the man ext values did not do it as the p5 modules also used this value. I bumped the revision number of my perl5.8 port and did an upgrade and I received no errors and with the minimal testing I've done I can now install p5-cgi as an example without using -f. I am no way qualified to even test if this approach produces more issues but so far I see non. Basically I added man1perl58 and man3perl58 man dirs after reading up on man and seeing that other distros seem to add dirs to man. It appears that man is able to find my man pages and the extension change was just for safety and it might we might be able to do away with that addition to configure.args. I added the configure.args as two appends so I could comment them out easily to for testing. I hope someone with more perl5 knowledge then me can offer some comments as to whether this approach will work without producing other problems. From what I can tell, this is something that can be done as a revision upgrade to perl5.8 without changing anything else so port upgrade perl5.8 solves the whole problem as relates to collisions. //Brad From florian.ebeling at gmail.com Mon Mar 9 14:20:48 2009 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Mon, 9 Mar 2009 22:20:48 +0100 Subject: The Guide - again In-Reply-To: References: <49B23133.1000908@macports.org> <49B3B7A0.6000600@macports.org> <90488D92-444F-4852-B916-46DEBC9B34A7@macports.org> <49B3F78C.20104@macports.org> Message-ID: <5cbbe4ae0903091420h578dbe46ja884bb88f3a0e65d@mail.gmail.com> On Mon, Mar 9, 2009 at 9:36 PM, Daniel J. Luke wrote: > But how about a future where things are somewhat different: > > - Portfiles are stored remotely > - Portfiles can be submitted by anyone and submitting a portfile > automatically causes a build farm to attempt to build a package (failures > are noted automatically and portfiles are marked as having built > successfully or not) > - Portfiles are optionally tagged by trusted users (committers?) after > review > - Portfiles are optionally tagged by end-users if they work (or if they > don't work). > > The end-user can then decide to have a port tree available that's similar to > the current one (only look at portfiles that are tagged by the trusted > users/committers), or have mild assurance of "OK" (works on the build farm), > or anything that someone in the community says is OK, or anything that > anyone has submitted. I really like this vision. And I also agree with Rainer's take that MacPorts has very few contributers right now, earlier today / yesterday. Given the size of the project, the number of ports, and the count of "nomaintainer" ports as well. We should strive for being able to take advantage of various levels of contributions. Be it just voting, tagging, of classical bug-filing, patch-submitting or core development. It's much work of course, but once the project makes it clear that such are the goals, somebody might step forward and help or even drive such an effort. Generally, it can only help to send a clear message on the various channels, that we really welcome contributions. Wiki and guide could be a bit more clear on this _without_ compromising any quality standard. I fear that some parts of these are able to discourage newcomers. -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From opendarwin.org at darkart.com Mon Mar 9 14:25:45 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Mon, 9 Mar 2009 21:25:45 +0000 Subject: perl5.8 fixup In-Reply-To: References: <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> Message-ID: <20090309212545.GT27410@darkart.com> On Sun, Mar 08, 2009 at 02:41:50AM +0000, Marcus Calhoun-Lopez wrote: > Bradley Giesbrecht writes: > > Thank you for the clarification. > > > > If I understand what is being discussed (please correct me if I'm > > > wrong), > > > we would > > > * copy perl5.8 -> perl5.8-core. > > > * create a port which installs all the core p5 ports. > > > * make perl5.8 do nothing except depend on perl5.8-core and the > > > new p5 umbrella port. > > > > > > It seems that this does not buy us anything, so I fear I am missing > > > something. > > > > It buys us perl modules as p5 ports that used to be part of perl5. > > This allows us to update those p5 ports to newer required versions > > without having to have a perl5 revision increment and upgrade perl5. > > It seems it would only do that if the @INC variable were modified > or conflicting modules pruned from perl5.8. > > I would suggest that these goals could be accomplished more easily > by the following (sorry for the duplication from an earlier message): > * Modify @INC so the newer p5 ports are found first. > * Do not add conflicting p5 port as dependencies unless the newer version is > actually required (mitigate the potential problems). > * Prepend p5- to the conflicting man pages. > * Modify the -f p5 ports so they no longer install in the directory > perl reserves for itself. > > This would require a minor change to perl5.8, a few minor > changes to "-f" p5 ports and some cleanup to minimize dependencies. I too think that modifying @INC is a better (no, much, much better) solution to the problem of "I want to install a newer version of perl module XYZ". Is there any reason to *not* modify @INC for perl5.8 (and presumably perl5.10) by inverting the search to find vendor_perl first, then site_perl, then ${PERL_VERSION} (aka the core modules)? So far as the man pages go, I'm not understanding what the 'Prepend p5- to the conflicting man pages.' really means - prepend 'p5-' to the base (perl5.x) installed pages, or to the pages installed by the p5-* ports? I'd prefer something like what the perl5.10 port does - alter the man pages installed by the core perl port rather than have each module's port alter its man pages (are there conflicts there too??). I'd also like to look at -Dman1direxp, -Dman3direxp, -Dsiteman1direxp, -Dsiteman3direxp, -Dvendorman1direxp, and -Dvendorman3direxp to see if that will provide a functional (and reasonably expected) solution for the man page collision problem. Otherwise I agree with the four steps outlined above (modify @INC, don't add conflicting p5-* ports as deps unless needed, (do something to avoid man page conflicts), and modify the '-f p5-*' ports so they no longer install into the base/core perl directories). I think removing the core perl modules from the perl5.x port and making them installed by a perl5.x-modules "meta" port is a very bad idea. Then there is no way to use the original core perl modules alongside the updated perl modules, if that is somehow desired/required (its fairly easy to do if both versions of a module are installed and one is willing to tweak one's script or module to pick the right one - something we do not want to be doing at a general level, but a knowledgable user could still do if they wanted). -eric From ryandesign at macports.org Mon Mar 9 15:07:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 9 Mar 2009 17:07:05 -0500 Subject: can't read "variant_installed": no such variable Message-ID: Trying to upgrade rpm51 running MacPorts 1.7 release branch r47786 I get this curious message; any ideas? I was able to upgrade other ports (that have no variants selected) successfully. Perhaps it has to do with the fact that this port has an autoselected platform variant (+macosx) but no other variants. $ port installed rpm51 The following ports are currently installed: rpm51 @5.1.6_2+macosx (active) $ port -ux upgrade rpm51 can't read "variant_installed": no such variable while executing "ui_debug "$iname ${version_installed}_${revision_installed}$ {variant_installed} is installed"" (procedure "upgrade" line 136) invoked from within "upgrade $d $i $variationslist [array get options] depscache" (procedure "macports::upgrade" line 172) invoked from within "macports::upgrade $portname "port:$portname" [array get variations] [array get options]" ("uplevel" body line 9) invoked from within "uplevel 1 $block" (procedure "foreachport" line 16) invoked from within "foreachport $portlist { # Merge global variations into the variations specified for this port foreach { variation value } [array get g..." (procedure "action_upgrade" line 6) invoked from within "$action_proc $action $portlist [array get global_options]" (procedure "process_cmd" line 86) invoked from within "process_cmd $remaining_args" invoked from within "if { [llength $remaining_args] > 0 } { # If there are remaining arguments, process those as a command # Exit immediately, by default, unless..." (file "/mp/bin/port" line 3241) $ From jmr at macports.org Mon Mar 9 15:53:14 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 10 Mar 2009 09:53:14 +1100 Subject: can't read "variant_installed": no such variable In-Reply-To: References: Message-ID: <49B59DDA.9070809@macports.org> Ryan Schmidt wrote: > Trying to upgrade rpm51 running MacPorts 1.7 release branch r47786 I get > this curious message; any ideas? I was able to upgrade other ports (that > have no variants selected) successfully. Perhaps it has to do with the > fact that this port has an autoselected platform variant (+macosx) but > no other variants. > > > $ port installed rpm51 > The following ports are currently installed: > rpm51 @5.1.6_2+macosx (active) > $ port -ux upgrade rpm51 > can't read "variant_installed": no such variable > while executing > "ui_debug "$iname > ${version_installed}_${revision_installed}${variant_installed} is > installed"" That'd be breakage from r47773. Fixing now. - Josh From opendarwin.org at darkart.com Mon Mar 9 15:55:52 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Mon, 9 Mar 2009 22:55:52 +0000 Subject: perl5.8 fixup In-Reply-To: References: <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> Message-ID: <20090309225551.GU27410@darkart.com> On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote: > I have played around with my perl5.8 port and I have what appears to > me to be a solution to the path collision/registry issue. > > I modified my perl5.8 Portfile like so: > > configure.args-append -D man1dir='/opt/local/share/man/man1' -D > man1direxp='/opt/local/share/man/man1' -D man3dir='/opt/local/share/ > man/man3' -D man3direxp='/opt/local/share/man/man3' -D > installman1dir='/opt/local/share/man/man1perl58' -D installman3dir='/ > opt/local/share/man/man3perl58' -D installsiteman1dir='/opt/local/ > share/man/man1perl58' -D installsiteman3dir='/opt/local/share/man/ > man3perl58' -D installvendorman1dir='/opt/local/share/man/man1perl58' - > D installvendorman3dir='/opt/local/share/man/man3perl58' -D > siteman1dir='/opt/local/share/man/man1perl58' -D siteman1direxp='/opt/ > local/share/man/man1perl58' -D siteman3dir='/opt/local/share/man/ > man3perl58' -D siteman3direxp='/opt/local/share/man/man3perl58' -D > vendorman1dir='/opt/local/share/man/man1perl58' -D vendorman1direxp='/ > opt/local/share/man/man1perl58' -D vendorman3dir='/opt/local/share/man/ > man3perl58' -D vendorman3direxp='/opt/local/share/man/man3perl58' > > configure.args-append -D man1ext='1p58' -D man3ext='31p58' > Cool. I've been futzing with it too, with a simpler setup (haven't finished testing, but it looks like only the man1dir, siteman1dir, vendorman1dir are required - and their 3 complements of course). > > > > There may be more changes here then are necessary but I can confirm > that just modifying the man ext values did not do it as the p5 modules > also used this value. > > I bumped the revision number of my perl5.8 port and did an upgrade and > I received no errors and with the minimal testing I've done I can now > install p5-cgi as an example without using -f. > > I am no way qualified to even test if this approach produces more > issues but so far I see non. > > Basically I added man1perl58 and man3perl58 man dirs after reading up > on man and seeing that other distros seem to add dirs to man. It > appears that man is able to find my man pages and the extension change > was just for safety and it might we might be able to do away with that > addition to configure.args. > > I added the configure.args as two appends so I could comment them out > easily to for testing. > > I hope someone with more perl5 knowledge then me can offer some > comments as to whether this approach will work without producing other > problems. > > From what I can tell, this is something that can be done as a > revision upgrade to perl5.8 without changing anything else so port > upgrade perl5.8 solves the whole problem as relates to collisions. It won't solve everything, just the man page collisions. I've also inverted @INC in the what I'm testing, so far that's good as well (though again, I'm still testing things). Once I've gotten enough testing done to feel like its solid, I'll send out another note with the changes so others can test as well. -eric From mcalhoun at macports.org Mon Mar 9 17:27:39 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Tue, 10 Mar 2009 00:27:39 +0000 (UTC) Subject: perl5.8 fixup References: <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> Message-ID: Eric Hall writes: > > On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote: > > I have played around with my perl5.8 port and I have what appears to > > me to be a solution to the path collision/registry issue. > > > > I modified my perl5.8 Portfile like so: > > > > configure.args-append -D man1dir='/opt/local/share/man/man1' -D > > man1direxp='/opt/local/share/man/man1' -D man3dir='/opt/local/share/ > > man/man3' -D man3direxp='/opt/local/share/man/man3' -D > > installman1dir='/opt/local/share/man/man1perl58' -D installman3dir='/ > > opt/local/share/man/man3perl58' -D installsiteman1dir='/opt/local/ > > share/man/man1perl58' -D installsiteman3dir='/opt/local/share/man/ > > man3perl58' -D installvendorman1dir='/opt/local/share/man/man1perl58' - > > D installvendorman3dir='/opt/local/share/man/man3perl58' -D > > siteman1dir='/opt/local/share/man/man1perl58' -D siteman1direxp='/opt/ > > local/share/man/man1perl58' -D siteman3dir='/opt/local/share/man/ > > man3perl58' -D siteman3direxp='/opt/local/share/man/man3perl58' -D > > vendorman1dir='/opt/local/share/man/man1perl58' -D vendorman1direxp='/ > > opt/local/share/man/man1perl58' -D vendorman3dir='/opt/local/share/man/ > > man3perl58' -D vendorman3direxp='/opt/local/share/man/man3perl58' > > > > configure.args-append -D man1ext='1p58' -D man3ext='31p58' > > > > Cool. I've been futzing with it too, with a simpler setup > (haven't finished testing, but it looks like only the man1dir, > siteman1dir, vendorman1dir are required - and their 3 complements > of course). > There is the issue that the user must modify his or her manpath. An alternate solution is to rename the manpages. The ticket originally opened to deal with this problem is http://trac.macports.org/ticket/12950 . In it, I posted patches which will reorder @INC. I also posted a patch for p5-test-simple to go along with it. The module is installed with perl, but p5-test-simple is a newer version. It avoids manpage conflicts by renaming the manpages. Any feedback would be appreciated. -Marcus From opendarwin.org at darkart.com Mon Mar 9 18:01:30 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Tue, 10 Mar 2009 01:01:30 +0000 Subject: perl5.8 fixup In-Reply-To: References: <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> Message-ID: <20090310010129.GW27410@darkart.com> On Tue, Mar 10, 2009 at 12:27:39AM +0000, Marcus Calhoun-Lopez wrote: > Eric Hall writes: > > > > > On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote: > > > I have played around with my perl5.8 port and I have what appears to > > > me to be a solution to the path collision/registry issue. > > > > > > I modified my perl5.8 Portfile like so: > > > > > > configure.args-append -D man1dir='/opt/local/share/man/man1' -D > > > man1direxp='/opt/local/share/man/man1' -D man3dir='/opt/local/share/ > > > man/man3' -D man3direxp='/opt/local/share/man/man3' -D > > > installman1dir='/opt/local/share/man/man1perl58' -D installman3dir='/ > > > opt/local/share/man/man3perl58' -D installsiteman1dir='/opt/local/ > > > share/man/man1perl58' -D installsiteman3dir='/opt/local/share/man/ > > > man3perl58' -D installvendorman1dir='/opt/local/share/man/man1perl58' - > > > D installvendorman3dir='/opt/local/share/man/man3perl58' -D > > > siteman1dir='/opt/local/share/man/man1perl58' -D siteman1direxp='/opt/ > > > local/share/man/man1perl58' -D siteman3dir='/opt/local/share/man/ > > > man3perl58' -D siteman3direxp='/opt/local/share/man/man3perl58' -D > > > vendorman1dir='/opt/local/share/man/man1perl58' -D vendorman1direxp='/ > > > opt/local/share/man/man1perl58' -D vendorman3dir='/opt/local/share/man/ > > > man3perl58' -D vendorman3direxp='/opt/local/share/man/man3perl58' > > > > > > configure.args-append -D man1ext='1p58' -D man3ext='31p58' > > > > > > > Cool. I've been futzing with it too, with a simpler setup > > (haven't finished testing, but it looks like only the man1dir, > > siteman1dir, vendorman1dir are required - and their 3 complements > > of course). > > > > There is the issue that the user must modify his or her manpath. > An alternate solution is to rename the manpages. > > The ticket originally opened to deal with this problem is > http://trac.macports.org/ticket/12950 > . > In it, I posted patches which will reorder @INC. > I also posted a patch for p5-test-simple to go along with it. > The module is installed with perl, but p5-test-simple is a newer version. > It avoids manpage conflicts by renaming the manpages. > Given that MP installs (most) modules into vendor_perl, I think the order should be: site, vendor, then perl base/core. I like the line(s) you have for showing the directory ordering in the patch, I'll incorporate those. I have a diff that does this, still testing. I may have a fix/hack for the man page problem as well, more details if it pans out. Why did you have p5-test-simple install into site_perl instead of vendor_perl (given that the general default for macports p5-* is to install into vendor_perl)? -eric From mcalhoun at macports.org Mon Mar 9 18:19:12 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Tue, 10 Mar 2009 01:19:12 +0000 (UTC) Subject: perl5.8 fixup References: <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> Message-ID: Eric Hall writes: > Given that MP installs (most) modules into vendor_perl, > I think the order should be: > > site, vendor, then perl base/core. > > I like the line(s) you have for showing the directory ordering > in the patch, I'll incorporate those. > > I have a diff that does this, still testing. I may > have a fix/hack for the man page problem as well, more details > if it pans out. > > Why did you have p5-test-simple install into site_perl > instead of vendor_perl (given that the general default for > macports p5-* is to install into vendor_perl)? As far as I know, site_perl is not being used. Installing into site_perl seems like a convenient way to keep careful control over these special p5-ports. Although I do not feel strongly about it, I would still vote for the order site, perl base/core, vendor. It seems that the smaller the change, the better. For what it's worth, it is the way FreeBSD does is (http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/perl5.8/). -Marcus From markd at macports.org Mon Mar 9 18:24:58 2009 From: markd at macports.org (markd at macports.org) Date: Mon, 09 Mar 2009 18:24:58 -0700 Subject: The Guide - again Message-ID: >> I think the distinction between types of users for documentation is >> problematic. But chunking documents into "topics" and assembling them >> into various docs as needed would at least allow it in theory. It is >> called DITA. Another XML standard. I know, ugh. But I just don't see >> how we can ditch XML and still do what we need to do. >> http://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture > >So DITA is a OASIS-approved standard originating with IBM >for doing documentation? Is there any reason to handle this >with IBM-style complexity? If we wish to do topic-based authoring. If not, no. But I hear people asking for various conflicting rearrangements to the docs, so I made a suggestion for how many types of docs could be generated from the same data. > >>>Especially if the concern is the guide being outdated, I see the problem >>>in the guide format. We had the recent discussion to move the guide to >>>another markup language but it was teared down. What else can we do to >>>attract more people for writing documentation? >> >> But if we have more than a few people contributing anything other than >> incremental changes, we'd need to use the formal approval process we've >> already talked about. So I don't see how that solves anything. There >is >> a natural tendency for people to throw all kinds of stuff into >documents >> just because they can. >I don't think that macports committers would handle guide changes >that mindlessly. I do, and that is no insult to anyone. The guide is not a repository for just anything. I personally don't think that one document is all we need. I never thought the guide should be the only document we'd ever have, and I think the tendency is to assume with no real thoughts that it is the only one we need. >So in my opinion this process of doc writing should not become >a closed thing. It is a bit, because of the tools in place, but we >should not go and even embrace that closedness. > >> I use text files in Textedit to flesh out >> documents and document structure so I don't understand why this is not >> acceptable to do this or any other technique and post it for review. >> Contributions don't need to be in XML. > >No offense, but that sounds quite unefficient. I mean I find it great that >you offer to do all this work. But if much of it can be avoided, than >that should probably happen. There are tools where you can avoid >drafting in plain text and then go into the "documentation IDE" to >"implement" it. >>>To be honest, editing the guide sucks. Contributing to the wiki is much >>>easier. >>> It sounds inefficient because you're conflating contributing to the guide and making minor edits. The guide is a rewrite almost completely from scratch. And the parts that I'll contribute to "complete" it this summer will be from scratch rewrites as well. I gather all information from wherever it exists currently and reorganize it, define terms where necessary, and try to make it as coherent as possible. Others were trying to incrementally edit the old docs which sucked bad into a new doc which didn't suck, and that would never work in my opinion. Typing or editing is the trivial part. It seems to me you see writing the guide as a series of incremental edits, but it isn't. And incremental edits just aren't that hard to do in XML. I am not a coder and I use an editor and get along fine, and I learned it in two weeks so I could do projects like this. Mark From markd at macports.org Mon Mar 9 18:34:00 2009 From: markd at macports.org (markd at macports.org) Date: Mon, 09 Mar 2009 18:34:00 -0700 Subject: The Guide - again Message-ID: >> We don't want more people writing the Guide. It should stay as a >> coherent document authored by one or a few individuals who have a >> handle on the whole thing. > >I want more people writing the guide :-) >At least I count some TODOs in the guide which are probably there for as >long as I use MacPorts. Well I followed the rules along with everybody else. I contributed ports until somebody got me commit rights because they could see I was contributing ports regularly. After awhile I closed dozens of bugs on Trac (eventually hundreds) and somebody gave me bug commit rights on trac so I could be more efficient at what I was already doing. Why should it be any different for the doc team? Pointing out missing parts that we're very aware of isn't enough. Especially since I'm dying to finish it soon. :) > >Missing/Incomplete: > * Some Tcl extensions > * Global variant descriptions > * /usr/local and its breakage > * More about port groups > * portindex > * *-devel ports > * It needs to be synchronized/merged with InstallingMacPorts [1] and > UsingMacPortsQuickStart [2]. > >For most of these items have corresponding Trac tickets [3], some of >them older than a year. > >>From this list it is clear for me that the current team of guide editors >is not able to catch up. Don't understand me wrong, I appreciate the >time investment and contributions from anyone, I just think we need to >make it possible for more people to contribute to the guide. > >The open source contributors count on Mac OS X is very low in my >opinion, so in order to attract more contributors we need to lower >barriers. We need people who can deliver. All these pieces are missing as you say, and I know this quite well. They are missing mainly because I stopped mid-rewrite to work with Simon@ to get a single source solution so that we wouldn't have to write and maintain duplicate information it multiple places. I will resume and complete it this summer, but it was the right thing to do to stop and make it so that our documents and man pages would match precisely and elininate wasted effort, even though it prolonged the process. Many of those tickets say "the guide should ..." and give not a lot of helpful information. Not all. Ryan's doc tickets are particularly helpful I should say. But as an example of ones that will linger: http://trac.macports.org/ticket/15784 Since the creator didn't give any directly usable information, it will be awhile before that gets acted on. Pretty much the same for any tickets as far as I can tell. So I don't see why these outstanding doc tickets make such great supporting evidence of your assertions that the current system is broken. Mark From brad at pixilla.com Mon Mar 9 18:53:20 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Mar 2009 18:53:20 -0700 Subject: perl5.8 fixup In-Reply-To: <20090309225551.GU27410@darkart.com> References: <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> Message-ID: <0F4A0F51-ECD3-4CF7-BB69-C4A6D8B106FB@pixilla.com> On Mar 9, 2009, at 3:55 PM, Eric Hall wrote: > On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote: >> I have played around with my perl5.8 port and I have what appears to >> me to be a solution to the path collision/registry issue. >> >> I modified my perl5.8 Portfile like so: >> >> configure.args-append -D man1dir='/opt/local/share/man/man1' -D >> man1direxp='/opt/local/share/man/man1' -D man3dir='/opt/local/share/ >> man/man3' -D man3direxp='/opt/local/share/man/man3' -D >> installman1dir='/opt/local/share/man/man1perl58' -D installman3dir='/ >> opt/local/share/man/man3perl58' -D installsiteman1dir='/opt/local/ >> share/man/man1perl58' -D installsiteman3dir='/opt/local/share/man/ >> man3perl58' -D installvendorman1dir='/opt/local/share/man/ >> man1perl58' - >> D installvendorman3dir='/opt/local/share/man/man3perl58' -D >> siteman1dir='/opt/local/share/man/man1perl58' -D siteman1direxp='/ >> opt/ >> local/share/man/man1perl58' -D siteman3dir='/opt/local/share/man/ >> man3perl58' -D siteman3direxp='/opt/local/share/man/man3perl58' -D >> vendorman1dir='/opt/local/share/man/man1perl58' -D >> vendorman1direxp='/ >> opt/local/share/man/man1perl58' -D vendorman3dir='/opt/local/share/ >> man/ >> man3perl58' -D vendorman3direxp='/opt/local/share/man/man3perl58' >> >> configure.args-append -D man1ext='1p58' -D man3ext='31p58' >> > > Cool. I've been futzing with it too, with a simpler setup > (haven't finished testing, but it looks like only the man1dir, > siteman1dir, vendorman1dir are required - and their 3 complements > of course). I think the modules install their man pages to man3. What I haven't been able to figure out yet is which man page man is loading when there are more then one with the same name. The man documentation suggests it will be the first match it finds so I think we should be shooting for perl5.8 modules to be found after p5 module man pages matching what you are doing with your inverted @INC. My testing suggests to me this may be a drop in replacement. Edit perl5.8 Portfile and bump revision and then port upgrade and your perl5.8 and p5's are good to go without messing with all the other installed software. I haven't been able to confirm this but I think ideally only the perl5.8 module mans should be moved and I think the p5 modules use the perl5.8 compile settings if not overridden so finding exactly which man paths need to changed is what I'm working on. >> There may be more changes here then are necessary but I can confirm >> that just modifying the man ext values did not do it as the p5 >> modules >> also used this value. >> >> I bumped the revision number of my perl5.8 port and did an upgrade >> and >> I received no errors and with the minimal testing I've done I can now >> install p5-cgi as an example without using -f. >> >> I am no way qualified to even test if this approach produces more >> issues but so far I see non. >> >> Basically I added man1perl58 and man3perl58 man dirs after reading up >> on man and seeing that other distros seem to add dirs to man. It >> appears that man is able to find my man pages and the extension >> change >> was just for safety and it might we might be able to do away with >> that >> addition to configure.args. >> >> I added the configure.args as two appends so I could comment them out >> easily to for testing. >> >> I hope someone with more perl5 knowledge then me can offer some >> comments as to whether this approach will work without producing >> other >> problems. >> >> From what I can tell, this is something that can be done as a >> revision upgrade to perl5.8 without changing anything else so port >> upgrade perl5.8 solves the whole problem as relates to collisions. > > It won't solve everything, just the man page collisions. > > I've also inverted @INC in the what I'm testing, so far that's > good as well (though again, I'm still testing things). > > Once I've gotten enough testing done to feel like its solid, > I'll send out another note with the changes so others can test as > well. Agreed. I have been using the @INC env var you suggested earlier in another thread I believe. I like the idea presented in a recent post of having an /opt/local/etc/ profile file. If you execute the file it will add a line to your .profile to source the file if it doesn't exist so new users can just execute /opt/local/etc/profile and their home .profile is setup for macports. I'd also like something like /opt/local/ect/profile.d for things like perl5.8 where /opt/local/ect/profile would source /opt/local/ect/ profile.d/* and perl5.8 would add /opt/local/ect/profile.d/perl5.8. Then other ports like mysql5 could also add paths to their executables into /opt/local/ect/profile.d/myslq5. //Brad From markd at macports.org Mon Mar 9 18:59:02 2009 From: markd at macports.org (markd at macports.org) Date: Mon, 09 Mar 2009 18:59:02 -0700 Subject: The Guide - again Message-ID: >> I think the distinction between types of users for documentation is >> problematic. > >Problematic in what way? Do you mean you think it would be >problematic to write the Guide to target different classes of users? >Or do you mean you think users will currently find it problematic to >identify which information in the Guide is applicable to them? I'm >finding the latter. I was really thinking it is a problem to classify information as "advanced" and "basic", and I avoided that in the guide. So I didn't say exactly what I was thinking. The reason is that these days people with little experience read some advenced stuff on the internet and want to do those things right away. But targeting groups of users is different, and I think necessary, so I misspoke. As far as users having difficulty finding which information is applicable, that may be so. To be honest, I think the 1st phase of writing the Guide (from scratch to feature complete summer - I hope) was/is mostly an exercise in knowledge management. After that phase is complete I think it would make sense to think about users, how the material is presented and/or formatted, and whether to split it or create supplements to it, and anything else that makes sense. I think various types of users finding what they want is an important part of usability, but I've not had time to think about that too much, and I'd be interested in hearing other opinions too. > > >Here's how I see the Guide at this time w.r.t. what kind of person >should read that section: > >1. Introduction -- all users >2. Installing MacPorts -- all users >3. Using MacPorts -- all users >4. Portfile Development -- port maintainers >5. Portfile Reference -- port maintainers, except that regular users >might well want to know about the different phases that MacPorts goes >through to install a port; or that ports can have dependencies and >what MacPorts does about that (i.e. it works out and installs the >dependencies first in the correct order); or that ports can have >startupitems and how that works >6. MacPorts Internals > 6.1. File Hierarchy -- all users > 6.2. Configuration Files -- advanced users > 6.3. Port Images -- all users > 6.4. APIs and Libs -- developers of GUI clients > 6.5. The MacPorts Registry -- base developers >7. MacPorts Project -- all users >8. MacPorts Guide Terms > Glossary -- no users (doesn't actually define any terms) > Yeah I think that pretty much describes the user/information mapping as it is. Though it is all subject to change as time goes on, what do you think of the overall structure right now? I would be interested to know your opinion. As I said before, it could be that the "internals" section ought to be in another document. But I'm not sure what it would be. I just looked at the FreeBSD Porter's Handbook, and it has a "Quick Porting" and "Slow Porting" section. That's interesting and doesn't get into "basic" and "advanced" categories. Mark From brad at pixilla.com Mon Mar 9 19:02:06 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Mar 2009 19:02:06 -0700 Subject: perl5.8 fixup In-Reply-To: References: <5F958958-5CAF-493C-801A-B0FDE26CA6F6@pixilla.com> <07040059-F411-4C81-A2AE-627C71A42388@macports.org> <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> Message-ID: <74403789-7EF4-4D3F-8730-8B8955CAE5D7@pixilla.com> On Mar 9, 2009, at 5:27 PM, Marcus Calhoun-Lopez wrote: > Eric Hall writes: > >> >> On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote: >>> I have played around with my perl5.8 port and I have what appears to >>> me to be a solution to the path collision/registry issue. >>> >>> I modified my perl5.8 Portfile like so: >>> >>> configure.args-append -D man1dir='/opt/local/share/man/man1' -D >>> man1direxp='/opt/local/share/man/man1' -D man3dir='/opt/local/share/ >>> man/man3' -D man3direxp='/opt/local/share/man/man3' -D >>> installman1dir='/opt/local/share/man/man1perl58' -D >>> installman3dir='/ >>> opt/local/share/man/man3perl58' -D installsiteman1dir='/opt/local/ >>> share/man/man1perl58' -D installsiteman3dir='/opt/local/share/man/ >>> man3perl58' -D installvendorman1dir='/opt/local/share/man/ >>> man1perl58' - >>> D installvendorman3dir='/opt/local/share/man/man3perl58' -D >>> siteman1dir='/opt/local/share/man/man1perl58' -D siteman1direxp='/ >>> opt/ >>> local/share/man/man1perl58' -D siteman3dir='/opt/local/share/man/ >>> man3perl58' -D siteman3direxp='/opt/local/share/man/man3perl58' -D >>> vendorman1dir='/opt/local/share/man/man1perl58' -D >>> vendorman1direxp='/ >>> opt/local/share/man/man1perl58' -D vendorman3dir='/opt/local/share/ >>> man/ >>> man3perl58' -D vendorman3direxp='/opt/local/share/man/man3perl58' >>> >>> configure.args-append -D man1ext='1p58' -D man3ext='31p58' >>> >> >> Cool. I've been futzing with it too, with a simpler setup >> (haven't finished testing, but it looks like only the man1dir, >> siteman1dir, vendorman1dir are required - and their 3 complements >> of course). >> > > There is the issue that the user must modify his or her manpath. > An alternate solution is to rename the manpages. Not according to my tests. Creating man1perl58 and man3perl58 without altering man paths seems to work. Looking at /etc/manpaths it looks like man must parse this entire directory. I may be missing something. bash-3.2# cat /etc/manpaths /usr/share/man /usr/local/share/man > The ticket originally opened to deal with this problem is > http://trac.macports.org/ticket/12950 > . > In it, I posted patches which will reorder @INC. > I also posted a patch for p5-test-simple to go along with it. > The module is installed with perl, but p5-test-simple is a newer > version. > It avoids manpage conflicts by renaming the manpages. I think the perl5.8 compile flags alone will fix the man path collisions. The @INC env var looks like a good solution and I favor using a /opt/local/etc/profile mechanism with /opt/local/etc/profile.d/ perl5.8 and friends. I think a new port name "profile" could be created to make this easy or it could become part of macports. Then perl5.8 could add the /opt/ local/etc/profile.d/perl5.8 file. //Brad From brad at pixilla.com Mon Mar 9 19:08:56 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Mar 2009 19:08:56 -0700 Subject: perl5.8 fixup In-Reply-To: <20090310010129.GW27410@darkart.com> References: <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> Message-ID: <10F00A17-BD5D-4C4C-88DC-43CFF09675E8@pixilla.com> On Mar 9, 2009, at 6:01 PM, Eric Hall wrote: > On Tue, Mar 10, 2009 at 12:27:39AM +0000, Marcus Calhoun-Lopez wrote: >> Eric Hall writes: >> >>> >>> On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote: >>>> I have played around with my perl5.8 port and I have what appears >>>> to >>>> me to be a solution to the path collision/registry issue. >>>> >>>> I modified my perl5.8 Portfile like so: >>>> >>>> configure.args-append -D man1dir='/opt/local/share/man/man1' -D >>>> man1direxp='/opt/local/share/man/man1' -D man3dir='/opt/local/ >>>> share/ >>>> man/man3' -D man3direxp='/opt/local/share/man/man3' -D >>>> installman1dir='/opt/local/share/man/man1perl58' -D >>>> installman3dir='/ >>>> opt/local/share/man/man3perl58' -D installsiteman1dir='/opt/local/ >>>> share/man/man1perl58' -D installsiteman3dir='/opt/local/share/man/ >>>> man3perl58' -D installvendorman1dir='/opt/local/share/man/ >>>> man1perl58' - >>>> D installvendorman3dir='/opt/local/share/man/man3perl58' -D >>>> siteman1dir='/opt/local/share/man/man1perl58' -D siteman1direxp='/ >>>> opt/ >>>> local/share/man/man1perl58' -D siteman3dir='/opt/local/share/man/ >>>> man3perl58' -D siteman3direxp='/opt/local/share/man/man3perl58' -D >>>> vendorman1dir='/opt/local/share/man/man1perl58' -D >>>> vendorman1direxp='/ >>>> opt/local/share/man/man1perl58' -D vendorman3dir='/opt/local/ >>>> share/man/ >>>> man3perl58' -D vendorman3direxp='/opt/local/share/man/man3perl58' >>>> >>>> configure.args-append -D man1ext='1p58' -D man3ext='31p58' >>>> >>> >>> Cool. I've been futzing with it too, with a simpler setup >>> (haven't finished testing, but it looks like only the man1dir, >>> siteman1dir, vendorman1dir are required - and their 3 complements >>> of course). >>> >> >> There is the issue that the user must modify his or her manpath. >> An alternate solution is to rename the manpages. >> >> The ticket originally opened to deal with this problem is >> http://trac.macports.org/ticket/12950 >> . >> In it, I posted patches which will reorder @INC. >> I also posted a patch for p5-test-simple to go along with it. >> The module is installed with perl, but p5-test-simple is a newer >> version. >> It avoids manpage conflicts by renaming the manpages. >> > > Given that MP installs (most) modules into vendor_perl, > I think the order should be: > > site, vendor, then perl base/core. > > I like the line(s) you have for showing the directory ordering > in the patch, I'll incorporate those. > > I have a diff that does this, still testing. I may > have a fix/hack for the man page problem as well, more details > if it pans out. > > > Why did you have p5-test-simple install into site_perl > instead of vendor_perl (given that the general default for > macports p5-* is to install into vendor_perl)? Simple, lack of understanding :) Perl is not a language I use for development. I just use perl applications and know next to nothing about how perl builds or what env vars do what. I've stated repeatedly that I do not feel qualified to choose a solution because I wouldn't know if I introduced other issues I wouldn't be aware of. But I badly want a solution so other ports I am working on that use perl applications that rely on perl modules can install without my users having to -f 30 or so p5 modules :) I'm just trying to keep this alive and do legwork with my clean macports and my server platform macports to keep this alive till smarter people can settle on a great solution. Thank you very much for participating in this process that matters a lot to me :) //Brad From brad at pixilla.com Mon Mar 9 19:12:17 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 9 Mar 2009 19:12:17 -0700 Subject: perl5.8 fixup In-Reply-To: References: <864DE530-F67B-4567-BA40-DFD047073339@pixilla.com> <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> Message-ID: <436C65EC-2A3F-4815-8F56-F80600B83CF5@pixilla.com> On Mar 9, 2009, at 6:19 PM, Marcus Calhoun-Lopez wrote: > Eric Hall writes: > >> Given that MP installs (most) modules into vendor_perl, >> I think the order should be: >> >> site, vendor, then perl base/core. >> >> I like the line(s) you have for showing the directory ordering >> in the patch, I'll incorporate those. >> >> I have a diff that does this, still testing. I may >> have a fix/hack for the man page problem as well, more details >> if it pans out. >> >> Why did you have p5-test-simple install into site_perl >> instead of vendor_perl (given that the general default for >> macports p5-* is to install into vendor_perl)? > > As far as I know, site_perl is not being used. > Installing into site_perl seems like a convenient way to > keep careful control over these special p5-ports. > > Although I do not feel strongly about it, I would still vote for the > order > site, perl base/core, vendor. > It seems that the smaller the change, the better. > > For what it's worth, it is the way FreeBSD does is > (http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/perl5.8/). I love to leverage the careful considerations others have put into similar problems and freebsd is somewhat of a natural because it's ports system is similar in many respects to the darwin macports combo. Freebsd has the freebsd base and the ports collection. We have macosx base and the macports collection. //Brad From ryandesign at macports.org Mon Mar 9 22:16:44 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Mar 2009 00:16:44 -0500 Subject: The Guide - again In-Reply-To: References: Message-ID: > Many of those tickets say "the guide should ..." and give not a lot of > helpful information. Not all. Ryan's doc tickets are particularly > helpful I should say. But as an example of ones that will linger: > http://trac.macports.org/ticket/15784 Since the creator didn't > give any > directly usable information, it will be awhile before that gets > acted on. The creator of the ticket may not know how to document the option. They may have just seen it in a portfile or portgroup or somewhere and wondered what it was, and noted it was not described in the guide. So it's right for them to ask for it to be documented. For tickets that say the guide should document something, without saying how it should be documented, maybe a message should be sent to macports-dev asking if anyone knows what the option does. For example in the case of 15784, I don't know what "perl5.use_module_build" is / does. Hopefully someone with more experience with the perl modules does. From blb at macports.org Mon Mar 9 22:39:02 2009 From: blb at macports.org (Bryan Blackburn) Date: Mon, 9 Mar 2009 23:39:02 -0600 Subject: The Guide - again In-Reply-To: References: Message-ID: <20090310053902.GE1036@ninagal.withay.com> On Tue, Mar 10, 2009 at 12:16:44AM -0500, Ryan Schmidt said: >> Many of those tickets say "the guide should ..." and give not a lot of >> helpful information. Not all. Ryan's doc tickets are particularly >> helpful I should say. But as an example of ones that will linger: >> http://trac.macports.org/ticket/15784 Since the creator didn't give >> any >> directly usable information, it will be awhile before that gets acted >> on. > > The creator of the ticket may not know how to document the option. They > may have just seen it in a portfile or portgroup or somewhere and wondered > what it was, and noted it was not described in the guide. So it's right > for them to ask for it to be documented. > > For tickets that say the guide should document something, without saying > how it should be documented, maybe a message should be sent to > macports-dev asking if anyone knows what the option does. For example in > the case of 15784, I don't know what "perl5.use_module_build" is / does. > Hopefully someone with more experience with the perl modules does. It changes how the perl5 port group does a build, specifically, by using perl's Module::Build instead of the usual Makefile.PL-style building. After the usual perl5.setup stuff, if you then add perl5.use_module_build, it should then do what's right to build the module with Module::Build (including depending on p5-module-build). Bryan From ryandesign at macports.org Mon Mar 9 22:53:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Mar 2009 00:53:03 -0500 Subject: The Guide - again In-Reply-To: References: Message-ID: <2E4279DF-8851-4F9B-A878-A796EB83CE19@macports.org> On Mar 9, 2009, at 20:59, markd at macports.org wrote: >> Here's how I see the Guide at this time w.r.t. what kind of person >> should read that section: >> >> 1. Introduction -- all users >> 2. Installing MacPorts -- all users >> 3. Using MacPorts -- all users >> 4. Portfile Development -- port maintainers >> 5. Portfile Reference -- port maintainers, except that regular users >> might well want to know about the different phases that MacPorts goes >> through to install a port; or that ports can have dependencies and >> what MacPorts does about that (i.e. it works out and installs the >> dependencies first in the correct order); or that ports can have >> startupitems and how that works >> 6. MacPorts Internals >> 6.1. File Hierarchy -- all users >> 6.2. Configuration Files -- advanced users >> 6.3. Port Images -- all users >> 6.4. APIs and Libs -- developers of GUI clients >> 6.5. The MacPorts Registry -- base developers >> 7. MacPorts Project -- all users >> 8. MacPorts Guide Terms >> Glossary -- no users (doesn't actually define any terms) > > Yeah I think that pretty much describes the user/information > mapping as it > is. Though it is all subject to change as time goes on, what do > you think > of the overall structure right now? I would be interested to know > your > opinion. As I said before, it could be that the "internals" > section ought > to be in another document. But I'm not sure what it would be. I just > looked at the FreeBSD Porter's Handbook, and it has a "Quick > Porting" and > "Slow Porting" section. That's interesting and doesn't get into > "basic" > and "advanced" categories. I may have to look at that document. I know virtually nothing about FreeBSD. Among the projects I'm involved with in some way, I consider the gold standard of documentation to be that of Subversion. Take a look just at the index: http://svnbook.red-bean.com/en/1.5/index.html Tons of categories. It begins with book-like stuff like Foreword and Preface. The Audience section says who the book is written for. How to Read This Book calls out different types of users and which sections they should read. It talks about how the book is organized. It has a section called What is Subversion; I like that section title very much. It also has a section on Subversion's history. It was written by a small team of writers who had a cohesive vision for the book. And it has been printed in hardcopy by O'Reilly; a second print edition is in the works. Another project whose documentation I like is Graphviz, in the way it documents all the options one can use in a graph: http://graphviz.org/doc/info/attrs.html It's not a book, just a single long page, but it goes into great detail about each option, under what circumstances it can be used, what its default value is, what valid values are, how options relate to one another, and so forth. We do this to some extent too in the guide for portfile options but in many cases we don't really explain things: * "platforms" says "The platforms on which the port has been tested" but doesn't say what values are available for this variable (answer: I'm not sure where the full list is) and what effect setting it has (answer: none at all; maybe in the future MacPorts will warn if you try to install the port on a platform it doesn't indicate compatibility with). * For "homepage" it says "Port application's homepage" but doesn't say what effect setting it has (answer: it will be shown in "port info" and you can also use "port gohome" to open it in your browser). * For "prefix" the guide says it can be overridden on a per-port basis, but doesn't say that there's absolutely no reason for any port to do so; the example of Aqua apps installing into /Applications/ MacPorts is spurious; those should use ${applications_prefix}. * Moving on a little ways, in the sections on fetching from CVS, Subversion, GIT and Mercurial, it says these "may cause non- reproducible builds, so it is strongly discouraged" but doesn't elaborate. The problem there is if you fetch from HEAD; yes certainly that will result in different builds for different users if there is continued development in the repository. Using repository fetches in this way is not discouraged; it's totally prohibited. You must pin your checkout with a tag name or date (CVS) or tag url or revision or date (Subversion); don't know what you need to do for GIT or Mercurial. * In 4.3.4 Eliminating Phases we tell the user how to override a phase with e.g. "build {}" but we don't tell the user not to do that for the configure phase. Well, there is a link from there to section 5, but it's not until 5.3.7 Configure Phase Keywords that we tell the user about "use_configure no", but we don't explain why we want users to use that instead of "configure {}" (answer: I don't remember). * I didn't look very hard but I don't think the Guide tries to call out the differences between dependencies ("deps") and dependents. This is a common source of confusion, but the sections for those two concepts are not near one another and don't mention one another. I'll stop for now; you get the idea. :) From markd at macports.org Tue Mar 10 09:06:18 2009 From: markd at macports.org (markd at macports.org) Date: Tue, 10 Mar 2009 09:06:18 -0700 Subject: The Guide - again Message-ID: >> Many of those tickets say "the guide should ..." and give not a lot of >> helpful information. Not all. Ryan's doc tickets are particularly >> helpful I should say. But as an example of ones that will linger: >> http://trac.macports.org/ticket/15784 Since the creator didn't >> give any >> directly usable information, it will be awhile before that gets >> acted on. > >The creator of the ticket may not know how to document the option. >They may have just seen it in a portfile or portgroup or somewhere >and wondered what it was, and noted it was not described in the >guide. So it's right for them to ask for it to be documented. > >For tickets that say the guide should document something, without >saying how it should be documented, maybe a message should be sent to >macports-dev asking if anyone knows what the option does. For example >in the case of 15784, I don't know what "perl5.use_module_build" is / >does. Hopefully someone with more experience with the perl modules does. I didn't mean to imply that that ticket shouldn't have been created. I just wanted to point out that there needs to be a distinction made between requests for something to be documented and actual document contributions. Both are entirely legitimate, but they are seen and acted on differently. This is to be expected, and is no different than what happens with other work in the project I think. And I agree that a follow-up question should be asked or the dev list asked about it if need be. I've done this before. I will be working on these tickets very soon and clearing all tickets will help to pay more attention to them as they come in. Mark From ryandesign at macports.org Tue Mar 10 09:22:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Mar 2009 11:22:41 -0500 Subject: [47931] trunk/dports/python In-Reply-To: <20090310145735.1864F1193346@beta.macosforge.org> References: <20090310145735.1864F1193346@beta.macosforge.org> Message-ID: On Mar 10, 2009, at 09:57, snc at macports.org wrote: > +distfiles hcluster-${version}${extract.suffix} > +worksrcdir hcluster-${version} The simplest way to express this is: distname hcluster-${version} The defaults for worksrcdir (${distname}) and distfiles (${distname}$ {extract.suffix}) then work properly. From ryandesign at macports.org Tue Mar 10 09:23:00 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Mar 2009 11:23:00 -0500 Subject: [47923] trunk/dports/math/maxima/Portfile In-Reply-To: <20090310085706.D0C8711902A5@beta.macosforge.org> References: <20090310085706.D0C8711902A5@beta.macosforge.org> Message-ID: <5C7B3A04-9F87-470B-AFD0-94A118663025@macports.org> On Mar 10, 2009, at 03:57, gwright at macports.org wrote: > Revision: 47923 > http://trac.macports.org/changeset/47923 > Author: gwright at macports.org > Date: 2009-03-10 01:57:06 -0700 (Tue, 10 Mar 2009) > Log Message: > ----------- > Version bump to 5.17.1. > > Modified Paths: > -------------- > trunk/dports/math/maxima/Portfile > > Modified: trunk/dports/math/maxima/Portfile > =================================================================== > --- trunk/dports/math/maxima/Portfile 2009-03-10 08:52:31 UTC (rev > 47922) > +++ trunk/dports/math/maxima/Portfile 2009-03-10 08:57:06 UTC (rev > 47923) > @@ -4,7 +4,7 @@ > PortSystem 1.0 > > name maxima > -version 5.17.0 > +version 5.17.1 > categories math > maintainers nomaintainer > platforms darwin > @@ -32,10 +32,11 @@ > > homepage http://maxima.sourceforge.net/ > master_sites sourceforge > -checksums md5 98ec3ec237d55639a8de5b317990eb2d \ > - sha1 7013221504c4f8e915d2f69349c37bad25d58635 \ > - rmd160 ea7227e39019505b945caa7257050ecaa58b14e2 > > +checksums md5 f49e7b978061a63423b0d486240d281e \ > + sha1 0f87f2fbf3c91cd54528cfc355ddf5ed30ee66ac \ > + rmd160 0738ddd1f8247ae0300b5810fa21db1fbfc608c3 > + > depends_lib port:sbcl > depends_run port:tk \ > port:recode \ > @@ -60,7 +61,7 @@ > } > > variant printable_doc description {Build printable documentation} { > - depends_build-append bin:tex:texlive > + depends_build-append port:texlive > build.target all pdf > > pre-destroot { Why change "bin:tex:texlive" to "port:texlive"? I thought it had been decided some months ago by those who know about texlive that "bin:tex:texlive" was the preferred syntax because it allows an external texlive to be used which is desirable because the MacPorts version of texlive was deficient in some way. From ryandesign at macports.org Tue Mar 10 09:38:56 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 10 Mar 2009 11:38:56 -0500 Subject: [47929] trunk/dports/python In-Reply-To: <20090310144805.1F05B119310A@beta.macosforge.org> References: <20090310144805.1F05B119310A@beta.macosforge.org> Message-ID: <3B9BD099-22EA-46A5-8123-196313026812@macports.org> On Mar 10, 2009, at 09:48, snc at macports.org wrote: > Revision: 47929 > http://trac.macports.org/changeset/47929 > Author: snc at macports.org > Date: 2009-03-10 07:48:04 -0700 (Tue, 10 Mar 2009) > Log Message: > ----------- > created py26-wxpython, ticket #18561 [snip] > +build.env CC="gcc-mp-4.3" UNICODE="1" WXPORT="mac" > PATH="${python.prefix}/lib/wx/config:$env(PATH)" > + > +destroot.env UNICODE="1" WXPORT="mac" PATH="$ > {python.prefix}/lib/wx/config:$env(PATH)" If you require gcc-mp-4.3, then you must declare a dependency on port:gcc43. It may need to be a build dependency, or possibly a library dependency of one of gcc43's libraries gets linked in. (Use "otool -L" on every file installed by the port to find out.) For the sake of clarity you should also set configure.compiler and use ${configure.cc}. You could also refactor so you only have to define the other env vars once. depends_build-append port:gcc43 configure.compiler macports-gcc-4.3 build.env UNICODE="1" WXPORT="mac" PATH="${python.prefix}/lib/wx/ config:$env(PATH)" destroot.env ${build.env} build.env-append CC="${configure.cc}" Or something like that. From markd at macports.org Tue Mar 10 09:59:09 2009 From: markd at macports.org (markd at macports.org) Date: Tue, 10 Mar 2009 09:59:09 -0700 Subject: The Guide - again Message-ID: >>> Here's how I see the Guide at this time w.r.t. what kind of person >>> should read that section: >>> >>> 1. Introduction -- all users >>> 2. Installing MacPorts -- all users >>> 3. Using MacPorts -- all users >>> 4. Portfile Development -- port maintainers >>> 5. Portfile Reference -- port maintainers, except that regular users >>> might well want to know about the different phases that MacPorts goes >>> through to install a port; or that ports can have dependencies and >>> what MacPorts does about that (i.e. it works out and installs the >>> dependencies first in the correct order); or that ports can have >>> startupitems and how that works >>> 6. MacPorts Internals >>> 6.1. File Hierarchy -- all users >>> 6.2. Configuration Files -- advanced users >>> 6.3. Port Images -- all users >>> 6.4. APIs and Libs -- developers of GUI clients >>> 6.5. The MacPorts Registry -- base developers >>> 7. MacPorts Project -- all users >>> 8. MacPorts Guide Terms >>> Glossary -- no users (doesn't actually define any terms) >> >> Yeah I think that pretty much describes the user/information >> mapping as it >> is. Though it is all subject to change as time goes on, what do >> you think >> of the overall structure right now? I would be interested to know >> your >> opinion. As I said before, it could be that the "internals" >> section ought >> to be in another document. But I'm not sure what it would be. I just >> looked at the FreeBSD Porter's Handbook, and it has a "Quick >> Porting" and >> "Slow Porting" section. That's interesting and doesn't get into >> "basic" >> and "advanced" categories. > >I may have to look at that document. I know virtually nothing about >FreeBSD. > >Among the projects I'm involved with in some way, I consider the gold >standard of documentation to be that of Subversion. Take a look just >at the index: > >http://svnbook.red-bean.com/en/1.5/index.html > >Tons of categories. It begins with book-like stuff like Foreword and >Preface. The Audience section says who the book is written for. How >to Read This Book calls out different types of users and which >sections they should read. It talks about how the book is organized. >It has a section called What is Subversion; I like that section title >very much. It also has a section on Subversion's history. It was >written by a small team of writers who had a cohesive vision for the >book. And it has been printed in hardcopy by O'Reilly; a second print >edition is in the works. > >Another project whose documentation I like is Graphviz, in the way it >documents all the options one can use in a graph: > >http://graphviz.org/doc/info/attrs.html > >It's not a book, just a single long page, but it goes into great >detail about each option, under what circumstances it can be used, >what its default value is, what valid values are, how options relate >to one another, and so forth. We do this to some extent too in the >guide for portfile options but in many cases we don't really explain >things: > >* "platforms" says "The platforms on which the port has been tested" >but doesn't say what values are available for this variable (answer: >I'm not sure where the full list is) and what effect setting it has >(answer: none at all; maybe in the future MacPorts will warn if you >try to install the port on a platform it doesn't indicate >compatibility with). > >* For "homepage" it says "Port application's homepage" but doesn't >say what effect setting it has (answer: it will be shown in "port >info" and you can also use "port gohome" to open it in your browser). > >* For "prefix" the guide says it can be overridden on a per-port >basis, but doesn't say that there's absolutely no reason for any port >to do so; the example of Aqua apps installing into /Applications/ >MacPorts is spurious; those should use ${applications_prefix}. > >* Moving on a little ways, in the sections on fetching from CVS, >Subversion, GIT and Mercurial, it says these "may cause non- >reproducible builds, so it is strongly discouraged" but doesn't >elaborate. The problem there is if you fetch from HEAD; yes certainly >that will result in different builds for different users if there is >continued development in the repository. Using repository fetches in >this way is not discouraged; it's totally prohibited. You must pin >your checkout with a tag name or date (CVS) or tag url or revision or >date (Subversion); don't know what you need to do for GIT or Mercurial. > >* In 4.3.4 Eliminating Phases we tell the user how to override a >phase with e.g. "build {}" but we don't tell the user not to do that >for the configure phase. Well, there is a link from there to section >5, but it's not until 5.3.7 Configure Phase Keywords that we tell the >user about "use_configure no", but we don't explain why we want users >to use that instead of "configure {}" (answer: I don't remember). > >* I didn't look very hard but I don't think the Guide tries to call >out the differences between dependencies ("deps") and dependents. >This is a common source of confusion, but the sections for those two >concepts are not near one another and don't mention one another. > >I'll stop for now; you get the idea. :) These are all good points. I don't just get the idea, I know the idea. :) I know there are many weaknesses in it, and for the most part it really hasn't even been proofread yet. Like I said, I see this process in phases and the fact is that these elements are a part of refinement process, which is not the one we're in right now. We're still in the throwing in large chunks phase, though it might not seem like it because of the lack of activity last year. But throwing in large chunks is what is on my todo list right now and what was happening before the pause in activity at the end of last year. And looking at other examples we'd like to emulate is very good, and I appreciate you referencing the other docs you did. One reminded me that I've wanted to create a sweet graphic in it to make the parts of MacPorts clear. It wouldn't take long to do. But the use_configure issue is a classic case of how not to use documentation. Documentation can't cover up glaring design flaws. The documentation and product should be thought of as a whole. use_configure is a glaring inconsistency and either needs to be removed or use_build, use_destroot, etc added. I'd prefer the former since the latter seems ugly, and "configure {}" seems no easier to remember in any way than "use_configure no", in fact it is harder and more error prone. Better to fix the product. Documenting inconsistent product behavior is putting lipstick on a pig. In fact, I wonder why some keywords have dot separaters for words and some have periods generally. At least I don't know the pattern for this if there is one. Mark From jeremy at lavergne.gotdns.org Tue Mar 10 12:28:12 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 10 Mar 2009 15:28:12 -0400 Subject: Trac Features Message-ID: Is it possible that we can implement a "download all" option for tickets? I know it's a minority to find a port with 13 files involved, but often enough there is at least 1 additional file. Having to click through and download each one is something I feel we can easily fix by generating a quick archive of the associated attachments. Is this something that can be done via the trac system? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From opendarwin.org at darkart.com Tue Mar 10 12:57:14 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Tue, 10 Mar 2009 19:57:14 +0000 Subject: perl5.8 fixup In-Reply-To: References: <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> Message-ID: <20090310195714.GA10906@darkart.com> On Tue, Mar 10, 2009 at 01:19:12AM +0000, Marcus Calhoun-Lopez wrote: > Eric Hall writes: > > > Given that MP installs (most) modules into vendor_perl, > > I think the order should be: > > > > site, vendor, then perl base/core. > > > > I like the line(s) you have for showing the directory ordering > > in the patch, I'll incorporate those. > > > > I have a diff that does this, still testing. I may > > have a fix/hack for the man page problem as well, more details > > if it pans out. > > > > Why did you have p5-test-simple install into site_perl > > instead of vendor_perl (given that the general default for > > macports p5-* is to install into vendor_perl)? > > As far as I know, site_perl is not being used. > Installing into site_perl seems like a convenient way to > keep careful control over these special p5-ports. > > Although I do not feel strongly about it, I would still vote for the order > site, perl base/core, vendor. > It seems that the smaller the change, the better. > > For what it's worth, it is the way FreeBSD does is > (http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/perl5.8/). > I'm pretty clear that for MacPorts the order should be site, vendor, then base. That way there is the ability to (locally, site/user) put modules into the first search directory, then MacPorts installed modules are found next (from vendor), then the base perl modules. Note that FreeBSD puts site first *and* puts ports-installed perl modules into site, that's probably why they don't use vendor. -eric From opendarwin.org at darkart.com Tue Mar 10 13:02:50 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Tue, 10 Mar 2009 20:02:50 +0000 Subject: perl5.8 fixup In-Reply-To: <74403789-7EF4-4D3F-8730-8B8955CAE5D7@pixilla.com> References: <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <74403789-7EF4-4D3F-8730-8B8955CAE5D7@pixilla.com> Message-ID: <20090310200250.GB10906@darkart.com> On Mon, Mar 09, 2009 at 07:02:06PM -0700, Bradley Giesbrecht wrote: > > On Mar 9, 2009, at 5:27 PM, Marcus Calhoun-Lopez wrote: > > >Eric Hall writes: > > > >> > >>On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote: > >>>I have played around with my perl5.8 port and I have what appears to > >>>me to be a solution to the path collision/registry issue. > >>> [snip stuff about configuring perl to land man pages in certain places, etc.] > >> > > > >There is the issue that the user must modify his or her manpath. > >An alternate solution is to rename the manpages. > > Not according to my tests. Creating man1perl58 and man3perl58 without > altering man paths seems to work. How did you test that the man pages were found? Did you check that man found the right files and not, say, the system-installed files? Check 'ps' for what files are being picked up. > > Looking at /etc/manpaths it looks like man must parse this entire > directory. I may be missing something. > bash-3.2# cat /etc/manpaths > /usr/share/man > /usr/local/share/man > Check /etc/man.conf for the MANSECT variable - this defines the 'sections' man will use, that's the clue as to what will really be picked up. > > >The ticket originally opened to deal with this problem is > >http://trac.macports.org/ticket/12950 > >. > >In it, I posted patches which will reorder @INC. > >I also posted a patch for p5-test-simple to go along with it. > >The module is installed with perl, but p5-test-simple is a newer > >version. > >It avoids manpage conflicts by renaming the manpages. > > I think the perl5.8 compile flags alone will fix the man path > collisions. The @INC env var looks like a good solution and I favor > using a /opt/local/etc/profile mechanism with /opt/local/etc/profile.d/ > perl5.8 and friends. > > I think a new port name "profile" could be created to make this easy > or it could become part of macports. Then perl5.8 could add the /opt/ > local/etc/profile.d/perl5.8 file. > What is the 'profile' idea? Shell profile, and if so what would be in it? -eric From raimue at macports.org Tue Mar 10 13:27:36 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 10 Mar 2009 21:27:36 +0100 Subject: perl5.8 fixup In-Reply-To: <20090310200250.GB10906@darkart.com> References: <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <74403789-7EF4-4D3F-8730-8B8955CAE5D7@pixilla.com> <20090310200250.GB10906@darkart.com> Message-ID: <49B6CD38.2030105@macports.org> Eric Hall wrote: > On Mon, Mar 09, 2009 at 07:02:06PM -0700, Bradley Giesbrecht wrote: >> On Mar 9, 2009, at 5:27 PM, Marcus Calhoun-Lopez wrote: >>> There is the issue that the user must modify his or her manpath. >>> An alternate solution is to rename the manpages. >> Not according to my tests. Creating man1perl58 and man3perl58 without >> altering man paths seems to work. > > How did you test that the man pages were found? Did you check > that man found the right files and not, say, the system-installed > files? Check 'ps' for what files are being picked up. Better and easier check 'man -w' to see the filename of the man page what would have been displayed or 'man -aw' to view all in the order of the MANPATH. Rainer From mcalhoun at macports.org Tue Mar 10 13:34:54 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Tue, 10 Mar 2009 20:34:54 +0000 (UTC) Subject: perl5.8 fixup References: <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> Message-ID: Eric Hall writes: > > On Tue, Mar 10, 2009 at 01:19:12AM +0000, Marcus Calhoun-Lopez wrote: > > > > Although I do not feel strongly about it, I would still vote for the order > > site, perl base/core, vendor. > > It seems that the smaller the change, the better. > > > > For what it's worth, it is the way FreeBSD does is > > (http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/perl5.8/). > > > > I'm pretty clear that for MacPorts the order > should be site, vendor, then base. That way there is > the ability to (locally, site/user) put modules into > the first search directory, then MacPorts installed > modules are found next (from vendor), then the base > perl modules. If I understand correctly, we would continue to install all p5 ports (even conflicting ones) into vendor. Site would be left empty for the site/user to install modules. If this is the case, it seems to me we want site to be searched last. It may not be a likely scenario, but if If the site/user installs a new conflicting module which breaks a MacPorts package in some way, portfiles, have no mechanism to select the older one. The user, however, can always select whichever one he/she wants with PERL5LIB. If the consensus remains site, vendor, then base, I will drop the subject. > Note that FreeBSD puts site first *and* puts > ports-installed perl modules into site, that's probably > why they don't use vendor. I missed that, thanks. -Marcus From blb at macports.org Tue Mar 10 13:35:10 2009 From: blb at macports.org (Bryan Blackburn) Date: Tue, 10 Mar 2009 14:35:10 -0600 Subject: Trac Features In-Reply-To: References: Message-ID: <20090310203510.GC1035@ninagal.withay.com> On Tue, Mar 10, 2009 at 03:28:12PM -0400, Jeremy Lavergne said: > Is it possible that we can implement a "download all" option for tickets? > > I know it's a minority to find a port with 13 files involved, but often > enough there is at least 1 additional file. Having to click through and > download each one is something I feel we can easily fix by generating a > quick archive of the associated attachments. > > Is this something that can be done via the trac system? Not currently, see There could be a plugin for it though... Bryan From opendarwin.org at darkart.com Tue Mar 10 16:31:08 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Tue, 10 Mar 2009 23:31:08 +0000 Subject: perl5.8 fixup In-Reply-To: References: <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> Message-ID: <20090310233108.GD10906@darkart.com> On Tue, Mar 10, 2009 at 08:34:54PM +0000, Marcus Calhoun-Lopez wrote: > Eric Hall writes: > > > > > On Tue, Mar 10, 2009 at 01:19:12AM +0000, Marcus Calhoun-Lopez wrote: > > > > > > Although I do not feel strongly about it, I would still vote for the order > > > site, perl base/core, vendor. > > > It seems that the smaller the change, the better. > > > > > > For what it's worth, it is the way FreeBSD does is > > > (http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/perl5.8/). > > > > > > > I'm pretty clear that for MacPorts the order > > should be site, vendor, then base. That way there is > > the ability to (locally, site/user) put modules into > > the first search directory, then MacPorts installed > > modules are found next (from vendor), then the base > > perl modules. > > If I understand correctly, we would continue to install all > p5 ports (even conflicting ones) into vendor. > Site would be left empty for the site/user to install modules. > If this is the case, it seems to me we want site to be searched last. > It may not be a likely scenario, but if If the site/user installs a new > conflicting module which breaks a MacPorts package in some way, > portfiles, have no mechanism to select the older one. > The user, however, can always select whichever one he/she wants with PERL5LIB. > > If the consensus remains site, vendor, then base, I will drop the subject. I would think that if the site/user wants to install a particular module at a particular rev (for some sort of custom stuff), they'd want site_perl to be searched before the MP installed modules (in vendor_perl) and the base perl modules. I agree they could break stuff, to me that's a feature of having the flexibilty, not a bug, primarily because I don't expect people who don't know what they're doing to be installing modules into site_perl (even though I know perfectly well somebody will do so, and then be stuck 'cause they don't really know what they're doing). If anyone else has ideas about the ordering, please let us know shortly as I'd like to resolve this issue this week. -eric From opendarwin.org at darkart.com Tue Mar 10 16:32:25 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Tue, 10 Mar 2009 23:32:25 +0000 Subject: perl5.8 fixup In-Reply-To: <10F00A17-BD5D-4C4C-88DC-43CFF09675E8@pixilla.com> References: <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <10F00A17-BD5D-4C4C-88DC-43CFF09675E8@pixilla.com> Message-ID: <20090310233225.GE10906@darkart.com> On Mon, Mar 09, 2009 at 07:08:56PM -0700, Bradley Giesbrecht wrote: > [snip] > > Thank you very much for participating in this process that matters a > lot to me :) Its good timing, this problem has been building up for awhile now and I've finally got some time to spend on it (and it being resolved makes some other things much easier for me). -eric From brad at pixilla.com Tue Mar 10 17:04:29 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 10 Mar 2009 17:04:29 -0700 Subject: perl5.8 fixup In-Reply-To: <20090310200250.GB10906@darkart.com> References: <48C31427-A490-427E-8391-20291C81CBD3@macports.org> <49B2D9EF.2060501@macports.org> <00D20BE5-2155-4C6D-970E-47EDB001B379@pixilla.com> <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <74403789-7EF4-4D3F-8730-8B8955CAE5D7@pixilla.com> <20090310200250.GB10906@darkart.com> Message-ID: <44548059-7F0B-48F8-BB2E-26B74E5C02C1@pixilla.com> On Mar 10, 2009, at 1:02 PM, Eric Hall wrote: >> >> I think the perl5.8 compile flags alone will fix the man path >> collisions. The @INC env var looks like a good solution and I favor >> using a /opt/local/etc/profile mechanism with /opt/local/etc/ >> profile.d/ >> perl5.8 and friends. >> >> I think a new port name "profile" could be created to make this easy >> or it could become part of macports. Then perl5.8 could add the /opt/ >> local/etc/profile.d/perl5.8 file. >> > > What is the 'profile' idea? Shell profile, and if > so what would be in it? end of ~/.profile: . /opt/local/etc/profile // source the macports profile /opt/local/etc/profile: export PATH=/opt/local/bin:/opt/local/sbin/:$PATH // add PATH env for macports base for file in $(ls /opt/local/etc/profile.d/); do // /opt/local/etc/ profile.d contains env vars needed and installed by ports like perl5, mysql5 ect.... . /opt/local/etc/profile.d/$file // source the file done /opt/local/etc/profile.d/mysql5: export PATH=/opt/local/bin/mysql5:$PATH // add PATH env for mysql /opt/local/etc/profile.d/perl5.8.9: export PERL5LIB="/opt/local/lib/perl5/vendor_perl/perl5.8.9:/opt/local/ perl5/perl5.8.9:$PERL5LIB" // add perl5 module paths Something like that. So the perl5 port could add this profile.d/ perl5.8.9 file and remove it if uninstalled. With something like this adding another os user and setting up their env would be just adding the sourcing of /opt/local/etc/profile to the ~/.profile. //Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From opendarwin.org at darkart.com Tue Mar 10 17:24:02 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Wed, 11 Mar 2009 00:24:02 +0000 Subject: perl5.8 fixup In-Reply-To: References: <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> Message-ID: <20090311002402.GG10906@darkart.com> [snip] I've attached a set of patches to: http://trac.macports.org/ticket/12950#comment:14 for testing. So far so good for me. -eric From cssdev at mac.com Tue Mar 10 21:05:30 2009 From: cssdev at mac.com (cssdev at mac.com) Date: Wed, 11 Mar 2009 00:05:30 -0400 Subject: [47804] trunk/dports/devel/cmake/Portfile In-Reply-To: References: <20090306214916.5B90B1159AEF@beta.macosforge.org> <08210248-EF74-4B82-AA00-1F46B1B2A76B@mac.com> <20090307230643.GF921@ninagal.withay.com> Message-ID: On Mar 8, 2009, at 7:09 AM, Blair Zajac wrote: > On Mar 7, 2009, at 4:48 PM, Ryan Schmidt wrote: > >> On Mar 7, 2009, at 17:06, Bryan Blackburn wrote: >> >>> On Sat, Mar 07, 2009 at 05:50:09PM -0500, cssdev at mac.com said: >>> >>>> I think we should require port commits to reference existing, >>>> open Trac >>>> tickets. >>> >>> For all commits? That would be horrible, then I'd have to create >>> a ticket >>> every time I wanted to update my own ports as well. Well, one could make multiple commits against one ticket, but yes. :) Where does one draw the line between commits requiring tickets and commits that can be made by anyone with a bit? Are tickets only for commits that might need some discussion? If you're trying to track changes and the reasons behind them, is it just a matter of digging through the commit history? Browsing through related tickets? Both? I think it's really not so horrible for developers to describe changes in a consistent place before making commits into a repository. >> After a little consideration I have to agree with Bryan. There are >> many times when I want to fix a port's whitespace, or fix a typo in >> a comment, or make another minor modification for which there's no >> ticket. Forcing me to make a ticket every time would be annoying. I >> agree there are some commits that have occurred without tickets >> where tickets would have been desirable, but I think the >> disadvantages of using this hook outweigh its benefits for MacPorts. > > +1. A little too much process there. The commit message should > fully describe the change if there's no Trac ticket then. I appreciate the feedback, and I recognize that such a hook might be too cumbersome for MacPorts. I also appreciate the proactive enhancements that help to benefit the project and move things forward. I'll get back to checking my builds! :) Thanks, Chris From raimue at macports.org Wed Mar 11 05:07:49 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 11 Mar 2009 13:07:49 +0100 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: <49B52CF9.7060905@macports.org> References: <49B52CF9.7060905@macports.org> Message-ID: <49B7A995.30509@macports.org> Rainer M?ller wrote: > Also, if you have a specific idea what could be improved in MacPorts, > but you never had the time to do it yourself, please put a proposal on > our ideas page. I already cleared up the list from the last year and > there are still interesting and important projects on it. And we need > mentors for these, of course. > > Ideas page: http://trac.macports.org/wiki/SummerOfCode I have no clue about this task here: http://trac.macports.org/wiki/SummerOfCode#images Can anybody explain why that would be useful? In my opinion, linking to the depot would be bad as every dependent port would break on an upgrade, even if you only changed variants. Should we keep it on the ideas page? Rainer From jmr at macports.org Wed Mar 11 05:21:46 2009 From: jmr at macports.org (Joshua Root) Date: Wed, 11 Mar 2009 23:21:46 +1100 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: <49B7A995.30509@macports.org> References: <49B52CF9.7060905@macports.org> <49B7A995.30509@macports.org> Message-ID: <49B7ACDA.5070208@macports.org> Rainer M?ller wrote: > Rainer M?ller wrote: >> Also, if you have a specific idea what could be improved in MacPorts, >> but you never had the time to do it yourself, please put a proposal on >> our ideas page. I already cleared up the list from the last year and >> there are still interesting and important projects on it. And we need >> mentors for these, of course. >> >> Ideas page: http://trac.macports.org/wiki/SummerOfCode > > I have no clue about this task here: > http://trac.macports.org/wiki/SummerOfCode#images > > Can anybody explain why that would be useful? In my opinion, linking to > the depot would be bad as every dependent port would break on an > upgrade, even if you only changed variants. Should we keep it on the > ideas page? This was one of Jordan's crazy ideas IIRC, and there's a reason it's classified as very challenging. The idea, as I understand it, is that you wouldn't be able to uninstall the old version when something is linked against it. This project of course requires the ability to depend on specific version ranges of ports (being able to exclude both too old and too new), and likewise with variants. There would also need to be a way to manage rebuilds when existing software would work with a newer version, and you want to get rid of the old one. (And other such interactions involving variants etc.) - Josh From raimue at macports.org Wed Mar 11 09:24:42 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Wed, 11 Mar 2009 17:24:42 +0100 Subject: [MacPorts] #16372: version update request psycopg2 2.0.5.1 --> 2.0.7x In-Reply-To: <071.ef0c919144dae7921e29a91491ccd9ff@macports.org> References: <062.32ada7ee01022fd10bd160d881ca659c@macports.org> <071.ef0c919144dae7921e29a91491ccd9ff@macports.org> Message-ID: <49B7E5CA.6050309@macports.org> MacPorts wrote: > #16372: version update request psycopg2 2.0.5.1 --> 2.0.7x > ----------------------------------------+----------------------------------- > Reporter: jbusser@? | Owner: landonf@? > Type: enhancement | Status: new > Priority: Normal | Milestone: Port Updates > Component: ports | Version: 1.6.0 > Keywords: | Port: py-psycopg2 > ----------------------------------------+----------------------------------- > > Comment(by snc@?): > > Should the prefix be changed to py24? This was discussed before, but there is currently no way to rename ports easily without causing potential problems on the user end. We would not gain much from such a rename, so better just keep py-*. As python26 is out now, I would rather see a push to remove python24 and move ports to use python25/python26. $ port echo depends:python24 and not 'py-*' |wc -l 54 $ port echo depends:python25 and not 'py25-*' |wc -l 73 Still a lot of ports in comparison. Rainer From raimue at macports.org Wed Mar 11 09:30:14 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 11 Mar 2009 17:30:14 +0100 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: <49B52CF9.7060905@macports.org> References: <49B52CF9.7060905@macports.org> Message-ID: <49B7E716.4040302@macports.org> Rainer M?ller wrote: > MacPorts will apply to be one of the mentoring organizations. The > students can propose their project ideas to us and we will choose the > most appealing applications. For the students application, I added the following additional questions to be required: * What are your experiences with Mac OS X so far? (How long do you use it, did you switch from Windows/Linux, etc.) * How long do you already use MacPorts? * Have you already made contributions to MacPorts? (New ports, port updates, etc.) * Do you have experience with other package management systems? (Gentoo Portage, FreeBSD ports, Debian APT, etc.) If other mentors are interested in other aspects of the student's background, let me know and I can add more. Rainer From brad at pixilla.com Wed Mar 11 10:13:01 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Wed, 11 Mar 2009 10:13:01 -0700 Subject: perl5.8 fixup In-Reply-To: <20090311002402.GG10906@darkart.com> References: <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> Message-ID: On Mar 10, 2009, at 5:24 PM, Eric Hall wrote: > [snip] > > I've attached a set of patches to: > > http://trac.macports.org/ticket/12950#comment:14 > > for testing. So far so good for me. Is anyone else having difficulty downloading these patches? http://trac.macports.org/attachment/ticket/12950/Portfile.20090310.1655.patch and http://trac.macports.org/attachment/ticket/12950/p5-test-simple.Portfile.patch are loading blank pages for me. I was able to download the two other recently submitted patches. //Brad From brad at pixilla.com Wed Mar 11 10:18:02 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Wed, 11 Mar 2009 10:18:02 -0700 Subject: perl5.8 fixup In-Reply-To: References: <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> Message-ID: On Mar 11, 2009, at 10:13 AM, Bradley Giesbrecht wrote: > > On Mar 10, 2009, at 5:24 PM, Eric Hall wrote: > >> [snip] >> >> I've attached a set of patches to: >> >> http://trac.macports.org/ticket/12950#comment:14 >> >> for testing. So far so good for me. > > Is anyone else having difficulty downloading these patches? > > http://trac.macports.org/attachment/ticket/12950/Portfile.20090310.1655.patch > > and > > http://trac.macports.org/attachment/ticket/12950/p5-test-simple.Portfile.patch > > are loading blank pages for me. > > I was able to download the two other recently submitted patches. Well that was strange. Hit refresh 4 or 5 times and it loaded. The first time it loaded the page format was wacked. The time was 10:14 PST if anyone wants to look at the server logs for something interesting. //Brad From raimue at macports.org Wed Mar 11 10:53:43 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 11 Mar 2009 18:53:43 +0100 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: <0ED34EB5-D9D6-42B8-8435-5FD595DEFA9F@lavergne.gotdns.org> References: <49B52CF9.7060905@macports.org> <49B7E716.4040302@macports.org> <0ED34EB5-D9D6-42B8-8435-5FD595DEFA9F@lavergne.gotdns.org> Message-ID: <49B7FAA7.40302@macports.org> Jeremy Lavergne wrote: > How familiar are they with the languages we use in MacPorts? Okay, that would be: * How much experience do you have with Tcl and C? In my opinion, having experience with Tcl is a weak criterion. There is the community bonding period (about 4 weeks) during which students should introduce themselves on mailing lists and make contact with the mentor. This phase can also be used to learn Tcl if they already have experience with scripting languages in general. In last years applications, most students already included their skills in programming languages on their own without such a question required by us. Rainer From brad at pixilla.com Wed Mar 11 11:29:35 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Wed, 11 Mar 2009 11:29:35 -0700 Subject: perl5.8 fixup In-Reply-To: <20090311002402.GG10906@darkart.com> References: <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> Message-ID: <3ADC7ED3-13E3-4E3C-BCF4-B008A48386B0@pixilla.com> On Mar 10, 2009, at 5:24 PM, Eric Hall wrote: > [snip] > > I've attached a set of patches to: > > http://trac.macports.org/ticket/12950#comment:14 > > for testing. So far so good for me. I'm testing your patches now. Small point. Looks like you want to change the patchfile name in perl5.8/Portfile or change the name of the patch file. Portfile: patch-perl.c.diff Actual file: patch-perl.c.2.diff -------------- next part -------------- An HTML attachment was scrubbed... URL: From opendarwin.org at darkart.com Wed Mar 11 11:43:36 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Wed, 11 Mar 2009 18:43:36 +0000 Subject: perl5.8 fixup In-Reply-To: <3ADC7ED3-13E3-4E3C-BCF4-B008A48386B0@pixilla.com> References: <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> <3ADC7ED3-13E3-4E3C-BCF4-B008A48386B0@pixilla.com> Message-ID: <20090311184335.GH10906@darkart.com> On Wed, Mar 11, 2009 at 11:29:35AM -0700, Bradley Giesbrecht wrote: > > On Mar 10, 2009, at 5:24 PM, Eric Hall wrote: > > >[snip] > > > > I've attached a set of patches to: > > > > http://trac.macports.org/ticket/12950#comment:14 > > > > for testing. So far so good for me. > > I'm testing your patches now. > Small point. Looks like you want to change the patchfile name in > perl5.8/Portfile or change the name of the patch file. > > Portfile: patch-perl.c.diff > Actual file: patch-perl.c.2.diff > Argh. That's a 'feature' of trac - it bumped the filename as I didn't tell it to overwrite the file of the same name. You can change either the portfile or the filename of the patch for testing, it will be 'patch-perl.c.diff' when committed. -eric From brad at pixilla.com Wed Mar 11 12:14:31 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Wed, 11 Mar 2009 12:14:31 -0700 Subject: perl5.8 fixup In-Reply-To: <20090311184335.GH10906@darkart.com> References: <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> <3ADC7ED3-13E3-4E3C-BCF4-B008A48386B0@pixilla.com> <20090311184335.GH10906@darkart.com> Message-ID: <402D5D60-56C4-4684-B2D7-6CA4C57F9A9B@pixilla.com> On Mar 11, 2009, at 11:43 AM, Eric Hall wrote: > On Wed, Mar 11, 2009 at 11:29:35AM -0700, Bradley Giesbrecht wrote: >> >> On Mar 10, 2009, at 5:24 PM, Eric Hall wrote: >> >>> [snip] >>> >>> I've attached a set of patches to: >>> >>> http://trac.macports.org/ticket/12950#comment:14 >>> >>> for testing. So far so good for me. >> >> I'm testing your patches now. >> Small point. Looks like you want to change the patchfile name in >> perl5.8/Portfile or change the name of the patch file. >> >> Portfile: patch-perl.c.diff >> Actual file: patch-perl.c.2.diff >> > > Argh. That's a 'feature' of trac - it bumped the filename > as I didn't tell it to overwrite the file of the same name. > You can change either the portfile or the filename of the > patch for testing, it will be 'patch-perl.c.diff' when > committed. I've just tested on p5. This is a G4 with a clean macports I put together just for this test. I will also test on a live system with existing perl5.8 and p5's. Here is my initial result: ChromeG4 root# port installed No ports are installed. ChromeG4 root# port install p5-cgi /* no errors to speak of */ ChromeG4 root# port installed The following ports are currently installed: p5-cgi @3.42_0 (active) perl5 @5.8.9_0 (active) perl5.8 @5.8.9_3 (active) ChromeG4 root# man -wa CGI /opt/local/man/man3/CGI.3pm.gz /opt/local/share/man/man3/CGI.3pm.gz /usr/share/man/man3/CGI.3pm /opt/local/man/man3p/CGI.3pm /opt/local/share/man/man3p/CGI.3pm ChromeG4 root# perl -MCGI -le 'print $INC{"CGI.pm"}' /opt/local/lib/perl5/vendor_perl/5.8.9/CGI.pm ChromeG4 root# Looks like there is a slight problem with the man pages. Looks like man searches all paths for man1 then man2 and so on to man3 then man3p or something a little wierd because even with a MANPATH env like "export MANPATH=/opt/local/share/man:$MANPATH" the /usr/share/man/man3 is showing up before /opt/local/man/man3p. I'm not that familiar with man's configuration or flags so maybe I'm misinterpreting this output. If that is the case we might do something like /opt/local/share/ perl5.8/man for the perl module man pages and add that to the MANPATH env after /opt/local/share/man and before $MANPATH. I'm still performing more tests and will report back. //Brad From brad at pixilla.com Wed Mar 11 12:22:53 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Wed, 11 Mar 2009 12:22:53 -0700 Subject: Trac Features In-Reply-To: References: Message-ID: On Mar 10, 2009, at 12:28 PM, Jeremy Lavergne wrote: > Is it possible that we can implement a "download all" option for > tickets? > > I know it's a minority to find a port with 13 files involved, but > often enough there is at least 1 additional file. Having to click > through and download each one is something I feel we can easily fix > by generating a quick archive of the associated attachments. > > Is this something that can be done via the trac system? I was just thinking the same thing while downloading the perl5.8 patches. Maybe the next time some maintenance is down on the trac server who's ever in charge could take a quick stab at it :) //Brad From jkh at apple.com Wed Mar 11 13:04:19 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Wed, 11 Mar 2009 13:04:19 -0700 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: <49B7ACDA.5070208@macports.org> References: <49B52CF9.7060905@macports.org> <49B7A995.30509@macports.org> <49B7ACDA.5070208@macports.org> Message-ID: <048D3DD7-B7B2-4EF2-BE7A-1CD847A56BB7@apple.com> On Mar 11, 2009, at 5:21 AM, Joshua Root wrote: > This was one of Jordan's crazy ideas IIRC, and there's a reason it's > classified as very challenging. The idea, as I understand it, is that > you wouldn't be able to uninstall the old version when something is > linked against it. Correct, though I don't know how "crazy" of an idea it is to try and make any collection involving hundreds, if not thousands, of software packages installed on any machine more robust in the face of version skew. :-) More to the point, there are already scenarios today (and far more in FreeBSD's ports collection, where the efforts to address this have taken on an increasingly desperate and hacky nature) where you simply cannot have two desired ports installed at the same time due to conflicting, mutually-exclusive dependencies. Port Foo depends on library Bar, version X. Port Blah depends on library Bar, version Y. X and Y are incompatible with eachother, and Foo cannot be easily ported to Bar-Y, just as Blah cannot be easily ported to Bar-X (we're talking about some old software in many situations, where there's just no one available to fix things "correctly" by adapting to the latest revision of Bar). Even if you do get volunteers to do the heavy lifting required once, after it breaks for the 2nd or 3rd time (and this is not so rare a scenario where things like Tcl or OpenSSL have been concerned, just to cite 2 quick examples) it quickly gets old and people are more tempted to walk away and simply let things rot in place, which is a bummer if you were one of the users who really liked being able to use Foo or Blah. Naturally, if we had more control over the filesystem lookup layer (or could use dyld interpositioning in such a way that every single relevant process in a given session got successfully interposed) then we could solve this at the "right" layer by simply redirecting Foo and Blah's requests for Bar files such that they went to the right place, without having to build either Foo or Bar in any particularly special way, but that's an even "crazier" suggestion and one likely to be so involved that nobody is going to want to even think of tackling the problem. By contrast, simply making sure that everything hooks into the depot location rather than looking directly in ${prefix} seems a lot simpler. Rainer also points out the upgrade problem, which is of course an important point. If you want to upgrade Bar (either X or Y) then you need to figure out some way of upgrading it in-place or settle for the trade-off of simply creating Bar-Z and retrying the builds of Foo and Blah against it, hoping that maybe the Bar folks have solved the compatibility issues. This is not a heck of a lot different than bumping the version / revision number on a dylib, however, since you have to also upgrade *those* in-place in order to get the benefit of some security update or other issue important enough to accept the risky proposition of upgrading a dylib in-place. In short, my crazy idea does not introduce any issues we do not have already today, and solves a number of issues for which we have *no* solution at present. > This project of course requires the ability to depend on specific > version ranges of ports (being able to exclude both too old and too > new), and likewise with variants. There would also need to be a way to > manage rebuilds when existing software would work with a newer > version, > and you want to get rid of the old one. (And other such interactions > involving variants etc.) Yep. I think what we ultimately need is a tuple containing port, version, variant-list which gets looked at in satisfying any dependencies, and we make the "binding precedence" follow the same order: First you look for port, then you look for version, then you look for (if the depending port even specifies a preference) the specific variant. If the port has declared one or both of the latter two items as "soft" dependencies, or has wild-carded them somehow, you can also fall back to a non-exact match rather than forcing a build of that specific tuple. Of course, since things also depend on the depot locations rather than the bits in ${prefix} in my crazy idea, it also means that you can have multiple variants of a given port installed at the same time, so all you're burning is some extra disk space and CPU time in the interests of a more exact functional match. - Jordan From jeremy at lavergne.gotdns.org Wed Mar 11 13:06:22 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 11 Mar 2009 16:06:22 -0400 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: <048D3DD7-B7B2-4EF2-BE7A-1CD847A56BB7@apple.com> References: <49B52CF9.7060905@macports.org> <49B7A995.30509@macports.org> <49B7ACDA.5070208@macports.org> <048D3DD7-B7B2-4EF2-BE7A-1CD847A56BB7@apple.com> Message-ID: >> This project of course requires the ability to depend on specific >> version ranges of ports (being able to exclude both too old and too >> new), and likewise with variants. There would also need to be a way >> to >> manage rebuilds when existing software would work with a newer >> version, >> and you want to get rid of the old one. (And other such interactions >> involving variants etc.) > > Yep. I think what we ultimately need is a tuple containing port, > version, variant-list which gets looked at in satisfying any > dependencies, and we make the "binding precedence" follow the same > order: First you look for port, then you look for version, then you > look for (if the depending port even specifies a preference) the > specific variant. If the port has declared one or both of the > latter two items as "soft" dependencies, or has wild-carded them > somehow, you can also fall back to a non-exact match rather than > forcing a build of that specific tuple. Of course, since things > also depend on the depot locations rather than the bits in ${prefix} > in my crazy idea, it also means that you can have multiple variants > of a given port installed at the same time, so all you're burning is > some extra disk space and CPU time in the interests of a more exact > functional match. Sounds like a good time to get sqlite support running. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jmr at macports.org Wed Mar 11 13:28:12 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 12 Mar 2009 07:28:12 +1100 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: <048D3DD7-B7B2-4EF2-BE7A-1CD847A56BB7@apple.com> References: <49B52CF9.7060905@macports.org> <49B7A995.30509@macports.org> <49B7ACDA.5070208@macports.org> <048D3DD7-B7B2-4EF2-BE7A-1CD847A56BB7@apple.com> Message-ID: <49B81EDC.10102@macports.org> Jordan K. Hubbard wrote: > > On Mar 11, 2009, at 5:21 AM, Joshua Root wrote: > >> This was one of Jordan's crazy ideas IIRC, and there's a reason it's >> classified as very challenging. The idea, as I understand it, is that >> you wouldn't be able to uninstall the old version when something is >> linked against it. > > Correct, though I don't know how "crazy" of an idea it is to try and > make any collection involving hundreds, if not thousands, of software > packages installed on any machine more robust in the face of version > skew. :-) Read "crazy" as "revolutionary" if you prefer. :-) - Josh From jmr at macports.org Wed Mar 11 13:29:14 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 12 Mar 2009 07:29:14 +1100 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: References: <49B52CF9.7060905@macports.org> <49B7A995.30509@macports.org> <49B7ACDA.5070208@macports.org> <048D3DD7-B7B2-4EF2-BE7A-1CD847A56BB7@apple.com> Message-ID: <49B81F1A.2090002@macports.org> Jeremy Lavergne wrote: >>> This project of course requires the ability to depend on specific >>> version ranges of ports (being able to exclude both too old and too >>> new), and likewise with variants. There would also need to be a way to >>> manage rebuilds when existing software would work with a newer version, >>> and you want to get rid of the old one. (And other such interactions >>> involving variants etc.) >> >> Yep. I think what we ultimately need is a tuple containing port, >> version, variant-list which gets looked at in satisfying any >> dependencies, and we make the "binding precedence" follow the same >> order: First you look for port, then you look for version, then you >> look for (if the depending port even specifies a preference) the >> specific variant. If the port has declared one or both of the latter >> two items as "soft" dependencies, or has wild-carded them somehow, you >> can also fall back to a non-exact match rather than forcing a build of >> that specific tuple. Of course, since things also depend on the depot >> locations rather than the bits in ${prefix} in my crazy idea, it also >> means that you can have multiple variants of a given port installed at >> the same time, so all you're burning is some extra disk space and CPU >> time in the interests of a more exact functional match. > > Sounds like a good time to get sqlite support running. It's always been a good time. ;-) There are lots of bugs and enhancement requests that need registry2.0. - Josh From toby at macports.org Wed Mar 11 13:36:39 2009 From: toby at macports.org (Toby Peterson) Date: Wed, 11 Mar 2009 13:36:39 -0700 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: References: <49B52CF9.7060905@macports.org> <49B7A995.30509@macports.org> <49B7ACDA.5070208@macports.org> <048D3DD7-B7B2-4EF2-BE7A-1CD847A56BB7@apple.com> Message-ID: <74c219d30903111336s2e9e9325k957a65283b91ec9c@mail.gmail.com> On Wed, Mar 11, 2009 at 13:06, Jeremy Lavergne wrote: > Sounds like a good time to get sqlite support running. +1 This is a much more manageable task that will have tangible benefits. Although it'd probably be rolled into something else, because I don't think it's a whole summer's worth of work - probably a week for a sufficiently motivated individual. - Toby From jeremy at lavergne.gotdns.org Wed Mar 11 13:38:06 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 11 Mar 2009 16:38:06 -0400 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: <74c219d30903111336s2e9e9325k957a65283b91ec9c@mail.gmail.com> References: <49B52CF9.7060905@macports.org> <49B7A995.30509@macports.org> <49B7ACDA.5070208@macports.org> <048D3DD7-B7B2-4EF2-BE7A-1CD847A56BB7@apple.com> <74c219d30903111336s2e9e9325k957a65283b91ec9c@mail.gmail.com> Message-ID: <088F948C-95D9-4829-A7C4-E77D0B7CD850@lavergne.gotdns.org> >> Sounds like a good time to get sqlite support running. > > +1 > > This is a much more manageable task that will have tangible benefits. > Although it'd probably be rolled into something else, because I don't > think it's a whole summer's worth of work - probably a week for a > sufficiently motivated individual. Hehe, how long has that one been on the drawing board? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From dluke at geeklair.net Wed Mar 11 13:47:02 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed, 11 Mar 2009 16:47:02 -0400 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: <048D3DD7-B7B2-4EF2-BE7A-1CD847A56BB7@apple.com> References: <49B52CF9.7060905@macports.org> <49B7A995.30509@macports.org> <49B7ACDA.5070208@macports.org> <048D3DD7-B7B2-4EF2-BE7A-1CD847A56BB7@apple.com> Message-ID: <638AEE81-EA82-4289-A46C-5EA56D869F3D@geeklair.net> On Mar 11, 2009, at 4:04 PM, Jordan K. Hubbard wrote: > More to the point, there are already scenarios today (and far more > in FreeBSD's ports collection, where the efforts to address this > have taken on an increasingly desperate and hacky nature) where you > simply cannot have two desired ports installed at the same time due > to conflicting, mutually-exclusive dependencies. Port Foo depends > on library Bar, version X. Port Blah depends on library Bar, > version Y. X and Y are incompatible with eachother, and Foo cannot > be easily ported to Bar-Y, just as Blah cannot be easily ported to > Bar-X (we're talking about some old software in many situations, > where there's just no one available to fix things "correctly" by > adapting to the latest revision of Bar). or port foo could just statically link to version X of the library and port blah can statically (or dynamically) link to version Y. (the build process for port foo could even build the old version X lib). > simply making sure that everything hooks into the depot location > rather than looking directly in ${prefix} seems a lot simpler. I don't really want every version of every library on my system available for things to link to. Even if we somehow only track ABI changes, I still probably don't want every ABI version around. Especially in cases where the older version is being kept around simply for compatibility with applications that no one is currently updating to 'new' libraries, I don't want to have to attempt to back- port any security fixes from the newer (and incompatible) versions of the library to the older one [and in some cases, it would probably be non-trivial to do so]. ... but I've raised this issue before and haven't gotten a response, so perhaps I'm missing some reason why this isn't an issue? > it also means that you can have multiple variants of a given port > installed at the same time, so all you're burning is some extra disk > space and CPU time in the interests of a more exact functional match. And in case of shared libraries loosing 'shared' magic (since several programs could have their own version+variant installed because it matched more closely) -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From ryandesign at macports.org Wed Mar 11 14:43:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 11 Mar 2009 16:43:29 -0500 Subject: [47962] trunk/dports/net In-Reply-To: <20090311184806.370EC11A3F5A@beta.macosforge.org> References: <20090311184806.370EC11A3F5A@beta.macosforge.org> Message-ID: <997D5139-A222-4C4F-B7AB-2A1BEBEF59A3@macports.org> On Mar 11, 2009, at 13:48, snc at macports.org wrote: > Revision: 47962 > http://trac.macports.org/changeset/47962 > Author: snc at macports.org > Date: 2009-03-11 11:48:05 -0700 (Wed, 11 Mar 2009) > Log Message: > ----------- > created argus-clients, ticket #18792 [snip] > +default_variants +graph > + > +variant graph description {Build ragraph (depends on rrdtool)} { > + depends_lib-append port:rrdtool > +} Why make it a variant and then make it the default? This makes it hard for anyone to deselect the variant since MacPorts does not record negative variants in the registry. If you want the feature enabled by default but want a way for people to disable it, code the portfile to enable the feature, and then have a "no_graph" variant to remove it. From ryandesign at macports.org Wed Mar 11 14:45:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 11 Mar 2009 16:45:41 -0500 Subject: [47969] trunk/dports/graphics/jpeg/Portfile In-Reply-To: <20090311212923.8D13B11A957E@beta.macosforge.org> References: <20090311212923.8D13B11A957E@beta.macosforge.org> Message-ID: <73266C1D-40D6-433C-9762-CD1ACA78F964@macports.org> On Mar 11, 2009, at 16:29, mcalhoun at macports.org wrote: > Revision: 47969 > http://trac.macports.org/changeset/47969 > Author: mcalhoun at macports.org > Date: 2009-03-11 14:29:23 -0700 (Wed, 11 Mar 2009) > Log Message: > ----------- > jpeg: Prevent linker from finding wrong library and header files. > Fixes #16411 (maintainer timeout). > Revision not increased because the library should have built > correctly or not at all. > > Modified Paths: > -------------- > trunk/dports/graphics/jpeg/Portfile > > Modified: trunk/dports/graphics/jpeg/Portfile > =================================================================== > --- trunk/dports/graphics/jpeg/Portfile 2009-03-11 21:26:37 UTC > (rev 47968) > +++ trunk/dports/graphics/jpeg/Portfile 2009-03-11 21:29:23 UTC > (rev 47969) > @@ -40,6 +40,14 @@ > post-patch { > system "cd ${worksrcpath} && > tar zxf ${distpath}/droppatch.tar.gz" > + > + # Reorder link flags so that so that local -L options come > first (especially before -L${prefix}/lib) > + # (see http://trac.macports.org/ticket/16411). > + reinplace "s|\\(.*\\)\\(\$(LDFLAGS)\\)\\(.*\\)\\(\$(LDLIBS)\\)\ > \(.*\\)|\\1\\4\\3\\2\\5|" ${worksrcpath}/makefile.cfg This is hard to decipher. Could it be implemented as a patchfile instead, or would that be huge? > + # As in the case of -L, CPPFLAGS come before -I. during > compilation. > + configure.cppflags-append -isystem${prefix}/include > + configure.cppflags-delete -I${prefix}/include What is the story behind using -isystem instead of -I? Where does that come from? Is this a change that would be useful generally? Should MacPorts base do this? From mcalhoun at macports.org Wed Mar 11 15:08:04 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Wed, 11 Mar 2009 22:08:04 +0000 (UTC) Subject: [47969] trunk/dports/graphics/jpeg/Portfile References: <20090311212923.8D13B11A957E@beta.macosforge.org> <73266C1D-40D6-433C-9762-CD1ACA78F964@macports.org> Message-ID: Ryan Schmidt writes: > > > + > > + # Reorder link flags so that so that local -L options come > > first (especially before -L${prefix}/lib) > > + # (see http://trac.macports.org/ticket/16411). > > + reinplace "s|\\(.*\\)\\(\$(LDFLAGS)\\)\\(.*\\)\\(\$(LDLIBS)\\)\ > > \(.*\\)|\\1\\4\\3\\2\\5|" ${worksrcpath}/makefile.cfg > > This is hard to decipher. Could it be implemented as a patchfile > instead, or would that be huge? As I recall there were four or five instances which had to be changed, so a patchfile would not be too bad. I was hoping the comment would make it more palatable. > > > + # As in the case of -L, CPPFLAGS come before -I. during > > compilation. > > + configure.cppflags-append -isystem${prefix}/include > > + configure.cppflags-delete -I${prefix}/include > > What is the story behind using -isystem instead of -I? Where does > that come from? > > Is this a change that would be useful generally? Should MacPorts base > do this? I saw in the output that -I${prefix}/include was first during compilation. For me, this has been an issue with ghostscript and qt4-mac: http://trac.macports.org/changeset/42207/trunk/dports/print/ghostscript/Portfile http://trac.macports.org/changeset/47699/trunk/dports/aqua/qt4-mac/Portfile It seems to have been an issue for others. There are a number of ports with -I${worksrcpath}. I can not speak for all of them, but mono at least seems to have picked up the wrong header file: http://trac.macports.org/changeset/46637 -Marcus From jmr at macports.org Wed Mar 11 15:13:04 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 12 Mar 2009 09:13:04 +1100 Subject: [47969] trunk/dports/graphics/jpeg/Portfile In-Reply-To: <73266C1D-40D6-433C-9762-CD1ACA78F964@macports.org> References: <20090311212923.8D13B11A957E@beta.macosforge.org> <73266C1D-40D6-433C-9762-CD1ACA78F964@macports.org> Message-ID: <49B83770.6040208@macports.org> Ryan Schmidt wrote: > > On Mar 11, 2009, at 16:29, mcalhoun at macports.org wrote: > >> Revision: 47969 >> http://trac.macports.org/changeset/47969 >> Author: mcalhoun at macports.org >> Date: 2009-03-11 14:29:23 -0700 (Wed, 11 Mar 2009) >> Log Message: >> ----------- >> jpeg: Prevent linker from finding wrong library and header files. >> Fixes #16411 (maintainer timeout). >> Revision not increased because the library should have built correctly >> or not at all. >> >> Modified Paths: >> -------------- >> trunk/dports/graphics/jpeg/Portfile >> >> Modified: trunk/dports/graphics/jpeg/Portfile >> =================================================================== >> --- trunk/dports/graphics/jpeg/Portfile 2009-03-11 21:26:37 UTC >> (rev 47968) >> +++ trunk/dports/graphics/jpeg/Portfile 2009-03-11 21:29:23 UTC >> (rev 47969) >> @@ -40,6 +40,14 @@ >> post-patch { >> system "cd ${worksrcpath} && >> tar zxf ${distpath}/droppatch.tar.gz" >> + >> + # Reorder link flags so that so that local -L options come first >> (especially before -L${prefix}/lib) >> + # (see http://trac.macports.org/ticket/16411). >> + reinplace >> "s|\\(.*\\)\\(\$(LDFLAGS)\\)\\(.*\\)\\(\$(LDLIBS)\\)\\(.*\\)|\\1\\4\\3\\2\\5|" >> ${worksrcpath}/makefile.cfg > > This is hard to decipher. Could it be implemented as a patchfile > instead, or would that be huge? It could be made less indecipherable by using braces instead of quotes, since no variables need to be expanded in the reinplace expression. - Josh From usx303 at googlemail.com Wed Mar 11 15:34:57 2009 From: usx303 at googlemail.com (Uwe Schwartz) Date: Wed, 11 Mar 2009 23:34:57 +0100 Subject: [47962] trunk/dports/net In-Reply-To: <997D5139-A222-4C4F-B7AB-2A1BEBEF59A3@macports.org> References: <20090311184806.370EC11A3F5A@beta.macosforge.org> <997D5139-A222-4C4F-B7AB-2A1BEBEF59A3@macports.org> Message-ID: Okay, I am going to fix that. I think, I can supply a patch tomorrow. Regards, Uwe On Wed, Mar 11, 2009 at 10:43 PM, Ryan Schmidt wrote: > On Mar 11, 2009, at 13:48, snc at macports.org wrote: > > Revision: 47962 >> http://trac.macports.org/changeset/47962 >> Author: snc at macports.org >> Date: 2009-03-11 11:48:05 -0700 (Wed, 11 Mar 2009) >> Log Message: >> ----------- >> created argus-clients, ticket #18792 >> > > [snip] > > +default_variants +graph >> + >> +variant graph description {Build ragraph (depends on rrdtool)} { >> + depends_lib-append port:rrdtool >> +} >> > > Why make it a variant and then make it the default? This makes it hard for > anyone to deselect the variant since MacPorts does not record negative > variants in the registry. If you want the feature enabled by default but > want a way for people to disable it, code the portfile to enable the > feature, and then have a "no_graph" variant to remove it. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkh at apple.com Wed Mar 11 17:25:20 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Wed, 11 Mar 2009 17:25:20 -0700 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: <638AEE81-EA82-4289-A46C-5EA56D869F3D@geeklair.net> References: <49B52CF9.7060905@macports.org> <49B7A995.30509@macports.org> <49B7ACDA.5070208@macports.org> <048D3DD7-B7B2-4EF2-BE7A-1CD847A56BB7@apple.com> <638AEE81-EA82-4289-A46C-5EA56D869F3D@geeklair.net> Message-ID: <5DC9FC1B-1BA0-49A0-B5DE-912BF5FFF0F7@apple.com> On Mar 11, 2009, at 1:47 PM, Daniel J. Luke wrote: > On Mar 11, 2009, at 4:04 PM, Jordan K. Hubbard wrote: >> More to the point, there are already scenarios today (and far more >> in FreeBSD's ports collection, where the efforts to address this >> have taken on an increasingly desperate and hacky nature) where you >> simply cannot have two desired ports installed at the same time due >> to conflicting, mutually-exclusive dependencies. Port Foo depends >> on library Bar, version X. Port Blah depends on library Bar, >> version Y. X and Y are incompatible with eachother, and Foo cannot >> be easily ported to Bar-Y, just as Blah cannot be easily ported to >> Bar-X (we're talking about some old software in many situations, >> where there's just no one available to fix things "correctly" by >> adapting to the latest revision of Bar). > > or port foo could just statically link to version X of the library > and port blah can statically (or dynamically) link to version Y. > (the build process for port foo could even build the old version X > lib). That wouldn't work as a general rule, since back when "foo" was created, X would also likely be the "latest and greatest" and, of course, you would want to ship that as a .dylib since shipping it as a static archive would mean that every client embedded a copy of X within itself, leading to bloated memory consumption and no opportunity to ever update X in-place for security reasons, as previously discussed. This is why static archives are generally discouraged on MacOSX - you want the extra level of indirection in fulfilling the API contract. > I don't really want every version of every library on my system > available for things to link to. Even if we somehow only track ABI > changes, I still probably don't want every ABI version around. Maybe *you* don't, but anyone who needs every library on their system available for other reasons, and does a halfway reasonable job of garbage collection once in awhile, is not going to share that opinion at all. - Jordan From dluke at geeklair.net Wed Mar 11 21:11:19 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Thu, 12 Mar 2009 00:11:19 -0400 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: <5DC9FC1B-1BA0-49A0-B5DE-912BF5FFF0F7@apple.com> References: <49B52CF9.7060905@macports.org> <49B7A995.30509@macports.org> <49B7ACDA.5070208@macports.org> <048D3DD7-B7B2-4EF2-BE7A-1CD847A56BB7@apple.com> <638AEE81-EA82-4289-A46C-5EA56D869F3D@geeklair.net> <5DC9FC1B-1BA0-49A0-B5DE-912BF5FFF0F7@apple.com> Message-ID: <2F17D59A-E3B5-4842-A310-44E8A451A385@geeklair.net> On Mar 11, 2009, at 8:25 PM, Jordan K. Hubbard wrote: >> or port foo could just statically link to version X of the library >> and port blah can statically (or dynamically) link to version Y. >> (the build process for port foo could even build the old version X >> lib). > > That wouldn't work as a general rule, since back when "foo" was > created, X would also likely be the "latest and greatest" and, of > course, you would want to ship that as a .dylib since shipping it as > a static archive would mean that every client embedded a copy of X > within itself, leading to bloated memory consumption and no > opportunity to ever update X in-place for security reasons, as > previously discussed. Right, so when X is latest and greatest, you don't statically link, but when you have to keep around old foo because it won't be updated for Y, you can just rebuild foo and statically link foo with the old X. The problems you mention (bloated memory consumption, and hard to do security updates) are also present with the more complex solution of having every version available for linking in the depot. At least with statically linking the old and unmaintained program, the choice is not automatic and the brokenness is contained to that program. > This is why static archives are generally discouraged on MacOSX - > you want the extra level of indirection in fulfilling the API > contract. indeed. In the case where you're installing an old and unmaintained library, though, I think it's desirable to limit it to only the old and unmaintained application that requires it, instead of having it generally available on the system. >> I don't really want every version of every library on my system >> available for things to link to. Even if we somehow only track ABI >> changes, I still probably don't want every ABI version around. > > Maybe *you* don't, but anyone who needs every library on their > system available for other reasons, and does a halfway reasonable > job of garbage collection once in awhile, is not going to share that > opinion at all. until they get rooted because one version of the old lib they have (and didn't realize things were linked to) had a bug that never got fixed in that old version (since it was fixed in a 'supported' version, and not the obsolete one that was still around). If the only benefit is keeping older applications running even when newer libs change the ABI or API and the older application can't be updated to use the new lib, then I don't see how the extra complication of having every version around and available for linking is the best solution. Maybe there's some other problem it solves that I'm not seeing? -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jkh at apple.com Wed Mar 11 22:15:02 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Wed, 11 Mar 2009 22:15:02 -0700 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: <2F17D59A-E3B5-4842-A310-44E8A451A385@geeklair.net> References: <49B52CF9.7060905@macports.org> <49B7A995.30509@macports.org> <49B7ACDA.5070208@macports.org> <048D3DD7-B7B2-4EF2-BE7A-1CD847A56BB7@apple.com> <638AEE81-EA82-4289-A46C-5EA56D869F3D@geeklair.net> <5DC9FC1B-1BA0-49A0-B5DE-912BF5FFF0F7@apple.com> <2F17D59A-E3B5-4842-A310-44E8A451A385@geeklair.net> Message-ID: <29B685F5-D859-476B-8F3B-A5AE44828FFB@apple.com> On Mar 11, 2009, at 9:11 PM, Daniel J. Luke wrote: > If the only benefit is keeping older applications running even when > newer libs change the ABI or API and the older application can't be > updated to use the new lib, then I don't see how the extra > complication of having every version around and available for > linking is the best solution. Don't just think "older applications running", think "older ports". In the scheme I'm talking about, you can maintain many different conflicting versions of things in the same ports collection, meaning that even "old" ports can be built and installed at any time. What you propose is something aimed more at simple backwards compatibility for users who have been following MacPorts for awhile, where I'm suggesting that even new users might use old ports, in which case they need the headers and other bits which comprise the "old" version of X. The issue of getting rooted because you have old, unpatched bits on the system exists in almost all the compatibility scenarios, so it's a somewhat orthogonal issue. - Jordan From jeremy at lavergne.gotdns.org Thu Mar 12 05:40:54 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 08:40:54 -0400 Subject: milestone 1.7.1 Message-ID: <35016D3E-8DC3-462F-95DE-1AA1F26F6005@lavergne.gotdns.org> Any idea when milestone 1.7.1 will be complete? It seems that all tickets but one are closed, and the last real activity on it is on the order of months. -------------- 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 Thu Mar 12 06:40:25 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 13 Mar 2009 00:40:25 +1100 Subject: milestone 1.7.1 In-Reply-To: <35016D3E-8DC3-462F-95DE-1AA1F26F6005@lavergne.gotdns.org> References: <35016D3E-8DC3-462F-95DE-1AA1F26F6005@lavergne.gotdns.org> Message-ID: <49B910C9.9090802@macports.org> Jeremy Lavergne wrote: > Any idea when milestone 1.7.1 will be complete? RSN. :-) > It seems that all tickets but one are closed, and the last real activity > on it is on the order of months. Yes. Now is a great time to test the release_1_7 branch and report any regressions from 1.7.0. If nobody moves on the direct mode issues soon, we'll punt on it for 1.7.1. - Josh From raimue at macports.org Thu Mar 12 06:49:28 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 12 Mar 2009 14:49:28 +0100 Subject: milestone 1.7.1 In-Reply-To: <49B910C9.9090802@macports.org> References: <35016D3E-8DC3-462F-95DE-1AA1F26F6005@lavergne.gotdns.org> <49B910C9.9090802@macports.org> Message-ID: <49B912E8.20308@macports.org> Joshua Root wrote: > Jeremy Lavergne wrote: >> Any idea when milestone 1.7.1 will be complete? > > RSN. :-) I have one last idea for which I will send out another mail after this. >> It seems that all tickets but one are closed, and the last real activity >> on it is on the order of months. > > Yes. Now is a great time to test the release_1_7 branch and report any > regressions from 1.7.0. If nobody moves on the direct mode issues soon, > we'll punt on it for 1.7.1. Do we need a release candidate or are we going to release it right away? I think the only major changes have been to the upgrade proc. Changes: http://trac.macports.org/changeset?old_path=%2Ftags%2Frelease_1_7_0&old=HEAD&new_path=%2Fbranches%2Frelease_1_7&new=HEAD#file17 Rainer From raimue at macports.org Thu Mar 12 07:05:33 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 12 Mar 2009 15:05:33 +0100 Subject: Deprecating port list Message-ID: <49B916AD.7020203@macports.org> Hi, The 'port list' command has led to much confusion in the past. For most people it does not do what they expect, as it is listing the latest version of available ports. For example, 'port list installed' will not list the installed versions, but the versions available. It can also happen that it lists the same port multiple times with the same version information, confusing users even more. My proposal is to remove 'port list' in favor of other commands which are already in port. Users should use 'port search', 'port installed' or 'port echo' instead. * Deprecate 'port list' in 1.7.x by printing a warning message * Remove 'port list' in 1.8.0 It would be possible to rename it to 'port latest', but I am not sure if this command would be useful. Comments? Rainer From jeremy at lavergne.gotdns.org Thu Mar 12 07:13:48 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 10:13:48 -0400 Subject: Deprecating port list In-Reply-To: <49B916AD.7020203@macports.org> References: <49B916AD.7020203@macports.org> Message-ID: > The 'port list' command has led to much confusion in the past. > > For most people it does not do what they expect, as it is listing the > latest version of available ports. For example, 'port list installed' > will not list the installed versions, but the versions available. It > can > also happen that it lists the same port multiple times with the same > version information, confusing users even more. > > My proposal is to remove 'port list' in favor of other commands which > are already in port. Users should use 'port search', 'port > installed' or > 'port echo' instead. > > * Deprecate 'port list' in 1.7.x by printing a warning message > * Remove 'port list' in 1.8.0 > > It would be possible to rename it to 'port latest', but I am not > sure if > this command would be useful. > > Comments? I should like to think that we should mimic other port systems --- what methods do they commonly have available? I happen to be familiar with yum: install, update, check-update, remove, list, info , provides, whatprovides, clean, makecache, search, shell, resolvedep, deplist, repolist, help Should we pick one system and go with it (or did we and I missed that memo)? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Thu Mar 12 07:29:06 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 10:29:06 -0400 Subject: Google Summer of Code 2009: Mentors needed! In-Reply-To: <49B91B85.8080401@macports.org> References: <49B52CF9.7060905@macports.org> <863D4CAD-034D-43AD-96AA-41EE3BCAC655@lavergne.gotdns.org> <49B91B85.8080401@macports.org> Message-ID: > You are relatively new to the MacPorts community, did you ever look at > the base code? > > I am not against you taking part as a mentor, I am just concerned if > you > know enough about MacPorts' base to help a student for a project. > But we > can try to sort that out later, it is also possible to do co-mentoring > in my opinion. You could also be helpful in the evaluation process of > students' applications. > > Thanks for your offer! I've looked at some of the patches going into 1.7.1 and already applied them directly to my bin/port. As for actually delving into the code, not so much yet. I'm just looking to help out since there weren't many mentors on the list yet: Co-mentoring and/or evaluating sounds like it would be a good way to go. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From raimue at macports.org Thu Mar 12 07:57:06 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 12 Mar 2009 15:57:06 +0100 Subject: Deprecating port list In-Reply-To: References: <49B916AD.7020203@macports.org> Message-ID: <49B922C2.8090509@macports.org> Jeremy Lavergne wrote: > I should like to think that we should mimic other port systems --- > what methods do they commonly have available? But what should 'port list' do in your opinion? We can try to fix the existing command. But in its current form, it causes too much confusion. > I happen to be familiar with yum: install, update, check-update, > remove, list, info , provides, whatprovides, clean, makecache, search, > shell, resolvedep, deplist, repolist, help > > Should we pick one system and go with it (or did we and I missed that > memo)? I don't see a reason to tie ourself to a specific other system. We are getting new users coming from all different platforms. Would you expect MacPorts to have Super Cow Powers? ;-) Rainer From jeremy at lavergne.gotdns.org Thu Mar 12 08:18:04 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 11:18:04 -0400 Subject: Deprecating port list In-Reply-To: <49B922C2.8090509@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> Message-ID: >> I should like to think that we should mimic other port systems --- >> what methods do they commonly have available? > > But what should 'port list' do in your opinion? We can try to fix the > existing command. But in its current form, it causes too much > confusion. For "port list" specifically, I would expect a listing of package names and package versions with an indication that it's out of date --- much like port outdated. I suggest we then throw in an additional third column indicating the status of that specific version. Here's an example: xorg-xproto 7.0.14_1 < 7.0.15_0 (active) xorg-xproto 7.0.14_0 < 7.0.15_0 (inactive) You'll note that I demonstrate what I feel should happen if there's more than one port installed. As for what's confusing, I feel we have too many commands available that overlap on naming. I think it would be a good idea to either consolidate or rename these functions. Since I'm talking about mimicking other port systems (for better or worse) I would expect "list" to provide the basic listings we provide from other functions as submethods: list all list available list updates list installed list extras list obsoletes list recent I would expect the searching ability to included on all these (e.g., list updates foo*). Feel free to throw more ideas onto this or pull some out; by no means should I be the only person driving MacPorts! >> I happen to be familiar with yum: install, update, check-update, >> remove, list, info , provides, whatprovides, clean, makecache, >> search, >> shell, resolvedep, deplist, repolist, help >> >> Should we pick one system and go with it (or did we and I missed that >> memo)? > > I don't see a reason to tie ourself to a specific other system. We are > getting new users coming from all different platforms. > > Would you expect MacPorts to have Super Cow Powers? ;-) sudo apt-get moo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From raimue at macports.org Thu Mar 12 09:38:06 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 12 Mar 2009 17:38:06 +0100 Subject: Deprecating port list In-Reply-To: References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> Message-ID: <49B93A6E.7060304@macports.org> Jeremy Lavergne wrote: > For "port list" specifically, I would expect a listing of package > names and package versions with an indication that it's out of date > --- much like port outdated. I suggest we then throw in an additional > third column indicating the status of that specific version. Here's > an example: So you only want to see installed packages, right? > xorg-xproto 7.0.14_1 < 7.0.15_0 (active) > xorg-xproto 7.0.14_0 < 7.0.15_0 (inactive) This is basically 'port outdated'. What would be the use of this if it is so similar? The duplicated ports and active/inactive status could be shown with an additional flag for 'port outdated' if you think this is useful. 'port installed' already lists active/inactive status. > [...] > As for what's confusing, I feel we have too many commands available > that overlap on naming. No commands overlap on naming. You have to differentiate between commands and pseudo-ports, which are much more powerful. Some commands have the same name as a pseudo-port, which is probably what you mean. But I don't think we can do anything against this. > [...] I think it would be a good idea to either > consolidate or rename these functions. Since I'm talking about > mimicking other port systems (for better or worse) I would expect > "list" to provide the basic listings we provide from other functions > as submethods: > list all > list available > list updates > list installed > list extras > list obsoletes > list recent list all is the same as list available, pseudo-port 'all' exists for all commands already. list updates sounds like our existing outdated command. list installed is covered by the installed command and the pseudo-port 'installed'. list obsoletes was added to trunk by me as a pseudo-port, 'obsolete' list extras and list recent, I have no idea what is meant by those. If this is all under the list command, I would expect the same consistent output for all of them. But for installed I would like to see the version which is installed, for outdated I would like to see the new and old version. I don't like sub-commands of commands. 'port [--options] [args]' is enough already. > I would expect the searching ability to included on all these (e.g., > list updates foo*). This is already possible for existing commands which accept lists of ports. Additionally, the use of pseudo-ports is possible, which can also be combined using logical operators. These allows to make complicated queries which is unique to MacPorts as far as I know. As we have such a feature I also don't think we can simply adopt commands from other systems, these just wouldn't fit. Note that the command echo exists to test such expansions: port echo depends:expat and 'a*' Gives you a list of all ports that depend on expat and start with the character 'a'. If you are concerned that new users who are already familiar with different packagement systems have a hard time to get used to 'port', we could create a wiki section which lists equivalent commands for other systems. Rainer From lists-macports at shopwatch.org Thu Mar 12 09:53:39 2009 From: lists-macports at shopwatch.org (Jay Levitt) Date: Thu, 12 Mar 2009 12:53:39 -0400 Subject: Deprecating port list In-Reply-To: <49B93A6E.7060304@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> Message-ID: <49B93E13.4020904@shopwatch.org> Rainer M?ller wrote: > This is basically 'port outdated'. What would be the use of this if it > is so similar? I think "port list" could/should be an alias for "port outdated". I'm not usually a fan of synonyms, but "list" is a basic function, provided by yum, gem, and quite probably others. Sure, you can document it in the wiki, but why force users to look something up and type a different command when you already know what they mean? Is there a use case where someone would be displeased by the output of "port outdated" when they do a "port list", and where they'd be more pleased to see "Please see the documentation" or "No such command?" Jay Levitt From stechert at macports.org Thu Mar 12 10:10:13 2009 From: stechert at macports.org (Andre Stechert) Date: Thu, 12 Mar 2009 10:10:13 -0700 Subject: Deprecating port list In-Reply-To: <49B93E13.4020904@shopwatch.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B93E13.4020904@shopwatch.org> Message-ID: <12a697af0903121010v7f94e51ek2f49a836ba90115@mail.gmail.com> I use port list but only in the following ways: port list | wc -l answers the question "how many ports does macports have nowadays? we catching up to freebsd yet?" port list | grep ... answers the question "is /re/ a port?" without requiring me to understand port search's syntax and/or limitations compared to regular old grep. port list | awk ... allows me to perform arbitrary shell operations against the entire set of possible ports for cleanup, statistics, or whatever. The second usage should probably be replaced with port search (provided that the operators are of equivalent expressive power), but I'm not sure how I'd do the others without port list. What would you suggest? Thanks, Andre On Thu, Mar 12, 2009 at 9:53 AM, Jay Levitt wrote: > Rainer M?ller wrote: >> This is basically 'port outdated'. What would be the use of this if it >> is so similar? > > I think "port list" could/should be an alias for "port outdated". ?I'm not > usually a fan of synonyms, but "list" is a basic function, provided by yum, > gem, and quite probably others. ?Sure, you can document it in the wiki, but > why force users to look something up and type a different command when you > already know what they mean? > > Is there a use case where someone would be displeased by the output of "port > outdated" when they do a "port list", and where they'd be more pleased to > see "Please see the documentation" or "No such command?" > > Jay Levitt > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From raimue at macports.org Thu Mar 12 10:24:55 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Thu, 12 Mar 2009 18:24:55 +0100 Subject: Deprecating port list In-Reply-To: <12a697af0903121010v7f94e51ek2f49a836ba90115@mail.gmail.com> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B93E13.4020904@shopwatch.org> <12a697af0903121010v7f94e51ek2f49a836ba90115@mail.gmail.com> Message-ID: <49B94567.4070401@macports.org> Andre Stechert wrote: > port list | wc -l > answers the question "how many ports does macports have nowadays? > we catching up to freebsd yet?" port echo all | wc -l port search '*' | tail -1 > port list | grep ... > answers the question "is /re/ a port?" without requiring me to > understand port search's syntax and/or limitations compared to regular > old grep. > > port list | awk ... > allows me to perform arbitrary shell operations against the entire > set of possible ports for cleanup, statistics, or whatever. port echo all | grep ... port echo all | awk ... Maybe it would be useful to make list an alias to echo? A command like port info --line --name --version ... all allows even more by selecting the field you want to view. Rainer From jeremy at lavergne.gotdns.org Thu Mar 12 10:30:06 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 13:30:06 -0400 Subject: Deprecating port list In-Reply-To: <49B93A6E.7060304@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> Message-ID: <80EF3C93-0D19-4E7A-A696-31561B5015B8@lavergne.gotdns.org> >> For "port list" specifically, I would expect a listing of package >> names and package versions with an indication that it's out of date >> --- much like port outdated. I suggest we then throw in an >> additional >> third column indicating the status of that specific version. Here's >> an example: > > So you only want to see installed packages, right? If it's only port list then I want all ports -- listing all installed ones and uninstalled ones. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Thu Mar 12 10:31:30 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 13:31:30 -0400 Subject: Deprecating port list In-Reply-To: <49B93A6E.7060304@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> Message-ID: >> As for what's confusing, I feel we have too many commands available >> that overlap on naming. > > No commands overlap on naming. You have to differentiate between > commands and pseudo-ports, which are much more powerful. > > Some commands have the same name as a pseudo-port, which is probably > what you mean. But I don't think we can do anything against this. From a user standpoint, there is no real difference between them: One combination that means the same thing does it totally differently. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From stechert at macports.org Thu Mar 12 10:36:15 2009 From: stechert at macports.org (Andre Stechert) Date: Thu, 12 Mar 2009 10:36:15 -0700 Subject: Deprecating port list In-Reply-To: <49B94567.4070401@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B93E13.4020904@shopwatch.org> <12a697af0903121010v7f94e51ek2f49a836ba90115@mail.gmail.com> <49B94567.4070401@macports.org> Message-ID: <12a697af0903121036t5bde1f39k5d725f4aaa5012b4@mail.gmail.com> ***a student becomes enlightened*** I previously thought "port echo" was just a loopback/diagnostic because if I do "port echo asdfjk" I get "asdfjk". Thanks! Andre On Thu, Mar 12, 2009 at 10:24 AM, Rainer M?ller wrote: > Andre Stechert wrote: >> port list | wc -l >> ? ? answers the question "how many ports does macports have nowadays? >> we catching up to freebsd yet?" > > port echo all | wc -l > port search '*' | tail -1 > >> port list | grep ... >> ? ? answers the question "is /re/ a port?" without requiring me to >> understand port search's syntax and/or limitations compared to regular >> old grep. >> >> port list | awk ... >> ? ? allows me to perform arbitrary shell operations against the entire >> set of possible ports for cleanup, statistics, or whatever. > > port echo all | grep ... > port echo all | awk ... > > Maybe it would be useful to make list an alias to echo? > > A command like > ?port info --line --name --version ... all > allows even more by selecting the field you want to view. > > Rainer > From jeremy at lavergne.gotdns.org Thu Mar 12 10:39:57 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 13:39:57 -0400 Subject: Deprecating port list In-Reply-To: <49B93A6E.7060304@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> Message-ID: > I would expect the searching ability to included on all these (e.g., > list updates foo*). > > This is already possible for existing commands which accept lists of > ports. Additionally, the use of pseudo-ports is possible, which can > also > be combined using logical operators. These allows to make complicated > queries which is unique to MacPorts as far as I know. As we have > such a > feature I also don't think we can simply adopt commands from other > systems, these just wouldn't fit. > > Note that the command echo exists to test such expansions: > port echo depends:expat and 'a*' > Gives you a list of all ports that depend on expat and start with the > character 'a'. I'm confused why the user has to come up with all these queries rather than just doing: port list depends:expat a* It just seems that in order to use these "special features" a lot more work is done by the user each time rather than devoting that energy to having MacPorts do stuff. Granted you can write a program to know what your user is doing. > list extras and list recent, I have no idea what is meant by those. Extras is just a repository for things outside the main repo. Recent are basically "added in X days" or since you ran it last --- software you might to try out or know about. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Thu Mar 12 10:41:10 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 13:41:10 -0400 Subject: Deprecating port list In-Reply-To: <49B93A6E.7060304@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> Message-ID: > If you are concerned that new users who are already familiar with > different packagement systems have a hard time to get used to > 'port', we > could create a wiki section which lists equivalent commands for other > systems. I like this idea. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From alakazam at macports.org Thu Mar 12 10:43:21 2009 From: alakazam at macports.org (Olivier Le Floch) Date: Thu, 12 Mar 2009 18:43:21 +0100 Subject: Deprecating port list In-Reply-To: References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> Message-ID: On 12 mars 09, at 18:41, Jeremy Lavergne wrote: >> If you are concerned that new users who are already familiar with >> different packagement systems have a hard time to get used to >> 'port', we >> could create a wiki section which lists equivalent commands for other >> systems. > > I like this idea. I like it too ! I can help out with the Debian/Apt/DPKG section. From raimue at macports.org Thu Mar 12 11:06:31 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 12 Mar 2009 19:06:31 +0100 Subject: Deprecating port list In-Reply-To: References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> Message-ID: <49B94F27.3070700@macports.org> Jeremy Lavergne wrote: >> Note that the command echo exists to test such expansions: >> port echo depends:expat and 'a*' >> Gives you a list of all ports that depend on expat and start with the >> character 'a'. > > I'm confused why the user has to come up with all these queries rather > than just doing: > port list depends:expat a* The default logical operator is "or". Your example is equivalent to: port list depends:expat or 'a*' If it would default to "and", you would be unable to do things like: port info vim expat bzip2 Okay, these simple examples above are handled a bit different internally, but I hope you get the point. More complicated: port echo inactive and \(vim expat bzip2\) which is the simplified form of: port echo inactive and \(vim or expat or bzip2\) Note: Use quotes as the shell will also expand wildcards. > It just seems that in order to use these "special features" a lot more > work is done by the user each time rather than devoting that energy to > having MacPorts do stuff. Granted you can write a program to know > what your user is doing. I don't see where the user has to do more work? >> list extras and list recent, I have no idea what is meant by those. > > Extras is just a repository for things outside the main repo. Recent > are basically "added in X days" or since you ran it last --- software > you might to try out or know about. MacPorts treats all sources added in sources.conf the same, with the [default] tag being the exception. There is lot of room for improvements in this area. For 'recent', the PortIndex does not contain timestamps when a port was added/modified. I don't think it should as there is no reliable source to get that information (examining commit log? filesystem mtime?). Rainer From jmr at macports.org Thu Mar 12 11:10:03 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 13 Mar 2009 05:10:03 +1100 Subject: Deprecating port list In-Reply-To: <49B93E13.4020904@shopwatch.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B93E13.4020904@shopwatch.org> Message-ID: <49B94FFB.5000600@macports.org> Jay Levitt wrote: > Rainer M?ller wrote: >> This is basically 'port outdated'. What would be the use of this if it >> is so similar? > > I think "port list" could/should be an alias for "port outdated". I'm not > usually a fan of synonyms, but "list" is a basic function, provided by yum, > gem, and quite probably others. Sure, you can document it in the wiki, but > why force users to look something up and type a different command when you > already know what they mean? > > Is there a use case where someone would be displeased by the output of "port > outdated" when they do a "port list", and where they'd be more pleased to > see "Please see the documentation" or "No such command?" `port list installed`,`port list all`, `port list `. Having commands just because users might try them doesn't seem like a good policy to me. As for the "we know what they meant" argument, it would seem that we don't, judging by the differences in what we think the command should do. I'm happy for list to be removed. If it stays, its output needs to be changed so it's clear what it is showing, and so 'list installed' does something sensible. One possibility would be to have two labelled columns, one for the available version and one for the installed versions of each port. - Josh From jeremy at lavergne.gotdns.org Thu Mar 12 11:12:17 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 14:12:17 -0400 Subject: Deprecating port list In-Reply-To: <49B94F27.3070700@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B94F27.3070700@macports.org> Message-ID: >>> Note that the command echo exists to test such expansions: >>> port echo depends:expat and 'a*' >>> Gives you a list of all ports that depend on expat and start with >>> the >>> character 'a'. >> >> I'm confused why the user has to come up with all these queries >> rather >> than just doing: >> port list depends:expat a* > > The default logical operator is "or". Your example is equivalent to: > port list depends:expat or 'a*' > > If it would default to "and", you would be unable to do things like: > port info vim expat bzip2 > > Okay, these simple examples above are handled a bit different > internally, but I hope you get the point. > > More complicated: > port echo inactive and \(vim expat bzip2\) > which is the simplified form of: > port echo inactive and \(vim or expat or bzip2\) > > Note: Use quotes as the shell will also expand wildcards. > >> It just seems that in order to use these "special features" a lot >> more >> work is done by the user each time rather than devoting that energy >> to >> having MacPorts do stuff. Granted you can write a program to know >> what your user is doing. > > I don't see where the user has to do more work? I wouldn't expect any logic operations to actually take place in the examples above. I'd expect it to do the command on each one independently. When it comes across depends:expat (or something else that's a "reserved" name, I would expect it to function according to what the command is, and apply it to the following ports. > port list depends:expat a* For this, I would expect list to show me what ports starting with a depend on expat. How it goes about it presently is different than i would expect. > port info vim expat bzip2 I would expect port info to be run against vim, then expat, then bzip2. It's just a matter of how I feel port list works. I clearly misunderstood how it was going about its business. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Thu Mar 12 11:14:43 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 14:14:43 -0400 Subject: Deprecating port list In-Reply-To: <49B94FFB.5000600@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B93E13.4020904@shopwatch.org> <49B94FFB.5000600@macports.org> Message-ID: > I'm happy for list to be removed. If it stays, its output needs to be > changed so it's clear what it is showing, and so 'list installed' does > something sensible. One possibility would be to have two labelled > columns, one for the available version and one for the installed > versions of each port. I don't think there's a problem with combining the functionality of port outdated into port installed: It still shows you what ones you have installed and provides you with a heads up that it's out of date. To me, it's like a subset versus a proper subset. -------------- 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 Thu Mar 12 11:29:24 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 12 Mar 2009 11:29:24 -0700 Subject: ui_msg Message-ID: Is there anyone else who thinks it would be nice to collect ui_msg and display the messages at the very end of the port run? Or make it an option? Or is there a way to do this already? Maybe even write them to a ui_message log along with a time stamp and the original port command. So if you install something that has a bunch of dependencies, and especially if you use the -v or -d flags you can read all the messages at the end. Removing and rebuilding things to test perl5.8 as an example: port -f uninstall installed port -k install mysql5-devel @5.1.30_1+partition+server apache2 php5 @5.2.8_1+apache2+imap+macosx+mysql5+pear+pspell+readline+sqlite+tidy perl5.8 @5.8.9_2+db+gdbm+shared+threads php5 @5.2.8_1+apache2+imap +macosx+mysql5+pear+pspell+readline+sqlite+tidyport -vk install mysql5- devel @5.1.30_1+partition+server apache2 php5 @5.2.8_1+apache2+imap +macosx+mysql5+pear+pspell+readline+sqlite+tidy perl5.8 @5.8.9_2+db +gdbm+shared+threads php5 @5.2.8_1+apache2+imap+macosx+mysql5+pear +pspell+readline+sqlite+tidy ---> normal output without us_msg ............ and at the end of the port run --->. Message from port mysql5-devel ****************************************************** * In order to setup the database, you might want to run * sudo -u mysql mysql_install_db5 * if this is a new install ****************************************************** ---> Message from port foo ****************************************************** * foo suggests you do something ****************************************************** //Brad From usx303 at googlemail.com Thu Mar 12 11:37:52 2009 From: usx303 at googlemail.com (Uwe Schwartz) Date: Thu, 12 Mar 2009 19:37:52 +0100 Subject: [47962] trunk/dports/net In-Reply-To: <997D5139-A222-4C4F-B7AB-2A1BEBEF59A3@macports.org> References: <20090311184806.370EC11A3F5A@beta.macosforge.org> <997D5139-A222-4C4F-B7AB-2A1BEBEF59A3@macports.org> Message-ID: <49B95680.7040203@googlemail.com> I changed the Portfile according to your suggestions. The patch is submitted in ticket 18809: http://trac.macports.org/ticket/18809 Ryan Schmidt wrote: > On Mar 11, 2009, at 13:48, snc at macports.org wrote: > >> Revision: 47962 >> http://trac.macports.org/changeset/47962 >> Author: snc at macports.org >> Date: 2009-03-11 11:48:05 -0700 (Wed, 11 Mar 2009) >> Log Message: >> ----------- >> created argus-clients, ticket #18792 > > [snip] > >> +default_variants +graph >> + >> +variant graph description {Build ragraph (depends on rrdtool)} { >> + depends_lib-append port:rrdtool >> +} > > Why make it a variant and then make it the default? This makes it hard > for anyone to deselect the variant since MacPorts does not record > negative variants in the registry. If you want the feature enabled by > default but want a way for people to disable it, code the portfile to > enable the feature, and then have a "no_graph" variant to remove it. > From jeremy at lavergne.gotdns.org Thu Mar 12 11:41:49 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 14:41:49 -0400 Subject: [47962] trunk/dports/net In-Reply-To: <49B95680.7040203@googlemail.com> References: <20090311184806.370EC11A3F5A@beta.macosforge.org> <997D5139-A222-4C4F-B7AB-2A1BEBEF59A3@macports.org> <49B95680.7040203@googlemail.com> Message-ID: > I changed the Portfile according to your suggestions. > The patch is submitted in ticket 18809: > > http://trac.macports.org/ticket/18809 The revision on this one should NOT be updated, right? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From usx303 at googlemail.com Thu Mar 12 11:50:26 2009 From: usx303 at googlemail.com (Uwe Schwartz) Date: Thu, 12 Mar 2009 19:50:26 +0100 Subject: [47962] trunk/dports/net In-Reply-To: References: <20090311184806.370EC11A3F5A@beta.macosforge.org> <997D5139-A222-4C4F-B7AB-2A1BEBEF59A3@macports.org> <49B95680.7040203@googlemail.com> Message-ID: <49B95972.6000005@googlemail.com> Jeremy Lavergne wrote: >> I changed the Portfile according to your suggestions. >> The patch is submitted in ticket 18809: >> >> http://trac.macports.org/ticket/18809 > > > The revision on this one should NOT be updated, right? > Well, I am not sure. There are changes in the Portfile so I increased the revision to 1. But for users it's not really necessary to update. From jeremy at lavergne.gotdns.org Thu Mar 12 11:51:14 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 14:51:14 -0400 Subject: [47962] trunk/dports/net In-Reply-To: <49B95972.6000005@googlemail.com> References: <20090311184806.370EC11A3F5A@beta.macosforge.org> <997D5139-A222-4C4F-B7AB-2A1BEBEF59A3@macports.org> <49B95680.7040203@googlemail.com> <49B95972.6000005@googlemail.com> Message-ID: >>> I changed the Portfile according to your suggestions. >>> The patch is submitted in ticket 18809: >>> >>> http://trac.macports.org/ticket/18809 >> >> >> The revision on this one should NOT be updated, right? >> > > Well, I am not sure. There are changes in the Portfile so I increased > the revision to 1. But for users it's not really necessary to update. The rule of thumb that I've heard is that if it doesn't modify the files being generated then it ought not be increased. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From raimue at macports.org Thu Mar 12 11:53:48 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Thu, 12 Mar 2009 19:53:48 +0100 Subject: Deprecating port list In-Reply-To: <12a697af0903121036t5bde1f39k5d725f4aaa5012b4@mail.gmail.com> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B93E13.4020904@shopwatch.org> <12a697af0903121010v7f94e51ek2f49a836ba90115@mail.gmail.com> <49B94567.4070401@macports.org> <12a697af0903121036t5bde1f39k5d725f4aaa5012b4@mail.gmail.com> Message-ID: <49B95A3C.5090105@macports.org> Andre Stechert wrote: > ***a student becomes enlightened*** > > I previously thought "port echo" was just a loopback/diagnostic > because if I do "port echo asdfjk" I get "asdfjk". True. 'port echo' simply expands the list you give to the command. If you would run port install asdfjk it would search for a port "asdfjk". This is also what port echo asdfjk tells you. But if you are going to run port install '*abc*' you don't know to which ports this would expand. port echo '*abc*' gives you the expanded list. So it is really some kind of diagnostic tool. Should 'port echo' also verify the expanded list? Rainer From jeremy at lavergne.gotdns.org Thu Mar 12 11:55:35 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 14:55:35 -0400 Subject: Deprecating port list In-Reply-To: <49B95A3C.5090105@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B93E13.4020904@shopwatch.org> <12a697af0903121010v7f94e51ek2f49a836ba90115@mail.gmail.com> <49B94567.4070401@macports.org> <12a697af0903121036t5bde1f39k5d725f4aaa5012b4@mail.gmail.com> <49B95A3C.5090105@macports.org> Message-ID: <51B4992C-BA9C-4E70-9D52-62A53000FCF9@lavergne.gotdns.org> > But if you are going to run > port install '*abc*' > you don't know to which ports this would expand. > port echo '*abc*' > gives you the expanded list. > > So it is really some kind of diagnostic tool. Should 'port echo' also > verify the expanded list? That sounds like functionality I would expect from "port search" but I worry that there are some advanced uses that I'm not considering. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From usx303 at googlemail.com Thu Mar 12 11:58:19 2009 From: usx303 at googlemail.com (Uwe Schwartz) Date: Thu, 12 Mar 2009 19:58:19 +0100 Subject: [47962] trunk/dports/net In-Reply-To: References: <20090311184806.370EC11A3F5A@beta.macosforge.org> <997D5139-A222-4C4F-B7AB-2A1BEBEF59A3@macports.org> <49B95680.7040203@googlemail.com> <49B95972.6000005@googlemail.com> Message-ID: <49B95B4B.3010208@googlemail.com> Jeremy Lavergne wrote: >>>> I changed the Portfile according to your suggestions. >>>> The patch is submitted in ticket 18809: >>>> >>>> http://trac.macports.org/ticket/18809 >>> >>> >>> The revision on this one should NOT be updated, right? >>> >> >> Well, I am not sure. There are changes in the Portfile so I increased >> the revision to 1. But for users it's not really necessary to update. > > The rule of thumb that I've heard is that if it doesn't modify the files > being generated then it ought not be increased. > Okay, there are no file changes. So revision change is not necessary. From raimue at macports.org Thu Mar 12 12:08:53 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 12 Mar 2009 20:08:53 +0100 Subject: Deprecating port list In-Reply-To: References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B94F27.3070700@macports.org> Message-ID: <49B95DC5.6000705@macports.org> Jeremy Lavergne wrote: > I wouldn't expect any logic operations to actually take place in the > examples above. I'd expect it to do the command on each one > independently. When it comes across depends:expat (or something else > that's a "reserved" name, I would expect it to function according to > what the command is, and apply it to the following ports. No, you completely misunderstand pseudo-ports. This is not meant as a modifier for following ports (how would you unset the modifier?), but as a selector. A pseudo-port like depends:expat is replaced by a set of ports. In this case, all ports depending on expat will be listed there. You combine sets of ports using logical operators "and", "or", "not", "!", "(" and ")". If you are interested in all the python modules being unmaintained you could do a query like: port echo maintainer:nomaintainer and \( py-* py25-* py26-* \) And it is even possible to find all python modules with either no maintainer or having openmaintainer set: port echo \( maintainer:nomaintainer maintainer:openmaintainer \) \ and \( py-* py25-* py26-* \) You can't do such things with simple modifiers you proposed and they work for any port command accepting a list of ports, that is such a port expression. This is very powerful, but you don't have to use it. It is still easy and intuitive to give a simple list of port names to a port command. Rainer From illogical1 at gmail.com Thu Mar 12 12:10:04 2009 From: illogical1 at gmail.com (Orville Bennett) Date: Thu, 12 Mar 2009 15:10:04 -0400 Subject: ui_msg In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 12, 2009, at 2:29 PM, Bradley Giesbrecht wrote: > Is there anyone else who thinks it would be nice to collect ui_msg > and display the messages at the very end of the port run? Awesome Idea. Maybe even summer of code material if it's complicated enough. > > Or make it an option? Or is there a way to do this already? > > Maybe even write them to a ui_message log along with a time stamp > and the original port command. > > So if you install something that has a bunch of dependencies, and > especially if you use the -v or -d flags you can read all the > messages at the end. > > Removing and rebuilding things to test perl5.8 as an example: > port -f uninstall installed > port -k install mysql5-devel @5.1.30_1+partition+server apache2 php5 > @5.2.8_1+apache2+imap+macosx+mysql5+pear+pspell+readline+sqlite+tidy > perl5.8 @5.8.9_2+db+gdbm+shared+threads php5 @5.2.8_1+apache2+imap > +macosx+mysql5+pear+pspell+readline+sqlite+tidyport -vk install > mysql5-devel @5.1.30_1+partition+server apache2 php5 > @5.2.8_1+apache2+imap+macosx+mysql5+pear+pspell+readline+sqlite+tidy > perl5.8 @5.8.9_2+db+gdbm+shared+threads php5 @5.2.8_1+apache2+imap > +macosx+mysql5+pear+pspell+readline+sqlite+tidy > ---> normal output without us_msg ............ > > and at the end of the port run > > --->. Message from port mysql5-devel > ****************************************************** > * In order to setup the database, you might want to run > * sudo -u mysql mysql_install_db5 > * if this is a new install > ****************************************************** > ---> Message from port foo > ****************************************************** > * foo suggests you do something > ****************************************************** > > //Brad > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkm5XgwACgkQ2yWVgjgEOKSBwQCfcjVVLNrL2PWuXYt7H5e4Kc2l OjEAn0VWiutQnif7PByN71IhxBkle5Ft =KZyL -----END PGP SIGNATURE----- From raimue at macports.org Thu Mar 12 12:15:46 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 12 Mar 2009 20:15:46 +0100 Subject: Deprecating port list In-Reply-To: <51B4992C-BA9C-4E70-9D52-62A53000FCF9@lavergne.gotdns.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B93E13.4020904@shopwatch.org> <12a697af0903121010v7f94e51ek2f49a836ba90115@mail.gmail.com> <49B94567.4070401@macports.org> <12a697af0903121036t5bde1f39k5d725f4aaa5012b4@mail.gmail.com> <49B95A3C.5090105@macports.org> <51B4992C-BA9C-4E70-9D52-62A53000FCF9@lavergne.gotdns.org> Message-ID: <49B95F62.2040708@macports.org> Jeremy Lavergne wrote: > That sounds like functionality I would expect from "port search" but I > worry that there are some advanced uses that I'm not considering. So you would like to do 'port search' and then copy the results by hand to another port command? For more pseudo-port usage, I am running port -v livecheck maintainer:raimue on a regular basis to check for updates to any ports I maintain. Rainer From jeremy at lavergne.gotdns.org Thu Mar 12 12:24:25 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 12 Mar 2009 15:24:25 -0400 Subject: Deprecating port list In-Reply-To: <49B95F62.2040708@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B93E13.4020904@shopwatch.org> <12a697af0903121010v7f94e51ek2f49a836ba90115@mail.gmail.com> <49B94567.4070401@macports.org> <12a697af0903121036t5bde1f39k5d725f4aaa5012b4@mail.gmail.com> <49B95A3C.5090105@macports.org> <51B4992C-BA9C-4E70-9D52-62A53000FCF9@lavergne.gotdns.org> <49B95F62.2040708@macports.org> Message-ID: <712D3B57-59D3-4658-9BFD-94E42FB2F7DC@lavergne.gotdns.org> > So you would like to do 'port search' and then copy the results by > hand > to another port command? > > For more pseudo-port usage, I am running > port -v livecheck maintainer:raimue > on a regular basis to check for updates to any ports I maintain. I wouldn't necessarily say it was by hand, but I've been doing things the embarrassing way (not precise as I'm winging this right now, but it gives you the idea how i've been abusing port): port destroot `port installed | grep -v following | awk '{print $1}' | sort -u | tr "\n" " +universal "` Later to be run with 'pkg' and finally into an 'mpkg pspp' (this was what I was doing prior to 1.7.0 to make a binary installer for PSPP as there were errors if you didn't walk ports through destroot, pkg, mpkg). I periodically find myself still using the other utilities, likely to come up with the pseudo-ports that I'm unfamiliar with. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From raimue at macports.org Thu Mar 12 12:43:45 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 12 Mar 2009 20:43:45 +0100 Subject: ui_msg In-Reply-To: References: Message-ID: <49B965F1.9020609@macports.org> Orville Bennett wrote: > > On Mar 12, 2009, at 2:29 PM, Bradley Giesbrecht wrote: > >> Is there anyone else who thinks it would be nice to collect ui_msg >> and display the messages at the very end of the port run? > > Awesome Idea. Maybe even summer of code material if it's complicated > enough. I think this would fit to the logging task, as it will have to touch ui_* stuff anyway. http://trac.macports.org/wiki/SummerOfCode#logging Rainer From brad at pixilla.com Thu Mar 12 14:28:39 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 12 Mar 2009 14:28:39 -0700 Subject: Deprecating port list In-Reply-To: <49B95F62.2040708@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B93E13.4020904@shopwatch.org> <12a697af0903121010v7f94e51ek2f49a836ba90115@mail.gmail.com> <49B94567.4070401@macports.org> <12a697af0903121036t5bde1f39k5d725f4aaa5012b4@mail.gmail.com> <49B95A3C.5090105@macports.org> <51B4992C-BA9C-4E70-9D52-62A53000FCF9@lavergne.gotdns.org> <49B95F62.2040708@macports.org> Message-ID: <6154E087-45B6-4936-AEAC-964C82F26503@pixilla.com> On Mar 12, 2009, at 12:15 PM, Rainer M?ller wrote: > Jeremy Lavergne wrote: >> That sounds like functionality I would expect from "port search" >> but I >> worry that there are some advanced uses that I'm not considering. > > So you would like to do 'port search' and then copy the results by > hand > to another port command? > > For more pseudo-port usage, I am running > port -v livecheck maintainer:raimue > on a regular basis to check for updates to any ports I maintain. pseudo-ports and echo are becoming my favorite features of port. It's only by reading this list that I begin to understand how to use them. The documentation didn't get me very far. So I thank all of you internal's people who post your port command usage to this list. It's a big help to me and probably others so I am encouraging you to keep it up :) //Brad From ryandesign at macports.org Thu Mar 12 14:38:18 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 12 Mar 2009 16:38:18 -0500 Subject: [47962] trunk/dports/net In-Reply-To: <49B95B4B.3010208@googlemail.com> References: <20090311184806.370EC11A3F5A@beta.macosforge.org> <997D5139-A222-4C4F-B7AB-2A1BEBEF59A3@macports.org> <49B95680.7040203@googlemail.com> <49B95972.6000005@googlemail.com> <49B95B4B.3010208@googlemail.com> Message-ID: On Mar 12, 2009, at 13:58, Uwe Schwartz wrote: > Jeremy Lavergne wrote: >>>>> I changed the Portfile according to your suggestions. >>>>> The patch is submitted in ticket 18809: >>>>> >>>>> http://trac.macports.org/ticket/18809 >>>> >>>> >>>> The revision on this one should NOT be updated, right? >>>> >>> >>> Well, I am not sure. There are changes in the Portfile so I >>> increased >>> the revision to 1. But for users it's not really necessary to >>> update. >> >> The rule of thumb that I've heard is that if it doesn't modify the >> files >> being generated then it ought not be increased. >> > > Okay, there are no file changes. So revision change is not necessary. I already committed it with the revision bump before reading these messages. There are valid reasons for increasing the revision even if the files installed do not change, for example if the dependencies change, or if the default variants change. The latter is why I didn't remove the revision increase, though in this case I don't particularly care one way or the other. From ryandesign at macports.org Thu Mar 12 14:41:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 12 Mar 2009 16:41:02 -0500 Subject: milestone 1.7.1 In-Reply-To: <49B912E8.20308@macports.org> References: <35016D3E-8DC3-462F-95DE-1AA1F26F6005@lavergne.gotdns.org> <49B910C9.9090802@macports.org> <49B912E8.20308@macports.org> Message-ID: On Mar 12, 2009, at 08:49, Rainer M?ller wrote: > Joshua Root wrote: >> Jeremy Lavergne wrote: >>> Any idea when milestone 1.7.1 will be complete? >> >> RSN. :-) > > I have one last idea for which I will send out another mail after > this. > >>> It seems that all tickets but one are closed, and the last real >>> activity >>> on it is on the order of months. >> >> Yes. Now is a great time to test the release_1_7 branch and report >> any >> regressions from 1.7.0. If nobody moves on the direct mode issues >> soon, >> we'll punt on it for 1.7.1. > > Do we need a release candidate or are we going to release it right > away? > I think the only major changes have been to the upgrade proc. > > Changes: > http://trac.macports.org/changeset?old_path=%2Ftags% > 2Frelease_1_7_0&old=HEAD&new_path=%2Fbranches% > 2Frelease_1_7&new=HEAD#file17 I don't think I'd bother with a release candidate. We should still merge back from trunk those handful of small changes that I mentioned in another thread some weeks ago. From florian.ebeling at gmail.com Thu Mar 12 14:46:55 2009 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Thu, 12 Mar 2009 22:46:55 +0100 Subject: Deprecating port list In-Reply-To: <49B95DC5.6000705@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> Message-ID: <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> On Thu, Mar 12, 2009 at 8:08 PM, Rainer M?ller wrote: > Jeremy Lavergne wrote: >> I wouldn't expect any logic operations to actually take place in the >> examples above. ?I'd expect it to do the command on each one >> independently. ?When it comes across depends:expat (or something else >> that's a "reserved" name, I would expect it to function according to >> what the command is, and apply it to the following ports. > > No, you completely misunderstand pseudo-ports. > > This is not meant as a modifier for following ports (how would you unset > the modifier?), but as a selector. A pseudo-port like depends:expat is > replaced by a set of ports. In this case, all ports depending on expat > will be listed there. > > You combine sets of ports using logical operators "and", "or", "not", > "!", "(" and ")". > > If you are interested in all the python modules being unmaintained you > could do a query like: > ?port echo maintainer:nomaintainer and \( py-* py25-* py26-* \) > > And it is even possible to find all python modules with either no > maintainer or having openmaintainer set: > ?port echo \( maintainer:nomaintainer maintainer:openmaintainer \) \ > ?and \( py-* py25-* py26-* \) This is indeed quite powerful and sure one of the nice aspects of macports. It think the documentation does not give it the credit it deserves, but the query possibilities are really extensive here. With respect to the original question, I'd like to mildly oppose the idea to remove 'list' entirely. Rather making it behave like 'echo' is something I could imagine to work well. 'echo' as it is, it feels, is meant a bit like 'debug-query-statement' or something: just to see what a particular expression would yield. But in many instances, the output from echo is exactly what you want; think shell script 'for' loop. So 'list' could become an alias for 'echo'. For in-depth information, there is still 'info.' Or we could make the version information appear only on -v/verbose flag. Also, I find 'port installed' and 'port outdated' a bit odd, because they look very much like the pseudo-name selectors, but they aren't. And they really are the only commands the 'receipt database,' as opposed to the portindex/portfile database. (IIRC, that is.) So one solution to make the whole command line interface more consistent would be to introduce a 'receipt database' / installed software (top level) command, which in turn accepts subcommands -- which might well be only 'installed' and 'outdated' in the beginning, still mimicking 'list' and its subcommands / query expression language. Later this command would become more parallel, or mirror, the 'list' query expression capabilities. I can't really come up with a name for this 'installed ports database' top-level command right now, unfortunately. 'host'? 'local'? 'present'? I don't know. Anyone else have an idea? :) So, in summary, I'd propose: keep 'list' and make it more clear (remove latest version, or put both) make the distinction between index and installed more visible by introducing more or less parallel top-level command for each. Florian > > You can't do such things with simple modifiers you proposed and they > work for any port command accepting a list of ports, that is such a port > expression. > > This is very powerful, but you don't have to use it. It is still easy > and intuitive to give a simple list of port names to a port command. > > Rainer > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From florian.ebeling at gmail.com Thu Mar 12 15:00:42 2009 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Thu, 12 Mar 2009 23:00:42 +0100 Subject: ui_msg In-Reply-To: References: Message-ID: <5cbbe4ae0903121500u4d3d3b2cve874955d71ff6b8a@mail.gmail.com> On Thu, Mar 12, 2009 at 7:29 PM, Bradley Giesbrecht wrote: > Is there anyone else who thinks it would be nice to collect ui_msg and > display the messages at the very end of the port run? > > Or make it an option? Or is there a way to do this already? +1. This one is on my personal wish list for a while now. Ideally these would end up in the users email inbox, imho, but a separate log file would do as well. Email might be tricky as well, since most people are not really prepared to just have running MTA. Message should still very much be plain text style/email in that they give instructions on what to do after a certain server was installed or upgraded, and similar things. The most common thing is probebly the pointer to the launchd plist. Florian > > Maybe even write them to a ui_message log along with a time stamp and the > original port command. > > So if you install something that has a bunch of dependencies, and especially > if you use the -v or -d flags you can read all the messages at the end. > > Removing and rebuilding things to test perl5.8 as an example: > port -f uninstall installed > port -k install mysql5-devel @5.1.30_1+partition+server apache2 php5 > @5.2.8_1+apache2+imap+macosx+mysql5+pear+pspell+readline+sqlite+tidy perl5.8 > @5.8.9_2+db+gdbm+shared+threads php5 > @5.2.8_1+apache2+imap+macosx+mysql5+pear+pspell+readline+sqlite+tidyport -vk > install mysql5-devel @5.1.30_1+partition+server apache2 php5 > @5.2.8_1+apache2+imap+macosx+mysql5+pear+pspell+readline+sqlite+tidy perl5.8 > @5.8.9_2+db+gdbm+shared+threads php5 > @5.2.8_1+apache2+imap+macosx+mysql5+pear+pspell+readline+sqlite+tidy > ---> normal output without us_msg ............ > > and at the end of the port run > > --->. Message from port mysql5-devel > ****************************************************** > * In order to setup the database, you might want to run > * sudo -u mysql mysql_install_db5 > * if this is a new install > ****************************************************** > ---> Message from port foo > ****************************************************** > * foo suggests you do something > ****************************************************** > > //Brad > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From brad at pixilla.com Thu Mar 12 15:21:11 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 12 Mar 2009 15:21:11 -0700 Subject: perl5.8 fixup In-Reply-To: <20090311002402.GG10906@darkart.com> References: <2302577A-1938-4C42-9CD8-9F4B3FABD49C@macports.org> <49B3785B.9050402@macports.org> <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> Message-ID: <27ABB9C8-6701-4F51-822B-56206C0FB14B@pixilla.com> On Mar 10, 2009, at 5:24 PM, Eric Hall wrote: > [snip] > > I've attached a set of patches to: > > http://trac.macports.org/ticket/12950#comment:14 > > for testing. So far so good for me. > > > -eric Eric, it appears that changing the man1dir and man3dir to man1p and man3p causes these man dirs to be searched after all the man1 and man3 dirs in the search path. I didn't explain that well so I'll try again. I think man must be searching all the man0 though man9 dirs before searching man1p and man3p. Or something like it. /usr/share/man/man3/CGI.3pm.gz is found before /opt/local/share/ perl5.8/man/man3p/CGI.3pm even when MANPATH looks like this: /opt/local/share/man:/usr/share/man:/usr/X11/man:/usr/local/share/man I'm not saying I like this solution but changing the Portfile to add perl5.8/man: -D man1dir='${prefix}/share/perl5.8/man/man1' \ -D man3dir='${prefix}/share/perl5.8/man/man3' \ -D siteman1dir='${prefix}/share/man/man1' \ -D siteman3dir='${prefix}/share/man/man3' \ -D vendorman1dir='${prefix}/share/man/man1' \ -D vendorman3dir='${prefix}/share/man/man3' and making my MANPATH look like: /opt/local/share/man:/opt/local/share/perl5.8/man:/opt/local/man:/usr/ share/man:/usr/X11/man:/usr/local/share/man causes perl5.8 module man pages to be found before apple installed man pages. I think this could also be done with man extensions but I don't see where in the perl Configure script there are vars for setting man1ext, site_man1ext and vendor_man1ext. //Brad From stechert at gmail.com Thu Mar 12 15:34:41 2009 From: stechert at gmail.com (Andre Stechert) Date: Thu, 12 Mar 2009 15:34:41 -0700 Subject: Deprecating port list In-Reply-To: <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> Message-ID: <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> In some other CLI's (e.g., mysql, IOS), the word "show" is used to communicate what is being done here. e.g., port show outdated port show installed port show maintainer:nomaintainer There also seems to be a case of noun vs. adjective vs. verb in the syntax. E.g., in the output of "port help" there are things called "actions" and then later called "commands". Actions strongly implies they should be verbs, but in practice they are not always verbs. Mostly like this: port build port configure port fetch ... but some usage has adjectives: port outdated port installed (interestingly not for all pseudo-portnames, e.g., you can't "port inactive" which would be a useful predecessor to "port uninstall inactive". Although I now know you can "port echo inactive"!) and some nouns: port info port location port version A more radical suggestion would be to require something like "echo" or "show" in front of all non-verb targets. Not particularly pushing for it, but thought it might be worth throwing out there. Andre On Thu, Mar 12, 2009 at 2:46 PM, C. Florian Ebeling wrote: > On Thu, Mar 12, 2009 at 8:08 PM, Rainer M?ller wrote: >> Jeremy Lavergne wrote: >>> I wouldn't expect any logic operations to actually take place in the >>> examples above. ?I'd expect it to do the command on each one >>> independently. ?When it comes across depends:expat (or something else >>> that's a "reserved" name, I would expect it to function according to >>> what the command is, and apply it to the following ports. >> >> No, you completely misunderstand pseudo-ports. >> >> This is not meant as a modifier for following ports (how would you unset >> the modifier?), but as a selector. A pseudo-port like depends:expat is >> replaced by a set of ports. In this case, all ports depending on expat >> will be listed there. >> >> You combine sets of ports using logical operators "and", "or", "not", >> "!", "(" and ")". >> >> If you are interested in all the python modules being unmaintained you >> could do a query like: >> ?port echo maintainer:nomaintainer and \( py-* py25-* py26-* \) >> >> And it is even possible to find all python modules with either no >> maintainer or having openmaintainer set: >> ?port echo \( maintainer:nomaintainer maintainer:openmaintainer \) \ >> ?and \( py-* py25-* py26-* \) > > This is indeed quite powerful and sure one of the nice aspects > of macports. It think the documentation does not give it > the credit it deserves, but the query possibilities are really > extensive here. > > With respect to the original question, I'd like to mildly oppose > the idea to remove 'list' entirely. Rather making it behave like > 'echo' is something I could imagine to work well. > > 'echo' as it is, it feels, is meant a bit like 'debug-query-statement' > or something: just to see what a particular expression would yield. > But in many instances, the output from echo is exactly what you > want; think shell script 'for' loop. So 'list' could become an alias > for 'echo'. For in-depth information, there is still 'info.' Or we > could make the version information appear only on -v/verbose flag. > > Also, I find 'port installed' and 'port outdated' a bit odd, because > they look very much like the pseudo-name selectors, but they > aren't. And they really are the only commands the 'receipt database,' > as opposed to the portindex/portfile database. (IIRC, that is.) > > So one solution to make the whole command line interface more > consistent would be to introduce a 'receipt database' / installed > software (top level) command, which in turn accepts subcommands -- > which might well be only 'installed' and 'outdated' in the beginning, > still mimicking 'list' and its subcommands / query expression language. > Later this command would become more parallel, or mirror, the 'list' > query expression capabilities. > > I can't really come up with a name for this 'installed ports database' > top-level command right now, unfortunately. 'host'? 'local'? 'present'? > I don't know. Anyone else have an idea? :) > > So, in summary, I'd propose: keep 'list' and make it more clear (remove > latest version, or put both) make the distinction between index and > installed more visible by introducing more or less parallel top-level > command for each. > > Florian > > >> >> You can't do such things with simple modifiers you proposed and they >> work for any port command accepting a list of ports, that is such a port >> expression. >> >> This is very powerful, but you don't have to use it. It is still easy >> and intuitive to give a simple list of port names to a port command. >> >> Rainer >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> > > > > -- > Florian Ebeling > Twitter: febeling > florian.ebeling at gmail.com > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From opendarwin.org at darkart.com Thu Mar 12 16:22:15 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Thu, 12 Mar 2009 23:22:15 +0000 Subject: perl5.8 fixup In-Reply-To: <27ABB9C8-6701-4F51-822B-56206C0FB14B@pixilla.com> References: <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> <27ABB9C8-6701-4F51-822B-56206C0FB14B@pixilla.com> Message-ID: <20090312232215.GI10906@darkart.com> On Thu, Mar 12, 2009 at 03:21:11PM -0700, Bradley Giesbrecht wrote: > > On Mar 10, 2009, at 5:24 PM, Eric Hall wrote: > > >[snip] > > > > I've attached a set of patches to: > > > > http://trac.macports.org/ticket/12950#comment:14 > > > > for testing. So far so good for me. > > > > > > -eric > > Eric, it appears that changing the man1dir and man3dir to man1p and > man3p causes these man dirs to be searched after all the man1 and man3 > dirs in the search path. I didn't explain that well so I'll try again. > > I think man must be searching all the man0 though man9 dirs before > searching man1p and man3p. Or something like it. Again, see /etc/man.conf, in particular the MANSECT line. > > /usr/share/man/man3/CGI.3pm.gz is found before /opt/local/share/ > perl5.8/man/man3p/CGI.3pm even when MANPATH looks like this: > > /opt/local/share/man:/usr/share/man:/usr/X11/man:/usr/local/share/man > > I'm not saying I like this solution but changing the Portfile to add > perl5.8/man: > -D man1dir='${prefix}/share/perl5.8/man/man1' \ > -D man3dir='${prefix}/share/perl5.8/man/man3' \ > -D siteman1dir='${prefix}/share/man/man1' \ > -D siteman3dir='${prefix}/share/man/man3' \ > -D vendorman1dir='${prefix}/share/man/man1' \ > -D vendorman3dir='${prefix}/share/man/man3' > > and making my MANPATH look like: > > /opt/local/share/man:/opt/local/share/perl5.8/man:/opt/local/man:/usr/ > share/man:/usr/X11/man:/usr/local/share/man > > causes perl5.8 module man pages to be found before apple installed man > pages. I really don't like changing MANPATH, its auto-generated (for the most part) and I think that's a Good Thing(tm). Forcing people to set a MANPATH will result in breakage. I agree it'd be better to get the MP installed man pages first - that does happen for p5-* installed man pages, but not for the base perl5.8 installed man pages. I think that's an acceptable loss, though not ideal. -eric From ryandesign at macports.org Thu Mar 12 19:45:43 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 12 Mar 2009 21:45:43 -0500 Subject: [48020] trunk/dports/www/elinks-devel/Portfile In-Reply-To: <20090313023452.A51C511C6173@beta.macosforge.org> References: <20090313023452.A51C511C6173@beta.macosforge.org> Message-ID: <0F54E84E-64AE-417F-8977-DB85E6502498@macports.org> On Mar 12, 2009, at 21:34, perry at macports.org wrote: > Revision: 48020 > http://trac.macports.org/changeset/48020 > Author: perry at macports.org > Date: 2009-03-12 19:34:52 -0700 (Thu, 12 Mar 2009) > Log Message: > ----------- > www/elinks-devel - Removed support for LZMA. > * elinks-devel no longer builds --with-lzma due to an API change. You must also increase the port's revision, so everyone rebuilds elinks-devel with this change. > Modified Paths: > -------------- > trunk/dports/www/elinks-devel/Portfile > > Modified: trunk/dports/www/elinks-devel/Portfile > =================================================================== > --- trunk/dports/www/elinks-devel/Portfile 2009-03-13 02:32:54 UTC > (rev 48019) > +++ trunk/dports/www/elinks-devel/Portfile 2009-03-13 02:34:52 UTC > (rev 48020) > @@ -19,8 +19,8 @@ > livecheck.url ${homepage} > > depends_lib \ > - port:boehmgc port:bzip2 port:expat port:libiconv port:liblzma \ > - port:openssl port:see port:zlib > + port:boehmgc port:bzip2 port:expat port:libiconv port:openssl > port:see \ > + port:zlib > > distname elinks-${version} > master_sites ${homepage}download/ > @@ -38,11 +38,11 @@ > --enable-ipv6 --enable-largefile --enable-leds --enable-mailcap \ > --enable-marks --enable-mimetypes --enable-mouse --enable-nls \ > --enable-nntp --enable-uri-rewrite --enable-utf-8 --enable-xbel \ > - --with-bzlib --with-gc --with-libiconv --with-lzma --with- > openssl \ > - --with-see --with-zlib --without-gnutls --without-gpm -- > without-gssapi \ > - --without-guile --without-idn --without-lua --without-perl \ > - --without-python --without-ruby --without-spidermonkey -- > without-x \ > - --without-xterm > + --with-bzlib --with-gc --with-libiconv --with-openssl --with- > see \ > + --with-zlib --without-gnutls --without-gpm --without-gssapi \ > + --without-guile --without-idn --without-lua --without-lzma \ > + --without-perl --without-python --without-ruby --without- > spidermonkey \ > + --without-x --without-xterm From raimue at macports.org Thu Mar 12 22:06:48 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Fri, 13 Mar 2009 06:06:48 +0100 Subject: Deprecating port list In-Reply-To: <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> Message-ID: <49B9E9E8.4060401@macports.org> Andre Stechert wrote: > In some other CLI's (e.g., mysql, IOS), the word "show" is used to > communicate what is being done here. > > e.g., > > port show outdated > port show installed > port show maintainer:nomaintainer As I said before, if we are going to use a single command, I would expect consistent output. But for installed I would like to see the version which is installed, for outdated I would like to see the new and old version. 'port outdated' and 'port installed' have a different output format. For this functionality it is not enough to expand the pseudo-port only. How would you combine that into a single 'show' command? > There also seems to be a case of noun vs. adjective vs. verb in the > syntax. E.g., in the output of "port help" there are things called > "actions" and then later called "commands". Actions strongly implies > they should be verbs, but in practice they are not always verbs. Internally they are called "actions", but I think documentation and users began to use the term "commands". > Mostly like this: > > port build > port configure > port fetch > ... > > but some usage has adjectives: > > port outdated > port installed > (interestingly not for all pseudo-portnames, e.g., you can't "port > inactive" which would be a useful predecessor to "port uninstall > inactive". Although I now know you can "port echo inactive"!) As explained above, there is a special output format for outdated and installed which is not necessary for any other set of ports. > and some nouns: > > port info > port location > port version > > A more radical suggestion would be to require something like "echo" or > "show" in front of all non-verb targets. And you forgot: cat, cd, contents, dependents, deps, dir, distfiles, file, notes (on trunk), platform, url, usage, variants, work There are lots of actions/commands which are not a verb. It would not make sense to require a verb before them. What should it be? 'port do'? Rainer From blb at macports.org Thu Mar 12 22:54:28 2009 From: blb at macports.org (Bryan Blackburn) Date: Thu, 12 Mar 2009 23:54:28 -0600 Subject: Removal of port options i and x Message-ID: <20090313055428.GO836@ninagal.withay.com> I'd like to see two options from port removed, -i and -x. For -i, the man page says Read commands from stdin. Short for -F - which means for handling commands from, eg, pipes. However, not using -i does that anyway as "echo info pkgconfig | port" works identically to "echo info pkgconfig | port -i". Using 'port -i' is also identical to just 'port' as they both drop you into interactive mode. The only difference I can see is that -i allows you to specify commands on port's command line, then when those are done, port drops to interactive mode instead of exiting. If there's no other use for it, is that a very necessary option? As far as -x, that's on ticket #13918: Basically we have two mutually exclusive options -x and -p, but without specifying either port acts in some other, odd, almost in-between mode. As mentioned on that ticket, I'd much prefer to see port default to what -x does, and simply keep -p for those who want port to continue past errors. Any objections? Bryan From stechert at gmail.com Thu Mar 12 23:28:50 2009 From: stechert at gmail.com (Andre Stechert) Date: Thu, 12 Mar 2009 23:28:50 -0700 Subject: Deprecating port list In-Reply-To: <49B9E9E8.4060401@macports.org> References: <49B916AD.7020203@macports.org> <49B93A6E.7060304@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> Message-ID: <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> On Thu, Mar 12, 2009 at 10:06 PM, Rainer M?ller wrote: > Andre Stechert wrote: >> In some other CLI's (e.g., mysql, IOS), the word "show" is used to >> communicate what is being done here. >> >> e.g., >> >> ? ?port show outdated >> ? ?port show installed >> ? ?port show maintainer:nomaintainer > > As I said before, if we are going to use a single command, I would > expect consistent output. But for installed I would like to see > the version which is installed, for outdated I would like to see the new > and old version. > > 'port outdated' and 'port installed' have a different output format. For > this functionality it is not enough to expand the pseudo-port only. > > How would you combine that into a single 'show' command? First off - thanks for hearing this out. Second, sorry for not connecting all the dots above. I hate repeating myself, and hate it when I inadvertently force others to do so. Apologies. Re: 'show', please understand that the idea is not to create a new 'port show installed' command alongside 'port installed', 'port echo installed', and 'port list installed'. Rather I meant to say that, in the interest of reducing user confusion, the word "show" might convey what we seem to mean more than "echo", but that it also makes a lot of sense to reduce the number of ways we have of saying the same thing (echo vs. list). Re: a single 'show' command vs. the different formats of 'port installed' and 'port echo installed', I guess I would personally try to reduce the number of formats to one or at least generate the multiple formats with one command with options. The difference in the output between 'port installed' and 'port echo installed' seems to be about as minor as the difference between 'port echo installed' and 'port list installed': 'port installed' lines look like: a52dec @0.7.4_0 (active) 'port echo installed' lines look like: a52dec @0.7.4_0 'port list installed' lines look like: a52dec @0.7.4 audio/a52dec Why not just make the output of "port echo installed" rich enough to handle whatever use cases are currently being handled by "port installed" and "port list installed"? Outdated is similar: 'port outdated' lines look like: aalib 1.4rc5_3 < 1.4rc5_4 'port echo outdated' lines look like: aalib @1.4rc5_3 'port list outdated' lines look like: aalib @1.4rc5 graphics/aalib >> A more radical suggestion would be to require something like "echo" or >> "show" in front of all non-verb targets. > > And you forgot: > cat, cd, contents, dependents, deps, dir, distfiles, file, > notes (on trunk), platform, url, usage, variants, work > > There are lots of actions/commands which are not a verb. It would not > make sense to require a verb before them. What should it be? 'port do'? For contents, dependents, deps, dir, distfiles, file, notes, platform, url, and variants, "port show ..." seems pretty natural to me, but YMMV. port cat - well, i guess technically cat is technically a noun, but in this case, I think it's being used as a verb :-). port cd - you can do that only in interactive mode, right? Cheers! Andre From ryandesign at macports.org Fri Mar 13 01:42:50 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 13 Mar 2009 03:42:50 -0500 Subject: Deprecating port list In-Reply-To: <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> References: <49B916AD.7020203@macports.org> <49B93A6E.7060304@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> Message-ID: <111044D7-CD95-4D30-8C0B-782BB38DB089@macports.org> I have not used "port list" or "port echo" very often. Now that I'm looking at them, I'm confused about echo's behavior. I have zlib installed: $ port installed zlib The following ports are currently installed: zlib @1.2.3_2+universal (active) "port list zlib" shows the name, version and category: $ port list zlib zlib @1.2.3 archivers/zlib "port echo zlib" shows the name only: $ port echo zlib zlib But "port echo installed" shows the name and version, revision and variants: $ port echo installed | grep ^zlib zlib @1.2.3_2+universal Why does "echo" behave differently depending on whether zlib was specified implicitly via the "installed" pseudo-port, or explicitly on the command line? I guess what's happening is that "installed" is expanding to not only the names of the installed ports but also their version, revision and variants, which I can even fake: $ port echo zlib @1.0_0+foo+bar zlib @1.0_0+bar+foo From ryandesign at macports.org Fri Mar 13 01:44:15 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 13 Mar 2009 03:44:15 -0500 Subject: Removal of port options i and x In-Reply-To: <20090313055428.GO836@ninagal.withay.com> References: <20090313055428.GO836@ninagal.withay.com> Message-ID: On Mar 13, 2009, at 00:54, Bryan Blackburn wrote: > I'd like to see two options from port removed, -i and -x. [snip] > Any objections? Sounds ok to me! From kngspook at gmail.com Fri Mar 13 01:50:44 2009 From: kngspook at gmail.com (Neil) Date: Fri, 13 Mar 2009 01:50:44 -0700 Subject: Deprecating port list In-Reply-To: <49B94FFB.5000600@macports.org> References: <49B916AD.7020203@macports.org> <49B922C2.8090509@macports.org> <49B93A6E.7060304@macports.org> <49B93E13.4020904@shopwatch.org> <49B94FFB.5000600@macports.org> Message-ID: <77e4079b0903130150m283ecf25hc93c5f0599c4a4b6@mail.gmail.com> On Thu, Mar 12, 2009 at 11:10 AM, Joshua Root wrote: > Jay Levitt wrote: > > Rainer M?ller wrote: > >> This is basically 'port outdated'. What would be the use of this if it > >> is so similar? > > > > I think "port list" could/should be an alias for "port outdated". I'm > not > > usually a fan of synonyms, but "list" is a basic function, provided by > yum, > > gem, and quite probably others. Sure, you can document it in the wiki, > but > > why force users to look something up and type a different command when > you > > already know what they mean? > > > > Is there a use case where someone would be displeased by the output of > "port > > outdated" when they do a "port list", and where they'd be more pleased to > > see "Please see the documentation" or "No such command?" > > `port list installed`,`port list all`, `port list `. > > Having commands just because users might try them doesn't seem like a > good policy to me. As for the "we know what they meant" argument, it > would seem that we don't, judging by the differences in what we think > the command should do. > > I'm happy for list to be removed. If it stays, its output needs to be > changed so it's clear what it is showing, and so 'list installed' does > something sensible. One possibility would be to have two labelled > columns, one for the available version and one for the installed > versions of each port. > I'm with Josh here (more or less): It seems like rather than remove port list, just add a couple lines indicating what is going on; maybe column headers and one line saying "Showing all available ports." or "Showing all installed ports." Dump those to stderr so people can still do easy piping and parsing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From florian.ebeling at gmail.com Fri Mar 13 01:51:22 2009 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Fri, 13 Mar 2009 09:51:22 +0100 Subject: Deprecating port list In-Reply-To: <111044D7-CD95-4D30-8C0B-782BB38DB089@macports.org> References: <49B916AD.7020203@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> <111044D7-CD95-4D30-8C0B-782BB38DB089@macports.org> Message-ID: <5cbbe4ae0903130151s51032971r334d57ecc8089891@mail.gmail.com> On Fri, Mar 13, 2009 at 9:42 AM, Ryan Schmidt wrote: > I have not used "port list" or "port echo" very often. > > Now that I'm looking at them, I'm confused about echo's behavior. > > I have zlib installed: > > $ port installed zlib > The following ports are currently installed: > ?zlib @1.2.3_2+universal (active) > > "port list zlib" shows the name, version and category: > > $ port list zlib > zlib ? ? ? ? ? ? ? ? ? ? ? ? ? @1.2.3 ? ? ? ? ?archivers/zlib > > "port echo zlib" shows the name only: > > $ port echo zlib > zlib > > But "port echo installed" shows the name and version, revision and variants: > > $ port echo installed | grep ^zlib > zlib ? ? ? ? ? ? ? ? ? ? ? ? ? @1.2.3_2+universal > > Why does "echo" behave differently depending on whether zlib was specified > implicitly via the "installed" pseudo-port, or explicitly on the command > line? Indeed. I'm felt sure that it behaved differently, but maybe that was a preconception. > > I guess what's happening is that "installed" is expanding to not only the > names of the installed ports but also their version, revision and variants, > which I can even fake: > > $ port echo zlib @1.0_0+foo+bar > zlib ? ? ? ? ? ? ? ? ? ? ? ? ? @1.0_0+bar+foo > > -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From jberry at macports.org Fri Mar 13 08:10:55 2009 From: jberry at macports.org (James Berry) Date: Fri, 13 Mar 2009 08:10:55 -0700 Subject: Removal of port options i and x In-Reply-To: <20090313055428.GO836@ninagal.withay.com> References: <20090313055428.GO836@ninagal.withay.com> Message-ID: <01D64034-77E1-453A-B2D9-2E7F9FDCA488@macports.org> Hi Bryan, On Mar 12, 2009, at 10:54 PM, Bryan Blackburn wrote: > I'd like to see two options from port removed, -i and -x. > > For -i, the man page says > > Read commands from stdin. Short for -F - > > which means for handling commands from, eg, pipes. However, not > using -i > does that anyway as "echo info pkgconfig | port" works identically > to "echo > info pkgconfig | port -i". Using 'port -i' is also identical to > just 'port' > as they both drop you into interactive mode. The only difference I > can see > is that -i allows you to specify commands on port's command line, > then when > those are done, port drops to interactive mode instead of exiting. If > there's no other use for it, is that a very necessary option? I wrote all that stuff, so I'll comment. I think later use was the primary motivation for -i. When this was written there was not yet any experience with interactive mode, piping of commands, etc. So it wasn't clear to what degree we'd need control. I think time has shown there to be little demand for the subtleties of this feature, so I'm fine with removing -i, especially as one can reconstruct it using -F - > As far as -x, that's on ticket #13918: > > > > Basically we have two mutually exclusive options -x and -p, but > without > specifying either port acts in some other, odd, almost in-between > mode. As > mentioned on that ticket, I'd much prefer to see port default to > what -x > does, and simply keep -p for those who want port to continue past > errors. > > Any objections? Here, too, when port was largely rewritten to add support for having commands work on multiple ports/pseudo-ports, there was a bit of a change of behavior, so I put these extra flags in to control how it might work. I think defaulting to the -x behavior is fine. James From jberry at macports.org Fri Mar 13 08:31:02 2009 From: jberry at macports.org (James Berry) Date: Fri, 13 Mar 2009 08:31:02 -0700 Subject: Deprecating port list In-Reply-To: <111044D7-CD95-4D30-8C0B-782BB38DB089@macports.org> References: <49B916AD.7020203@macports.org> <49B93A6E.7060304@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> <111044D7-CD95-4D30-8C0B-782BB38DB089@macports.org> Message-ID: <610D1189-A1E6-49A9-9400-3EF87933A974@macports.org> Hi Ryan, On Mar 13, 2009, at 1:42 AM, Ryan Schmidt wrote: > I have not used "port list" or "port echo" very often. > > Now that I'm looking at them, I'm confused about echo's behavior. I'll try to answer this; the reasons for this are a little subtle. As the author of this stuff, at least I understand the motivations involved. The ports that may be specified on the command line may be general ("apache"), or more specific ("apache at 1.1"), or more specific yet (addition of variant specs). So the list of ports we build up includes those various degrees of information. port tries to be careful not to assume more than it knows. If you just say "port echo zlib", it just knows that you've specified zlib, but not anything else about it. pseudo-ports, at least in some cases, expand to much more specific information. "port echo installed", for instance, knows exactly which version of apache is installed, and so will expand the pseudo-port to that more specific instance of the apache port. You're thankful for this behavior when you say something like "port uninstall inactive", and rely on the inactive pseudo-port to expand to a specific port and version of the inactive port. Depending on the particular pseudo-port, the version information may relate to the latest version of the port, or a version that is installed. port is also careful, when doing set operations on ports, to do the right thing in promoting or coalescing this information. If I remember right, for instance, "apache and apache at 1.1" will resolve to "apache at 1.1", but "apache at 2.0 and apache at 1.1" will resolve to the null set. Etc. That background laid, I'll try to get to the answer. "port echo" really does just tell you all the information this it has about the port specifications you've given. In the case of "port apache" (or "port zlib"), it doesn't know anything else. Where you specified more, or where a pseudo-port supplied more specific information, it has more knowledge, and will report it. Remember that port echo, itself, doesn't query any database of ports: it just echos what you gave it (including expansions thereof). The pseudo-ports, on the other hand, do hit the database, and so may have supplied more information from there. Hope that helps. James > I have zlib installed: > > $ port installed zlib > The following ports are currently installed: > zlib @1.2.3_2+universal (active) > > "port list zlib" shows the name, version and category: > > $ port list zlib > zlib @1.2.3 archivers/zlib > > "port echo zlib" shows the name only: > > $ port echo zlib > zlib > > But "port echo installed" shows the name and version, revision and > variants: > > $ port echo installed | grep ^zlib > zlib @1.2.3_2+universal > > Why does "echo" behave differently depending on whether zlib was > specified implicitly via the "installed" pseudo-port, or explicitly > on the command line? > > I guess what's happening is that "installed" is expanding to not > only the names of the installed ports but also their version, > revision and variants, which I can even fake: > > $ port echo zlib @1.0_0+foo+bar > zlib @1.0_0+bar+foo > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From jberry at macports.org Fri Mar 13 08:54:58 2009 From: jberry at macports.org (James Berry) Date: Fri, 13 Mar 2009 08:54:58 -0700 Subject: Deprecating port list In-Reply-To: <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> References: <49B916AD.7020203@macports.org> <49B93A6E.7060304@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> Message-ID: <0B91728B-7A87-4F49-B170-C6EC3A499B41@macports.org> On Mar 12, 2009, at 11:28 PM, Andre Stechert wrote: > The difference in the output between 'port installed' and 'port echo > installed' seems > to be about as minor as the difference between 'port echo installed' > and 'port list installed': > > 'port installed' lines look like: a52dec @0.7.4_0 (active) > 'port echo installed' lines look like: > a52dec @0.7.4_0 > 'port list installed' lines look like: a52dec > @0.7.4 audio/a52dec > > Why not just make the output of "port echo installed" rich enough to > handle whatever use cases A good answer is that if you read the reply I just gave to Ryan, you'll see that port echo is extremely lightweight, and meant to be so. It just tells you what you told it. It really doesn't have the information that port list gets. And if we put it into the position of having to get that information, than it looses its value of just parroting what you've told it. > port cat - well, i guess technically cat is technically a noun, but in > this case, I think it's being used as a verb :-). > port cd - you can do that only in interactive mode, right? Strictly speaking, you can do port cd on the command line, but it doesn't generally have any effect. (port can change the current directory for the duration of its execution, but there's no way it can change the current directory for its parent process. It would be cool if it could, but I know no way to achieve that. Any ideas? Even more strictly speaking, you can use the cd command on the command line. Try this, for instance: port cd apache \; file \; dir \; url :) Jaes From brad at pixilla.com Fri Mar 13 09:20:49 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 13 Mar 2009 09:20:49 -0700 Subject: perl5.8 fixup In-Reply-To: <20090312232215.GI10906@darkart.com> References: <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> <27ABB9C8-6701-4F51-822B-56206C0FB14B@pixilla.com> <20090312232215.GI10906@darkart.com> Message-ID: On Mar 12, 2009, at 4:22 PM, Eric Hall wrote: > On Thu, Mar 12, 2009 at 03:21:11PM -0700, Bradley Giesbrecht wrote: >> >> On Mar 10, 2009, at 5:24 PM, Eric Hall wrote: >> >>> [snip] >>> >>> I've attached a set of patches to: >>> >>> http://trac.macports.org/ticket/12950#comment:14 >>> >>> for testing. So far so good for me. >>> >>> >>> -eric >> >> Eric, it appears that changing the man1dir and man3dir to man1p and >> man3p causes these man dirs to be searched after all the man1 and >> man3 >> dirs in the search path. I didn't explain that well so I'll try >> again. >> >> I think man must be searching all the man0 though man9 dirs before >> searching man1p and man3p. Or something like it. > > > Again, see /etc/man.conf, in particular the MANSECT line. I have. So what am I supposed to see that's relevant to apple man pages showing up before perl5.8 man pages? >> /usr/share/man/man3/CGI.3pm.gz is found before /opt/local/share/ >> perl5.8/man/man3p/CGI.3pm even when MANPATH looks like this: >> >> /opt/local/share/man:/usr/share/man:/usr/X11/man:/usr/local/share/man >> >> I'm not saying I like this solution but changing the Portfile to add >> perl5.8/man: >> -D man1dir='${prefix}/share/perl5.8/man/man1' \ >> -D man3dir='${prefix}/share/perl5.8/man/man3' \ >> -D siteman1dir='${prefix}/share/man/man1' \ >> -D siteman3dir='${prefix}/share/man/man3' \ >> -D vendorman1dir='${prefix}/share/man/man1' \ >> -D vendorman3dir='${prefix}/share/man/man3' >> >> and making my MANPATH look like: >> >> /opt/local/share/man:/opt/local/share/perl5.8/man:/opt/local/man:/ >> usr/ >> share/man:/usr/X11/man:/usr/local/share/man >> >> causes perl5.8 module man pages to be found before apple installed >> man >> pages. > > I really don't like changing MANPATH, its auto-generated > (for the most part) and I think that's a Good Thing(tm). Forcing > people to set a MANPATH will result in breakage. > > I agree it'd be better to get the MP installed man pages > first - that does happen for p5-* installed man pages, but > not for the base perl5.8 installed man pages. I think that's > an acceptable loss, though not ideal. I'm not quick to agree. If no p5 modules are installed we get apples perl module man pages? That doesn't sound good. Apples perl modules could be many versions different. By moving the perl5.8 man pages at least there is the option to have man show the port perl5.8 man pages first by adding to MANPATH. If you don't add to MANPATH you get the apple man pages. Since freebsd ships with perl but allows you to install ports perl do you know how they handle it? I'm going to log into a freebsd server and find out. //Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at pixilla.com Fri Mar 13 09:22:41 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 13 Mar 2009 09:22:41 -0700 Subject: perl5.8 fixup In-Reply-To: <20090312232215.GI10906@darkart.com> References: <883DB2D2-C5F1-4F35-825F-3DA69D61A4CB@macports.org> <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> <27ABB9C8-6701-4F51-822B-56206C0FB14B@pixilla.com> <20090312232215.GI10906@darkart.com> Message-ID: <7239713A-E8B9-4365-B251-136266B8EADC@pixilla.com> >> /usr/share/man/man3/CGI.3pm.gz is found before /opt/local/share/ >> perl5.8/man/man3p/CGI.3pm even when MANPATH looks like this: >> >> /opt/local/share/man:/usr/share/man:/usr/X11/man:/usr/local/share/man >> >> I'm not saying I like this solution but changing the Portfile to add >> perl5.8/man: >> -D man1dir='${prefix}/share/perl5.8/man/man1' \ >> -D man3dir='${prefix}/share/perl5.8/man/man3' \ >> -D siteman1dir='${prefix}/share/man/man1' \ >> -D siteman3dir='${prefix}/share/man/man3' \ >> -D vendorman1dir='${prefix}/share/man/man1' \ >> -D vendorman3dir='${prefix}/share/man/man3' >> >> and making my MANPATH look like: >> >> /opt/local/share/man:/opt/local/share/perl5.8/man:/opt/local/man:/ >> usr/ >> share/man:/usr/X11/man:/usr/local/share/man >> >> causes perl5.8 module man pages to be found before apple installed >> man >> pages. > > I really don't like changing MANPATH, its auto-generated > (for the most part) and I think that's a Good Thing(tm). Forcing > people to set a MANPATH will result in breakage. Aren't we already adding macports /opt/local/share/man to MANPATH? //Brad From stechert at gmail.com Fri Mar 13 09:22:59 2009 From: stechert at gmail.com (Andre Stechert) Date: Fri, 13 Mar 2009 09:22:59 -0700 Subject: Deprecating port list In-Reply-To: <0B91728B-7A87-4F49-B170-C6EC3A499B41@macports.org> References: <49B916AD.7020203@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> <0B91728B-7A87-4F49-B170-C6EC3A499B41@macports.org> Message-ID: <12a697af0903130922w1ffbbb6at2780ae6e861f4443@mail.gmail.com> On Fri, Mar 13, 2009 at 8:54 AM, James Berry wrote: > > On Mar 12, 2009, at 11:28 PM, Andre Stechert wrote: > >> The difference in the output between 'port installed' and 'port echo >> installed' seems >> to be about as minor as the difference between 'port echo installed' >> and 'port list installed': >> >> 'port installed' lines look like: a52dec @0.7.4_0 (active) >> 'port echo installed' lines look like: a52dec >> @0.7.4_0 >> 'port list installed' lines look like: a52dec >> @0.7.4 ? ? ? ? ?audio/a52dec >> >> Why not just make the output of "port echo installed" rich enough to >> handle whatever use cases > > A good answer is that if you read the reply I just gave to Ryan, you'll see > that port echo is extremely lightweight, and meant to be so. It just tells > you what you told it. It really doesn't have the information that port list > gets. And if we put it into the position of having to get that information, > than it looses its value of just parroting what you've told it. Indeed. I guess what I was trying to point out is that the subtle differences between 'port installed', 'port echo installed', and 'port list installed' will likely be lost on most users and even if they weren't, the value of doing the lightweight thing may not justify the amount of confusion it causes. All that being said, no measurement has been done, so this is all conjecture. > ***more enlightenment*** Cheers, Andre From brad at pixilla.com Fri Mar 13 09:36:01 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 13 Mar 2009 09:36:01 -0700 Subject: Deprecating port list In-Reply-To: <12a697af0903130922w1ffbbb6at2780ae6e861f4443@mail.gmail.com> References: <49B916AD.7020203@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> <0B91728B-7A87-4F49-B170-C6EC3A499B41@macports.org> <12a697af0903130922w1ffbbb6at2780ae6e861f4443@mail.gmail.com> Message-ID: <8F97E751-850F-4E51-93D6-6258F9BF6C5F@pixilla.com> bash-3.2# port installed The following ports are currently installed: apache2 @2.2.11_0+darwin_9 (active) bash-3.2# port -q installed The following ports are currently installed: apache2 @2.2.11_0+darwin_9 (active) I would like a means to print non-formated output without messages like "The following ports are currently installed:". I think "list" or "show" are pretty natural and common commands followed by what you want to see. port list p5-* port show active port show new //Brad From opendarwin.org at darkart.com Fri Mar 13 09:41:15 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Fri, 13 Mar 2009 16:41:15 +0000 Subject: perl5.8 fixup In-Reply-To: <7239713A-E8B9-4365-B251-136266B8EADC@pixilla.com> References: <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> <27ABB9C8-6701-4F51-822B-56206C0FB14B@pixilla.com> <20090312232215.GI10906@darkart.com> <7239713A-E8B9-4365-B251-136266B8EADC@pixilla.com> Message-ID: <20090313164115.GJ10906@darkart.com> On Fri, Mar 13, 2009 at 09:22:41AM -0700, Bradley Giesbrecht wrote: > >>/usr/share/man/man3/CGI.3pm.gz is found before /opt/local/share/ > >>perl5.8/man/man3p/CGI.3pm even when MANPATH looks like this: > >> > >>/opt/local/share/man:/usr/share/man:/usr/X11/man:/usr/local/share/man > >> > >>I'm not saying I like this solution but changing the Portfile to add > >>perl5.8/man: > >> -D man1dir='${prefix}/share/perl5.8/man/man1' \ > >> -D man3dir='${prefix}/share/perl5.8/man/man3' \ > >> -D siteman1dir='${prefix}/share/man/man1' \ > >> -D siteman3dir='${prefix}/share/man/man3' \ > >> -D vendorman1dir='${prefix}/share/man/man1' \ > >> -D vendorman3dir='${prefix}/share/man/man3' > >> > >>and making my MANPATH look like: > >> > >>/opt/local/share/man:/opt/local/share/perl5.8/man:/opt/local/man:/ > >>usr/ > >>share/man:/usr/X11/man:/usr/local/share/man > >> > >>causes perl5.8 module man pages to be found before apple installed > >>man > >>pages. > > > > I really don't like changing MANPATH, its auto-generated > >(for the most part) and I think that's a Good Thing(tm). Forcing > >people to set a MANPATH will result in breakage. > > Aren't we already adding macports /opt/local/share/man to MANPATH? No, /opt/local/share/man gets auto-added to the search paths for man when /opt/local/bin is in one's PATH. So far as the search order goes, the system-installed /etc/man.conf has: MANSECT 1:1p:8:2:3:3p:4:5:6:7:9:0p:tcl:n:l:p:o which means that man will search section 1, then section 1p, then section 8, then section 2, then section 3, then section 3p, and so on. The reason you're seeing the system-installed perl (base/core) man pages is that man searches all the paths for each section, then moves on to the next section. Again, I agree it'd be better to get the MP installed man pages first if possible without doing things like setting MANPATH. I feel that picking up the "wrong" man pages is an acceptable (if undesired) consequence of getting p5-* installs to work without -f. Looking at man a bit more, you could do a couple of things to change this behavior. You could set a MANSECT environment variable, and put 3p in front of 3. Getting crazy with that idea, you could do (for sh/bash/etc.): MANSECT=`egrep '^MANSECT' /etc/man.conf | sed -E 's/:3:3p:/:3p:3:/'` export MANSECT or for csh/tcsh: setenv MANSECT `egrep '^MANSECT' /etc/man.conf | sed -E 's/:3:3p:/:3p:3:/'` This would set the MANSECT variable to what is /etc/man.conf except for re-ordering 3 and 3p. As well, I don't use the man pages for perl modules much, I find that perldoc MODULE_NAME is generally much better documentation. Perhaps this is true for most people, I don't know. -eric From jeremy at lavergne.gotdns.org Fri Mar 13 09:55:19 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 13 Mar 2009 12:55:19 -0400 Subject: Deprecating port list In-Reply-To: <8F97E751-850F-4E51-93D6-6258F9BF6C5F@pixilla.com> References: <49B916AD.7020203@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> <0B91728B-7A87-4F49-B170-C6EC3A499B41@macports.org> <12a697af0903130922w1ffbbb6at2780ae6e861f4443@mail.gmail.com> <8F97E751-850F-4E51-93D6-6258F9BF6C5F@pixilla.com> Message-ID: > bash-3.2# port installed > The following ports are currently installed: > apache2 @2.2.11_0+darwin_9 (active) > > bash-3.2# port -q installed > The following ports are currently installed: > apache2 @2.2.11_0+darwin_9 (active) > > I would like a means to print non-formated output without messages > like "The following ports are currently installed:". In the mean time, you can just pipe it through grep: port installed | grep -v following From jberry at macports.org Fri Mar 13 10:04:15 2009 From: jberry at macports.org (James Berry) Date: Fri, 13 Mar 2009 10:04:15 -0700 Subject: Deprecating port list In-Reply-To: <12a697af0903130922w1ffbbb6at2780ae6e861f4443@mail.gmail.com> References: <49B916AD.7020203@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> <0B91728B-7A87-4F49-B170-C6EC3A499B41@macports.org> <12a697af0903130922w1ffbbb6at2780ae6e861f4443@mail.gmail.com> Message-ID: On Mar 13, 2009, at 9:22 AM, Andre Stechert wrote: >> A good answer is that if you read the reply I just gave to Ryan, >> you'll see >> that port echo is extremely lightweight, and meant to be so. It >> just tells >> you what you told it. It really doesn't have the information that >> port list >> gets. And if we put it into the position of having to get that >> information, >> than it looses its value of just parroting what you've told it. > > Indeed. I guess what I was trying to point out is that the subtle > differences > between 'port installed', 'port echo installed', and 'port list > installed' will likely > be lost on most users and even if they weren't, the value of doing the > lightweight thing may not justify the amount of confusion it > causes. All that > being said, no measurement has been done, so this is all conjecture. I would advocate keeping "echo" as it is, since it has a very real function which would be mutated by trying to add more to it. If "list" needs to be modified to be more useful, or renamed show, or whatever, I think that's fine. James From dluke at geeklair.net Fri Mar 13 10:07:18 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 13 Mar 2009 13:07:18 -0400 Subject: perl5.8 fixup In-Reply-To: <20090313164115.GJ10906@darkart.com> References: <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> <27ABB9C8-6701-4F51-822B-56206C0FB14B@pixilla.com> <20090312232215.GI10906@darkart.com> <7239713A-E8B9-4365-B251-136266B8EADC@pixilla.com> <20090313164115.GJ10906@darkart.com> Message-ID: On Mar 13, 2009, at 12:41 PM, Eric Hall wrote: > Again, I agree it'd be better to get the MP installed man pages > first if possible without doing things like setting MANPATH. I feel > that > picking up the "wrong" man pages is an acceptable (if undesired) > consequence > of getting p5-* installs to work without -f. I agree that it's an acceptable tradeoff (that we may be able to fix in the future). > As well, I don't use the man pages for perl modules much, I find > that perldoc MODULE_NAME is generally much better documentation. > Perhaps > this is true for most people, I don't know. It's true for people who I've worked with who use perl. I find I often just end up viewing the documentation on CPAN anyway... -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jmr at macports.org Fri Mar 13 10:14:59 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 14 Mar 2009 04:14:59 +1100 Subject: Deprecating port list In-Reply-To: <8F97E751-850F-4E51-93D6-6258F9BF6C5F@pixilla.com> References: <49B916AD.7020203@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> <0B91728B-7A87-4F49-B170-C6EC3A499B41@macports.org> <12a697af0903130922w1ffbbb6at2780ae6e861f4443@mail.gmail.com> <8F97E751-850F-4E51-93D6-6258F9BF6C5F@pixilla.com> Message-ID: <49BA9493.2020605@macports.org> Bradley Giesbrecht wrote: > bash-3.2# port installed > The following ports are currently installed: > apache2 @2.2.11_0+darwin_9 (active) > > bash-3.2# port -q installed > The following ports are currently installed: > apache2 @2.2.11_0+darwin_9 (active) > > I would like a means to print non-formated output without messages like > "The following ports are currently installed:". - Josh From brad at pixilla.com Fri Mar 13 10:25:05 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 13 Mar 2009 10:25:05 -0700 Subject: perl5.8 fixup In-Reply-To: <20090313164115.GJ10906@darkart.com> References: <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> <27ABB9C8-6701-4F51-822B-56206C0FB14B@pixilla.com> <20090312232215.GI10906@darkart.com> <7239713A-E8B9-4365-B251-136266B8EADC@pixilla.com> <20090313164115.GJ10906@darkart.com> Message-ID: <81E70198-7707-4AC5-945F-D2FB23F4F90B@pixilla.com> On Mar 13, 2009, at 9:41 AM, Eric Hall wrote: > On Fri, Mar 13, 2009 at 09:22:41AM -0700, Bradley Giesbrecht wrote: >>>> /usr/share/man/man3/CGI.3pm.gz is found before /opt/local/share/ >>>> perl5.8/man/man3p/CGI.3pm even when MANPATH looks like this: >>>> >>>> /opt/local/share/man:/usr/share/man:/usr/X11/man:/usr/local/share/ >>>> man >>>> >>>> I'm not saying I like this solution but changing the Portfile to >>>> add >>>> perl5.8/man: >>>> -D man1dir='${prefix}/share/perl5.8/man/man1' \ >>>> -D man3dir='${prefix}/share/perl5.8/man/man3' \ >>>> -D siteman1dir='${prefix}/share/man/man1' \ >>>> -D siteman3dir='${prefix}/share/man/man3' \ >>>> -D vendorman1dir='${prefix}/share/man/man1' \ >>>> -D vendorman3dir='${prefix}/share/man/man3' >>>> >>>> and making my MANPATH look like: >>>> >>>> /opt/local/share/man:/opt/local/share/perl5.8/man:/opt/local/man:/ >>>> usr/ >>>> share/man:/usr/X11/man:/usr/local/share/man >>>> >>>> causes perl5.8 module man pages to be found before apple installed >>>> man >>>> pages. >>> >>> I really don't like changing MANPATH, its auto-generated >>> (for the most part) and I think that's a Good Thing(tm). Forcing >>> people to set a MANPATH will result in breakage. >> >> Aren't we already adding macports /opt/local/share/man to MANPATH? > > No, /opt/local/share/man gets auto-added to the search paths > for man when /opt/local/bin is in one's PATH. I see. As a normal (non-sudo) user I wasn't seeing /opt/local/share/man without adding the path to MANPATH. sudo manpath does indeed add /opt/local/share/man > So far as the search order goes, the system-installed /etc/man.conf > has: > > MANSECT 1:1p:8:2:3:3p:4:5:6:7:9:0p:tcl:n:l:p:o > > which means that man will search section 1, then section 1p, > then section 8, then section 2, then section 3, then section 3p, and > so on. > The reason you're seeing the system-installed perl (base/core) man > pages > is that man searches all the paths for each section, then moves on to > the next section. > Again, I agree it'd be better to get the MP installed man pages > first if possible without doing things like setting MANPATH. I feel > that > picking up the "wrong" man pages is an acceptable (if undesired) > consequence > of getting p5-* installs to work without -f. > Looking at man a bit more, you could do a couple of things to change > this behavior. You could set a MANSECT environment variable, and > put 3p > in front of 3. Getting crazy with that idea, you could do (for sh/ > bash/etc.): > > MANSECT=`egrep '^MANSECT' /etc/man.conf | sed -E 's/:3:3p:/:3p:3:/'` > export MANSECT > > or for csh/tcsh: > > setenv MANSECT `egrep '^MANSECT' /etc/man.conf | sed -E 's/:3:3p:/: > 3p:3:/'` > > This would set the MANSECT variable to what is /etc/man.conf > except for re-ordering 3 and 3p. > > As well, I don't use the man pages for perl modules much, I find > that perldoc MODULE_NAME is generally much better documentation. > Perhaps > this is true for most people, I don't know. Neither do I. I don't program in perl but I do use the work of others and am only just pushing for the best solution since it's somewhat of a pain to change a package like perl and p5's. Thank you taking the time to explain your solution and the tradeoffs. Since you and I seem to be the only people left on this thread I am endorsing your thoughtful solution and would love to see it committed soon. +1 //Brad From opendarwin.org at darkart.com Fri Mar 13 10:32:42 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Fri, 13 Mar 2009 17:32:42 +0000 Subject: perl5.8 fixup In-Reply-To: <81E70198-7707-4AC5-945F-D2FB23F4F90B@pixilla.com> References: <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> <27ABB9C8-6701-4F51-822B-56206C0FB14B@pixilla.com> <20090312232215.GI10906@darkart.com> <7239713A-E8B9-4365-B251-136266B8EADC@pixilla.com> <20090313164115.GJ10906@darkart.com> <81E70198-7707-4AC5-945F-D2FB23F4F90B@pixilla.com> Message-ID: <20090313173242.GK10906@darkart.com> On Fri, Mar 13, 2009 at 10:25:05AM -0700, Bradley Giesbrecht wrote: > > On Mar 13, 2009, at 9:41 AM, Eric Hall wrote: > > >On Fri, Mar 13, 2009 at 09:22:41AM -0700, Bradley Giesbrecht wrote: [snip] > >>Aren't we already adding macports /opt/local/share/man to MANPATH? > > > > No, /opt/local/share/man gets auto-added to the search paths > >for man when /opt/local/bin is in one's PATH. > > I see. > > As a normal (non-sudo) user I wasn't seeing /opt/local/share/man > without adding the path to MANPATH. > > sudo manpath does indeed add /opt/local/share/man Do you have MANPATH set? If so, man will not auto-add directories based on your PATH (at least that's what I understand it to do). [snip] > > Since you and I seem to be the only people left on this thread I am > endorsing your thoughtful solution and would love to see it committed > soon. > Thanks for trying it out and poking at it, its helpful to have tests done by someone else. -eric From brad at pixilla.com Fri Mar 13 10:46:21 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 13 Mar 2009 10:46:21 -0700 Subject: Deprecating port list In-Reply-To: References: <49B916AD.7020203@macports.org> <49B94F27.3070700@macports.org> <49B95DC5.6000705@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> <0B91728B-7A87-4F49-B170-C6EC3A499B41@macports.org> <12a697af0903130922w1ffbbb6at2780ae6e861f4443@mail.gmail.com> <8F97E751-850F-4E51-93D6-6258F9BF6C5F@pixilla.com> Message-ID: On Mar 13, 2009, at 9:55 AM, Jeremy Lavergne wrote: >> bash-3.2# port installed >> The following ports are currently installed: >> apache2 @2.2.11_0+darwin_9 (active) >> >> bash-3.2# port -q installed >> The following ports are currently installed: >> apache2 @2.2.11_0+darwin_9 (active) >> >> I would like a means to print non-formated output without messages >> like "The following ports are currently installed:". > > In the mean time, you can just pipe it through grep: > > port installed | grep -v following Thanks, I've been using "sed '1d'". My comment is more of general comment for all the commands. I expected -q to have an effect on output from port installed. //Brad From brad at pixilla.com Fri Mar 13 14:10:22 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 13 Mar 2009 14:10:22 -0700 Subject: perl5.8 fixup In-Reply-To: <20090313173242.GK10906@darkart.com> References: <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> <27ABB9C8-6701-4F51-822B-56206C0FB14B@pixilla.com> <20090312232215.GI10906@darkart.com> <7239713A-E8B9-4365-B251-136266B8EADC@pixilla.com> <20090313164115.GJ10906@darkart.com> <81E70198-7707-4AC5-945F-D2FB23F4F90B@pixilla.com> <20090313173242.GK10906@darkart.com> Message-ID: <126D6A26-EF63-49D9-8B7F-A4381D8C28CD@pixilla.com> On Mar 13, 2009, at 10:32 AM, Eric Hall wrote: > On Fri, Mar 13, 2009 at 10:25:05AM -0700, Bradley Giesbrecht wrote: >> I see. >> >> As a normal (non-sudo) user I wasn't seeing /opt/local/share/man >> without adding the path to MANPATH. >> >> sudo manpath does indeed add /opt/local/share/man > > Do you have MANPATH set? If so, man will not auto-add > directories based on your PATH (at least that's what I understand > it to do). I had been using MANPATH but to test I removed it from .profile, logged out of my shell, opened a new shell and ran "manpath" and /opt/ local/share/man was not in my man path. Tried "sudo manpath" and /opt/ local/share/man was in my man path. A quick look shows /opt/local has root:admin and 755 for directories. Would this prevent man from operating on /opt/local/share/man? Maybe because it stores formated results in catx or something? I really don't know much about man. //Brad From blb at macports.org Fri Mar 13 14:23:02 2009 From: blb at macports.org (Bryan Blackburn) Date: Fri, 13 Mar 2009 15:23:02 -0600 Subject: perl5.8 fixup In-Reply-To: <126D6A26-EF63-49D9-8B7F-A4381D8C28CD@pixilla.com> References: <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> <27ABB9C8-6701-4F51-822B-56206C0FB14B@pixilla.com> <20090312232215.GI10906@darkart.com> <7239713A-E8B9-4365-B251-136266B8EADC@pixilla.com> <20090313164115.GJ10906@darkart.com> <81E70198-7707-4AC5-945F-D2FB23F4F90B@pixilla.com> <20090313173242.GK10906@darkart.com> <126D6A26-EF63-49D9-8B7F-A4381D8C28CD@pixilla.com> Message-ID: <20090313212302.GE1007@ninagal.withay.com> On Fri, Mar 13, 2009 at 02:10:22PM -0700, Bradley Giesbrecht said: > On Mar 13, 2009, at 10:32 AM, Eric Hall wrote: [...] >> Do you have MANPATH set? If so, man will not auto-add >> directories based on your PATH (at least that's what I understand >> it to do). > > I had been using MANPATH but to test I removed it from .profile, logged > out of my shell, opened a new shell and ran "manpath" and /opt/ > local/share/man was not in my man path. Tried "sudo manpath" and /opt/ > local/share/man was in my man path. Don't just remove the setting of MANPATH but actually unset it; put as the last line in .profile unset MANPATH then try. This makes man more dynamic by using your PATH to figure out where to find relevant man pages. Bryan > > A quick look shows /opt/local has root:admin and 755 for directories. > Would this prevent man from operating on /opt/local/share/man? > > Maybe because it stores formated results in catx or something? I really > don't know much about man. > > > //Brad From ryandesign at macports.org Fri Mar 13 14:43:01 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 13 Mar 2009 16:43:01 -0500 Subject: [48065] trunk/dports/games In-Reply-To: <20090313210617.0AE6E11DF3EC@beta.macosforge.org> References: <20090313210617.0AE6E11DF3EC@beta.macosforge.org> Message-ID: On Mar 13, 2009, at 16:06, raimue at macports.org wrote: > Added: trunk/dports/games/freedink/files/patch-src-paths.c.diff > =================================================================== > --- trunk/dports/games/freedink/files/patch-src- > paths.c.diff (rev 0) > +++ trunk/dports/games/freedink/files/patch-src-paths.c.diff > 2009-03-13 21:05:53 UTC (rev 48065) > @@ -0,0 +1,11 @@ > +--- src/paths.c 2009-03-12 23:23:52.000000000 +0100 > ++++ src/paths.c 2009-03-12 23:24:09.000000000 +0100 > +@@ -140,7 +140,7 @@ > + seem to be found of */ > + default3 = br_build_path(datadir, "dink"); > + default4 = "/usr/local/share/games/dink"; > +- default5 = "/usr/local/share/dink"; > ++ default5 = "/opt/local/share/dink"; > + default6 = "/usr/share/games/dink"; > + default7 = "/usr/share/dink"; > + lookup[3] = default3; This won't work if MacPorts is installed somewhere else. So you mustn't put "/opt/local" into your files. Instead, use a placeholder like "@PREFIX@" and then "reinplace s|@PREFIX@|${prefix}|g $ {worksrcpath}/src/paths.c" in the portfile. From raimue at macports.org Fri Mar 13 14:57:31 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 13 Mar 2009 22:57:31 +0100 Subject: [48065] trunk/dports/games In-Reply-To: References: <20090313210617.0AE6E11DF3EC@beta.macosforge.org> Message-ID: <49BAD6CB.8080905@macports.org> On 13.03.2009 22:43 Uhr, Ryan Schmidt wrote: > On Mar 13, 2009, at 16:06, raimue at macports.org wrote: > This won't work if MacPorts is installed somewhere else. So you > mustn't put "/opt/local" into your files. Instead, use a placeholder > like "@PREFIX@" and then "reinplace s|@PREFIX@|${prefix}|g $ > {worksrcpath}/src/paths.c" in the portfile. Ugh, sorry, didn't catch that. Thanks for watching. I applied a fix in r48069. Rainer From blair at orcaware.com Fri Mar 13 17:37:02 2009 From: blair at orcaware.com (Blair Zajac) Date: Fri, 13 Mar 2009 17:37:02 -0700 Subject: Moving X11 install into their own subdirectory Message-ID: <49BAFC2E.7040709@orcaware.com> Hello, I haven't followed closely the work on getting X11 into the MacPorts, but I was installing some new ports today and the xorg-libice port conflicts with an existing port, ice-cpp, on the libIce.dylib. Unfortunately, they have different capitalization, ice-cpp has libIce.dylib and xorg-libice has libICE.dylib. Given precedence of an existing port and following the Linux standard, it seems moving the xorg-* ports into $prefix/X11 or $prefix/X11R6 would be a good thing to do. Comments? Regards, Blair From jeremyhu at macports.org Fri Mar 13 18:27:48 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Fri, 13 Mar 2009 18:27:48 -0700 Subject: Moving X11 install into their own subdirectory In-Reply-To: <49BAFC2E.7040709@orcaware.com> References: <49BAFC2E.7040709@orcaware.com> Message-ID: <7DA5E02A-6F6F-4C8E-A733-A481C7FA0D91@macports.org> On Mar 13, 2009, at 17:37, Blair Zajac wrote: > Hello, > > I haven't followed closely the work on getting X11 into the > MacPorts, but I was installing some new ports today and the xorg- > libice port conflicts with an existing port, ice-cpp, on the > libIce.dylib. Unfortunately, they have different capitalization, > ice-cpp has libIce.dylib and xorg-libice has libICE.dylib. > > Given precedence of an existing port and following the Linux > standard, it seems moving the xorg-* ports into $prefix/X11 or > $prefix/X11R6 would be a good thing to do. 1) Use a case sensitive FS. 2) The Linux "standard" is actually placing these libs in ${prefix}. I don't think many distros keep around /usr/X11 anymore unless it's a symlink to /usr... As far as this problem goes... yes, it's a problem. No, I don't have a better solution that (1) above. From raimue at macports.org Fri Mar 13 20:01:34 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 14 Mar 2009 04:01:34 +0100 Subject: MacPorts 1.7.1 In-Reply-To: References: <465D826E-7631-41EC-958C-8478DCAD809E@macports.org> Message-ID: <49BB1E0E.5060309@macports.org> On 18.02.2009 19:47 Uhr, Perry Lee wrote: > On Feb 18, 2009, at 1:03 AM, Ryan Schmidt wrote: > >> There are probably also other changes on trunk that are not >> described in the ChangeLog. > > You may also want to merge in r46810 (it fixes a bug in wrapline). As > far as I can tell, it applies to the 1.7 branch as well. Confirmed and merged in r48074. Rainer From raimue at macports.org Fri Mar 13 22:33:59 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Sat, 14 Mar 2009 06:33:59 +0100 Subject: [48077] trunk/dports/games/netpanzer/Portfile In-Reply-To: <20090314040352.290C311E409E@beta.macosforge.org> References: <20090314040352.290C311E409E@beta.macosforge.org> Message-ID: <49BB41C7.6010602@macports.org> On 14.03.2009 5:03 Uhr, ryandesign at macports.org wrote: > --- trunk/dports/games/netpanzer/Portfile 2009-03-14 03:52:29 UTC (rev 48076) > +++ trunk/dports/games/netpanzer/Portfile 2009-03-14 04:03:51 UTC (rev 48077) > @@ -44,4 +44,4 @@ > > livecheck.check regex > livecheck.url ${homepage}download.html > -livecheck.regex ${name}-(\[0-9.\]+)\.tar\.bz2 > +livecheck.regex ${name}-(\[0-9.\]+)\\.tar\\.bz2 Thanks, didn't notice as '.' is of course also matching a literal dot and the livecheck worked before. But this is more correct. Rainer From raimue at macports.org Fri Mar 13 22:35:47 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Sat, 14 Mar 2009 06:35:47 +0100 Subject: [48083] trunk/base In-Reply-To: <20090314052952.7018A11E4CAE@beta.macosforge.org> References: <20090314052952.7018A11E4CAE@beta.macosforge.org> Message-ID: <49BB4233.3010302@macports.org> On 14.03.2009 6:29 Uhr, raimue at macports.org wrote: > Revision: 48083 > http://trac.macports.org/changeset/48083 > Author: raimue at macports.org > Date: 2009-03-13 22:29:50 -0700 (Fri, 13 Mar 2009) > Log Message: > ----------- > base/aclocal.m4, base/configure: > Do expansion on ~ when looking for the home directory of a user. > > Most ports expect applications_dir to be an absolute path starting with a > slash. If this is not the case, constructs like ${destroot}${applications_dir} > will fail (work/destroot~foo/). This copies files outside the destroot so they > will not get installed. > > Thanks to Kevin Reid (kpreid) for the report. > > Modified Paths: > -------------- > trunk/base/aclocal.m4 > trunk/base/configure > > Modified: trunk/base/aclocal.m4 > =================================================================== > --- trunk/base/aclocal.m4 2009-03-14 05:10:13 UTC (rev 48082) > +++ trunk/base/aclocal.m4 2009-03-14 05:29:50 UTC (rev 48083) > @@ -454,7 +454,7 @@ > if test "$DSTUSR" = "root" ; then > MPAPPLICATIONSDIR="/Applications/MacPorts" > else > - MPAPPLICATIONSDIR="~$DSTUSR/Applications/MacPorts" > + MPAPPLICATIONSDIR="$(eval echo ~$DSTUSR)/Applications/MacPorts" > fi > fi Is there a better way to do the expansion than spawning eval in a sub-shell? If not, I will also merge this to the 1.7.x branch. Rainer From ryandesign at macports.org Fri Mar 13 23:41:46 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 14 Mar 2009 01:41:46 -0500 Subject: Moving X11 install into their own subdirectory In-Reply-To: <7DA5E02A-6F6F-4C8E-A733-A481C7FA0D91@macports.org> References: <49BAFC2E.7040709@orcaware.com> <7DA5E02A-6F6F-4C8E-A733-A481C7FA0D91@macports.org> Message-ID: <30D08EE8-97EA-4FE3-BD10-D1831AB17446@macports.org> On Mar 13, 2009, at 20:27, Jeremy Huddleston wrote: > On Mar 13, 2009, at 17:37, Blair Zajac wrote: > >> I haven't followed closely the work on getting X11 into the >> MacPorts, but I was installing some new ports today and the xorg- >> libice port conflicts with an existing port, ice-cpp, on the >> libIce.dylib. Unfortunately, they have different capitalization, >> ice-cpp has libIce.dylib and xorg-libice has libICE.dylib. >> >> Given precedence of an existing port and following the Linux >> standard, it seems moving the xorg-* ports into $prefix/X11 or >> $prefix/X11R6 would be a good thing to do. > > 1) Use a case sensitive FS. > > 2) The Linux "standard" is actually placing these libs in $ > {prefix}. I don't think many distros keep around /usr/X11 anymore > unless it's a symlink to /usr... > > As far as this problem goes... yes, it's a problem. No, I don't > have a better solution that (1) above. The MacPorts project will not recommend users use a case-sensitive file system on Mac OS X. :-) Doing so is known to cause problems with other applications and is disruptive to the Macintosh user experience. As the two of you already know, there is a ticket on this issue but it doesn't say more than the above. http://trac.macports.org/ticket/17997 From kngspook at gmail.com Sat Mar 14 01:15:49 2009 From: kngspook at gmail.com (Neil) Date: Sat, 14 Mar 2009 01:15:49 -0700 Subject: Deprecating port list In-Reply-To: References: <49B916AD.7020203@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> <0B91728B-7A87-4F49-B170-C6EC3A499B41@macports.org> <12a697af0903130922w1ffbbb6at2780ae6e861f4443@mail.gmail.com> <8F97E751-850F-4E51-93D6-6258F9BF6C5F@pixilla.com> Message-ID: <77e4079b0903140115o4a3aa76fj722c1d049db9ac1d@mail.gmail.com> On Fri, Mar 13, 2009 at 10:46 AM, Bradley Giesbrecht wrote: > > On Mar 13, 2009, at 9:55 AM, Jeremy Lavergne wrote: > > bash-3.2# port installed >>> The following ports are currently installed: >>> apache2 @2.2.11_0+darwin_9 (active) >>> >>> bash-3.2# port -q installed >>> The following ports are currently installed: >>> apache2 @2.2.11_0+darwin_9 (active) >>> >>> I would like a means to print non-formated output without messages like >>> "The following ports are currently installed:". >>> >> >> In the mean time, you can just pipe it through grep: >> >> port installed | grep -v following >> > > Thanks, I've been using "sed '1d'". > > My comment is more of general comment for all the commands. I expected -q > to have an effect on output from port installed. > > //Brad > Why not send "The following ports are currently installed:" to stderr? -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimue at macports.org Sat Mar 14 07:20:45 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 14 Mar 2009 15:20:45 +0100 Subject: Deprecating port list In-Reply-To: <77e4079b0903140115o4a3aa76fj722c1d049db9ac1d@mail.gmail.com> References: <49B916AD.7020203@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> <0B91728B-7A87-4F49-B170-C6EC3A499B41@macports.org> <12a697af0903130922w1ffbbb6at2780ae6e861f4443@mail.gmail.com> <8F97E751-850F-4E51-93D6-6258F9BF6C5F@pixilla.com> <77e4079b0903140115o4a3aa76fj722c1d049db9ac1d@mail.gmail.com> Message-ID: <49BBBD3D.60608@macports.org> On 14.03.2009 9:15 Uhr, Neil wrote: > Why not send "The following ports are currently installed:" to stderr? Hm, stderr and stdout do not have to be synchron, I am not sure it is a good idea to mix them for this purpose. Recently I added a wrapper around isatty(3) which is already used in port. It decides if the output is a tty or a pipe/file. I will look into removing the header if the output is not a tty. Rainer From brad at pixilla.com Sat Mar 14 10:01:00 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sat, 14 Mar 2009 10:01:00 -0700 Subject: Deprecating port list In-Reply-To: <49BBBD3D.60608@macports.org> References: <49B916AD.7020203@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> <0B91728B-7A87-4F49-B170-C6EC3A499B41@macports.org> <12a697af0903130922w1ffbbb6at2780ae6e861f4443@mail.gmail.com> <8F97E751-850F-4E51-93D6-6258F9BF6C5F@pixilla.com> <77e4079b0903140115o4a3aa76fj722c1d049db9ac1d@mail.gmail.com> <49BBBD3D.60608@macports.org> Message-ID: <47ECCBA3-4C44-4686-9AB5-C35486CE201C@pixilla.com> On Mar 14, 2009, at 7:20 AM, Rainer M?ller wrote: > On 14.03.2009 9:15 Uhr, Neil wrote: >> Why not send "The following ports are currently installed:" to >> stderr? > > Hm, stderr and stdout do not have to be synchron, I am not sure it > is a > good idea to mix them for this purpose. > > Recently I added a wrapper around isatty(3) which is already used in > port. It decides if the output is a tty or a pipe/file. I will look > into > removing the header if the output is not a tty. > > Rainer Or not add the header if -q. //Brad From ryandesign at macports.org Sat Mar 14 12:06:30 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 14 Mar 2009 14:06:30 -0500 Subject: [48111] trunk/dports/science/gwyddion/Portfile In-Reply-To: <20090314181534.B0C5911F1272@beta.macosforge.org> References: <20090314181534.B0C5911F1272@beta.macosforge.org> Message-ID: On Mar 14, 2009, at 13:15, rowue at macports.org wrote: > +variant system_x11 { > + default_variants +system_x11 > +} What's the purpose of this? "default_variants +system_x11" means "cause the variant +system_x11 to be selected". So it seems to serve no purpose to do so inside the variant you're selecting... From jeremyhu at macports.org Sat Mar 14 13:29:17 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 14 Mar 2009 13:29:17 -0700 Subject: [48111] trunk/dports/science/gwyddion/Portfile In-Reply-To: References: <20090314181534.B0C5911F1272@beta.macosforge.org> Message-ID: <7E195CED-A3ED-4B02-A752-0ACF6CB66B2B@macports.org> Further, there should be no ports that use the system_x11 variant other than the xorg packages. There is no purpose for it outside of that context. On Mar 14, 2009, at 12:06, Ryan Schmidt wrote: > On Mar 14, 2009, at 13:15, rowue at macports.org wrote: > >> +variant system_x11 { >> + default_variants +system_x11 >> +} > > What's the purpose of this? > > "default_variants +system_x11" means "cause the variant +system_x11 > to be selected". So it seems to serve no purpose to do so inside the > variant you're selecting... > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From blair at orcaware.com Sat Mar 14 14:15:41 2009 From: blair at orcaware.com (Blair Zajac) Date: Sat, 14 Mar 2009 14:15:41 -0700 Subject: Moving X11 install into their own subdirectory In-Reply-To: <7DA5E02A-6F6F-4C8E-A733-A481C7FA0D91@macports.org> References: <49BAFC2E.7040709@orcaware.com> <7DA5E02A-6F6F-4C8E-A733-A481C7FA0D91@macports.org> Message-ID: <49BC1E7D.6020900@orcaware.com> Jeremy Huddleston wrote: > > On Mar 13, 2009, at 17:37, Blair Zajac wrote: > >> Hello, >> >> I haven't followed closely the work on getting X11 into the MacPorts, >> but I was installing some new ports today and the xorg-libice port >> conflicts with an existing port, ice-cpp, on the libIce.dylib. >> Unfortunately, they have different capitalization, ice-cpp has >> libIce.dylib and xorg-libice has libICE.dylib. >> >> Given precedence of an existing port and following the Linux standard, >> it seems moving the xorg-* ports into $prefix/X11 or $prefix/X11R6 >> would be a good thing to do. > > 1) Use a case sensitive FS. > > 2) The Linux "standard" is actually placing these libs in ${prefix}. I > don't think many distros keep around /usr/X11 anymore unless it's a > symlink to /usr... The three I have, Ubuntu Dapper Drake and Centos 4 and 5, has /usr/X11R6 and its subdirectories as normal directories, not symlinks. Blair From ryandesign at macports.org Sat Mar 14 16:41:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 14 Mar 2009 18:41:02 -0500 Subject: [48116] trunk/dports/science/gwyddion/Portfile In-Reply-To: <20090314203450.07AB411F4A26@beta.macosforge.org> References: <20090314203450.07AB411F4A26@beta.macosforge.org> Message-ID: <275877ED-4C3A-41C4-B8B0-9D2DCC1E775F@macports.org> On Mar 14, 2009, at 15:34, jeremyhu at macports.org wrote: > +platform darwin 8 { > + post-activate { > + if {[file exists ${x11prefix}/lib/pkgconfig/x11.pc]} { > + ui_msg "openGL support currently requires you to use MacPorts' > X11 server (xorg-server) rather than Apple's." > + } > + } > +} When would ${x11prefix}/lib/pkgconfig/x11.pc exist on Tiger? From jeremyhu at macports.org Sat Mar 14 17:19:46 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 14 Mar 2009 17:19:46 -0700 Subject: Moving X11 install into their own subdirectory In-Reply-To: <49BC1E7D.6020900@orcaware.com> References: <49BAFC2E.7040709@orcaware.com> <7DA5E02A-6F6F-4C8E-A733-A481C7FA0D91@macports.org> <49BC1E7D.6020900@orcaware.com> Message-ID: <2903A083-81ED-4B7F-9FC0-41077738128B@macports.org> On Mar 14, 2009, at 14:15, Blair Zajac wrote: > Jeremy Huddleston wrote: >> On Mar 13, 2009, at 17:37, Blair Zajac wrote: >>> Hello, >>> >>> I haven't followed closely the work on getting X11 into the >>> MacPorts, but I was installing some new ports today and the xorg- >>> libice port conflicts with an existing port, ice-cpp, on the >>> libIce.dylib. Unfortunately, they have different capitalization, >>> ice-cpp has libIce.dylib and xorg-libice has libICE.dylib. >>> >>> Given precedence of an existing port and following the Linux >>> standard, it seems moving the xorg-* ports into $prefix/X11 or >>> $prefix/X11R6 would be a good thing to do. >> 1) Use a case sensitive FS. >> 2) The Linux "standard" is actually placing these libs in $ >> {prefix}. I don't think many distros keep around /usr/X11 anymore >> unless it's a symlink to /usr... > > The three I have, Ubuntu Dapper Drake and Centos 4 and 5, has /usr/ > X11R6 and its subdirectories as normal directories, not symlinks. Well, CentOS is an enterprise distro and tends to lag behind. Your Ubuntu version is 2 major releases old. Fedora Core 10 has no /usr/ X11R6 present. Gentoo has not had a /usr/X11R6 directory for a few years now, but they still have the /usr/X11R6 -> /usr symlink. Additionally, http://en.wikipedia.org/wiki/X.Org_Server "The modular path (using GNU Autotools) is however the future direction of the X.Org server, and also saw the X11 binaries moving out of their own / usr/X11R6 subdirectory tree and into the global /usr tree on many Unix systems." Further, moving all of X11 into a subdirectory would require changes to base, massive changes throughout the tree, or both. It's not feasible. And if you want to play the "who was there first" game... X11R6 has been around since 1987. From jeremyhu at macports.org Sat Mar 14 17:21:33 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 14 Mar 2009 17:21:33 -0700 Subject: [48116] trunk/dports/science/gwyddion/Portfile In-Reply-To: <275877ED-4C3A-41C4-B8B0-9D2DCC1E775F@macports.org> References: <20090314203450.07AB411F4A26@beta.macosforge.org> <275877ED-4C3A-41C4-B8B0-9D2DCC1E775F@macports.org> Message-ID: Whoops... copy/pasted too fast. Fixed in svn. On Mar 14, 2009, at 16:41, Ryan Schmidt wrote: > > On Mar 14, 2009, at 15:34, jeremyhu at macports.org wrote: > >> +platform darwin 8 { >> + post-activate { >> + if {[file exists ${x11prefix}/lib/pkgconfig/x11.pc]} { >> + ui_msg "openGL support currently requires you to use MacPorts' >> X11 server (xorg-server) rather than Apple's." >> + } >> + } >> +} > > When would ${x11prefix}/lib/pkgconfig/x11.pc exist on Tiger? > From blair at orcaware.com Sat Mar 14 20:41:04 2009 From: blair at orcaware.com (Blair Zajac) Date: Sat, 14 Mar 2009 20:41:04 -0700 Subject: Moving X11 install into their own subdirectory In-Reply-To: <2903A083-81ED-4B7F-9FC0-41077738128B@macports.org> References: <49BAFC2E.7040709@orcaware.com> <7DA5E02A-6F6F-4C8E-A733-A481C7FA0D91@macports.org> <49BC1E7D.6020900@orcaware.com> <2903A083-81ED-4B7F-9FC0-41077738128B@macports.org> Message-ID: <49BC78D0.2020808@orcaware.com> Jeremy Huddleston wrote: > On Mar 14, 2009, at 14:15, Blair Zajac wrote: > > > Further, moving all of X11 into a subdirectory would require changes to > base, massive changes throughout the tree, or both. It's not feasible. Well, I think it's rude to tread on some another port without even an apology and requiring work on my part to fix something imposed on me. And you say that this is infeasible. What about the people who build apps against ice-cpp library and the changes that this require them to their build systems? You're pushing all this work on me and the people that use ice-cpp. MacPorts X11 isn't a required feature, but a nice to have, since ports can use Apple's X11. Additionally, it's hypocritical to say, it's OK for X11 to impact these other ports, even when the X11 ports are new, and not give ice-cpp the same weight. If somebody said, look, I'm sorry about this, we're going to do this in spite of ice-cpp, how can I help, that would be great. I realize that ZeroC gave a bad name to their shared library, but that's out of my hands. So now I need to figure out the best solution to resolve this and take time I don't want to spend on this issue. > And if you want to play the "who was there first" game... X11R6 has been > around since 1987. True, but not in this distribution. Blair From raimue at macports.org Sat Mar 14 20:43:36 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 15 Mar 2009 04:43:36 +0100 Subject: milestone 1.7.1 In-Reply-To: References: <35016D3E-8DC3-462F-95DE-1AA1F26F6005@lavergne.gotdns.org> <49B910C9.9090802@macports.org> <49B912E8.20308@macports.org> Message-ID: <49BC7968.80904@macports.org> On 12.03.2009 22:41 Uhr, Ryan Schmidt wrote: > We should still merge back from trunk those handful of small changes > that I mentioned in another thread some weeks ago. For reference: http://lists.macosforge.org/pipermail/macports-dev/2009-February/007440.html Proposed merges (reformatted): | We could merge in these additional small changes that are on trunk: | | - Add new "use_7z yes" port option to allow distfiles in 7z | format (#18521, ryandesign) | | - port lint no longer requires variable master_sites if the port | has no distfiles (#18479, ryandesign) | | - Upgrade will no longer accept ports that are not installed | (but it still installs new ports as dependencies if needed). | In particular, this means that "port upgrade all" will no | longer proceed to install every available port. (jmr in | r46052) | | - Add mkdtemp Tcl command to create temporary directories. | (#17181, perry) There were no real objections. Ryan, would you take care of merging them? Rainer From jeremyhu at macports.org Sun Mar 15 02:22:08 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 15 Mar 2009 02:22:08 -0700 Subject: Moving X11 install into their own subdirectory In-Reply-To: <49BC78D0.2020808@orcaware.com> References: <49BAFC2E.7040709@orcaware.com> <7DA5E02A-6F6F-4C8E-A733-A481C7FA0D91@macports.org> <49BC1E7D.6020900@orcaware.com> <2903A083-81ED-4B7F-9FC0-41077738128B@macports.org> <49BC78D0.2020808@orcaware.com> Message-ID: <5E04B33A-C349-41B6-AD76-D7B12FF5A5AE@macports.org> On Mar 14, 2009, at 20:41, Blair Zajac wrote: > Jeremy Huddleston wrote: >> On Mar 14, 2009, at 14:15, Blair Zajac wrote: >> Further, moving all of X11 into a subdirectory would require >> changes to base, massive changes throughout the tree, or both. >> It's not feasible. > > Well, I think it's rude to tread on some another port without even > an apology and requiring work on my part to fix something imposed on > me. I didn't "tread on some another (sic) port". libICE had been in MP for a long time (before I got here, so don't point at me) before this conflict was discovered. > And you say that this is infeasible. Yes. libICE has been around for 20 years! It is linked against by numerous ports and third party apps. It's unfortunate that this ice- cpp package chose an existing name for their library, but this is really a problem that upstream should've considered before releasing their package. > What about the people who build apps against ice-cpp library and the > changes that this require them to their build systems? Exactly, it's a symmetric problem. It is infeasible to move the X11 libs into a subdirectory for the same reason it is a problem for you to move ice-cpp... Unfortunately, libICE is much more widely used, so it's less intrusive to find a solution involving tweaking ice-cpp than it is to tweak libICE. > You're pushing all this work on me and the people that use ice-cpp. > MacPorts X11 isn't a required feature, but a nice to have, since > ports can use Apple's X11. Yes, and ice-cpp is not a required feature either. It's a symmetric argument. > Additionally, it's hypocritical to say, it's OK for X11 to impact > these other ports, even when the X11 ports are new, and not give ice- > cpp the same weight. I did not say "it's OK for X11 to impact these other ports". For one thing, I did not add the libICE package to MP. The modular lib was part of MP for almost a year before this conflict was discovered. Because ice-cpp users did not test out X11 in MacPorts, this was not discovered until a massive amount of work had gone into integrating the new X11 changes into MacPorts and pushing these changes to mainstream users. I had written emails to macports-dev on three separate occasions over a period of 6 weeks detailing stage by stage how I was going to change dports. I implemented the changes in stages as to have as little impact as possible. > If somebody said, look, I'm sorry about this, we're going to do this > in spite of ice-cpp, how can I help, that would be great. I realize > that ZeroC gave a bad name to their shared library, but that's out > of my hands. So now I need to figure out the best solution to > resolve this and take time I don't want to spend on this issue. Well, like I said, I have no idea how to solve this. It's a difficult problem with no easy solution. If I could help, I would... but I don't see an out. >> And if you want to play the "who was there first" game... X11R6 has >> been around since 1987. > > True, but not in this distribution. libICE was added in with XFree86 in r134 (2002-08-06). ice-cpp was added in r23806 (2007-04-09). libICE was added independent of XFree86 as xorg-libice in r34665 (2008-03-01) From mvfranz at gmail.com Sun Mar 15 06:07:43 2009 From: mvfranz at gmail.com (Michael Franz) Date: Sun, 15 Mar 2009 09:07:43 -0400 Subject: Moving X11 install into their own subdirectory In-Reply-To: <49BAFC2E.7040709@orcaware.com> References: <49BAFC2E.7040709@orcaware.com> Message-ID: Blair, What port did you installed that required xorg-libice? Michael On Fri, Mar 13, 2009 at 8:37 PM, Blair Zajac wrote: > Hello, > > I haven't followed closely the work on getting X11 into the MacPorts, but I > was installing some new ports today and the xorg-libice port conflicts with > an existing port, ice-cpp, on the libIce.dylib. Unfortunately, they have > different capitalization, ice-cpp has libIce.dylib and xorg-libice has > libICE.dylib. > > Given precedence of an existing port and following the Linux standard, it > seems moving the xorg-* ports into $prefix/X11 or $prefix/X11R6 would be a > good thing to do. > > Comments? > > Regards, > Blair > > _______________________________________________ > 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 cssdev at mac.com Sun Mar 15 09:09:36 2009 From: cssdev at mac.com (cssdev at mac.com) Date: Sun, 15 Mar 2009 12:09:36 -0400 Subject: ulimits for MacPorts on Panther Message-ID: <184DA3D4-492C-4C91-A184-69B04DC740BA@mac.com> Hello, Looking at a CMake bug [1], it seems like there might be differences in the limits defined for the MacPorts environment. This apparently causes a problem when building CMake. It apparently builds fine outside MacPorts, but not within it. I think that CMake needs a different limit than what's imposed by the MacPorts build environment. Could someone with Panther confirm whether there are any differences between the MacPorts and Panther environment limits? Thanks, Chris [1]: http://trac.macports.org/ticket/17333 From raimue at macports.org Sun Mar 15 10:30:00 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 15 Mar 2009 18:30:00 +0100 Subject: ulimits for MacPorts on Panther In-Reply-To: <184DA3D4-492C-4C91-A184-69B04DC740BA@mac.com> References: <184DA3D4-492C-4C91-A184-69B04DC740BA@mac.com> Message-ID: <49BD3B18.6030607@macports.org> On 15.03.2009 17:09 Uhr, cssdev at mac.com wrote: > Looking at a CMake bug [1], it seems like there might be differences > in the limits defined for the MacPorts environment. This apparently > causes a problem when building CMake. It apparently builds fine > outside MacPorts, but not within it. I think that CMake needs a > different limit than what's imposed by the MacPorts build environment. > Could someone with Panther confirm whether there are any differences > between the MacPorts and Panther environment limits? I don't own a Panther machine, but I had a look at the error message reported in the ticket. The compiler is trying to allocate 3609800964 bytes, that's around 3.4 *giga*bytes. I would suspect a compiler bug with gcc 3.x here. Ryan, when you tried compiling outside of MacPorts, did you enable the same CFLAGS? MacPorts applies -O2 to CFLAGS and CXXFLAGS by default, it could be that the bug is only experienced with optimization enabled. Try setting configure.optflags to an empty value. Rainer From brad at pixilla.com Sun Mar 15 13:28:34 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sun, 15 Mar 2009 13:28:34 -0700 Subject: env_helper Message-ID: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> I have modeled an env setup script after the one apple supplies at / usr/libexec/path_helper which is evaluated by /etc/profile. My idea is to add a line like this at the top of ones .profile file. eval `/opt/local/libexec/env_helper` I don't know if this list allows file attachments so if the tar file is not attached I will upload it somewhere and send another email with a link. If I should open a trac ticket someone tell me to and I will. I was thinking this might be a nice way to allow ports to modify the users env in a managed fashion. They can drop their env files in the proper place and they will be automatically added to the users env. Also, since the files would be registered to the port if the port is deactivated the files can be removed. I was thinking of making this as a port (env_helper or macports_env) that other ports could use or if people thought it useful adding it directly to macports. I started with just path vars and only bash at this point but looking at /usr/libexc/path_helper it shouldn't be difficult to add support for other shells. I'm simply naming the files the same as the env var and looping over the directory. //Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: env_helper.tar.gz Type: application/x-gzip Size: 1155 bytes Desc: not available URL: -------------- next part -------------- From brad at pixilla.com Sun Mar 15 14:26:47 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sun, 15 Mar 2009 14:26:47 -0700 Subject: env_helper In-Reply-To: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> Message-ID: <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> On Mar 15, 2009, at 1:28 PM, Bradley Giesbrecht wrote: > I have modeled an env setup script after the one apple supplies at / > usr/libexec/path_helper which is evaluated by /etc/profile. > > My idea is to add a line like this at the top of ones .profile file. > eval `/opt/local/libexec/env_helper` > > I don't know if this list allows file attachments so if the tar file > is not attached I will upload it somewhere and send another email > with a link. > If I should open a trac ticket someone tell me to and I will. > > I was thinking this might be a nice way to allow ports to modify the > users env in a managed fashion. They can drop their env files in the > proper place and they will be automatically added to the users env. > > Also, since the files would be registered to the port if the port is > deactivated the files can be removed. > > I was thinking of making this as a port (env_helper or macports_env) > that other ports could use or if people thought it useful adding it > directly to macports. > > I started with just path vars and only bash at this point but > looking at /usr/libexc/path_helper it shouldn't be difficult to add > support for other shells. > > I'm simply naming the files the same as the env var and looping over > the directory. > > > //Brad I modified /opt/local/libexec/env_helper to evaluate the paths so $ {PREFIX} can be used in the conf files. This would not NEED to be done because any installer could create the path properly but it does remove that necessary step. //Brad From brad at pixilla.com Sun Mar 15 15:25:38 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sun, 15 Mar 2009 15:25:38 -0700 Subject: env_helper In-Reply-To: <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> Message-ID: I'm thinking I like this. I just added paths for ${PREFIX}/apach2/bin and ${PREFIX}/lib/mysql5/ bin to /opt/local/etc/env_helper/paths/PATH/(apache2 & mysql5). So port apache2 and mysql5 could add /opt/local/etc/env_helper/paths/ PATH/apache2 and /opt/local/etc/env_helper/paths/PATH/mysql5 during install and with the one line added to .profile you pick up their bin dirs. I've done the same for MANPATH where I installed p5 man pages to /opt/ local/share/p5/man. The p5 module man pages show up first, then the port perl5.8 base modules and then the apple perl5.8 man pages. This can probably be done better but I do think this adds value with little cost. //Brad On Mar 15, 2009, at 2:26 PM, Bradley Giesbrecht wrote: > > On Mar 15, 2009, at 1:28 PM, Bradley Giesbrecht wrote: > >> I have modeled an env setup script after the one apple supplies at / >> usr/libexec/path_helper which is evaluated by /etc/profile. >> >> My idea is to add a line like this at the top of ones .profile file. >> eval `/opt/local/libexec/env_helper` >> >> I don't know if this list allows file attachments so if the tar >> file is not attached I will upload it somewhere and send another >> email with a link. >> If I should open a trac ticket someone tell me to and I will. >> >> I was thinking this might be a nice way to allow ports to modify >> the users env in a managed fashion. They can drop their env files >> in the proper place and they will be automatically added to the >> users env. >> >> Also, since the files would be registered to the port if the port >> is deactivated the files can be removed. >> >> I was thinking of making this as a port (env_helper or >> macports_env) that other ports could use or if people thought it >> useful adding it directly to macports. >> >> I started with just path vars and only bash at this point but >> looking at /usr/libexc/path_helper it shouldn't be difficult to add >> support for other shells. >> >> I'm simply naming the files the same as the env var and looping >> over the directory. >> >> >> //Brad > > I modified /opt/local/libexec/env_helper to evaluate the paths so $ > {PREFIX} can be used in the conf files. This would not NEED to be > done because any installer could create the path properly but it > does remove that necessary step. > > //Brad From jeremyhu at macports.org Sun Mar 15 19:21:27 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 15 Mar 2009 19:21:27 -0700 Subject: env_helper In-Reply-To: References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> Message-ID: <259C475B-8641-4423-A7BC-B069ADD6BCF9@macports.org> I think this is a bit too many files lying around. Why have separate directories/files for each environment variable. It seems cleaner to me to have: ${etcdir}/paths.d contain a set of files (one file per port). These files are newline-delimited in the form: ENVIRONMENT_VARIABLE=VALUE so you would have: ${etcdir}/paths.d/mysql contain: PATH=/opt/local/lib/mysql5/bin ${etcdir}/paths.d/perl5 contain: MANPATH=/opt/local/share/p5/man It would be nice to actually have this be backwards compatible with path_helper, so if ${etcdir}/paths.d/myapp contained: /opt/local/lib/some/bin it would default to assume an implicit PATH=. Similarly, it could support ${etcdir}/manpaths.d with an implicit MANPATH I thought about that last year, but I never got around to doing anything about it ;) On Mar 15, 2009, at 15:25, Bradley Giesbrecht wrote: > I'm thinking I like this. > > I just added paths for ${PREFIX}/apach2/bin and ${PREFIX}/lib/mysql5/ > bin to /opt/local/etc/env_helper/paths/PATH/(apache2 & mysql5). > > So port apache2 and mysql5 could add /opt/local/etc/env_helper/paths/ > PATH/apache2 and /opt/local/etc/env_helper/paths/PATH/mysql5 during > install and with the one line added to .profile you pick up their > bin dirs. > > I've done the same for MANPATH where I installed p5 man pages to / > opt/local/share/p5/man. The p5 module man pages show up first, then > the port perl5.8 base modules and then the apple perl5.8 man pages. > > This can probably be done better but I do think this adds value with > little cost. > > //Brad > > On Mar 15, 2009, at 2:26 PM, Bradley Giesbrecht wrote: > >> >> On Mar 15, 2009, at 1:28 PM, Bradley Giesbrecht wrote: >> >>> I have modeled an env setup script after the one apple supplies >>> at /usr/libexec/path_helper which is evaluated by /etc/profile. >>> >>> My idea is to add a line like this at the top of ones .profile file. >>> eval `/opt/local/libexec/env_helper` >>> >>> I don't know if this list allows file attachments so if the tar >>> file is not attached I will upload it somewhere and send another >>> email with a link. >>> If I should open a trac ticket someone tell me to and I will. >>> >>> I was thinking this might be a nice way to allow ports to modify >>> the users env in a managed fashion. They can drop their env files >>> in the proper place and they will be automatically added to the >>> users env. >>> >>> Also, since the files would be registered to the port if the port >>> is deactivated the files can be removed. >>> >>> I was thinking of making this as a port (env_helper or >>> macports_env) that other ports could use or if people thought it >>> useful adding it directly to macports. >>> >>> I started with just path vars and only bash at this point but >>> looking at /usr/libexc/path_helper it shouldn't be difficult to >>> add support for other shells. >>> >>> I'm simply naming the files the same as the env var and looping >>> over the directory. >>> >>> >>> //Brad >> >> I modified /opt/local/libexec/env_helper to evaluate the paths so $ >> {PREFIX} can be used in the conf files. This would not NEED to be >> done because any installer could create the path properly but it >> does remove that necessary step. >> >> //Brad > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From raimue at macports.org Sun Mar 15 22:17:38 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Mon, 16 Mar 2009 06:17:38 +0100 Subject: perl5.8 fixup In-Reply-To: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> Message-ID: <49BDE0F2.6060701@macports.org> Hi Bradley and Eric, (and all others still following this thread), I invested some time to find out how other packagement systems I use deal with this issue. I checked mostly with the Getopt::Long and CGI modules. The versions below are what I have currently installed, YMMV. == Gentoo == The modules coming with dev-lang/perl are installed to /usr/lib/perl5/5.8.8/, man pages are still shipped with a .3pm suffix in the usual location. The modules also exist as extra packages, these get installed into /usr/lib/perl5/vendor_perl/5.8.8/. The man pages which come with these modules are ignored and not installed at all. perldoc is recommended instead. The environment has been altered: MANPATH gets exported to search some additional directories, but nothing relevant to perl. There is also no PERL5LIB in the environment. $ perl -le 'print join("\n", @INC);' /etc/perl /usr/lib/perl5/vendor_perl/5.8.8/i686-linux /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl/5.8.8/i686-linux /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/5.8.8/i686-linux /usr/lib/perl5/5.8.8 /usr/local/lib/site_perl . == Debian (lenny) == The modules are splitted over perl, perl-base and perl-modules. They are installed to /usr/lib/perl/5.10.0/ or /usr/share/perl/5.10.0/. I don't know or see the rules for this split. Man pages are part of perl-doc which are installed to the usual location with a .3perl suffix. Additional modules (lib*-perl) are installed to /usr/share/perl5. Man pages here get a .3pm suffix in the usual location. For the man pages, the man configuration was altered to search the 3pm section before 3perl, so you get the man pages from the extra packages first. The environment has not been altered (no MANPATH or PERL5LIB). $ perl -le 'print join("\n", @INC);' /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl . $ man -aw CGI /usr/share/man/man3/CGI.3pm.gz /usr/share/man/man3/CGI.3perl.gz I hope this is useful and interesting for you and may help to find a solution for MacPorts. If you are interested in further informations about these systems? I can provide them. Rainer From brad at pixilla.com Mon Mar 16 08:55:22 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 16 Mar 2009 08:55:22 -0700 Subject: env_helper In-Reply-To: <259C475B-8641-4423-A7BC-B069ADD6BCF9@macports.org> References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> <259C475B-8641-4423-A7BC-B069ADD6BCF9@macports.org> Message-ID: <1BCF2666-817F-4D56-B7CE-26DE3D97D903@pixilla.com> On Mar 15, 2009, at 7:21 PM, Jeremy Huddleston wrote: > I think this is a bit too many files lying around. I really don't understand what the implied problem is here. Can you explain? I simply took the path_helper approach and modified the script to figure out the var name based on the file name so I would have to modify the core script if lets say perl5 wanted to add PERL5LIB. > Why have separate directories/files for each environment variable. That's the way path_helper does it. If it ends up being a port then this port could right the initial paths but other ports would need to write their own vars like mysql wouldn't own the file. If this was built into macports then macports could manage it and have some new commands for Portfiles to write user env vars. As I think I mentioned, this is only for paths right now. I have this as env_helper/paths because I'm looping and concatenating with ":" as a separator. Concatenating with ":" wouldn't be appropriate for other vars. I planned on a generic ENVIRONMENT_VARIABLE=VALUE under env_helper/vars > It seems cleaner to me to have: > > ${etcdir}/paths.d contain a set of files (one file per port). These > files are newline-delimited in the form: > ENVIRONMENT_VARIABLE=VALUE > > so you would have: > > ${etcdir}/paths.d/mysql contain: > PATH=/opt/local/lib/mysql5/bin > > ${etcdir}/paths.d/perl5 contain: > MANPATH=/opt/local/share/p5/man > > It would be nice to actually have this be backwards compatible with > path_helper, so if ${etcdir}/paths.d/myapp contained: > /opt/local/lib/some/bin That's what my script does now. paths.d is renamed PATH.d but that's the only diff. The files in PATH.d can be written exactly like path_helper files or they CAN use ${PREFIX} so the ports would use the system could have pre-written support files that would just be copied in place. So you would parse the file into left and right side values and add them to the beginning of the current env var? echo $PATH /sbin:/bin becomes /opt/local/lib/mysql5/bin/sbin:/bin This is obviously doable but it's more work then I wanted to put into it before I knew whether or not there is even an audience. > it would default to assume an implicit PATH=. Similarly, it could > support ${etcdir}/manpaths.d with an implicit MANPATH > > I thought about that last year, but I never got around to doing > anything about it ;) If you or someone wants to contribute parsing left and right of equal into vars go ahead and I'll support that. The thing is, when you have ENVIRONMENT_VARIABLE=VALUE how are you going to know whether or not you should prepend current var values with the new value and a path separator. I think your script wound have to be smart enough to know what to do with names. By having a path TYPE var we can drop anything in this dir and treat it the same knowing nothing about the var name. I don't need to know what PERL5LIB is used for, it's in the paths dir, I'm going to concat with sep. > On Mar 15, 2009, at 15:25, Bradley Giesbrecht wrote: > >> I'm thinking I like this. >> >> I just added paths for ${PREFIX}/apach2/bin and ${PREFIX}/lib/ >> mysql5/bin to /opt/local/etc/env_helper/paths/PATH/(apache2 & >> mysql5). >> >> So port apache2 and mysql5 could add /opt/local/etc/env_helper/ >> paths/PATH/apache2 and /opt/local/etc/env_helper/paths/PATH/mysql5 >> during install and with the one line added to .profile you pick up >> their bin dirs. >> >> I've done the same for MANPATH where I installed p5 man pages to / >> opt/local/share/p5/man. The p5 module man pages show up first, then >> the port perl5.8 base modules and then the apple perl5.8 man pages. >> >> This can probably be done better but I do think this adds value >> with little cost. >> >> //Brad >> >> On Mar 15, 2009, at 2:26 PM, Bradley Giesbrecht wrote: >> >>> >>> On Mar 15, 2009, at 1:28 PM, Bradley Giesbrecht wrote: >>> >>>> I have modeled an env setup script after the one apple supplies >>>> at /usr/libexec/path_helper which is evaluated by /etc/profile. >>>> >>>> My idea is to add a line like this at the top of ones .profile >>>> file. >>>> eval `/opt/local/libexec/env_helper` >>>> >>>> I don't know if this list allows file attachments so if the tar >>>> file is not attached I will upload it somewhere and send another >>>> email with a link. >>>> If I should open a trac ticket someone tell me to and I will. >>>> >>>> I was thinking this might be a nice way to allow ports to modify >>>> the users env in a managed fashion. They can drop their env files >>>> in the proper place and they will be automatically added to the >>>> users env. >>>> >>>> Also, since the files would be registered to the port if the port >>>> is deactivated the files can be removed. >>>> >>>> I was thinking of making this as a port (env_helper or >>>> macports_env) that other ports could use or if people thought it >>>> useful adding it directly to macports. >>>> >>>> I started with just path vars and only bash at this point but >>>> looking at /usr/libexc/path_helper it shouldn't be difficult to >>>> add support for other shells. >>>> >>>> I'm simply naming the files the same as the env var and looping >>>> over the directory. >>>> >>>> >>>> //Brad >>> >>> I modified /opt/local/libexec/env_helper to evaluate the paths so $ >>> {PREFIX} can be used in the conf files. This would not NEED to be >>> done because any installer could create the path properly but it >>> does remove that necessary step. >>> >>> //Brad >> >> _______________________________________________ >> 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 Mar 16 09:33:18 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 16 Mar 2009 09:33:18 -0700 Subject: perl5.8 fixup In-Reply-To: <49BDE0F2.6060701@macports.org> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <49BDE0F2.6060701@macports.org> Message-ID: On Mar 15, 2009, at 10:17 PM, Rainer M?ller wrote: > Hi Bradley and Eric, > (and all others still following this thread), > > I invested some time to find out how other packagement systems I use > deal with this issue. I checked mostly with the Getopt::Long and CGI > modules. The versions below are what I have currently installed, YMMV. Thank you Rainer. > == Gentoo == > > The modules coming with dev-lang/perl are installed to > /usr/lib/perl5/5.8.8/, man pages are still shipped with a .3pm > suffix in > the usual location. > > The modules also exist as extra packages, these get installed into > /usr/lib/perl5/vendor_perl/5.8.8/. The man pages which come with these > modules are ignored and not installed at all. perldoc is recommended > instead. This could be good. Just not have perl5.8 install man pages. If perl users don't use them why waste effort. A perl user to me is someone who writes code in perl. That's not me. I just use programs written in perl as most of us do at some point. Out of principle I've been doing my best to find a solution to -f p5's that some perl5 user down the road will be happy with. I'm not a perl user and don't personally care. > The environment has been altered: MANPATH gets exported to search some > additional directories, but nothing relevant to perl. There is also no > PERL5LIB in the environment. > > $ perl -le 'print join("\n", @INC);' > /etc/perl > /usr/lib/perl5/vendor_perl/5.8.8/i686-linux > /usr/lib/perl5/vendor_perl/5.8.8 > /usr/lib/perl5/vendor_perl > /usr/lib/perl5/site_perl/5.8.8/i686-linux > /usr/lib/perl5/site_perl/5.8.8 > /usr/lib/perl5/site_perl > /usr/lib/perl5/5.8.8/i686-linux > /usr/lib/perl5/5.8.8 > /usr/local/lib/site_perl > . > > > == Debian (lenny) == > > The modules are splitted over perl, perl-base and perl-modules. They > are > installed to /usr/lib/perl/5.10.0/ or /usr/share/perl/5.10.0/. I don't > know or see the rules for this split. > > Man pages are part of perl-doc which are installed to the usual > location > with a .3perl suffix. > > Additional modules (lib*-perl) are installed to /usr/share/perl5. Man > pages here get a .3pm suffix in the usual location. > > For the man pages, the man configuration was altered to search the 3pm > section before 3perl, so you get the man pages from the extra packages > first. > > The environment has not been altered (no MANPATH or PERL5LIB). > > $ perl -le 'print join("\n", @INC);' > /etc/perl > /usr/local/lib/perl/5.10.0 > /usr/local/share/perl/5.10.0 > /usr/lib/perl5 > /usr/share/perl5 > /usr/lib/perl/5.10 > /usr/share/perl/5.10 > /usr/local/lib/site_perl > . > > $ man -aw CGI > /usr/share/man/man3/CGI.3pm.gz > /usr/share/man/man3/CGI.3perl.gz I was very interested in having the per5.8 rename it's man extensions to something that would be found after p5 module. I couldn't find where the Configure script allowed for this although they do make allowances for having man pages for man1, site_man1 and vendor_man1. > I hope this is useful and interesting for you and may help to find a > solution for MacPorts. If you are interested in further informations > about these systems? I can provide them. Thanks for the research Rainer. To me it looks like perl users don't really use perl man pages. Makes sense to me that perl would have better resources then man pages for documentation. I'd say the patch that has been submitted is a very good solution in that it's simple and backward compatible as far as I can tell. I think we should move forward with the submited patch. http://trac.macports.org/attachment/ticket/12950/Portfile.20090310.1655.patch Sound good? Ok, execute :) Engage. Who is ricci? Do it! Count votes. +1 > //Brad From jeremyhu at macports.org Mon Mar 16 10:45:42 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Mon, 16 Mar 2009 10:45:42 -0700 Subject: env_helper In-Reply-To: <1BCF2666-817F-4D56-B7CE-26DE3D97D903@pixilla.com> References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> <259C475B-8641-4423-A7BC-B069ADD6BCF9@macports.org> <1BCF2666-817F-4D56-B7CE-26DE3D97D903@pixilla.com> Message-ID: <286FA51E-72CA-4D47-BB9C-F8F7531B660D@macports.org> On Mar 16, 2009, at 08:55, Bradley Giesbrecht wrote: > On Mar 15, 2009, at 7:21 PM, Jeremy Huddleston wrote: > >> I think this is a bit too many files lying around. > > I really don't understand what the implied problem is here. Can you > explain? Clutter is bad. It's better to have everything in one file if possible. This way if you have one port that wants to set PATH, MANPATH, C_INCLUDE_PATH, OBJC_INCLUDE_PATH, PKG_CONFIG_PATH, ... it just needs to create ONE file rather than one file per variable >> Why have separate directories/files for each environment variable. > > That's the way path_helper does it. Yes, and that is a problem. It doesn't scale well. >> It seems cleaner to me to have: >> >> ${etcdir}/paths.d contain a set of files (one file per port). >> These files are newline-delimited in the form: >> ENVIRONMENT_VARIABLE=VALUE >> >> so you would have: >> >> ${etcdir}/paths.d/mysql contain: >> PATH=/opt/local/lib/mysql5/bin >> >> ${etcdir}/paths.d/perl5 contain: >> MANPATH=/opt/local/share/p5/man >> >> It would be nice to actually have this be backwards compatible with >> path_helper, so if ${etcdir}/paths.d/myapp contained: >> /opt/local/lib/some/bin > That's what my script does now. paths.d is renamed PATH.d but > that's the only diff. The files in PATH.d can be written exactly > like path_helper files or they CAN use ${PREFIX} so the ports would > use the system could have pre-written support files that would just > be copied in place. That's great, but that's only the backwards compatibility that I mentioned, not the main idea. You said you have separate files per port per variable: /opt/local/etc/env_helper/paths// I'm saying we should have one file per port: /opt/local/etc/paths.d/ > So you would parse the file into left and right side values and add > them to the beginning of the current env var? > echo $PATH > /sbin:/bin > becomes > /opt/local/lib/mysql5/bin/sbin:/bin I'm guessing you meant: /opt/local/lib/mysql5/bin:/sbin:/bin > This is obviously doable but it's more work then I wanted to put > into it before I knew whether or not there is even an audience. I don't think it's any more work than what you currently proposed, and yes, there's certainly an audience. I wanted to do this last year, but I never got around to it. >> it would default to assume an implicit PATH=. Similarly, it could >> support ${etcdir}/manpaths.d with an implicit MANPATH >> >> I thought about that last year, but I never got around to doing >> anything about it ;) > > If you or someone wants to contribute parsing left and right of > equal into vars go ahead and I'll support that. > > The thing is, when you have ENVIRONMENT_VARIABLE=VALUE how are you > going to know whether or not you should prepend current var values > with the new value and a path separator. The same way you know now whether or not to prepend the current values with the new value and a path separator. I don't understand the confusion. MANPATH=${PARSED_VALUE}${MANPATH+:${MANPATH}} > I think your script wound have to be smart enough to know what to do > with names. I'm not sure what you mean by that. > By having a path TYPE var we can drop anything in this dir and treat > it the same knowing nothing about the var name. And by having a line of the form "TYPE=VALUE", we know the exact same information. > I don't need to know what PERL5LIB is used for, it's in the paths > dir, I'm going to concat with sep. You don't need to know what PERL5LIB is used for any more in the scenario that I proposed. The scenarios are bijective, so there's nothing different in terms of expressibility or capability. It's just a matter of organization. Example (yes, this uses eval... no, I didn't feel like finding another way): simple_parse() { local LINE VALUE VARIABLE while read LINE ; do VARIABLE=${LINE%%=*} VALUE=${LINE#*=} eval ${VARIABLE}=${VALUE}${!VARIABLE+:${!VARIABLE}} done < ${1} } ~ $ cat test MYVAR=1234 MYVAR2=4567:3223 ~ $ cat test2 MYVAR=432 MYVAR2=467:33 ~ $ simple_parse test ~ $ echo $MYVAR 1234 ~ $ echo $MYVAR2 4567:3223 ~ $ simple_parse test2 ~ $ echo $MYVAR 432:1234 ~ $ echo $MYVAR2 467:33:4567:3223 From raimue at macports.org Mon Mar 16 10:45:43 2009 From: raimue at macports.org (=?windows-1252?Q?Rainer_M=FCller?=) Date: Mon, 16 Mar 2009 18:45:43 +0100 Subject: perl5.8 fixup In-Reply-To: References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <49BDE0F2.6060701@macports.org> Message-ID: <49BE9047.8090806@macports.org> On 2009-03-16 17:33, Bradley Giesbrecht wrote: > I was very interested in having the per5.8 rename it's man extensions > to something that would be found after p5 module. > I couldn't find where the Configure script allowed for this although > they do make allowances for having man pages for man1, site_man1 and > vendor_man1. In perl5, we could use: ./Configure ... -man1ext=3perl -man3ext=3perl p5-* ports are already using .3pm for their man pages as far as I can see, so no conflicts any more. I just tried this approach manually and it seems to get at least 3pm before 3perl. $ man -w /opt/local/share/man:/usr/share/man:/usr/local/share/man:/usr/X11/share/man $ man -aw CGI /opt/local/share/man/man3/CGI.3pm.gz /opt/local/share/man/man3/CGI.3perl.gz /opt/local/share/man/man3/CGI.3.gz /usr/share/man/man3/CGI.3pm.gz /opt/local/share/man/man3/CGI.3pm.gz /opt/local/share/man/man3/CGI.3perl.gz /usr/share/man/man3/CGI.3pm.gz So it kind of works. But the 3perl man page is inaccessible (except specifying the full path) as there is only 3 or 3p in MANSECT, which seems to consider these man pages to be equal. Not sure which rules apply for the order here. $ man -aw 3pm CGI /opt/local/share/man/man3/CGI.3pm.gz /usr/share/man/man3/CGI.3pm.gz $ man -aw 3perl CGI No manual entry for 3perl /opt/local/share/man/man3/CGI.3pm.gz /opt/local/share/man/man3/CGI.3perl.gz /opt/local/share/man/man3/CGI.3.gz /usr/share/man/man3/CGI.3pm.gz /opt/local/share/man/man3/CGI.3pm.gz /opt/local/share/man/man3/CGI.3perl.gz /usr/share/man/man3/CGI.3pm.gz Adding 3pm and 3perl to MANSECT could resolve this issue. $ export MANSECT=1:1p:8:2:3:3p:3pm:3perl:4:5:6:7:9:0p:tcl:n:l:p:o $ man -aw 3pm CGI /opt/local/share/man/man3/CGI.3pm.gz /usr/share/man/man3/CGI.3pm.gz $ man -aw 3perl CGI /opt/local/share/man/man3/CGI.3perl.gz There does not seem to be a solution for this without modifying MANSECT. But at least we do not have conflicting files any more. > I think we should move forward with the submited patch. > http://trac.macports.org/attachment/ticket/12950/Portfile.20090310.1655.patch On other system I use man1p or man3p is usually reserved for POSIX man pages. I see another problem here, the man pages would be totally inaccessible in man3p. At least in my limited tests, it is not searched at all. $ ls /opt/local/share/man/man3p/CGI.3pm.gz /opt/local/share/man/man3p/CGI.3pm.gz $ man -aw CGI /opt/local/share/man/man3/CGI.3pm.gz /opt/local/share/man/man3/CGI.3perl.gz /opt/local/share/man/man3/CGI.3.gz /usr/share/man/man3/CGI.3pm.gz /opt/local/share/man/man3/CGI.3pm.gz /opt/local/share/man/man3/CGI.3perl.gz /usr/share/man/man3/CGI.3pm.gz $ man -aw CGI |grep man3p $ Rainer From raimue at macports.org Mon Mar 16 11:17:44 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 16 Mar 2009 19:17:44 +0100 Subject: env_helper In-Reply-To: References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> Message-ID: <49BE97C8.4060800@macports.org> On 2009-03-15 23:25, Bradley Giesbrecht wrote: > I'm thinking I like this. > > I just added paths for ${PREFIX}/apach2/bin and ${PREFIX}/lib/mysql5/ > bin to /opt/local/etc/env_helper/paths/PATH/(apache2 & mysql5). Okay, so you expect this to be added to PATH. At the front? At the end? In which order? How will it now it needs to do concat at all and not replace? (Thinking of possible more general settings). How will it know to concat using ":" and not spaces? For apache2, this is just the old lame reason that nobody fixed the layout yet to be inside $prefix :-) mysql5 does not put the files into $prefix/bin because it conflicts with mysql4. If now both ports add the alternative dir to PATH this lends to confusion and breakage. For example, you installed mysql4 which has added the libdir to PATH this way. Typing "mysql" is actually mysql4. Now some port also pulls in mysql5 which you do not recognize at all and suddenly "mysql" is mysql5 because for some reason the PATH ended up in this order. By the way, can anybody think of other ports we did not talk about yet for which something like this could be useful? For example, I can think of bash-completion. I concur with Jeremy that a equal sign separated format would be the better choice for this, for clarity and maintenance, one file per port is enough. What I would like to see is a way to choose which items are actually added to my environment, because I still want to have control. I think the easiest would be to use symlinks. I have a layout in mind similar to what is used for init-scripts on most systems. To address the issues mentioned above and support a little bit more we would have to split it into env and profile: ${etcdir}/env-avail.d/: apache2 mysql5 ${etcdir}/env.d/: apache2 -> ../env-avail.d/apache2 mysql5 -> ../env-avail.d/mysql5 ${etcdir}/profile-avail.d/: bash-completion trac-tools ${etcdir}/profile.d/: trac-tools -> ../profile-avail.d/trac-tools (Think of trac-tools making [1] available, as I can't think of another existing port right now). env.d is meant to contain files in the equal sign separated format which are concatenated. Rules for concatenation are The order has yet to be defined (possible using 00foo through 99bar in the symlinks?). profile.d is meant to contain arbitrary shell scripts registering aliases/functions etc. And then we would have a `port env` command which operates on these dirs and files as follows: port env --enable bash-completion port env --disable bash-completion Creates/removes a symlink in profile.d pointing to profile-avail.d port env --update Generates or updates ${etcdir}/profile based on the current symlink layout, which is then used by `port env` as traversing all the files each time a shell is spawned is probably a bit slow. Could also generate ${etcdir}/profile.csh or similar. Needs to be run after --enable/--disable or port installes/upgrades to apply changes. Ideally port would check for file modification time of ${etcdir}/*.d/ after activation and recommend to run env-update if necessary. A user would only need to add this line to his .profile to load MacPorts: [ -f /opt/local/etc/profile ] && source /opt/local/etc/profile Still reading? Comments? ;-) > [...] > This can probably be done better but I do think this adds value with > little cost. This will definitely be useful, especially as it reduces the need of lines to be added to the profile. I started something different for this earlier with $prefix/share/macports/setupenv.bash in which nobody seemed to be interested (e.g. similar scripts for tcsh/zsh). But this could be incorporated into the new ${etcdir}/profile. Rainer [1] http://trac.macports.org/wiki/CommittersTipsAndTricks#ApplypatchesdirectlyfromTracURL From brad at pixilla.com Mon Mar 16 15:07:19 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 16 Mar 2009 15:07:19 -0700 Subject: perl5.8 fixup In-Reply-To: <49BE9047.8090806@macports.org> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <49BDE0F2.6060701@macports.org> <49BE9047.8090806@macports.org> Message-ID: <8E9161D6-7F54-4BAE-96EF-B1A860CC2CF5@pixilla.com> On Mar 16, 2009, at 10:45 AM, Rainer M?ller wrote: > On 2009-03-16 17:33, Bradley Giesbrecht wrote: >> I was very interested in having the per5.8 rename it's man extensions >> to something that would be found after p5 module. >> I couldn't find where the Configure script allowed for this although >> they do make allowances for having man pages for man1, site_man1 and >> vendor_man1. > > In perl5, we could use: > ./Configure ... -man1ext=3perl -man3ext=3perl This only changes the dot extension, right? I tried this earlier using ./Configure ... -man1ext=1perl5.8 -man3ext=3perl5.8 and when building p5 modules afterward I thought it also used 3perl5.8 for the module man extension. I'm checking this again. Yep, the p5's use the man1 and man3 extentions that perl5 was configured with unless p5-CGI is behaving different then other p5 ports. bash-3.2# port install p5-cgi ---> Fetching p5-cgi ---> Verifying checksum(s) for p5-cgi ---> Extracting p5-cgi ---> Configuring p5-cgi ---> Building p5-cgi ---> Staging p5-cgi into destroot ---> Installing p5-cgi @3.42_0 ---> Activating p5-cgi @3.42_0 Error: Target org.macports.activate returned: Image error: /opt/local/ share/man/man3/CGI.3perl.gz is being used by the active perl5.8 port. Please deactivate this port first, or use the -f flag to force the activation. Error: Status 1 encountered during processing. I hunted all over the web to find how to Configure perl5 with man1ext, man3ext, siteman1ext, siteman3ext, vendorman1ext and vendorman3ext but that doesn't seem an option. Configure --help doesn't mention it either. What about having the perl5.8 port move all it's man pages after pre distroot or something so we can use ./Configure ... -man1ext=1perl5.8 -man3ext=3perl5.8 and have the Portfile move them from man/man3/CGI.3pm to man/man3/CGI. 3perl5.8 as an example? The name could be shortened but I'm not sure if people will try to have perl5.10 or something else installed and active alongside perl5.8 some day. Looking at the Makefile for p5-cgi we could patch: MAN1EXT = 1perl MAN3EXT = 3perl to MAN1EXT = 1pm MAN3EXT = 3pm but who wants to change all those modules. No one. This seems to be working on my system. Does this look like an acceptable solution to anyone? configure.args \ -des \ -D prefix='${prefix}' \ -D scriptdir='${prefix}/bin' \ -D cppflags="\${CPPFLAGS}" \ -D ldflags="\${LDFLAGS}" \ -D siteprefix='${prefix}' \ -D vendorprefix='${prefix}' \ -D man1ext='1p' \ -D man3ext='3p' \ -D cc=\${CC} \ -D ld=\${CC} \ -D man1dir='${prefix}/share/man/man1' \ -D man3dir='${prefix}/share/man/man3' \ -D siteman1dir='${prefix}/share/man/man1' \ -D siteman3dir='${prefix}/share/man/man3' \ -D vendorman1dir='${prefix}/share/man/man1' \ -D vendorman3dir='${prefix}/share/man/man3' # Move perl5.8 installed man pages out of the way of port p5 modules post-configure { reinplace "s|^man1ext='1p'|man1ext='1p5.8'|" ${worksrcpath}/config.sh reinplace "s|^man3ext='3p'|man3ext='3p5.8'|" ${worksrcpath}/config.sh } > p5-* ports are already using .3pm for their man pages as far as I can > see, so no conflicts any more. I just tried this approach manually and > it seems to get at least 3pm before 3perl. > > $ man -w > /opt/local/share/man:/usr/share/man:/usr/local/share/man:/usr/X11/ > share/man > $ man -aw CGI > /opt/local/share/man/man3/CGI.3pm.gz > /opt/local/share/man/man3/CGI.3perl.gz > /opt/local/share/man/man3/CGI.3.gz > /usr/share/man/man3/CGI.3pm.gz > /opt/local/share/man/man3/CGI.3pm.gz > /opt/local/share/man/man3/CGI.3perl.gz > /usr/share/man/man3/CGI.3pm.gz > > So it kind of works. But the 3perl man page is inaccessible (except > specifying the full path) as there is only 3 or 3p in MANSECT, which > seems to consider these man pages to be equal. Not sure which rules > apply for the order here. I thought the MANSECT refered to the dirnames. Basically man/ man[MANSECT]/. I guess I'm wrong. //Brad From mcalhoun at macports.org Mon Mar 16 15:46:22 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Mon, 16 Mar 2009 22:46:22 +0000 (UTC) Subject: KDE and qt4-mac Message-ID: I would like to upgrade qt4-mac to version 4.5.0 (making it the same as qt4-mac-devel). It was indicated in another thread that this might not be entirely compatible with KDE (http://thread.gmane.org/gmane.os.apple.macports.devel/7504). I did not want to break all of KDE without some warning. If KDE and Qt 4.5 do not work well together, perhaps we can create a qt4-kde port which stays at version 4.4. Because qt4-mac and qt4-x11 are careful not to conflict, it should be straightforward to create yet another Qt distribution. Version 4.5 allows 64-bit universal builds, which to me is a compelling reason to upgrade. -Marcus From ryandesign at macports.org Mon Mar 16 15:55:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 16 Mar 2009 17:55:03 -0500 Subject: KDE and qt4-mac In-Reply-To: References: Message-ID: On Mar 16, 2009, at 17:46, Marcus Calhoun-Lopez wrote: > I would like to upgrade qt4-mac to version 4.5.0 > (making it the same as qt4-mac-devel). That sounds like a good idea to me. > It was indicated in another thread that this might not be entirely > compatible with KDE > (http://thread.gmane.org/gmane.os.apple.macports.devel/7504). > I did not want to break all of KDE without some warning. > > If KDE and Qt 4.5 do not work well together, perhaps we can create a > qt4-kde port which stays at version 4.4. I agree that's the right way to continue to make Qt 4.4 available, if necessary. I propose the port be called qt44-mac. > Because qt4-mac and qt4-x11 are careful not to conflict, it should be > straightforward to create yet another Qt distribution. > > Version 4.5 allows 64-bit universal builds, > which to me is a compelling reason to upgrade. From mcalhoun at macports.org Mon Mar 16 15:59:39 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Mon, 16 Mar 2009 22:59:39 +0000 (UTC) Subject: KDE and qt4-mac References: Message-ID: Ryan Schmidt writes: > > I propose the port be called qt44-mac. > I do not feel strongly about this, but I thought qt4-kde might be better since there was an indication in the previous thread (http://thread.gmane.org/gmane.os.apple.macports.devel/7504) that there were some KDE specific changes that could be made. -Marcus From brad at pixilla.com Mon Mar 16 16:10:32 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 16 Mar 2009 16:10:32 -0700 Subject: env_helper In-Reply-To: <49BE97C8.4060800@macports.org> References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> <49BE97C8.4060800@macports.org> Message-ID: <9C4208C1-0A11-41B8-973F-A1C2B4A1CE98@pixilla.com> On Mar 16, 2009, at 11:17 AM, Rainer M?ller wrote: > On 2009-03-15 23:25, Bradley Giesbrecht wrote: >> I'm thinking I like this. >> >> I just added paths for ${PREFIX}/apach2/bin and ${PREFIX}/lib/mysql5/ >> bin to /opt/local/etc/env_helper/paths/PATH/(apache2 & mysql5). > > Okay, so you expect this to be added to PATH. At the front? At the > end? > In which order? Front, and yes, the order isn't guaranteed to be correct for everyone, especially all those people installing mysql4 and mysql5 :) > How will it now it needs to do concat at all and not replace? > (Thinking > of possible more general settings). How will it know to concat using > ":" > and not spaces? Because everything in etc/env_helper/paths is going to be parsed and have it's paths added to the front of the var value with ":" as the separator. Different things could be done in /etc/env_helper/vars as an example. I know this is not a robust solution. I'm just looking for a one liner to be added to ~/.profile to fix some of the things that don't work, like apache2 and mysql5 you mention below. > For apache2, this is just the old lame reason that nobody fixed the > layout yet to be inside $prefix :-) Agreed :) > mysql5 does not put the files into $prefix/bin because it conflicts > with > mysql4. If now both ports add the alternative dir to PATH this lends > to > confusion and breakage. Agreed. This multi-version idea doesn't seem to pay well. Any chance of a refund :) > For example, you installed mysql4 which has added the libdir to PATH > this way. Typing "mysql" is actually mysql4. Now some port also > pulls in > mysql5 which you do not recognize at all and suddenly "mysql" is > mysql5 > because for some reason the PATH ended up in this order. > > By the way, can anybody think of other ports we did not talk about yet > for which something like this could be useful? For example, I can > think > of bash-completion. I have a bash-completion line in my ~/.profile as well. > I concur with Jeremy that a equal sign separated format would be the > better choice for this, for clarity and maintenance, one file per port > is enough. And I have no objection to this either. While working on the perl5 fix I learned about path_helper and thought throwing something simple together to get a ~/.profile one liner might be useful. I also imagined that for those whose env ended up not being what they wanted they could not use the one liner OR they could toss their own file into the proper dir and override or what ever. Just name the file so it gets read last. > What I would like to see is a way to choose which items > are actually added to my environment, because I still want to have > control. Wouldn't making overrides solve your control issue? I'm just thinking something very simple that works 93% of the time. If your in the 7% you'll know how to quickly fix up your env I bet. > I think the easiest would be to use symlinks. I have a layout > in mind similar to what is used for init-scripts on most systems. And I consider symlinks clutter :) Simlinks would be much more time consuming to track down and modify if you weren't happy with the choices that were made for you. > To address the issues mentioned above and support a little bit more we > would have to split it into env and profile: > > ${etcdir}/env-avail.d/: > apache2 > mysql5 > ${etcdir}/env.d/: > apache2 -> ../env-avail.d/apache2 > mysql5 -> ../env-avail.d/mysql5 > ${etcdir}/profile-avail.d/: > bash-completion > trac-tools > ${etcdir}/profile.d/: > trac-tools -> ../profile-avail.d/trac-tools This sounds good but personally I'd vote to just have them all add and allow overrides. If overrides aren't cutting it then just don't include the ~/.profile one liner and setup your on env. I'll bet this will be the rare exception. > (Think of trac-tools making [1] available, as I can't think of another > existing port right now). > > env.d is meant to contain files in the equal sign separated format > which > are concatenated. Rules for concatenation are The order has yet to be > defined (possible using 00foo through 99bar in the symlinks?). And have Portfiles deciding when they are loaded. I see a lot of 99999myports. [...] > port env --update > Generates or updates ${etcdir}/profile based on the current symlink > layout, which is then used by `port env` as traversing all the files > each time a shell is spawned is probably a bit slow. Could also > generate ${etcdir}/profile.csh or similar. Needs to be run > after --enable/--disable or port installes/upgrades to apply changes. > Ideally port would check for file modification time of ${etcdir}/*.d/ > after activation and recommend to run env-update if necessary. > > A user would only need to add this line to his .profile to load > MacPorts: > [ -f /opt/local/etc/profile ] && source /opt/local/etc/profile > > > Still reading? Comments? ;-) I am not familiar with the port code base but I do think that if ports are allowed to install things in dirs that are not already in ones typical paths and such the port should have a way and a responsibility to fix up the env. >> [...] >> This can probably be done better but I do think this adds value with >> little cost. > > This will definitely be useful, especially as it reduces the need of > lines to be added to the profile. I started something different for > this > earlier with $prefix/share/macports/setupenv.bash in which nobody > seemed > to be interested (e.g. similar scripts for tcsh/zsh). But this could > be > incorporated into the new ${etcdir}/profile. I think fixing the location or env for ports shouldn't cost all that much and pays for itself quickly. Whichever the approach is taken I think the conf files should be constructed so as to be easily parsed by shells other then bash. I use bash but I think we should be kind to others and it shouldn't be that difficult. As well, I would like to have it easily overridden with /etc/$ {somedir}/override or /etc/${somedir}/user or something. This way if you need to tweak something you can still take advantage of the env setup but alter a little at the end. If you need major changes just don't use it and tweak your ~/.profile. Thank you Rainer and Jeremy for expressing an interest in making the macports env more friendly. //Brad From ryandesign at macports.org Mon Mar 16 16:14:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 16 Mar 2009 18:14:35 -0500 Subject: env_helper In-Reply-To: <49BE97C8.4060800@macports.org> References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> <49BE97C8.4060800@macports.org> Message-ID: <10F81B70-869B-4B83-99ED-83E5FF73305C@macports.org> On Mar 16, 2009, at 13:17, Rainer M?ller wrote: > On 2009-03-15 23:25, Bradley Giesbrecht wrote: >> > >> I just added paths for ${PREFIX}/apach2/bin and ${PREFIX}/lib/mysql5/ >> bin to /opt/local/etc/env_helper/paths/PATH/(apache2 & mysql5). > > Okay, so you expect this to be added to PATH. At the front? At the > end? > In which order? > > How will it now it needs to do concat at all and not replace? > (Thinking > of possible more general settings). How will it know to concat > using ":" > and not spaces? > > For apache2, this is just the old lame reason that nobody fixed the > layout yet to be inside $prefix :-) > > mysql5 does not put the files into $prefix/bin because it conflicts > with > mysql4. If now both ports add the alternative dir to PATH this > lends to > confusion and breakage. mysql4 and mysql5 still conflict: http://trac.macports.org/ticket/4115 And there is no need to put ${prefix}/lib/mysql5/bin into PATH because mysql5 installs symlinks into ${prefix}/bin with the same names, just with "5" appended. > By the way, can anybody think of other ports we did not talk about yet > for which something like this could be useful? For example, I can > think > of bash-completion. Bradley mentioned p5 manpages in his first message, and I agree that would be useful. In the perl5.8 fixup thread I was thinking a way to solve the issue would be if the manpages could be put into different paths, if only MacPorts had a way of modifying the user's manpath. And with Bradley's script, now it does. Currently the MacPorts binary installer modifies the user's .profile to munge the PATH and if necessary the MANPATH. I would prefer if instead MacPorts simply added a single line to load a MacPorts bash script which did that munging. This script would be owned by MacPorts and could be updated when MacPorts is updated. So if we ever decide to change what we want to munge in the .profile we could change it in our script and not have to re-munge the user's .profile. Someone already wrote this script. It's in the repository. MacPorts base just doesn't use it. If we used such a script, then that's where this path/env helper functionality could be built in, rather than having the user add another line to their .profile. From bwaters at nrao.edu Mon Mar 16 16:24:54 2009 From: bwaters at nrao.edu (Boyd Waters) Date: Mon, 16 Mar 2009 17:24:54 -0600 Subject: env_helper In-Reply-To: <49BE97C8.4060800@macports.org> References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> <49BE97C8.4060800@macports.org> Message-ID: <2b0225fb0903161624o296cea20u779cbd732b683247@mail.gmail.com> Very weird, I was working on path_helper yesterday! I like the "port env" idea. We need "rpath" and "lpath" -- to add to the beginning or end of a PATH Here's what we use at work: #!/bin/ksh # # Script to define path-related manipulation functions. Must be run with "." # # Revision history: 1.0 MRM 940204 Functions from Chris Flatters' .profile # with permission # 1.1 MRM 950817 Corrections & updates from Chris # Define some useful functions for setting paths: # PrependPath makes the first element of # the search path stored in unless the first element # of the path is the current working directory (.), in which case # becomes the second element of the search path, or unless # is already an element of the search path, in which case # the search path is left unchanged. function PrependPath { typeset path eval path=\${${1}} if [ -n "$path" ] then case $path in ${2}*) ;; # Directory already at beginning *:${2}*) ;; # Directory already present .:*) eval ${1}=.:${2}:${path##.:} ;; *) eval ${1}=${2}:$path ;; esac else eval export ${1}=${2} fi } # PostpendPath makes the last element of # the search path stored in unless the last element # of the path is the current working directory (.), in which case # becomes the second-last element of the search path, or unless # is already an element of the search path, in which case # the search path is left unchanged. function PostpendPath { typeset path eval path=\${${1}} if [ -n "$path" ] then case $path in ${2}*) ;; # Directory already at beginning *:${2}*) ;; # Directory already present *:.) eval ${1}=${path%%:.}:${2}:. ;; *) eval ${1}=$path:${2} ;; esac else eval export ${1}=${2} fi } # PrependXPath prepends a set of pathnames # for XtResolvePathname rooted at to the path stored # in . This is intended for use with XFILESEARCHPATH # etc. function PrependXPath { typeset dir eval dir=${2} # Items suggested in X11R6 man page for XtResolvePathname PrependPath ${1} ${dir}/%T/%N%S PrependPath ${1} ${dir}/%l/%T/%N%S PrependPath ${1} ${dir}/%L/%T/%N%S PrependPath ${1} ${dir}/%T/%N%C%S PrependPath ${1} ${dir}/%l/%T/%N%C%S PrependPath ${1} ${dir}/%L/%T/%N%C%S } # PostpendXPath appends a set of pathnames # for XtResolvePathname rooted at to the path stored # in . This is intended for use with XFILESEARCHPATH # etc. function PostpendXPath { typeset dir eval dir=${2} # Items suggested in X11R6 man page for XtResolvePathname PostpendPath ${1} ${dir}/%L/%T/%N%C%S PostpendPath ${1} ${dir}/%l/%T/%N%C%S PostpendPath ${1} ${dir}/%T/%N%C%S PostpendPath ${1} ${dir}/%L/%T/%N%S PostpendPath ${1} ${dir}/%l/%T/%N%S PostpendPath ${1} ${dir}/%T/%N%S } # PrependUIDPath prepends a set of pathnames # for the Mrm functions rooted at to the path stored # in . If the path begins with %U%S then the new # entries will be inserted following %U%S function PrependUIDPath { typeset dir typeset path typeset pcu eval dir=${2} eval path=\${${1}} pcu=%U # To get around SCCS %U% keyword substitution case $path in %U?S*) eval ${1}=${path#\%U\%S} eval path=\${${1}} eval ${1}=${path#:} PrependPath ${1} ${dir}/%T/$pcu%S PrependPath ${1} ${dir}/%l/%T/$pcu%S PrependPath ${1} ${dir}/%L/%T/$pcu%S eval ${1}=$pcu%S:\${${1}} ;; *) PrependPath ${1} ${dir}/%T/$pcu%S PrependPath ${1} ${dir}/%l/%T/$pcu%S PrependPath ${1} ${dir}/%L/%T/$pcu%S ;; esac } # PostpendUIDPath appends a set of pathnames # for the Mrm functions rooted at to the path stored # in . function PostpendUIDPath { typeset dir typeset pcu eval dir=${2} pcu=%U # Get around SCCS %U% substitution PostpendPath ${1} ${dir}/%L/%T/$pcu%S PostpendPath ${1} ${dir}/%l/%T/$pcu%S PostpendPath ${1} ${dir}/%T/$pcu%S } From ryandesign at macports.org Mon Mar 16 18:04:10 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 16 Mar 2009 20:04:10 -0500 Subject: [48164] trunk/dports/graphics/gimp/Portfile In-Reply-To: <20090315185755.CB7C41211DB1@beta.macosforge.org> References: <20090315185755.CB7C41211DB1@beta.macosforge.org> Message-ID: <339848A8-CE30-499A-A67A-C482D9006013@macports.org> On Mar 15, 2009, at 13:57, devans at macports.org wrote: > Revision: 48164 > http://trac.macports.org/changeset/48164 > Author: devans at macports.org > Date: 2009-03-15 11:57:55 -0700 (Sun, 15 Mar 2009) > Log Message: > ----------- > gimp: make gimp-gap-devel the default version for the +animation > variant even though it is a development version as it really works > much better with the gimp 2.6 series and supports more video and > audio formats. Perhaps you could allow the user to choose whether they want gimp-gap or gimp-gap-devel by making this a path:-style dependency instead of a port:-style one? As it is now, any user who had gimp +animation installed before will have gimp-gap installed. When they try to upgrade the port next time, gimp-gap-devel will get installed but MacPorts won't be able to activate it because it will conflict with gimp-gap. > Modified Paths: > -------------- > trunk/dports/graphics/gimp/Portfile > > Modified: trunk/dports/graphics/gimp/Portfile > =================================================================== > --- trunk/dports/graphics/gimp/Portfile 2009-03-15 18:53:02 UTC > (rev 48163) > +++ trunk/dports/graphics/gimp/Portfile 2009-03-15 18:57:55 UTC > (rev 48164) > @@ -44,7 +44,7 @@ > } > > variant animation description "Include the Gimp Animation Package > (gimp-gap)." { > - depends_lib-append port:gimp-gap > + depends_lib-append port:gimp-gap-devel > } From ryandesign at macports.org Mon Mar 16 18:07:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 16 Mar 2009 20:07:03 -0500 Subject: [48123] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <20090315042852.EF8DF11FD58B@beta.macosforge.org> References: <20090315042852.EF8DF11FD58B@beta.macosforge.org> Message-ID: On Mar 14, 2009, at 23:28, raimue at macports.org wrote: > Revision: 48123 > http://trac.macports.org/changeset/48123 > Author: raimue at macports.org > Date: 2009-03-14 21:28:51 -0700 (Sat, 14 Mar 2009) > Log Message: > ----------- > macports1.0/macports.tcl: > Improve messages given for selfupdate > > Modified Paths: > -------------- > trunk/base/src/macports1.0/macports.tcl > > Modified: trunk/base/src/macports1.0/macports.tcl > =================================================================== > --- trunk/base/src/macports1.0/macports.tcl 2009-03-15 03:49:27 UTC > (rev 48122) > +++ trunk/base/src/macports1.0/macports.tcl 2009-03-15 04:28:51 UTC > (rev 48123) > @@ -2086,6 +2086,7 @@ > > # syncing ports tree. > if {![info exists options(ports_selfupdate_nosync)] || $options > (ports_selfupdate_nosync) != "yes"} { > + ui_msg "--> Updating the ports tree" [snip other similar lines] Shouldn't we be using $UI_PREFIX in these places instead of "-->"? From raimue at macports.org Mon Mar 16 18:51:35 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 17 Mar 2009 02:51:35 +0100 Subject: [48123] trunk/base/src/macports1.0/macports.tcl In-Reply-To: References: <20090315042852.EF8DF11FD58B@beta.macosforge.org> Message-ID: <49BF0227.9050901@macports.org> On 2009-03-17 02:07, Ryan Schmidt wrote: > On Mar 14, 2009, at 23:28, raimue at macports.org wrote: >> --- trunk/base/src/macports1.0/macports.tcl 2009-03-15 03:49:27 UTC >> (rev 48122) >> +++ trunk/base/src/macports1.0/macports.tcl 2009-03-15 04:28:51 UTC >> (rev 48123) >> @@ -2086,6 +2086,7 @@ >> >> # syncing ports tree. >> if {![info exists options(ports_selfupdate_nosync)] || $options >> (ports_selfupdate_nosync) != "yes"} { >> + ui_msg "--> Updating the ports tree" > > [snip other similar lines] > > Shouldn't we be using $UI_PREFIX in these places instead of "-->"? Yes, I know that. I already spoke with Joshua when he used "-->" in the dependency calculation. There is simply no UI_PREFIX in the macports1.0 package, it is used in port1.0 only. It is also hardcoded in registry1.0. Although port1.0 tries to overwrite UI_PREFIX from the environment, this is blocked by the env cleanup in macports1.0. I don't think anybody could be actually overwriting this at the moment and it was broken before, so it's not a real regression caused by this commit ;-) For fixing this, having a ui_msg_prefix (or ui_section/ui_header/etc.) command similar to ui_msg which prepends this prefix would be better and more portable. Clients of macports1.0 could tell which prefix they prefer or even get it through a different channel and add the prefix on its own. Rainer From ryandesign at macports.org Mon Mar 16 20:53:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 16 Mar 2009 22:53:28 -0500 Subject: [MacPorts] #17349: svn.tag should be called svn.rev In-Reply-To: <068.35fa0abefb4f48e268dc803f13277871@macports.org> References: <059.7396539c1302207b7f7f924ecd3776e2@macports.org> <068.35fa0abefb4f48e268dc803f13277871@macports.org> Message-ID: On Mar 16, 2009, at 22:46, MacPorts wrote: > #17349: svn.tag should be called svn.rev > -------------------------------------------- > +------------------------------- > Reporter: ryandesign@? | Owner: > macports-tickets@? > Type: enhancement | Status: new > Priority: Normal | Milestone: > MacPorts 1.8.0 > Component: base | Version: 1.6.0 > Keywords: svn.tag svn.revision deprecate | Port: > -------------------------------------------- > +------------------------------- > Changes (by raimue@?): > > * keywords: => svn.tag svn.revision deprecate > * milestone: MacPorts Future => MacPorts 1.8.0 > > > Comment: > > Oh, I have not been aware of this ticket before doing r48223. > > I made it a ui_warn message now. I will take a look if we can also > make it > count as a warning in lint by adding another option_proc there. Looks like we both had the same idea. :) And I wasn't aware of option_deprecate. I just wanted you to see the ticket so you can add your notes to it. From raimue at macports.org Mon Mar 16 20:54:25 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 17 Mar 2009 04:54:25 +0100 Subject: [48123] trunk/base/src/macports1.0/macports.tcl In-Reply-To: References: <20090315042852.EF8DF11FD58B@beta.macosforge.org> Message-ID: <49BF1EF1.3090704@macports.org> On 2009-03-17 02:07, Ryan Schmidt wrote: > On Mar 14, 2009, at 23:28, raimue at macports.org wrote: > >> Revision: 48123 >> http://trac.macports.org/changeset/48123 >> Author: raimue at macports.org >> Date: 2009-03-14 21:28:51 -0700 (Sat, 14 Mar 2009) >> Log Message: >> ----------- >> macports1.0/macports.tcl: >> Improve messages given for selfupdate >> >> Modified Paths: >> -------------- >> trunk/base/src/macports1.0/macports.tcl >> >> Modified: trunk/base/src/macports1.0/macports.tcl >> =================================================================== >> --- trunk/base/src/macports1.0/macports.tcl 2009-03-15 03:49:27 UTC >> (rev 48122) >> +++ trunk/base/src/macports1.0/macports.tcl 2009-03-15 04:28:51 UTC >> (rev 48123) >> @@ -2086,6 +2086,7 @@ >> >> # syncing ports tree. >> if {![info exists options(ports_selfupdate_nosync)] || $options >> (ports_selfupdate_nosync) != "yes"} { >> + ui_msg "--> Updating the ports tree" > > [snip other similar lines] > > Shouldn't we be using $UI_PREFIX in these places instead of "-->"? You made me aware that I was not even using something to look like $UI_PREFIX. I am looking daily at port output, and still I don't know how it should look like? Shame on me. Fixed in r48226. Rainer From raimue at macports.org Mon Mar 16 23:02:25 2009 From: raimue at macports.org (=?windows-1252?Q?Rainer_M=FCller?=) Date: Tue, 17 Mar 2009 07:02:25 +0100 Subject: Deprecation of options (was: Re: [MacPorts] #17349: svn.tag should be called svn.rev) In-Reply-To: References: <059.7396539c1302207b7f7f924ecd3776e2@macports.org> <068.35fa0abefb4f48e268dc803f13277871@macports.org> Message-ID: <49BF3CF1.7090407@macports.org> On 2009-03-17 04:53, Ryan Schmidt wrote: > And I wasn't aware of option_deprecate. It was dead code before, but I revived it and made it actually work. I also would like to deprecate livecheck.check and rename it to livecheck.type in the same way for consistency with other phases. This will affect a lot of ports, but I think we can simply work that out with one mass-change after 1.8.0 is released. Anything else to consider while I am at it? Rainer From ryandesign at macports.org Mon Mar 16 23:17:32 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 17 Mar 2009 01:17:32 -0500 Subject: Deprecation of options (was: Re: [MacPorts] #17349: svn.tag should be called svn.rev) In-Reply-To: <49BF3CF1.7090407@macports.org> References: <059.7396539c1302207b7f7f924ecd3776e2@macports.org> <068.35fa0abefb4f48e268dc803f13277871@macports.org> <49BF3CF1.7090407@macports.org> Message-ID: On Mar 17, 2009, at 01:02, Rainer M?ller wrote: > On 2009-03-17 04:53, Ryan Schmidt wrote: >> And I wasn't aware of option_deprecate. > > It was dead code before, but I revived it and made it actually work. > > I also would like to deprecate livecheck.check and rename it to > livecheck.type in the same way for consistency with other phases. Agreed! > This > will affect a lot of ports, but I think we can simply work that out > with > one mass-change after 1.8.0 is released. > > Anything else to consider while I am at it? Not right this moment. We can add more later if we think of it. From alakazam at macports.org Tue Mar 17 00:39:57 2009 From: alakazam at macports.org (Olivier Le Floch) Date: Tue, 17 Mar 2009 08:39:57 +0100 Subject: [48229] trunk/www/includes/header.inc In-Reply-To: <20090317072953.F009F123208C@beta.macosforge.org> References: <20090317072953.F009F123208C@beta.macosforge.org> Message-ID: On 17 mars 09, at 08:29, raimue at macports.org wrote: > Revision: 48229 > http://trac.macports.org/changeset/48229 > Author: raimue at macports.org > Date: 2009-03-17 00:29:53 -0700 (Tue, 17 Mar 2009) > Log Message: > ----------- > www/includes/header.inc: > The website is not available in multiple languages, so hide this > confusing language chooser. Why comment the code instead of removing it altogether ? From raimue at macports.org Tue Mar 17 00:45:22 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 17 Mar 2009 08:45:22 +0100 Subject: [48229] trunk/www/includes/header.inc In-Reply-To: References: <20090317072953.F009F123208C@beta.macosforge.org> Message-ID: <49BF5512.8070403@macports.org> Olivier Le Floch wrote: > On 17 mars 09, at 08:29, raimue at macports.org wrote: > >> Revision: 48229 >> http://trac.macports.org/changeset/48229 >> Author: raimue at macports.org >> Date: 2009-03-17 00:29:53 -0700 (Tue, 17 Mar 2009) >> Log Message: >> ----------- >> www/includes/header.inc: >> The website is not available in multiple languages, so hide this >> confusing language chooser. > > Why comment the code instead of removing it altogether ? I was lazy and did not remove the CSS and Javascript which is still there for this. With a comment it leaves a trace what this was meant to be. Rainer From blb at macports.org Tue Mar 17 01:58:34 2009 From: blb at macports.org (Bryan Blackburn) Date: Tue, 17 Mar 2009 02:58:34 -0600 Subject: milestone 1.7.1 In-Reply-To: <49BC7968.80904@macports.org> References: <35016D3E-8DC3-462F-95DE-1AA1F26F6005@lavergne.gotdns.org> <49B910C9.9090802@macports.org> <49B912E8.20308@macports.org> <49BC7968.80904@macports.org> Message-ID: <20090317085834.GC750@ninagal.withay.com> On Sun, Mar 15, 2009 at 04:43:36AM +0100, Rainer M?ller said: > On 12.03.2009 22:41 Uhr, Ryan Schmidt wrote: > > We should still merge back from trunk those handful of small changes > > that I mentioned in another thread some weeks ago. > > For reference: > http://lists.macosforge.org/pipermail/macports-dev/2009-February/007440.html > > Proposed merges (reformatted): > | We could merge in these additional small changes that are on trunk: > | > | - Add new "use_7z yes" port option to allow distfiles in 7z > | format (#18521, ryandesign) Merged in r48236. > | > | - port lint no longer requires variable master_sites if the port > | has no distfiles (#18479, ryandesign) Merged in r48235. > | > | - Upgrade will no longer accept ports that are not installed > | (but it still installs new ports as dependencies if needed). > | In particular, this means that "port upgrade all" will no > | longer proceed to install every available port. (jmr in > | r46052) Merged in r48234. > | > | - Add mkdtemp Tcl command to create temporary directories. > | (#17181, perry) Merged in r48233. All that's left is to get confirmation that ticket #17762 has been fixed, then 1.7.1 should be good to go. Bryan > > > There were no real objections. > Ryan, would you take care of merging them? > > Rainer From brad at pixilla.com Tue Mar 17 09:01:04 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 17 Mar 2009 09:01:04 -0700 Subject: env_helper In-Reply-To: <10F81B70-869B-4B83-99ED-83E5FF73305C@macports.org> References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> <49BE97C8.4060800@macports.org> <10F81B70-869B-4B83-99ED-83E5FF73305C@macports.org> Message-ID: <1F12D3A8-2A62-4306-8FE9-D72750030A91@pixilla.com> On Mar 16, 2009, at 4:14 PM, Ryan Schmidt wrote: > > On Mar 16, 2009, at 13:17, Rainer M?ller wrote: > >> On 2009-03-15 23:25, Bradley Giesbrecht wrote: >> [...] >> mysql5 does not put the files into $prefix/bin because it conflicts >> with >> mysql4. If now both ports add the alternative dir to PATH this >> lends to >> confusion and breakage. > > mysql4 and mysql5 still conflict: > > http://trac.macports.org/ticket/4115 > > And there is no need to put ${prefix}/lib/mysql5/bin into PATH > because mysql5 installs symlinks into ${prefix}/bin with the same > names, just with "5" appended. True, but I wanted some examples of where it COULD have been used. Mysql5 works fine. >> By the way, can anybody think of other ports we did not talk about >> yet >> for which something like this could be useful? For example, I can >> think >> of bash-completion. > > Bradley mentioned p5 manpages in his first message, and I agree that > would be useful. In the perl5.8 fixup thread I was thinking a way to > solve the issue would be if the manpages could be put into different > paths, if only MacPorts had a way of modifying the user's manpath. > And with Bradley's script, now it does. > > > Currently the MacPorts binary installer modifies the user's .profile > to munge the PATH and if necessary the MANPATH. I would prefer if > instead MacPorts simply added a single line to load a MacPorts bash > script which did that munging. This script would be owned by > MacPorts and could be updated when MacPorts is updated. So if we > ever decide to change what we want to munge in the .profile we could > change it in our script and not have to re-munge the user's .profile. > > Someone already wrote this script. It's in the repository. MacPorts > base just doesn't use it. > > If we used such a script, then that's where this path/env helper > functionality could be built in, rather than having the user add > another line to their .profile. Righto, and macports should setup the basics and then use some method to traverse some lists that can be altered by a Portfile. I like just dropping files with one or two lines into the right place with a user override file parsed last. //Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad at pixilla.com Tue Mar 17 09:15:42 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 17 Mar 2009 09:15:42 -0700 Subject: env_helper In-Reply-To: <2b0225fb0903161624o296cea20u779cbd732b683247@mail.gmail.com> References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> <49BE97C8.4060800@macports.org> <2b0225fb0903161624o296cea20u779cbd732b683247@mail.gmail.com> Message-ID: <7A0740C4-D27A-4E7D-9542-C4FDB3489EAE@pixilla.com> On Mar 16, 2009, at 4:24 PM, Boyd Waters wrote: > Very weird, I was working on path_helper yesterday! > > I like the "port env" idea. If all it does is add the one line to your ~/.profile then I like that as well. > We need "rpath" and "lpath" -- to add to the beginning or end of a > PATH I would be happy with the simpler "free for all" approach I took. Whose going to control this? What ports are going to say "Load my path AFTER everyone elses so I'm found last if at all". I don't think env_helper will be needed that much because most ports already work well without altering env vars. Something really really simple with user overrides is good enough for me. If some port does something unlikely like putting an httpd in front of apache2's I could just add this to my paths/user or ~/.profile: PATH=/opt/local/apache2/bin:$PATH Path order issues would be very rare in my opinion. //Brad From devans at macports.org Tue Mar 17 10:25:20 2009 From: devans at macports.org (David Evans) Date: Tue, 17 Mar 2009 10:25:20 -0700 Subject: [48164] trunk/dports/graphics/gimp/Portfile In-Reply-To: <339848A8-CE30-499A-A67A-C482D9006013@macports.org> References: <20090315185755.CB7C41211DB1@beta.macosforge.org> <339848A8-CE30-499A-A67A-C482D9006013@macports.org> Message-ID: <49BFDD00.2070105@macports.org> Ryan Schmidt wrote: > On Mar 15, 2009, at 13:57, devans at macports.org wrote: > >> Revision: 48164 >> http://trac.macports.org/changeset/48164 >> Author: devans at macports.org >> Date: 2009-03-15 11:57:55 -0700 (Sun, 15 Mar 2009) >> Log Message: >> ----------- >> gimp: make gimp-gap-devel the default version for the +animation >> variant even though it is a development version as it really works >> much better with the gimp 2.6 series and supports more video and >> audio formats. > > Perhaps you could allow the user to choose whether they want gimp-gap > or gimp-gap-devel by making this a path:-style dependency instead of a > port:-style one? As it is now, any user who had gimp +animation > installed before will have gimp-gap installed. When they try to > upgrade the port next time, gimp-gap-devel will get installed but > MacPorts won't be able to activate it because it will conflict with > gimp-gap. > Good idea, Ryan, thanks. Change committed in r48245. From blair at orcaware.com Tue Mar 17 10:37:57 2009 From: blair at orcaware.com (Blair Zajac) Date: Tue, 17 Mar 2009 10:37:57 -0700 Subject: Moving X11 install into their own subdirectory In-Reply-To: <5E04B33A-C349-41B6-AD76-D7B12FF5A5AE@macports.org> References: <49BAFC2E.7040709@orcaware.com> <7DA5E02A-6F6F-4C8E-A733-A481C7FA0D91@macports.org> <49BC1E7D.6020900@orcaware.com> <2903A083-81ED-4B7F-9FC0-41077738128B@macports.org> <49BC78D0.2020808@orcaware.com> <5E04B33A-C349-41B6-AD76-D7B12FF5A5AE@macports.org> Message-ID: <49BFDFF5.50604@orcaware.com> Jeremy Huddleston wrote: > > On Mar 14, 2009, at 20:41, Blair Zajac wrote: > >> Jeremy Huddleston wrote: >>> On Mar 14, 2009, at 14:15, Blair Zajac wrote: >>> Further, moving all of X11 into a subdirectory would require changes >>> to base, massive changes throughout the tree, or both. It's not >>> feasible. >> >> Well, I think it's rude to tread on some another port without even an >> apology and requiring work on my part to fix something imposed on me. > > I didn't "tread on some another (sic) port". libICE had been in MP for > a long time (before I got here, so don't point at me) before this > conflict was discovered. > >> And you say that this is infeasible. > > Yes. libICE has been around for 20 years! It is linked against by > numerous ports and third party apps. It's unfortunate that this ice-cpp > package chose an existing name for their library, but this is really a > problem that upstream should've considered before releasing their package. Agreed. > Well, like I said, I have no idea how to solve this. It's a difficult > problem with no easy solution. If I could help, I would... but I don't > see an out. Sorry for my heated responses in this thread :) I've asked ZeroC to suggest an alternate name for their shared library and I think the only solution is to rename their shared library. >>> And if you want to play the "who was there first" game... X11R6 has >>> been around since 1987. >> >> True, but not in this distribution. > > libICE was added in with XFree86 in r134 (2002-08-06). ice-cpp was > added in r23806 (2007-04-09). libICE was added independent of XFree86 > as xorg-libice in r34665 (2008-03-01) I checked svn and just saw it as a separate port. Did MacPorts X11 libraries always install into $prefix/lib or into an X11R6 style subdirectory? Regards, Blair From blair at orcaware.com Tue Mar 17 10:40:27 2009 From: blair at orcaware.com (Blair Zajac) Date: Tue, 17 Mar 2009 10:40:27 -0700 Subject: Moving X11 install into their own subdirectory In-Reply-To: References: <49BAFC2E.7040709@orcaware.com> Message-ID: <49BFE08B.9000900@orcaware.com> Michael, I install xemacs which uses Xaw3d which uses xorg-libice. Regards, Blair Michael Franz wrote: > Blair, > > What port did you installed that required xorg-libice? > > Michael > > On Fri, Mar 13, 2009 at 8:37 PM, Blair Zajac > wrote: > > Hello, > > I haven't followed closely the work on getting X11 into the > MacPorts, but I was installing some new ports today and the > xorg-libice port conflicts with an existing port, ice-cpp, on the > libIce.dylib. Unfortunately, they have different capitalization, > ice-cpp has libIce.dylib and xorg-libice has libICE.dylib. > > Given precedence of an existing port and following the Linux > standard, it seems moving the xorg-* ports into $prefix/X11 or > $prefix/X11R6 would be a good thing to do. > > Comments? > > Regards, > Blair > From blair at orcaware.com Tue Mar 17 11:33:10 2009 From: blair at orcaware.com (Blair Zajac) Date: Tue, 17 Mar 2009 11:33:10 -0700 Subject: Moving X11 install into their own subdirectory In-Reply-To: <49BFDFF5.50604@orcaware.com> References: <49BAFC2E.7040709@orcaware.com> <7DA5E02A-6F6F-4C8E-A733-A481C7FA0D91@macports.org> <49BC1E7D.6020900@orcaware.com> <2903A083-81ED-4B7F-9FC0-41077738128B@macports.org> <49BC78D0.2020808@orcaware.com> <5E04B33A-C349-41B6-AD76-D7B12FF5A5AE@macports.org> <49BFDFF5.50604@orcaware.com> Message-ID: <49BFECE6.5000106@orcaware.com> Blair Zajac wrote: > > I've asked ZeroC to suggest an alternate name for their shared library > and I think the only solution is to rename their shared library. A reply from ZeroC on this: > On MacOS X, libIce.dylib is just a symbolic link to libIce.33.dylib, > itself a symbolic link to libIce.3.3.0.dylib and soon > libIce.3.3.1.dylib, and this symbolic link should be used only when > linking an application, and not at runtime. > > So the issue occurs if you're using a case-insensitive file system, and: > - you're building an application that links with both libICE and libIce > (which would seem uncommon), or > - all your library symbolic links are installed in the same directory > (e.g. /usr/lib). > > At first glance, my preference in this case would be to rename only the > conflicting symbolic link, but not the symbolic links/libraries it > points to, for example: libZeroCIce.dylib -> libIce.33.dylib -> > libIce.3.3.0.dylib > > and then of course adjust your makefiles to use -lZeroCIce instead of -lIce. Any comments on this approach? Blair From jeremyhu at macports.org Tue Mar 17 13:26:46 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Tue, 17 Mar 2009 13:26:46 -0700 Subject: Moving X11 install into their own subdirectory In-Reply-To: <49BFECE6.5000106@orcaware.com> References: <49BAFC2E.7040709@orcaware.com> <7DA5E02A-6F6F-4C8E-A733-A481C7FA0D91@macports.org> <49BC1E7D.6020900@orcaware.com> <2903A083-81ED-4B7F-9FC0-41077738128B@macports.org> <49BC78D0.2020808@orcaware.com> <5E04B33A-C349-41B6-AD76-D7B12FF5A5AE@macports.org> <49BFDFF5.50604@orcaware.com> <49BFECE6.5000106@orcaware.com> Message-ID: <8FCF4F42-CDA5-4AEC-8A5D-0A0E9B8142E8@macports.org> On Mar 17, 2009, at 11:33, Blair Zajac wrote: > Blair Zajac wrote: >> I've asked ZeroC to suggest an alternate name for their shared >> library and I think the only solution is to rename their shared >> library. > > A reply from ZeroC on this: > > > On MacOS X, libIce.dylib is just a symbolic link to libIce.33.dylib, > > itself a symbolic link to libIce.3.3.0.dylib and soon > > libIce.3.3.1.dylib, and this symbolic link should be used only when > > linking an application, and not at runtime. > > > > So the issue occurs if you're using a case-insensitive file > system, and: > > - you're building an application that links with both libICE and > libIce > > (which would seem uncommon), or > > - all your library symbolic links are installed in the same > directory > > (e.g. /usr/lib). > > > > At first glance, my preference in this case would be to rename > only the > > conflicting symbolic link, but not the symbolic links/libraries it > > points to, for example: libZeroCIce.dylib -> libIce.33.dylib -> > > libIce.3.3.0.dylib > > > > and then of course adjust your makefiles to use -lZeroCIce instead > of -lIce. > > Any comments on this approach? Curious... Why is it libIce.33.dylib and not libIce.3.dylib as the libIce.3.3.0.dylib seems to indicate it should be? Is it built using libtool? If so, that seems really inconsistent. What does 'otool -L /opt/local/lib/libIce.33.dylib' say? This is a "good enough" solution for the short term. libICE is at libICE.6.dylib, so we just need to watch to make sure there's never conflict between the two. Why not just go one step further and actually rename the dylibs libZeroCIce.33.dylib and libZeroCIce.3.3.0.dylib? That seems safer, easier, and less confusing. From devans at macports.org Tue Mar 17 17:27:30 2009 From: devans at macports.org (David Evans) Date: Tue, 17 Mar 2009 17:27:30 -0700 Subject: [48265] trunk/base/src/port1.0/portlivecheck.tcl In-Reply-To: <20090317233232.7134F124028F@beta.macosforge.org> References: <20090317233232.7134F124028F@beta.macosforge.org> Message-ID: <49C03FF2.5000506@macports.org> perry at macports.org wrote: > > Revision > 48265 > Author > perry at macports.org > Date > 2009-03-17 16:32:31 -0700 (Tue, 17 Mar 2009) > > > Log Message > > port1.0/portlivecheck.tcl - Fixed livecheck for freshmeat. (Addresses #18887) > > > Modified Paths > > * trunk/base/src/port1.0/portlivecheck.tcl > <#trunkbasesrcport10portlivechecktcl> > > > Diff > > > Modified: trunk/base/src/port1.0/portlivecheck.tcl (48264 => > 48265) > > > --- trunk/base/src/port1.0/portlivecheck.tcl 2009-03-17 22:52:16 UTC (rev 48264) > +++ trunk/base/src/port1.0/portlivecheck.tcl 2009-03-17 23:32:31 UTC (rev 48265) > @@ -123,10 +123,10 @@ > switch ${livecheck.check} { > "freshmeat" { > if {!$has_homepage || ${livecheck.url} eq ${homepage}} { > - set livecheck.url "http://freshmeat.net/projects-xml/${livecheck.name}/${livecheck.name}.xml" > + set livecheck.url "http://freshmeat.net/projects/${livecheck.name}/releases.atom" > } > if {${livecheck.regex} eq ""} { > - set livecheck.regex [list "(.*)"] > + set livecheck.regex [list "${livecheck.name} (.*)"] > } > set livecheck.check "regex" > } This certainly fixes the URL and the majority of cases but there are some that fail because the regex doesn't match due to differences in case (in various combinations) between our port name and the name used in the rss entry. It appears that their page will accept and match to the correct project any casing of the livecheck.name in the URL. If the regex would do the same then most of the rest would be solved. Examples livecheck.name gimp or GIMP selects the right but the regex needs to match GIMP livecheck.name XviD, xvid, Xvid selects the right project but the regex needs to match Xvid livecheck.name xsane select the right project but the regex needs to match XSane Hopefully you can see what I mean -- I'm not describing it well. So if one could construct a regex that would match the livecheck.name in any case combination that would be good. I just don't know how to do that off the top of my head. Dave From perry at macports.org Tue Mar 17 17:41:07 2009 From: perry at macports.org (Perry Lee) Date: Tue, 17 Mar 2009 17:41:07 -0700 Subject: [48265] trunk/base/src/port1.0/portlivecheck.tcl In-Reply-To: <49C03FF2.5000506@macports.org> References: <20090317233232.7134F124028F@beta.macosforge.org> <49C03FF2.5000506@macports.org> Message-ID: <00DCC956-4919-47E1-8A59-EAC221B11C91@macports.org> On Mar 17, 2009, at 5:27 PM, David Evans wrote: > Examples > > livecheck.name gimp or GIMP selects the right but the regex needs > to match GIMP > livecheck.name XviD, xvid, Xvid selects the right project but the > regex needs to match Xvid > livecheck.name xsane select the right project but the regex needs to > match XSane > > Hopefully you can see what I mean -- I'm not describing it well. > So if one could construct a regex that would match the > livecheck.name in any case combination that We could use the -nocase option ("Causes upper-case characters in string to be treated as lower case during the matching process") with regexp, but I'm not sure if we should be ignoring case. From devans at macports.org Tue Mar 17 17:49:46 2009 From: devans at macports.org (David Evans) Date: Tue, 17 Mar 2009 17:49:46 -0700 Subject: [48265] trunk/base/src/port1.0/portlivecheck.tcl In-Reply-To: <00DCC956-4919-47E1-8A59-EAC221B11C91@macports.org> References: <20090317233232.7134F124028F@beta.macosforge.org> <49C03FF2.5000506@macports.org> <00DCC956-4919-47E1-8A59-EAC221B11C91@macports.org> Message-ID: <49C0452A.2050407@macports.org> Perry Lee wrote: > > We could use the -nocase option ("Causes upper-case characters in > string to be treated as lower case during the matching process") with > regexp, but I'm not sure if we should be ignoring case. > To work, I think it would have to lowercase both the livecheck.name and the corresponding text to be matched in the rss entry. Not sure that is what this does. On the other hand, it can be fixed in the Portfile by just setting the livecheck.name to the same casing as is used in the freshmeat rss entry. So these work: livecheck.name GIMP livecheck.name XVid livecheck.name XSane But it would be more elegant if it could be done automatically. From perry at macports.org Tue Mar 17 18:06:46 2009 From: perry at macports.org (Perry Lee) Date: Tue, 17 Mar 2009 18:06:46 -0700 Subject: [48265] trunk/base/src/port1.0/portlivecheck.tcl In-Reply-To: <49C0452A.2050407@macports.org> References: <20090317233232.7134F124028F@beta.macosforge.org> <49C03FF2.5000506@macports.org> <00DCC956-4919-47E1-8A59-EAC221B11C91@macports.org> <49C0452A.2050407@macports.org> Message-ID: <2375EC04-0D03-4A03-810A-37FD3288CBDD@macports.org> On Mar 17, 2009, at 5:49 PM, David Evans wrote: > livecheck.name GIMP > livecheck.name XVid > livecheck.name XSane > > But it would be more elegant if it could be done automatically. Index: src/port1.0/portlivecheck.tcl =================================================================== --- src/port1.0/portlivecheck.tcl (revision 48265) +++ src/port1.0/portlivecheck.tcl (working copy) @@ -199,7 +199,7 @@ set updated_version 0 set foundmatch 0 while {[gets $chan line] >= 0} { - if {[regexp $the_re $line matched upver]} { + if {[regexp -nocase $the_re $line matched upver]} { set foundmatch 1 if {$updated_version == 0 || [rpm-vercomp $upver $updated_version] > 0} { set updated_version $upver With the above change, livecheck works with the examples you've listed (i.e., you don't need to change their livecheck.names). Are there any negative repercussions for ignoring case in livecheck, though? From blb at macports.org Tue Mar 17 19:07:30 2009 From: blb at macports.org (Bryan Blackburn) Date: Tue, 17 Mar 2009 20:07:30 -0600 Subject: [48265] trunk/base/src/port1.0/portlivecheck.tcl In-Reply-To: <2375EC04-0D03-4A03-810A-37FD3288CBDD@macports.org> References: <20090317233232.7134F124028F@beta.macosforge.org> <49C03FF2.5000506@macports.org> <00DCC956-4919-47E1-8A59-EAC221B11C91@macports.org> <49C0452A.2050407@macports.org> <2375EC04-0D03-4A03-810A-37FD3288CBDD@macports.org> Message-ID: <20090318020730.GN1022@ninagal.withay.com> On Tue, Mar 17, 2009 at 06:06:46PM -0700, Perry Lee said: > On Mar 17, 2009, at 5:49 PM, David Evans wrote: >> livecheck.name GIMP >> livecheck.name XVid >> livecheck.name XSane >> >> But it would be more elegant if it could be done automatically. > > Index: src/port1.0/portlivecheck.tcl > =================================================================== > --- src/port1.0/portlivecheck.tcl (revision 48265) > +++ src/port1.0/portlivecheck.tcl (working copy) > @@ -199,7 +199,7 @@ > set updated_version 0 > set foundmatch 0 > while {[gets $chan line] >= 0} { > - if {[regexp $the_re $line matched upver]} { > + if {[regexp -nocase $the_re $line matched > upver]} { > set foundmatch 1 > if {$updated_version == 0 || [rpm-vercomp > $upver $updated_version] > 0} { > set updated_version $upver > > With the above change, livecheck works with the examples you've listed > (i.e., you don't need to change their livecheck.names). Are there any > negative repercussions for ignoring case in livecheck, though? So the main problem is that freshmeat changed the format such that we now have to look for "${livecheck.name}" instead of simply , hence livecheck.name now being a big issue? If so, we can limit the case-insensitivity to just the freshmeat regex by instead using @@ -126,7 +126,7 @@ set livecheck.url "http://freshmeat.net/projects/${livecheck.name}/releases.atom" } if {${livecheck.regex} eq ""} { - set livecheck.regex [list "${livecheck.name} (.*)"] + set livecheck.regex [list "(?i)${livecheck.name} (.*)"] } set livecheck.check "regex" } For long-term, I've filed #18889 to push some of this into dports/_resources so it wouldn't require a complete MacPorts release to update: Bryan From jeremyhu at macports.org Tue Mar 17 21:03:13 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Tue, 17 Mar 2009 21:03:13 -0700 Subject: [48196] trunk/dports/x11/mesa/Portfile In-Reply-To: References: <20090316203222.C502912279BB@beta.macosforge.org> Message-ID: <3E618345-A52C-4086-8190-052D5C6B6824@macports.org> On Mar 17, 2009, at 20:41, Rolf W?rdemann wrote: > Hi Jeremy, > > first: thank you again for getting the OpenGL-Stuff on tiger to work! > > Short question - is there any reason not to simply plug in > xorg-server in the tiger installation (depends_lib-append port:xorg- > server) > instead of giving an ui_msg? I wanted to avoid cyclic dependencies. From jeremyhu at macports.org Wed Mar 18 00:14:29 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Wed, 18 Mar 2009 00:14:29 -0700 Subject: [48196] trunk/dports/x11/mesa/Portfile In-Reply-To: <734D8DF0-FC29-4B7D-A5D6-6FA5F12E48F1@macports.org> References: <20090316203222.C502912279BB@beta.macosforge.org> <3E618345-A52C-4086-8190-052D5C6B6824@macports.org> <734D8DF0-FC29-4B7D-A5D6-6FA5F12E48F1@macports.org> Message-ID: <0303BC87-7210-490F-83E7-8ED507F5734C@macports.org> On Mar 17, 2009, at 22:50, Rolf W?rdemann wrote: > > Am 18.03.2009 um 05:03 schrieb Jeremy Huddleston: > >> >> On Mar 17, 2009, at 20:41, Rolf W?rdemann wrote: >> >>> Hi Jeremy, >>> >>> first: thank you again for getting the OpenGL-Stuff on tiger to >>> work! >>> >>> Short question - is there any reason not to simply plug in >>> xorg-server in the tiger installation (depends_lib-append >>> port:xorg-server) >>> instead of giving an ui_msg? >> >> I wanted to avoid cyclic dependencies. > > O.K. - with cyclic dependencys you mean port a, depends on port b > which depends on port a? > > Hm - the only Port in x11 which has the ui_mesg of xorg-server is > mesa (done grep on xorg-server > in x11/*/Portfile) - where do you see an dependency-cycle? xorg-server-devel (which will be xorg-server one day) depends on mesa, so we shouldn't have mesa depend on xorg-server. From rowue at digitalis.org Wed Mar 18 00:51:09 2009 From: rowue at digitalis.org (=?ISO-8859-1?Q?Rolf_W=FCrdemann?=) Date: Wed, 18 Mar 2009 08:51:09 +0100 Subject: [48196] trunk/dports/x11/mesa/Portfile In-Reply-To: <0303BC87-7210-490F-83E7-8ED507F5734C@macports.org> References: <20090316203222.C502912279BB@beta.macosforge.org> <3E618345-A52C-4086-8190-052D5C6B6824@macports.org> <734D8DF0-FC29-4B7D-A5D6-6FA5F12E48F1@macports.org> <0303BC87-7210-490F-83E7-8ED507F5734C@macports.org> Message-ID: <815C6538-9375-426E-81C1-B964132172EC@digitalis.org> Am 18.03.2009 um 08:14 schrieb Jeremy Huddleston: > > On Mar 17, 2009, at 22:50, Rolf W?rdemann wrote: > >> >> Am 18.03.2009 um 05:03 schrieb Jeremy Huddleston: >> >>> >>> On Mar 17, 2009, at 20:41, Rolf W?rdemann wrote: >>> >>>> Hi Jeremy, >>>> >>>> first: thank you again for getting the OpenGL-Stuff on tiger to >>>> work! >>>> >>>> Short question - is there any reason not to simply plug in >>>> xorg-server in the tiger installation (depends_lib-append >>>> port:xorg-server) >>>> instead of giving an ui_msg? >>> >>> I wanted to avoid cyclic dependencies. >> >> O.K. - with cyclic dependencys you mean port a, depends on port b >> which depends on port a? >> >> Hm - the only Port in x11 which has the ui_mesg of xorg-server is >> mesa (done grep on xorg-server >> in x11/*/Portfile) - where do you see an dependency-cycle? > > xorg-server-devel (which will be xorg-server one day) depends on > mesa, so we shouldn't have mesa depend on xorg-server. *outsch* - ack (had only searched the other way ...) > -- Security is an illusion - Datasecurity twice Rolf W?rdemann - private: rowue at digitalis.org - office: rowue at crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue at digitalis.org ECF127C7 EAB85F87 BC75ACB5 2EC646D4 99211A31 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: Signierter Teil der Nachricht URL: From jeremy at lavergne.gotdns.org Wed Mar 18 06:47:43 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 18 Mar 2009 09:47:43 -0400 Subject: 10.5 +universal builds Message-ID: <72886F66-A77D-403C-9761-93289C88C8B2@lavergne.gotdns.org> I'm attempting to create a universal mpkg for PSPP, however it seems to contain only the i386 variant of libintl (from gettext). It says only i386 exists when I run `file libintl.8.dylib`, but if I do it on the actual builds both versions are present. Does anyone have any insight as to why this might be or how to get around it? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From devans at macports.org Wed Mar 18 10:18:43 2009 From: devans at macports.org (David Evans) Date: Wed, 18 Mar 2009 10:18:43 -0700 Subject: [48265] trunk/base/src/port1.0/portlivecheck.tcl In-Reply-To: <2375EC04-0D03-4A03-810A-37FD3288CBDD@macports.org> References: <20090317233232.7134F124028F@beta.macosforge.org> <49C03FF2.5000506@macports.org> <00DCC956-4919-47E1-8A59-EAC221B11C91@macports.org> <49C0452A.2050407@macports.org> <2375EC04-0D03-4A03-810A-37FD3288CBDD@macports.org> Message-ID: <49C12CF3.20608@macports.org> Perry Lee wrote: > Index: src/port1.0/portlivecheck.tcl > =================================================================== > --- src/port1.0/portlivecheck.tcl (revision 48265) > +++ src/port1.0/portlivecheck.tcl (working copy) > @@ -199,7 +199,7 @@ > set updated_version 0 > set foundmatch 0 > while {[gets $chan line] >= 0} { > - if {[regexp $the_re $line matched upver]} { > + if {[regexp -nocase $the_re $line matched > upver]} { > set foundmatch 1 > if {$updated_version == 0 || [rpm-vercomp > $upver $updated_version] > 0} { > set updated_version $upver > > With the above change, livecheck works with the examples you've listed > (i.e., you don't need to change their livecheck.names). Are there any > negative repercussions for ignoring case in livecheck, though? > After looking at the code, I understand your caution since this change applies to all livecheck regex's not just the freshmeat ones. So I did a more extensive test with this patch in place. I did livechecks on a list of ports consisting of all my maintained ports and their dependencies (287 ports total). This includes port using many different regex styles not just freshmeat. The only failures were the following 8 (my comments on the reasons for failure appended) : Error: cannot check if libgsf was updated (regex didn't match) // freshmeat: string to match is "GNOME Structured File Library" Error: cannot check if libsamplerate was updated (regex didn't match) // freshmeat: string to match is "Secret Rabbit Code" Error: cannot check if libusb was updated (regex didn't match) // sourceforge: string to match is "libusb-1.0 libusb-" Error: cannot check if mesa was updated (regex didn't match) // sourceforge: port uses livecheck.name mesa3d, needs to match "Mesa Lib" Error: cannot check if sane-backends was updated (HTTP response code said error) // freshmeat: project not in freshmeat, returns error page. Error: cannot check if tcl was updated (regex didn't match) // freshmeat: port uses livecheck.name tcltk, string to match is "Tcl/Tk" Error: cannot check if tk was updated (regex didn't match) // freshmeat: port uses livecheck.name tcltk, string to match is "Tcl/Tk" Error: cannot check if webkit-gtk was updated (HTTP response code said error) // freshmeat: project not in freshmeat, returns error page. These would fail in any case and probably did before the freshmeat change as well, so I don't see any adverse effects from -nocase in this fairly large same. Can send you my test list if you like. I vote to include this additional patch as part of 1.7.1 to keep the freshmeat livechecks working as they did before the recent changes. From raimue at macports.org Wed Mar 18 11:44:51 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 18 Mar 2009 19:44:51 +0100 Subject: env_helper In-Reply-To: <49BE97C8.4060800@macports.org> References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> <49BE97C8.4060800@macports.org> Message-ID: <49C14123.4010306@macports.org> Rainer M?ller wrote: > To address the issues mentioned above and support a little bit more we > would have to split it into env and profile: > > ${etcdir}/env-avail.d/: > apache2 > mysql5 > ${etcdir}/env.d/: > apache2 -> ../env-avail.d/apache2 > mysql5 -> ../env-avail.d/mysql5 > ${etcdir}/profile-avail.d/: > bash-completion > trac-tools > ${etcdir}/profile.d/: > trac-tools -> ../profile-avail.d/trac-tools > > (Think of trac-tools making [1] available, as I can't think of another > existing port right now). > > env.d is meant to contain files in the equal sign separated format which > are concatenated. Rules for concatenation are The order has yet to be > defined (possible using 00foo through 99bar in the symlinks?). > > profile.d is meant to contain arbitrary shell scripts registering > aliases/functions etc. > > And then we would have a `port env` command which operates on these dirs > and files as follows: > > port env --enable bash-completion > port env --disable bash-completion > Creates/removes a symlink in profile.d pointing to profile-avail.d What I was proposing here is probably totally wrong. I should have thought longer about it before proposing ;-) If I as a user want control, which is what I said as intention for the text above, this should not be done on the system level. And by ${prefix}/etc we are talking about the system, not individual user settings. Could probably do something like that symlinking stuff in $HOME, but it is not appropriate for ${prefix}/etc. > port env --update > Generates or updates ${etcdir}/profile based on the current symlink > layout, which is then used by `port env` as traversing all the files > each time a shell is spawned is probably a bit slow. Could also > generate ${etcdir}/profile.csh or similar. Needs to be run > after --enable/--disable or port installes/upgrades to apply changes. > Ideally port would check for file modification time of ${etcdir}/*.d/ > after activation and recommend to run env-update if necessary. > > A user would only need to add this line to his .profile to load MacPorts: > [ -f /opt/local/etc/profile ] && source /opt/local/etc/profile What is left is the caching, I would still prefer that. Rainer From raimue at macports.org Wed Mar 18 12:09:07 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Wed, 18 Mar 2009 20:09:07 +0100 Subject: MacPorts accepted for GSoC 2009 Message-ID: <49C146D3.30808@macports.org> Hello, MacPorts has been accepted for Google Summer of Code 2009! So for students who are interested in working on MacPorts over the summer and even earn money for it, visit our Summer of Code wiki page and read on: http://trac.macports.org/wiki/SummerOfCode Oh, and if some idea from you about improving anything in MacPorts is still missing, now is the time to discuss it here or add it to the list! Rainer From brad at pixilla.com Wed Mar 18 13:00:46 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Wed, 18 Mar 2009 13:00:46 -0700 Subject: env_helper In-Reply-To: <49C14123.4010306@macports.org> References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> <49BE97C8.4060800@macports.org> <49C14123.4010306@macports.org> Message-ID: <39ADA414-4D07-4842-9D0E-4DE1B596487C@pixilla.com> On Mar 18, 2009, at 11:44 AM, Rainer M?ller wrote: > Rainer M?ller wrote: [...] >> A user would only need to add this line to his .profile to load >> MacPorts: >> [ -f /opt/local/etc/profile ] && source /opt/local/etc/profile > > What is left is the caching, I would still prefer that. What is your idea as to when the cache gets updated? I have mentioned user overrides so I would want the cache function to be aware of things that might happen outside the port command like a user editing a conf file. I might not understand what you mean by caching. Since ~/.profile is only sourced when a shell is first opened is the complexity of a cache going to pay for itself? //Brad From raimue at macports.org Wed Mar 18 13:27:22 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 18 Mar 2009 21:27:22 +0100 Subject: env_helper In-Reply-To: <39ADA414-4D07-4842-9D0E-4DE1B596487C@pixilla.com> References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> <49BE97C8.4060800@macports.org> <49C14123.4010306@macports.org> <39ADA414-4D07-4842-9D0E-4DE1B596487C@pixilla.com> Message-ID: <49C1592A.6060402@macports.org> Bradley Giesbrecht wrote: > On Mar 18, 2009, at 11:44 AM, Rainer M?ller wrote: > >> Rainer M?ller wrote: > [...] >>> A user would only need to add this line to his .profile to load >>> MacPorts: >>> [ -f /opt/local/etc/profile ] && source /opt/local/etc/profile >> What is left is the caching, I would still prefer that. > > What is your idea as to when the cache gets updated? > > I have mentioned user overrides so I would want the cache function to > be aware of things that might happen outside the port command like a > user editing a conf file. > > I might not understand what you mean by caching. Since ~/.profile is > only sourced when a shell is first opened is the complexity of a cache > going to pay for itself? If you are going to traverse the filesystem in ${prefix}/etc/profile and concatenating values like PATH this probably gets slow. As long as no file changes this will give the same result each time anyway. So I would like to see a cache of this being generated by a command and the result saved to ${prefix}/etc/profile. We could also do the cache updates automatically in activate/deactivate (install/uninstall in direct mode). But then we need to tell the user that he absolutely has to do 'source ${prefix}/etc/profile' right now after this command. Rainer From brad at pixilla.com Wed Mar 18 13:00:46 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Wed, 18 Mar 2009 13:00:46 -0700 Subject: env_helper In-Reply-To: <49C14123.4010306@macports.org> References: <58BCCF60-F0DB-4507-887C-0641FB39A9AF@pixilla.com> <580904F2-30FB-4490-950D-497050909C8B@pixilla.com> <49BE97C8.4060800@macports.org> <49C14123.4010306@macports.org> Message-ID: <39ADA414-4D07-4842-9D0E-4DE1B596487C@pixilla.com> On Mar 18, 2009, at 11:44 AM, Rainer M?ller wrote: > Rainer M?ller wrote: [...] >> A user would only need to add this line to his .profile to load >> MacPorts: >> [ -f /opt/local/etc/profile ] && source /opt/local/etc/profile > > What is left is the caching, I would still prefer that. What is your idea as to when the cache gets updated? I have mentioned user overrides so I would want the cache function to be aware of things that might happen outside the port command like a user editing a conf file. I might not understand what you mean by caching. Since ~/.profile is only sourced when a shell is first opened is the complexity of a cache going to pay for itself? //Brad From perry at macports.org Wed Mar 18 15:57:38 2009 From: perry at macports.org (Perry Lee) Date: Wed, 18 Mar 2009 15:57:38 -0700 Subject: [48265] trunk/base/src/port1.0/portlivecheck.tcl In-Reply-To: <49C12CF3.20608@macports.org> References: <20090317233232.7134F124028F@beta.macosforge.org> <49C03FF2.5000506@macports.org> <00DCC956-4919-47E1-8A59-EAC221B11C91@macports.org> <49C0452A.2050407@macports.org> <2375EC04-0D03-4A03-810A-37FD3288CBDD@macports.org> <49C12CF3.20608@macports.org> Message-ID: <118A5C04-295A-4C48-9BFF-C7798956D64B@macports.org> On Mar 18, 2009, at 10:18 AM, David Evans wrote: > I vote to include this additional patch as part of 1.7.1 to keep the > freshmeat livechecks working as they did before the recent changes. I committed Bryan's simpler fix to make freshmeat's default livecheck.regex case-insensitive in r48310. From devans at macports.org Wed Mar 18 16:27:48 2009 From: devans at macports.org (David Evans) Date: Wed, 18 Mar 2009 16:27:48 -0700 Subject: [48265] trunk/base/src/port1.0/portlivecheck.tcl In-Reply-To: <118A5C04-295A-4C48-9BFF-C7798956D64B@macports.org> References: <20090317233232.7134F124028F@beta.macosforge.org> <49C03FF2.5000506@macports.org> <00DCC956-4919-47E1-8A59-EAC221B11C91@macports.org> <49C0452A.2050407@macports.org> <2375EC04-0D03-4A03-810A-37FD3288CBDD@macports.org> <49C12CF3.20608@macports.org> <118A5C04-295A-4C48-9BFF-C7798956D64B@macports.org> Message-ID: <49C18374.7020306@macports.org> Perry Lee wrote: > On Mar 18, 2009, at 10:18 AM, David Evans wrote: >> I vote to include this additional patch as part of 1.7.1 to keep the >> freshmeat livechecks working as they did before the recent changes. > > I committed Bryan's simpler fix to make freshmeat's default > livecheck.regex case-insensitive in r48310. > Yes, this gives the same test results and has the benefit of restricting the changes to freshmeat only. Hopefully, this can be pushed into 1.7.1. Thanks to you and Bryan for solving the problem so quickly. From jeremy at lavergne.gotdns.org Wed Mar 18 19:23:05 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 18 Mar 2009 22:23:05 -0400 Subject: [48314] trunk/base/src/port1.0/portbuild.tcl In-Reply-To: <20090319021018.4D579125671A@beta.macosforge.org> References: <20090319021018.4D579125671A@beta.macosforge.org> Message-ID: When are we going to have the mass ports-upgrade to rid ourselves of the default values that are going to be there (use_parallel_build yes)? Is it going to be scripted or will this be left to the maintainers? On Mar 18, 2009, at 10:10 PM, jmr at macports.org wrote: > Make parallel build opt-out rather than opt-in (buildmakejobs still > defaults to 1) > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Wed Mar 18 19:26:59 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 18 Mar 2009 22:26:59 -0400 Subject: [48314] trunk/base/src/port1.0/portbuild.tcl In-Reply-To: <20090319021018.4D579125671A@beta.macosforge.org> References: <20090319021018.4D579125671A@beta.macosforge.org> Message-ID: <3CF338A5-9AE8-41D5-BDEE-73C60D0C2F51@lavergne.gotdns.org> Curiously, why did we not (or have not yet) decided to use build.parallel to follow what seems to be a build.X pattern? Can build.jobs not take its place? On Mar 18, 2009, at 10:10 PM, jmr at macports.org wrote: > Revision48314Authorjmr at macports.orgDate2009-03-18 19:10:17 -0700 > (Wed, 18 Mar 2009)Log Message > Make parallel build opt-out rather than opt-in (buildmakejobs still > defaults to 1) > Modified Paths > ? trunk/base/src/port1.0/portbuild.tcl > Diff > Modified: trunk/base/src/port1.0/portbuild.tcl (48313 => 48314) > --- trunk/base/src/port1.0/portbuild.tcl 2009-03-19 00:52:26 UTC > (rev 48313) > +++ trunk/base/src/port1.0/portbuild.tcl 2009-03-19 02:10:17 UTC > (rev 48314) > @@ -43,7 +43,8 @@ > options build.nice > options build.jobs > options build.asroot > -commands build parallel_build > +options use_parallel_build > +commands build > # defaults > default build.asroot no > default build.dir {${workpath}/${worksrcdir}} > @@ -52,6 +53,7 @@ > default build.jobs {${buildmakejobs}} > default build.pre_args {${build.target}} > default build.target "all" > +default use_parallel_build yes > > set_ui_prefix > > @@ -116,9 +118,9 @@ > # check if port allows a parallel build > global use_parallel_build > if {![tbool use_parallel_build]} { > + ui_debug "port disallows a parallel build" > return "" > } > - ui_debug "port allows a parallel build" > > if {![exists build.jobs] || !([string match "*make*" [option > build.cmd]] || [string match "*scons*" [option build.cmd]])} { > return "" > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes -------------- 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 Mar 19 02:43:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 19 Mar 2009 04:43:35 -0500 Subject: [48280] trunk/dports/net/proftpd/Portfile In-Reply-To: <20090318021912.680731245449@beta.macosforge.org> References: <20090318021912.680731245449@beta.macosforge.org> Message-ID: On Mar 17, 2009, at 21:19, blb at macports.org wrote: > Revision: 48280 > http://trac.macports.org/changeset/48280 > Author: blb at macports.org > Date: 2009-03-17 19:18:50 -0700 (Tue, 17 Mar 2009) > Log Message: > ----------- > net/proftpd - version update to 1.3.2 (ticket #15046) and add > +mysql5 variant (ticket #15047) [snip] > +variant mysql5 { > + depends_lib-append port:mysql5 > + configure.args-append --with-modules=mod_sql:mod_sql_mysql \ > + --with-includes=${prefix}/include/mysql5/mysql \ > + --with-libraries=${prefix}/lib/mysql5/mysql > +} Do you have any objection to allowing mysql5-devel to satisfy the mysql5 dependency? If not, we should change "port:mysql5" to "path:bin/mysql_config5:mysql5" as other ports do. I assume the mysql5 variant conflicts with the existing mysql4 variant? If so, they should be marked as such, by replacing "variant mysql4" with "variant mysql4 conflicts mysql5" and replacing "variant mysql5" with "variant mysql5 conflicts mysql4". Both variants should also have descriptions. Please let me know if these changes are ok and I will change them. From ryandesign at macports.org Thu Mar 19 22:32:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 20 Mar 2009 00:32:29 -0500 Subject: Moving X11 install into their own subdirectory In-Reply-To: <8FCF4F42-CDA5-4AEC-8A5D-0A0E9B8142E8@macports.org> References: <49BAFC2E.7040709@orcaware.com> <7DA5E02A-6F6F-4C8E-A733-A481C7FA0D91@macports.org> <49BC1E7D.6020900@orcaware.com> <2903A083-81ED-4B7F-9FC0-41077738128B@macports.org> <49BC78D0.2020808@orcaware.com> <5E04B33A-C349-41B6-AD76-D7B12FF5A5AE@macports.org> <49BFDFF5.50604@orcaware.com> <49BFECE6.5000106@orcaware.com> <8FCF4F42-CDA5-4AEC-8A5D-0A0E9B8142E8@macports.org> Message-ID: On Mar 17, 2009, at 15:26, Jeremy Huddleston wrote: > Why not just go one step further and actually rename the dylibs > libZeroCIce.33.dylib and libZeroCIce.3.3.0.dylib? That seems > safer, easier, and less confusing. +1. Seems that way to me too. From jeremy at lavergne.gotdns.org Fri Mar 20 07:21:34 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 20 Mar 2009 10:21:34 -0400 Subject: reinplace question Message-ID: If I want to append a space and ampersand at the end of a known line, what's the way to write this in reinplace? I tried (without success): reinplace s|psppire|psppire &|g reinplace s|psppire|psppire\ &|g reinplace s|psppire|psppire\ \&|g Any suggestions? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From raimue at macports.org Fri Mar 20 08:06:30 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 20 Mar 2009 16:06:30 +0100 Subject: reinplace question In-Reply-To: References: Message-ID: <49C3B0F6.9050003@macports.org> Jeremy Lavergne wrote: > If I want to append a space and ampersand at the end of a known line, > what's the way to write this in reinplace? > > I tried (without success): > reinplace s|psppire|psppire &|g > reinplace s|psppire|psppire\ &|g > reinplace s|psppire|psppire\ \&|g > > Any suggestions? You have to quote the replace pattern, otherwise &|g is interpreted as a filename. reinplace "s|psppire|psppire &|g" ... Rainer From brad at pixilla.com Fri Mar 20 08:45:20 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Fri, 20 Mar 2009 08:45:20 -0700 Subject: reinplace question In-Reply-To: References: Message-ID: <8368B141-6D9A-4397-9ACD-866A146C6FC9@pixilla.com> On Mar 20, 2009, at 7:21 AM, Jeremy Lavergne wrote: > If I want to append a space and ampersand at the end of a known > line, what's the way to write this in reinplace? > > I tried (without success): > reinplace s|psppire|psppire &|g > reinplace s|psppire|psppire\ &|g > reinplace s|psppire|psppire\ \&|g > > Any suggestions? Keep adding backslashes. This is what I ended up with to escape double quotes. I'm sure someone here will show me a better way. set CCARGS [concat ${CCARGS} -DUSE_SASL_AUTH - DDEF_SERVER_SASL_TYPE=\\\\\\"dovecot\\\\\\"] //Brad From jmpp at macports.org Fri Mar 20 09:55:15 2009 From: jmpp at macports.org (Juan Manuel Palacios) Date: Fri, 20 Mar 2009 12:25:15 -0430 Subject: [48379] trunk/dports/ruby/rb-cocoa/Portfile In-Reply-To: <20090320091309.AC31512977F2@beta.macosforge.org> References: <20090320091309.AC31512977F2@beta.macosforge.org> Message-ID: <5587710D-3630-4780-A5AF-CB50DA555C79@macports.org> On Mar 20, 2009, at 4:43 AM, kimuraw at macports.org wrote: > Modified: trunk/dports/ruby/rb-cocoa/Portfile (48378 => 48379) > > --- trunk/dports/ruby/rb-cocoa/Portfile 2009-03-20 07:55:52 UTC (rev > 48378) > +++ trunk/dports/ruby/rb-cocoa/Portfile 2009-03-20 09:13:09 UTC (rev > 48379) > @@ -32,6 +32,7 @@ > --install-root=${destroot} \ > --documentation=${prefix}/share/doc/${name} \ > --examples=${prefix}/share/examples/${name} > +destroot.violate_mtree yes > > platform darwin 9 { > if {![variant_isset universal]} { > @@ -39,6 +40,13 @@ > } > } > > +# by default, do not install Xcode templates. #18708 > +variant xcode description {install project templates for Xcode} { } > +if {![variant_isset xcode]} { > + configure.args-append \ > + --xcode-extras="${prefix}/share/doc/${name}/project-templates" > +} > + > post-extract { > system "find \"${worksrcpath}\" -type d -name '.svn' | xargs /bin/ > rm -rf" > } Why put that configure.args modifier line outside the corresponding variant block if it's meant to be called only when the variant is selected? Something like the following should work, unless there's something obvious I'm missing: variant xcode description {blah blah blah} { configure.args-append --xcode-extras=${prefix}/share/doc/${name}/ project-templates } Also note that I don't use quotes around the argument to the xcode- extras flag, I hardly think they're necessary. Lastly... does that really violate the mtree? I doubt that too, since ${prefix}/share/doc/$ {name} is within the mtree, if I'm not mistaken. Regards,... -jmpp -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimue at macports.org Fri Mar 20 10:14:04 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Fri, 20 Mar 2009 18:14:04 +0100 Subject: [48384] trunk/base/src/port1.0/portutil.tcl In-Reply-To: <20090320165208.AF7B912A05D1@beta.macosforge.org> References: <20090320165208.AF7B912A05D1@beta.macosforge.org> Message-ID: <49C3CEDC.2010800@macports.org> raimue at macports.org wrote: > Revision: 48384 > http://trac.macports.org/changeset/48384 > Author: raimue at macports.org > Date: 2009-03-20 09:52:08 -0700 (Fri, 20 Mar 2009) > Log Message: > ----------- > port1.0/portutil.tcl: > New handle_option-replace proc which allows to apply strsed on an option > > Modified Paths: > -------------- > trunk/base/src/port1.0/portutil.tcl > [...] A little bit of explanation on this commit. We often have stuff like the following lines in our Portfiles, especially in variants: configure.args-delete --disable-foo configure.args-append --enable-foo Writing these lines is cumbersome in my opinion. So I created a similar *-replace which allows to apply strsed replaces on an option: configure.args-replace s/--disable-foo/--enable-foo/ Note this is not real sed, only a small subset is supported (lacking documentation). You can only do "s/foo/bar/" which replaces a single instance of the search pattern or "g/foo/bar/" to make the replace global, i.e. apply on all occurrences. It is also possible to leave out 's' or 'g' which behaves like 's', but can also be used for deletes like "/foo/". The delimiter, which is "/" above, can be chosen freely. If you want to play with strsed or test your replaces do what you expect, use [1]. I hope Portfile authors will find *-replace as useful as I do. Rainer [1] http://trac.macports.org/wiki/CommittersTipsAndTricks#DoExplorativeProgrammingintclshwithReadlineSupport From raimue at macports.org Fri Mar 20 10:27:46 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 20 Mar 2009 18:27:46 +0100 Subject: reinplace question In-Reply-To: <49C3B0F6.9050003@macports.org> References: <49C3B0F6.9050003@macports.org> Message-ID: <49C3D212.8000003@macports.org> Rainer M?ller wrote: > You have to quote the replace pattern, otherwise &|g is interpreted as a > filename. > > reinplace "s|psppire|psppire &|g" ... And please note that & does not do here what it usually does with sed. It will not be replaced with the matched pattern. But this just as a side-note. Rainer From raimue at macports.org Fri Mar 20 10:34:48 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 20 Mar 2009 18:34:48 +0100 Subject: reinplace question In-Reply-To: <49C3D212.8000003@macports.org> References: <49C3B0F6.9050003@macports.org> <49C3D212.8000003@macports.org> Message-ID: <49C3D3B8.8040509@macports.org> Rainer M?ller wrote: > Rainer M?ller wrote: > >> You have to quote the replace pattern, otherwise &|g is interpreted as a >> filename. >> >> reinplace "s|psppire|psppire &|g" ... > > And please note that & does not do here what it usually does with sed. > It will not be replaced with the matched pattern. But this just as a > side-note. Gnah, sorry, ignore and discard this reply above. I meant to write a reply to my other mail. reinplace uses standard sed as available on your system and & works here as usual. So for a literal & you have to escape it. Rainer From raimue at macports.org Fri Mar 20 10:38:46 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 20 Mar 2009 18:38:46 +0100 Subject: [48384] trunk/base/src/port1.0/portutil.tcl In-Reply-To: <49C3CEDC.2010800@macports.org> References: <20090320165208.AF7B912A05D1@beta.macosforge.org> <49C3CEDC.2010800@macports.org> Message-ID: <49C3D4A6.4060803@macports.org> Rainer M?ller wrote: > Note this is not real sed, only a small subset is supported (lacking > documentation). You can only do "s/foo/bar/" which replaces a single > instance of the search pattern or "g/foo/bar/" to make the replace > global, i.e. apply on all occurrences. It is also possible to leave out > 's' or 'g' which behaves like 's', but can also be used for deletes like > "/foo/". The delimiter, which is "/" above, can be chosen freely. If you > want to play with strsed or test your replaces do what you expect, use [1]. And now what I intended to write here but replied to the wrong mail first: Please note that & does not do here what it usually does with sed. It will not be replaced with the matched pattern, but treated as a regular character. It's also not possible to use other back-references like \1 etc. Rainer From vincent-opdarw at vinc17.org Fri Mar 20 16:17:24 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Sat, 21 Mar 2009 00:17:24 +0100 Subject: perl5.8 fixup In-Reply-To: <20090312232215.GI10906@darkart.com> References: <20090309225551.GU27410@darkart.com> <20090310010129.GW27410@darkart.com> <20090310195714.GA10906@darkart.com> <20090311002402.GG10906@darkart.com> <27ABB9C8-6701-4F51-822B-56206C0FB14B@pixilla.com> <20090312232215.GI10906@darkart.com> Message-ID: <20090320231724.GA7603@prunille.vinc17.org> On 2009-03-12 23:22:15 +0000, Eric Hall wrote: > Again, see /etc/man.conf, in particular the MANSECT line. But if you're using "man" from MacPorts, the config file is: /opt/local/etc/man.conf -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From vincent-opdarw at vinc17.org Fri Mar 20 16:31:22 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Sat, 21 Mar 2009 00:31:22 +0100 Subject: perl5.8 fixup In-Reply-To: References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <49BDE0F2.6060701@macports.org> Message-ID: <20090320233122.GH22844@prunille.vinc17.org> On 2009-03-16 09:33:18 -0700, Bradley Giesbrecht wrote: > This could be good. Just not have perl5.8 install man pages. If perl > users don't use them why waste effort. I frequently use the Perl-related man pages. In practice, for the modules, they give the same information as perldoc (when the installation is correct). BTW "man" is faster to type and has completion in zsh (perldoc doesn't). -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From vincent-opdarw at vinc17.org Fri Mar 20 16:36:27 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Sat, 21 Mar 2009 00:36:27 +0100 Subject: perl5.8 fixup In-Reply-To: <8E9161D6-7F54-4BAE-96EF-B1A860CC2CF5@pixilla.com> References: <76FE6EBD-004C-4441-97BD-F98FC3B1E699@pixilla.com> <49BDE0F2.6060701@macports.org> <49BE9047.8090806@macports.org> <8E9161D6-7F54-4BAE-96EF-B1A860CC2CF5@pixilla.com> Message-ID: <20090320233627.GI22844@prunille.vinc17.org> On 2009-03-16 15:07:19 -0700, Bradley Giesbrecht wrote: > I tried this earlier using > ./Configure ... -man1ext=1perl5.8 -man3ext=3perl5.8 I don't think it is a good idea to use a dot in the extension, as this can be very confusing (this would probably make completion fail or behave in a strange way). -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From raimue at macports.org Fri Mar 20 18:25:33 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 21 Mar 2009 02:25:33 +0100 Subject: reinplace question In-Reply-To: <8368B141-6D9A-4397-9ACD-866A146C6FC9@pixilla.com> References: <8368B141-6D9A-4397-9ACD-866A146C6FC9@pixilla.com> Message-ID: <49C4420D.7010100@macports.org> Bradley Giesbrecht wrote: > This is what I ended up with to escape double quotes. I'm sure someone > here will show me a better way. > > set CCARGS [concat ${CCARGS} -DUSE_SASL_AUTH - > DDEF_SERVER_SASL_TYPE=\\\\\\"dovecot\\\\\\"] First, there is usually no need to do: set foo [concat $foo bar] You can use append for strings and lappend for lists instead: lappend foo bar In this specific case, I don't know why you had to put that many backslashes there. How is it used further? It can also end in funny results if you try to use a list as a string without using join. See this short tclsh example for the difference: $ tclsh % set foo "bar" bar % lappend foo baz="qux" bar baz=\"qux\" % puts $foo bar baz=\"qux\" % puts [join $foo] bar baz="qux" The last thing is probably what you expected here. Rainer From kimuraw at macports.org Fri Mar 20 20:11:05 2009 From: kimuraw at macports.org (kimura wataru) Date: Sat, 21 Mar 2009 12:11:05 +0900 Subject: [48379] trunk/dports/ruby/rb-cocoa/Portfile In-Reply-To: <5587710D-3630-4780-A5AF-CB50DA555C79@macports.org> References: <20090320091309.AC31512977F2@beta.macosforge.org> <5587710D-3630-4780-A5AF-CB50DA555C79@macports.org> Message-ID: <20090321121105458743.ae1ccdef@macports.org> Hi, (1)configure.args append --xcode-extras to configure.args when +xcode is NOT selected. I means ---- configure.args --install-prefix=${destroot}${prefix} \ --install-root=${destroot} \ --documentation=${prefix}/share/doc/${name} \ --examples=${prefix}/share/examples/${name} \ --xcode-extras="${prefix}/share/doc/${name}/project-templates" variant xcode description {install project templates for Xcode} { configure.args-delete \ --xcode-extras="${prefix}/share/doc/${name}/project-templates" } ---- (2)violate_mtree rb-cocoa installes /Library/Frameworks/RubyCocoa.framework whether +xcode/-xcode. I think destroot.violate_mtree is needed. thanks, On Fri, 20 Mar 2009 12:25:15 -0430, Juan Manuel Palacios wrote: > > On Mar 20, 2009, at 4:43 AM, kimuraw at macports.org wrote: > >> Modified: trunk/dports/ruby/rb-cocoa/Portfile (48378 => 48379) >> >> --- trunk/dports/ruby/rb-cocoa/Portfile 2009-03-20 07:55:52 UTC (rev 48378) >> +++ trunk/dports/ruby/rb-cocoa/Portfile 2009-03-20 09:13:09 UTC (rev 48379) >> @@ -32,6 +32,7 @@ >> --install-root=${destroot} \ >> --documentation=${prefix}/share/doc/${name} \ >> --examples=${prefix}/share/examples/${name} >> +destroot.violate_mtree yes >> >> platform darwin 9 { >> if {![variant_isset universal]} { >> @@ -39,6 +40,13 @@ >> } >> } >> >> +# by default, do not install Xcode templates. #18708 >> +variant xcode description {install project templates for Xcode} { } >> +if {![variant_isset xcode]} { >> + configure.args-append \ >> + --xcode-extras="${prefix}/share/doc/${name}/project-templates" >> +} >> + >> post-extract { >> system "find \"${worksrcpath}\" -type d -name '.svn' | xargs >> /bin/rm -rf" >> } > > > Why put that configure.args modifier line outside the corresponding > variant block if it's meant to be called only when the variant is > selected? Something like the following should work, unless there's > something obvious I'm missing: > > variant xcode description {blah blah blah} { > configure.args-append > --xcode-extras=${prefix}/share/doc/${name}/project-templates > } > > Also note that I don't use quotes around the argument to the > xcode-extras flag, I hardly think they're necessary. Lastly... does > that really violate the mtree? I doubt that too, since > ${prefix}/share/doc/${name} is within the mtree, if I'm not mistaken. > > Regards,... > > > -jmpp > -- kimura wataru From ryandesign at macports.org Fri Mar 20 22:03:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 21 Mar 2009 00:03:08 -0500 Subject: [48379] trunk/dports/ruby/rb-cocoa/Portfile In-Reply-To: <20090320091309.AC31512977F2@beta.macosforge.org> References: <20090320091309.AC31512977F2@beta.macosforge.org> Message-ID: <1DCB5525-060A-41EC-B85B-F0E596FF8597@macports.org> On Mar 20, 2009, at 04:13, kimuraw at macports.org wrote: > Revision: 48379 > http://trac.macports.org/changeset/48379 > Author: kimuraw at macports.org > Date: 2009-03-20 02:13:09 -0700 (Fri, 20 Mar 2009) > Log Message: > ----------- > ruby/rb-cocoa: fix #18708, add a variant "xcode". > > Modified Paths: > -------------- > trunk/dports/ruby/rb-cocoa/Portfile > > Modified: trunk/dports/ruby/rb-cocoa/Portfile > =================================================================== > --- trunk/dports/ruby/rb-cocoa/Portfile 2009-03-20 07:55:52 UTC > (rev 48378) > +++ trunk/dports/ruby/rb-cocoa/Portfile 2009-03-20 09:13:09 UTC > (rev 48379) > @@ -32,6 +32,7 @@ > --install-root=${destroot} \ > --documentation=${prefix}/share/doc/${name} \ > --examples=${prefix}/share/examples/${name} > +destroot.violate_mtree yes What part of the port violates the mtree? Is it only the newly-added xcode variant? If so, put the "destroot.violate_mtree yes" directive inside the xcode variant. > +# by default, do not install Xcode templates. #18708 > +variant xcode description {install project templates for Xcode} { } > +if {![variant_isset xcode]} { > + configure.args-append \ > + --xcode-extras="${prefix}/share/doc/${name}/project-templates" > +} From ryandesign at macports.org Sat Mar 21 00:31:37 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 21 Mar 2009 02:31:37 -0500 Subject: [48314] trunk/base/src/port1.0/portbuild.tcl In-Reply-To: References: <20090319021018.4D579125671A@beta.macosforge.org> Message-ID: <32D19398-DAD0-40C4-BCE9-91DE3B8B121F@macports.org> On Mar 18, 2009, at 21:23, Jeremy Lavergne wrote: > On Mar 18, 2009, at 10:10 PM, jmr at macports.org wrote: > >> Make parallel build opt-out rather than opt-in (buildmakejobs >> still defaults to 1) Joshua, can you add something to the ChangeLog about this change? > When are we going to have the mass ports-upgrade to rid ourselves > of the default values that are going to be there > (use_parallel_build yes)? Is it going to be scripted or will this > be left to the maintainers? It can't happen until a version of MacPorts with this change is released, which I guess will be 1.8.0. We can discus it after then. A single mass-update by a MacPorts mgr would be fine. On Mar 18, 2009, at 21:26, Jeremy Lavergne wrote: > Curiously, why did we not (or have not yet) decided to use > build.parallel to follow what seems to be a build.X pattern? I don't know. > Can build.jobs not take its place? Well, build.jobs is set by MacPorts base and is influenced by macports.conf, so you can either set build.jobs in macports.conf to a number of jobs you want, or you can set it to 0 to have MacPorts use the number of available cores. I would prefer to delete use_parallel_build and replace it with a setting like build.max_jobs which would default to build.jobs (or to maxint or some large number). This way, individual ports can set build.max_jobs to 1 if they do not support parallel build, or set it to some higher value if they are known to be able to build in parallel with, say, 2 parallel jobs but are known to fail with 3 or more. We could leave use_parallel_build around for a version or two and just mark it deprecated, using the newly-revived option deprecation feature. From jmr at macports.org Sat Mar 21 03:15:42 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 21 Mar 2009 21:15:42 +1100 Subject: [48314] trunk/base/src/port1.0/portbuild.tcl In-Reply-To: <32D19398-DAD0-40C4-BCE9-91DE3B8B121F@macports.org> References: <20090319021018.4D579125671A@beta.macosforge.org> <32D19398-DAD0-40C4-BCE9-91DE3B8B121F@macports.org> Message-ID: <49C4BE4E.5090509@macports.org> Ryan Schmidt wrote: > On Mar 18, 2009, at 21:23, Jeremy Lavergne wrote: >> When are we going to have the mass ports-upgrade to rid ourselves of >> the default values that are going to be there (use_parallel_build >> yes)? Is it going to be scripted or will this be left to the >> maintainers? > > It can't happen until a version of MacPorts with this change is > released, which I guess will be 1.8.0. We can discus it after then. A > single mass-update by a MacPorts mgr would be fine. We don't necessarily have to do that. It isn't hurting anything, and could serve as documentation that parallel build has been tested. - Josh From ryandesign at macports.org Sat Mar 21 04:03:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 21 Mar 2009 06:03:42 -0500 Subject: [48307] trunk/dports/science/qucs In-Reply-To: <20090318210808.3FF1D1250F78@beta.macosforge.org> References: <20090318210808.3FF1D1250F78@beta.macosforge.org> Message-ID: On Mar 18, 2009, at 16:08, rowue at macports.org wrote: > +patchfiles patch-configure.diff > +post-destroot { > + xinstall -m 755 -d ${destroot}/Applications/MacPorts/Qucs.app/ > Contents/MacOS > + ln -s ${prefix}/bin/qucs ${destroot}/Applications/MacPorts/ > Qucs.app/Contents/MacOS/Qucs > +} Please use ${applications_dir} instead of /Applications/MacPorts. > Added: trunk/dports/science/qucs/files/patch-configure.diff > =================================================================== > --- trunk/dports/science/qucs/files/patch- > configure.diff (rev 0) > +++ trunk/dports/science/qucs/files/patch-configure.diff 2009-03-18 > 21:08:07 UTC (rev 48307) > @@ -0,0 +1,11 @@ > +--- configure.orig 2008-04-10 15:21:51.000000000 +0200 > ++++ configure 2009-03-18 21:28:50.000000000 +0100 > +@@ -6005,7 +6005,7 @@ > + paths="$QTDIR/include /usr/local/qt/include /usr/include/qt /usr/ > include/qt3 \ > + /usr/include /usr/X11R6/include/X11/qt /usr/X11R6/include/X11/qt \ > + /usr/X11R6/include/qt /usr/X11R6/include /sw/include/qt \ > +- /usr/X11R6/include/qt2" > ++ /usr/X11R6/include/qt2 /opt/local/include/qt3" > + for path in $paths; do > + if test -f "$path/qapplication.h"; then > + QT_INCLUDES=$path You mustn't hardcode /opt/local into your patches since MacPorts could be installed in a different prefix. From brad at pixilla.com Sat Mar 21 09:08:02 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sat, 21 Mar 2009 09:08:02 -0700 Subject: reinplace question In-Reply-To: <49C4420D.7010100@macports.org> References: <8368B141-6D9A-4397-9ACD-866A146C6FC9@pixilla.com> <49C4420D.7010100@macports.org> Message-ID: <709DB994-0419-4FD9-A82C-2950A415A6C8@pixilla.com> On Mar 20, 2009, at 6:25 PM, Rainer M?ller wrote: > Bradley Giesbrecht wrote: >> This is what I ended up with to escape double quotes. I'm sure >> someone >> here will show me a better way. >> >> set CCARGS [concat ${CCARGS} -DUSE_SASL_AUTH - >> DDEF_SERVER_SASL_TYPE=\\\\\\"dovecot\\\\\\"] > > First, there is usually no need to do: > set foo [concat $foo bar] > You can use append for strings and lappend for lists instead: > lappend foo bar > > In this specific case, I don't know why you had to put that many > backslashes there. How is it used further? > > It can also end in funny results if you try to use a list as a string > without using join. See this short tclsh example for the difference: > > $ tclsh > % set foo "bar" > bar > % lappend foo baz="qux" > bar baz=\"qux\" > % puts $foo > bar baz=\"qux\" Thank you. This is what I needed, a backslash doublequote \". I'm adding dovecot_sasl variant to my local postfix. The existing Portfile uses a lot of concat so I just rolled with it. % set CCARGS "-DSOMETHING" -DSOMETHING % append CCARGS \ -DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\\"dovecot\\" -DSOMETHING -DUSE_SASL_AUTH-DDEF_SERVER_SASL_TYPE=\"dovecot\" Portfile: variant dovecot_sasl description "add Dovecot SASL support " { append CCARGS \ -DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\\"dovecot\ \" } //Brad From mcalhoun at macports.org Sat Mar 21 19:34:10 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Sun, 22 Mar 2009 02:34:10 +0000 (UTC) Subject: Is isysroot useful for non-universal? Message-ID: It is mentioned in http://trac.macports.org/ticket/17356#comment:6 that universal builds do not suffer from bad .la files because of -isysroot. Perhaps -isysroot could be used to solve other problems as well. If I understand the behavior, any compiler call with -isysroot would not see /usr/local/include. It also does not see any changes the user might have made. -Wl,-syslibroot,${SDK} might be used in a similar manner (for user changes anyway). It would still see /use/local/lib since /Developer/SDKs/*/usr/local/lib exists and is a link to /usr/local/lib. One big downside is that the Apple developer pages say that support of isysroot "is likely to change in the future. " Even still, might isysroot and syslibroot be used to cut down on bug reports? -Marcus From ryandesign at macports.org Sat Mar 21 21:29:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 21 Mar 2009 23:29:13 -0500 Subject: Is isysroot useful for non-universal? In-Reply-To: References: Message-ID: On Mar 21, 2009, at 21:34, Marcus Calhoun-Lopez wrote: > It is mentioned in http://trac.macports.org/ticket/17356#comment:6 > that universal builds do not suffer from bad .la files because of - > isysroot. That ticket specifically talks about bad .la files installed by some Apple software, relating to X11. We should not need workarounds in MacPorts for these bad files. Apple should distribute software updates to fix the bad files they installed. Further, this specific problem is no longer observed for the majority of users who will presumably not have selected the +system_x11 variant. > Perhaps -isysroot could be used to solve other problems as well. What kinds of problems? Do you mean those kinds of problems that arise from the user installing things in /usr/local and MacPorts- installed software inadvertently linking with it? > If I understand the behavior, any compiler call with > -isysroot would not see /usr/local/include. From where do you get that understanding? Is this from the fact that there is no /Developer/SDKs/*/usr/local/include? Any documentation you have on -isysroot would be helpful; I know nothing about it other than the way in which Apple says to use it for building a universal binary. > It also does not see any changes the user might have made. What kinds of changes are you talking about? Do you mean rogue software installed by the user in system prefixes like / and /usr? I suppose this would help MacPorts avoid linking with additional software the user has installed there. I don't see it helping if the user has replaced existing software. > -Wl,-syslibroot,${SDK} might be used in a similar manner > (for user changes anyway). > It would still see /use/local/lib since > /Developer/SDKs/*/usr/local/lib exists and is a link to /usr/local/ > lib. I see. > One big downside is that the Apple developer pages say that > support of isysroot "is likely to change in the future. " > > Even still, might isysroot and syslibroot be used to cut down on > bug reports? From mcalhoun at macports.org Sat Mar 21 22:03:47 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Sun, 22 Mar 2009 05:03:47 +0000 (UTC) Subject: Is isysroot useful for non-universal? References: Message-ID: Ryan Schmidt writes: > > > On Mar 21, 2009, at 21:34, Marcus Calhoun-Lopez wrote: > > > It is mentioned in http://trac.macports.org/ticket/17356#comment:6 > > that universal builds do not suffer from bad .la files because of - > > isysroot. > > That ticket specifically talks about bad .la files installed by some > Apple software, relating to X11. We should not need workarounds in > MacPorts for these bad files. Apple should distribute software > updates to fix the bad files they installed. Further, this specific > problem is no longer observed for the majority of users who will > presumably not have selected the +system_x11 variant. Sorry, I was not suggesting a workaround for this particular problem. I was making the point that isysroot would have been useful when the problem first arose. > > Perhaps -isysroot could be used to solve other problems as well. > > What kinds of problems? Do you mean those kinds of problems that > arise from the user installing things in /usr/local and MacPorts- > installed software inadvertently linking with it? ... > > It also does not see any changes the user might have made. > > What kinds of changes are you talking about? Do you mean rogue > software installed by the user in system prefixes like / and /usr? I > suppose this would help MacPorts avoid linking with additional > software the user has installed there. I don't see it helping if the > user has replaced existing software. Yes, I was thinking of unsupported configurations. It seems that, with some regularity, reported problems can be traced to /usr/local or some other installed software. I was thinking that we could reduce the time spent tracking down these problems with isysroot and syslibroot. > > > If I understand the behavior, any compiler call with > > -isysroot would not see /usr/local/include. > > From where do you get that understanding? Is this from the fact that > there is no /Developer/SDKs/*/usr/local/include? Any documentation > you have on -isysroot would be helpful; I know nothing about it other > than the way in which Apple says to use it for building a universal > binary. The documentation on isysroot seems a little sparse. According to the cross development documents, isysrtoot is not even in the man pages because "this feature is likely to change in the future." So my somewhat limited knowledge is from experiments. As I understand it, -isysroot /Developer/SDKs/MacOSX10.5.sdk treats /Developer/SDKs/MacOSX10.5.sdk/ as / when it comes to includes. So it won't find anything in /usr/local/include because /Developer/SDKs/MacOSX10.5.sdk/usr/local/include does not exist. -Marcus -Marcus From ryandesign at macports.org Sat Mar 21 23:35:52 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Mar 2009 01:35:52 -0500 Subject: [48432] trunk/dports/irc/irssi-devel/Portfile In-Reply-To: <20090321234843.A22B512B5110@beta.macosforge.org> References: <20090321234843.A22B512B5110@beta.macosforge.org> Message-ID: <9F14C83C-8230-4397-ACA6-E45376B62AAF@macports.org> On Mar 21, 2009, at 18:48, blb at macports.org wrote: > Revision: 48432 > http://trac.macports.org/changeset/48432 > Author: blb at macports.org > Date: 2009-03-21 16:48:43 -0700 (Sat, 21 Mar 2009) > Log Message: > ----------- > irc/irssi-devel - use svn.revision on MacPorts 1.8 > > Modified Paths: > -------------- > trunk/dports/irc/irssi-devel/Portfile > > Modified: trunk/dports/irc/irssi-devel/Portfile > =================================================================== > --- trunk/dports/irc/irssi-devel/Portfile 2009-03-21 23:38:12 UTC > (rev 48431) > +++ trunk/dports/irc/irssi-devel/Portfile 2009-03-21 23:48:43 UTC > (rev 48432) > @@ -18,7 +18,12 @@ > homepage http://irssi.org/ > fetch.type svn > svn.url http://svn.irssi.org/repos/irssi/trunk > -svn.tag ${version} > +# When 1.8 is released, svn.revision can be set without the if{} > +if {[info exists svn.revision]} { > + svn.revision ${version} > +} else { > + svn.tag ${version} > +} Why bother to make this change now when you'll change it again after 1.8 is released? Why not just leave it as is until after 1.8 is released? From ryandesign at macports.org Sat Mar 21 23:43:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Mar 2009 01:43:35 -0500 Subject: Is isysroot useful for non-universal? In-Reply-To: References: Message-ID: On Mar 22, 2009, at 00:03, Marcus Calhoun-Lopez wrote: > Ryan Schmidt writes: > >> On Mar 21, 2009, at 21:34, Marcus Calhoun-Lopez wrote: >> >>> It is mentioned in http://trac.macports.org/ticket/17356#comment:6 >>> that universal builds do not suffer from bad .la files because of - >>> isysroot. >> >> That ticket specifically talks about bad .la files installed by some >> Apple software, relating to X11. We should not need workarounds in >> MacPorts for these bad files. Apple should distribute software >> updates to fix the bad files they installed. Further, this specific >> problem is no longer observed for the majority of users who will >> presumably not have selected the +system_x11 variant. > > Sorry, I was not suggesting a workaround for this particular problem. > I was making the point that isysroot would have been useful > when the problem first arose. > >>> Perhaps -isysroot could be used to solve other problems as well. >> >> What kinds of problems? Do you mean those kinds of problems that >> arise from the user installing things in /usr/local and MacPorts- >> installed software inadvertently linking with it? > ... >>> It also does not see any changes the user might have made. >> >> What kinds of changes are you talking about? Do you mean rogue >> software installed by the user in system prefixes like / and /usr? I >> suppose this would help MacPorts avoid linking with additional >> software the user has installed there. I don't see it helping if the >> user has replaced existing software. > > Yes, I was thinking of unsupported configurations. > It seems that, with some regularity, reported problems can > be traced to /usr/local or some other installed software. > I was thinking that we could reduce the time spent tracking > down these problems with isysroot and syslibroot. > >> >>> If I understand the behavior, any compiler call with >>> -isysroot would not see /usr/local/include. >> >> From where do you get that understanding? Is this from the fact that >> there is no /Developer/SDKs/*/usr/local/include? Any documentation >> you have on -isysroot would be helpful; I know nothing about it other >> than the way in which Apple says to use it for building a universal >> binary. > > The documentation on isysroot seems a little sparse. > According to the cross development documents, isysrtoot is not > even in the man pages because "this feature is likely to change in > the future." > So my somewhat limited knowledge is from experiments. > As I understand it, -isysroot /Developer/SDKs/MacOSX10.5.sdk > treats /Developer/SDKs/MacOSX10.5.sdk/ as / when it comes to includes. > So it won't find anything in /usr/local/include because > /Developer/SDKs/MacOSX10.5.sdk/usr/local/include > does not exist. Probably what one should do, then, is to dig up some of the tickets where software in /usr/local was deemed to be the cause of the problem, recreate the issue on a machine, and then change MacPorts to use isysroot and/or syslibroot and see if it avoids the problem. From blb at macports.org Sun Mar 22 00:31:06 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 22 Mar 2009 01:31:06 -0600 Subject: [48432] trunk/dports/irc/irssi-devel/Portfile In-Reply-To: <9F14C83C-8230-4397-ACA6-E45376B62AAF@macports.org> References: <20090321234843.A22B512B5110@beta.macosforge.org> <9F14C83C-8230-4397-ACA6-E45376B62AAF@macports.org> Message-ID: <20090322073106.GA8488@ninagal.withay.com> On Sun, Mar 22, 2009 at 01:35:52AM -0500, Ryan Schmidt said: > On Mar 21, 2009, at 18:48, blb at macports.org wrote: [...] >> @@ -18,7 +18,12 @@ >> homepage http://irssi.org/ >> fetch.type svn >> svn.url http://svn.irssi.org/repos/irssi/trunk >> -svn.tag ${version} >> +# When 1.8 is released, svn.revision can be set without the if{} >> +if {[info exists svn.revision]} { >> + svn.revision ${version} >> +} else { >> + svn.tag ${version} >> +} > > Why bother to make this change now when you'll change it again after 1.8 > is released? Why not just leave it as is until after 1.8 is released? Partly a reminder, partly to quiet the warning about it being deprecated. Bryan From dluke at geeklair.net Sun Mar 22 13:11:06 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Sun, 22 Mar 2009 16:11:06 -0400 Subject: Is isysroot useful for non-universal? In-Reply-To: References: Message-ID: On Mar 22, 2009, at 2:43 AM, Ryan Schmidt wrote: >> The documentation on isysroot seems a little sparse. >> According to the cross development documents, isysrtoot is not >> even in the man pages because "this feature is likely to change in >> the future." >> So my somewhat limited knowledge is from experiments. >> As I understand it, -isysroot /Developer/SDKs/MacOSX10.5.sdk >> treats /Developer/SDKs/MacOSX10.5.sdk/ as / when it comes to >> includes. >> So it won't find anything in /usr/local/include because >> /Developer/SDKs/MacOSX10.5.sdk/usr/local/include >> does not exist. > > Probably what one should do, then, is to dig up some of the tickets > where software in /usr/local was deemed to be the cause of the > problem, recreate the issue on a machine, and then change MacPorts > to use isysroot and/or syslibroot and see if it avoids the problem. note that we'd need to use autoconf to check for the location of the SDK (if we don't already) since it doesn't have to be installed at / Developer/SDKs on 10.5. Also, the last time I checked, with isysroot you only get the stuff in the SDK so while it would fix looking in /usr/local, it would also prevent looking in ${prefix} for headers and libraries, which we don't want. There may be a way to work-around that though. We probalby want to eventually use -nostdinc and -nostdlib plus adding back all of the paths that don't include /usr/local to fix the /usr/ local searching issue. -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From raimue at macports.org Sun Mar 22 13:58:55 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 22 Mar 2009 21:58:55 +0100 Subject: Is isysroot useful for non-universal? In-Reply-To: References: Message-ID: <49C6A68F.1010800@macports.org> Daniel J. Luke wrote: > We probalby want to eventually use -nostdinc and -nostdlib plus adding > back all of the paths that don't include /usr/local to fix the /usr/ > local searching issue. I don't think -nostdlib really does what you assume. It removes the standard libraries which are linked, such as the libgcc.a library. We would have to call it like: gcc -nostdlib ... foo.o bar.o ... $(gcc -print-libgcc-file-name) Order matters here, so we can't put libgcc.a at the top. And we don't want to patch each gcc call in all Makefiles :-) The man page does not talk about "standard search paths", so I am not even sure this affects -L and -l at all. Rainer From mcalhoun at macports.org Sun Mar 22 14:25:51 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Sun, 22 Mar 2009 21:25:51 +0000 (UTC) Subject: Is isysroot useful for non-universal? References: Message-ID: Daniel J. Luke writes: > Also, the last time I checked, with isysroot you only get the stuff in > the SDK so while it would fix looking in /usr/local, it would also > prevent looking in ${prefix} for headers and libraries, which we don't > want. There may be a way to work-around that though. Based solely on my own experiments -isystem does not affect -I${prefix}/include. From dluke at geeklair.net Sun Mar 22 15:01:24 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Sun, 22 Mar 2009 18:01:24 -0400 Subject: Is isysroot useful for non-universal? In-Reply-To: <49C6A68F.1010800@macports.org> References: <49C6A68F.1010800@macports.org> Message-ID: On Mar 22, 2009, at 4:58 PM, Rainer M?ller wrote: > Daniel J. Luke wrote: >> We probalby want to eventually use -nostdinc and -nostdlib plus >> adding >> back all of the paths that don't include /usr/local to fix the /usr/ >> local searching issue. > > I don't think -nostdlib really does what you assume. It removes the > standard libraries which are linked, such as the libgcc.a library. > > We would have to call it like: > gcc -nostdlib ... foo.o bar.o ... $(gcc -print-libgcc-file-name) > > Order matters here, so we can't put libgcc.a at the top. And we don't > want to patch each gcc call in all Makefiles :-) > > The man page does not talk about "standard search paths", so I am not > even sure this affects -L and -l at all. oh :-\ I was thinking it was the mirror of -nostdinc (without looking at it further). -nostdinc isn't useful by itself if we can't also prevent liking to things in /usr/local/ Looks like ld has -Z which we could perhaps use (and then add back some of the standard search paths) Maybe tracemode (or something like it) could be adapted to be on by default to fix this then? -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From ryandesign at macports.org Sun Mar 22 15:27:15 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Mar 2009 17:27:15 -0500 Subject: [48460] trunk/dports/science In-Reply-To: <20090322213942.33A6512BFF4E@beta.macosforge.org> References: <20090322213942.33A6512BFF4E@beta.macosforge.org> Message-ID: On Mar 22, 2009, at 16:39, blb at macports.org wrote: > +master_sites http://downloads.sourceforge.net/viking/ Could this be changed to master_sites sourceforge From ryandesign at macports.org Sun Mar 22 15:29:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Mar 2009 17:29:02 -0500 Subject: [48455] trunk/dports/science/qucs/files/patch-configure.diff In-Reply-To: <20090322182819.8C37712BD048@beta.macosforge.org> References: <20090322182819.8C37712BD048@beta.macosforge.org> Message-ID: <57953254-2DDE-451E-8C14-163B1E29F883@macports.org> On Mar 22, 2009, at 13:28, rowue at macports.org wrote: > Revision: 48455 > http://trac.macports.org/changeset/48455 > Author: rowue at macports.org > Date: 2009-03-22 11:28:17 -0700 (Sun, 22 Mar 2009) > Log Message: > ----------- > Changed /opt/local/include/qt3 to $prefix/include/qt3 > -+ /usr/X11R6/include/qt2 /opt/local/include/qt3" > ++ /usr/X11R6/include/qt2 $prefix/include/qt3" You don't think that will work. You have to use a placeholder like @PREFIX@ in the patchfile, then replace that placeholder with the variable value in the portfile, as in post-patch { reinplace "s|@PREFIX@|${prefix}|g" ${worksrcpath}/configure } From ryandesign at macports.org Sun Mar 22 15:48:53 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Mar 2009 17:48:53 -0500 Subject: CC, CXX et al in build, test and destroot phases Message-ID: <6F6B96C6-BEC5-4575-884C-DBCD054DB016@macports.org> MacPorts sets the environment variables CC, CXX and so forth in the configure phase only. Can anyone think of a reason why it should not also set these variables in the build, test and destroot phases? It would save a lot of this kind of thing for ports that have an unusual configure script, or none at all: build.args-append CC=${configure.cc} destroot.args-append CC=${configure.cc} From ryandesign at macports.org Sun Mar 22 15:57:18 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Mar 2009 17:57:18 -0500 Subject: [48455] trunk/dports/science/qucs/files/patch-configure.diff In-Reply-To: <151C4A22-E83F-42F8-9DB3-F56EC3FEA728@macports.org> References: <20090322182819.8C37712BD048@beta.macosforge.org> <57953254-2DDE-451E-8C14-163B1E29F883@macports.org> <151C4A22-E83F-42F8-9DB3-F56EC3FEA728@macports.org> Message-ID: On Mar 22, 2009, at 17:39, Rolf W?rdemann wrote: > Am 22.03.2009 um 23:29 schrieb Ryan Schmidt: > >> On Mar 22, 2009, at 13:28, rowue at macports.org wrote: >> >>> Revision: 48455 >>> http://trac.macports.org/changeset/48455 >>> Author: rowue at macports.org >>> Date: 2009-03-22 11:28:17 -0700 (Sun, 22 Mar 2009) >>> Log Message: >>> ----------- >>> Changed /opt/local/include/qt3 to $prefix/include/qt3 >> >> >>> -+ /usr/X11R6/include/qt2 /opt/local/include/qt3" >>> ++ /usr/X11R6/include/qt2 $prefix/include/qt3" >> >> >> You don't think that will work. You have to use a placeholder like >> @PREFIX@ in the patchfile, then replace that placeholder with the >> variable value in the portfile, as in > > Hm - but has worked in test ;) In that case, the patch may not be having any effect at all. Have you tried without patching that line? >> post-patch { >> reinplace "s|@PREFIX@|${prefix}|g" ${worksrcpath}/configure >> } > > applied, testing, afterwards committing From raimue at macports.org Sun Mar 22 15:58:40 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 22 Mar 2009 23:58:40 +0100 Subject: [48455] trunk/dports/science/qucs/files/patch-configure.diff In-Reply-To: <57953254-2DDE-451E-8C14-163B1E29F883@macports.org> References: <20090322182819.8C37712BD048@beta.macosforge.org> <57953254-2DDE-451E-8C14-163B1E29F883@macports.org> Message-ID: <49C6C2A0.6000308@macports.org> Ryan Schmidt wrote: > On Mar 22, 2009, at 13:28, rowue at macports.org wrote: > >> Revision: 48455 >> http://trac.macports.org/changeset/48455 >> Author: rowue at macports.org >> Date: 2009-03-22 11:28:17 -0700 (Sun, 22 Mar 2009) >> Log Message: >> ----------- >> Changed /opt/local/include/qt3 to $prefix/include/qt3 > > >> -+ /usr/X11R6/include/qt2 /opt/local/include/qt3" >> ++ /usr/X11R6/include/qt2 $prefix/include/qt3" > > > You don't think that will work. Actually it does. This is inside the configure script, where $prefix is what has been passed via --prefix. Rainer From toby at macports.org Sun Mar 22 16:00:54 2009 From: toby at macports.org (Toby Peterson) Date: Sun, 22 Mar 2009 16:00:54 -0700 Subject: CC, CXX et al in build, test and destroot phases In-Reply-To: <6F6B96C6-BEC5-4575-884C-DBCD054DB016@macports.org> References: <6F6B96C6-BEC5-4575-884C-DBCD054DB016@macports.org> Message-ID: <74c219d30903221600v7db27f05wa817a7e584ce3896@mail.gmail.com> On Sun, Mar 22, 2009 at 15:48, Ryan Schmidt wrote: > MacPorts sets the environment variables CC, CXX and so forth in the > configure phase only. > > Can anyone think of a reason why it should not also set these variables in > the build, test and destroot phases? It would save a lot of this kind of > thing for ports that have an unusual configure script, or none at all: > > > build.args-append ? ? ? ? ? ? ? CC=${configure.cc} > destroot.args-append ? ? ? ? ? ?CC=${configure.cc} Properly designed configure-based projects will pay attention to the environment and set things according... configuring it so that the build phase to consist of nothing more than "make". Ports that need environment variables during build are more of a special case. Current behavior is fine, and most correct. - Toby From ryandesign at macports.org Sun Mar 22 16:06:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Mar 2009 18:06:41 -0500 Subject: [48460] trunk/dports/science In-Reply-To: <20090322224005.GJ868@chimeric.de> References: <20090322213942.33A6512BFF4E@beta.macosforge.org> <20090322224005.GJ868@chimeric.de> Message-ID: <78998337-FC8A-4136-B56A-7E0593883F35@macports.org> On Mar 22, 2009, at 17:40, Michael Klier wrote: > On Sun, Mar 22, 2009 at 05:27:15PM -0500, Ryan Schmidt wrote: >> On Mar 22, 2009, at 16:39, blb at macports.org wrote: >> >>> +master_sites http://downloads.sourceforge.net/viking/ >> >> Could this be changed to >> >> master_sites sourceforge > > Yes of course (I've removed the distfile, changed my local Portfile > and it > seems to work), I'll read up on predefind keyword values. > > Do I have to open another ticket and bump the revision number to 1 > or do you > guys handle this? No, that's fine, I committed the change in r48463. I didn't increase the port revision since this change does not result in any different files ending up on the user's system. From ryandesign at macports.org Sun Mar 22 16:14:52 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Mar 2009 18:14:52 -0500 Subject: [48455] trunk/dports/science/qucs/files/patch-configure.diff In-Reply-To: <49C6C2A0.6000308@macports.org> References: <20090322182819.8C37712BD048@beta.macosforge.org> <57953254-2DDE-451E-8C14-163B1E29F883@macports.org> <49C6C2A0.6000308@macports.org> Message-ID: On Mar 22, 2009, at 17:58, Rainer M?ller wrote: > Ryan Schmidt wrote: >> On Mar 22, 2009, at 13:28, rowue at macports.org wrote: >> >>> Revision: 48455 >>> http://trac.macports.org/changeset/48455 >>> Author: rowue at macports.org >>> Date: 2009-03-22 11:28:17 -0700 (Sun, 22 Mar 2009) >>> Log Message: >>> ----------- >>> Changed /opt/local/include/qt3 to $prefix/include/qt3 >> >> >>> -+ /usr/X11R6/include/qt2 /opt/local/include/qt3" >>> ++ /usr/X11R6/include/qt2 $prefix/include/qt3" >> >> >> You don't think that will work. > > Actually it does. This is inside the configure script, where > $prefix is > what has been passed via --prefix. Oh, goodness. Never mind then! From rowue at digitalis.org Sun Mar 22 16:19:03 2009 From: rowue at digitalis.org (=?ISO-8859-1?Q?Rolf_W=FCrdemann?=) Date: Mon, 23 Mar 2009 00:19:03 +0100 Subject: [48455] trunk/dports/science/qucs/files/patch-configure.diff In-Reply-To: References: <20090322182819.8C37712BD048@beta.macosforge.org> <57953254-2DDE-451E-8C14-163B1E29F883@macports.org> <49C6C2A0.6000308@macports.org> Message-ID: <9A85564B-7EAE-48C2-9B81-360413C1BAD8@digitalis.org> Am 23.03.2009 um 00:14 schrieb Ryan Schmidt: > > On Mar 22, 2009, at 17:58, Rainer M?ller wrote: > >> Ryan Schmidt wrote: >>> On Mar 22, 2009, at 13:28, rowue at macports.org wrote: >>> >>>> Revision: 48455 >>>> http://trac.macports.org/changeset/48455 >>>> Author: rowue at macports.org >>>> Date: 2009-03-22 11:28:17 -0700 (Sun, 22 Mar 2009) >>>> Log Message: >>>> ----------- >>>> Changed /opt/local/include/qt3 to $prefix/include/qt3 >>> >>> >>>> -+ /usr/X11R6/include/qt2 /opt/local/include/qt3" >>>> ++ /usr/X11R6/include/qt2 $prefix/include/qt3" >>> >>> >>> You don't think that will work. >> >> Actually it does. This is inside the configure script, where >> $prefix is >> what has been passed via --prefix. > > Oh, goodness. Never mind then! O.K. - Then I will remove it with the next bigger changes of the Portfile (Playing with info.plist qucs.icns) and send Patch to upstream Thanks! rowue > [...] -- Security is an illusion - Datasecurity twice Rolf W?rdemann - private: rowue at digitalis.org - office: rowue at crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue at digitalis.org ECF127C7 EAB85F87 BC75ACB5 2EC646D4 99211A31 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: Signierter Teil der Nachricht URL: From ryandesign at macports.org Sun Mar 22 16:19:30 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Mar 2009 18:19:30 -0500 Subject: CC, CXX et al in build, test and destroot phases In-Reply-To: <74c219d30903221600v7db27f05wa817a7e584ce3896@mail.gmail.com> References: <6F6B96C6-BEC5-4575-884C-DBCD054DB016@macports.org> <74c219d30903221600v7db27f05wa817a7e584ce3896@mail.gmail.com> Message-ID: On Mar 22, 2009, at 18:00, Toby Peterson wrote: > On Sun, Mar 22, 2009 at 15:48, Ryan Schmidt wrote: > >> MacPorts sets the environment variables CC, CXX and so forth in the >> configure phase only. >> >> Can anyone think of a reason why it should not also set these >> variables in >> the build, test and destroot phases? It would save a lot of this >> kind of >> thing for ports that have an unusual configure script, or none at >> all: >> >> >> build.args-append CC=${configure.cc} >> destroot.args-append CC=${configure.cc} > > Properly designed configure-based projects will pay attention to the > environment and set things according... configuring it so that the > build phase to consist of nothing more than "make". I am aware of that. But we have a lot of ports for software which is not properly-designed. Of my 81 ports, 11 need fiddling with ${configure.cc} at this time. Most of this could be removed if MacPorts base set CC et al during the build and destroot phases as I proposed. > Ports that need > environment variables during build are more of a special case. Current > behavior is fine, and most correct. Current behavior is annoying because it causes port authors to need to repeat certain common bits in their portfiles which could be moved into MacPorts base so that port maintainers don't need to worry about it. We should always be on the lookout for ways of simplifying portfiles by moving common functionality into base. I feel this particular issue is especially important because most port maintainers probably don't know they should make sure the port uses ${configure.cc} (e.g. /usr/bin/gcc-4.0) instead of just "cc", not to mention that we have thousands of ports that have no maintainer which are not being looked after. Even for those that are, the port will probably not produce an error message for the maintainer if they do not take care to set CC. But the port may produce an error for some other user who has gcc_select'ed some other compiler. The whole reason the setting of CC=${configure.cc} etc. was added to the configure phase in base was to avoid problems for users who have gcc_select'ed something else, but this only works for software that have well-behaved configure scripts. If we can make this work automatically for additional ports, I feel we should do so. So I ask again: can you think of any reason why we should not set these variables in the build, test and destroot phases? Can you think of any problems it would cause? From ryandesign at macports.org Sun Mar 22 16:37:47 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Mar 2009 18:37:47 -0500 Subject: Is isysroot useful for non-universal? In-Reply-To: References: <49C6A68F.1010800@macports.org> Message-ID: <54AEB61A-D795-4E7B-8DBB-5281DE79E484@macports.org> On Mar 22, 2009, at 17:01, Daniel J. Luke wrote: > Maybe tracemode (or something like it) could be adapted to be on by > default to fix this then? Tracemode seems very finicky, having gotten more so since the 1.7.0 release, so I would be loath to do so. From ryandesign at macports.org Sun Mar 22 16:48:11 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Mar 2009 18:48:11 -0500 Subject: Is isysroot useful for non-universal? In-Reply-To: References: Message-ID: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> On Mar 22, 2009, at 15:11, Daniel J. Luke wrote: > note that we'd need to use autoconf to check for the location of > the SDK (if we don't already) since it doesn't have to be installed > at /Developer/SDKs on 10.5. I've ignored this problem so far. I would be surprised if MacPorts would work if Xcode is installed in a different location. We should probably document somewhere that you should install Xcode in its standard location. > Also, the last time I checked, with isysroot you only get the stuff > in the SDK so while it would fix looking in /usr/local, it would > also prevent looking in ${prefix} for headers and libraries, which > we don't want. There may be a way to work-around that though. We currently build universal ports using isysroot, so this can't be a general problem, can it? Otherwise none of our universal ports would compile at all. There are some issues if you try to link with a library but don't use the appropriate -l flag. This happens often when software uses the -l flag for a library but doesn't include the -l flag for a library that library depends on. This causes an error message like can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/opt/local/ lib/libsomething.dylib on Tiger. See e.g. http://trac.macports.org/ticket/18035 This does not appear to be a problem on Leopard. From toby at macports.org Sun Mar 22 17:25:21 2009 From: toby at macports.org (Toby Peterson) Date: Sun, 22 Mar 2009 17:25:21 -0700 Subject: Is isysroot useful for non-universal? In-Reply-To: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> Message-ID: <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> On Sun, Mar 22, 2009 at 16:48, Ryan Schmidt wrote: > > On Mar 22, 2009, at 15:11, Daniel J. Luke wrote: > >> note that we'd need to use autoconf to check for the location of the SDK >> (if we don't already) since it doesn't have to be installed at >> /Developer/SDKs on 10.5. > > I've ignored this problem so far. I would be surprised if MacPorts would > work if Xcode is installed in a different location. We should probably > document somewhere that you should install Xcode in its standard location. Ultimately the solution to this should be to simply stop building against an SDK. Nothing fundamentally wrong with building against an SDK, but it shouldn't be tied to universal building, nor should it be the default behavior. - Toby From toby at macports.org Sun Mar 22 17:28:15 2009 From: toby at macports.org (Toby Peterson) Date: Sun, 22 Mar 2009 17:28:15 -0700 Subject: CC, CXX et al in build, test and destroot phases In-Reply-To: References: <6F6B96C6-BEC5-4575-884C-DBCD054DB016@macports.org> <74c219d30903221600v7db27f05wa817a7e584ce3896@mail.gmail.com> Message-ID: <74c219d30903221728t4f592c1aqa0e07277e1496cb6@mail.gmail.com> On Sun, Mar 22, 2009 at 16:19, Ryan Schmidt wrote: > So I ask again: can you think of any reason why we should not set these > variables in the build, test and destroot phases? Can you think of any > problems it would cause? CC is probably safe, others not so much (e.g. CFLAGS might cause unexpected overrides). Still, I prefer to avoid special-casing as much as possible. If a few ports have to be a bit more explicit, I don't think that's the end of the world. - Toby From ryandesign at macports.org Sun Mar 22 17:31:16 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Mar 2009 19:31:16 -0500 Subject: Is isysroot useful for non-universal? In-Reply-To: <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> Message-ID: On Mar 22, 2009, at 19:25, Toby Peterson wrote: > On Sun, Mar 22, 2009 at 16:48, Ryan Schmidt wrote: > >> On Mar 22, 2009, at 15:11, Daniel J. Luke wrote: >> >>> note that we'd need to use autoconf to check for the location of >>> the SDK >>> (if we don't already) since it doesn't have to be installed at >>> /Developer/SDKs on 10.5. >> >> I've ignored this problem so far. I would be surprised if MacPorts >> would >> work if Xcode is installed in a different location. We should >> probably >> document somewhere that you should install Xcode in its standard >> location. > > Ultimately the solution to this should be to simply stop building > against an SDK. > > Nothing fundamentally wrong with building against an SDK, but it > shouldn't be tied to universal building, nor should it be the default > behavior. It is necessary to build against an SDK in order to get a universal build (on Tiger, anyway). And it is the way Apple says to do it. If you can get Apple to change their recommendation, and compel me to upgrade my Tiger systems to Leopard, we can talk about changing the way MacPorts builds universal binaries. From toby at macports.org Sun Mar 22 17:44:50 2009 From: toby at macports.org (Toby Peterson) Date: Sun, 22 Mar 2009 17:44:50 -0700 Subject: Is isysroot useful for non-universal? In-Reply-To: References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> Message-ID: <74c219d30903221744v1e643d76jf5baf9c9081602f6@mail.gmail.com> On Sun, Mar 22, 2009 at 17:31, Ryan Schmidt wrote: > It is necessary to build against an SDK in order to get a universal build > (on Tiger, anyway). And it is the way Apple says to do it. If you can get > Apple to change their recommendation, and compel me to upgrade my Tiger > systems to Leopard, we can talk about changing the way MacPorts builds > universal binaries. *Only* on Tiger/PPC. We can special-case that; normally, there's no need. - Toby From dluke at geeklair.net Sun Mar 22 19:41:00 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Sun, 22 Mar 2009 22:41:00 -0400 Subject: Is isysroot useful for non-universal? In-Reply-To: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> Message-ID: On Mar 22, 2009, at 7:48 PM, Ryan Schmidt wrote: >> note that we'd need to use autoconf to check for the location of >> the SDK (if we don't already) since it doesn't have to be installed >> at /Developer/SDKs on 10.5. > > I've ignored this problem so far. I would be surprised if MacPorts > would work if Xcode is installed in a different location. We should > probably document somewhere that you should install Xcode in its > standard location. Even if you install stuff not in /Developer gcc gets installed in the 'normal' location, so things work fine (except for builds that are looking for the sdk). It's probably reasonable to just add an autoconf check. Something like: AC_PATH_PROG(XCODE_SELECT,xcode-select,no) if test $XCODE_SELECT = no; then SDKPATH="/Developer" else SDKPATH=`$XCODE_SELECT -print-path` fi SDK="$SDKPATH/SDKs/MacOSX10.4u.sdk" CFLAGS="$CFLAGS -isysroot $SDK -mmacosx-version-min=10.4" CXXFLAGS="$CXXFLAGS -isysroot $SDK -mmacosx-version-min=10.4" LDFLAGS="$LDFLAGS -isysroot $SDK -mmacosx-version-min=10.4" Although it would need to be modified to select the 10.5 sdk on 10.5 or whatever the current policy is (I don't recall :) ). >> Also, the last time I checked, with isysroot you only get the stuff >> in the SDK so while it would fix looking in /usr/local, it would >> also prevent looking in ${prefix} for headers and libraries, which >> we don't want. There may be a way to work-around that though. > > We currently build universal ports using isysroot, so this can't be > a general problem, can it? Otherwise none of our universal ports > would compile at all. I think there perhaps used to be some problem that no longer exists that I was remembering (I added universal build support to a project for work a while ago and I think I stumbled across the problem at that time, see http://lists.apple.com/archives/Darwin-dev/2006/Apr/msg00042.html) . I guess isysroot doesn't work that way any more? > There are some issues if you try to link with a library but don't > use the appropriate -l flag. This happens often when software uses > the -l flag for a library but doesn't include the -l flag for a > library that library depends on. This causes an error message like > > can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/opt/ > local/lib/libsomething.dylib > > on Tiger. See e.g. > > http://trac.macports.org/ticket/18035 > > This does not appear to be a problem on Leopard. -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From ryandesign at macports.org Sun Mar 22 19:53:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 22 Mar 2009 21:53:49 -0500 Subject: Is isysroot useful for non-universal? In-Reply-To: References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> Message-ID: <9D4622AE-487F-43D2-9A45-C720543E4048@macports.org> On Mar 22, 2009, at 21:41, Daniel J. Luke wrote: > On Mar 22, 2009, at 7:48 PM, Ryan Schmidt wrote: > >>> note that we'd need to use autoconf to check for the location of >>> the SDK (if we don't already) since it doesn't have to be >>> installed at /Developer/SDKs on 10.5. >> >> I've ignored this problem so far. I would be surprised if MacPorts >> would work if Xcode is installed in a different location. We >> should probably document somewhere that you should install Xcode >> in its standard location. > > Even if you install stuff not in /Developer gcc gets installed in > the 'normal' location, so things work fine (except for builds that > are looking for the sdk). I believe there is a checkbox in the installer to not do that, so this is not necessarily so. > It's probably reasonable to just add an autoconf check. Something > like: > > AC_PATH_PROG(XCODE_SELECT,xcode-select,no) > if test $XCODE_SELECT = no; then > SDKPATH="/Developer" > else > SDKPATH=`$XCODE_SELECT -print-path` > fi > SDK="$SDKPATH/SDKs/MacOSX10.4u.sdk" > CFLAGS="$CFLAGS -isysroot $SDK -mmacosx-version-min=10.4" > CXXFLAGS="$CXXFLAGS -isysroot $SDK -mmacosx-version-min=10.4" > LDFLAGS="$LDFLAGS -isysroot $SDK -mmacosx-version-min=10.4" > > Although it would need to be modified to select the 10.5 sdk on > 10.5 or whatever the current policy is (I don't recall :) ). Current policy is to use the SDK the user requested in macports.conf. >>> Also, the last time I checked, with isysroot you only get the >>> stuff in the SDK so while it would fix looking in /usr/local, it >>> would also prevent looking in ${prefix} for headers and >>> libraries, which we don't want. There may be a way to work-around >>> that though. >> >> We currently build universal ports using isysroot, so this can't >> be a general problem, can it? Otherwise none of our universal >> ports would compile at all. > > I think there perhaps used to be some problem that no longer exists > that I was remembering (I added universal build support to a > project for work a while ago and I think I stumbled across the > problem at that time, see http://lists.apple.com/archives/Darwin- > dev/2006/Apr/msg00042.html). > > I guess isysroot doesn't work that way any more? I believe that's the problem I described below: >> There are some issues if you try to link with a library but don't >> use the appropriate -l flag. This happens often when software uses >> the -l flag for a library but doesn't include the -l flag for a >> library that library depends on. This causes an error message like >> >> can't open dynamic library: /Developer/SDKs/MacOSX10.4u.sdk/opt/ >> local/lib/libsomething.dylib >> >> on Tiger. See e.g. >> >> http://trac.macports.org/ticket/18035 >> >> This does not appear to be a problem on Leopard. > From raimue at macports.org Mon Mar 23 01:15:46 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 23 Mar 2009 09:15:46 +0100 Subject: CC, CXX et al in build, test and destroot phases In-Reply-To: <74c219d30903221728t4f592c1aqa0e07277e1496cb6@mail.gmail.com> References: <6F6B96C6-BEC5-4575-884C-DBCD054DB016@macports.org> <74c219d30903221600v7db27f05wa817a7e584ce3896@mail.gmail.com> <74c219d30903221728t4f592c1aqa0e07277e1496cb6@mail.gmail.com> Message-ID: <49C74532.2070506@macports.org> Toby Peterson wrote: > On Sun, Mar 22, 2009 at 16:19, Ryan Schmidt wrote: >> So I ask again: can you think of any reason why we should not set these >> variables in the build, test and destroot phases? Can you think of any >> problems it would cause? > > CC is probably safe, others not so much (e.g. CFLAGS might cause > unexpected overrides). Still, I prefer to avoid special-casing as much > as possible. If a few ports have to be a bit more explicit, I don't > think that's the end of the world. But Ryan has a valid point there. At least setting CC would make sense. If a port does not have configure and just calls CC in the Makefile, this could be different compilers if someone used gcc_select. The original port author may not even have noticed that something like build.env CC=${configure.cc} is necessary. Rainer From afb at macports.org Mon Mar 23 01:39:36 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 23 Mar 2009 09:39:36 +0100 Subject: CC, CXX et al in build, test and destroot phases In-Reply-To: <74c219d30903221728t4f592c1aqa0e07277e1496cb6@mail.gmail.com> References: <6F6B96C6-BEC5-4575-884C-DBCD054DB016@macports.org> <74c219d30903221600v7db27f05wa817a7e584ce3896@mail.gmail.com> <74c219d30903221728t4f592c1aqa0e07277e1496cb6@mail.gmail.com> Message-ID: <70393C18-ED60-4F44-B47D-C985821EB5A8@macports.org> Toby Peterson wrote: > On Sun, Mar 22, 2009 at 16:19, Ryan Schmidt > wrote: >> So I ask again: can you think of any reason why we should not set >> these >> variables in the build, test and destroot phases? Can you think of >> any >> problems it would cause? > > CC is probably safe, others not so much (e.g. CFLAGS might cause > unexpected overrides). Still, I prefer to avoid special-casing as much > as possible. If a few ports have to be a bit more explicit, I don't > think that's the end of the world. There's a lot of ports ignoring CFLAGS too (in addition to CC), as was noted when experimenting with the -m32 and -m64 flags... Not so important when it's "-O2" versus "-O3 -fomit-frame-pointer", but annoying indeed when it skips over a -m64 or -arch x86_64. So if all the ports could be made to respect $CC and $CFLAGS (and $CXX and $CXXFLAGS), that would ultimately be a good thing. Then again, there's always someone* that feels the need to rewrite autotools in python and change the names of the variables slightly... * Looking at you, Waf. --anders From ryandesign at macports.org Mon Mar 23 02:30:10 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 23 Mar 2009 04:30:10 -0500 Subject: [48432] trunk/dports/irc/irssi-devel/Portfile In-Reply-To: <20090322073106.GA8488@ninagal.withay.com> References: <20090321234843.A22B512B5110@beta.macosforge.org> <9F14C83C-8230-4397-ACA6-E45376B62AAF@macports.org> <20090322073106.GA8488@ninagal.withay.com> Message-ID: <32CB5F42-5935-4FAD-B1C4-0742E3083B1B@macports.org> On Mar 22, 2009, at 02:31, Bryan Blackburn wrote: > On Sun, Mar 22, 2009 at 01:35:52AM -0500, Ryan Schmidt said: >> On Mar 21, 2009, at 18:48, blb at macports.org wrote: > [...] >>> @@ -18,7 +18,12 @@ >>> homepage http://irssi.org/ >>> fetch.type svn >>> svn.url http://svn.irssi.org/repos/irssi/trunk >>> -svn.tag ${version} >>> +# When 1.8 is released, svn.revision can be set without the if{} >>> +if {[info exists svn.revision]} { >>> + svn.revision ${version} >>> +} else { >>> + svn.tag ${version} >>> +} >> >> Why bother to make this change now when you'll change it again >> after 1.8 >> is released? Why not just leave it as is until after 1.8 is released? > > Partly a reminder, partly to quiet the warning about it being > deprecated. I was wondering if there might be a deprecation warning already. I don't think we should have a deprecation warning until after we've released a version of MacPorts including the new option name (so, after 1.8 is released). From afb at macports.org Mon Mar 23 03:47:54 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 23 Mar 2009 11:47:54 +0100 Subject: Is isysroot useful for non-universal? In-Reply-To: <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> Message-ID: Toby Peterson wrote: > Ultimately the solution to this should be to simply stop building > against an SDK. > > Nothing fundamentally wrong with building against an SDK, but it > shouldn't be tied to universal building, nor should it be the default > behavior. The +universal "variant" is a glorious mess that mixes all of fatness (universalness, archness, whatever...) and MDT and SDK together in one big undefined configuration. Back then in the day, ppc+i386/10.4/MacOSX10.4u.sdk seemed like a reasonable default for building "Universal Binaries". These days, i686+x86_64/10.5/MacOSX10.5.sdk is more popular*. There's some minimal separation into archs/target/sysroot, but it's still all covered with the "universal" variant - just like flags are covered with the "configure" target. Despite the fact that they cover much more than "just" universal (arch) and configure (autotools), that is... So it's more of a legacy quirk, than a design decision. --anders * yes, I know that excludes PowerPC and Tiger users. From toby at macports.org Mon Mar 23 07:49:55 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 23 Mar 2009 07:49:55 -0700 Subject: [48432] trunk/dports/irc/irssi-devel/Portfile In-Reply-To: <32CB5F42-5935-4FAD-B1C4-0742E3083B1B@macports.org> References: <20090321234843.A22B512B5110@beta.macosforge.org> <9F14C83C-8230-4397-ACA6-E45376B62AAF@macports.org> <20090322073106.GA8488@ninagal.withay.com> <32CB5F42-5935-4FAD-B1C4-0742E3083B1B@macports.org> Message-ID: <74c219d30903230749w33e94126h65bf436270a592f6@mail.gmail.com> On Mon, Mar 23, 2009 at 02:30, Ryan Schmidt wrote: > I was wondering if there might be a deprecation warning already. I don't > think we should have a deprecation warning until after we've released a > version of MacPorts including the new option name (so, after 1.8 is > released). It's deprecated if you're running trunk. No warning for 1.7 users. - Toby From febeling at macports.org Mon Mar 23 14:04:27 2009 From: febeling at macports.org (C. Florian Ebeling) Date: Mon, 23 Mar 2009 22:04:27 +0100 Subject: Migrate app data on upgrade Message-ID: <5cbbe4ae0903231404t22e611deo8708e61d37bb94c7@mail.gmail.com> Is there a working example of migrating app data to a new format in a some port? There are obviously a number of issues with doing something like this: - finding the source format version from a portfile with higher version - finding app data from a range of versions in possibly a number of locations - working with a number of formats from a higher version portfile, and previous (creating) versions possibly uninstalled - probably many others Are there good paths to follow? Is it worth doing? Is having version-specific (default) data directories a good idea (And then offering people export in old and import in new version, advertised by ui_msgs)? What do other distros do? Florian -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From ryandesign at macports.org Mon Mar 23 15:12:07 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 23 Mar 2009 17:12:07 -0500 Subject: Universal and binary builds (was: Re: Is isysroot useful for non-universal?) In-Reply-To: References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> Message-ID: <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> On Mar 23, 2009, at 05:47, Anders F Bj?rklund wrote: > The +universal "variant" is a glorious mess that mixes all > of fatness (universalness, archness, whatever...) and > MDT and SDK together in one big undefined configuration. > > Back then in the day, ppc+i386/10.4/MacOSX10.4u.sdk seemed > like a reasonable default for building "Universal Binaries". > These days, i686+x86_64/10.5/MacOSX10.5.sdk is more popular*. > > There's some minimal separation into archs/target/sysroot, > but it's still all covered with the "universal" variant - > just like flags are covered with the "configure" target. > > Despite the fact that they cover much more than "just" > universal (arch) and configure (autotools), that is... > So it's more of a legacy quirk, than a design decision. I'm getting really burned out on universal. The default universal variant has severe problems, in that the configure phase runs just once for all architectures combined, and many programs' configure scripts are written wrong so they assume, for example, the size of ints or the endianness of the processor based on just one of the multiple architectures for which we're trying to configure. The software then probably builds and installs without error and we never learn of the problem until someone actually tries to run it on another platform from the one it was compiled on. Or maybe they don't notice until their data ends up being corrupted. Port maintainers can add ed scripts to fix things after the configure phase, but that only fixes it at that instant. Who's to say the upstream software won't introduce new processor- specific variables in a later version? How is the maintainer to detect that this has occurred? The new muniversal portgroup aims to solve this but has other severe problems, in that the configure phase runs once for each architecture, and some configure scripts are written wrong so they try to run a program at configure time to learn things about the build environment, which is not appropriate when cross-compiling. So the configure script exits saying it cannot run a program when cross- compiling, and the maintainer has to research what those values are supposed to be for each architecture, possibly getting them wrong. Many programs simply cannot be cross-compiled so then the list of supported architectures is reduced, and it's a different list of supported architectures depending on the computer doing the build. What if we set aside what we have now for universal variants and spent some energy on finally doing binary builds? Finish the script that builds a port in a clean MacPorts tree in a chroot. Make it package that up and send it to a download server. Modify MacPorts base to look for, download and install those binaries first. Make those binaries integrate properly with the registry. Begin by having the build server only build the default variant of a port, but later it can be expanded to build more combinations of variants. We can work out a system later that allows more variant combinations of an old port to be built without impacting the building of newly-updated ports. Since the server will have multiple cores we can run multiple ports' builds simultaneously, in multiple chroots. I would want (at least) one build server for each OS and processor combination, but if we began with just a single Intel Leopard machine, that would cover the majority of users. If we add a corresponding PowerPC Leopard machine, then we could do something interesting: Once the Intel and PowerPC builds are sent to the download server, the download server could combine both builds into a single universal binary package. It would use lipo, probably assisted by the code we have in the MacPorts merge procedure or the muniversal portgroup. It would avoid the above problems with our existing universal variants because the configure phase would run once for each processor, on that processor. We wouldn't need to deal with SDKs anymore. (I've never been comfortable with the idea of allowing the user to specify an SDK in macports.conf, so I don't see it as a problem that that would not be accommodated by our binary builds.) Using the above, we would have stable 32-bit universal binaries. We would also want each build server to separately build 64-bit versions. Obviously the build servers would be 64-bit machines. We would need a way for ports to indicate what architectures they can be built for. The universal_archs_supported variable from the muniversal portgroup should be formalized and brought into MacPorts base. Only it should be renamed to not include the word universal, because sometimes it's not about being universal at all. For example wine lets you run Windows binaries on an Intel Mac. It can currently be compiled on i386. It cannot be compiled on x86_64; I presume that is a bug. It will never be possible to compile on ppc or ppc64 because a PowerPC Mac cannot run the Intel code contained within Windows binaries. So totally unrelated to being universal or not, I need to be able to indicate, via a better mechanism than "universal_variant no" and a pre-fetch block, that the port can only be built for i386. We also need a way to indicate that a port has no compiled parts and only needs to be packaged up once. For example all the xorg-*proto ports. We also need a way to indicate that a port already provides binaries of a certain architecture. For example isightcapture and oracle- instantclient. Ports would no longer need to include any directives for cross- compiling universal, because that would no longer be done. Some ports would possibly need to include directives for compiling 64-bit, for software that doesn't manage that on its own. We could provide a platform selector ("64bit") that ports could use to easily deal with this, for example: platform darwin 64bit { configure.args-append --disable-some-carbon-feature } From afb at macports.org Mon Mar 23 15:50:39 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 23 Mar 2009 23:50:39 +0100 Subject: Universal and binary builds (was: Re: Is isysroot useful for non-universal?) In-Reply-To: <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> Message-ID: Ryan Schmidt wrote: >> Despite the fact that they cover much more than "just" >> universal (arch) and configure (autotools), that is... >> So it's more of a legacy quirk, than a design decision. > > I'm getting really burned out on universal. It sorta worked originally, but has probably outlived itself. Especially with the current source ports, it seems like overkill. Had there been binary packages, then sure it might have been OK. But when doing all the builds locally on each machine anyway ? I personally think that "autolipo"* is neater than universal. * i.e. when you can "add" a i386 to a ppc, and it becomes fat > What if we set aside what we have now for universal variants and > spent some energy on finally doing binary builds? Finish the script > that builds a port in a clean MacPorts tree in a chroot. Make it > package that up and send it to a download server. Modify MacPorts > base to look for, download and install those binaries first. Make > those binaries integrate properly with the registry. Begin by > having the build server only build the default variant of a port, > but later it can be expanded to build more combinations of > variants. We can work out a system later that allows more variant > combinations of an old port to be built without impacting the > building of newly-updated ports. Since the server will have > multiple cores we can run multiple ports' builds simultaneously, in > multiple chroots. I think this chroot build is what the MPAB project was all about. There's also the XML/XAR based format, if anyone feels up to it... We could also resume building RPMS, if someone wants to spend some time on that. The build script could probably produce both archives and packages in the same run, from the same destroot. But the integration part with the port registry is still missing. > I would want (at least) one build server for each OS and processor > combination, but if we began with just a single Intel Leopard > machine, that would cover the majority of users. If we add a > corresponding PowerPC Leopard machine, then we could do something > interesting: Once the Intel and PowerPC builds are sent to the > download server, the download server could combine both builds into > a single universal binary package. It would use lipo, probably > assisted by the code we have in the MacPorts merge procedure or the > muniversal portgroup. It would avoid the above problems with our > existing universal variants because the configure phase would run > once for each processor, on that processor. We wouldn't need to > deal with SDKs anymore. (I've never been comfortable with the idea > of allowing the user to specify an SDK in macports.conf, so I don't > see it as a problem that that would not be accommodated by our > binary builds.) Or, the destroots could just be kept as separate arch archives. If from remote, this would cut the download size in half too... Universal binaries are mostly useful for the user, so that there's "only one thing to choose from". If it's the computer that is doing the choosing, it might as well pick the right one. Maybe lipo for exporting packages, but not for internal archives. > Using the above, we would have stable 32-bit universal binaries. We > would also want each build server to separately build 64-bit > versions. Obviously the build servers would be 64-bit machines. It would be nice with a 64-bit option without Universal and SDKs. In theory this just involves adding the -m64 option to the flags. --anders From jeremyhu at macports.org Mon Mar 23 16:01:52 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Mon, 23 Mar 2009 16:01:52 -0700 Subject: Universal and binary builds (was: Re: Is isysroot useful for non-universal?) In-Reply-To: <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> Message-ID: <08DDCC98-ACBA-488C-913C-19543C7FC24A@macports.org> On Mar 23, 2009, at 15:12, Ryan Schmidt wrote: > > I would want (at least) one build server for each OS and processor > combination, but if we began with just a single Intel Leopard > machine, that would cover the majority of users. If we add a > corresponding PowerPC Leopard machine, then we could do something > interesting: Once the Intel and PowerPC builds are sent to the > download server, the download server could combine both builds into > a single universal binary package. Why put it on the back of the download server? Let the user handle this. That way if we support n differnet architectures, we just need to host n files (one tarball for each arch) instead of n! files (one tarball for each combination). With ppc, ppc64, i386, x86_64 that's 4 versus 24 files which would probably be about 10x storage space required (just a rough estimate considering that the combined packages will be larger than the individual ones) > It would use lipo, probably assisted by the code we have in the > MacPorts merge procedure or the muniversal portgroup. It would avoid > the above problems with our existing universal variants because the > configure phase would run once for each processor, on that > processor. We wouldn't need to deal with SDKs anymore. (I've never > been comfortable with the idea of allowing the user to specify an > SDK in macports.conf, so I don't see it as a problem that that would > not be accommodated by our binary builds.) > > Using the above, we would have stable 32-bit universal binaries. We > would also want each build server to separately build 64-bit > versions. Obviously the build servers would be 64-bit machines. This just needs 2 build servers per OS version. Setup a ppc chroot on the ppc64 box and an i386 chroot on the x86_64 box. Since rosetta doesn't handle ppc64, we can't narrow this down to a single x86_64 box. From ryandesign at macports.org Mon Mar 23 18:43:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 23 Mar 2009 20:43:02 -0500 Subject: Universal and binary builds (was: Re: Is isysroot useful for non-universal?) In-Reply-To: <08DDCC98-ACBA-488C-913C-19543C7FC24A@macports.org> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <08DDCC98-ACBA-488C-913C-19543C7FC24A@macports.org> Message-ID: On Mar 23, 2009, at 18:01, Jeremy Huddleston wrote: > On Mar 23, 2009, at 15:12, Ryan Schmidt wrote: > >> I would want (at least) one build server for each OS and processor >> combination, but if we began with just a single Intel Leopard >> machine, that would cover the majority of users. If we add a >> corresponding PowerPC Leopard machine, then we could do something >> interesting: Once the Intel and PowerPC builds are sent to the >> download server, the download server could combine both builds >> into a single universal binary package. > > Why put it on the back of the download server? Let the user handle > this. That way if we support n differnet architectures, we just > need to host n files (one tarball for each arch) instead of n! > files (one tarball for each combination). With ppc, ppc64, i386, > x86_64 that's 4 versus 24 files which would probably be about 10x > storage space required (just a rough estimate considering that the > combined packages will be larger than the individual ones) My motivation for suggesting that was that most packages include shared files which are arch-agnostic and I didn't want the user to have to download those shared files twice. I should have also mentioned that some ports may still need to include merging instructions. Compiled things can be merged with lipo, but headers and other text files may also differ and may not be mergeable with diff. The muniversal portgroup offers solutions for this but the port must indicate for which files those other methods should be employed. I meant to also mention that it would still be up to the user to decide which architectures they wanted to have installed. >> It would use lipo, probably assisted by the code we have in the >> MacPorts merge procedure or the muniversal portgroup. It would >> avoid the above problems with our existing universal variants >> because the configure phase would run once for each processor, on >> that processor. We wouldn't need to deal with SDKs anymore. (I've >> never been comfortable with the idea of allowing the user to >> specify an SDK in macports.conf, so I don't see it as a problem >> that that would not be accommodated by our binary builds.) >> >> Using the above, we would have stable 32-bit universal binaries. >> We would also want each build server to separately build 64-bit >> versions. Obviously the build servers would be 64-bit machines. > > This just needs 2 build servers per OS version. Exactly. > Setup a ppc chroot on the ppc64 box and an i386 chroot on the > x86_64 box. Sure. > Since rosetta doesn't handle ppc64, we can't narrow this down to a > single x86_64 box. We can't narrow it down to a single Intel Mac per OS anyway because one of the problems is that some software doesn't cross-compile correctly. The point is to eliminate the need for cross-compiling by compiling natively on each type of Mac. From ryandesign at macports.org Mon Mar 23 18:54:33 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 23 Mar 2009 20:54:33 -0500 Subject: Migrate app data on upgrade In-Reply-To: <5cbbe4ae0903231404t22e611deo8708e61d37bb94c7@mail.gmail.com> References: <5cbbe4ae0903231404t22e611deo8708e61d37bb94c7@mail.gmail.com> Message-ID: <037C799F-B466-4228-95B9-70EF4B71FE2B@macports.org> On Mar 23, 2009, at 16:04, C. Florian Ebeling wrote: > Is there a working example of migrating app data to a new format in a > some port? There are obviously a number of issues with doing something > like this: > > - finding the source format version from a portfile with higher > version > - finding app data from a range of versions in possibly a number of > locations > - working with a number of formats from a higher version portfile, > and previous (creating) versions possibly uninstalled > - probably many others > > Are there good paths to follow? Is it worth doing? Is having > version-specific (default) data directories a good idea (And then > offering people export in old and import in new version, advertised by > ui_msgs)? What do other distros do? I don't think upgrading a port should upgrade any user data. If an upgrade of user data is necessary, the user should be advised how to do so, but it should be left to the user to do. From ryandesign at macports.org Mon Mar 23 18:57:45 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 23 Mar 2009 20:57:45 -0500 Subject: [48432] trunk/dports/irc/irssi-devel/Portfile In-Reply-To: <74c219d30903230749w33e94126h65bf436270a592f6@mail.gmail.com> References: <20090321234843.A22B512B5110@beta.macosforge.org> <9F14C83C-8230-4397-ACA6-E45376B62AAF@macports.org> <20090322073106.GA8488@ninagal.withay.com> <32CB5F42-5935-4FAD-B1C4-0742E3083B1B@macports.org> <74c219d30903230749w33e94126h65bf436270a592f6@mail.gmail.com> Message-ID: <51E0DB02-0FD3-4FCC-B2C0-3B3282518AE0@macports.org> On Mar 23, 2009, at 09:49, Toby Peterson wrote: > On Mon, Mar 23, 2009 at 02:30, Ryan Schmidt wrote: > >> I was wondering if there might be a deprecation warning already. I >> don't >> think we should have a deprecation warning until after we've >> released a >> version of MacPorts including the new option name (so, after 1.8 is >> released). > > It's deprecated if you're running trunk. No warning for 1.7 users. Right, and I am suggesting that we remove the deprecation warning for svn.tag from trunk again, and not re-add it until the next version of MacPorts has been released which includes svn.revision. Because svn.tag *is not* deprecated today. svn.tag is in fact the only way to accomplish that today. Nobody, not even those running trunk, should be led to believe that they should replace instances of svn.tag with svn.revision today, because they should not; doing so would break things for those not running trunk. From ryandesign at macports.org Mon Mar 23 19:08:44 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 23 Mar 2009 21:08:44 -0500 Subject: [48314] trunk/base/src/port1.0/portbuild.tcl In-Reply-To: <49C4BE4E.5090509@macports.org> References: <20090319021018.4D579125671A@beta.macosforge.org> <32D19398-DAD0-40C4-BCE9-91DE3B8B121F@macports.org> <49C4BE4E.5090509@macports.org> Message-ID: On Mar 21, 2009, at 05:15, Joshua Root wrote: > Ryan Schmidt wrote: >> On Mar 18, 2009, at 21:23, Jeremy Lavergne wrote: >>> When are we going to have the mass ports-upgrade to rid ourselves of >>> the default values that are going to be there (use_parallel_build >>> yes)? Is it going to be scripted or will this be left to the >>> maintainers? >> >> It can't happen until a version of MacPorts with this change is >> released, which I guess will be 1.8.0. We can discus it after then. A >> single mass-update by a MacPorts mgr would be fine. > > We don't necessarily have to do that. It isn't hurting anything, and > could serve as documentation that parallel build has been tested. Uh, true. I have pushed for that myself in the past. Very well, it should stay. With dismay I note my earlier proposal of replacing use_parallel_build with build.max_jobs doesn't leave a way to indicate that a port works fine with any number of parallel jobs. :-( Well, it could be two parameters. build.parallel (values yes or no, default yes) this would be a direct equivalent to use_parallel_build (which would be deprecated later) build.max_jobs (nonzero positive integers, default maxint) Maybe max_jobs isn't the right name either. Because both the value in the portfile and the value in macports.conf are maximums: the former is the maximum number of jobs the port supports, and the latter is the maximum number of jobs the user wants. The number of jobs that will be started is the smaller of the two. Maybe both can be called "build.jobs". From blb at macports.org Mon Mar 23 19:14:22 2009 From: blb at macports.org (Bryan Blackburn) Date: Mon, 23 Mar 2009 20:14:22 -0600 Subject: [48432] trunk/dports/irc/irssi-devel/Portfile In-Reply-To: <51E0DB02-0FD3-4FCC-B2C0-3B3282518AE0@macports.org> References: <20090321234843.A22B512B5110@beta.macosforge.org> <9F14C83C-8230-4397-ACA6-E45376B62AAF@macports.org> <20090322073106.GA8488@ninagal.withay.com> <32CB5F42-5935-4FAD-B1C4-0742E3083B1B@macports.org> <74c219d30903230749w33e94126h65bf436270a592f6@mail.gmail.com> <51E0DB02-0FD3-4FCC-B2C0-3B3282518AE0@macports.org> Message-ID: <20090324021422.GJ564@ninagal.withay.com> On Mon, Mar 23, 2009 at 08:57:45PM -0500, Ryan Schmidt said: > > On Mar 23, 2009, at 09:49, Toby Peterson wrote: > >> On Mon, Mar 23, 2009 at 02:30, Ryan Schmidt wrote: >> >>> I was wondering if there might be a deprecation warning already. I >>> don't >>> think we should have a deprecation warning until after we've released >>> a >>> version of MacPorts including the new option name (so, after 1.8 is >>> released). >> >> It's deprecated if you're running trunk. No warning for 1.7 users. > > Right, and I am suggesting that we remove the deprecation warning for > svn.tag from trunk again, and not re-add it until the next version of > MacPorts has been released which includes svn.revision. Because svn.tag > *is not* deprecated today. svn.tag is in fact the only way to accomplish > that today. Nobody, not even those running trunk, should be led to believe > that they should replace instances of svn.tag with svn.revision today, > because they should not; doing so would break things for those not running > trunk. Unless you use both, like irssi-devel, then you support 1.7, trunk, actual 1.8, etc... Bryan From mcalhoun at macports.org Mon Mar 23 19:39:32 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Tue, 24 Mar 2009 02:39:32 +0000 (UTC) Subject: Universal and binary builds (was: Re: Is isysroot useful =?utf-8?b?Zm9yCW5vbi11bml2ZXJzYWw/KQ==?= References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> Message-ID: Ryan Schmidt writes: > I'm getting really burned out on universal. ... > > The new muniversal portgroup aims to solve this but has other severe > problems, in that the configure phase runs once for each > architecture, and some configure scripts are written wrong so they > try to run a program at configure time to learn things about the > build environment, which is not appropriate when cross-compiling. So > the configure script exits saying it cannot run a program when cross- > compiling, and the maintainer has to research what those values are > supposed to be for each architecture, possibly getting them wrong. > Many programs simply cannot be cross-compiled so then the list of > supported architectures is reduced, and it's a different list of > supported architectures depending on the computer doing the build. > > What if we set aside what we have now for universal variants and > spent some energy on finally doing binary builds? Finish the script > that builds a port in a clean MacPorts tree in a chroot. Make it > package that up and send it to a download server. Modify MacPorts > base to look for, download and install those binaries first. Make > those binaries integrate properly with the registry. Begin by having > the build server only build the default variant of a port, but later > it can be expanded to build more combinations of variants. We can > work out a system later that allows more variant combinations of an > old port to be built without impacting the building of newly-updated > ports. Since the server will have multiple cores we can run multiple > ports' builds simultaneously, in multiple chroots. I am all for binary builds, but I would suggest that work on universal variants continue (personally I find them very useful). Universal, however, should be limited to 32/64-bit universal as soon as possible. Having changes several ports over the muniversal PortGroup, the biggest obstacle is the cross-compiling (see http://trac.macports.org/attachment/ticket/17042/glib2-Portfile.diff) for the reasons noted above. I can not image that MacPorts ppc/i386 universal builds are in widespread use. -Marcus From ryandesign at macports.org Mon Mar 23 19:50:58 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 23 Mar 2009 21:50:58 -0500 Subject: [48486] trunk/dports/devel/libsdl/Portfile In-Reply-To: <20090323164318.5CC7C12CC8A6@beta.macosforge.org> References: <20090323164318.5CC7C12CC8A6@beta.macosforge.org> Message-ID: On Mar 23, 2009, at 11:43, nox at macports.org wrote: > Revision: 48486 > http://trac.macports.org/changeset/48486 > Author: nox at macports.org > Date: 2009-03-23 09:43:17 -0700 (Mon, 23 Mar 2009) > Log Message: > ----------- > libsdl: Enable nasm only on ppc (fix #18069). Actually your change looks like it was trying to *dis*able nasm only on ppc. However: > @@ -32,8 +32,7 @@ > port:xrender > > configure.args --enable-shared \ > - --mandir=${prefix}/share/man \ > - --disable-nasm > + --mandir=${prefix}/share/man > > variant no_x11 { > configure.args-append --without-x > @@ -122,6 +121,10 @@ > } > } > > +platform darwin ppc { > + configure.args-append --disable-nasm > +} There is no such platform as "ppc". The platform is called "powerpc". From brad at pixilla.com Mon Mar 23 20:16:39 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 23 Mar 2009 20:16:39 -0700 Subject: Universal and binary builds (was: Re: Is isysroot useful for non-universal?) In-Reply-To: References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> Message-ID: <2CE3461A-CD32-48FA-A963-0F62D502CC42@pixilla.com> On Mar 23, 2009, at 3:50 PM, Anders F Bj?rklund wrote: [...] > We could also resume building RPMS, if someone wants to spend > some time on that. The build script could probably produce both > archives and packages in the same run, from the same destroot. RPM may be appealing to many for various reasons and I won't argue that. Apple has created the package format for distributing binaries and it is familiar to most users and does not require any additional software be installed. If macports binaries were packaged in osx package format wouldn't that be more native and there by more attractive then rpms? //Brad From jmr at macports.org Mon Mar 23 20:21:06 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 24 Mar 2009 14:21:06 +1100 Subject: Universal and binary builds In-Reply-To: References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> Message-ID: <49C851A2.7050605@macports.org> Marcus Calhoun-Lopez wrote: > I am all for binary builds, but I would suggest that work on > universal variants continue (personally I find them very useful). It is useful to be able to build universal, but universal *variants* are the wrong way of going about it. > Universal, however, should be limited to 32/64-bit universal as soon as possible. I see no reason to limit the functionality. Changing the default archs, sure. > Having changes several ports over the muniversal PortGroup, the biggest > obstacle is the cross-compiling (see > http://trac.macports.org/attachment/ticket/17042/glib2-Portfile.diff) > for the reasons noted above. Speaking of muniversal, it would be nice if its functionality were integrated into base sooner rather than later, along with a more sane approach to universal building in general. Also, just an observation, muniversal is not a solution that can be applied upstream. When possible, it is preferable to fix things in ways that upstream can adopt. > I can not image that MacPorts ppc/i386 universal builds are in widespread use. That was the *only* kind of MacPorts universal build prior to 1.7. I suspect that ppc/i386 is the combination of choice for those building binary packages. I would go so far as to say that most people who aren't building ppc/i386 don't really want to build universal at all, but want to change the target arch (or OS, though that's an orthogonal issue). - Josh From jmr at macports.org Mon Mar 23 20:25:30 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 24 Mar 2009 14:25:30 +1100 Subject: Universal and binary builds In-Reply-To: <2CE3461A-CD32-48FA-A963-0F62D502CC42@pixilla.com> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <2CE3461A-CD32-48FA-A963-0F62D502CC42@pixilla.com> Message-ID: <49C852AA.9010300@macports.org> Bradley Giesbrecht wrote: > > On Mar 23, 2009, at 3:50 PM, Anders F Bj?rklund wrote: > [...] >> We could also resume building RPMS, if someone wants to spend >> some time on that. The build script could probably produce both >> archives and packages in the same run, from the same destroot. > > > RPM may be appealing to many for various reasons and I won't argue that. > > Apple has created the package format for distributing binaries and it is > familiar to most users and does not require any additional software be > installed. > > If macports binaries were packaged in osx package format wouldn't that > be more native and there by more attractive then rpms? The package format is practically irrelevant for use within MacPorts since all the necessary info should be stored in the registry. For distributing to users who don't have MP installed, .pkg is nice until you want to uninstall... - Josh From jeremyhu at macports.org Mon Mar 23 20:25:40 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Mon, 23 Mar 2009 20:25:40 -0700 Subject: Universal and binary builds (was: Re: Is isysroot useful for non-universal?) In-Reply-To: References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <08DDCC98-ACBA-488C-913C-19543C7FC24A@macports.org> Message-ID: <2B83DEC4-AA70-4E2C-9249-650851DE0D3A@macports.org> On Mar 23, 2009, at 18:43, Ryan Schmidt wrote: >> Since rosetta doesn't handle ppc64, we can't narrow this down to a >> single x86_64 box. > > We can't narrow it down to a single Intel Mac per OS anyway because > one of the problems is that some software doesn't cross-compile > correctly. The point is to eliminate the need for cross-compiling by > compiling natively on each type of Mac. Right, but with rosetta, you *should* (I haven't tried it) be able to setup a ppc chroot and within that chroot it'll look and feel like ppc as far as your build train is concerned (thus it's not "cross" compiling specifically). But still, the lack of ppc64 support within rosetta is probably the bigger issue (atleast in my mind) From ryandesign at macports.org Mon Mar 23 20:43:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 23 Mar 2009 22:43:41 -0500 Subject: Universal and binary builds (was: Re: Is isysroot useful for non-universal?) In-Reply-To: <2B83DEC4-AA70-4E2C-9249-650851DE0D3A@macports.org> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <08DDCC98-ACBA-488C-913C-19543C7FC24A@macports.org> <2B83DEC4-AA70-4E2C-9249-650851DE0D3A@macports.org> Message-ID: <040BA220-BC73-4D3E-8A4E-28A75673BA4B@macports.org> On Mar 23, 2009, at 22:25, Jeremy Huddleston wrote: > On Mar 23, 2009, at 18:43, Ryan Schmidt wrote: > >>> Since rosetta doesn't handle ppc64, we can't narrow this down to >>> a single x86_64 box. >> >> We can't narrow it down to a single Intel Mac per OS anyway >> because one of the problems is that some software doesn't cross- >> compile correctly. The point is to eliminate the need for cross- >> compiling by compiling natively on each type of Mac. > > Right, but with rosetta, you *should* (I haven't tried it) be able > to setup a ppc chroot and within that chroot it'll look and feel > like ppc as far as your build train is concerned (thus it's not > "cross" compiling specifically). But still, the lack of ppc64 > support within rosetta is probably the bigger issue (atleast in my > mind) Ah, well that would be somewhat entertaining, but unless Rosetta is going to grow ppc64 emulation soon, I don't think we need to expend any energy implementing that. From brad at pixilla.com Mon Mar 23 20:53:14 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 23 Mar 2009 20:53:14 -0700 Subject: Universal and binary builds In-Reply-To: <49C852AA.9010300@macports.org> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <2CE3461A-CD32-48FA-A963-0F62D502CC42@pixilla.com> <49C852AA.9010300@macports.org> Message-ID: On Mar 23, 2009, at 8:25 PM, Joshua Root wrote: > Bradley Giesbrecht wrote: >> >> On Mar 23, 2009, at 3:50 PM, Anders F Bj?rklund wrote: >> [...] >>> We could also resume building RPMS, if someone wants to spend >>> some time on that. The build script could probably produce both >>> archives and packages in the same run, from the same destroot. >> >> >> RPM may be appealing to many for various reasons and I won't argue >> that. >> >> Apple has created the package format for distributing binaries and >> it is >> familiar to most users and does not require any additional software >> be >> installed. >> >> If macports binaries were packaged in osx package format wouldn't >> that >> be more native and there by more attractive then rpms? > > The package format is practically irrelevant for use within MacPorts > since all the necessary info should be stored in the registry. > > For distributing to users who don't have MP installed, .pkg is nice > until you want to uninstall... Are uninstall options within a pkg difficult? Many installer distributed in dmg's provide an uninstall script. I guess I just don't see the appeal of rpm. What do you see as the advantages of rpm? Would rpm be internal to the macports port command and leverage rpm dependency checking or something? I'm thinking of all the software I have downloaded in the past like php, mysql, gimp, foo2zjs, foomatic-rip, gutenprint etc... that are already distributed via dmg's. It seems like it would be nice to have macports a popular place to build and distribute such things. //Brad From mcalhoun at macports.org Mon Mar 23 21:45:46 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Tue, 24 Mar 2009 04:45:46 +0000 (UTC) Subject: Universal and binary builds References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <49C851A2.7050605@macports.org> Message-ID: Joshua Root writes: > > Universal, however, should be limited to 32/64-bit universal as soon as > > possible. > > I see no reason to limit the functionality. Changing the default archs, > sure. Granted, but the extra functionality comes with a price, especially in Portfile creation and maintenance. It also adds the problem of dependencies. Now, if one port depends on another, then not only must they both be universal, they must be the same type of universal. Having universal just mean 32/64-bit would greatly simplify things. I would respectfully suggest that the extra functionality is not worth the price. > Speaking of muniversal, it would be nice if its functionality were > integrated into base sooner rather than later, along with a more sane > approach to universal building in general. I agree, but I was hoping that I could create a consensus to limit the meaning of universal to 32/64-bit. It would make incorporating muniversal into the base easier. > > Also, just an observation, muniversal is not a solution that can be > applied upstream. When possible, it is preferable to fix things in ways > that upstream can adopt. Most of the reasons muniversal is needed seem unlikely to be adopted upstream. For example, the configure script checking the size of an int. > > > I can not image that MacPorts ppc/i386 universal builds are in widespread > > use. > > That was the *only* kind of MacPorts universal build prior to 1.7. I > suspect that ppc/i386 is the combination of choice for those building > binary packages. I would go so far as to say that most people who aren't > building ppc/i386 don't really want to build universal at all, but want > to change the target arch (or OS, though that's an orthogonal issue). Perhaps I was wrong about how widespread the use of ppc/i386 use was. It just seems like ppc/i386 universal support has not made great inroads in the Portfiles (other than being turned on by default). -Marcus From toby at macports.org Mon Mar 23 22:31:46 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 23 Mar 2009 22:31:46 -0700 Subject: Universal and binary builds In-Reply-To: References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <49C851A2.7050605@macports.org> Message-ID: <74c219d30903232231q3e600ff2s9e7b0da6d841da36@mail.gmail.com> On Mon, Mar 23, 2009 at 21:45, Marcus Calhoun-Lopez wrote: > Granted, but the extra functionality comes with a price, especially in > Portfile creation and maintenance. > It also adds the problem of dependencies. > Now, if one port depends on another, then not only must they both be > universal, they must be the same type of universal. > Having universal just mean 32/64-bit would greatly simplify things. > I would respectfully suggest that the extra functionality is not worth the price. With a more powerful registry (*cough*), we could record the specific architectures built (rather than "+universal"). This would make it pretty easy to complain (and rebuild?) if someone tries to build a port for architectures its dependencies are not built for. - Toby From ryandesign at macports.org Tue Mar 24 00:16:01 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 24 Mar 2009 02:16:01 -0500 Subject: cpan2port Message-ID: <516FD1B7-2373-4580-B569-C929A2AB4FE8@macports.org> I wanted to use cpan2port today for the first time to make a perl module port. I ran into some problems. First, I had hoped to find cpan2port in the contrib section of the repository: http://trac.macports.org/browser/contrib but it's not there. I found it on the official site here: http://mc.koha-fr.org/mac/cpan2port/lastest and an older version here: http://geeklair.net/~dluke/cpan2port Can it be put into the contrib section of the repository instead? Second, the first line of the script is #! /usr/bin/perl Why is it using Mac OS X perl and not MacPorts perl? Perhaps it could use "#! /usr/bin/env perl" so that it would use the perl that I prefer. Third, I tried to run the script with no parameters, expecting a usage message, but I got: $ ./cpan2port.pl Can't locate Module/Depends.pm in @INC (@INC contains: /System/ Library/Perl/5.8.8/darwin-thread-multi-2level /System/Library/Perl/ 5.8.8 /Library/Perl/5.8.8/darwin-thread-multi-2level /Library/Perl/ 5.8.8 /Library/Perl /Network/Library/Perl/5.8.8/darwin-thread- multi-2level /Network/Library/Perl/5.8.8 /Network/Library/Perl / System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level /System/ Library/Perl/Extras/5.8.8 /Library/Perl/5.8.6 /Library/Perl/5.8.1) at ./cpan2port.pl line 22. BEGIN failed--compilation aborted at ./cpan2port.pl line 22. The script appears to want a module Module::Depends but I guess Mac OS X doesn't provide this. I don't want to use CPAN to install any modules in my Mac OS X perl; I want to use MacPorts to install perl modules for use with MacPorts perl. Then again, we don't seem to have a port p5-module-depends either. Can we add this and any other ports this script needs? Maybe I'm going about this wrong. Clearly the author of the script got it to work, and I assume others have as well since it was announced. Should I be doing something different to use this script? From afb at macports.org Tue Mar 24 00:33:06 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue, 24 Mar 2009 08:33:06 +0100 Subject: Universal and binary builds In-Reply-To: References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <2CE3461A-CD32-48FA-A963-0F62D502CC42@pixilla.com> <49C852AA.9010300@macports.org> Message-ID: Bradley Giesbrecht wrote: >>> RPM may be appealing to many for various reasons and I won't >>> argue that. >>> >>> Apple has created the package format for distributing binaries >>> and it is >>> familiar to most users and does not require any additional >>> software be >>> installed. >>> >>> If macports binaries were packaged in osx package format wouldn't >>> that >>> be more native and there by more attractive then rpms? >> >> The package format is practically irrelevant for use within MacPorts >> since all the necessary info should be stored in the registry. >> >> For distributing to users who don't have MP installed, .pkg is nice >> until you want to uninstall... > > Are uninstall options within a pkg difficult? No, theoretically you would just hit "Uninstall" on the receipt file... It's just that the feature has been removed from Installer for a while. > Many installer distributed in dmg's provide an uninstall script. Right, those are normally created manually and known as "a workaround". I suppose "port dmg" target could create such uninstaller programs too. > I guess I just don't see the appeal of rpm. What do you see as the > advantages of rpm? - It's free software. - It's cross-platform. - It doesn't require a dmg wrapper (fixed with "flat" packages, but still). - It offers much better compression than gzip, such as bzip2 or lzma or xz. - It has much better metadata, and offer powerful queries on such metadata. - It has multiple signature and digest formats included within the package. - It has SRPMS for source. - You can uninstall them. But I might be slightly biased, since I maintain RPM for Mac OS X and FreeBSD. You can find more information about RPM outside of MacPorts on http:// rpm5.org > Would rpm be internal to the macports port command and leverage rpm > dependency checking or something? It could be (see "dp_light"* or Fink), or it could run on external packages. * http://web.archive.org/web/20060616124730/http://opendarwin.org/ ~olegb/notes/NOTES_ON_DPLIGHT.TXT That is, you could use MacPorts to build the RPMS and then use RPM tools to install them. Not that port would have any clue that they were installed (unless someone writes the rpmdb<->registry integration), so it would be about the same as using pkg packages. Neither needs port to be installed. For now there is no development on it though, so MP is using the "archives". > I'm thinking of all the software I have downloaded in the past like > php, mysql, gimp, foo2zjs, foomatic-rip, gutenprint etc... that are > already distributed via dmg's. What's inside those packages could vary a bit, but I assume you mean pkg here ? > It seems like it would be nice to have macports a popular place to > build and distribute such things. MacPorts is rather poor at building stand-alone installers, besides for itself. The meta-packages are rather huge, mostly manual to install and to update and keep updated - and has all the same problems as regular Installer packages do. Still, people seem to like them so against my better judgement I fixed them... --anders From jkh at apple.com Tue Mar 24 02:04:43 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue, 24 Mar 2009 02:04:43 -0700 Subject: Universal and binary builds In-Reply-To: References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <2CE3461A-CD32-48FA-A963-0F62D502CC42@pixilla.com> <49C852AA.9010300@macports.org> Message-ID: <666824FB-87FD-49CD-AE1B-73E63C483BD6@apple.com> Oh gee. Package management. My favorite subject.... TEN YEARS AGO. ;-) On Mar 23, 2009, at 8:53 PM, Bradley Giesbrecht wrote: > Are uninstall options within a pkg difficult? Yes. The .pkg format is basically just cpio on a small dose of steroids. Strictly one-way, and the pre/post-flight scripts are also allowed to do pretty much anything else they want, assuming you hand them the privileges to do so (which, of course, almost everyone does). > Many installer distributed in dmg's provide an uninstall script. That is an entirely optional "hi, we're being nice" extra that the vendors who produce those dmgs roll by hand, generally speaking, and they don't exactly scale to hundreds of installed software packages. > I guess I just don't see the appeal of rpm. What do you see as the > advantages of rpm? > Would rpm be internal to the macports port command and leverage rpm > dependency checking or something? I think you're asking the wrong question. The right question is not "is package format foo better than package format bar?" but rather "what exactly are we trying to do?" I think the MacPorts project has essentially paralyzed itself with respect to package formats, and the subsequent task of package production, by taking the position of "we'll just support all package formats! badly!", thus essentially rendering all choices equally mediocre and unappetizing to anyone wishing to experiment with this side of MacPorts. That's a shame, because I think it's a good example of some bit of code filling a much- needed vacuum, tricking future generations into walking down the wrong path and into a bad part of town. :-) "What's ``the right path'' then?", I hear you ask. Glad you asked! The right idea is to go back to that more fundamental "what exactly are we trying to do?" question and try to answer it first, deciding what constitutes a package in MacPorts-land and how much of a role, if any, the MacPorts project wants to take in producing packages for popular consumption. Once you have those answers, assuming that you've decided to go anywhere with packaging at all, you can attack the problem by writing something strictly to spec, swearing under pain of death that it will absolutely never be any more complicated or feature-full than it needs to be at any given time. That will keep you out of the La Brea Tarpit of package management tools, where the temptation to be too clever/forward-looking can quickly lead to an explosion of options and special-case behavior that rapidly complicates what should actually be relatively simple. > I'm thinking of all the software I have downloaded in the past like > php, mysql, gimp, foo2zjs, foomatic-rip, gutenprint etc... that are > already distributed via dmg's. I'll also bet that the majority of those dmgs also bundle each and every dependency they need, thus ensuring that if php, mysql or gimp from your list above need, say, libjpeg, they all have their own copy so that you can drag the resulting bundle around. That's always one way of doing it, of course, and even one with certain advantages (or drag installs would not be as popular as they are), but it's even less of a managed-package scenario than what most users currently have in / opt/local. Some might even choose to continue to build everything themselves (thus raising the overall carbon footprint of Mac users everywhere ;-) rather than go "the dmg route" because they like the notion of non-duplicated bits and targeted / small security updates. It would be nice[er] IMO if a solution could be devised which makes "port install foo" and "pkg install file:///foo.xar" lead to exactly the same place. Well, to be even more precise, it would be nicer still if "port install foo" simply became a wrapper around "port package foo -o /var/tmp//foo.pkg && pkg install file:///var/tmp //foo.pkg && rm -f /var/tmp//foo.pkg" so that the base MacPorts infrastructure could just get out of the business of directly installing bits on the system. Just my two cents. ;) - Jordan From febeling at macports.org Tue Mar 24 02:11:25 2009 From: febeling at macports.org (C. Florian Ebeling) Date: Tue, 24 Mar 2009 10:11:25 +0100 Subject: Migrate app data on upgrade In-Reply-To: <037C799F-B466-4228-95B9-70EF4B71FE2B@macports.org> References: <5cbbe4ae0903231404t22e611deo8708e61d37bb94c7@mail.gmail.com> <037C799F-B466-4228-95B9-70EF4B71FE2B@macports.org> Message-ID: <5cbbe4ae0903240211m6274055cwc8f4d03495c374c5@mail.gmail.com> On Tue, Mar 24, 2009 at 2:54 AM, Ryan Schmidt wrote: > On Mar 23, 2009, at 16:04, C. Florian Ebeling wrote: > >> Is there a working example of migrating app data to a new format in a >> some port? There are obviously a number of issues with doing something >> like this: >> >> - finding the source format version from a portfile with higher version >> - finding app data from a range of versions in possibly a number of >> locations >> - working with a number of formats from a higher version portfile, >> and previous (creating) versions possibly uninstalled >> - probably many others >> >> Are there good paths to follow? Is it worth doing? Is having >> version-specific (default) data directories a good idea (And then >> offering people export in old and import in new version, advertised by >> ui_msgs)? What do other distros do? > > I don't think upgrading a port should upgrade any user data. If an upgrade > of user data is necessary, the user should be advised how to do so, but it > should be left to the user to do. Yes, I know this is the classical mp answer. But why is this the best way to do it? Other distros do something like this obviously. One possible answer is that it is out of the scope of mp, or something. But we could maybe also think a bit about it. We could for instance create/document a well-known variant ("migrate-data"?) which people could configure. Then every portfile author could hook into this general approach and decide if she wants to provide it meaningfully in a port. Something similar could be offered for starting and stopping services. If they are off by default that would still give people with concerns about mp doing such things a safe environment, but in the background maintainers could provide more seamless procedures. Just thinking out loud. Florian -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From afb at macports.org Tue Mar 24 03:11:26 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue, 24 Mar 2009 11:11:26 +0100 Subject: Universal and binary builds In-Reply-To: <666824FB-87FD-49CD-AE1B-73E63C483BD6@apple.com> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <2CE3461A-CD32-48FA-A963-0F62D502CC42@pixilla.com> <49C852AA.9010300@macports.org> <666824FB-87FD-49CD-AE1B-73E63C483BD6@apple.com> Message-ID: <5F29AE20-54CD-444F-AEF0-4DE102243D77@macports.org> Jordan K. Hubbard wrote: >> I guess I just don't see the appeal of rpm. What do you see as the >> advantages of rpm? >> Would rpm be internal to the macports port command and leverage >> rpm dependency checking or something? > > I think you're asking the wrong question. The right question is > not "is package format foo better than package format bar?" but > rather "what exactly are we trying to do?" Was it about package formats (.rpm and .deb), or about package managers (rpm and dpkg) ? If it's just about the file format, then yes one might as well use .tar or .xar instead. > I think the MacPorts project has essentially paralyzed itself with > respect to package formats, and the subsequent task of package > production, by taking the position of "we'll just support all > package formats! badly!", thus essentially rendering all choices > equally mediocre and unappetizing to anyone wishing to experiment > with this side of MacPorts. That's a shame, because I think it's a > good example of some bit of code filling a much-needed vacuum, > tricking future generations into walking down the wrong path and > into a bad part of town. :-) Wasn't that why we went with the destroot archives last year, "just to get it started" ? I don't think it was the archive format that was the big obstacle to MacPorts binaries... > "What's ``the right path'' then?", I hear you ask. Glad you > asked! The right idea is to go back to that more fundamental > "what exactly are we trying to do?" question and try to answer it > first, deciding what constitutes a package in MacPorts-land and how > much of a role, if any, the MacPorts project wants to take in > producing packages for popular consumption. Once you have those > answers, assuming that you've decided to go anywhere with packaging > at all, you can attack the problem by writing something strictly to > spec, swearing under pain of death that it will absolutely never be > any more complicated or feature-full than it needs to be at any > given time. That will keep you out of the La Brea Tarpit of > package management tools, where the temptation to be too clever/ > forward-looking can quickly lead to an explosion of options and > special-case behavior that rapidly complicates what should actually > be relatively simple. I mistook it for an technical/engineering problem first, when it really wasn't. It shouldn't matter much for the big picture whether txt+tar or xml +xar is used. I found it easier to build my packages outside of MacPorts (whether application bundles or RPM packages), while the project tries to answer the basic question... > [...] It would be nice[er] IMO if a solution could be devised which > makes "port install foo" and "pkg install file:///foo.xar" lead to > exactly the same place. Well, to be even more precise, it would be > nicer still if "port install foo" simply became a wrapper around > "port package foo -o /var/tmp//foo.pkg && pkg install > file:///var/tmp//foo.pkg && rm -f /var/tmp// > foo.pkg" so that the base MacPorts infrastructure could just get > out of the business of directly installing bits on the system. This is what Fink does with dpkg, and what was tried (in "dp_light") with rpm. There was even some talk about reviving xpkg (using xar) to do it for MacPorts. "port xpkg" should be operational to create the xar archive (with xml metadata). I guess it's just waiting for someone to complete the xpkg(1) implementation ? --anders From afb at macports.org Tue Mar 24 03:26:45 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue, 24 Mar 2009 11:26:45 +0100 Subject: Universal and binary builds (was: Re: Is isysroot useful for non-universal?) In-Reply-To: <040BA220-BC73-4D3E-8A4E-28A75673BA4B@macports.org> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <08DDCC98-ACBA-488C-913C-19543C7FC24A@macports.org> <2B83DEC4-AA70-4E2C-9249-650851DE0D3A@macports.org> <040BA220-BC73-4D3E-8A4E-28A75673BA4B@macports.org> Message-ID: Ryan Schmidt wrote: >>>> Since rosetta doesn't handle ppc64, we can't narrow this down to >>>> a single x86_64 box. >>> >>> We can't narrow it down to a single Intel Mac per OS anyway >>> because one of the problems is that some software doesn't cross- >>> compile correctly. The point is to eliminate the need for cross- >>> compiling by compiling natively on each type of Mac. >> >> Right, but with rosetta, you *should* (I haven't tried it) be able >> to setup a ppc chroot and within that chroot it'll look and feel >> like ppc as far as your build train is concerned (thus it's not >> "cross" compiling specifically). But still, the lack of ppc64 >> support within rosetta is probably the bigger issue (atleast in my >> mind) > > Ah, well that would be somewhat entertaining, but unless Rosetta is > going to grow ppc64 emulation soon, I don't think we need to expend > any energy implementing that. I used virtualization (x86) or emulation (ppc) to build packages for "Pure" Darwin... 47M /opt/local/var/db/dports/packages/darwin/x86/XFree86-4.5.0_2 +puredarwin.x86.tgz 49M /opt/local/var/db/dports/packages/darwin/powerpc/ XFree86-4.5.0_2+puredarwin.powerpc.tgz It took ages or eons, but did "work". For Mac OS X, I think there's licensing issues. While cross-compiling and virtual build machines does have some entertaining value, you would probably be better off with one hardware node per OS/arch and a chroot ? Assuming that you're even going to build PowerPC binaries, it shouldn't be so hard finding cheap used hardware for it. The new machines available only use Intel anyway. --anders From jkh at apple.com Tue Mar 24 03:31:34 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue, 24 Mar 2009 03:31:34 -0700 Subject: Universal and binary builds In-Reply-To: <5F29AE20-54CD-444F-AEF0-4DE102243D77@macports.org> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <2CE3461A-CD32-48FA-A963-0F62D502CC42@pixilla.com> <49C852AA.9010300@macports.org> <666824FB-87FD-49CD-AE1B-73E63C483BD6@apple.com> <5F29AE20-54CD-444F-AEF0-4DE102243D77@macports.org> Message-ID: On Mar 24, 2009, at 3:11 AM, Anders F Bj?rklund wrote: > Jordan K. Hubbard wrote: > >>> I guess I just don't see the appeal of rpm. What do you see as the >>> advantages of rpm? >>> Would rpm be internal to the macports port command and leverage >>> rpm dependency checking or something? >> >> I think you're asking the wrong question. The right question is >> not "is package format foo better than package format bar?" but >> rather "what exactly are we trying to do?" > > Was it about package formats (.rpm and .deb), or about package > managers (rpm and dpkg) ? Yes. :) I was using "package format" much more in the sense of "choosing that particular religion", one which includes a number of pre-existing tools and even certain policies that it would be wise to adhere to if either .rpm or .deb were chosen as the target package file format. However, I don't think that the future lies with either, as I suspect you also agree. >> I think the MacPorts project has essentially paralyzed itself with >> respect to package formats, and the subsequent task of package >> production, by taking the position of "we'll just support all >> package formats! badly!", thus essentially rendering all choices >> equally mediocre and unappetizing to anyone wishing to experiment >> with this side of MacPorts. That's a shame, because I think it's a >> good example of some bit of code filling a much-needed vacuum, >> tricking future generations into walking down the wrong path and >> into a bad part of town. :-) > > Wasn't that why we went with the destroot archives last year, "just > to get it started" ? Frankly, I was never all that sure why the archivemode stuff came along, so I suspect you're asking the wrong person. I've never used an archive for anything explicitly myself, and I always rather assumed that they were being used as a quick and dirty way of satisfying dependencies behind the scenes, should you choose to grab a copy of somebody else's archives, but that's just an assumption. The problem is more complex than mere archival in any case, since there is no provision for recording install-time actions in the archive or specifying other package metadata. I would also hope that the notion of signed packages would be on the very first version of the wish list. :) > I mistook it for an technical/engineering problem first, when it > really wasn't. > It shouldn't matter much for the big picture whether txt+tar or xml > +xar is used. Nope! Most of the interesting parts of the problem lie in how you take that tarball, or whatever, and add just enough secret sauce to cover the resolution of package dependencies (on other packages, specific system settings / accounts, ...). > > This is what Fink does with dpkg, and what was tried (in "dp_light") > with rpm. > There was even some talk about reviving xpkg (using xar) to do it > for MacPorts. That would be cool. > "port xpkg" should be operational to create the xar archive (with > xml metadata). > I guess it's just waiting for someone to complete the xpkg(1) > implementation ? Pretty much, yeah! I think xar/xpkg would be a fine selection, myself, since it seems to do a pretty good job of embodying the "really no more than you need" approach, while remaining extensible. At this point, xpkg(1) itself and the relevant xpkg support in MacPorts are the biggest blockers. Some success with the mpab project would also help start digging the tunnel from the other side of the mountain, so to speak, but that's not strictly necessary for progress. - Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: From afb at macports.org Tue Mar 24 03:59:31 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue, 24 Mar 2009 11:59:31 +0100 Subject: Universal and binary builds In-Reply-To: References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <2CE3461A-CD32-48FA-A963-0F62D502CC42@pixilla.com> <49C852AA.9010300@macports.org> <666824FB-87FD-49CD-AE1B-73E63C483BD6@apple.com> <5F29AE20-54CD-444F-AEF0-4DE102243D77@macports.org> Message-ID: <3F65EF0A-0614-4DD6-B833-82D91028D60F@macports.org> Jordan K. Hubbard wrote: >>> I think you're asking the wrong question. The right question is >>> not "is package format foo better than package format bar?" but >>> rather "what exactly are we trying to do?" >> >> Was it about package formats (.rpm and .deb), or about package >> managers (rpm and dpkg) ? > > Yes. :) I was using "package format" much more in the sense of > "choosing that particular religion", one which includes a number of > pre-existing tools and even certain policies that it would be wise > to adhere to if either .rpm or .deb were chosen as the target > package file format. However, I don't think that the future lies > with either, as I suspect you also agree. I meant it as in if talking about archives (for port) or packages (for rpm). If it's "just an archive format", then port doesn't need more than rpm2cpio (or similar) to pry the bits open and then extract the destroot contents... But if choosing the particular religion and building "real" packages for it, then it probably would need to follow a bunch of rules and traditions yes. RPM still works, but I don't think the "dp_light" alternative is in MP future. >>> Wasn't that why we went with the destroot archives last year, >>> "just to get it started" ? > > Frankly, I was never all that sure why the archivemode stuff came > along, so I suspect you're asking the wrong person. I've never > used an archive for anything explicitly myself, and I always rather > assumed that they were being used as a quick and dirty way of > satisfying dependencies behind the scenes, should you choose to > grab a copy of somebody else's archives, but that's just an > assumption. The problem is more complex than mere archival in any > case, since there is no provision for recording install-time > actions in the archive or specifying other package metadata. I do enable archivemode though, since it's a good way to save time and space for me. Not having to rebuild from source, and being able to compress inactive. I've found the darwinports/macports archives (.tgz) to work "just as well" as the FreeBSD packages. Then again, that's "not very good" beyond initial install. > I would also hope that the notion of signed packages would be on > the very first version of the wish list. :) There's .tgz.asc (for GPG) which seems to be "good enough" in the same way... Not sure if xar offers much extra help in the signature department, though ? >> I mistook it for an technical/engineering problem first, when it >> really wasn't. >> It shouldn't matter much for the big picture whether txt+tar or xml >> +xar is used. > > Nope! Most of the interesting parts of the problem lie in how you > take that tarball, or whatever, and add just enough secret sauce to > cover the resolution of package dependencies (on other packages, > specific system settings / accounts, ...). The current "solution" is to just dump the Portfile's Tcl for reading "later". Then again, port also reads the registry rather than look at the archive data. >> This is what Fink does with dpkg, and what was tried (in >> "dp_light") with rpm. >> There was even some talk about reviving xpkg (using xar) to do it >> for MacPorts. > > That would be cool. Cool, but not very popular ? Then again, the release xar 1.6 is slightly delayed. (it's been in the "development" stage since 2007, the svn is still being updated) >> "port xpkg" should be operational to create the xar archive (with >> xml metadata). >> I guess it's just waiting for someone to complete the xpkg(1) >> implementation ? > > Pretty much, yeah! I think xar/xpkg would be a fine selection, > myself, since it seems to do a pretty good job of embodying the > "really no more than you need" approach, while remaining > extensible. At this point, xpkg(1) itself and the relevant xpkg > support in MacPorts are the biggest blockers. Some success with > the mpab project would also help start digging the tunnel from the > other side of the mountain, so to speak, but that's not strictly > necessary for progress. There's a "xpkg-0.2dev" lurking, if anyone else wants to continue developing it... See http://web.archive.org/web/20061230221957/http://www.xpkg.org/ for 0.1.3 --anders From jmr at macports.org Tue Mar 24 05:42:14 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 24 Mar 2009 23:42:14 +1100 Subject: Universal and binary builds In-Reply-To: References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <49C851A2.7050605@macports.org> Message-ID: <49C8D526.4020503@macports.org> Marcus Calhoun-Lopez wrote: > Joshua Root writes: > >>> Universal, however, should be limited to 32/64-bit universal as soon as >>> possible. >> I see no reason to limit the functionality. Changing the default archs, >> sure. > Granted, but the extra functionality comes with a price, especially in > Portfile creation and maintenance. > It also adds the problem of dependencies. > Now, if one port depends on another, then not only must they both be > universal, they must be the same type of universal. > Having universal just mean 32/64-bit would greatly simplify things. > I would respectfully suggest that the extra functionality is not worth the price. Once again, I don't believe that the vast majority of users really want universal, they are just using it as a hack to get x86_64. There may be a few sharing builds between an i386 and a ppc machine, but they would be better served by binaries. Those that do need universal can reasonably be expected to know what they're doing, and the "price" isn't all that high anyway, since making this work maps exactly to a fix for #126. >> Also, just an observation, muniversal is not a solution that can be >> applied upstream. When possible, it is preferable to fix things in ways >> that upstream can adopt. > Most of the reasons muniversal is needed seem unlikely to be adopted upstream. > For example, the configure script checking the size of an int. I don't see why autoconf wouldn't accept a patch making their macros do the right thing in case of multi-word-size, or why projects using autoconf wouldn't accept patches to use the updated macros correctly. - Josh From raimue at macports.org Tue Mar 24 06:35:46 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 24 Mar 2009 14:35:46 +0100 Subject: [48432] trunk/dports/irc/irssi-devel/Portfile In-Reply-To: <51E0DB02-0FD3-4FCC-B2C0-3B3282518AE0@macports.org> References: <20090321234843.A22B512B5110@beta.macosforge.org> <9F14C83C-8230-4397-ACA6-E45376B62AAF@macports.org> <20090322073106.GA8488@ninagal.withay.com> <32CB5F42-5935-4FAD-B1C4-0742E3083B1B@macports.org> <74c219d30903230749w33e94126h65bf436270a592f6@mail.gmail.com> <51E0DB02-0FD3-4FCC-B2C0-3B3282518AE0@macports.org> Message-ID: <49C8E1B2.6040804@macports.org> Ryan Schmidt wrote: >> It's deprecated if you're running trunk. No warning for 1.7 users. > > Right, and I am suggesting that we remove the deprecation warning for > svn.tag from trunk again, and not re-add it until the next version of > MacPorts has been released which includes svn.revision. Because > svn.tag *is not* deprecated today. svn.tag is in fact the only way to > accomplish that today. Nobody, not even those running trunk, should > be led to believe that they should replace instances of svn.tag with > svn.revision today, because they should not; doing so would break > things for those not running trunk. svn.tag is deprecated on trunk now as it will be in 1.8. I expect anybody running trunk to follow macports-dev and be aware of these changes. The deprecation code I implemented keeps the options in sync. That means for example after setting svn.tag to 42, a read of svn.revision will give you 42 (works also vice-versa). So Portfiles with svn.tag still work without problems on trunk, but once 1.8 is released they should be updated to use svn.revsion instead. It is backwards compatible to <=1.7 and that is enough in my opinion. I agree that the warning is a bit annoying, and I did not commit the livecheck.check -> livecheck.type rename yet because it is even more talkative. The deprecation warning there appears for nearly all ports, each time it is parsed. For example on a dependency walk. I will look into a different approach so the warning will only be displayed on running 'port lint'. Normal users can't do anything with it anyway. Rainer From mcalhoun at macports.org Tue Mar 24 08:20:03 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Tue, 24 Mar 2009 15:20:03 +0000 (UTC) Subject: Universal and binary builds References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <49C851A2.7050605@macports.org> <49C8D526.4020503@macports.org> Message-ID: Joshua Root writes: > Once again, I don't believe that the vast majority of users really want > universal, they are just using it as a hack to get x86_64. There may be > a few sharing builds between an i386 and a ppc machine, but they would > be better served by binaries. If the vast majority of users really just want x86_64, then it seems simplifying universal to 32/64-bit would be closer to what they want than the mixture of 4 architectures we have now. > Those that do need universal can reasonably be expected to know what > they're doing, and the "price" isn't all that high anyway, since making > this work maps exactly to a fix for #126. When talking about "price," I was referring to maintenance of Portfiles and base code. Getting cross-compiling to work can be a painful undertaking (see the patch in #17042). > >> Also, just an observation, muniversal is not a solution that can be > >> applied upstream. When possible, it is preferable to fix things in ways > >> that upstream can adopt. > > Most of the reasons muniversal is needed seem unlikely to be > > adopted upstream. > > For example, the configure script checking the size of an int. > > I don't see why autoconf wouldn't accept a patch making their macros do > the right thing in case of multi-word-size, or why projects using > autoconf wouldn't accept patches to use the updated macros correctly. Perhaps they would, but based on the ports I have checked so far, it would be a lot of patches to a lot of projects. In any event, the muniversal PortGroup (and the ideas which should be included in the base code) are a good way of catching the projects where a patch is necessary. -Marcus From jeremy at lavergne.gotdns.org Tue Mar 24 10:47:29 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 24 Mar 2009 13:47:29 -0400 Subject: suggestion for package website Message-ID: I was perusing Arch's website today and noticed there's a "flag package out-of-date" link when you're viewing information about a package. Is this something we might find worthwhile for MacPorts since not everything has a livecheck? I presume it can put a community-initiated flag of "might be out of date" on the page and fire an email off to the maintainer (or if open-/ no-maintainer to the dev list). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From milosh at macports.org Tue Mar 24 11:17:31 2009 From: milosh at macports.org (Emmanuel Hainry) Date: Tue, 24 Mar 2009 19:17:31 +0100 Subject: suggestion for package website In-Reply-To: References: Message-ID: <20090324181731.GA6985@velsheda.lateralis.org> Citando Jeremy Lavergne : > I was perusing Arch's website today and noticed there's a "flag package > out-of-date" link when you're viewing information about a package. Is > this something we might find worthwhile for MacPorts since not everything > has a livecheck? > > I presume it can put a community-initiated flag of "might be out of > date" on the page and fire an email off to the maintainer (or if open-/ > no-maintainer to the dev list). > I have a few ports that I keep voluntarily in an out-of-date state (because the newer version does not compile without work and does not add any useful feature). If someone finds it is worth updating, then he can spend the time to open a trac ticket requesting an update. This way, it is possible to explain why not update it. I feel that a feature request must put a little work on the requester as it can give a lot of work to the maintainer. Emmanuel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From jmr at macports.org Tue Mar 24 12:12:06 2009 From: jmr at macports.org (Joshua Root) Date: Wed, 25 Mar 2009 06:12:06 +1100 Subject: suggestion for package website In-Reply-To: References: Message-ID: <49C93086.6030109@macports.org> Jeremy Lavergne wrote: > I was perusing Arch's website today and noticed there's a "flag package > out-of-date" link when you're viewing information about a package. Is > this something we might find worthwhile for MacPorts since not > everything has a livecheck? > > I presume it can put a community-initiated flag of "might be out of > date" on the page and fire an email off to the maintainer (or if > open-/no-maintainer to the dev list). Sure, there's all kinds of stuff like that that we could do with a working MPWA/db.macports.org. - Josh From florian.ebeling at gmail.com Tue Mar 24 13:05:21 2009 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Tue, 24 Mar 2009 21:05:21 +0100 Subject: suggestion for package website In-Reply-To: <49C93086.6030109@macports.org> References: <49C93086.6030109@macports.org> Message-ID: <5cbbe4ae0903241305n2f33b846iac54ee8ad86341a2@mail.gmail.com> > Sure, there's all kinds of stuff like that that we could do with a > working MPWA/db.macports.org. What's the status of this thing anyway? -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From raimue at macports.org Tue Mar 24 14:39:41 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 24 Mar 2009 22:39:41 +0100 Subject: suggestion for package website In-Reply-To: <5cbbe4ae0903241305n2f33b846iac54ee8ad86341a2@mail.gmail.com> References: <49C93086.6030109@macports.org> <5cbbe4ae0903241305n2f33b846iac54ee8ad86341a2@mail.gmail.com> Message-ID: <49C9531D.40101@macports.org> C. Florian Ebeling wrote: >> Sure, there's all kinds of stuff like that that we could do with a >> working MPWA/db.macports.org. > > What's the status of this thing anyway? It is on our ideas list for Google Summer of Code this year again, as it already was last year, but the project failed on the student-side. James Berry will be the mentor for this. The old version which was once online on db.macports.org (without much functionality) can still be found on . Rainer From jeremy at lavergne.gotdns.org Tue Mar 24 16:25:30 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 24 Mar 2009 19:25:30 -0400 Subject: [MacPorts] SummerOfCode modified In-Reply-To: <20090324231640.07B0D2808C@relay13.apple.com> References: <20090324231640.07B0D2808C@relay13.apple.com> Message-ID: <71EE5A8B-663C-4478-AF71-D46ECEF0665F@lavergne.gotdns.org> Were both of those links suppose to be to macports-dev ? On Mar 24, 2009, at 7:16 PM, MacPorts wrote: > > Changed page "SummerOfCode" by raimue at macports.org from 91.11.216.162* > Page URL: > Diff URL: > > Revision 106 > > -------8 > <------8<------8<------8<------8<------8<------8<------8<-------- > Index: SummerOfCode > = > = > = > ====================================================================== > --- SummerOfCode (version: 105) > +++ SummerOfCode (version: 106) > @@ -29,6 +29,7 @@ > * Write your own abstract and proposal, copying text from this idea > page is not enough > * Get familiar with the MacPorts project resources. Especially > [GetMacPortsSource check out the code] and [http:// > guide.macports.org read the guide]. > * Read the [http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html > Tcl Tutorial] > + * Subscribe to the mailing lists [http://lists.macosforge.org/mailman/listinfo/macports-dev > macports-dev] and [http://lists.macosforge.org/mailman/listinfo/macports-dev > macports-users] if you do not already read them. Don't be too shy > to post. > * Get in contact! Discuss your contribution ideas with potential > mentors by e-mail, on the MacPorts development list or the IRC > channel '''before applying'''. > > == Mentors == > > -------8 > <------8<------8<------8<------8<------8<------8<------8<-------- > > * The IP shown here might not mean anything if the user or the > server is > behind a proxy. > > -- > MacPorts > Ports system for Mac OS > > This is an automated message. Someone at http://www.macports.org/ > added your email > address to be notified of changes on SummerOfCode. If it was not > you, please > report to . > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From raimue at macports.org Tue Mar 24 16:43:17 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 25 Mar 2009 00:43:17 +0100 Subject: [MacPorts] SummerOfCode modified In-Reply-To: <71EE5A8B-663C-4478-AF71-D46ECEF0665F@lavergne.gotdns.org> References: <20090324231640.07B0D2808C@relay13.apple.com> <71EE5A8B-663C-4478-AF71-D46ECEF0665F@lavergne.gotdns.org> Message-ID: <49C97015.7040300@macports.org> Jeremy Lavergne wrote: > Were both of those links suppose to be to macports-dev ? Of course not, thanks for noticing. Copy and paste error :-) Fixed now. Rainer From raimue at macports.org Tue Mar 24 19:23:51 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 25 Mar 2009 03:23:51 +0100 Subject: [48432] trunk/dports/irc/irssi-devel/Portfile In-Reply-To: <49C8E1B2.6040804@macports.org> References: <20090321234843.A22B512B5110@beta.macosforge.org> <9F14C83C-8230-4397-ACA6-E45376B62AAF@macports.org> <20090322073106.GA8488@ninagal.withay.com> <32CB5F42-5935-4FAD-B1C4-0742E3083B1B@macports.org> <74c219d30903230749w33e94126h65bf436270a592f6@mail.gmail.com> <51E0DB02-0FD3-4FCC-B2C0-3B3282518AE0@macports.org> <49C8E1B2.6040804@macports.org> Message-ID: <49C995B7.2020602@macports.org> Rainer M?ller wrote: > I agree that the warning is a bit annoying, and I did not commit the > livecheck.check -> livecheck.type rename yet because it is even more > talkative. The deprecation warning there appears for nearly all ports, > each time it is parsed. For example on a dependency walk. I will look > into a different approach so the warning will only be displayed on > running 'port lint'. Normal users can't do anything with it anyway. Whereas 'port lint' does not run all code paths like variants, pre-/post- or overriden phases. Hmmmm... Rainer From allencmcbride at gmail.com Tue Mar 24 20:23:49 2009 From: allencmcbride at gmail.com (Allen McBride) Date: Tue, 24 Mar 2009 23:23:49 -0400 Subject: no comments on my port submission yet? Message-ID: Hi folks, I submitted a port a little over a week ago (http://trac.macports.org/ticket/18870 ), but no one has committed it or commented on it yet. No big hurry, but in someone else's earlier ticket (http://trac.macports.org/ticket/18220 ), Rainer suggested that people nudge this list in such cases, so I thought I'd write. Thanks, Allen From ryandesign at macports.org Tue Mar 24 20:35:53 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 24 Mar 2009 22:35:53 -0500 Subject: Universal and binary builds (was: Re: Is isysroot useful for non-universal?) In-Reply-To: References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <08DDCC98-ACBA-488C-913C-19543C7FC24A@macports.org> <2B83DEC4-AA70-4E2C-9249-650851DE0D3A@macports.org> <040BA220-BC73-4D3E-8A4E-28A75673BA4B@macports.org> Message-ID: On Mar 24, 2009, at 05:26, Anders F Bj?rklund wrote: > While cross-compiling and virtual build machines does have some > entertaining value, > you would probably be better off with one hardware node per OS/arch > and a chroot ? I'd like that. > Assuming that you're even going to build PowerPC binaries, it > shouldn't be so hard > finding cheap used hardware for it. The new machines available only > use Intel anyway. If we want to support universal binaries -- and given the effort that's been put in so far on our existing solutions, I'd say there is some interest in this -- then I'd say we should build PowerPC binaries too. It would surprise me if Apple didn't still have a few G5 Xserves around that could be repurposed. From raimue at macports.org Tue Mar 24 20:41:24 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 25 Mar 2009 04:41:24 +0100 Subject: Deprecating port list In-Reply-To: <49BBBD3D.60608@macports.org> References: <49B916AD.7020203@macports.org> <5cbbe4ae0903121446r4fdd20b3tb9abd8716f348e5e@mail.gmail.com> <12a697af0903121534s4b0f3dd8vdf5a405d5313a640@mail.gmail.com> <49B9E9E8.4060401@macports.org> <12a697af0903122328g55a0d0aai1f63daee8883e87d@mail.gmail.com> <0B91728B-7A87-4F49-B170-C6EC3A499B41@macports.org> <12a697af0903130922w1ffbbb6at2780ae6e861f4443@mail.gmail.com> <8F97E751-850F-4E51-93D6-6258F9BF6C5F@pixilla.com> <77e4079b0903140115o4a3aa76fj722c1d049db9ac1d@mail.gmail.com> <49BBBD3D.60608@macports.org> Message-ID: <49C9A7E4.3070405@macports.org> Rainer M?ller wrote: > On 14.03.2009 9:15 Uhr, Neil wrote: >> Why not send "The following ports are currently installed:" to stderr? > > Hm, stderr and stdout do not have to be synchron, I am not sure it is a > good idea to mix them for this purpose. > > Recently I added a wrapper around isatty(3) which is already used in > port. It decides if the output is a tty or a pipe/file. I will look into > removing the header if the output is not a tty. I decided that this would be bad behavior. It would make it impossible to capture the port output. For example, think of commands like "port ... | tee foo.log" or "port ... >foo.log". Instead, the headers are no longer printed if you are using the quiet flag, "port -q". I hope this is a good compromise and should satisfy all. Rainer From raimue at macports.org Tue Mar 24 20:47:01 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 25 Mar 2009 04:47:01 +0100 Subject: Universal and binary builds In-Reply-To: References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <08DDCC98-ACBA-488C-913C-19543C7FC24A@macports.org> <2B83DEC4-AA70-4E2C-9249-650851DE0D3A@macports.org> <040BA220-BC73-4D3E-8A4E-28A75673BA4B@macports.org> Message-ID: <49C9A935.7050500@macports.org> Ryan Schmidt wrote: >> Assuming that you're even going to build PowerPC binaries, it >> shouldn't be so hard >> finding cheap used hardware for it. The new machines available only >> use Intel anyway. > > If we want to support universal binaries -- and given the effort > that's been put in so far on our existing solutions, I'd say there is > some interest in this -- then I'd say we should build PowerPC > binaries too. It would surprise me if Apple didn't still have a few > G5 Xserves around that could be repurposed. Before we go on looking for hardware there should be some software to run on it. I don't think sudden availability of hardware would speed up the development progress, would it? Rainer From raimue at macports.org Tue Mar 24 20:48:02 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 25 Mar 2009 04:48:02 +0100 Subject: no comments on my port submission yet? In-Reply-To: References: Message-ID: <49C9A972.1060706@macports.org> Allen McBride wrote: > I submitted a port a little over a week ago (http://trac.macports.org/ticket/18870 > ), but no one has committed it or commented on it yet. No big hurry, > but in someone else's earlier ticket (http://trac.macports.org/ticket/18220 > ), Rainer suggested that people nudge this list in such cases, so I > thought I'd write. Sorry for the delay, thanks for the reminder :-) Looking at the Portfile right now, we do not have a top-level category education [1]. What would be the best next match? Maybe we should really have education? Rainer [1] http://trac.macports.org/browser/trunk/dports/ From ryandesign at macports.org Tue Mar 24 21:04:19 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 24 Mar 2009 23:04:19 -0500 Subject: Universal and binary builds In-Reply-To: <49C9A935.7050500@macports.org> References: <31948B81-79C3-4A12-8F64-7755A001CCF5@macports.org> <74c219d30903221725v20f39839m3b66cc42c1624f08@mail.gmail.com> <13B4161E-C8B0-481E-9607-8ACE7D24B54E@macports.org> <08DDCC98-ACBA-488C-913C-19543C7FC24A@macports.org> <2B83DEC4-AA70-4E2C-9249-650851DE0D3A@macports.org> <040BA220-BC73-4D3E-8A4E-28A75673BA4B@macports.org> <49C9A935.7050500@macports.org> Message-ID: On Mar 24, 2009, at 22:47, Rainer M?ller wrote: > Ryan Schmidt wrote: >>> Assuming that you're even going to build PowerPC binaries, it >>> shouldn't be so hard >>> finding cheap used hardware for it. The new machines available only >>> use Intel anyway. >> >> If we want to support universal binaries -- and given the effort >> that's been put in so far on our existing solutions, I'd say there is >> some interest in this -- then I'd say we should build PowerPC >> binaries too. It would surprise me if Apple didn't still have a few >> G5 Xserves around that could be repurposed. > > Before we go on looking for hardware there should be some software to > run on it. I don't think sudden availability of hardware would > speed up > the development progress, would it? I agree. From shreevatsa.public at gmail.com Tue Mar 24 21:05:42 2009 From: shreevatsa.public at gmail.com (Shreevatsa R) Date: Wed, 25 Mar 2009 00:05:42 -0400 Subject: Discouraging variants [was: Re: port install efficiency issue] Message-ID: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> On Mon, Mar 23, 2009 at 3:47 AM, Ryan Schmidt wrote: > Mac OS X is not Debian. The Mac way is to provide not as many options as > possible, but as few options as possible. Meet the needs of most of the > users with the default setup, and provide a few options for everyone else. > > As a consumer, I do not enjoy having to select amongst 37 different types of > toothpaste at the grocery store. More choices is not always better. > > http://www.cafeaulait.org/images/remotes.png These are very good words! I couldn't agree more. This would be a good starting point to mention my pet peeve with MacPorts, which is the excessive use of variants. Ideally, all ports would enable by default all the features that users might want, and only leave as variants those features which are *definitely* undesirable to significantly many people (and definitely desirable for significantly many). Instead, some ports try to make every feature a separate variant. This is entirely unnecessary: disk space is cheap and shouldn't be considered a cost of enabling the feature by default. It is important to remember that with N variants, there are 2^N potential versions to test -- such combinatorial explosion is hard to maintain and introduces many bugs. There will be situations where variants are absolutely necessary, but if there can be consensus against variants, and if the Guide (etc.) could suggest to maintainers that variants should only be used when necessary, I hope it will lead to some improvement. Regards, Shreevatsa From allencmcbride at gmail.com Tue Mar 24 21:13:48 2009 From: allencmcbride at gmail.com (Allen McBride) Date: Wed, 25 Mar 2009 00:13:48 -0400 Subject: no comments on my port submission yet? In-Reply-To: <49C9A972.1060706@macports.org> References: <49C9A972.1060706@macports.org> Message-ID: On Mar 24, 2009, at 11:48 PM, Rainer M?ller wrote: > Looking at the Portfile right now, we do not have a top-level category > education [1]. What would be the best next match? Maybe we should > really > have education? > > Rainer > > [1] http://trac.macports.org/browser/trunk/dports/ I see... I had been looking at the categories at http://www.macports.org/ports.php when I picked "education". I guess "audio" or "games" would be the next best matches, since there's no "music" category either. But "audio" makes me think of programs that would edit or process audio files as their main function, which isn't what solfege is for. And, though ear training can be fun if you're really into it, calling solfege a "game" is also a stretch. Having an "education" or "music" category would make sense to me, but then, you'd know better than I would whether there would be enough other ports to justify either category. Thanks for the response! Let me know if you see any other issues with the portfile. For quick reference, here's a link to the last message in the thread about my trace mode results: http://lists.macosforge.org/pipermail/macports-users/2009-March/014347.html --Allen From ryandesign at macports.org Tue Mar 24 21:51:26 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 24 Mar 2009 23:51:26 -0500 Subject: Discouraging variants [was: Re: port install efficiency issue] In-Reply-To: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> References: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> Message-ID: On Mar 24, 2009, at 23:05, Shreevatsa R wrote: > This would be a good starting point to mention my pet peeve with > MacPorts, which is the excessive use of variants. > > Ideally, all ports would enable by default all the features that users > might want, and only leave as variants those features which are > *definitely* undesirable to significantly many people (and definitely > desirable for significantly many). Instead, some ports try to make > every feature a separate variant. This is entirely unnecessary: disk > space is cheap and shouldn't be considered a cost of enabling the > feature by default. > > It is important to remember that with N variants, there are 2^N > potential versions to test -- such combinatorial explosion is hard to > maintain and introduces many bugs. There will be situations where > variants are absolutely necessary, but if there can be consensus > against variants, and if the Guide (etc.) could suggest to maintainers > that variants should only be used when necessary, I hope it will lead > to some improvement. I am constantly telling people on the mailing list to use variant sparingly, only when absolutely necessary. Variants frequently don't get tested when ports are updated, so things break without the maintainer realizing it. Are there any specific ports you can point out that have more variants than you think they need? From florian.ebeling at gmail.com Wed Mar 25 01:42:17 2009 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Wed, 25 Mar 2009 09:42:17 +0100 Subject: Discouraging variants [was: Re: port install efficiency issue] In-Reply-To: References: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> Message-ID: <5cbbe4ae0903250142g34cebfedxb716e0890f618567@mail.gmail.com> On Wed, Mar 25, 2009 at 5:51 AM, Ryan Schmidt wrote: > > On Mar 24, 2009, at 23:05, Shreevatsa R wrote: > >> This would be a good starting point to mention my pet peeve with >> MacPorts, which is the excessive use of variants. >> >> Ideally, all ports would enable by default all the features that users >> might want, and only leave as variants those features which are >> *definitely* undesirable to significantly many people (and definitely >> desirable for significantly many). Instead, some ports try to make >> every feature a separate variant. This is entirely unnecessary: disk >> space is cheap and shouldn't be considered a cost of enabling the >> feature by default. >> >> It is important to remember that with N variants, there are 2^N >> potential versions to test -- such combinatorial explosion is hard to >> maintain and introduces many bugs. There will be situations where >> variants are absolutely necessary, but if there can be consensus >> against variants, and if the Guide (etc.) could suggest to maintainers >> that variants should only be used when necessary, I hope it will lead >> to some improvement. > > I am constantly telling people on the mailing list to use variant sparingly, > only when absolutely necessary. > > Variants frequently don't get tested when ports are updated, so things break > without the maintainer realizing it. > > Are there any specific ports you can point out that have more variants than > you think they need? Maybe a guidelining positive list would be helpful, with reasons that usually warrant a variant. And if your reason is not on the list either collapse the variant into the main port or seperate it out into a port altogether. One problem with variants is that in the beginning it makes you feel like your a good citizen when you provide many. Misunderstood 'Mimize Coupling' thinking probably. Are there maybe better alternatives for any case where variants are used today? Florian -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From ryandesign at macports.org Wed Mar 25 05:01:09 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 25 Mar 2009 07:01:09 -0500 Subject: [48565] trunk/dports/science/gwyddion In-Reply-To: <20090325072858.9E0F312DFC24@beta.macosforge.org> References: <20090325072858.9E0F312DFC24@beta.macosforge.org> Message-ID: <896ADB98-5822-4DA1-B2FC-41057937932C@macports.org> On Mar 25, 2009, at 02:28, rowue at macports.org wrote: > Added: trunk/dports/science/gwyddion/files/gwyddion > =================================================================== > --- trunk/dports/science/gwyddion/files/ > gwyddion (rev 0) > +++ trunk/dports/science/gwyddion/files/gwyddion 2009-03-25 > 07:28:56 UTC (rev 48565) > @@ -0,0 +1,6 @@ > +#!/bin/bash > +if [ -x @APPDIR@/X11.app/Contents/MacOS/X11 ]; then > + open -a @APPDIR@/X11.app/Contents/MacOS/X11 /opt/local/bin/gwyddion > +else > + open -a /Applications/Utilities/X11.app/Contents/MacOS/X11 /opt/ > local/bin/gwyddion > +fi /opt/local shouldn't be hardcoded here. :) From ryandesign at macports.org Wed Mar 25 05:14:39 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 25 Mar 2009 07:14:39 -0500 Subject: Discouraging variants [was: Re: port install efficiency issue] In-Reply-To: <5cbbe4ae0903250142g34cebfedxb716e0890f618567@mail.gmail.com> References: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> <5cbbe4ae0903250142g34cebfedxb716e0890f618567@mail.gmail.com> Message-ID: <93D15EFA-D253-4F74-8D98-CCDCB4471A6F@macports.org> On Mar 25, 2009, at 03:42, C. Florian Ebeling wrote: > Maybe a guidelining positive list would be helpful, with > reasons that usually warrant a variant. And if your > reason is not on the list either collapse the variant > into the main port or seperate it out into a port altogether. > > One problem with variants is that in the beginning it makes > you feel like your a good citizen when you provide many. > Misunderstood 'Mimize Coupling' thinking probably. > > Are there maybe better alternatives for any case > where variants are used today? Some examples from my ports: Variant: +doc / +docs. Usually bad. Example: freetype +doc. Instead, always install the documentation. (This specific issue was fixed in r42509.) Corollary: If the documentation files must be built using a heavy dependency such as doxygen, and users are unlikely to need the documentation, leaving it in a variant is better. Example: libexif +doc. Variant: +server. Usually bad. Example: mysql5 +server. Instead, create a separate mysql5-server port. (There is a ticket open for this specific issue.) Example of something that has to be a variant: mysql5-devel +innodb_plugin. Here you are choosing between the built-in InnoDB functions that have been around forever vs. the new InnoDB functions available in the InnoDB plugin. The plugin is not dynamically loaded; rather, it's built into MySQL at compile time. You have to delete part of the MySQL source and replace it with the source of the InnoDB plugin. From ryandesign at macports.org Wed Mar 25 05:27:33 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 25 Mar 2009 07:27:33 -0500 Subject: [48526] trunk/dports/math/pspp/Portfile In-Reply-To: <20090324140155.0C25E12D6F73@beta.macosforge.org> References: <20090324140155.0C25E12D6F73@beta.macosforge.org> Message-ID: <98420EA5-F39B-4B2C-853C-23B2860A9731@macports.org> On Mar 24, 2009, at 09:01, snc at macports.org wrote: > Revision: 48526 > http://trac.macports.org/changeset/48526 > Author: snc at macports.org > Date: 2009-03-24 07:01:54 -0700 (Tue, 24 Mar 2009) > Log Message: > ----------- > added Finder-launchable application > > Modified Paths: > -------------- > trunk/dports/math/pspp/Portfile > > Modified: trunk/dports/math/pspp/Portfile > =================================================================== > --- trunk/dports/math/pspp/Portfile 2009-03-24 13:53:03 UTC (rev > 48525) > +++ trunk/dports/math/pspp/Portfile 2009-03-24 14:01:54 UTC (rev > 48526) > @@ -97,10 +97,19 @@ > ln -s ${prefix}/lib/pspp/libpsppwidgets.dylib \ > ${destroot}${prefix}/lib/pspp/libpsppwidgets.so > > - move ${destroot}${prefix}/bin/psppire ${destroot}${prefix}/ > libexec/${name}/psppire > + move ${destroot}${prefix}/bin/psppire \ > + ${destroot}${prefix}/libexec/${name}/psppire > > xinstall -m 755 ${filespath}/psppire.in ${destroot}$ > {prefix}/bin/psppire > reinplace s|@PREFIX@|${prefix}|g ${destroot}${prefix}/bin/ > psppire > reinplace s|@NAME@|${name}|g ${destroot}${prefix}/bin/psppire > } > + > + xinstall -d ${destroot}${applications_dir}/PSPP.app/Contents/MacOS > + xinstall -m 644 ${filespath}/PSPP.app/Contents/Info.plist \ > + ${destroot}${applications_dir}/PSPP.app/Contents > + copy ${destroot}${prefix}/bin/psppire \ > + ${destroot}${applications_dir}/PSPP.app/Contents/MacOS > + reinplace "s|psppire|psppire \\&|g" \ > + ${destroot}${applications_dir}/PSPP.app/Contents/MacOS/psppire > } You have to increase the port's revision so everyone gets these new files. From ryandesign at macports.org Wed Mar 25 05:29:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 25 Mar 2009 07:29:35 -0500 Subject: [48534] trunk/dports/editors In-Reply-To: <20090324174621.D5DD612D8710@beta.macosforge.org> References: <20090324174621.D5DD612D8710@beta.macosforge.org> Message-ID: <99059097-55D7-4A80-BCFE-C252D65296F2@macports.org> On Mar 24, 2009, at 12:46, jmr at macports.org wrote: > +extract.suffix .tar.gz?format=raw This is not a good trick because it causes the file to have that odd extension on the user's disk and on the distfiles mirrors: http://distfiles.macports.org/yaml-mode.el/ See gtkimageview for the way to handle this that does not have that problem. From florian.ebeling at gmail.com Wed Mar 25 05:44:16 2009 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Wed, 25 Mar 2009 13:44:16 +0100 Subject: Discouraging variants [was: Re: port install efficiency issue] In-Reply-To: <93D15EFA-D253-4F74-8D98-CCDCB4471A6F@macports.org> References: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> <5cbbe4ae0903250142g34cebfedxb716e0890f618567@mail.gmail.com> <93D15EFA-D253-4F74-8D98-CCDCB4471A6F@macports.org> Message-ID: <5cbbe4ae0903250544s6f0cf446j8e2ed064279284cd@mail.gmail.com> >> Are there maybe better alternatives for any case >> where variants are used today? > > Some examples from my ports: > > Variant: +doc / +docs. Usually bad. Example: freetype +doc. Instead, always > install the documentation. (This specific issue was fixed in r42509.) > Corollary: If the documentation files must be built using a heavy dependency > such as doxygen, and users are unlikely to need the documentation, leaving > it in a variant is better. Example: libexif +doc. Yes, doxygen dependency made me put ruby19 C API docs into a variant as well. Maybe such cases can with some justification be made separate doc ports? I find that quite acceptable. > Variant: +server. Usually bad. Example: mysql5 +server. Instead, create a > separate mysql5-server port. (There is a ticket open for this specific > issue.) I agree on this as well. > Example of something that has to be a variant: mysql5-devel +innodb_plugin. > Here you are choosing between the built-in InnoDB functions that have been > around forever vs. the new InnoDB functions available in the InnoDB plugin. > The plugin is not dynamically loaded; rather, it's built into MySQL at > compile time. You have to delete part of the MySQL source and replace it > with the source of the InnoDB plugin. Wouldn't it make sense to provide a separate and conflicting whole port maybe for this hten? I now that seems a bit farfetched, but I'm trying to understand the implications of an hypothentical removal of the variant concept altogether, which I would find quite a clean scenario. I don't see a real blocker for such a move yet. -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From jmr at macports.org Wed Mar 25 08:36:53 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 26 Mar 2009 02:36:53 +1100 Subject: [48534] trunk/dports/editors In-Reply-To: <99059097-55D7-4A80-BCFE-C252D65296F2@macports.org> References: <20090324174621.D5DD612D8710@beta.macosforge.org> <99059097-55D7-4A80-BCFE-C252D65296F2@macports.org> Message-ID: <49CA4F95.9060701@macports.org> Ryan Schmidt wrote: > > On Mar 24, 2009, at 12:46, jmr at macports.org wrote: > >> +extract.suffix .tar.gz?format=raw > > This is not a good trick because it causes the file to have that odd > extension on the user's disk and on the distfiles mirrors: > > http://distfiles.macports.org/yaml-mode.el/ > > See gtkimageview for the way to handle this that does not have that > problem. The homepage is down, and that is how the distfile is named on the FreeBSD mirrors. - Josh From blb at macports.org Wed Mar 25 13:07:18 2009 From: blb at macports.org (Bryan Blackburn) Date: Wed, 25 Mar 2009 14:07:18 -0600 Subject: [48582] trunk/dports/lang In-Reply-To: <20090325193804.9367312EF478@beta.macosforge.org> References: <20090325193804.9367312EF478@beta.macosforge.org> Message-ID: <20090325200718.GC824@ninagal.withay.com> On Wed, Mar 25, 2009 at 12:38:04PM -0700, jann at macports.org said: > Revision: 48582 > http://trac.macports.org/changeset/48582 > Author: jann at macports.org > Date: 2009-03-25 12:38:03 -0700 (Wed, 25 Mar 2009) > Log Message: > ----------- > Use instead of overriding , fixes #18973 I'm guessing your shell did a replacement of variable names here? Bryan [...] From perry at macports.org Wed Mar 25 13:29:04 2009 From: perry at macports.org (Perry Lee) Date: Wed, 25 Mar 2009 13:29:04 -0700 Subject: Discouraging variants [was: Re: port install efficiency issue] In-Reply-To: <5cbbe4ae0903250544s6f0cf446j8e2ed064279284cd@mail.gmail.com> References: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> <5cbbe4ae0903250142g34cebfedxb716e0890f618567@mail.gmail.com> <93D15EFA-D253-4F74-8D98-CCDCB4471A6F@macports.org> <5cbbe4ae0903250544s6f0cf446j8e2ed064279284cd@mail.gmail.com> Message-ID: <84DA4F1B-C391-4D9A-96C0-78C922BF88AF@macports.org> On Mar 25, 2009, at 5:44 AM, C. Florian Ebeling wrote: >>> Wouldn't it make sense to provide a separate and conflicting whole > port maybe for this hten? I now that seems a bit farfetched, but > I'm trying to understand the implications of an hypothentical > removal of the variant concept altogether, which I would find > quite a clean scenario. I don't see a real blocker for such a move > yet. For the previously listed variants (+doc, +server), these can be made into separate ports; however, what do you do in cases such as the curl port? For example, the curl port has the variants openldap and sftp_scp. I don't imagine many users would need these features, but there are users that use them. Enabling these features by default is not reasonable because their dependencies are heavy (specifically openldap), but making these two variants a separate port also doesn't make sense. The variants openldap and sftp_scp are not mutually exclusive; I may want to enable both. Without variants, I don't see how we could handle these types of situations. From jeremy at lavergne.gotdns.org Wed Mar 25 13:55:18 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 25 Mar 2009 16:55:18 -0400 Subject: Discouraging variants [was: Re: port install efficiency issue] In-Reply-To: <84DA4F1B-C391-4D9A-96C0-78C922BF88AF@macports.org> References: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> <5cbbe4ae0903250142g34cebfedxb716e0890f618567@mail.gmail.com> <93D15EFA-D253-4F74-8D98-CCDCB4471A6F@macports.org> <5cbbe4ae0903250544s6f0cf446j8e2ed064279284cd@mail.gmail.com> <84DA4F1B-C391-4D9A-96C0-78C922BF88AF@macports.org> Message-ID: <6663B591-B973-4670-A0C3-975D5F6CA218@lavergne.gotdns.org> >>>> Wouldn't it make sense to provide a separate and conflicting whole >> port maybe for this hten? I now that seems a bit farfetched, but >> I'm trying to understand the implications of an hypothentical >> removal of the variant concept altogether, which I would find >> quite a clean scenario. I don't see a real blocker for such a move >> yet. > > For the previously listed variants (+doc, +server), these can be > made into separate ports; however, what do you do in cases such as > the curl port? For example, the curl port has the variants openldap > and sftp_scp. I don't imagine many users would need these features, > but there are users that use them. Enabling these features by > default is not reasonable because their dependencies are heavy > (specifically openldap), but making these two variants a separate > port also doesn't make sense. The variants openldap and sftp_scp are > not mutually exclusive; I may want to enable both. Without variants, > I don't see how we could handle these types of situations. I always thought default variants took care of making things simple for the novice yet allowed you to override what variants were used if you were advanced. Granted, that's just the facade of easiness, when it does supply you more choices. I guess what I'm saying is we can have the average user depend on the defaults to be the "easy" route and the advanced user can care about the variants. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From raimue at macports.org Wed Mar 25 14:09:16 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 25 Mar 2009 22:09:16 +0100 Subject: no comments on my port submission yet? In-Reply-To: References: <49C9A972.1060706@macports.org> Message-ID: <49CA9D7C.3080300@macports.org> Allen McBride wrote: > On Mar 24, 2009, at 11:48 PM, Rainer M?ller wrote: > >> Looking at the Portfile right now, we do not have a top-level category >> education [1]. What would be the best next match? Maybe we should >> really >> have education? >> >> Rainer >> >> [1] http://trac.macports.org/browser/trunk/dports/ > > > I see... I had been looking at the categories at http://www.macports.org/ports.php > when I picked "education". There is a difference between top-level categories and other categories. The top-level category is the first on the list and is the same as the port's parent directory. There can be other categories listed after the first one which do not exist as top-level category, thus there is education in that list linked above. Rainer From raimue at macports.org Wed Mar 25 15:29:18 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 25 Mar 2009 23:29:18 +0100 Subject: Discouraging variants [was: Re: port install efficiency issue] In-Reply-To: <5cbbe4ae0903250544s6f0cf446j8e2ed064279284cd@mail.gmail.com> References: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> <5cbbe4ae0903250142g34cebfedxb716e0890f618567@mail.gmail.com> <93D15EFA-D253-4F74-8D98-CCDCB4471A6F@macports.org> <5cbbe4ae0903250544s6f0cf446j8e2ed064279284cd@mail.gmail.com> Message-ID: <49CAB03E.9040708@macports.org> C. Florian Ebeling wrote: > Wouldn't it make sense to provide a separate and conflicting whole > port maybe for this hten? I now that seems a bit farfetched, but > I'm trying to understand the implications of an hypothentical > removal of the variant concept altogether, which I would find > quite a clean scenario. I don't see a real blocker for such a move > yet. Variants would be a really useful feature in MacPorts if only we could use them as intended. Which means, using default_variants and storing negative variant selections. So I could enable and disable variants as I like in my variants.conf to avoid certain dependencies or get additional features. I don't like rigid packagement systems which provide one package only without any chance to influence dependencies or features. If the provided features do not match what I need I have to make my own package or compile on my own. Variants perfectly fit here. Rainer From shreevatsa.public at gmail.com Wed Mar 25 19:39:08 2009 From: shreevatsa.public at gmail.com (Shreevatsa R) Date: Wed, 25 Mar 2009 22:39:08 -0400 Subject: Discouraging variants [was: Re: port install efficiency issue] In-Reply-To: References: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> Message-ID: <7675454e0903251939i5296e786tafcda0d7e6683b5f@mail.gmail.com> On Wed, Mar 25, 2009 at 12:51 AM, Ryan Schmidt wrote: > > On Mar 24, 2009, at 23:05, Shreevatsa R wrote: > >> This would be a good starting point to mention my pet peeve with >> MacPorts, which is the excessive use of variants. >> >> Ideally, all ports would enable by default all the features that users >> might want, and only leave as variants those features which are >> *definitely* undesirable to significantly many people (and definitely >> desirable for significantly many). Instead, some ports try to make >> every feature a separate variant. This is entirely unnecessary: disk >> space is cheap and shouldn't be considered a cost of enabling the >> feature by default. >> >> It is important to remember that with N variants, there are 2^N >> potential versions to test -- such combinatorial explosion is hard to >> maintain and introduces many bugs. There will be situations where >> variants are absolutely necessary, but if there can be consensus >> against variants, and if the Guide (etc.) could suggest to maintainers >> that variants should only be used when necessary, I hope it will lead >> to some improvement. > > I am constantly telling people on the mailing list to use variant sparingly, > only when absolutely necessary. > > Variants frequently don't get tested when ports are updated, so things break > without the maintainer realizing it. Exactly! I am glad there is some consensus on this point, although some people still disagree. > Are there any specific ports you can point out that have more variants than > you think they need? Well my hope was to influence policy, and didn't particularly want to point fingers -- after all, maintainers providing variants do so in the belief that they are helping the users by "giving them more options". :-) Still, just as an indication of the current state of variants, I compiled a list: after ignoring platform variants and "universal", there are 130 ports with at least 4 variants: that's already 16 configurations (ignoring conflicts etc.), which is more than most maintainers have time to test. See http://web.mit.edu/vatsa/Public/macports-var/variants-04.txt (or see http://web.mit.edu/vatsa/Public/macports-var/ for the ~400 ports with at least two variants, etc. There are a dozen ports with *16* or more variants. In some cases all of them can be justified, but in many others it is hard to imagine someone who would want one subset of the features and be actively harmed by the rest.) The broader point is here that a package maintainer is *not* doing the user a service by providing a lot of options. It is very frustrating to install something, find out later that there's some feature missing, and have to install again with a different variant. It is also frustrating to have to always check variants first before installing (not only of what one is installing, but also of its dependencies), or maintain one's own "variants.conf" (or "USE flags" or whatever arbitrary configuration mechanism). More generally, it is the packager's *job* to make choices for the user[1]; not doing so is just evading responsibility. Simply throwing every possible option as a variant, just because one couldn't decide if someone would *not* want it or not, simply increases the chances of failure[2], and is not pleasant to anyone, especially Mac users accustomed to encountering decisions Done Right. Having to pick from so many choices feels awful[3,4]. Just design for yourself[5], and if there are disgruntled users they'll let you know. There, I'm off my soapbox. Really, just please read [1]. Back to MacPorts specifically, a few humble suggestions: always install docs unless there is a big dependency like Doxygen (also worth considering: is doxygen *really* a very big dependency? :)), in which case make it a separate port. There shouldn't be "no_docs" variants: no one really *needs* not to install docs. More generally, install all features wherever possible (e.g. why is mp_completion a variant for zsh instead of being installed by default? Just a random example from the bottom of the list, not complaining about that port specifically) and where there are cases where this is really "too" huge (say, wrt build time, not disk space), have just one variant, between a sensible "light" version and the "heavy" version. Bug #126 still needs to be fixed, but maybe it can be made less important. ;-) Regards, Shreevatsa [1]: http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html [2]: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html [3]: http://www.columbia.edu/~ss957/articles/Choice_is_Demotivating.pdf [4]: http://www.amazon.com/dp/0060005688 [5]: http://www.37signals.com/svn/posts/904-why-we-disagree-with-don-norman From milosh at macports.org Thu Mar 26 01:46:27 2009 From: milosh at macports.org (Emmanuel Hainry) Date: Thu, 26 Mar 2009 09:46:27 +0100 Subject: Discouraging variants [was: Re: port install efficiency issue] In-Reply-To: <7675454e0903251939i5296e786tafcda0d7e6683b5f@mail.gmail.com> References: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> <7675454e0903251939i5296e786tafcda0d7e6683b5f@mail.gmail.com> Message-ID: <20090326084627.GA15918@velsheda.lateralis.org> Citando Shreevatsa R : > > On Wed, Mar 25, 2009 at 12:51 AM, Ryan Schmidt wrote: > > > > Variants frequently don't get tested when ports are updated, so things break > > without the maintainer realizing it. > > Exactly! I am glad there is some consensus on this point, although > some people still disagree. > > > Are there any specific ports you can point out that have more variants than > > you think they need? > > Well my hope was to influence policy, and didn't particularly want to > point fingers -- after all, maintainers providing variants do so in > the belief that they are helping the users by "giving them more > options". :-) Still, just as an indication of the current state of > variants, I compiled a list: after ignoring platform variants and > "universal", there are 130 ports with at least 4 variants: that's > already 16 configurations (ignoring conflicts etc.), which is more > than most maintainers have time to test. More often than not, if the port compiles with all the variants turned on, then everything will be OK. I happen to have tested most combinations of variants for mpd (before I had a comaintainer who added even more variants) and testing a few combinations enabling or disabling some variants is far more easy than testing that it compiles on all architectures and all systems "supported" by macports. As I now don't have a macosx computer, some ports simply don't compile as they are mac centric. If a dependency is not absolutely necessary, I am happy to be able to disable it (for example making moreutils compile with docs was a real pain when I first made the port, simply does not work now that I don't have one). > The broader point is here that a package maintainer is *not* doing the > user a service by providing a lot of options. It is very frustrating > to install something, find out later that there's some feature > missing, and have to install again with a different variant. Yes, that is what default_variants and negative variants are for. I know that the use of default_variants is discouraged, but they are a really fine feature of macports. Variants are a great aspect of macports, sure there are some bugs with them (126, default_variants not preserved by upgrade), sure there are cases of abuse of variants (e.g. mpd, but I am proud of it), but don't throw them away or try to reduce their use to some really rare use cases unless you want to have 16 ports where you had 1 port with 4 variants... > > Back to MacPorts specifically, a few humble suggestions: always > install docs unless there is a big dependency like Doxygen (also worth > considering: is doxygen *really* a very big dependency? :)), in which > case make it a separate port. There shouldn't be "no_docs" variants: > no one really *needs* not to install docs. No one really *needs* not to install docs, but some users (1) really cannot install docs when they depend on docbook2X and a strange version of docbook-xml-4.5.beta17, when they depend on doxygen. That being said, I consider not installing docs a bug in a port. Best, milosh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From raimue at macports.org Thu Mar 26 03:05:06 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 26 Mar 2009 11:05:06 +0100 Subject: Discouraging variants [was: Re: port install efficiency issue] In-Reply-To: <7675454e0903251939i5296e786tafcda0d7e6683b5f@mail.gmail.com> References: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> <7675454e0903251939i5296e786tafcda0d7e6683b5f@mail.gmail.com> Message-ID: <49CB5352.9010407@macports.org> Shreevatsa R wrote: >> Variants frequently don't get tested when ports are updated, so things break >> without the maintainer realizing it. > > Exactly! I am glad there is some consensus on this point, although > some people still disagree. Breaking ports can always happen. Why would this be different when there are less or no variants? >> Are there any specific ports you can point out that have more variants than >> you think they need? > > Well my hope was to influence policy, and didn't particularly want to > point fingers -- after all, maintainers providing variants do so in > the belief that they are helping the users by "giving them more > options". :-) Still, just as an indication of the current state of > variants, I compiled a list: after ignoring platform variants and > "universal", there are 130 ports with at least 4 variants: that's > already 16 configurations (ignoring conflicts etc.), which is more > than most maintainers have time to test. You don't need to test each and every variant combination. In most cases it is safe to assume that if +foo +bar works, also +foo and +bar as single selected variants work. > The broader point is here that a package maintainer is *not* doing the > user a service by providing a lot of options. It is very frustrating > to install something, find out later that there's some feature > missing, and have to install again with a different variant. It is > also frustrating to have to always check variants first before > installing (not only of what one is installing, but also of its > dependencies), or maintain one's own "variants.conf" (or "USE flags" > or whatever arbitrary configuration mechanism). More generally, it is > the packager's *job* to make choices for the user[1]; not doing so is > just evading responsibility. Simply throwing every possible option as > a variant, just because one couldn't decide if someone would *not* > want it or not, simply increases the chances of failure[2], [...] It is the responsibility of the maintainer to select what is included by default without variants, in default_variants or additionally available as variant. > and is not > pleasant to anyone, especially Mac users accustomed to encountering > decisions Done Right. Having to pick from so many choices feels > awful[3,4]. Just design for yourself[5], and if there are disgruntled > users they'll let you know. > There, I'm off my soapbox. Really, just please read [1]. What I learnt mostly is that Mac users are ignorant people who like to complain and rant if software does not work. But the number of people actually filing tickets and providing patches is small. > Back to MacPorts specifically, a few humble suggestions: always > install docs unless there is a big dependency like Doxygen (also worth > considering: is doxygen *really* a very big dependency? :)), Think of ports requiring a TeX distribution to build their docs. > in which > case make it a separate port. So you say maintaining multiple ports is easier than maintaining variants? Keep in mind that for updates you would have to update the version and checksums in two ports. Also take care that they are using the same dist_subdir, as the docs are usually distributed in the same tarball and you don't want to download it twice. Which most probably makes the port for docs a clone of the original port - except build.target and destroot.target. > There shouldn't be "no_docs" variants: > no one really *needs* not to install docs. Why should I install docs for a library if I am not going to develop for it? In an ideal world, there wouldn't be any +no_* variants. That's just a lame workaround for broken default_variants and negative variant selections. > More generally, install all > features wherever possible (e.g. why is mp_completion a variant for > zsh instead of being installed by default? Just a random example from > the bottom of the list, not complaining about that port specifically) > and where there are cases where this is really "too" huge (say, wrt > build time, not disk space), have just one variant, between a sensible > "light" version and the "heavy" version. And then I have to select the heavy version requiring >16 other libraries just because I need support for one of them? Doesn't sound any better. Rainer From afb at macports.org Thu Mar 26 03:32:54 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 26 Mar 2009 11:32:54 +0100 Subject: Discouraging variants [was: Re: port install efficiency issue] In-Reply-To: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> References: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> Message-ID: <4B8AB84D-CF0F-400C-8BA8-42590F24A42A@macports.org> Shreevatsa R wrote: > On Mon, Mar 23, 2009 at 3:47 AM, Ryan Schmidt > wrote: >> Mac OS X is not Debian. The Mac way is to provide not as many >> options as >> possible, but as few options as possible. Meet the needs of most >> of the >> users with the default setup, and provide a few options for >> everyone else. >> >> As a consumer, I do not enjoy having to select amongst 37 >> different types of >> toothpaste at the grocery store. More choices is not always better. >> >> http://www.cafeaulait.org/images/remotes.png > > These are very good words! I couldn't agree more. > This would be a good starting point to mention my pet peeve with > MacPorts, which is the excessive use of variants. > > Ideally, all ports would enable by default all the features that users > might want, and only leave as variants those features which are > *definitely* undesirable to significantly many people (and definitely > desirable for significantly many). Instead, some ports try to make > every feature a separate variant. This is entirely unnecessary: disk > space is cheap and shouldn't be considered a cost of enabling the > feature by default. I thought the whole point of doing Ports for Mac was to provide choice... Why else would it require you to install Developer Tools and go mucking about in the Terminal, if it wasn't that you *wanted* to choose things ? Wouldn't you rather install the provided binary in the graphic interface, and be happy with the choices that the vendor has already made for you ? Blaming current bugs and shortcomings with variants on choice seems unfair. --anders From jeremy at lavergne.gotdns.org Thu Mar 26 06:37:27 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 26 Mar 2009 09:37:27 -0400 Subject: Assistance Python Ticket #12447 Message-ID: Can I get assistance in aisle Python? :-) The ticket, without the portgroup, looks to violate the tree and go straight for /Library without the prefix for destroot. To fix this, I tried adding the python25 portgroup to it, but had to override the build.cmd and destroot.cmd since it seems the only argument that its setup.py can handle is --prefix. When I reduced it to just prefix, I got an error from python. Would someone who's more knowledgeable of python take a moment and try to figure this one out? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Thu Mar 26 13:01:14 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 26 Mar 2009 16:01:14 -0400 Subject: [48644] trunk/dports/python/py25-pydb/ In-Reply-To: <20090326195536.0755812FB64D@beta.macosforge.org> References: <20090326195536.0755812FB64D@beta.macosforge.org> Message-ID: <0D75882E-F4F0-4833-9FF0-407588520549@lavergne.gotdns.org> Watch out guys, you two are doing opposites of each other. We need to decide if we're doing py25-db or py25-pydb. On Mar 26, 2009, at 3:55 PM, mcalhoun at macports.org wrote: > Revision48644Authormcalhoun at macports.orgDate2009-03-26 12:55:35 > -0700 (Thu, 26 Mar 2009)Log Message > This port is a duplicate of py25-db. > Removed Paths > ? trunk/dports/python/py25-pydb/ > Diff > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From mcalhoun at macports.org Thu Mar 26 13:12:26 2009 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Thu, 26 Mar 2009 20:12:26 +0000 (UTC) Subject: [48644] trunk/dports/python/py25-pydb/ References: <20090326195536.0755812FB64D@beta.macosforge.org> <0D75882E-F4F0-4833-9FF0-407588520549@lavergne.gotdns.org> Message-ID: Jeremy Lavergne writes: > > Watch out guys, you two are doing opposites of each other. > > We need to decide if we're doing py25-db or py25-pydb. > > On Mar 26, 2009, at 3:55 PM, mcalhoun at ... wrote: > > > Revision48644Authormcalhoun at ... > 12:55:35 > > -0700 (Thu, 26 Mar 2009)Log Message > > This port is a duplicate of py25-db. > > Removed Paths > > ? trunk/dports/python/py25-pydb/ > > Diff The situation should be resolved. The relevant tickets are #12447 and #17071. Reading through the the tickets, py25-pydb seemed to have more support as a name, but py25-db had a slightly improved Portfile. So py25-pydb was deleted, and py-db was renamed to py25-pydb. -Marcus From raimue at macports.org Thu Mar 26 17:35:43 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Fri, 27 Mar 2009 01:35:43 +0100 Subject: [48664] trunk/dports/_resources/port1.0/group/cmake-1.0.tcl In-Reply-To: <20090326231033.CA7C912FE377@beta.macosforge.org> References: <20090326231033.CA7C912FE377@beta.macosforge.org> Message-ID: <49CC1F5F.7090804@macports.org> illogic-al at macports.org wrote: > --- trunk/dports/_resources/port1.0/group/cmake-1.0.tcl 2009-03-26 22:55:37 UTC (rev 48663) > +++ trunk/dports/_resources/port1.0/group/cmake-1.0.tcl 2009-03-26 23:10:33 UTC (rev 48664) > @@ -44,7 +44,7 @@ > -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON \ > -DCMAKE_OSX_SYSROOT=${universal_sysroot} \ > -DCMAKE_SYSTEM_PREFIX_PATH=\"${prefix}\;/usr\" \ > - -DQT_QMAKE_EXECUTABLE=${prefix}/libexec/qt4-mac/bin/qmake \ > + -DQT_QMAKE_EXECUTABLE=${prefix}/libexec/qt4-kde/bin/qmake \ > -Wno-dev > > variant universal { Not all software using cmake is automatically KDE related. Why did you change it to qt4-kde by default? I would like to avoid having to install multiple versions of qt4-*. Also, all ports using this port group would need a revision bump for such a change by our conventions. Rainer From raimue at macports.org Thu Mar 26 19:09:37 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 27 Mar 2009 03:09:37 +0100 Subject: [48664] trunk/dports/_resources/port1.0/group/cmake-1.0.tcl In-Reply-To: References: <20090326231033.CA7C912FE377@beta.macosforge.org> <49CC1F5F.7090804@macports.org> Message-ID: <49CC3561.3090208@macports.org> Orville Bennett wrote: > On Mar 26, 2009, at 8:35 PM, Rainer M?ller wrote: >> Not all software using cmake is automatically KDE related. Why did you >> change it to qt4-kde by default? I would like to avoid having to >> install >> multiple versions of qt4-*. > I assumed nothing else was using the cmake portgroup besides the kde > stuff. > I didn't even think of the issue until after commiting this. > I've reverted this change, thanks for bringing it to my attention. I > totally forgot about it after I realized this goof (ah, the internet. > From trac ticket to twitter. Such a slippery slope.) Thanks for the fix. For example I am using doxygen +wizard which depends on qt4-mac. >> Also, all ports using this port group would need a revision bump for >> such a change by our conventions. > Can portgroups themselves get revisions? No, port groups are just treaten as includes. Which means the code in the port group is put at the place you use PortGroup. So we need to find all ports using this port group. Not really fast, but works better than plain recursive grep: find trunk/dports/ -type f -name Portfile -print0 | \ xargs -0 grep 'PortGroup[ \t]*kde4' For convenience, here is a list of all ports using PortGroup kde4: (based on r48670) audio/phonon audio/taglib-devel devel/akonadi devel/soprano graphics/qimageblitz kde/amarok kde/amarok-devel kde/choqok kde/kdebase4 kde/kdebase4-runtime kde/kdeedu4 kde/kdegames4 kde/kdegraphics4 kde/kdelibs4 kde/kdemultimedia4 kde/kdenetwork4 kde/kdepim4 kde/kdepimlibs4 kde/kdesdk4 kde/kdetoys4 kde/kdeutils4 kde/koffice2-devel kde/ktorrent Rainer From shreevatsa.public at gmail.com Thu Mar 26 22:07:46 2009 From: shreevatsa.public at gmail.com (Shreevatsa R) Date: Fri, 27 Mar 2009 01:07:46 -0400 Subject: Discouraging variants [was: Re: port install efficiency issue] In-Reply-To: <4B8AB84D-CF0F-400C-8BA8-42590F24A42A@macports.org> <49CB5352.9010407@macports.org> <20090326084627.GA15918@velsheda.lateralis.org> References: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> <4B8AB84D-CF0F-400C-8BA8-42590F24A42A@macports.org> <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> <7675454e0903251939i5296e786tafcda0d7e6683b5f@mail.gmail.com> <49CB5352.9010407@macports.org> <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> <7675454e0903251939i5296e786tafcda0d7e6683b5f@mail.gmail.com> <20090326084627.GA15918@velsheda.lateralis.org> Message-ID: <49cc5f26.85c2f10a.6a85.3064@mx.google.com> Hello, Firstly, I should clarify that I have/had no intention of starting an argument; I'm only speaking from a genuine desire to make MacPorts better. To reply... On Thu, Mar 26, 2009 at 09:46:27AM +0100, Emmanuel Hainry wrote: > Yes, that is what default_variants and negative variants are for. I know > that the use of default_variants is discouraged, but they are a really > fine feature of macports. Variants are a great aspect of macports, sure > there are some bugs with them (126, default_variants not preserved by > upgrade), sure there are cases of abuse of variants (e.g. mpd, but I am > proud of it), but don't throw them away or try to reduce their use to > some really rare use cases unless you want to have 16 ports where you > had 1 port with 4 variants... Completely agree that 16 ports is much worse than 1 port with 4 variants. What is even better is one port with no variants (if possible). > No one really *needs* not to install docs, but some users (1) really > cannot install docs when they depend on docbook2X and a strange version > of docbook-xml-4.5.beta17, when they depend on doxygen. That being said, > I consider not installing docs a bug in a port. Great, we agree. :-) I too agree that ports should install docs by default, and I too agree that when docbook is a dependency, a variant is justified (under the present conditions, where docbook takes a long time to install etc.) On Thu, Mar 26, 2009 at 11:05:06AM +0100, Rainer Muller wrote: > > Shreevatsa R wrote: > >> Variants frequently don't get tested when ports are updated, so things break > >> without the maintainer realizing it. > > > > Exactly! I am glad there is some consensus on this point, although > > some people still disagree. > > Breaking ports can always happen. Why would this be different when there > are less or no variants? When there are more variants, there are more things that can break. More importantly, things can break *without the maintainer realizing it* -- a user might install some subset different from what the maintainer has tested. > You don't need to test each and every variant combination. In most cases > it is safe to assume that if +foo +bar works, also +foo and +bar as > single selected variants work. With enough users, the cases other than the "most cases" occur often enough; and my point was precisely that maintainers are more likely to just test +foo +bar and assume that +foo and +bar also work. (Not saying that they should test all subsets; rather that they *shouldn't* have to). > It is the responsibility of the maintainer to select what is included by > default without variants, in default_variants or additionally available > as variant. Agreed. > > and is not > > pleasant to anyone, especially Mac users accustomed to encountering > > decisions Done Right. Having to pick from so many choices feels > > awful[3,4]. Just design for yourself[5], and if there are disgruntled > > users they'll let you know. > > There, I'm off my soapbox. Really, just please read [1]. > > What I learnt mostly is that Mac users are ignorant people who like to > complain and rant if software does not work. But the number of people > actually filing tickets and providing patches is small. Great. :) So why worry about trying to please the ignorant lazy complaining ranting people? If they won't even file tickets, you don't have to work so hard trying to provide so many "options" without even knowing if there exists someone who cares enough to file a ticket. > > in which > > case make it a separate port. > > So you say maintaining multiple ports is easier than maintaining > variants? Keep in mind that for updates you would have to update the > version and checksums in two ports. Also take care that they are using > the same dist_subdir, as the docs are usually distributed in the same > tarball and you don't want to download it twice. Which most probably > makes the port for docs a clone of the original port - except > build.target and destroot.target. Good point. You've convinced me; I agree that when there is reason for not installing documentation by default, it is better to have it as a variant than as a separate port. > > There shouldn't be "no_docs" variants: > > no one really *needs* not to install docs. > > Why should I install docs for a library if I am not going to develop for it? > > In an ideal world, there wouldn't be any +no_* variants. That's just a > lame workaround for broken default_variants and negative variant selections. Agreed, but we have to work with the world we have. :) For cases where you feel that no one needs the docs, it would be fine to remove them entirely: have no variants and don't install docs ever. > > More generally, install all > > features wherever possible (e.g. why is mp_completion a variant for > > zsh instead of being installed by default? Just a random example from > > the bottom of the list, not complaining about that port specifically) > > and where there are cases where this is really "too" huge (say, wrt > > build time, not disk space), have just one variant, between a sensible > > "light" version and the "heavy" version. > > And then I have to select the heavy version requiring >16 other > libraries just because I need support for one of them? Doesn't sound any > better. The question is whether there are users who really want just one of them. I'm not saying it's possible always, but in most cases, with a little thought, it is possible to winnow down the possibilities users *actually* want to a small set. On Thu, Mar 26, 2009 at 11:32:54AM +0100, afb wrote: > I thought the whole point of doing Ports for Mac was to provide > choice... IMO, the point was to provide "package mananagement", making it easy to install, upgrade, and not have to chase down dependencies, especially for packages without a graphical binary installer. To reiterate/rephrase, I had two suggestions: 1. That the default selection of variants should be a good choice for what the user is likely to need, so that he/she won't have to reinstall with different variants, always be careful to check variants, etc. 2. That there should not be variants corresponding to things no actual users care about, just to give them "options". This only makes things worse, so variants should exist only when there is user demand. It seems everyone agrees with (1), but not everyone with (2). Most users are only going to be affected by (1), so even just that would be great. The arguments for (2) are that * having too many variants can lead to things break *subtly* * there is a high cost (to the user) of making "the wrong choice" * discouraging variants is a way of encouraging maintainers to make the right choices, as in (1) * it can reduce the amount of work and testing for the maintainers Ultimately, of course, the choice of what to do is the maintainers'; since they are the ones doing the work. :) Cheers, Shreevatsa From allencmcbride at gmail.com Thu Mar 26 23:25:42 2009 From: allencmcbride at gmail.com (Allen McBride) Date: Fri, 27 Mar 2009 02:25:42 -0400 Subject: mistake in my solfege portfile, seeking guidance Message-ID: As I've written at http://trac.macports.org/ticket/18870 I made a mistake in my portfile for solfege. For a silly reason, I didn't realize that Mac users, in order to use Solfege, needed to install an external MIDI player and then point Solfege at that player in its preferences, once it's running. Therefore I think I should add qtplay as a runtime dependency for solfege. I'm working with the author to make it so that Solfege will default to the correct settings if it's being built on a Mac. In the meantime, I'm thinking I should submit a new portfile with the following changes: 1) Include qtplay as a runtime dependency 2) Include the following (I copied the ui_msg thing from python26): post-activate { ui_msg "\nAfter starting Solfege for the first time, select\ File->Preferences. \nUnder the External Programs tab, under the subheading\ Audio File \nPlayers, enter \"qtplay\" in the field labeled \"MIDI:\".\ Under the \nSound Setup tab, select \"Use external MIDI player\".\n" } 3) Include "revision 1" Does this seem like the right course of action? I could also just wait until I get everything ironed out so that users don't have to mess with preferences at all. But I hate to think of users being frustrated with the error message that Rainer told me about on the ticket. I guess I don't have any idea how many MacPorts fans are likely to install a yet-unadvertised, minor port like solfege in the next week or two. Could be zero or fifty, for all I know. Thanks, Allen From ryandesign at macports.org Fri Mar 27 00:18:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 27 Mar 2009 02:18:08 -0500 Subject: mistake in my solfege portfile, seeking guidance In-Reply-To: References: Message-ID: On Mar 27, 2009, at 01:25, Allen McBride wrote: > As I've written at > http://trac.macports.org/ticket/18870 > I made a mistake in my portfile for solfege. For a silly reason, I > didn't realize that Mac users, in order to use Solfege, needed to > install an external MIDI player and then point Solfege at that > player in its preferences, once it's running. Therefore I think I > should add qtplay as a runtime dependency for solfege. I'm working > with the author to make it so that Solfege will default to the > correct settings if it's being built on a Mac. In the meantime, > I'm thinking I should submit a new portfile with the following > changes: > > 1) Include qtplay as a runtime dependency > > 2) Include the following (I copied the ui_msg thing from python26): > post-activate { > ui_msg "\nAfter starting Solfege for the first time, select\ > File->Preferences. \nUnder the External Programs tab, under the > subheading\ > Audio File \nPlayers, enter \"qtplay\" in the field labeled \"MIDI: > \".\ > Under the \nSound Setup tab, select \"Use external MIDI player\".\n" > } > > 3) Include "revision 1" > > Does this seem like the right course of action? I could also just > wait until I get everything ironed out so that users don't have to > mess with preferences at all. But I hate to think of users being > frustrated with the error message that Rainer told me about on the > ticket. I guess I don't have any idea how many MacPorts fans are > likely to install a yet-unadvertised, minor port like solfege in > the next week or two. Could be zero or fifty, for all I know. Those changes sound good to me! From afb at macports.org Fri Mar 27 01:00:04 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri, 27 Mar 2009 09:00:04 +0100 Subject: Discouraging variants [was: Re: port install efficiency issue] In-Reply-To: <49cc5f26.85c2f10a.6a85.3064@mx.google.com> References: <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> <4B8AB84D-CF0F-400C-8BA8-42590F24A42A@macports.org> <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> <7675454e0903251939i5296e786tafcda0d7e6683b5f@mail.gmail.com> <49CB5352.9010407@macports.org> <7675454e0903242105k2a019a0frc27bc0894cde68bf@mail.gmail.com> <7675454e0903251939i5296e786tafcda0d7e6683b5f@mail.gmail.com> <20090326084627.GA15918@velsheda.lateralis.org> <49cc5f26.85c2f10a.6a85.3064@mx.google.com> Message-ID: <374C414A-4058-44CB-927E-391A96513162@macports.org> Shreevatsa R wrote: >> I thought the whole point of doing Ports for Mac was to provide >> choice... > > IMO, the point was to provide "package mananagement", making it > easy to > install, upgrade, and not have to chase down dependencies, especially > for packages without a graphical binary installer. Well, if MacPorts had used a package manager that could have been it. :-) Sure it provides "software management" (or "port management") for you... But when building packages, the actual handling of those is outsourced to whatever package manager chosen - whether Installer.app or rpm or dpkg. If and when the project starts a binary distribution, we can resume the package management discussion. Hopefully it doesn't mean just "xpkg"... --anders From ryandesign at macports.org Fri Mar 27 04:19:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 27 Mar 2009 06:19:40 -0500 Subject: overriding the checksum phase (was: [48686] trunk/dports/databases/libpqxx/Portfile) In-Reply-To: <20090327060253.6C5891301B6B@beta.macosforge.org> References: <20090327060253.6C5891301B6B@beta.macosforge.org> Message-ID: <7BE50237-55FD-46C9-8126-CD821BE1B771@macports.org> On Mar 27, 2009, at 01:02, jmr at macports.org wrote: > Revision: 48686 > http://trac.macports.org/changeset/48686 > Author: jmr at macports.org > Date: 2009-03-26 23:02:52 -0700 (Thu, 26 Mar 2009) > Log Message: > ----------- > libpqxx: don't skip checksum phase (!) > > Modified Paths: > -------------- > trunk/dports/databases/libpqxx/Portfile > > Modified: trunk/dports/databases/libpqxx/Portfile > =================================================================== > --- trunk/dports/databases/libpqxx/Portfile 2009-03-27 05:52:14 UTC > (rev 48685) > +++ trunk/dports/databases/libpqxx/Portfile 2009-03-27 06:02:52 UTC > (rev 48686) > @@ -37,8 +37,6 @@ > sha1 163d4142015c81a0dc4046fff208d14411532717 \ > rmd160 05cd650741fa29174252a4b09b3030911c0ceb95 > > -checksum {} Wouldn't you say that no port should ever override the checksum phase? If there are distfiles, their checksums must be validated, and if there are no distfiles, then the checksum phase won't get run anyway. Same with the extract phase. If we agree, we could add a warning to lint about this. The following ports block the checksum phase: $ grep '^checksum[[:space:]]*{[[:space:]]*}' */*/Portfile databases/postgresql80-server/Portfile:checksum {} databases/postgresql81-server/Portfile:checksum {} databases/postgresql82-server/Portfile:checksum {} databases/postgresql83-server/Portfile:checksum {} devel/gnome-bindings-csharp/Portfile:checksum { } devel/gnome-bindings-cxx/Portfile:checksum { } devel/gnome-bindings-perl5/Portfile:checksum { } devel/gnome-bindings-python/Portfile:checksum { } devel/gnome-bindings-suite/Portfile:checksum { } devel/hg-forest/Portfile:checksum {} devel/libopensync/Portfile:checksum {} gnome/colorscheme/Portfile:checksum {} gnome/control-center/Portfile:checksum {} gnome/gnome-desktop-suite/Portfile:checksum { } gnome/gnome-platform-suite/Portfile:checksum { } gnome/gnome/Portfile:checksum { } gnustep/gnustep-core/Portfile:checksum { } gnustep/gnustep/Portfile:checksum { } graphics/glut/Portfile:checksum { } kde/kde/Portfile:checksum { } lang/ghc-devel/Portfile:checksum { } lang/perl5/Portfile:checksum {} lang/smlnj-dev/Portfile:checksum { } python/py-scipy04/Portfile:checksum {} ruby/rb-dbd-mysql/Portfile:checksum {} ruby/rb-dbd-pg/Portfile:checksum {} tex/texlive/Portfile:checksum {} x11/xorg-apps/Portfile:checksum { } x11/xorg-fonts/Portfile:checksum { } x11/xorg-proto/Portfile:checksum { } x11/xorg/Portfile:checksum { } xfce/xfce/Portfile:checksum { } $ And we have these ports blocking the extract phase: $ grep '^extract[[:space:]]*{[[:space:]]*}' */*/Portfile audio/flac2mp3/Portfile:extract {} databases/postgresql80-server/Portfile:extract {} databases/postgresql81-server/Portfile:extract {} databases/postgresql82-server/Portfile:extract {} databases/postgresql83-server/Portfile:extract {} devel/cl-ppcre/Portfile:extract {} devel/hg-forest/Portfile:extract {} devel/libopensync/Portfile:extract {} graphics/glut/Portfile:extract { } lang/ghc-devel/Portfile:extract { } lang/lisp-hyperspec/Portfile:extract { } lang/perl5/Portfile:extract {} ruby/rb-dbd-mysql/Portfile:extract {} ruby/rb-dbd-pg/Portfile:extract {} sysutils/ccal/Portfile:extract {} tex/texlive/Portfile:extract {} textproc/psbind/Portfile:extract { } x11/xroot/Portfile:extract {} $ From ryandesign at macports.org Fri Mar 27 04:22:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 27 Mar 2009 06:22:02 -0500 Subject: Fwd: cpan2port References: <20090324145741.GA8684@auckland.lan> Message-ID: <8A7C194C-A095-47E7-BDD1-4A92EFA86446@macports.org> Marc's response: Begin forwarded message: > From: Marc Chantreux > Date: March 24, 2009 09:57:41 CDT > To: Ryan Schmidt > Subject: Re: cpan2port > > hello Ryan, > > For the moment, we have no to fund the cpan2port project and i have no > free time to hack on it ... I have a ready to use macports account and > and hope i'll use it asap. > > Waiting for this glorious moment, please feel free to do everything > you > find usefull for yourself and the communauty (very last version as > attachement). > > On Tue, Mar 24, 2009 at 02:16:01AM -0500, Ryan Schmidt wrote: >> #! /usr/bin/perl >> >> Why is it using Mac OS X perl and not MacPorts perl? Perhaps it could >> use "#! /usr/bin/env perl" so that it would use the perl that I >> prefer. > > i actually prepare the packages on my server that is a debian machine > because my mac is an old damn slow G4 under tiger. > > but you're right: this must be fixed. > >> Third, I tried to run the script with no parameters, expecting a >> usage >> The script appears to want a module Module::Depends but I guess >> Mac OS X >> doesn't provide this. I don't want to use CPAN to install any >> modules in >> my Mac OS X perl; I want to use MacPorts to install perl modules >> for use >> with MacPorts perl. Then again, we don't seem to have a port >> p5-module-depends either. Can we add this and any other ports this >> script >> needs? > > I just generated the portfile (as attachement too). It's not tested: > feel free to feeback if it doesn't work (or if everthing else goes > wrong). > >> Maybe I'm going about this wrong. > > No: *i* use it wrong ... > >> Clearly the author of the script got it to work, > > sure: i am the author and i generated everything required to > install the > koha ILS. > >> and I assume others have as well since it was announced. Should >> I be doing something different to use this script? > > I have only one testimonial of successfull use ... please be the > second > one ;) > > regards > marc -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cpan2port.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Portfile.txt URL: -------------- next part -------------- From ryandesign at macports.org Fri Mar 27 04:23:33 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 27 Mar 2009 06:23:33 -0500 Subject: overriding the checksum phase (was: [48686] trunk/dports/databases/libpqxx/Portfile) In-Reply-To: <7BE50237-55FD-46C9-8126-CD821BE1B771@macports.org> References: <20090327060253.6C5891301B6B@beta.macosforge.org> <7BE50237-55FD-46C9-8126-CD821BE1B771@macports.org> Message-ID: <809242D8-1BC2-4F43-96E6-2F189178C2C2@macports.org> On Mar 27, 2009, at 06:19, Ryan Schmidt wrote: > Wouldn't you say that no port should ever override the checksum > phase? If there are distfiles, their checksums must be validated, > and if there are no distfiles, then the checksum phase won't get > run anyway. > > Same with the extract phase. Same with the fetch phase. $ grep '^fetch[[:space:]]*{[[:space:]]*}' */*/Portfile databases/postgresql80-server/Portfile:fetch {} databases/postgresql81-server/Portfile:fetch {} databases/postgresql82-server/Portfile:fetch {} databases/postgresql83-server/Portfile:fetch {} devel/gnome-bindings-csharp/Portfile:fetch { } devel/gnome-bindings-cxx/Portfile:fetch { } devel/gnome-bindings-perl5/Portfile:fetch { } devel/gnome-bindings-python/Portfile:fetch { } devel/gnome-bindings-suite/Portfile:fetch { } devel/hg-forest/Portfile:fetch {} devel/libopensync/Portfile:fetch {} gnome/control-center/Portfile:fetch {} gnome/gnome-desktop-suite/Portfile:fetch { } gnome/gnome-platform-suite/Portfile:fetch { } gnome/gnome/Portfile:fetch { } gnustep/gnustep-core/Portfile:fetch { } gnustep/gnustep/Portfile:fetch { } graphics/glut/Portfile:fetch { } kde/kde/Portfile:fetch { } lang/perl5/Portfile:fetch {} ruby/rb-dbd-mysql/Portfile:fetch {} ruby/rb-dbd-pg/Portfile:fetch {} tex/texlive/Portfile:fetch {} x11/xorg-apps/Portfile:fetch { } x11/xorg-fonts/Portfile:fetch { } x11/xorg-proto/Portfile:fetch { } x11/xorg/Portfile:fetch { } x11/xping/Portfile:fetch {} xfce/xfce/Portfile:fetch { } $ From ryandesign at macports.org Fri Mar 27 04:43:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 27 Mar 2009 06:43:42 -0500 Subject: overriding the checksum phase In-Reply-To: <7BE50237-55FD-46C9-8126-CD821BE1B771@macports.org> References: <20090327060253.6C5891301B6B@beta.macosforge.org> <7BE50237-55FD-46C9-8126-CD821BE1B771@macports.org> Message-ID: On Mar 27, 2009, at 06:19, Ryan Schmidt wrote: > If we agree, we could add a warning to lint about this. Which could look like the attached patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: portlint.tcl.diff Type: application/octet-stream Size: 593 bytes Desc: not available URL: From ryandesign at macports.org Fri Mar