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

${version} vs. ${portversion}
by Ryan Schmidt 23 Mar '07

23 Mar '07

What's the difference between ${version} and ${portversion}? There are 1350 ports that use the former construct, and 74 that use the latter. Do they represent the same thing? If so, why do we have two variables? dports $ grep '${portversion}' */*/Portfile | cut -d ':' -f 1 | sort | uniq | wc -l 74 dports $ grep '${version}' */*/Portfile | cut -d ':' -f 1 | sort | uniq | wc -l 1350 -- To reply to the mailing list, please use your mailer's Reply To All function

2 1

MacPorts 1.4, final call for feedback
by Juan Manuel Palacios 23 Mar '07

23 Mar '07

MacPorts 1.4 has been in rc status for a while now and, as far as I can recall, not a single issue has been reported against it. This is because, either: a) There are *no* issues in MacPorts 1.4 (not likely in any piece of software I've ever seen), in which case we should be OK to go with the final release; Or: b) None of us has done enough testing (most likely), in which case, unfortunately, our wider general user base will have to serve as our test bed, 'cause it doesn't make any sense to keep holding things back indefinitely. In any case, I plan to do the final release on Monday, which should give us all two full days (and a half) to test the last mile and report any findings. If you do come about any bug(s), please by all means file a ticket for it (them) under the 1.4 milestone ("base" component). Also, feel free to object to this timeline if you have any strong and compelling arguments against it (but I warn you, your arguments have to be strong, 1.4 has been cooking for long already ;-). If b) above happens to be the case, we can always do quick 1.4.x minor releases, so last minute small bugs shouldn't be show stoppers. I can only see major, somehow previously unnoticed bugs in our 1.4 sources delaying the release now, but those are very unlikely at this point too (maybe little, I don't know, but at least *some* testing has taken place). Regards to all and thanks for your work on MacPorts 1.4! -jmpp

1 0

Add version 1.5 to Trac
by Ryan Schmidt 23 Mar '07

23 Mar '07

Someone with the ability please add version 1.5 to the Version pop-up menu in the Trac tickets. I have MacPorts installed from trunk, and I'd like to be able to submit bugs and accurately represent the version of the software I currently use. Thanks.

2 1

ports need to indicate whether they work with +universal (was: Re: Newbie ncursesw problem - can't install apache2 | Re: port should not complain about +universal, CFLAGS/LDFLAGS, configure.universal_cflags-append/configure.universal_ldflags-append)
by Elias Pipping 23 Mar '07

23 Mar '07

I'm merging these two threads to create a new one, because * they (now) deal with the same topic * their names are too long and unrelated to the current topic so please * reply to this email instead * leave off the (was: ...) part Regards, Elias Begin forwarded message: > From: Elias Pipping <pipping(a)macports.org> > Date: March 23, 2007 3:24:25 PM GMT+01:00 > To: Ryan Schmidt <ryandesign(a)macports.org> > Cc: Macports dev <macports-dev(a)lists.macosforge.org> > Subject: Re: port should not complain about +universal, CFLAGS/ > LDFLAGS, configure.universal_cflags-append/ > configure.universal_ldflags-append > > On Mar 23, 2007, at 11:21 AM, Ryan Schmidt wrote: > >> >> On Mar 18, 2007, at 05:52, Elias Pipping wrote: >> >>> Let's wait for official support of +universal with that... >> >> Well, how will we get official support of +universal unless we >> push for it? Now that I have an Intel Mac, it no longer takes >> forever for me to compile things, so I'm trying to build as many >> things universal as I can. And I will continue to bring to the >> list's attention all problems I encounter in this endeavor. And we >> should all try our best to fix the problems. >> >> When will we get +universal anyway? Right now, I'm running >> MacPorts compiled from trunk, a.k.a. 1.500, because the 1.4rc2 >> release doesn't appear to contain the default +universal variant. >> The messages that have been inserted into some portfiles suggest >> that the default +universal variant should have been in MacPorts >> 1.400. So what's up? > > that was done before the version of the trunk was bumped to 1.5. - > it's malinformation now > >>> eventually the whole if clause will be gone anyway. >> >> I understand that the if clause in the portfiles testing for the >> universal functionality will go away, once that functionality is >> generally available. That does not fix the problem that the port >> system will still print a warning that the port might fail to >> build universally, when in fact it will not. I stand by my >> original statement that the port system should not print the >> warning about the CFLAGS or LDFLAGS if the portfile uses the >> configure.universal_cflags-append or configure.universal_ldflags- >> append options. > > that was unrelated to the issue you described, indeed. > >>> I mean really, there's worse problems than obsolete warnings >> >> I think inaccurate warnings are almost worse than no warnings. If >> I try to install something universal, and it says "warning! this >> may not work!" then I will stop the build and examine the portfile >> to see what I think. Then I find the configure.universal_cflags- >> append bit or whatever which means it most likely will work >> because someone has gone out of their way to add that specifically >> for universal support. So then I get annoyed that I was made to >> check the portfile source. >> >> Maybe this is all a moot point if the "universal_ok" flag is >> implemented as I described in the other thread. Then portfiles >> known to build universally can include "universal_ok yes", and the >> port system can then check just for that variable and not bother >> checking for CFLAGS, LDFLAGS or anything else. > > sounds good - and a port that doesn't have that flag shouldn't > display 'universal' as a variant. > > >> >>> especially with gettext. e.g. gettext +universal is somehow >>> incomplete: all the libasprintf-related files are missing >>> completely. diff the results of port contents with and without >>> +universal and see for yourself (ideas, patches appreciated) >> >> Hmm. I wasn't aware of that. But I have no idea what libasprintf >> is or why I would want it, and I don't know what to do about its >> absence either. >> > > I've fixed it in a recent commit[1]. the problems was simply that > gettext is written in C++, hence g++ needs the same flags as gcc > (the isysroot and the arch flags). gettext +universal is now stable > [2]. > > [1] http://trac.macports.org/projects/macports/changeset/23028 > [2] http://trac.macports.org/projects/macports/wiki/ > Universal#gettext0.16.1_0 > > Regards, > > Elias > _______________________________________________ > macports-dev mailing list > macports-dev(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev Begin forwarded message: > From: Elias Pipping <pipping(a)macports.org> > Date: March 23, 2007 3:33:38 PM GMT+01:00 > To: Ryan Schmidt <ryandesign(a)macports.org> > Cc: Macports Dev <macports-dev(a)lists.macosforge.org> > Subject: Re: Newbie ncursesw problem - can't install apache2 > > On Mar 23, 2007, at 11:10 AM, Ryan Schmidt wrote: > >> On Mar 20, 2007, at 10:57, Elias Pipping wrote: >> >>> This is a serious problem btw. That "oh there's a universal >>> variant, it'll surely work" thought, which is perfectly natural >>> but doesn't work in this case. That's why >>> >>> http://trac.macosforge.org/projects/macports/wiki/Universal >>> >>> needs to be extended and made aware of. (alternatively, a port >>> could be required to hold some keyword in order to allow for >>> building with +universal. like 'build_universal yes' or something. >> >> I think your wiki list is perhaps helpful right now, but not a >> viable long-term solution. I would want a solution that's >> completely contained within the MacPorts software. > > It wasn't meant to be a standalone solution. A start rather. I'd > like an infrastructure like the guys over at gentoo have it.[1] > (without the wait for something to become stable, though, at least > at first) > >> I would prefer a variable named something like "universal_works" >> or "universal_ok" which could be set to "yes" or "no". The default >> would be neither, more of an "I don't know" or "maybe" state. >> Ports where the maintainer has tried the +universal variant and >> believes it to work should have "universal_ok yes" added. Ports >> that have been tested and found not to work universally should be >> marked with "universal_ok no" (that's assuming they cannot be >> easily fixed to work universally). Anyone who tries to build a >> port that has neither marking would get a warning that the >> universal build is untested, and that they should let us know if >> they find that it works or doesn't work. > > That's good for now, but it's only a short term solution as well, > because it only says something about the universal variant whereas > we need information about what works for every package on every > supported platform with every variant (the variants will be ugly). > > [1] http://packages.gentoo.org/search/?sstring=bash > > Regards, > > Elias > _______________________________________________ > macports-dev mailing list > macports-dev(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev

1 0

Re: Newbie ncursesw problem - can't install apache2
by Ryan Schmidt 23 Mar '07

23 Mar '07

On Mar 20, 2007, at 10:57, Elias Pipping wrote: > This is a serious problem btw. That "oh there's a universal > variant, it'll surely work" thought, which is perfectly natural but > doesn't work in this case. That's why > > http://trac.macosforge.org/projects/macports/wiki/Universal > > needs to be extended and made aware of. (alternatively, a port > could be required to hold some keyword in order to allow for > building with +universal. like 'build_universal yes' or something. I think your wiki list is perhaps helpful right now, but not a viable long-term solution. I would want a solution that's completely contained within the MacPorts software. I would prefer a variable named something like "universal_works" or "universal_ok" which could be set to "yes" or "no". The default would be neither, more of an "I don't know" or "maybe" state. Ports where the maintainer has tried the +universal variant and believes it to work should have "universal_ok yes" added. Ports that have been tested and found not to work universally should be marked with "universal_ok no" (that's assuming they cannot be easily fixed to work universally). Anyone who tries to build a port that has neither marking would get a warning that the universal build is untested, and that they should let us know if they find that it works or doesn't work.

2 1

Re: [22768] trunk/base
by Juan Manuel Palacios 23 Mar '07

23 Mar '07

Hey Kevin! Remember this commit in which you abstracted bzip2's path and left it to autoconf to figure out at configure time? I have one question about it: On Mar 13, 2007, at 10:13 PM, source_changes(a)macosforge.org wrote: > Revision > 22768 > Author > eridius(a)macports.org > Date > 2007-03-13 19:13:50 -0700 (Tue, 13 Mar 2007) > > Log Message > receipt_flat.tcl no longer uses an absolute path for bzip2 > Boy, autoconf is ugly Now that we have a base/src/registry1.0/registry_autoconf.tcl.in autoconfiscated file, shouldn't the "clean" (or "distclean"?) target of that dir's Makefile delete the generated registry_autoconf.tcl file? > > Modified Paths > • trunk/base/configure > • trunk/base/configure.ac > • trunk/base/src/registry1.0/Makefile > • trunk/base/src/registry1.0/receipt_flat.tcl > > Added Paths > • trunk/base/src/registry1.0/registry_autoconf.tcl.in > > Property Changed > • trunk/base/src/registry1.0/ > -jmpp

1 0

OpenCV python bindings
by Nathaniel Fairfield 22 Mar '07

22 Mar '07

Hi, I've been trying to get the python wrapping for OpenCV to work. Right now, every time I try to "import opencv", I get a Bus Error (seg fault, I assume). From gdb, I get the following, which isn't very helpful to me: Starting program: /opt/local/bin/python Reading symbols for shared libraries .+ done Python 2.4.3 (#1, Jan 4 2007, 19:19:23) [GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin Type "help", "copyright", "credits" or "license" for more information. Reading symbols for shared libraries ... done >>> import opencv Reading symbols for shared libraries .... done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 PyInt_FromLong (ival=88) at Objects/intobject.c:89 89 Objects/intobject.c: No such file or directory. in Objects/intobject.c I've tried both OpenCV 0.9.9 (which is in the current portfile) and OpenCV 1.0.0 (the latest release), and get the same result. I'm running MacPorts Python 2.4.3. Rummaging around with google shows that other people have had similar problems, but have been able to get the 'built-in' Python 2.3 that comes with Tiger to work. I'd like to get it working with 2.4 if possible. The crux of the matter seems to be when python loads "_cv.so". otool -L _cv.so _cv.so: /opt/local/lib/libpython2.4.dylib (compatibility version 2.4.0, current version 2.4.0) /opt/local/lib/libcv.1.dylib (compatibility version 2.0.0, current version 2.0.0) /opt/local/lib/libcxcore.1.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.8) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) I've tried compiling OpenCV with Carbon (the default), and also with the configure.args --without-carbon --with-gtk --without-quicktime --with-swig Any help would be much appreciated. Thanks, Nathaniel

1 0

Re: [23027] trunk/dports/lang/gcj34/Portfile
by Weissmann Markus 22 Mar '07

22 Mar '07

+ cd ${destroot}${prefix}/${name}-${version}/share/man/ + foreach n {1 7} { + foreach f [glob man${n}/*.${n}] { + system "gzip -9 ${f}" + } + } Whats the deal with compressing the manfiles explicitly? Does the auto-compression not work here? (And why? And why not fix it globally?) thanks, -Markus On 22.03.2007, at 17:25, source_changes(a)macosforge.org wrote: > Revision 23027 Author pipping(a)macports.org Date 2007-03-22 09:25:20 > -0700 (Thu, 22 Mar 2007) Log Message * bump version to 3.4.6 * > depend on and link against libiconv * force compression of manpages > Modified Paths > trunk/dports/lang/gcj34/Portfile > Diff > Modified: trunk/dports/lang/gcj34/Portfile (23026 => 23027) --- > trunk/dports/lang/gcj34/Portfile 2007-03-22 14:05:21 UTC (rev > 23026) +++ trunk/dports/lang/gcj34/Portfile 2007-03-22 16:25:20 UTC > (rev 23027) @@ -2,7 +2,7 @@ PortSystem 1.0 name gcj34 -version > 3.4.5 +version 3.4.6 categories lang devel java maintainers > nomaintainer(a)macports.org description GNU Java compiler @@ -15,26 > +15,29 @@ platforms darwin homepage http://www.gnu.org/software/ > gcc/java/ -master_sites gnu:gcc/gcc-3.4.5 +distname gcc-$ > {version} +master_sites gnu:gcc/${distname} use_bzip2 yes > dist_subdir gcc -distname gcc-${version} -checksums md5 > 7c3c3c3e764dcee5eb771432062d69e1 +checksums md5 > 4a21ac777d4b5617283ce488b808da7b \ + sha1 > 97b290fdc572c8e490b3b39f243e69bacad23c2b \ + rmd160 > b15003368cedc7964f6ceaee0c39ddc43a46c442 worksrcdir ${distname}/ > build -depends_lib port:zlib +depends_lib port:libiconv port:zlib > patchfiles patch-libjava_libltdl_ltmain.sh patch-ltmain.sh pre- > patch { - file mkdir ${worksrcpath} + xinstall -d ${worksrcpath} } > set gcjBaseDir ${prefix}/${name}-${version} configure.cmd $ > {worksrcpath}/../configure -configure.env CPPFLAGS="-I${prefix}/ > include" LDFLAGS="-L${prefix}/lib" +configure.env CPPFLAGS="-I$ > {prefix}/include" LDFLAGS="-L${prefix}/lib" \ + LIBS=-liconv > configure.pre_args --prefix=${gcjBaseDir} configure.args --enable- > languages=c++,java --disable-nls \ --with-system-zlib --mandir=$ > {gcjBaseDir}/share/man \ @@ -45,6 +48,12 @@ # Since we install in a > subdir dedicated to gcj, this gets it visibility post-destroot { + > cd ${destroot}${prefix}/${name}-${version}/share/man/ + foreach n > {1 7} { + foreach f [glob man${n}/*.${n}] { + system "gzip -9 ${f}" > + } + } set gcjLinkFiles { gcj gcjh gij grepjar jcf-dump jv-convert > jv-scan } cd ${destroot}/${prefix}/bin foreach gcjBinFile $ > {gcjLinkFiles} { @@ -53,7 +62,7 @@ cd ${destroot}/${prefix}/share/ > man/man1 foreach gcjManFile ${gcjLinkFiles} { system "ln -s \ > - ../../../${name}-${version}/share/man/man1/${gcjManFile}.1 ." > + ../../../${name}-${version}/share/man/man1/${gcjManFile}. > 1.gz ." } xinstall -m 755 -d ${destroot}/${prefix}/lib/pkgconfig cd > ${destroot}/${prefix}/lib/pkgconfig > _______________________________________________ > macports-changes mailing list > macports-changes(a)lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes --- Markus W. Weissmann http://www.mweissmann.de/

2 1

fftw3
by Takeshi Enomoto 22 Mar '07

22 Mar '07

I submitted a portfile for fftw-3.1.2. fftw-2 and fftw-3 are incompatible so port fftw should remain as it is. <http://trac.macosforge.org/projects/macports/ticket/11578> Takeshi

2 4

Deactivating a port
by John Ridgway 22 Mar '07

22 Mar '07

Friends - I'm creating some new ports -- stuff from CTAN for TeX, and I am discovering a real need for a pre- or post- deactivate hook (preferably both, but I could live with only post-). What are the chances that this functionality could get in to the base? The reason is that when adding fonts to a TeX tree one needs to run updmap-sys to make the fonts available, but when they go away again we need to run updmap-sys again... I just like to clean up after myself. :-) Peace - John

3 2