From vincent-opdarw at vinc17.org Mon Oct 1 00:45:31 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:39 2007 Subject: gcc42 fails to build with texinfo 4.11 In-Reply-To: <201288D5-6ECD-46B2-B552-6817967218C5@macports.org> References: <470041FF.1050900@macports.org> <20071001013645.GN25775@prunille.vinc17.org> <201288D5-6ECD-46B2-B552-6817967218C5@macports.org> Message-ID: <20071001074531.GP25775@prunille.vinc17.org> On 2007-10-01 14:32:54 +1000, Boey Maun Suang wrote: > So, as a workaround, would there be any problems in recommending > deactivating texinfo before installing affected ports, and then > reactivating texinfo after? (I'm assuming that Mac OS X >= 10.2.0 have > makeinfo installed with the BSD subsystem; it's 4.7 on 10.4.10 here.) It would be easier to patch the gcc ports by applying the patch to their configure file. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From ryandesign at macports.org Mon Oct 1 01:19:13 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:39 2007 Subject: Trac ticket Cc list should be changeable by anybody Message-ID: Apparently our Trac install doesn't allow just anybody to add themselves to a ticket's Cc list. I think it should. Can we change it? From dluke at geeklair.net Mon Oct 1 08:12:15 2007 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue Oct 9 16:40:40 2007 Subject: UPDATE: postgrey 1.31 In-Reply-To: <46FBF754.70406@sky.fr> References: <46FBF754.70406@sky.fr> Message-ID: <37A33B23-078E-400B-A5F1-CA65DA8FAA05@geeklair.net> On Sep 27, 2007, at 2:32 PM, Cyril Bellot wrote: > Could someone have a look at this postgrey update request please : > http://trac.macosforge.org/projects/macports/ticket/12751 committed in r29589, thanks! -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071001/5e235896/PGP.bin From paulp at improving.org Mon Oct 1 09:22:48 2007 From: paulp at improving.org (Paul Phillips) Date: Tue Oct 9 16:40:40 2007 Subject: smoothing leopard Message-ID: <20071001162248.GA11681@jon.loc> Leopard is supposed to come out this month (for real this time) and there are many ports that don't build - a lot more than there are bug reports. Maybe it's not a big priority but if it's of interest I have a leopard test system and can gather data on what doesn't build and why. If there is a consensus to let leopard settle further before worrying about it, then I don't want to clutter trac with bug reports. Is there a clear delineation between what should be considered an upstream bug and what should be addressed in macports? Sometimes it's obvious but not always. -- Paul Phillips | These are the climbs that apply men's soles. Vivid | Empiricist | pull his pi pal! |----------* http://www.improving.org/paulp/ *---------- From dluke at geeklair.net Mon Oct 1 09:31:58 2007 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue Oct 9 16:40:40 2007 Subject: smoothing leopard In-Reply-To: <20071001162248.GA11681@jon.loc> References: <20071001162248.GA11681@jon.loc> Message-ID: On Oct 1, 2007, at 12:22 PM, Paul Phillips wrote: > Leopard is supposed to come out this month (for real this time) and > there are many ports that don't build - a lot more than there are bug > reports. Maybe it's not a big priority but if it's of interest I > have a > leopard test system and can gather data on what doesn't build and why. > If there is a consensus to let leopard settle further before worrying > about it, then I don't want to clutter trac with bug reports. I don't have Leopard seed access, so I haven't read the NDA, but it's possible that you are prohibited from doing that. You may want to read the NDA over to make sure you can actually do it. > Is there a clear delineation between what should be considered an > upstream bug and what should be addressed in macports? Sometimes it's > obvious but not always. When it's not clear, I think we favor a two pronged approach (first, make things 'just work' by addressing it in macports. second, follow up with upstream and remove the macports patches when it gets fixed upstream). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071001/1deab1c5/PGP.bin From jberry at macports.org Mon Oct 1 17:12:09 2007 From: jberry at macports.org (James Berry) Date: Tue Oct 9 16:40:40 2007 Subject: Heads up: MacOSForge machine reorganizations Message-ID: <4B29E0CD-5F93-476E-95E6-B094F2E280EF@macports.org> This is just a general heads up that the wonderful folks at macosforge are doing some machine migrations (more power for the masses...) in the coming days and weeks. They, and we, will try to minimize any service interruptions for MacPorts, but please be aware that this is afoot, and that there may be some temporary interrupts to mail, web, trac, svn, etc... If critical services are down, and you're not sure what's going on, you might try our irc channel, where up to date information (or perhaps flat-out speculation) will be available ;) James From afb at macports.org Tue Oct 2 00:49:11 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:40 2007 Subject: [29593] trunk/www (install.php) In-Reply-To: <20071001230437.957278213E7@cvs.opensource.apple.com> References: <20071001230437.957278213E7@cvs.opensource.apple.com> Message-ID: <7dc7df7d444973fd56dcf64cac1b7b9d@macports.org> > Log Message > * Rename the getmp.php page to a better suited install.php, update > references; > * Provide extra information in the new install.php, which I believe > should be > somewhat merged with the new guide efforts (next to be discussed on > macports-dev@). > > Modified Paths > ? trunk/www/includes/header.inc > ? trunk/www/index.php > > Added Paths > ? trunk/www/install.php > > Removed Paths > ? trunk/www/getmp.php The System Requirements of MacPorts needs to be explained better on this page. (it also needs a Don't Panic button in nice friendly letters up at the top :) ) It needs to say what versions of Mac OS X that Panther and Tiger represent... Probably "Mac OS X 10.3.9" and "Mac OS X 10.4.10" to make sure they're updated. Additionally it needs to mention Jaguar and earlier, as well as (Open)Darwin OS ? Something like "previously it also supported older versions", or "now unsupported" BTW: The binary packages for FreeBSD and Fedora are operational, so I might add those as part of the "experimental support" for those two operating system platforms... Both the BSD Makefile and RPM Specfile are rather small, so they could probably go in the "portmgr" directory directly - instead of being a separate download. Should work OK with FreeBSD 6.2 and Fedora Core 5+ / Red Hat Enterprise Linux 5, as well as with the FreeBSD "CURRENT" and Fedora "Rawhide" development versions. --anders From afb at macports.org Tue Oct 2 03:05:44 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk Message-ID: For MacPorts 1.6.0, I think you should split the "dports" trunk in two, "trunk" and "release", just as done with the "base". There is just too much port breakage with running the latest developer version on the user machines, IMHO. It also needs a cooler name... Such as "Evolution", as in: I'm running the latest MacPorts Evolution. :-) --anders From themiwi at gmail.com Tue Oct 2 04:05:28 2007 From: themiwi at gmail.com (Michael Wild) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: References: Message-ID: <470225F8.1090404@gmail.com> Anders F Bj?rklund wrote: > For MacPorts 1.6.0, > > I think you should split the "dports" trunk in two, > "trunk" and "release", just as done with the "base". > There is just too much port breakage with running the > latest developer version on the user machines, IMHO. > I second that. Or perhaps a bit a more elaborate scheme like fink uses it: namely a stable and an unstable tree. Would make things much more reliable. > It also needs a cooler name... Such as "Evolution", > as in: I'm running the latest MacPorts Evolution. :-) > If people want fancy names... > --anders > Michael From jmpp at macports.org Tue Oct 2 06:04:08 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:40 2007 Subject: [29593] trunk/www (install.php) In-Reply-To: <7dc7df7d444973fd56dcf64cac1b7b9d@macports.org> References: <20071001230437.957278213E7@cvs.opensource.apple.com> <7dc7df7d444973fd56dcf64cac1b7b9d@macports.org> Message-ID: <6B2BC1F3-97EC-471D-B824-82F266375669@macports.org> Hello Anders! Thanks for your comments & feedback, much appreciated! I wrote a bit of a long message regarding my commit, my thoughts on what's still missing and what I believe we should do with what's in other sources of information like the new guide and trac, but haven't posted so far 'cause there's gonna be a temporary outage for @macports.org mail aliases today at 9am California time (Mac OS Forge moving boxes), and I didn't want to miss any replies. I'll amend that soon-to-be-post with your comments below and release it ASAP ;-) Thanks again for the feedback, that's exactly what I need! Regards,... -jmpp On Oct 2, 2007, at 3:49 AM, Anders F Bj?rklund wrote: >> Log Message >> * Rename the getmp.php page to a better suited install.php, >> update references; >> * Provide extra information in the new install.php, which I >> believe should be >> somewhat merged with the new guide efforts (next to be discussed >> on macports-dev@). >> >> Modified Paths >> ? trunk/www/includes/header.inc >> ? trunk/www/index.php >> >> Added Paths >> ? trunk/www/install.php >> >> Removed Paths >> ? trunk/www/getmp.php > > The System Requirements of MacPorts needs to be explained better on > this page. > (it also needs a Don't Panic button in nice friendly letters up at > the top :) ) > > It needs to say what versions of Mac OS X that Panther and Tiger > represent... > Probably "Mac OS X 10.3.9" and "Mac OS X 10.4.10" to make sure > they're updated. > > Additionally it needs to mention Jaguar and earlier, as well as > (Open)Darwin OS ? > Something like "previously it also supported older versions", or > "now unsupported" > > > BTW: > The binary packages for FreeBSD and Fedora are operational, so I > might add those > as part of the "experimental support" for those two operating > system platforms... > > Both the BSD Makefile and RPM Specfile are rather small, so they > could probably > go in the "portmgr" directory directly - instead of being a > separate download. > > Should work OK with FreeBSD 6.2 and Fedora Core 5+ / Red Hat > Enterprise Linux 5, > as well as with the FreeBSD "CURRENT" and Fedora "Rawhide" > development versions. > > --anders > From jmpp at macports.org Tue Oct 2 07:44:08 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:40 2007 Subject: Trac ticket Cc list should be changeable by anybody In-Reply-To: References: Message-ID: On Oct 1, 2007, at 4:19 AM, Ryan Schmidt wrote: > Apparently our Trac install doesn't allow just anybody to add > themselves to a ticket's Cc list. I think it should. Can we change it? > This requires tweaking trac privileges for each user, which trac doesn't support out of the box. I'm currently lobbying Mac OS Forge admins to install the appropriate plugin to let us do just that (see ticket #12595), but I reckon it's gonna take some time given that they are currently moving to new servers (wooooot!). I'll inform of any updates. Regards,... -jmpp From ryandesign at macports.org Tue Oct 2 16:18:10 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: References: Message-ID: <0EAA09FD-F19B-435B-AA6B-71D80DE4D5D7@macports.org> On Oct 2, 2007, at 05:05, Anders F Bj?rklund wrote: > For MacPorts 1.6.0, > > I think you should split the "dports" trunk in two, > "trunk" and "release", just as done with the "base". > There is just too much port breakage with running the > latest developer version on the user machines, IMHO. Specifically, what? From jmpp at macports.org Tue Oct 2 23:40:44 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:40 2007 Subject: Website & documentation updates Message-ID: Hello documentation team! (and, of course, anyone else who wants to lend a hand for the heavy lifting ;-) First off, I would like to apologize for having disappeared for the last couple of weeks, that annoying "real life & work" thing hasn't left me with much extra time lately to work with you guys ;-) I hope I can still mull your interest to work on a little reorganization of our documentation priorities. As you may have seen in r29593, I recently committed a facelift to the MacPorts installation instructions in the new 'install.php' page (following some suggestions on this list), revamped & renamed from the old 'getmp.php' page. It has come to my attention, though (as some of you have already pointed out), that we are chronically and needlessly duplicating information all over the place (web pages, guide, wiki, in-source text files, etc), so I wanted to call on the doc team's initiative to stop this practice and centralize everything in a single location. The in-this-case relevant examples are a) the content of the new 'install.php' page and Chapter 1 of the new guide, and b) the overall contents of our Wiki (particularly the main page, http://trac.macports.org/) and Chapter 2 of the new guide. I am aware we're currently facing this situation simply because for a long time we lacked a coordinated documentation strategy, but I think it's time we put a stop & fix to this practice. We have been advancing rather slow on our new documentation and website efforts so far, unfortunately, so I would like to call for a small reorganization of our priorities by pulling a Steve&iPhone&Leopard move ;-) I wanted to ask you guys if it's possible for you to momentarily re-focus your energies into helping me complete the content of the new website before continuing on the new guide, so that we can finally provide a friendly project portal to newcomers ASAP. What I committed to 'install.php' is basically a) what was in the old 'getmp.php' page, plus b) some suggestions taken from this list (Ryan's and Chris', IIRC), and c) hints taken from the wiki doc "InstallingMacPorts". I believe we should reorganize these three sources by first taking from the wiki doc what's useful and then obliterating it, following with a reduction of 'install.php' to some smart cues that lead users in smart ways into specific sections of the new guide (where content from the other two sources should be concentrated). Any one up to the plate for this? Secondly, we need to start enforcing wiki documentation rules: HOTOWs like "Installing GNOME with MacPorts", "Setting up a MySQL & PHP server with MacPorts", FAQs, members' pages, etc., but no "official" MacPorts installation/usage/troubleshooting/membership/ ticketing guides and/or documents -- those belong in the *official* (new) guide. Our trac entry page (http://trac.macports.org/projects/ macports, which maps to http://trac.macports.org/projects/macports/ wiki/WikiStart) currently holds the following titles (next to which you'll find my thoughts on each): 1) http://trac.macports.org/projects/macports/wiki/InstallingMacPorts -- integrate into 'install.php' & chapter 1 of the guide and obliterate; 2) http://trac.macports.org/projects/macports/wiki/ UsingMacPortsQuickStart -- integrate into chapter 2 of the guide and obliterate; 3) http://trac.macports.org/projects/macports/wiki/GetMacPortsSource -- integrate into 'install.php' & chapter 1 of the guide and obliterate; 4) http://trac.macports.org/projects/macports/wiki/NewCommittersGuide -- integrate into the new guide (chapter 7?) and obliterate; 5) http://trac.macports.org/projects/macports/wiki/FAQ -- should remain in the Wiki, I believe (and properly advertised on the wiki's front page --as it now is--, in 'install.php' and in the guide); 6) http://trac.macports.org/projects/macports/wiki/BuildPhases -- integrate into the new guide, not too sure where, and obliterate; 7) http://trac.macports.org/projects/macports/wiki/GNOME -- perfect example of what Wiki docs should be for, just like the FAQ; 8) http://trac.macports.org/projects/macports/wiki/TracGuide -- a Trac default document, should remain in the Wiki's front page; 9) http://trac.macports.org/projects/macports/wiki/ProblemHotlist -- totally Wiki document; 10) http://trac.macports.org/projects/macports/wiki/TracTicketing -- this one and NewTracTicketing should be merged into the new guide (mostly done, see ticket #12714) and then obliterated; 11) http://trac.macports.org/projects/macports/wiki/MailingLists -- moved to the guide and obliterated. The result of these moves doesn't necessarily have to be a scant introductory Wiki page, as we can always link to the relevant guide pages (and whatever else we find appropriate) off it (thus favoring doc centralization again). After that's done, the only thing keeping us from going live with the new website would be a new "Home" section, 'index.php', per the guidelines I outlined for it in an earlier thread on this list: -) Home: a front page detailing what the project is about (including a brief description of our ports tree), mission goals (very brief summary of a project roadmap) and introductory text of how to participate/join. Blog functionality would be provided by our existing Wordpress installation, but a way to smoothly tie the latter into the former has to be thought out. Of course, feel free to brainstorm over that if you have other/ better ideas. Anyone willing to help writing that text? The rest of the pending tasks for a fully functional site are mostly server related issues that I would have to work out with Mac OS Forge admin personnel. But that shouldn't stop us from moving forward as soon as we have the content ready, as we can always roll in new functionality incrementally. So.... this is just another one of my a-tad-too-long mails, so I'm gonna wrap it up here hoping you don't get too bored reading and instead step forward to volunteer some much needed help ;-) Thanks in advance! Regards,.... -jmpp From n.oxyde at gmail.com Tue Oct 2 14:13:21 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:40 2007 Subject: compiler selection In-Reply-To: <6A74ABF9-E337-4DEB-9BAD-AA5C8A715C32@macports.org> References: <46FD15CF.1090801@gmail.com> <46764922-9AD0-41F7-9377-D38A2F2B08E2@macports.org> <834846C6-FF26-46E4-8DF1-BC8D812D574B@macports.org> <46FF76D4.1020403@gmail.com> <6A74ABF9-E337-4DEB-9BAD-AA5C8A715C32@macports.org> Message-ID: Le 30 sept. 07 ? 13:57, Weissmann Markus a ?crit : > On 30.09.2007, at 12:13, Michael Wild wrote: > >> Ryan Schmidt wrote: >>> On Sep 28, 2007, at 14:45, Ryan Schmidt wrote: >>>> On Sep 28, 2007, at 09:55, Michael Wild wrote: >>>> >>>>> My problem actually is that a port which I'm preparing requires >>>>> gfortran which doesn't come with Apple's system gcc but is in >>>>> port:gcc42. I could simply do "configure.fc ${prefix}/bin/ >>>>> gfortran-mp-4.2, but what if someone has another gcc installed? >>>>> I could depends_build on gcc42 but if a gcc suite is required >>>>> by MacPorts anyways I wouldn't like to impose something which >>>>> might install another compiler suite unnecessarily. >>>> >>>> If you require gfortran, you should depends_build on gcc42. >>>> Nevermind anyone who has gcc43 installed; that's beta and >>>> shouldn't be relied on until gcc44 is released, at which point >>>> the port can be updated. Nevermind anyone who has gcc41 or gc40 >>>> or earlier installed; any ports that still depend on those >>>> should be updated to gcc42. >>> Oh, I meant to say: and then you go: >>> configure.compiler gcc-4.0 >> >> You mean >> >> configure.compiler macports-gcc-4.2 >> >> else it doesn't work... >> >>> and with depends_build gcc42 that's all you should need. >> >> Yep, works like a charm now! >> > > Well, you need to pay attention: If you have C++ or Objective-C > code, it will link to the C++/Objective-C lib of the used compiler. > So if you build a C++ program, this needs to be "depends_lib > gcc42"! For pure C programs, a "depends_build" is sufficient though. > You mean `depends_lib port:gcc42`. > You can check out if your program does this by doing a `otool -L > name-of-the-binary-or-dynamic-library'. C++ programs compiled with > macports gcc 4.2 will return e.g. '/opt/local/lib/gcc42/libstdc++. > 6.dylib'. > > > -Markus > > --- > Markus W. Weissmann > http://www.mweissmann.de/ > -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From raimue at macports.org Wed Oct 3 02:37:34 2007 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: References: Message-ID: <470362DE.3090602@macports.org> Anders F Bj?rklund wrote: > For MacPorts 1.6.0, > > I think you should split the "dports" trunk in two, > "trunk" and "release", just as done with the "base". > There is just too much port breakage with running the > latest developer version on the user machines, IMHO. That sounds like a good idea. But who decides at which time we merge revisions from unstable to stable? And do we have enough resources (I mean: contributors and testers) to find all problems? Would this really help to find problems at all? 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.*. But for this we need some place to track those changes and mark them for a later merge. Where should we store which revisions are to be merged to stable? And who will do the merging? It sounds great, but are we ready to manage more than one ports tree? Rainer From rhwood at mac.com Wed Oct 3 02:48:43 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: <470362DE.3090602@macports.org> References: <470362DE.3090602@macports.org> Message-ID: On 3 Oct 2007, at 05:37, Rainer M?ller wrote: > Anders F Bj?rklund wrote: >> For MacPorts 1.6.0, >> >> I think you should split the "dports" trunk in two, >> "trunk" and "release", just as done with the "base". >> There is just too much port breakage with running the >> latest developer version on the user machines, IMHO. > > That sounds like a good idea. But who decides at which time we merge > revisions from unstable to stable? And do we have enough resources (I > mean: contributors and testers) to find all problems? Would this > really > help to find problems at all? If we had a build farm, the farm could catch every build error, so that the only ports in the "stable" tree would have runtime errors. > 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.*. > > But for this we need some place to track those changes and mark > them for > a later merge. Where should we store which revisions are to be > merged to > stable? And who will do the merging? > > It sounds great, but are we ready to manage more than one ports tree? If we could automate it? > Rainer > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev Randall Wood rhwood@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." From themiwi at gmail.com Wed Oct 3 03:58:00 2007 From: themiwi at gmail.com (Michael Wild) Date: Tue Oct 9 16:40:40 2007 Subject: Port update for qt4-mac Message-ID: <470375B8.9040900@gmail.com> Hi I submitted an updated Portfile for qt4-mac version 4.3.1. For the details see http://trac.macports.org/projects/macports/ticket/12846 Quite a lot changed, so please have a close look at it. Regards Michael From n.oxyde at gmail.com Tue Oct 2 14:16:51 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: <470225F8.1090404@gmail.com> References: <470225F8.1090404@gmail.com> Message-ID: <02F14E0C-659D-4CA4-9556-D48D8296D2C8@gmail.com> Le 2 oct. 07 ? 13:05, Michael Wild a ?crit : > Anders F Bj?rklund wrote: >> For MacPorts 1.6.0, >> >> I think you should split the "dports" trunk in two, >> "trunk" and "release", just as done with the "base". >> There is just too much port breakage with running the >> latest developer version on the user machines, IMHO. >> > I second that. > > Or perhaps a bit a more elaborate scheme like fink uses it: namely > a stable and an unstable tree. > > Would make things much more reliable. > I would rather see this problem resolved by working on a major modification against base/ code: multiple versions for each port. Only one tree would be required, and we could use a fine-grained dependency system as it is in Gentoo Portage. > >> It also needs a cooler name... Such as "Evolution", >> as in: I'm running the latest MacPorts Evolution. :-) >> > > If people want fancy names... > >> --anders >> > > Michael -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From yves at macports.org Wed Oct 3 15:31:18 2007 From: yves at macports.org (Yves de Champlain) Date: Tue Oct 9 16:40:40 2007 Subject: Replacement for cd In-Reply-To: References: Message-ID: Le 07-10-02 ? 18:23, Kevin Ballard a ?crit : > Since the cd command has been removed from trunk, perhaps another > command could be added to fill in the void? I'm proposing a command > that acts like cd but takes a block and executes the block within > the given directory, then restores the old working directory before > continuing on. > > Any thoughts? Please or thanks, maybe both ! yves From ryandesign at macports.org Wed Oct 3 16:15:15 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: References: <470362DE.3090602@macports.org> Message-ID: 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? From ryandesign at macports.org Wed Oct 3 16:16:49 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: <02F14E0C-659D-4CA4-9556-D48D8296D2C8@gmail.com> References: <470225F8.1090404@gmail.com> <02F14E0C-659D-4CA4-9556-D48D8296D2C8@gmail.com> Message-ID: <31F43343-DD2C-4B5C-B42A-43C4B6FB9F6C@macports.org> On Oct 2, 2007, at 16:16, N_Ox wrote: > Le 2 oct. 07 ? 13:05, Michael Wild a ?crit : > >> Anders F Bj?rklund wrote: >> >>> For MacPorts 1.6.0, >>> >>> I think you should split the "dports" trunk in two, >>> "trunk" and "release", just as done with the "base". >>> There is just too much port breakage with running the >>> latest developer version on the user machines, IMHO. >> >> I second that. >> >> Or perhaps a bit a more elaborate scheme like fink uses it: namely >> a stable and an unstable tree. >> >> Would make things much more reliable. > > I would rather see this problem resolved by working on a major > modification against base/ code: > multiple versions for each port. > > Only one tree would be required, and we could use a fine-grained > dependency system as it is in Gentoo Portage. For what purpose? We already have the situation that when we want to make, say, both apache 2.0 and apache 2.2 available, we create two ports: apache20 and apache2, respectively. This works fine. What do you need in addition to that? From raimue at macports.org Wed Oct 3 16:37:10 2007 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Oct 9 16:40:40 2007 Subject: Replacement for cd In-Reply-To: References: Message-ID: <470427A6.7070906@macports.org> Kevin Ballard wrote: > Since the cd command has been removed from trunk, perhaps another > command could be added to fill in the void? I'm proposing a command that > acts like cd but takes a block and executes the block within the given > directory, then restores the old working directory before continuing on. Is this really necessary? All calls could be done using absolute paths. And prefixing with ${destroot}${prefix} or ${worksrcdir} is not that long. I don't think there should be too much complexity on commands in Portfiles. Rainer From themiwi at gmail.com Wed Oct 3 23:37:53 2007 From: themiwi at gmail.com (Michael Wild) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: References: <470362DE.3090602@macports.org> Message-ID: <47048A41.4020600@gmail.com> Ryan Schmidt wrote: [snip] > > 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? > [snip] I'd gladly volunteer to take some. I think that it would make sense to assign the ports by priority: Important ones first. However, as I'm relatively new to MacPorts I don't know which ports are considered to be important (or very popular). Any suggestions? How would I go about "adopting" an unmaintained port? Michael From ryandesign at macports.org Wed Oct 3 23:52:35 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: <47048A41.4020600@gmail.com> References: <470362DE.3090602@macports.org> <47048A41.4020600@gmail.com> Message-ID: On Oct 4, 2007, at 01:37, Michael Wild wrote: > Ryan Schmidt wrote: > [snip] > > > > 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? > > > [snip] > > I'd gladly volunteer to take some. I think that it would make sense > to assign the ports by priority: Important ones first. However, as > I'm relatively new to MacPorts I don't know which ports are > considered to be important (or very popular). Any suggestions? How > would I go about "adopting" an unmaintained port? Simply indicate your desire and a committer such as me can change the maintainer address in the port to yours. If you have an update to a port, even an unmaintained or openmaintainer one, attach a diff to a ticket and notify the list and someone will review and commit it. From afb at macports.org Wed Oct 3 23:54:49 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: References: <470362DE.3090602@macports.org> Message-ID: Ryan Schmidt wrote: >> 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. Took a quick look, but it was mostly about "are you guys crazy". Will take another look... > 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? Actually I didn't use the terms "stable" and "unstable" (I think those were from Fink), I used the terms "release" (since the term "archive" means that it is frozen) and "development" (or the SVN term of "trunk"). > 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. It's much easier to do packaging and testing, when the rate of change slows down. The automated build and packaging process is being revised now (using it to build RPMS), and that is very useful to have either way. > 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. Impatient or out-of-date users will occur either way, the easiest path to help them is probably have an updated ports list for easy viewing - such as a web page with versions and recent updates. > By what mechanism would you suggest that changes move between these > two hypothetical ports trees? "Release Engineering". Eventually, someone will have to take a look at it. But maybe just not today ? --anders From jmpp at macports.org Thu Oct 4 00:15:13 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:40 2007 Subject: MacPorts (and our ports) on Leopard Message-ID: 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@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 From mww at macports.org Thu Oct 4 01:08:23 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: References: <470362DE.3090602@macports.org> Message-ID: On 04.10.2007, at 08:54, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >>> 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. > > Took a quick look, but it was mostly about "are you guys crazy". > Will take another look... > >> 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? > > Actually I didn't use the terms "stable" and "unstable" (I think > those were from Fink), I used the terms "release" (since the term > "archive" means that it is frozen) and "development" (or the SVN > term of "trunk"). > >> 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. > > It's much easier to do packaging and testing, when the rate of > change slows down. The automated build and packaging process is > being revised now (using it to build RPMS), and that is very useful > to have either way. > This is great. I think we can talk about splitting the tree as soon as this features is finished and we have a build-server that reports about build errors. >> 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. > > Impatient or out-of-date users will occur either way, the easiest > path to help them is probably have an updated ports list for easy > viewing - such as a web page with versions and recent updates. > The out-of-date users will be far less if we provide RPMs. The impatient ones are often also those who find the bugs in the first place. >> By what mechanism would you suggest that changes move between >> these two hypothetical ports trees? > > "Release Engineering". Eventually, someone will have to take a look > at it. But maybe just not today ? > I'd prefer to combine this job with an automated build. This will make this tasks much less error prone and less time consuming. -Markus --- Markus W. Weissmann http://www.mweissmann.de/ From afb at macports.org Thu Oct 4 01:20:29 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: References: <470362DE.3090602@macports.org> Message-ID: Weissmann Markus wrote: >> It's much easier to do packaging and testing, when the rate of change >> slows down. The automated build and packaging process is being >> revised now (using it to build RPMS), and that is very useful to have >> either way. > > This is great. I think we can talk about splitting the tree as soon as > this features is finished and we have a build-server that reports > about build errors. Having a build server is more of an infrastructure/resource question, but there is a lot of work being done with tracing and logging - I'm more doing the oldfashioned approach with a chroot and scripting... But the Koji* build system is kinda nice looking, otherwise... :-) >> Impatient or out-of-date users will occur either way, the easiest >> path to help them is probably have an updated ports list for easy >> viewing - such as a web page with versions and recent updates. > > The out-of-date users will be far less if we provide RPMs. The > impatient ones are often also those who find the bugs in the first > place. It's also possible to provides archives (tgz) for impatient developer users, within the port system itself. But both are being built anyway, it's the same destroot contents in both - no matter the wrapping. Having portable MacPorts also helps, easier to build/test on BSD/GNU. --anders * see http://koji.fedoraproject.org/koji/ From ryandesign at macports.org Thu Oct 4 01:25:08 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:40 2007 Subject: [29634] trunk/dports/devel/pcre/Portfile In-Reply-To: <20071004074351.74BE283563F@cvs.opensource.apple.com> References: <20071004074351.74BE283563F@cvs.opensource.apple.com> Message-ID: On Oct 4, 2007, at 02:43, source_changes@macosforge.org wrote: > Revision: 29634 > http://trac.macosforge.org/projects/macports/changeset/29634 > Author: jkh@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? From raimue at macports.org Thu Oct 4 02:24:55 2007 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: <31F43343-DD2C-4B5C-B42A-43C4B6FB9F6C@macports.org> References: <470225F8.1090404@gmail.com> <02F14E0C-659D-4CA4-9556-D48D8296D2C8@gmail.com> <31F43343-DD2C-4B5C-B42A-43C4B6FB9F6C@macports.org> Message-ID: <4704B167.4030603@macports.org> Ryan Schmidt wrote: > For what purpose? We already have the situation that when we want to > make, say, both apache 2.0 and apache 2.2 available, we create two > ports: apache20 and apache2, respectively. This works fine. What do you > need in addition to that? One could choose which version to install without loosing dependencies. For example, all of our *-devel ports are useless because they break the depedencies. For example, you can't install something like apache2-devel and add php5, because php5 depends on the normal apache2. With multiple version per port this would be possible. But it would also require the introduction of new commands that allow a port to depend on at least a specific version of another port. We could mark the different versions as "stable" or "unstable". With this approach we would get a better environment to test port upgrades with beta versions or release candidates. Rainer From jwa at macports.org Thu Oct 4 03:26:36 2007 From: jwa at macports.org (Jyrki Wahlstedt) Date: Tue Oct 9 16:40:40 2007 Subject: r 29606: python25 Message-ID: This was committed: r29606 | nox@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 From n.oxyde at gmail.com Thu Oct 4 03:42:53 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:40 2007 Subject: r 29606: python25 In-Reply-To: References: Message-ID: <3137302E-366A-4F4D-AA3E-DB569C36FB56@gmail.com> Le 4 oct. 07 ? 12:26, Jyrki Wahlstedt a ?crit : > This was committed: > r29606 | nox@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 > What is the framework install really needed? To solve your problem, you only need to disable the Makefile.pre.in patch. Anyway, it seems the Makefile framework target is broken: `$(INSTALL) -d -m $(DIRMODE) $(PYTHONFRAMEWORKDIR)/Versions/$(VERSION) ` does not install in $(DESTDIR). `-install_name $(DESTDIR)$(PYTHONFRAMEWORKINSTALLDIR)/Versions/$ (VERSION)/Python` should not include $(DESTDIR). > 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 > -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From frank-lists at auroralux.net Thu Oct 4 04:04:23 2007 From: frank-lists at auroralux.net (Frank McPherson) Date: Tue Oct 9 16:40:40 2007 Subject: Request: commit 12654, update postgis to 1.3.1 In-Reply-To: References: <6184508C-FA0E-4909-9680-7ADB00047C8C@janusresearch.com> <46A2FA60-4CC0-458B-BFC3-D5AE9144A12A@cjstubbs.org> <64CF892C-FD85-47FB-8E2D-438DDE49EC78@janusresearch.com> <2A280686-6E3D-46DC-98A4-3B6EF2F82332@cjstubbs.org> Message-ID: <99FA7E95-46D4-40F5-8D32-104EB76285EC@auroralux.net> On Sep 10, 2007, at 1:56 PM, Jeff Stubbs wrote: > > On Sep 10, 2007, at 1:09 PM, N_Ox wrote: > >> >> Le 10 sept. 07 ? 17:31, Jeff Stubbs a ?crit : >> >> Or just add `build.args "ICONV_LDFLAGS=\"-L${prefix}/lib -liconv >> \""` in the Portfile? > > That works, and it's much cleaner. No need to patch the loader's > makefile. This also works for me so I've patched the Portfile and added it to the ticket. Could someone with access please commit 12654 to update postgis to 1.3.1? Thanks, Frank From jwa at macports.org Thu Oct 4 04:04:43 2007 From: jwa at macports.org (Jyrki Wahlstedt) Date: Tue Oct 9 16:40:40 2007 Subject: r 29606: python25 In-Reply-To: <3137302E-366A-4F4D-AA3E-DB569C36FB56@gmail.com> References: <3137302E-366A-4F4D-AA3E-DB569C36FB56@gmail.com> Message-ID: <020446F7-C00B-484E-A77A-039BF0795B4F@macports.org> On 4.10.2007, at 13.42, N_Ox wrote: > Le 4 oct. 07 ? 12:26, Jyrki Wahlstedt a ?crit : > >> This was committed: >> r29606 | nox@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 >> > > What is the framework install really needed? E.g. py25-wxpython? > To solve your problem, you only need to disable the Makefile.pre.in > patch. > Thanks, have to try! > Anyway, it seems the Makefile framework target is broken: > `$(INSTALL) -d -m $(DIRMODE) $(PYTHONFRAMEWORKDIR)/Versions/$ > (VERSION)` does not install in $(DESTDIR). > `-install_name $(DESTDIR)$(PYTHONFRAMEWORKINSTALLDIR)/Versions/$ > (VERSION)/Python` should not include $(DESTDIR). > >> 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. >> > -- > Anthony Ramine, the infamous MacPorts Trac slave. > nox@macports.org > > ! ! 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 From jwa at macports.org Thu Oct 4 04:19:29 2007 From: jwa at macports.org (Jyrki Wahlstedt) Date: Tue Oct 9 16:40:40 2007 Subject: r 29606: python25 In-Reply-To: <020446F7-C00B-484E-A77A-039BF0795B4F@macports.org> References: <3137302E-366A-4F4D-AA3E-DB569C36FB56@gmail.com> <020446F7-C00B-484E-A77A-039BF0795B4F@macports.org> Message-ID: <36BF5A8A-B246-4472-9A36-EBF7C7BC339B@macports.org> On 4.10.2007, at 14.04, Jyrki Wahlstedt wrote: > E.g. py25-wxpython? > >> To solve your problem, you only need to disable the >> Makefile.pre.in patch. >> > Thanks, have to try! Hmm, I added patch-delete the file mentioned, but the result was: make: *** No rule to make target `libpython2.5.dylib', needed by `python.exe'. Stop. Warning: the following items did not execute (for python25): org.macports.destroot org.macports.build So, back to ? ! ! 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 From n.oxyde at gmail.com Thu Oct 4 05:48:42 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:40 2007 Subject: [29634] trunk/dports/devel/pcre/Portfile In-Reply-To: <20071004074351.74BE283563F@cvs.opensource.apple.com> References: <20071004074351.74BE283563F@cvs.opensource.apple.com> Message-ID: <75B49921-D5E4-4F4C-9C73-59CC37CF3314@gmail.com> Le 4 oct. 07 ? 09:43, source_changes@macosforge.org a ?crit : > Revision 29634 > Author jkh@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@macports.org From n.oxyde at gmail.com Thu Oct 4 05:51:16 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:40 2007 Subject: r 29606: python25 In-Reply-To: <020446F7-C00B-484E-A77A-039BF0795B4F@macports.org> References: <3137302E-366A-4F4D-AA3E-DB569C36FB56@gmail.com> <020446F7-C00B-484E-A77A-039BF0795B4F@macports.org> Message-ID: <52416FD1-9861-492A-9FDD-965C24A91A54@gmail.com> 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 : >> >>> This was committed: >>> r29606 | nox@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 >>> >> >> 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. >> To solve your problem, you only need to disable the >> Makefile.pre.in patch. >> > Thanks, have to try! > >> Anyway, it seems the Makefile framework target is broken: >> `$(INSTALL) -d -m $(DIRMODE) $(PYTHONFRAMEWORKDIR)/Versions/$ >> (VERSION)` does not install in $(DESTDIR). >> `-install_name $(DESTDIR)$(PYTHONFRAMEWORKINSTALLDIR)/Versions/$ >> (VERSION)/Python` should not include $(DESTDIR). >> >>> 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. >>> >> -- >> Anthony Ramine, the infamous MacPorts Trac slave. >> nox@macports.org >> >> > > > ! > ! 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 > > > -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From jwa at macports.org Thu Oct 4 06:05:39 2007 From: jwa at macports.org (Jyrki Wahlstedt) Date: Tue Oct 9 16:40:40 2007 Subject: r 29606: python25 In-Reply-To: <52416FD1-9861-492A-9FDD-965C24A91A54@gmail.com> References: <3137302E-366A-4F4D-AA3E-DB569C36FB56@gmail.com> <020446F7-C00B-484E-A77A-039BF0795B4F@macports.org> <52416FD1-9861-492A-9FDD-965C24A91A54@gmail.com> Message-ID: 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 : >>> >>>> This was committed: >>>> r29606 | nox@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 >>>> >>> >>> 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? >>> To solve your problem, you only need to disable the >>> Makefile.pre.in patch. >>> >> Thanks, have to try! >> >>> Anyway, it seems the Makefile framework target is broken: >>> `$(INSTALL) -d -m $(DIRMODE) $(PYTHONFRAMEWORKDIR)/Versions/$ >>> (VERSION)` does not install in $(DESTDIR). >>> `-install_name $(DESTDIR)$(PYTHONFRAMEWORKINSTALLDIR)/Versions/$ >>> (VERSION)/Python` should not include $(DESTDIR). >>> >>>> 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. >>>> >>> -- >>> Anthony Ramine, the infamous MacPorts Trac slave. >>> nox@macports.org >>> >>> >> >> >> ! >> ! 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 >> >> >> > > -- > Anthony Ramine, the infamous MacPorts Trac slave. > nox@macports.org > > From n.oxyde at gmail.com Thu Oct 4 06:17:25 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:40 2007 Subject: r 29606: python25 In-Reply-To: References: <3137302E-366A-4F4D-AA3E-DB569C36FB56@gmail.com> <020446F7-C00B-484E-A77A-039BF0795B4F@macports.org> <52416FD1-9861-492A-9FDD-965C24A91A54@gmail.com> Message-ID: <7FFC8DB7-1376-452B-88B9-3A85E4195B37@gmail.com> 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 : >>>> >>>>> >>>> >>>> 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 ;) Back on topic, disable both Makefile.pre.in and configure patches and try again. >>> >>> ! >>> ! 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 >>> -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From dluke at geeklair.net Thu Oct 4 06:39:51 2007 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue Oct 9 16:40:40 2007 Subject: Request: commit 12654, update postgis to 1.3.1 In-Reply-To: <99FA7E95-46D4-40F5-8D32-104EB76285EC@auroralux.net> References: <6184508C-FA0E-4909-9680-7ADB00047C8C@janusresearch.com> <46A2FA60-4CC0-458B-BFC3-D5AE9144A12A@cjstubbs.org> <64CF892C-FD85-47FB-8E2D-438DDE49EC78@janusresearch.com> <2A280686-6E3D-46DC-98A4-3B6EF2F82332@cjstubbs.org> <99FA7E95-46D4-40F5-8D32-104EB76285EC@auroralux.net> Message-ID: On Oct 4, 2007, at 7:04 AM, Frank McPherson wrote: > This also works for me so I've patched the Portfile and added it to > the ticket. Could someone with access please commit 12654 to update > postgis to 1.3.1? This is done. You wouldn't happen to want to be listed as the maintainer for this port, would you? :) -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071004/8cc54928/PGP.bin From n.oxyde at gmail.com Thu Oct 4 06:47:58 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:40 2007 Subject: cups-headers on Panther Message-ID: Could someone still running MP on a Panther box test the patch from ticket #12768? Regards, -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From ehainry at free.fr Thu Oct 4 13:32:23 2007 From: ehainry at free.fr (Emmanuel Hainry) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: <4704B167.4030603@macports.org> References: <470225F8.1090404@gmail.com> <02F14E0C-659D-4CA4-9556-D48D8296D2C8@gmail.com> <31F43343-DD2C-4B5C-B42A-43C4B6FB9F6C@macports.org> <4704B167.4030603@macports.org> Message-ID: <20071004203223.GA9062@velsheda.lateralis.org> Citando Rainer M?ller : > Ryan Schmidt wrote: > > For what purpose? We already have the situation that when we want to > > make, say, both apache 2.0 and apache 2.2 available, we create two > > ports: apache20 and apache2, respectively. This works fine. What do you > > need in addition to that? > > One could choose which version to install without loosing dependencies. > For example, all of our *-devel ports are useless because they break the > depedencies. > For example, you can't install something like apache2-devel and add > php5, because php5 depends on the normal apache2. > > With multiple version per port this would be possible. But it would also > require the introduction of new commands that allow a port to depend on > at least a specific version of another port. > > We could mark the different versions as "stable" or "unstable". With > this approach we would get a better environment to test port upgrades > with beta versions or release candidates. > Being a simple maintainer, I would say that dependencies on specific version (? la debian "this software require thingy version > 2.2.17 but it is not going to be installed") would make me unable to manage seriously my ports. The not too untractable point however would be to introduce some metaports (for example, musicpd can be provided by mpd or mpd-dev), and dependencies would be put to the metaport instead of one of the providing ports. It can at the moment be achieved through the old dependency scheme (sthg like depends_lib bin:mpd:mpd-devel) but that scheme cannot discriminate between something provided by macports and something provided by apple or another source. Emmanuel From blair at orcaware.com Thu Oct 4 15:00:40 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:40 2007 Subject: r 29606: python25 In-Reply-To: <3137302E-366A-4F4D-AA3E-DB569C36FB56@gmail.com> References: <3137302E-366A-4F4D-AA3E-DB569C36FB56@gmail.com> Message-ID: <47056288.3020706@orcaware.com> N_Ox wrote: > Le 4 oct. 07 ? 12:26, Jyrki Wahlstedt a ?crit : > >> This was committed: >> r29606 | nox@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 >> > > What is the framework install really needed? As a general note, having a framework install of Python 2.5 is important, as right now you're stuck on 2.4 for any PyQt apps or anything else that needs a window. It also should be possible to have a framework Python 2.4 and framework Python 2.5 installed at the same time, so I suggest having them install in two totally different different locations, such as $prefix/Library/Frameworks (for 2.4) and $prefix/Library/Frameworks-Python2.5 otherwise the version $prefix/Library/Frameworks/Python.framework/Versions/Current can't point to either framework. Blair -- Blair Zajac, Ph.D. http://www.orcaware.com/svn/ From n.oxyde at gmail.com Thu Oct 4 15:02:15 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: <20071004203223.GA9062@velsheda.lateralis.org> References: <470225F8.1090404@gmail.com> <02F14E0C-659D-4CA4-9556-D48D8296D2C8@gmail.com> <31F43343-DD2C-4B5C-B42A-43C4B6FB9F6C@macports.org> <4704B167.4030603@macports.org> <20071004203223.GA9062@velsheda.lateralis.org> Message-ID: Le 4 oct. 07 ? 22:32, Emmanuel Hainry a ?crit : > Citando Rainer M?ller : >> Ryan Schmidt wrote: >>> For what purpose? We already have the situation that when we want to >>> make, say, both apache 2.0 and apache 2.2 available, we create two >>> ports: apache20 and apache2, respectively. This works fine. What >>> do you >>> need in addition to that? >> >> One could choose which version to install without loosing >> dependencies. >> For example, all of our *-devel ports are useless because they >> break the >> depedencies. >> For example, you can't install something like apache2-devel and add >> php5, because php5 depends on the normal apache2. >> >> With multiple version per port this would be possible. But it >> would also >> require the introduction of new commands that allow a port to >> depend on >> at least a specific version of another port. >> >> We could mark the different versions as "stable" or "unstable". With >> this approach we would get a better environment to test port upgrades >> with beta versions or release candidates. >> > > Being a simple maintainer, I would say that dependencies on specific > version (? la debian "this software require thingy version > 2.2.17 > but > it is not going to be installed") would make me unable to manage > seriously my ports. > How would that make you unable to maintain your ports? I don't understand your point. > The not too untractable point however would be to introduce some > metaports (for example, musicpd can be provided by mpd or mpd-dev), > and > dependencies would be put to the metaport instead of one of the > providing ports. It can at the moment be achieved through the old > dependency scheme (sthg like depends_lib bin:mpd:mpd-devel) but that > scheme cannot discriminate between something provided by macports and > something provided by apple or another source. > > Emmanuel > We can use path:${prefix}/bin/mpd:mpd, but how manage things like postgresql8*? For example, how could you easily set dependencies for packages such as phpmyadmin and phppgadmin? You can't. -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From n.oxyde at gmail.com Thu Oct 4 15:03:36 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:40 2007 Subject: r 29606: python25 In-Reply-To: References: <3137302E-366A-4F4D-AA3E-DB569C36FB56@gmail.com> <020446F7-C00B-484E-A77A-039BF0795B4F@macports.org> <52416FD1-9861-492A-9FDD-965C24A91A54@gmail.com> <7FFC8DB7-1376-452B-88B9-3A85E4195B37@gmail.com> Message-ID: 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 : >>>>>> >>>>>>> >>>>>> >>>>>> 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@macports.org From raimue at macports.org Thu Oct 4 15:06:35 2007 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: <20071004203223.GA9062@velsheda.lateralis.org> References: <470225F8.1090404@gmail.com> <02F14E0C-659D-4CA4-9556-D48D8296D2C8@gmail.com> <31F43343-DD2C-4B5C-B42A-43C4B6FB9F6C@macports.org> <4704B167.4030603@macports.org> <20071004203223.GA9062@velsheda.lateralis.org> Message-ID: <470563EB.3070303@macports.org> Emmanuel Hainry wrote: > Being a simple maintainer, I would say that dependencies on specific > version (? la debian "this software require thingy version > 2.2.17 but > it is not going to be installed") would make me unable to manage > seriously my ports. Why? I just don't get this point. > The not too untractable point however would be to introduce some > metaports (for example, musicpd can be provided by mpd or mpd-dev), and > dependencies would be put to the metaport instead of one of the > providing ports. Okay, let's call it "metaport". But it is the same thing you are describing. A port which provides multiple versions of a software. Nevertheless, dependencies have to go in each version of a port. A development snapshot could have completely different dependencies than the current "stable" version. Rainer From mww at macports.org Thu Oct 4 15:09:48 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:40 2007 Subject: r 29606: python25 In-Reply-To: References: <3137302E-366A-4F4D-AA3E-DB569C36FB56@gmail.com> <020446F7-C00B-484E-A77A-039BF0795B4F@macports.org> <52416FD1-9861-492A-9FDD-965C24A91A54@gmail.com> <7FFC8DB7-1376-452B-88B9-3A85E4195B37@gmail.com> Message-ID: <872BB2BC-7CEA-4F7E-B5CB-6BE757709E81@macports.org> On 05.10.2007, at 00:03, N_Ox wrote: > 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 : >>>>>>> >>>>>>>> >>>>>>> >>>>>>> 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. > I didn't dig into this far enough, the thing simply is that starting a Python program that wants to use the GUI -- e.g. via py-game (SDL) or py-wxwidgets (wxWidgets) -- must use the "pythonw" executable. This is only available in the framework build. -Markus --- Markus W. Weissmann http://www.mweissmann.de/ From ehainry at free.fr Thu Oct 4 23:29:50 2007 From: ehainry at free.fr (Emmanuel Hainry) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: <470563EB.3070303@macports.org> References: <470225F8.1090404@gmail.com> <02F14E0C-659D-4CA4-9556-D48D8296D2C8@gmail.com> <31F43343-DD2C-4B5C-B42A-43C4B6FB9F6C@macports.org> <4704B167.4030603@macports.org> <20071004203223.GA9062@velsheda.lateralis.org> <470563EB.3070303@macports.org> Message-ID: <20071005062950.GB3432@velsheda.lateralis.org> Citando Rainer M?ller : > Emmanuel Hainry wrote: > > Being a simple maintainer, I would say that dependencies on specific > > version (? la debian "this software require thingy version > 2.2.17 but > > it is not going to be installed") would make me unable to manage > > seriously my ports. > > Why? I just don't get this point. > I know the ports I maintain build with the latest versions of their dependencies at the time I uploaded the Portfile. I am unable to predict breakage (for example when libogg changed its API, mpd did not build anymore) and I am even more unable to decide if it builds against each version of each of its dependencies. The current way is tractable for me, adding such possibility would mean far more testing than trying to build the port with the differents combinations of variants. If the other maintainers have far more free time than I do, maybe it can work and the tree will not be full of untested dependencies. Seeing the number of unmaintained ports, and the numbers of tickets in trac (even simple updates), I would say that it is not the case. > > The not too untractable point however would be to introduce some > > metaports (for example, musicpd can be provided by mpd or mpd-dev), and > > dependencies would be put to the metaport instead of one of the > > providing ports. > > Okay, let's call it "metaport". But it is the same thing you are > describing. Yes, I just stated that it was the part of what you proposed I found interesting: as long as it is not taken too far. > A port which provides multiple versions of a software. Nevertheless, >dependencies have to go in each version of a port. A development >snapshot could have completely different dependencies than the current >"stable" version. Yes of course. The metaport metaphp would depend on php5 or php52 or any version. But those ports keep their current portfile. Then ports depending on "just any version of php" would put depends-lib metaphp in their portfile. Emmanuel From jmpp at macports.org Thu Oct 4 23:56:57 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: References: <470362DE.3090602@macports.org> Message-ID: Top posting to make some general comments. If you guys may remember, I suggested a somewhat large rearrangement of our svn tree a while ago, but all in all I was met with quite a bit of opposition so I simply dropped it (the initiative at the time, not the desire to do it ;-). Basically, my thoughts were along the line of: -) forego the svn {trunk,branches,tags} standard top level dirs model as I believe it doesn't suit us, the only thing we're ever branching and/or tagging is the 'base' component; -) based on that, rearrange as so (leading / indicate I'm referring to top level dirs): /base trunk/ branches/ tags/ /ports (read explanation below) release/ aqua/ audio/ (etc) test/ aqua/ audio/ (etc) /www , . /docs , . Most of that layout is self-explanatory, I believe, but my view of the "new" ports tree(s) does warrant some explanation. It was my idea that in making the ports dir a top level one (and thus decoupling it from the erroneously implied "trunk" category), we could leverage the opportunity to create different "sets of trees", the "release" one being the one we distribute to users by default and where "most" things submitted by contributors would go. I don't like the Fink idea of a stable (release) Vs. unstable tree, the last one holding the equivalent of our *-devel ports, as I believe it has been proven that that approach condemns the "stable" tree to an always-out-of-date jail and as a result pushes everyone to the "unstable" tree (a lot of users come to MacPorts complaining Fink only has outdated packages). I did, however, propose a "test" tree of some sort where we would instead test MacPorts itself, freely using whatever new features/ constructs that may be in our trunk base code but not in a MacPorts release at any moment; currently, any new MacPorts feature has to wait for a new release before being adopted in Portfiles, which hinders our ability to test. "mysql5" and "mysql5-devel" ports would both live in the "release" tree if they work with whatever MacPorts release is current, but (a copy of) any of those would have to move to the "test" tree if the corresponding Portfile starts using syntax/ code only available in base's trunk. Users would be free to use the "test" tree against base's trunk or the recommended "release" tree against the current MacPorts release. But that layout is not limited to only those two trees, as any other purpose-specific tree could be created to fulfill whatever need we may have should they arise. For instance, platform specific trees could be created: /ports tiger/ aqua/ audio/ (etc) leopard/ aqua/ audio/ (etc) Do we really need this....? Certainly not now... but who knows if we ever do...? ;-) In any case, having the room to grow is a big plus, I believe, and we don't have it now. And about automated testing through automated ports build runs: this is one of the primary goals I am aiming for in the mid-term future, but there are in my opinion a couple of key components we are still missing to be able to do it properly. One of those is full a blown trace mode so that we can have all the needed information about everything that goes on outside the destroot sandbox; this depends on Eugene's GSoC work so I guess this is a great oportunity to ask for a status update on that (as I did tonight with Chris on IRC ;-). Eugene, could you please bring us up to speed with the state of your work? [1] Secondly.... and obviously... logging support! Can't do any sort of automated software building if we don't have any mean to catch errors and report them. I've spoken at lengths about this already, and since this mail is a tad too long already (were you expecting any different form me? ;-), I'll just point you to the formal proposal I wrote on it: http://trac.macports.org/projects/macports/wiki/PortLoggingProposal As a treat, while evangelizing that to Chris tonight on IRC, he was kind enough to put together a small mock-up of what an xml MacPorts log would look like: http://xml.sfiera.net/macports-log.xml Once I'm done with the new website I plan to devote to some serious energies to this feature that we're so sorely lacking -- do not feel one bit shy to chime in if you feel like helping in any way! And all that having been said, I should be in bed ;-) Regards,... -jmpp [1] I asked Chris for a status update on his GSoC work spanning a few key points: -) original goals; -) if they were modified along the way, how? -) how successfully did you achieve your original and/or modified goals? -) future plans for your end result product(s), most certainly including how you plan to use it (them) in MacPorts Eugene and Elias, you think you could please put something like that together for us? It would greatly help us plan future MacPorts releases. Thank you! On Oct 4, 2007, at 2:54 AM, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >>> 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. > > Took a quick look, but it was mostly about "are you guys crazy". > Will take another look... > >> 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? > > Actually I didn't use the terms "stable" and "unstable" (I think > those were from Fink), I used the terms "release" (since the term > "archive" means that it is frozen) and "development" (or the SVN > term of "trunk"). > >> 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. > > It's much easier to do packaging and testing, when the rate of > change slows down. The automated build and packaging process is > being revised now (using it to build RPMS), and that is very useful > to have either way. > >> 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. > > Impatient or out-of-date users will occur either way, the easiest > path to help them is probably have an updated ports list for easy > viewing - such as a web page with versions and recent updates. > >> By what mechanism would you suggest that changes move between >> these two hypothetical ports trees? > > "Release Engineering". Eventually, someone will have to take a look > at it. But maybe just not today ? > > --anders > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From afb at macports.org Fri Oct 5 01:03:28 2007 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: References: <470362DE.3090602@macports.org> Message-ID: <61e25a55b48ede5173e9ac2d6c2d184c@macports.org> Juan Manuel Palacios wrote: > If you guys may remember, I suggested a somewhat large rearrangement > of our svn tree a while ago, but all in all I was met with quite a bit > of opposition so I simply dropped it (the initiative at the time, not > the desire to do it ;-). Wasn't ready for it then, isn't ready for it now. Maybe bring it up again for MacPorts 2.0... :-) I also found the post http://lists.macosforge.org/pipermail/macports-dev/2007-April/ 001159.html > I did, however, propose a "test" tree of some sort where we would > instead test MacPorts itself, freely using whatever new > features/constructs that may be in our trunk base code but not in a > MacPorts release at any moment; currently, any new MacPorts feature > has to wait for a new release before being adopted in Portfiles, which > hinders our ability to test. "mysql5" and "mysql5-devel" ports would > both live in the "release" tree if they work with whatever MacPorts > release is current, but (a copy of) any of those would have to move to > the "test" tree if the corresponding Portfile starts using syntax/code > only available in base's trunk. Users would be free to use the "test" > tree against base's trunk or the recommended "release" tree against > the current MacPorts release. This is somewhat similar, except that "test" and "development" moves in opposite directions... i.e. your ports gets pushed from release to "test" when needed for testing features, whereas the "development" tree gets pushed to "release" once released (possibly even getting some testing inbetween, i.e. development -> testing > release) Normally you'd even have a security branch that leads to backporting things for old releases. > But that layout is not limited to only those two trees, as any other > purpose-specific tree could be created to fulfill whatever need we may > have should they arise. For instance, platform specific trees could be > created: > > /ports > tiger/ > aqua/ > audio/ > (etc) > leopard/ > aqua/ > audio/ > (etc) > > Do we really need this....? Certainly not now... but who knows if we > ever do...? ;-) In any case, having the room to grow is a big plus, I > believe, and we don't have it now. I think that binaries (archives and packages) should be split by OS/major, but I don't think sources (Portfile and files/) should be unless it really really has to. That is, I prefer the "platform {}" variants. http://lists.macosforge.org/pipermail/macports-dev/2007-July/002033.html It doesn't really have to split locally (at least not until the cross-platform development features appear), but it does have to split on the server side when serving out binary packages or binary archives (i.e. pre-compiled). --anders From ryandesign at macports.org Fri Oct 5 02:01:03 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:40 2007 Subject: "port outdated" broken in trunk Message-ID: <0939B1D3-3CA1-46FB-9D54-8B37C34D8975@macports.org> In trunk @29497 "port outdated" returns the list of outdated ports: $ port outdated The following installed ports are outdated: fontconfig 2.4.2_0 < 2.4.2_1 lighttpd 1.4.15_0 < 1.4.18_0 openssh 4.7p1_0 < 4.7p1_1 p5-compress-zlib 2.006_0 < 2.007_0 wxWidgets 2.8.4_2 < 2.8.6_1 $ However in trunk @29502 "port outdated" finds nothing: $ port outdated None of the specified ports are outdated. $ I can still query individual ports: $ port outdated wxWidgets The following installed ports are outdated: wxWidgets 2.8.4_2 < 2.8.6_1 $ Or all installed ports: $ port outdated installed The following installed ports are outdated: fontconfig 2.4.2_0 < 2.4.2_1 lighttpd 1.4.15_0 < 1.4.18_0 openssh 4.7p1_0 < 4.7p1_1 p5-compress-zlib 2.006_0 < 2.007_0 wxWidgets 2.8.4_2 < 2.8.6_1 $ But is this change in behavior intentional? There were a couple commits made on trunk between r29497 and r29502 but they seemed to be related and were all made by eridius so that's as far as I felt like narrowing it down. From eridius at macports.org Fri Oct 5 07:53:48 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:40:40 2007 Subject: "port outdated" broken in trunk In-Reply-To: <0939B1D3-3CA1-46FB-9D54-8B37C34D8975@macports.org> References: <0939B1D3-3CA1-46FB-9D54-8B37C34D8975@macports.org> Message-ID: <91D27246-B071-413A-B2B5-CE8AD5509307@macports.org> Those two commits have nothing to do with this. I'm as mystified by this as you are. On Oct 5, 2007, at 5:01 AM, Ryan Schmidt wrote: > In trunk @29497 "port outdated" returns the list of outdated ports: > > $ port outdated > The following installed ports are outdated: > fontconfig 2.4.2_0 < 2.4.2_1 > lighttpd 1.4.15_0 < 1.4.18_0 > openssh 4.7p1_0 < 4.7p1_1 > p5-compress-zlib 2.006_0 < 2.007_0 > wxWidgets 2.8.4_2 < 2.8.6_1 > $ > > However in trunk @29502 "port outdated" finds nothing: > > $ port outdated > None of the specified ports are outdated. > $ > > I can still query individual ports: > > $ port outdated wxWidgets > The following installed ports are outdated: > wxWidgets 2.8.4_2 < 2.8.6_1 > $ > > Or all installed ports: > > $ port outdated installed > The following installed ports are outdated: > fontconfig 2.4.2_0 < 2.4.2_1 > lighttpd 1.4.15_0 < 1.4.18_0 > openssh 4.7p1_0 < 4.7p1_1 > p5-compress-zlib 2.006_0 < 2.007_0 > wxWidgets 2.8.4_2 < 2.8.6_1 > $ > > But is this change in behavior intentional? > > There were a couple commits made on trunk between r29497 and r29502 > but they seemed to be related and were all made by eridius so that's > as far as I felt like narrowing it down. > -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com From sfiera at macports.org Fri Oct 5 08:06:31 2007 From: sfiera at macports.org (Chris Pickel) Date: Tue Oct 9 16:40:40 2007 Subject: "port outdated" broken in trunk In-Reply-To: <91D27246-B071-413A-B2B5-CE8AD5509307@macports.org> References: <0939B1D3-3CA1-46FB-9D54-8B37C34D8975@macports.org> <91D27246-B071-413A-B2B5-CE8AD5509307@macports.org> Message-ID: On 05 Oct, 2007, at 10:53, Kevin Ballard wrote: > Those two commits have nothing to do with this. I'm as mystified by > this as you are. > > On Oct 5, 2007, at 5:01 AM, Ryan Schmidt wrote: > >> In trunk @29497 "port outdated" returns the list of outdated ports: >> ... >> However in trunk @29502 "port outdated" finds nothing: >> ... >> But is this change in behavior intentional? >> >> There were a couple commits made on trunk between r29497 and >> r29502 but they seemed to be related and were all made by eridius >> so that's as far as I felt like narrowing it down. I believe this is due to the API change in r29191 that changed from global_option_isset to macports::global_option_isset. Note that port.tcl:2349, which is responsible for setting ports_no_args, was unchanged. I'm not sure what the appropriate API for *setting* such values is, but I'm looking into it and should hopefully be able to commit a fix soon. Anyone with more info is welcome to contact me on irc. Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071005/cfad5552/PGP.bin From jberry at macports.org Fri Oct 5 08:15:35 2007 From: jberry at macports.org (James Berry) Date: Tue Oct 9 16:40:40 2007 Subject: "port outdated" broken in trunk In-Reply-To: References: <0939B1D3-3CA1-46FB-9D54-8B37C34D8975@macports.org> <91D27246-B071-413A-B2B5-CE8AD5509307@macports.org> Message-ID: On Oct 5, 2007, at 8:06 AM, Chris Pickel wrote: > On 05 Oct, 2007, at 10:53, Kevin Ballard wrote: >> Those two commits have nothing to do with this. I'm as mystified >> by this as you are. >> >> On Oct 5, 2007, at 5:01 AM, Ryan Schmidt wrote: >> >>> In trunk @29497 "port outdated" returns the list of outdated ports: >>> ... >>> However in trunk @29502 "port outdated" finds nothing: >>> ... >>> But is this change in behavior intentional? >>> >>> There were a couple commits made on trunk between r29497 and >>> r29502 but they seemed to be related and were all made by eridius >>> so that's as far as I felt like narrowing it down. > > I believe this is due to the API change in r29191 that changed from > global_option_isset to macports::global_option_isset. Note that > port.tcl:2349, which is responsible for setting ports_no_args, was > unchanged. > > I'm not sure what the appropriate API for *setting* such values is, > but I'm looking into it and should hopefully be able to commit a > fix soon. Anyone with more info is welcome to contact me on irc. Yes, it seems to be the change in usage of global_options that broke this. The port(1) code in port.tcl is written to assume global_options is its own private variable (which it is: was). Note the use global_options_base, too, from which global_options is reset during processing of multiple commands. James From eridius at macports.org Fri Oct 5 08:15:57 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:40:40 2007 Subject: "port outdated" broken in trunk In-Reply-To: References: <0939B1D3-3CA1-46FB-9D54-8B37C34D8975@macports.org> <91D27246-B071-413A-B2B5-CE8AD5509307@macports.org> Message-ID: <94BF7D5B-3249-4A5D-A753-5FC225F738B9@macports.org> Ah hah. It seems port(1) is using the global options array to hold its own private options as well. There are two possible solutions. The first is to make port(1) stop using macports::global_option_isset and make it just check the global_options array directly. The second is to make port(1) use a separate array for its private options and check that directly. On Oct 5, 2007, at 11:06 AM, Chris Pickel wrote: > On 05 Oct, 2007, at 10:53, Kevin Ballard wrote: >> Those two commits have nothing to do with this. I'm as mystified by >> this as you are. >> >> On Oct 5, 2007, at 5:01 AM, Ryan Schmidt wrote: >> >>> In trunk @29497 "port outdated" returns the list of outdated ports: >>> ... >>> However in trunk @29502 "port outdated" finds nothing: >>> ... >>> But is this change in behavior intentional? >>> >>> There were a couple commits made on trunk between r29497 and >>> r29502 but they seemed to be related and were all made by eridius >>> so that's as far as I felt like narrowing it down. > > I believe this is due to the API change in r29191 that changed from > global_option_isset to macports::global_option_isset. Note that > port.tcl:2349, which is responsible for setting ports_no_args, was > unchanged. > > I'm not sure what the appropriate API for *setting* such values is, > but I'm looking into it and should hopefully be able to commit a fix > soon. Anyone with more info is welcome to contact me on irc. > > > Chris -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com From jmpp at macports.org Fri Oct 5 09:55:44 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: <61e25a55b48ede5173e9ac2d6c2d184c@macports.org> References: <470362DE.3090602@macports.org> <61e25a55b48ede5173e9ac2d6c2d184c@macports.org> Message-ID: <917D88DD-E4E8-42D2-B015-CC89F2B1477C@macports.org> On Oct 5, 2007, at 4:03 AM, Anders F Bj?rklund wrote: > Juan Manuel Palacios wrote: > >> If you guys may remember, I suggested a somewhat large >> rearrangement of our svn tree a while ago, but all in all I was >> met with quite a bit of opposition so I simply dropped it (the >> initiative at the time, not the desire to do it ;-). > > Wasn't ready for it then, isn't ready for it now. Maybe bring it up > again for MacPorts 2.0... :-) > > I also found the post http://lists.macosforge.org/pipermail/ > macports-dev/2007-April/001159.html > >> I did, however, propose a "test" tree of some sort where we would >> instead test MacPorts itself, freely using whatever new features/ >> constructs that may be in our trunk base code but not in a >> MacPorts release at any moment; currently, any new MacPorts >> feature has to wait for a new release before being adopted in >> Portfiles, which hinders our ability to test. "mysql5" and "mysql5- >> devel" ports would both live in the "release" tree if they work >> with whatever MacPorts release is current, but (a copy of) any of >> those would have to move to the "test" tree if the corresponding >> Portfile starts using syntax/code only available in base's trunk. >> Users would be free to use the "test" tree against base's trunk or >> the recommended "release" tree against the current MacPorts release. > > This is somewhat similar, except that "test" and "development" > moves in opposite directions... > > i.e. your ports gets pushed from release to "test" when needed for > testing features, whereas the "development" tree gets pushed to > "release" once released (possibly even getting some testing > inbetween, i.e. development -> testing > release) It's a matter of approaches. I just don't like the Fink Stable Vs. Unstable approach and, although not recently, the inability to use unreleased features in our Portfiles is something that has concerned many of us repeatedly, as it severely hinders our testing abilities. Therefore, a "trunk", "testing" or whatever tree for Portfiles that work with base' trunk at any moment (without the constraint of not breaking use installations) seemed like a good approach to me. I should emphasize again that said approach does *not* aim at testing ported software versions, e.g. the latest rpm5 alpha build, but MacPorts unreleased features instead. But,... > > Normally you'd even have a security branch that leads to > backporting things for old releases. My proposed model leaves open room to grow any number of port trees we might ever need, including "security" and even Stable Vs. Unstable of for whatever reason we deem it appropriate one day ;-) > ---snip--- > > I think that binaries (archives and packages) should be split by OS/ > major, but I don't think sources (Portfile and files/) should be > unless it really really has to. That is, I prefer the "platform {}" > variants. Agree, totally platform blocks for the win! I only used the platform trees as examples of what we could do should we ever need to, based on my proposed reorganization. Exporting any of these trees to users would also be as simple as adapting the base/portmgr/mprsyncup script to server them. But,... > > http://lists.macosforge.org/pipermail/macports-dev/2007-July/ > 002033.html > > It doesn't really have to split locally (at least not until the > cross-platform development features appear), but it does have to > split on the server side when serving out binary packages or binary > archives (i.e. pre-compiled). Yeah, a regular user should only see the need for using a single tree, the one we would serve up by default ("release"), unless very specific needs drove him/her some secondary tree for whatever reason (e.g., a MacPorts developers wanting to test with real life Portfiles a new feature that hasn't been released ;-) But I'll now stop insisting on that, I just liked the idea of being able to create any number of trees should we ever need to. As for binaries, we will need to have platform specific trees, but I don't see those belonging in SVN (ftp, webdav, plain HTTP, whatever, but not SVN) so this particular part of the discussion may be out of scope [1]. Regards,... -jmpp [1] Some people have suggested before we pull the ports tree out of svn entirely, but I disagree with that. Having history tracking for Portfiles and being able to see how they have evolved is a very big plus in my opinion, but that argument does not apply to packages, I believe, as they are simply the end result of the Portfiles... for which we have history tracking ;-) And as for tracing the builds.... you guessed it: http://trac.macports.org/projects/macports/wiki/ PortLoggingProposal (specially the part on post-processing of the logs into tabulated web pages). From libc.mail at gmail.com Fri Oct 5 11:02:03 2007 From: libc.mail at gmail.com (libc) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: References: <470362DE.3090602@macports.org> Message-ID: 2007/10/5, Juan Manuel Palacios : > And about automated testing through automated ports build runs: this > is one of the primary goals I am aiming for in the mid-term future, > but there are in my opinion a couple of key components we are still > missing to be able to do it properly. One of those is full a blown > trace mode so that we can have all the needed information about > everything that goes on outside the destroot sandbox; this depends on > Eugene's GSoC work so I guess this is a great oportunity to ask for a > status update on that (as I did tonight with Chris on IRC ;-). > Eugene, could you please bring us up to speed with the state of your > work? http://trac.macports.org/projects/macports/wiki/soc2007/epimenov > -jmpp > > > [1] I asked Chris for a status update on his GSoC work spanning a few > key points: > > -) original goals; > -) if they were modified along the way, how? > -) how successfully did you achieve your original and/or modified > goals? > -) future plans for your end result product(s), most certainly > including how you plan to use it (them) in MacPorts > > Eugene and Elias, you think you could please put something like that > together for us? It would greatly help us plan future MacPorts > releases. Thank you! > > > > On Oct 4, 2007, at 2:54 AM, Anders F Bj?rklund wrote: > > > Ryan Schmidt wrote: > > > >>> 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. > > > > Took a quick look, but it was mostly about "are you guys crazy". > > Will take another look... > > > >> 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? > > > > Actually I didn't use the terms "stable" and "unstable" (I think > > those were from Fink), I used the terms "release" (since the term > > "archive" means that it is frozen) and "development" (or the SVN > > term of "trunk"). > > > >> 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. > > > > It's much easier to do packaging and testing, when the rate of > > change slows down. The automated build and packaging process is > > being revised now (using it to build RPMS), and that is very useful > > to have either way. > > > >> 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. > > > > Impatient or out-of-date users will occur either way, the easiest > > path to help them is probably have an updated ports list for easy > > viewing - such as a web page with versions and recent updates. > > > >> By what mechanism would you suggest that changes move between > >> these two hypothetical ports trees? > > > > "Release Engineering". Eventually, someone will have to take a look > > at it. But maybe just not today ? > > > > --anders > > > > _______________________________________________ > > macports-dev mailing list > > macports-dev@lists.macosforge.org > > http://lists.macosforge.org/mailman/listinfo/macports-dev > > From dluke at geeklair.net Fri Oct 5 13:04:53 2007 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue Oct 9 16:40:40 2007 Subject: Split Trunk In-Reply-To: <917D88DD-E4E8-42D2-B015-CC89F2B1477C@macports.org> References: <470362DE.3090602@macports.org> <61e25a55b48ede5173e9ac2d6c2d184c@macports.org> <917D88DD-E4E8-42D2-B015-CC89F2B1477C@macports.org> Message-ID: > Yeah, a regular user should only see the need for using a single > tree, the one we would serve up by default ("release"), unless very > specific needs drove him/her some secondary tree for whatever > reason (e.g., a MacPorts developers wanting to test with real life > Portfiles a new feature that hasn't been released ;-) There's nothing that stops macports developers from having their own trees where they test new features that they're working on. Having another port tree in the repo doesn't help us get more testing if we're not pushing users to it somehow (and I don't know how that would work since we'd also be pushing them to run on pre-release base/) -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20071005/3072835d/PGP.bin From ramercer at gmail.com Sun Oct 7 10:05:06 2007 From: ramercer at gmail.com (Adam Mercer) Date: Tue Oct 9 16:40:40 2007 Subject: UPDATE: #12822 python/py-pexpect 2.1 Message-ID: <799406d60710071005rb64aa10yd7671aea2e13dab7@mail.gmail.com> 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 From ryandesign at macports.org Sun Oct 7 14:31:34 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:40 2007 Subject: UPDATE: #12822 python/py-pexpect 2.1 In-Reply-To: <799406d60710071005rb64aa10yd7671aea2e13dab7@mail.gmail.com> References: <799406d60710071005rb64aa10yd7671aea2e13dab7@mail.gmail.com> Message-ID: <34582A03-9AFC-477F-BFB2-770509E23EC3@macports.org> On Oct 7, 2007, at 12:05, Adam Mercer wrote: > 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 I got it! Thanks. From boeyms at macports.org Sun Oct 7 15:54:46 2007 From: boeyms at macports.org (Boey Maun Suang) Date: Tue Oct 9 16:40:40 2007 Subject: cups-headers on Panther In-Reply-To: References: Message-ID: <9FBEA1F9-FB53-424B-82E3-FD46E5FDF31B@macports.org> On 04/10/2007, at 23:47, N_Ox wrote: > Could someone still running MP on a Panther box test the patch from > ticket #12768? Finally I get to test something on the second-hand dual G5 PowerMac I bought specifically for this :P On said PowerMac running 10.3.9 and XCode 1.5 with the November 2004 GCC update, your patch from #12768 installed fine, and both libgnomecups and gtk2, which state dependence on cups-headers, built and installed fine. Note, however, that I don't have any printers to connect to to test how well this works with end-user apps (and I haven't found a GTK or Gnome app that would be useful to me, though I'll happily take suggestions). I also noted from the debug output that neither libgnomecups nor gtk2 called the cups-config executable for information on how to link. If it's of any use to anyone, I'll attach to the ticket the output from cups-config when called with all the possible command-line options except help. Kind regards, Maun Suang -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org From rhwood at mac.com Sun Oct 7 18:16:18 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:40 2007 Subject: Reference Portfile Message-ID: <73472010-DD6A-468B-9ABD-928105726552@mac.com> Does anyone have a reference portfile that adheres to all recommended standards? Randall Wood rhwood@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." From yves at macports.org Mon Oct 8 07:44:11 2007 From: yves at macports.org (Yves de Champlain) Date: Tue Oct 9 16:40:40 2007 Subject: [29735] trunk/dports/x11/gtk-engines2/Portfile In-Reply-To: <20071008093434.1FF9284BB3C@cvs.opensource.apple.com> References: <20071008093434.1FF9284BB3C@cvs.opensource.apple.com> Message-ID: <4DCC7728-7A9A-4BCA-A3E1-7F0F6118093F@macports.org> Le 07-10-08 ? 05:34, source_changes@macosforge.org a ?crit : > Revision > 29735 > Author > rhwood@macports.org > Date > 2007-10-08 02:34:33 -0700 (Mon, 08 Oct 2007) > Log Message > > Update dependencies based on trace output > -depends_build port:p5-xml-parser > > -depends_lib port:gtk2 > +depends_build \ > + port:expat \ > + port:p5-xml-parser \ > + port:perl5.8 > +depends_lib \ > + port:atk \ > + port:cairo \ > + port:fontconfig \ > + port:freetype \ > + port:gettext \ > + port:glib2 \ > + port:gtk2 \ > + port:jpeg \ > + port:libiconv \ > + port:libpng \ > + port:pango \ > + port:tiff Sorry, but does this make any sense at all ? I think all it will do is make the dependency checking phase even longer and the Portfile stuffier. And what about the gnome port ? yves -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20071008/810c8566/attachment.html From n.oxyde at gmail.com Mon Oct 8 11:45:30 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:40 2007 Subject: [29735] trunk/dports/x11/gtk-engines2/Portfile In-Reply-To: <4DCC7728-7A9A-4BCA-A3E1-7F0F6118093F@macports.org> References: <20071008093434.1FF9284BB3C@cvs.opensource.apple.com> <4DCC7728-7A9A-4BCA-A3E1-7F0F6118093F@macports.org> Message-ID: Le 8 oct. 07 ? 16:44, Yves de Champlain a ?crit : > > Le 07-10-08 ? 05:34, source_changes@macosforge.org a ?crit : > >> Revision 29735 Author rhwood@macports.org Date 2007-10-08 02:34:33 >> -0700 (Mon, 08 Oct 2007) Log MessageUpdate dependencies based on >> trace output-depends_build port:p5-xml-parser >> -depends_lib port:gtk2 +depends_build \ + port:expat \ + port:p5- >> xml-parser \ + port:perl5.8 +depends_lib \ + port:atk \ + >> port:cairo \ + port:fontconfig \ + port:freetype \ + port:gettext >> \ + port:glib2 \ + port:gtk2 \ + port:jpeg \ + port:libiconv \ + >> port:libpng \ + port:pango \ + port:tiff > Sorry, but does this make any sense at all ? > I think all it will do is make the dependency checking phase even > longer and the Portfile stuffier. > And what about the gnome port ? > yves > > It does make sense if all of these are hard dependencies (as in "hardcoded in configure.in or somewhere else.") We should not do "If A depends on B and C and B depends on C, then let's say A depends on B only." -- Anthony Ramine, the infamous MacPorts Trac slave. nox@macports.org From yves at macports.org Mon Oct 8 12:49:27 2007 From: yves at macports.org (Yves de Champlain) Date: Tue Oct 9 16:40:40 2007 Subject: [29735] trunk/dports/x11/gtk-engines2/Portfile In-Reply-To: References: <20071008093434.1FF9284BB3C@cvs.opensource.apple.com> <4DCC7728-7A9A-4BCA-A3E1-7F0F6118093F@macports.org> Message-ID: <057B0F4D-EA5F-4F8B-8E1F-78E7973B967F@macports.org> Le 07-10-08 ? 14:45, N_Ox a ?crit : > > Le 8 oct. 07 ? 16:44, Yves de Champlain a ?crit : > >> >> Le 07-10-08 ? 05:34, source_changes@macosforge.org a ?crit : >> >>> Revision 29735 Author rhwood@macports.org Date 2007-10-08 >>> 02:34:33 -0700 (Mon, 08 Oct 2007) Log MessageUpdate dependencies >>> based on trace output-depends_build port:p5-xml-parser >>> -depends_lib port:gtk2 +depends_build \ + port:expat \ + port:p5- >>> xml-parser \ + port:perl5.8 +depends_lib \ + port:atk \ + >>> port:cairo \ + port:fontconfig \ + port:freetype \ + port:gettext >>> \ + port:glib2 \ + port:gtk2 \ + port:jpeg \ + port:libiconv \ + >>> port:libpng \ + port:pango \ + port:tiff >> Sorry, but does this make any sense at all ? >> I think all it will do is make the dependency checking phase even >> longer and the Portfile stuffier. >> And what about the gnome port ? >> yves >> >> > > It does make sense if all of these are hard dependencies (as in > "hardcoded in configure.in or somewhere else.") > We should not do "If A depends on B and C and B depends on C, then > let's say A depends on B only." Why not ? yves From ryandesign at macports.org Mon Oct 8 12:57:10 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:40 2007 Subject: [29735] trunk/dports/x11/gtk-engines2/Portfile In-Reply-To: <057B0F4D-EA5F-4F8B-8E1F-78E7973B967F@macports.org> References: <20071008093434.1FF9284BB3C@cvs.opensource.apple.com> <4DCC7728-7A9A-4BCA-A3E1-7F0F6118093F@macports.org> <057B0F4D-EA5F-4F8B-8E1F-78E7973B967F@macports.org> Message-ID: <497FA7B7-4589-49D2-84F4-4C14BA925FAB@macports.org> On Oct 8, 2007, at 14:49, Yves de Champlain wrote: > Le 07-10-08 ? 14:45, N_Ox a ?crit : > >> Le 8 oct. 07 ? 16:44, Yves de Champlain a ?crit : >> >>> Le 07-10-08 ? 05:34, source_changes@macosforge.org a ?crit : >>> >>>> Revision 29735 Author rhwood@macports.org Date 2007-10-08 >>>> 02:34:33 -0700 (Mon, 08 Oct 2007) Log MessageUpdate dependencies >>>> based on trace output-depends_build port:p5-xml-parser >>>> -depends_lib port:gtk2 +depends_build \ + port:expat \ + port:p5- >>>> xml-parser \ + port:perl5.8 +depends_lib \ + port:atk \ + >>>> port:cairo \ + port:fontconfig \ + port:freetype \ + >>>> port:gettext \ + port:glib2 \ + port:gtk2 \ + port:jpeg \ + >>>> port:libiconv \ + port:libpng \ + port:pango \ + port:tiff >>> >>> Sorry, but does this make any sense at all ? >>> I think all it will do is make the dependency checking phase even >>> longer and the Portfile stuffier. >>> And what about the gnome port ? >> >> It does make sense if all