gmane.os.apple.macports.devel

noob question: can't find a new port

Jeremy Huddleston — 2008-12-02T21:03:39

This is a bit of a noob question, and I'm sure it's buried in documentation somewhere, but I didn't see it... I'm trying to test a new port which isn't committed yet that has a dependency on a just- committed port... but it's not finding it. Am I missing a step? Thanks, Jeremy ~/src/macports/trunk/dports/x11/xorg-libXext $ sudo port -v install ---> Installing xorg-libXext < at >1.0.4_0+universal ---> Activating xorg-libXext < at >1.0.4_0+universal ---> Cleaning xorg-libXext ---> Removing build directory for xorg-libXext ~/src/macports/trunk/dports/x11/xorg-libXext $ cd .. ~/src/macports/trunk/dports/x11 $ svn add xorg-libXext/ A xorg-libXext A xorg-libXext/Portfile ~/src/macports/trunk/dports/x11 $ cd xorg-libXext ~/src/macports/trunk/dports/x11/xorg-libXext $ svn ci -m "New port: xorg-libXext" Adding xorg-libXext Adding xorg-libXext/Portfile Transmitting file data . Committed revision 42951. ~/src/macports/trunk/dports/x11/xorg-libXext $ cd ../xorg-libAppleWM/ ~/src/macports/trunk/dports/x11/xorg-libAppleWM $ sudo port -v install Error: Dependency 'xorg-libXext' not found. Error: Status 1 encountered during processing.

No default port source specified in /mp/etc/macports/sources.conf

Ryan Schmidt — 2008-12-01T06:29:12

I tried updating my MacPorts trunk base just now (r42837) and got this: ===> making install in src/programs/daemondo /usr/bin/install -c -o rschmidt -g admin -m 555 build/daemondo /mp/bin /usr/bin/install -c -o rschmidt -g admin -m 444 setupenv.bash /mp/ share/macports/ /usr/bin/tclsh src/upgrade_sources_conf_default.tcl /mp /usr/bin/tclsh src/dep_map_clean.tcl /mp/Library/Tcl No default port source specified in /mp/etc/macports/sources.conf while executing "mportinit" (file "src/dep_map_clean.tcl" line 12) make: *** [install] Error 1 The only non-comment line in my sources.conf is: file:///Users/rschmidt/macports/dports So it does not have anything in brackets after the URL.

Install Order

Neil — 2008-11-30T21:40:38

(Stolen from Ryan Schmidt's mail on 29 Nov 2008, at 14:48.) Order of Operations to Install 1 fetch 2 checksum 3 extract 4 patch 5 configure 6 build 7 destroot 8 install 9 deactivate 10 activate 11 clean (I'm kind of thinking out loud here...) Proposal: What if we changed the order slightly, so we do steps 1-7 for all the packages first, and then, if there are no errors, do 8-11? "Why?": Suppose we have pkg2 which depends on pkg1. If they both build fine, then we're dandy. But if pkg2 fails, pkg1 is still installed. If there are a lot of dependencies, it can be a pain to track them down. If we separate the steps into two phases, then most breaks during the installation (which mostly happen during 5-6, I think) won't leave unneeded ports on the system (at least not after a clean command). Thoughts?

committing update to configure

Jeremy Huddleston — 2008-11-29T10:02:26

I had a small update to configure.ac that I wanted to push (below). I decided to regen configure since it was made with an old version of autoconf that doesn't detect X11 properly. I got an error from svn about inconsistent line ending style... I find it odd that svn:eol- style is set on a generated file, so I thought I'd satisfy by bewilderment by asking here... so... yeah, what's up with that? --Jeremy ~/src/macports/trunk/base $ svn ci -m "Updated list of outdated os versions and rebuilt configure with newer autoconf that searches for X11 properly (looking for libX11.dylib instead of just libX11.so)" Sending base/configure Sending base/configure.ac Transmitting file data .svn: Commit failed (details follow): svn: While preparing '/Users/jeremy/src/macports/trunk/base/configure' for commit svn: Inconsistent line ending style ~/src/macports/trunk/base $ svn pl configure Properties on 'configure': svn:executable svn:keywords svn:eol-style ~/src/macports/trunk/base $ svn diff configure.ac Index: configure.ac =================================================================== --- configure.ac(revision 42677) +++ configure.ac(working copy) < at >< at > -31,7 +31,7 < at >< at > AC_WARN(This version of Mac OS X is not supported) AC_WARN(Please upgrade at http://store.apple.com/) ;; - 10.1.[[0-4]]|10.2.[[0-7]]|10.3.[[0-8]]|10.4.[[0-8]]) + 10.1.[[0-4]]|10.2.[[0-7]]|10.3.[[0-8]]|10.4.[[0-9]]|10.4.10|10.5. [[0-4]]) AC_WARN(This version of Mac OS X is out of date) AC_WARN(Please run Software Update to update it) ;;

1.7.0 beta 1 tagged and ready to test

Bryan Blackburn — 2008-11-29T08:40:18

A 1.7.0 branch has been created [1] and a tag for 1.7.0 beta1 is available for testing [2]. Considering the stability of trunk lately, this will hopefully be the only beta and we can move to a release candidate soon, barring issues. When testing, be sure to check the 1.7.1 milestone [3] as there are a few issues already known which have been moved to 1.7.1 so a 1.7.0 can be pushed out the door to finally (finally!) get people away from the postflight and Tcl environment problems. So everyone test it out, and be sure to have a look at the long list of changes [4] since 1.6.0, as there are quite a few... Bryan [1] - [2] - and [3] - [4] -

Example of a port with a custom build { } script

Ian Grant — 2008-11-27T17:05:40

Hi All I am trying to build a port which has a more complicated build procedure than just 'make xxx' I have to first build and install the main package and then go back into several subdirectories of the build directory and build and install plugins. Can anyone point me to an example port which does something like this? I guess I need to add a post-destroot { } section to do this. But how to change the working directory and run the make. Do I just use the tcl 'cd' and 'exec' commands, or is there some sophisticated error handling that I need to do? Just being able to read the default build { } script would be a good start. Where is that kept? Ian

Valgrind and Darwin (was: [42576] users/raimue)

C. Florian Ebeling — 2008-11-25T09:23:46

Are there any good news on Darwin support in Valgrind? Florian

kde4 ports

Ryan Schmidt — 2008-11-24T07:36:28

Regarding all the kde4 ports you've committed... You're fetching them all from the Subversion repository. Are distfiles not available for any of them? If there are distfiles provided, they should be used. If not, then you need to add svn as a build dependency. I recommend you declare it as "bin:svn:subversion", that way the Subversion client that Apple provides in Leopard and later can be used on those systems since it should be sufficient, and for those using Tiger or earlier or other OSes without built-in Subversion clients the subversion port will be built. What is the idea behind the line "pre-configure { file mkdir $ {worksrcpath} }"? I mentioned this earlier regarding qimageblitz but I see now it applies to all of them: /opt/local should not appear in the ports; the variable ${prefix} should be used. These ports use cmake, and I see several things you've had to do in each port to accommodate this. Should there be a cmake portgroup? Since you're gaining familiarity with what cmake needs as a result of these ports, maybe you could work on such a portgroup. For the universal variant, is there a way to make use of $ {configure.universal_archs} so that the user's selected architectures are built, instead of assuming they want ppc and i386?

X11 in Macports

Jeremy Huddleston — 2008-11-23T05:00:53

For those of you who don't know me, I took over development of X11 in OSX when Ben Byer moved on to bigger and better things at the beginning of 2009. I've been poke, prodded, nudged, and otherwise motivated into trying to "fix the X11 problem in Macports" as well... so I figured I'd make some proper introductions, and offer some suggestions to see what everyone's thoughts are on the subject before I start changing things only to have 100 people lash out at me for "breaking" something... so here goes... 1) The dependency issue X11 lives in a grey area in Macports' dependency policy. X11 is actually given as the example for something that is appropriate to use the lib:* or bin:* dependency rather than a port:* dependency, yet there are plenty of ports that are still using a port: dependency. I believe this is mainly for things like libXrender (rather than libX11) as a legacy of what was available in Tiger's X11. I'd very much like to use anything in /usr/X11/* over installing a duplicate in /opt/ local, and I'm sure others are in the same boat. I have seen a fair share of bug reports on xquartz-dev that came about simply because the macports version didn't have a fix that was in the system version or macports config files (eg: for fontconfig) didn't match system configurations, so users were wondering why some fonts weren't available in some programs. I intend to go through all the x11 related ports and update dependencies to be lib: or bin: where appropriate instead of port: (if a port is not nomaintainer or openmaintainer, I will file a bug in trac to be on the safe side... unless general consensus here is that such reports would be overkill and I should just do it myself) 2) The other dependency issue Now, for what port to actually depend on... Quickly grepping though the code, I have seen the following dependencies for libX11: lib:libX11.6:XFree86 lib:libX11.6:xorg lib:libX11:XFree86 lib:libX11:xorg lib:libX11:xorg-libX11 I'd like to standardize this to be xorg-libX11 3) The old monolith xorg and XFree86 I'd like to eventually punt these in favor of having just one X11 solution in Macports based on the latest release. Thoughts?

Question regarding new Python ports and PortGroup

Perry Lee — 2008-11-22T22:39:08

For new Python ports, what should the PortGroup be set to? I recently noticed the warning message "Warning: This portgroup is deprecated and will be removed in a future version!" while running a portindex. Thanks, Perry

Macports Installation instructions

William Davis — 2008-11-22T16:49:27

re: http://trac.macports.org/wiki/InstallingMacPorts I know told our former Release Engineer that the directions given on this page concerning setting the DISPLAY env value were incorrect for Mac OS 10.5 and later. He wrote me that he had updated this. I just reviewed the page and note that it still omits mention that setting $DISPLAY=:0 is incorrect for OS 10.5. Was this somehow changed back or what? Ill post this as a trac ticket shortly William Davis frstanATbellsouthDOTnet Mac OS X.5.5 Darwin 9.5.0 XQuartz 2.3.2_rc1 (xorg-server 1.4.2-apple23) Mac Mini Intel Duo < at > 1.86 GHz Mundus vult decepi, ego non

Port update needs commit

Luis O'Shea — 2008-11-21T01:25:00

Could someone commit my update to the asymptote port? See Ticket #13249 (http://trac.macports.org/ticket/13249). Note that this is a closed ticket, but I have been using it to attach updates. Thanks, Luis

MacPorts 1.7.1 milestone created

Joshua Root — 2008-11-20T17:04:08

I've created a MacPorts 1.7.1 milestone on Trac. I think we should move most of the open tickets from the 1.7.0 milestone to 1.7.1, and release a 1.7.0 beta. - Josh

Too many libconfig's

David Evans — 2008-11-19T00:57:23

I was trying to install ntfsprogs +crypto today and found that it failed configuration looking for a pkg-config file for libconfig. We have a port libconfig but it doesn't provide pkg-config files and definitely isn't the one that ntfsprogs is looking for (completely different API). The homepage for our libconfig is http://www.rkeene.org/oss/libconfig Found the libconfig that ntfsprogs is looking for at http://www.hyperrealm.com/libconfig/ So the question is how to differentiate these two packages: 1) Current libconfig port is not referenced by any other port based on grep of the current dports tree. Could replace this one with the new one but they really are different packages and someone might be using the current one somewhere. 2) Commit the new libconfig package as libconfig-new or the like (suggestions welcome) and make ntfsprogs depend upon it. 3) Rename the existing one (libconfig-old) and make the new one libconfig. 4) Something else. Ideas and suggestions are solicited and appreciated. By the way, the newer package has both C and C++ interfaces which may be the story behind this ticket: http://trac.macports.org/ticket/14035

charset.alias bug

Vincent Lefevre — 2008-11-15T02:18:26

At least 5 ports installed a broken ${prefix}/lib/charset.alias file: http://trac.macports.org/ticket/11474 http://trac.macports.org/ticket/11968 http://trac.macports.org/ticket/16152 http://trac.macports.org/ticket/17084 Since this seems to be a more or less global problem, shouldn't the removal of this file be handled by the base?

Grails port updated to 1.0.4

Tomas Lin — 2008-11-14T17:33:19

Grails has been updated to 1.0.4, and the port file is openmantainer. https://trac.macports.org/ticket/17246 can someone take a look at this ticket? Thanks, Tomas

gnunextstep-gui

William Davis — 2008-11-13T04:25:59

j/GSNibLoader.o obj/NSPasteboard.o -L/opt/local/lib -L/opt/ local/GNUstep/Local/Library/Libraries/ -L/opt/local/GNUstep/System/ Library/Libraries/ -lgnustep-base -laudiofile -laspell -lungif -lpng -ltiff -lz -ljpeg -lm && (cd ./obj; rm -f libgnustep-gui.dylib; if [ "libgnustep-gui.dylib.0.12" != "libgnustep-gui.dylib.0.12.0" ]; then rm -f libgnustep-gui.dylib.0.12; ln -s libgnustep-gui.dylib.0.12.0 libgnustep-gui.dylib.0.12; fi; ln -s libgnustep-gui.dylib.0.12.0 libgnustep-gui.dylib) ld warning: duplicate dylib /opt/local/lib/gcc42/libgcc_s.1.dylib ld: file not found: /opt/local/lib/libffi-2.1.dylib /usr/bin/libtool: internal link edit command failed gnumake[2]: *** [obj/libgnustep-gui.dylib.0.12.0] Error 1 gnumake[1]: *** [libgnustep-gui.all.library.variables] Error 2 gnumake: *** [internal-all] Error 2 Warning: the following items did not execute (for gnustep-gui): org.macports.destroot org.macports.build DEBUG: Error: Unable to upgrade port: 1 William Davis frstanATbellsouthDOTnet Mac OS X.5.5 Darwin 9.5.0 XQuartz 2.3.2_beta3 (xorg-server 1.4.2-apple22) Mac Mini Intel Duo < at > 1.86 GHz Mundus vult decepi, ego non

using port -R

William Davis — 2008-11-13T04:09:11

using sudo port -unR upgrade foo {libsoup in the present case}: ..... --> Fetching gnome-applets DEBUG: Executing org.macports.fetch (gnome-applets) ---> gnome-applets-2.24.0.tar.bz2 doesn't seem to exist in /opt/local/ var/macports/distfiles/gnome-applets/gnome-applets/gnome-applets/gnome- applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets/gnome- applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets ---> Attempting to fetch gnome-applets-2.24.0.tar.bz2 from http://mandril.creatis.insa-lyon.fr/linux/gnome.org/sources/gnome-applets/2.24/ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 44 7291k 44 3215k 0 0 93842 0 0:01:19 0:00:35 0:00:44 96460 I hope this is fixed in 1.7............ William Davis frstanATbellsouthDOTnet Mac OS X.5.5 Darwin 9.5.0 XQuartz 2.3.2_beta3 (xorg-server 1.4.2-apple22) Mac Mini Intel Duo < at > 1.86 GHz Mundus vult decepi, ego non

Typo in dp2mp-move code in dmg preflight

Ryan Schmidt — 2008-11-12T00:46:00

Do we have a typo here? http://trac.macports.org/browser/trunk/base/portmgr/dmg/preflight? rev=32397#L47 [ ! -d /opt/local/share/darwinports ] || rm -rf /opt/local/darwinports Shouldn't that be [ ! -d /opt/local/share/darwinports ] || rm -rf /opt/local/share/ darwinports It looks like this typo was introduced here: http://trac.macports.org/changeset/26518

portindex updates

William Davis — 2008-11-09T14:03:04

Strange errors with port

David Evans — 2008-11-08T01:25:28

Since upgrading trunk from svn today, port randomly crashes with the following error types: segmentation fault buss error and my favorite tclsh(16432,0xa000ed88) malloc: *** error for object 0x3128a0: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug tclsh(16432,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug The last one often (but not always) occurs at the end of the configuration phase. I scrubbed base and updated from svn and reinstalled with no change in this behavior. Has anyone else run into the same thing? Dave