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 encountered during processing. From andrea.damore at macports.org Sun May 11 13:17:50 2008 From: andrea.damore at macports.org (Andrea D'Amore) Date: Sun May 11 13:13:55 2008 Subject: octave-forge tarball format changed Message-ID: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> Hello, octave-forge portfile is pretty outdated, I got latest tarball and structure has changed, main tarball hasn't a configure script anymore,now it's only a collection of .tar.gz, each of them with its own configure script. What's the more convenient way to manage this? I basically tought of: a system shell cycle that will extract all tarballs and then perform configure&install; a system shell cycle that will invoke octave "pkg" command to let octave manage pkg installation, with a -global option so packages will be available to all users; an octave cycle that will install each package. A point to be kept in mind is that packages do have dependencies and I'm not sure pkg command can manage them, I tried to install optimization using octave in batch mode and it failed, but Tatsuro Matsuoka from octave-dev has provided me a list that should be dependecy-safe. Let me know how your toughts about this topic. Andrea From jmr at macports.org Sun May 11 15:43:56 2008 From: jmr at macports.org (Joshua Root) Date: Sun May 11 15:39:56 2008 Subject: [36679] trunk/base/src =?windows-1252?q?=97_extract_stage_doe?= =?windows-1252?q?sn=27t_get_the_right_tarball_path?= In-Reply-To: <0F6A625A-AC8B-42CF-BC66-C96AF758A0B4@gmail.com> References: <20080511081825.578321666DB4@beta.macosforge.org> <0F6A625A-AC8B-42CF-BC66-C96AF758A0B4@gmail.com> Message-ID: <482776AC.1090907@macports.org> nox wrote: > 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: > [...] > Error: Target org.macports.checksum returned: Could not open file: > /opt/local/var/macports/distfiles/libogg-1.1.3.tar.gz Should be fixed now. - Josh From landonf at macports.org Sun May 11 17:14:13 2008 From: landonf at macports.org (Landon Fuller) Date: Sun May 11 17:10:21 2008 Subject: Macports's buggy configure scripts In-Reply-To: <88A3F644-0871-4CFD-922C-71A0231316A9@macports.org> References: <7675454e0805081943wacfdc85xe3f5f9b614730036@mail.gmail.com> <88A3F644-0871-4CFD-922C-71A0231316A9@macports.org> Message-ID: On May 8, 2008, at 11:25 PM, Anders F Bj?rklund wrote: > 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. To solve the opposite problem -- if you change the source file, 'make' should remake it. See: http://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables Specifically: Similarly, you should not rely on AC_CONFIG_FILES to replace datadir and friends in your shell scripts and other files; instead, let make manage their replacement. For instance Autoconf ships templates of its shell scripts ending with `.in', and uses a makefile snippet similar to the following to build scripts like autoheader and autom4te: edit = sed ... If re-running configure should also cause any files to be regenerated, then another 'make' dependency is probably in order. -landonf -------------- 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/20080511/44a2c638/PGP-0001.bin From afb at macports.org Sun May 11 23:19:25 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun May 11 23:15:24 2008 Subject: Macports's buggy configure scripts In-Reply-To: References: <7675454e0805081943wacfdc85xe3f5f9b614730036@mail.gmail.com> <88A3F644-0871-4CFD-922C-71A0231316A9@macports.org> Message-ID: <1EC5C220-AC89-4F30-A644-7F8852FB49C8@macports.org> Landon Fuller wrote: >> Not sure why that doesn't use autoconf, but instead a sed hack. > > To solve the opposite problem -- if you change the source file, > 'make' should remake it. See: > http://www.gnu.org/software/autoconf/manual/ > autoconf.html#Installation-Directory-Variables Right, thanks for explaining the issue. Probably easier when also using automake. > If re-running configure should also cause any files to be > regenerated, then another 'make' dependency is probably in order. Yeah, since it was just three seds the easiest was to just regenerate them always. --anders From aschenke at tampabay.rr.com Mon May 12 12:58:40 2008 From: aschenke at tampabay.rr.com (Adam Schenker) Date: Mon May 12 12:54:34 2008 Subject: [ticket 15264]: need commit & requesting commit privileges Message-ID: <0ACF9B04-DB1F-4CA9-A3D9-0CF4779EF948@tampabay.rr.com> I have updated this port (Larn) to no longer depend on libcompat, since libcompat doesn't build under Leopard. I have attached the diff to the ticket: http://trac.macports.org/ticket/15264 I'd be grateful if someone could commit this for me. Also, I'd like to go ahead and request commit privileges so I don't have to keep asking on the list. I am the maintainer of the above port as well as 4 others. -- Adam Schenker aschenke@tampabay.rr.com From xunil at xunil.net Mon May 12 17:25:52 2008 From: xunil at xunil.net (Robert Liesenfeld) Date: Mon May 12 17:21:55 2008 Subject: Building python2.5 extensions under MacPorts Message-ID: <4E6E57A9-B79D-4898-96FE-B8A025DDB4BE@xunil.net> Anyone built any Python extensions, specifically for Python 2.5? I'm trying to make a py25-pyqt4 port, and i'm running into trouble with building the extension .so's; they keep getting linked against the system (i.e. Apple-provided) Python, not the MacPorts Python: ~/Projects/ports/python/py25-pyqt4/work/PyQt-mac-gpl-4.3.3/Qt $ otool - L Qt.so Qt.so: /System/Library/Frameworks/Python.framework/Versions/2.5/Python (compatibility version 2.5.0, current version 2.5.1) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) This seems to be due to the fact that the python25 port is configured with frameworks explicitly disabled (--disable-frameworks passed to configure). Obviously this incorrect linkage causes problems: $ /opt/local/bin/python2.5 Python 2.5.2 (r252:60911, May 8 2008, 00:00:59) [GCC 4.0.1 (Apple Inc. build 5478)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import Qt Fatal Python error: Interpreter not initialized (version mismatch?) Abort trap I'll admit I'm a little out of my depth here, having never done much with Qt or Python extensions before. I hope someone can shed some light on how I would convince the linker to link against the python25 port, especially since there's no Python.framework to be found under the MacPorts hierarchy. Thanks! -Robert "Xunil96" Liesenfeld From etiffany at alum.mit.edu Mon May 12 17:52:11 2008 From: etiffany at alum.mit.edu (Eric Tiffany) Date: Mon May 12 17:48:16 2008 Subject: Building python2.5 extensions under MacPorts In-Reply-To: <4E6E57A9-B79D-4898-96FE-B8A025DDB4BE@xunil.net> Message-ID: I have had trouble with python grabbing the wrong lib versions, too. My solution was to set DYLD_LIBRARY_PATH to the correct thing (/opt/local/lib) in both the build environment AND the runtime env. Others have different solutions. There was a similar thread on the LXML mailing list, part of which can be found here: http://thread.gmane.org/gmane.comp.python.lxml.devel/3599 The thread seems to have been broken, so to see the whole thing you'll need to look at all the threads in that group. But I think that segment of the thread has most of the juicy bits. ET On 5/12/08 5:25 PM, "Robert Liesenfeld" wrote: > > Anyone built any Python extensions, specifically for Python 2.5? I'm > trying to make a py25-pyqt4 port, and i'm running into trouble with > building the extension .so's; they keep getting linked against the > system (i.e. Apple-provided) Python, not the MacPorts Python: > > ~/Projects/ports/python/py25-pyqt4/work/PyQt-mac-gpl-4.3.3/Qt $ otool - > L Qt.so > Qt.so: > /System/Library/Frameworks/Python.framework/Versions/2.5/Python > (compatibility version 2.5.0, current version 2.5.1) > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current > version 7.4.0) > /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current > version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 111.0.0) > > This seems to be due to the fact that the python25 port is configured > with frameworks explicitly disabled (--disable-frameworks passed to > configure). Obviously this incorrect linkage causes problems: > > $ /opt/local/bin/python2.5 > Python 2.5.2 (r252:60911, May 8 2008, 00:00:59) > [GCC 4.0.1 (Apple Inc. build 5478)] on darwin > Type "help", "copyright", "credits" or "license" for more information. >>>> import Qt > Fatal Python error: Interpreter not initialized (version mismatch?) > Abort trap > > I'll admit I'm a little out of my depth here, having never done much > with Qt or Python extensions before. I hope someone can shed some > light on how I would convince the linker to link against the python25 > port, especially since there's no Python.framework to be found under > the MacPorts hierarchy. > > Thanks! > > -Robert "Xunil96" Liesenfeld > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From blair at orcaware.com Mon May 12 18:14:01 2008 From: blair at orcaware.com (Blair Zajac) Date: Mon May 12 18:09:55 2008 Subject: Building python2.5 extensions under MacPorts In-Reply-To: <4E6E57A9-B79D-4898-96FE-B8A025DDB4BE@xunil.net> References: <4E6E57A9-B79D-4898-96FE-B8A025DDB4BE@xunil.net> Message-ID: <4828EB59.7090502@orcaware.com> Robert Liesenfeld wrote: > > Anyone built any Python extensions, specifically for Python 2.5? I'm > trying to make a py25-pyqt4 port, and i'm running into trouble with > building the extension .so's; they keep getting linked against the > system (i.e. Apple-provided) Python, not the MacPorts Python: The python 2.5 provided by MacPorts is not a framework Python, which I'm pretty sure is required by PyQt. There's a thread that was started last week about getting Python 2.5 to a Framework build. Regards, Blair From n.oxyde at gmail.com Tue May 13 03:01:47 2008 From: n.oxyde at gmail.com (nox) Date: Tue May 13 02:57:48 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: <0F6A625A-AC8B-42CF-BC66-C96AF758A0B4@gmail.com> References: <20080511081825.578321666DB4@beta.macosforge.org> <0F6A625A-AC8B-42CF-BC66-C96AF758A0B4@gmail.com> Message-ID: <4FB5916D-0F18-4FB8-8D79-9154D787F5E8@gmail.com> Le 11 mai 08 ? 19:14, nox a ?crit : > 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 encountered during processing. > jmr fixed this specific problem in r36687 and r36688, but I've found another one in the patch stage: $ sudo port install +universal ---> Fetching jpeg ---> Attempting to fetch jpegsrc.v6b.tar.gz from ftp://ftp.uu.net/graphics/jpeg ---> Attempting to fetch jpegsrc.v6b.tar.gz from http://www.ijg.org/files ---> Attempting to fetch droppatch.tar.gz from http://sylvana.net/jpegcrop/ ---> Verifying checksum(s) for jpeg ---> Extracting jpeg ---> Applying patches to jpeg Error: Target org.macports.patch returned: shell command "cd /opt/ local/var/macports/build/_Users_nox_src_MacPorts_dports_graphics_jpeg/ work/jpeg-6b && tar zxf /opt/local/var/macports/distfiles/droppatch.tar.gz" returned error 2 Command output: tar (child): /opt/local/var/macports/distfiles/ droppatch.tar.gz: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error exit delayed from previous errors Error: Status 1 encountered during processing. From jmr at macports.org Tue May 13 03:37:24 2008 From: jmr at macports.org (Joshua Root) Date: Tue May 13 03:33:16 2008 Subject: [36679] trunk/base/src =?windows-1252?q?=97_extract_stage_doe?= =?windows-1252?q?sn=27t_get_the_right_tarball_path?= In-Reply-To: <4FB5916D-0F18-4FB8-8D79-9154D787F5E8@gmail.com> References: <20080511081825.578321666DB4@beta.macosforge.org> <0F6A625A-AC8B-42CF-BC66-C96AF758A0B4@gmail.com> <4FB5916D-0F18-4FB8-8D79-9154D787F5E8@gmail.com> Message-ID: <48296F64.4040102@macports.org> nox wrote: > jmr fixed this specific problem in r36687 and r36688, but I've found > another one in the patch stage: > > $ sudo port install +universal > ---> Fetching jpeg > ---> Attempting to fetch jpegsrc.v6b.tar.gz from > ftp://ftp.uu.net/graphics/jpeg > ---> Attempting to fetch jpegsrc.v6b.tar.gz from http://www.ijg.org/files > ---> Attempting to fetch droppatch.tar.gz from > http://sylvana.net/jpegcrop/ > ---> Verifying checksum(s) for jpeg > ---> Extracting jpeg > ---> Applying patches to jpeg > Error: Target org.macports.patch returned: shell command "cd > /opt/local/var/macports/build/_Users_nox_src_MacPorts_dports_graphics_jpeg/work/jpeg-6b > && > tar zxf /opt/local/var/macports/distfiles/droppatch.tar.gz" > returned error 2 > Command output: tar (child): > /opt/local/var/macports/distfiles/droppatch.tar.gz: Cannot open: No such > file or directory Hmm... I can't reproduce this one. Could there be some state left over from before or something? - Josh From ryandesign at macports.org Tue May 13 04:30:01 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue May 13 04:25:59 2008 Subject: [36127] trunk/base/doc/macports.conf.in In-Reply-To: <20080419014618.C075415B4066@beta.macosforge.org> References: <20080419014618.C075415B4066@beta.macosforge.org> Message-ID: <18A4960E-A17D-4A14-99F2-938EEC685FE9@macports.org> On Apr 18, 2008, at 8:46 PM, markd@macports.org wrote: > Revision: 36127 > http://trac.macosforge.org/projects/macports/changeset/36127 > Author: markd@macports.org > Date: 2008-04-18 18:46:17 -0700 (Fri, 18 Apr 2008) > > Log Message: > ----------- > Add comments for binpath. > > Modified Paths: > -------------- > trunk/base/doc/macports.conf.in > > Modified: trunk/base/doc/macports.conf.in > =================================================================== > --- trunk/base/doc/macports.conf.in 2008-04-19 01:33:52 UTC (rev > 36126) > +++ trunk/base/doc/macports.conf.in 2008-04-19 01:46:17 UTC (rev > 36127) > @@ -14,6 +14,10 @@ > # Type of installation to do for ports, "direct" or "image". See > macports.conf(5) and online documentation. > portinstalltype image > > +# PATH settings that are used for external tools (configure, make, > etc.) while installing ports. The default > +# paths are given in the example; it need not be uncommented. > Customizing binpath is intended for advanced users only. > +#binpath /opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/ > sbin:/usr/X11R6/bin > + > # Directory containing the X11 installation. > x11prefix @x11prefix@ Shouldn't we not hard-code the prefix and x11prefix, even if it is just a commented-out example line? -------------- next part -------------- A non-text attachment was scrubbed... Name: macports.conf.in.diff Type: application/octet-stream Size: 678 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080513/fc404163/macports.conf.in-0001.obj -------------- next part -------------- From ryandesign at macports.org Tue May 13 04:32:05 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue May 13 04:28:03 2008 Subject: [36379] trunk/base/src In-Reply-To: <20080429032938.52736160CB08@beta.macosforge.org> References: <20080429032938.52736160CB08@beta.macosforge.org> Message-ID: On Apr 28, 2008, at 10:29 PM, raimue@macports.org wrote: > Revision: 36379 > http://trac.macosforge.org/projects/macports/changeset/36379 > Author: raimue@macports.org > Date: 2008-04-28 20:29:37 -0700 (Mon, 28 Apr 2008) > > Log Message: > ----------- > base/src: > Adapting $portname @$version notation Oh thank you, thank you, thank you!!! :) From raimue at macports.org Tue May 13 07:02:40 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Tue May 13 06:58:33 2008 Subject: [36708] trunk/base/src/port1.0 In-Reply-To: <20080513032726.32317167EA3F@beta.macosforge.org> References: <20080513032726.32317167EA3F@beta.macosforge.org> Message-ID: <48299F80.7090703@macports.org> ryandesign@macports.org wrote: > Revision: 36708 > http://trac.macosforge.org/projects/macports/changeset/36708 > Author: ryandesign@macports.org > Date: 2008-05-12 20:27:25 -0700 (Mon, 12 May 2008) > > Log Message: > ----------- > Allow distfiles to be disk images with new "use_dmg yes" port option; #13509. Nice new feature! > Modified: trunk/base/src/port1.0/portextract.tcl > =================================================================== > --- trunk/base/src/port1.0/portextract.tcl 2008-05-13 03:11:06 UTC (rev 36707) > +++ trunk/base/src/port1.0/portextract.tcl 2008-05-13 03:27:25 UTC (rev 36708) [...] > @@ -74,6 +74,14 @@ > option extract.cmd [binaryInPath "unzip"] > option extract.pre_args -q > option extract.post_args "-d [option extract.dir]" > + } elseif {[tbool use_dmg]} { > + global worksrcdir > + set dmg_tmp_dir [exec mktemp -d -q "/tmp/mports.XXXXXXXX"] We have a mktemp procedure in pextlib, so you could just call that instead: [mktemp "/tmp/mports.XXXXXXXX"] > + set dmg_mount ${dmg_tmp_dir}/${worksrcdir} > + file mkdir ${dmg_mount} > + option extract.cmd [binaryInPath "hdiutil"] > + option extract.pre_args attach > + option extract.post_args "-private -readonly -nobrowse -mountpoint ${dmg_mount} && [binaryInPath "cp"] -Rp ${dmg_mount} ${extract.dir} && ${extract.cmd} detach ${dmg_mount} && [binaryInPath "rmdir"] ${dmg_mount} ${dmg_tmp_dir}" > } > } From markd at macports.org Tue May 13 09:25:12 2008 From: markd at macports.org (markd@macports.org) Date: Tue May 13 09:20:58 2008 Subject: [36127] trunk/base/doc/macports.conf.in Message-ID: >> +# PATH settings that are used for external tools (configure, make, >> etc.) while installing ports. The default >> +# paths are given in the example; it need not be uncommented. >> Customizing binpath is intended for advanced users only. >> +#binpath >/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/ >> sbin:/usr/X11R6/bin >> + >> # Directory containing the X11 installation. >> x11prefix @x11prefix@ > >Shouldn't we not hard-code the prefix and x11prefix, even if it is >just a commented-out example line? Maybe. Would it be better to put psuedo paths in the comments such as "/foo; /blah" or something? I think the variable should be referenced in the file somewhere, and it seems awkward to list no path. Also, I see the guide doesn't list the default binpath so that should be fixed. http://guide.macports.org/#reference.variables I'm shortly going to do some minor enhancement of path related information in the guide related to binpath anyway. Things I didn't understand until now. Mark From raimue at macports.org Tue May 13 09:43:32 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue May 13 09:39:25 2008 Subject: [36127] trunk/base/doc/macports.conf.in In-Reply-To: References: Message-ID: <4829C534.8020501@macports.org> markd@macports.org wrote: >>> +# PATH settings that are used for external tools (configure, make, >>> etc.) while installing ports. The default >>> +# paths are given in the example; it need not be uncommented. >>> Customizing binpath is intended for advanced users only. >>> +#binpath >> /opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/ >>> sbin:/usr/X11R6/bin >>> + >>> # Directory containing the X11 installation. >>> x11prefix @x11prefix@ >> Shouldn't we not hard-code the prefix and x11prefix, even if it is >> just a commented-out example line? > > Maybe. Would it be better to put psuedo paths in the comments such as > "/foo; /blah" or something? I think the variable should be referenced in > the file somewhere, and it seems awkward to list no path. Also, I see the > guide doesn't list the default binpath so that should be fixed. Just use @prefix_expended@ and @x11prefix@ which will get expanded on install. We already use them at other places in this file. As a side note, maybe binpath should not be overwritten, but paths given in the config should be prepended to the default list. This would make it much easier to use this feature. But I am unsure if we really want users to make use of this as it allows third-party dependencies. Rainer From markd at macports.org Tue May 13 10:07:10 2008 From: markd at macports.org (markd@macports.org) Date: Tue May 13 10:02:58 2008 Subject: [36127] trunk/base/doc/macports.conf.in Message-ID: >>>> Customizing binpath is intended for advanced users only. >>>> +#binpath >>> /opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/ >>>> sbin:/usr/X11R6/bin >>>> + >>>> # Directory containing the X11 installation. >>>> x11prefix @x11prefix@ >>> Shouldn't we not hard-code the prefix and x11prefix, even if it is >>> just a commented-out example line? >> >> Maybe. Would it be better to put psuedo paths in the comments such as >> "/foo; /blah" or something? I think the variable should be referenced >in >> the file somewhere, and it seems awkward to list no path. Also, I see >the >> guide doesn't list the default binpath so that should be fixed. > >Just use @prefix_expended@ and @x11prefix@ which will get expanded on >install. We already use them at other places in this file. Are you saying that we should move where the binpath setting is set from wherever it is now to macports.conf? Also, what is @prefix_expended@ variable? I'm not familiar with that. > >As a side note, maybe binpath should not be overwritten, but paths given >in the config should be prepended to the default list. This would make >it much easier to use this feature. But I am unsure if we really want >users to make use of this as it allows third-party dependencies. That's an interesting idea, but I'm not qualified to comment on the merits of it. I know binpath is little used, and we probably want it that way, but I hate not to have it documented nonetheless in the usual places. If prepending the binpath makes it easier to use and developers like the idea, given that we still want to discourage its use, perhaps we could make the warnings against using it even scarier than "advanced users only", and also issue similar stern warnings in the manpage/guide (the same source in the new docs). We're basically trying to solve the conundrum of documenting something we don't want people to use. But I'd like to document binpath on the idea that we don't have features that aren't documented like all other features so as not to cause unneccessary list traffic or user confusion, no matter how infrequent. Mark From raimue at macports.org Tue May 13 10:18:33 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue May 13 10:14:25 2008 Subject: [36127] trunk/base/doc/macports.conf.in In-Reply-To: References: Message-ID: <4829CD69.50301@macports.org> markd@macports.org wrote: >> Just use @prefix_expended@ and @x11prefix@ which will get expanded on >> install. We already use them at other places in this file. > > Are you saying that we should move where the binpath setting is set from > wherever it is now to macports.conf? Also, what is @prefix_expended@ > variable? I'm not familiar with that. Sorry, I typed it wrong. This should have been @prefix_expanded@ with an 'a' instead of an 'e'. This @foo@ notation gets replaced with the real path on ./configure using autoconf. For example see the prefix and x11prefix options in the same file. So binpath could be like this: #binpath @prefix_expanded@/bin:@prefix_expanded@/sbin:/bin:/sbin:/usr/bin:/usr/sbin:@x11prefix@/bin All paths will get replaced automatically. Rainer From markd at macports.org Tue May 13 10:07:10 2008 From: markd at macports.org (markd@macports.org) Date: Tue May 13 10:25:32 2008 Subject: [36127] trunk/base/doc/macports.conf.in Message-ID: >>> Just use @prefix_expended@ and @x11prefix@ which will get expanded on >>> install. We already use them at other places in this file. >> >> Are you saying that we should move where the binpath setting is set from >> wherever it is now to macports.conf? Also, what is @prefix_expended@ >> variable? I'm not familiar with that. > >Sorry, I typed it wrong. This should have been @prefix_expanded@ with an >'a' instead of an 'e'. > >This @foo@ notation gets replaced with the real path on ./configure >using autoconf. For example see the prefix and x11prefix options in the >same file. > >So binpath could be like this: >#binpath >@prefix_expanded@/bin:@prefix_expanded@/sbin:/bin:/sbin:/usr/bin:/usr/sbin:@x11prefix@/bin > >All paths will get replaced automatically. That makes sense. I think I misinterpreted Ryan's comment to be also addressing other (possibly problematic) aspects of the new comments, but I see that I just overlooked that variables should have been used and that is probably all he meant by pointing out they were "hard coded". That was pretty dumb now I see. I'll fix it. Thanks for helping out here, and to Ryan for noticing. Mark From eridius at macports.org Tue May 13 16:45:51 2008 From: eridius at macports.org (Kevin Ballard) Date: Tue May 13 16:41:42 2008 Subject: [MacPorts] #15274: Warning: the following items did not execute (for macfuse): org.macports.build # (cp: invalid option -- X) In-Reply-To: References: <037.bd5092be58c13be7f5587848405e9d4d@macports.org> <046.b91bc5dc8be8803557fb447da72b70d1@macports.org> Message-ID: <185A60A4-05D7-4527-BB13-5049640C2117@macports.org> On May 13, 2008, at 6:43 PM, Charles Darwin wrote: > On May 13, 2008, at 7:31 PM, MacPorts wrote: > >> #15274: Warning: the following items did not execute (for macfuse): >> org.macports.build # (cp: invalid option -- X) >> --------------------------------------- >> +------------------------------------ >> Reporter: macports.users@gmail.com | Owner: eridius@macports.org >> Type: defect | Status: new >> Priority: Normal | Milestone: Port Bugs >> Component: ports | Version: 1.7.0 >> Resolution: | Keywords: >> --------------------------------------- >> +------------------------------------ >> Comment (by eridius@macports.org): >> >> Replying to [comment:3 macports.users@gmail.com]: >> >> I take it you have coreutils+with_default_names installed? That >> would seem >> to be the problem. The only solution I could really do is to change >> cp >> into /bin/cp with a patch. > > I don't know how to do that so I am going to check out the source > code from google and then wait for things to get better. The easiest thing for you would simply be to uninstall coreutils +with_default_names, but I assume you installed that for a reason. -Kevin Ballard -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080513/a13315ac/attachment-0001.html From raimue at macports.org Tue May 13 16:56:58 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue May 13 16:52:49 2008 Subject: [ticket 15264]: need commit & requesting commit privileges In-Reply-To: <0ACF9B04-DB1F-4CA9-A3D9-0CF4779EF948@tampabay.rr.com> References: <0ACF9B04-DB1F-4CA9-A3D9-0CF4779EF948@tampabay.rr.com> Message-ID: <482A2ACA.9000706@macports.org> Adam Schenker wrote: > I'd be grateful if someone could commit this for me. Also, I'd like to > go ahead and request commit privileges so I don't have to keep asking > on the list. I am the maintainer of the above port as well as 4 others. This should go over portmgr's desk for approval. I am CC'ing their list. Rainer From raimue at macports.org Tue May 13 17:04:27 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue May 13 17:00:17 2008 Subject: octave-forge tarball format changed In-Reply-To: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> References: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> Message-ID: <482A2C8B.7050404@macports.org> Andrea D'Amore wrote: > Hello, > octave-forge portfile is pretty outdated, I got latest tarball and > structure has changed, main tarball hasn't a configure script > anymore,now it's only a collection of .tar.gz, each of them with its > own configure script. > > What's the more convenient way to manage this? > > I basically tought of: > a system shell cycle that will extract all tarballs and then perform > configure&install; Works, but will result in a huge scripted Portfile. Each phase needs to be handwritten (fetching, extracting, etc.). > a system shell cycle that will invoke octave "pkg" command to let > octave manage pkg installation, with a -global option so packages will > be available to all users; I don't know about this pkg command from octave. What is its purpose? > an octave cycle that will install each package. I don't know what you mean by this. > A point to be kept in mind is that packages do have dependencies and > I'm not sure pkg command can manage them, I tried to install > optimization using octave in batch mode and it failed, but Tatsuro > Matsuoka from octave-dev has provided me a list that should be > dependecy-safe. What about splitting it up into several ports and make octave-forge depend on all those? This will only work as long as dependencies between these sub-ports can be maintained, otherwise this tends to break... What is the release policy? Do all these parts have the same version number? Do they all get updated at the same time? Things you have to consider when splitting this into smaller ports. Rainer From eridius at macports.org Tue May 13 17:05:12 2008 From: eridius at macports.org (Kevin Ballard) Date: Tue May 13 17:01:02 2008 Subject: [MacPorts] #15274: Warning: the following items did not execute (for macfuse): org.macports.build # (cp: invalid option -- X) In-Reply-To: References: <037.bd5092be58c13be7f5587848405e9d4d@macports.org> <046.b91bc5dc8be8803557fb447da72b70d1@macports.org> <185A60A4-05D7-4527-BB13-5049640C2117@macports.org> Message-ID: <72159CBE-13DA-4232-8035-2D7CCAE48425@macports.org> On May 13, 2008, at 6:51 PM, Charles Darwin wrote: >> The easiest thing for you would simply be to uninstall coreutils >> +with_default_names, but I assume you installed that for a reason. >> >> -Kevin Ballard >> > > That's right. And I am getting the same error when I am building > from the source. > > 07:49:00> sudo ./build_macfuse.sh I would be very surprised if it worked, given that the problem lies in the build scripts in the fusefs.xcodeproj Xcode project file. If you uninstall coreutils+with_default_names you should be able to install macfuse just fine (heck, you could simply deactivate coreutils, install macfuse, then reactivate coreutils if you want). When I push out macfuse 1.5, I'll make sure to patch it to fix this issue, and I'll inform the upstream project about it. -Kevin Ballard -- Kevin Ballard http://kevin.sb.org kevin@sb.org http://www.tildesoft.com From eridius at macports.org Tue May 13 17:41:23 2008 From: eridius at macports.org (Kevin Ballard) Date: Tue May 13 17:37:18 2008 Subject: [MacPorts] #15274: Warning: the following items did not execute (for macfuse): org.macports.build # (cp: invalid option -- X) In-Reply-To: <50095F36-BA19-448F-9A36-A2E0F2A7F7A5@gmail.com> References: <037.bd5092be58c13be7f5587848405e9d4d@macports.org> <046.b91bc5dc8be8803557fb447da72b70d1@macports.org> <185A60A4-05D7-4527-BB13-5049640C2117@macports.org> <72159CBE-13DA-4232-8035-2D7CCAE48425@macports.org> <50095F36-BA19-448F-9A36-A2E0F2A7F7A5@gmail.com> Message-ID: <899B7370-A8AA-49B7-BCCA-880BB9ADE98D@macports.org> On May 13, 2008, at 7:31 PM, Charles Darwin wrote: > On May 13, 2008, at 8:05 PM, Kevin Ballard wrote: > >> On May 13, 2008, at 6:51 PM, Charles Darwin wrote: >> >>>> The easiest thing for you would simply be to uninstall coreutils >>>> +with_default_names, but I assume you installed that for a reason. >>>> >>>> -Kevin Ballard >>>> >>> >>> That's right. And I am getting the same error when I am building >>> from the source. >>> >>> 07:49:00> sudo ./build_macfuse.sh >> >> I would be very surprised if it worked, given that the problem lies >> in the build scripts in the fusefs.xcodeproj Xcode project file. >> >> If you uninstall coreutils+with_default_names you should be able to >> install macfuse just fine (heck, you could simply deactivate >> coreutils, install macfuse, then reactivate coreutils if you want). >> When I push out macfuse 1.5, I'll make sure to patch it to fix this >> issue, and I'll inform the upstream project about it. >> >> -Kevin Ballard > > This guy seems to be the trouble maker: > ~/macfuse/core/10.5/fusefs/build/fusefs.build/Release/All.build/ > Script-54C6DE950B5F7755002D9FD9.sh > Replacing `cp -pRX' with `cp -pR' doesn't help either. Some other > guy is feeding the X ? That script is generated when you run the build. Editing it on-disk doesn't change anything, it's actually stored inside the fusefs.xcodeproj/project.pbxproj file, and you can only safely edit it by opening up fusefs.xcodeproj in Xcode and changing it there. In other words, you have to be familiar with Xcode to edit the script. > I deactivated the coreutils and now macfuse is rolling? Well it just > finished its job; installed with no problem. Glad to hear that. -Kevin Ballard -- Kevin Ballard http://kevin.sb.org kevin@sb.org http://www.tildesoft.com From eridius at macports.org Tue May 13 22:00:08 2008 From: eridius at macports.org (Kevin Ballard) Date: Tue May 13 21:55:59 2008 Subject: [MacPorts] #15274: Warning: the following items did not execute (for macfuse): org.macports.build # (cp: invalid option -- X) In-Reply-To: <50095F36-BA19-448F-9A36-A2E0F2A7F7A5@gmail.com> References: <037.bd5092be58c13be7f5587848405e9d4d@macports.org> <046.b91bc5dc8be8803557fb447da72b70d1@macports.org> <185A60A4-05D7-4527-BB13-5049640C2117@macports.org> <72159CBE-13DA-4232-8035-2D7CCAE48425@macports.org> <50095F36-BA19-448F-9A36-A2E0F2A7F7A5@gmail.com> Message-ID: <971226AF-461C-4B90-81D3-2A7BDB1A6F7A@macports.org> On May 13, 2008, at 7:31 PM, Charles Darwin wrote: > On May 13, 2008, at 8:05 PM, Kevin Ballard wrote: > >> On May 13, 2008, at 6:51 PM, Charles Darwin wrote: >> >>>> The easiest thing for you would simply be to uninstall coreutils >>>> +with_default_names, but I assume you installed that for a reason. >>>> >>>> -Kevin Ballard >>>> >>> >>> That's right. And I am getting the same error when I am building >>> from the source. >>> >>> 07:49:00> sudo ./build_macfuse.sh >> >> I would be very surprised if it worked, given that the problem lies >> in the build scripts in the fusefs.xcodeproj Xcode project file. >> >> If you uninstall coreutils+with_default_names you should be able to >> install macfuse just fine (heck, you could simply deactivate >> coreutils, install macfuse, then reactivate coreutils if you want). >> When I push out macfuse 1.5, I'll make sure to patch it to fix this >> issue, and I'll inform the upstream project about it. >> >> -Kevin Ballard > > This guy seems to be the trouble maker: > ~/macfuse/core/10.5/fusefs/build/fusefs.build/Release/All.build/ > Script-54C6DE950B5F7755002D9FD9.sh > Replacing `cp -pRX' with `cp -pR' doesn't help either. Some other > guy is feeding the X ? > I deactivated the coreutils and now macfuse is rolling? Well it just > finished its job; installed with no problem. I just committed r36749 which bumps the macfuse port to 1.5 and includes a patch that should fix your problem. Within 12 hours the PortIndex should be rebuilt and you should be able to `port sync` to get the changes and install. -Kevin Ballard -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com From wsiegrist at apple.com Tue May 13 22:42:21 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue May 13 22:38:15 2008 Subject: [36748] distfiles/macfuse/macfuse-1.5.tar.bz2 In-Reply-To: <20080514045443.D25A0168C94E@beta.macosforge.org> References: <20080514045443.D25A0168C94E@beta.macosforge.org> Message-ID: <50F18EBA-8C34-4701-BF71-4ED15471AADF@apple.com> On May 13, 2008, at 9:54 PM, eridius@macports.org wrote: > Revision36748Authoreridius@macports.orgDate2008-05-13 21:54:21 -0700 > (Tue, 13 May 2008)Log Message > Add dump for MacFUSE 1.5 > Added Paths > ? distfiles/macfuse/macfuse-1.5.tar.bz2 > Diff > Added: distfiles/macfuse/macfuse-1.5.tar.bz2 (0 => 36748) > Not sure if it really matters, but looks like git-svn didnt set the mime type again. -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/20080513/b2ef739d/smime.bin From eridius at macports.org Tue May 13 22:43:49 2008 From: eridius at macports.org (Kevin Ballard) Date: Tue May 13 22:39:45 2008 Subject: [36748] distfiles/macfuse/macfuse-1.5.tar.bz2 In-Reply-To: <50F18EBA-8C34-4701-BF71-4ED15471AADF@apple.com> References: <20080514045443.D25A0168C94E@beta.macosforge.org> <50F18EBA-8C34-4701-BF71-4ED15471AADF@apple.com> Message-ID: <22D252DB-7783-4407-AC28-4B834A16ABF3@macports.org> On May 14, 2008, at 12:42 AM, William Siegrist wrote: > On May 13, 2008, at 9:54 PM, eridius@macports.org wrote: > >> Revision36748Authoreridius@macports.orgDate2008-05-13 21:54:21 >> -0700 (Tue, 13 May 2008)Log Message >> Add dump for MacFUSE 1.5 >> Added Paths >> ? distfiles/macfuse/macfuse-1.5.tar.bz2 >> Diff >> Added: distfiles/macfuse/macfuse-1.5.tar.bz2 (0 => 36748) >> > > Not sure if it really matters, but looks like git-svn didnt set the > mime type again. Yeah, I looked into fixing that but git-svn is a messy perl script. I haven't a clue where to begin. I should probably contact the author of the script and ask him to look into it. -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080514/9be7d5fb/attachment-0001.html From andrea.damore at macports.org Tue May 13 23:08:20 2008 From: andrea.damore at macports.org (Andrea D'Amore) Date: Tue May 13 23:04:13 2008 Subject: octave-forge tarball format changed In-Reply-To: <482A2C8B.7050404@macports.org> References: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> <482A2C8B.7050404@macports.org> Message-ID: <62E8503E-B14C-4AB6-A9BB-9AD62F9C1FD9@macports.org> On 14/mag/08, at 02:04, Rainer M?ller wrote: > Works, but will result in a huge scripted Portfile. Each phase needs > to be handwritten (fetching, extracting, etc.). Indeed > I don't know about this pkg command from octave. What is its purpose? To manage octave-forge packages, it is basically an octave interface to configure&&make&&make install and it is called as interal command > I don't know what you mean by this. Same thing of first point but using octave statements to loop into packages rather than system shell. > What about splitting it up into several ports and make octave-forge > depend on all those? This will only work as long as dependencies > between these sub-ports can be maintained, otherwise this tends to > break... I had a look to debian octave packages and they have switched to single package modules too (maybe accordingly to change in single octave-forge package), this has the obvious advantage of semplicity and dependency control. I think we should have this approach. > What is the release policy? Do all these parts have the same version > number? Do they all get updated at the same time? Things you have to > consider when splitting this into smaller ports. They have separate versions and each one get updated when needed (a bug patch for example) > Rainer Andrea From ryandesign at macports.org Wed May 14 02:39:26 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed May 14 02:35:15 2008 Subject: [36735] trunk/base/src/macports1.0/macports.tcl In-Reply-To: <20080513134324.4A6051685CDC@beta.macosforge.org> References: <20080513134324.4A6051685CDC@beta.macosforge.org> Message-ID: On May 13, 2008, at 8:43 AM, jmr@macports.org wrote: > Revision: 36735 > http://trac.macosforge.org/projects/macports/changeset/36735 > Author: jmr@macports.org > Date: 2008-05-13 06:43:23 -0700 (Tue, 13 May 2008) > > Log Message: > ----------- > In image mode, don't count dependencies as being satisfied when the > satisfying > port is not active. Fix for #7361. Man, you are just kicking ass with these old annoying issues, aren't you? Thanks so much! From n.oxyde at gmail.com Wed May 14 08:42:22 2008 From: n.oxyde at gmail.com (nox) Date: Wed May 14 08:38:13 2008 Subject: [36765] trunk/base/src/port1.0/portutil.tcl In-Reply-To: <20080514093622.18DEA168D924@beta.macosforge.org> References: <20080514093622.18DEA168D924@beta.macosforge.org> Message-ID: Le 14 mai 08 ? 11:36, ryandesign@macports.org a ?crit : > Revision 36765 > proc add_default_universal_variant {args} { > - # Declare default universal variant, on >10.3 > + # Declare default universal variant if universal SDK is installed > variant universal description {Build for multiple > architectures} { > if {![file exists ${configure.universal_sysroot}]} { > return -code error "Universal SDK is not installed (are > we running on 10.3? did you forget to install it?) and building with > +universal will very likely fail" By the way, the check for SDK should be in a pre-fetch block, shouldn't it? From eridius at macports.org Wed May 14 09:41:19 2008 From: eridius at macports.org (Kevin Ballard) Date: Wed May 14 09:37:18 2008 Subject: [MacPorts] #15274: Warning: the following items did not execute (for macfuse): org.macports.build # (cp: invalid option -- X) In-Reply-To: <1B378F0E-2B0F-4941-9EC8-FEB252150DF9@gmail.com> References: <037.bd5092be58c13be7f5587848405e9d4d@macports.org> <046.b91bc5dc8be8803557fb447da72b70d1@macports.org> <185A60A4-05D7-4527-BB13-5049640C2117@macports.org> <72159CBE-13DA-4232-8035-2D7CCAE48425@macports.org> <50095F36-BA19-448F-9A36-A2E0F2A7F7A5@gmail.com> <971226AF-461C-4B90-81D3-2A7BDB1A6F7A@macports.org> <1B378F0E-2B0F-4941-9EC8-FEB252150DF9@gmail.com> Message-ID: <46EB083C-E17B-474F-8FC6-EF845F854D0F@macports.org> On May 14, 2008, at 6:47 AM, Charles Darwin wrote: > I got this: > > DEBUG: Executing destroot_finish > ---> Compressing man pages for readline > DEBUG: Scanning man3 > man3/history.3: 66.1% -- replaced with man3/history.3.gz > man3/history.3.gz: changing permissions from 00644 to 00444 > man3/readline.3: 67.7% -- replaced with man3/readline.3.gz > man3/readline.3.gz: changing permissions from 00644 to 00444 > DEBUG: checking for mtree violations > DEBUG: Uninstalling readline 5.2.007_0+darwin_9 > DEBUG: bash depends on this port > ---> Unable to uninstall readline 5.2.007_0+darwin_9, the following > ports depend on it: > ---> bash > DEBUG: Please uninstall the ports that depend on readline first. > while executing > "portuninstall::uninstall $portname ${version_installed}_ > $revision_installed$oldvariant $optionslist" > Error: Uninstall readline 5.2.007_0+darwin_9 failed: Please > uninstall the ports that depend on readline first. > > So I force installed and got through. > > sudo port -sdRnuf upgrade outdated > > It reinstalled/updated? the bash too. Well yes, you told it to upgrade all outdated ports. This is not relevant to macfuse at all. If you wanted to update macfuse you should have just said `sudo port -unf upgrade macfuse`. -Kevin Ballard -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com From db.evans at gmail.com Wed May 14 15:01:52 2008 From: db.evans at gmail.com (David Evans) Date: Wed May 14 14:57:40 2008 Subject: Commit tickets #15040 #15291 Message-ID: <482B6150.8090509@gmail.com> I'd be grateful if someone would commit the following tickets for me: https://trac.macports.org/ticket/15040 Upgrade glade 2.12.1 -> 2.12.2 https://trac.macports.org/ticket/15291 Upgrade glade3 3.4.3 ->3.4.5 Note that previously submitted ticket https://trac.macports.org/ticket/15039 which has not as yet been acted upon is now superseded by #15291 and should be closed out without any further action. Thanks for your help Dave From alakazam at melix.net Wed May 14 16:36:50 2008 From: alakazam at melix.net (Alakazam) Date: Wed May 14 16:32:37 2008 Subject: octave-forge tarball format changed In-Reply-To: <62E8503E-B14C-4AB6-A9BB-9AD62F9C1FD9@macports.org> References: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> <482A2C8B.7050404@macports.org> <62E8503E-B14C-4AB6-A9BB-9AD62F9C1FD9@macports.org> Message-ID: Hi, On 14 mai 08, at 08:08, Andrea D'Amore wrote: >> What about splitting it up into several ports and make octave-forge >> depend on all those? This will only work as long as dependencies >> between these sub-ports can be maintained, otherwise this tends to >> break... > > I had a look to debian octave packages and they have switched to > single package modules too (maybe accordingly to change in single > octave-forge package), this has the obvious advantage of semplicity > and dependency control. I think we should have this approach. I think this might be the best approach. I have tried compiling and installing several octave-forge packages recently, and the success rate is quite random ; this means having one big monolithic port might be inadequate and very difficult to maintain. Maintaining many separate Portfiles may be more complicated to manage, but will ensure that more octave-forge modules have better availability (instead of all of them being broken because of one module on one configuration for instance), and will make it easier for users to only install modules that they use. Would it be possible to have an octave PortGroup ? That would make it easier to maintain several octave-forge modules in separate portfiles, I think. Regards, -- Olivier Le Floch AKA Alakazam alakazam@melix.net / olivier@le-floch.fr / http://olivier.le-floch.fr/ From raimue at macports.org Wed May 14 17:16:52 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed May 14 17:12:40 2008 Subject: Commit tickets #15040 #15291 In-Reply-To: <482B6150.8090509@gmail.com> References: <482B6150.8090509@gmail.com> Message-ID: <482B80F4.4070403@macports.org> David Evans wrote: > https://trac.macports.org/ticket/15040 Upgrade glade 2.12.1 -> 2.12.2 Committed in r36799. > https://trac.macports.org/ticket/15291 Upgrade glade3 3.4.3 ->3.4.5 Committed in r36798. > > Note that previously submitted ticket > > https://trac.macports.org/ticket/15039 > > which has not as yet been acted upon is now superseded by #15291 and > should be closed out without any further action. Closed. By the way, why is glade in category gnome, but glade3 in category devel? Shouldn't we move them into the same category? Rainer From raimue at macports.org Wed May 14 17:19:25 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed May 14 17:15:10 2008 Subject: octave-forge tarball format changed In-Reply-To: References: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> <482A2C8B.7050404@macports.org> <62E8503E-B14C-4AB6-A9BB-9AD62F9C1FD9@macports.org> Message-ID: <482B818D.60608@macports.org> Alakazam wrote: > Would it be possible to have an octave PortGroup ? That would make it > easier to maintain several octave-forge modules in separate portfiles, > I think. Yes, in theory. But until we resolve #14553 [1], port groups can only be shipped with new releases (and releases seem to be rare at the moment). Rainer [1] http://trac.macports.org/ticket/14553 From raimue at macports.org Wed May 14 17:38:34 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 15 May 2008 02:38:34 +0200 Subject: [36765] trunk/base/src/port1.0/portutil.tcl In-Reply-To: References: <20080514093622.18DEA168D924@beta.macosforge.org> Message-ID: <482B860A.1000006@macports.org> nox wrote: > Le 14 mai 08 ? 11:36, ryandesign at macports.org a ?crit : > >> Revision 36765 >> proc add_default_universal_variant {args} { >> - # Declare default universal variant, on >10.3 >> + # Declare default universal variant if universal SDK is installed >> variant universal description {Build for multiple >> architectures} { >> if {![file exists ${configure.universal_sysroot}]} { >> return -code error "Universal SDK is not installed (are >> we running on 10.3? did you forget to install it?) and building with >> +universal will very likely fail" > > By the way, the check for SDK should be in a pre-fetch block, > shouldn't it? It should be in a pre-fetch block. I think with this implementation commands like 'port info +universal' will fail on 10.3 or if the Universal SDK is missing. I added the pre-fetch block in r36800. Rainer From db.evans at gmail.com Wed May 14 17:32:30 2008 From: db.evans at gmail.com (David Evans) Date: Wed, 14 May 2008 17:32:30 -0700 Subject: Commit tickets #15040 #15291 In-Reply-To: <482B80F4.4070403@macports.org> References: <482B6150.8090509@gmail.com> <482B80F4.4070403@macports.org> Message-ID: <482B849E.7030907@gmail.com> Rainer M?ller wrote: > David Evans wrote: >> https://trac.macports.org/ticket/15040 Upgrade glade 2.12.1 -> 2.12.2 > > Committed in r36799. > >> https://trac.macports.org/ticket/15291 Upgrade glade3 3.4.3 ->3.4.5 > > Committed in r36798. Thanks, Rainer > >> >> Note that previously submitted ticket >> >> https://trac.macports.org/ticket/15039 >> >> which has not as yet been acted upon is now superseded by #15291 and >> should be closed out without any further action. > > Closed. > > By the way, why is glade in category gnome, but glade3 in category > devel? Shouldn't we move them into the same category? > > Rainer > This is the way I found them but I agree with you. My personal preference would be devel since the application supports GTK+ and optionally GNOME development and development seems to be moving in the direction of more GTK and less GNOME. What do others think? By the way, I'm also on the fence about retaining glade (version 2) as a port at all since glade3 is the active development, glade3 files are NOT necessarily backwards compatible and the main feature of version 2 not available in version 3, that of automatically generating code, is deprecated in favor of using libglade or GtkBuildable. Again open to input. Dave From raimue at macports.org Wed May 14 19:13:28 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 15 May 2008 04:13:28 +0200 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> <48245572.6080805@macports.org> Message-ID: <482B9C48.5030402@macports.org> Ronald Oussoren wrote: > 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. Currently the python24 port is build as framework, while python25 is installed without the framework option. As the framework has some benefits (especially GUI related, the pythonw command), we would like to switch all python builds to frameworks. But I don't think there would be any change in the python distribution helpful to achieve this. The issues we currently face lie inside MacPorts itself. Rainer From raimue at macports.org Wed May 14 20:33:51 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 15 May 2008 05:33:51 +0200 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: <482BAF1F.9010705@macports.org> Rainer M?ller wrote: > 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. So today I had time to play with the python25 port group a little bit. I thought we could just change --prefix=${prefix} to --prefix=${prefix}/Library/Frameworks/Python.framework/Versions/2.5/ in order to achieve py25-* modules to get installed into the framework. But it turned out that this will cause more problems than we gain. There are other ports around using the python25 port group which are not modules for python25, e.g. mercurial. So with this change, the hg binary will land at ${prefix}/Library/Frameworks/Python.framework/Versions/2.5/bin/hg which is absolutely not what we want. So, currently, I don't know a better solution than to stick with --prefix=${prefix}. The setup.py script does not seem allow to specify seperate lib or header directories and doing that manually in a custom post-destroot just adds unecessary complexity in my opinion. Thomas, I don't know if you are around and reading this mail, but what is your opinion on this? But after all, this means that we have yet again to change the direction of the symlinks. I wanted to avoid spreading the different files all over ${prefix} and have them all at one place in the framework, so the symlinks would always go from the "usual" place to the framework. Well, now it turned out that this does not work as expected, because apparently we never thought of non-modules and how they would get installed while planning the transition. Okay, so we have the option to install the files at their "usual" location (like ${prefix}/lib/python2.5/ and ${prefix}/include/python2.5/ instead of somewhere in the framework). This also means the direction of the symlinks changes, so they are now created inside the framework pointing to the "usual" location (as shown below). These symlinks are necessary to avoid spreading files over multiple locations which should be at the same place (e.g. some files in the framework, some files at the "usual" place). The current python24 is patched (patch-Lib-site.py) to also look at the "usual" place for modules, but I think a symlink will also work and avoid splitting of files over these locations. New symlinks would be like this (not exactly, you get the idea): set ${framewdir} ${prefix}/Library/Frameworks/Python.framework ${framewdir}/Python.framework/Versions/2.5/lib/python2.5 -> ${prefix}/lib/python2.5 ${framewdir}/Python.framework/Versions/2.5/lib/libpython*.dylib -> ${prefix}/lib/libpython*.dylib ${framewdir}/Python.framework/Versions/2.5/include/python2.5 -> ${prefix}/include/python2.5 ${framewdir}/Python.framework/Versions/2.5/bin/$foo -> ${prefix}/bin/$foo Maybe then we don't need a change to the python port groups at all and upgrading existing pyXX-* ports may be easier. Let's see, I did not yet investigate that... I will update the PythonFrameworkTransition wiki page later, when I got together a more solid plan. Rainer From reiffert at macports.org Wed May 14 22:54:11 2008 From: reiffert at macports.org (Thomas Reifferscheid) Date: Thu, 15 May 2008 07:54:11 +0200 Subject: Where are we with simultaneous Python Framework installs In-Reply-To: <482BAF1F.9010705@macports.org> References: <4821E146.5000405@orcaware.com> <4821E7D3.6030709@macports.org> <482BAF1F.9010705@macports.org> Message-ID: <482BD003.3090206@macports.org> Rainer M?ller wrote: [...] > But it turned out that this will cause more problems than we gain. > > There are other ports around using the python25 port group which are > not modules for python25, e.g. mercurial. So with this change, the hg > binary will land at > ${prefix}/Library/Frameworks/Python.framework/Versions/2.5/bin/hg > which is absolutely not what we want. [...] > ${framewdir}/Python.framework/Versions/2.5/bin/$foo > -> ${prefix}/bin/$foo > Dear Rainer, I do not understand the "..is absolutely not what we want"-part of your e-mail. Regarding the symlink you posted, the binary in your example will appear as $prefix/bin/hg. Why is that considered "bad" or "no go"? Regarding my time: University got my attention for the next 24 months, finishing it off. Kind regards Thomas From raimue at macports.org Thu May 15 06:08:15 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 15 May 2008 15:08:15 +0200 Subject: Where are we with simultaneous Python Framework installs In-Reply-To: <482BD003.3090206@macports.org> References: <4821E146.5000405@orcaware.com> <4821E7D3.6030709@macports.org> <482BAF1F.9010705@macports.org> <482BD003.3090206@macports.org> Message-ID: <482C35BF.3090408@macports.org> Thomas Reifferscheid wrote: > I do not understand the "..is absolutely not what we want"-part of your > e-mail. > Regarding the symlink you posted, the binary in your example will appear > as $prefix/bin/hg. Why is that considered "bad" or "no go"? According to our plans in the wiki we decided to do the symlinks in the direction "usual" place -> framework. But what you see there is the new plan because the old one does not work. Sorry if I was a bit unclear. > Regarding my time: University got my attention for the next 24 months, > finishing it off. Have a good time and do it well! Rainer From raimue at macports.org Thu May 15 06:56:33 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Thu, 15 May 2008 15:56:33 +0200 Subject: [36811] trunk/dports/net In-Reply-To: <20080515092710.01E6916981E7@beta.macosforge.org> References: <20080515092710.01E6916981E7@beta.macosforge.org> Message-ID: <482C4111.7070808@macports.org> rhwood at macports.org wrote: > Revision: 36811 > http://trac.macosforge.org/projects/macports/changeset/36811 > Author: rhwood at macports.org > Date: 2008-05-15 02:27:07 -0700 (Thu, 15 May 2008) > > Log Message: > ----------- > Put all glade libraries into the same category. > > Added Paths: > ----------- > trunk/dports/net/glade/ > trunk/dports/net/glademm/ > > Copied: trunk/dports/net/glade (from rev 36810, trunk/dports/gnome/glade) > > Copied: trunk/dports/net/glademm (from rev 36810, trunk/dports/gnome/glademm) I think this should have gone to devel instead of net? Also, the categories in the Portfile should be changed to reflect the move (the first category should be the same as the location). Rainer From raimue at macports.org Thu May 15 07:18:58 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 15 May 2008 16:18:58 +0200 Subject: Alternative system for conflicting files In-Reply-To: <4821E3D8.5090309@orcaware.com> References: <4821E3D8.5090309@orcaware.com> Message-ID: <482C4652.1030809@macports.org> Blair Zajac wrote: > MacPorts needs a alternative system so that multiple ports can be installed that > provide the same file. Because nobody else commented on this, I just want to send a short mail to show that I agree with you. > 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. I never understood why there is an extra level of symlinks. Why is the symlink not directly /usr/bin/java -> /usr/lib/.../jre/bin/java? Is there any benefit from using /etc/alternatives? I can only think of backup purposes where you only save /etc, but as long as the current selection is saved in /etc and can be re-applied, this extra level should not be necessary. > 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. I fully agree with you. gcc_select and python_select have been more workarounds until we get a proper implementation. Well, interim solutions often last the longest :-) It would be good to have a way in the Portfile to register (a set of) files as alternatives for a select group. Then a port select command could make symlinks (as gcc_select and python_select currently do). Of course if there is only one alternative installed for a select group it should be automatically selected. Debian's update-alternatives also allows you to register your own files for specific groups which is a nice feature but might be dangerous for us. At the moment we try to avoid the use of external dependencies because they cause a lot of problems and make it hard to debug things (for example people often request to use the python provided by Mac OS X itself, but it might be an older version, being patched, have another feature set, behave differently etc.). But to make such a system fully usable, a better dependency engine would also be needed. So one can specify a dependency on python>=2.4 and any port of python{24,25,26,30} will satisfy this dependency. Rainer From db.evans at gmail.com Thu May 15 08:32:07 2008 From: db.evans at gmail.com (David Evans) Date: Thu, 15 May 2008 08:32:07 -0700 Subject: [36812] trunk/dports/devel In-Reply-To: <20080515092933.4CC541698210@beta.macosforge.org> References: <20080515092933.4CC541698210@beta.macosforge.org> Message-ID: <482C5777.4020008@gmail.com> rhwood at macports.org wrote: > Revision > 36812 > Author > rhwood at macports.org > Date > 2008-05-15 02:29:32 -0700 (Thu, 15 May 2008) > > > Log Message > > Fix pre-caffine mistake from r36811 and put these ports in the correct category > > > Added Paths > > * trunk/dports/devel/glade/ > * trunk/dports/devel/glademm/ > > > Diff > > > Copied: trunk/dports/devel/glade (from rev 36811, > trunk/dports/net/glade) > > > Copied: trunk/dports/devel/glademm (from rev 36811, > trunk/dports/net/glademm) > > > ------------------------------------------------------------------------ > > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes After this change there are redundant copies of glade in gnome and net and glademm in net. Also how about libglade2 and libglademm which are still in gnome? Finally, are glademm and libglademm different versions of the same port? Looks like libglademm is more current. If they are the same, do we need both? Dave From macports-mgr at lists.macosforge.org Thu May 15 16:56:36 2008 From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org) Date: Thu, 15 May 2008 16:56:36 -0700 (PDT) Subject: PortIndex2MySQL run failure on Thursday 2008-05-15 at 16:15:00 Message-ID: <20080515235636.C73704B218C@localhost> Synchronizing from file:///Volumes/data/macports/macports/dports U /Volumes/data/macports/macports/dports/games/gnushogi/Portfile U /Volumes/data/macports/macports/dports/games/jnethack/Portfile U /Volumes/data/macports/macports/dports/devel/libdatrie/Portfile U /Volumes/data/macports/macports/dports/devel/darts/Portfile U /Volumes/data/macports/macports/dports/sysutils/FDclone/Portfile U /Volumes/data/macports/macports/dports/textproc/chasen/Portfile U /Volumes/data/macports/macports/dports/textproc/libthai/Portfile U /Volumes/data/macports/macports/dports/textproc/nkf/Portfile U /Volumes/data/macports/macports/dports/textproc/canna/Portfile A /Volumes/data/macports/macports/dports/textproc/hunspell/files A /Volumes/data/macports/macports/dports/textproc/hunspell/files/patch-hunspell.cxx.diff U /Volumes/data/macports/macports/dports/textproc/hunspell/Portfile U /Volumes/data/macports/macports/dports/textproc/lv/Portfile U /Volumes/data/macports/macports/dports/textproc/kakasi/Portfile A /Volumes/data/macports/macports/dports/textproc/hunspell-dict-de_DE A /Volumes/data/macports/macports/dports/textproc/hunspell-dict-de_DE/Portfile U /Volumes/data/macports/macports/dports/textproc/wv2/Portfile A /Volumes/data/macports/macports/dports/textproc/hunspell-dict-en_US A /Volumes/data/macports/macports/dports/textproc/hunspell-dict-en_US/Portfile U /Volumes/data/macports/macports/dports/textproc/cocot/Portfile U /Volumes/data/macports/macports/dports/PortIndex U /Volumes/data/macports/macports/dports/lang/gcc44/Portfile U /Volumes/data/macports/macports/dports/print/scribus/Portfile U /Volumes/data/macports/macports/dports/print/lcdf-typetools/Portfile U /Volumes/data/macports/macports/dports/print/ghostscript/Portfile U /Volumes/data/macports/macports/dports/graphics/fontforge/Portfile U /Volumes/data/macports/macports/dports/tex/makejvf/Portfile U /Volumes/data/macports/macports/dports/perl/p5-datemanip/Portfile U /Volumes/data/macports/macports/dports/science/nco/files/patch-src_nco++_Makefile.in.diff U /Volumes/data/macports/macports/dports/science/nco/Portfile U /Volumes/data/macports/macports/dports/x11/gtk-engines2/Portfile U /Volumes/data/macports/macports/dports/x11/kinput2-macim/Portfile U /Volumes/data/macports/macports/dports/x11/kinput2/Portfile Fetching external item into '/Volumes/data/macports/macports/dports/sysutils/MacPorts/files' Updated external to revision 36824. Updated to revision 36824. Error: CHILDSTATUS 29993 1: ERROR 1062 (23000) at line 8548: Duplicate entry 'glade' for key 1 From blb at macports.org Fri May 16 01:44:09 2008 From: blb at macports.org (Bryan Blackburn) Date: Fri, 16 May 2008 02:44:09 -0600 Subject: port doesn't exit with proper return value Message-ID: In base/src/port/port.tcl (what becomes ${prefix}/bin/port), proc process_cmd returns $action_status which eventually becomes $exit_status (and hence port's return value). However, it appears this is always reset to 0 because of the part: # If we're not in exit mode then ignore the status from the command if { ![macports::ui_isset ports_exit] } { set action_status 0 } At the end of port.tcl (line 2869 as of svn right now) is: if {![info exists ui_options(ports_commandfiles)]} { set ui_options(ports_exit) yes } So ports_exit should be set to yes, but that macports::ui_isset doesn't seem to be noticing it. Are there issues with ui_options and macports::ui_isset that's causing this? Changing the bit in process_cmd to: # If we're not in exit mode then ignore the status from the command if { ![info exists ui_options(ports_exit)] } { set action_status 0 } makes it work as it should. Bryan From macports-mgr at lists.macosforge.org Fri May 16 05:37:36 2008 From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org) Date: Fri, 16 May 2008 05:37:36 -0700 (PDT) Subject: PortIndex2MySQL run failure on Friday 2008-05-16 at 04:15:00 Message-ID: <20080516123736.E80E74BA4B0@localhost> Synchronizing from file:///Volumes/data/macports/macports/dports U /Volumes/data/macports/macports/dports/archivers/gnutar/Portfile A /Volumes/data/macports/macports/dports/devel/lua-expat A /Volumes/data/macports/macports/dports/devel/lua-expat/files A /Volumes/data/macports/macports/dports/devel/lua-expat/files/patch-luaexpat.diff A /Volumes/data/macports/macports/dports/devel/lua-expat/Portfile U /Volumes/data/macports/macports/dports/devel/eventlog/Portfile U /Volumes/data/macports/macports/dports/sysutils/syslog-ng/Portfile U /Volumes/data/macports/macports/dports/PortIndex D /Volumes/data/macports/macports/dports/net/glademm D /Volumes/data/macports/macports/dports/net/glade U /Volumes/data/macports/macports/dports/net/tcpdump/Portfile U /Volumes/data/macports/macports/dports/aqua/qt4-mac/Portfile U /Volumes/data/macports/macports/dports/databases/oracle-instantclient/Portfile D /Volumes/data/macports/macports/dports/gnome/glademm D /Volumes/data/macports/macports/dports/gnome/glade Fetching external item into '/Volumes/data/macports/macports/dports/sysutils/MacPorts/files' Updated external to revision 36837. Updated to revision 36835. Error: CHILDSTATUS 8683 1: ERROR 1062 (23000) at line 8555: Duplicate entry 'glade' for key 1 From jmr at macports.org Fri May 16 05:46:33 2008 From: jmr at macports.org (Joshua Root) Date: Fri, 16 May 2008 22:46:33 +1000 Subject: port doesn't exit with proper return value Message-ID: <482D8229.8030008@macports.org> Port's normal mode of operation is to run as many of the requested commands as possible and not exit when a command fails. It does this by suppressing the error status from the commands. This is certainly incorrect when there's only one command run and it fails, but it's less clear what should happen when some of the requested commands succeed. You can make the first failed command cause port to exit, with the appropriate return code, by using the -x option on the command line. Related tickets: http://trac.macports.org/ticket/13918 http://trac.macports.org/ticket/14928 - Josh From macports-mgr at lists.macosforge.org Fri May 16 08:25:04 2008 From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org) Date: Fri, 16 May 2008 08:25:04 -0700 (PDT) Subject: PortIndex2MySQL run failure on Friday 2008-05-16 at 07:56:34 Message-ID: <20080516152504.D59824BC667@localhost> Synchronizing from file:///Volumes/data/macports/macports/dports U /Volumes/data/macports/macports/dports/devel/cmake/Portfile U /Volumes/data/macports/macports/dports/devel/glademm/Portfile U /Volumes/data/macports/macports/dports/devel/glade/Portfile Fetching external item into '/Volumes/data/macports/macports/dports/sysutils/MacPorts/files' Updated external to revision 36839. Updated to revision 36839. Error: CHILDSTATUS 18681 1: ERROR 1062 (23000) at line 8555: Duplicate entry 'glade' for key 1 From macports-mgr at lists.macosforge.org Fri May 16 13:08:13 2008 From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org) Date: Fri, 16 May 2008 13:08:13 -0700 (PDT) Subject: PortIndex2MySQL run failure on Friday 2008-05-16 at 12:45:02 Message-ID: <20080516200813.A26BE4BFEA9@localhost> Synchronizing from file:///Volumes/data/macports/macports/dports U /Volumes/data/macports/macports/dports/ruby/rb-mysql/Portfile U /Volumes/data/macports/macports/dports/devel/atk/Portfile U /Volumes/data/macports/macports/dports/devel/libsdl_ttf/Portfile A /Volumes/data/macports/macports/dports/devel/luarocks A /Volumes/data/macports/macports/dports/devel/luarocks/Portfile U /Volumes/data/macports/macports/dports/PortIndex U /Volumes/data/macports/macports/dports/databases/db46/Portfile U /Volumes/data/macports/macports/dports/x11/gtk-engines2/Portfile U /Volumes/data/macports/macports/dports/x11/xrender/Portfile Fetching external item into '/Volumes/data/macports/macports/dports/sysutils/MacPorts/files' Updated external to revision 36849. Updated to revision 36849. Error: CHILDSTATUS 6309 1: ERROR 1062 (23000) at line 33955: Duplicate entry 'hunspell-dict-en_US' for key 1 From markd at macports.org Fri May 16 15:12:01 2008 From: markd at macports.org (markd at macports.org) Date: Fri, 16 May 2008 15:12:01 -0700 Subject: arbitration of multiple master_sites Message-ID: > master_sites lists ..... >has a lower ping for the reporter, hence it was used. I always assumed that the master_sites were tried in order. I'd like to document the true behavior in the guide. So it does a ping test of all master_sites and uses the one with the fastest ping response? Mark From wsiegrist at apple.com Fri May 16 15:21:07 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 16 May 2008 15:21:07 -0700 Subject: arbitration of multiple master_sites In-Reply-To: References: Message-ID: On May 16, 2008, at 3:12 PM, markd at macports.org wrote: >> master_sites lists > ..... >> has a lower ping for the reporter, hence it was used. > > I always assumed that the master_sites were tried in order. I'd like > to > document the true behavior in the guide. So it does a ping test of > all > master_sites and uses the one with the fastest ping response? > Its a recent feature by jmr: http://trac.macports.org/ticket/14891 http://trac.macports.org/changeset/35748 -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/20080516/caf56d07/attachment-0001.p7s From markd at macports.org Fri May 16 21:06:56 2008 From: markd at macports.org (markd at macports.org) Date: Fri, 16 May 2008 21:06:56 -0700 Subject: arbitration of multiple master_sites Message-ID: >> I always assumed that the master_sites were tried in order. I'd like >> to >> document the true behavior in the guide. So it does a ping test of >> all >> master_sites and uses the one with the fastest ping response? >> > >Its a recent feature by jmr: > >http://trac.macports.org/ticket/14891 > >http://trac.macports.org/changeset/35748 Thanks, Bill. Question for jmr at . Is this an accurate description of the fetch behavior now? -Ping the list of master_sites and sort them based on ping response times -Sourceforge, gnu, etc., special mirrors go after sorted url list -MacPorts fallback mirrors at the end Also, how many mirror types do we have defined? Sourceforge, gnu, and what else? Mark From ryandesign at macports.org Fri May 16 21:40:57 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 16 May 2008 23:40:57 -0500 Subject: [36851] trunk/dports/devel/class-dump/Portfile In-Reply-To: <20080516205408.F1A01169E7F4@beta.macosforge.org> References: <20080516205408.F1A01169E7F4@beta.macosforge.org> Message-ID: <3C34EC1A-BF47-43A4-9B20-192E44CC55B5@macports.org> You can't do this until the next version of MacPorts is released. MacPorts 1.6.0 does not have that variable. $ port install class-dump +universal Error: Error executing universal: can't read "configure.universal_archs": no such variable Error: Unable to open port: Error evaluating variants $ On May 16, 2008, at 3:54 PM, waqar at macports.org wrote: > Revision: 36851 > http://trac.macosforge.org/projects/macports/changeset/36851 > Author: waqar at macports.org > Date: 2008-05-16 13:54:08 -0700 (Fri, 16 May 2008) > > Log Message: > ----------- > Added patch for universal binary. > > Modified Paths: > -------------- > trunk/dports/devel/class-dump/Portfile > > Modified: trunk/dports/devel/class-dump/Portfile > =================================================================== > --- trunk/dports/devel/class-dump/Portfile 2008-05-16 20:26:07 UTC > (rev 36850) > +++ trunk/dports/devel/class-dump/Portfile 2008-05-16 20:54:08 UTC > (rev 36851) > @@ -5,7 +5,7 @@ > > name class-dump > version 3.1.2 > -revision 1 > +revision 2 > categories devel > maintainers waqar at macports.org > description Utility for examining the Objective-C segment of Mach- > O files. > @@ -29,8 +29,8 @@ > xcode.destroot.path ${prefix}/bin > > variant universal { > - xcode.build.settings ARCHS="i386 ppc" > - xcode.destroot.settings ARCHS="i386 ppc" > + set xcode.build.settings ARCHS="${configure.universal_archs}" > + set xcode.destroot.settings ARCHS="${configure.universal_archs}" > } > > livecheck.check regex From ryandesign at macports.org Fri May 16 21:47:42 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 16 May 2008 23:47:42 -0500 Subject: [36832] trunk/dports/archivers/gnutar/Portfile In-Reply-To: <20080516075528.C9C76169CA86@beta.macosforge.org> References: <20080516075528.C9C76169CA86@beta.macosforge.org> Message-ID: <0F656FEC-E3C5-4DE3-9FF1-99DEB24C530F@macports.org> On May 16, 2008, at 2:55 AM, mww at macports.org wrote: > version 1.20 with workaround for broken gcc-4.0 on 10.5: beta gcc > 4.2 needs to be installed :/ > +platform darwin 9 { > + # gcc 4.0 fails to compile gnutar on 10.5 (probably will get > fixed with XCode 3.1) > + configure.compiler gcc-4.2 > +} Don't you also need to add "depends_lib port:gcc42" in the "platform darwin 9" section then, since MacPorts doesn't automatically add the compiler dependency? From ryandesign at macports.org Fri May 16 22:27:23 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 17 May 2008 00:27:23 -0500 Subject: port doesn't exit with proper return value In-Reply-To: <482D8229.8030008@macports.org> References: <482D8229.8030008@macports.org> Message-ID: On May 16, 2008, at 7:46 AM, Joshua Root wrote: > Port's normal mode of operation is to run as many of the requested > commands as possible and not exit when a command fails. It does > this by > suppressing the error status from the commands. This is certainly > incorrect when there's only one command run and it fails, but it's > less > clear what should happen when some of the requested commands succeed. > > You can make the first failed command cause port to exit, with the > appropriate return code, by using the -x option on the command line. > > Related tickets: > > http://trac.macports.org/ticket/13918 > http://trac.macports.org/ticket/14928 Seems like -x should be the default, or rather, that the -x option should be removed, and port should always issue an error message and stop with a nonzero exit status the moment something goes wrong. Why would one not want that? From ryandesign at macports.org Fri May 16 22:32:48 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 17 May 2008 00:32:48 -0500 Subject: octave-forge tarball format changed In-Reply-To: <482B818D.60608@macports.org> References: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> <482A2C8B.7050404@macports.org> <62E8503E-B14C-4AB6-A9BB-9AD62F9C1FD9@macports.org> <482B818D.60608@macports.org> Message-ID: <5F504965-C944-460E-AB58-F36FCAD08658@macports.org> On May 14, 2008, at 7:19 PM, Rainer M?ller wrote: > Alakazam wrote: >> Would it be possible to have an octave PortGroup ? That would make >> it easier to maintain several octave-forge modules in separate >> portfiles, I think. > > Yes, in theory. But until we resolve #14553 [1], port groups can > only be shipped with new releases (and releases seem to be rare at > the moment). > > Rainer > > [1] http://trac.macports.org/ticket/14553 There will have to be a new release of MacPorts base soon enough. A *lot* has been done since 1.6.0 and jmpp has already talked on the list about a 1.6.1 release. So if you want a new portgroup, get it written and committed now so it can be a part of 1.6.1. From jmr at macports.org Fri May 16 22:56:36 2008 From: jmr at macports.org (Joshua Root) Date: Sat, 17 May 2008 15:56:36 +1000 Subject: arbitration of multiple master_sites In-Reply-To: References: Message-ID: <482E7394.9030909@macports.org> markd at macports.org wrote: > Question for jmr at . Is this an accurate description of the fetch behavior > now? > > -Ping the list of master_sites and sort them based on ping response times Right. > -Sourceforge, gnu, etc., special mirrors go after sorted url list No. They get mixed in with the other master_sites and sorted. > -MacPorts fallback mirrors at the end Right. > Also, how many mirror types do we have defined? Sourceforge, gnu, and > what else? Lots. They're defined in mirror_sites.tcl, which lives in src/port1.0/resources/fetch/ in the source tree, and in ${prefix}/share/macports/resources/port1.0/fetch/ when installed. - Josh From jmr at macports.org Fri May 16 23:50:28 2008 From: jmr at macports.org (Joshua Root) Date: Sat, 17 May 2008 16:50:28 +1000 Subject: port doesn't exit with proper return value In-Reply-To: References: <482D8229.8030008@macports.org> Message-ID: <482E8034.9060909@macports.org> Ryan Schmidt wrote: > > On May 16, 2008, at 7:46 AM, Joshua Root wrote: > >> Port's normal mode of operation is to run as many of the requested >> commands as possible and not exit when a command fails. It does this by >> suppressing the error status from the commands. This is certainly >> incorrect when there's only one command run and it fails, but it's less >> clear what should happen when some of the requested commands succeed. >> >> You can make the first failed command cause port to exit, with the >> appropriate return code, by using the -x option on the command line. >> >> Related tickets: >> >> http://trac.macports.org/ticket/13918 >> http://trac.macports.org/ticket/14928 > > Seems like -x should be the default, or rather, that the -x option > should be removed, and port should always issue an error message and > stop with a nonzero exit status the moment something goes wrong. Why > would one not want that? I think the idea is that if you run `port install foo bar baz` or `port upgrade outdated`, and one of the ports fails to install/upgrade, you probably want it to still do the others. This is certainly the case when the operation will take a long time and you want to be able to leave it unattended. On reflection, there should probably always be a non-zero exit status when any command fails, but a failure shouldn't cause the batch to stop. - Josh From ryandesign at macports.org Fri May 16 23:56:52 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 17 May 2008 01:56:52 -0500 Subject: port doesn't exit with proper return value In-Reply-To: <482E8034.9060909@macports.org> References: <482D8229.8030008@macports.org> <482E8034.9060909@macports.org> Message-ID: <9FF70FF0-4969-45A3-A07B-EEE94C8B6AEC@macports.org> On May 17, 2008, at 1:50 AM, Joshua Root wrote: > Ryan Schmidt wrote: >> On May 16, 2008, at 7:46 AM, Joshua Root wrote: >>> Port's normal mode of operation is to run as many of the requested >>> commands as possible and not exit when a command fails. It does >>> this by >>> suppressing the error status from the commands. This is certainly >>> incorrect when there's only one command run and it fails, but >>> it's less >>> clear what should happen when some of the requested commands >>> succeed. >>> >>> You can make the first failed command cause port to exit, with the >>> appropriate return code, by using the -x option on the command line. >>> >>> Related tickets: >>> >>> http://trac.macports.org/ticket/13918 >>> http://trac.macports.org/ticket/14928 >> Seems like -x should be the default, or rather, that the -x option >> should be removed, and port should always issue an error message >> and stop with a nonzero exit status the moment something goes >> wrong. Why would one not want that? > > I think the idea is that if you run `port install foo bar baz` or > `port upgrade outdated`, and one of the ports fails to install/ > upgrade, you probably want it to still do the others. This is > certainly the case when the operation will take a long time and you > want to be able to leave it unattended. On the contrary, I do want MacPorts to stop as soon as it runs into an error. If I say "port upgrade cairo pango graphviz", and graphviz depends on pango, and pango depends on cairo, and maybe the latest version of graphviz requires the latest version of pango which requires the latest version of cairo, and suppose that cairo fails to upgrade, then I do not want MacPorts to attempt to upgrade pango or graphviz. I suppose I can see the point if you've asked for the installation of various unrelated ports, that it should continue to install the other ports even if one fails. But it seems like "most" people would want MacPorts to stop and issue and error if an error occurs. The other behavior could be available via a flag, for advanced users. > On reflection, there should probably always be a non-zero exit > status when any command fails, but a failure shouldn't cause the > batch to stop. From jmr at macports.org Sat May 17 00:41:02 2008 From: jmr at macports.org (Joshua Root) Date: Sat, 17 May 2008 17:41:02 +1000 Subject: port doesn't exit with proper return value In-Reply-To: <9FF70FF0-4969-45A3-A07B-EEE94C8B6AEC@macports.org> References: <482D8229.8030008@macports.org> <482E8034.9060909@macports.org> <9FF70FF0-4969-45A3-A07B-EEE94C8B6AEC@macports.org> Message-ID: <482E8C0E.4070203@macports.org> Ryan Schmidt wrote: > > On May 17, 2008, at 1:50 AM, Joshua Root wrote: > >> Ryan Schmidt wrote: >>> On May 16, 2008, at 7:46 AM, Joshua Root wrote: >>>> Port's normal mode of operation is to run as many of the requested >>>> commands as possible and not exit when a command fails. It does this by >>>> suppressing the error status from the commands. This is certainly >>>> incorrect when there's only one command run and it fails, but it's less >>>> clear what should happen when some of the requested commands succeed. >>>> >>>> You can make the first failed command cause port to exit, with the >>>> appropriate return code, by using the -x option on the command line. >>>> >>>> Related tickets: >>>> >>>> http://trac.macports.org/ticket/13918 >>>> http://trac.macports.org/ticket/14928 >>> Seems like -x should be the default, or rather, that the -x option >>> should be removed, and port should always issue an error message and >>> stop with a nonzero exit status the moment something goes wrong. Why >>> would one not want that? >> >> I think the idea is that if you run `port install foo bar baz` or >> `port upgrade outdated`, and one of the ports fails to >> install/upgrade, you probably want it to still do the others. This is >> certainly the case when the operation will take a long time and you >> want to be able to leave it unattended. > > On the contrary, I do want MacPorts to stop as soon as it runs into an > error. If I say "port upgrade cairo pango graphviz", and graphviz > depends on pango, and pango depends on cairo, and maybe the latest > version of graphviz requires the latest version of pango which requires > the latest version of cairo, and suppose that cairo fails to upgrade, > then I do not want MacPorts to attempt to upgrade pango or graphviz. So the underlying issue is that MP doesn't support version ranges for dependencies, which allows a failed upgrade to detrimentally affect others without making them fail. If in the example you instead run `port upgrade graphviz`, it will also try to upgrade pango and cairo if they are outdated, right? If pango is outdated and fails to upgrade, does the graphviz upgrade also fail as a result? - Josh From ryandesign at macports.org Sat May 17 01:19:47 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 17 May 2008 03:19:47 -0500 Subject: parallel destroot problematic Message-ID: <7CC8BC3A-1B5A-403D-B0CA-05D716CD78A0@macports.org> "use_parallel_build yes" does more than just run the build phase in parallel. It also runs the destroot phase in parallel. This has caused issues for libxml2 and mysql5-devel; see: http://trac.macports.org/ticket/15295 http://trac.macports.org/changeset/36613 Should we change MacPorts to only add the -j argument to the make command in the build phase, and not do so in the destroot phase? The point of running the build in parallel is to make use of additional CPU cores, but the destroot phase is concerned only with copying files on disk. Extra CPU cores won't speed that up anyway. From afb at macports.org Sat May 17 01:29:24 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sat, 17 May 2008 10:29:24 +0200 Subject: parallel destroot problematic In-Reply-To: <7CC8BC3A-1B5A-403D-B0CA-05D716CD78A0@macports.org> References: <7CC8BC3A-1B5A-403D-B0CA-05D716CD78A0@macports.org> Message-ID: <5539B16C-EA1B-4484-8CCB-7CE0BACE00C1@macports.org> Ryan Schmidt wrote: > Should we change MacPorts to only add the -j argument to the make > command in the build phase, and not do so in the destroot phase? Sounds like a good idea to me. --anders From n.oxyde at gmail.com Sat May 17 03:02:27 2008 From: n.oxyde at gmail.com (nox) Date: Sat, 17 May 2008 12:02:27 +0200 Subject: port doesn't exit with proper return value In-Reply-To: <9FF70FF0-4969-45A3-A07B-EEE94C8B6AEC@macports.org> References: <482D8229.8030008@macports.org> <482E8034.9060909@macports.org> <9FF70FF0-4969-45A3-A07B-EEE94C8B6AEC@macports.org> Message-ID: Le 17 mai 08 ? 08:56, Ryan Schmidt a ?crit : > I suppose I can see the point if you've asked for the installation of > various unrelated ports, that it should continue to install the other > ports even if one fails. But it seems like "most" people would want > MacPorts to stop and issue and error if an error occurs. The other > behavior could be available via a flag, for advanced users. We should remove "-x" then, as "-p" already exists: -p Despite any errors encountered, proceed to process multiple ports and commands. Regards, Anthony. From raimue at macports.org Sat May 17 07:02:49 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 17 May 2008 16:02:49 +0200 Subject: parallel destroot problematic In-Reply-To: <5539B16C-EA1B-4484-8CCB-7CE0BACE00C1@macports.org> References: <7CC8BC3A-1B5A-403D-B0CA-05D716CD78A0@macports.org> <5539B16C-EA1B-4484-8CCB-7CE0BACE00C1@macports.org> Message-ID: <482EE589.5030808@macports.org> Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >> Should we change MacPorts to only add the -j argument to the make >> command in the build phase, and not do so in the destroot phase? > > Sounds like a good idea to me. Yes, this is good. We should also merge it to release_1_6 to get it included in the next 1.6.1 release. Rainer From alakazam at melix.net Sat May 17 12:26:32 2008 From: alakazam at melix.net (Alakazam) Date: Sat, 17 May 2008 21:26:32 +0200 Subject: octave-forge tarball format changed In-Reply-To: <5F504965-C944-460E-AB58-F36FCAD08658@macports.org> References: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> <482A2C8B.7050404@macports.org> <62E8503E-B14C-4AB6-A9BB-9AD62F9C1FD9@macports.org> <482B818D.60608@macports.org> <5F504965-C944-460E-AB58-F36FCAD08658@macports.org> Message-ID: <6A0773E0-76D1-476D-875E-8DFA3878E38C@melix.net> On 17 mai 08, at 07:32, Ryan Schmidt wrote: > On May 14, 2008, at 7:19 PM, Rainer M?ller wrote: > >> Alakazam wrote: >>> Would it be possible to have an octave PortGroup ? That would make >>> it easier to maintain several octave-forge modules in separate >>> portfiles, I think. >> >> Yes, in theory. But until we resolve #14553 [1], port groups can >> only be shipped with new releases (and releases seem to be rare at >> the moment). >> >> Rainer >> >> [1] http://trac.macports.org/ticket/14553 > > There will have to be a new release of MacPorts base soon enough. A > *lot* has been done since 1.6.0 and jmpp has already talked on the > list about a 1.6.1 release. So if you want a new portgroup, get it > written and committed now so it can be a part of 1.6.1. If we agree that that is the correct solution for octave-forge, I can look into this in the next couple of days. -- Alakazam From markd at macports.org Sat May 17 13:50:50 2008 From: markd at macports.org (markd at macports.org) Date: Sat, 17 May 2008 13:50:50 -0700 Subject: arbitration of multiple master_sites Message-ID: >> -Sourceforge, gnu, etc., special mirrors go after sorted url list > >No. They get mixed in with the other master_sites and sorted. So if we had this master_sites keyword in port foo: master_sites \ sourceforge \ (ping resp t9) ftp://example1.org \ (ping resp t4) http://example2.org \ (ping resp t7) freebsd (ping resp t1) The fetch order of the master_sites would be: 1) freebsd 2) ftp://example1.org 3) http://example2.org 4) sourceforge 5) implicit MP fallback mirrors And the individual url's listed in mirrors_sites.tcl for mirrors are tried in order. Is that understanding correct? Mark From andrea.damore at macports.org Sat May 17 15:20:06 2008 From: andrea.damore at macports.org (Andrea D'Amore) Date: Sun, 18 May 2008 00:20:06 +0200 Subject: octave-forge tarball format changed In-Reply-To: <6A0773E0-76D1-476D-875E-8DFA3878E38C@melix.net> References: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> <482A2C8B.7050404@macports.org> <62E8503E-B14C-4AB6-A9BB-9AD62F9C1FD9@macports.org> <482B818D.60608@macports.org> <5F504965-C944-460E-AB58-F36FCAD08658@macports.org> <6A0773E0-76D1-476D-875E-8DFA3878E38C@melix.net> Message-ID: <0DFFB3D0-5F80-4CE0-BF47-EACD40E9B10F@macports.org> On 17/mag/08, at 21:26, Alakazam wrote: > If we agree that that is the correct solution for octave-forge, I can > look into this in the next couple of days. I'm not sure how to cope with portgroups (they have to be builtin into macports from what I've read). I wrote a small script to parse web page and generate Portfiles with dependencies. I have still to try them all though, the few I checked supported DESTDIR so they should be fine. I octave-forge packages are going with portgroups I won't commit them, basically having a common set of properties is what I made, using a prototype Portfile and changing only per-package specific data. From raimue at macports.org Sat May 17 15:28:46 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 18 May 2008 00:28:46 +0200 Subject: octave-forge tarball format changed In-Reply-To: <0DFFB3D0-5F80-4CE0-BF47-EACD40E9B10F@macports.org> References: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> <482A2C8B.7050404@macports.org> <62E8503E-B14C-4AB6-A9BB-9AD62F9C1FD9@macports.org> <482B818D.60608@macports.org> <5F504965-C944-460E-AB58-F36FCAD08658@macports.org> <6A0773E0-76D1-476D-875E-8DFA3878E38C@melix.net> <0DFFB3D0-5F80-4CE0-BF47-EACD40E9B10F@macports.org> Message-ID: <482F5C1E.9090001@macports.org> Andrea D'Amore wrote: > On 17/mag/08, at 21:26, Alakazam wrote: > >> If we agree that that is the correct solution for octave-forge, I can >> look into this in the next couple of days. > > I'm not sure how to cope with portgroups (they have to be builtin into > macports from what I've read). [...] > I octave-forge packages are going with portgroups I won't commit them, > basically having a common set of properties is what I made, using a > prototype Portfile and changing only per-package specific data. That's exactly what the PortGroup command is for. Think of it as an include (in fact, that's exactly what it does internally), so everything you specify in the group is also in the port. So basically this is your prototype Portfile you are building currently. Rainer From alakazam at melix.net Sat May 17 15:57:35 2008 From: alakazam at melix.net (Alakazam) Date: Sun, 18 May 2008 00:57:35 +0200 Subject: octave-forge tarball format changed In-Reply-To: <482F5C1E.9090001@macports.org> References: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> <482A2C8B.7050404@macports.org> <62E8503E-B14C-4AB6-A9BB-9AD62F9C1FD9@macports.org> <482B818D.60608@macports.org> <5F504965-C944-460E-AB58-F36FCAD08658@macports.org> <6A0773E0-76D1-476D-875E-8DFA3878E38C@melix.net> <0DFFB3D0-5F80-4CE0-BF47-EACD40E9B10F@macports.org> <482F5C1E.9090001@macports.org> Message-ID: <895D7FC3-DD6A-4127-AF7B-B5966E62D66B@melix.net> On 18 mai 08, at 00:28, Rainer M?ller wrote: >> I octave-forge packages are going with portgroups I won't commit >> them, >> basically having a common set of properties is what I made, using a >> prototype Portfile and changing only per-package specific data. > > That's exactly what the PortGroup command is for. Think of it as an > include (in fact, that's exactly what it does internally), so > everything > you specify in the group is also in the port. So basically this is > your > prototype Portfile you are building currently. I think adding a Portgroup for octave would be as easy as adding a file to > http://trac.macports.org/browser/trunk/base/src/port1.0/resources/ > group Am I mistaken ? -- Olivier From raimue at macports.org Sat May 17 16:00:19 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 18 May 2008 01:00:19 +0200 Subject: octave-forge tarball format changed In-Reply-To: <895D7FC3-DD6A-4127-AF7B-B5966E62D66B@melix.net> References: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> <482A2C8B.7050404@macports.org> <62E8503E-B14C-4AB6-A9BB-9AD62F9C1FD9@macports.org> <482B818D.60608@macports.org> <5F504965-C944-460E-AB58-F36FCAD08658@macports.org> <6A0773E0-76D1-476D-875E-8DFA3878E38C@melix.net> <0DFFB3D0-5F80-4CE0-BF47-EACD40E9B10F@macports.org> <482F5C1E.9090001@macports.org> <895D7FC3-DD6A-4127-AF7B-B5966E62D66B@melix.net> Message-ID: <482F6383.6000607@macports.org> Alakazam wrote: > I think adding a Portgroup for octave would be as easy as adding a > file to > >> http://trac.macports.org/browser/trunk/base/src/port1.0/resources/ >> group > > Am I mistaken ? No, that's it. They are stored locally at /opt/local/share/macports/resources/port1.0/group/ and are part of MacPorts base. Rainer From raimue at macports.org Sat May 17 18:11:09 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 18 May 2008 03:11:09 +0200 Subject: Documenting unreleased features in the guide Message-ID: <482F822D.70107@macports.org> Hi all, at the moment, we do not distinguish between features in the released version and features on trunk only (e.g. universal_archs, sort master_sites by ping) in our guide. This will easily lead to confusion by users. Therefore we need some way to ensure users get the right documentation and do not make wrong assumptions because they read about stuff which is only in trunk. Also, stuff on trunk might change until it is finally released. I think there are multiple ways to deal with this problem. Here are two different solutions: 1) Branch the guide to the release branch This means multiple trees of the guide exist. While new features are being documented on trunk, fixes to the existing documentation are merged back to the release branch. Might lead into some work to do the nominating and merging stuff. 2) Include version information directly in the guide There is still only one tree of the guide. Every new feature and variable documented has a version number. This will just be a smaller printed information after the variable name or below the section headline, something like ">=1.7.0" or "HEAD only". I already had some words about this on IRC with Joshua and Bill (who actually suggested number 2). Personally, my first idea was way 1, but after some thinking I like way 2 better. As our guide is always work-in-progress, I think this will be a good way to reflect the current state how things work according to the version information. Other ideas? Rainer From raimue at macports.org Sat May 17 18:33:43 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 18 May 2008 03:33:43 +0200 Subject: arbitration of multiple master_sites In-Reply-To: References: Message-ID: <482F8777.3010309@macports.org> markd at macports.org wrote: >>> -Sourceforge, gnu, etc., special mirrors go after sorted url list >> No. They get mixed in with the other master_sites and sorted. > > So if we had this master_sites keyword in port foo: > > master_sites \ > sourceforge \ (ping resp t9) > ftp://example1.org \ (ping resp t4) > http://example2.org \ (ping resp t7) > freebsd (ping resp t1) Actually, the mirror lists get expanded first and pinging is then started on all hosts regardless if they come from a mirror list or were directly given in the Portfile. The only exception is the fallback mirror group named "macports", it will always be last. Rainer From markd at macports.org Sat May 17 20:45:05 2008 From: markd at macports.org (markd at macports.org) Date: Sat, 17 May 2008 20:45:05 -0700 Subject: Documenting unreleased features in the guide Message-ID: >at the moment, we do not distinguish between features in the released >version and features on trunk only (e.g. universal_archs, sort >master_sites by ping) in our guide. This will easily lead to confusion >by users. Therefore we need some way to ensure users get the right >documentation and do not make wrong assumptions because they read about >stuff which is only in trunk. Also, stuff on trunk might change until it >is finally released. I think a more pressing problem that contributes to this problem is that we have no formal way of saying "here's a new feature that needs documenting". I think we need a document that mirrors "Changelog" that lists new features that will effect documentation. Right now we can create tickets, but I don't think this is used too much. I squirrel away links to base changes that I see on the list for future documentation, but sometimes I miss them, as I did for the new fetch feature. So frankly, since I think keeping documentation up-to-date is a higher priority than that worrying that users may try to use a feature, and when I feel lucky to discover by pure chance a new feature, as it happened this time, I've just wanted to get it in writing before the moment is gone. All that to say, simply that I think we need something comprehensive like a "ChangeLog docs edition" before a concern that users will be confused by unimplemented features in the guide can really be addressed. That said, the point you make is completely valid of course. > >I think there are multiple ways to deal with this problem. Here are two >different solutions: > >1) Branch the guide to the release branch >This means multiple trees of the guide exist. While new features are >being documented on trunk, fixes to the existing documentation are >merged back to the release branch. Might lead into some work to do the >nominating and merging stuff. > >2) Include version information directly in the guide >There is still only one tree of the guide. Every new feature and >variable documented has a version number. This will just be a smaller >printed information after the variable name or below the section >headline, something like ">=1.7.0" or "HEAD only". > >I already had some words about this on IRC with Joshua and Bill (who >actually suggested number 2). Personally, my first idea was way 1, but >after some thinking I like way 2 better. As our guide is always >work-in-progress, I think this will be a good way to reflect the current >state how things work according to the version information. > >Other ideas? I think two branches of the released guide is cumbersome. And though I don't like including version numbers in the guide per se, but I'll throw out another alternative that is sort of a "third way" betwen 1 and 2. Use DocBook "profiling"; some vendors refer to this feature as "conditional text". So the xml in the guide that represents features in HEAD are flagged as such, and two guides are cranked out by the stylesheets. So we would in fact have two versions of the guide as far as generated html, one for the released version and one for HEAD, though only one source tree. But as I said, I think we'd need to get a handle on listing base changes that need documenting before this would really work. Mark From andrea.damore at macports.org Sat May 17 23:19:24 2008 From: andrea.damore at macports.org (Andrea D'Amore) Date: Sun, 18 May 2008 08:19:24 +0200 Subject: octave-forge tarball format changed In-Reply-To: <482F6383.6000607@macports.org> References: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> <482A2C8B.7050404@macports.org> <62E8503E-B14C-4AB6-A9BB-9AD62F9C1FD9@macports.org> <482B818D.60608@macports.org> <5F504965-C944-460E-AB58-F36FCAD08658@macports.org> <6A0773E0-76D1-476D-875E-8DFA3878E38C@melix.net> <0DFFB3D0-5F80-4CE0-BF47-EACD40E9B10F@macports.org> <482F5C1E.9090001@macports.org> <895D7FC3-DD6A-4127-AF7B-B5966E62D66B@melix.net> <482F6383.6000607@macports.org> Message-ID: <4DE74F09-9748-4B01-B075-EB424B05AD5E@macports.org> On 18/mag/08, at 01:00, Rainer M?ller wrote: > No, that's it. They are stored locally at > /opt/local/share/macports/resources/port1.0/group/ and are part of > MacPorts base. And that means that people won't see it until they don't selfupdate, doesn't it? > Rainer Andrea From jmr at macports.org Sun May 18 00:09:02 2008 From: jmr at macports.org (Joshua Root) Date: Sun, 18 May 2008 17:09:02 +1000 Subject: arbitration of multiple master_sites In-Reply-To: <482F8777.3010309@macports.org> References: <482F8777.3010309@macports.org> Message-ID: <482FD60E.5070808@macports.org> Rainer M?ller wrote: > markd at macports.org wrote: >>>> -Sourceforge, gnu, etc., special mirrors go after sorted url list >>> No. They get mixed in with the other master_sites and sorted. >> >> So if we had this master_sites keyword in port foo: >> >> master_sites \ >> sourceforge \ (ping resp t9) >> ftp://example1.org \ (ping resp t4) >> http://example2.org \ (ping resp t7) >> freebsd (ping resp t1) > > Actually, the mirror lists get expanded first and pinging is then > started on all hosts regardless if they come from a mirror list or were > directly given in the Portfile. The only exception is the fallback > mirror group named "macports", it will always be last. Just to be completely clear, 'macports' is an ordinary mirror group like any other. The reason it is tried last is that it is listed in a separate fallback_mirrors list that is tried after master_sites. If for some reason you listed 'macports' in master_sites, svn.macports.org would be pinged and could potentially sort to any position in the list. - Josh From jmr at macports.org Sun May 18 01:01:42 2008 From: jmr at macports.org (Joshua Root) Date: Sun, 18 May 2008 18:01:42 +1000 Subject: octave-forge tarball format changed Message-ID: <482FE266.3030501@macports.org> > On 18/mag/08, at 01:00, Rainer M?ller wrote: > >> No, that's it. They are stored locally at >> /opt/local/share/macports/resources/port1.0/group/ and are part of >> MacPorts base. > > And that means that people won't see it until they don't selfupdate, > doesn't it? Right. Though it would be nice to change that (for everything in the resources dir, in fact): - Josh From mww at macports.org Sun May 18 02:34:32 2008 From: mww at macports.org (Markus Weissmann) Date: Sun, 18 May 2008 11:34:32 +0200 Subject: [36832] trunk/dports/archivers/gnutar/Portfile In-Reply-To: <0F656FEC-E3C5-4DE3-9FF1-99DEB24C530F@macports.org> References: <20080516075528.C9C76169CA86@beta.macosforge.org> <0F656FEC-E3C5-4DE3-9FF1-99DEB24C530F@macports.org> Message-ID: <90EB4D14-FCA6-4EAA-89DC-7F59E8E56542@macports.org> On 17 May 2008, at 06:47, Ryan Schmidt wrote: > On May 16, 2008, at 2:55 AM, mww at macports.org wrote: > >> version 1.20 with workaround for broken gcc-4.0 on 10.5: beta gcc >> 4.2 needs to be installed :/ > >> +platform darwin 9 { >> + # gcc 4.0 fails to compile gnutar on 10.5 (probably will get >> fixed with XCode 3.1) >> + configure.compiler gcc-4.2 >> +} > > Don't you also need to add "depends_lib port:gcc42" in the "platform > darwin 9" section then, since MacPorts doesn't automatically add the > compiler dependency? > No, this is not the vanilla-gcc installed via MacPorts but the beta release of gcc 4.2 from Apple -- which allows universal builds etc.; I don't know if we should introduct a virtual package for this or if there should be a "depends_build bin:gcc-4.2:APPLE_STUFF" in there. Any thoughts? Regards, -Markus -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/ From randall.h.wood at alexandriasoftware.com Sun May 18 03:26:32 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sun, 18 May 2008 06:26:32 -0400 Subject: Forcing destroot to work Message-ID: I'm attempting to write a portfile for swftools but during the destroot phase, it simply goes ahead and installs into ${prefix} instead of ${destroot}/${prefix} What is the best way to correct this sort of behavior? -- Randall Wood randall.h.wood at alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From afb at macports.org Sun May 18 03:34:16 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 18 May 2008 12:34:16 +0200 Subject: Forcing destroot to work In-Reply-To: References: Message-ID: Randall Wood wrote: > I'm attempting to write a portfile for swftools but during the > destroot phase, it simply goes ahead and installs into ${prefix} > instead of ${destroot}/${prefix} > > What is the best way to correct this sort of behavior? Either educate the port / upstream about using DESTDIR, or use "destroot.destdir prefix=${destroot}${prefix}" and fix "later"... --anders From alakazam at melix.net Sun May 18 04:05:48 2008 From: alakazam at melix.net (Alakazam) Date: Sun, 18 May 2008 13:05:48 +0200 Subject: octave-forge tarball format changed In-Reply-To: <4DE74F09-9748-4B01-B075-EB424B05AD5E@macports.org> References: <4EBE5ABE-37B5-4FFD-8EC6-A214D7CB25AB@macports.org> <482A2C8B.7050404@macports.org> <62E8503E-B14C-4AB6-A9BB-9AD62F9C1FD9@macports.org> <482B818D.60608@macports.org> <5F504965-C944-460E-AB58-F36FCAD08658@macports.org> <6A0773E0-76D1-476D-875E-8DFA3878E38C@melix.net> <0DFFB3D0-5F80-4CE0-BF47-EACD40E9B10F@macports.org> <482F5C1E.9090001@macports.org> <895D7FC3-DD6A-4127-AF7B-B5966E62D66B@melix.net> <482F6383.6000607@macports.org> <4DE74F09-9748-4B01-B075-EB424B05AD5E@macports.org> Message-ID: On 18 mai 08, at 08:19, Andrea D'Amore wrote: > On 18/mag/08, at 01:00, Rainer M?ller wrote: > >> No, that's it. They are stored locally at >> /opt/local/share/macports/resources/port1.0/group/ and are part of >> MacPorts base. > > And that means that people won't see it until they don't selfupdate, > doesn't it? Indeed. Do you ask because you are worried that they might not be able to install the octave-forge Portfiles ? If I am not mistakn, octave- forge does not currently build, so this might not be a major problem. -- Alakazam From andrea.damore at macports.org Sun May 18 05:16:31 2008 From: andrea.damore at macports.org (Andrea D'Amore) Date: Sun, 18 May 2008 14:16:31 +0200 Subject: octave-forge tarball format changed In-Reply-To: <482FE266.3030501@macports.org> References: <482FE266.3030501@macports.org> Message-ID: <81DB760C-44EA-48D4-8B97-A56DFA5BBA4B@macports.org> On 18/mag/08, at 10:01, Joshua Root wrote: > Right. Though it would be nice to change that (for everything in the > resources dir, in fact): Ok so how sohuld we manage this? Wait for inclusion in portgroup? I've already prepared a good number of portfiles for them and I'm in the processo of testing them but if we're going with portgroup I'll just drop it. > - Josh Andrea From alakazam at melix.net Sun May 18 05:19:14 2008 From: alakazam at melix.net (Alakazam) Date: Sun, 18 May 2008 14:19:14 +0200 Subject: octave-forge tarball format changed In-Reply-To: <81DB760C-44EA-48D4-8B97-A56DFA5BBA4B@macports.org> References: <482FE266.3030501@macports.org> <81DB760C-44EA-48D4-8B97-A56DFA5BBA4B@macports.org> Message-ID: On 18 mai 08, at 14:16, Andrea D'Amore wrote: > Ok so how sohuld we manage this? Wait for inclusion in portgroup? > I've already prepared a good number of portfiles for them and I'm in > the processo of testing them but if we're going with portgroup I'll > just drop it. If I am not mistaken, it would be quite simple to take all the common elements in the Portfiles you are building, and add them to a Portgroup (simply factor into a new Portfile all the common commands and variables, and that makes a Portgroup file, actually), and then use your script, without adding all the common rules, and use "Portgroup octave" as the only common rule in all these portfiles. -- Alakazam From afb at macports.org Sun May 18 11:20:53 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 18 May 2008 20:20:53 +0200 Subject: parallel destroot problematic In-Reply-To: <482EE589.5030808@macports.org> References: <7CC8BC3A-1B5A-403D-B0CA-05D716CD78A0@macports.org> <5539B16C-EA1B-4484-8CCB-7CE0BACE00C1@macports.org> <482EE589.5030808@macports.org> Message-ID: <26C67E5C-1563-4903-9425-7826FEEB3CDE@macports.org> Rainer M?ller wrote: >>> Should we change MacPorts to only add the -j argument to the make >>> command in the build phase, and not do so in the destroot phase? >> Sounds like a good idea to me. > Yes, this is good. We should also merge it to release_1_6 to get it > included in the next 1.6.1 release. I made a partial fix/workaround, that makes destroot.cmd not inherit build.cmd but instead use the same "make" definition (with make type) This is not perfect, since it makes the earlier behaviour of making destroot.cmd inherit build.cmd. That would still be the preferred... So there should be a better solution, that would separate build.nice and build.jobs from build.cmd so that it could still be e.g. "make". The same should probably be applied to test.cmd as well as destroot.cmd, since probably not every port will run successfully with "make -j2 test" ? --anders From afb at macports.org Sun May 18 14:58:07 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 18 May 2008 23:58:07 +0200 Subject: parallel destroot problematic In-Reply-To: <26C67E5C-1563-4903-9425-7826FEEB3CDE@macports.org> References: <7CC8BC3A-1B5A-403D-B0CA-05D716CD78A0@macports.org> <5539B16C-EA1B-4484-8CCB-7CE0BACE00C1@macports.org> <482EE589.5030808@macports.org> <26C67E5C-1563-4903-9425-7826FEEB3CDE@macports.org> Message-ID: <92C3874B-A994-47B6-B006-E24B94078B57@macports.org> > I made a partial fix/workaround, that makes destroot.cmd not inherit > build.cmd but instead use the same "make" definition (with make type) > > This is not perfect, since it makes the earlier behaviour of making > destroot.cmd inherit build.cmd. That would still be the preferred... > So there should be a better solution, that would separate build.nice > and build.jobs from build.cmd so that it could still be e.g. "make". Now fixed (in r36913), so that build.cmd is back to "make" again... --anders From markd at macports.org Sun May 18 16:39:23 2008 From: markd at macports.org (markd at macports.org) Date: Sun, 18 May 2008 16:39:23 -0700 Subject: arbitration of multiple master_sites Message-ID: >>> So if we had this master_sites keyword in port foo: >>> >>> master_sites \ >>> sourceforge \ (ping resp t9) >>> ftp://example1.org \ (ping resp t4) >>> http://example2.org \ (ping resp t7) >>> freebsd (ping resp t1) >> >> Actually, the mirror lists get expanded first and pinging is then >> started on all hosts regardless if they come from a mirror list or were >> directly given in the Portfile. The only exception is the fallback >> mirror group named "macports", it will always be last. > >Just to be completely clear, 'macports' is an ordinary mirror group like >any other. The reason it is tried last is that it is listed in a >separate fallback_mirrors list that is tried after master_sites. If for >some reason you listed 'macports' in master_sites, svn.macports.org >would be pinged and could potentially sort to any position in the list. Joshua, Thanks for the detailed explanation. It is very clear now. Mark From jmpp at macports.org Sun May 18 17:44:19 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun, 18 May 2008 20:14:19 -0430 Subject: [36916] trunk/dports/PortIndex In-Reply-To: <20080518194458.8552D16AAF2E@beta.macosforge.org> References: <20080518194458.8552D16AAF2E@beta.macosforge.org> Message-ID: <87868883-DDFF-451F-9643-4DE873859746@macports.org> On May 18, 2008, at 3:14 PM, dluke at macports.org wrote: > Revision > 36916 > Author > dluke at macports.org > Date > 2008-05-18 12:44:56 -0700 (Sun, 18 May 2008) > Log Message > > Total number of ports parsed: 4777 > Ports successfully parsed: 4777 > Ports failed: 0 > Modified Paths > > trunk/dports/PortIndex Big Woot! to Andrea for pushing our ports count from 4715 to 4776 (plus another new port by Randall) in one fell swoop, with a single commit (I imagine Octave loving users are now loving you ;-) Regards,... -jmpp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080518/07c9c9a5/attachment.htm From andrea.damore at macports.org Sun May 18 23:50:12 2008 From: andrea.damore at macports.org (Andrea D'Amore) Date: Mon, 19 May 2008 08:50:12 +0200 Subject: [36916] trunk/dports/PortIndex In-Reply-To: <87868883-DDFF-451F-9643-4DE873859746@macports.org> References: <20080518194458.8552D16AAF2E@beta.macosforge.org> <87868883-DDFF-451F-9643-4DE873859746@macports.org> Message-ID: <397F5B74-47D0-47C6-A61E-BE553543C5B8@macports.org> On 19/mag/08, at 02:44, Juan Manuel Palacios wrote: > Big Woot! to Andrea for pushing our ports count from 4715 to 4776 > (plus another new port by Randall) in one fell swoop, with a single > commit (I imagine Octave loving users are now loving you ;-) No big deal, they are basically the same portfile and it was more like a proof of concept for autogenerate portfiles from octave-forge web page. Too bad not all packages did it, 12 have broken build, I just stayed safe and committed only those that built without any change. I'm going to ask for testing to octave users in macports-users, I'm not a heavy octave users myself (actually I just needed 2 of those packages) and I can't really check all of them, I can't even say what most of them actually do. Anyway they show in "pkg list" at octave prompt and that should be enough. > Regards,... Regards > -jmpp Andrea From wsiegrist at apple.com Mon May 19 11:50:57 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 19 May 2008 11:50:57 -0700 Subject: Documenting unreleased features in the guide In-Reply-To: References: Message-ID: <35F56DD2-0333-4906-8C8E-35F56A679568@apple.com> On May 17, 2008, at 8:45 PM, markd at macports.org wrote: >> > I think two branches of the released guide is cumbersome. And > though I > don't like including version numbers in the guide per se, but I'll > throw > out another alternative that is sort of a "third way" betwen 1 and > 2. Use > DocBook "profiling"; some vendors refer to this feature as > "conditional > text". So the xml in the guide that represents features in HEAD are > flagged as such, and two guides are cranked out by the stylesheets. > So we > would in fact have two versions of the guide as far as generated > html, one > for the released version and one for HEAD, though only one source > tree. > But as I said, I think we'd need to get a handle on listing base > changes > that need documenting before this would really work. This idea seems like a decent compromise. If we do this, I would like to see a link at the top of each page to switch to the other versions. So maybe guide.macports.org is the current Trunk/HEAD docs, and guide.macports.org/1.6.0/ is the docs for v1.6.0. At the top of guide.macports.org is a link to /1.6.0/ and the top of /1.6.0/ has a link to the Trunk/HEAD docs. An example of this is the documentation for Django: http://www.djangoproject.com/documentation/ Now, under this model, its up for debate as to which version lives on the "top" of guide.macports.org. I can see reasons for both, so I dont have a strong preference either way. -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/20080519/8cc63e5c/attachment-0001.p7s From wsiegrist at apple.com Mon May 19 12:35:27 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 19 May 2008 12:35:27 -0700 Subject: distfiles.macports.org Message-ID: <38ED7DA2-C2E1-430B-9445-364F684A552A@apple.com> I've begun experimenting with hosting a distfile mirror on Mac OS Forge for MacPorts. This is very much a beta service, so it wont be automatically used by MacPorts just yet. But if you have trouble fetching a distfile, the checksums fail repeatedly, or you need an old distfile, you might try looking here: http://distfiles.macports.org// Disclaimer: this service is experimental, it may not be available all of the time, it may not contain all distfiles, I will probably rearrange the files later, it may not always be up to date with the portfiles in the svn repo, etc etc. Also, there may be some ports out there that forbid mirroring of their distfiles. If you know of such a port, you can email me directly with the port name so it can be excluded from mirroring. Thanks -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/20080519/35b796b0/attachment.p7s From markd at macports.org Mon May 19 14:56:01 2008 From: markd at macports.org (markd at macports.org) Date: Mon, 19 May 2008 14:56:01 -0700 Subject: Documenting unreleased features in the guide Message-ID: >> I think two branches of the released guide is cumbersome. And >> though I >> don't like including version numbers in the guide per se, but I'll >> throw >> out another alternative that is sort of a "third way" betwen 1 and >> 2. Use >> DocBook "profiling"; some vendors refer to this feature as >> "conditional >> text". So the xml in the guide that represents features in HEAD are >> flagged as such, and two guides are cranked out by the stylesheets. >> So we >> would in fact have two versions of the guide as far as generated >> html, one >> for the released version and one for HEAD, though only one source >> tree. >> But as I said, I think we'd need to get a handle on listing base >> changes >> that need documenting before this would really work. > > > >This idea seems like a decent compromise. If we do this, I would like >to see a link at the top of each page to switch to the other versions. >So maybe guide.macports.org is the current Trunk/HEAD docs, and >guide.macports.org/1.6.0/ is the docs for v1.6.0. At the top of >guide.macports.org is a link to /1.6.0/ and the top of /1.6.0/ has a >link to the Trunk/HEAD docs. > >An example of this is the documentation for Django: > >http://www.djangoproject.com/documentation/ > >Now, under this model, its up for debate as to which version lives on >the "top" of guide.macports.org. I can see reasons for both, so I dont >have a strong preference either way. > >-Bill The django site method looks like a good way to present multiple versions. But even though I don't think it would be hard to do, I still have some problems with doing it. The problem I see is that: 1) We don't sufficiently distinguish between versions of the program itself to adequately distinguish versions of documentation, since doing that assumes a clear distinction already. 2) MacPorts versions tend to be extremely similar to each other it seems to me, and it seems to me keeping multiple versions of a document implies some extensive changes. So on the one hand I wonder if it is worth it; on the other I wonder if it will be confusing to present several versions of a document so similar. As far as point 1), some have suggested we shouldn't use MP releases at all and call everything a beta for similar reasons I think. I don't want to advance an opinion one way or the other on that, but I think the question simply rises again in the docs. Though "conditional text" isn't hard I don't think, I worry about confusion about which features will be released with the next version of base generating confusion on the doc team about to write the docs. Though I know I said I don't like using version numbers in the guide generally, for this one instance maybe it isn't a bad idea to just add a version number and remove it after the next code release. Right now, the fetch feature I documented from HEAD recently is the only instance I'm aware of where HEAD features are in the guide. Perhaps we could just wait and see if versioning problems come up again frequently before using more advanced methods. Mark From ram at macports.org Mon May 19 20:29:25 2008 From: ram at macports.org (Adam Mercer) Date: Mon, 19 May 2008 22:29:25 -0500 Subject: Checking that a given variant of a port is active Message-ID: <799406d60805192029k1276b2c4l9985d3bc74a39bc0@mail.gmail.com> Hi In trying to fix #14240, scipy failing to build on Tiger using g95 as the fortran compiler; I am wondering if its possible, in a pre-fetch phase for example, to determine if a given variant of a specific port is active. More precisely in the scipy ports I want to check that numpy has been built using either the gcc42 or gcc43 variants, is this possible and how would I go about determining this? A bit of background information: average users of numpy itself will probably not need the fortran aspects of numpy, i.e. f2py, therefore for the upcoming numpy-1.1.0 (and corresponding scipy-0.7.0) release(s) I am thinking of moving all numpy fortran support to non-default variants. scipy however requires a numpy built using a fortran compiler. I therefore need to ensure that numpy has been built with either gcc42 or gcc43 fortran support prior to trying to build scipy. Hope that makes sense. Cheers Adam From jmr at macports.org Tue May 20 08:44:06 2008 From: jmr at macports.org (Joshua Root) Date: Wed, 21 May 2008 01:44:06 +1000 Subject: Checking that a given variant of a port is active In-Reply-To: <799406d60805192029k1276b2c4l9985d3bc74a39bc0@mail.gmail.com> References: <799406d60805192029k1276b2c4l9985d3bc74a39bc0@mail.gmail.com> Message-ID: <4832F1C6.1020909@macports.org> Adam Mercer wrote: > In trying to fix #14240, scipy failing to build on Tiger using g95 as > the fortran compiler; I am wondering if its possible, in a pre-fetch > phase for example, to determine if a given variant of a specific port > is active. More precisely in the scipy ports I want to check that > numpy has been built using either the gcc42 or gcc43 variants, is this > possible and how would I go about determining this? > > A bit of background information: average users of numpy itself will > probably not need the fortran aspects of numpy, i.e. f2py, therefore > for the upcoming numpy-1.1.0 (and corresponding scipy-0.7.0) > release(s) I am thinking of moving all numpy fortran support to > non-default variants. scipy however requires a numpy built using a > fortran compiler. I therefore need to ensure that numpy has been built > with either gcc42 or gcc43 fortran support prior to trying to build > scipy. 1. This would require access to the registry, which is not an API that is meant to be exposed in Portfiles. 2. Maybe it would be possible to call registry::installed from a Portfile anyway, which would give you a list of all the installed versions and variants for a given port name (and their activation status). However, my understanding of the namespaces, sub-interpreters and so forth is not good enough to say how difficult that would be. 3. What you really want is for #126 to be fixed. -Josh From jmr at macports.org Tue May 20 08:46:55 2008 From: jmr at macports.org (Joshua Root) Date: Wed, 21 May 2008 01:46:55 +1000 Subject: [36940] trunk/dports/games/SDLInvaders/Portfile In-Reply-To: <20080520115616.AFAF216B5253@beta.macosforge.org> References: <20080520115616.AFAF216B5253@beta.macosforge.org> Message-ID: <4832F26F.5020301@macports.org> phw at macports.org wrote: > Revision: 36940 > http://trac.macosforge.org/projects/macports/changeset/36940 > Author: phw at macports.org > Date: 2008-05-20 04:56:15 -0700 (Tue, 20 May 2008) > > Log Message: > ----------- > Created new Port Duke Nukem 3D (runtimes only) > > Modified Paths: > -------------- > trunk/dports/games/SDLInvaders/Portfile Looks like you changed the wrong portfile here. From dluke at geeklair.net Tue May 20 09:56:08 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue, 20 May 2008 12:56:08 -0400 Subject: Checking that a given variant of a port is active In-Reply-To: <4832F1C6.1020909@macports.org> References: <799406d60805192029k1276b2c4l9985d3bc74a39bc0@mail.gmail.com> <4832F1C6.1020909@macports.org> Message-ID: On May 20, 2008, at 11:44 AM, Joshua Root wrote: >> A bit of background information: average users of numpy itself will >> probably not need the fortran aspects of numpy, i.e. f2py, therefore >> for the upcoming numpy-1.1.0 (and corresponding scipy-0.7.0) >> release(s) I am thinking of moving all numpy fortran support to >> non-default variants. scipy however requires a numpy built using a >> fortran compiler. I therefore need to ensure that numpy has been >> built >> with either gcc42 or gcc43 fortran support prior to trying to build >> scipy. > > 1. This would require access to the registry, which is not an API that > is meant to be exposed in Portfiles. > > 2. Maybe it would be possible to call registry::installed from a > Portfile anyway, which would give you a list of all the installed > versions and variants for a given port name (and their activation > status). However, my understanding of the namespaces, sub-interpreters > and so forth is not good enough to say how difficult that would be. > > 3. What you really want is for #126 to be fixed. > Another option is to break the numpy port into two ports. One of which works like the 'normal' (non-fortran) numpy and the other which requires gcc42/43 and builds with fortran support. Then your scipy port can depend on a port that supplies everything it needs without requiring a specific variant (and yes, it's not an ideal solution). -- Daniel J. Luke +========================================================+ | *---------------- dluke at 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/20080520/8f602a27/attachment.sig From jmr at macports.org Tue May 20 12:17:18 2008 From: jmr at macports.org (Joshua Root) Date: Wed, 21 May 2008 05:17:18 +1000 Subject: [36946] trunk/dports/x11/AfterStep/Portfile In-Reply-To: <20080520181352.B0A6516B65FA@beta.macosforge.org> References: <20080520181352.B0A6516B65FA@beta.macosforge.org> Message-ID: <483323BE.20704@macports.org> waqar at macports.org wrote: > Revision: 36946 > http://trac.macosforge.org/projects/macports/changeset/36946 > Author: waqar at macports.org > Date: 2008-05-20 11:13:51 -0700 (Tue, 20 May 2008) > > Log Message: > ----------- > Updated to the latest version of the software. > > Modified Paths: > -------------- > trunk/dports/x11/AfterStep/Portfile [...] > > -depends_lib lib:libX11.6:XFree86 lib:libXext.6:XFree86 \ > - lib:libjpeg.62:jpeg lib:libpng.3:libpng \ > - lib:libfreetype:freetype lib:libtiff:tiff \ > - lib:libungif:libungif lib:libgtk.2:gtk2 > +depends_lib port:XFree86 port:jpeg port:libpng port:freetype \ > + port:tiff port:libungif port:gtk2 port:librsvg Shouldn't the XFree86 dependency stay as lib: rather than port: so that it will be satisfied by Apple's X11? - Josh From raimue at macports.org Tue May 20 12:20:38 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 20 May 2008 21:20:38 +0200 Subject: [36946] trunk/dports/x11/AfterStep/Portfile In-Reply-To: <483323BE.20704@macports.org> References: <20080520181352.B0A6516B65FA@beta.macosforge.org> <483323BE.20704@macports.org> Message-ID: <48332486.3060802@macports.org> Joshua Root wrote: >> +depends_lib port:XFree86 port:jpeg port:libpng port:freetype \ >> + port:tiff port:libungif port:gtk2 port:librsvg > > Shouldn't the XFree86 dependency stay as lib: rather than port: so that > it will be satisfied by Apple's X11? The XFree86 port checks for X11 and X11SDK by Apple and errors out if only one of them is present. So it does a bit more than just a lib: dependency. Rainer From jmr at macports.org Tue May 20 12:34:33 2008 From: jmr at macports.org (Joshua Root) Date: Wed, 21 May 2008 05:34:33 +1000 Subject: [36946] trunk/dports/x11/AfterStep/Portfile In-Reply-To: <48332486.3060802@macports.org> References: <20080520181352.B0A6516B65FA@beta.macosforge.org> <483323BE.20704@macports.org> <48332486.3060802@macports.org> Message-ID: <483327C9.4020008@macports.org> Rainer M?ller wrote: > Joshua Root wrote: >>> +depends_lib port:XFree86 port:jpeg port:libpng port:freetype \ >>> + port:tiff port:libungif port:gtk2 port:librsvg >> >> Shouldn't the XFree86 dependency stay as lib: rather than port: so >> that it will be satisfied by Apple's X11? > > The XFree86 port checks for X11 and X11SDK by Apple and errors out if > only one of them is present. So it does a bit more than just a lib: > dependency. It also errors out if both Apple X11 and X11SDK are present. (And the usage of ${prefix} in those checks in the XFree86 portfile seems to be wrong, BTW. Not to mention quartz-wm is in /usr/bin these days, not ${x11prefix}/bin.) So it's impossible to install AfterStep with X11 installed: % sudo port -v install AfterStep Password: ---> Fetching XFree86 Error: Target org.macports.fetch returned: You have an Apple X11SDK installation already. MacPorts will not overwrite it. If you wish to use Apple X11, install it from your Mac OS X install disc. If you really want to use XFree86 instead, please move it aside first : sudo mv /usr/X11R6 /usr/X11R6.apple Warning: the following items did not execute (for XFree86): org.macports.activate org.macports.fetch org.macports.extract org.macports.checksum org.macports.patch org.macports.configure org.macports.build org.macports.destroot org.macports.install Error: The following dependencies failed to build: XFree86 Error: Status 1 encountered during processing. From raimue at macports.org Tue May 20 12:50:27 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 20 May 2008 21:50:27 +0200 Subject: [36946] trunk/dports/x11/AfterStep/Portfile In-Reply-To: <483327C9.4020008@macports.org> References: <20080520181352.B0A6516B65FA@beta.macosforge.org> <483323BE.20704@macports.org> <48332486.3060802@macports.org> <483327C9.4020008@macports.org> Message-ID: <48332B83.9020803@macports.org> Joshua Root wrote: > It also errors out if both Apple X11 and X11SDK are present. (And the > usage of ${prefix} in those checks in the XFree86 portfile seems to be > wrong, BTW. Not to mention quartz-wm is in /usr/bin these days, not > ${x11prefix}/bin.) So it's impossible to install AfterStep with X11 > installed: Don't miss the line: prefix ${x11prefix} Hm, if the location of quartz-wm changed between Tiger and Leopard, we should add checks for this to this port if we want to sustain it's functionality. I thought I have seen port:XFree86 also at other places, but seems like they are all gone now? Rainer From jmr at macports.org Tue May 20 12:56:31 2008 From: jmr at macports.org (Joshua Root) Date: Wed, 21 May 2008 05:56:31 +1000 Subject: [36946] trunk/dports/x11/AfterStep/Portfile In-Reply-To: <05749CF5-ED4C-49FF-8A23-05BA5B86A754@gmail.com> References: <20080520181352.B0A6516B65FA@beta.macosforge.org> <483323BE.20704@macports.org> <48332486.3060802@macports.org> <483327C9.4020008@macports.org> <05749CF5-ED4C-49FF-8A23-05BA5B86A754@gmail.com> Message-ID: <48332CEF.4080001@macports.org> Waqar Malik wrote: > I wanted to add the variant X11 so that you would install X11 with that > variant, that seemed wrong as x11 is required for the window manager to > run. > > I tried to add builtin-x11 by depends_lib-delete and it did not work. So > I will look into it some more. But for now I guess we can just add the > X11 variant? Adding a builtin-x11 variant seems like wasted effort when you can get the same effect by simply depending on lib:libX11.6:XFree86. - Josh From jmr at macports.org Tue May 20 13:06:08 2008 From: jmr at macports.org (Joshua Root) Date: Wed, 21 May 2008 06:06:08 +1000 Subject: [36946] trunk/dports/x11/AfterStep/Portfile In-Reply-To: <48332B83.9020803@macports.org> References: <20080520181352.B0A6516B65FA@beta.macosforge.org> <483323BE.20704@macports.org> <48332486.3060802@macports.org> <483327C9.4020008@macports.org> <48332B83.9020803@macports.org> Message-ID: <48332F30.5090609@macports.org> Rainer M?ller wrote: > Joshua Root wrote: >> It also errors out if both Apple X11 and X11SDK are present. (And the >> usage of ${prefix} in those checks in the XFree86 portfile seems to be >> wrong, BTW. Not to mention quartz-wm is in /usr/bin these days, not >> ${x11prefix}/bin.) So it's impossible to install AfterStep with X11 >> installed: > > Don't miss the line: > prefix ${x11prefix} Right. I was confused by the fact that I was getting the third error message, triggered by [file exists ${prefix}/include/X11/X.h]. Since the check for Apple X11 hadn't triggered, I figured this must be due to my having xorg-xproto installed. But of course this behaviour was actually because it was looking for quartz-wm in the wrong place. I'll try to fix up the checks. - Josh From afb at macports.org Tue May 20 13:46:06 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue, 20 May 2008 22:46:06 +0200 Subject: [36950] trunk/dports/x11/XFree86/Portfile In-Reply-To: <20080520201053.366DA16B6D8A@beta.macosforge.org> References: <20080520201053.366DA16B6D8A@beta.macosforge.org> Message-ID: <92DA3E35-E97A-4509-9225-9508424D41C5@macports.org> > Revision 36950 > Author jmr at macports.org > Date 2008-05-20 13:10:52 -0700 (Tue, 20 May 2008) > > Log Message > XFree86: add working detection of Apple X11 on Leopard > Modified Paths > trunk/dports/x11/XFree86/Portfile Note that ${x11prefix} requires trunk / MacPorts 1.7... In earlier versions it was hardcoded as /usr/X11R6 always. (which isn't a problem on Leopard, due to /usr/X11R6-> X11) In the new "base", it is configurable (--with-x11-prefix) --anders From jmr at macports.org Tue May 20 14:18:25 2008 From: jmr at macports.org (Joshua Root) Date: Wed, 21 May 2008 07:18:25 +1000 Subject: [36950] trunk/dports/x11/XFree86/Portfile In-Reply-To: <92DA3E35-E97A-4509-9225-9508424D41C5@macports.org> References: <20080520201053.366DA16B6D8A@beta.macosforge.org> <92DA3E35-E97A-4509-9225-9508424D41C5@macports.org> Message-ID: <48334021.5050609@macports.org> Anders F Bj?rklund wrote: >> Revision 36950 >> Author jmr at macports.org >> Date 2008-05-20 13:10:52 -0700 (Tue, 20 May 2008) >> >> Log Message >> XFree86: add working detection of Apple X11 on Leopard >> Modified Paths >> trunk/dports/x11/XFree86/Portfile > > Note that ${x11prefix} requires trunk / MacPorts 1.7... Really? I could have sworn it was configurable in 1.6.0 via macports.conf. The XFree86 portfile was already using it, anyway. - Josh From mmoll at cs.rice.edu Tue May 20 15:50:50 2008 From: mmoll at cs.rice.edu (Mark Moll) Date: Tue, 20 May 2008 17:50:50 -0500 Subject: tickets for number of math / scientific computing ports Message-ID: Hi, Can someone commit the following ports I have submitted quite a while back: http://trac.macports.org/ticket/15175 Added support to arpack port for using different fortran compilers (the same way it is done for e.g. py25-scipy). http://trac.macports.org/ticket/14832 New port for PETSc, a suite of data structures and routines for the scalable (parallel) solution of scientific applications modeled by partial differential equations. Has been assigned to mcalhoun at macports.org over a month ago. http://trac.macports.org/ticket/14833 New port for SLEPc, a software library for the solution of large scale sparse eigenvalue problems on parallel computers. Requires PETSc, includes a variant to support arpack. -- Mark From wsiegrist at apple.com Tue May 20 16:38:08 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 20 May 2008 16:38:08 -0700 Subject: tickets for number of math / scientific computing ports In-Reply-To: References: Message-ID: On May 20, 2008, at 3:50 PM, Mark Moll wrote: > Hi, > > Can someone commit the following ports I have submitted quite a while > back: > I've assigned the tickets to myself. I'll work on them and comment in the tickets if anything prevents them from being added. -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/20080520/977fbfb4/attachment-0001.p7s From jkh at apple.com Tue May 20 18:42:50 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue, 20 May 2008 18:42:50 -0700 Subject: tickets for number of math / scientific computing ports In-Reply-To: References: Message-ID: You seem to have a unique interest in Fortran and scientific ports. Ever considered joining MacPorts as a committer? - Jordan On May 20, 2008, at 3:50 PM, Mark Moll wrote: > Hi, > > Can someone commit the following ports I have submitted quite a while > back: > > http://trac.macports.org/ticket/15175 > Added support to arpack port for using different fortran compilers > (the same way it is done for e.g. py25-scipy). > > http://trac.macports.org/ticket/14832 > New port for PETSc, a suite of data structures and routines for the > scalable (parallel) solution of scientific applications modeled by > partial differential equations. Has been assigned to mcalhoun at macports.org > over a month ago. > > http://trac.macports.org/ticket/14833 > New port for SLEPc, a software library for the solution of large scale > sparse eigenvalue problems on parallel computers. Requires PETSc, > includes a variant to support arpack. > > -- > Mark > > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From wsiegrist at apple.com Wed May 21 15:43:36 2008 From: wsiegrist at apple.com (William Siegrist) Date: Wed, 21 May 2008 15:43:36 -0700 Subject: Remove www/legacy ? Message-ID: Is there any reason why we have the www/legacy directory still in subversion? http://trac.macports.org/browser/trunk/www/legacy I'd like to recommend its removal. -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/20080521/540e11df/attachment.p7s From wsiegrist at apple.com Wed May 21 15:52:03 2008 From: wsiegrist at apple.com (William Siegrist) Date: Wed, 21 May 2008 15:52:03 -0700 Subject: [36980] trunk/dports In-Reply-To: <20080521224319.8462316BD1A8@beta.macosforge.org> References: <20080521224319.8462316BD1A8@beta.macosforge.org> Message-ID: <9607983A-83CE-4367-A3F6-C15FD5CDE674@apple.com> You can leave off the @macports.org since thats the default. -Bill On May 21, 2008, at 3:43 PM, aschenke at macports.org wrote: > Revision36980Authoraschenke at macports.orgDate2008-05-21 15:43:10 > -0700 (Wed, 21 May 2008)Log Message > update maintainer e-mail > Modified Paths > ? trunk/dports/games/larn/Portfile > ? trunk/dports/games/moria/Portfile > ? trunk/dports/games/rogue/Portfile > ? trunk/dports/print/ps2eps/Portfile > ? trunk/dports/tex/latexdiff/Portfile > Diff > Modified: trunk/dports/games/larn/Portfile (36979 => 36980) > --- trunk/dports/games/larn/Portfile 2008-05-21 22:37:16 UTC (rev > 36979) > +++ trunk/dports/games/larn/Portfile 2008-05-21 22:43:10 UTC (rev > 36980) > @@ -5,7 +5,7 @@ > version 12 > revision 0 > categories games > -maintainers aschenke at tampabay.rr.com > +maintainers aschenke at macports.org > description Text-based cavern exploring game > long_description Larn is a text-based fantasy role-playing game > similar to Rogue, \ > Nethack, etc. -------------- 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/20080521/80169139/attachment.p7s From kvv at apple.com Wed May 21 15:57:32 2008 From: kvv at apple.com (Kevin Van Vechten) Date: Wed, 21 May 2008 15:57:32 -0700 Subject: Remove www/legacy ? In-Reply-To: References: Message-ID: No objection here. On May 21, 2008, at 3:43 PM, William Siegrist wrote: > Is there any reason why we have the www/legacy directory still in > subversion? > > http://trac.macports.org/browser/trunk/www/legacy > > I'd like to recommend its removal. > > -Bill From jmpp at macports.org Wed May 21 22:46:20 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu, 22 May 2008 01:16:20 -0430 Subject: Remove www/legacy ? In-Reply-To: References: Message-ID: On May 21, 2008, at 6:27 PM, Kevin Van Vechten wrote: > No objection here. > > On May 21, 2008, at 3:43 PM, William Siegrist wrote: > >> Is there any reason why we have the www/legacy directory still in >> subversion? >> >> http://trac.macports.org/browser/trunk/www/legacy >> >> I'd like to recommend its removal. >> >> -Bill I kept it around while re-writing the website as a "just in case". Then after for something else... which I cannot recall at the moment (maybe the rss code in includes/news.inc and admin/? but then came wordpress and so forth...), and since nothing is ever really lost in SCM... nuke it! (you with admin access to Trac can tell better than any of us if there's anything worth keeping in that rss code). -jmpp From wsiegrist at apple.com Wed May 21 22:56:14 2008 From: wsiegrist at apple.com (William Siegrist) Date: Wed, 21 May 2008 22:56:14 -0700 Subject: [MacPorts] #15395: Use primary port category for fetched distfile layout In-Reply-To: <055.4079a4435b0465352a5b1f32e193a2ab@macports.org> References: <055.4079a4435b0465352a5b1f32e193a2ab@macports.org> Message-ID: <95BF041D-F206-48C3-A287-92958BD5F1CE@apple.com> Could I get a review of this patch from someone with some base experience to make sure this wont break anything. I believe it'll be seamless for end users and is the simplest change to make the mirror layout the way I want it to. Thanks -Bill On May 21, 2008, at 10:46 PM, MacPorts wrote: > #15395: Use primary port category for fetched distfile layout > ------------------------------------ > +--------------------------------------- > Reporter: wsiegrist at apple.com | Owner: wsiegrist at apple.com > Type: enhancement | Status: new > Priority: Normal | Milestone: > Component: base | Version: > Keywords: fetch mirror distfiles | > ------------------------------------ > +--------------------------------------- > The distfile directory ($prefix/var/macports/distfiles/) currently > uses 1 > level of directory based on port name. This means mirroring also > uses the > single directory level. > > I propose to use the primary category to layout mirrors and > distfiles with > an additional directory. The main reason for this is the layout on > distfiles.macports.org. We need the 2 layers of directories to make > browsing more managable. > > The change will be mostly invisible to users as far as their local > installations are concerned. This will make distfiles match the > layout of > Portfiles in the svn and rsync repositories. > > The simplest fix, and the one I provide a patch for here, is to read > the > categories value and set distpath accordingly during fetch_init. This > affects all fetching and mirroring. The only impact I see to end > users is > if they pre-fetch something, upgrade to the patched code, then try to > install. The distfile would be in the wrong place and re-fetched. This > case seems rare and a minor inconvenience at that. > > -- > Ticket URL: > MacPorts > Ports system for Mac OS -------------- 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/20080521/3b1143d8/attachment-0001.p7s From dluke at geeklair.net Thu May 22 07:28:37 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Thu, 22 May 2008 10:28:37 -0400 Subject: [MacPorts] #15395: Use primary port category for fetched distfile layout In-Reply-To: <95BF041D-F206-48C3-A287-92958BD5F1CE@apple.com> References: <055.4079a4435b0465352a5b1f32e193a2ab@macports.org> <95BF041D-F206-48C3-A287-92958BD5F1CE@apple.com> Message-ID: <3DCA5AC4-3015-4EEF-85A7-180DA79B9631@geeklair.net> On May 22, 2008, at 1:56 AM, William Siegrist wrote: > Could I get a review of this patch from someone with some base > experience to make sure this wont break anything. I believe it'll be > seamless for end users and is the simplest change to make the mirror > layout the way I want it to. Why would people be browsing the mirrored files? Wouldn't the interaction with the site mostly just be 'port' downloading a mirrored file? Also, without some sort of migration for currently saved distfiles, we end up orphaning all of the currently saved distfiles on a machine (I've got one machine with about 1GB of old distfiles). At the very least, we need to make port clean --dist be able to remove distfiles from both the old and new locations. > On May 21, 2008, at 10:46 PM, MacPorts wrote: >> #15395: Use primary port category for fetched distfile layout >> ------------------------------------ >> +--------------------------------------- >> Reporter: wsiegrist at apple.com | Owner: >> wsiegrist at apple.com >> Type: enhancement | Status: new >> Priority: Normal | Milestone: >> Component: base | Version: >> Keywords: fetch mirror distfiles | >> ------------------------------------ >> +--------------------------------------- >> The distfile directory ($prefix/var/macports/distfiles/) currently >> uses 1 >> level of directory based on port name. This means mirroring also >> uses the >> single directory level. >> >> I propose to use the primary category to layout mirrors and >> distfiles with >> an additional directory. The main reason for this is the layout on >> distfiles.macports.org. We need the 2 layers of directories to make >> browsing more managable. >> >> The change will be mostly invisible to users as far as their local >> installations are concerned. This will make distfiles match the >> layout of >> Portfiles in the svn and rsync repositories. >> >> The simplest fix, and the one I provide a patch for here, is to >> read the >> categories value and set distpath accordingly during fetch_init. This >> affects all fetching and mirroring. The only impact I see to end >> users is >> if they pre-fetch something, upgrade to the patched code, then try to >> install. The distfile would be in the wrong place and re-fetched. >> This >> case seems rare and a minor inconvenience at that. -- Daniel J. Luke +========================================================+ | *---------------- dluke at 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/20080522/0999352b/attachment.sig From afb at macports.org Thu May 22 07:54:35 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 22 May 2008 16:54:35 +0200 Subject: [MacPorts] #15395: Use primary port category for fetched distfile layout In-Reply-To: <3DCA5AC4-3015-4EEF-85A7-180DA79B9631@geeklair.net> References: <055.4079a4435b0465352a5b1f32e193a2ab@macports.org> <95BF041D-F206-48C3-A287-92958BD5F1CE@apple.com> <3DCA5AC4-3015-4EEF-85A7-180DA79B9631@geeklair.net> Message-ID: <9CCD0553-106A-4D04-8BA9-5A4F4791402D@macports.org> Daniel J. Luke wrote: > On May 22, 2008, at 1:56 AM, William Siegrist wrote: >> Could I get a review of this patch from someone with some base >> experience to make sure this wont break anything. I believe it'll >> be seamless for end users and is the simplest change to make the >> mirror layout the way I want it to. > > Why would people be browsing the mirrored files? Wouldn't the > interaction with the site mostly just be 'port' downloading a > mirrored file? And couldn't you make something like MPWA to browse the files, instead of having to wade through all the lowlevel yourself ? Or, for a low-tech solution, setup some symlink directories. "category/foo -> ../foo", then you can browse category/foo/ ? --anders From randall.h.wood at alexandriasoftware.com Thu May 22 08:39:26 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Thu, 22 May 2008 11:39:26 -0400 Subject: [MacPorts] #15395: Use primary port category for fetched distfile layout In-Reply-To: References: <055.4079a4435b0465352a5b1f32e193a2ab@macports.org> <95BF041D-F206-48C3-A287-92958BD5F1CE@apple.com> <3DCA5AC4-3015-4EEF-85A7-180DA79B9631@geeklair.net> <9CCD0553-106A-4D04-8BA9-5A4F4791402D@macports.org> Message-ID: Arg. Failure to reply to all... On Thu, May 22, 2008 at 11:38 AM, Randall Wood wrote: > On Thu, May 22, 2008 at 10:54 AM, Anders F Bj?rklund wrote: >> Daniel J. Luke wrote: >> >>> On May 22, 2008, at 1:56 AM, William Siegrist wrote: >>>> Could I get a review of this patch from someone with some base >>>> experience to make sure this wont break anything. I believe it'll >>>> be seamless for end users and is the simplest change to make the >>>> mirror layout the way I want it to. >>> >>> Why would people be browsing the mirrored files? Wouldn't the >>> interaction with the site mostly just be 'port' downloading a >>> mirrored file? >> >> And couldn't you make something like MPWA to browse the files, >> instead of having to wade through all the lowlevel yourself ? >> >> Or, for a low-tech solution, setup some symlink directories. >> "category/foo -> ../foo", then you can browse category/foo/ ? >> >> --anders >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> > > There does remain a performance hit for large flat directories no > matter how the user sees it (through a web server which takes the hit > or on the user's own machine). > > -- > Randall Wood > randall.h.wood at alexandriasoftware.com > > "The rules are simple: The ball is round. The game lasts 90 minutes. > All the rest is just philosophy." > -- Randall Wood randall.h.wood at alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From dluke at geeklair.net Thu May 22 08:45:05 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Thu, 22 May 2008 11:45:05 -0400 Subject: [MacPorts] #15395: Use primary port category for fetched distfile layout In-Reply-To: References: <055.4079a4435b0465352a5b1f32e193a2ab@macports.org> <95BF041D-F206-48C3-A287-92958BD5F1CE@apple.com> <3DCA5AC4-3015-4EEF-85A7-180DA79B9631@geeklair.net> <9CCD0553-106A-4D04-8BA9-5A4F4791402D@macports.org> Message-ID: <20C2CD74-8EDF-44A2-B4E2-F7E4AA438194@geeklair.net> On May 22, 2008, at 11:39 AM, Randall Wood wrote: >> There does remain a performance hit for large flat directories no >> matter how the user sees it (through a web server which takes the hit >> or on the user's own machine). Do you have some evidence for this? I know it's the case for ffs or ext2 (in its default configuration), but HFS+ uses a tree structure for directory contents, so in testing I did in the past, there isn't much of a reason for making a big directory hierarchy. Back in the 10.1 days, I did some testing with many items in a directory (over 10,000, but I don't recall what the maximum number I tested with was) with no noticeable performance difference (except with the Finder, which choked). -- Daniel J. Luke +========================================================+ | *---------------- dluke at 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/20080522/2710c9e3/attachment.sig From wsiegrist at apple.com Thu May 22 11:12:51 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 22 May 2008 11:12:51 -0700 Subject: [MacPorts] #15395: Use primary port category for fetched distfile layout In-Reply-To: <20C2CD74-8EDF-44A2-B4E2-F7E4AA438194@geeklair.net> References: <055.4079a4435b0465352a5b1f32e193a2ab@macports.org> <95BF041D-F206-48C3-A287-92958BD5F1CE@apple.com> <3DCA5AC4-3015-4EEF-85A7-180DA79B9631@geeklair.net> <9CCD0553-106A-4D04-8BA9-5A4F4791402D@macports.org> <20C2CD74-8EDF-44A2-B4E2-F7E4AA438194@geeklair.net> Message-ID: <7549D37D-0300-480C-941C-5B906B0A25E2@apple.com> On May 22, 2008, at 8:45 AM, Daniel J. Luke wrote: > On May 22, 2008, at 11:39 AM, Randall Wood wrote: >>> There does remain a performance hit for large flat directories no >>> matter how the user sees it (through a web server which takes the >>> hit >>> or on the user's own machine). > > Do you have some evidence for this? > > I know it's the case for ffs or ext2 (in its default configuration), > but HFS+ uses a tree structure for directory contents, so in testing > I did in the past, there isn't much of a reason for making a big > directory hierarchy. > > Back in the 10.1 days, I did some testing with many items in a > directory (over 10,000, but I don't recall what the maximum number I > tested with was) with no noticeable performance difference (except > with the Finder, which choked). > The files dont live on HFS+. In any case, the current load time of http://distfiles.macports.org/ is pretty good evidence. -------------- 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/20080522/f83298fa/attachment.p7s From wsiegrist at apple.com Thu May 22 11:25:27 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 22 May 2008 11:25:27 -0700 Subject: [MacPorts] #15395: Use primary port category for fetched distfile layout In-Reply-To: <9CCD0553-106A-4D04-8BA9-5A4F4791402D@macports.org> References: <055.4079a4435b0465352a5b1f32e193a2ab@macports.org> <95BF041D-F206-48C3-A287-92958BD5F1CE@apple.com> <3DCA5AC4-3015-4EEF-85A7-180DA79B9631@geeklair.net> <9CCD0553-106A-4D04-8BA9-5A4F4791402D@macports.org> Message-ID: <5862C096-D195-4D30-B65A-1F7930A6F7AB@apple.com> On May 22, 2008, at 7:54 AM, Anders F Bj?rklund wrote: > Daniel J. Luke wrote: > >> On May 22, 2008, at 1:56 AM, William Siegrist wrote: >>> Could I get a review of this patch from someone with some base >>> experience to make sure this wont break anything. I believe it'll >>> be seamless for end users and is the simplest change to make the >>> mirror layout the way I want it to. >> >> Why would people be browsing the mirrored files? Wouldn't the >> interaction with the site mostly just be 'port' downloading a >> mirrored file? > > And couldn't you make something like MPWA to browse the files, > instead of having to wade through all the lowlevel yourself ? > > Or, for a low-tech solution, setup some symlink directories. > "category/foo -> ../foo", then you can browse category/foo/ ? I definitely hope that MPWA, `port fetch`, and ports.php will make it so that users dont need to browse via Apache indexes, or even know what distfiles.macports.org is. However, right now, I am implementing the low level stuff. If I can also make it useful while we wait on MPWA, then I think it can help some people. Now, putting aside whether or not people should be browsing apache indexes... I want the layout to use a category directory to make it more manageable on the server for me. I could, and still might, just make it work like I want on the server and leave MP base alone. But I wanted to leverage some of the MP base functionality since some work is already done there for me. It also seemed like a chance to sync the layout convention used by Portfiles and distfiles so they are the same. -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/20080522/0ffd7c11/attachment-0001.p7s From zach at zachfine.com Thu May 22 12:55:49 2008 From: zach at zachfine.com (Zachary Fine) Date: Thu, 22 May 2008 12:55:49 -0700 Subject: difficulty cross-compiling on Leopard for Tiger Message-ID: Greetings all, I'm trying to cross-compile php5, lighttpd, and mysql5 on a MacBook Pro running OS X 10.5.2, and I plan to transfer the resulting binaries over to run on my AppleTV box. The AppleTV runs a slimmed-down version of OS 10.4 Tiger, and seems to run <10.4.8 binaries just fine. Running 'uname -a' on my AppleTV box results in the following output: Darwin AppleTV.local 8.8.2 Darwin Kernel Version 8.8.2: Mon Jan 29 18:57:29 PST 2007; root:xnu-792.94.18~1/RELEASE_I386 i386 i386 I first tried just copying the lighttpd and php5 that I'd compiled on my Leopard MacBook Pro over to the AppleTV and running them, but the binaries are incompatible: > bash-2.05b$ ./php-cgi > dyld: unknown required load command 0x8000001C > Trace/BPT trap Through a process of research, trial and error, I made the following adjustments to macports.conf and variants.conf. I added the following lines to 'macports.conf': universal_target 10.4 universal_sysroot /Developer/SDKs/MacOSX10.4u.sdk mmacosx-version-min 10.4 and the following to variants.conf: +darwin_8 +i386 +universal I uninstalled all ports, and was able to get my lighttpd and mysql5 to install (using the command "sudo port install lighttpd +cml +davprops +mysql5 +ssl") but php refuses to compile: > [zachmbp:~] zach% sudo port install php5 +fastcgi +imap +macosx > +mysql5 +pcntl +pear +sqlite +tidy > Error: Error executing universal: Default universal variant only > works with ports based on configure > Error: Unable to execute port: Error evaluating variants I'm tempted to just give up on my cross-compilation effort, set up 10.4.8 on a partition on a firewire drive, and compile using macports on that. But it feels like it should be possible to get this working, and I don't really want to have to keep 10.4.8 around any time I need to compile something for an older system. Thanks for any help or information. -Zach Fine zach at zachfine.com From afb at macports.org Thu May 22 13:18:21 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 22 May 2008 22:18:21 +0200 Subject: [MacPorts] #15395: Use primary port category for fetched distfile layout In-Reply-To: <5862C096-D195-4D30-B65A-1F7930A6F7AB@apple.com> References: <055.4079a4435b0465352a5b1f32e193a2ab@macports.org> <95BF041D-F206-48C3-A287-92958BD5F1CE@apple.com> <3DCA5AC4-3015-4EEF-85A7-180DA79B9631@geeklair.net> <9CCD0553-106A-4D04-8BA9-5A4F4791402D@macports.org> <5862C096-D195-4D30-B65A-1F7930A6F7AB@apple.com> Message-ID: William Siegrist wrote: >>> Why would people be browsing the mirrored files? Wouldn't the >>> interaction with the site mostly just be 'port' downloading a >>> mirrored file? >> >> And couldn't you make something like MPWA to browse the files, >> instead of having to wade through all the lowlevel yourself ? >> >> Or, for a low-tech solution, setup some symlink directories. >> "category/foo -> ../foo", then you can browse category/foo/ ? > > > I definitely hope that MPWA, `port fetch`, and ports.php will make > it so that users dont need to browse via Apache indexes, or even > know what distfiles.macports.org is. However, right now, I am > implementing the low level stuff. If I can also make it useful > while we wait on MPWA, then I think it can help some people. > > Now, putting aside whether or not people should be browsing apache > indexes... I want the layout to use a category directory to make it > more manageable on the server for me. I could, and still might, > just make it work like I want on the server and leave MP base > alone. But I wanted to leverage some of the MP base functionality > since some work is already done there for me. It also seemed like > a chance to sync the layout convention used by Portfiles and > distfiles so they are the same. I guess I was just surprised to see another layer of directories proposed, after the earlier question on the list why it needed any directories at all and not just have all distfiles in one big directory... (like BSD) But as long as there is a migration path and someone willing to do the work, then I suppose it's worth the while after all. Kinda like the dp2mp transition, it seems like the innocent change could break some things. --anders From wsiegrist at apple.com Thu May 22 13:50:21 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 22 May 2008 13:50:21 -0700 Subject: [MacPorts] #15395: Use primary port category for fetched distfile layout In-Reply-To: References: <055.4079a4435b0465352a5b1f32e193a2ab@macports.org> <95BF041D-F206-48C3-A287-92958BD5F1CE@apple.com> <3DCA5AC4-3015-4EEF-85A7-180DA79B9631@geeklair.net> <9CCD0553-106A-4D04-8BA9-5A4F4791402D@macports.org> <5862C096-D195-4D30-B65A-1F7930A6F7AB@apple.com> Message-ID: <1CAE0F8C-C321-43BF-A173-5F4C00573A67@apple.com> On May 22, 2008, at 1:18 PM, Anders F Bj?rklund wrote: > William Siegrist wrote: > >>>> Why would people be browsing the mirrored files? Wouldn't the >>>> interaction with the site mostly just be 'port' downloading a >>>> mirrored file? >>> >>> And couldn't you make something like MPWA to browse the files, >>> instead of having to wade through all the lowlevel yourself ? >>> >>> Or, for a low-tech solution, setup some symlink directories. >>> "category/foo -> ../foo", then you can browse category/foo/ ? >> >> >> I definitely hope that MPWA, `port fetch`, and ports.php will make >> it so that users dont need to browse via Apache indexes, or even >> know what distfiles.macports.org is. However, right now, I am >> implementing the low level stuff. If I can also make it useful >> while we wait on MPWA, then I think it can help some people. >> >> Now, putting aside whether or not people should be browsing apache >> indexes... I want the layout to use a category directory to make it >> more manageable on the server for me. I could, and still might, >> just make it work like I want on the server and leave MP base >> alone. But I wanted to leverage some of the MP base functionality >> since some work is already done there for me. It also seemed like >> a chance to sync the layout convention used by Portfiles and >> distfiles so they are the same. > > I guess I was just surprised to see another layer of directories > proposed, after the earlier question on the list why it needed any > directories at all and not just have all distfiles in one big > directory... (like BSD) > The 1 big directory idea is fine if you're not the one who has to manage it. The Fink mirror we provide does this with MD5-named symlinks and its a pain anytime I have to deal with it. > But as long as there is a migration path and someone willing to do > the work, then I suppose it's worth the while after all. Kinda like > the dp2mp transition, it seems like the innocent change could break > some things. Like I commented in the ticket, if it turns out to be a lot of work and risk just for this 1 service, I'll just organize stuff manually on the server and leave the base functionality alone. -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/20080522/627821ff/attachment.p7s From ryandesign at macports.org Thu May 22 21:07:01 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 22 May 2008 23:07:01 -0500 Subject: difficulty cross-compiling on Leopard for Tiger In-Reply-To: References: Message-ID: <32C87F01-4F12-4DDF-ACAE-BA349A81FE3B@macports.org> On May 22, 2008, at 14:55, Zachary Fine wrote: > I'm trying to cross-compile php5, lighttpd, and mysql5 on a MacBook > Pro running OS X 10.5.2, and I plan to transfer the resulting binaries > over to run on my AppleTV box. The AppleTV runs a slimmed-down version > of OS 10.4 Tiger, and seems to run <10.4.8 binaries just fine. Running > 'uname -a' on my AppleTV box results in the following output: > > Darwin AppleTV.local 8.8.2 Darwin Kernel Version 8.8.2: Mon Jan 29 > 18:57:29 PST 2007; root:xnu-792.94.18~1/RELEASE_I386 i386 i386 > > I first tried just copying the lighttpd and php5 that I'd compiled on > my Leopard MacBook Pro over to the AppleTV and running them, but the > binaries are incompatible: > >> bash-2.05b$ ./php-cgi >> dyld: unknown required load command 0x8000001C >> Trace/BPT trap > > > Through a process of research, trial and error, I made the following > adjustments to macports.conf and variants.conf. > > I added the following lines to 'macports.conf': > universal_target 10.4 > universal_sysroot /Developer/SDKs/MacOSX10.4u.sdk > mmacosx-version-min 10.4 > > and the following to variants.conf: > +darwin_8 +i386 +universal > > I uninstalled all ports, and was able to get my lighttpd and mysql5 to > install (using the command "sudo port install lighttpd +cml +davprops > +mysql5 +ssl") but php refuses to compile: > >> [zachmbp:~] zach% sudo port install php5 +fastcgi +imap +macosx >> +mysql5 +pcntl +pear +sqlite +tidy >> Error: Error executing universal: Default universal variant only >> works with ports based on configure >> Error: Unable to execute port: Error evaluating variants > > I'm tempted to just give up on my cross-compilation effort, set up > 10.4.8 on a partition on a firewire drive, and compile using macports > on that. But it feels like it should be possible to get this working, > and I don't really want to have to keep 10.4.8 around any time I need > to compile something for an older system. This exercise is of course completely unsupported. Compiling on one major Mac OS X release for use on another major Mac OS X release is not supported by MacPorts, and MacPorts isn't supported at all on AppleTV, which is not (according to Apple definitions anyway) a Mac. However, I applaud your efforts thus far, and you're clearly on the right track. The error message you're getting is also, I should point out, not coming from php5, which is based on configure and builds universal just fine. Some other port is complaining (maybe one of the ones necessary for the imap, pcntl, pear, or tidy variants.... those I haven't tested much). To find out which one, try using the debug flag ("sudo port -d install php5 ........"). That should make it more clear which non-configure port doesn't have a universal variant. Maybe then we can add one to make a universal build of that port possible. From ryandesign at macports.org Fri May 23 00:21:19 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 May 2008 02:21:19 -0500 Subject: [36971] trunk/dports/sysutils/freeradius/Portfile In-Reply-To: <20080521145025.B8B9516BB0EC@beta.macosforge.org> References: <20080521145025.B8B9516BB0EC@beta.macosforge.org> Message-ID: <412895D3-AD40-4ABF-8B13-9980A36B5AB5@macports.org> On May 21, 2008, at 09:50, andrea.damore at macports.org wrote: > Revision: 36971 > http://trac.macosforge.org/projects/macports/changeset/36971 > Author: andrea.damore at macports.org > Date: 2008-05-21 07:50:21 -0700 (Wed, 21 May 2008) > > Log Message: > ----------- > freeradius update to 2.0.4 Thanks for the update! See some suggestions below... > -version 1.1.7 > +version 2.0.4 > revision 1 When you increase a port's version, you should drop the revision down to 0, or you can remove the revision line altogether which will have the same effect. > -master_sites ftp://ftp.freeradius.org/pub/radius/ \ > +use_bzip2 yes > +distname ${name}-server-${version} > +master_sites ftp://ftp.freeradius.org/pub/freeradius/ \ > ftp://ftp.freeradius.org/pub/radius/old > -checksums sha1 4e8515f82260478ef881ed7b87b7ca258e19ccba > +checksums \ > + freeradius-server-2.0.4.tar.bz2 \ > + md5 0b63d1d75e51bd94b62c11c639fa329e \ > + sha1 3408d09a990c63df6718939097650a463d654a99 \ > + rmd160 66915fb5511573b502b7afdb96fd0adb807faa29 You don't need to repeat the distfile name in the checksum section if it's of the default form (${distname}${extract.suffix}) and there's only one distfile. I'd suggest removing this redundant information from all your ports as well, where possible, to keep them simpler. > -destroot.destdir prefix=${destroot}${prefix} > +destroot.env-append R=${destroot} > +#destroot.destdir prefix=${destroot}${prefix} You should generally remove lines no longer needed, not comment them out. If you need to refer to the line later, you can always look up the older version of the portfile in the Subversion repository. From ryandesign at macports.org Fri May 23 01:33:47 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 May 2008 03:33:47 -0500 Subject: [36832] trunk/dports/archivers/gnutar/Portfile In-Reply-To: <90EB4D14-FCA6-4EAA-89DC-7F59E8E56542@macports.org> References: <20080516075528.C9C76169CA86@beta.macosforge.org> <0F656FEC-E3C5-4DE3-9FF1-99DEB24C530F@macports.org> <90EB4D14-FCA6-4EAA-89DC-7F59E8E56542@macports.org> Message-ID: <4E3B6876-F0C9-483F-94F7-51DF73850296@macports.org> On May 18, 2008, at 04:34, Markus Weissmann wrote: > On 17 May 2008, at 06:47, Ryan Schmidt wrote: > >> On May 16, 2008, at 2:55 AM, mww at macports.org wrote: >> >>> version 1.20 with workaround for broken gcc-4.0 on 10.5: beta gcc >>> 4.2 needs to be installed :/ >> >>> +platform darwin 9 { >>> + # gcc 4.0 fails to compile gnutar on 10.5 (probably will get >>> fixed with XCode 3.1) >>> + configure.compiler gcc-4.2 >>> +} >> >> Don't you also need to add "depends_lib port:gcc42" in the >> "platform darwin 9" section then, since MacPorts doesn't >> automatically add the compiler dependency? > > No, this is not the vanilla-gcc installed via MacPorts but the beta > release of gcc 4.2 from Apple -- which allows universal builds etc.; Gotcha! I missed that. > I don't know if we should introduct a virtual package for this or > if there should be a "depends_build bin:gcc-4.2:APPLE_STUFF" in > there. Any thoughts? Oh, I think that's probably not necessary. I just wasn't paying enough attention. From ryandesign at macports.org Fri May 23 02:32:26 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 May 2008 04:32:26 -0500 Subject: distfiles.macports.org In-Reply-To: <38ED7DA2-C2E1-430B-9445-364F684A552A@apple.com> References: <38ED7DA2-C2E1-430B-9445-364F684A552A@apple.com> Message-ID: On May 19, 2008, at 14:35, William Siegrist wrote: > I've begun experimenting with hosting a distfile mirror on Mac OS > Forge for MacPorts. This is very much a beta service, so it wont be > automatically used by MacPorts just yet. But if you have trouble > fetching a distfile, the checksums fail repeatedly, or you need an > old distfile, you might try looking here: > > http://distfiles.macports.org// I hope it's not actually but as defined in the port. For most ports, will equal but some ports may override it. > Disclaimer: this service is experimental, it may not be available > all of the time, it may not contain all distfiles, I will probably > rearrange the files later, it may not always be up to date with the > portfiles in the svn repo, etc etc. > > Also, there may be some ports out there that forbid mirroring of > their distfiles. If you know of such a port, you can email me > directly with the port name so it can be excluded from mirroring. From ryandesign at macports.org Fri May 23 02:36:58 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 May 2008 04:36:58 -0500 Subject: [36950] trunk/dports/x11/XFree86/Portfile In-Reply-To: <48334021.5050609@macports.org> References: <20080520201053.366DA16B6D8A@beta.macosforge.org> <92DA3E35-E97A-4509-9225-9508424D41C5@macports.org> <48334021.5050609@macports.org> Message-ID: <08852046-D703-4723-B7C1-F42D5B48F955@macports.org> On May 20, 2008, at 16:18, Joshua Root wrote: > Anders F Bj?rklund wrote: > >>> Revision 36950 >>> Author jmr at macports.org >>> Date 2008-05-20 13:10:52 -0700 (Tue, 20 May 2008) >>> >>> Log Message >>> XFree86: add working detection of Apple X11 on Leopard >>> Modified Paths >>> trunk/dports/x11/XFree86/Portfile >> >> Note that ${x11prefix} requires trunk / MacPorts 1.7... > > Really? I could have sworn it was configurable in 1.6.0 via > macports.conf. The XFree86 portfile was already using it, anyway. We already have 103 occurrences of "x11prefix" in 67 ports. If it didn't work with 1.6.0 I'd expect to have seen complaints by now, but I don't recall any... From afb at macports.org Fri May 23 02:50:37 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri, 23 May 2008 11:50:37 +0200 Subject: [36950] trunk/dports/x11/XFree86/Portfile In-Reply-To: <08852046-D703-4723-B7C1-F42D5B48F955@macports.org> References: <20080520201053.366DA16B6D8A@beta.macosforge.org> <92DA3E35-E97A-4509-9225-9508424D41C5@macports.org> <48334021.5050609@macports.org> <08852046-D703-4723-B7C1-F42D5B48F955@macports.org> Message-ID: <9AD96626-8D93-4CDD-B65E-CF8B31D300AD@macports.org> Ryan Schmidt wrote: >>> Note that ${x11prefix} requires trunk / MacPorts 1.7... >> >> Really? I could have sworn it was configurable in 1.6.0 via >> macports.conf. The XFree86 portfile was already using it, anyway. > > We already have 103 occurrences of "x11prefix" in 67 ports. If it > didn't work with 1.6.0 I'd expect to have seen complaints by now, > but I don't recall any... I might be mistaken, I haven't tried with another X11 suffix. (as using /usr/X11R6 works fine with both Tiger and Leopard) But anyway trunk will detect the X11 prefix automatically now. (it is /usr/X11 for Leopard, and /usr/local for FreeBSD 7.0) --anders From andrea.damore at macports.org Fri May 23 03:52:18 2008 From: andrea.damore at macports.org (Andrea D'Amore) Date: Fri, 23 May 2008 12:52:18 +0200 Subject: [36971] trunk/dports/sysutils/freeradius/Portfile In-Reply-To: <412895D3-AD40-4ABF-8B13-9980A36B5AB5@macports.org> References: <20080521145025.B8B9516BB0EC@beta.macosforge.org> <412895D3-AD40-4ABF-8B13-9980A36B5AB5@macports.org> Message-ID: On 23/mag/08, at 09:21, Ryan Schmidt wrote: >> revision 1 > > When you increase a port's version, you should drop the revision > down to 0, or you can remove the revision line altogether which will > have the same effect. Thanks I just missed that one. Actually I didn't even knew what it meant and in another portfile I was updating I just deleted it. >> +checksums \ >> + freeradius-server-2.0.4.tar.bz2 \ > You don't need to repeat the distfile name in the checksum section > if it's of the default form (${distname}${extract.suffix}) and > there's only one distfile. I'd suggest removing this redundant > information from all your ports as well, where possible, to keep > them simpler. I'm using a bash script to generate checksums as I found myself typing each commands often when updating, as I had to manage with more than one distfile per port I found it easier to type the name too even when there's is a single file. By the way did you ever wanted a checksum auto-update option? I think of updates that just involve updating a release number, you edit it, port fetch, port checksumupdate and you're ready. > You should generally remove lines no longer needed, not comment them > out. If you need to refer to the line later, you can always look up > the older version of the portfile in the Subversion repository. I think on 1.1.7 freeradius didn't supported DESTDIR correctly so I commented it to test why it was there in first place. Thanks for suggestions, I'll fix those Andrea From ryandesign at macports.org Fri May 23 04:56:43 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 May 2008 06:56:43 -0500 Subject: Documenting unreleased features in the guide In-Reply-To: References: Message-ID: My thoughts are that I wouldn't branch the guide and I wouldn't put conditional anything in the XML to generate two documents. Keep a single guide. Do, or do not, indicate which version of MacPorts each feature was introduced in. I like the php documentation because for every php function it says which version of php it was introduced with. For some functions, it has a kind of changelog at the top, showing that in, say, version 4.3.0, the function was added, and in 5.0.3 it was changed in this and that way. This is great because sometimes your web host has an older version of php installed and you need to know that you can't use a function in a certain way, or at all. MacPorts is much smaller in that it has much fewer functions (commands), and also prior versions aren't useful in that once someone syncs their ports tree, they pretty much have to be running the current MacPorts version so they don't run into syntax errors and such. All this is to say that I think it's ok if we just continue documenting new trunk features in the guide without further ado. If we could add an "introduced in" version number next to new things, that would be great, but isn't essential. From wsiegrist at apple.com Fri May 23 07:56:39 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 23 May 2008 07:56:39 -0700 Subject: distfiles.macports.org In-Reply-To: References: <38ED7DA2-C2E1-430B-9445-364F684A552A@apple.com> Message-ID: On May 23, 2008, at 2:32 AM, Ryan Schmidt wrote: > On May 19, 2008, at 14:35, William Siegrist wrote: > >> I've begun experimenting with hosting a distfile mirror on Mac OS >> Forge for MacPorts. This is very much a beta service, so it wont be >> automatically used by MacPorts just yet. But if you have trouble >> fetching a distfile, the checksums fail repeatedly, or you need an >> old distfile, you might try looking here: >> >> http://distfiles.macports.org// > > I hope it's not actually but as defined in > the port. For most ports, will equal but > some ports may override it. > Yes, right now its dist_subdir. It'll probably change though to incorporate the category eventually. -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/20080523/1516fc3f/attachment.p7s From blb at macports.org Fri May 23 11:32:46 2008 From: blb at macports.org (Bryan Blackburn) Date: Fri, 23 May 2008 12:32:46 -0600 Subject: [36832] trunk/dports/archivers/gnutar/Portfile In-Reply-To: <4E3B6876-F0C9-483F-94F7-51DF73850296@macports.org> References: <20080516075528.C9C76169CA86@beta.macosforge.org> <0F656FEC-E3C5-4DE3-9FF1-99DEB24C530F@macports.org> <90EB4D14-FCA6-4EAA-89DC-7F59E8E56542@macports.org> <4E3B6876-F0C9-483F-94F7-51DF73850296@macports.org> Message-ID: <7FEEB9BD-7DA4-4A6E-9A3D-F09AF51E6837@macports.org> On May 23, 2008, at 2:33 AM, Ryan Schmidt wrote: > On May 18, 2008, at 04:34, Markus Weissmann wrote: > >> On 17 May 2008, at 06:47, Ryan Schmidt wrote: >> >>> On May 16, 2008, at 2:55 AM, mww at macports.org wrote: >>> >>>> version 1.20 with workaround for broken gcc-4.0 on 10.5: beta gcc >>>> 4.2 needs to be installed :/ >>> >>>> +platform darwin 9 { >>>> + # gcc 4.0 fails to compile gnutar on 10.5 (probably will get >>>> fixed with XCode 3.1) >>>> + configure.compiler gcc-4.2 >>>> +} >>> >>> Don't you also need to add "depends_lib port:gcc42" in the >>> "platform darwin 9" section then, since MacPorts doesn't >>> automatically add the compiler dependency? >> >> No, this is not the vanilla-gcc installed via MacPorts but the beta >> release of gcc 4.2 from Apple -- which allows universal builds etc.; > > Gotcha! I missed that. > Shouldn't there either be a check in the Portfile for gcc-4.2 (maybe pre-fetch), or otherwise a note about this on the problem hotlist? Otherwise, it'll simply fail with configure: error: C compiler cannot create executables which usually means Xcode is not installed. But if you aren't running the beta version (like I'm not), then Xcode is installed... This can removed of course when 3.1 is no longer beta/under NDA. Bryan >> I don't know if we should introduct a virtual package for this or >> if there should be a "depends_build bin:gcc-4.2:APPLE_STUFF" in >> there. Any thoughts? > > Oh, I think that's probably not necessary. I just wasn't paying > enough attention. > From blb at macports.org Fri May 23 11:37:27 2008 From: blb at macports.org (Bryan Blackburn) Date: Fri, 23 May 2008 12:37:27 -0600 Subject: [36971] trunk/dports/sysutils/freeradius/Portfile In-Reply-To: References: <20080521145025.B8B9516BB0EC@beta.macosforge.org> <412895D3-AD40-4ABF-8B13-9980A36B5AB5@macports.org> Message-ID: On May 23, 2008, at 4:52 AM, Andrea D'Amore wrote: > > ... > By the way did you ever wanted a checksum auto-update option? > I think of updates that just involve updating a release number, you > edit it, port fetch, port checksumupdate and you're ready. > FYI, if you're running trunk (I think it's only trunk and not in 1.6.0), running a 'port checksum' that fails will give you a nice block you can copy/paste into the Portfile with the checksums found. Definitely eases upgrading a Portfile version. Bryan ... >> > > Andrea From eridius at macports.org Fri May 23 15:08:02 2008 From: eridius at macports.org (Kevin Ballard) Date: Fri, 23 May 2008 15:08:02 -0700 Subject: Keeping MacPortsDevelopers up-to-date Message-ID: <7D53D11C-9565-4921-8E4E-0AE4E068CA53@macports.org> Whenever someone gets commit rights, *please* remember to add them to MacPortsDevelopers. At the moment Florian Ebeling is not listed. -Kevin Ballard -- Kevin Ballard http://kevin.sb.org eridius at macports.org http://www.tildesoft.com From ryandesign at macports.org Fri May 23 17:38:26 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 May 2008 19:38:26 -0500 Subject: [37029] trunk/dports/sysutils/freeradius/Portfile In-Reply-To: <20080523142422.B506E16C8B6A@beta.macosforge.org> References: <20080523142422.B506E16C8B6A@beta.macosforge.org> Message-ID: <31D80209-65DD-4275-83FF-8226E505B044@macports.org> On May 23, 2008, at 09:24, andrea.damore at macports.org wrote: > version 2.0.4 > -revision 1 > +revision 0 You probably shouldn't ever decrease a port's revision unless you also simultaneously increase its version. What if someone has already installed freeradius 2.0.4_1? What if you later want to make a change to the portfile which necessitates increasing the revision? You will have to remember at that time to increase the revision to 2 (not 1) so that users who already had the short-lived 2.0.4_1 will be informed via "port outdated" of the new port. In my previous comment, I just wanted to make sure you were aware, for future changes, that the initial revision for a given port's version should be 0, not 1. From ryandesign at macports.org Fri May 23 22:27:07 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 24 May 2008 00:27:07 -0500 Subject: [36898] trunk/dports/net In-Reply-To: <20080517180925.07E5016A2DBE@beta.macosforge.org> References: <20080517180925.07E5016A2DBE@beta.macosforge.org> Message-ID: On May 17, 2008, at 13:09, mr_bond at macports.org wrote: > Log Message: > ----------- > New port sumbission, dynamips version 0.2.8-RC2 (required for GNS3) Thanks for the port! Some suggestions: > Added Paths: > ----------- > trunk/dports/net/dynamips-devel/ > trunk/dports/net/dynamips-devel/Portfile > trunk/dports/net/dynamips-devel/files/ > trunk/dports/net/dynamips-devel/files/patch-Makefile > > Added: trunk/dports/net/dynamips-devel/Portfile > =================================================================== > --- trunk/dports/net/dynamips-devel/ > Portfile (rev 0) > +++ trunk/dports/net/dynamips-devel/Portfile 2008-05-17 18:09:24 > UTC (rev 36898) > @@ -0,0 +1,52 @@ > +# $Id$ > + > +PortSystem 1.0 > + > +name dynamips-devel > +version 0.2.8-RC2 > +revision 1 The initial revision of a version of a port should be 0, not 1. Don't change it now, but keep it in mind for future updates. > +configure {} Could you please use "use_configure no" instead of "configure {}"? Thanks. From andrea.damore at macports.org Fri May 23 23:51:28 2008 From: andrea.damore at macports.org (Andrea D'Amore) Date: Sat, 24 May 2008 08:51:28 +0200 Subject: [37029] trunk/dports/sysutils/freeradius/Portfile In-Reply-To: <31D80209-65DD-4275-83FF-8226E505B044@macports.org> References: <20080523142422.B506E16C8B6A@beta.macosforge.org> <31D80209-65DD-4275-83FF-8226E505B044@macports.org> Message-ID: <8117CA59-064D-4C4C-90AA-8CB59F8E999F@macports.org> On 24/mag/08, at 02:38, Ryan Schmidt wrote: > In my previous comment, I just wanted to make sure you were aware, > for future changes, that the initial revision for a given port's > version should be 0, not 1. Now I am. Moving to 2 then. From ryandesign at macports.org Sat May 24 00:57:12 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 24 May 2008 02:57:12 -0500 Subject: [34950] trunk/dports/lang/ghc/Portfile In-Reply-To: <20080312164111.251D2149CFE7@beta.macosforge.org> References: <20080312164111.251D2149CFE7@beta.macosforge.org> Message-ID: <1EDD59DA-E858-41A8-87B9-1FFC046C2DC5@macports.org> On Mar 12, 2008, at 11:41, gwright at macports.org wrote: > Log Message: > ----------- > Fix reported destroot error caused by not cd'ing to ${worksrcpath}. > +# This should not be necessary, but it seems to work around a bug > +# that exist at least in MP 1.600. > destroot { > - system "${destroot.cmd} ${destroot.target}" > + system "cd ${worksrcpath} && ${destroot.cmd} ${destroot.target}" > } Why override the destroot phase at all? From raimue at macports.org Sat May 24 06:25:21 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 24 May 2008 15:25:21 +0200 Subject: [34950] trunk/dports/lang/ghc/Portfile In-Reply-To: <1EDD59DA-E858-41A8-87B9-1FFC046C2DC5@macports.org> References: <20080312164111.251D2149CFE7@beta.macosforge.org> <1EDD59DA-E858-41A8-87B9-1FFC046C2DC5@macports.org> Message-ID: <48381741.9000002@macports.org> Ryan Schmidt wrote: > On Mar 12, 2008, at 11:41, gwright at macports.org wrote: > >> Log Message: >> ----------- >> Fix reported destroot error caused by not cd'ing to ${worksrcpath}. > >> +# This should not be necessary, but it seems to work around a bug >> +# that exist at least in MP 1.600. >> destroot { >> - system "${destroot.cmd} ${destroot.target}" >> + system "cd ${worksrcpath} && ${destroot.cmd} ${destroot.target}" >> } > > Why override the destroot phase at all? If you use a workaround and reference a bug, also include a ticket number. So later this can be removed after the ticket was fixed. Rainer From randall.h.wood at alexandriasoftware.com Sun May 25 02:39:39 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sun, 25 May 2008 05:39:39 -0400 Subject: Trac problems Message-ID: This morning, Trac is timing out or taking an inordinate amount of time to load. I'm trying to connect from the DC area if that has any bearing. -- Randall Wood randall.h.wood at alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From wsiegrist at apple.com Sun May 25 02:48:57 2008 From: wsiegrist at apple.com (William Siegrist) Date: Sun, 25 May 2008 02:48:57 -0700 Subject: Trac problems In-Reply-To: References: Message-ID: <6B20651A-1555-4AC6-9B6E-B8F9EC74BA96@apple.com> On May 25, 2008, at 2:39 AM, Randall Wood wrote: > This morning, Trac is timing out or taking an inordinate amount of > time to load. I'm trying to connect from the DC area if that has any > bearing. > We had some server problems. They should be fixed now. -Bill ---- 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/20080525/b232656b/attachment.p7s From raimue at macports.org Mon May 26 14:40:34 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Mon, 26 May 2008 23:40:34 +0200 Subject: [37074] trunk/dports/lang In-Reply-To: <20080525235016.5C68516D43E6@beta.macosforge.org> References: <20080525235016.5C68516D43E6@beta.macosforge.org> Message-ID: <483B2E52.5050504@macports.org> landonf at macports.org wrote: > Revision: 37074 > http://trac.macosforge.org/projects/macports/changeset/37074 > Author: landonf at macports.org > Date: 2008-05-25 16:50:14 -0700 (Sun, 25 May 2008) > > Log Message: > ----------- > Add a port for GNU smalltalk We already had this port as "gst". --snip-- $ port info gst gst @3.0.1 (lang) Variants: darwin_6, universal GNU Smalltalk is a free implementation of the Smalltalk-80 language which runs on most versions on Unix and, in general, everywhere you can find a POSIX-compliance library. An uncommon feature of it is that it is well-versed to scripting tasks and headless processing. Homepage: http://smalltalk.gnu.org/ --snap-- Rainer From landonf at macports.org Mon May 26 14:49:30 2008 From: landonf at macports.org (Landon Fuller) Date: Mon, 26 May 2008 14:49:30 -0700 Subject: [37074] trunk/dports/lang In-Reply-To: <483B2E52.5050504@macports.org> References: <20080525235016.5C68516D43E6@beta.macosforge.org> <483B2E52.5050504@macports.org> Message-ID: <4F826A90-4A13-409E-B7C1-6274921081B7@macports.org> On May 26, 2008, at 2:40 PM, Rainer M?ller wrote: > landonf at macports.org wrote: >> Revision: 37074 >> http://trac.macosforge.org/projects/macports/changeset/37074 >> Author: landonf at macports.org >> Date: 2008-05-25 16:50:14 -0700 (Sun, 25 May 2008) >> Log Message: >> ----------- >> Add a port for GNU smalltalk > > We already had this port as "gst". > > --snip-- > $ port info gst > gst @3.0.1 (lang) > Variants: darwin_6, universal > > GNU Smalltalk is a free implementation of the Smalltalk-80 language > which runs > on most versions on Unix and, in general, everywhere you can find a > POSIX-compliance library. An uncommon feature of it is that it is > well-versed to > scripting tasks and headless processing. > Homepage: http://smalltalk.gnu.org/ > --snap-- My mistake, I'd only searched for 'smalltalk'. I'll rename gnu- smalltalk to gst-dev and normalize the ports. Thanks, -landonf -------------- 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/20080526/d22f9f17/attachment.sig From raimue at macports.org Mon May 26 15:35:48 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 27 May 2008 00:35:48 +0200 Subject: [37074] trunk/dports/lang In-Reply-To: <4F826A90-4A13-409E-B7C1-6274921081B7@macports.org> References: <20080525235016.5C68516D43E6@beta.macosforge.org> <483B2E52.5050504@macports.org> <4F826A90-4A13-409E-B7C1-6274921081B7@macports.org> Message-ID: <483B3B44.9030302@macports.org> Landon Fuller wrote: > My mistake, I'd only searched for 'smalltalk'. I'll rename gnu- > smalltalk to gst-dev and normalize the ports. Hm, I thought 'port search' searches in the port name and the description. But it only searches in the name. So at the moment the command $ port echo name:smalltalk or description:smalltalk gives much better results than $ port search smalltalk I openend ticket #15434 [1] for this. Rainer [1] http://trac.macports.org/ticket/15434 From randall.h.wood at alexandriasoftware.com Tue May 27 02:03:45 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Tue, 27 May 2008 05:03:45 -0400 Subject: http://trac.macports.org/ticket/15109 Message-ID: Does port not set the deployment environment to the OS version? See http://trac.macports.org/ticket/15109 -- Randall Wood randall.h.wood at 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 Tue May 27 02:26:18 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 27 May 2008 04:26:18 -0500 Subject: http://trac.macports.org/ticket/15109 In-Reply-To: References: Message-ID: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> On May 27, 2008, at 04:03, Randall Wood wrote: > Does port not set the deployment environment to the OS version? > > See http://trac.macports.org/ticket/15109 MacPorts trunk already sets MACOSX_DEPLOYMENT_TARGET correctly, but MacPorts 1.6.0 does not. Hence, we still have lots of portfiles setting MACOSX_DEPLOYMENT_TARGET manually. From randall.h.wood at alexandriasoftware.com Tue May 27 03:50:34 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Tue, 27 May 2008 06:50:34 -0400 Subject: Fwd: http://trac.macports.org/ticket/15109 In-Reply-To: References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> Message-ID: Stupid me hit "Reply" not "Reply-all" ---------- Forwarded message ---------- From: Randall Wood Date: Tue, May 27, 2008 at 6:49 AM Subject: Re: http://trac.macports.org/ticket/15109 To: Ryan Schmidt SO when are we planning on getting a macports (1.6.1, 1.7.0) out that addresses this issue? On Tue, May 27, 2008 at 5:26 AM, Ryan Schmidt wrote: > > On May 27, 2008, at 04:03, Randall Wood wrote: > >> Does port not set the deployment environment to the OS version? >> >> See http://trac.macports.org/ticket/15109 > > MacPorts trunk already sets MACOSX_DEPLOYMENT_TARGET correctly, but MacPorts > 1.6.0 does not. Hence, we still have lots of portfiles setting > MACOSX_DEPLOYMENT_TARGET manually. > > -- Randall Wood randall.h.wood at alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." -- Randall Wood randall.h.wood at alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From raimue at macports.org Tue May 27 04:29:20 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 27 May 2008 13:29:20 +0200 Subject: Merging to the release_1_6 branch (was: Re: Fwd: http://trac.macports.org/ticket/15109) In-Reply-To: References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> Message-ID: <483BF090.3060209@macports.org> Randall Wood wrote: > SO when are we planning on getting a macports (1.6.1, 1.7.0) out that > addresses this issue? There were a lot of changes to trunk. But not all of them are suited for inclusion in a 1.6.1 release. To make a 1.6.1 release a lot of revisions still need to get merged to the release_1_6 branch, but currently we don't have any guidelines who should do the merge. See the 1.6.1 milestone, all tickets are still open because nothing was merged to release_1_6 yet. This makes it difficult to track the progress for this release. Should the base developers just merge back what should be included in 1.6.1 judged by themselves? Or should we put up some system for nominating revisions for merging and let the release manager do it? There is no mention how the merging should be done in our ReleaseProcess documentation at [1]. I think the approach until now was to review the svn log of trunk and merge back what is needed, but this is a long list. The ChangeLog can be a good hint, but not all revisions which need to get merged might be noted down there. So I am in favor of nominating revisions by everyone and merging by one person (or a small group) coordinating the release. As I said before, some features have already been merged to release_1_6, see [2] for reference. Rainer [1] http://trac.macports.org/browser/trunk/base/portmgr/ReleaseProcess [2] http://lists.macosforge.org/pipermail/macports-dev/2008-May/005112.html From febeling at macports.org Tue May 27 09:25:54 2008 From: febeling at macports.org (Caspar Florian Ebeling) Date: Tue, 27 May 2008 18:25:54 +0200 Subject: Ruby 1.9 port Message-ID: <5cbbe4ae0805270925n5ba56b9el5d62a07898061c3f@mail.gmail.com> Hi, I have prepared port for Ruby 1.9. I could just commit it, but I wanted to hear your opinion on a few things, before these become facts, on which users might rely. * Name: I tend to call it ruby19. Another option would be ruby-devel, but 1.9 is mildly incompatible, and Python ports use a similar approach, for the same reason, I think. There will probably not be a point in time when we would want to switch ruby-devel to be the new ruby because of that, so the version suffixing seems to be appropriate. * Accordingly, binaries have to be suffixed to be able to live alongside the established ones. There will be ruby, irb, ri, etc. and ruby1.9, irb1.9, ri1.9, etc. * The regular rb-* ports would live in directories which where not visible in the path, because usually you would run the setup.rb from the old binary which brings the $Config::CONFIG along, telling it where to put stuff. So packages would not be found automatically -- a rather good thing though, given the incompatibilities. Still this port would trigger need for them, I guess, once it's there. What do you think about these points? Is there a bigger ruby roadmap I overlooked, or somebody who coordinates ruby issues? Once something like "MacPorts Alternatives" is there it might be interesting to have an overarching ruby abstract port, or whatever it's called then, but that's quite compatible with this. What do you think? Florian -- Florian Ebeling florian.ebeling at gmail.com From jkh at apple.com Tue May 27 10:52:08 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue, 27 May 2008 10:52:08 -0700 Subject: Merging to the release_1_6 branch (was: Re: Fwd: http://trac.macports.org/ticket/15109) In-Reply-To: <483BF090.3060209@macports.org> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> Message-ID: This is why I think that releases should be tags on trunk, with a convergence period before each release. This project is not big enough and does not have the manpower or written guidelines and a release engineer driving the process on a daily basis which are necessary to really do a two-branch model. That is merely my opinion, of course, but it's driven by some experience in this area. - Jordan On May 27, 2008, at 4:29 AM, Rainer M?ller wrote: > Randall Wood wrote: >> SO when are we planning on getting a macports (1.6.1, 1.7.0) out that >> addresses this issue? > > There were a lot of changes to trunk. But not all of them are suited > for > inclusion in a 1.6.1 release. > > To make a 1.6.1 release a lot of revisions still need to get merged to > the release_1_6 branch, but currently we don't have any guidelines who > should do the merge. See the 1.6.1 milestone, all tickets are still > open > because nothing was merged to release_1_6 yet. This makes it difficult > to track the progress for this release. > > Should the base developers just merge back what should be included in > 1.6.1 judged by themselves? Or should we put up some system for > nominating revisions for merging and let the release manager do it? > > There is no mention how the merging should be done in our > ReleaseProcess > documentation at [1]. I think the approach until now was to review the > svn log of trunk and merge back what is needed, but this is a long > list. > The ChangeLog can be a good hint, but not all revisions which need to > get merged might be noted down there. So I am in favor of nominating > revisions by everyone and merging by one person (or a small group) > coordinating the release. > > As I said before, some features have already been merged to > release_1_6, > see [2] for reference. > > Rainer > > [1] http://trac.macports.org/browser/trunk/base/portmgr/ReleaseProcess > [2] http://lists.macosforge.org/pipermail/macports-dev/2008-May/005112.html > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From febeling at macports.org Tue May 27 12:47:47 2008 From: febeling at macports.org (Caspar Florian Ebeling) Date: Tue, 27 May 2008 21:47:47 +0200 Subject: Merging to the release_1_6 branch (was: Re: Fwd: http://trac.macports.org/ticket/15109) In-Reply-To: <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> Message-ID: <5cbbe4ae0805271247j3c9d1103q4c005d39f90eebbf@mail.gmail.com> > This is why I think that releases should be tags on trunk, with a > convergence period before each release. This project is not big > enough and does not have the manpower or written guidelines and a > release engineer driving the process on a daily basis which are > necessary to really do a two-branch model. That is merely my opinion, > of course, but it's driven by some experience in this area. This is exactly what I have been preaching, but I think it changes with Git. I know that saying this might well be boring by now, but Git eases the whole branch handling a lot. And svnmerge.py is really not a substitute here. I used it for a feature branch of a project and some file renamings made things go haywire. It was certainly not the reassurement your actually want to get out of version control. But git mostly makes branches a private thing, so that effectively their number rather gets reduced, or at least the number of public ones gets reduced. The existing branches tend to be feature-specific, and mainline stays sane because branches only get merged in once they are not questionable anymore. Florian -- Florian Ebeling florian.ebeling at gmail.com -- Florian Ebeling florian.ebeling at gmail.com From raimue at macports.org Tue May 27 12:48:25 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 27 May 2008 21:48:25 +0200 Subject: Merging to the release_1_6 branch In-Reply-To: References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> Message-ID: <483C6589.2030104@macports.org> Jordan K. Hubbard wrote: > This is why I think that releases should be tags on trunk, with a > convergence period before each release. This project is not big > enough and does not have the manpower or written guidelines and a > release engineer driving the process on a daily basis which are > necessary to really do a two-branch model. That is merely my opinion, > of course, but it's driven by some experience in this area. If we would do this the way you describe, every new feature would have to be developed on a different branch. It could just be merged in as we prepare a new major release. This is absolutely not practical, as nobody would test new code/features and it would create even more branches which need merging. Also, this approach need to do code freezes which would make development on this project even more slow than it currently is. There is unfinished stuff on trunk at the moment which I would not want to appear in a release, because it is not ready for public consumption. For example registry2.0 (okay, we already included that... why?) and the half-baked implementation of 'port help'. Rainer From simon at ruderich.com Tue May 27 12:53:15 2008 From: simon at ruderich.com (Simon Ruderich) Date: Tue, 27 May 2008 21:53:15 +0200 Subject: [MacPorts] #15402: Warning: the following items did not execute (for mutt): org.macports.patch In-Reply-To: <4DCEF0FE-A7C8-4C42-8A46-4E5577B03379@gmail.com> References: <060.a3bf4ddd9d6f2b5f6c52bf4a0449db22@macports.org> <069.a70439e6e72df1fde3bfdd6a53965829@macports.org> <4DCEF0FE-A7C8-4C42-8A46-4E5577B03379@gmail.com> Message-ID: <20080527195315.GA9145@ruderich.com> On Tue, May 27, 2008 at 12:22:39PM -0400, Charles Darwin wrote: > > > sudo port -d selfupdate > ? > 12:20:42> sudo port clean --all mutt > ---> Cleaning mutt > 12:20:51> sudo port -dsc patch mutt +imap +ssl +buffy +compress +imap_headercache Sorry, normally you have to wait 12 hours until the updated version can be fetched with "selfupdate". To use the new version right away, download the Portfile from [1] and cd to the directory where you saved it and run > sudo port install +imap +ssl +buffy +compress +imap_headercache Hope this helps, Simon [1]: http://trac.macports.org/browser/trunk/dports/mail/mutt/Portfile -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080527/0b351602/attachment.sig From raimue at macports.org Tue May 27 13:35:46 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Tue, 27 May 2008 22:35:46 +0200 Subject: [MacPorts] #15402: Warning: the following items did not execute (for mutt): org.macports.patch In-Reply-To: <20080527195315.GA9145@ruderich.com> References: <060.a3bf4ddd9d6f2b5f6c52bf4a0449db22@macports.org> <069.a70439e6e72df1fde3bfdd6a53965829@macports.org> <4DCEF0FE-A7C8-4C42-8A46-4E5577B03379@gmail.com> <20080527195315.GA9145@ruderich.com> Message-ID: <483C70A2.8030409@macports.org> Simon Ruderich wrote: > On Tue, May 27, 2008 at 12:22:39PM -0400, Charles Darwin wrote: >>> sudo port -d selfupdate >> ? >> 12:20:42> sudo port clean --all mutt >> ---> Cleaning mutt >> 12:20:51> sudo port -dsc patch mutt +imap +ssl +buffy +compress +imap_headercache > > Sorry, normally you have to wait 12 hours until the updated version can be > fetched with "selfupdate". To use the new version right away, download the > Portfile from [1] and cd to the directory where you saved it and run This is not correct. The rsync server is updated every hour, just the PortIndex only gets regenerated every 12 hours. So something like this should work even before the PortIndex is updated (which would only be interesting for port upgrade): sudo port sync sudo port clean mutt sudo port build mutt +imap +ssl +buffy +compress +imap_headercache If this worked fine, you can replace your current mutt with it: sudo port deactivate mutt sudo port install mutt And optionally of course: sudo port -f uninstall mutt @old_version Rainer From raimue at macports.org Tue May 27 13:38:01 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Tue, 27 May 2008 22:38:01 +0200 Subject: Merging to the release_1_6 branch In-Reply-To: <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> Message-ID: <483C7129.9080807@macports.org> Caspar Florian Ebeling wrote: > This is exactly what I have been preaching, but I think it changes > with Git. I know that saying this might well be boring by now, but Git > eases the whole branch handling a lot. And svnmerge.py is really > not a substitute here. I used it for a feature branch of a project and > some file renamings made things go haywire. It was certainly not > the reassurement your actually want to get out of version control. Git is just another version control system and does not decide if we make feature branches or not. Yes, merging in Subversion is not the best, but this will become a lot better with Subversion 1.5. I don't think we have to discuss different version control systems and their advantages here. Basically, they are all the same. You got a main line and branches. So we have to decide how to use branches, not which system stores our branches. Jordan brings up the idea not to use branches at all, but to make releases from the main line. I don't agree that this would be sane, even if it comes from his experience. How would we do minor releases for bugfixes without branches? I can only think of checking out the tag, applying (multiple?) patches and creating a new tag from it. Which would not give you any control to see what you applied and you would also need to apply that separately to the main line without any connection between the two commits! Gosh. I really don't think we want to do it this way. > But git mostly makes branches a private thing, so that effectively > their number rather gets reduced, or at least the number of public > ones gets reduced. The existing branches tend to be feature-specific, > and mainline > stays sane because branches only get merged in once they are > not questionable anymore. So who tests your new code? You privately and nobody else? And you never test it together with other features which could even break it? Doesn't sound like a good idea to me. Rainer From febeling at macports.org Tue May 27 15:06:53 2008 From: febeling at macports.org (Caspar Florian Ebeling) Date: Wed, 28 May 2008 00:06:53 +0200 Subject: Merging to the release_1_6 branch In-Reply-To: <483C7129.9080807@macports.org> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> Message-ID: <5cbbe4ae0805271506l4bfcd14bge1f73e0931584728@mail.gmail.com> > Git is just another version control system and does not decide if we make > feature branches or not. Yes, merging in Subversion is not the best, but > this will become a lot better with Subversion 1.5. I don't think we have to > discuss different version control systems and their advantages here. > Basically, they are all the same. You got a main line and branches. So we > have to decide how to use branches, not which system stores our branches. I could have argued this way. Actually I used to think that people who want to solve problems with tools were quite dumb. But Git makes a bit of a difference. > Jordan brings up the idea not to use branches at all, but to make releases > from the main line. I don't agree that this would be sane, even if it comes > from his experience. How would we do minor releases for bugfixes without > branches? I can only think of checking out the tag, applying (multiple?) > patches and creating a new tag from it. Which would not give you any control > to see what you applied and you would also need to apply that separately to > the main line without any connection between the two commits! Gosh. Yeah, and that's the whole problem. With svn you dump all your new half-cooked, half-done features into trunk. With Git it's the reverse situation. You do the dangerous things in branches and can assume that mainline is reasonably in shape. That's only a tendency. But I know from exprience why I don't want to release things from trunk under svn usually. And if only complete, well-understood features would go into it, I would feel different. It's a bit like not comitting with subversion for 10 days, but having everything in the undo history, or something. >> But git mostly makes branches a private thing, so that effectively >> their number rather gets reduced, or at least the number of public >> ones gets reduced. The existing branches tend to be feature-specific, >> and mainline >> stays sane because branches only get merged in once they are >> not questionable anymore. > > So who tests your new code? You privately and nobody else? And you never > test it together with other features which could even break it? Doesn't > sound like a good idea to me. Of course you would have it tested by a broader audience, after merged to master. And you would sync releases so that you have a grace period for that. But you don't run trunk all the time, with half-feature A, 3/4 of B and all of C, but only C. And then all of B, when it's author is happy. Etc. That does not solve eberything, but it's better. New tools are not always not the solution :) Florian -- Florian Ebeling florian.ebeling at gmail.com From blair at orcaware.com Tue May 27 15:17:56 2008 From: blair at orcaware.com (Blair Zajac) Date: Tue, 27 May 2008 15:17:56 -0700 Subject: Merging to the release_1_6 branch In-Reply-To: <5cbbe4ae0805271506l4bfcd14bge1f73e0931584728@mail.gmail.com> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <5cbbe4ae0805271506l4bfcd14bge1f73e0931584728@mail.gmail.com> Message-ID: <483C8894.8050106@orcaware.com> Caspar Florian Ebeling wrote: >> Git is just another version control system and does not decide if we make >> feature branches or not. Yes, merging in Subversion is not the best, but >> this will become a lot better with Subversion 1.5. I don't think we have to >> discuss different version control systems and their advantages here. >> Basically, they are all the same. You got a main line and branches. So we >> have to decide how to use branches, not which system stores our branches. > > I could have argued this way. Actually I used to think that people who > want to solve problems with tools were quite dumb. But Git makes a bit of > a difference. > >> Jordan brings up the idea not to use branches at all, but to make releases >> from the main line. I don't agree that this would be sane, even if it comes >> from his experience. How would we do minor releases for bugfixes without >> branches? I can only think of checking out the tag, applying (multiple?) >> patches and creating a new tag from it. Which would not give you any control >> to see what you applied and you would also need to apply that separately to >> the main line without any connection between the two commits! Gosh. > > Yeah, and that's the whole problem. With svn you dump all your new half-cooked, > half-done features into trunk. With Git it's the reverse situation. > You do the dangerous > things in branches and can assume that mainline is reasonably in shape. That's > only a tendency. But I know from exprience why I don't want to release things > from trunk under svn usually. And if only complete, well-understood > features would go > into it, I would feel different. It's a bit like not comitting with > subversion for 10 > days, but having everything in the undo history, or something. Well, we should have feature branches in svn for half-cooked and half-done and when they are ready, have them reviewed and merged into trunk. The differences between svn/git isn't the issue here, it's how the code is being managed. We can have a MacPorts policy that all new work is being done on a branch and trunk is pretty stable code in it. Having one other review the work before merging into trunk could be required. Blair From raimue at macports.org Tue May 27 15:50:15 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Wed, 28 May 2008 00:50:15 +0200 Subject: Merging to the release_1_6 branch In-Reply-To: <5cbbe4ae0805271506l4bfcd14bge1f73e0931584728@mail.gmail.com> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <5cbbe4ae0805271506l4bfcd14bge1f73e0931584728@mail.gmail.com> Message-ID: <483C9027.5080904@macports.org> Caspar Florian Ebeling wrote: > Yeah, and that's the whole problem. With svn you dump all your new half-cooked, > half-done features into trunk. With Git it's the reverse situation. > You do the dangerous > things in branches and can assume that mainline is reasonably in shape. That's > only a tendency. But I know from exprience why I don't want to release things > from trunk under svn usually. And if only complete, well-understood > features would go > into it, I would feel different. It's a bit like not comitting with > subversion for 10 > days, but having everything in the undo history, or something. Now you are talking about feature branches here, while I was referring to release branches in my statement before. > Of course you would have it tested by a broader audience, after merged to > master. And you would sync releases so that you have a grace period for that. > But you don't run trunk all the time, with half-feature A, 3/4 of B and > all of C, but only C. And then all of B, when it's author is happy. Etc. That > does not solve eberything, but it's better. I agree with you here that feature branches should only be merged then they are considered to be complete by the author(s) of this feature. But now we are in the discussion about feature branches while I initially started to talk about release branches. Let's stick to release branches as it is more important for now to get a 1.6.1 release. Rainer From jkh at apple.com Tue May 27 15:54:28 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue, 27 May 2008 15:54:28 -0700 Subject: Merging to the release_1_6 branch (was: Re: Fwd: http://trac.macports.org/ticket/15109) In-Reply-To: <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> Message-ID: <3AFD5C2D-48DA-4C73-B475-2D3413138940@apple.com> On May 27, 2008, at 12:38 PM, Caspar Florian Ebeling wrote: > This is exactly what I have been preaching, but I think it changes > with Git. I know that saying this might well be boring by now, but Git > eases the whole branch handling a lot. And svnmerge.py is really > not a substitute here. I used it for a feature branch of a project and > some file renamings made things go haywire. It was certainly not > the reassurement your actually want to get out of version control. I think that's a side alley best avoided for now. Conflating the "we should all use VCS $x!" and "we should have proper release engineering practices!" issues only raises the odds significantly that neither one will be addressed. - Jordan From jkh at apple.com Tue May 27 16:06:15 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue, 27 May 2008 16:06:15 -0700 Subject: Merging to the release_1_6 branch In-Reply-To: <483C6589.2030104@macports.org> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <483C6589.2030104@macports.org> Message-ID: <9D2A3C62-08D1-4404-A065-F38378816BFC@apple.com> On May 27, 2008, at 12:48 PM, Rainer M?ller wrote: > If we would do this the way you describe, every new feature would > have to be developed on a different branch. I think this depends entirely on what you call "a feature." If by "feature" you mean "something which is going to take a long time to do and may or may not even result in success" then sure, you're going to put it on a branch. You would have always put it on a branch, in fact, since a feature like this is disruptive even to other work in trunk so "good branch practices" still apply and what we're talking about doesn't even really matter to you since your modus operandi is going to be the same either way. If, on the other hand, you are talking about "ongoing improvements and some amount of WIP" when you say "feature" then that's fine. You can still absolutely release trunk periodically, after a convergence period, and have that kind of work going on in the VCS. It just takes a bit of clear communication amongst the developers and the release engineer as well as a commitment to working that way, e.g. by following certain engineering practices like always having enough "configuration switches" in the tree such that WIPs can be turned off by default and only enabled by those wishing to participate in the WIP (and I'm not talking about anything complex when I say "configuration switches" - they can be everything from compilation options to crude developer-only runtime settings). - Jordan From jkh at apple.com Tue May 27 16:19:19 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue, 27 May 2008 16:19:19 -0700 Subject: Merging to the release_1_6 branch In-Reply-To: <483C7129.9080807@macports.org> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> Message-ID: <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> On May 27, 2008, at 1:38 PM, Rainer M?ller wrote: > Jordan brings up the idea not to use branches at all, but to make > releases from the main line. [ ... ] How would we do minor releases > for bugfixes without branches? Easy. In Subversion, tags and branches are the same thing - it's just a matter of convention. If you need to do minor releases for anything you've already released, you just promote your release tag to a branch and start checking in everything on that branch. You create it on- demand, in other words, and if you never need to make a minor release then that release tag just stays a tag. You've yet to raise an issue which suggests anything but unfamiliarity with the process, Rainer. - Jordan From lists-macports at shopwatch.org Tue May 27 16:41:26 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Tue, 27 May 2008 19:41:26 -0400 Subject: Ruby 1.9 port In-Reply-To: <5cbbe4ae0805270925n5ba56b9el5d62a07898061c3f@mail.gmail.com> References: <5cbbe4ae0805270925n5ba56b9el5d62a07898061c3f@mail.gmail.com> Message-ID: <483C9C26.3070401@shopwatch.org> Caspar Florian Ebeling wrote: > * Name: I tend to call it ruby19. Another option would be ruby-devel, > but 1.9 is mildly incompatible, I'd say more than mildly! And 1.9.0, at least, is explicitly NOT production-ready. ruby19 sounds logical. I don't know if there's a naming standard on macports, but "-dev" and "-devel" package suffixes on both Red Hat- and Debian-based Linux distros mean "the include files you'll need to compile against this package/library". So I'd recommend against -devel. Jay Levitt From raimue at macports.org Tue May 27 16:51:58 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 28 May 2008 01:51:58 +0200 Subject: Ruby 1.9 port In-Reply-To: <483C9C26.3070401@shopwatch.org> References: <5cbbe4ae0805270925n5ba56b9el5d62a07898061c3f@mail.gmail.com> <483C9C26.3070401@shopwatch.org> Message-ID: <483C9E9E.2010103@macports.org> Jay Levitt wrote: > I don't know if there's a naming standard on macports, but "-dev" and > "-devel" package suffixes on both Red Hat- and Debian-based Linux > distros mean "the include files you'll need to compile against this > package/library". So I'd recommend against -devel. It is the naming convention for MacPorts as it was borrowed from FreeBSD ports. Beta releases/Release candidates get a -devel suffix. Although it makes dependencies a bit complicated, it is the only way we currently have for this, as MacPorts can't handle multiple versions of the same port at the moment. Rainer From ryandesign at macports.org Tue May 27 17:22:07 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 27 May 2008 19:22:07 -0500 Subject: Ruby 1.9 port In-Reply-To: <483C9C26.3070401@shopwatch.org> References: <5cbbe4ae0805270925n5ba56b9el5d62a07898061c3f@mail.gmail.com> <483C9C26.3070401@shopwatch.org> Message-ID: <787C7271-2836-4F66-8030-D79BBA09065A@macports.org> On May 27, 2008, at 18:41, Jay Levitt wrote: > Caspar Florian Ebeling wrote: > >> * Name: I tend to call it ruby19. Another option would be ruby-devel, >> but 1.9 is mildly incompatible, > > I'd say more than mildly! And 1.9.0, at least, is explicitly NOT > production-ready. ruby19 sounds logical. > > I don't know if there's a naming standard on macports, but "-dev" and > "-devel" package suffixes on both Red Hat- and Debian-based Linux > distros mean "the include files you'll need to compile against this > package/library". So I'd recommend against -devel. MacPorts ports already include the headers. The port suffix "-devel" in MacPorts means "the development version of the software". Please see: http://trac.macports.org/ticket/14540 If 1.9.0 is explicitly not production-ready, then "ruby-devel" seems an appropriate port name. Later, when 1.9.x becomes production-ready, it can be decided whether this should become the new ruby port, or whether a new port ruby19 should be added. From raimue at macports.org Tue May 27 18:28:16 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 28 May 2008 03:28:16 +0200 Subject: Merging to the release_1_6 branch In-Reply-To: <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> Message-ID: <483CB530.3030408@macports.org> Jordan K. Hubbard wrote: > On May 27, 2008, at 1:38 PM, Rainer M?ller wrote: > >> Jordan brings up the idea not to use branches at all, but to make >> releases from the main line. [ ... ] How would we do minor releases >> for bugfixes without branches? > > Easy. In Subversion, tags and branches are the same thing - it's just > a matter of convention. If you need to do minor releases for anything > you've already released, you just promote your release tag to a branch > and start checking in everything on that branch. You create it on- > demand, in other words, and if you never need to make a minor release > then that release tag just stays a tag. Hm, this sounds like you propose here to make release branches without using tags. Branching off a release from trunk, but never do any tags. Or tagging and break the immutability of the tag by changing it. Whatever, but this makes it more clear what you mean. But tagging releases wouldn't harm, would it? What I didn't like about your initial proposal was the "convergence period" which I interpreted to put trunk into code freeze. In my opinion, you should branch off the release if you think the current feature set in trunk would make a good release and stabilize the code on this release branch. Then you roll the release. And that all while work on trunk continues as normal. > You've yet to raise an issue which suggests anything but unfamiliarity > with the process, Rainer. Yes, I admit that I may be unfamiliar with every way of software development used out there and that I am not so good by understanding your proposal which was just made up of one sentence. I know the "standard" way with trunk, branches and tags as I use Subversion for some years. You didn't elaborate much in your first mail how you want to do it. But how do you solve my initial question? Who should merge patches to the release branch (or call it tag)? In my opinion the same issue occurs here. What we have now on release_1_6 and trunk is a case where we can't introduce another scheme of doing branches right now. We need a solution how to do it for 1.6.x and can then maybe decide to use another way for 1.7.x. Rainer From jkh at apple.com Tue May 27 19:21:10 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue, 27 May 2008 19:21:10 -0700 Subject: Merging to the release_1_6 branch In-Reply-To: <483CB530.3030408@macports.org> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> <483CB530.3030408@macports.org> Message-ID: <493768C3-CB53-4CCF-A072-AED9C1369D2E@apple.com> On May 27, 2008, at 6:28 PM, Rainer M?ller wrote: > Hm, this sounds like you propose here to make release branches > without using tags. No. From the very beginning of my proposal (please go back and read my first message again) I have suggested making releases WITH tags. WITH. - Jordan From jkh at apple.com Tue May 27 22:09:55 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue, 27 May 2008 22:09:55 -0700 Subject: Merging to the release_1_6 branch In-Reply-To: <483CB530.3030408@macports.org> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> <483CB530.3030408@macports.org> Message-ID: <7A4ECD06-F0C3-4691-B3FC-0C181668C89E@apple.com> On May 27, 2008, at 6:28 PM, Rainer M?ller wrote: > What I didn't like about your initial proposal was the "convergence > period" which I interpreted to put trunk into code freeze. In my > opinion, you should branch off the release if you think the current > feature set in trunk would make a good release and stabilize the > code on this release branch. Then you roll the release. And that all > while work on trunk continues as normal. Code freezes are more like "code slushes" in trunk and can be done without too much disruption. Also, if the tree is so unready to release at a given time that it would require weeks of code freeze to stabilize, you simply don't release then. I have also seen releases done by essentially going backwards in time; you figure out that the tree was a lot more stable a week ago than today, you check out the tree as of one week ago and release that. I'm not saying that release branches don't have their place - of course they do, if you have the manpower to do things that way every time and you have a clear idea of what the goals are for each release. For macports, however, it seems like the current goals are best expressed as "release when it's usable" and that's fine. You can, however, do that without a branch or someone having to decide what goes into it. - Jordan From jmr at macports.org Tue May 27 22:57:01 2008 From: jmr at macports.org (Joshua Root) Date: Wed, 28 May 2008 15:57:01 +1000 Subject: Merging to the release_1_6 branch In-Reply-To: <7A4ECD06-F0C3-4691-B3FC-0C181668C89E@apple.com> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> <483CB530.3030408@macports.org> <7A4ECD06-F0C3-4691-B3FC-0C181668C89E@apple.com> Message-ID: <483CF42D.20207@macports.org> Jordan K. Hubbard wrote: > On May 27, 2008, at 6:28 PM, Rainer M?ller wrote: > >> What I didn't like about your initial proposal was the "convergence >> period" which I interpreted to put trunk into code freeze. In my >> opinion, you should branch off the release if you think the current >> feature set in trunk would make a good release and stabilize the >> code on this release branch. Then you roll the release. And that all >> while work on trunk continues as normal. > > Code freezes are more like "code slushes" in trunk and can be done > without too much disruption. Also, if the tree is so unready to > release at a given time that it would require weeks of code freeze to > stabilize, you simply don't release then. I have also seen releases > done by essentially going backwards in time; you figure out that the > tree was a lot more stable a week ago than today, you check out the > tree as of one week ago and release that. I would have no objection to tagging trunk today and calling it an -rc1. Well, except that there are apparently some bug fixes in the 1.6 branch that are not in trunk - argh! - Josh From raimue at macports.org Tue May 27 23:40:34 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 28 May 2008 08:40:34 +0200 Subject: Merging to the release_1_6 branch In-Reply-To: <493768C3-CB53-4CCF-A072-AED9C1369D2E@apple.com> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> <483CB530.3030408@macports.org> <493768C3-CB53-4CCF-A072-AED9C1369D2E@apple.com> Message-ID: <483CFE62.7010206@macports.org> Jordan K. Hubbard wrote: > On May 27, 2008, at 6:28 PM, Rainer M?ller wrote: > >> Hm, this sounds like you propose here to make release branches >> without using tags. > > No. From the very beginning of my proposal (please go back and read > my first message again) I have suggested making releases WITH tags. > WITH. If you are going to change a copy, it is not a tag. A tag is immutable. So, you make a branch as you proposed to change it later. Please stick to the usual terminology. Rainer From raimue at macports.org Tue May 27 23:52:16 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Wed, 28 May 2008 08:52:16 +0200 Subject: Merging to the release_1_6 branch In-Reply-To: <483CF42D.20207@macports.org> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> <483CB530.3030408@macports.org> <7A4ECD06-F0C3-4691-B3FC-0C181668C89E@apple.com> <483CF42D.20207@macports.org> Message-ID: <483D0120.8030405@macports.org> Joshua Root wrote: > I would have no objection to tagging trunk today and calling it an -rc1. > Well, except that there are apparently some bug fixes in the 1.6 branch > that are not in trunk - argh! But you would definitely tag that 1.7.0-rc1 not 1.6.1-rc1. And where do you fix a bug found in that rc1? On and trunk and you merge it back to the 1.7.x release branch. So you definitely need a 1.7.x branch and there is no way to make that from trunk as it could get other changes in the mean time which are not suited for a release. If we would not make a release branch as suggested by Jordan and make the release from trunk, trunk would have to go into code freeze until the final release is there. So if a release was near, I would do (with some pseudo-shell commands): svn cp trunk branches/release_1_7 svn cp branches/release_1_7 tags/release_1_7_0-rc1 Bug fixes go to branches/release_1_7. Anything can happen on trunk in the mean time. If the release candidate was considered bug free, svn cp branches/release_1_7 tags/release_1_7_0 And then release from that tag. This is how it should be done in my opinion, if I was any unclear in my previous explanations. And I think this is also the way we do it already, except the fact that some new features were merged back to release_1_6. Why did this happen? Because nobody watches the merges or it is not clear who does the merging at all. And now please back to my initial question. Rainer From febeling at macports.org Wed May 28 02:30:43 2008 From: febeling at macports.org (Caspar Florian Ebeling) Date: Wed, 28 May 2008 11:30:43 +0200 Subject: Ruby 1.9 port In-Reply-To: <787C7271-2836-4F66-8030-D79BBA09065A@macports.org> References: <5cbbe4ae0805270925n5ba56b9el5d62a07898061c3f@mail.gmail.com> <483C9C26.3070401@shopwatch.org> <787C7271-2836-4F66-8030-D79BBA09065A@macports.org> Message-ID: <5cbbe4ae0805280230t1e19e11cn7d0a84849302c51e@mail.gmail.com> >>> * Name: I tend to call it ruby19. Another option would be ruby-devel, >>> but 1.9 is mildly incompatible, >> >> I'd say more than mildly! And 1.9.0, at least, is explicitly NOT >> production-ready. ruby19 sounds logical. >> >> I don't know if there's a naming standard on macports, but "-dev" and >> "-devel" package suffixes on both Red Hat- and Debian-based Linux >> distros mean "the include files you'll need to compile against this >> package/library". So I'd recommend against -devel. > > MacPorts ports already include the headers. The port suffix "-devel" in > MacPorts means "the development version of the software". Please see: > > http://trac.macports.org/ticket/14540 > > If 1.9.0 is explicitly not production-ready, then "ruby-devel" seems an > appropriate port name. Later, when 1.9.x becomes production-ready, it can be > decided whether this should become the new ruby port, or whether a new port > ruby19 should be added. I think this can be decided now and does not need to be deferred. Ruby 1.9 is incompatible, and not by accident, but by design. One of the goals for 1.9 was actually cleaning up syntax. See more about the differences here [1]. And this "not production-ready" is not clear either. My webhoster provides 1.9 in the standard basic web plan already. Of course, Matz has not announced it to be stable release, but it is features-frozen quite a while. And 1.9 became a "testing" packages in Debian in May 2006 for the first time. Here [2] more about the status, but the article dates back to January already (15 days after the 1.9.0 release). Debian (with Ubuntu) seems to be the only Linux with includes 1.9 so far, though. But they go the same route which i propose and call it ruby1.9. And fundamentally, MP knows both approaches. php4, php5, python2[1-5], and so on. So both techniques seem to be possible. But let's examine the devel approach a bit more in detail. Coming to the points made in the above mentioned "-devel" ticket, there is another reason not to use this approach, I think: > -devel ports install software in the same places as their > non-devel counterparts, so that -devel ports can satisfy > a dependency via the same files as the equivalent non-devel > port, with the side-effect that you cannot have both the > -devel and the non-devel port activated at the same time This we probably don't want. Rather install them alongside each other. As said earlier, the ruby executable carries a config hash with it, which tells it its library locations among other things. The lib search paths contains PREFIX, etc, information from the build pahse, but also the ruby version. So it depends on the executable that runs setup.rb where a lib gets installed, when you do this step, e.g. And it becomes invisible when you run the other version, because ruby inferes the lib path form this same config table. And if libs are not present any more when running the alternative version, this silently switching to another executable becomes pretty pointless. Those are the reasons why I think the name should be ruby19, i.e. a new package in the namespace. But I wonder how to deal with all the libraries then. That can probably only be fixed by adding again all the rb packages as rb19 or something, like it is with python already. On the other hand, we can address the lib issues only once we have a ruby19 to depend them on, and only then can prepare for the time when it is ripe for production. Florian [1] http://eigenclass.org/hiki/Changes+in+Ruby+1.9 [2] http://www.infoq.com/news/2008/01/ruby-19-for-production -- Florian Ebeling florian.ebeling at gmail.com From jkh at apple.com Wed May 28 02:48:53 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Wed, 28 May 2008 02:48:53 -0700 Subject: Merging to the release_1_6 branch In-Reply-To: <483CFE62.7010206@macports.org> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> <483CB530.3030408@macports.org> <493768C3-CB53-4CCF-A072-AED9C1369D2E@apple.com> <483CFE62.7010206@macports.org> Message-ID: <52253A69-7E52-4CD0-8B0D-12328EF455D4@apple.com> As I stated earlier, if you did not make point releases from a given release then it wouldn't be a branch- it would be immutable and therefore te default MO would be to make it a tag. I'm all for using the correct semantics, but the semantics here are variable based on subsequent events and I don't know how else to explain that to you. - Jordan On May 27, 2008, at 11:40 PM, Rainer M?ller wrote: > Jordan K. Hubbard wrote: >> On May 27, 2008, at 6:28 PM, Rainer M?ller wrote: >>> Hm, this sounds like you propose here to make release branches >>> without using tags. >> No. From the very beginning of my proposal (please go back and >> read my first message again) I have suggested making releases WITH >> tags. WITH. > If you are going to change a copy, it is not a tag. A tag is > immutable. So, you make a branch as you proposed to change it later. > Please stick to the usual terminology. > > Rainer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080528/5a9832c9/attachment.htm From jkh at apple.com Wed May 28 02:57:01 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Wed, 28 May 2008 02:57:01 -0700 Subject: Merging to the release_1_6 branch In-Reply-To: <483D0120.8030405@macports.org> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> <483CB530.3030408@macports.org> <7A4ECD06-F0C3-4691-B3FC-0C181668C89E@apple.com> <483CF42D.20207@macports.org> <483D0120.8030405@macports.org> Message-ID: <2C1190EB-7A47-46D9-B7AB-7DBD1758D98F@apple.com> On May 27, 2008, at 11:52 PM, Rainer M?ller wrote: > But you would definitely tag that 1.7.0-rc1 not 1.6.1-rc1. And where > do you fix a bug found in that rc1? On and trunk and you merge it > back to the 1.7.x release branch That's either truly one-dimensional thinking at work or you are now merely working overtime try and invent reasons to branch. :-) Who says that the only way to fix bugs is to branch? You might just as well decide to create 3 tags in a row on trunk, during a code slush, or even declare it a release and fix the bugs in the next release (which, hopefully, would also happen MORE OFTEN than they do now because there would be less work involved). That is what "convergence" means. You fix the bugs in trunk until things are "release ready" and then you release it. If you want to create "release candidate" tags, then fine, create them on trunk also. It may seem like a minor point of order we're arguing to everyone else who is undoubtedly bored sick by the topic by now, but one process is a lot more light-weight than the other and minimizes confusion (like features being on the 1.6 branch that someone forgot to merge to trunk, as was just noticed) since the default scenario is always to be on one linear path, with branches being the specialized exception rather than the constant-expense rule. But hey, maybe Rainer here wants to volunteer to be release engineer for the next 5 years or so (it takes at least 2 years to figure out how to do everything right, so it's a long-term commitment) and win the argument by default since if he's signing up to do all the extra merge work, I will stop arguing and get out of his way immediately. :-) - Jordan From raimue at macports.org Wed May 28 05:27:12 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 28 May 2008 14:27:12 +0200 Subject: Merging to the release_1_6 branch In-Reply-To: <2C1190EB-7A47-46D9-B7AB-7DBD1758D98F@apple.com> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> <483CB530.3030408@macports.org> <7A4ECD06-F0C3-4691-B3FC-0C181668C89E@apple.com> <483CF42D.20207@macports.org> <483D0120.8030405@macports.org> <2C1190EB-7A47-46D9-B7AB-7DBD1758D98F@apple.com> Message-ID: <483D4FA0.8050404@macports.org> Jordan K. Hubbard wrote: > That's either truly one-dimensional thinking at work or you are now > merely working overtime try and invent reasons to branch. :-) No, I still try to understand how your proposal should be useful. > Who says that the only way to fix bugs is to branch? You might just > as well decide to create 3 tags in a row on trunk, during a code > slush, or even declare it a release and fix the bugs in the next > release (which, hopefully, would also happen MORE OFTEN than they do > now because there would be less work involved). That is what > "convergence" means. You fix the bugs in trunk until things are > "release ready" and then you release it. If you want to create > "release candidate" tags, then fine, create them on trunk also. If you don't branch, you need a code freeze to avoid other changes happen on trunk which you don't want to have in your release. So, again you need a release engineer to announce code freezes. Code freezes make your development slower as you can't implement new stuff as it flows to your mind. While the code is freezed you would have to branch in order to work on something which is not suited for the release for which the code is freezed. In my opinion it is easier to branch a release than do this on-deman branching. Which also means people have to watch where they make their changes etc. You can disagree on me again, but I simply don't see how code freezes should be useful for this project. > It may seem like a minor point of order we're arguing to everyone else > who is undoubtedly bored sick by the topic by now, but one process is > a lot more light-weight than the other and minimizes confusion (like > features being on the 1.6 branch that someone forgot to merge to > trunk, as was just noticed) since the default scenario is always to be > on one linear path, with branches being the specialized exception > rather than the constant-expense rule. But hey, maybe Rainer here > wants to volunteer to be release engineer for the next 5 years or so > (it takes at least 2 years to figure out how to do everything right, > so it's a long-term commitment) and win the argument by default since > if he's signing up to do all the extra merge work, I will stop arguing > and get out of his way immediately. :-) I am primal interested in getting 1.6.1 out of the door eventually. It should have already have happened to address the postflight bug which was fixed only weeks after the release. Now we are in months after the release, nearly half a year. As our port managers do not seem to push the release, so I am asking what we can do to make this release process faster. For example, we could nominate revisions for backport to 1.6.x, so nobody has to look through hundreds of revisions (see the output of 'svnmerge.py avail' in branches/release_1_6/base). This was just a suggestion. If finally nobody objects or says anything different on this topic I will just start to merge revisions to the release_1_6 which I think should be included in 1.6.1 (especially the stuff from the tickets in the 1.6.1 milestone which was already committed to trunk). And I didn't want to start a discussion about how and if creating release branches for MacPorts is useful, this was introduced by you. Rainer From lists-macports at shopwatch.org Wed May 28 08:20:18 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Wed, 28 May 2008 11:20:18 -0400 Subject: Ruby 1.9 port In-Reply-To: <5cbbe4ae0805280230t1e19e11cn7d0a84849302c51e@mail.gmail.com> References: <5cbbe4ae0805270925n5ba56b9el5d62a07898061c3f@mail.gmail.com> <483C9C26.3070401@shopwatch.org> <787C7271-2836-4F66-8030-D79BBA09065A@macports.org> <5cbbe4ae0805280230t1e19e11cn7d0a84849302c51e@mail.gmail.com> Message-ID: <483D7832.6060603@shopwatch.org> Rainer wrote: > It is the naming convention for MacPorts as it was borrowed from FreeBSD ports. Shows what I know... > And this "not production-ready" is not clear either. My webhoster provides 1.9 > in the standard basic web plan already. Of course, Matz has not announced > it to be stable release, but it is features-frozen quite a while. Right, that's more what I meant. It's not supposed to be a drop-in replacement for 1.8; there are deliberate incompatibilities. And I assume anything using threads is likely to have some bugs with the new threading scheme. > Those are the reasons why I think the name should be ruby19, i.e. > a new package in the namespace. > > But I wonder how to deal with all the libraries then. That > can probably only be fixed by adding again all the rb packages > as rb19 or something, like it is with python already. I would think that's a good thing, just like the conservative switch to parallel makes; you can add an rb19 dependency once you know that the package actually works with Ruby 1.9. This is only going to get more complex as things like JRuby gain currency; now any gems that depend on native extensions won't work, etc. Jay From macsforever2000 at macports.org Wed May 28 08:22:06 2008 From: macsforever2000 at macports.org (Frank Schima) Date: Wed, 28 May 2008 09:22:06 -0600 Subject: Variants vs. new ports for different version Message-ID: <0FBC3AFB-80F8-4B6B-93F0-7D70E46FCB57@macports.org> Hi all, What's the best practice for handling ports with different versions? For example, take tcl/tk . Currently it is up to version 8.5.2 and the port files for tcl and tk are both using that. However, the 8.4 tree is also still updated. MacPorts does not support the 8.4.x versions. But blt, for one, conflicts with tcl/tk 8.5.2 and needs 8.4.x to be used. I was planning to add support for tcl and tk 8.4.19. Is it alright to just add a variant on the ports for the 8.4.x version? Obviously the other way is to create new tcl84 and tk84 Portfiles. The advantage to using a variant is that there are more than one other ports that depend on tcl/tk and so they, in theory, would not need to be changed. However, in the case of blt, it would need to depend on the 8.4.x variant of tcl and tk. It's not clear to me from reading the wiki if it's possible to depend on a specific variant. Can someone kindly explain if that's possible? Furthermore, it appears that it is not possible to install both 8.5.x and 8.4.x versions of tcl and tk at the same time. So only one should be allowed. Are there other ports like this and what has been done? Cheers! Frank From mww at macports.org Wed May 28 08:30:47 2008 From: mww at macports.org (Markus Weissmann) Date: Wed, 28 May 2008 17:30:47 +0200 Subject: Variants vs. new ports for different version In-Reply-To: <0FBC3AFB-80F8-4B6B-93F0-7D70E46FCB57@macports.org> References: <0FBC3AFB-80F8-4B6B-93F0-7D70E46FCB57@macports.org> Message-ID: <90191F04-509F-42BC-B067-96891BFB3FCE@macports.org> Hi Frank, On 28 May 2008, at 17:22, Frank Schima wrote: > What's the best practice for handling ports with different versions? > > For example, take tcl/tk . > Currently it is up to version 8.5.2 and the port files for tcl and > tk are both using that. However, the 8.4 tree is also still updated. > MacPorts does not support the 8.4.x versions. But blt, for one, > conflicts with tcl/tk 8.5.2 and needs 8.4.x to be used. > > I was planning to add support for tcl and tk 8.4.19. Is it alright > to just add a variant on the ports for the 8.4.x version? Obviously > the other way is to create new tcl84 and tk84 Portfiles. > > The advantage to using a variant is that there are more than one > other ports that depend on tcl/tk and so they, in theory, would not > need to be changed. However, in the case of blt, it would need to > depend on the 8.4.x variant of tcl and tk. It's not clear to me from > reading the wiki if it's possible to depend on a specific variant. > Can someone kindly explain if that's possible? > > Furthermore, it appears that it is not possible to install both > 8.5.x and 8.4.x versions of tcl and tk at the same time. So only one > should be allowed. > > Are there other ports like this and what has been done? There are some ports that do just that: gcc, postgresql, mysql, python, bdb come to my mind; The different versions of e.g. gcc put their header files, libraries, etc. in version-suffixed directories; binaries are directly suffixed and for convenience there is gcc_select (which exists for python, too) to select which version gets called when you execute 'gcc'. This way, they all can be installed simultaneously. I'd favor this approach for Tcl, too -- if possible. This method does grant a good amount of flexibility (ports can depend on their prefered version, multiple versions can be installed simultaneously) and good compatibility/testing (The port will get the version of the dependency it was initially tested with). Regards, -Markus -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/ From blair at orcaware.com Wed May 28 10:15:40 2008 From: blair at orcaware.com (Blair Zajac) Date: Wed, 28 May 2008 10:15:40 -0700 Subject: Merging to the release_1_6 branch In-Reply-To: <2C1190EB-7A47-46D9-B7AB-7DBD1758D98F@apple.com> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> <483CB530.3030408@macports.org> <7A4ECD06-F0C3-4691-B3FC-0C181668C89E@apple.com> <483CF42D.20207@macports.org> <483D0120.8030405@macports.org> <2C1190EB-7A47-46D9-B7AB-7DBD1758D98F@apple.com> Message-ID: <483D933C.5060209@orcaware.com> Jordan K. Hubbard wrote: > On May 27, 2008, at 11:52 PM, Rainer M?ller wrote: > >> But you would definitely tag that 1.7.0-rc1 not 1.6.1-rc1. And where >> do you fix a bug found in that rc1? On and trunk and you merge it >> back to the 1.7.x release branch > > That's either truly one-dimensional thinking at work or you are now > merely working overtime try and invent reasons to branch. :-) > > Who says that the only way to fix bugs is to branch? You might just > as well decide to create 3 tags in a row on trunk, during a code > slush, or even declare it a release and fix the bugs in the next > release (which, hopefully, would also happen MORE OFTEN than they do > now because there would be less work involved). That is what > "convergence" means. You fix the bugs in trunk until things are > "release ready" and then you release it. If you want to create > "release candidate" tags, then fine, create them on trunk also. > > It may seem like a minor point of order we're arguing to everyone else > who is undoubtedly bored sick by the topic by now, but one process is > a lot more light-weight than the other and minimizes confusion (like > features being on the 1.6 branch that someone forgot to merge to > trunk, as was just noticed) since the default scenario is always to be > on one linear path, with branches being the specialized exception > rather than the constant-expense rule. But hey, maybe Rainer here > wants to volunteer to be release engineer for the next 5 years or so > (it takes at least 2 years to figure out how to do everything right, > so it's a long-term commitment) and win the argument by default since > if he's signing up to do all the extra merge work, I will stop arguing > and get out of his way immediately. :-) I think the amount of work to use a branch is overestimated. It's not hard and very easy and safer then having everything in trunk and then having to do code freezes. Blair From blair at orcaware.com Wed May 28 10:17:02 2008 From: blair at orcaware.com (Blair Zajac) Date: Wed, 28 May 2008 10:17:02 -0700 Subject: Merging to the release_1_6 branch In-Reply-To: <483D0120.8030405@macports.org> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> <483CB530.3030408@macports.org> <7A4ECD06-F0C3-4691-B3FC-0C181668C89E@apple.com> <483CF42D.20207@macports.org> <483D0120.8030405@macports.org> Message-ID: <483D938E.8070902@orcaware.com> Rainer M?ller wrote: > Joshua Root wrote: >> I would have no objection to tagging trunk today and calling it an -rc1. >> Well, except that there are apparently some bug fixes in the 1.6 branch >> that are not in trunk - argh! > > But you would definitely tag that 1.7.0-rc1 not 1.6.1-rc1. And where do > you fix a bug found in that rc1? On and trunk and you merge it back to > the 1.7.x release branch. So you definitely need a 1.7.x branch and > there is no way to make that from trunk as it could get other changes in > the mean time which are not suited for a release. If we would not make a > release branch as suggested by Jordan and make the release from trunk, > trunk would have to go into code freeze until the final release is there. > > So if a release was near, I would do (with some pseudo-shell commands): > svn cp trunk branches/release_1_7 > svn cp branches/release_1_7 tags/release_1_7_0-rc1 > > Bug fixes go to branches/release_1_7. Anything can happen on trunk in > the mean time. If the release candidate was considered bug free, Ideally you would fix the bug in trunk and then merge it to the release_1_7 branch which would appear in the next tagged release. Going from the release branch back to trunk has two way merges and doesn't seem as clean and easier to forget that a fix needs to go back to trunk. Blair From febeling at macports.org Wed May 28 10:46:44 2008 From: febeling at macports.org (Caspar Florian Ebeling) Date: Wed, 28 May 2008 19:46:44 +0200 Subject: Ruby 1.9 port In-Reply-To: <483D7832.6060603@shopwatch.org> References: <5cbbe4ae0805270925n5ba56b9el5d62a07898061c3f@mail.gmail.com> <483C9C26.3070401@shopwatch.org> <787C7271-2836-4F66-8030-D79BBA09065A@macports.org> <5cbbe4ae0805280230t1e19e11cn7d0a84849302c51e@mail.gmail.com> <483D7832.6060603@shopwatch.org> Message-ID: <5cbbe4ae0805281046r71dd2dc5t7a1472f8dbc868d6@mail.gmail.com> >> And this "not production-ready" is not clear either. My webhoster provides >> 1.9 >> in the standard basic web plan already. Of course, Matz has not announced >> it to be stable release, but it is features-frozen quite a while. > > Right, that's more what I meant. It's not supposed to be a drop-in > replacement for 1.8; there are deliberate incompatibilities. And I assume > anything using threads is likely to have some bugs with the new threading > scheme. > >> Those are the reasons why I think the name should be ruby19, i.e. >> a new package in the namespace. >> >> But I wonder how to deal with all the libraries then. That >> can probably only be fixed by adding again all the rb packages >> as rb19 or something, like it is with python already. > > I would think that's a good thing, just like the conservative switch to > parallel makes; you can add an rb19 dependency once you know that the > package actually works with Ruby 1.9. Ok, with your encouraging comment I thought just check in and see how things work out. So we have ruby19 by now. (The broader audience obviously has to wait for the new portindex at about 10 CEST to find it, or do this step manually.) Florian -- Florian Ebeling florian.ebeling at gmail.com From raimue at macports.org Wed May 28 10:55:36 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 28 May 2008 19:55:36 +0200 Subject: Merging to the release_1_6 branch In-Reply-To: <483D938E.8070902@orcaware.com> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> <483CB530.3030408@macports.org> <7A4ECD06-F0C3-4691-B3FC-0C181668C89E@apple.com> <483CF42D.20207@macports.org> <483D0120.8030405@macports.org> <483D938E.8070902@orcaware.com> Message-ID: <483D9C98.3010103@macports.org> Blair Zajac wrote: > Rainer M?ller wrote: >> So if a release was near, I would do (with some pseudo-shell commands): >> svn cp trunk branches/release_1_7 >> svn cp branches/release_1_7 tags/release_1_7_0-rc1 >> >> Bug fixes go to branches/release_1_7. Anything can happen on trunk in >> the mean time. If the release candidate was considered bug free, > > Ideally you would fix the bug in trunk and then merge it to the release_1_7 > branch which would appear in the next tagged release. Oh yes, that's what I meant here. > Going from the release branch back to trunk has two way merges and doesn't seem > as clean and easier to forget that a fix needs to go back to trunk. This was done with our postflight script as the postflight script in trunk also had changes, which were not suited for backporting. But these cases should be very rare and there should never be the need to merge it to trunk if you make changes directly to the release branch. Rainer From ryandesign at macports.org Wed May 28 15:11:54 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 28 May 2008 17:11:54 -0500 Subject: Variants vs. new ports for different version In-Reply-To: <0FBC3AFB-80F8-4B6B-93F0-7D70E46FCB57@macports.org> References: <0FBC3AFB-80F8-4B6B-93F0-7D70E46FCB57@macports.org> Message-ID: <41758476-FB0F-425E-A751-524652ED6250@macports.org> On May 28, 2008, at 10:22, Frank Schima wrote: > What's the best practice for handling ports with different versions? > > For example, take tcl/tk . > Currently it is up to version 8.5.2 and the port files for tcl and tk > are both using that. However, the 8.4 tree is also still updated. > MacPorts does not support the 8.4.x versions. But blt, for one, > conflicts with tcl/tk 8.5.2 and needs 8.4.x to be used. > > I was planning to add support for tcl and tk 8.4.19. Is it alright to > just add a variant on the ports for the 8.4.x version? Obviously the > other way is to create new tcl84 and tk84 Portfiles. > > The advantage to using a variant is that there are more than one other > ports that depend on tcl/tk and so they, in theory, would not need to > be changed. However, in the case of blt, it would need to depend on > the 8.4.x variant of tcl and tk. It's not clear to me from reading the > wiki if it's possible to depend on a specific variant. Can someone > kindly explain if that's possible? > > Furthermore, it appears that it is not possible to install both 8.5.x > and 8.4.x versions of tcl and tk at the same time. So only one should > be allowed. > > Are there other ports like this and what has been done? It's not ok for a port variant to change the version of software that is installed. I'm not sure where that's documented but it was told to me once. Also it's not possible for a port to depend on a specific variant of another port; see: http://trac.macports.org/ticket/126 I think the way we do it is to just upgrade ports when new versions are out. If it's later discovered that a particular other port doesn't work with the updated version, then at that point a new port for the older version can be created from an older version in the repository. For example, if blt does not work with tcl/tk 8.5.x and cannot be made to work with that version, then you can now create new ports tcl84/tk84 from the last version of the tcl/tk ports that used version 8.4.x. Like this: svn checkout -N http://svn.macports.org/repository/macports/trunk/ dports/ cd dports svn up -N lang x11 svn up lang/tcl x11/tk svn cp -r 32234 lang/tcl lang/tcl84 svn cp -r 32234 x11/tk x11/tk84 Now fix the "name" field in lang/tcl84/Portfile and x11/tk84/ Portfile. Since this would be your baby, you should add yourself to the maintainers line. You should stay in contact with the existing maintainer to ensure that changes he makes to tcl/tk can also be applied to tcl84/tk84. You would also have to modify these new tcl84/tk84 ports so that they install into different places than the tcl/tk ports, so that it is possible to install both tcl and tcl84 (and tk and tk84) at the same time. Then: svn ci -m "tcl84, tk84: new ports based on r32234 of tcl and tk" Then you change blt so it depends on tcl84/tk84 and can find the tcl84/tk84 software wherever it got installed (since it had to be modified to install in a nonstandard location to allow simultaneous installation with the newer version). Precedent for this is the apache20 port (and the accompanying apr0 and apr-util0 ports), which were created after the apache2 port got updated to version 2.2 (and apr and apr-util were updated to 1.2) which was incompatible with something. I should point out though that it's preferable to work with the developers of blt to get it to work with tcl/tk 8.5 and not create new tcl84/tk84 ports. Better to move forward than backward. For example graphviz 2.16 didn't work with tcl/tk 8.5. I could have created tcl84/tk84 ports then, but instead I reported the problem to the developers of graphviz and disabled tcl/tk support in the graphviz port until they released version 2.18 which does support tcl/ tk 8.5. See: http://trac.macports.org/ticket/13813 From bwaters at nrao.edu Wed May 28 16:00:51 2008 From: bwaters at nrao.edu (Boyd Waters) Date: Wed, 28 May 2008 17:00:51 -0600 Subject: Building python2.5 extensions under MacPorts In-Reply-To: <4828EB59.7090502@orcaware.com> References: <4E6E57A9-B79D-4898-96FE-B8A025DDB4BE@xunil.net> <4828EB59.7090502@orcaware.com> Message-ID: <6FBBD88B-286C-4FC3-B0D9-9DD4E5E2CE3A@nrao.edu> I have a Python 2.5.2 port that builds just fine with PyQt4. I also have one that builds quad-architecture universal (with quad- architecture Qt4). I've only tested it on Leopard, and I'm working on it now with another Mac, and testing Tiger as well. I'll post the port to this list later tonight. On May 12, 2008, at 7:14 PM, Blair Zajac wrote: > Robert Liesenfeld wrote: >> Anyone built any Python extensions, specifically for Python 2.5? >> I'm trying to make a py25-pyqt4 port, and i'm running into trouble >> with building the extension .so's; they keep getting linked against >> the system (i.e. Apple-provided) Python, not the MacPorts Python: > > The python 2.5 provided by MacPorts is not a framework Python, which > I'm pretty sure is required by PyQt. > > There's a thread that was started last week about getting Python 2.5 > to a Framework build. > > Regards, > Blair > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From macsforever2000 at macports.org Wed May 28 16:23:42 2008 From: macsforever2000 at macports.org (Frank Schima) Date: Wed, 28 May 2008 17:23:42 -0600 Subject: Variants vs. new ports for different version In-Reply-To: <41758476-FB0F-425E-A751-524652ED6250@macports.org> References: <0FBC3AFB-80F8-4B6B-93F0-7D70E46FCB57@macports.org> <41758476-FB0F-425E-A751-524652ED6250@macports.org> Message-ID: Hi Ryan, On May 28, 2008, at 4:11 PM, Ryan Schmidt wrote: > For example, if blt does not work with tcl/tk 8.5.x and cannot be > made to work with that version, then you can now create new ports > tcl84/tk84 from the last version of the tcl/tk ports that used > version 8.4.x. Like this: If I go ahead with this, I plan to just take the current Portfiles and modify them for 8.4. Tcl/tk 8.4.x are being actively developed so I would want to use the latest version of that branch, not just the last one at the time of switch to 8.5. > I should point out though that it's preferable to work with the > developers of blt to get it to work with tcl/tk 8.5 and not create > new tcl84/tk84 ports. Better to move forward than backward. For > example graphviz 2.16 didn't work with tcl/tk 8.5. I could have > created tcl84/tk84 ports then, but instead I reported the problem to > the developers of graphviz and disabled tcl/tk support in the > graphviz port until they released version 2.18 which does support > tcl/tk 8.5. See: I completely agree that it would be optimal to get blt updated to fix the problem. It is a known issue. Apparently there is only one developer and he has been silent on this issue. In fact, it hasn't really been updated for many years. So no one knows when or if this will get fixed. Cheers! Frank From febeling at macports.org Thu May 29 01:11:44 2008 From: febeling at macports.org (Caspar Florian Ebeling) Date: Thu, 29 May 2008 10:11:44 +0200 Subject: Merging to the release_1_6 branch In-Reply-To: References: Message-ID: <5cbbe4ae0805290111k65d059cdq1c396dc97b2f140e@mail.gmail.com> > I think the amount of work to use a branch is overestimated. It's not hard and > very easy and safer then having everything in trunk and then having to do code > freezes. I think the amount of time passed since the 1.6.0 release and the amount of time since 1.6.1 is vaporware, combined with rumors that 1_6 or 1_7 branches contains stuff that did not go into trunk make this claim a bit questionable. I can only second Jordan's position here. I do used trunk, and it works quite well. Why not just push it out to users, and forget about bureaucracy of branches? Having many bugs out there is much less professional than not using branches. Florian -- Florian Ebeling florian.ebeling at gmail.com -- Florian Ebeling florian.ebeling at gmail.com From ryandesign at macports.org Thu May 29 01:22:44 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 29 May 2008 03:22:44 -0500 Subject: Merging to the release_1_6 branch In-Reply-To: <5cbbe4ae0805290111k65d059cdq1c396dc97b2f140e@mail.gmail.com> References: <5cbbe4ae0805290111k65d059cdq1c396dc97b2f140e@mail.gmail.com> Message-ID: <962B2CEE-7518-4225-AFDE-CFC9C0346515@macports.org> On May 29, 2008, at 03:11, Caspar Florian Ebeling wrote: >> I think the amount of work to use a branch is overestimated. It's >> not hard and >> very easy and safer then having everything in trunk and then >> having to do code >> freezes. > > I think the amount of time passed since the 1.6.0 release and the > amount of time since > 1.6.1 is vaporware, combined with rumors that 1_6 or 1_7 branches > contains > stuff that did not go into trunk make this claim a bit questionable. > > I can only second Jordan's position here. I do used trunk, and it > works quite well. > Why not just push it out to users, and forget about bureaucracy of > branches? > Having many bugs out there is much less professional than not using > branches. I've been using trunk for months. Trunk recently received many nice fixes from jmr which it would be great to release to everyone. On the other hand, I practically never used the 1.6 branch (with its modifications since the 1.6.0 release). I don't know that it works right. The changes on the 1.6.0 branch were to address problems with the dmg installer, which those of us building from source are not testing. Doesn't trunk have a different fix for the dmg issue? Most of us haven't tested that either. I would be in favor of examining the commits that were made to the 1.6 branch since the release of 1.6.0 to see what needs to be merged back to trunk. Then we could release a set of 1.7.0-rc1 disk images. We should make sure the dmg installer properly sets up the .profile on all five supported configurations (Panther PowerPC, Tiger PowerPC and Intel, Leopard PowerPC and Intel). Let people run 1.7.0-rc1 for a few weeks and make sure no major issues are reported, then release it as 1.7.0. From ryandesign at macports.org Thu May 29 05:48:40 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 29 May 2008 07:48:40 -0500 Subject: Indicate which architectures are in universal ports? Message-ID: In "port installed" I can see which ports I have installed universal and which I haven't. But for those that are universal, I can't see what architectures are represented (since we now allow people to change that via the macports.conf). This makes it hard if, e.g., I've decided that I want to upgrade from having 2-arch universal builds to having 4-arch universal builds. Maybe "port installed" could be enhanced to show which architectures a port was built with? This could apply only to ports with the universal variant, or maybe better to all ports. Comments? Other ideas for solving this problem? From jkh at apple.com Thu May 29 11:12:17 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Thu, 29 May 2008 11:12:17 -0700 Subject: Merging to the release_1_6 branch In-Reply-To: <483D4FA0.8050404@macports.org> References: <98A8E235-EF26-4061-9A7D-3C6B47C7A7A6@macports.org> <483BF090.3060209@macports.org> <5cbbe4ae0805271238s6523695elc64bf02574d09d17@mail.gmail.com> <483C7129.9080807@macports.org> <96213218-6A5C-48AF-928A-935A40AC903F@apple.com> <483CB530.3030408@macports.org> <7A4ECD06-F0C3-4691-B3FC-0C181668C89E@apple.com> <483CF42D.20207@macports.org> <483D0120.8030405@macports.org> <2C1190EB-7A47-46D9-B7AB-7DBD1758D98F@apple.com> <483D4FA0.8050404@macports.org> Message-ID: On May 28, 2008, at 5:27 AM, Rainer M?ller wrote: > If you don't branch, you need a code freeze to avoid other changes > happen on trunk which you don't want to have in your release. So, > again you need a release engineer to announce code freezes. > > Code freezes make your development slower as you can't implement new > stuff as it flows to your mind. While the code is freezed you would > have to branch in order to work on something which is not suited for > the release for which the code is freezed. In my opinion it is > easier to branch a release than do this on-deman branching. Which > also means people have to watch where they make their changes etc. I think this thread has gone on long enough, so let me just respond "of course you still need a release engineer, it's just less constant work for that engineer" to the first paragraph and "non sequitur" to the second. - Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080529/9f38bb8e/attachment.htm From mmoll at macports.org Thu May 29 17:14:24 2008 From: mmoll at macports.org (Mark Moll) Date: Thu, 29 May 2008 19:14:24 -0500 Subject: linking c/c++ code against fortran libraries Message-ID: There are number of ports that have variants for choosing one the fortran compilers: gcc42, gcc43, and g95. Suppose now that I have port A that includes a library libfoo.a of fortran code. I would like to create a port B that contains C code and depends on this library in port A. However, to properly link against libfoo.a I also need to include "-lgfortran". There are then two issues: 1. How do I determine which variant was used for port A, so that I know where I can find libgfortran.dylib? 2. By default, MacPorts will use /usr/bin/gcc-4.0. It sounds like a bad idea to mix and match compiler versions. In the case of the gcc42 and gcc43 variants of port A, I could use the corresponding gcc compiler for port B. Is this acceptable? What is the right C compiler to link against code compiled with g95? -- Mark From wsiegrist at apple.com Thu May 29 22:15:26 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 29 May 2008 22:15:26 -0700 Subject: distfiles.macports.org In-Reply-To: References: <38ED7DA2-C2E1-430B-9445-364F684A552A@apple.com> Message-ID: <4283E9D1-E3BE-414E-81AE-B6944193630E@apple.com> On May 23, 2008, at 7:56 AM, William Siegrist wrote: > > On May 23, 2008, at 2:32 AM, Ryan Schmidt wrote: > >> On May 19, 2008, at 14:35, William Siegrist wrote: >> >>> I've begun experimenting with hosting a distfile mirror on Mac OS >>> Forge for MacPorts. This is very much a beta service, so it wont >>> be automatically used by MacPorts just yet. But if you have >>> trouble fetching a distfile, the checksums fail repeatedly, or you >>> need an old distfile, you might try looking here: >>> >>> http://distfiles.macports.org// >> >> I hope it's not actually but as defined in >> the port. For most ports, will equal but >> some ports may override it. >> > > > Yes, right now its dist_subdir. It'll probably change though to > incorporate the category eventually. People can start relying on the mirror and building it into port1.0 and MPWA and whatever else. The layout will stay with whatever "port mirror" does. The mirroring will be done daily around 1am PDT for all ports regardless of changes to Portfiles. -Bill ---- 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/20080529/1af0b33c/attachment.p7s From jmr at macports.org Fri May 30 00:35:01 2008 From: jmr at macports.org (Joshua Root) Date: Fri, 30 May 2008 17:35:01 +1000 Subject: distfiles.macports.org In-Reply-To: <4283E9D1-E3BE-414E-81AE-B6944193630E@apple.com> References: <38ED7DA2-C2E1-430B-9445-364F684A552A@apple.com> <4283E9D1-E3BE-414E-81AE-B6944193630E@apple.com> Message-ID: <483FAE25.1080008@macports.org> William Siegrist wrote: > On May 23, 2008, at 7:56 AM, William Siegrist wrote: >>> On May 19, 2008, at 14:35, William Siegrist wrote: >>> >>>> I've begun experimenting with hosting a distfile mirror on Mac OS >>>> Forge for MacPorts. This is very much a beta service, so it wont >>>> be automatically used by MacPorts just yet. But if you have >>>> trouble fetching a distfile, the checksums fail repeatedly, or you >>>> need an old distfile, you might try looking here: >>>> >>>> http://distfiles.macports.org// > People can start relying on the mirror and building it into port1.0 Done: http://trac.macports.org/attachment/ticket/15456/d.m.o.diff :-D - Josh From raimue at macports.org Fri May 30 04:40:10 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 30 May 2008 13:40:10 +0200 Subject: distfiles.macports.org In-Reply-To: <483FAE25.1080008@macports.org> References: <38ED7DA2-C2E1-430B-9445-364F684A552A@apple.com> <4283E9D1-E3BE-414E-81AE-B6944193630E@apple.com> <483FAE25.1080008@macports.org> Message-ID: <483FE79A.7010406@macports.org> Joshua Root wrote: >> People can start relying on the mirror and building it into port1.0 > > Done: http://trac.macports.org/attachment/ticket/15456/d.m.o.diff :-D Nice implementation. Patch works fine here! As you use port mirror for this task now, can we revert the addition of port distfiles? Or should this still be considered useful? Another topic: Some time ago we had the idea to generate usage statistics by counting distfiles downloads from the macports distfiles mirror. If we still want to do this, we would have to add the macports distfiles mirror at the top of the list, so everybody tries that first. But this would make this shiny new ping sort feature useless. What is more important for use? Probably faster downloads or pseudo usage statistics? Rainer From jmr at macports.org Fri May 30 05:30:46 2008 From: jmr at macports.org (Joshua Root) Date: Fri, 30 May 2008 22:30:46 +1000 Subject: distfiles.macports.org In-Reply-To: <483FE79A.7010406@macports.org> References: <38ED7DA2-C2E1-430B-9445-364F684A552A@apple.com> <4283E9D1-E3BE-414E-81AE-B6944193630E@apple.com> <483FAE25.1080008@macports.org> <483FE79A.7010406@macports.org> Message-ID: <483FF376.3090900@macports.org> Rainer M?ller wrote: > Another topic: Some time ago we had the idea to generate usage > statistics by counting distfiles downloads from the macports distfiles > mirror. If we still want to do this, we would have to add the macports > distfiles mirror at the top of the list, so everybody tries that first. > But this would make this shiny new ping sort feature useless. What is > more important for use? Probably faster downloads or pseudo usage > statistics? We'll still get a (geographically-biased) sample from distfiles.macports.org with mirror sorting enabled. At the very least we'll get lower bounds for the overall download numbers. Besides, the stats will get better once again when we start distributing binaries, right? ;-) - Josh From wsiegrist at apple.com Fri May 30 07:38:54 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 30 May 2008 07:38:54 -0700 Subject: distfiles.macports.org In-Reply-To: <483FE79A.7010406@macports.org> References: <38ED7DA2-C2E1-430B-9445-364F684A552A@apple.com> <4283E9D1-E3BE-414E-81AE-B6944193630E@apple.com> <483FAE25.1080008@macports.org> <483FE79A.7010406@macports.org> Message-ID: On May 30, 2008, at 4:40 AM, Rainer M?ller wrote: > Joshua Root wrote: >>> People can start relying on the mirror and building it into port1.0 >> Done: http://trac.macports.org/attachment/ticket/15456/d.m.o.diff :-D > > Nice implementation. Patch works fine here! > > As you use port mirror for this task now, can we revert the addition > of port distfiles? Or should this still be considered useful? > I dont need the distfiles target. -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/20080530/fcfcb2ed/attachment.p7s From ryandesign at macports.org Fri May 30 17:09:18 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 30 May 2008 19:09:18 -0500 Subject: distfiles.macports.org In-Reply-To: <483FE79A.7010406@macports.org> References: <38ED7DA2-C2E1-430B-9445-364F684A552A@apple.com> <4283E9D1-E3BE-414E-81AE-B6944193630E@apple.com> <483FAE25.1080008@macports.org> <483FE79A.7010406@macports.org> Message-ID: <375DB3C0-7992-417C-B081-D561A47C37BE@macports.org> On May 30, 2008, at 06:40, Rainer M?ller wrote: >>> People can start relying on the mirror and building it into port1.0 >> >> Done: http://trac.macports.org/attachment/ticket/15456/d.m.o.diff :-D > > Nice implementation. Patch works fine here! > > As you use port mirror for this task now, can we revert the > addition of > port distfiles? Or should this still be considered useful? Ooh, I overlooked that feature. That's kinda nice. Too bad it requires sudo... (IMHO it shouldn't, just like lint and livecheck don't.) > Another topic: Some time ago we had the idea to generate usage > statistics by counting distfiles downloads from the macports distfiles > mirror. If we still want to do this, we would have to add the macports > distfiles mirror at the top of the list, so everybody tries that > first. > But this would make this shiny new ping sort feature useless. What is > more important for use? Probably faster downloads or pseudo usage > statistics? Why don't we keep the nice ping feature for now, since it hasn't even seen the light of day and closer/faster downloads has been requested more than once. From wsiegrist at apple.com Fri May 30 18:36:47 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 30 May 2008 18:36:47 -0700 Subject: distfiles.macports.org In-Reply-To: <375DB3C0-7992-417C-B081-D561A47C37BE@macports.org> References: <38ED7DA2-C2E1-430B-9445-364F684A552A@apple.com> <4283E9D1-E3BE-414E-81AE-B6944193630E@apple.com> <483FAE25.1080008@macports.org> <483FE79A.7010406@macports.org> <375DB3C0-7992-417C-B081-D561A47C37BE@macports.org> Message-ID: <6514B8D2-3B6B-457E-8706-E085D213B5B7@apple.com> On May 30, 2008, at 5:09 PM, Ryan Schmidt wrote: > > On May 30, 2008, at 06:40, Rainer M?ller wrote: >>>> >> But this would make this shiny new ping sort feature useless. What is >> more important for use? Probably faster downloads or pseudo usage >> statistics? > > Why don't we keep the nice ping feature for now, since it hasn't even > seen the light of day and closer/faster downloads has been requested > more than once. > I suggest letting the mirror compete equally with other sites but keep the svn.macports.org sites at the bottom. I think if everyone had to go to the mirror it would end up slower for everyone anyway. But people near Cupertino could benefit and it would give a sample of usage. -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/20080530/0dc9e30c/attachment.p7s From jmr at macports.org Sat May 31 00:30:58 2008 From: jmr at macports.org (Joshua Root) Date: Sat, 31 May 2008 17:30:58 +1000 Subject: distfiles.macports.org In-Reply-To: <6514B8D2-3B6B-457E-8706-E085D213B5B7@apple.com> References: <38ED7DA2-C2E1-430B-9445-364F684A552A@apple.com> <4283E9D1-E3BE-414E-81AE-B6944193630E@apple.com> <483FAE25.1080008@macports.org> <483FE79A.7010406@macports.org> <375DB3C0-7992-417C-B081-D561A47C37BE@macports.org> <6514B8D2-3B6B-457E-8706-E085D213B5B7@apple.com> Message-ID: <4840FEB2.6070603@macports.org> William Siegrist wrote: > > On May 30, 2008, at 5:09 PM, Ryan Schmidt wrote: > >> >> On May 30, 2008, at 06:40, Rainer M?ller wrote: >>>>> >>> But this would make this shiny new ping sort feature useless. What is >>> more important for use? Probably faster downloads or pseudo usage >>> statistics? >> >> Why don't we keep the nice ping feature for now, since it hasn't even >> seen the light of day and closer/faster downloads has been requested >> more than once. >> > > > I suggest letting the mirror compete equally with other sites but keep > the svn.macports.org sites at the bottom. I agree, and that's exactly what I implemented. - Josh From takeshi at enomosphere.net Sat May 31 06:21:26 2008 From: takeshi at enomosphere.net (Takeshi Enomoto) Date: Sat, 31 May 2008 22:21:26 +0900 Subject: linking c/c++ code against fortran libraries In-Reply-To: References: Message-ID: <6B2DC5C6-A6F1-4620-B29C-27ED2D279BED@enomosphere.net> Hi, > However, to properly link against libfoo.a I also need to > include "-lgfortran". With a fortran compiler, necessary libraries will be linked. > What is the right C compiler > to link against code compiled with g95? Currently g95 builds against gcc-4.0.4, which is the same source code as gcc40 port. Takeshi From raimue at macports.org Sat May 31 07:19:34 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Sat, 31 May 2008 16:19:34 +0200 Subject: [37228] trunk/dports In-Reply-To: <20080531141039.55E5816F4C91@beta.macosforge.org> References: <20080531141039.55E5816F4C91@beta.macosforge.org> Message-ID: <48415E76.8080108@macports.org> jmr at macports.org wrote: > Revision: 37228 > http://trac.macosforge.org/projects/macports/changeset/37228 > Author: jmr at macports.org > Date: 2008-05-31 07:10:38 -0700 (Sat, 31 May 2008) > > Log Message: > ----------- > Switch over remaining teTeX dependencies to texlive. Closes #12913 (maintainer timeout). > > Modified Paths: > -------------- [...] > trunk/dports/tex/tetex-rechnung/Portfile Maybe this port should be renamed now. CC'ing mww as maintainer. Rainer From mmoll at macports.org Sat May 31 09:44:52 2008 From: mmoll at macports.org (Mark Moll) Date: Sat, 31 May 2008 11:44:52 -0500 Subject: linking c/c++ code against fortran libraries In-Reply-To: <6B2DC5C6-A6F1-4620-B29C-27ED2D279BED@enomosphere.net> References: <6B2DC5C6-A6F1-4620-B29C-27ED2D279BED@enomosphere.net> Message-ID: <1419F00F-9545-491E-8959-5A778B17E5B3@macports.org> On May 31, 2008, at 8:21 AM, Takeshi Enomoto wrote: > Hi, > >> However, to properly link against libfoo.a I also need to >> include "-lgfortran". > > With a fortran compiler, necessary libraries will be linked. Yes, but I can't specify in a Portfile two compilers (one for compiling c/c++ code, and one for linking the object files). Below is how I currently attempt to get around this problem in the arpack variant of the slepc port. Arpack is a port for a Fortran library, slepc is a port for a C++ library. I am open to suggestions for improvement. variant arpack description {compile with ARPACK support} { pre-fetch { if {![file exists ${prefix}/lib/libparpack.a]} { return -code error "Please install the mpi variant of arpack first." } } # This is a rather fragile way to figure out where the fortran library can be # found that is needed to link against libparpack.a: if {[file exists ${prefix}/lib/gcc43]} { set fortrandir ${prefix}/lib/gcc43 } else { if {[file exists ${prefix}/lib/gcc42]} { set fortrandir ${prefix}/lib/gcc42 } else { if {[file exists ${prefix}/lib/g95]} { set fortrandir ${prefix}/lib/gcc95 } else { return -code error "Please install a fortran compiler by installing one of the following ports: gcc42, gcc43, or g95." } } } depends_lib-append port:arpack configure.args-append --with-arpack-dir=${fortrandir} \ --with-arpack-flags=-lparpack,-larpack,-lgfortran,- lmpi_f77 } -- Mark -- Mark From blb at macports.org Sat May 31 14:24:30 2008 From: blb at macports.org (Bryan Blackburn) Date: Sat, 31 May 2008 15:24:30 -0600 Subject: MacPorts AutoBuild Message-ID: <86A557C5-0074-49D2-802C-A45062768220@macports.org> I just finished uploading what I've been working on for the last few weeks off and on, my redo of my old DarwinPorts AutoBuild scripts. See Right now it builds ports fine in the chroot (though now with 10.5.3 I need to rebuild a newer version of my chroot), but does have a few limitations. One is that I've currently only tested it with 10.5 and Xcode 3.0. See the Todo section in the ReadMe.txt file that comes with the archive. I've had it successfully build about 145 ports so far, with several failing for various reasons. It starts to slow down when you are dealing when building a port with many dependencies as it will uninstall all ports between each build attempt for better cleanroom building. My MBP's HD gets a bit slow when frequently extracting then removing thousands of files.... Give it a try if you'd like and reply here or update the wiki page. Bryan From raimue at macports.org Sat May 31 17:12:48 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Sun, 01 Jun 2008 02:12:48 +0200 Subject: [37243] trunk/base/src/port/port-help.tcl In-Reply-To: <20080531215719.E18A116FB2EB@beta.macosforge.org> References: <20080531215719.E18A116FB2EB@beta.macosforge.org> Message-ID: <4841E980.3090205@macports.org> raimue at macports.org wrote: > Revision: 37243 > http://trac.macosforge.org/projects/macports/changeset/37243 > Author: raimue at macports.org > Date: 2008-05-31 14:57:15 -0700 (Sat, 31 May 2008) > > Log Message: > ----------- > port/port-help.tcl: > More helpful action desriptions > > Modified Paths: > -------------- > trunk/base/src/port/port-help.tcl I added some basic usage strings here [1]. If anybody wants to contribute a little bit to MacPorts, here is an easy chance to do so. This is really bite-sized. Just write more information about the commands. See ticket http://trac.macports.org/ticket/15467 I am CC'ing also the users list, because we might find some new contributor? :-) Rainer [1] http://trac.macports.org/browser/trunk/base/src/port/port-help.tcl From bwaters at nrao.edu Thu May 29 15:09:38 2008 From: bwaters at nrao.edu (Boyd Waters) Date: Thu, 29 May 2008 22:09:38 -0000 Subject: [Pythonmac-SIG] 64-bit Python? In-Reply-To: References: <302611.62100.qm@web52111.mail.re2.yahoo.com> Message-ID: On May 29, 2008, at 2:53 PM, Frank Schima wrote: > I have the latest Mac Pro with 10.5.3. I ran the sys.maxint test and > got the 32-bit result. I tried both the Apple python and the > MacPorts python 2.5.2. The MacPorts 2.5.2 doesn't have my 64-bit hacks in it. I'm not sure what the consequences of 64-bit Python will be with respect to other Python packages, so I haven't committed the changes. And I ran into a problem compiling this on Tiger with GNU (non-Apple-patched) GCC 4.2.1. But it's really 64-bit Python here, I think: $ /usr/bin/python -c 'import sys; print sys.maxint' 2147483647 $ /opt/casa/core2-apple-darwin9/3rd-party/bin/python -c 'import sys; print sys.maxint' 9223372036854775807 Here's the MacPorts port: -------------- next part -------------- A non-text attachment was scrubbed... Name: python25.tbz Type: application/octet-stream Size: 47056 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080529/b492d860/attachment-0001.obj -------------- next part -------------- You might unpack this thing into your MacPorts tree like this: tar xjvf ~/Downloads/python25.tbz -C $(port dir python25)/.. and then do a port update python25 ... but I haven't tested that path. I can post a binary on a web site if anyone is interested in testing this; it's a quad-architecture Framework build. Be careful out there... - boyd Boyd Waters Scientific Programmer National Radio Astronomy Observatory Socorro, New Mexico