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

Re: RubyCocoa 0.11.1
by Ryan Schmidt 24 Jul '07

24 Jul '07

On Jun 30, 2007, at 14:40, Eloy Duran wrote: > On 6/30/07, Ryan Schmidt wrote: > >> On Jun 30, 2007, at 09:48, Eloy Duran wrote: >> >> > Second, I'm not allowed to use the universal variant because >> it's not >> > a configure script based installation. Is there some way to >> override >> > this? Because now I have a builduniversal variant, but this is >> not so >> > nice... >> >> It should suffice to just redefine the universal variant: >> >> variant universal { >> configure.args-append --build-universal=yes >> } > > Unfortunately it doesn't. Macports complains that the universal > variant is only supported on "configure" based ports... Don't forget to reply to all so that your reply goes to the list, too, and not just to me. Run the install in debug mode (sudo port -dv install). It's not complaining about your port; it's complaining about a different one. See my similar experience here: http://trac.macosforge.org/projects/macports/ticket/12170 If you'll tell us which port it's complaining about, we can disable its universal variant like I did in #12137 for XFree86. That will work around the problem.

2 15

Release 1.5 branch created
by Juan Manuel Palacios 06 Jul '07

06 Jul '07

Evening everyone! I finally created the release_1_5 branch wherefrom we'll start cutting the 1.5.x releases, really soon now I hope! For those willing to help around in sanitizing, please reinstall off this branch and test as thoroughly as posible, reporting any findings you may come by. I'll rework the roadmap to move open tickets in the 1.4 milestone to 1.5, as well as those that were fixed in it but not released to users (committed to trunk, which as of r26608 is the same as release1_5) but not to the release_1_4 branch. Any new ticket on the base component should be submitted to the 1.5 milestone, consider 1.4 closed! As said previously, I'm mainly interested in reports on upgrading existing 1.4.x installations to 1.5 through any mean (selfupdate, make, binary -- I know there's no dmg up yet, but you can always build your own ;-). Even though I haven't received a single one to date (and supposedly "no news is good news), I'd still love to hear whatever you, the tester, have to say about it. Thanks to all for the help and attention, thanks to those who've put so much into improving the MacPorts core! Regards,... -jmpp

8 21

Re: [26541] trunk/doc/guide/xml/portfiles/details.xml
by Juan Manuel Palacios 01 Jul '07

01 Jul '07

Hi Maun Suang! Well, first of all, on behalf of the entire team thanks again for all this love you're devoting to the until now much abandoned guide, I'm sure a large user base will be very pleased to see this work come to fruition! About one of the changes you made here: > - configuration file /etc/ports/ports.conf. Can be > + configuration file ${prefix}/etc/ports/macports.conf. Can be I plan to release MacPorts 1.5 soon now (I've been preparing base for the last days and think it's time to branch already), so I'd love it if we could detail all throughout the entire guide the new installation layout resulting from the work I did on the dp2mp-move branch. You can read about it here: http://trac.macports.org/projects/macports/wiki/MacPortsRenaming And as that's what we'll be handing off to users in the near future we should start documenting it and adapting old documentation to it. I'll correct this one below in a sec... but just for future reference ;-) Regards,,... -jmpp On Jun 28, 2007, at 1:25 AM, source_changes(a)macosforge.org wrote: > Revision > 26541 > Author > boeyms(a)macports.org > Date > 2007-06-27 22:25:27 -0700 (Wed, 27 Jun 2007) > Log Message > > doc/guide/xml/portfiles: > * Correct names of some paths that MacPorts uses. > Modified Paths > > trunk/doc/guide/xml/portfiles/details.xml > Diff > > Modified: trunk/doc/guide/xml/portfiles/details.xml (26540 => 26541) > --- trunk/doc/guide/xml/portfiles/details.xml 2007-06-28 05:23:48 > UTC (rev 26540) > +++ trunk/doc/guide/xml/portfiles/details.xml 2007-06-28 05:25:27 > UTC (rev 26541) > @@ -71,10 +71,10 @@ > <term>prefix</term> > <listitem> > <para>Installation prefix, set in the systemwide > - configuration file /etc/ports/ports.conf. Can be > + configuration file ${prefix}/etc/ports/macports.conf. Can be > overridden on a per port basis. For example XFree86 > needs to install in the /usr tree, or aqua applications > - are installed in /Applications/Ports</para> > + are installed in /Applications/MacPorts</para> > > </listitem> > </varlistentry> > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes

2 4

RubyCocoa 0.11.1
by Eloy Duran 30 Jun '07

30 Jun '07

Hello, I've created a updated portfile for RubyCocoa. However I have a few questions: First I would like to change the name from rb-cocoa to rb-rubycocoa since that's the real name. Is this allowed? Second, I'm not allowed to use the universal variant because it's not a configure script based installation. Is there some way to override this? Because now I have a builduniversal variant, but this is not so nice... Portfile: http://pastie.textmate.org/74998 Note: I haven't yet updated the description. Cheers, Eloy

3 3

Re: RubyCocoa 0.11.1
by Boey Maun Suang 30 Jun '07

30 Jun '07

On 01/07/2007, at 02:36, Eloy Duran wrote: > Yes indeed this works. > However I'm sure you agree that it should work directly from a > clean install? Absolutely, but I'm having a terrible time trying to figure out how to make it work that way! > I've send an email to the maintainer asking what all the patches do, > since a regular "ruby setup.rb" works fine for me... Hopefully you have more luck getting a reply than I have; otherwise, I'll just have to keep stumbling around, hoping that I or someone else figures out how to make it work first time around. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org

1 0

ports with bootstrapping dependencies
by Taylor R Campbell 30 Jun '07

30 Jun '07

Hello! I'd like to make a port for MIT Scheme, an implementation of the Scheme programming language. The port is somewhat complicated, though, because of a bootstrapping process. However, I think that I have found a way to make the bootstrapping process work without introducing circular dependencies, which requires only a small change to MacPorts' dependency specifications. MIT Scheme is a large program written primarily in Scheme, and based on a native-code compiler. This would mean that building it is impossible without an older version of itself, but its compiler also has a C back end, and the next snapshot to be released very shortly will support the construction of distributions with pre-generated C code by which the whole system can be bootstrapped. This means that it is easy to write a port that just fetches a tarball with the generated C code and bootstraps the whole system from that. The trouble with this is that it is very slow, and only the C back end can be built from generated C code. I'd like to have another port for the native back end, so I'll call the port with the C back end `mit-scheme-c', and the port with the native back end `mit-scheme-native'. Building Scheme from scratch is slow (requiring about an hour or two on my 2 GHz MacBook), and building either back end with the other back end is also slow (C -> native or native -> C). If the user already has an older version of either back end, then upgrading to a newer version can run much faster (about ten or twenty minutes for me). In an ideal world, I could have two portfiles, something like <http://people.csail.mit.edu/riastradh/tmp/liarc-Portfile> and <http://people.csail.mit.edu/riastradh/tmp/native-Portfile>: mit-scheme-c has three variants, all of which are mutually exclusive, and which I'll write with a `+' prefix just to visually distinguish them from port names: +from-scratch requires nothing but a C compiler and an operating system, fetches a tarball containing pre-generated C files, and bootstraps the whole system from that. Slow. +from-c requires mit-scheme-c (usually an older version), fetches a pristine source tarball, and just builds the system, without any extra intermediate bootstrapping stages. Decently fast. +from-native requires mit-scheme-native, fetches a pristine source tarball, and bootstraps the system with an intermediate cross-compiler. (This one isn't actually very useful; it does more work than +from-scratch, because it has to prepare what was pre-generated for +from-scratch.) mit-scheme-native has two variants, both of which depend on an existing installation: +from-c requires mit-scheme-c, fetches a pristine source tarball, and bootstraps a native compiler from that. Slow, but this is the only way to get a native system to begin with. +from-native requires mit-scheme-native (usually an older version), fetches a pristine source tarball, and builds the system without any extra intermediate bootstrapping stages. Fast. Unfortunately, `mit-scheme-c +from-c' and `mit-scheme-native +from-native' don't work because of the obvious bootstrapping problem. I discussed the issue with Juan Manuel Palacios and Eric Hall on IRC, and was informed that the dependency engine would require an inordinate amount of work before this kind of nearly circular dependency would work at all. However, it occurred to me that we could somewhat dangerously work around the *port* dependency by rendering it into a *binary* dependency -- that is, the +from-c variants depend on the existence of a binary called `mit-scheme-c', and the +from-native variants depend on the existence of a binary called `mit-scheme-native'. MacPorts do have a way to specify a dependency on a binary file by some name -- `depends_* bin:foo:bar' --, but it requires a port to be associated with the file. What I need for MIT Scheme is *almost* this: if the file isn't there, I want MacPorts not to try to build the port associated with it, but just to give up; users shouldn't use the +from-c or +from-native variants if they aren't available. What I propose, then, is to allow a dependency of the form `bin:<filename>', without an associated port (or perhaps with `I-know-what-I-am-doing' or `just-complain-to-the-user-if-unavailable' instead of a port). Although it is slightly dangerous to do this, it's a very small change that lets us work around what would otherwise appear to be circular dependencies, and it would mean that upgrading the MIT Scheme port could take fifteen to thirty minutes, rather than anywhere from two to four hours. Thoughts? Does this sound reasonable? Is there another way to go about this that I hadn't thought of?

4 8

Re: [26591] trunk/dports/sysutils/smart/Portfile
by Ryan Schmidt 30 Jun '07

30 Jun '07

On Jun 29, 2007, at 05:01, source_changes(a)macosforge.org wrote: > Revision: 26591 > http://trac.macosforge.org/projects/macports/changeset/26591 > Author: afb(a)macports.org > Date: 2007-06-29 03:01:16 -0700 (Fri, 29 Jun 2007) > > Log Message: > ----------- > fix configure system hack > > Modified Paths: > -------------- > trunk/dports/sysutils/smart/Portfile > > Modified: trunk/dports/sysutils/smart/Portfile > =================================================================== > --- trunk/dports/sysutils/smart/Portfile 2007-06-29 07:40:52 UTC > (rev 26590) > +++ trunk/dports/sysutils/smart/Portfile 2007-06-29 10:01:16 UTC > (rev 26591) > @@ -28,7 +28,8 @@ > system "cd '${workpath}/${distname}' && \ > sed -e 's#@@PREFIX@@#${prefix}#g' '${portpath}/${filesdir}/$ > {patch}' | patch -p0" > } > - system "echo 'exit 0' > '${workpath}/${distname}/configure' && > chmod +x '${workpath}/${distname}/configure'" > } > > +use_configure no > + > build.env PYTHON="${prefix}/bin/python2.4" That same fix could be applied to yum, right? That's the only other port I could find with this weird hack.

1 0

New port aircrack-ng
by Sbranzo 29 Jun '07

29 Jun '07

Hi, This is a ticket for a the aircrack-ng port http://trac.macports.org/projects/macports/ticket/12181 No driver is available to capture and inject packets under osx, but the cracking library should work as on linux and other systems. Can someone please review and commit it? Thanks, Gufo

2 1

Re: [26588] trunk/dports/python/py-py2app/Portfile
by Ryan Schmidt 29 Jun '07

29 Jun '07

On Jun 29, 2007, at 02:31, source_changes(a)macosforge.org wrote: > Revision: 26588 > http://trac.macosforge.org/projects/macports/changeset/26588 > Author: jwa(a)macports.org > Date: 2007-06-29 00:31:37 -0700 (Fri, 29 Jun 2007) > > Log Message: > ----------- > version bump to 0.3.6, adding livecheck, whitespace changes If you're going to make whitespace changes, could you please commit them separately, in their own revision? That way people looking for changes to the substance of the port can see them more clearly.

1 0

MacPorts 1.5 Leopard Ready?
by James Berry 28 Jun '07

28 Jun '07

With an impending MacPorts 1.5 release, it would be nice to know/make sure that the infrastructure code is Leopard-ready out of the box. If anybody knows of any issues with MacPorts 1.5 base code and Leopard, please let us know. Due to confidentiality issues, you may email macports-mgr(a)lists.macosforge.org directly. James

1 0