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

Problem: Macports on Leopard, cannot selfupdate
by Stellit Woo 28 Oct '07

28 Oct '07

I just switch my system to Leopard and I also need Macports same as in tiger. There is no problem during the installation. But when I selfupdate Macports, it says I do not have an acceptable C compiler. Following is the error message what I got Stellit:~ stellit$ sudo port -f selfupdate Password: MacPorts base version 1.5 installed Downloaded MacPorts base version 1.520 Configuring, Building and Installing new MacPorts base Error: /opt/local/bin/port: selfupdate failed: Error installing new MacPorts base: shell command "cd /opt/local/var/macports/sources/ rsync.macports.org/release/base && ./configure --prefix=/opt/local -- with-install-user=root --with-install-group=admin --with-tclpackage=/ Library/Tcl && make && make install" returned error 1 Command output: checking build system type... powerpc-apple-darwin9.0.0 checking host system type... powerpc-apple-darwin9.0.0 checking target system type... powerpc-apple-darwin9.0.0 checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: no acceptable C compiler found in $PATH See `config.log' for more details. Regards, Stellit

2 1

Project naming
by Juan Manuel Palacios 27 Oct '07

27 Oct '07

Easy, easy! This is not another project rename endeavor nor another host migration, relax and breathe easy now! ;-) It is, however, a call to standardize the name string we use to identify this project we work on. We are "MacPorts", sure... but, actually, that's really the name of the software we make and love ;-) There are any number of iterations of that string (plain & flat "MacPorts", "The MacPorts Team", "The MacPorts Organization", "The MacPorts Group", who-knows-what-else) strewn out all over our sources, documentation and web pages whenever it comes to identifying "us", the group that works on putting together that "MacPorts" software. Even though this mess is not a project life threatening issue, it certainly does not help to consolidate an identity... or at least that of a non-schizophrenic software project! So on behalf of exactly that, our project identity, I would like to ask all of us to standardize on a single name string whenever there's a need to identify our group : "The MacPorts Project". Not too formal -- we're not a legal entity--, not too informal -- we are definitely serious about our work! As a Portmgr petition, I would like to ask you all to start using this name when crediting our organization in whatever work you do for the project. Also, as a side note, a couple of guidelines for work crediting and copyright attribution: 1) If you contribute a new software module and/or a new source file in an existing module of our project, and you can attribute all that work to yourself, then please by all means credit yourself in the file (s) headers with a copyright notice (or notices in case more than one individual participated). Among other things, this helps us to quickly find all those that were involved in creating whatever source file. One exception to this guideline should probably be our Portfiles, since those are partly meant for human eyes consumption and we should keep the boilerplate (comment cruft) to a minimum. 2) If you instead contribute a sizable patch to an existing source file (either a bug fix or feature enhancement), then also feel free to attribute yourself a copyright notice on the file header. An exception for this second guideline should be when doing small things like simple code refactoring, whitespace cleanups, one/two-liner bug fixes, etc... Crediting all of these is in my opinion unnecessary and would create unmanageable file headers, among other things. 3) If this work in which you credit yourself is uploaded to the "base" component of our repository, then you are clearly *contributing* it to the project. Therefore, a credit line for the project itself, with our standardized name of course, is desirable. If you are more versed on the legal aspects of licensing and the sort than us, and you find anything that may feel uncomfortable in our petitions, then by all means feel free to raise your concerns. But in any case lets please try to stick to the spirit outlined here, thank you! Regards to all and thank you for your help and support! -jmpp, on behalf of Portmgr

1 0

Re: [30293] trunk/dports/lang/clisp
by Ryan Schmidt 26 Oct '07

26 Oct '07

On Oct 23, 2007, at 18:45, source_changes(a)macosforge.org wrote: > Revision: 30293 > http://trac.macosforge.org/projects/macports/changeset/30293 > Author: eridius(a)macports.org > Date: 2007-10-23 16:45:28 -0700 (Tue, 23 Oct 2007) > > Log Message: > ----------- > Update clisp 2.42, and at the same time make significant changes so > this will actually build under Leopard > > Modified Paths: > -------------- > trunk/dports/lang/clisp/Portfile > > Removed Paths: > ------------- > trunk/dports/lang/clisp/files/ > > Modified: trunk/dports/lang/clisp/Portfile > =================================================================== > --- trunk/dports/lang/clisp/Portfile 2007-10-23 22:46:03 UTC (rev > 30292) > +++ trunk/dports/lang/clisp/Portfile 2007-10-23 23:45:28 UTC (rev > 30293) > @@ -1,10 +1,11 @@ > # $Id$ > > PortSystem 1.0 > + > name clisp > -version 2.40 > +version 2.42 > categories lang > -maintainers nomaintainer > +maintainers eridius openmaintainer > platforms darwin > description The Clisp Common Lisp Implementation > long_description \ > @@ -21,9 +22,9 @@ > homepage http://clisp.cons.org/ > master_sites gnu:clisp/release/${version} \ > sourceforge > -checksums sha1 4e64b3d04c91b16bc2626f5d89938dbcd4d71a56 > +checksums md5 3fc28342e446a62c1eb4f65277929888 \ > + sha1 4c39a5549d2821b1d5ab1cfca172527e9053af1c > use_bzip2 yes > -patchfiles patch-documentation.lisp > > depends_lib port:readline \ > port:gettext \ > @@ -41,82 +42,74 @@ > } > > platform darwin 6 { > - ui_msg "clisp is not supported on Jaguar (OS X 10.2.x)" > - exit 1 > + throw UNSUPPORTED "clisp is not supported on Jaguar (OS X 10.2.x)" > } [snip] Hm! I've never seen "throw" in a portfile before. Interesting. Seems to work though. (I made a minor fix in r30386). Is "throw" how we should be handling unsupported platforms? What else should we be throwing, instead of 'return -code error "message"' which is what I thought was recommended before?

2 1

New port submission: py-memcached
by Derek Harland 26 Oct '07

26 Oct '07

* My first port submission :-) * Port submitted under ticket #12987. des.

2 1

startupitem.pidfile options
by markd＠macports.org 25 Oct '07

25 Oct '07

James, I don't fully understand the startupitem.pidfile options. I think I've got the documentation improved for startupitems, but like to improve it some more. Here are the current new docs on the options: ------------------------------- Pidfile handling options: none - The daemon is not to use a pidfile. auto - The daemon generates its own pidfile. manual - The daemon never generates a pidfile; the StartupItem must manage the pidfile on its own. clean - The daemon generates its own but will not delete it; the StartupItem must delete it. --------------------------------- Question 1) I have a startupitem that creates the pidfile like this: 'startupitem.start "${nedimonitorbin} & echo \$! > ${nedimonitorpid}"' I thought "manual" would be the best option. But "manual" deleted my pidfile when launchctl executed. Why would that be? Also, it sets "<string>--pid=exec</string>" in the .plist. Is this correct? I had to use the "clean" option, and it works fine, but I don't understand why "manual" worked as it did, or why "clean" works since it says "the startupitem must delete it" and mine doesn't. Should the docs say "daemondo must delete it", instead of "StartupItem must delete it"? Question 2) none - This means that pidfile startupitem.pidfile disabled, correct? Same as not using the startupitem.pidfile keyword at all. auto - This option deletes the pidfile as well, correct? clean - "The daemon generates its own but will not delete it; the StartupItem must delete it". Why must implies the pid file should be deleted. Why? Mark

2 5

daemondo is not restarting processes that die
by markd＠macports.org 25 Oct '07

25 Oct '07

Daemondo is not restarting a process for me that dies. I am sure it is tracking the script's pid correctly (using startupitem.pidfile) and I have setup logging to verify all this. At first I did not have the startupitem pidfile configured properly and daemondo kept starting more instances of the daemon, which was a good sign to me that it was looking for the pidfile, using it, and might in fact restart a process that died. But after fixing the startupitem.pidfile properly, if I kill the script (to simulate the script dying abnormally) daemondo never restarts it. Or is kiling it using the Unix kill command a valid test? Is there a bug in daemondo? It isn't behaving as the main.c comments (or our documentation) say it should. I have never explicitly tested it before, and I'm not sure anyone else has either so it seems like a bug. Mark

2 6

Re: [30348] distfiles/yves/gtk-nodoka-engine-0.6.tar.gz
by Juan Manuel Palacios 25 Oct '07

25 Oct '07

On Oct 25, 2007, at 8:11 AM, source_changes(a)macosforge.org wrote: > Revision > 30348 > Author > yves(a)macports.org > Date > 2007-10-25 05:11:55 -0700 (Thu, 25 Oct 2007) > Log Message > > gtk-nodoka distfile > Added Paths > > distfiles/yves/gtk-nodoka-engine-0.6.tar.gz Hello Yves! It is now our standard to upload source drops to directories named on a $portname basis, not our user names as as we were doing before. Can you please move this and adapt the Portfile accordingly? Thanks! Regards,... -jmpp

1 0

emacs top-level category
by N_Ox 25 Oct '07

25 Oct '07

Hi, Following r30144 and r30145, can i create a top-level emacs category? I think I'm going to add some more emacs packages, i don't want to pollute the editors category. Regards, -- Anthony Ramine, the infamous MacPorts Trac slave. nox(a)macports.org

4 5

Re: [30338] trunk/base
by Ryan Schmidt 25 Oct '07

25 Oct '07

On Oct 25, 2007, at 01:50, source_changes(a)macosforge.org wrote: > Revision: 30338 > http://trac.macosforge.org/projects/macports/changeset/30338 > Author: afb(a)macports.org > Date: 2007-10-24 23:50:15 -0700 (Wed, 24 Oct 2007) > > Log Message: > ----------- > issue warning for old versions of Mac OS X and Xcode > > Modified Paths: > -------------- > trunk/base/configure > trunk/base/configure.ac > > Modified: trunk/base/configure > =================================================================== > --- trunk/base/configure 2007-10-25 05:25:18 UTC (rev 30337) > +++ trunk/base/configure 2007-10-25 06:50:15 UTC (rev 30338) > @@ -2096,6 +2096,25 @@ > echo "${ECHO_T}$MACOSX_VERSION" >&6; } > fi > > +case "$MACOSX_VERSION" in > + 10.0*|10.1*|10.2*) > + { echo "$as_me:$LINENO: WARNING: This version of Mac OS X is > not supported" >&5 > +echo "$as_me: WARNING: This version of Mac OS X is not supported" > >&2;} > + { echo "$as_me:$LINENO: WARNING: Please upgrade at http:// > store.apple.com/" >&5 > +echo "$as_me: WARNING: Please upgrade at http://store.apple.com/" > >&2;} > + ;; > + 10.1.[0-4]|10.2.[0-7]|10.3.[0-8]|10.4.[0-8]) > + { echo "$as_me:$LINENO: WARNING: This version of Mac OS X is > out of date" >&5 > +echo "$as_me: WARNING: This version of Mac OS X is out of date" >&2;} > + { echo "$as_me:$LINENO: WARNING: Please run Software Update to > update it" >&5 > +echo "$as_me: WARNING: Please run Software Update to update it" >&2;} [snip] Shouldn't 10.4.9 be indicated as out-of-date too? We're currently on 10.4.10.

2 3

port disaster
by Jyrki Wahlstedt 25 Oct '07

25 Oct '07

For some reason yesterday, as I was doing 'port selfupdate; port outdated' that is quite routine for me, I ended up with error message saying something like: port installed failed, list element ended with } instead of space (the exact wording escapes me at the moment). However, the result is that I am informed I have no ports installed! Probably I have to install all ports again from scratch, which takes time that could be used more productively and is a RPITA?! How could this kind of situation be avoided or if disaster hits, how could the ports be restored? The problem is to find all packages that are installed and active, and to find the configuration (i.e. variants) used to build them. I'd hope a new selfupdate could solve the problem, but I am not optimistic. not a happy man at the moment, ! ! Jyrki Wahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386

3 3