December 2007 - macports-dev - lists.macosforge.org

xinstall examples in guide
by Ryan Schmidt 10 Dec '07

10 Dec '07

In the xinstall section of the new guide, several examples are shown to copy files into "${destroot}${prefix}/share/doc/${name}". nox has been on a mission to make ports install their documentation into "$ {destroot}${prefix}/share/doc/${name}-${version}". Could the examples be changed to that instead?

2 1

Re: [31791] trunk/dports/devel
by Weissmann Markus 10 Dec '07

10 Dec '07

Please do not do this! This will end up in a dead-lock!!! "bzr activate" will wait for "bazaar activate" to finish, which will never happen (as "bazaar install" is waiting for "bzr activate"). Regards, -Markus On 07.12.2007, at 17:05, ram(a)macports.org wrote: > Revision 31791 Author ram(a)macports.org Date 2007-12-07 08:05:11 > -0800 (Fri, 07 Dec 2007) Log Message rename bazaar-ng port to bzr, > automatically upgrade to this new port Modified Paths > trunk/dports/devel/bazaar-ng/Portfile > trunk/dports/devel/bzr/Portfile > Added Paths > trunk/dports/devel/bzr/ > Removed Paths > trunk/dports/devel/bazaar-ng/files/ > Diff > Modified: trunk/dports/devel/bazaar-ng/Portfile (31790 => 31791) > --- trunk/dports/devel/bazaar-ng/Portfile 2007-12-07 15:15:18 UTC > (rev 31790) +++ trunk/dports/devel/bazaar-ng/Portfile 2007-12-07 > 16:05:11 UTC (rev 31791) @@ -1,49 +1,37 @@ # $Id$ PortSystem 1.0 - > PortGroup python25 1.0 name bazaar-ng version 0.92 -revision 3 > +revision 4 categories devel python platforms darwin maintainers > ram openmaintainer -description The next-generation distributed > version control system -long_description Bazaar is an open source > distributed version control \ - system that is powerful, friendly, > and scalable. It manages trees of \ - files and subdirectories, In > particular, it records revisions of trees, \ - representing their > state at a particular point in time, and information \ - about > those revisions and their relationships. Recording and retrieving \ > - tree revisions is useful in several ways if you are writing > software or \ - documents or doing similar creative work. > +description This port has been made obsolete by the bzr port > +long_description ${description} homepage http://bazaar-vcs.org/ - > master_sites ${homepage}releases/src/ -distname bzr-${version} - > checksums md5 f91e760d646660f0f790066ff0526b38 \ - sha1 > 51901b0c467e30dab9e51b990bb491752460d680 \ - rmd160 > f7a6c24944be50c830c25376bfaf0d2b8c56ae56 - -patchfiles patch- > setup.py.diff \ - patch-bzr.dev-r2966.diff \ - patch-bzr.dev- > r2975.diff \ - -depends_lib-append port:py25-paramiko \ - port:py25- > crypto \ - port:py25-hashlib \ - port:py25-zlib \ - port:py25-bz2 - > -test.run yes -test.cmd make -test.target check - -post-destroot > { - xinstall -m 644 -W ${worksrcpath} INSTALL NEWS README TODO \ - $ > {destroot}${prefix}/share/doc/${name} +fetch { + ui_msg "" + ui_msg > "Port bazaar-ng has been superseeded by port bzr" + ui_msg "bzr > will be installed after removing bazaar-ng" + ui_msg "" } +checksum > {} +configure {} +build {} +destroot {} +archive {} +install { + > ui_msg "Removing bazaar-ng" + system "port -f uninstall bazaar-ng" > + ui_msg "Installing bzr" + system "port install bzr" + ui_msg > "Port bzr has been installed" +} +activate {} universal_variant no > Copied: trunk/dports/devel/bzr (from rev 31790, trunk/dports/devel/ > bazaar-ng) > Modified: trunk/dports/devel/bzr/Portfile (31790 => 31791) --- > trunk/dports/devel/bazaar-ng/Portfile 2007-12-07 15:15:18 UTC (rev > 31790) +++ trunk/dports/devel/bzr/Portfile 2007-12-07 16:05:11 UTC > (rev 31791) @@ -3,9 +3,8 @@ PortSystem 1.0 PortGroup python25 1.0 - > name bazaar-ng +name bzr version 0.92 -revision 3 > categories devel python platforms darwin maintainers ram > openmaintainer @@ -21,7 +20,6 @@ homepage http://bazaar-vcs.org/ > master_sites ${homepage}releases/src/ -distname bzr-${version} > checksums md5 f91e760d646660f0f790066ff0526b38 \ sha1 > 51901b0c467e30dab9e51b990bb491752460d680 \ > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes --- Dipl. Inf. (FH) Markus W. Weissmann http://www.mweissmann.de/ http://www.macports.org/

4 4

Doubled slashes in master_sites
by Ryan Schmidt 10 Dec '07

10 Dec '07

It's a common occurrence that you'll see something like this while fetching a port: $ sudo port install python24 ---> Fetching python24 ---> Attempting to fetch Python-2.4.4.tar.bz2 from http:// www.python.org//ftp/python/2.4.4/ ^C $ Note the double slash after the hostname, which should just be a single slash. This is not a major problem, because the server still responds and delivers the desired file. But it's not 100% correct, and I'm a stickler for perfection, so here we go. The problem comes about because of these definitions in the portfile: homepage http://www.python.org/ master_sites ${homepage}/ftp/python/${version}/ The homepage ends with a slash, as it definitely should. But then the port author has defined master_sites with a slash after the homepage variable, which should not have been done. The correct definiton for master_sites would be: master_sites ${homepage}ftp/python/${version}/ I fix this in open ports when I see it and send patches to the maintainers of closed ports. In response to one such patch, Markus suggested that MacPorts base should automatically fix this. I suppose there is precedent, insofar as MacPorts will fix master_sites to end with a slash, if it does not already. I'm not sure if I'd be in favor of automated stripping of doubled slashes within URLs. It introduces a bit of magic into the master_sites variable, and I think magic should be avoided. And theoretically, a server could behave differently depending on the number of slashes. In practice, though, Apache collapses doubled slashes into a single one, and I don't know of any sites that would rely on double slashes in their download URLs. What do you all think?

2 2

Document variant description in guide (was: [31848] trunk/dports)
by Ryan Schmidt 10 Dec '07

10 Dec '07

On Dec 10, 2007, at 00:09, ryandesign(a)macports.org wrote: > Log Message: > ----------- > Remove extra space before and after variant descriptions, because > this shows through in the output of "`port variants`". We need to document variant descriptions in the guide. There doesn't appear to be much on that now. It needs to say that all variants should have a description, except for platform "variants" and other MacPorts-provided variants (only "universal", I guess), for which MacPorts base should be providing descriptions (but currently doesn't; we don't need to document that but we do need to fix this in base). It should say that the variant description should be short but clear, and ideally not merely repeat the name of the variant. It should say that the syntax can be either variant bar description {foo} {...} or variant bar description "foo" {...} but that with "foo" one will need more quoting / escaping than with {foo}. (Or maybe there should be a general section of the guide describing these two different kinds of strings; then the variant description section can just say that the variant description is any valid kind of string.) It should say that because the variant description is a string, one should take care not to put whitespace between the brackets or quotation marks and the beginning and end of the variant description, and also to watch whitespace within the description. This is in contrast to the port description and long_description, which aren't strings in that sense (what are they?) and don't have these whitespace constraints. If we provide recommendations for the wording of the variant description, my recommendation would be to write it as a sentence fragment, with a capitalized first letter but no trailing punctuation, and to think of the variant description as a radio button or checkbox label. (Envision a GUI installation mechanism for MacPorts in which variants are shown as checkboxes (for variants that stand alone) or radio buttons (for a set of variants which are mutually exclusive (using the "conflicts" syntax)).) Thus, it would be better to write "Build with support for foo" instead of "Builds with support for foo"; "Add support for foo" would be better than "Adds support for foo".

1 0

Please commit openssh breakage on Leopard patch on ticket 13046
by Mark Evenson 09 Dec '07

09 Dec '07

openssh on Leopard is broken as reported and fixed in ticket [13046][1], but the commit seems stalled over confusion of the proper maintainer. Can someone please promote this to the correct party? [1]: http://trac.macports.org/projects/macports/ticket/13046

2 1

Final steps for 1.6
by Juan Manuel Palacios 09 Dec '07

09 Dec '07

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

2 4

Re: [31806] trunk/dports/security/afflib/Portfile
by Ryan Schmidt 08 Dec '07

08 Dec '07

On Dec 7, 2007, at 23:41, ricci(a)macports.org wrote: > Revision: 31806 > http://trac.macosforge.org/projects/macports/changeset/31806 > Author: ricci(a)macports.org > Date: 2007-12-07 21:41:46 -0800 (Fri, 07 Dec 2007) > > Log Message: > ----------- > add a pre-destroot step to copy over the lib and include files If this changes the complement of files that get installed by the port, you should increment the revision so anyone who had the previous complement of files gets informed of the update. > Modified Paths: > -------------- > trunk/dports/security/afflib/Portfile > > Modified: trunk/dports/security/afflib/Portfile > =================================================================== > --- trunk/dports/security/afflib/Portfile 2007-12-08 04:25:07 UTC > (rev 31805) > +++ trunk/dports/security/afflib/Portfile 2007-12-08 05:41:46 UTC > (rev 31806) > @@ -33,7 +33,19 @@ > --with-ssl=${prefix} \ > --with-zlib=${prefix} > > +pre-destroot { > + ## install things that don't get automatically installed (say, > libs, headers...) > + ## really the auto* stuff needs to be reworked, below is a band-aid > + xinstall -d ${destroot}/${prefix}/lib > + xinstall -m 0644 ${worksrcpath}/lib/.libs/libafflib.a ${destroot}/ > ${prefix}/lib/ > + xinstall -d ${destroot}/${prefix}/include/${name}/lib > + foreach header [glob ${worksrcpath}/lib/*.h] { > + xinstall -m 0644 $header ${destroot}${prefix}/include/${name}/lib > + } > + xinstall -m 0644 ${worksrcpath}/config.h ${destroot}${prefix}/ > include/${name}/ > +} There shouldn't be a slash between ${destroot} and ${prefix}. ($ {prefix} already begins with a slash.)

2 1

Re: [31804] trunk/base/portmgr/jobs
by Juan Manuel Palacios 08 Dec '07

08 Dec '07

Hey Bill! On Dec 7, 2007, at 11:14 PM, wsiegrist(a)apple.com wrote: > Revision > 31804 > Author > wsiegrist(a)apple.com > Date > 2007-12-07 19:14:52 -0800 (Fri, 07 Dec 2007) > Log Message > > added explicit paths to rm and tclsh in order to run without a > PATH. PortIndex2MySQL.tcl now relies on tclsh being in /opt/local/bin Since we're safeguarding these scripts for proper functioning within launchd, wouldn't it also help abstracting the paths to the `mkdir` and `ln` commands away into their own variables too for the mprsyncup script? I think PortIndex2MySQL is already bullet proof, as you already removed the environment reliance for the tcl shell and all other external commands are already abstracted, I think. Regards,... -jmpp

1 0

Re: [31739] trunk/dports/x11/gtk2/Portfile
by Randall Wood 08 Dec '07

08 Dec '07

ALCON: For GTK2, I have restored the default behavior of installing for X11. At some point it would be nice to be able to provide a nice transition from using X11 as the default for GTK to using Aqua as the GTK default, but we are not at that point yet (I thought we were closer than I now think we are to that point). There are three possible installation states for GTK2: 1. gtk2+x11 2. gtk2+quartz with X11 on the Mac 3. gtk2+quartz without X11 on the Mac State 1 is the state that almost all upstream developers expect, State 3 works if no X11 APIs is used in upstream development other than gtk+, and State 2 just simply breakslots of stuff horribly. Unfortunately, since OS X 10.5 ships with X11 installed by default, State 3 is not easily reached on 10.5, leaving State 1 as the only reliably working state. Hence the decision to make that the default state. On 12/5/07, rhwood(a)macports.org < rhwood(a)macports.org> wrote: > > Revision 31739<http://trac.macosforge.org/projects/macports/changeset/31739> > Author rhwood(a)macports.org Date 2007-12-05 02:13:18 -0800 (Wed, 05 Dec > 2007) Log Message > > Upgrade to 2.12.3 > Clarify variant failure message > Make the +x11 variant default > > Modified Paths > > - trunk/dports/x11/gtk2/Portfile<#116aeed633ea0c92_116a9cd0b6c2e8b4_trunkdportsx11gtk2Portfile> > > Diff Modified: trunk/dports/x11/gtk2/Portfile (31738 => 31739) > > --- trunk/dports/x11/gtk2/Portfile 2007-12-05 09:34:22 UTC (rev 31738) > +++ trunk/dports/x11/gtk2/Portfile 2007-12-05 10:13:18 UTC (rev 31739)@@ -4,7 +4,7 @@ PortSystem 1.0 name gtk2-version 2.12.2+version 2.12.3 set branch [join [lrange [split ${version} .] 0 1] .] categories x11 maintainers rhwood openmaintainer@@ -25,9 +25,9 @@ distname gtk+-${version} checksums \- md5 a789a8a333d418f47cda1dba106d9aac \ > - sha1 495ff3ef09de44cc23718239967203bd7871b4aa \ > - rmd160 b5cd6b7ec6abf557a6f82c707e0eafb67c813f8d + md5 dc8455144f27945f2fcbe91e75acd118 \ > + sha1 5af5ab069c49189abf223b25736c254da047c712 \ > + rmd160 5da22ae4ac257bd2fcefbe2f374e92b6b0dbcc85 use_bzip2 yes @@ -48,10 +48,11 @@ port:render \ port:zlib +default_variants +x11 pre-fetch { if { ![variant_isset quartz] && ![variant_isset x11] } {- return -code 1 "\n\nThe gtk2 port can be built and installed with support for either Quartz\n(Aqua) rendering or X11 rendering, but not both.\n\nPlease install the gtk2 port by running either:\n\t\"port install gtk2 +quartz\" or\n\"port install gtk2 +x11\"\n\n" + return -code 1 "\n\nThe gtk2 port can be built and installed with support for either Quartz\n(Aqua) rendering or X11 rendering, but not both.\n\nPlease install the gtk2 port by running either:\n\t\"port install gtk2 +quartz\" or\n\t\"port install gtk2 +x11\"\n\nIf you are upgrading a port and see this message, use the X11 variant.\n\n" } if {[variant_isset quartz]} { if { ![file exists ${prefix}/include/cairo/cairo-quartz.h] } { > > > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes > > -- Randall Wood randall.h.wood(a)alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

1 0

Unable to install devel/bazaar using base from release_1_6 branch, OK with MacPorts 1.5.2
by Adam Mercer 08 Dec '07

08 Dec '07

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

2 2