January 2008 - macports-dev - lists.macosforge.org

MacPorts 1.6.0 dmg now available for Panther (Mac OS X 10.3)
by Boey Maun Suang 10 Jan '08

10 Jan '08

Hi everyone, Firstly, apologies for cross-posting, but I wanted to make sure everyone gets this. This message is to notify all of our wonderful Panther-using MacPorts users that we've finally ironed out the bugs that were preventing MacPorts 1.6.0 from operating correctly on Panther, and have now uploaded a Panther dmg incorporating our fixes, which you can now download (you can fetch it directly [1], or go via the installation page of the MacPorts website [2]). A big thank you to Juan Manuel Palacios and Kevin Ballard for providing the fixes, to Chris Janton for confirming that one particular problem wasn't just with my build machine, and to all of the Panther users who reported the problems! For those Panther users who like installing MacPorts from source instead of from our dmgs, the 1.6.0 tarball doesn't yet incorporate the Panther fixes, but we'll be releasing a 1.6.1 update soon, so you should have to wait too long. If you're really keen, however, you can still do a 1.6.0 source install by applying a few patches from our repository. Those not interested can safely skip this bit, but if you are interested, here's what to do: === Start of patch instructions === 1. Download and extract the MacPorts tarball as normal (see the "Source Install" section of the MacPorts Guide [3]). 2. Download the changesets 32105 [4], 32212 [5], 32514 [6] and 32525 [7] from the MacPorts repository, copying or saving them to the "MacPorts 1.x.x" directory that the MacPorts tarball extracted itself into. If your browser displays the patches instead of saving them, use your browser's "File > Save As..." menu item -- they should save with filenames like "changeset_32105.diff". 3. At the command line, change into the directory as per the MacPorts Guide [3], but before running the "./configure" command as described there, run the following commands (one for each of the changeset files you saved above): % patch -p3 < changeset_32105.diff % patch -p3 < changeset_32212.diff % patch -p3 < changeset_32514.diff % patch -p3 < changeset_32525.diff 4. Follow the rest of the source install procedure as normal. === End of patch instructions === Don't worry, we won't be making you source installers get used to doing things like this! Once again, apologies to all our Panther users out there, and thanks for using MacPorts. Wishing you all a happy 2008, Boey Maun Suang [1] http://svn.macports.org/repository/macports/downloads/MacPorts-1.6.0/MacPor… [2] http://www.macports.org/install.php [3] http://guide.macports.org/#installing.source [4] http://trac.macosforge.org/projects/macports/changeset/32105?format=diff&ne… [5] http://trac.macosforge.org/projects/macports/changeset/32212?format=diff&ne… [6] http://trac.macosforge.org/projects/macports/changeset/32514?format=diff&ne… [7] http://trac.macosforge.org/projects/macports/changeset/32525?format=diff&ne… -- Boey Maun Suang (Boey is my surname) Email: boeyms(a)macports.org

1 0

Re: [32627] branches/release_1_6/base/portmgr/dmg/postflight
by Ryan Schmidt 10 Jan '08

10 Jan '08

jmpp, did you mean to change 32627, 32628 and 32629 only on the 1.6 branch and not in trunk?

2 1

Re: [32194] trunk/base/src/port1.0/portconfigure.tcl
by Anders F Björklund 09 Jan '08

09 Jan '08

> Revision > 32194 > Author > mww(a)macports.org > Date > 2007-12-19 06:44:11 -0800 (Wed, 19 Dec 2007) > > Log Message > make the universal flags take the archs from a single source (thanks > to ryandesign for the idea), enable 64 bit universal builds This change makes all +universal ports with an UI based on Carbon break, since it (Carbon) doesn't support 64-bit... (and especially not x86_64) http://developer.apple.com/documentation/Carbon/Conceptual/ Carbon64BitGuide/ "Most APIs in Mac OS X v10.5 are available to both 32-bit and 64-bit applications, but some APIs commonly used by Carbon applications are not. In particular, the APIs used to implement a Carbon user interface are generally available only to 32-bit applications. If you want to create a 64-bit application for Mac OS X, you need to use Cocoa to implement its user interface." Never mind that it also makes each one twice as big (4 times the original) > > +# > +# internal functions to determine the "-arch xy" flags for the > compiler > +# -> these should preferably get a more global scope, perhaps be > user-configurable? > +set universal_archs {ppc ppc64 i386 x86_64} > + This should probably be reverted back to "set universal_archs {ppc i386}" ? --anders

3 2

Re: [32596] trunk/dports/print/libpaper/Portfile
by Ryan Schmidt 09 Jan '08

09 Jan '08

On Jan 8, 2008, at 15:51, ricci(a)macports.org wrote: > Modified: trunk/dports/print/libpaper/Portfile > =================================================================== > --- trunk/dports/print/libpaper/Portfile 2008-01-08 21:48:43 UTC > (rev 32595) > +++ trunk/dports/print/libpaper/Portfile 2008-01-08 21:51:10 UTC > (rev 32596) > @@ -2,8 +2,8 @@ > > PortSystem 1.0 > name libpaper > -version 1.1.14-3 > -set base_version 1.1.14 > +version 1.1.21 > +set base_version 1.1.21 > revision 1 FYI: Instead of listing the version number twice, you could list it just once in ${version} and compute it for ${base_version}, like this: version 1.1.21 set base_version [lindex [split ${version} -] 0] Also, when you increase the port's version, don't forget to drop the revision down to 0 (or remove the revision line entirely which does the same thing).

2 2

Re: [32592] trunk/dports/python/py-django-devel/Portfile
by Ryan Schmidt 08 Jan '08

08 Jan '08

On Jan 8, 2008, at 15:42, erickt(a)macports.org wrote: > Revision: 32592 > http://trac.macosforge.org/projects/macports/changeset/32592 > Author: erickt(a)macports.org > Date: 2008-01-08 13:42:49 -0800 (Tue, 08 Jan 2008) > > Log Message: > ----------- > version bump to 0.96.1 > > Modified Paths: > -------------- > trunk/dports/python/py-django-devel/Portfile > > Modified: trunk/dports/python/py-django-devel/Portfile > =================================================================== > --- trunk/dports/python/py-django-devel/Portfile 2008-01-08 > 21:10:31 UTC (rev 32591) > +++ trunk/dports/python/py-django-devel/Portfile 2008-01-08 > 21:42:49 UTC (rev 32592) > @@ -4,7 +4,7 @@ > PortGroup python24 1.0 > > name py-django-devel > -version 0.96 > +version 0.96.1 > revision 1 When you bump a port's version, don't forget to drop the revision back down to 0 (or remove the revision line entirely which does the same thing). > -master_sites http://media.djangoproject.com/releases/$ > {version}/ > +master_sites http://media.djangoproject.com/releases/0.96/ Instead of changing to hard-coding the version here, you could do this as in the glib2 portfile and others: set branch [join [lrange [split ${version} .] 0 1] .] master_sites http://media.djangoproject.com/releases/$ {branch}/

1 0

libiconv
by Takeshi Enomoto 08 Jan '08

08 Jan '08

Hello Ryan, I have received an error report on g95. <http://trac.macosforge.org/projects/macports/ticket/13841> It is related to MacPorts' libiconv. MacPorts' libiconv does not have symbols iconv_*. There are libiconv_* instead. System's libiconv have both. A quick google search tells me that it is a cause of build failure of a few other packages. Could you tell me if 1) iconv_* are deprecated and I should rewrite them to libiconv_*, 2) system's libiconv should be used, or 3) I should wait an update of libiconv package? Regards, Takeshi

3 5

Re: [32334] trunk/www/install.php
by Anders F Björklund 08 Jan '08

08 Jan '08

> Revision > 32334 > Author > jmpp(a)macports.org > Date > 2007-12-25 13:33:06 -0800 (Tue, 25 Dec 2007) > > Log Message > Clarify that Leopard users need to install Xcode 3.0, while Tiger > users need 2.5 (sorry Anders, no direct link to 2.4 off apple's site > :-P). As long as you are willing to deal with the breakage from using Xcode 2.5 (like #13736 et al), feel free to recommend either... I still think 2.4(.1) is the one to use while on Tiger. But the link is the same as ever: http://connect.apple.com "Xcode 2.5 is a minor update to the Tiger tools that is functionally similar to Xcode 2.4.1. It is not considered a critical update. ... This release is recommended for developers needing to continue to use the Tiger tools while running Leopard, and serves as a transition to Xcode 3.0..." > Also switch to the now more familiar "Xcode" name, as the older > "Developer Tools" is apparently being phased out. Closes #12779. I only use the name "Developer Tools" since "Xcode Tools" is somewhat ambiguous and easily confused with Xcode.app even though it also installs a lot of BSD tools... But you can say "Xcode Tools 2.4" instead of "August 2006 Developer Tools" if you prefer that name (but not just Xcode please) So saying Developer Tools is just a personal preference of mine, that extends to FreeBSD and Fedora as well. But the name hasn't been in use since Project Builder, when everything was renamed to Xcode. I kinda expected Interface Builder to be renamed to Xgui or something too, but that never happened. --anders

2 2

Re: [MacPorts] #13352: Shortened "Assign to" list in tickets
by Ryan Schmidt 08 Jan '08

08 Jan '08

On Dec 20, 2007, at 13:29, MacPorts wrote: > #13352: Shortened "Assign to" list in tickets > -------------------------------- > +------------------------------------------- > Reporter: jmpp(a)macports.org | Owner: wsiegrist(a)apple.com > Type: defect | Status: closed > Priority: Normal | Milestone: > Component: server/hosting | Version: 1.5.2 > Resolution: fixed | Keywords: assign to list > -------------------------------- > +------------------------------------------- > Changes (by wsiegrist(a)apple.com) > > * status: new => closed > * resolution: => fixed > > Comment: > > Closing. Trac generates the list from all valid accounts, so if a > maintainer is missing they can just login to trac and they will > show up. So why do we have so few of our maintainers logging into Trac? The list of possible assignees contains only four email addresses not @macports.org, and two of those are @apple.com: kvv(a)apple.com macosforge(a)otierney.net pguyot(a)kallisys.net wsiegrist(a)apple.com But I count well over 200 maintainer email addresses in our portfiles that aren't @macports.org. How can it be that only two of our non- @macports.org maintainers are logging in? Take as an example this ticket: http://trac.macosforge.org/projects/macports/ticket/13597 It was filed by Paulo Moura, one of our maintainers. Surely he logged in in order to file the ticket. Why is his email address not showing up in the assignee list?

4 6

MacPorts 1.6.1
by Juan Manuel Palacios 08 Jan '08

08 Jan '08

So, how about a quick and simple 1.6.1 release? There are a couple of things I'd like to give a bit of a wider audience to: -) James' "load" and "unload" port actions; -) MacPorts build fixes with Universal flags turned on (usually through the MacPorts Portfile) and a Panther specific fix to search the bundled sqlite sources; -) Kevin's switch to try-catch blocks in the UI initialization in macports1.0; -) my reworked selfupdate proc, which I've already cleanup quite a bit locally. Items 2 and 3 above will help us hunt down the problems that have prevented us so far from building a Panther dmg. On the other hand, is there something currently in trunk that anyone would like to keep out of the release branch for the time being? For instance, if I'm not mistaken there are some concerns about the changes to Universal building that have gone in recently....? Regards,... -jmpp

1 0

darwinports.com
by Michael Witten 08 Jan '08

08 Jan '08

Maintainers of MacPorts, There is a fairly benign, but terribly frustrating issue with which you should deal swiftly. Somebody by the name of Mat Caughron is running a mirror of the MacPorts project at http://darwinports.com/ Unfortunately, such a usually kind favor is actually a mischievous attempt to garner advertisement revenue and glean user email addresses. While these ulterior motives are trashy, what disturbs me most is the confusion that results from 2 seemingly viable ports systems, especially since Mat Caughron not only hosts the system under the name DarwinPorts, but he also tries to hide the direct connection with MacPorts. Which one is the "correct" system? This semblance of disorganization and trashiness drives people away from open source or at least to other projects like fink. It is a branding issue. I advise the following: (1) Clarify the situation in the FAQ, in the Wiki, and on the main page. It should be stated in rather clear terms that darwinports.com is attempting to rebrand MacPorts mischievously for email gathering and unwarranted advertisement revenue. A strong statement makes it clear which project is official. (2) Explicitly state somewhere that derivatives must acknowledge MacPorts clearly; this will help with future troubles. (3) Try to negotiate the transfer of the ownership of darwinports.com to the MacPorts team; he can app- arently be contacted at Mat Caughron (408) 910-1266 caughron(a)gmail.com In any case, this subject of darwinports.com came up once in discussions: http://osdir.com/ml/opendarwin.darwinports/2004-02/msg00090.html and though Mat Caughron pretended to be a novice, who was just having fun and trying to support a project, it came to light that he had tried and is still trying to peddle other projects: http://osdir.com/ml/opendarwin.darwinports/2004-02/msg00091.html Furthermore, James Berry contacted Mat Caughron a couple of years ago in order to resolve this point of contention by initiating a transfer of the domain ownership to the project. In return, Matt Caughron required a PowerBook. With (1), it won't really matter if this transaction is refused. Sincerely, Michael Witten

5 7