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

Re: [27578] trunk/dports/devel/libsdl
by Juan Manuel Palacios 09 Aug '07

09 Aug '07

On Aug 8, 2007, at 6:24 PM, source_changes(a)macosforge.org wrote: > + exit 1 > + } > + Calling exit from a Portfile has been more than deprecated, it's unsupported at present (or at least will be in 1.5.1). There's now code in macports1.0 that hides 'exit' from the Tcl interpreter that loads the Portfiles 'cause its use introduces many problems we want to avoid. Recommended practice is to use 'return -code error "your error message here"' Regards,... -jmpp

2 1

Re: [27578] trunk/dports/devel/libsdl
by Ryan Schmidt 08 Aug '07

08 Aug '07

On Aug 8, 2007, at 17:24, source_changes(a)macosforge.org wrote: > Revision: 27578 > http://trac.macosforge.org/projects/macports/changeset/27578 > Author: nox(a)macports.org > Date: 2007-08-08 15:24:43 -0700 (Wed, 08 Aug 2007) > > Log Message: > ----------- > * Port cleaned! > * Updated to version 1.2.11 > * The check for QuickTime version on Panther is now in native TCL. > * Configure patch has been replaced by a single reinplace procedure > call. > * Added sha1 and rmd160 checksums. > * Added documentation. > * Taken over (with openmaintainer). > > Modified Paths: > -------------- > trunk/dports/devel/libsdl/Portfile > > Removed Paths: > ------------- > trunk/dports/devel/libsdl/files/patch-configure > trunk/dports/devel/libsdl/files/qt-check.sh [snip] > platform darwin 7 { > - pre-fetch { system "/bin/bash ${portpath}/${filesdir}/qt-check.sh" } > + pre-fetch { > + set qt_header [open /System/Library/Frameworks/ > QuickTime.framework/Headers/QuickTime.h r] > + > + while {[gets $qt_header line] != -1} { > + if {[regexp {Version:} $line]} { > + regexp {(\d+)\.(\d+)$} $line _ qt_min qt_rev > + > + if {$qt_min > 0 || $qt_rev > 3} { > + ui_error "" > + ui_error "Installation of libSDL is exiting > because it believes you have" > + ui_error "QuickTime version 7.${qt_min}.$ > {qt_rev} installed." > + ui_error "" > + ui_error "On Mac OS 10.3/XCode 1.5, you must > have QuickTime 7.0.3 or lower if" > + ui_error "you want to install the libSDL port." > + ui_error "" > + ui_error "If you have QuickTime 7.0.4, you can > downgrade to 7.0.1:" > + ui_error "http://www.apple.com/support/ > downloads/quicktime701reinstallerforquicktime704.html" That URL is 404. I can't find any place to download QT 7.0.1 from Apple anymore. If Apple has not fixed this problem in the several versions of QT since 7.0.4, Apple must not believe it is a bug. Has anyone attempted to contact the libsdl developers about this problem, or checked their bug database?

1 0

Port submission - InsightToolkit take 2
by Peter Schmiedeskamp 08 Aug '07

08 Aug '07

Eek, I just noticed that I unwittingly submitted an HTML formatted e-mail to a mailing list. Many apologies. Since it looks like the content was blocked, I'll try this again: I recently needed to install the InsightToolkit (http://www.itk.org) and thought it best if I took the opportunity to build up a MacPort for it. I'm attaching a copy of the Portfile (loosely based on the VTK port) in hopes that folks can: 1. Point out any errors I've made. 2. Help me out with how to make a new submission. (Sorry if I missed this on the website somewhere) Best, Peter

3 3

Re: [27561] trunk/dports/devel/codeblocks-devel/Portfile
by Ryan Schmidt 08 Aug '07

08 Aug '07

On Aug 8, 2007, at 07:37, source_changes(a)macosforge.org wrote: > Revision: 27561 > http://trac.macosforge.org/projects/macports/changeset/27561 > Author: afb(a)macports.org > Date: 2007-08-08 05:37:25 -0700 (Wed, 08 Aug 2007) > > Log Message: > ----------- > - update to SVN rev 4361+ etc > - fix broken default_variants > - fix broken depends_lib too > > Revision Links: > -------------- > http://trac.macosforge.org/projects/macports/changeset/4361 > > Modified Paths: > -------------- > trunk/dports/devel/codeblocks-devel/Portfile > > Modified: trunk/dports/devel/codeblocks-devel/Portfile > =================================================================== > --- trunk/dports/devel/codeblocks-devel/Portfile 2007-08-08 > 12:11:07 UTC (rev 27560) > +++ trunk/dports/devel/codeblocks-devel/Portfile 2007-08-08 > 12:37:25 UTC (rev 27561) > @@ -19,7 +19,7 @@ > > fetch.type svn > svn.url svn://svn.berlios.de/codeblocks/trunk > -#svn.tag 4261 > +#svn.tag 4361 > worksrcdir trunk [snip] ...why is the svn.tag command commented out?

1 0

Re: Trac tickets
by Simon Ruderich 08 Aug '07

08 Aug '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Gabriel O'Brien wrote: > This seems reasonable to me, my only question as the maintainer is > what is the process to update the patchfile if required? Should I > just open a ticket with the diff or is there something else that > should be done to directly update the file? > > cheers, > Gabriel Yes, the Trac way is the preferred one. Open a ticket and attach the patch. Then someone with subversion access will checkin this change. If the ticket seems forgotten because no one fixed it yet then send an email to macports-dev(a)lists.macosforge.org and it will be taken care of. Hope this helps, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGuaSyYRX4BO+zMikRCvwkAJ4ggeDPquP/kjuQbUXVTyVrdiV7GgCgymbK SKSzBzPHcGbkOFlo/3163gE= =SaIY -----END PGP SIGNATURE-----

1 0

Trac tickets
by Simon Ruderich 08 Aug '07

08 Aug '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, because I recently said that there are fixes in Trac which aren't noticed I just started collecting them to help the developers with svn access. Here is an (incomplete) list of tickets which should be ready for checkin. (I'm also CCing the maintainers of the ports which have one.) + http://trac.macports.org/projects/macports/ticket/12068 Patch for +universal builds fine on my Intel MacBook, but fails on my PowerPC iMac. But the non universal build works fine on both. So I think the patch should be submitted to svn. + http://trac.macports.org/projects/macports/ticket/12207 Patch submitted to update to newest version, fixes the bug. + http://trac.macports.org/projects/macports/ticket/12364 Patch works fine for me. + http://trac.macports.org/projects/macports/ticket/12368 portfile worked for me but I added a patch which also downloads the data file and so lets the user directly use raceintospace without doing anything else. + http://trac.macports.org/projects/macports/ticket/11895 My fix for the portfile could also be added. But there seems to be an error in macports with build.env which should be checked. + http://trac.macports.org/projects/macports/ticket/11802 portfile works for me. But I think the configure.env line is not necessary anymore; I also don't know if port:python24 is really necessary. I created a portfile before I found this and it worked without python24. + http://trac.macports.org/projects/macports/ticket/11509 portfile installs fine for me, I don't have any application which uses it so I can't say for sure it works. + http://trac.macports.org/projects/macports/ticket/12203 Fix for the portfile (there was a new release). Also added a patch for the mplayer portfile as suggested by the ticket. Thanks for your help, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGsLAmYRX4BO+zMikRCrqWAJ95hIHWPNuuDrsyfPU9OzixG73P9wCgjsrj 2vnV8ElWGbGouKm7qwNR63M= =P3fp -----END PGP SIGNATURE-----

4 9

Documentation terminology change
by markd＠macports.org 08 Aug '07

08 Aug '07

I'm trying to clarify conceptually what MacPorts is and how it works in the new guide. In the old guide the term "initialization phase" is used for what I think we may commonly refer to this as the "global section" of a portfile. http://geeklair.net/macports_guide/ch04.html#id927488 I don't like the term "initialization phase" because it seems counterintuitive for many keywords such as "maintainer", "description", etc. I prefer to call those "global" keywords, thereby disguishing between the global port/Portfile stuff and port/Portfile installation phases. Seen that way the global part is not termed an installation phase at all and I like the separation conceptually. I think this is more clear and more or less clearly explains the murky relationship between a port and a Portfile. To see how I have explained it, see the brief intro in section "Portfile Introduction" in 4.1 of the new guide. http://geeklair.net/macports_guide/ Does anyone see any problem with this characterization? Mark

2 1

Port submission - InsightToolkit
by Peter Schmiedeskamp 07 Aug '07

07 Aug '07

Hello, I recently needed to install the InsightToolkit (http://www.itk.org) and thought it best if I took the opportunity to build up a MacPort for it. I'm attaching a copy of the Portfile (loosely based on the VTK port) in hopes that folks can: 1. Point out any errors I've made. 2. Help me out with how to make a new submission. (Sorry if I missed this on the website somewhere) Best, Peter

1 0

Re: depends_lib, depends_build, depends_run, oh my
by Ryan Schmidt 07 Aug '07

07 Aug '07

On Aug 6, 2007, at 17:37, Mark Duling wrote: > Kevin Van Vechten writes: > >>>> Why do we have depends_lib, depends_build and depends_run? Why not >>>> just a single "depends"? Why does it matter which phase requires >>>> the >>>> other software? Isn't it enough to know that the other software is >>>> required at some point, and so MacPorts should install that other >>>> software first? >> >> Depends_build dependencies are only needed if you're actually >> building the software. They're not needed at all once the software >> is built and installed. (Think of gcc). >> >> Depends_run dependencies are needed when the software is run, but not >> necessarily to build the software. (Think of a program that does a >> fork/exec of /usr/bin/foo at runtime). >> >> Depends_lib dependencies are needed both at build time (for headers >> and libraries to link against) and at run time (to provide necessary >> code). >> >> For binary packages, you'd only need to consider depends_lib + >> depends_run. Even for those building their own software, it makes >> sense to distinguish since it gives a better sense of what uninstalls >> might break (i.e. gcc is a depends_build for most projects, but >> uninstalling it wouldn't interfere with many ports operation). > > Thanks, Kevin. I'll review this more closely in a bit and document > it in > the new guide. Curiously, even though I fixed the four ports I had installed that required pkgconfig to list it as a build dependency instead of a library, "port uninstall" still won't let me uninstall pkgconfig, saying those four ports depend on it. Oh, I see, I have to reinstall those four ports first. So, for the documentation, another consequence is: if you try to "port uninstall" something, it will prevent you from doing so if any port depends on it via depends_lib, but doesn't complain if a port depends on it via depends_build (and I don't know about depends_run).

1 0

Updated port commit request: ufraw to 0.12. Fixes ticket 12308
by Frank McPherson 07 Aug '07

07 Aug '07

ufraw has been upgraded to ufraw-0.12 upstream. There was a slight problem with building the new version, easily fixed by adding a small patch. The patches for the source file and Portfile are attached to the ticket, http://trac.macports.org/ projects/macports/ticket/12308. Could someone with commit access please commit these changes and close this ticket? Thanks, Frank

2 1