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

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

A 1.4 release
by Juan Manuel Palacios 07 Mar '07

07 Mar '07

Hello everybody! For those of you who don't know me because you're rather new here, I would like to introduce myself: I am one of the three {Darwin,Mac}Ports old... team members holding the "honorary" title of "Project Manager" who has been too swamped by Real Life these last months to manage to get any productive work done on this great project, hoping that'll change in the not too distant future. I'll tell you though that at one point I did come to be known as a quite active contributor, so there! :-P To the new and old blood that's still with us, thank you so much for your continued drive and enthusiasm put into this project, we wouldn't be walking on our own two feet if it weren't for you! Now, however, I have been lurking on this list and have kept an eye over a couple of issues which I believe warrant a new minor release of our infrastructure, 1.4 I propose. As I am not exactly called Mr. Current Affairs at this point in time, I would like to call for some feedback on what should be considered for inclusion in the new release, but I think I can at least propose a small starter list: 1) Final and long overdue DarwinPorts --> MacPorts migration in our base code, carried out by Randall Wood if he so volunteers; 2) Migration to SourForge's new mirrors redirection mechanism in our trunk/base/src/port1.0/resources/fetch/mirros_sites.tcl file, with the addition of maybe two or three hardcoded fail-safe mirrors as suggested in the mail forwarded by Kevin Ballard; 3) The addition of a MacPorts mirror list in the same file with a starting single entry pointing to a distfiles/ (or any other better idea) location in our svn repo, where we can start loading selected distfiles for projects missing them at their main sites. Such list could pave the way for a future MacPorts mirroring system, as adding new entries to it would be transparent to users and Portfiles, the latter only having to use "master_sites macports:foo:bar" to leverage our mirrors just as they currently do SourceForge's; 4) Any other differences between trunk/base and /brances/release_1_3, to be integrated into a future release_1_4 branch, including but not limited to: -) the unarchive --> archive rollback of my earlier "fix", performed by Daniel Luke; -) Kevin Ballard's fast_load improvements; -) a new portfile.7 man page, I think...? -) anything else I'm missing...? Anyone care to diff the two code bases? ;-) Please feel free to append to this list whatever you feel should be included in the new release branch, lets brainstorm at least a bit over all the ideas. In any case, I would like to point out it wouldn't be too wise to try to fix the entire world with 1.4, I have myself voiced some rather large and therefore mid-term goals for the project as a whole and have also heard of some interesting ones from other developers, but needless to say all those warrant wider discussion and consensus among us all, so lets try to keep this release a small and focused one, comprising only necessary and urgent fixes. World domination may come later on! ;-) We used to have a pretty good and detailed page detailing our release process, most kindly created by James Berry, up in our old Wiki, but I don't believe it survived the migration so I'll see if I can coordinate with Kevin Van Vechten to resurrect it. Once I do I would like to call for someone (someone*s* ;-) volunteering to give me a hand putting together the release, as there are a few things to keep an eye over and I don't think mine alone will suffice. Once we get this ball rolling I'll post a release candidate I would like all of use to test as extensively as possible, so keep your eyes open for future announcements, please. Thanks again for your hard work put into the project and for bearing with me this far in my mail (yeah, still jmpp -v -v -v, some things never change!). Hope we can make a great 1.4 release and thus pave the way to move forward in great leaps :-D Much regards to all,... -jmpp

7 22

tbz or tbz2
by Blair Zajac 05 Mar '07

05 Mar '07

I was messing around with the portarchivetype option today and tried to set it to tbz2 according to ports.conf, but the resulting files, while ending in .tbz2, were not: /opt/local/var/db/dports/packages/darwin/i386/coreutils-6.7_1+with_default_names.i386.tbz2: POSIX tar archive So the code looks a little fragile in that it does regex matching on the names to determine which archiver and compressor to use. It also doesn't cover misspelled settings So a couple of things: 1) Should we decide on a standard tbz or tbz2? We should have the documentation match the code. 2) Have to code check for all valid types instead of trying regexps on them? Thanks, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair(a)orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/

2 2

Python 2.5 and py-crypto...
by Douglas Philips 01 Mar '07

01 Mar '07

Sorry for not having been paying close attention, but I found I needed python 2.5, so I installed that. I also needed py-crypto, but that has a dependency on python24 and no py25-crypto package was available. So, I fetch'd and extract'd plain ol py-crypto, then with python 2.5 on my PATH I was able to build, test, and install it (into /opt/local/ lib/python2.5/...) and so far it seems to be working fine. --Doug

8 11

devel variants
by Martin Vito Cruz 28 Feb '07

28 Feb '07

I'm not sure if it's a problem with the portfiles or if it's a problem with code in base/ but I'm running into trouble trying to install +devel variants of various ports (auctex, slime, haskell-mode.el, etc). I'm using a subversion checkout of the trunk; everytime I try to install one of these +devel variants I get an error message like: Error: Error executing devel: can't set "depends_lib": invalid depspec: Error: Status 1 encountered during processing. I haven't checked all of them but it seems like any port that does something like variant devel { depends_lib-delete port:emacs depends_lib-append port:emacs-devel } will run into the same error. I can file a bug report in Trac, but I was wondering first whether someone else is seeing this problem, and whether I should file it against the specific ports or against base. Thanks, Martin

1 0

Default +universal variant for configure-based ports
by Paul Guyot 28 Feb '07

28 Feb '07

Dear all, I've just implemented and committed a default +universal variant for configure-based ports. There's been some heat about +universal recently and I did not want every port to define the same code over and over. This variant is more or less equivalent to: variant universal { configure.args-append "--disable-dependency-tracking" configure.env-append CFLAGS="-isysroot /Developer/SDKs/ MacOSX10.4u.sdk -arch i386 -arch ppc" LDFLAGS="-arch i386 -arch ppc" } However, there is some additional magic: * selecting the variant will fail if the port doesn't invoke configure (because user may think they can build the port universal while it would be effectless) * selecting the variant will print a warning message if the port already overrides LDFLAGS or CFLAGS in the environment for the configure command * you can add -O -g if the port requires it with just: configure.universal_cflags-append -O -g * you can simply redefine the variant to override the default code and provide port-specific handler for the universal variant. etc. The variant is documented in portfile(7). I tested it with several ports and it seems to just work®™. I'm considering some future enhancements, but let's see what it gives if we start building ports with +universal. Of course, the build will probably fail if dependencies were not built universal. Enjoy! Paul

11 39

Re: Default +universal variant for configure-based ports
by Kevin Ballard 28 Feb '07

28 Feb '07

We currently have 3787 ports. I expect a majority of these ports to fail building +universal. Do you really want emails sent out about 2000+ ports, and 2000+ changes to add the exact same behaviour? To put it simply, the universal variant paul added is not going to work for, I expect, a majority of ports. Thus, it should be an opt-in rather than an opt-out. On Feb 27, 2007, at 11:40 PM, Ryan Schmidt wrote: > On Feb 27, 2007, at 13:49, Kevin Ballard wrote: > >> That said, I don't think it *should* list universal unless the >> port is actually known to work with it. Any proposed solutions? > > I don't think anything needs to be done. I don't have any problem > with the +universal variant being listed even if it doesn't work. > If someone tries it and it does not work, then they should submit a > bug report to the maintainer, just as they would for any other > problem with the port. Then the maintainer will either fix it or > add a universal variant which just outputs a us_msg explaining that > a universal build is not available at this time. Problem solved. -- Kevin Ballard http://kevin.sb.org eridius(a)macports.org http://www.tildesoft.com

1 0

gnu ports
by Elias Pipping 28 Feb '07

28 Feb '07

There are some inconsistencies when it comes to gnu ports e.g.: "tar" goes by the name "gnutar". its executable is called "gnutar" "sed" goes by the name "gsed". its executable is called "gnused" "which" goes by the name "gwhich". its executable is called "gwhich" Regards, Elias Pipping

5 11

Re: port clean bails on ophcrack (on macports-users)
by Cédric Luthi 28 Feb '07

28 Feb '07

On 27 févr. 07, at 10:27, Bryan Blackburn wrote: > On Feb 26, 2007, at 10:18 PM, Paul Beard wrote: > >> ---> Cleaning openvanilla >> ---> Cleaning openvpn >> ---> Cleaning openvpn2 >> Error: ophcrack only runs on little-endian machines. >> >> I tried to run port clean all and it dies when it gets an error >> message on ophcrack. Should this be part of a PPC-based ports tree? > > Looks like ophcrack is using exit in the pre-fetch phase, which is > bad for certain operations (like 'port clean' and possibly others) > as I found a few years back. I thought there was a discussion on > how best to handle these situations, but I sure can't seem to find > the email thread in the archives... This has been posted on the users list. I'm not sure how this problem should be fixed. Exiting after pre- fetch would be stupid as the file should not be downloaded at all on a PowerPC Mac. Bryan mentions an old thread about this subject, can anyone remember this ? Cédric Luthi

2 1

Re: [22371] trunk/dports/graphics/ImageMagick/Portfile
by Yves de Champlain 27 Feb '07

27 Feb '07

Wouldn't it be more sane to have, say, 2 variants for that port ? like without_ghostscript (because gplghostscript conficts with "default" ghostscript) without_x11 (for the pure) It would go along the official guidelines, but it would mostly make it friendlier to use. yves Le 07-02-27 à 13:53, source_changes(a)macosforge.org a écrit : > Revision > 22371 > Author > blair(a)macports.org > Date > 2007-02-27 10:53:46 -0800 (Tue, 27 Feb 2007) > Log Message > > Whitespace cleanup. > Modified Paths > > trunk/dports/graphics/ImageMagick/Portfile > Diff > > Modified: trunk/dports/graphics/ImageMagick/Portfile (22370 => 22371) > > --- trunk/dports/graphics/ImageMagick/Portfile 2007-02-27 14:52:19 > UTC (rev 22370) > +++ trunk/dports/graphics/ImageMagick/Portfile 2007-02-27 18:53:46 > UTC (rev 22371) > @@ -53,47 +53,47 @@ > # Using gplghostscript instead of ghostscript as the former provides > # libgs and the latter appears not to at this time > variant gs { > - depends_lib-append port:gplghostscript > + depends_lib-append port:gplghostscript > configure.args-delete --without-gslib > configure.args-append --with-gslib > } > > variant lcms { > - depends_lib-append port:lcms > + depends_lib-append port:lcms > configure.args-delete --without-lcms > configure.args-append --with-lcms > } > > variant wmf { > - depends_lib-append port:libwmf > + depends_lib-append port:libwmf > configure.args-delete --without-wmf > configure.args-append --with-wmf > } > > variant mpeg { > - depends_lib-append port:mpeg2vidcodec > + depends_lib-append port:mpeg2vidcodec > } > > variant jbig { > - depends_lib-append port:jbigkit > + depends_lib-append port:jbigkit > configure.args-delete --without-jbig > configure.args-append --with-jbig > } > > variant jpeg2 { > - depends_lib-append port:jasper > + depends_lib-append port:jasper > configure.args-delete --without-jp2 > configure.args-append --with-jp2 > } > > variant graphviz { > - depends_lib-append port:graphviz > + depends_lib-append port:graphviz > configure.args-delete --without-gvc > configure.args-append --with-gvc > } > > variant nox11 { > - depends_lib-delete lib:libX11.6:XFree86 > + depends_lib-delete lib:libX11.6:XFree86 > configure.args-delete --with-x > configure.args-append --without-x > } > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes

1 0