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

p5-berkeleydb dyld problem
by Cyril Bellot 12 Jun '07

12 Jun '07

Hello, Is there anyone here successfully using p5-berkeleydb ? I have a linking problem and wanted to check it out before posting a ticket : $ /opt/local/bin/perl -wc -T postgrey dyld: lazy symbol binding failed: Symbol not found: _db_version Referenced from: /opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level/auto/BerkeleyDB/BerkeleyDB.bundle Expected in: dynamic lookup dyld: Symbol not found: _db_version Referenced from: /opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level/auto/BerkeleyDB/BerkeleyDB.bundle Expected in: dynamic lookup Trace/BPT trap Maybe a linking problem at build, but I am not sure as the fail is about a dynamic lookup. $otool -L /opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level/auto/BerkeleyDB/BerkeleyDB.bundle /opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level/auto/BerkeleyDB/BerkeleyDB.bundle: /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.4.1) I've allready tried to reinstall this port...

2 7

berkeleydb version duplication
by markd＠macports.org 12 Jun '07

12 Jun '07

I see that db4 is at version 4.3, so it is duplicated by the db43 port, though not entirely because the lib locations are different. In addition to the duplication, the library names and locations aren't consistent the way it is. The following ports depend on db4, should any of them depend on db44? db4 - libgda, libgda3, openldap, prothon, cyrus-imapd, exim, isync, mutt-devel, spamprobe, netatalk, rb-bdb, xastir db44 - many db45 - a few db41 - no dependents db42 - no dependents db43 - no dependents Mark

2 1

Re: Automatic out-of-dateness checking for base and ports tree
by Glen Whitney 12 Jun '07

12 Jun '07

On Jun 7, 2007, at 9:13 PM, Ryan Schmidt <ryandesign(a)macports.org> wrote: >> This would require no periodic checking, other than the `port sync` >> which has to happen anyway. Nor would there be any possibility of >> the user having problems in the intermittent period between the >> server update and their check. > > Why do we even have two commands -- sync and selfupdate? Why can't we > just have a single command which always does the right thing? What if (for development/testing purposes) you had a branch of base from macports-1.4.40 installed, say, and you did a selfupdate? Wouldn't that either fail or overwrite your branch with the standard macports-1.4.42? Yet you might want to update the portfiles even though you were running with a branched base (and at least for me, "port sync" is a lot faster than "svn update" for grabbing the latest portfiles). To me, that provides justification for a "port sync" separate from "port selfupdate" -- I have used "port sync" for this reason. Of course, I could be mistaken about what happens with a "port selfupdate" when your current installation is a branch, but I've never been brave enough to try it, lest things end up in a muddled state. Regards, Glen

1 0

Re: where do feature requests go?
by Ryan Schmidt 11 Jun '07

11 Jun '07

On Jun 11, 2007, at 02:05, paul beard wrote: > Still wondering why my distfiles have to come from so far away. Because nobody has programmed (or discussed) an alternative. I'm Cc'ing the -dev list, where discussions of this nature (developing MacPorts) should probably take place. When you reply, please edit -users out of the addressees and let's continue this discussion only on -dev. > I would create a more formal feature request but I can't access > anything at MacOSForge. Clearly that's a separate issue, but we should address that too. Please tell us (on -users) what problems you're having. Before we file a feature request in Trac, though, we should discuss on the mailing list what the feature should do. > Is there some way for the lists of mirrors to be associated with > the user's timezone (gdate +%Z value) so that the load can be > distributed around more evenly, users get distfiles faster, and > mirror sites at the top of the list don't get pounded? > > {prefix}/share/darwinports/resources/port1.0/fetch/mirror_sites.tcl > Actually for some of these, it could be done by hemisphere or > continent ;-) > > set portfetch::mirror_sites::sites(gnome) { > http://mandril.creatis.insa-lyon.fr/linux/gnome.org/ > http://mirror.aarnet.edu.au/pub/GNOME/ > http://ftp.unina.it/pub/linux/GNOME > http://fr.rpmfind.net/linux/gnome.org/ > http://fr2.rpmfind.net/linux/gnome.org/ > http://ftp.acc.umu.se/pub/GNOME/ > http://ftp.belnet.be/mirror/ftp.gnome.org/ > http://ftp.linux.org.uk/mirrors/ftp.gnome.org/ > http://ftp.nara.wide.ad.jp/pub/X11/GNOME/ > http://ftp.gnome.org/pub/GNOME/ > ftp://mirror.pacific.net.au/linux/GNOME > ftp://ftp.dataplus.se/pub/GNOME/ > ftp://ftp.dit.upm.es/pub/GNOME/ > ftp://ftp.no.gnome.org/pub/GNOME/ > ftp://ftp.isu.edu.tw/pub/Unix/Desktop/GNOME/ > ftp://ftp.nara.wide.ad.jp/pub/X11/GNOME/ > ftp://ftp.chg.ru/pub/X11/gnome/ > ftp://ftp.kddlabs.co.jp/pub/GNOME/ > ftp://ftp.dti.ad.jp/pub/X/gnome/ > } I think the suggestion has merit in principle, though I wouldn't necessary do it by time zone. SourceForge has implemented something like this, where you access one central URL to download anything, and it redirects you to a nearby mirror, based on your IP. I don't know if they do it by country or what, but I know there are databases (free ones, even) that will tell you what country an IP address is in, so that's a reasonable way to do it. One solution would be to have a script (like a PHP script*) available on www.macports.org which we could call to download files from our various master_sites groups (like the gnome group you've quoted above) with a URL like: http://example.macports.org/download/from/gnome/sources/pango/1.16/ pango-1.16.4.tar.bz2 http://example.macports.org/download/from is the download script gnome is the group sources/pango/1.16/pango-1.16.4.tar.bz2 is the path used on servers in that group In this scenario, the list of gnome mirrors (and other groups from mirror_sites.tcl) would migrate to this "download" script, which would also know (or automatically find out) what country each mirror is in. And for each incoming request, it would find out the visitor's IP and direct them to one of the mirrors in their country. We obviously also need a solution for when there is no mirror in the visitor's country. We probably need a table that says which countries are near which other countries. Maybe such data can also be downloaded for free. If we can even just get lat/long coordinates for each country, MySQL 5 has support for spacial queries which may help us find other nearby servers. I guess this would be one aspect where doing it by time zone might simplify things... Finding out the visitor's time zone is easy (on the client side), and finding out what time zones are near other time zones is also easy. Finding out which time zone a given server is in might also be possible... though I can't off the top of my head think of an automated way... The headers the servers return seem to always be GMT... Also, I'm not sure how much load this would add to www.macports.org. And I'm not sure if it would be seen as a bad thing that the mirror list becomes a server-side thing, not a client-side thing. Though to me it seems like a reasonable good idea. As expressed above, the idea would only handle the common master_sites groups. It wouldn't deal with other ports that define several master_sites. A different form of the above idea would be a download URL that just says which port and which file to download, with a URL like: http://example.macports.org/download/pango/pango-1.16.4.tar.bz2 The "download" script would read the portfile and get its list of master_sites, so this would work both for portfiles that use master_sites groups and those that define the sites individually. For each master_site, determine its IP, and from that, its country (and cache this). Get the visitor's IP, and thus country, compare, find match, redirect for download. Same caveat as above regarding visitors that don't have a mirror in their country. There's probably a way to turn this around and do it a more "MacPorts"-like way where the country data is either embedded into the PortIndex or into another file that like the PortIndex gets automatically updated at some interval. This way clients aren't constantly pinging the MacPorts web site to get each file's download location; they'd already know. A less-automated solution could be that for each master_site defined in master_sites.tcl and for each master_site defined in each portfile, one must specify the country code. The port command can then determine what country the user is in (e.g. by pinging a simple script on the server which returns the country code -- e.g. http:// example.macports.org/country.php -- and this can be cached on the client side for some interval -- or since we only support Mac OS now, we can find a way to look up wherever the Date & Time system preferences stores its data) and see which mirror to download from. I think I don't like this option because it places too great a burden on the port authors to determine and specify each master_site's country. Since we can figure it out, we should do so, and not make the port author do it. I'm just throwing ideas out there. Any others? Any comments on my ideas? What's good, what's bad? * I just say PHP script because I like to write PHP scripts. It could of course be in any language.

2 2

About new default configure-{c(pp|xx)?,ld}flags
by N_Ox 11 Jun '07

11 Jun '07

Hello, The new configure flags change made in 1.4 seems to cause problems with some ports (at least 2, maybe more). This change introduces things like default ldflags -L/opt/local/lib. The problem with these flags is that some ports write ENV flags before the configure script ones. On a port upgrade, this causes gcc to include the installed headers instead of the distfile ones, the same goes for ld and liking against libs. As this is useful only if the port depends on some other ports, why not put these defaults settings only if the port does depend on another one? -- Anthony Ramine, a lazy french student. nox(a)macports.org

3 5

livecheck.url containing semicolon
by Ryan Schmidt 10 Jun '07

10 Jun '07

I want to set up livecheck for fontconfig and I want to use the following livecheck URL: ${homepage}release/?C=M;O=D How can I do this? I've tried: livecheck.url ${homepage}release/?C=M;O=D --> doesn't work because it gets cut off at the semicolon; "port -dv livecheck" shows: DEBUG: Fetching http://fontconfig.org/release/?C=M livecheck.url ${homepage}release/?C=M\;O=D --> doesn't work because of "unsupported protocol" which is weird: DEBUG: Fetching {http://fontconfig.org/release/?C=M;O=D} Error: cannot check if fontconfig was updated (unsupported protocol) livecheck.url "${homepage}release/?C=M;O=D" --> doesn't work for the same reason as above: "unsupported protocol". livecheck.url ${homepage}release/?C=M%3BO=D --> doesn't work because the server does not deliver the same response when I encode the semicolon as %3B.

3 5

Re: [26000] trunk/dports/games/neverball/Portfile
by Ryan Schmidt 09 Jun '07

09 Jun '07

On Jun 9, 2007, at 01:37, source_changes(a)macosforge.org wrote: > Revision: 26000 > http://trac.macosforge.org/projects/macports/changeset/26000 > Author: markd(a)macports.org > Date: 2007-06-08 23:37:45 -0700 (Fri, 08 Jun 2007) > > Log Message: > ----------- > Closes #11834. Maintainer cleanup of portfile. > > Modified Paths: > -------------- > trunk/dports/games/neverball/Portfile > > Modified: trunk/dports/games/neverball/Portfile > =================================================================== > --- trunk/dports/games/neverball/Portfile 2007-06-09 06:25:49 UTC > (rev 25999) > +++ trunk/dports/games/neverball/Portfile 2007-06-09 06:37:45 UTC > (rev 26000) > @@ -2,34 +2,32 @@ > > PortSystem 1.0 > > -name neverball > -version 1.4.0 > -revision 1 > -categories games > -platforms darwin > -maintainers mvitocruz(a)gmail.com > -description Tilt the floor to roll a ball through an obstacle > course. > -long_description Tilt the floor to roll a ball through an obstacle \ > - course before time runs out. Neverball is part puzzle \ > - game, part action game, and entirely a test of skill. > +name neverball > +version 1.4.0 > +revision 2 > +categories games > +platforms darwin > +maintainers mvitocruz(a)gmail.com > +description Tilt the floor to roll a ball through an obstacle course. > +long_description \ > + Tilt the floor to roll a ball through an obstacle \ > + course before time runs out. Neverball is part puzzle \ > + game, part action game, and entirely a test of skill. > > -homepage http://icculus.org/neverball/ > +homepage http://icculus.org/neverball/ > master_sites ${homepage} > -checksums md5 a6cd860f1c2b7d8cecbcfc05ff228ef0 > -patchfiles patch-Makefile.diff patch-ball-main.c patch-putt-main.c > +checksums md5 a6cd860f1c2b7d8cecbcfc05ff228ef0 > +patchfiles patch-Makefile.diff patch-ball-main.c patch-putt-main.c > > -depends_lib bin:sdl-config:libsdl \ > - lib:libSDL_image:libsdl_image \ > - lib:libSDL_mixer:libsdl_mixer \ > - lib:libSDL_ttf:libsdl_ttf > +depends_lib bin:sdl-config:libsdl \ > + lib:libSDL_image:libsdl_image \ > + lib:libSDL_mixer:libsdl_mixer \ > + lib:libSDL_ttf:libsdl_ttf > > configure { > reinplace "s|./data|${prefix}/share/${name}|g" ${worksrcpath}/ > share/config.h > } > > -build.env CFLAGS=-I${prefix}/include \ > - LDFLAGS=-L${prefix}/lib > - > destroot { > xinstall -d -m 755 ${destroot}${prefix}/share/ > file copy ${worksrcpath}/data ${destroot}${prefix}/share/${name} The port revision should not have been bumped if the only changes were portfile cleanup. Only bump the revision if you want to force all users who already have the port installed to reinstall it.

1 0

New port: ajp-wsgi
by Bryan Blackburn 08 Jun '07

08 Jun '07

I forgot to email the list when I first added the ticket for ajp- wsgi, but I've just updated the ticket for version 1.0: <http://trac.macports.org/projects/macports/ticket/11581> If someone could commit, it'd be much appreciated. Bryan

1 0

Automatic out-of-dateness checking for base and ports tree
by Ryan Schmidt 08 Jun '07

08 Jun '07

With some of the fundamental changes that have gone on in MacPorts 1.4.x since the 1.4.0 release, and since we only do downloadable disk images for the major releases, we have this problem that a lot of people seem to be downloading 1.4.0 and attempting to use it before selfupdating and reporting a whole slew of problems to the list which we then have to diagnose and it's always the same suggestion to fix it: update MacPorts. Or, people are installing MacPorts and not realizing that they have to periodically inform it to update itself. People may be under one of two reasonable expectations: 1) software keeps itself up to date, or 2) software that is not updated continues to function. MacPorts does neither: it doesn't auto-update the base software, but if you update the ports tree (or do a fresh install of MacPorts, which pulls down a current ports tree), it may not work with your old version of MacPorts. And this is a problem I think we should solve. Below is one such message. Steve says it might be nice if MacPorts would suggest updating itself if it encounters an error. I think we can probably do better than that, can't we? Couldn't we have MacPorts periodically (weekly?) check if a new version of MacPorts is available, and alert the user to this fact if they haven't run selfupdate themselves? I don't mean a cron task; I just mean, if the user happens to be running "port" right now and it's been a week since the last selfupdate, then print a message. There should be a file somewhere indicating the last time MacPorts checked its version, and this file would not exist for new installs, such that the first time somebody runs "port", it would check to see if it's outdated. It wouldn't have to update itself automatically. But it should inform the user if it is outdated. For those who are paranoid about apps phoning home, there could be a way to disable this feature. Something similar could be done for the ports tree, but for that we probably don't even need to check the server -- we know that ports get updated very frequently. We could just store the last time that a sync was done, and if it's been awhile (a day? a week?), alert the user that they should sync again. Thoughts? Begin forwarded message: > From: Steve Dekorte <steve(a)dekorte.com> > Date: June 7, 2007 02:14:49 CDT > To: Ryan Schmidt <ryandesign(a)macports.org> > Cc: macports-users(a)lists.macosforge.org > Subject: Re: llvm port problem > > > On 6 Jun 2007, at 06:36 pm, Ryan Schmidt wrote: > >> I tried it just now, and llvm 2.0_0 installs just fine for me on >> Intel Core 2 Duo with Mac OS X 10.4.9 and MacPorts 1.4.42 and >> Xcode 2.4.1. >> >> What MacPorts version do you have? Is your ports tree up to date? >> Try "sudo port selfupdate" to update both. >> >> Do you have the latest Xcode? > > Thanks Ryan, the port version was the problem. It might save some > frustration and support requests if port suggest what you did when > a port fails.

3 4

HEADS-UP: merging dp2mp-move into trunk ASAP now
by Juan Manuel Palacios 07 Jun '07

07 Jun '07

Well, the subject of this post pretty much says what it is all about, I'm ready to merge my branch back into trunk waiting only for some adjustments on the rsync server to take place. But the reason I consider this heads-up necessary is that this merge, as opposed to others we've seen around here, will change not only naming of some of the functions/routines/procs in our sources but also paths in svn (like base/src/darwinports1.0 to base/src/macports1.0, among others), so I would advice anyone writing new code against base to use branches/dp2mp-move/base as the point of reference from now on, as that will become trunk really soon now. I would also prefer it, if possible, that you don't commit to base until this merge is in, but I understand sticking to that petition can be a bit of a nuisance at times... so consider it only that, a petition from me. If you can withhold from committing to base until my merge is in I would appreciate it, but other than consider trunk open for work. About timing, as already said the commit should come really soon now, so in any case it's not much what you would have to wait holding your commits. I'm all ready on my side but I need to wait for Kevin to make some adaptations on the rsync server, we need to coordinate both things (otherwise "sync" and "selfupdate" will break for existing users). We're aiming for some time next Monday or Tuesday, if we don't get lucky and happen to sync up and do it earlier. I'll let the list know in any case. Thanks for your attention and help! Regards,... -jmpp

1 0