From randall.h.wood at alexandriasoftware.com Thu May 1 03:07:12 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Thu May 1 03:03:56 2008 Subject: Fwd: [36423] adium Lint Report In-Reply-To: <20080501095854.4A359420002@relay12.apple.com> References: <20080501095854.4A359420002@relay12.apple.com> Message-ID: Port growl exists, but I'm getting the forwarded message. Can anyone explain? 'port lint' reports no issues: Obilex:adium rhwood$ sudo port lint Password: ---> Verifying Portfile for adium ---> 0 errors and 0 warnings found. ---------- Forwarded message ---------- From: Date: Thu, May 1, 2008 at 5:55 AM Subject: [36423] adium Lint Report To: rhwood@macports.org, rhwood@macports.org Portfile: adium Error: Unknown dependency: growl -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From ryandesign at macports.org Thu May 1 03:32:26 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu May 1 03:29:13 2008 Subject: [36423] adium Lint Report In-Reply-To: References: <20080501095854.4A359420002@relay12.apple.com> Message-ID: <712690E2-5350-4D52-AA10-2EBEC7A676A3@macports.org> Port growl doesn't exist. Port Growl exists. :) Case-sensitive, apparently. On May 1, 2008, at 5:07 AM, Randall Wood wrote: > Port growl exists, but I'm getting the forwarded message. Can > anyone explain? > > 'port lint' reports no issues: > > Obilex:adium rhwood$ sudo port lint > Password: > ---> Verifying Portfile for adium > ---> 0 errors and 0 warnings found. > > > ---------- Forwarded message ---------- > From: > Date: Thu, May 1, 2008 at 5:55 AM > Subject: [36423] adium Lint Report > To: rhwood@macports.org, rhwood@macports.org > > > Portfile: adium > > > Error: Unknown dependency: growl From armahg at gmail.com Thu May 1 12:59:31 2008 From: armahg at gmail.com (George Armah) Date: Thu May 1 12:56:15 2008 Subject: Who Is Going to Be at WWDC 08 ? Message-ID: <481A2123.9070403@gmail.com> Hello, I'm George Armah (Armahg on IRC), your GSoC student who will be working with Randall Wood on the MacPorts Objective-C Framework. I just found out yesterday that Apple gave me a student scholarship to attend WWDC :) 8. I was wondering who else from MacPorts was going to be there. Perhaps it would be nice to meet up at some point during the conference? Thanks, George. From wsiegrist at apple.com Thu May 1 14:00:41 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu May 1 13:58:53 2008 Subject: Who Is Going to Be at WWDC 08 ? In-Reply-To: <481A2123.9070403@gmail.com> References: <481A2123.9070403@gmail.com> Message-ID: <81EBFFA7-BBD1-428B-9D4A-9806C721BC70@apple.com> On May 1, 2008, at 12:59 PM, George Armah wrote: > Hello, > > I'm George Armah (Armahg on IRC), > your GSoC student who will be working with Randall Wood on the > MacPorts Objective-C Framework. > I just found out yesterday that Apple gave me a student scholarship > to attend WWDC :) 8. > > I was wondering who else from MacPorts was going to be there. > Perhaps it would be nice to meet up at some point during the > conference? > I live in the SF area, so I'm always around, and I should be at WWDC for at least 1 day. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080501/66fc799a/smime.bin From raimue at macports.org Thu May 1 17:52:05 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu May 1 17:48:51 2008 Subject: HOWTO: Get started, gain macports-foo, make bad first impression In-Reply-To: References: <4818AB0E.50702@shopwatch.org> <1B8EA38A-D808-4006-AEEC-19D489D533DE@geeklair.net> Message-ID: <481A65B5.1030702@macports.org> Ryan Schmidt wrote: > The other problem with parallel builds is that they are not identical > each time you run them. The build may succeed 3 times, then fail the > 4th. I personally haven't had the time to try to build each of my > ports several times with parallel build on to see if they repeatably > build correctly. If the port does not build correctly the dependencies in the Makefile are wrong. If it ever fails for someone and he/she files some ticket it can be disabled. Usually there is no need to test it multiple times or something like that. Locally I use a patched version since this option was introduced which has "use_parallel_build yes" as default. And so far port failed only on one occasion due to parallel building which was the python frameworks. And as a side note, I am still in favor of making parallel building opt-out and enable it for every port when buildmakejobs is set to a value greater 1. Of course the default value of buildmakejobs should still be 1 because this really depends on the machine it runs on. [snip] > Maybe we should revisit this topic, though like you say, if we get > binary packages, then we don't need build success/failure statistics > from each user, but only from the build servers. As I said before in other emails, we will not be able to provide packages for each and every variant combination (that would be 2^n for a port with n variants). So building custom ports on the end-user side will still happen even once we ship binary packages for default_variants. Rainer From jmpp at macports.org Fri May 2 01:26:32 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Fri May 2 01:23:22 2008 Subject: New MacPorts release and immediate future plans In-Reply-To: <59F11B4B-8A54-4224-B1D5-CE6A978F2A63@macports.org> References: <1146792E-1584-457C-A57F-16FD5F229F8B@macports.org> <59F11B4B-8A54-4224-B1D5-CE6A978F2A63@macports.org> Message-ID: <07F7435E-64BE-46D9-9099-88F03B0C7D9C@macports.org> On Apr 27, 2008, at 3:01 AM, Ryan Schmidt wrote: > Welcome back, jmpp. I'm quite relieved to hear from you! Hi Ryan, it's good to be back! > > > I don't believe in these .5 releases for the sake of .5 releases... > especially in the third digit. ("System 7.5" sounds cooler than > "System 7.2" but "System 7.1.5" doesn't sound that much more > impressive than "System 7.1.2".) Either call it 1.7.0 since it > includes so much new stuff, or call it 1.6.1 since we're probably > releasing from the 1.6 branch. As said, release numbers are mostly arbitrary, so we can go with whatever we want. And by popular demand, lets indeed make it a 1.6.1 release (still), 'cause even though much has happened since 1.6.0 it's all been about bug fixing. > > > The new release should include the greatly enhanced port lint code > which is already trunk, and we should also resolve this port lint > ticket before the release: > > http://trac.macosforge.org/projects/macports/ticket/14799 > > I would be happy to commit the three patches I attached there if you > approve. > > \r Gattaca-like Portfile cleanness is absolutely a maintainer's choice (one that I'd make, but on a personal basis), so I agree we shouldn't waste people's time with such pedantry and thus deter them from reading what would otherwise be a useful report on real warnings. On this note, I second moving to: -) warning of trailing whitespace only when the last line character is a backslash (http://trac.macports.org/attachment/ticket/14799/portlint.tcl.trailing-whitespace.diff ), as these are mostly unnoticeable to humans and could lead to real problems with the Portfile; -) not advising how the Portfile should look like, i.e. blank lines, as this is easily one of the most personal things of all and we have no business dictating it (http://trac.macosforge.org/projects/macports/attachment/ticket/14799/portlint.tcl.blank-lines.diff ); -) not advising on patchfile naming in any way (either if that's patch- *.diff, patch-*, *.diff or *.patch) at the lint level. From the very beginning this was only a suggestion that most of us agreed on, so we can still keep it in the guide and elsewhere as such, a suggestion; but it was just that, a suggestion, so I really don't think we have any business annoying a maintainer who, after reading the guide and what-not, has still chosen to name his patches in whatever other way. So my take on this particular issue is that we should remove all patch naming checks from lint, and as a direct result any [file exists foo] checks, which would instantly resolve Bill's comments at the very end of that ticket. So, all in all, I'm seconding the first two patches and vote for a reworked third one per my comments, even though my personal taste would be against them (I'm not trying to say I'm special or anything, but rather emphasizing that our personal tastes are just that, personal). Regards,... -jmpp PS: The 1.6.1 milestone has been created, http://trac.macports.org/milestone/MacPorts%201.6.1 (bit woot to Bill for our new URLs!). Tomorrow I'll work on filing 1.6.1 relevant tickets into it, getting a ChangeLog together and addressing some other comments in this thread, but my schedule shouldn't keep anyone else from doing any legwork if you already have some tickets handy. > On Apr 26, 2008, at 10:03 PM, Juan Manuel Palacios wrote: > >> >> Evening all developers! >> >> First off, I'd like to apologize for being so inactive lately, a >> somewhat forced hiatus has kept me away from MacPorts, and most of >> my online life for that matter, for the last couple of months. I >> understand how that may seem like I've lost interest in the >> project, and in my PortMgr position, but I can assure you that's >> not the case. The issues that were holding me back have now been >> cleared to a large extent so I should be considerably more >> available from now on. >> >> I am glad to tell you that we've had some interesting activity >> lately, even though it may seem to most of you like things have >> largely stalled. I can assure you that's not the case either. In >> the past month those of us who volunteered to be GSoC08 mentors >> have been working hard to put together our summer plans, and I'm >> glad to say that things are looking interesting. >> >> I am most proud to inform that we received not only a high number >> of applications (always a good thing), but also some very solid >> ones from more capable students than we could harbor. As a result >> will be conducting development with our four alloted students on >> key areas of the mid to long term future of MacPorts: >> >> 1) Logging support, per my proposal at http://trac.macports.org/projects/macports/wiki/LoggingProposal >> (hopefully, as it is explicitly stated in the proposal itself, >> this work will help open up the doors to binary packaging done the >> right way, something that's been debated here quite a bit lately); >> >> 2) MacPorts Web Application (a.k.a. MPWA), which among other things >> will hopefully evolve to process the result of log submissions >> (task 1 above) to provide real time information of the status of >> our ports tree; >> >> 3) MacPorts Framework, an initiative to endow MacPorts with a high >> level API written in Cocoa to open up the doors to a myriad of >> possibilities, including things like a Cocoa GUI >> >> 4) Root privileges, to make safer and better use of the powers >> we're granted through sudo to run in a more secure environment >> >> We learned quite a bit from last year's GSoC experience, so this >> time round we're taking the necessary steps to ensure a proper use >> of resources and that the deliverables of this work are properly >> seen through to completion and integration into our shipping product. >> >> Now, as for the immediate future of MacPorts, I think we all agree >> the time is ripe (or more than) for a new quick release that'll >> incorporate many of the recent enhancements and bug fixes trunk has >> seen recently. I've been collecting ideas and roadmap suggestions >> for what should go into this new issue of MacPorts, but I have been >> away for a while and therefore it's easy for me to miss a thing or >> to. So I'd love to hear what any of you has to say about a still >> theoretical 1.6.5 release (what should go in, what should not, etc). >> >> And about the release number: I was originally aiming for a small >> 1.6.1 which never took place, and a lot has happened since but >> maybe not enough for a 1.7.0. The main issue with these numbers is >> that we're still not working on a release driven cycle; for that >> reason mostly, our release numbers are mostly meaningless at >> present and only indicative of where we feel we are on a very >> subjective timeline. This is something many have pointed out as in >> need of fixing, and I'd just like to say that I'm strongly >> seconding that initiative. >> >> We're not making any API incompatible changes at present, so our >> numbers will still be arbitrary to certain degree. But hopefully >> the work that will be put into GSoC and other initiatives too will >> give us enough material to at least conduct a feature-driven >> release cycle. >> >> In any case, I propose that from now on we also try to adopt a >> schedule for minor, bug fixing releases, even if a loose one, so >> that after a given number of weeks/months we force ourselves to re- >> evaluate the state of trunk and the current release branch to asses >> what is ready for general consumption and/or in need of a broader >> testing audience. This will also help us fight the perception of a >> stale project. >> >> What should that schedule be? What new features will go into major >> releases and which ones into minor releases? Hopefully answering >> those questions will encourage us to put our Trac roadmap to better >> use, something that has been criticized lately too. >> >> For the moment, I propose we do 1.6.5 with bug fixes against >> what's currently shipping in 1.6.0, including (but not limited to): >> >> -) my postflight installer bug (already fixed in the release_1_6 >> branch); >> -) what's been done on universal building and choosing of SDK && MDT; >> -) improved fetching code; >> -) improved dependency handling; >> -) improved selfupdate target (my part on this work is done). >> >> I'd love to hear feedback on any and all of the topics touched in >> this mail, but at least on what's relevant for 1.6.5. I'll create >> an appropriate milestone for this new release so that we can start >> classifying tickets accordingly. >> >> And this is already a bit of a long mail, as usual for me, so I'll >> cap it here and wait for your feedback, hoping you're not still >> soar at me for having disappeared! >> >> Regards,... >> >> >> -jmpp From ryandesign at macports.org Fri May 2 02:36:10 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri May 2 02:32:55 2008 Subject: Who Is Going to Be at WWDC 08 ? In-Reply-To: <481A2123.9070403@gmail.com> References: <481A2123.9070403@gmail.com> Message-ID: On May 1, 2008, at 2:59 PM, George Armah wrote: > I'm George Armah (Armahg on IRC), > your GSoC student who will be working with Randall Wood on the > MacPorts Objective-C Framework. > I just found out yesterday that Apple gave me a student scholarship > to attend WWDC :) 8. > > I was wondering who else from MacPorts was going to be there. > Perhaps it would be nice to meet up at some point during the > conference? Congratulations! It was a lot of fun when I went to WWDC '98 as a student developer. I got to see Douglas Adams! Going to the sessions, meeting all the other smart people... it was a great experience. I'm not going because it is quite an expense, but I'm sure you'll have a great time! From lists-macports at shopwatch.org Fri May 2 04:45:14 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Fri May 2 04:42:12 2008 Subject: HOWTO: Get started, gain macports-foo, make bad first impression In-Reply-To: <1B8EA38A-D808-4006-AEEC-19D489D533DE@geeklair.net> References: <4818AB0E.50702@shopwatch.org> <1B8EA38A-D808-4006-AEEC-19D489D533DE@geeklair.net> Message-ID: <481AFECA.3050604@shopwatch.org> Daniel J. Luke wrote: > On Apr 30, 2008, at 1:23 PM, Jay Levitt wrote: >> But I have absolutely no idea how to go about incorporating others' >> fixes, or trying and submitting my own. And the FAQ doesn't have a >> "how can I get involved" section. Any tips/pointers? > > Have you read the guide? (http://guide.macports.org) Nope, I totally missed that. I went straight for the FAQ. I'm not sure if this reflects more on the FAQ, or on my reading comprehension skills... OK, I am sure, I just don't like to talk about it. The doc looks great. Ah, but now I see why I missed it. Once you go to the FAQ, you're in Trac, not the main CMS. So the "Documentation" part of the navigation bar (among others) is missing! I'd recommend that the Trac nav-bar add a third section, rather than replacing the "Getting Started" section with its own goodies. > That ticket is marked as fixed and checked in in r34520, so you just > need to do 'port selfupdate' or 'port sync' to make sure you have the > latest Portfile and you'll already have that fix. Now I'm very confused. I *did* do a "port selfupdate" and it gave me the impression that nothing changed. (I wish Terminal saved your old scrollback buffers so I could see it now...) Yet, apparently, it did, because my edited Portfile is gone, the real Portfile is now the one from r34520, and libwww builds just fine. I'll keep a better logfile next time it happens. > If it's for a port that currently doesn't have a maintainer, it would be > great if you would be willing to maintain the port! What sort of commitment is involved in being a maintainer? I have a sordid history of 1. Feeling a lot of pain when first installing something 2. Swearing that I will be the one to fix it once and for all 3. No longer feeling that pain 4. Look, there's something shiny over there! That said, I'll be happy to volunteer as a "good god, I must be better than no maintainer at all" type maintainer when I find bugs. > I don't think anyone is working on anything like that, there was some > discussion in the past, with the takeaway that it would need to be off > by default and optionally opt-in if it were something that was even > going to be added. Oh, absolutely. I'm a staunch privacy and consent advocate. It would have to be off, opt-in, and as anonymized/obscured as possible. >> It seems to me that the best solution for this, and for any breaking >> change, would be to allow end users to opt-in and become part of the >> macports "build farm". Instead of a yes/no flag for parallel builds, >> add a third state: experimental. Experimental would build everything >> in parallel, run the unit tests, > > Not ever port has tests available from the upstream, and not every end > user has a 'clean' build environment (so this would also require either > getting chroot/trace mode/whatever build environment working well enough > to make it the default, and probably storing state other than OK/Not OK > - since ports could build fine but not work, and it would be difficult > to test every port that doesn't already have a comprehensive test suite). Good points. The feedback loop would probably work best as an information resource for the maintainer, rather than an automatic switch-flipper. Put one way: Right now we have the degenerate version of this. The "build farm" is whatever platform the maintainer uses (if there even is a maintainer), the amount of user feedback is zero, and the regression tests are whatever the maintainer happens to try. Anything we can add to that is gravy. >> and report back to macosforge. If we see it working on enough >> "supported platforms", we could flip the Big Switch and move that to >> the stable distribution. > > There is currently no stable/unstable distinction for portfiles. Ohhhhh. That was unclear to me. So the macports releases like 1.6.0 are purely macports, not the individual ports? This is different from Linux distros, and might bear mentioning in the FAQ. > I think it would be nice to have something like this, where we have some > state associated with each port that would give an indication of what > systems the port has been successfully built on (and maybe eventually > where it works correctly). If we combined it with some way for multiple > versions of the portfile to be available to the end-user they could > choose to install the 'newest' portfile, the newest one that has been > build tested on similar hardware, or an older version. Yeah, exactly... > If you've got the time, it would be great if you would check out the > macports code, and try to get (at least some of) your ideas working. I promise to try to try.... Jay From lists-macports at shopwatch.org Fri May 2 05:00:51 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Fri May 2 04:58:09 2008 Subject: HOWTO: Get started, gain macports-foo, make bad first impression In-Reply-To: References: <4818AB0E.50702@shopwatch.org> <1B8EA38A-D808-4006-AEEC-19D489D533DE@geeklair.net> Message-ID: <481B0273.5010104@shopwatch.org> Ryan Schmidt wrote: > The other problem with parallel builds is that they are not identical > each time you run them. The build may succeed 3 times, then fail the > 4th. I personally haven't had the time to try to build each of my ports > several times with parallel build on to see if they repeatably build > correctly. Good point. So, to the extent that feedback has any automation attached to it, "bad" should probably be weighted more heavily than "good". A successful build is "absence of evidence" of problems, not evidence of absence. That said, with enough data points, if you get one "bad" build and eight "good" builds on what's ostensibly the same platform, there's probably something unique about the bad build configuration that you aren't measuring. > Sounds nice to me. But how would we learn what port works on what OS / > architecture? I had proposed last year the idea of MacPorts > automatically sending information back to the mothership regarding what > ports people had installed on what OS and what architecture, which could > be used to determine which ports actually work, and could also show port > popularity. I thought this would make for an interesting front-page > www.macports.org display, showing the most popular ports. But several > people didn't want MacPorts reporting this information: > > http://lists.macosforge.org/pipermail/macports-dev/2007-May/001604.html I think that post was too focused on getting ultra-precise stats, which will always end up compromising anonymity. See for example the Netflix/IMDB privacy leak: http://www.schneier.com/blog/archives/2007/12/anonymity_and_t_2.html How many active users do we think Macports has? A thousand, ten thousand? It doesn't matter if there are some GUIDs that we track that no longer get used. We don't actually care if there are 53 users with jigdo installed, or 57; we care if 95% of them had no trouble building on 10.5.2 with a Core Duo. If you try to be too precise, you end up with the Windows DLL registry: you can't uninstall a DLL, because some program, somewhere, registered it twice, and now the "lock count" is off by one. So if we generate a GUID and it stops reporting to us.. that's fine. (If we need a more accurate "current user" count, we can always age off non-reporting GUIDs.) If the user reinstalls, fine. If some people use svn up, that's fine too. In aggregate, the numbers will still be useful. It's a dial, not a switch. Hell, you could even go as far as "I want to install ports that are at least 87% successful"; the named "stable" and "unstable" distributions could just be default dial settings. (N.B. This is called over-abstraction.) I envision something more like: 1. At install: "Would you like macports to send anonymous reports about build quality? Yes, No, More Info [N]" 2. Upon build: ...some data, samples of which we show at step 1 3. A nice dashboard on macports.org 4. When a build fails, offer the user the opportunity to opt in again (with a "never ask me again" option, of course). I feel like I've seen a good build-farm dashboard somewhere, but I can't recall which project at the moment. What sort of capabilities do we have on "the mothership"? I see it runs GForge, which I know nothing about; can it run arbitrary servers on arbitary ports? I'm starting to wonder if there aren't generic "talkback" solutions we could take advantage of. Jay From lists-macports at shopwatch.org Fri May 2 05:04:04 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Fri May 2 05:01:04 2008 Subject: HOWTO: Get started, gain macports-foo, make bad first impression In-Reply-To: <481A65B5.1030702@macports.org> References: <4818AB0E.50702@shopwatch.org> <1B8EA38A-D808-4006-AEEC-19D489D533DE@geeklair.net> <481A65B5.1030702@macports.org> Message-ID: <481B0334.3040406@shopwatch.org> Rainer M?ller wrote: > Ryan Schmidt wrote: >> The other problem with parallel builds is that they are not identical >> each time you run them. The build may succeed 3 times, then fail the >> 4th. I personally haven't had the time to try to build each of my >> ports several times with parallel build on to see if they repeatably >> build correctly. > > If the port does not build correctly the dependencies in the Makefile > are wrong. If it ever fails for someone and he/she files some ticket it > can be disabled. Usually there is no need to test it multiple times or > something like that. I think "multiple times" may be a proxy for "under slightly different circumstances that trigger race conditions"... > As I said before in other emails, we will not be able to provide > packages for each and every variant combination (that would be 2^n for a > port with n variants). So building custom ports on the end-user side > will still happen even once we ship binary packages for default_variants. Good point. If you can hit 80% of the user base with binary builds, you've made a lot of people very happy. (That said, I am very pleased with the build speed on my shiny new dual-quad-core-Xeon 3.2GHz Mac Pro with 16GB RAM, four Cheetah 15K.5 SAS drives, and ccache enabled. I just want to throw that out there. You know, as a data point.) Jay From dluke at geeklair.net Fri May 2 07:20:35 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri May 2 07:17:18 2008 Subject: HOWTO: Get started, gain macports-foo, make bad first impression In-Reply-To: <481AFECA.3050604@shopwatch.org> References: <4818AB0E.50702@shopwatch.org> <1B8EA38A-D808-4006-AEEC-19D489D533DE@geeklair.net> <481AFECA.3050604@shopwatch.org> Message-ID: <88133C4B-1F3B-4A0E-95DE-D96C2CFF3608@geeklair.net> On May 2, 2008, at 7:45 AM, Jay Levitt wrote: >> If it's for a port that currently doesn't have a maintainer, it >> would be great if you would be willing to maintain the port! > > What sort of commitment is involved in being a maintainer? I have a > sordid history of A maintainer should test and update the port in a timely fashion (if your port is really popular, often people will submit diffs for this for you) and take some time to try to help people who have problems with the port (if you maintain a port people who have problems with it will probably open tickets and assign or CC you on them - 90% of the time the problem with be something wonky with their machine, but 10% of the time it will be a bug in the port ... ). Of course if you don't know the answer to a problem, that's OK too. People on the mailing list can usually help. > That said, I'll be happy to volunteer as a "good god, I must be > better than no maintainer at all" type maintainer when I find bugs. If you're not really interested in sticking around with a port, it's great to submit patches to fix issues that you fine. If the port is for something that you use and/or something that you're interested in, please consider becoming the maintainer (and yes, anyone interested in maintaining a port is better than the port having no maintainer). -- 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: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080502/73fff576/PGP.bin From alakazam at melix.net Fri May 2 08:05:59 2008 From: alakazam at melix.net (Alakazam) Date: Fri May 2 08:02:44 2008 Subject: [Ticket #13686] Octave Portfile upgrade and maintainership Message-ID: <0EADA3E2-D10F-4CDB-8EE6-036E3D271F26@melix.net> Hello, seeing that there has been no progress on the octave port for the last couple of months, even though many users have encountered problems with it, I think the Portfile could be advantageously upgraded with the one proposed on Ticket #13686 (http://trac.macosforge.org/projects/macports/ticket/13686 ). I am also ready to volunteer as maintainer for the octave port, if that may be useful and improve the frequency of updates and fixes. Thanks in advance, -- Olivier Le Floch (AKA Alakazam ) From mp at dpj.sent.com Sat May 3 02:28:56 2008 From: mp at dpj.sent.com (Daniel Horwood) Date: Sat May 3 02:25:38 2008 Subject: upgrading to conflicting dependencies Message-ID: <6BDF4391-5770-485E-9A4F-B02F764F9D6F@dpj.sent.com> gnucash depends on the goffice03 port (and is the only port in the tree that does), but can now work with the newer goffice port. I've made a patch on http://trac.macosforge.org/projects/macports/ticket/14893 that changes the gnucash dependency to goffice, but the problem is that goffice conflicts with goffice03. What's the best way to solve this problem? I thought about deactivating goffice03 in the gnucash portfile, but that won't work because MacPorts will try to install the dependencies (ie goffice) first. Can the goffice03 portfile be "redirected" to goffice? (I guess this is a bit like the scrollkeeper->rarian change). Ideas? Regards, Dan From jmr at macports.org Sat May 3 15:36:36 2008 From: jmr at macports.org (Joshua Root) Date: Sat May 3 15:33:11 2008 Subject: upgrading to conflicting dependencies Message-ID: <481CE8F4.1080408@macports.org> Daniel Horwood wrote: > gnucash depends on the goffice03 port (and is the only port in the > tree that does), but can now work with the newer goffice port. > > I've made a patch on http://trac.macosforge.org/projects/macports/ticket/14893 > that changes the gnucash dependency to goffice, but the problem is > that goffice conflicts with goffice03. I patched goffice03 so it doesn't conflict with goffice any more. BTW, gnucash-devel also depends on goffice03, and will need to be updated to a more recent revision before it can be switched over to goffice. - Josh From jmpp at macports.org Sat May 3 22:25:49 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sat May 3 22:22:27 2008 Subject: HOWTO: Get started, gain macports-foo, make bad first impression In-Reply-To: References: <4818AB0E.50702@shopwatch.org> <1B8EA38A-D808-4006-AEEC-19D489D533DE@geeklair.net> Message-ID: <5D75632E-20F6-43D7-B580-29C7B658BDB5@macports.org> On Apr 30, 2008, at 5:44 PM, Ryan Schmidt wrote: > > Sounds nice to me. But how would we learn what port works on what > OS / architecture? I had proposed last year the idea of MacPorts > automatically sending information back to the mothership regarding > what ports people had installed on what OS and what architecture, > which could be used to determine which ports actually work, and > could also show port popularity. I thought this would make for an > interesting front-page www.macports.org display, showing the most > popular ports. But several people didn't want MacPorts reporting > this information: > > http://lists.macosforge.org/pipermail/macports-dev/2007-May/ > 001604.html > > Maybe we should revisit this topic, though like you say, if we get > binary packages, then we don't need build success/failure statistics > from each user, but only from the build servers. I should note that this is the very spirit of my logging proposal (http://trac.macports.org/wiki/LoggingProposal ), which combined with a build farm, a build plan & schedule and an enhanced MPWA will hopefully provide tabulated statistics of the build status of all our ports on all our supported platforms. Yeah, I realize it may sound like a bit too much forward-thinking, yes, but holding our breath for this is no longer a question of life and death, as we will be working on two of these things (logging & mpwa) for GSoC (I'll be mentoring logging). Now, I'm not making any promises, don't start holding your breath just yet ;-) But I do want everyone to know that some form of stats gathering *is* a goal we're actively pursuing. Regards,... -jmpp From jmpp at macports.org Sat May 3 22:47:25 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sat May 3 22:44:27 2008 Subject: [Ticket #13686] Octave Portfile upgrade and maintainership In-Reply-To: <0EADA3E2-D10F-4CDB-8EE6-036E3D271F26@melix.net> References: <0EADA3E2-D10F-4CDB-8EE6-036E3D271F26@melix.net> Message-ID: On May 2, 2008, at 10:35 AM, Alakazam wrote: > Hello, > > seeing that there has been no progress on the octave port for the > last couple of months, even though many users have encountered > problems with it, I think the Portfile could be advantageously > upgraded with the one proposed on Ticket #13686 (http://trac.macosforge.org/projects/macports/ticket/13686 > ). > > I am also ready to volunteer as maintainer for the octave port, if > that may be useful and improve the frequency of updates and fixes. > > Thanks in advance, > -- > Olivier Le Floch > (AKA Alakazam ) I just made a comment on that ticket. Read it and get back to us on the things I requested, please. Regards,... -jmpp From mp at dpj.sent.com Sun May 4 00:01:36 2008 From: mp at dpj.sent.com (Daniel Horwood) Date: Sat May 3 23:58:13 2008 Subject: upgrading to conflicting dependencies In-Reply-To: <481CE8F4.1080408@macports.org> References: <481CE8F4.1080408@macports.org> Message-ID: <8BF042C4-D57E-4DFB-9022-B5C9C631207F@dpj.sent.com> On 04/05/2008, at 6:36 AM, Joshua Root wrote: > Daniel Horwood wrote: >> gnucash depends on the goffice03 port (and is the only port in the >> tree that does), but can now work with the newer goffice port. >> I've made a patch on http://trac.macosforge.org/projects/macports/ticket/14893 >> that changes the gnucash dependency to goffice, but the problem >> is that goffice conflicts with goffice03. > > I patched goffice03 so it doesn't conflict with goffice any more. > BTW, gnucash-devel also depends on goffice03, and will need to be > updated to a more recent revision before it can be switched over to > goffice. > > - Josh There isn't currently a "gnucash-devel" branch - perhaps the gnucash- devel port should just be upgraded to the current stable version (2.2.*) until a new development branch (ie 2.3.*) is created upstream. Dan From jmr at macports.org Sun May 4 00:49:01 2008 From: jmr at macports.org (Joshua Root) Date: Sun May 4 00:45:35 2008 Subject: upgrading to conflicting dependencies In-Reply-To: <8BF042C4-D57E-4DFB-9022-B5C9C631207F@dpj.sent.com> References: <481CE8F4.1080408@macports.org> <8BF042C4-D57E-4DFB-9022-B5C9C631207F@dpj.sent.com> Message-ID: <481D6A6D.8080107@macports.org> Daniel Horwood wrote: > On 04/05/2008, at 6:36 AM, Joshua Root wrote: > >> Daniel Horwood wrote: >>> gnucash depends on the goffice03 port (and is the only port in the >>> tree that does), but can now work with the newer goffice port. >>> I've made a patch on >>> http://trac.macosforge.org/projects/macports/ticket/14893 that >>> changes the gnucash dependency to goffice, but the problem is that >>> goffice conflicts with goffice03. >> >> I patched goffice03 so it doesn't conflict with goffice any more. BTW, >> gnucash-devel also depends on goffice03, and will need to be updated >> to a more recent revision before it can be switched over to goffice. >> >> - Josh > > There isn't currently a "gnucash-devel" branch - perhaps the > gnucash-devel port should just be upgraded to the current stable version > (2.2.*) until a new development branch (ie 2.3.*) is created upstream. It's currently fetching svn revision 16555, which is somewhere between 2.2.1 and 2.2.2. - Josh From takeshi at enomosphere.net Mon May 5 00:35:18 2008 From: takeshi at enomosphere.net (Takeshi Enomoto) Date: Mon May 5 00:31:44 2008 Subject: [Ticket #13686] Octave Portfile upgrade and maintainership In-Reply-To: References: <0EADA3E2-D10F-4CDB-8EE6-036E3D271F26@melix.net> Message-ID: <2dc53b910805050035s1a97ed42ra110363dccae5ba6@mail.gmail.com> Hello all, I did not have problems on Intel Mac but on iMac G5. So I make small changes for 2.9.15. Portfiles for versions 2.9.17 and 3.0.1 seem to be ready and 2.9.19 is available. IMHO, octave3 deserves a different port since it is said ``significantly different''. Regards, Takeshi From takeshi at enomosphere.net Mon May 5 01:01:39 2008 From: takeshi at enomosphere.net (Takeshi Enomoto) Date: Mon May 5 00:58:04 2008 Subject: [36498] trunk/dports/science/hdf5/Portfile In-Reply-To: References: <20080504130534.9C9F0162C6AD@beta.macosforge.org> Message-ID: <2dc53b910805050101h137decbdo448cc62b3e1c4bb1@mail.gmail.com> Dear Jochen, > the port is openmaintainer, so it is fine to submit reasonable changes > without asking the maintainer (me). I should have contact you. > With regard to your previous change: are you sure thread-safety works for > all Mac OS X systems. I vaguely remember that it is not supported on Mac OS > X... > Have you checked it carefully? I have not tested but as far as I browsed through the source, it is implemented with pthreads. Mac OS X is POSIX compliant and has /usr/include/pthread.h. > > -# -*- coding: utf-8; mode: tcl; c-basic-offset: 4; indent-tabs-mode: nil; > tab-width: 4; truncate-lines: t -*- vim:fenc=utf-8:et:sw=4:ts=4:sts=4 > Please keep these line in! See the guide for its description. > The lint warning you are referring to is a deficiency of the current > MacPorts lint system, see the mailing lists for details. I see. I will respect this. Takeshi From ryandesign at macports.org Mon May 5 01:05:17 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon May 5 01:01:42 2008 Subject: [36498] trunk/dports/science/hdf5/Portfile In-Reply-To: References: <20080504130534.9C9F0162C6AD@beta.macosforge.org> Message-ID: On May 4, 2008, at 3:27 PM, Jochen K?pper wrote: > The lint warning you are referring to is a deficiency of the > current MacPorts lint system, see the mailing lists for details. Or upgrade macports base to the version in trunk where I believe this problem has been fixed. From wsiegrist at apple.com Mon May 5 12:00:50 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon May 5 11:57:16 2008 Subject: Trac/SVN Changes in Progress In-Reply-To: <1516BF9B-69E6-4AD0-958B-C7A52532EFBD@apple.com> References: <1516BF9B-69E6-4AD0-958B-C7A52532EFBD@apple.com> Message-ID: Tonight, Monday, May 5th, at 8pm PDT, we'll be deploying a new authentication system along with some new Trac templates. This should clear up the rest of the issues with macports.org, especially those dealing with the login redirecting. The total work could take a few hours, however, Trac will be mostly functional except for brief periods. For example, we need to change DNS for HTTPS access, so logins will be subject to some propagation delay of about 1 hour. You might also catch the templates in a partially changed state so they might look broken. Just please be patient and start reporting problems tomorrow morning. Subversion will not be affected. As always, I'll be in IRC and try to give everyone a heads up when I start breaking things. Thanks -Bill On Apr 29, 2008, at 9:02 PM, William Siegrist wrote: > [Cross-posting for maximum coverage, please reply-all with care] > > I'm in the process of migrating to the new auth/trac/svn system for > MacPorts. So right now, trac.macports.org should be using shorter > URLs (minus the /projects/macports/ portion of the URI), however, > you may find that login/logout are broken. For the old, stable > behavior, for now, continue to browse via >. > > Once some DNS changes propagate, I can deploy the last bit of the > new system which will clean everything up (should happen by the end > of the week). Once I declare the move complete, please start filing > tickets for anything that doesnt work for you (or for additional > improvements you would like to see). > > Thank you for your patience during our maintenance. ---- William Siegrist Mac OS Forge http://macosforge.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080505/1d611c39/smime-0001.bin From jmr at macports.org Mon May 5 17:59:06 2008 From: jmr at macports.org (Joshua Root) Date: Mon May 5 17:55:31 2008 Subject: Please review: proposed dependency handling change Message-ID: <481FAD5A.8000409@macports.org> Ticket: The full enhancement requested by the ticket will (AFAICT) be rather difficult to implement at present. I have however attached a patch which improves things a bit. It makes 3 things better: 1. You can use depends_build for software that needs to be used in the extract or patch phases. This helps e.g. python23 which needs gnutar for extract. 2. You can use depends_build for software that is needed for the configure phase but not at runtime (e.g. pkgconfig). Currently depends_build is not checked until after the configure phase. 3. Dependencies weren't being checked when running some packaging targets. Now they are. - Josh From jkh at apple.com Mon May 5 20:09:40 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon May 5 20:06:02 2008 Subject: Please review: proposed dependency handling change In-Reply-To: <481FAD5A.8000409@macports.org> References: <481FAD5A.8000409@macports.org> Message-ID: On May 5, 2008, at 5:59 PM, Joshua Root wrote: > The full enhancement requested by the ticket will (AFAICT) be rather > difficult to implement at present. I have however attached a patch > which improves things a bit. It makes 3 things better: > > 1. You can use depends_build for software that needs to be used in > the extract or patch phases. This helps e.g. python23 which needs > gnutar for extract. > 2. You can use depends_build for software that is needed for the > configure phase but not at runtime (e.g. pkgconfig). Currently > depends_build is not checked until after the configure phase. > 3. Dependencies weren't being checked when running some packaging > targets. Now they are. This raises an important question: Is there any value in creating depends_foo procs for each reasonable value of foo, even if they are just aliases for depends_build in the short/medium/forever term? Pros: There is some documentary value to being able to say depends_extract or depends_configure even if they just fold to depends_build since it's clearer from the declaration just why the dependency is needed. At some point, there might be real value to distinguishing between the types of dependencies. Say you were going on a business trip and looked forward to having plenty of spare CPU/disk cycles to build stuff on your laptop but not such great internet connectivity. You might do "port fetch bar" and expect it to only pre-populate your distfile cache, plus any tools the dependencies for bar might need just for fetching, but not actually build anything. Might be less confusing than trying to explain that there are really only two umbrella dependencies types even though there are lots of different possible targets. Cons: Adds complexity, namespace bloat. From florian.ebeling at gmail.com Tue May 6 14:18:03 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Tue May 6 14:14:23 2008 Subject: Wiki changes not possible Message-ID: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> Hi, it seems I can't change the Trac wiki, even though I'm logged in. Bug or feature? Florian -- Florian Ebeling florian.ebeling@gmail.com From florian.ebeling at gmail.com Tue May 6 14:21:58 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Tue May 6 14:18:18 2008 Subject: Trac/SVN Changes in Progress In-Reply-To: References: <1516BF9B-69E6-4AD0-958B-C7A52532EFBD@apple.com> Message-ID: <5cbbe4ae0805061421u1a8f7738ibc43c639a25cdc1d@mail.gmail.com> > Tonight, Monday, May 5th, at 8pm PDT, we'll be deploying a new > authentication system along with some new Trac templates. This should clear > up the rest of the issues with macports.org, especially those dealing with > the login redirecting. Will this also bring us an editable CC in Trac issues? I think that would help the project a lot. Florian -- Florian Ebeling florian.ebeling@gmail.com From wsiegrist at apple.com Tue May 6 14:22:06 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue May 6 14:18:26 2008 Subject: Wiki changes not possible In-Reply-To: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> Message-ID: Wiki modification requires committer privileges. -Bill On May 6, 2008, at 2:18 PM, Florian Ebeling wrote: > Hi, > > it seems I can't change the Trac wiki, even though I'm logged in. Bug > or feature? > > Florian > > -- > Florian Ebeling > florian.ebeling@gmail.com > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080506/5ef734f3/smime.bin From wsiegrist at apple.com Tue May 6 14:26:45 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue May 6 14:23:05 2008 Subject: Trac/SVN Changes in Progress In-Reply-To: <5cbbe4ae0805061421u1a8f7738ibc43c639a25cdc1d@mail.gmail.com> References: <1516BF9B-69E6-4AD0-958B-C7A52532EFBD@apple.com> <5cbbe4ae0805061421u1a8f7738ibc43c639a25cdc1d@mail.gmail.com> Message-ID: On May 6, 2008, at 2:21 PM, Florian Ebeling wrote: >> Tonight, Monday, May 5th, at 8pm PDT, we'll be deploying a new >> authentication system along with some new Trac templates. This >> should clear >> up the rest of the issues with macports.org, especially those >> dealing with >> the login redirecting. > > Will this also bring us an editable CC in Trac issues? I think that > would > help the project a lot. > Actually, I wrote/installed a plugin to provide a button for putting yourself on the Cc list. However, I broke it last night, and am fixing it right now. The button should be back soon. Look for a "Cc Me" button just under the yellow-ish description box later today. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080506/67d3316e/smime.bin From florian.ebeling at gmail.com Tue May 6 14:27:08 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Tue May 6 14:23:30 2008 Subject: Wiki changes not possible In-Reply-To: References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> Message-ID: <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> > Wiki modification requires committer privileges. I think it would benefit the project if we losen this policy. Nobody applies for commit to correct a small factual error. And it works for other site quite well. What was the name of this online encyclopedia, gain? ;) Florian -- Florian Ebeling florian.ebeling@gmail.com From wsiegrist at apple.com Tue May 6 15:49:38 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue May 6 15:46:13 2008 Subject: Trac/SVN Changes in Progress In-Reply-To: References: <1516BF9B-69E6-4AD0-958B-C7A52532EFBD@apple.com> <5cbbe4ae0805061421u1a8f7738ibc43c639a25cdc1d@mail.gmail.com> Message-ID: <6365B81A-CBC7-4383-9866-259D84DACB32@apple.com> On May 6, 2008, at 2:26 PM, William Siegrist wrote: > On May 6, 2008, at 2:21 PM, Florian Ebeling wrote: > >>> Tonight, Monday, May 5th, at 8pm PDT, we'll be deploying a new >>> authentication system along with some new Trac templates. This >>> should clear >>> up the rest of the issues with macports.org, especially those >>> dealing with >>> the login redirecting. >> >> Will this also bring us an editable CC in Trac issues? I think that >> would >> help the project a lot. >> > > Actually, I wrote/installed a plugin to provide a button for putting > yourself on the Cc list. However, I broke it last night, and am > fixing it right now. The button should be back soon. Look for a "Cc > Me" button just under the yellow-ish description box later today. Cc Me is back. Let me know if you have trouble getting on or off the cc lists. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080506/8d140c74/smime.bin From raimue at macports.org Tue May 6 23:16:09 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Tue May 6 23:12:31 2008 Subject: Wiki changes not possible In-Reply-To: <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> Message-ID: <48214929.9000105@macports.org> Florian Ebeling wrote: >> Wiki modification requires committer privileges. > > I think it would benefit the project if we losen this policy. Nobody applies > for commit to correct a small factual error. And it works for other site quite > well. What was the name of this online encyclopedia, gain? ;) I fully agree. We should allow wiki edits for everyone logged in. This opens up more possibilities to contribute to MacPorts, e.g. in the howto/* section. Trac's wiki has a history, so if anyone makes "wrong" edits, we can still revert to an earlier version. Rainer From wsiegrist at apple.com Tue May 6 23:58:09 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue May 6 23:54:29 2008 Subject: Wiki changes not possible In-Reply-To: <48214929.9000105@macports.org> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> <48214929.9000105@macports.org> Message-ID: <068F85B4-6135-491E-840F-54761B171457@apple.com> On May 6, 2008, at 11:16 PM, Rainer M?ller wrote: > Florian Ebeling wrote: >>> Wiki modification requires committer privileges. >> I think it would benefit the project if we losen this policy. >> Nobody applies >> for commit to correct a small factual error. And it works for other >> site quite >> well. What was the name of this online encyclopedia, gain? ;) > > I fully agree. We should allow wiki edits for everyone logged in. > This opens up more possibilities to contribute to MacPorts, e.g. in > the howto/* section. > > Trac's wiki has a history, so if anyone makes "wrong" edits, we can > still revert to an earlier version. > I agree as well. It certainly isnt a technical limit. Its a policy decision by macports management. I can relax the requirements if they agree to it. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080506/00975824/smime.bin From florian.ebeling at gmail.com Wed May 7 00:47:12 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Wed May 7 00:43:31 2008 Subject: Trac/SVN Changes in Progress In-Reply-To: <6365B81A-CBC7-4383-9866-259D84DACB32@apple.com> References: <1516BF9B-69E6-4AD0-958B-C7A52532EFBD@apple.com> <5cbbe4ae0805061421u1a8f7738ibc43c639a25cdc1d@mail.gmail.com> <6365B81A-CBC7-4383-9866-259D84DACB32@apple.com> Message-ID: <5cbbe4ae0805070047o26b8f67elf9fdd477850d36df@mail.gmail.com> > Cc Me is back. Let me know if you have trouble getting on or off the cc > lists. Works nicely. Thanks. Florian -- Florian Ebeling florian.ebeling@gmail.com From florian.ebeling at gmail.com Wed May 7 00:52:29 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Wed May 7 00:48:48 2008 Subject: Wiki changes not possible In-Reply-To: <068F85B4-6135-491E-840F-54761B171457@apple.com> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> <48214929.9000105@macports.org> <068F85B4-6135-491E-840F-54761B171457@apple.com> Message-ID: <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> >>>> Wiki modification requires committer privileges. >>> >>> I think it would benefit the project if we losen this policy. Nobody >>> applies >>> for commit to correct a small factual error. And it works for other site >>> quite >>> well. What was the name of this online encyclopedia, gain? ;) >> >> I fully agree. We should allow wiki edits for everyone logged in. This >> opens up more possibilities to contribute to MacPorts, e.g. in the howto/* >> section. >> Trac's wiki has a history, so if anyone makes "wrong" edits, we can still >> revert to an earlier version. >> > I agree as well. It certainly isnt a technical limit. Its a policy decision > by macports management. I can relax the requirements if they agree to it. Ok, then I hereby officially appeal to portmgr. @portmgr: Do you approve of a change to the wiki permission policy to the effect that every logged-in user can edit? Florian -- Florian Ebeling florian.ebeling@gmail.com From jmpp at macports.org Wed May 7 09:14:04 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Wed May 7 09:12:34 2008 Subject: [macports-mgr] Re: Wiki changes not possible In-Reply-To: <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> <48214929.9000105@macports.org> <068F85B4-6135-491E-840F-54761B171457@apple.com> <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> Message-ID: On May 7, 2008, at 3:22 AM, Florian Ebeling wrote: >>>>> Wiki modification requires committer privileges. >>>> >>>> I think it would benefit the project if we losen this policy. >>>> Nobody >>>> applies >>>> for commit to correct a small factual error. And it works for >>>> other site >>>> quite >>>> well. What was the name of this online encyclopedia, gain? ;) >>> >>> I fully agree. We should allow wiki edits for everyone logged in. >>> This >>> opens up more possibilities to contribute to MacPorts, e.g. in the >>> howto/* >>> section. >>> Trac's wiki has a history, so if anyone makes "wrong" edits, we >>> can still >>> revert to an earlier version. >>> >> I agree as well. It certainly isnt a technical limit. Its a policy >> decision >> by macports management. I can relax the requirements if they agree >> to it. > > Ok, then I hereby officially appeal to portmgr. > > @portmgr: Do you approve of a change to the wiki permission policy > to the effect > that every logged-in user can edit? > > Florian With my PortMgr hat on, I'm willing to loosen up a bit on this particular requirement and experiment for a while to see how it goes. I totally love Wikipedia, but I'm sure they have many more resources than us to deal with the side effects of such openness, e.g. wikispam. So it'd be great if we could keep a close eye on the Trac timeline for unwanted Wiki edits, also looking out for legit edits but with misleading information. Does James have anything to say about this? Regards,... -jmpp From wsiegrist at apple.com Wed May 7 09:30:11 2008 From: wsiegrist at apple.com (William Siegrist) Date: Wed May 7 09:26:28 2008 Subject: [macports-mgr] Re: Wiki changes not possible In-Reply-To: References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> <48214929.9000105@macports.org> <068F85B4-6135-491E-840F-54761B171457@apple.com> <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> Message-ID: <8EF8523F-F9C8-47B3-B279-D8E64FC4DEBB@apple.com> On May 7, 2008, at 9:14 AM, Juan Manuel Palacios wrote: > > On May 7, 2008, at 3:22 AM, Florian Ebeling wrote: > >>>>>> Wiki modification requires committer privileges. >>>>> >>>>> I think it would benefit the project if we losen this policy. >>>>> Nobody >>>>> applies >>>>> for commit to correct a small factual error. And it works for >>>>> other site >>>>> quite >>>>> well. What was the name of this online encyclopedia, gain? ;) >>>> >>>> I fully agree. We should allow wiki edits for everyone logged in. >>>> This >>>> opens up more possibilities to contribute to MacPorts, e.g. in >>>> the howto/* >>>> section. >>>> Trac's wiki has a history, so if anyone makes "wrong" edits, we >>>> can still >>>> revert to an earlier version. >>>> >>> I agree as well. It certainly isnt a technical limit. Its a >>> policy decision >>> by macports management. I can relax the requirements if they agree >>> to it. >> >> Ok, then I hereby officially appeal to portmgr. >> >> @portmgr: Do you approve of a change to the wiki permission policy >> to the effect >> that every logged-in user can edit? >> > > > With my PortMgr hat on, I'm willing to loosen up a bit on this > particular requirement and experiment for a while to see how it > goes. I totally love Wikipedia, but I'm sure they have many more > resources than us to deal with the side effects of such openness, > e.g. wikispam. So it'd be great if we could keep a close eye on the > Trac timeline for unwanted Wiki edits, also looking out for legit > edits but with misleading information. > I can have Trac send email when a wiki modification happens. I actually use this to monitor all of the wikis on Mac OS Forge. So if you want me to add portmgr or -dev to that email, then you dont have to watch the Timeline page. (it emails a diff, comment, username, IP, etc). -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080507/337eaddb/smime.bin From raimue at macports.org Wed May 7 09:36:38 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed May 7 09:32:58 2008 Subject: [macports-mgr] Re: Wiki changes not possible In-Reply-To: <8EF8523F-F9C8-47B3-B279-D8E64FC4DEBB@apple.com> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> <48214929.9000105@macports.org> <068F85B4-6135-491E-840F-54761B171457@apple.com> <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> <8EF8523F-F9C8-47B3-B279-D8E64FC4DEBB@apple.com> Message-ID: <4821DA96.90508@macports.org> William Siegrist wrote: > On May 7, 2008, at 9:14 AM, Juan Manuel Palacios wrote: >> With my PortMgr hat on, I'm willing to loosen up a bit on this >> particular requirement and experiment for a while to see how it >> goes. I totally love Wikipedia, but I'm sure they have many more >> resources than us to deal with the side effects of such openness, >> e.g. wikispam. So it'd be great if we could keep a close eye on the >> Trac timeline for unwanted Wiki edits, also looking out for legit >> edits but with misleading information. >> I don't think we will get much spam as long as we still registration for editing the wiki. If some spammer registers an account, banning will also be easy. The benefits from opening up the wiki will be much bigger. Everyone can contribute to the documentation without creating tickets for it, sending patches etc. > I can have Trac send email when a wiki modification happens. I > actually use this to monitor all of the wikis on Mac OS Forge. So if > you want me to add portmgr or -dev to that email, then you dont have > to watch the Timeline page. (it emails a diff, comment, username, IP, > etc). I read the wiki edits as RSS feed (from the timeline). Although it does not contain diffs, it links to the changed page. But I don't think we need to spam -dev. If we really decide to send mails, these should go to -changes with some [wiki] prefix. So others not wanting to get these diffs can easily set up a filter for it. Rainer From wsiegrist at apple.com Wed May 7 09:41:00 2008 From: wsiegrist at apple.com (William Siegrist) Date: Wed May 7 09:37:17 2008 Subject: [macports-mgr] Re: Wiki changes not possible In-Reply-To: <4821DA96.90508@macports.org> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> <48214929.9000105@macports.org> <068F85B4-6135-491E-840F-54761B171457@apple.com> <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> <8EF8523F-F9C8-47B3-B279-D8E64FC4DEBB@apple.com> <4821DA96.90508@macports.org> Message-ID: <9CB94B76-6987-4081-ADEE-3AC9AB11340C@apple.com> On May 7, 2008, at 9:36 AM, Rainer M?ller wrote: > > But I don't think we need to spam -dev. If we really decide to send > mails, these should go to -changes with some [wiki] prefix. So > others not wanting to get these diffs can easily set up a filter for > it. Ah, yes, -changes is a much better choice. And the prefix would be [MacPorts] unless I modified the plugin (its not something I wrote myself). It uses the project name of the Trac environment and the wiki title. For example: [MacPorts] Notification: LeopardProblems modified -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080507/ee404aed/smime.bin From jmpp at macports.org Wed May 7 09:43:01 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Wed May 7 09:39:33 2008 Subject: [macports-mgr] Re: Wiki changes not possible In-Reply-To: <8EF8523F-F9C8-47B3-B279-D8E64FC4DEBB@apple.com> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> <48214929.9000105@macports.org> <068F85B4-6135-491E-840F-54761B171457@apple.com> <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> <8EF8523F-F9C8-47B3-B279-D8E64FC4DEBB@apple.com> Message-ID: <967A8E7C-5BE4-49DD-86EC-D0B8DACF3672@macports.org> On May 7, 2008, at 12:00 PM, William Siegrist wrote: >> >> With my PortMgr hat on, I'm willing to loosen up a bit on this >> particular requirement and experiment for a while to see how it >> goes. I totally love Wikipedia, but I'm sure they have many more >> resources than us to deal with the side effects of such openness, >> e.g. wikispam. So it'd be great if we could keep a close eye on the >> Trac timeline for unwanted Wiki edits, also looking out for legit >> edits but with misleading information. >> > > I can have Trac send email when a wiki modification happens. I > actually use this to monitor all of the wikis on Mac OS Forge. So > if you want me to add portmgr or -dev to that email, then you dont > have to watch the Timeline page. (it emails a diff, comment, > username, IP, etc). > > -Bill That would be *really* nice! The only thing I'm left wondering is the volume we'll be managing going forward, being more open, in case we have to dedicate an entire mailing list to such mails. In the mean time, I'd say this one, mp-dev, would be most appropriate, since (and I hope I'm not mistaken) we'll be mainly dealing with technical documentation which we'll want our developers reviewing anyhow. So you have my approval for this change in direction. Any comments, James? -jmpp From jmpp at macports.org Wed May 7 09:50:27 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Wed May 7 09:47:11 2008 Subject: [macports-mgr] Re: Wiki changes not possible In-Reply-To: <9CB94B76-6987-4081-ADEE-3AC9AB11340C@apple.com> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> <48214929.9000105@macports.org> <068F85B4-6135-491E-840F-54761B171457@apple.com> <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> <8EF8523F-F9C8-47B3-B279-D8E64FC4DEBB@apple.com> <4821DA96.90508@macports.org> <9CB94B76-6987-4081-ADEE-3AC9AB11340C@apple.com> Message-ID: <11C06D1A-B850-471A-8E06-1F01C8E23749@macports.org> On May 7, 2008, at 12:11 PM, William Siegrist wrote: > > On May 7, 2008, at 9:36 AM, Rainer M?ller wrote: > >> >> But I don't think we need to spam -dev. If we really decide to send >> mails, these should go to -changes with some [wiki] prefix. So >> others not wanting to get these diffs can easily set up a filter >> for it. > > > Ah, yes, -changes is a much better choice. And the prefix would be > [MacPorts] unless I modified the plugin (its not something I wrote > myself). It uses the project name of the Trac environment and the > wiki title. For example: > > [MacPorts] Notification: LeopardProblems modified > > -Bill Funny, I just posted about this! I can see mp-changes hosting these mails, but I'd actually think this list is a better choice, since these edits will mostly (hopefully) be about documentation, which is something we've always reviewed here. In any case, I have no problem with having them on mp-changes if the majority of voices speak against this list, but in such case it'd be nice having the From and Reply-To fields of each message constructed similar to how the commit logs are currently. About the From field: everyone who edits the wiki has to be a valid registered user, with a legit address, so would it be possible to have that as the From of each of those messages (and from there on, into the Reply-To field too)? If it is, we would deal with the mailing list accepting all those messages in some smart way, but we first need to know if we can have custom From's. Regards,... -jmpp From lists-macports at shopwatch.org Wed May 7 09:53:23 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Wed May 7 09:49:45 2008 Subject: [macports-mgr] Re: Wiki changes not possible In-Reply-To: <4821DA96.90508@macports.org> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> <48214929.9000105@macports.org> <068F85B4-6135-491E-840F-54761B171457@apple.com> <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> <8EF8523F-F9C8-47B3-B279-D8E64FC4DEBB@apple.com> <4821DA96.90508@macports.org> Message-ID: <4821DE83.3020803@shopwatch.org> Rainer M?ller wrote: > The benefits from opening up the wiki will be much bigger. Everyone > can contribute to the documentation without creating tickets for it, > sending patches etc. As a non-committer but a technical user, I hereby do solemly swear to check the wiki before asking questions, and to update the wiki when I find answers, so help me me. Jay Levitt From raimue at macports.org Wed May 7 10:02:03 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed May 7 09:58:23 2008 Subject: [macports-mgr] Re: Wiki changes not possible In-Reply-To: <11C06D1A-B850-471A-8E06-1F01C8E23749@macports.org> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> <48214929.9000105@macports.org> <068F85B4-6135-491E-840F-54761B171457@apple.com> <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> <8EF8523F-F9C8-47B3-B279-D8E64FC4DEBB@apple.com> <4821DA96.90508@macports.org> <9CB94B76-6987-4081-ADEE-3AC9AB11340C@apple.com> <11C06D1A-B850-471A-8E06-1F01C8E23749@macports.org> Message-ID: <4821E08B.9030100@macports.org> Juan Manuel Palacios wrote: > I can see mp-changes hosting these mails, but I'd actually think this > list is a better choice, since these edits will mostly (hopefully) be > about documentation, which is something we've always reviewed here. In > any case, I have no problem with having them on mp-changes if the > majority of voices speak against this list, but in such case it'd be > nice having the From and Reply-To fields of each message constructed > similar to how the commit logs are currently. Also svn commits are open for review and we also put them onto the -changes list to seperate change mails and actual discussion. We don't need to discuss every wiki change, but we can start of a thread from -changes as we do for commit reviews. So I would prefer to send these mails to -changes. > About the From field: everyone who edits the wiki has to be a valid > registered user, with a legit address, so would it be possible to have > that as the From of each of those messages (and from there on, into > the Reply-To field too)? If it is, we would deal with the mailing list > accepting all those messages in some smart way, but we first need to > know if we can have custom From's. Sounds like a good idea. Although I wouldn't say the From: thing has high priority... We should put up an official announcement once we enabled this to encourage more users to contribute to the wiki. Rainer From blair at orcaware.com Wed May 7 10:05:10 2008 From: blair at orcaware.com (Blair Zajac) Date: Wed May 7 10:01:27 2008 Subject: Where are we with simultaneous Python Framework installs Message-ID: <4821E146.5000405@orcaware.com> I'd like to move to Python 2.5 for all our PyQt and GUI apps that require the Framework build. We have some major apps written on 2.4, so I'd like to be able to have 2.4 and 2.5 simulatenously installed so developers can check their work on the same system with a single MacPorts install. Were we going to have the port system update the /opt/local/Library/Frameworks/Python.framework/Versions/Current symlink depending upon the version of Python that is currently being used for a build? Regards, Blair From blair at orcaware.com Wed May 7 10:16:08 2008 From: blair at orcaware.com (Blair Zajac) Date: Wed May 7 10:12:27 2008 Subject: Alternative system for conflicting files Message-ID: <4821E3D8.5090309@orcaware.com> I'm starting to see more ports that install the same binary or file, such as PyQt3 and PyQt4, py-pil and py25-pil, python24 and python25, xemacs and emacs, etc. These prevent simultaneous installs of these packages. MacPorts needs a alternative system so that multiple ports can be installed that provide the same file. Debian systems have a system, call alternatives. Take java, which is provided by 5 or so different packages. There's /usr/bin/java which is a symlink to /etc/alternatives/java which is then a symlink to the real java, /usr/lib/jvm/java-6-sun/jre/bin/java on my system. There's a update-alternatives binary which is used to update these symlinks. http://blog.stevenkroon.com/2006/08/29/debian-update-alternatives/ We need this for MacPorts. If we don't come up with a MacPorts solution, then each package that has a conflict will either result in 1) the author not bothering to allow simultaneous installs, which is the easy route or 2) bake their own solution, such as gcc_select and python_select. The solution for MacPorts should be general enough to subsume gcc_select and python_select, allowing those scripts to become wrappers around MacPort's alternatives. It's probably late for GSoC, but this would be a great project. Blair From raimue at macports.org Wed May 7 10:33:07 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed May 7 10:29:25 2008 Subject: Where are we with simultaneous Python Framework installs In-Reply-To: <4821E146.5000405@orcaware.com> References: <4821E146.5000405@orcaware.com> Message-ID: <4821E7D3.6030709@macports.org> Blair Zajac wrote: > I'd like to move to Python 2.5 for all our PyQt and GUI apps that require the > Framework build. We have some major apps written on 2.4, so I'd like to be able > to have 2.4 and 2.5 simulatenously installed so developers can check their work > on the same system with a single MacPorts install. See http://trac.macports.org/wiki/PythonFrameworkTransition and the python-frameworks branch in svn. I tried to make python24 and python25 more similar and build both as frameworks. Before this can be released we need an easy way for the transition as described on the wiki page. Also updates to the python port groups are necessary. Currently they are shipped with base, so we can't update them at any time, only with releases. See ticket #14553 [1] for more. Sure we could solve this issue before (with a release) and then update the port groups whenever we like without waiting for new releases. > Were we going to have the port system update the > /opt/local/Library/Frameworks/Python.framework/Versions/Current symlink > depending upon the version of Python that is currently being used for a build? python_select will take care of this and set Current to the python version you selected. If we also need to update this at build time, the python port groups need an update to set and restore this link for building. Is there no other way to choose a version than changing the Current symlink? I am afraid of race conditions when we often change this symlink... I am CC'ing reiffert who had a major role in developing the transition plan. Rainer [1] http://trac.macports.org/ticket/14553 From wsiegrist at apple.com Wed May 7 15:03:15 2008 From: wsiegrist at apple.com (William Siegrist) Date: Wed May 7 14:59:31 2008 Subject: [macports-mgr] Re: Wiki changes not possible In-Reply-To: <11C06D1A-B850-471A-8E06-1F01C8E23749@macports.org> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> <48214929.9000105@macports.org> <068F85B4-6135-491E-840F-54761B171457@apple.com> <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> <8EF8523F-F9C8-47B3-B279-D8E64FC4DEBB@apple.com> <4821DA96.90508@macports.org> <9CB94B76-6987-4081-ADEE-3AC9AB11340C@apple.com> <11C06D1A-B850-471A-8E06-1F01C8E23749@macports.org> Message-ID: On May 7, 2008, at 9:50 AM, Juan Manuel Palacios wrote: > I can see mp-changes hosting these mails, but I'd actually think > this list is a better choice, since these edits will mostly > (hopefully) be about documentation, which is something we've always > reviewed here. In any case, I have no problem with having them on mp- > changes if the majority of voices speak against this list, but in > such case it'd be nice having the From and Reply-To fields of each > message constructed similar to how the commit logs are currently. > > About the From field: everyone who edits the wiki has to be a valid > registered user, with a legit address, so would it be possible to > have that as the From of each of those messages (and from there on, > into the Reply-To field too)? If it is, we would deal with the > mailing list accepting all those messages in some smart way, but we > first need to know if we can have custom From's. We cant set the addresses on a per-email basis. So we can just set it to trac@macports.org (or whatever) and add it to the accept list for - changes. We can set the Reply-to to be -dev for discussion purposes. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080507/06c1255b/smime.bin From erickt at macports.org Wed May 7 20:51:35 2008 From: erickt at macports.org (Erick Tryzelaar) Date: Wed May 7 20:47:48 2008 Subject: website down? Message-ID: <1ef034530805072051m23fa8e4cxbb6711f55ae2542f@mail.gmail.com> Can anyone else connect to macports.org? From erickt at macports.org Wed May 7 21:09:32 2008 From: erickt at macports.org (Erick Tryzelaar) Date: Wed May 7 21:05:48 2008 Subject: website down? In-Reply-To: <1ef034530805072051m23fa8e4cxbb6711f55ae2542f@mail.gmail.com> References: <1ef034530805072051m23fa8e4cxbb6711f55ae2542f@mail.gmail.com> Message-ID: <1ef034530805072109w5fc71c54u71f433c207717fab@mail.gmail.com> On Wed, May 7, 2008 at 8:51 PM, Erick Tryzelaar wrote: > Can anyone else connect to macports.org? > It's back. From wsiegrist at apple.com Wed May 7 21:09:44 2008 From: wsiegrist at apple.com (William Siegrist) Date: Wed May 7 21:06:25 2008 Subject: website down? In-Reply-To: <1ef034530805072051m23fa8e4cxbb6711f55ae2542f@mail.gmail.com> References: <1ef034530805072051m23fa8e4cxbb6711f55ae2542f@mail.gmail.com> Message-ID: <5F15ACDF-B1B4-441F-81A6-2FCC538F08FA@apple.com> It was. Its now back. -Bill On May 7, 2008, at 8:51 PM, Erick Tryzelaar wrote: > Can anyone else connect to macports.org? > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev ---- William Siegrist Mac OS Forge http://macosforge.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080507/2ad4afa7/smime-0001.bin From jmpp at macports.org Thu May 8 01:17:30 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu May 8 01:13:54 2008 Subject: [macports-mgr] Re: Wiki changes not possible In-Reply-To: References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> <48214929.9000105@macports.org> <068F85B4-6135-491E-840F-54761B171457@apple.com> <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> <8EF8523F-F9C8-47B3-B279-D8E64FC4DEBB@apple.com> <4821DA96.90508@macports.org> <9CB94B76-6987-4081-ADEE-3AC9AB11340C@apple.com> <11C06D1A-B850-471A-8E06-1F01C8E23749@macports.org> Message-ID: <3F1A934B-49E1-47D5-BA3C-B5B1EA9E1F57@macports.org> On May 7, 2008, at 5:33 PM, William Siegrist wrote: > > On May 7, 2008, at 9:50 AM, Juan Manuel Palacios wrote: > >> I can see mp-changes hosting these mails, but I'd actually think >> this list is a better choice, since these edits will mostly >> (hopefully) be about documentation, which is something we've always >> reviewed here. In any case, I have no problem with having them on >> mp-changes if the majority of voices speak against this list, but >> in such case it'd be nice having the From and Reply-To fields of >> each message constructed similar to how the commit logs are >> currently. >> >> About the From field: everyone who edits the wiki has to be a >> valid registered user, with a legit address, so would it be >> possible to have that as the From of each of those messages (and >> from there on, into the Reply-To field too)? If it is, we would >> deal with the mailing list accepting all those messages in some >> smart way, but we first need to know if we can have custom From's. > > > We cant set the addresses on a per-email basis. So we can just set > it to trac@macports.org (or whatever) and add it to the accept list > for -changes. We can set the Reply-to to be -dev for discussion > purposes. > > -Bill Hoping one day we can have custom From's and Reply-To's for these mails, if the technical limitations aren't that great, Id' be OK with trac@macports.org in From, sending to mp-changes, and mp-dev as the Reply-To. So, PortMgr hat back on, lets go ahead and flip this switch, lets see how well our users react. Thanks for bringing this subject up in the first place, to whoever did, can't remember any longer! Regards,... -jmpp From jmr at macports.org Thu May 8 02:01:19 2008 From: jmr at macports.org (Joshua Root) Date: Thu May 8 01:57:36 2008 Subject: Patches awaiting review Message-ID: <4822C15F.6060207@macports.org> Hi all, I've got a bunch of bugfix patches on Trac which need reviewing. It would be nice to get as many of them as possible into the upcoming release. Ticket URLS: http://trac.macports.org/ticket/7361 http://trac.macports.org/ticket/10768 http://trac.macports.org/ticket/10827 http://trac.macports.org/ticket/11971 http://trac.macports.org/ticket/12013 http://trac.macports.org/ticket/12170 There are also some patches from gwhitney which have been sitting there for quite a while. He says he won't have time to work on MP until at least the end of June. Tickets: http://trac.macports.org/ticket/8221 http://trac.macports.org/ticket/11891 http://trac.macports.org/ticket/11897 Cheers, Josh From lists-macports at shopwatch.org Thu May 8 06:18:35 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Thu May 8 06:14:55 2008 Subject: ccache and autoconf? Message-ID: <4822FDAB.20403@shopwatch.org> An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080508/21885a8c/attachment.html From afb at macports.org Thu May 8 07:13:25 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu May 8 07:09:43 2008 Subject: Patches awaiting review In-Reply-To: <4822C15F.6060207@macports.org> References: <4822C15F.6060207@macports.org> Message-ID: <72CF79C2-76BF-4F67-A2E9-D9B83C248044@macports.org> Joshua Root wrote: > I've got a bunch of bugfix patches on Trac which need reviewing. It > would be nice to get as many of them as possible into the upcoming > release. As jmpp mentioned, there will probably be two releases: one "old/ bugfix" release of MacPorts 1.6.1 and one "new/feature" release of MacPorts 1.7.0 Currently the bugfixes go on branches/release_1_6, while the features go on trunk (usually, large changes might need a branch for testing first) There was some talk about a roadmap, but I haven't seen one just yet. Presumably there'll be a "release_1_7", and trunk will become 1.8.0... --anders From wsiegrist at apple.com Thu May 8 08:49:29 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu May 8 08:45:48 2008 Subject: [macports-mgr] Re: Wiki changes not possible In-Reply-To: <3F1A934B-49E1-47D5-BA3C-B5B1EA9E1F57@macports.org> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805061427u1eb5c3b8pf3df2b6e8a78c0e1@mail.gmail.com> <48214929.9000105@macports.org> <068F85B4-6135-491E-840F-54761B171457@apple.com> <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> <8EF8523F-F9C8-47B3-B279-D8E64FC4DEBB@apple.com> <4821DA96.90508@macports.org> <9CB94B76-6987-4081-ADEE-3AC9AB11340C@apple.com> <11C06D1A-B850-471A-8E06-1F01C8E23749@macports.org> <3F1A934B-49E1-47D5-BA3C-B5B1EA9E1F57@macports.org> Message-ID: <8C3C799D-07BA-4909-8A6C-5909704B98D1@apple.com> On May 8, 2008, at 1:17 AM, Juan Manuel Palacios wrote: > > > Hoping one day we can have custom From's and Reply-To's for these > mails, if the technical limitations aren't that great, Id' be OK > with trac@macports.org in From, sending to mp-changes, and mp-dev as > the Reply-To. > > So, PortMgr hat back on, lets go ahead and flip this switch, lets > see how well our users react. Thanks for bringing this subject up in > the first place, to whoever did, can't remember any longer! > Done. ---- William Siegrist Mac OS Forge http://macosforge.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080508/a38d6a50/smime.bin From n.oxyde at gmail.com Thu May 8 09:01:04 2008 From: n.oxyde at gmail.com (nox) Date: Thu May 8 08:57:22 2008 Subject: ccache and autoconf? In-Reply-To: <4822FDAB.20403@shopwatch.org> References: <4822FDAB.20403@shopwatch.org> Message-ID: Le 8 mai 08 ? 15:18, Jay Levitt a ?crit : > I just encountered #15085 (nmap 4.6 doesn't build when ccache is > enabled), and thought I'd try to fix it. The problem seems to be > that nmap's configure.ac explicitly tests for the presence of a file > "g++" in the path. Unfortunately, with ccache enabled, the $AC_WORD > goes from "g++" to "ccache g++", and there ain't no "ccache g++" in > our path. > > My first step is always to make sure I can rebuild configure from > autoconf, so I did: > > $ autoconf > $ > > But: now, configure ignores ccache! I'm running it with the same > options that macports originally ran it with: > > $ ./configure --prefix=/opt/local --without-zenmap --mandir=$ > {prefix}/share/man --infodir=${prefix}/share/info --with-openssl=/ > opt/local --with-libpcre=/opt/local > > > Before I go traipsing through thousands of lines of shell scripts, > can anyone enlighten me on the interaction of the ccache port and > autoconf? How does it insert itself? > > Jay Levitt ccache is enabled through the configure script environment, for example: DEBUG: Environment: CFLAGS='-pipe -O2' CPPFLAGS='-I/opt/local/include' CXXFLAGS='-pipe -O2' CPP='ccache /usr/bin/cpp-4.0' CXX='ccache /usr/ bin/g++-4.0' F90FLAGS='-pipe -O2' LDFLAGS='-L/opt/local/lib' FCFLAGS='- pipe -O2' OBJC='ccache /usr/bin/gcc-4.0' INSTALL='/usr/bin/install -c' OBJCFLAGS='-pipe -O2' FFLAGS='-pipe -O2' "MACOSX_DEPLOYMENT_TARGET"='10.5' CC='ccache /usr/bin/gcc-4.0' Hope it helps, Anthony. From jmpp at macports.org Thu May 8 11:10:26 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu May 8 11:06:47 2008 Subject: [MacPorts] Notification: wms modified In-Reply-To: <054.02a42fb2360c2b2a52e931f754566f4c@macports.org> References: <054.02a42fb2360c2b2a52e931f754566f4c@macports.org> <054.02a42fb2360c2b2a52e931f754566f4c@macports.org> Message-ID: The message below detailing the change that was performed on the Wiki seems perfect for the purpose of keeping an eye on changes, it contains all the information we could ever need should we want to back something out and/or complain to someone about whatever. The only missing feature I can think of at the time is the editor's address in the Reply-To field, so as to not have to add him/her manually as I did in this case. But even if that's not technically possible, this will be a great tool to have with an open WIki. Thanks for making it happen, Bill! Now, let me cook up a brief announcement on mp-users@ and our news page. Regards,... -jmpp On May 8, 2008, at 11:13 AM, MacPorts wrote: > > > Changed page "wms" by wsiegrist@apple.com from 17.151.113.36* > Page URL: > Diff URL: > Revision 3 > Comment: > > Changes on attached wms.diff file. > > > * The IP shown here might not mean anything if the user is behind a > proxy. > > -- > MacPorts > Ports system for Mac OS > Index: wms > =================================================================== > --- wms (version: 2) > +++ wms (version: 3) > @@ -3,6 +3,7 @@ > wms manages the main infrastructure of MacPorts, including the main > web server, rsync server, mail, etc. > > == Port Maintenance == > + > [[BR]] [http://www.macports.org/ports.php?by=name&substr=awstats > awstats] > [[BR]] [http://www.macports.org/ports.php?by=name&substr=bugzilla > bugzilla] > [[BR]] [http://www.macports.org/ports.php?by=name&substr=lisp-hyperspec > lisp-hyperspec] > _______________________________________________ > macports-changes mailing list > macports-changes@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes From florian.ebeling at gmail.com Thu May 8 11:50:02 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Thu May 8 11:46:14 2008 Subject: [macports-mgr] Re: Wiki changes not possible In-Reply-To: <8C3C799D-07BA-4909-8A6C-5909704B98D1@apple.com> References: <5cbbe4ae0805061418m4f9718eeu1462d9e977fd3aaa@mail.gmail.com> <5cbbe4ae0805070052t3299dd14p758f66fa464c695@mail.gmail.com> <8EF8523F-F9C8-47B3-B279-D8E64FC4DEBB@apple.com> <4821DA96.90508@macports.org> <9CB94B76-6987-4081-ADEE-3AC9AB11340C@apple.com> <11C06D1A-B850-471A-8E06-1F01C8E23749@macports.org> <3F1A934B-49E1-47D5-BA3C-B5B1EA9E1F57@macports.org> <8C3C799D-07BA-4909-8A6C-5909704B98D1@apple.com> Message-ID: <5cbbe4ae0805081150v3581c391vbe8eb5731b2b69da@mail.gmail.com> >> So, PortMgr hat back on, lets go ahead and flip this switch, lets >> see how well our users react. Thanks for bringing this subject up in the >> first place, to whoever did, can't remember any longer! >> > Done. Just did a small change. Works nicely, thanks! Florian -- Florian Ebeling florian.ebeling@gmail.com From raimue at macports.org Thu May 8 15:22:56 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu May 8 15:19:12 2008 Subject: Patches awaiting review In-Reply-To: <72CF79C2-76BF-4F67-A2E9-D9B83C248044@macports.org> References: <4822C15F.6060207@macports.org> <72CF79C2-76BF-4F67-A2E9-D9B83C248044@macports.org> Message-ID: <48237D40.901@macports.org> Anders F Bj?rklund wrote: > Joshua Root wrote: > >> I've got a bunch of bugfix patches on Trac which need reviewing. It >> would be nice to get as many of them as possible into the upcoming >> release. > > As jmpp mentioned, there will probably be two releases: one "old/ > bugfix" release of MacPorts 1.6.1 and one "new/feature" release of > MacPorts 1.7.0 We already have this 1.6.1 milestone in the roadmap. Depending how fast we can sort out these tickets, I would even vote to delay them for 1.6.2. We really need a release again ASAP. There are enough unreleased changes on release_1_6 already. Diffing tags/release_1_6_0 with branches/release_1_6: * Fixed postflight script (we should also do new pkg installers) * port lint recognizes modelines * port load/unload (isn't this a new feature which should go with a major release?) * port platform (the same, new feature?) * configure.pipe I think these alone would make a good 1.6.1 release. > Currently the bugfixes go on branches/release_1_6, while the features > go on trunk (usually, large changes might need a branch for testing > first) Bugfixes also go to trunk but will be merged back to release_1_6 :-) > There was some talk about a roadmap, but I haven't seen one just yet. Categorizing the tickets filed against our base code in milestones for 1.6.1, 1.6.2, ... and 1.7.0 would be a good start. Rainer From shreevatsa.public at gmail.com Thu May 8 19:43:01 2008 From: shreevatsa.public at gmail.com (Shreevatsa R) Date: Thu May 8 19:39:11 2008 Subject: Macports's buggy configure scripts Message-ID: <7675454e0805081943wacfdc85xe3f5f9b614730036@mail.gmail.com> The site doesn't seem to be working, so reporting a bug here: The guide says that to install two different MacPorts copies, one must use --with-tclpackage. But try this: ./configure --prefix=PREFIX1 --with-tclpackage=TCLPREFIX1 && make && make install ./configure && make && make install. Now go in /opt/local and grep for TCLPREFIX1. Sigh. Actually, even installing two different things: ./configure --prefix=PREFIX1 --with-tclpackage=TCLPREFIX1 && make && make install ./configure --prefix=PREFIX2 --with-tclpackage=TCLPREFIX2 && make && make install did not work for me -- installing from the second prefix's binary would install it under the first prefix. Somehow, it doesn't surprise me at all that even MacPorts's own configure scripts are broken. Someone correct me if I'm wrong. From wsiegrist at apple.com Thu May 8 19:45:03 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu May 8 19:41:12 2008 Subject: Macports's buggy configure scripts In-Reply-To: <7675454e0805081943wacfdc85xe3f5f9b614730036@mail.gmail.com> References: <7675454e0805081943wacfdc85xe3f5f9b614730036@mail.gmail.com> Message-ID: <4A000D2A-720A-433F-A8C1-BEB9DA3B8D55@apple.com> I was rebooting the servers per my IRC announcement. Sorry for the downtime. On May 8, 2008, at 7:43 PM, Shreevatsa R wrote: > The site doesn't seem to be working, so reporting a bug here: > > The guide says that to install two different MacPorts copies, one must > use --with-tclpackage. But try this: > ./configure --prefix=PREFIX1 --with-tclpackage=TCLPREFIX1 && make && > make install > ./configure && make && make install. > Now go in /opt/local and grep for TCLPREFIX1. > Sigh. > > Actually, even installing two different things: > ./configure --prefix=PREFIX1 --with-tclpackage=TCLPREFIX1 && make && > make install > ./configure --prefix=PREFIX2 --with-tclpackage=TCLPREFIX2 && make && > make install > did not work for me -- installing from the second prefix's binary > would install it under the first prefix. > > Somehow, it doesn't surprise me at all that even MacPorts's own > configure scripts are broken. > > Someone correct me if I'm wrong. > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev ---- William Siegrist Mac OS Forge http://macosforge.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080508/74ee8bba/smime.bin From blair at orcaware.com Thu May 8 22:46:16 2008 From: blair at orcaware.com (Blair Zajac) Date: Thu May 8 22:42:40 2008 Subject: Where are we with simultaneous Python Framework installs In-Reply-To: <4821E7D3.6030709@macports.org> References: <4821E146.5000405@orcaware.com> <4821E7D3.6030709@macports.org> Message-ID: <4823E528.3050601@orcaware.com> Rainer M?ller wrote: > Blair Zajac wrote: >> I'd like to move to Python 2.5 for all our PyQt and GUI apps that >> require the Framework build. We have some major apps written on 2.4, >> so I'd like to be able to have 2.4 and 2.5 simulatenously installed so >> developers can check their work on the same system with a single >> MacPorts install. > > See http://trac.macports.org/wiki/PythonFrameworkTransition and the > python-frameworks branch in svn. I tried to make python24 and python25 > more similar and build both as frameworks. > > Before this can be released we need an easy way for the transition as > described on the wiki page. I don't think we can just move the site-packages, can we? There are .so's in there. Shouldn't we require a recompile of all python 25 ports? It's safer. Just bump all the revisions after we release 1.6.1. > Also updates to the python port groups are necessary. Currently they are > shipped with base, so we can't update them at any time, only with > releases. See ticket #14553 [1] for more. Sure we could solve this issue > before (with a release) and then update the port groups whenever we like > without waiting for new releases. > >> Were we going to have the port system update the >> /opt/local/Library/Frameworks/Python.framework/Versions/Current >> symlink depending upon the version of Python that is currently being >> used for a build? > > python_select will take care of this and set Current to the python > version you selected. > > If we also need to update this at build time, the python port groups > need an update to set and restore this link for building. Is there no > other way to choose a version than changing the Current symlink? I am > afraid of race conditions when we often change this symlink... We just need this symlink for building though? After build time doesn't everything have the Current symlink resolved? We would need a lock on simultaneous Python builds also. Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From ryandesign at macports.org Thu May 8 23:06:29 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu May 8 23:02:42 2008 Subject: Macports's buggy configure scripts In-Reply-To: <7675454e0805081943wacfdc85xe3f5f9b614730036@mail.gmail.com> References: <7675454e0805081943wacfdc85xe3f5f9b614730036@mail.gmail.com> Message-ID: <7A9A8508-229B-46D4-B357-C101B76E21F9@macports.org> On May 8, 2008, at 9:43 PM, Shreevatsa R wrote: > The site doesn't seem to be working, so reporting a bug here: Parts of the web site may be down or weird for a few days as William continues to stabilize the system following the recent site upgrades. Hopefully we'll soon be back to normal. > The guide says that to install two different MacPorts copies, one must > use --with-tclpackage. But try this: > ./configure --prefix=PREFIX1 --with-tclpackage=TCLPREFIX1 && make && > make install Ok, you're requesting to install a copy of MacPorts into PREFIX1. > ./configure && make && make install. Now you're requesting a second copy be installed in the default prefix, /opt/local. > Now go in /opt/local and grep for TCLPREFIX1. > Sigh. > > Actually, even installing two different things: > ./configure --prefix=PREFIX1 --with-tclpackage=TCLPREFIX1 && make && > make install > ./configure --prefix=PREFIX2 --with-tclpackage=TCLPREFIX2 && make && > make install > did not work for me -- installing from the second prefix's binary > would install it under the first prefix. I tested this second recipe, and I see that the second "make" doesn't do anything; it says "Nothing to be done for `all'" many times. "make install" then succeeds, installs everything in PREFIX2, and I agree that TCLPREFIX1 does appear in port, portf (a symlink to port), portindex and portmirror in PREFIX2/bin, which is clearly not what one wants. "make clean" before trying to configure a second time solves this. I'm not sufficiently well-versed in the make system to know whether that's to be expected or not. When I build MacPorts from source, I personally always "make clean" after I'm done so I don't run into any weirdness the next time. > Somehow, it doesn't surprise me at all that even MacPorts's own > configure scripts are broken. You're implying that a lot of MacPorts is broken. We can only fix what people report as broken, and what we know how to fix. Please file bugs as you find things that are wrong. If you know how to fix the problem, of course please tell us how in the ticket or attach a patch; that should make it quicker to fix. > Someone correct me if I'm wrong. From afb at macports.org Thu May 8 23:25:18 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu May 8 23:21:30 2008 Subject: Macports's buggy configure scripts In-Reply-To: <7675454e0805081943wacfdc85xe3f5f9b614730036@mail.gmail.com> References: <7675454e0805081943wacfdc85xe3f5f9b614730036@mail.gmail.com> Message-ID: <88A3F644-0871-4CFD-922C-71A0231316A9@macports.org> Shreevatsa R wrote: > The site doesn't seem to be working, so reporting a bug here: > > The guide says that to install two different MacPorts copies, one must > use --with-tclpackage. But try this: > ./configure --prefix=PREFIX1 --with-tclpackage=TCLPREFIX1 && make && > make install > ./configure && make && make install. > Now go in /opt/local and grep for TCLPREFIX1. > Sigh. TCLPREFIX1 is *outside* of PREFIX1, since the MacPorts Tcl files install outside of the prefix - like its applications/frameworks. (usually using the defaults of: "/Library/Tcl" and "/opt/local") I don't think that's such a great idea myself, but that is the way that the current setup is done. See older list discussions. > Actually, even installing two different things: > ./configure --prefix=PREFIX1 --with-tclpackage=TCLPREFIX1 && make && > make install > ./configure --prefix=PREFIX2 --with-tclpackage=TCLPREFIX2 && make && > make install > did not work for me -- installing from the second prefix's binary > would install it under the first prefix. Confirmed, the src/Makefile doesn't rebuild the "port" binary when you configure twice in the same directory. The workaround for now is to "clean" base before doing the second installation. (preferably distclean, but "dist" and "distclean" are missing) Not sure why that doesn't use autoconf, but instead a sed hack. --anders From jmpp at macports.org Fri May 9 00:01:13 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu May 8 23:57:31 2008 Subject: Macports's buggy configure scripts In-Reply-To: <7675454e0805081943wacfdc85xe3f5f9b614730036@mail.gmail.com> References: <7675454e0805081943wacfdc85xe3f5f9b614730036@mail.gmail.com> Message-ID: <60FCF962-4121-4387-89BF-1306DD3A3008@macports.org> On May 8, 2008, at 10:13 PM, Shreevatsa R wrote: > The site doesn't seem to be working, so reporting a bug here: > > The guide says that to install two different MacPorts copies, one must > use --with-tclpackage. But try this: > ./configure --prefix=PREFIX1 --with-tclpackage=TCLPREFIX1 && make && > make install > ./configure && make && make install. > Now go in /opt/local and grep for TCLPREFIX1. > Sigh. > > Actually, even installing two different things: > ./configure --prefix=PREFIX1 --with-tclpackage=TCLPREFIX1 && make && > make install > ./configure --prefix=PREFIX2 --with-tclpackage=TCLPREFIX2 && make && > make install > did not work for me -- installing from the second prefix's binary > would install it under the first prefix. $[jmpp @MacBookPro: base](156/0,0) -> ./build.sh Building sources... ./configure --prefix=/opt/mp1 --with-install-user=root --with-install- group=admin --with-tclinclude=/usr/include --with-tcl=/usr/lib --with- tclpackage=/opt/mp1/Library/Tcl && make ---snip--- $[jmpp @MacBookPro: base](157/0,0) -> sudo make install Password: Upgrading your existing MacPorts installation to the new namespace if necessary: [ ! -d /opt/mp1/Library/Tcl/darwinports1.0 ] || rm -rf /opt/mp1/ Library/Tcl/darwinports1.0 ---snip--- $[jmpp @MacBookPro: base](158/0,0) -> make distclean ---snip--- $[jmpp @MacBookPro: base](161/2,0) -> ./build.sh Building sources... ./configure --prefix=/opt/mp2 --with-install-user=root --with-install- group=admin --with-tclinclude=/usr/include --with-tcl=/usr/lib --with- tclpackage=/opt/mp2/Library/Tcl && make ---snip--- $[jmpp @MacBookPro: base](162/0,0) -> sudo make install Upgrading your existing MacPorts installation to the new namespace if necessary: [ ! -d /opt/mp2/Library/Tcl/darwinports1.0 ] || rm -rf /opt/mp2/ Library/Tcl/darwinports1.0 ---snip--- $[jmpp @MacBookPro: base](163/0,0) -> cd /opt/ $[jmpp @MacBookPro: opt](164/0,0) -> ls total 0 drwxr-xr-x 13 root admin 442B May 4 01:04 local/ drwxr-xr-x 14 root admin 476B May 9 02:09 mp1/ drwxr-xr-x 14 root admin 476B May 9 02:10 mp2/ $[jmpp @MacBookPro: opt](181/0,0) -> grep macports_conf_path mp1/ Library/Tcl/macports1.0/macports_autoconf.tcl variable macports_conf_path "/opt/mp1/etc/macports" $[jmpp @MacBookPro: opt](184/0,0) -> grep macports_fastload mp1/bin/port [file join "/opt/mp1/Library/Tcl" macports1.0 macports_fastload.tcl]} $[jmpp @MacBookPro: opt](194/0,0) -> ls mp1/bin/portf lrwxr-xr-x 1 root admin 4B May 9 02:09 mp1/bin/portf@ -> port $[jmpp @MacBookPro: opt](195/0,0) -> grep macports_conf_path mp2/ Library/Tcl/macports1.0/macports_autoconf.tcl variable macports_conf_path "/opt/mp2/etc/macports" $[jmpp @MacBookPro: opt](196/0,0) -> grep macports_fastload mp2/bin/port [file join "/opt/mp2/Library/Tcl" macports1.0 macports_fastload.tcl]} $[jmpp @MacBookPro: opt](197/0,0) -> ls mp2/bin/portf lrwxr-xr-x 1 root admin 4B May 9 02:10 mp2/bin/portf@ -> port So, as you can see, everything works if you simply "distclean" between the first config and the second, to remove the build results *and* the autoconf generated files. I could agree that our build system maybe doesn't have the best of dependency logic or whatever (maybe proper cleaning actions?) if what you want doesn't work with a plain reconf or even a "make clean" between reconfs, but in such case we're open to hear suggestions (best if they come accompanied by patches!). As to why things are the way they are, e.g. not autoconfing the regen of the port(1) script , I honestly can't remember the reasoning that lead the original designers to write what we now have, a sed action to shoehorn the proper paths into the scripts. But, as stated, we're open to improvements of any kind. In any case, the point stands, what you want to do is achievable with a "distclean" in between reconfs. > > > Somehow, it doesn't surprise me at all that even MacPorts's own > configure scripts are broken. Do help us improve MacPorts if the impression you have is such a bad one. -jmpp From raimue at macports.org Fri May 9 00:30:56 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri May 9 00:27:48 2008 Subject: Where are we with simultaneous Python Framework installs In-Reply-To: <4823E528.3050601@orcaware.com> References: <4821E146.5000405@orcaware.com> <4821E7D3.6030709@macports.org> <4823E528.3050601@orcaware.com> Message-ID: <4823FDB0.3080101@macports.org> Blair Zajac wrote: > I don't think we can just move the site-packages, can we? There are .so's in there. No, especially not because they are recorded in file_map.db to be installed at the old location. If you just move them, they are not known to MacPorts at all. It would be possible to do it vice-versa and put a symlink into the framework pointing to /opt/local/lib/pythonX.Y/. If I recall correctly this is the current behavior used by the python2.4 port (which was chosen to avoid reinstalling all py-* ports?). But somehow I don't want to make an exception for lib/ and treat it different than include/ and bin/. Better put everything into the framework and make symlinks at the usual places pointing to it. > Shouldn't we require a recompile of all python 25 ports? It's safer. Just bump > all the revisions after we release 1.6.1. No, just bumping revisions is not enough. Some paths like /opt/local/lib/pythonX.Y will change from a directory to a symlink to the framework. Our registry can't handle that. If the directory still exists and the pythonX.Y port tries to create a symlink there it fails with "File exists". So, all pyX.Y-* ports have to be completely uninstalled before doing the transition. That's the main problem why we need these hooks described in the wiki (Way 1 and Way 2). >> If we also need to update this at build time, the python port groups >> need an update to set and restore this link for building. Is there no >> other way to choose a version than changing the Current symlink? I am >> afraid of race conditions when we often change this symlink... > > We just need this symlink for building though? After build time doesn't > everything have the Current symlink resolved? Yes, that should be the case. > We would need a lock on simultaneous Python builds also. At the moment I am thinking if we need the Current symlink at all. How would one use this Framework (see also my tests below)? If we just add -I and -L with framework paths in the python port group we don't need to bother about the Current symlink at all. I think this is the best solution. Are there any other options? I tried to link some program to the python framework in /opt/local using gcc, but it didn't work. $ gcc -o foo foo.c -Z -syslibroot /opt/local -framework Python ld: framework not found Python collect2: ld returned 1 exit status I think I had all necessary files in place: $ ls -la /opt/local/Library/Frameworks/Python.framework/{,Versions} /opt/local/Library/Frameworks/Python.framework/: total 16 drwxr-xr-x 5 root admin 170 May 9 09:23 . drwxr-xr-x 4 root admin 136 Jan 19 05:56 .. lrwxr-xr-x 1 root admin 20 May 9 09:22 Headers -> Versions/2.5/Headers lrwxr-xr-x 1 root admin 19 May 9 09:23 Python -> Versions/2.5/Python lrwxr-xr-x 1 root admin 22 May 9 09:23 Resources -> Versions/2.5/Resources drwxr-xr-x 6 root admin 204 May 9 09:23 Versions /opt/local/Library/Frameworks/Python.framework/Versions: total 8 drwxr-xr-x 6 root admin 204 May 9 09:23 . drwxr-xr-x 5 root admin 170 May 9 09:23 .. drwxr-xr-x 8 root admin 272 Apr 24 04:09 2.5 lrwxr-xr-x 1 root admin 3 May 9 09:23 Current -> 2.5 So if someone knows how to link against a framework in a custom path, please advice. Rainer From afb at macports.org Fri May 9 00:47:46 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri May 9 00:43:56 2008 Subject: Where are we with simultaneous Python Framework installs In-Reply-To: <4823FDB0.3080101@macports.org> References: <4821E146.5000405@orcaware.com> <4821E7D3.6030709@macports.org> <4823E528.3050601@orcaware.com> <4823FDB0.3080101@macports.org> Message-ID: Rainer M?ller: > So if someone knows how to link against a framework in a custom > path, please advice. See the -F flag. You'd still need the standard Current symlink operational, though. --anders From raimue at macports.org Fri May 9 00:55:56 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri May 9 00:52:08 2008 Subject: Where are we with simultaneous Python Framework installs In-Reply-To: References: <4821E146.5000405@orcaware.com> <4821E7D3.6030709@macports.org> <4823E528.3050601@orcaware.com> <4823FDB0.3080101@macports.org> Message-ID: <4824038C.3040101@macports.org> Anders F Bj?rklund wrote: > Rainer M?ller: > >> So if someone knows how to link against a framework in a custom >> path, please advice. > > See the -F flag. You'd still need the standard Current symlink > operational, though. -F is documented to set the include path (like -I): "Add the framework directory dir to the head of the list of directories to be searched for header files." If this works for headers, how is the linking done? In my test, it still did not work ("ld: framework not found Python") or was linked against the system's python which was not what I intended. Rainer From afb at macports.org Fri May 9 01:02:15 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri May 9 00:58:24 2008 Subject: Where are we with simultaneous Python Framework installs In-Reply-To: <4824038C.3040101@macports.org> References: <4821E146.5000405@orcaware.com> <4821E7D3.6030709@macports.org> <4823E528.3050601@orcaware.com> <4823FDB0.3080101@macports.org> <4824038C.3040101@macports.org> Message-ID: <29BA273A-6ADB-4CC1-ABB9-A5A61AB04925@macports.org> Rainer M?ller wrote: >> See the -F flag. You'd still need the standard Current symlink >> operational, though. > > -F is documented to set the include path (like -I): > "Add the framework directory dir to the head of the list of > directories to be searched for header files." > > If this works for headers, how is the linking done? In my test, it > still did not work ("ld: framework not found Python") or was linked > against the system's python which was not what I intended. Hmm, guess I didn't play with frameworks in strange locations enough... Wonder if there is a gcc solution, or if $DYLD_FRAMEWORK_PATH is the way ? --anders From afb at macports.org Fri May 9 01:09:36 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri May 9 01:05:59 2008 Subject: Where are we with simultaneous Python Framework installs In-Reply-To: <29BA273A-6ADB-4CC1-ABB9-A5A61AB04925@macports.org> References: <4821E146.5000405@orcaware.com> <4821E7D3.6030709@macports.org> <4823E528.3050601@orcaware.com> <4823FDB0.3080101@macports.org> <4824038C.3040101@macports.org> <29BA273A-6ADB-4CC1-ABB9-A5A61AB04925@macports.org> Message-ID: >> -F is documented to set the include path (like -I): >> "Add the framework directory dir to the head of the list of >> directories to be searched for header files." >> >> If this works for headers, how is the linking done? In my test, it >> still did not work ("ld: framework not found Python") or was >> linked against the system's python which was not what I intended. > > Hmm, guess I didn't play with frameworks in strange locations > enough... > > Wonder if there is a gcc solution, or if $DYLD_FRAMEWORK_PATH is > the way ? Nope, seems to be working as I originally thought: gcc test.c -framework Python a.out: /Library/Frameworks/Python.framework/Versions/2.5/Python (compatibility version 2.5.0, current version 2.5.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10) gcc test.c -F/opt/local/Library/Frameworks -framework Python a.out: /opt/local/Library/Frameworks/Python.framework/Versions/2.4/ Python (compatibility version 2.4.0, current version 2.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10) So the -F flag is for adding to the framework paths. --anders From raimue at macports.org Fri May 9 06:45:22 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri May 9 06:41:34 2008 Subject: Where are we with simultaneous Python Framework installs In-Reply-To: References: <4821E146.5000405@orcaware.com> <4821E7D3.6030709@macports.org> <4823E528.3050601@orcaware.com> <4823FDB0.3080101@macports.org> <4824038C.3040101@macports.org> <29BA273A-6ADB-4CC1-ABB9-A5A61AB04925@macports.org> Message-ID: <48245572.6080805@macports.org> Anders F Bj?rklund wrote: > gcc test.c -F/opt/local/Library/Frameworks -framework Python Ah, my bad. I added the path to Python.framework instead of the parent. Must have misread the documentation. So, if there is no solution to choose a specific version we really need to add locking... Rainer From ronaldoussoren at mac.com Fri May 9 07:02:09 2008 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri May 9 06:58:17 2008 Subject: Where are we with simultaneous Python Framework installs In-Reply-To: <48245572.6080805@macports.org> References: <4821E146.5000405@orcaware.com> <4821E7D3.6030709@macports.org> <4823E528.3050601@orcaware.com> <4823FDB0.3080101@macports.org> <4824038C.3040101@macports.org> <29BA273A-6ADB-4CC1-ABB9-A5A61AB04925@macports.org> <48245572.6080805@macports.org> Message-ID: On Friday, May 09, 2008, at 03:45PM, "Rainer M?ller" wrote: >Anders F Bj?rklund wrote: >> gcc test.c -F/opt/local/Library/Frameworks -framework Python > >Ah, my bad. I added the path to Python.framework instead of the parent. >Must have misread the documentation. > >So, if there is no solution to choose a specific version we really need >to add locking... I haven't followed the discussion at all, so please forgive my ignorance on that part. First of: what are you trying to accomplish? And more to the point: I'd like to know if there's anything we can change in the python.org distribution to make that easier to accomplish. Python's distutils will automaticly link to the right python framework (or rather, doesn't explicitly link to the framework at all). For other unix-style builds you can add '-L ${sys.prefix}/lib/pythonX.Y/config/ -lpythonX.Y' to the link flags, which will link to the framework on recent enough builds of python (AFAIK all 2.5 builds, but definitly 2.5.2 and later). If you're using python2.5 or later: have a look at the "python-config" command. Apple's GCC doesn't have an option to explicitly pick a specific framework version, although you can always link the dylib inside the framework: gcc -o foo .... /Library/Frameworks/Python.framework/2.5/Python instead of: gcc -o foo .... -framework Python Ronald From jmr at macports.org Sun May 11 00:33:19 2008 From: jmr at macports.org (Joshua Root) Date: Sun May 11 00:29:21 2008 Subject: Patches awaiting review In-Reply-To: <4822C15F.6060207@macports.org> References: <4822C15F.6060207@macports.org> Message-ID: <4826A13F.3070609@macports.org> Joshua Root wrote: > I've got a bunch of bugfix patches on Trac which need reviewing. It > would be nice to get as many of them as possible into the upcoming > release. Ticket URLS: > > http://trac.macports.org/ticket/7361 > http://trac.macports.org/ticket/10768 > http://trac.macports.org/ticket/10827 > http://trac.macports.org/ticket/11971 > http://trac.macports.org/ticket/12013 > http://trac.macports.org/ticket/12170 > > There are also some patches from gwhitney which have been sitting there > for quite a while. He says he won't have time to work on MP until at > least the end of June. Tickets: > > http://trac.macports.org/ticket/8221 > http://trac.macports.org/ticket/11891 > http://trac.macports.org/ticket/11897 #10768 has now been committed. Thanks to Rainer for reviewing the patches in #7631, #10827, #11971 and #12170. I've updated #7361 and #12170 in response. Some more tickets with patches that need review that aren't on the previous list: http://trac.macports.org/ticket/8763 http://trac.macports.org/ticket/11501 http://trac.macports.org/ticket/11759 http://trac.macports.org/ticket/15161 - Josh From raimue at macports.org Sun May 11 01:44:11 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Sun May 11 01:40:15 2008 Subject: Patches awaiting review In-Reply-To: <4826A13F.3070609@macports.org> References: <4822C15F.6060207@macports.org> <4826A13F.3070609@macports.org> Message-ID: <4826B1DB.8030602@macports.org> Joshua Root wrote: > #10768 has now been committed. Thanks to Rainer for reviewing the > patches in #7631, #10827, #11971 and #12170. I've updated #7361 and > #12170 in response. As you nominated these patches for 1.6.1 you either need to merge them yourself to the release_1_6 branch. As we don't have a procedure for nomination and merging, I think it would be best to just merge it before it will be forgotten. We should decide on a procedure here, some list for nominating and one release manager doing the merges to the branch. As I said in the other mail in this thread, there were already new features merged back to the release_1_6 branch although this should not have happened. > Some more tickets with patches that need review that aren't on the > previous list: > > http://trac.macports.org/ticket/8763 > http://trac.macports.org/ticket/11501 > http://trac.macports.org/ticket/11759 > http://trac.macports.org/ticket/15161 I reviewed these as well and added comments. I would really like to see #11759 getting fixed, but my supplied patch is not necessarily the best solution. I think there must be a better way to do that a few levels above the registry. Rainer From jmr at macports.org Sun May 11 01:57:59 2008 From: jmr at macports.org (Joshua Root) Date: Sun May 11 01:54:00 2008 Subject: Patches awaiting review In-Reply-To: <4826B1DB.8030602@macports.org> References: <4822C15F.6060207@macports.org> <4826A13F.3070609@macports.org> <4826B1DB.8030602@macports.org> Message-ID: <4826B517.9020604@macports.org> Rainer M?ller wrote: > As you nominated these patches for 1.6.1 you either need to merge them > yourself to the release_1_6 branch. As we don't have a procedure for > nomination and merging, I think it would be best to just merge it before > it will be forgotten. > > We should decide on a procedure here, some list for nominating and one > release manager doing the merges to the branch. As I said in the other > mail in this thread, there were already new features merged back to the > release_1_6 branch although this should not have happened. Oh. I got the impression from the docs that the person building a release would go through the trunk revision log and merge the appropriate changesets into the branch. Perhaps jmpp could chime in here and clear up what actually happens in practice? >> http://trac.macports.org/ticket/8763 >> http://trac.macports.org/ticket/11501 >> http://trac.macports.org/ticket/11759 >> http://trac.macports.org/ticket/15161 > > I reviewed these as well and added comments. Thanks! - Josh From raimue at macports.org Sun May 11 09:55:43 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Sun May 11 09:51:46 2008 Subject: Patches awaiting review In-Reply-To: <4826B517.9020604@macports.org> References: <4822C15F.6060207@macports.org> <4826A13F.3070609@macports.org> <4826B1DB.8030602@macports.org> <4826B517.9020604@macports.org> Message-ID: <4827250F.2080909@macports.org> Joshua Root wrote: > Oh. I got the impression from the docs that the person building a > release would go through the trunk revision log and merge the > appropriate changesets into the branch. Perhaps jmpp could chime in here > and clear up what actually happens in practice? Depending how long ago the branch off was done, this could be a lot of work. svnmerge avail shows >100 revisions for release_1_6/base. I think it would be a lot easier to nominate specific revisions for merging. Rainer From n.oxyde at gmail.com Sun May 11 10:14:39 2008 From: n.oxyde at gmail.com (nox) Date: Sun May 11 10:10:41 2008 Subject: =?windows-1252?q?Re=3A_=5B36679=5D_trunk/base/src_=97_extract_st?= =?windows-1252?q?age_doesn=27t_get_the_right_tarball_path?= In-Reply-To: <20080511081825.578321666DB4@beta.macosforge.org> References: <20080511081825.578321666DB4@beta.macosforge.org> Message-ID: <0F6A625A-AC8B-42CF-BC66-C96AF758A0B4@gmail.com> Le 11 mai 08 ? 10:18, jmr@macports.org a ?crit : > Revision 36679 > Author jmr@macports.org > Date 2008-05-11 01:18:24 -0700 (Sun, 11 May 2008) > > Log Message > fetch_init, archive_init, unarchive_init: > Avoid creating too many subdirectory levels when these procedures > are called > more than once. Fix for #11971. > Modified Paths > ? trunk/base/src/package1.0/portarchive.tcl > ? trunk/base/src/package1.0/portunarchive.tcl > ? trunk/base/src/port1.0/portfetch.tcl Hi, I think this commit broke something: Bellcross:~ nox$ cd src/MacPorts/dports/multimedia/libogg/ Bellcross:libogg nox$ sudo port clean --all Password: ---> Cleaning libogg Bellcross:libogg nox$ sudo port -d extract DEBUG: Changing to port directory: /Users/nox/src/MacPorts/dports/ multimedia/libogg DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: Requested variant darwin is not provided by port libogg. DEBUG: Requested variant i386 is not provided by port libogg. DEBUG: Requested variant macosx is not provided by port libogg. DEBUG: Changing to port directory: /Users/nox/src/MacPorts/dports/ multimedia/libogg DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: Requested variant darwin is not provided by port libogg. DEBUG: Requested variant i386 is not provided by port libogg. DEBUG: Requested variant macosx is not provided by port libogg. DEBUG: Portfile changed since installation DEBUG: Executing org.macports.main (libogg) DEBUG: Portfile changed since installation ---> Fetching libogg DEBUG: Executing org.macports.fetch (libogg) ---> libogg-1.1.3.tar.gz doesn't seem to exist in /opt/local/var/ macports/distfiles/libogg ---> Attempting to fetch libogg-1.1.3.tar.gz from http://downloads.xiph.org/releases/ogg/ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 394k 100 394k 0 0 217k 0 0:00:01 0:00:01 --:--:-- 267k DEBUG: Portfile changed since installation ---> Verifying checksum(s) for libogg DEBUG: Executing org.macports.checksum (libogg) ---> Checksumming libogg-1.1.3.tar.gz Error: Target org.macports.checksum returned: Could not open file: / opt/local/var/macports/distfiles/libogg-1.1.3.tar.gz Warning: the following items did not execute (for libogg): org.macports.extract org.macports.checksum Error: Status 1 enc