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

Helping new ports and fixes into MacPorts
by Steve Purcell 16 Mar '07

16 Mar '07

Hi all, I submitted a new Portfile to Trac, and wondered by what process it might (hopefully) go from an Enhancement there to the main port archive. There's a guide for new committers, but nothing similar for new maintainers/contributors. The ticket in question is this one: http://trac.macosforge.org/projects/macports/ticket/11551 Also, I believe I fixed a defect in a further ticket, but have no means of reassigning that ticket to the maintainer of the port in question (mww): http://trac.macosforge.org/projects/macports/ticket/9043 Best wishes, -Steve -- http://www.sanityinc.com/ - Software For a Saner World http://www.looktothestars.org/ - Celebrity Charity News & Information http://sproglogs.com/ - Better Baby Blogs

2 3

MacPorts 1.4 rc2
by Juan Manuel Palacios 15 Mar '07

15 Mar '07

Hello everyone! I just tagged 1.4.0-rc2 and posted corresponding test tarballs and checksums to our downloads directory. Those of you keeping track of svn commits should know about the changes that took place since rc1, those of you that don't please be patient, I'll update the ChangeLog as I get a chance through out the day. In any case, there have been changes to the release_1_4 branch so getting some testing on rc2 would be good! Just the same, if anything comes up please file a ticket in trac and assign it to the "MacPorts 1.4" milestone, base component (forwarding the ticket number to this list, thanks!). Does anyone have any compelling reason why I should keep the rc1 tarballs around...? I'm inclined to deleting them. Final 1.4 release shouldn't be too far now (famous last words! ...just kidding ;-). Regards and thanks to all for your help,... -jmpp

6 17

Students: MacPorts approved for Google Summer of Code 2007
by James Berry 15 Mar '07

15 Mar '07

I'm very pleased to announce that MacPorts has been selected by Google as an organizational member of Google Summer of Code 2007. This means that students may apply to work on MacPorts projects through the Summer of Code program sponsored by google. Compensation for completion of a project is $4500 to the student, and $500 to MacPorts. I can say that I, and the other members of the MacPorts portmgr team and community, are excited by this opportunity to improve MacPorts while also welcoming new contributors to the MacPorts ecosystem. For more information, please see the MacPorts tracking page for summer of code: http://trac.macosforge.org/projects/macports/wiki/ SummerOfCode. We encourage qualified and interested students to apply! James

1 0

Re: Pallet
by Guido Soranzio 15 Mar '07

15 Mar '07

Randall Wood <rhwood(a)mac.com> wrote: > Is the old dp_cocoa code available anywhere? You can still download it from here: <http://opendarwin.org/~matt/PortsManager.tbz2> <http://opendarwin.org/~matt/dp-cocoa.tbz2>

1 0

port outdated is acting funny
by Yves de Champlain 14 Mar '07

14 Mar '07

Hi I am working on e17 stuff and here is what happened after installing evas 0.9.9.037 while the Portindex refenrence is still at 0.9.9.010 : Bilbo:~/macports/dports yves$ port outdated The following installed ports are outdated: evas 0.9.9.037_0 < 0.9.9.010_0 yves

4 4

Re: [MacPorts] #10682: BUG: New Install Won't Work on MBP (Problem with Pextli
by Mark Duling 14 Mar '07

14 Mar '07

When you say "installed Aqua/Tk", do you mean this? http://tcltkaqua.sourceforge.net/ If there are good reasons to do install this package (isn't it kinda old?), then we have a known issue that could be written up on the Wiki. Also, there is a problem with MacPorts Tk +aqua variant. http://trac.macports.org/projects/macports/ticket/8730 Is using MacPorts Tk +aqua a good idea? If a small blurb could be constructed to generalize whats going on with Tk and aqua in general for MacPorts users, I'd put it on the Wiki. Mark noreply(a)macosforge.org on Tuesday, March 13, 2007 at 4:40 PM -0800 wrote: >My problem was related to issue > [http://trac.macports.org/projects/macports/ticket/11401 11401]. Below is > the assistance I got on #macports which solved my problem. > > > {{{ > [8:06pm] mrevoir: I've been having problems on my MacBook Pro ever since >I > did a self update to 1.3.1 with "Failed to initialize ports system, can't > find package Pextlib 1.0". I was able to extract that file from the >bundle > as suggested in the mailing list, but then I was unable to build most > packages due to vm_allocate errors. I tried installing MacPorts >1.4.0-rc1, > but it too can't find Pextlib, even though pkgIndex.tcl and Pextlib.dylib > are in /opt/local/share/darwinports/Tcl/pextlib1.0/. Does anyone have any > suggestions? I've tried both DarwinPorts 1.2.1 and 1.3.1 from the > installers. > [8:24pm] Eridius: mrevoir: I bet you have the same problem someone else > did > [8:24pm] Eridius: you installed Aqua/tk didn't you? > [8:24pm] Eridius: apparently it's not generating the package index for > pextlib properly (if you examine it, it just contains comments) > [8:24pm] Eridius: the trick is to uninstall Aqua/tk, rename > /usr/bin/tclsh8.4.7 to tclsh8.4 (not necessary, but that's what the >apple- > provided one looks like), and symlink /usr/bin/tclsh to it > [8:25pm] mrevoir: Eridius: Thanks, I'll give that a shot. > [8:38pm] mrevoir: Eridius: You're correct that the package index was > empty. I have 8.4, 8.4.7 and 8.5 installed. tclsh was symlinked to > tclsh8.4. Symlinking it to 8.4.7 made it work. Thanks! > }}}

2 1

Re: [22707] trunk/dports/sysutils
by Randall Wood 13 Mar '07

13 Mar '07

ALCON: This morning I placed some code in the MacPorts subversion repository for a GUI for MacPorts. The GUI is currently named Pallet. I'll write an explanation of the name later. The code is at https://svn.macosforge.org/repository/macports/users/ rhwood/Pallet Please feel free to check it out, run it, fix it, and commit the fixes or submit tickets (assigned to rhwood(a)macports.org) against it. There is a portfile for Pallet, and it checks out, builds, and installs, but fails to run. Status: * Crashes on start when run outside xcode. * Can only run port sync or port selfupdate as of now. * Does not know the status of ports. * Displays incomplete and truncated port information. * Really really immature. * Needs new application icon. * Log output needs formatting for legibility. * Gets confused when a port has a zero-length or missing long_description (I think I fixed all 3 ports that caused this problem--since the long_description is a required field per man portfile) Randall Wood rhwood(a)mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

2 1

Trac Roadmap milestones
by Juan Manuel Palacios 13 Mar '07

13 Mar '07

Evening everyone! Recently I started using Trac's Roadmap facility (thanks to Kevin's push!) and created two initial milestones, one for our upcoming 1.4 release and one for 1.5. Any problems you might encounter with the 1.4 rc I posted last week should be filed in tickets assigned to the corresponding milestone (base component). The 1.5 milestone will probably hold tickets detailing project goals that might coincide with our SoC2007 application, if we get elected, of course (but, in any case, all of that is still a bit up in the air, nothing written on stone just yet). Just now I also created two trial milestones that are open for testing and improvements. One is for new port submissions: http://trac.macports.org/projects/macports/milestone/New%20Ports Needless to say, tickets requesting the inclusion of a particular port(s) into our tree, whether the ticket is just a petition or a proposal full with an attached Portfile, should be assigned to that milestone. The other milestone is for bug reports and/or enhancement requests against ports we already carry: http://trac.macports.org/projects/macports/milestone/Available%20Ports Any ticket filed against a port already in our tree should be put there, again whether the ticket is just a petition or a proposal including a patch. Please feel free to suggest improvements to these two last milestones, including their names and descriptions, at the moment they're just bare bones (born only 5 minutes ago). Also, feel free to suggest new milestones that could help refine trac & ticket queries. I'm guessing a balance is in order, a good number of milestones to fine grain our roadmap, but not too many as to make it easy to get lost in it. Once we have things pinned down somewhat, I'll encourage *all* of us with trac access ('cause no one single person can accomplish such an undertaking) to start moving existing tickets into their corresponding milestones. Lastly, please refrain from assigning port specific tickets to MacPorts release milestones, base sources and the ports tree are two different things and from an organizational point of view tickets for each are best kept separate, thank you! Regards to all and thank you in advance for your feedback! -jmpp

1 0

Commit patch to john / Commit rights
by Jann Röder 13 Mar '07

13 Mar '07

Hello, could someone commit the patch to the john ports in this ticket please: http://trac.macports.org/projects/macports/ticket/11526 If possible I'd like to have commit rights. I hate it, if tickets in the tracker are not taken care of. I'm currently maintaining the following ports: - Eiffelstudio - mico - ldns - drill and have provided patches to several others. Cheers Jann

1 0

Homegrown destroot, maybe chroot?
by Ryan Schmidt 13 Mar '07

13 Mar '07

This question isn't about using MacPorts but about how MacPorts does something that I want to do elsewhere. How does it do the destroot phase? I have some software I would like to build. It happens to be Graphviz. There are a dozen other packages on which Graphviz depends. Ultimately they need to go into a location under /usr/local which would require root access, but I would like to build them in a user- writable temporary location first. If I'm not mistaken, MacPorts accomplishes its destroot phase by using, usually make install DESTDIR=/foo where /foo is the destroot directory of the work directory. The software gets installed in /foo/opt/local/whatever. Then, later, during the install phase, everything from /foo gets merged with the real /opt/local. Right? Right. What if I have multiple packages I want to install in the temporary directory before installing? Say I want to install libpng, which depends on zlib. But if zlib is only in the temporary destroot directory, the libpng build won't find it there when I've told it the dependencies are to be found in /usr/local. And if I instead tell libpng to link with zlib in the temporary destroot, won't that be the location where libpng forever looks for zlib, even after I've tried to install everything in /usr/local? Is there a way to make this work? Maybe something I need to do in addition to setting DESTDIR during make install? Or is there a different option? It occurs to me to try to use a chroot, but I've never used one before. Does that sound like a good thing to try -- make a chroot which contains an empty /usr/local directory, links (hard links?) to /usr/bin, /usr/X11R6, /System, and other things the build is likely to need, and do the build in there, letting it think it's writing to the real /usr/local when it's really not? Any other suggestions for building multiple packages in a temporary directory before installation? Thanks for any insight you can offer. The ultimate goal, in case you're wondering, is that I would like to do a complete build of Graphviz -- from decompressing the source archives, all the way up to creating a disk image containing an installer package -- without requiring root access. Running the installer package would require root access, but I don't want the build system to require root.

3 5