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

Re: A 1.4 release / Insall MacPorts of different drive
by Mark Duling 20 Feb '07

20 Feb '07

"Daniel J. Luke" <dluke(a)geeklair.net> on Tuesday, February 20, 2007 at 1:03 PM -0800 wrote: >> I think this issue has been broached before, but as it is still >> ongoing, I'd like to raise it up again. I'd like to install >> MacPorts on a different drive other than my boot-up drive. The >> current version of DarwinPorts-1.3.1 lets me select the disk to >> install on, but does not run properly after installation. > >If you build/install from source, you should be able to get a working >macports install wherever you want it. > >> Can this be fixed in the next release? Actually, I was hoping that >> MacPorts would be even more location-independent. I would like to >> install MacPorts on a network drive under Mac OSX Server which >> shares its available ports and libraries with client OSX machines >> on the network. I'm not sure how much effort or re-organization of >> the files involved, but is this a feature that others would find >> worthwhile as well? > >Our installer should probably limit installation to the boot drive so >that things 'just work' (while alternative install locations are >supported/available with the source install). Oh I see my question about http://trac.macosforge.org/projects/macports/ticket/7534 has been addressed in this parallel thread. Also, I'll see if I can stick some verbiage in the README installer .dmg file to warn people about trying to install into other than /opt/local with the .dmg installer, since I am guessing no actuial installer changes will be made for this point release. http://trac.macosforge.org/projects/macports/ticket/11010 Mark

1 0

X11prefix ignored?
by Juan Manuel Palacios 20 Feb '07

20 Feb '07

Hello again guys! In looking into completing some of our documentation (Cf. "Undocumented ports.conf options" thread) I ran into the dportinit proc in base/src/darwinports1.0/darwinports.tcl and noticed that the x11prefix option is not initialized in it. And for that matter, neither is ${prefix}, but I know that one is autoconfiscated. Looking further I found and old ticket, http://trac.macports.org/projects/macports/ticket/3073, claiming that setting x11prefix in ports.conf indeed does not work. Is x11prefix autoconfiscated too? Does that preclude setting those variables as customizable options in ports.conf? I can easily see how dangerous tweaking ${prefix} once MP is already installed can be, I see that variable as an "adjust once only" one (therefore autoconfiscated) and as such I'm thinking we should even remove it from ports.conf... unless something needs to read it off that file at runtime. What gives? 1) Can/should we remove prefix from ports.conf? 2) Can/should we make x11prefix customizable from ports.conf? 3) In case the answer to the latter is "don't touch it, autoconfiscation takes care of it and it shouldn't be tweaked thereafter!", then question 1) applies to x11prefix as well. Anyone care to comment? Sorry for cc'ing you explicitly Landon, please don't write that filtering rule to send my messages directly to the trash ;-) Thanks for the help! -jmpp

1 0

Undocumented ports.conf options
by Juan Manuel Palacios 20 Feb '07

20 Feb '07

Hello guys! I'm going over some more documentation in my quest to advance on the 1.4 release, and I have some question for you guys about some undocumented options in the porsts.conf file. What exactly do the following do? -) porttrace: sets trace mode on by default, no need to pass -t? -) portverbose: kinda self explanatory, but I wasn't able to figure out what verbosity level is enabled, -v or -d? -) xcodeversion & xcodebuildcmd: Xcode related block in base/src/darwinports1.0/darwinports.tcl is rather involved, so I wasn't able to gather much information on these.... On the other hand: -) destroot_umask: already have it documented locally, will commit shortly; -) libpath & autopath: should we document these? The former seems rather dangerous to me and the latter.. well, I don't understand what it does but since it plays with libpath... Thanks for the info! Regards,... -jmpp

3 5

New Port: Slrn-devel
by Sbranzo 19 Feb '07

19 Feb '07

Just a head-up for a new port submitted a while ago: http://trac.macports.org/projects/macports/ticket/11299 Gufo

2 3

New Port: gtk2-extra
by Anant Narayanan 19 Feb '07

19 Feb '07

Hi! I'm new to this list; and so I don't know what the actual procedure for introducing a new port is. Nevertheless, I am attaching the Portfile for x11/gtk2-extra. GtkExtra is a set of useful widgets for Gtk+. The port for gtk-extra (corresponding to Gtk+1) was already present; I just had to change the version numbers and update the MD5. If Matthew is not available or is unwilling to maintain this port; I would be glad to do so. Best Regards, -- Anant # $Id: Portfile 20497 2006-11-03 15:49:13Z blair(a)macports.org $ PortSystem 1.0 name gtk2-extra version 2.1.1 categories x11 devel platforms darwin maintainers matthew.c(a)rogers.com description Extra GTK+2 Widgets long_description GtkExtra is a useful set of widgets for creating \ GUI's for the Xwindows system using GTK+2. You can \ use it complementary to GTK+ and it is written in \ C. It is also Free Software and released under the \ LGPL license. homepage http://gtkextra.sourceforge.net master_sites sourceforge:scigraphica distname gtk+extra-${version} depends_lib lib:libgtk.2:gtk2 checksums gtk+extra-2.1.1.tar.gz md5 1a933ca1286829383a0554cc2deb9e04 pre-configure { # Copy new versions of config.guess and config.sub for host detection set src_dir ${portpath}/${workdir}/${name}-${version} system "cp /usr/share/automake-1.6/config.guess ${src_dir}" system "cp /usr/share/automake-1.6/config.sub ${src_dir}" }

2 2

committer's guide / portfile author's guide
by mel 19 Feb '07

19 Feb '07

Hi all, Macports (and mac os x) newbie here. I'm trying my hands at writing portfile, just a few questions: 1) Besides the NewCommittersGuide, is there any other documents that I can use as a guide, such as 'Port Author's Guide' which lay out things like quality, ensuring that portfiles aren't broken, consistency, etc? 2) When developing my own portfile, how do I go about setting my own 'development' environment? I.e. I don't want to clutter the current port tree, and I want to be able to remove/install ports easily. Regards, --mel

2 1

Re: New Port: gtk2-extra
by Ryan Schmidt 18 Feb '07

18 Feb '07

On Feb 18, 2007, at 14:56, Elias Pipping wrote: > On Feb 18, 2007, at 9:51 PM, Ryan Schmidt wrote: > >> I guess the MacPorts copy command isn't available until MacPorts >> 1.4? so "system cp ... ..." is still the best way to copy >> something? Once MacPorts makes the copy command available, I >> suppose that would be safer than direct system calls. > > what about tcl's 'file copy'? Oh, ok. I didn't know (or I forgot) that existed. I'm not a tcl expert at all. I just noticed that a "copy" command was added to portutil.tcl in MacPorts trunk, and that it isn't in the 1.3.2 source, so I assume it's better in some way than file copy.

1 0

Re: [22092] trunk/dports/python
by Weissmann Markus 18 Feb '07

18 Feb '07

On 18.02.2007, at 18:08, Jyrki Wahlstedt wrote: > On 18.2.2007, at 0.15, Weissmann Markus wrote: > >> On 17.02.2007, at 17:42, Yves de Champlain wrote: >> >>> Le 07-02-17 à 11:32, Yves de Champlain a écrit : >>> >>>> Le 07-02-17 à 11:18, source_changes(a)macosforge.org a écrit : >>>> >>>>> Revision 22092 Author mww(a)macports.org Date 2007-02-17 08:18:26 >>>>> -0800 (Sat, 17 Feb 2007) Log Messagenew port py25-bz2 - python >>>>> 2.5 bindings to bzip2 >>>> >>>> I am a bit confused. Python 2.5 is presented as current >>>> production version on python.org, but these commits make it look >>>> like a special case. Is there some sort of problem with python >>>> 2.5 on Mac ? Or is this a problem with how python is managed in >>>> MacPorts ? >>> >>> Just let me be a little more precise : could there be py24-* and >>> py25-* ports for python ports that use a specific PortGroup and >>> py-* ports for python packages that don't use a PortGroup ? >>> >> >> No, I'd rather say we leave the py- prefix for 2.4 and use py25- >> for python 2.5; >> We could rename all py- ports to py24- but that'll probably more >> of a headache than just leaving them like this. >> > Hi, > I'm not totally comfortable with this. It is inconsistent to use > ports bound to specific version, unless there is really some very > definite reason to do it (like with posgresql having different > binary formats with different versions). Users who want the latest > version, expect to find it with the name they have used, nobody > wants to dig new names with versions attached to them. Engineers > might find it easier to use such names, but engineers should make > users' lives as easy as possible, not to create obstacles. > This isn't about engineers vs. users. The not-so-smart user you picture would not even care about specific python modules, but just about some software that might use this module. And it wouldn't bother him if this piece of software uses python 2.4 or 2.5. The problem is, that python 2.4 and 2.5 are _not_ compatible. A user will note care if a program uses python 2.4 or 2.5, but most programmers and port developers will be pissed if python modules show up randomly either in python 2.4 or 2.5 (or elsewhere). -Markus --- Markus W. Weissmann http://www.mweissmann.de/

1 0

Port submision
by Andrea Cimino 18 Feb '07

18 Feb '07

I have written a port for the Parma Polyhedra Library (http://www.cs.unipr.it/ppl) (http://www.cs.unipr.it/cgi-bin/viewvc/viewvc.cgi/ppl/DarwinPorts_Portfile?r…) How can i submit the port? I have read the Darwinports submission rules but they seem to be outdated. Can you give me some hints? Best regards, Andrea Cimino

3 3

Re: [22096] trunk/dports
by Juan Manuel Palacios 18 Feb '07

18 Feb '07

On Feb 17, 2007, at 2:19 PM, source_changes(a)macosforge.org wrote: > Revision > 22096 > Author > yves(a)macports.org > Date > 2007-02-17 10:19:56 -0800 (Sat, 17 Feb 2007) > > Log Message > Rename PRICE to PRICE-aqua to avoid name collision with gnustep PRICE, > move it in aqua directory > upgrade Portfile to xcode group and current version 0.8.1 Just a friendly reminder: actions like these should state explicitly in the commit log (and elsewhere if possible, like trac tickets for instance) that the maintainer has granted his/her blessing (I spoke to mww and he told me such was the case for this one), even if it is just to avoid misunderstandings. Other than that, nice move! Regards,... -jmpp

1 0