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

Reference Portfile
by Randall Wood 08 Oct '07

08 Oct '07

Does anyone have a reference portfile that adheres to all recommended standards? Randall Wood rhwood(a)mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

1 0

cups-headers on Panther
by N_Ox 07 Oct '07

07 Oct '07

Could someone still running MP on a Panther box test the patch from ticket #12768? Regards, -- Anthony Ramine, the infamous MacPorts Trac slave. nox(a)macports.org

2 1

UPDATE: #12822 python/py-pexpect 2.1
by Adam Mercer 07 Oct '07

07 Oct '07

Hi Could someone with commit access please take a look at ticket #12822 [1] which contains a series of patches that takes maintainership and updates the Portfile to version 2.1. Cheers Adam [1] http://trac.macports.org/projects/macports/ticket/12822

2 1

Re: Split Trunk
by Ryan Schmidt 05 Oct '07

05 Oct '07

On Oct 3, 2007, at 05:05, Anders F Björklund wrote: > Rainer Müller wrote: > >> A good reason is, we could adopt new features from base in unstable >> first and merge them to stable once a new base gets released. For >> example, removing of "cd" from all ports. Or introduction of >> compiler.*. > > This was what I was thinking about, yes. Or when upgrading one port, > but "failing" to upgrade all of the dependencies in the first commit. > > Or just to get a little "quarantine" in order to test new releases > and updated ports, before introducing them on production machines ? > >> It sounds great, but are we ready to manage more than one ports tree? > > Probably not, as there isn't enough resources maintaining even one > tree. > I just think it would be a good idea, even if it moved really > really slow. > > One could start out with a copy of the "archive", and then merge ports > one by one from the "trunk" - either manually or maybe just by > timer... I think it's a bad idea, specifically because we're in such a nonoptimal state already. This topic has been discussed on the list before. You may want to look that up in the mailing list archive. Half of our portfiles (2139 of 4300) are currently unmaintained. Even ports that are maintained are not necessarily working properly. How could we in good conscience even declare that the current port collection is "stable"? How would dividing our efforts between stable and unstable branches help us to improve our ports collection faster than we do now? We don't even know which ports currently work and which don't. We don't have any automated build process that tries to build every port on every supported OS & architecture. I kinda feel that would be more useful at this point. We currently get emails or tickets occasionally asking for updates that have already occurred; the user has just forgotten to sync, or the update was just committed and the portindex has not yet been regenerated. If we introduce a quarantine of some sort whereby updates do not immediately appear to users, the frequency of these emails and tickets will increase, and we will have to deal with them, further reducing the amount of time we spend actually fixing the ports. By what mechanism would you suggest that changes move between these two hypothetical ports trees?

7 10

Re: r 29606: python25
by N_Ox 04 Oct '07

04 Oct '07

Le 4 oct. 07 à 19:49, Weissmann Markus a écrit : > On 04.10.2007, at 15:17, N_Ox wrote: > >> >> Le 4 oct. 07 à 15:05, Jyrki Wahlstedt a écrit : >> >>> >>> On 4.10.2007, at 15.51, N_Ox wrote: >>> >>>> >>>> Le 4 oct. 07 à 13:04, Jyrki Wahlstedt a écrit : >>>> >>>>> >>>>> On 4.10.2007, at 13.42, N_Ox wrote: >>>>> >>>>>> Le 4 oct. 07 à 12:26, Jyrki Wahlstedt a écrit : >>>>>> >>>>>>> <snip> >>>>>> >>>>>> What is the framework install really needed? >>>>> >>>>> E.g. py25-wxpython… >>>>> >>>> >>>> So that's py25-wxpython which is having a problem. No port >>>> should require modifications on other ports to install. >>>> >>> I wouldn't do this conclusion. It is clearly stated in wxPython >>> documentation. Moreover, framework install is something that >>> should work, even if it isn't used… >>> >> >> But you do need to go around modifying the python25 Portfile. >> I haven't said these softwares are broken, just their ports ;) >> > > The problem is that the parts of Python that make processes able to > use the Mac OS X GUI are only built IF Python is build as a framework. > This seems to be a "feature" of Python. We don't need the framework > installation - en contraire. But we do need the "make-the-GUI- > accessible" parts. If someone knows how to enable those w/o > enabling the framework build, I'll be more than happy! > > > -Markus Could you tell us which are those parts? Are you talking about IDLE? I would also like to be able to provide users a perfect python port, so let's brainstorm all of this mess. -- Anthony Ramine, the infamous MacPorts Trac slave. nox(a)macports.org

2 1

r 29606: python25
by Jyrki Wahlstedt 04 Oct '07

04 Oct '07

This was committed: r29606 | nox(a)macports.org | 2007-10-02 23:59:41 +0300 (Ti, 02 Lok 2007) | 8 lines python25 (closes #12803): * Added dynamic library build. * Added gettext dependency (for the _locale core module). * Fixed the "_environ not defined" bug. * Reworked post-destroot stage to use `move` instead of `system cd mv`. * Added md5 checksum. * Rewritten livecheck.regex to something cooler. Ok, this seems to work as advertised, but if, as I did, one drops disable-framework (to do the framework install that is really needed), the result is this: libtool -o libpython2.5.dylib -dynamic \ -all_load libpython2.5.a -single_module \ -install_name /opt/local/Library/Frameworks/Python.framework/ Versions/2.5/lib/libpython2.5.dylib \ -compatibility_version 2.5 \ -current_version 2.5 -lSystem -lSystemStubs -L/opt/local/lib /usr/bin/gcc-4.0 -L/opt/local/lib -u _PyMac_Error Python.framework/ Versions/2.5/Python -o python.exe \ Modules/python.o \ -L. -lpython2.5 -ldl i686-apple-darwin8-gcc-4.0.1: Python.framework/Versions/2.5/Python: No such file or directory make: *** [python.exe] Error 1 With the previous version I could build a framework install, albeit a bit misconfigured, but this breaks it. I'll look into this, but I don't have much time to use at the moment, so I'd be grateful of anyone's help here. ! ! Jyrki Wahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386

3 7

Request: commit 12654, update postgis to 1.3.1
by Frank Mcpherson 04 Oct '07

04 Oct '07

Could someone with permissions please commit this ticket? Thanks, Frank

5 8

Re: [29634] trunk/dports/devel/pcre/Portfile
by N_Ox 04 Oct '07

04 Oct '07

Le 4 oct. 07 à 09:43, source_changes(a)macosforge.org a écrit : > Revision 29634 > Author jkh(a)macports.org > Date 2007-10-04 00:43:51 -0700 (Thu, 04 Oct 2007) > Log Message > Given that utf8 is the "defacto standard" encoding for MacOSX, > make it supported by default (I can see no particularly compelling > reason to make it a variant). > Modified Paths > trunk/dports/devel/pcre/Portfile Please read `configure --help` before making such changes: configure --help: --enable-unicode-properties enable Unicode properties support (implies --enable-utf8) configure.ac: # Make sure that if enable_unicode_properties was set, that UTF-8 support # is enabled. # if test "x$enable_unicode_properties" = "xyes" then if test "x$enable_utf8" = "xno" then AC_MSG_ERROR([support for Unicode properties requires UTF-8 support]) fi enable_utf8=yes fi By the way, this port is not openmaintained, please file a ticket if you have any complaint. Regards, -- Anthony Ramine, the infamous MacPorts Trac slave. nox(a)macports.org

1 0

Re: [29634] trunk/dports/devel/pcre/Portfile
by Ryan Schmidt 04 Oct '07

04 Oct '07

On Oct 4, 2007, at 02:43, source_changes(a)macosforge.org wrote: > Revision: 29634 > http://trac.macosforge.org/projects/macports/changeset/29634 > Author: jkh(a)macports.org > Date: 2007-10-04 00:43:51 -0700 (Thu, 04 Oct 2007) > > Log Message: > ----------- > Given that utf8 is the "defacto standard" encoding for MacOSX, make it > supported by default (I can see no particularly compelling reason > to make it > a variant). > > Modified Paths: > -------------- > trunk/dports/devel/pcre/Portfile > > Modified: trunk/dports/devel/pcre/Portfile > =================================================================== > --- trunk/dports/devel/pcre/Portfile 2007-10-04 07:33:20 UTC (rev > 29633) > +++ trunk/dports/devel/pcre/Portfile 2007-10-04 07:43:51 UTC (rev > 29634) > @@ -28,7 +28,7 @@ > rmd160 42bc33e5592c23c7eb337f8fcfab77fb290aed61 > > configure.args --docdir=${prefix}/share/doc/${name}-${version} \ > - --enable-unicode-properties > + --enable-unicode-properties --enable-utf8 > > post-configure { > if {! [variant_isset doc]} { Did the maintainer OK that change? If this changes what's built, shouldn't the port's revision have been incremented?

1 0

MacPorts (and our ports) on Leopard
by Juan Manuel Palacios 04 Oct '07

04 Oct '07

Hello to all those who have approached us asking about the state of MacPorts (and our ports) on the up-coming Leopard platform. On the "To:" field are only the last ones I can remember off the top of my head, but please do consider these words extensive to anyone wondering about MacPorts & Leopard & NDA. Following is what should be considered our official stance on the issue, given the NDA binding those with Leopard seeds and the area of the system we, MacPorts, most commonly deal with. MacPorts itself is Leopard ready, so you shouldn't see any problems using it (MacPorts itself, things like the port(1) command and whatever else) on the new platform. That, however, does not necessarily apply to the software MacPorts distributes, the ports themselves that is. They either work satisfactorily (should be most of them, hopefully), compile & fail to work to some extent for whatever reason, or don't even compile at all to begin with, depending on the port and its build particularities. Some of us have been fixing these failures (of either kind) on a case by case basis (basically the only way it can be done) and committing "platform darwin 9" code blocks for each "fixed" Portfile to our repo. Since we mostly deal with the BSD (& UNIX) layer of the OS, which has been publicly discussed by Apple already in the case of Leopard, it's NDA safe for us to commit these fixes and make them available to users at this early stage. However, if in doubt, if you fear you might break your NDA with any particular question/comment/Leopard-specific-fix, please do not hesitate to contact us (portmgr) privately for some further advice (macports-mgr(a)lists.macosforge.org) Other than that, feel free to openly submit Leopard specific patches to our trac tickets db, committers will include them into the tree as time becomes available to them. Thanks for your interest in the future of the project, much appreciated! Regards,... -jmpp

1 0