From randall.h.wood at alexandriasoftware.com Sat Dec 1 00:53:10 2007 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sat Dec 1 00:50:14 2007 Subject: ChangeLog and NEWS file (Re: [31640] trunk/base) In-Reply-To: References: <20071201033215.B1C0D22DFD7@beta.macosforge.org> Message-ID: Is there any reason the ChangeLog can not be automatically generated from the SVN commit messages? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20071201/7782cff2/attachment.html From ryandesign at macports.org Sat Dec 1 01:08:27 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Dec 1 01:05:33 2007 Subject: +x11, and +quartz variants (or a dangerous idea) In-Reply-To: References: Message-ID: <88AFD808-924D-479E-B8ED-DA72EADED196@macports.org> On Nov 30, 2007, at 05:10, Randall Wood wrote: > I would like to suggest that the variants +quartz and +x11 should > be supported where relevant, eliminating the use of the +no_x11 > variant: > > > +quartz Enable building the port to render graphics using the > quartz engine and aqua user interface > +x11 Enable building the port to use X11 > > > Furthermore, I would like to suggest that these variants should > never be default variants and that we should modify the macports > base to recognize that a port has these variants and if neither is > selected (either at the command line or in variants.conf) that an > error message should be displayed explaining that the port may be > installed with either: +quartz, +x11, or +quartz+x11, although some > ports may result in unpredicatable behavior if +quartz+x11 is used. > > > Furthermore, I would like to suggest that the +no_x11 variant and > the +no_quartz (if it is used at all) variants should be actively > discouraged. I wouldn't make this generalization. There are ports, like ImageMagick, that have a +no_x11 variant, which I believe should continue to have them. ImageMagick can build with support for some X11 things, or not. By default, we want to build the most featureful software possible, so X11 support is on by default. Users who do not wish this support can use the +no_x11 variant. I'm not aware of any Quartz support in ImageMagick. Unless you would like to redefine our default installation goals to no longer be "most featureful" but instead be "most featureful excluding X11 things". I'm not saying we should or should not redefine this, just point out what our current status is, and that you seem to be proposing a change to that. Actually, I guess our current guidelines are to build a port to be the most featureful while not including huge libraries as dependencies which most users won't want. Thus far, I think we've had an unspoken agreement that the X11 features are useful, and indeed our installation docs require the user to install X11 and the X11SDK. I guess you're proposing a change to that as well. From randall.h.wood at alexandriasoftware.com Sat Dec 1 01:56:04 2007 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sat Dec 1 01:53:08 2007 Subject: +x11, and +quartz variants (or a dangerous idea) In-Reply-To: <88AFD808-924D-479E-B8ED-DA72EADED196@macports.org> References: <88AFD808-924D-479E-B8ED-DA72EADED196@macports.org> Message-ID: On 12/1/07, Ryan Schmidt wrote: > > > On Nov 30, 2007, at 05:10, Randall Wood wrote: > > > I would like to suggest that the variants +quartz and +x11 should > > be supported where relevant, eliminating the use of the +no_x11 > > variant: > > > > > > +quartz Enable building the port to render graphics using the > > quartz engine and aqua user interface > > +x11 Enable building the port to use X11 > > > > > > Furthermore, I would like to suggest that these variants should > > never be default variants and that we should modify the macports > > base to recognize that a port has these variants and if neither is > > selected (either at the command line or in variants.conf) that an > > error message should be displayed explaining that the port may be > > installed with either: +quartz, +x11, or +quartz+x11, although some > > ports may result in unpredicatable behavior if +quartz+x11 is used. > > > > > > Furthermore, I would like to suggest that the +no_x11 variant and > > the +no_quartz (if it is used at all) variants should be actively > > discouraged. > > > > I wouldn't make this generalization. There are ports, like > ImageMagick, that have a +no_x11 variant, which I believe should > continue to have them. ImageMagick can build with support for some > X11 things, or not. By default, we want to build the most featureful > software possible, so X11 support is on by default. Users who do not > wish this support can use the +no_x11 variant. I'm not aware of any > Quartz support in ImageMagick. > > Unless you would like to redefine our default installation goals to > no longer be "most featureful" but instead be "most featureful > excluding X11 things". I'm not saying we should or should not > redefine this, just point out what our current status is, and that > you seem to be proposing a change to that. > > Actually, I guess our current guidelines are to build a port to be > the most featureful while not including huge libraries as > dependencies which most users won't want. Thus far, I think we've had > an unspoken agreement that the X11 features are useful, and indeed > our installation docs require the user to install X11 and the X11SDK. > I guess you're proposing a change to that as well. > > This is not a case of selecting features, but of having to make *mutually exclusive choices* between the Aqua (quartz rendering) and X11 user interfaces. In this case, I think we should make the default behavior be Aqua, but I am aware that pushing that now will break what already works during an upgrade, so I have made the default behavior to fail without explicit instructions from the user. -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20071201/09cc0f25/attachment.html From milosh at macports.org Sat Dec 1 02:15:33 2007 From: milosh at macports.org (Emmanuel Hainry) Date: Sat Dec 1 02:12:38 2007 Subject: +x11, and +quartz variants (or a dangerous idea) In-Reply-To: References: <88AFD808-924D-479E-B8ED-DA72EADED196@macports.org> Message-ID: <20071201101533.GA5502@velsheda.lateralis.org> Citando Randall Wood : > On 12/1/07, Ryan Schmidt wrote: > > > > I wouldn't make this generalization. There are ports, like > > ImageMagick, that have a +no_x11 variant, which I believe should > > continue to have them. ImageMagick can build with support for some > > X11 things, or not. By default, we want to build the most featureful > > software possible, so X11 support is on by default. Users who do not > > wish this support can use the +no_x11 variant. I'm not aware of any > > Quartz support in ImageMagick. > > > > Unless you would like to redefine our default installation goals to > > no longer be "most featureful" but instead be "most featureful > > excluding X11 things". I'm not saying we should or should not > > redefine this, just point out what our current status is, and that > > you seem to be proposing a change to that. > > > > Actually, I guess our current guidelines are to build a port to be > > the most featureful while not including huge libraries as > > dependencies which most users won't want. Thus far, I think we've had > > an unspoken agreement that the X11 features are useful, and indeed > > our installation docs require the user to install X11 and the X11SDK. > > I guess you're proposing a change to that as well. > > > > > This is not a case of selecting features, but of having to make *mutually > exclusive choices* between the Aqua (quartz rendering) and X11 user > interfaces. In this case, I think we should make the default behavior be > Aqua, but I am aware that pushing that now will break what already works > during an upgrade, so I have made the default behavior to fail without > explicit instructions from the user. > This choice between aqua and x11 is only sensible for ports depending on gtk. ImageMagick's display, teTeX's xdvi and most ports depending on X11 have no quartz backend. I don't know about gtk (the number of dependencies made me avoid gtk on osx), I'm not sure about qt (qt-mac and qt-x11 seem to provide the same things and ports depending on qt seem to be able to work in both cases), but for other things +no_x11 is often the most sensible variant to provide. As for gimp and other gtk progs, isn't the best way to do to have a gimp-app and gimp-x port that depend on two gtk2 ports (gtk2-quartz and gtk2-x) as vim-app vs vim +gtk or carbon-emacs vs emacs? Probably the most time consuming for the maintainers though as it means a lot of ports that become twice a lot of ports (but half as many variants to test and no black-variant-magick dependency to check). Emmanuel From simon at ruderich.com Sat Dec 1 03:48:07 2007 From: simon at ruderich.com (Simon Ruderich) Date: Sat Dec 1 03:52:14 2007 Subject: Meet our new website In-Reply-To: <402877A8-CF28-482B-B4E0-F4FA44E00BF2@macports.org> References: <402877A8-CF28-482B-B4E0-F4FA44E00BF2@macports.org> Message-ID: <20071201114806.GB15112@ruderich.com> On Fri, Nov 30, 2007 at 11:37:14PM -0400, Juan Manuel Palacios wrote: > > Say hello: http://www.macports.org/ > > Thanks a bunch to Bill for making this happen, much appreciated! > > As always, feedback is welcome. I'll announce our new web presence to a > broader audience together with the release of 1.6.0, which I'm putting > together as we spea.... sorry, as I write this message ;-) > > Regards,... > > > -jmpp It looks great, thanks to all who helped create it. I found a minor issue. The links to "The Macports Guide" should be http://geeklair.net/macports_guide/ as the guide is the same on both the locations. And I think the Trac installation (as the blog) should also use the new design for the left navigation. Thanks again, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071201/e47bdb7a/attachment.bin From loshea at gmail.com Sat Dec 1 14:35:54 2007 From: loshea at gmail.com (Luis O'Shea) Date: Sat Dec 1 14:32:56 2007 Subject: New port needs commit -- asymptote Message-ID: I have created a port for asymptote, see ticket 13249. Could someone please review and commit it? Thanks. This is my first port, so it's probably worth checking that I haven't done anything too silly. Luis O'Shea From ryandesign at macports.org Sat Dec 1 23:50:28 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Dec 1 23:47:29 2007 Subject: [31655] trunk/dports/lang/sbcl In-Reply-To: <20071201223117.E8DBF23A63E@beta.macosforge.org> References: <20071201223117.E8DBF23A63E@beta.macosforge.org> Message-ID: On Dec 1, 2007, at 16:31, waqar@macports.org wrote: > Revision: 31655 > http://trac.macosforge.org/projects/macports/changeset/31655 > Author: waqar@macports.org > Date: 2007-12-01 14:31:16 -0800 (Sat, 01 Dec 2007) > > Log Message: > ----------- > Updated to the latest release of the software and fixed the build > on Leopard. > > Modified Paths: > -------------- > trunk/dports/lang/sbcl/Portfile > > Added Paths: > ----------- > trunk/dports/lang/sbcl/files/base-target-features.patch Patchfiles should be named "patch-whatever.diff". "port lint" in MacPorts 1.6.0 will flag this as a warning otherwise. Especially for new patchfiles, there's no reason not to follow the recommended patchname convention. From ryandesign at macports.org Sat Dec 1 23:48:43 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Dec 2 00:12:26 2007 Subject: [31659] trunk/dports/games/freeciv In-Reply-To: <20071202024307.6EBE123D78B@beta.macosforge.org> References: <20071202024307.6EBE123D78B@beta.macosforge.org> Message-ID: On Dec 1, 2007, at 20:43, rhwood@macports.org wrote: > Revision: 31659 > http://trac.macosforge.org/projects/macports/changeset/31659 > Author: rhwood@macports.org > Date: 2007-12-01 18:42:54 -0800 (Sat, 01 Dec 2007) > > Log Message: > ----------- > Add patch from Bryan Blackburn to build if bind9 is present. Is there any more information available about this? a ticket? a discussion somewhere? php5 won't build either if bind9 is present, and it would be nice to know if this fix for freeciv will help php5 as well. Thanks. From ryandesign at macports.org Sun Dec 2 00:57:37 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Dec 2 00:54:39 2007 Subject: [31625] trunk/dports/lang/scala/Portfile In-Reply-To: <20071130211452.C666822937D@beta.macosforge.org> References: <20071130211452.C666822937D@beta.macosforge.org> Message-ID: On Nov 30, 2007, at 15:14, blair@macports.org wrote: > Revision: 31625 > http://trac.macosforge.org/projects/macports/changeset/31625 > Author: blair@macports.org > Date: 2007-11-30 13:14:51 -0800 (Fri, 30 Nov 2007) > > Log Message: > ----------- > New upstream 2.6.1-RC1 release of Scala. > > Modified Paths: > -------------- > trunk/dports/lang/scala/Portfile > > Modified: trunk/dports/lang/scala/Portfile > =================================================================== > --- trunk/dports/lang/scala/Portfile 2007-11-30 19:49:21 UTC (rev > 31624) > +++ trunk/dports/lang/scala/Portfile 2007-11-30 21:14:51 UTC (rev > 31625) > @@ -2,7 +2,7 @@ > > PortSystem 1.0 > name scala > -version 2.6.0 > +version 2.6.0.2.6.1.rc1 Out of curiosity, why not "version 2.6.1-rc1"? Is there a MacPorts base bug you're working around by using this made-up version number? From ryandesign at macports.org Sun Dec 2 01:08:30 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Dec 2 01:05:32 2007 Subject: [31639] trunk/dports/sysutils/duplicity/Portfile In-Reply-To: <20071201024352.000C622D7F6@beta.macosforge.org> References: <20071201024352.000C622D7F6@beta.macosforge.org> Message-ID: <432C65F9-0621-46CB-B0CE-295A22E3A208@macports.org> On Nov 30, 2007, at 20:43, ram@macports.org wrote: > Revision: 31639 > http://trac.macosforge.org/projects/macports/changeset/31639 > Author: ram@macports.org > Date: 2007-11-30 18:43:49 -0800 (Fri, 30 Nov 2007) > > Log Message: > ----------- > sysutils/duplicity: disable universal variant That's clear from the diff. The log message should really go a bit further to explain why the change is being made. Is it because the software is non-binary and therefore architecture-agnostic? or is it because the universal build process is currently broken for this software and a solution is not yet known? or because it only builds universal when hosted on one architecture but not the other? Putting this in the log will help people looking at the port later decide whether they should invest time in trying to make the port work universal or not. From randall.h.wood at alexandriasoftware.com Sun Dec 2 01:21:16 2007 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sun Dec 2 01:18:15 2007 Subject: [31659] trunk/dports/games/freeciv In-Reply-To: References: <20071202024307.6EBE123D78B@beta.macosforge.org> Message-ID: There was just one email message directly from Bryan Blackburn to me, forwarded under separate cover. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20071202/dfdf1b4c/attachment.html From randall.h.wood at alexandriasoftware.com Sun Dec 2 01:21:26 2007 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sun Dec 2 01:18:26 2007 Subject: Fwd: freeciv patch when bind9 is installed In-Reply-To: References: Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: patch-configure.diff Type: application/octet-stream Size: 7002 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071202/8f501430/patch-configure.obj From ryandesign at macports.org Sun Dec 2 03:14:07 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Dec 2 03:11:08 2007 Subject: [31624] trunk/doc-new/guide/xml/portfile-global-keywords.7.xml In-Reply-To: <20071130194930.1FE3F227B4C@beta.macosforge.org> References: <20071130194930.1FE3F227B4C@beta.macosforge.org> Message-ID: <18C3909D-59F2-4879-9A4B-03C84238EE81@macports.org> On Nov 30, 2007, at 13:49, simon@macports.org wrote: > - homepage http://www.somesite.org/apps programlisting> > + homepage http://www.somesite.org/apps programlisting> The web site "www.somesite.org" is owned by a domain squatter. The correct web site address to use in examples and documentation is "www.example.(com|net|org)". These are reserved for examples. See section 3 of RFC 2606. http://www.ietf.org/rfc/rfc2606.txt From blair at orcaware.com Sun Dec 2 06:40:18 2007 From: blair at orcaware.com (Blair Zajac) Date: Sun Dec 2 06:37:32 2007 Subject: [31625] trunk/dports/lang/scala/Portfile In-Reply-To: References: <20071130211452.C666822937D@beta.macosforge.org> Message-ID: <0C71705D-E09C-47C9-9C65-D2F3CFF29C98@orcaware.com> On Dec 2, 2007, at 12:57 AM, Ryan Schmidt wrote: > > On Nov 30, 2007, at 15:14, blair@macports.org wrote: > >> Revision: 31625 >> http://trac.macosforge.org/projects/macports/changeset/ >> 31625 >> Author: blair@macports.org >> Date: 2007-11-30 13:14:51 -0800 (Fri, 30 Nov 2007) >> >> Log Message: >> ----------- >> New upstream 2.6.1-RC1 release of Scala. >> >> Modified Paths: >> -------------- >> trunk/dports/lang/scala/Portfile >> >> Modified: trunk/dports/lang/scala/Portfile >> =================================================================== >> --- trunk/dports/lang/scala/Portfile 2007-11-30 19:49:21 UTC (rev >> 31624) >> +++ trunk/dports/lang/scala/Portfile 2007-11-30 21:14:51 UTC (rev >> 31625) >> @@ -2,7 +2,7 @@ >> >> PortSystem 1.0 >> name scala >> -version 2.6.0 >> +version 2.6.0.2.6.1.rc1 > > Out of curiosity, why not "version 2.6.1-rc1"? Is there a MacPorts > base bug you're working around by using this made-up version number? Because when 2.6.1 final comes out with a '2.6.1' version number, it'll be less then '2.6.1-rc1'. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From ebgssth at gmail.com Sun Dec 2 07:53:14 2007 From: ebgssth at gmail.com (js) Date: Sun Dec 2 07:50:17 2007 Subject: NEW port request Message-ID: Hi, I submitted two new ports, py25-httplib2 and py25-lxml about a week ago, but I've got no response... Could anyone please review these attachment and commit them to svn? http://trac.macosforge.org/projects/macports/ticket/13411 http://trac.macosforge.org/projects/macports/ticket/13393 From jmpp at macports.org Sun Dec 2 09:28:45 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun Dec 2 09:23:02 2007 Subject: ChangeLog and NEWS file (Re: [31640] trunk/base) In-Reply-To: References: <20071201033215.B1C0D22DFD7@beta.macosforge.org> Message-ID: <561FAA99-175B-49D5-8AB3-9E38DB7684E5@macports.org> On Dec 1, 2007, at 4:53 AM, Randall Wood wrote: > Is there any reason the ChangeLog can not be automatically generated > from the SVN commit messages? First off, an entry in the ChangeLog does not need to fully mirror its corresponding commit log. If the latter is small, like a one liner comment, then it surely could, that wouldn't be a bad thing; but in the other case, when a commit log is a detailed explanation of what was fixed and how (as commit logs should really be), then duplicating all that information in the ChangeLog would be completely overkill, in my opinion. That's the reason why I'm requesting entries in the ChangeLog be made full with svn revision and ticket number (if any) references, so that they can be regarded as "summaries that point interested parties to further information", short of telling them "run 'svn log' on base and spend hours in there to become acquainted with what has changed and how" (sounds live I've been there...? ;-). But that put aside, do you have any suggestions for auto-generation of the ChangeLog off of the commit log? The only thing that comes to mind is a post-commit hook of some kind that prepends the log of particular revisions to the ChangeLog and then in turn commits that change, which in my opinion is also unnecessarily overkill (you would have to handle infinite loops and other corner cases). The only other thing I can think of is... manually making an entry for your commit ;-) Regards,... -jmpp From jmpp at macports.org Sun Dec 2 09:35:52 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun Dec 2 09:30:05 2007 Subject: Meet our new website In-Reply-To: <20071201114806.GB15112@ruderich.com> References: <402877A8-CF28-482B-B4E0-F4FA44E00BF2@macports.org> <20071201114806.GB15112@ruderich.com> Message-ID: On Dec 1, 2007, at 7:48 AM, Simon Ruderich wrote: > On Fri, Nov 30, 2007 at 11:37:14PM -0400, Juan Manuel Palacios wrote: >> >> Say hello: http://www.macports.org/ >> >> Thanks a bunch to Bill for making this happen, much appreciated! >> >> As always, feedback is welcome. I'll announce our new web presence >> to a >> broader audience together with the release of 1.6.0, which I'm >> putting >> together as we spea.... sorry, as I write this message ;-) >> >> Regards,... >> >> >> -jmpp > > It looks great, thanks to all who helped create it. > > I found a minor issue. The links to "The Macports Guide" should be > http://geeklair.net/macports_guide/ as the guide is the same on both > the > locations. Thanks for pointing this out, Simon, I just corrected it in r31668. > > > And I think the Trac installation (as the blog) should also use the > new design > for the left navigation. You are completely right, they should. Nevertheless, the blog and Trac are entities technically separate from our website and many extra steps would have to be taken to further integrate them into our new design. I'm not saying we wont do it, but rather explaining why we haven't. The blog feature is in flux at the moment and its current wordpress incarnation will be going away eventually, so there's no point in investing any time in improving what we currently have there. As for Trac, we're still working on polishing its the functionality details (Trac mails, user permissions, etc); once that's done, I'll push for the visual integration with the new site. > > > Thanks again, > Simon Thank you for the feedback! Regards,... -jmpp From jmpp at macports.org Sun Dec 2 09:50:41 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun Dec 2 09:44:53 2007 Subject: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard In-Reply-To: <475041AD.8050900@mathiesen.info> References: <20071129150356.GA7916@haing4.loria.fr> <71CC6889-D3C2-4AAA-A214-C53FBA31E7AA@apple.com> <8B475581-62E6-4F2A-A7FF-C782CC3B2838@macports.org> <475041AD.8050900@mathiesen.info> Message-ID: <67FAAB0B-084A-475E-A129-DBA425CF05B7@macports.org> On Nov 30, 2007, at 1:00 PM, Bjarne D Mathiesen wrote: > How about this: > > mkdir -p /etc/paths.d > mv -n /etc/paths /etc/paths.d/999macosx > touch /etc/paths > echo "${prefix}/bin" > /etc/paths.d/000macports > echo "${prefix}/sbin" >> /etc/paths.d/000macports > echo "/Developer/Tools" > /etc/paths.d/888developer > > mkdir -p /etc/manpaths.d > mv -n /etc/manpaths /etc/manpaths.d/999macosx > touch /etc/manpaths > echo "${prefix}/share/man" > /etc/manpaths.d/000macports > > If the paths are loaded in alphabetical order, this ought to ensure > that > the macports paths are before the standard Mac OS X ones. > > You _do_ want the macport path to be before the standard paths as I > guess you want to execute the alternative utilities provided by > macports > instaed of those from Mac OS X ;-) Even though prepending our path settings to the environment (rather than appending them) is what is preferred and what has been proven to work more smoothly, a hack like what's being proposed above makes me very uncomfortable. Maybe I'm not sufficiently acquainted with its simplicity, but a mere glance makes me fearful of many things we could potentially be breaking. Actually, for that matter, the simple thought of changing anything in /etc/ is not something I'm not too happy with; for me that's a "hands off" area of the system... but I'm aware that's another discussion. So, has any conclusion been reached for this issue? I'm inclined to backing this feature out of the release_1_6 branch until a working consensus is reached, and only release it to the public at that time (in 1.6.x (x > 0)). Until now we've only been modifying the user "profile" for a range of bourne based shells and the "cshrc" file for equivalent C based shells, which has worked fairly well, I believe; anyone experienced enough to create something like ~/.bash_profile or anything else very shell specific would be savvy enough to setup his/ her own environment to their content, I'm sure. I'd strongly favor sticking to this approach in 1.6.0 until something better is found, unless it explicitly breaks expected behavior on Leopard. Does it? Regards,... -jmpp From jmpp at macports.org Sun Dec 2 09:58:29 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun Dec 2 09:52:42 2007 Subject: ChangeLog and NEWS file (Re: [31640] trunk/base) In-Reply-To: <561FAA99-175B-49D5-8AB3-9E38DB7684E5@macports.org> References: <20071201033215.B1C0D22DFD7@beta.macosforge.org> <561FAA99-175B-49D5-8AB3-9E38DB7684E5@macports.org> Message-ID: <3A3656BD-CCEE-47E8-89F9-D2327D103163@macports.org> On Dec 2, 2007, at 1:28 PM, Juan Manuel Palacios wrote: > > On Dec 1, 2007, at 4:53 AM, Randall Wood wrote: > >> Is there any reason the ChangeLog can not be automatically >> generated from the SVN commit messages? > > > First off, an entry in the ChangeLog does not need to fully mirror > its corresponding commit log. If the latter is small, like a one > liner comment, then it surely could, that wouldn't be a bad thing; > but in the other case, when a commit log is a detailed explanation > of what was fixed and how (as commit logs should really be), then > duplicating all that information in the ChangeLog would be > completely overkill, in my opinion. That's the reason why I'm > requesting entries in the ChangeLog be made full with svn revision > and ticket number (if any) references, so that they can be regarded > as "summaries that point interested parties to further information", > short of telling them "run 'svn log' on base and spend hours in > there to become acquainted with what has changed and how" (sounds > live I've been there...? ;-). > > But that put aside, do you have any suggestions for auto-generation > of the ChangeLog off of the commit log? The only thing that comes to > mind is a post-commit hook of some kind that prepends the log of > particular revisions to the ChangeLog and then in turn commits that > change, which in my opinion is also unnecessarily overkill (you > would have to handle infinite loops and other corner cases). The > only other thing I can think of is... manually making an entry for > your commit ;-) > > Regards,... > > > -jmpp > One thing I forgot to say is that it's also perfectly acceptable to group a number of related commits in a single entry on the ChangeLog, provided the full list svn revisions (and, again, ticket number(s) if applicable) is included with it. Regards,... -jmpp From jberry at macports.org Sun Dec 2 10:06:19 2007 From: jberry at macports.org (James Berry) Date: Sun Dec 2 10:03:29 2007 Subject: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard In-Reply-To: <67FAAB0B-084A-475E-A129-DBA425CF05B7@macports.org> References: <20071129150356.GA7916@haing4.loria.fr> <71CC6889-D3C2-4AAA-A214-C53FBA31E7AA@apple.com> <8B475581-62E6-4F2A-A7FF-C782CC3B2838@macports.org> <475041AD.8050900@mathiesen.info> <67FAAB0B-084A-475E-A129-DBA425CF05B7@macports.org> Message-ID: <24E9FB8A-B67C-4F0C-832F-CC0A4EE519B1@macports.org> Hi Juan, On Dec 2, 2007, at 9:50 AM, Juan Manuel Palacios wrote: > So, has any conclusion been reached for this issue? I'm inclined to > backing this feature out of the release_1_6 branch until a working > consensus is reached, and only release it to the public at that time > (in 1.6.x (x > 0)). Until now we've only been modifying the user > "profile" for a range of bourne based shells and the "cshrc" file > for equivalent C based shells, which has worked fairly well, I > believe; anyone experienced enough to create something like > ~/.bash_profile or anything else very shell specific would be savvy > enough to setup his/her own environment to their content, I'm sure. > I'd strongly favor sticking to this approach in 1.6.0 until > something better is found, unless it explicitly breaks expected > behavior on Leopard. Does it? Well, given that man pages are broken at present with a standard MacPorts install under Leopard, something has to be done. A few choices: (1) Use this scheme, as implemented. (Downsides: affects /etc, MacPorts paths are added at the end of PATH and MANPATH). (2) Supplement this scheme by munging PATH inside the MacPorts code to ensure that $prefix is always at the head of the path during builds, and to guard against the sort of build problems suggested by kvv. (3) Modify existing path modification code to also add MacPorts paths to MANPATH. (This might break other man pages on Tiger where the system provides no meaningful default for MANPATH?maybe we do it only if MANPATH is already defined?) I've been mulling over this situation for the last week or so, but haven't done anything because I'm not very happy with any of the solutions.... I think (3), however is the lowest risk approach. James From jmpp at macports.org Sun Dec 2 10:35:22 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun Dec 2 10:30:51 2007 Subject: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard In-Reply-To: <24E9FB8A-B67C-4F0C-832F-CC0A4EE519B1@macports.org> References: <20071129150356.GA7916@haing4.loria.fr> <71CC6889-D3C2-4AAA-A214-C53FBA31E7AA@apple.com> <8B475581-62E6-4F2A-A7FF-C782CC3B2838@macports.org> <475041AD.8050900@mathiesen.info> <67FAAB0B-084A-475E-A129-DBA425CF05B7@macports.org> <24E9FB8A-B67C-4F0C-832F-CC0A4EE519B1@macports.org> Message-ID: <28F38E93-BCD1-415B-B6EA-821BE9FB0D2C@macports.org> On Dec 2, 2007, at 2:06 PM, James Berry wrote: > Hi Juan, > > On Dec 2, 2007, at 9:50 AM, Juan Manuel Palacios wrote: >> So, has any conclusion been reached for this issue? I'm inclined >> to backing this feature out of the release_1_6 branch until a >> working consensus is reached, and only release it to the public at >> that time (in 1.6.x (x > 0)). Until now we've only been modifying >> the user "profile" for a range of bourne based shells and the >> "cshrc" file for equivalent C based shells, which has worked fairly >> well, I believe; anyone experienced enough to create something like >> ~/.bash_profile or anything else very shell specific would be savvy >> enough to setup his/her own environment to their content, I'm sure. >> I'd strongly favor sticking to this approach in 1.6.0 until >> something better is found, unless it explicitly breaks expected >> behavior on Leopard. Does it? > > Well, given that man pages are broken at present with a standard > MacPorts install under Leopard, something has to be done. A few > choices: > > (1) Use this scheme, as implemented. (Downsides: affects /etc, > MacPorts paths are added at the end of PATH and MANPATH). I'm uncomfortable with this approach, as already noted in my previous mail. > > > (2) Supplement this scheme by munging PATH inside the MacPorts code > to ensure that $prefix is always at the head of the path during > builds, and to guard against the sort of build problems suggested by > kvv. MacPorts already sets its internal path for a few things, so this suggestion may be easy to implement but might, just might, have repercussions that we may want to test more thoroughly (not on the verge of a release, in my opinion ;-) > > > (3) Modify existing path modification code to also add MacPorts > paths to MANPATH. (This might break other man pages on Tiger where > the system provides no meaningful default for MANPATH?maybe we do it > only if MANPATH is already defined?) I could definitely look into this extension to the existing postflight script and its implications on both Leopard and Tiger, I like its "lowest risk" approach. In this case I'll remove the /etc/ paths.d and /etc/manpaths.d munging code from the release_1_6 branch to safeguard the release, but will not touch it in trunk so that we can continue brainstorming over it there. Any other suggestions? Regards,... -jmpp From randall.h.wood at alexandriasoftware.com Sun Dec 2 12:43:25 2007 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sun Dec 2 12:40:25 2007 Subject: Fwd: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard In-Reply-To: References: <71CC6889-D3C2-4AAA-A214-C53FBA31E7AA@apple.com> <8B475581-62E6-4F2A-A7FF-C782CC3B2838@macports.org> <475041AD.8050900@mathiesen.info> <67FAAB0B-084A-475E-A129-DBA425CF05B7@macports.org> <24E9FB8A-B67C-4F0C-832F-CC0A4EE519B1@macports.org> <28F38E93-BCD1-415B-B6EA-821BE9FB0D2C@macports.org> Message-ID: Oops. Hit reply instead of reply all... ---------- Forwarded message ---------- From: Randall Wood Date: Dec 2, 2007 3:41 PM Subject: Re: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard To: Juan Manuel Palacios On 12/2/07, Juan Manuel Palacios wrote: > > > On Dec 2, 2007, at 2:06 PM, James Berry wrote: > > > Hi Juan, > > > > On Dec 2, 2007, at 9:50 AM, Juan Manuel Palacios wrote: > >> So, has any conclusion been reached for this issue? I'm inclined > >> to backing this feature out of the release_1_6 branch until a > >> working consensus is reached, and only release it to the public at > >> that time (in 1.6.x (x > 0)). Until now we've only been modifying > >> the user "profile" for a range of bourne based shells and the > >> "cshrc" file for equivalent C based shells, which has worked fairly > >> well, I believe; anyone experienced enough to create something like > >> ~/.bash_profile or anything else very shell specific would be savvy > >> enough to setup his/her own environment to their content, I'm sure. > >> I'd strongly favor sticking to this approach in 1.6.0 until > >> something better is found, unless it explicitly breaks expected > >> behavior on Leopard. Does it? > > > > Well, given that man pages are broken at present with a standard > > MacPorts install under Leopard, something has to be done. A few > > choices: > > > > (1) Use this scheme, as implemented. (Downsides: affects /etc, > > MacPorts paths are added at the end of PATH and MANPATH). > > > I'm uncomfortable with this approach, as already noted in my > previous > mail. If Apple provides a mechanism for third-party developers to append paths to PATH and MANPATH without changing any user or system-installed file, then I think we should use it. We may want though (if this would work--I don't know if symlinks would be honored or if only real files would be honored by this mechanism) to use symlinks from /opt/local/etc/[man]path.d/macports to /etc/[man]path.d/macports instead of placing files in /etc/[man]path.d and provide a simple tool (like macports-path-util) to allow users to add/remove those symlinks > > > > > (2) Supplement this scheme by munging PATH inside the MacPorts > code > > to ensure that $prefix is always at the head of the path during > > builds, and to guard against the sort of build problems suggested by > > kvv. > > > MacPorts already sets its internal path for a few things, so this > suggestion may be easy to implement but might, just might, have > repercussions that we may want to test more thoroughly (not on the > verge of a release, in my opinion ;-) > > > > > > > (3) Modify existing path modification code to also add MacPorts > > paths to MANPATH. (This might break other man pages on Tiger where > > the system provides no meaningful default for MANPATH?maybe we do it > > only if MANPATH is already defined?) > > > I could definitely look into this extension to the existing > postflight script and its implications on both Leopard and Tiger, I > like its "lowest risk" approach. In this case I'll remove the /etc/ > paths.d and /etc/manpaths.d munging code from the release_1_6 branch > to safeguard the release, but will not touch it in trunk so that we > can continue brainstorming over it there. > > Any other suggestions? > > Regards,... > > > -jmpp > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev > -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20071202/34656293/attachment.html From simon at ruderich.com Sun Dec 2 03:55:56 2007 From: simon at ruderich.com (Simon Ruderich) Date: Sun Dec 2 12:58:54 2007 Subject: [31624] trunk/doc-new/guide/xml/portfile-global-keywords.7.xml In-Reply-To: <18C3909D-59F2-4879-9A4B-03C84238EE81@macports.org> References: <20071130194930.1FE3F227B4C@beta.macosforge.org> <18C3909D-59F2-4879-9A4B-03C84238EE81@macports.org> Message-ID: <20071202115556.GA623@ruderich.com> On Sun, Dec 02, 2007 at 05:14:07AM -0600, Ryan Schmidt wrote: > > On Nov 30, 2007, at 13:49, simon@macports.org wrote: > >> - homepage http://www.somesite.org/apps >> + homepage http://www.somesite.org/apps > > The web site "www.somesite.org" is owned by a domain squatter. > > The correct web site address to use in examples and documentation is > "www.example.(com|net|org)". These are reserved for examples. See section 3 > of RFC 2606. > > http://www.ietf.org/rfc/rfc2606.txt Hi Ryan, thanks for the hint. I will fix it as soon it's possible (when we finished some outstanding changes). Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071202/8911c3f1/attachment.bin From ryandesign at macports.org Sun Dec 2 13:49:00 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Dec 2 13:46:02 2007 Subject: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard In-Reply-To: <28F38E93-BCD1-415B-B6EA-821BE9FB0D2C@macports.org> References: <20071129150356.GA7916@haing4.loria.fr> <71CC6889-D3C2-4AAA-A214-C53FBA31E7AA@apple.com> <8B475581-62E6-4F2A-A7FF-C782CC3B2838@macports.org> <475041AD.8050900@mathiesen.info> <67FAAB0B-084A-475E-A129-DBA425CF05B7@macports.org> <24E9FB8A-B67C-4F0C-832F-CC0A4EE519B1@macports.org> <28F38E93-BCD1-415B-B6EA-821BE9FB0D2C@macports.org> Message-ID: <44EF89F0-72F6-495E-A83D-D755CCEC436F@macports.org> On Dec 2, 2007, at 12:35, Juan Manuel Palacios wrote: >> (2) Supplement this scheme by munging PATH inside the MacPorts >> code to ensure that $prefix is always at the head of the path >> during builds, and to guard against the sort of build problems >> suggested by kvv. > > MacPorts already sets its internal path for a few things, so this > suggestion may be easy to implement but might, just might, have > repercussions that we may want to test more thoroughly (not on the > verge of a release, in my opinion ;-) Yes, just to chime in a bit on that point: I'm rather unhappy about all these changes that appear to be going into 1.6.0 after we've already had two release candidates. That's not what release candidate means. Release candidate means that it is a candidate for release, and if no major problems are found, it will be released as is. It does not mean that we will add lots of other code and then release it, especially not with another release candidate. I don't want another MacPorts 1.4.0--no wait, 1.4.1--no wait, 1.4.2--no wait, 1.4.3. That's exactly what release candidates are supposed to prevent. Ok, if the manpages aren't working on Leopard because of this, then we could fix it. On the other hand, it's equally broken in all previous versions of MacPorts, so we're not introducing any additional breakage, which is what I'm most interested in. New releases of MacPorts should only improve things. Even a little improvement at a time is fine. Introducing major changes to how key parts work, right before a new release of MacPorts, is not to my liking. So my suggestion would be to either leave the path setup the way it is in 1.5.2, let it continue to be broken in Leopard, and think about how best to fix it after release, or to take the (I hope) simpler route of munging MANPATH in addition to PATH, only if MANPATH is set. From ryandesign at macports.org Sun Dec 2 13:58:35 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Dec 2 13:55:35 2007 Subject: [31663] trunk/dports/python/py25-scientific In-Reply-To: <20071202152905.4BD43246EB1@beta.macosforge.org> References: <20071202152905.4BD43246EB1@beta.macosforge.org> Message-ID: <8F79B712-CC4A-4144-B874-3A45ECB7B9D4@macports.org> On Dec 2, 2007, at 09:29, saispo@macports.org wrote: > Revision: 31663 > http://trac.macosforge.org/projects/macports/changeset/31663 > Author: saispo@macports.org > Date: 2007-12-02 07:28:44 -0800 (Sun, 02 Dec 2007) > > Log Message: > ----------- > Fix py25-scientific on Leopard using py25-numeric patch, ticket > #13113 can be closed > > Modified Paths: > -------------- > trunk/dports/python/py25-scientific/Portfile In this commit, you've fixed py25-scientific, but ticket #13113 is about py25-ipython... From jmpp at macports.org Sun Dec 2 14:39:11 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun Dec 2 14:33:24 2007 Subject: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard In-Reply-To: <44EF89F0-72F6-495E-A83D-D755CCEC436F@macports.org> References: <20071129150356.GA7916@haing4.loria.fr> <71CC6889-D3C2-4AAA-A214-C53FBA31E7AA@apple.com> <8B475581-62E6-4F2A-A7FF-C782CC3B2838@macports.org> <475041AD.8050900@mathiesen.info> <67FAAB0B-084A-475E-A129-DBA425CF05B7@macports.org> <24E9FB8A-B67C-4F0C-832F-CC0A4EE519B1@macports.org> <28F38E93-BCD1-415B-B6EA-821BE9FB0D2C@macports.org> <44EF89F0-72F6-495E-A83D-D755CCEC436F@macports.org> Message-ID: <9F377A41-EDC0-45C0-B947-73EEDDA662AC@macports.org> On Dec 2, 2007, at 5:49 PM, Ryan Schmidt wrote: > > On Dec 2, 2007, at 12:35, Juan Manuel Palacios wrote: > >>> (2) Supplement this scheme by munging PATH inside the MacPorts >>> code to ensure that $prefix is always at the head of the path >>> during builds, and to guard against the sort of build problems >>> suggested by kvv. >> >> MacPorts already sets its internal path for a few things, so this >> suggestion may be easy to implement but might, just might, have >> repercussions that we may want to test more thoroughly (not on the >> verge of a release, in my opinion ;-) > > Yes, just to chime in a bit on that point: I'm rather unhappy about > all these changes that appear to be going into 1.6.0 after we've > already had two release candidates. That's not what release > candidate means. Release candidate means that it is a candidate for > release, and if no major problems are found, it will be released as > is. It does not mean that we will add lots of other code and then > release it, especially not with another release candidate. I don't > want another MacPorts 1.4.0--no wait, 1.4.1--no wait, 1.4.2--no > wait, 1.4.3. That's exactly what release candidates are supposed to > prevent. Yes, I agree 100% percent. But please do note that all the changes I merged into the release_1_6 branch since rc2, except for 2, have had nothing to do with MacPorts functionality. Mostly just with the PortIndex2MySQL script (after working with Bill to deploy it on Mac OS Forge), which, on the one hand, I've been testing locally extensively for a really long time and, on the other hand, is something most regular users never even see. Of the two commits that do have to do with MacPorts functionality: *) one is a corner-case bugfix against the "dp2mp-move" upgrade code (paths with spaces embedded in them), which I satisfactorily tested, and *) the other is the path munging work by James Berry, which I'm inclined to remove from the branch. There is yet a third functionality change I'm considering integrating into the release branch, but, again, it's just another bug fix which I asked Anders to put together (through private mail), related to the pkg target (and a rather cosmetic issue for that matter). So all in all, I believe the spirit of RC has been respected. > > So my suggestion would be to either leave the path setup the way it > is in 1.5.2, let it continue to be broken in Leopard, and think > about how best to fix it after release, or to take the (I hope) > simpler route of munging MANPATH in addition to PATH, only if > MANPATH is set. > That's precisely the approach I favored in a previous post of mine to this thread. Regards,... -jmpp From dluke at geeklair.net Sun Dec 2 14:59:49 2007 From: dluke at geeklair.net (Daniel J. Luke) Date: Sun Dec 2 14:56:47 2007 Subject: Meet our new website In-Reply-To: References: <402877A8-CF28-482B-B4E0-F4FA44E00BF2@macports.org> <20071201114806.GB15112@ruderich.com> Message-ID: On Dec 2, 2007, at 12:35 PM, Juan Manuel Palacios wrote: >> It looks great, thanks to all who helped create it. >> >> I found a minor issue. The links to "The Macports Guide" should be >> http://geeklair.net/macports_guide/ as the guide is the same on >> both the >> locations. > > Thanks for pointing this out, Simon, I just corrected it in r31668. It would be good if we could get this moved to macosforge soon (ish) as my machine only has a T1 to the world right now (mostly because I haven't gotten serial console working on it yet, so I don't want to move it further away where I get more bandwidth yet). [Incidentally, if anyone has set up serial console on a G4 with a 'Stealth' serial port adaptor, or something similar, I would appreciate any advise - or even just a note saying that you got it to work at some point]. I can do some clever things to help if access to it becomes an issue before it can get moved, though (proxy from a better-connected machine, move the regen to another machine, and/or just move my machine to where I can get well connected GigE). -- Daniel J. Luke +========================================================+ | *---------------- dluke@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: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071202/ba3cb1bc/PGP.bin From jmpp at macports.org Sun Dec 2 15:13:26 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun Dec 2 15:07:40 2007 Subject: Meet our new website In-Reply-To: References: <402877A8-CF28-482B-B4E0-F4FA44E00BF2@macports.org> <20071201114806.GB15112@ruderich.com> Message-ID: <2B870E37-7700-4E02-B743-C95C5FE43BCF@macports.org> On Dec 2, 2007, at 6:59 PM, Daniel J. Luke wrote: > On Dec 2, 2007, at 12:35 PM, Juan Manuel Palacios wrote: >>> It looks great, thanks to all who helped create it. >>> >>> I found a minor issue. The links to "The Macports Guide" should be >>> http://geeklair.net/macports_guide/ as the guide is the same on >>> both the >>> locations. >> >> Thanks for pointing this out, Simon, I just corrected it in r31668. > > It would be good if we could get this moved to macosforge soon (ish) > as my machine only has a T1 to the world right now (mostly because I > haven't gotten serial console working on it yet, so I don't want to > move it further away where I get more bandwidth yet). Of course Daniel! You have been most kind to host this for us as a trial (and I'm aware it's only a trial and not an "official solution" ;-), and I thank you for that. I'm working with Bill to polish our setup at Mac OS Forge and we both have many entries on our TODO lists, the guide certainly being one of them. I'll try to move it to the top of mine, at least ;-) I thank you again for your continued support to the project! Regards,... -jmpp From jberry at macports.org Sun Dec 2 15:15:26 2007 From: jberry at macports.org (James Berry) Date: Sun Dec 2 15:12:32 2007 Subject: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard In-Reply-To: <9F377A41-EDC0-45C0-B947-73EEDDA662AC@macports.org> References: <20071129150356.GA7916@haing4.loria.fr> <71CC6889-D3C2-4AAA-A214-C53FBA31E7AA@apple.com> <8B475581-62E6-4F2A-A7FF-C782CC3B2838@macports.org> <475041AD.8050900@mathiesen.info> <67FAAB0B-084A-475E-A129-DBA425CF05B7@macports.org> <24E9FB8A-B67C-4F0C-832F-CC0A4EE519B1@macports.org> <28F38E93-BCD1-415B-B6EA-821BE9FB0D2C@macports.org> <44EF89F0-72F6-495E-A83D-D755CCEC436F@macports.org> <9F377A41-EDC0-45C0-B947-73EEDDA662AC@macports.org> Message-ID: <7F48E2ED-0DCA-4868-849B-D2E440063B5B@macports.org> Hi Ryan, On Dec 2, 2007, at 2:39 PM, Juan Manuel Palacios wrote: > On Dec 2, 2007, at 5:49 PM, Ryan Schmidt wrote: >> On Dec 2, 2007, at 12:35, Juan Manuel Palacios wrote: >> >>>> (2) Supplement this scheme by munging PATH inside the MacPorts >>>> code to ensure that $prefix is always at the head of the path >>>> during builds, and to guard against the sort of build problems >>>> suggested by kvv. >>> >>> MacPorts already sets its internal path for a few things, so this >>> suggestion may be easy to implement but might, just might, have >>> repercussions that we may want to test more thoroughly (not on the >>> verge of a release, in my opinion ;-) >> >> Yes, just to chime in a bit on that point: I'm rather unhappy about >> all these changes that appear to be going into 1.6.0 after we've >> already had two release candidates. That's not what release >> candidate means. Release candidate means that it is a candidate for >> release, and if no major problems are found, it will be released as >> is. It does not mean that we will add lots of other code and then >> release it, especially not with another release candidate. I don't >> want another MacPorts 1.4.0--no wait, 1.4.1--no wait, 1.4.2--no >> wait, 1.4.3. That's exactly what release candidates are supposed to >> prevent. > > Yes, I agree 100% percent. But please do note that all the changes > I merged into the release_1_6 branch since rc2, except for 2, have > had nothing to do with MacPorts functionality. Mostly just with the > PortIndex2MySQL script (after working with Bill to deploy it on Mac > OS Forge), which, on the one hand, I've been testing locally > extensively for a really long time and, on the other hand, is > something most regular users never even see. > > Of the two commits that do have to do with MacPorts functionality: > > *) one is a corner-case bugfix against the "dp2mp-move" upgrade code > (paths with spaces embedded in them), which I satisfactorily tested, > and > *) the other is the path munging work by James Berry, which I'm > inclined to remove from the branch. Note please that my addition was a 100% non-code change, to try to fix MANPATH which is 100% broken in Leopard, Ryan, a situation that was not present in Tiger or before. Which isn't to say (as I wrote earlier) that I'm completely happy with the state of things so far, but that we do need to fix this problem before a 1.6 release. James From ryandesign at macports.org Sun Dec 2 15:45:07 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Dec 2 15:42:07 2007 Subject: [31640] trunk/base In-Reply-To: <20071201033215.B1C0D22DFD7@beta.macosforge.org> References: <20071201033215.B1C0D22DFD7@beta.macosforge.org> Message-ID: On Nov 30, 2007, at 21:32, jmpp@macports.org wrote: > The ChangeLog was orignally meant to be a user-parsable file > listing only major changes to base, so that we could > use it in our release process to advertise our new goodies. > Unfortunately, lately it has turned into a litle bit > of a file tracking commits to base, with a little bit of user level > information and a lot of gaps in between to > do either one right, bleh! > > Therefore add a real user-parsable NEWS file in which new features > and bug fixes for each release will be advertised, > starting with the contents of 1.6.0 > > Here's hoping that from now on the ChangeLog will turn into a file > that truly tracks commits to base, with proper revision > numbers for each entry and ticket numbers in case of bug fixes, > after being spared from having to remain user-parsable. Can't people who are interested in that kind of information just read the Subversion log? I don't want to have to bother with updating the ChangeLog every time I change something on base. Granted, it's not that often for me. But for others who make many changes on base, this would seem to be annoying. From jberry at macports.org Sun Dec 2 16:03:28 2007 From: jberry at macports.org (James Berry) Date: Sun Dec 2 16:00:25 2007 Subject: [31640] trunk/base In-Reply-To: References: <20071201033215.B1C0D22DFD7@beta.macosforge.org> Message-ID: <8FA42BAF-2074-4F7F-81C5-7C23382343C7@macports.org> Hi Ryan, On Dec 2, 2007, at 3:45 PM, Ryan Schmidt wrote: > On Nov 30, 2007, at 21:32, jmpp@macports.org wrote: > >> The ChangeLog was orignally meant to be a user-parsable file >> listing only major changes to base, so that we could >> use it in our release process to advertise our new goodies. >> Unfortunately, lately it has turned into a litle bit >> of a file tracking commits to base, with a little bit of user level >> information and a lot of gaps in between to >> do either one right, bleh! >> >> Therefore add a real user-parsable NEWS file in which new features >> and bug fixes for each release will be advertised, >> starting with the contents of 1.6.0 >> >> Here's hoping that from now on the ChangeLog will turn into a file >> that truly tracks commits to base, with proper revision >> numbers for each entry and ticket numbers in case of bug fixes, >> after being spared from having to remain user-parsable. > > > Can't people who are interested in that kind of information just > read the Subversion log? I don't want to have to bother with > updating the ChangeLog every time I change something on base. > Granted, it's not that often for me. But for others who make many > changes on base, this would seem to be annoying. Yes, I basically agree with you. I believe that: (1) The ChangeLog should be developer's best attempt to communicate to the outside world what's happening to base. This is often a somewhat different level of detail from what goes into the subversion commit log. (2) That the ChangeLog should not have too much detail, as otherwise it would simply replicate the svn commit log. Juan says that he may rewrite svn log entries and/or ChangeLog entries into the NEWS file. I'm not sure I would have that much energy in building a release, and would be more apt just to rely on developer's summaries in the ChangeLog file. James From blb at macports.org Sun Dec 2 16:24:32 2007 From: blb at macports.org (Bryan Blackburn) Date: Sun Dec 2 16:21:32 2007 Subject: [31659] trunk/dports/games/freeciv In-Reply-To: References: <20071202024307.6EBE123D78B@beta.macosforge.org> Message-ID: <962A6208-90F8-4549-AE43-4EF0D8FEEDE6@macports.org> On Dec 2, 2007, at 12:48 AM, Ryan Schmidt wrote: > > On Dec 1, 2007, at 20:43, rhwood@macports.org wrote: > >> Revision: 31659 >> http://trac.macosforge.org/projects/macports/changeset/ >> 31659 >> Author: rhwood@macports.org >> Date: 2007-12-01 18:42:54 -0800 (Sat, 01 Dec 2007) >> >> Log Message: >> ----------- >> Add patch from Bryan Blackburn to build if bind9 is present. > > Is there any more information available about this? a ticket? a > discussion somewhere? php5 won't build either if bind9 is present, > and it would be nice to know if this fix for freeciv will help php5 > as well. Thanks. > No ticket, I just sent an email to Randall with the configure patch. As far as php5, are you talking about this error: /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: _res_nclose _res_ninit _res_nmkquery _res_nsend collect2: ld returned 1 exit status It's a different issue from freeciv, but similarly fixed. I'd create a ticket and attach the configure patch (it's larger than the one for freeciv), but I can't seem to find the 'new bug' link anymore on trac. I can send it to you directly (it's 150K). Bryan From ryandesign at macports.org Sun Dec 2 17:26:50 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Dec 2 17:23:50 2007 Subject: [31659] trunk/dports/games/freeciv In-Reply-To: <962A6208-90F8-4549-AE43-4EF0D8FEEDE6@macports.org> References: <20071202024307.6EBE123D78B@beta.macosforge.org> <962A6208-90F8-4549-AE43-4EF0D8FEEDE6@macports.org> Message-ID: On Dec 2, 2007, at 18:24, Bryan Blackburn wrote: > On Dec 2, 2007, at 12:48 AM, Ryan Schmidt wrote: > >> On Dec 1, 2007, at 20:43, rhwood@macports.org wrote: >> >>> Revision: 31659 >>> http://trac.macosforge.org/projects/macports/changeset/ >>> 31659 >>> Author: rhwood@macports.org >>> Date: 2007-12-01 18:42:54 -0800 (Sat, 01 Dec 2007) >>> >>> Log Message: >>> ----------- >>> Add patch from Bryan Blackburn to build if bind9 is present. >> >> Is there any more information available about this? a ticket? a >> discussion somewhere? php5 won't build either if bind9 is present, >> and it would be nice to know if this fix for freeciv will help >> php5 as well. Thanks. > > No ticket, I just sent an email to Randall with the configure > patch. As far as php5, are you talking about this error: > > /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: > _res_nclose > _res_ninit > _res_nmkquery > _res_nsend > collect2: ld returned 1 exit status > > It's a different issue from freeciv, but similarly fixed. I'd > create a ticket and attach the configure patch (it's larger than > the one for freeciv), but I can't seem to find the 'new bug' link > anymore on trac. I can send it to you directly (it's 150K). Yes, that's the one. There's an existing ticket you could attach the patch to: http://trac.macports.org/projects/macports/ticket/11283 Thanks. From jmpp at macports.org Sun Dec 2 17:43:31 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun Dec 2 17:37:47 2007 Subject: propchange - r31680 svn:log In-Reply-To: <20071203012440.EF6D22808B@relay12.apple.com> References: <20071203012440.EF6D22808B@relay12.apple.com> Message-ID: <0D440723-5A4F-43DA-AFF6-F7373A691919@macports.org> On Dec 2, 2007, at 9:24 PM, ryandesign@macports.org wrote: > Author: ryandesign@macports.org The author here needs to be that of the original revision you're editing, I'll work with Bill this coming week to fix that. -jmpp > > Revision: 31680 > Property Name: svn:log > > New Property Value: > Hard wrap and detab HACKING file. Whitespace changes only. From ryandesign at macports.org Sun Dec 2 18:36:40 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Dec 2 18:33:41 2007 Subject: New Ticket button missing Message-ID: <39D99D44-DEFD-4337-BF3A-D23865F7A9F3@macports.org> I can't find the New Ticket button in Trac anymore. Where did it go? From blb at macports.org Sun Dec 2 18:46:56 2007 From: blb at macports.org (Bryan Blackburn) Date: Sun Dec 2 18:43:56 2007 Subject: [31659] trunk/dports/games/freeciv In-Reply-To: References: <20071202024307.6EBE123D78B@beta.macosforge.org> <962A6208-90F8-4549-AE43-4EF0D8FEEDE6@macports.org> Message-ID: On Dec 2, 2007, at 6:26 PM, Ryan Schmidt wrote: > > On Dec 2, 2007, at 18:24, Bryan Blackburn wrote: > >> On Dec 2, 2007, at 12:48 AM, Ryan Schmidt wrote: >> >>> On Dec 1, 2007, at 20:43, rhwood@macports.org wrote: >>> >>>> Revision: 31659 >>>> http://trac.macosforge.org/projects/macports/changeset/ >>>> 31659 >>>> Author: rhwood@macports.org >>>> Date: 2007-12-01 18:42:54 -0800 (Sat, 01 Dec 2007) >>>> >>>> Log Message: >>>> ----------- >>>> Add patch from Bryan Blackburn to build if bind9 is present. >>> >>> Is there any more information available about this? a ticket? a >>> discussion somewhere? php5 won't build either if bind9 is >>> present, and it would be nice to know if this fix for freeciv >>> will help php5 as well. Thanks. >> >> No ticket, I just sent an email to Randall with the configure >> patch. As far as php5, are you talking about this error: >> >> /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: >> _res_nclose >> _res_ninit >> _res_nmkquery >> _res_nsend >> collect2: ld returned 1 exit status >> >> It's a different issue from freeciv, but similarly fixed. I'd >> create a ticket and attach the configure patch (it's larger than >> the one for freeciv), but I can't seem to find the 'new bug' link >> anymore on trac. I can send it to you directly (it's 150K). > > Yes, that's the one. There's an existing ticket you could attach > the patch to: > > http://trac.macports.org/projects/macports/ticket/11283 > > Thanks. > Done; I put an explanation of the basics of what was going on with it, though do note I haven't tested functionality beyond the fact that, without the patch, I get the link error and with the patch, 'make all' succeeds. Bryan From blb at macports.org Sun Dec 2 18:50:48 2007 From: blb at macports.org (Bryan Blackburn) Date: Sun Dec 2 18:47:46 2007 Subject: New Ticket button missing In-Reply-To: <39D99D44-DEFD-4337-BF3A-D23865F7A9F3@macports.org> References: <39D99D44-DEFD-4337-BF3A-D23865F7A9F3@macports.org> Message-ID: On Dec 2, 2007, at 7:36 PM, Ryan Schmidt wrote: > I can't find the New Ticket button in Trac anymore. Where did it go? > So it wasn't just me that was having trouble finding it. Not to mention, when I was looking around for it I went around between trac.macports.org, trac.macosforge.org, and svn.macosforge.org. I think in the process I had to log in two separate times. Bryan From ryandesign at macports.org Sun Dec 2 19:41:20 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Dec 2 20:05:00 2007 Subject: New Ticket button missing In-Reply-To: References: <39D99D44-DEFD-4337-BF3A-D23865F7A9F3@macports.org> Message-ID: <291911CB-EF36-4384-B142-7D98D4DA7408@macports.org> On Dec 2, 2007, at 20:50, Bryan Blackburn wrote: > On Dec 2, 2007, at 7:36 PM, Ryan Schmidt wrote: > >> I can't find the New Ticket button in Trac anymore. Where did it go? > > So it wasn't just me that was having trouble finding it. Right. For now I'm going to https://trac.macports.org/projects/macports/newticket from my browser history. > Not to mention, when I was looking around for it I went around > between trac.macports.org, trac.macosforge.org, and > svn.macosforge.org. I think in the process I had to log in two > separate times. Unrelated issue, but sure. We currently have four URLs for our Trac installation. We should have just one, matching the hostname in the SSL certificate, and have all the other URLs redirect with a permanent status code to the new URL. I would prefer that everything be under www.macports.org but if it must be a different hostname, then so be it. From ryandesign at macports.org Sun Dec 2 19:43:39 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Dec 2 20:40:40 2007 Subject: [31659] trunk/dports/games/freeciv In-Reply-To: References: <20071202024307.6EBE123D78B@beta.macosforge.org> <962A6208-90F8-4549-AE43-4EF0D8FEEDE6@macports.org> Message-ID: On Dec 2, 2007, at 20:46, Bryan Blackburn wrote: > On Dec 2, 2007, at 6:26 PM, Ryan Schmidt wrote: > >> On Dec 2, 2007, at 18:24, Bryan Blackburn wrote: >> >>> On Dec 2, 2007, at 12:48 AM, Ryan Schmidt wrote: >>> >>>> On Dec 1, 2007, at 20:43, rhwood@macports.org wrote: >>>> >>>>> Revision: 31659 >>>>> http://trac.macosforge.org/projects/macports/ >>>>> changeset/31659 >>>>> Author: rhwood@macports.org >>>>> Date: 2007-12-01 18:42:54 -0800 (Sat, 01 Dec 2007) >>>>> >>>>> Log Message: >>>>> ----------- >>>>> Add patch from Bryan Blackburn to build if bind9 is present. >>>> >>>> Is there any more information available about this? a ticket? a >>>> discussion somewhere? php5 won't build either if bind9 is >>>> present, and it would be nice to know if this fix for freeciv >>>> will help php5 as well. Thanks. >>> >>> No ticket, I just sent an email to Randall with the configure >>> patch. As far as php5, are you talking about this error: >>> >>> /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols: >>> _res_nclose >>> _res_ninit >>> _res_nmkquery >>> _res_nsend >>> collect2: ld returned 1 exit status >>> >>> It's a different issue from freeciv, but similarly fixed. I'd >>> create a ticket and attach the configure patch (it's larger than >>> the one for freeciv), but I can't seem to find the 'new bug' link >>> anymore on trac. I can send it to you directly (it's 150K). >> >> Yes, that's the one. There's an existing ticket you could attach >> the patch to: >> >> http://trac.macports.org/projects/macports/ticket/11283 > > Done; I put an explanation of the basics of what was going on with > it, though do note I haven't tested functionality beyond the fact > that, without the patch, I get the link error and with the patch, > 'make all' succeeds. Could you also attach your changes to the config.m4 file and instructions on how to regenerate the configure file? I'll speak with the php developers to see if they can incorporate it upstream, but if not, I have a feeling I may need to regenerate it at every new version of php. From jmpp at macports.org Sun Dec 2 21:14:08 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun Dec 2 21:08:22 2007 Subject: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard In-Reply-To: <24E9FB8A-B67C-4F0C-832F-CC0A4EE519B1@macports.org> References: <20071129150356.GA7916@haing4.loria.fr> <71CC6889-D3C2-4AAA-A214-C53FBA31E7AA@apple.com> <8B475581-62E6-4F2A-A7FF-C782CC3B2838@macports.org> <475041AD.8050900@mathiesen.info> <67FAAB0B-084A-475E-A129-DBA425CF05B7@macports.org> <24E9FB8A-B67C-4F0C-832F-CC0A4EE519B1@macports.org> Message-ID: <3AE3197A-5AAE-4BBA-A3DA-3720F25574AB@macports.org> On Dec 2, 2007, at 2:06 PM, James Berry wrote: > Hi Juan, > > On Dec 2, 2007, at 9:50 AM, Juan Manuel Palacios wrote: >> So, has any conclusion been reached for this issue? I'm inclined >> to backing this feature out of the release_1_6 branch until a >> working consensus is reached, and only release it to the public at >> that time (in 1.6.x (x > 0)). Until now we've only been modifying >> the user "profile" for a range of bourne based shells and the >> "cshrc" file for equivalent C based shells, which has worked fairly >> well, I believe; anyone experienced enough to create something like >> ~/.bash_profile or anything else very shell specific would be savvy >> enough to setup his/her own environment to their content, I'm sure. >> I'd strongly favor sticking to this approach in 1.6.0 until >> something better is found, unless it explicitly breaks expected >> behavior on Leopard. Does it? > > Well, given that man pages are broken at present with a standard > MacPorts install under Leopard, something has to be done. A few > choices: > > (1) Use this scheme, as implemented. (Downsides: affects /etc, > MacPorts paths are added at the end of PATH and MANPATH). > > (2) Supplement this scheme by munging PATH inside the MacPorts code > to ensure that $prefix is always at the head of the path during > builds, and to guard against the sort of build problems suggested by > kvv. > > (3) Modify existing path modification code to also add MacPorts > paths to MANPATH. (This might break other man pages on Tiger where > the system provides no meaningful default for MANPATH?maybe we do it > only if MANPATH is already defined?) > > I've been mulling over this situation for the last week or so, but > haven't done anything because I'm not very happy with any of the > solutions.... I think (3), however is the lowest risk approach. > > James So, using approach number 3) to add our settings to the MANPATH variable on both Tiger and Leopard only if it the latter exists, James and I have two suggestions that we believe work equally well, either one to be added to the base/portmgr/dmg/postflight script: 1) A conditional that would be added to each of the two important cases of the "case $USHELL in" clause: *csh) if $SHELL -lc "/usr/bin/env | grep -q MANPATH" && ! $SHELL -lc "/usr/ bin/printenv MANPATH" | grep -q /opt/local/share/man; then echo "set manpath=(/opt/local/share/man" '$path'")" >> $HOME/.cshrc fi *sh) if $SHELL -lc "/usr/bin/env | grep -q MANPATH" && ! $SHELL -lc "/usr/ bin/printenv MANPATH" | grep -q /opt/local/share/man; then echo "export MANPATH=/opt/local/share/man:\$PATH" >> $HOME/.profile fi With this approach, a static setting is added to the proper files if the conditional matches. 2) No conditional what-so-ever is added to either of the cases, but rather code to test for manpath at shell runtime is output to both cshrc and profile files: *csh) echo "[ -n \"\$MANPATH\" ] && echo \$MANPATH | grep "/opt/local/" > /dev/null && set manpath=(/opt/local/share/man '$path')" >> $HOME/.cshrc *sh) echo "[ -n \"\$MANPATH\" ] && \$(echo \$MANPATH | grep "/opt/local/" >& /dev/null) && export MANPATH=/opt/local/share/man:\$MANPATH" >> $HOME/.profile With this approach, a dynamic check for the variable would be performed upon each shell invocation, but I wouldn't be too sure about the proper escaping needed to get everything through to the files appropriately. So, opinions? Option 1? Option 2? Corrections to either? Something completely different? Regards,... -jmpp From randall.h.wood at alexandriasoftware.com Mon Dec 3 01:38:20 2007 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Mon Dec 3 01:35:33 2007 Subject: New Ticket button missing In-Reply-To: <291911CB-EF36-4384-B142-7D98D4DA7408@macports.org> References: <39D99D44-DEFD-4337-BF3A-D23865F7A9F3@macports.org> <291911CB-EF36-4384-B142-7D98D4DA7408@macports.org> Message-ID: <1700157B-6F5B-4A0D-AE52-82751D8942E3@alexandriasoftware.com> On 2 Dec 2007, at 22:41, Ryan Schmidt wrote: > > On Dec 2, 2007, at 20:50, Bryan Blackburn wrote: > >> On Dec 2, 2007, at 7:36 PM, Ryan Schmidt wrote: >> >>> I can't find the New Ticket button in Trac anymore. Where did it go? >> >> So it wasn't just me that was having trouble finding it. > > Right. For now I'm going to > > https://trac.macports.org/projects/macports/newticket > > from my browser history. See https://svn.macosforge.org/projects/macports/ticket/13457 for a ticket discussing this. >> Not to mention, when I was looking around for it I went around >> between trac.macports.org, trac.macosforge.org, and >> svn.macosforge.org. I think in the process I had to log in two >> separate times. > > Unrelated issue, but sure. We currently have four URLs for our Trac > installation. We should have just one, matching the hostname in the > SSL certificate, and have all the other URLs redirect with a > permanent status code to the new URL. > > I would prefer that everything be under www.macports.org but if it > must be a different hostname, then so be it. Randall Wood randall.h.wood@alexandriasoftware.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From ebgssth at gmail.com Mon Dec 3 06:49:35 2007 From: ebgssth at gmail.com (js) Date: Mon Dec 3 06:47:04 2007 Subject: NEW port request In-Reply-To: References: Message-ID: Both works on my machine. On Dec 3, 2007 12:53 AM, js wrote: > Hi, > > I submitted two new ports, py25-httplib2 and py25-lxml about a week ago, > but I've got no response... > > Could anyone please review these attachment and commit them to svn? > > http://trac.macosforge.org/projects/macports/ticket/13411 > http://trac.macosforge.org/projects/macports/ticket/13393 > From jmpp at macports.org Mon Dec 3 10:10:54 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Mon Dec 3 10:05:19 2007 Subject: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard In-Reply-To: References: <71CC6889-D3C2-4AAA-A214-C53FBA31E7AA@apple.com> <8B475581-62E6-4F2A-A7FF-C782CC3B2838@macports.org> <475041AD.8050900@mathiesen.info> <67FAAB0B-084A-475E-A129-DBA425CF05B7@macports.org> <24E9FB8A-B67C-4F0C-832F-CC0A4EE519B1@macports.org> <3AE3197A-5AAE-4BBA-A3DA-3720F25574AB@macports.org> Message-ID: Hello Marc! On Dec 3, 2007, at 7:28 AM, Marc Andr? Selig wrote: > Let me start out by saying I find this whole business of modifying > users' files without telling them so quite awkward. Please note that all this path & manpath munging, user specific against system wide files modification is only meant to happen from the pkg installer (off of its postfligth script located in svn's base/ portmgr/dmg) which: *) Does warn users in the welcoming ReadMe.rtf file displayed by the installer that their environment will be modified for MacPorts usage; *) As it is aimed at a group of users who either don't want or don't know how to install from source, it is configured in the most standard fashion possible and, as such, it is only meant to work in that situation. If you're experienced enough to modify your system in meaningful ways, such as placing your profile file in a read-only image, then surely you're savvy enough to install from source and setup your own MacPorts environment (no project at all can afford to construct hand-holding installers of their software and instructions for more than a bare couple of usually similar-among-them scenarios). This is also made clear througout the documentation: ReadMe.rtf, website, guide, etc. If you feel we're still not being clear and forthcoming enough about this scenario and assumptions we're presenting the user with, then please feel most free to suggest improvements anywhere you might find them appropriate. > > > On Dec 3, 2007 6:14 AM, Juan Manuel Palacios > wrote: >> *sh) >> if $SHELL -lc "/usr/bin/env | grep -q MANPATH" && ! $SHELL - >> lc "/usr/ >> bin/printenv MANPATH" | grep -q /opt/local/share/man; then >> echo "export MANPATH=/opt/local/share/man:\$PATH" >> >> $HOME/.profile >> fi > > This would fail silently on my account, where ~/.profile is symlinked > to a read-only image under normal circumstances. This is a new instruction that would print further content into the profile file, yes. But note that overall behavior is unchanged: if that fails for you, then the entire postflight script fails because prior to that there are also other instructions printed to the profile. Your "bug report" is not applicable, I'm afraid to say, the postflight script is simply not meant to work with your setup. Nevertheless, as I said above, please feel most free to suggest any improvements you might find appropriate, like some welcomed error catching. > If you don't catch > the error, things would go from "it fails unless you do everything in > the documentation" to "it fails if you do the things in the > (shortened) documentation; read the source if you want to get it > working again". What documentation are you referring to? What's the shortened version that's leaving you in a rather lost state? > I clearly prefer the old variant (more things to do, > but if you do them all, things work) to the new one (it works > magically if your installation is pure standard, but fails in > mysterious ways otherwise). There is no old and new way. We've had this postflight script for a long time already and all we're doing now is enhancing it to fill avoid we're encountering on Leopard (an appropriate setting for MacPorts installed man pages). James' enhancements writing to /etc/ [man]paths.d/ were deferred because they are not yet polished enough for production time, so we're aiming for this alternative through the same postflight script that, if it doesn't work for you now because of the setup you describe, it simply couldn't have worked for you earlier either. Also, magically working on a pure standard scenario but failing unexpectedly on different ones is precisely what the pgk installer and its postflight script are meant to do, that's expected behavior. If you're on the latter crowd, then please install from source. We as a team have not discussed putting together binary installers to cover for other scenarios than the pure standard one. I'm not saying we *wont* do it, but rather that we simply haven't; if we do, then I'm sure mixing its settings/considerations/assumptions with the ones of the pure standard scenario would be a very bad approach. In such case we'd be building two or more completely different and separate installers, each with its own private set of resources. > > > Just the point of view of a mere user. :-) And appreciated! Would love to study whatever enhancement you might propose. > > > Regards, > Marc > > PS: I agree that modifying the local user's preferences is preferrable > to modifying /etc. I still think it needs to be pointed out quite > clearly in the installation manual (i.e. you don't get to shorten the > manual if you do this). Otherwise, everybody who has one account for > each user (plus one account for managing the machine) will not know to > add your stub to the .profile of each user who wants to use MacPorts. Those are interesting documentation enhancements, making it clear that the environment we're setting up will only work on a per user basis. > > > PPS: Another story from the point of view of a mere user: I've had > people apparently locked out from their machine because they had > /opt/local/bin first thing in their PATH and some port had pulled in a > version of sudo that did not work. I've been telling people to put > /opt/local/bin at the end ever since. That should definitely be filed as a bug in our Trac. In fact I think it was and I also think it was fixed, but I don't have any reference to that, sorry. Regards,... -jmpp From macintosh at mathiesen.info Mon Dec 3 22:11:21 2007 From: macintosh at mathiesen.info (Bjarne D Mathiesen) Date: Mon Dec 3 22:10:02 2007 Subject: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard In-Reply-To: <67FAAB0B-084A-475E-A129-DBA425CF05B7@macports.org> References: <20071129150356.GA7916@haing4.loria.fr> <71CC6889-D3C2-4AAA-A214-C53FBA31E7AA@apple.com> <8B475581-62E6-4F2A-A7FF-C782CC3B2838@macports.org> <475041AD.8050900@mathiesen.info> <67FAAB0B-084A-475E-A129-DBA425CF05B7@macports.org> Message-ID: <4754EF89.10300@mathiesen.info> Juan Manuel Palacios wrote: > > On Nov 30, 2007, at 1:00 PM, Bjarne D Mathiesen wrote: > >> How about this: >> I'll amend with this: cp -n /etc/paths /etc/paths.orig >> mkdir -p /etc/paths.d >> mv -n /etc/paths /etc/paths.d/999macosx >> touch /etc/paths >> echo "${prefix}/bin" > /etc/paths.d/000macports >> echo "${prefix}/sbin" >> /etc/paths.d/000macports >> echo "/Developer/Tools" > /etc/paths.d/888developer >> cp -n /etc/manpaths /etc/manpaths.orig >> mkdir -p /etc/manpaths.d >> mv -n /etc/manpaths /etc/manpaths.d/999macosx >> touch /etc/manpaths >> echo "${prefix}/share/man" > /etc/manpaths.d/000macports These two cp commands will keep a backup copy of the original files >> >> If the paths are loaded in alphabetical order, this ought to ensure that >> the macports paths are before the standard Mac OS X ones. >> >> You _do_ want the macport path to be before the standard paths as I >> guess you want to execute the alternative utilities provided by macports >> instaed of those from Mac OS X ;-) > > > Even though prepending our path settings to the environment (rather > than appending them) is what is preferred and what has been proven to > work more smoothly, a hack like what's being proposed above makes me > very uncomfortable. Maybe I'm not sufficiently acquainted with its > simplicity, but a mere glance makes me fearful of many things we could > potentially be breaking. Actually, for that matter, the simple thought > of changing anything in /etc/ is not something I'm not too happy with; > for me that's a "hands off" area of the system... but I'm aware that's > another discussion. Actually, if I understand the situation correctly, the (man)paths.d dirctories _are_ meant to be modified by the sysadmin > > So, has any conclusion been reached for this issue? I'm inclined to > backing this feature out of the release_1_6 branch until a working > consensus is reached, and only release it to the public at that time (in > 1.6.x (x > 0)). Until now we've only been modifying the user "profile" > for a range of bourne based shells and the "cshrc" file for equivalent C > based shells, which has worked fairly well, I believe; anyone > experienced enough to create something like ~/.bash_profile or anything > else very shell specific would be savvy enough to setup his/her own > environment to their content, I'm sure. I'd strongly favor sticking to > this approach in 1.6.0 until something better is found, unless it > explicitly breaks expected behavior on Leopard. Does it? I'm much more unhappy with the proposal for modifying a user's ~/.bash_profile (or the equivalent for other shells) 1) you'll have to test for and modify each and every of these files instead of doing it once at the system level 2) I regard the ~/.bash_profile as a hands-off file much more so than files at the system level. When you install something you _should_ expect that something might change at the system level. But messing around with someone's personal settings ... nope 3) you'll only get it done for the user installing macports. Other users won't get the benefit. 4) we can insert comments in the files we install/modify and use these comments to back out our changes 5) the script I've provided can be run as many times as you want without breaking anything. > > Regards,... > > -jmpp > -- Bjarne D Mathiesen K?benhavn N ; Danmark ; Europa ---------------------------------------------------------------------- denne besked er skrevet i et totalt M$-frit milj? MacOS X 10.5.1 Leopard ; Seamonkey 1.1.x ; PowerPC G4 800MHz From yves at macports.org Tue Dec 4 21:32:40 2007 From: yves at macports.org (Yves de Champlain) Date: Tue Dec 4 21:29:51 2007 Subject: [31434] trunk/dports/x11/gtk2/Portfile In-Reply-To: <20071130190618.GC25807@darkart.com> References: <20071123151649.879B11A06C3@beta.macosforge.org> <20071129200116.GA25807@darkart.com> <20071129235204.GB25807@darkart.com> <0E9A7B2D-4B55-46A4-BDAC-C288000696A7@mac.com> <20071130190618.GC25807@darkart.com> Message-ID: <87413ADC-FC68-433F-AECC-FD4B47162C0B@macports.org> Le 07-11-30 ? 14:06, Eric Hall a ?crit : > On Fri, Nov 30, 2007 at 04:22:12AM -0500, Randall Wood wrote: >> The assumption that a user wants the entire X11 stack installed for >> him is not deterministically true. I will not and can not force a >> user to install X11 if they do not want to. >> > > I agree, we can't (always) know that a user wants X11 intalled. > As Marcus pointed out, there are users who know what they want, > and they tend to be the folks who know what to do to get it (or can > figure it out). There are the other users (which to me includes > the automated builds) that just want it to work(tm). > Perhaps the best compromise would be to have a message pop > up indicating that the gtk2 port is capable of being installed > with +x11 or +quartz (in wording that people understand) and will > default to +x11 in $SECONDS and what to do to stop it and go back > to install with +quartz if that's what they want. If port can also > tell if it is going to go build all of X11 (vs it being installed > already, as is the default for Leopard), that'd be great. > I think this would let people who know and/or are interested > get what they want (+quartz) and also allow automated and "I don't > know/care" installs to succeed. What do you think about this? > Improvements or other ideas? This gtk2 message should indicate clearly that most ports will fail at runtime with +quartz yves From ryandesign at macports.org Wed Dec 5 12:42:11 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Dec 5 12:39:03 2007 Subject: +x11, and +quartz variants (or a dangerous idea) In-Reply-To: <13A130A1-160B-4FC9-AC0F-D46221B19F60@gmx.de> References: <88AFD808-924D-479E-B8ED-DA72EADED196@macports.org> <13A130A1-160B-4FC9-AC0F-D46221B19F60@gmx.de> Message-ID: <38683FC7-ACD4-4EA3-876B-B1D9750D8918@macports.org> On Dec 5, 2007, at 05:55, Wenchieh Yen wrote: > On Dec 1, 2007, at 10:08 AM, Ryan Schmidt wrote: > >> Unless you would like to redefine our default installation goals >> to no longer be "most featureful" but instead be "most featureful >> excluding X11 things". I'm not saying we should or should not >> redefine this, just point out what our current status is, and that >> you seem to be proposing a change to that. >> >> Actually, I guess our current guidelines are to build a port to be >> the most featureful while not including huge libraries as >> dependencies which most users won't want. Thus far, I think we've >> had an unspoken agreement that the X11 features are useful, and >> indeed our installation docs require the user to install X11 and >> the X11SDK. I guess you're proposing a change to that as well. > > The following is a bit off-topic but this "most featureful" > guideline is sometimes annoying for me: Macports is a supporting > package management system and it is source based. It should be > flexible and customizable to indivisual needs (like Gentoo > Portage). Otherwise, we could just have a central build-farm and > provide users with binaries that would just work. We do want to have a central build-farm and provide users with binaries. :) There is a lot of work before we get there, though. We do want to be flexible and customizable too, though, which is why ports have variants. The default should be to have as many features as most users want. Variants are provided for additional features, or to turn off some features that some people don't want. Though usually if you don't want a feature that was built, you just use it. MacPorts philosophy is that disk space is cheap, so the little bit of extra space occupied by the unused features shouldn't really matter. From ryandesign at macports.org Wed Dec 5 15:13:35 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Dec 5 17:00:25 2007 Subject: [31752] distfiles In-Reply-To: <20071205224706.11C582A0490@beta.macosforge.org> References: <20071205224706.11C582A0490@beta.macosforge.org> Message-ID: On Dec 5, 2007, at 16:47, takanori@macports.org wrote: > Revision: 31752 > http://trac.macosforge.org/projects/macports/changeset/31752 > Author: takanori@macports.org > Date: 2007-12-05 14:46:57 -0800 (Wed, 05 Dec 2007) > > Log Message: > ----------- > Add distfile for octave. > > Added Paths: > ----------- > distfiles/octave/ > distfiles/octave/octave-2.9.15.tar.bz2 Why? Just to have an http mirror? Because it's still on the octave ftp server, and they've got releases back to 2.9.0, so I don't think they're going to remove it any time soon. From blair at orcaware.com Wed Dec 5 17:17:23 2007 From: blair at orcaware.com (Blair Zajac) Date: Wed Dec 5 17:17:31 2007 Subject: [31752] distfiles In-Reply-To: References: <20071205224706.11C582A0490@beta.macosforge.org> Message-ID: <47574DA3.4030309@orcaware.com> Ryan Schmidt wrote: > On Dec 5, 2007, at 16:47, takanori@macports.org wrote: > >> Revision: 31752 >> http://trac.macosforge.org/projects/macports/changeset/31752 >> Author: takanori@macports.org >> Date: 2007-12-05 14:46:57 -0800 (Wed, 05 Dec 2007) >> >> Log Message: >> ----------- >> Add distfile for octave. >> >> Added Paths: >> ----------- >> distfiles/octave/ >> distfiles/octave/octave-2.9.15.tar.bz2 > > Why? Just to have an http mirror? Because it's still on the octave ftp > server, and they've got releases back to 2.9.0, so I don't think they're > going to remove it any time soon. Some corporations that I know of do not allow any outgoing FTP, so having an HTTP mirror available is good. Blair -- Blair Zajac, Ph.D. http://www.orcaware.com/svn/ From ryandesign at macports.org Wed Dec 5 18:42:23 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed Dec 5 18:42:33 2007 Subject: [31752] distfiles In-Reply-To: <47574DA3.4030309@orcaware.com> References: <20071205224706.11C582A0490@beta.macosforge.org> <47574DA3.4030309@orcaware.com> Message-ID: On Dec 5, 2007, at 19:17, Blair Zajac wrote: > Ryan Schmidt wrote: >> On Dec 5, 2007, at 16:47, takanori@macports.org wrote: >>> Revision: 31752 >>> http://trac.macosforge.org/projects/macports/changeset/ >>> 31752 >>> Author: takanori@macports.org >>> Date: 2007-12-05 14:46:57 -0800 (Wed, 05 Dec 2007) >>> >>> Log Message: >>> ----------- >>> Add distfile for octave. >>> >>> Added Paths: >>> ----------- >>> distfiles/octave/ >>> distfiles/octave/octave-2.9.15.tar.bz2 >> Why? Just to have an http mirror? Because it's still on the octave >> ftp server, and they've got releases back to 2.9.0, so I don't >> think they're going to remove it any time soon. > > Some corporations that I know of do not allow any outgoing FTP, so > having an HTTP mirror available is good. Right. I was just asking if having an http mirror was the only reason. I'm just very wary of having distfiles in our repository at all. They take up so phenomenally more more space than any code we would ever write, and they can "never" be removed from the repository, so I think we should all think at least 5 times before adding distfiles to the repository. From blair at orcaware.com Wed Dec 5 20:34:35 2007 From: blair at orcaware.com (Blair Zajac) Date: Wed Dec 5 20:34:54 2007 Subject: [31752] distfiles In-Reply-To: References: <20071205224706.11C582A0490@beta.macosforge.org> <47574DA3.4030309@orcaware.com> Message-ID: <47577BDB.7000808@orcaware.com> Ryan Schmidt wrote: > On Dec 5, 2007, at 19:17, Blair Zajac wrote: > >> Ryan Schmidt wrote: >>> On Dec 5, 2007, at 16:47, takanori@macports.org wrote: >>>> Revision: 31752 >>>> http://trac.macosforge.org/projects/macports/changeset/31752 >>>> Author: takanori@macports.org >>>> Date: 2007-12-05 14:46:57 -0800 (Wed, 05 Dec 2007) >>>> >>>> Log Message: >>>> ----------- >>>> Add distfile for octave. >>>> >>>> Added Paths: >>>> ----------- >>>> distfiles/octave/ >>>> distfiles/octave/octave-2.9.15.tar.bz2 >>> Why? Just to have an http mirror? Because it's still on the octave >>> ftp server, and they've got releases back to 2.9.0, so I don't think >>> they're going to remove it any time soon. >> >> Some corporations that I know of do not allow any outgoing FTP, so >> having an HTTP mirror available is good. > > Right. I was just asking if having an http mirror was the only reason. > > I'm just very wary of having distfiles in our repository at all. They > take up so phenomenally more more space than any code we would ever > write, and they can "never" be removed from the repository, so I think > we should all think at least 5 times before adding distfiles to the > repository. We should have another mechanism then for uploading them and storing them on the server. Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From ryandesign at macports.org Thu Dec 6 00:11:34 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Dec 6 00:11:42 2007 Subject: [31752] distfiles In-Reply-To: <47577BDB.7000808@orcaware.com> References: <20071205224706.11C582A0490@beta.macosforge.org> <47574DA3.4030309@orcaware.com> <47577BDB.7000808@orcaware.com> Message-ID: <04116B03-6FF5-4A0B-9E46-F11DF4618AAD@macports.org> On Dec 5, 2007, at 22:34, Blair Zajac wrote: > Ryan Schmidt wrote: > >> I'm just very wary of having distfiles in our repository at all. >> They take up so phenomenally more more space than any code we >> would ever write, and they can "never" be removed from the >> repository, so I think we should all think at least 5 times before >> adding distfiles to the repository. > > We should have another mechanism then for uploading them and > storing them on the server. Old distfiles could be removed from the current repository but it would involve downtime of the Subversion server, and it could involve all the revisions being renumbered, which would mean everyone would have to check out new working copies of everything, which would be a nightmare. We could store distfiles in a completely separate repository so that renumbering of revisions wouldn't affect the main repository. But it's still really the wrong tool for the job. We should just have FTP space where the distfiles can be put and deleted as needed. From ryandesign at macports.org Thu Dec 6 04:05:57 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Dec 6 04:06:09 2007 Subject: Support .dmg disk images as distfiles with new use_dmg option Message-ID: <99264D2B-18F6-49F3-8671-99408B7FFB28@macports.org> I'd like MacPorts to support distfiles in .dmg disk image format, in addition to the .tar.gz, .tar.bz2 and .zip formats currently supported. I spent some time working on this tonight and came up with an implementation that works for me. It's my first bit of hacking in MacPorts base, though, so I'd appreciate any and all feedback, both on the idea and the implementation. Here's the ticket, which includes the patch: http://trac.macports.org/projects/macports/ticket/13509 Thanks. From ebgssth at gmail.com Thu Dec 6 05:50:40 2007 From: ebgssth at gmail.com (js) Date: Thu Dec 6 05:50:41 2007 Subject: No response from ipython's main Message-ID: Hi, I filed a tichet and attached patches but no response is returned. http://trac.macosforge.org/projects/macports/ticket/13459 Someone please check my patches into the svn? From ram at macports.org Thu Dec 6 07:06:44 2007 From: ram at macports.org (Adam Mercer) Date: Thu Dec 6 07:06:45 2007 Subject: Renaming a port Message-ID: <799406d60712060706g37d76cbdh2304a7ab8b927535@mail.gmail.com> Hi I would like to rename the 'bazaar-ng' port to simply 'bzr' to match the name used in most other distributions, the ideal time to do this would be when version 1.0 is released - in a week or two. The new name would also make more sense for ports of various bzr plugins I plan to add. However I don't simply want to rename the port as this will cause problems with people who have the current port installed and may not be aware of the name change. Therefore, in addition to renaming the port, I would like to add a sort of dummy port that alerts the user that the port has been renamed. Is there any infrastructure that I could use, or a recommended approach for this, or would something like the following suffice? PortSystem 1.0 name bazaar-ng version 1.0 categories devel python platforms darwin maintainers ram description The next-generation distributed version control system long_description ${description} pre-fetch { ui_msg "The bazaar-ng port has been renamed to bzr." return -code error "port has been renamed" } Cheers Adam From markd at macports.org Thu Dec 6 08:53:16 2007 From: markd at macports.org (markd@macports.org) Date: Thu Dec 6 08:55:25 2007 Subject: Problem with a Qt application portfile Message-ID: >>>>> I'm trying to port evolvotron: >>>>> >>>>> http://sourceforge.net/projects/evolvotron >>>>> >>>>> It build with qmake. Works in Fink. >>>>> >>>>> So far, I have this: >>>>> >>>>> PortSystem 1.0 >>>>> name evolvotron >>>>> version 0.4.0 >>>>> categories graphics x11 >>>>> platforms darwin >>>>> maintainers nomaintainer@macports.org >>>>> homepage http://sourceforge.net/projects/evolvotron >>>>> master_sites http://downloads.sourceforge.net/evolvotron/ >>>>> checksums md5 ab6f3a3247e36ca0024d3837f78bdf6b >>>>> description "Generative art" image evolver, based on Qt >>>>> long_description "Generative art" software to evolve images/ >>>>> textures/patterns through an \ >>>>> iterative process of random mutation and >>>>> user-selection driven evolution. >>>>> depends_lib port:qt3 >>>>> depends_build port:graphviz port:doxygen >>>>> patchfiles patch-common.pro patch-evolvotron.pro >>>>> worksrcdir ${name} >>>>> configure.args --mandir=${prefix}/share/man >>>>> destroot.destdir INSTALL_ROOT=${destroot} >>>>> configure.env QTDIR=${prefix} INSTALLBASE=${prefix} >>>>> INSTALLPATH=${destroot}${prefix} >>>>> build.env QTDIR=${prefix} INSTALLBASE=${prefix} >>>>> INSTALLPATH=${destroot}${prefix} >>>>> destroot.env QTDIR=${prefix} INSTALLBASE=${prefix} >>>>> INSTALLPATH=${destroot}${prefix} >>>>> > >>>>> I get as far as this: >>>>> >>>>> ---> Fetching evolvotron >>>>> ---> Verifying checksum(s) for evolvotron >>>>> ---> Extracting evolvotron >>>>> ---> Applying patches to evolvotron >>>>> ---> Configuring evolvotron >>>>> ---> Building evolvotron with target all >>>>> ---> Staging evolvotron into destroot >>>>> ---> Packaging tgz archive for evolvotron 0.4.0_0 >>>>> >>>>> And then I get this: >>>>> >>>>> Error: Target org.macports.archive returned: error copying "/opt/ >>>>> local/var/macports/build/ >>>>> _opt_local_var_macports_sources_local_graphics_evolvotron/ >>>>> work/.macports.evolvotron.state" to "/opt/local/var/macports/ >>>>> build/_opt_local_var_macports_sources_local_graphics_evolvotron/ >>>>> work/destroot/+STATE": no such file or directory >>>>> Error: Status 1 encountered during processing. Hi Linc, Because MacPorts uses an intermediate install location phase we call destroot, some poorly written Makefiles do not support DESTDIR or the use of it is not tested. There is no single answer on how to fix it. When possible, if the port author knows how to fix the application's Makefile so that it does work the patch should be contributed upstream. But many times this is not feasible. In this case it appears that evolvotron installs few files (http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/graphics/evolvotron/pkg-plist?rev=1.3;content-type=text%2Fplain), so one option is to just override the destroot phase entirely with your own. Looks like the freebsd port does the same thing. http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/graphics/evolvotron/Makefile?rev=1.16;content-type=text%2Fplain See the Portfile Development Examples in the guide and let us know if you have questions. Also, take a look at the logrotate port (the destroot phase) for an example of using MacPorts instead a Makefile's "make install" to destroot a port. http://geeklair.net/new_macports_guide/#development.examples Also note that scanning the freebsd ports collection (and gentoo, openbsd, and fink) can be a big help in creating MacPorts. But with the possible exception of openbsd, there is no equivalent to destroot, so destroot problems often can't be solved by getting tips from these other package managers. Freebsd must not use the makefile for installation for some other reason. Mark From ryandesign at macports.org Thu Dec 6 15:07:48 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Dec 6 15:14:36 2007 Subject: No response from ipython's main In-Reply-To: References: Message-ID: <0C3A39C2-DB4B-43B8-A325-20631F4774E1@macports.org> On Dec 6, 2007, at 07:50, js wrote: > I filed a tichet and attached patches but no response is returned. > http://trac.macosforge.org/projects/macports/ticket/13459 > > Someone please check my patches into the svn? Looks like jochen did. From ryandesign at macports.org Thu Dec 6 15:14:49 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Dec 6 15:14:55 2007 Subject: Ticket instructions Message-ID: <3D1E337B-4F30-417B-918B-03BC606A49D5@macports.org> So I've been referring people to this URL for instructions on filing tickets: http://trac.macosforge.org/projects/macports/wiki/TracTicketing But that now includes a link to "our official ticketing guidelines" here: http://geeklair.net/new_macports_guide/#project.tickets If the official guidelines are in the guide, can the wiki page content be completely replaced with a link to the guide? Or is there still information in the wiki page that has not been migrated to the guide? (If so, why hasn't it been migrated?) From ryandesign at macports.org Thu Dec 6 15:37:00 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Dec 6 15:43:49 2007 Subject: [31766] trunk/dports/audio/libao In-Reply-To: <20071206192743.1C8D12B3A7A@beta.macosforge.org> References: <20071206192743.1C8D12B3A7A@beta.macosforge.org> Message-ID: On Dec 6, 2007, at 13:27, saispo@macports.org wrote: > Modified: trunk/dports/audio/libao/Portfile > =================================================================== > --- trunk/dports/audio/libao/Portfile 2007-12-06 18:47:51 UTC (rev > 31765) > +++ trunk/dports/audio/libao/Portfile 2007-12-06 19:27:22 UTC (rev > 31766) > @@ -2,8 +2,8 @@ > > PortSystem 1.0 > name libao > -version 0.8.6 > -revision 2 > +version 0.8.8 > +revision 1 Don't change this now, but remember for next time that the first revision of a given port version is 0, not 1. In the future, just remove the revision line when upgrading a port's version to get the default revision of 0. > -patchfiles patch-AU-configure patch-AU- > src__plugins__macosx__ao_macosx.c > +patchfiles patch-configure Patchfiles should be named "patch-whatever.diff". See "port lint". Also, you removed references to some patchfiles, but didn't remove the patchfiles themselves....? From ryandesign at macports.org Thu Dec 6 15:38:38 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Dec 6 15:45:25 2007 Subject: [31764] trunk/dports/net/cacti/Portfile In-Reply-To: <20071206183920.06F072B2B16@beta.macosforge.org> References: <20071206183920.06F072B2B16@beta.macosforge.org> Message-ID: <9D694AE8-3576-42C9-B2BA-D38CD0BEDC43@macports.org> On Dec 6, 2007, at 12:39, markd@macports.org wrote: > -patchfiles tree_console_missing_hosts.patch > +# Placeholder for Cacti official patches > +#patchfiles You removed the reference to the patchfile, but didn't delete the patchfile itself from the files directory...? From ryandesign at macports.org Thu Dec 6 15:46:59 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Dec 6 15:47:06 2007 Subject: Can't find unassigned tickets anymore Message-ID: <141ADE8E-8F4F-4D3A-965B-819932C1CCE4@macports.org> How do I find "unassigned" tickets in Trac now? I used to be able to do a custom query for "Owner is macports- dev@lists.macosforge.org" but that address does not appear in that menu anymore. From ryandesign at macports.org Thu Dec 6 16:17:28 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Dec 6 16:17:36 2007 Subject: ChangeLog, 1.6.0 and trunk versions Message-ID: I'd like to add something into the ChangeLog about the new "port load" and "port unload" commands, implemented in r31500 and fixed in r31771. The ChangeLog lists version 1.5.2's changes, and then above that, we have a whole bunch of changes classified "unreleased". "port load" and "port unload" are not in the 1.6.0 branch. Where do I add information about this to the changelog? And how do we know which of these unreleased changes in the ChangeLog will be released in 1.6.0 and which are still only in trunk? Related: The version of MacPorts in trunk should be updated to 1.7.0 and a 1.7.0 version should be added to Trac so we can file accurate bugs. For example, all the bugs about the missing "cd" command, which are currently assigned to the 1.6.0 version, should be changed to 1.7.0, since 1.6.0 now will have the "cd" command again. From ramercer at gmail.com Thu Dec 6 19:46:11 2007 From: ramercer at gmail.com (Adam Mercer) Date: Thu Dec 6 20:11:12 2007 Subject: tickets mailing list Message-ID: <799406d60712061946o5381e49g38c7e6913b00a13d@mail.gmail.com> Hi Is there a problem with the macports-tickets mailing list? As I've haven't received any emails from it for a couple of days even though there has been ticket activity. Cheers Adam From ryandesign at macports.org Thu Dec 6 18:53:18 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Dec 6 20:13:22 2007 Subject: Final steps for 1.6 In-Reply-To: References: Message-ID: <44A3894E-B2C9-4EBD-9225-B70FD224D7CD@macports.org> On Dec 6, 2007, at 20:45, Juan Manuel Palacios wrote: > My list of outstanding TODOs for the 1.6 release is almost empty > after finishing what I committed in r31774, directly to the > release branch: a rethought and rewritten postflight script to add > PATH and MANPATH settings as appropriate to the user's shell > configuration file. Please read the commit log and test the script, > reporting any findings you have. > > The only things that remain are selectively resyncing the branch > with trunk and updating the proper License.html, ReadMe.rtf and > postflight files in the files dir of the MacPorts port dir, for pkg > installer creation. I plan to use svn:externals off of the release > tag (once I create it) for the latter, rather than needlessly keep > on duplicating those files across the repo. As for the former, > selectively resyncing the release branch and trunk, I think there's > nothing outstanding other than working out the differences between > the postfight script on release and its trunk guise: on release > we're still tweaking user shell configuration files and in trunk > we're discussing James' additions to the /etc/[man]paths.d/ > directories, so those two fronts will likely remain decoupled for > the time being. There's also James' "load" & "unload" new port(1) > targets, which James explicitly requested remain only in trunk > until further tested (which rules out the merger of Ryan's r31771, > which if I understand correctly is a regression fix against the new > targets). Am I correct? Anything I'm missing? > > Thanks for your help in getting 1.6 out ASAP (it's been delayed > enough already ;-). Regards,... Yes, r31771 is just a followup to the initial implementation of port load and port unload in r31500. Let's keep this feature in trunk a little longer, in case more little issues are found. From jmpp at macports.org Thu Dec 6 20:16:50 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu Dec 6 20:13:33 2007 Subject: Ticket instructions In-Reply-To: <3D1E337B-4F30-417B-918B-03BC606A49D5@macports.org> References: <3D1E337B-4F30-417B-918B-03BC606A49D5@macports.org> Message-ID: <3857A615-80EB-45F9-A190-332FA74666A0@macports.org> On Dec 6, 2007, at 7:14 PM, Ryan Schmidt wrote: > So I've been referring people to this URL for instructions on > filing tickets: > > http://trac.macosforge.org/projects/macports/wiki/TracTicketing I amended that so that,.... > > But that now includes a link to "our official ticketing guidelines" > here: > > http://geeklair.net/new_macports_guide/#project.tickets Yes, but I should change the link to plain 'macports_guide', no 'new' moniker. > > If the official guidelines are in the guide, can the wiki page > content be completely replaced with a link to the guide? Or is > there still information in the wiki page that has not been migrated > to the guide? I seem to recall I didn't delete all of that page precisely because there was still some relevant info there that sill hasn't made it into our guide. > (If so, why hasn't it been migrated?) Available time maybe...? ;-) In any case, it is our intention to migrate all our official and "static" documentation to the guide, and prune the Wiki as that happens (which was populated over time with such documentation only because our guide and site were dormant). Any help in that chore will be more than appreciated! ;-) Regards,.... -jmpp From jmpp at macports.org Thu Dec 6 20:17:04 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu Dec 6 20:13:52 2007 Subject: Final steps for 1.6 Message-ID: <32A82EA6-6229-4DD8-867C-DB8FF3E87EC8@macports.org> My list of outstanding TODOs for the 1.6 release is almost empty after finishing what I committed in r31774, directly to the release branch: a rethought and rewritten postflight script to add PATH and MANPATH settings as appropriate to the user's shell configuration file. Please read the commit log and test the script, reporting any findings you have. The only things that remain are selectively resyncing the branch with trunk and updating the proper License.html, ReadMe.rtf and postflight files in the files dir of the MacPorts port dir, for pkg installer creation. I plan to use svn:externals off of the release tag (once I create it) for the latter, rather than needlessly keep on duplicating those files across the repo. As for the former, selectively resyncing the release branch and trunk, I think there's nothing outstanding other than working out the differences between the postfight script on release and its trunk guise: on release we're still tweaking user shell configuration files and in trunk we're discussing James' additions to the /etc/[man]paths.d/ directories, so those two fronts will likely remain decoupled for the time being. There's also James' "load" & "unload" new port(1) targets, which James explicitly requested remain only in trunk until further tested (which rules out the merger of Ryan's r31771, which if I understand correctly is a regression fix against the new targets). Am I correct? Anything I'm missing? Thanks for your help in getting 1.6 out ASAP (it's been delayed enough already ;-). Regards,... -jmpp From jmpp at macports.org Thu Dec 6 20:17:12 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu Dec 6 20:13:55 2007 Subject: Can't find unassigned tickets anymore In-Reply-To: <141ADE8E-8F4F-4D3A-965B-819932C1CCE4@macports.org> References: <141ADE8E-8F4F-4D3A-965B-819932C1CCE4@macports.org> Message-ID: <599408BC-EB03-41B9-80FA-116094673482@macports.org> On Dec 6, 2007, at 7:46 PM, Ryan Schmidt wrote: > How do I find "unassigned" tickets in Trac now? > > I used to be able to do a custom query for "Owner is macports- > dev@lists.macosforge.org" but that address does not appear in that > menu anymore. > The entries in the assignee Trac menu is something I still have to work on with Bill, I've been rather busy this last week so some things have taken a bit of a back seat, I'm sorry to say. It's on my list though! In the mean time, I guess you can construct a manually crafted query such as: http://trac.macports.org/projects/macports/query? owner=macports-dev%40lists.macosforge.org&order=priority That returns all relevant tickets for me, including already closed ones (so maybe some further crafting may be in order to get only open tickets). -jmpp From jmpp at macports.org Thu Dec 6 20:18:14 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu Dec 6 20:14:54 2007 Subject: ChangeLog, 1.6.0 and trunk versions In-Reply-To: References: Message-ID: <7CF9A07D-2535-41E3-BE42-5563789BE154@macports.org> Hello Ryan! On Dec 6, 2007, at 8:17 PM, Ryan Schmidt wrote: > I'd like to add something into the ChangeLog about the new "port > load" and "port unload" commands, implemented in r31500 and fixed > in r31771. > > The ChangeLog lists version 1.5.2's changes, and then above that, > we have a whole bunch of changes classified "unreleased". "port > load" and "port unload" are not in the 1.6.0 branch. Where do I add > information about this to the changelog? And how do we know which > of these unreleased changes in the ChangeLog will be released in > 1.6.0 and which are still only in trunk? I posted about the status of the release_1_6 branch little ago to this list and made a little change to the ChangeLog file in trunk in r31776, indicating the reach of the 1.6.0 release. Basically the only things missing from the release branch are the path settings James is working on and his "load" & "unload" port(1) actions; feel free to add any of that to the "Unreleased" section of the ChangeLog. For a full and classified listing of what will be in 1.6.0 take a look at the NEWS file I recently created. > > > Related: The version of MacPorts in trunk should be updated to > 1.7.0 and a 1.7.0 version should be added to Trac so we can file > accurate bugs. For example, all the bugs about the missing "cd" > command, which are currently assigned to the 1.6.0 version, should > be changed to 1.7.0, since 1.6.0 now will have the "cd" command again. Thanks for the reminder, I'll work on that once 1.6.0 is out. Regards,.... -jmpp From jmpp at macports.org Thu Dec 6 20:31:53 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu Dec 6 20:28:39 2007 Subject: HEADS-UP: Mailing lists possible & sporadic downtime (Was "Re: tickets mailing list") In-Reply-To: <799406d60712061946o5381e49g38c7e6913b00a13d@mail.gmail.com> References: <799406d60712061946o5381e49g38c7e6913b00a13d@mail.gmail.com> Message-ID: On Dec 6, 2007, at 11:46 PM, Adam Mercer wrote: > Hi > > Is there a problem with the macports-tickets mailing list? As I've > haven't received any emails from it for a couple of days even though > there has been ticket activity. > > Cheers > > Adam Yes, our mailing lists server has been having problems lately; they are being worked on. In the mean time, most unfortunately, it's possible for all our lists to experiment sporadic downtime (that we may not be able to anticipate) until the underlaying issues are resolved. I'll keep the group posted about progress on this issue. About the Trac list, however, it's been completely disabled in the past couple of days due to this very problem, please excuse me for failing to announce this. It should be back up now, though (but, again, may still experience unexpected downtime until the entire issue is resolved). Regards,... -jmpp From ryandesign at macports.org Thu Dec 6 22:01:19 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Dec 6 22:28:10 2007 Subject: [31762] trunk/dports/sysutils/memcached/Portfile In-Reply-To: <20071206151543.671B42AEB38@beta.macosforge.org> References: <20071206151543.671B42AEB38@beta.macosforge.org> Message-ID: On Dec 6, 2007, at 09:15, brett@macports.org wrote: > Modified: trunk/dports/sysutils/memcached/Portfile > =================================================================== > --- trunk/dports/sysutils/memcached/Portfile 2007-12-06 14:28:01 > UTC (rev 31761) > +++ trunk/dports/sysutils/memcached/Portfile 2007-12-06 15:15:38 > UTC (rev 31762) > @@ -2,7 +2,7 @@ > > PortSystem 1.0 > name memcached > -version 1.2.2 > +version 1.2.4 > revision 1 Don't do it now, but in the future remember to delete the revision line when upgrading a port's version. The revision should start at zero. From ryandesign at macports.org Thu Dec 6 23:56:44 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu Dec 6 23:56:56 2007 Subject: Final steps for 1.6 In-Reply-To: References: <32A82EA6-6229-4DD8-867C-DB8FF3E87EC8@macports.org> Message-ID: <1672AF30-2829-4CA3-89C4-D90A813DDCB3@macports.org> On Dec 6, 2007, at 22:26, Jordan K. Hubbard wrote: > I'm just curious, and I hope you'll pardon my attack of manager- > ness here, but what [hopefully documented] list of objectives > drives each release? In other words, how do you know when you're > "done" for 1.6 or, perhaps more importantly, 1.7? Is it your > personal TODO list, as you note below, or is there a more global > project TODO list driving the release parameters? Releases seem pretty arbitrary to me. In the case of 1.6, I think the important feature was: - added startupitem.netchange boolean flag (#12931, N_Ox in r30086). because I think we were seeing more of these failures on Leopard, though I haven't seen many lately on the list so maybe that was a false diagnosis. I thought there was another thing we were eager to release but looking through the ChangeLog I'm not reminded what it was. The release of "port lint" is important to me because it means we can finally write that post-commit hook that emails information from "port lint" to commiters and/or maintainers. I know you've argued in the past for abandoning "releases" as such. I guess we're just continuing with the existing strategy for now. From vincent-opdarw at vinc17.org Fri Dec 7 00:53:20 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Fri Dec 7 00:54:01 2007 Subject: Final steps for 1.6 In-Reply-To: <32A82EA6-6229-4DD8-867C-DB8FF3E87EC8@macports.org> References: <32A82EA6-6229-4DD8-867C-DB8FF3E87EC8@macports.org> Message-ID: <20071207085320.GA12545@prunille.vinc17.org> On 2007-12-07 00:17:04 -0400, Juan Manuel Palacios wrote: > My list of outstanding TODOs for the 1.6 release is almost empty after > finishing what I committed in r31774, directly to the release branch: a > rethought and rewritten postflight script to add PATH and MANPATH > settings as appropriate to the user's shell configuration file. Please > read the commit log and test the script, reporting any findings you have. When will this be modified exactly? There's should be a confirmation from the user in any case. FYI, modifying the .profile will not necessarily work with zsh (this is quite complex, see its man page). Also, it's a bad idea to modify $MANPATH as this may break things in particular if the user usually has an empty $MANPATH (in which case the man path is automatically built from $PATH -- this is much better to get consistent paths). -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From ram at macports.org Fri Dec 7 09:23:34 2007 From: ram at macports.org (Adam Mercer) Date: Fri Dec 7 09:23:36 2007 Subject: Unable to install devel/bazaar using base from release_1_6 branch, OK with MacPorts 1.5.2 Message-ID: <799406d60712070923n282487d8t592f70238b07391a@mail.gmail.com> Hi I've been trying to install the devel/bazaar port using base from the release_1_6 branch but the port fails on installation. However If I use the 1.5.2 release of base then devel/bazaar installs without issue. In ticket #13042 [1] the ports maintainer has noticed that the build environment is not being correctly set when using base from the release_1_6 branch, e.g.: DEBUG: Executing org.macports.build (bazaar) DEBUG: Environment: whereas using 1.5.2: DEBUG: Executing org.macports.build (bazaar) DEBUG: Environment: CFLAGS='-g -O2 -Wall -fno-strict-aliasing -I'/opt/local/include' -L'/opt/local/lib' -lintl -lneon -lgpgme -lpth' does anyone know why base from release_1_6 branch is not setting the build environment correctly? Cheers Adam [1] http://trac.macosforge.org/projects/macports/ticket/13042 From jmpp at macports.org Fri Dec 7 09:38:09 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Fri Dec 7 09:34:54 2007 Subject: Final steps for 1.6 In-Reply-To: References: <32A82EA6-6229-4DD8-867C-DB8FF3E87EC8@macports.org> Message-ID: On Dec 7, 2007, at 12