From ryandesign at macports.org Tue Dec 1 14:27:43 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 1 Dec 2009 16:27:43 -0600 Subject: [61088] trunk/dports/aqua/qt4-mac-devel/Portfile In-Reply-To: <20091201203419.5B96E373C0D6@beta.macosforge.org> References: <20091201203419.5B96E373C0D6@beta.macosforge.org> Message-ID: On Dec 1, 2009, at 14:34, jochen at macports.org wrote: > Revision: 61088 > http://trac.macports.org/changeset/61088 > Author: jochen at macports.org > Date: 2009-12-01 12:34:18 -0800 (Tue, 01 Dec 2009) > Log Message: > ----------- > update to 4.6.0 final > > Modified Paths: > -------------- > trunk/dports/aqua/qt4-mac-devel/Portfile > > Modified: trunk/dports/aqua/qt4-mac-devel/Portfile > =================================================================== > --- trunk/dports/aqua/qt4-mac-devel/Portfile 2009-12-01 20:27:47 UTC (rev 61087) > +++ trunk/dports/aqua/qt4-mac-devel/Portfile 2009-12-01 20:34:18 UTC (rev 61088) > @@ -5,7 +5,7 @@ > > name qt4-mac-devel > conflicts qt4-mac > -version 4.6.0-rc1 > +version 4.6.0 Does rpm-vercomp know that "4.6.0" is greater than "4.6.0-rc1"? If not, the epoch should be increased. Will qt4-mac also be updated to this version? You did not encounter the error I reported in #22701? http://trac.macports.org/ticket/22701 From talklists at newgeo.com Tue Dec 1 14:29:12 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 1 Dec 2009 14:29:12 -0800 Subject: Suggestion on auto ticket filing In-Reply-To: References: Message-ID: <0D8EAAC3-D09D-4797-A746-723C33F6FB6B@newgeo.com> Can you tell me more about the gsoc project wrt MacPorts? Where do I find the log? I can force a portfile to fail, or look at some others that have, where do I find those logs? From what I can gather, your comments below are speaking towards 100% automated ticket submissions on port install error? Or are you saying, that after a failed install, and some general guidance to a wiki/troubleshooting page, that the steps the user take would auto submit a new trac ticket, which in turn, a script could fish out some details and make the ticket more relevant? Sorry, had the flu, and am catching up, and also a little cloudy still, reading over your post, I am not sure I entirely follow what you mean, but would love to work on making this a reality. If you could help bring me up to speed on what you envision, maybe there is a chance my skill set falls in range with the work needed to be done. Thanks. -- Scott * If you contact me off list replace talklists@ with scott@ * On Nov 26, 2009, at 9:46 PM, Jeremy Lavergne wrote: > The gsoc logging project assists us in that the log is already > available---no more need to rerun with debug mode. > > It also provides the path to the log file (copy/paste into Finder). > > As for the port field and ticket owner, we can likely have a script > auto-assign (and CC) the ticket based on the port field, and we > could require the port to be set for ports-based tickets (the > default, type I believe). > > These requirements should cause people to read the instructions > since the tickets won't submit without making sure they've added the > port, but it will also remove the need for them to mark the owner. > > While we're at it, we might consider logic to test that the reporter/ > owner isn't a CC. > > On Nov 27, 2009, at 12:37 AM, Scott Haneda wrote: > >> In a past message on MP-users, subject of: Re: "Electric" failed to >> compile, Ryan suggested the use of: >> >> sudo port -d install electric 2>&1 | tee ~/Desktop/electric.txt >> >> Then asked: >>> Then file a new ticket in the issue tracker and attach >>> electric.txt from your desktop. >> >> I have been wondering this for a while, and this is a good intro >> for me to ask... >> >> As a result of any error in MacPorts, a message is written to the >> terminal of what the error was. What if the last line was: >> >> You may want to try the troubleshooting steps located at: http://trac.macports.org/wiki/FAQ#buildfails >> >> Though I would like to point to a new wiki page, where it was much >> more orderly, a set of steps to try. I see a lot of requests that >> are answered with "did you clean and try again", "yeah, I did, that >> worked, thanks". >> >> Maybe that entire dialog could go away, with the pointing of a url >> at the very end of the error message. Then, within the new wiki >> page, I would add the "If all else fails...". >> >> sudo port -d install portname 2>&1 | tee | mp-reporter >> >> * Not sure I have that correct. >> >> The idea is, that the output is passed to a small shell script, mp- >> reporter, which would automatically create the report in the >> ticketing system. We would need one account for which this >> happened under. >> >> I would like to make the mp-reporter script interactive, so if >> desired, they could login to trac right there, and the ticket would >> be made under their account. Or they can decline, and it will be >> made under the general mp-reporter account. >> >> I believe this is something within my abilities to create. I think >> it can be done with curl and some pretty simple bash scripting. >> Filing the ticket with the output as an attachment, over putting it >> into the ticket itself is up for discussion, and would be the only >> aspect of curl I am not familiar with off the bat. >> >> Comments? >> -- >> Scott * If you contact me off list replace talklists@ with scott@ * >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> > From jeremy at lavergne.gotdns.org Tue Dec 1 14:38:52 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 1 Dec 2009 17:38:52 -0500 Subject: Suggestion on auto ticket filing In-Reply-To: <0D8EAAC3-D09D-4797-A746-723C33F6FB6B@newgeo.com> References: <0D8EAAC3-D09D-4797-A746-723C33F6FB6B@newgeo.com> Message-ID: <805AD5FF-A357-414C-A792-BB1B4061465D@lavergne.gotdns.org> > Can you tell me more about the gsoc project wrt MacPorts? Where do I find the log? I can force a portfile to fail, or look at some others that have, where do I find those logs? It's in the trunk version: when there's an error it'll report where it put the log. >> The gsoc logging project assists us in that the log is already available---no more need to rerun with debug mode. >> >> It also provides the path to the log file (copy/paste into Finder). >> >> As for the port field and ticket owner, we can likely have a script auto-assign (and CC) the ticket based on the port field, and we could require the port to be set for ports-based tickets (the default, type I believe). >> >> These requirements should cause people to read the instructions since the tickets won't submit without making sure they've added the port, but it will also remove the need for them to mark the owner. >> >> While we're at it, we might consider logic to test that the reporter/owner isn't a CC. > > From what I can gather, your comments below are speaking towards 100% automated ticket submissions on port install error? Or are you saying, that after a failed install, and some general guidance to a wiki/troubleshooting page, that the steps the user take would auto submit a new trac ticket, which in turn, a script could fish out some details and make the ticket more relevant? The ticketing process is currently not automated, but my ideas were geared toward the creation of such a system. I feel most of the information can be gleaned from the server's database and port can fire up a terminal window with a specific URL to trigger an auto-population of the form (e.g., `open http://trac.macports.org/...port=...mpversion=1.8.99...`). Ultimately, I would like to aim for port to POST the log to trac, with a ticket ID returned. Then port will open a URL to trac which will display the ticket pre-populated as much as we can and referencing that log. > Sorry, had the flu, and am catching up, and also a little cloudy still, reading over your post, I am not sure I entirely follow what you mean, but would love to work on making this a reality. If you could help bring me up to speed on what you envision, maybe there is a chance my skill set falls in range with the work needed to be done. Basically we need to plan both the server-side URLs and the ability to open such URLs directly from MacPorts. It isn't something that can be done on one side only. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From talklists at newgeo.com Tue Dec 1 14:57:27 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 1 Dec 2009 14:57:27 -0800 Subject: Suggestion on auto ticket filing In-Reply-To: <805AD5FF-A357-414C-A792-BB1B4061465D@lavergne.gotdns.org> References: <0D8EAAC3-D09D-4797-A746-723C33F6FB6B@newgeo.com> <805AD5FF-A357-414C-A792-BB1B4061465D@lavergne.gotdns.org> Message-ID: <2E7B1C57-C7F2-4E7B-A83B-DC08677B9A5B@newgeo.com> On Dec 1, 2009, at 2:38 PM, Jeremy Lavergne wrote: >> Can you tell me more about the gsoc project wrt MacPorts? Where do >> I find the log? I can force a portfile to fail, or look at some >> others that have, where do I find those logs? > > It's in the trunk version: when there's an error it'll report where > it put the log. Any eta on when this hits the general users hands? >>> The gsoc logging project assists us in that the log is already >>> available---no more need to rerun with debug mode. >>> >>> It also provides the path to the log file (copy/paste into Finder). >>> >>> As for the port field and ticket owner, we can likely have a >>> script auto-assign (and CC) the ticket based on the port field, >>> and we could require the port to be set for ports-based tickets >>> (the default, type I believe). >>> >>> These requirements should cause people to read the instructions >>> since the tickets won't submit without making sure they've added >>> the port, but it will also remove the need for them to mark the >>> owner. >>> >>> While we're at it, we might consider logic to test that the >>> reporter/owner isn't a CC. >> >> From what I can gather, your comments below are speaking towards >> 100% automated ticket submissions on port install error? Or are >> you saying, that after a failed install, and some general guidance >> to a wiki/troubleshooting page, that the steps the user take would >> auto submit a new trac ticket, which in turn, a script could fish >> out some details and make the ticket more relevant? > > The ticketing process is currently not automated, but my ideas were > geared toward the creation of such a system. I feel most of the > information can be gleaned from the server's database and port can > fire up a terminal window with a specific URL to trigger an auto- > population of the form (e.g., `openhttp://trac.macports.org/...port=...mpversion=1.8.99 > ...`). Ok, cool, we are on the exact same page, that was my thinking as well. > Ultimately, I would like to aim for port to POST the log to trac, > with a ticket ID returned. Then port will open a URL to trac which > will display the ticket pre-populated as much as we can and > referencing that log. As long as we know the location to that path, I do not see that being an issue. I am just pretty sure we are going to need either: 1) A local script that interfaces with curl to shove that data off as a http POST 2) Changes to MP core to so the same as what the above script would do. >> Sorry, had the flu, and am catching up, and also a little cloudy >> still, reading over your post, I am not sure I entirely follow what >> you mean, but would love to work on making this a reality. If you >> could help bring me up to speed on what you envision, maybe there >> is a chance my skill set falls in range with the work needed to be >> done. > > Basically we need to plan both the server-side URLs and the ability > to open such URLs directly from MacPorts. It isn't something that > can be done on one side only. The pre-population of the form data in trac is going to require the user have an account, is that correct? Or is there some way of doing this in a anonymous way, so MacPorts gets the report, but the user does not hit a barrier? Of course, logging a general user in via part of this process is an option, but that account user and pass is then stored somewhere, in which nefarious things could happen to it. Unless the account was mode post only, so no deletes or edits are allowed under that account. I would like to build a small test case, just to see how much pre- population I am able to achieve, and how the flow of it would all work. https://trac.macports.org/newticket?field_summary=test So far, that simple test, http GET does not work to add test to the field_summary field. I will have to start poking at curl, trac, and cookies in curl and such to see how to even get to a point where I can pre-populate that field. -- Scott * If you contact me off list replace talklists@ with scott@ * From jeremy at lavergne.gotdns.org Tue Dec 1 15:07:43 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 1 Dec 2009 18:07:43 -0500 Subject: Suggestion on auto ticket filing In-Reply-To: <2E7B1C57-C7F2-4E7B-A83B-DC08677B9A5B@newgeo.com> References: <0D8EAAC3-D09D-4797-A746-723C33F6FB6B@newgeo.com> <805AD5FF-A357-414C-A792-BB1B4061465D@lavergne.gotdns.org> <2E7B1C57-C7F2-4E7B-A83B-DC08677B9A5B@newgeo.com> Message-ID: <35576AC3-FF02-430C-BF48-F35CA8E1A18C@lavergne.gotdns.org> >> It's in the trunk version: when there's an error it'll report where it put the log. > > Any eta on when this hits the general users hands? Whenever the port manager team feels like doing another release. If you check out the roadmap, you'll find there are some bugs they'd like to finish before then. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From ryandesign at macports.org Tue Dec 1 15:13:58 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 1 Dec 2009 17:13:58 -0600 Subject: Suggestion on auto ticket filing In-Reply-To: <2E7B1C57-C7F2-4E7B-A83B-DC08677B9A5B@newgeo.com> References: <0D8EAAC3-D09D-4797-A746-723C33F6FB6B@newgeo.com> <805AD5FF-A357-414C-A792-BB1B4061465D@lavergne.gotdns.org> <2E7B1C57-C7F2-4E7B-A83B-DC08677B9A5B@newgeo.com> Message-ID: <2A0C5534-A055-4D4C-9B71-1CA714E50553@macports.org> On Dec 1, 2009, at 16:57, Scott Haneda wrote: > On Dec 1, 2009, at 2:38 PM, Jeremy Lavergne wrote: > >>> Can you tell me more about the gsoc project wrt MacPorts? Where do I find the log? I can force a portfile to fail, or look at some others that have, where do I find those logs? >> >> It's in the trunk version: when there's an error it'll report where it put the log. > > Any eta on when this hits the general users hands? It will be in MacPorts 1.9.0, for which there is no ETA. I think we can do a smaller 1.8.2 release before then, for which there is also no ETA, but IMHO it could occur this month. We already have a few things added to the 1.8 branch beyond what was released in 1.8.1, and several more small fixes that could be merged from trunk as well. >>>> From what I can gather, your comments below are speaking towards 100% automated ticket submissions on port install error? Or are you saying, that after a failed install, and some general guidance to a wiki/troubleshooting page, that the steps the user take would auto submit a new trac ticket, which in turn, a script could fish out some details and make the ticket more relevant? >> >> The ticketing process is currently not automated, but my ideas were geared toward the creation of such a system. I feel most of the information can be gleaned from the server's database and port can fire up a terminal window with a specific URL to trigger an auto-population of the form (e.g., `openhttp://trac.macports.org/...port=...mpversion=1.8.99...`). > > Ok, cool, we are on the exact same page, that was my thinking as well. Before we talk about technically how to auto-submit tickets, we should make sure that's what we want. Personally, I think the user needs to have some say in whether a ticket gets filed. Not every error MacPorts prints means there is a bug. For example, a checksum error may indicate a problem with the user's network. A build failure might occur if the user did not install dependencies with the right architecture (or perhaps did not follow the Migration procedure when upgrading to Snow Leopard). And what about duplicates? We don't want 100 users (or even 2 users) filing tickets for the same problem. We want users to locate existing issues in the issue tracker and only file a new ticket if their issue is not already covered. From brad at pixilla.com Tue Dec 1 16:33:46 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 1 Dec 2009 16:33:46 -0800 Subject: Suggestion on auto ticket filing In-Reply-To: <2A0C5534-A055-4D4C-9B71-1CA714E50553@macports.org> References: <0D8EAAC3-D09D-4797-A746-723C33F6FB6B@newgeo.com> <805AD5FF-A357-414C-A792-BB1B4061465D@lavergne.gotdns.org> <2E7B1C57-C7F2-4E7B-A83B-DC08677B9A5B@newgeo.com> <2A0C5534-A055-4D4C-9B71-1CA714E50553@macports.org> Message-ID: <42095FC9-E457-48B5-AB0A-0A4F500D9D32@pixilla.com> On Dec 1, 2009, at 3:13 PM, Ryan Schmidt wrote: > On Dec 1, 2009, at 16:57, Scott Haneda wrote: > >> On Dec 1, 2009, at 2:38 PM, Jeremy Lavergne wrote: >> >>>> Can you tell me more about the gsoc project wrt MacPorts? Where >>>> do I find the log? I can force a portfile to fail, or look at >>>> some others that have, where do I find those logs? >>> >>> It's in the trunk version: when there's an error it'll report >>> where it put the log. >> >> Any eta on when this hits the general users hands? > > It will be in MacPorts 1.9.0, for which there is no ETA. > > I think we can do a smaller 1.8.2 release before then, for which > there is also no ETA, but IMHO it could occur this month. We already > have a few things added to the 1.8 branch beyond what was released > in 1.8.1, and several more small fixes that could be merged from > trunk as well. > > >>>>> From what I can gather, your comments below are speaking towards >>>>> 100% automated ticket submissions on port install error? Or are >>>>> you saying, that after a failed install, and some general >>>>> guidance to a wiki/troubleshooting page, that the steps the user >>>>> take would auto submit a new trac ticket, which in turn, a >>>>> script could fish out some details and make the ticket more >>>>> relevant? >>> >>> The ticketing process is currently not automated, but my ideas >>> were geared toward the creation of such a system. I feel most of >>> the information can be gleaned from the server's database and port >>> can fire up a terminal window with a specific URL to trigger an >>> auto-population of the form (e.g., `openhttp://trac.macports.org/...port=...mpversion=1.8.99 >>> ...`). >> >> Ok, cool, we are on the exact same page, that was my thinking as >> well. > > Before we talk about technically how to auto-submit tickets, we > should make sure that's what we want. Personally, I think the user > needs to have some say in whether a ticket gets filed. Not every > error MacPorts prints means there is a bug. For example, a checksum > error may indicate a problem with the user's network. A build > failure might occur if the user did not install dependencies with > the right architecture (or perhaps did not follow the Migration > procedure when upgrading to Snow Leopard). And what about > duplicates? We don't want 100 users (or even 2 users) filing tickets > for the same problem. We want users to locate existing issues in the > issue tracker and only file a new ticket if their issue is not > already covered. Is it safe to say we wouldn't want local repo submissions? // Brad From haraoka at gmail.com Tue Dec 1 16:53:37 2009 From: haraoka at gmail.com (Yoshiyuki HARAOKA) Date: Wed, 2 Dec 2009 09:53:37 +0900 Subject: [MacPorts] #21037: commons-dbcp does not compile In-Reply-To: <062.9c4769461556ae8ed725521b3c0881be@macports.org> References: <053.ee28856e45483d3622038964212559ef@macports.org> <062.9c4769461556ae8ed725521b3c0881be@macports.org> Message-ID: <9bf451ce0912011653g68fe4045ue6a818ee0fdc3eeb@mail.gmail.com> When is this patch merged? --haraoka On Sun, Nov 29, 2009 at 12:01 PM, MacPorts wrote: > #21037: commons-dbcp does not compile > -------------------------------+-------------------------------------------- > ?Reporter: ?johan@? ? ? ? ? ? ?| ? ? ? Owner: ?jberry@? > ? ? Type: ?defect ? ? ? ? ? ? | ? ? ?Status: ?new > ?Priority: ?Normal ? ? ? ? ? ? | ? Milestone: > Component: ?ports ? ? ? ? ? ? ?| ? ? Version: > ?Keywords: ? ? ? ? ? ? ? ? ? ? | ? ? ? ?Port: ?commons-dbcp > -------------------------------+-------------------------------------------- > > Comment(by nox@?): > > ?This bug is [https://issues.apache.org/jira/browse/DBCP-191 known by > ?upstream], I've attached a patch which fixes it. > > -- > Ticket URL: > MacPorts > Ports system for Mac OS > _______________________________________________ > macports-tickets mailing list > macports-tickets at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-tickets > From dports at ambulatoryclam.net Tue Dec 1 17:48:15 2009 From: dports at ambulatoryclam.net (Dan Ports) Date: Tue, 1 Dec 2009 17:48:15 -0800 Subject: Suggestion on auto ticket filing In-Reply-To: <2A0C5534-A055-4D4C-9B71-1CA714E50553@macports.org> References: <0D8EAAC3-D09D-4797-A746-723C33F6FB6B@newgeo.com> <805AD5FF-A357-414C-A792-BB1B4061465D@lavergne.gotdns.org> <2E7B1C57-C7F2-4E7B-A83B-DC08677B9A5B@newgeo.com> <2A0C5534-A055-4D4C-9B71-1CA714E50553@macports.org> Message-ID: <20091202014815.GA30227@ambulatoryclam.net> On Tue, Dec 01, 2009 at 05:13:58PM -0600, Ryan Schmidt wrote: > Before we talk about technically how to auto-submit tickets, we should make sure that's what we want. Personally, I think the user needs to have some say in whether a ticket gets filed. Personally, I'd be surprised if auto-submitted tickets proved useful at all. I would expect significant numbers of duplicates, invalid bugs, or bug reports for stale ports trees. I imagine that before too long people would stop looking at the automatic submissions, and they might even deter users from bothering to manually submit reports. On the other hand, automatically gathering up relevant information (system configurations, failure logs, etc) to attach to a report sounds quite handy. Maybe it would help to direct the user to a list of existing tickets that theirs might be duplicating? The existing trac report of open tickets against the same port would do nicely. I think I remember Ubuntu doing something similar for new ticket submissions. Dan -- Dan R. K. Ports Research Henchman Massachusetts Institute of Technology Computer Science and Artificial Intelligence Lab From brad at pixilla.com Tue Dec 1 17:59:54 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 1 Dec 2009 17:59:54 -0800 Subject: Suggestion on auto ticket filing In-Reply-To: <20091202014815.GA30227@ambulatoryclam.net> References: <0D8EAAC3-D09D-4797-A746-723C33F6FB6B@newgeo.com> <805AD5FF-A357-414C-A792-BB1B4061465D@lavergne.gotdns.org> <2E7B1C57-C7F2-4E7B-A83B-DC08677B9A5B@newgeo.com> <2A0C5534-A055-4D4C-9B71-1CA714E50553@macports.org> <20091202014815.GA30227@ambulatoryclam.net> Message-ID: On Dec 1, 2009, at 5:48 PM, Dan Ports wrote: > On Tue, Dec 01, 2009 at 05:13:58PM -0600, Ryan Schmidt wrote: >> Before we talk about technically how to auto-submit tickets, we >> should make sure that's what we want. Personally, I think the user >> needs to have some say in whether a ticket gets filed. > > Personally, I'd be surprised if auto-submitted tickets proved useful > at > all. I would expect significant numbers of duplicates, invalid bugs, > or > bug reports for stale ports trees. I imagine that before too long > people would stop looking at the automatic submissions, and they might > even deter users from bothering to manually submit reports. I could see this being the outcome. > On the other hand, automatically gathering up relevant information > (system configurations, failure logs, etc) to attach to a report > sounds > quite handy. Kept away from Trac or whatever were using. Dump it in a db that port maintainers can query. > Maybe it would help to direct the user to a list of existing tickets > that theirs might be duplicating? The existing trac report of open > tickets > against the same port would do nicely. I think I remember Ubuntu doing > something similar for new ticket submissions. And let them star the ticket that sounds like their issue or open a new one. And give port maintainers/users the ability to get star counts for their ports of interest. // Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From dports at ambulatoryclam.net Tue Dec 1 19:53:04 2009 From: dports at ambulatoryclam.net (Dan Ports) Date: Tue, 1 Dec 2009 19:53:04 -0800 Subject: emacs breakage on 10.6 Message-ID: <20091202035304.GB30227@ambulatoryclam.net> The emacs port (just regular emacs, not emacs-app) currently does not build under Snow Leopard. I backported the fix from the latest CVS release and put a patch for this in ticket #22364. It looks like ticket #21335 is a duplicate with essentially the same patch. The port appears to be abandoned by its maintainer (see #21273) -- can someone review and apply one of the patches? It would also be nice if emacs were eventually updated to 23.1, but perhaps that is a problem for another day. (I actually mostly use emacs-app-devel instead, but keep editors/emacs installed because various other ports depend on it.) Thanks, Dan -- Dan R. K. Ports Research Henchman Massachusetts Institute of Technology Computer Science and Artificial Intelligence Lab From ryandesign at macports.org Wed Dec 2 10:18:27 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Dec 2009 12:18:27 -0600 Subject: [61088] trunk/dports/aqua/qt4-mac-devel/Portfile In-Reply-To: References: <20091201203419.5B96E373C0D6@beta.macosforge.org> Message-ID: <92E05865-76DE-4903-86F7-FDE6F12D69B4@macports.org> On Dec 1, 2009, at 16:50, Jochen K?pper wrote: >> Does rpm-vercomp know that "4.6.0" is greater than "4.6.0-rc1"? If not, the epoch should be increased. > > Hah, good catch, thanks. > I?ve added "epoch 1? Thanks. >> Will qt4-mac also be updated to this version? > > I guess so;-) Looks like there's already a ticket filed for that too. http://trac.macports.org/ticket/22743 > Maybe we should resolve issues (like your ticket below) and also wait for 4.6.1 before doing this? Any other issues you're aware of? >> You did not encounter the error I reported in #22701? >> http://trac.macports.org/ticket/22701 > > no > > I?ve only run this on Snow Leopard systems, though. What system did you use? I saw the issue on Leopard, and so did somebody else who added a patch to the ticket, which I'll commit in a few hours once I see how far I get in this build attempt. From ryandesign at macports.org Thu Dec 3 10:30:18 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 3 Dec 2009 12:30:18 -0600 Subject: [61158] trunk/dports/emulators/dosbox/Portfile In-Reply-To: <20091203172531.5BE83378112C@beta.macosforge.org> References: <20091203172531.5BE83378112C@beta.macosforge.org> Message-ID: <16D87589-2ADD-4116-A76D-4594B20F7243@macports.org> On Dec 3, 2009, at 11:25, jmr at macports.org wrote: > Revision: 61158 > http://trac.macports.org/changeset/61158 > Author: jmr at macports.org > Date: 2009-12-03 09:25:27 -0800 (Thu, 03 Dec 2009) > Log Message: > ----------- > dosbox: pass correct arch to configure, Oh, interesting. Well it built an i386 executable even without that change. So do we even need to set the --build argument at all? > and don't bother testing for the existence of build_arch Thanks, I got confused between checking for the existence of build_arch (which you're right is not necessary) and checking whether build_arch is the empty string (which it could be on non-Darwin platforms but which we don't care about here). From macsforever2000 at macports.org Fri Dec 4 07:27:21 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Fri, 4 Dec 2009 08:27:21 -0700 Subject: [61171] trunk/dports/aqua In-Reply-To: <20091203224019.58670378781B@beta.macosforge.org> References: <20091203224019.58670378781B@beta.macosforge.org> Message-ID: <04011159-A4D9-439F-84B8-635F940BE0BB@macports.org> In principal I disagree with marking kdelibs3 and libevent as conflicting with qt4-mac and qt4-mac-devel. They only cause problems during the build phase for some reason. If those ports are deactivated during the build and reactivated afterwards, then they can co-exist just fine. But since you marked them as conflicting, these ports cannot be used together. Cheers! Frank On Dec 3, 2009, at 3:40 PM, ryandesign at macports.org wrote: > Revision > 61171 > Author > ryandesign at macports.org > Date > 2009-12-03 14:40:15 -0800 (Thu, 03 Dec 2009) > Log Message > > qt4-mac and qt4-mac-devel conflict with kdelibs3; see #20199 > Modified Paths > > trunk/dports/aqua/qt4-mac/Portfile > trunk/dports/aqua/qt4-mac-devel/Portfile > Diff > > Modified: trunk/dports/aqua/qt4-mac/Portfile (61170 => 61171) > > --- trunk/dports/aqua/qt4-mac/Portfile 2009-12-03 20:54:09 UTC (rev 61170) > +++ trunk/dports/aqua/qt4-mac/Portfile 2009-12-03 22:40:15 UTC (rev 61171) > @@ -4,7 +4,7 @@ > PortSystem 1.0 > > name qt4-mac > -conflicts qt4-mac-devel libevent > +conflicts qt4-mac-devel kdelibs3 libevent > version 4.5.3 > categories aqua > platforms macosx > Modified: trunk/dports/aqua/qt4-mac-devel/Portfile (61170 => 61171) > > --- trunk/dports/aqua/qt4-mac-devel/Portfile 2009-12-03 20:54:09 UTC (rev 61170) > +++ trunk/dports/aqua/qt4-mac-devel/Portfile 2009-12-03 22:40:15 UTC (rev 61171) > @@ -4,7 +4,7 @@ > PortSystem 1.0 > > name qt4-mac-devel > -conflicts qt4-mac libevent > +conflicts qt4-mac kdelibs3 libevent > epoch 1 > version 4.6.0 > categories aqua > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmr at macports.org Fri Dec 4 07:39:27 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 05 Dec 2009 02:39:27 +1100 Subject: [61171] trunk/dports/aqua In-Reply-To: <04011159-A4D9-439F-84B8-635F940BE0BB@macports.org> References: <20091203224019.58670378781B@beta.macosforge.org> <04011159-A4D9-439F-84B8-635F940BE0BB@macports.org> Message-ID: <4B192D2F.80208@macports.org> On 2009-12-5 02:27 , Frank Schima wrote: > In principal I disagree with marking kdelibs3 and libevent as > conflicting with qt4-mac and qt4-mac-devel. They only cause problems > during the build phase for some reason. If those ports are deactivated > during the build and reactivated afterwards, then they can co-exist just > fine. But since you marked them as conflicting, these ports cannot be > used together. Have you actually tried building with the conflicting port deactivated and reactivating it afterwards? - Josh From macsforever2000 at macports.org Fri Dec 4 07:49:24 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Fri, 4 Dec 2009 08:49:24 -0700 Subject: [61171] trunk/dports/aqua In-Reply-To: <4B192D2F.80208@macports.org> References: <20091203224019.58670378781B@beta.macosforge.org> <04011159-A4D9-439F-84B8-635F940BE0BB@macports.org> <4B192D2F.80208@macports.org> Message-ID: <21DF5754-6485-47A2-B902-2CB77251551E@macports.org> On Dec 4, 2009, at 8:39 AM, Joshua Root wrote: > On 2009-12-5 02:27 , Frank Schima wrote: >> In principal I disagree with marking kdelibs3 and libevent as >> conflicting with qt4-mac and qt4-mac-devel. They only cause problems >> during the build phase for some reason. If those ports are deactivated >> during the build and reactivated afterwards, then they can co-exist just >> fine. But since you marked them as conflicting, these ports cannot be >> used together. > > Have you actually tried building with the conflicting port deactivated > and reactivating it afterwards? OK, I just built libevent and it activated just fine even though I have qt4-mac installed. I withdraw my complaint. :) Cheers! Frank From talklists at newgeo.com Fri Dec 4 16:15:00 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 4 Dec 2009 16:15:00 -0800 Subject: p5-astro-satpass version update sent to trac Message-ID: <535A548B-6345-47A9-953A-AB8F9975E965@newgeo.com> I have attached Portfile-p5-astro-satpass.diff to the following ticket... http://trac.macports.org/ticket/22781 If there is any error in my submission process, please let me know. I would like to know: 1) Correct title format for new, patch, and version updates 2) Should diff and updated Portfile be attached 3) Any other things I can do to make the committers life easier 4) Should I even post to the dev list to make the ticket known Thank you -- Scott * If you contact me off list replace talklists@ with scott@ * From talklists at newgeo.com Fri Dec 4 16:24:33 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 4 Dec 2009 16:24:33 -0800 Subject: p5-io-socket-inet6 port updated Message-ID: I have revision bumped p5-io-socket-inet6 from 2.56 to 2.57 http://trac.macports.org/ticket/22783 -- Scott * If you contact me off list replace talklists@ with scott@ * From talklists at newgeo.com Fri Dec 4 16:57:05 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 4 Dec 2009 16:57:05 -0800 Subject: Port rbldnsd - added livecheck options Message-ID: No other changes to rbldnsd, just added the livecheck.regex and livecheck.url http://trac.macports.org/ticket/22784 -- Scott * If you contact me off list replace talklists@ with scott@ * From jmr at macports.org Sat Dec 5 01:24:55 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 05 Dec 2009 20:24:55 +1100 Subject: p5-astro-satpass version update sent to trac In-Reply-To: <535A548B-6345-47A9-953A-AB8F9975E965@newgeo.com> References: <535A548B-6345-47A9-953A-AB8F9975E965@newgeo.com> Message-ID: <4B1A26E7.1060208@macports.org> On 2009-12-5 11:15 , Scott Haneda wrote: > I would like to know: > 1) Correct title format for new, patch, and version updates All the guidelines we have are in the Guide: > 2) Should diff and updated Portfile be attached For existing Portfiles, just a diff (made with 'svn diff' or 'diff -u'). For patchfiles, it's less confusing to attach the whole file rather than a diff of a diff. > 4) Should I even post to the dev list to make the ticket known No, that's what macports-tickets is for. Only post to -dev if you think a ticket has been forgotten about. - Josh From jmr at macports.org Sat Dec 5 03:26:31 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 05 Dec 2009 22:26:31 +1100 Subject: Test base fixes Message-ID: <4B1A4367.3060507@macports.org> Could someone affected by them please test the (already committed) potential fixes for these base tickets? - Josh From ryandesign at macports.org Sat Dec 5 22:26:26 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 6 Dec 2009 00:26:26 -0600 Subject: p5-io-socket-inet6 port updated In-Reply-To: References: Message-ID: On Dec 4, 2009, at 18:24, Scott Haneda wrote: > I have revision bumped p5-io-socket-inet6 from 2.56 to 2.57 > http://trac.macports.org/ticket/22783 Done. From ryandesign at macports.org Sat Dec 5 22:28:45 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 6 Dec 2009 00:28:45 -0600 Subject: p5-astro-satpass version update sent to trac In-Reply-To: <535A548B-6345-47A9-953A-AB8F9975E965@newgeo.com> References: <535A548B-6345-47A9-953A-AB8F9975E965@newgeo.com> Message-ID: <8D0CB5FD-01EE-41DF-8D57-0C739E135C7E@macports.org> On Dec 4, 2009, at 18:15, Scott Haneda wrote: > I have attached Portfile-p5-astro-satpass.diff to the following ticket... > http://trac.macports.org/ticket/22781 > Done. From ryandesign at macports.org Sat Dec 5 22:29:55 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 6 Dec 2009 00:29:55 -0600 Subject: Port rbldnsd - added livecheck options In-Reply-To: References: Message-ID: On Dec 4, 2009, at 18:57, Scott Haneda wrote: > No other changes to rbldnsd, just added the livecheck.regex and livecheck.url > http://trac.macports.org/ticket/22784 Joshua took care of this one. From software at macfreek.nl Mon Dec 7 03:39:43 2009 From: software at macfreek.nl (Freek Dijkstra) Date: Mon, 07 Dec 2009 12:39:43 +0100 Subject: wxWidgets Message-ID: <4B1CE97F.9070100@macfreek.nl> Hi, I submitted a patch for the wxWidgets portfile just over two months ago. It has been tested on Intel (10.5 32bit Intel + 10.6 64bit Intel + 10.5 32bit PPC), and there have been reports by others that it works. I'm not sure what the typical time is before a patch is put in the repository, but I really appreciate it if someone could do that. https://trac.macports.org/ticket/20952 Thanks, Freek Dijkstra From jmr at macports.org Mon Dec 7 04:10:48 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 07 Dec 2009 23:10:48 +1100 Subject: wxWidgets In-Reply-To: <4B1CE97F.9070100@macfreek.nl> References: <4B1CE97F.9070100@macfreek.nl> Message-ID: <4B1CF0C8.40901@macports.org> On 2009-12-7 22:39 , Freek Dijkstra wrote: > Hi, > > I submitted a patch for the wxWidgets portfile just over two months ago. > It has been tested on Intel (10.5 32bit Intel + 10.6 64bit Intel + 10.5 > 32bit PPC), and there have been reports by others that it works. > > I'm not sure what the typical time is before a patch is put in the > repository, but I really appreciate it if someone could do that. > > https://trac.macports.org/ticket/20952 I don't see any patch for wxWidgets there. If you're referring to the Portfile labelled "Working portfile for wxWidgets 2.9.0", 2.9.0 is already available as wxWidgets-devel. - Josh From software at macfreek.nl Mon Dec 7 07:59:03 2009 From: software at macfreek.nl (Freek Dijkstra) Date: Mon, 07 Dec 2009 16:59:03 +0100 Subject: -dev ports (Was: wxWidgets) In-Reply-To: <4B1CF0C8.40901@macports.org> References: <4B1CE97F.9070100@macfreek.nl> <4B1CF0C8.40901@macports.org> Message-ID: <4B1D2647.4000001@macfreek.nl> [now with the correct sender so it goes to the list] Freek Dijkstra asked: >> I submitted a patch for the wxWidgets portfile just over two months ago. >> >> I'm not sure what the typical time is before a patch is put in the >> repository, but I really appreciate it if someone could do that. Joshua Root replied: > 2.9.0 is already available as wxWidgets-devel. Ah, thanks. Out of curiosity: why was this report not closed with a referal to the other package? Why are there actually two packages, especially considering that they do the same and one of them is non-functional? Of course it is my own stupid mistake to not consider that option, and wasting my time on a problem that someone else has already solved, but I given that there are still quite a lot of other people on the cc I think I'm not the only one who finds the current situation utterly confusing. In particular, other ports that depend on wxWidgets will install the "regular" wxWidgets port, and will fail. Of course, it is possible for users to still install wxWidgets-dev manually, but that still means they can not install the ports that depend on the regular wxWidgets, because the whole dependency chain will fail. to me, this more or less removes the whole purpose of having a package manager. Regards, Freek Dijkstra From software at macfreek.nl Mon Dec 7 09:15:21 2009 From: software at macfreek.nl (Freek Dijkstra) Date: Mon, 07 Dec 2009 18:15:21 +0100 Subject: -dev ports (Was: wxWidgets) In-Reply-To: <4B1D2647.4000001@macfreek.nl> References: <4B1CE97F.9070100@macfreek.nl> <4B1CF0C8.40901@macports.org> <4B1D2647.4000001@macfreek.nl> Message-ID: <4B1D3829.3030701@macfreek.nl> Joshua Root deferred: >> 2.9.0 is already available as wxWidgets-devel. Just had a quick look; the wxWidgets-devel Portfile seems to be the one by vince, which uses a subversion pre-release of 2.9.0. The one I created and tested uses the actual 2.9.0 release. Since stuff like wxPython depends on wxWidgets, not on wxWidgets-devel, a working Portfile for wxWidgets is really needed. Fortunately, it exists for over two months now, so one last try: could someone please upload the Portfile? (if someone likes to take a stab at the still open bug that Universal does not build, that would be highly appreciated; see #20952, #21530 and #22815. That bug is present in the wxWidget Portfiles for 2.6.4, 2.8.9, 2.9.0 and in the wxWidgets-devel Portfile for 2.9.0). Regards, Freek From ryandesign at macports.org Mon Dec 7 12:58:25 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 7 Dec 2009 14:58:25 -0600 Subject: -devel ports In-Reply-To: <4B1D3829.3030701@macfreek.nl> References: <4B1CE97F.9070100@macfreek.nl> <4B1CF0C8.40901@macports.org> <4B1D2647.4000001@macfreek.nl> <4B1D3829.3030701@macfreek.nl> Message-ID: <71A9F1B1-BD09-4E7F-B451-AD56AD8AA47A@macports.org> On Dec 7, 2009, at 11:15, Freek Dijkstra wrote: > Joshua Root deferred: > >>> 2.9.0 is already available as wxWidgets-devel. > > Just had a quick look; the wxWidgets-devel Portfile seems to be the one by vince, which uses a subversion pre-release of 2.9.0. > > The one I created and tested uses the actual 2.9.0 release. > > Since stuff like wxPython depends on wxWidgets, not on wxWidgets-devel, a working Portfile for wxWidgets is really needed. Fortunately, it exists for over two months now, so one last try: could someone please upload the Portfile? > > (if someone likes to take a stab at the still open bug that Universal does not build, that would be highly appreciated; see #20952, #21530 and #22815. That bug is present in the wxWidget Portfiles for 2.6.4, 2.8.9, 2.9.0 and in the wxWidgets-devel Portfile for 2.9.0). -devel ports are for development versions of software. Non-devel ports are for stable versions of software. This is not documented in the guide or wiki, but the request to have it documented is here: http://trac.macports.org/ticket/14540 It's usually not a good idea to update a stable port (wxWidgets) to a non-stable version (2.9.0). I can't confirm your statement that wxWidgets-devel is by vince and uses a Subversion pre-release of 2.9.0; as far as I can tell it is maintained by jwa and was updated to the final 2.9.0 in r57894 three months ago. Vince has commented on the bug you're talking about, though, as I'm sure you've read, and pointed out that even if we update wxWidgets to 2.9.0, the released version of py26-wxwidgets will not compile: http://trac.macports.org/ticket/20952#comment:20 If we decide wxWidgets should be an exception to the rule, and update it to 2.9.0, we would then have to update py26-wxwidgets and perhaps other ports that depend on wxWidgets to an unstable version as well. I'm sure you can appreciate that in a package manager like MacPorts where users expect to get stable versions of software, it would be bad to suddenly deliver development versions to them without warning. I will grant that users also expect ports to work, and I see that wxWidgets 2.8 does not work on 64-bit Snow Leopard, and I understand and apologize for your frustration, but you may wish to direct it at the developers of wxWidgets instead and encourage them to release a stable version of their software that compiles 64-bit on Snow Leopard. You're right that ports like py26-wxpython depend on port:wxWidgets and therefore port:wxWidgets-devel does not satisfy that dependency. A solution is to rewrite the dependency in ports like py26-wxpython, changing "port:wxWidgets" to e.g. "path:bin/wx-config:wxWidgets"; this would allow any port that provides ${prefix}/bin/wx-config (i.e. either wxWidgets or wxWidgets-devel) to satisfy the dependency. We have done this for other ports in the past. For example, my ports cairo, pango, libpixman, graphviz, php5, and mysql5 all have -devel versions, and most ports that declare dependencies on them do so in a way that either of them can satisfy it. But, as mentioned above, it sounds like 2.9 may be substantially different from 2.8 such that ports that work with 2.8 won't work with 2.9/2.10. We've encountered that before in the upgrade from 2.6 to 2.8, which is why a wxWidgets26 port was created after wxWidgets was updated to 2.8, to accommodate software that hadn't been updated to work with 2.8. Maybe we need to revisit the naming of these ports, and always use the branch number (i.e. rename wxWidgets to wxWidgets28, rename wxWidgets-devel to wxWidgets210, allow wxWidgets28 and wxWidgets210 to install simultaneously in different directories, update dependencies in other ports). I feel I should stop rambling at this point but I hope I've explained some of the issues and considerations involved, though I realize I haven't provided a clear answer about what should be done now, because I don't know. From brooks at clarksonline.net Mon Dec 7 15:46:23 2009 From: brooks at clarksonline.net (M. Brooks Clark) Date: Mon, 7 Dec 2009 17:46:23 -0600 Subject: Installing config files Message-ID: Due to some changes in the way the author is handling the installation of the wview package, I'm looking for some strategies on how to best handle this in MacPorts. Currently, wview installs configuration files and html template files in /opt/local/etc/wview and /opt/local/etc/wview/html (many files). It also installs a database file in /opt/local/var/wview. With recent changes to the build system, these files will now get overwritten during an upgrade and will be removed during an uninstall. Should I install /opt/local/etc/wview as something like /opt/local/etc/wview.sample, then check if /opt/local/etc/wview is present. If not, copy /opt/local/etc/wview.sample to /opt/local/etc/wview in a post-activate step? Or do I need to do this check for each individual file? Alternatively, should I install the files in /opt/local/share/wview, then copy the whole directory to /opt/local/etc/wview if it is not present? Similar question for the database file(s) in /opt/local/var/wview? What is the preferred/recommended practice? Thanks, Brooks From jmr at macports.org Mon Dec 7 22:12:55 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 08 Dec 2009 17:12:55 +1100 Subject: -dev ports (Was: wxWidgets) In-Reply-To: <4B1D2647.4000001@macfreek.nl> References: <4B1CE97F.9070100@macfreek.nl> <4B1CF0C8.40901@macports.org> <4B1D2647.4000001@macfreek.nl> Message-ID: <4B1DEE67.1060704@macports.org> On 2009-12-8 02:59 , Freek Dijkstra wrote: > [now with the correct sender so it goes to the list] > > Freek Dijkstra asked: > >>> I submitted a patch for the wxWidgets portfile just over two months ago. >>> >>> I'm not sure what the typical time is before a patch is put in the >>> repository, but I really appreciate it if someone could do that. > > Joshua Root replied: > >> 2.9.0 is already available as wxWidgets-devel. > > Ah, thanks. > > Out of curiosity: why was this report not closed with a referal to the > other package? Because wxWidgets still does not build 64-bit, and that is the subject of the bug report. It would of course be useful in the meantime to add a check to the wxWidgets portfile to error out early if $build_arch is something 64-bit, and recommend using wxWidgets-devel instead. Normally it would also be useful to add a similar check in dependent ports that changes the dependency to the -devel version (and also allow either version to fulfil the dep), but in this case it seems that many of the dependents won't work with 2.9.0 yet. Actually, since the problem is Carbon, could wxWidgets be switched to an X11-based back end instead when building 64-bit? - Josh From vince at macports.org Tue Dec 8 03:56:43 2009 From: vince at macports.org (vincent habchi) Date: Tue, 8 Dec 2009 12:56:43 +0100 Subject: -devel ports In-Reply-To: <71A9F1B1-BD09-4E7F-B451-AD56AD8AA47A@macports.org> References: <4B1CE97F.9070100@macfreek.nl> <4B1CF0C8.40901@macports.org> <4B1D2647.4000001@macfreek.nl> <4B1D3829.3030701@macfreek.nl> <71A9F1B1-BD09-4E7F-B451-AD56AD8AA47A@macports.org> Message-ID: Le 7 d?c. 2009 ? 21:58, Ryan Schmidt a ?crit : > I feel I should stop rambling at this point but I hope I've explained some of the issues and considerations involved, though I realize I haven't provided a clear answer about what should be done now, because I don't know. Could you be more specific? :) I know I should have followed this thread more closely. I am trying to learn Cocoa, that's a bit hard so it takes me a lot of time. Sorry for that. Vincent From mail at uwe-arzt.de Tue Dec 8 08:28:14 2009 From: mail at uwe-arzt.de (Uwe Arzt) Date: Tue, 8 Dec 2009 17:28:14 +0100 Subject: Commit of Portfile change in #22740 Message-ID: <7042BF6B-F5F1-461B-A269-FCDE6C68C421@uwe-arzt.de> Hi all, can someone look into that bug and submit it? The git repo for pthsem doesn't provide a configure any more. Thanks Uwe -- mail at uwe-arzt.de www.uwe-arzt.de From rmsfisher at macports.org Tue Dec 8 10:52:44 2009 From: rmsfisher at macports.org (Ryan Stonecipher-Fisher) Date: Tue, 8 Dec 2009 12:52:44 -0600 Subject: Installing config files Message-ID: <6612b2e0912081052j784db525q12b2a9fa79201f29@mail.gmail.com> Brooks, Lines 71-80 of the current mpd Portfile may help solve your problem. Post-destroot is a good phase for doing conditional installation of example/default configuration files. Cheers, Ryan Stonecipher-Fisher 573.489.2848 ---------- Forwarded message ---------- From: "M. Brooks Clark" To: MacPorts Development Date: Mon, 7 Dec 2009 17:46:23 -0600 Subject: Installing config files Due to some changes in the way the author is handling the installation of the wview package, I'm looking for some strategies on how to best handle this in MacPorts. Currently, wview installs configuration files and html template files in /opt/local/etc/wview and /opt/local/etc/wview/html (many files). It also installs a database file in /opt/local/var/wview. With recent changes to the build system, these files will now get overwritten during an upgrade and will be removed during an uninstall. Should I install /opt/local/etc/wview as something like /opt/local/etc/wview.sample, then check if /opt/local/etc/wview is present. If not, copy /opt/local/etc/wview.sample to /opt/local/etc/wview in a post-activate step? Or do I need to do this check for each individual file? Alternatively, should I install the files in /opt/local/share/wview, then copy the whole directory to /opt/local/etc/wview if it is not present? Similar question for the database file(s) in /opt/local/var/wview? What is the preferred/recommended practice? Thanks, Brooks From ryandesign at macports.org Tue Dec 8 15:11:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 8 Dec 2009 17:11:23 -0600 Subject: Shouldn't arch flags also go in LDFLAGS? Message-ID: <03450869-D7CD-4776-B1B3-6CAC333D8828@macports.org> Port pure wasn't respecting build_arch properly. In discussing this with the developer of pure, I told him MacPorts puts the arch flags in CFLAGS and CPPFLAGS, and he explained that we should also be putting them in LDFLAGS [1]. I notice the muniversal portgroup and the regular universal variant both do this when building universal. Is there any reason base should not also do so when not building universal? [1] http://groups.google.com/group/pure-lang/browse_thread/thread/325daccbd9439a00#40fbc4af7c34574a From jmr at macports.org Tue Dec 8 15:27:09 2009 From: jmr at macports.org (Joshua Root) Date: Wed, 09 Dec 2009 10:27:09 +1100 Subject: Shouldn't arch flags also go in LDFLAGS? In-Reply-To: <03450869-D7CD-4776-B1B3-6CAC333D8828@macports.org> References: <03450869-D7CD-4776-B1B3-6CAC333D8828@macports.org> Message-ID: <4B1EE0CD.3010802@macports.org> On 2009-12-9 10:11 , Ryan Schmidt wrote: > Port pure wasn't respecting build_arch properly. In discussing this with the developer of pure, I told him MacPorts puts the arch flags in CFLAGS and CPPFLAGS, and he explained that we should also be putting them in LDFLAGS [1]. I notice the muniversal portgroup and the regular universal variant both do this when building universal. Is there any reason base should not also do so when not building universal? - Josh From ryandesign at macports.org Tue Dec 8 15:34:01 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 8 Dec 2009 17:34:01 -0600 Subject: Shouldn't arch flags also go in LDFLAGS? In-Reply-To: <4B1EE0CD.3010802@macports.org> References: <03450869-D7CD-4776-B1B3-6CAC333D8828@macports.org> <4B1EE0CD.3010802@macports.org> Message-ID: On Dec 8, 2009, at 17:27, Joshua Root wrote: > On 2009-12-9 10:11 , Ryan Schmidt wrote: > >> Port pure wasn't respecting build_arch properly. In discussing this with the developer of pure, I told him MacPorts puts the arch flags in CFLAGS and CPPFLAGS, and he explained that we should also be putting them in LDFLAGS [1]. I notice the muniversal portgroup and the regular universal variant both do this when building universal. Is there any reason base should not also do so when not building universal? > > Thanks, I read that before but it obviously didn't stick in my brain. :) So it looks like this has been fixed in trunk in r60662 and r60680. (I should test that with pure without the patch.) There's several things I still want to merge back to the 1.8 branch for hopefully a 1.8.2 release soon. Any reason I couldn't merge these as well? From cssdev at mac.com Wed Dec 9 04:56:39 2009 From: cssdev at mac.com (cssdev at mac.com) Date: Wed, 09 Dec 2009 07:56:39 -0500 Subject: emacs breakage on 10.6 In-Reply-To: <20091202035304.GB30227@ambulatoryclam.net> References: <20091202035304.GB30227@ambulatoryclam.net> Message-ID: <60E54254-093C-45FA-8084-CD7297A0D8F2@mac.com> On Dec 1, 2009, at 10:53 PM, Dan Ports wrote: > It would also be nice if emacs were eventually updated to 23.1, but > perhaps that is a problem for another day. (I actually mostly use > emacs-app-devel instead, but keep editors/emacs installed because various > other ports depend on it.) But how much do those ports actually depend on that specific emacs build? Shouldn't other ports be able to use either emacs or emacs-app-devel? The emacs-app-devel port will load lisp files from ${prefix}. Chris From jmr at macports.org Wed Dec 9 05:20:50 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 10 Dec 2009 00:20:50 +1100 Subject: Shouldn't arch flags also go in LDFLAGS? In-Reply-To: References: <03450869-D7CD-4776-B1B3-6CAC333D8828@macports.org> <4B1EE0CD.3010802@macports.org> Message-ID: <4B1FA432.7040306@macports.org> On 2009-12-9 10:34 , Ryan Schmidt wrote: > > On Dec 8, 2009, at 17:27, Joshua Root wrote: > >> On 2009-12-9 10:11 , Ryan Schmidt wrote: >> >>> Port pure wasn't respecting build_arch properly. In discussing this with the developer of pure, I told him MacPorts puts the arch flags in CFLAGS and CPPFLAGS, and he explained that we should also be putting them in LDFLAGS [1]. I notice the muniversal portgroup and the regular universal variant both do this when building universal. Is there any reason base should not also do so when not building universal? >> >> > > Thanks, I read that before but it obviously didn't stick in my brain. :) > > So it looks like this has been fixed in trunk in r60662 and r60680. (I should test that with pure without the patch.) > > There's several things I still want to merge back to the 1.8 branch for hopefully a 1.8.2 release soon. Any reason I couldn't merge these as well? Don't see why not. - Josh From ryandesign at macports.org Wed Dec 9 16:09:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 9 Dec 2009 18:09:13 -0600 Subject: [61345] trunk/dports/devel/soprano/Portfile In-Reply-To: <20091209133800.769C6381E2C6@beta.macosforge.org> References: <20091209133800.769C6381E2C6@beta.macosforge.org> Message-ID: <4335B11E-43C9-44ED-BE1E-BBB50BE58CF7@macports.org> On Dec 9, 2009, at 07:38, rmsfisher at macports.org wrote: > Revision: 61345 > http://trac.macports.org/changeset/61345 > Author: rmsfisher at macports.org > Date: 2009-12-09 05:37:57 -0800 (Wed, 09 Dec 2009) > Log Message: > ----------- > devel/soprano upgraded version > > Modified Paths: > -------------- > trunk/dports/devel/soprano/Portfile > > Modified: trunk/dports/devel/soprano/Portfile > =================================================================== > --- trunk/dports/devel/soprano/Portfile 2009-12-09 05:54:16 UTC (rev 61344) > +++ trunk/dports/devel/soprano/Portfile 2009-12-09 13:37:57 UTC (rev 61345) > @@ -4,7 +4,7 @@ > PortGroup kde4 1.0 > > name soprano > -version 2.3.1 > +version 2.3.70 Are you sure you want to do that? 2.3.70 is a beta version of 2.4; 2.3.1 was a stable version. As such, 2.3.70 would be more at home in a soprano-devel port. http://soprano.sourceforge.net/node/40 From ryandesign at macports.org Thu Dec 10 02:15:11 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 10 Dec 2009 04:15:11 -0600 Subject: [61389] trunk/dports/net/libtorrent-devel/Portfile In-Reply-To: <20091210092826.7539B383FA29@beta.macosforge.org> References: <20091210092826.7539B383FA29@beta.macosforge.org> Message-ID: <302BA05A-BAC7-4CB0-9F71-1B65A0AE5CEC@macports.org> On Dec 10, 2009, at 03:28, mnick at macports.org wrote: > Revision: 61389 > http://trac.macports.org/changeset/61389 > Author: mnick at macports.org > Date: 2009-12-10 01:28:18 -0800 (Thu, 10 Dec 2009) > Log Message: > ----------- > maintainer update (ticket #22758) > long_description \ > libTorrent is a BitTorrent library written in C++ for \ > *nix. It is designed to avoid redundant copying and \ > storing of data that other clients and libraries suffer from. \ > - This is the development version of libTorrent. > + This is the "unstable" release of libTorrent. Note that quotes in the long description won't actually show up in "port info" unless you escape them with a backslash. > -livecheck.type regex > +livecheck.check regex As you already discovered, livecheck.check was replaced by livecheck.type, so you should not change it back. Be sure you run "svn diff" before every commit to make sure what you're committing makes sense, and run "port lint" too to make sure there aren't any errors. From jwa at macports.org Thu Dec 10 08:48:20 2009 From: jwa at macports.org (Jyrki Wahlstedt) Date: Thu, 10 Dec 2009 18:48:20 +0200 Subject: -devel ports In-Reply-To: <71A9F1B1-BD09-4E7F-B451-AD56AD8AA47A@macports.org> References: <4B1CE97F.9070100@macfreek.nl> <4B1CF0C8.40901@macports.org> <4B1D2647.4000001@macfreek.nl> <4B1D3829.3030701@macfreek.nl> <71A9F1B1-BD09-4E7F-B451-AD56AD8AA47A@macports.org> Message-ID: <0C629E3D-AEE9-498E-A1B3-AF802DC4F54C@macports.org> Sorry for being late in answering, comments between lines below... On 7.12.2009, at 22.58, Ryan Schmidt wrote: > On Dec 7, 2009, at 11:15, Freek Dijkstra wrote: > >> Joshua Root deferred: >> >>>> 2.9.0 is already available as wxWidgets-devel. >> >> Just had a quick look; the wxWidgets-devel Portfile seems to be the one by vince, which uses a subversion pre-release of 2.9.0. >> >> The one I created and tested uses the actual 2.9.0 release. This is news to me, as when I just looked at the project site, the stable version is 2.8.10, 2.9.0 is still a development snapshot. I may be wrong, but even Sourceforge package dates from the same time as the one referred to in the -devel Portfile. If the project has moved to another home, would be good to know. Yes, I might be the one to blame about this, as I have been doing the upgrades most of the time with wxWidgets (my co-maintainer, mww, has several other ports to maintain, and other stuff to do). >> >> Since stuff like wxPython depends on wxWidgets, not on wxWidgets-devel, a working Portfile for wxWidgets is really needed. Fortunately, it exists for over two months now, so one last try: could someone please upload the Portfile? >> >> (if someone likes to take a stab at the still open bug that Universal does not build, that would be highly appreciated; see #20952, #21530 and #22815. That bug is present in the wxWidget Portfiles for 2.6.4, 2.8.9, 2.9.0 and in the wxWidgets-devel Portfile for 2.9.0). > > -devel ports are for development versions of software. Non-devel ports are for stable versions of software. This is not documented in the guide or wiki, but the request to have it documented is here: > > http://trac.macports.org/ticket/14540 > > It's usually not a good idea to update a stable port (wxWidgets) to a non-stable version (2.9.0). I can't confirm your statement that wxWidgets-devel is by vince and uses a Subversion pre-release of 2.9.0; as far as I can tell it is maintained by jwa and was updated to the final 2.9.0 in r57894 three months ago. Vince has commented on the bug you're talking about, though, as I'm sure you've read, and pointed out that even if we update wxWidgets to 2.9.0, the released version of py26-wxwidgets will not compile: > > http://trac.macports.org/ticket/20952#comment:20 > > If we decide wxWidgets should be an exception to the rule, and update it to 2.9.0, we would then have to update py26-wxwidgets and perhaps other ports that depend on wxWidgets to an unstable version as well. I'm sure you can appreciate that in a package manager like MacPorts where users expect to get stable versions of software, it would be bad to suddenly deliver development versions to them without warning. I will grant that users also expect ports to work, and I see that wxWidgets 2.8 does not work on 64-bit Snow Leopard, and I understand and apologize for your frustration, but you may wish to direct it at the developers of wxWidgets instead and encourage them to release a stable version of their software that compiles 64-bit on Snow Leopard. > > You're right that ports like py26-wxpython depend on port:wxWidgets and therefore port:wxWidgets-devel does not satisfy that dependency. A solution is to rewrite the dependency in ports like py26-wxpython, changing "port:wxWidgets" to e.g. "path:bin/wx-config:wxWidgets"; this would allow any port that provides ${prefix}/bin/wx-config (i.e. either wxWidgets or wxWidgets-devel) to satisfy the dependency. We have done this for other ports in the past. For example, my ports cairo, pango, libpixman, graphviz, php5, and mysql5 all have -devel versions, and most ports that declare dependencies on them do so in a way that either of them can satisfy it. > > But, as mentioned above, it sounds like 2.9 may be substantially different from 2.8 such that ports that work with 2.8 won't work with 2.9/2.10. We've encountered that before in the upgrade from 2.6 to 2.8, which is why a wxWidgets26 port was created after wxWidgets was updated to 2.8, to accommodate software that hadn't been updated to work with 2.8. Maybe we need to revisit the naming of these ports, and always use the branch number (i.e. rename wxWidgets to wxWidgets28, rename wxWidgets-devel to wxWidgets210, allow wxWidgets28 and wxWidgets210 to install simultaneously in different directories, update dependencies in other ports). > > I feel I should stop rambling at this point but I hope I've explained some of the issues and considerations involved, though I realize I haven't provided a clear answer about what should be done now, because I don't know. > The reason I have not been updated wxWidgets port is that I've been quite late in upgrading to SL. Now I have done that, but I'm still in the process of upgrading my libraries &c. to work in the snowy world (well, I'm in Finland, so...). I noticed that the wxWidgets fold have collected a list of hints and tips to build wxWidgets on SL. The big thing with wxWidgets actually is that it is moving to use Cocoa-based structures instead of Carbon. Hence the difficulties that hopefully can be overcome! ! ! Jyrki Wahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386 From jmr at macports.org Thu Dec 10 09:10:52 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 11 Dec 2009 04:10:52 +1100 Subject: wxWidgets (was: Re: -devel ports) In-Reply-To: <0C629E3D-AEE9-498E-A1B3-AF802DC4F54C@macports.org> References: <4B1CE97F.9070100@macfreek.nl> <4B1CF0C8.40901@macports.org> <4B1D2647.4000001@macfreek.nl> <4B1D3829.3030701@macfreek.nl> <71A9F1B1-BD09-4E7F-B451-AD56AD8AA47A@macports.org> <0C629E3D-AEE9-498E-A1B3-AF802DC4F54C@macports.org> Message-ID: <4B212B9C.8050706@macports.org> On 2009-12-11 03:48 , Jyrki Wahlstedt wrote: > This > is news to me, as when I just looked at the project site, the stable version is 2.8.10, 2.9.0 is still a development snapshot. That's correct. > I noticed that the wxWidgets fold have collected a list of hints and tips to build wxWidgets on SL. It builds fine on SL AFAIK, the problem is that the stable release doesn't build 64-bit (at least wxMac doesn't). The "solution" on their wiki is to build 32-bit, which is of course no solution at all. - Josh From ryandesign at macports.org Thu Dec 10 12:19:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 10 Dec 2009 14:19:41 -0600 Subject: [61108] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: References: <20091202033414.DDDEF3744247@beta.macosforge.org> Message-ID: <41D46A86-7AB9-41E2-9D07-89C0CF919DC1@macports.org> Jeremy, allow me to bring this to the macports-dev list... On Dec 10, 2009, at 13:23, Jeremy Huddleston wrote: > On Dec 1, 2009, at 19:34, ryandesign at macports.org wrote: > >> Revision: 61108 >> http://trac.macports.org/changeset/61108 >> Author: ryandesign at macports.org >> Date: 2009-12-01 19:34:12 -0800 (Tue, 01 Dec 2009) >> Log Message: >> ----------- >> muniversal-1.0.tcl: compare contents of compressed files, not the compressed files themselves; see #22650 > > I think you may have broken muniversal with this change. See attached log for installing tiff. > > > :debug:destroot Backtrace: /opt/local/lib/libtiff.la differs in /opt/local/var/macports/build/_Users_jeremy_src_macports-trunk_dports_graphics_tiff/work/destroot-i386 and /opt/local/var/macports/build/_Users_jeremy_src_macports-trunk_dports_graphics_tiff/work/destroot-x86_64 and cannot be merged That wasn't because of r61108, but because of r61090. And that revision wouldn't have broken tiff or any other port; that revision merely causes MacPorts to notify you that tiff +universal is already broken. Before, you would've gotten a broken .la file without knowing it. muniversal tries to merge files using C/C++ preprocessor directives, which are not appropriate for .la files or .pc files or -config scripts. muniversal previous assumed those types of files would never differ. Sometimes they do. So r61090 now actively prevents those files from being merged. See #21953 for the long list of related confusing issues that had previously been caused by not having this in place. This change will probably reveal many ports that have been broken all along. For example a ticket was filed for pango +quartz +universal. I don't know how to fix it but now we at least prevent users from installing software that they think is working properly when it really isn't. In the case of tiff, though, it installs fine for me. So I would be interested for you to show me how libtiff.la differs between your two destroots. Could you send me those two libtiff.la files, or run a diff -ru between your two destroots and see how they (and perhaps other files) differ? One common reason why such files might differ is if one of the dependencies (jpeg, zlib) wasn't built universal. If that's the reason here, we could add archcheck to tiff to prevent it in the future. From ryandesign at macports.org Thu Dec 10 12:44:43 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 10 Dec 2009 14:44:43 -0600 Subject: [61345] trunk/dports/devel/soprano/Portfile In-Reply-To: <6612b2e0912100529r7c23c675p4d8ef83e77b5d294@mail.gmail.com> References: <20091209133800.769C6381E2C6@beta.macosforge.org> <4335B11E-43C9-44ED-BE1E-BBB50BE58CF7@macports.org> <6612b2e0912100529r7c23c675p4d8ef83e77b5d294@mail.gmail.com> Message-ID: <42FDCCEE-F4CE-41B8-9626-28E66DE4F55F@macports.org> On Dec 10, 2009, at 07:29, Ryan Stonecipher-Fisher wrote: > On Wed, Dec 9, 2009 at 6:09 PM, Ryan Schmidt wrote: >> > >> On Dec 9, 2009, at 07:38, rmsfisher at macports.org wrote: >> >>> Revision: 61345 >>> http://trac.macports.org/changeset/61345 >>> Author: rmsfisher at macports.org >>> Date: 2009-12-09 05:37:57 -0800 (Wed, 09 Dec 2009) >>> Log Message: >>> ----------- >>> devel/soprano upgraded version >>> >>> Modified Paths: >>> -------------- >>> trunk/dports/devel/soprano/Portfile >>> >>> Modified: trunk/dports/devel/soprano/Portfile >>> =================================================================== >>> --- trunk/dports/devel/soprano/Portfile 2009-12-09 05:54:16 UTC (rev 61344) >>> +++ trunk/dports/devel/soprano/Portfile 2009-12-09 13:37:57 UTC (rev 61345) >>> @@ -4,7 +4,7 @@ >>> PortGroup kde4 1.0 >>> >>> name soprano >>> -version 2.3.1 >>> +version 2.3.70 >> >> Are you sure you want to do that? 2.3.70 is a beta version of 2.4; 2.3.1 was a stable version. As such, 2.3.70 would be more at home in a soprano-devel port. >> >> http://soprano.sourceforge.net/node/40 > > It seems to run fine but if you wish to revert to 2.3.1 that may be > better in case some behavioral quirk is present that I have not yet > bumped into. I don't doubt it appears to run fine for you, but your testing was probably not exhaustive, and there may be cases where this pre-release version doesn't work perfectly; if it did, I have to assume the developers would have released it as a stable version. In MacPorts we like to offer stable versions, not development versions (except in -devel ports); see the ongoing discussion on this list about -devel ports and wxWidgets. Unless there is a reason why 2.3.1 totally doesn't work anymore, the port should be downgraded back to 2.3.1. To do that, you'll have to increase the port's epoch from its default 0 to a higher integer, for example 1, so that anyone who already upgraded to 2.3.70 will be prompted to downgrade again. > Is there an easy way to determine that a livecheck suggestion is not a > stable release? No, you just have to know the versioning scheme used by the software. Some projects use the "2nd digit is odd" rule for unstable releases (cairo, glib2, graphviz, libpixman, pango, wine). Others use "3rd digit is large" rule (fontconfig, obby, gobby, sobby, net6 use .90 and higher). Still others label their development releases "alpha", "beta", or "rc" (php5). Once you know how they label their development versions, you can fix the livecheck to skip those versions. I fixed soprano's livecheck in r61410 using a version of the one from fontconfig. From jeremyhu at macports.org Thu Dec 10 14:30:10 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Thu, 10 Dec 2009 14:30:10 -0800 Subject: [61108] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: <41D46A86-7AB9-41E2-9D07-89C0CF919DC1@macports.org> References: <20091202033414.DDDEF3744247@beta.macosforge.org> <41D46A86-7AB9-41E2-9D07-89C0CF919DC1@macports.org> Message-ID: <361D79AA-E00E-481E-96EA-DAF556A9D2C4@macports.org> Ah... it's a difference in -ljbig : /usr/bin/file /opt/local/lib/libjbig.dylib /opt/local/lib/libjbig.dylib: Mach-O 64-bit dynamically linked shared library x86_64 Looks like jbigkit lies about being universal... --- libtiff.la.i386 2009-12-10 14:25:50.000000000 -0800 +++ libtiff.la.x86_64 2009-12-10 14:26:02.000000000 -0800 @@ -17,7 +17,7 @@ old_library='libtiff.a' inherited_linker_flags=' ' # Libraries that this one depends upon. -dependency_libs=' -L/opt/local/lib /opt/local/lib/libjpeg.la -lz -lc' +dependency_libs=' -L/opt/local/lib -ljbig /opt/local/lib/libjpeg.la -lz -lc' # Names of additional weak libraries provided by this library weak_library_names='' -------------- next part -------------- A non-text attachment was scrubbed... Name: libtiff.la.x86_64 Type: application/octet-stream Size: 971 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: libtiff.la.i386 Type: application/octet-stream Size: 964 bytes Desc: not available URL: -------------- next part -------------- On Dec 10, 2009, at 12:19, Ryan Schmidt wrote: > Jeremy, allow me to bring this to the macports-dev list... > > On Dec 10, 2009, at 13:23, Jeremy Huddleston wrote: > >> On Dec 1, 2009, at 19:34, ryandesign at macports.org wrote: >> >>> Revision: 61108 >>> http://trac.macports.org/changeset/61108 >>> Author: ryandesign at macports.org >>> Date: 2009-12-01 19:34:12 -0800 (Tue, 01 Dec 2009) >>> Log Message: >>> ----------- >>> muniversal-1.0.tcl: compare contents of compressed files, not the compressed files themselves; see #22650 >> >> I think you may have broken muniversal with this change. See attached log for installing tiff. >> >> > >> :debug:destroot Backtrace: /opt/local/lib/libtiff.la differs in /opt/local/var/macports/build/_Users_jeremy_src_macports-trunk_dports_graphics_tiff/work/destroot-i386 and /opt/local/var/macports/build/_Users_jeremy_src_macports-trunk_dports_graphics_tiff/work/destroot-x86_64 and cannot be merged > > That wasn't because of r61108, but because of r61090. And that revision wouldn't have broken tiff or any other port; that revision merely causes MacPorts to notify you that tiff +universal is already broken. Before, you would've gotten a broken .la file without knowing it. muniversal tries to merge files using C/C++ preprocessor directives, which are not appropriate for .la files or .pc files or -config scripts. muniversal previous assumed those types of files would never differ. Sometimes they do. So r61090 now actively prevents those files from being merged. See #21953 for the long list of related confusing issues that had previously been caused by not having this in place. > > This change will probably reveal many ports that have been broken all along. For example a ticket was filed for pango +quartz +universal. I don't know how to fix it but now we at least prevent users from installing software that they think is working properly when it really isn't. > > In the case of tiff, though, it installs fine for me. So I would be interested for you to show me how libtiff.la differs between your two destroots. Could you send me those two libtiff.la files, or run a diff -ru between your two destroots and see how they (and perhaps other files) differ? One common reason why such files might differ is if one of the dependencies (jpeg, zlib) wasn't built universal. If that's the reason here, we could add archcheck to tiff to prevent it in the future. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5820 bytes Desc: not available URL: From ryandesign at macports.org Thu Dec 10 14:33:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 10 Dec 2009 16:33:49 -0600 Subject: [61413] users/ged/sysutils/cfengine3 In-Reply-To: <20091210221306.3AE91384AE32@beta.macosforge.org> References: <20091210221306.3AE91384AE32@beta.macosforge.org> Message-ID: On Dec 10, 2009, at 16:13, ged at macports.org wrote: > Revision: 61413 > http://trac.macports.org/changeset/61413 > Author: ged at macports.org > Date: 2009-12-10 14:13:05 -0800 (Thu, 10 Dec 2009) > Log Message: > ----------- > Initial work on the cfengine3 port What does that work entail? Your commit message should say what you changed, and (if what you changed is unusual) why. > +version 3.0.2 > +revision 1 Don't change it now, but for future reference, note that the first revision of any given version of a port should be 0, not 1. > +maintainers FaerieMUD.org:ged You should probably use your MacPorts handle here ("maintainers ged"). From jeremyhu at macports.org Thu Dec 10 14:44:56 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Thu, 10 Dec 2009 14:44:56 -0800 Subject: [61108] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: <41D46A86-7AB9-41E2-9D07-89C0CF919DC1@macports.org> References: <20091202033414.DDDEF3744247@beta.macosforge.org> <41D46A86-7AB9-41E2-9D07-89C0CF919DC1@macports.org> Message-ID: Why don't we just stop shipping .la files? They don't actually do ANYTHING useful. On Dec 10, 2009, at 12:19, Ryan Schmidt wrote: > Jeremy, allow me to bring this to the macports-dev list... > > On Dec 10, 2009, at 13:23, Jeremy Huddleston wrote: > >> On Dec 1, 2009, at 19:34, ryandesign at macports.org wrote: >> >>> Revision: 61108 >>> http://trac.macports.org/changeset/61108 >>> Author: ryandesign at macports.org >>> Date: 2009-12-01 19:34:12 -0800 (Tue, 01 Dec 2009) >>> Log Message: >>> ----------- >>> muniversal-1.0.tcl: compare contents of compressed files, not the compressed files themselves; see #22650 >> >> I think you may have broken muniversal with this change. See attached log for installing tiff. >> >> > >> :debug:destroot Backtrace: /opt/local/lib/libtiff.la differs in /opt/local/var/macports/build/_Users_jeremy_src_macports-trunk_dports_graphics_tiff/work/destroot-i386 and /opt/local/var/macports/build/_Users_jeremy_src_macports-trunk_dports_graphics_tiff/work/destroot-x86_64 and cannot be merged > > That wasn't because of r61108, but because of r61090. And that revision wouldn't have broken tiff or any other port; that revision merely causes MacPorts to notify you that tiff +universal is already broken. Before, you would've gotten a broken .la file without knowing it. muniversal tries to merge files using C/C++ preprocessor directives, which are not appropriate for .la files or .pc files or -config scripts. muniversal previous assumed those types of files would never differ. Sometimes they do. So r61090 now actively prevents those files from being merged. See #21953 for the long list of related confusing issues that had previously been caused by not having this in place. > > This change will probably reveal many ports that have been broken all along. For example a ticket was filed for pango +quartz +universal. I don't know how to fix it but now we at least prevent users from installing software that they think is working properly when it really isn't. > > In the case of tiff, though, it installs fine for me. So I would be interested for you to show me how libtiff.la differs between your two destroots. Could you send me those two libtiff.la files, or run a diff -ru between your two destroots and see how they (and perhaps other files) differ? One common reason why such files might differ is if one of the dependencies (jpeg, zlib) wasn't built universal. If that's the reason here, we could add archcheck to tiff to prevent it in the future. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5820 bytes Desc: not available URL: From ryandesign at macports.org Thu Dec 10 14:49:06 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 10 Dec 2009 16:49:06 -0600 Subject: [61108] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: <361D79AA-E00E-481E-96EA-DAF556A9D2C4@macports.org> References: <20091202033414.DDDEF3744247@beta.macosforge.org> <41D46A86-7AB9-41E2-9D07-89C0CF919DC1@macports.org> <361D79AA-E00E-481E-96EA-DAF556A9D2C4@macports.org> Message-ID: <6232BFD3-A146-4A7D-B98B-681D1BEE1FA5@macports.org> On Dec 10, 2009, at 16:30, Jeremy Huddleston wrote: > Ah... it's a difference in -ljbig : > > /usr/bin/file /opt/local/lib/libjbig.dylib > /opt/local/lib/libjbig.dylib: Mach-O 64-bit dynamically linked shared library x86_64 > > Looks like jbigkit lies about being universal... Ok, looks like we have a bug report for that already, with maybe a fix: http://trac.macports.org/ticket/21476 > --- libtiff.la.i386 2009-12-10 14:25:50.000000000 -0800 > +++ libtiff.la.x86_64 2009-12-10 14:26:02.000000000 -0800 > @@ -17,7 +17,7 @@ old_library='libtiff.a' > inherited_linker_flags=' ' > > # Libraries that this one depends upon. > -dependency_libs=' -L/opt/local/lib /opt/local/lib/libjpeg.la -lz -lc' > +dependency_libs=' -L/opt/local/lib -ljbig /opt/local/lib/libjpeg.la -lz -lc' > > # Names of additional weak libraries provided by this library > weak_library_names='' > > So the other problem is that tiff uses jbigkit without declaring a dependency, for which we also now have a bug report: http://trac.macports.org/ticket/22841 From ryandesign at macports.org Thu Dec 10 14:49:26 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 10 Dec 2009 16:49:26 -0600 Subject: [61108] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: References: <20091202033414.DDDEF3744247@beta.macosforge.org> <41D46A86-7AB9-41E2-9D07-89C0CF919DC1@macports.org> Message-ID: <329EA366-A56F-4254-9D14-7EB671898E89@macports.org> On Dec 10, 2009, at 16:44, Jeremy Huddleston wrote: > Why don't we just stop shipping .la files? They don't actually do ANYTHING useful. Citation needed? :) From ryandesign at macports.org Thu Dec 10 15:03:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 10 Dec 2009 17:03:24 -0600 Subject: [61108] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl In-Reply-To: <6232BFD3-A146-4A7D-B98B-681D1BEE1FA5@macports.org> References: <20091202033414.DDDEF3744247@beta.macosforge.org> <41D46A86-7AB9-41E2-9D07-89C0CF919DC1@macports.org> <361D79AA-E00E-481E-96EA-DAF556A9D2C4@macports.org> <6232BFD3-A146-4A7D-B98B-681D1BEE1FA5@macports.org> Message-ID: <0E5F3E08-9CCA-4622-AC7A-0B99722BD4C3@macports.org> On Dec 10, 2009, at 16:49, Ryan Schmidt wrote: > the other problem is that tiff uses jbigkit without declaring a dependency fixed: http://trac.macports.org/ticket/22841 From dports at ambulatoryclam.net Thu Dec 10 15:39:58 2009 From: dports at ambulatoryclam.net (Dan Ports) Date: Thu, 10 Dec 2009 15:39:58 -0800 Subject: emacs breakage on 10.6 In-Reply-To: <60E54254-093C-45FA-8084-CD7297A0D8F2@mac.com> References: <20091202035304.GB30227@ambulatoryclam.net> <60E54254-093C-45FA-8084-CD7297A0D8F2@mac.com> Message-ID: <20091210233958.GA69145@ambulatoryclam.net> On Wed, Dec 09, 2009 at 07:56:39AM -0500, cssdev at mac.com wrote: > But how much do those ports actually depend on that specific emacs build? Shouldn't other ports be able to use either emacs or emacs-app-devel? The emacs-app-devel port will load lisp files from ${prefix}. I think in most (all?) cases the dependency is only that the portfiles happen to list dependencies on port:emacs rather than some sort of actual dependency. Should we have a metaport to act as a dependency for "any version of emacs"? Currently there's at least emacs, emacs-app, and emacs-app-devel; I could also see a need for an emacs-devel or perhaps separate ports for 22 and 23. It would also be nice if eventually we could have installed lisp packages byte-compiled for all installed emacs versions, like Debian's emacsen does, but that sounds like a much more involved project. Dan -- Dan R. K. Ports Research Henchman Massachusetts Institute of Technology Computer Science and Artificial Intelligence Lab From ryandesign at macports.org Thu Dec 10 16:25:18 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 10 Dec 2009 18:25:18 -0600 Subject: emacs breakage on 10.6 In-Reply-To: <20091210233958.GA69145@ambulatoryclam.net> References: <20091202035304.GB30227@ambulatoryclam.net> <60E54254-093C-45FA-8084-CD7297A0D8F2@mac.com> <20091210233958.GA69145@ambulatoryclam.net> Message-ID: <5ACD1499-D262-4627-ABD5-2D5E49A62028@macports.org> On Dec 10, 2009, at 17:39, Dan Ports wrote: > On Wed, Dec 09, 2009 at 07:56:39AM -0500, Chris Scharver wrote: > >> But how much do those ports actually depend on that specific emacs build? Shouldn't other ports be able to use either emacs or emacs-app-devel? The emacs-app-devel port will load lisp files from ${prefix}. > > I think in most (all?) cases the dependency is only that the portfiles > happen to list dependencies on port:emacs rather than some sort of > actual dependency. > > Should we have a metaport to act as a dependency for "any version of > emacs"? Currently there's at least emacs, emacs-app, and > emacs-app-devel; I could also see a need for an emacs-devel or perhaps > separate ports for 22 and 23. You don't need a metaport, assuming all of these emacs ports install a common file (perhaps ${prefix}/bin/emacs?). Simply rewrite the dependency "path:bin/emacs:emacs". From dports at ambulatoryclam.net Thu Dec 10 17:01:31 2009 From: dports at ambulatoryclam.net (Dan Ports) Date: Thu, 10 Dec 2009 17:01:31 -0800 Subject: emacs breakage on 10.6 In-Reply-To: <5ACD1499-D262-4627-ABD5-2D5E49A62028@macports.org> References: <20091202035304.GB30227@ambulatoryclam.net> <60E54254-093C-45FA-8084-CD7297A0D8F2@mac.com> <20091210233958.GA69145@ambulatoryclam.net> <5ACD1499-D262-4627-ABD5-2D5E49A62028@macports.org> Message-ID: <20091211010131.GA5122@ambulatoryclam.net> On Thu, Dec 10, 2009 at 06:25:18PM -0600, Ryan Schmidt wrote: > You don't need a metaport, assuming all of these emacs ports install a common file (perhaps ${prefix}/bin/emacs?). Simply rewrite the dependency "path:bin/emacs:emacs". They don't -- that's the problem. The emacs-app ports install themselves entirely into /Applications/MacPorts/Emacs.app. Dan -- Dan R. K. Ports Research Henchman Massachusetts Institute of Technology Computer Science and Artificial Intelligence Lab From ryandesign at macports.org Thu Dec 10 17:08:22 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 10 Dec 2009 19:08:22 -0600 Subject: [61413] users/ged/sysutils/cfengine3 In-Reply-To: <4B2199A5.8060903@FaerieMUD.org> References: <20091210221306.3AE91384AE32@beta.macosforge.org> <4B2199A5.8060903@FaerieMUD.org> Message-ID: <55566162-4C98-40DA-8BE3-1A91601315AA@macports.org> On Dec 10, 2009, at 19:00, Michael Granger wrote: > On 12/10/2009 02:33 PM, Ryan Schmidt wrote: > >> On Dec 10, 2009, at 16:13, ged at macports.org wrote: >> >>> Revision: 61413 >>> http://trac.macports.org/changeset/61413 >>> Author: ged at macports.org >>> Date: 2009-12-10 14:13:05 -0800 (Thu, 10 Dec 2009) >>> Log Message: >>> ----------- >>> Initial work on the cfengine3 port >> >> What does that work entail? Your commit message should say what you >> changed, and (if what you changed is unusual) why. > > What level of detail are you looking for? For instance, this commit was > for the initial revision of a Portfile for CFengine3 using the > 'cfengine' one as an example (which I indicated in the log for the copy > operation), so what additional details would you have expected? Is it > expected that commits to a users/ directory (which I was given to > believe was for experimental development) should have the same level of > detail as commits to a public port? I've seen commits with terse > messages like 'improve comments', 'rename variables', etc. especially in > the users/ directory, so I thought I was following the examples of my > peers fairly closely. I try not to duplicate information that the > version-control system already provides in a commit message, but I'm > happy to comply with whatever convention is expected. Sorry, I hadn't had my coffee yet. I neither saw that this was in your users directory, nor that this was copied from another port and then updated. Please disregard. From ryandesign at macports.org Thu Dec 10 17:15:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 10 Dec 2009 19:15:05 -0600 Subject: emacs breakage on 10.6 In-Reply-To: References: <20091202035304.GB30227@ambulatoryclam.net> <60E54254-093C-45FA-8084-CD7297A0D8F2@mac.com> <20091210233958.GA69145@ambulatoryclam.net> <5ACD1499-D262-4627-ABD5-2D5E49A62028@macports.org> <20091211010131.GA5122@ambulatoryclam.net> Message-ID: On Dec 10, 2009, at 19:02, Jeremy Lavergne wrote: >>> You don't need a metaport, assuming all of these emacs ports install a common file (perhaps ${prefix}/bin/emacs?). Simply rewrite the dependency "path:bin/emacs:emacs". >> >> They don't -- that's the problem. The emacs-app ports install >> themselves entirely into /Applications/MacPorts/Emacs.app. Then how would a port that wanted to depend on emacs know where emacs is, if the different ports don't put them in the same place? > Looks like it's time to add another hierarchy test to Macports. > appdir:Emacs.app:emacs No need: use "path:${applications_dir}/Emacs.app:emacs-app". From ernest.prabhakar at gmail.com Thu Dec 10 23:06:36 2009 From: ernest.prabhakar at gmail.com (Ernest Prabhakar) Date: Thu, 10 Dec 2009 23:06:36 -0800 Subject: =?iso-8859-1?Q?Introducing_Metalink_=AB_hueniverse?= Message-ID: Interesting new RFC - think MacPorts might be able to use it to help manage mirror sites? -- Ernie P. http://hueniverse.com/2009/12/introducing-metalink/ Metalinks are frequently used for large files or files stored on many mirrors. Because of this, many open source projects like cURL, OpenOffice.org, openSUSE, Fedora, Ubuntu, & others use them to turn their mirrors into a coordinated Content Distribution Network. About 50 applications support Metalinks. Package update programs like Appupdater and yum use them behind the scenes. File hosting services are starting to provide Metalinks for downloads, and search engines are starting to index them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dports at ambulatoryclam.net Fri Dec 11 10:50:26 2009 From: dports at ambulatoryclam.net (Dan Ports) Date: Fri, 11 Dec 2009 10:50:26 -0800 Subject: emacs breakage on 10.6 In-Reply-To: References: <20091202035304.GB30227@ambulatoryclam.net> <60E54254-093C-45FA-8084-CD7297A0D8F2@mac.com> <20091210233958.GA69145@ambulatoryclam.net> <5ACD1499-D262-4627-ABD5-2D5E49A62028@macports.org> <20091211010131.GA5122@ambulatoryclam.net> Message-ID: <20091211185026.GB5122@ambulatoryclam.net> On Thu, Dec 10, 2009 at 07:15:05PM -0600, Ryan Schmidt wrote: > Then how would a port that wanted to depend on emacs know where emacs is, if the different ports don't put them in the same place? I was thinking that emacs packages could safely install them into ${prefix}/share/emacs/site-lisp potentially even if emacs wasn't installed, as emacs-app checks there too. But after taking a closer look at some of the ports in question, this isn't a great idea -- many of them (though not all) byte-compile the lisp source, meaning they do depend on (and need to find) an emacs executable. This digression aside, may I repeat my original request that someone commit the patch in #22364 so that emacs builds on Snow Leopard? Thanks. Dan -- Dan R. K. Ports Research Henchman Massachusetts Institute of Technology Computer Science and Artificial Intelligence Lab From raimue at macports.org Fri Dec 11 13:33:09 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 11 Dec 2009 22:33:09 +0100 Subject: Can't access configure.env in portfile In-Reply-To: <947340C9-EDDB-4279-9CCE-8FF09D761EE1@macports.org> References: <947340C9-EDDB-4279-9CCE-8FF09D761EE1@macports.org> Message-ID: <4B22BA95.1010102@macports.org> Sorry for the late reply, I did not have quite the time over the last weeks to follow posts to the list. On 2009-11-29 15:33 , Ryan Schmidt wrote: > See, both before and after the configure phase, configure.env only > contains the "FOO=bar" variable I added. But what I actually want to > know about are the CFLAGS, CPPFLAGS, CXXFLAGS, etc. that MacPorts > sets automatically. Yes, I know we have separate variables > ${configure.cflags}, ${configure.cppflags}, ${configure.cxxflags}, > etc. for most (all?) of those, but I'd rather not have to enumerate > over them myself since to my mind MacPorts should have already done > so for me somewhere. configure.env are only additional variables which will be merged into the environment for the configure phase. If you want to get better results for debugging use: configure.cmd /usr/bin/env HTH, Rainer From ryandesign at macports.org Fri Dec 11 14:12:30 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 11 Dec 2009 16:12:30 -0600 Subject: Can't access configure.env in portfile In-Reply-To: <4B22BA95.1010102@macports.org> References: <947340C9-EDDB-4279-9CCE-8FF09D761EE1@macports.org> <4B22BA95.1010102@macports.org> Message-ID: On Dec 11, 2009, at 15:33, Rainer M?ller wrote: > On 2009-11-29 15:33 , Ryan Schmidt wrote: > >> See, both before and after the configure phase, configure.env only >> contains the "FOO=bar" variable I added. But what I actually want to >> know about are the CFLAGS, CPPFLAGS, CXXFLAGS, etc. that MacPorts >> sets automatically. Yes, I know we have separate variables >> ${configure.cflags}, ${configure.cppflags}, ${configure.cxxflags}, >> etc. for most (all?) of those, but I'd rather not have to enumerate >> over them myself since to my mind MacPorts should have already done >> so for me somewhere. > > configure.env are only additional variables which will be merged into > the environment for the configure phase. Yes, but if you set (rather than append to) configure.env in a portfile, you overwrite the default environment. Therefore it was unexpected to me not to be able to see the default environment in configure.env when querying it. No matter; I've found another way. > If you want to get better results for debugging use: > configure.cmd /usr/bin/env My reasons for asking were not for debugging but for a reworking of the php5extension portgroup. I've found out what I was doing wrong though and will be able to commit my update soon. From jmr at macports.org Fri Dec 11 14:36:44 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 12 Dec 2009 09:36:44 +1100 Subject: Can't access configure.env in portfile In-Reply-To: References: <947340C9-EDDB-4279-9CCE-8FF09D761EE1@macports.org> <4B22BA95.1010102@macports.org> Message-ID: <4B22C97C.8030108@macports.org> On 2009-12-12 09:12 , Ryan Schmidt wrote: > > On Dec 11, 2009, at 15:33, Rainer M?ller wrote: > >> configure.env are only additional variables which will be merged into >> the environment for the configure phase. > > Yes, but if you set (rather than append to) configure.env in a portfile, you overwrite the default environment. Can't say I've ever encountered this. Steps to reproduce? - Josh From raimue at macports.org Fri Dec 11 15:03:01 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 12 Dec 2009 00:03:01 +0100 Subject: Can't access configure.env in portfile In-Reply-To: References: <947340C9-EDDB-4279-9CCE-8FF09D761EE1@macports.org> <4B22BA95.1010102@macports.org> Message-ID: <4B22CFA5.7020005@macports.org> On 2009-12-11 23:12 , Ryan Schmidt wrote: > Yes, but if you set (rather than append to) configure.env in a > portfile, you overwrite the default environment. Therefore it was > unexpected to me not to be able to see the default environment in > configure.env when querying it. No matter; I've found another way. Options like configure.cflags take precedence over a construct like "configure.env CFLAGS=" and therefore you cannot overwrite the defaults in this way. Note that configure.env is empty by default. Rainer From ryandesign at macports.org Fri Dec 11 16:04:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 11 Dec 2009 18:04:29 -0600 Subject: [61461] trunk/dports/devel In-Reply-To: <20091211232705.D1F5A386A5BF@beta.macosforge.org> References: <20091211232705.D1F5A386A5BF@beta.macosforge.org> Message-ID: <1C82050C-74FD-4B18-901E-7235F592AF29@macports.org> On Dec 11, 2009, at 17:27, tommyd at macports.org wrote: > Revision: 61461 > http://trac.macports.org/changeset/61461 > Author: tommyd at macports.org > Date: 2009-12-11 15:27:01 -0800 (Fri, 11 Dec 2009) > Log Message: > ----------- > * new port: osc, the python-based cli client for the openSUSE build system > > Added Paths: > ----------- > trunk/dports/devel/osc/ > trunk/dports/devel/osc/Portfile > +post-destroot { > + ln -s ${prefix}/bin/osc-wrapper.py ${prefix}/bin/osc > +} Oops -- this symlink should be created inside the destroot. From tommyd at macports.org Fri Dec 11 16:21:12 2009 From: tommyd at macports.org (Thomas Keller) Date: Sat, 12 Dec 2009 01:21:12 +0100 Subject: py25-m2crypto / openssl / root certs and CAs on OSX Message-ID: <4B22E1F8.7040704@macports.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I'm currently trying to get a python-based cli client running which bases its ssl implementation on py25-m2crypto. The latter package has a load_verify_locations() method in SSL/Context.py which takes either a single pem / root cert or a directory of certs. The aforementioned cli client now tries to guess these verify locations by checking for the existence of either /etc/ssl/certs or /etc/pki/tls/cert.pem, which of course both do not exist on OSX. What I've found out on the whole root cert topic (I'm pretty new to this) is that OSX stores the root certs in proprietary binary keychain file(s) under /System/Library/Keychains, which py25-m2crypto can't handle. So the question arises how py25-m2crypto could either be made to accept this keychain format or how this has been handled for other ports / parts in MacPorts. (I guess internally py25-m2crypto also only uses openssl somehow and I hope there is already a solution for this.) Patching the load_verify_locations() step out of the cli clients code will work temporarily, until of course I get an openssl prompt which asks me if I want to accept the (for openssl) unknown, but valid remote site certificate for which it misses a root cert... Any hints? Thanks in advance, Thomas. - -- GPG-Key 0x160D1092 | tommyd3mdi at jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksi4fgACgkQaf7NlBYNEJLl+QCdGItmij0LQnMgHy/XTqh4ToRS c28AniDdz+Dq12IRd5As/8e9FlGR94T/ =cXqj -----END PGP SIGNATURE----- From jeremy at lavergne.gotdns.org Fri Dec 11 16:29:11 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 11 Dec 2009 19:29:11 -0500 Subject: py25-m2crypto / openssl / root certs and CAs on OSX In-Reply-To: <4B22E1F8.7040704@macports.org> References: <4B22E1F8.7040704@macports.org> Message-ID: <725CE253-2CB3-4F2F-A6B3-11E4D27CBA80@lavergne.gotdns.org> Load port:curl-ca-certificates the cert will be in ${prefix}/share/curl/curl-ca-bundle.crt On Dec 11, 2009, at 7:21 PM, Thomas Keller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hi! > > I'm currently trying to get a python-based cli client running which > bases its ssl implementation on py25-m2crypto. > > The latter package has a load_verify_locations() method in > SSL/Context.py which takes either a single pem / root cert or a > directory of certs. The aforementioned cli client now tries to guess > these verify locations by checking for the existence of either > /etc/ssl/certs or /etc/pki/tls/cert.pem, which of course both do not > exist on OSX. > > What I've found out on the whole root cert topic (I'm pretty new to > this) is that OSX stores the root certs in proprietary binary keychain > file(s) under /System/Library/Keychains, which py25-m2crypto can't > handle. So the question arises how py25-m2crypto could either be made to > accept this keychain format or how this has been handled for other ports > / parts in MacPorts. (I guess internally py25-m2crypto also only uses > openssl somehow and I hope there is already a solution for this.) > > Patching the load_verify_locations() step out of the cli clients code > will work temporarily, until of course I get an openssl prompt which > asks me if I want to accept the (for openssl) unknown, but valid remote > site certificate for which it misses a root cert... > > Any hints? > > Thanks in advance, > Thomas. > > - -- > GPG-Key 0x160D1092 | tommyd3mdi at jabber.ccc.de | http://thomaskeller.biz > Please note that according to the EU law on data retention, information > on every electronic information exchange might be retained for a period > of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAksi4fgACgkQaf7NlBYNEJLl+QCdGItmij0LQnMgHy/XTqh4ToRS > c28AniDdz+Dq12IRd5As/8e9FlGR94T/ > =cXqj > -----END PGP SIGNATURE----- > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From tommyd at macports.org Fri Dec 11 16:43:30 2009 From: tommyd at macports.org (Thomas Keller) Date: Sat, 12 Dec 2009 01:43:30 +0100 Subject: py25-m2crypto / openssl / root certs and CAs on OSX In-Reply-To: <725CE253-2CB3-4F2F-A6B3-11E4D27CBA80@lavergne.gotdns.org> References: <4B22E1F8.7040704@macports.org> <725CE253-2CB3-4F2F-A6B3-11E4D27CBA80@lavergne.gotdns.org> Message-ID: <4B22E732.8090203@macports.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 12.12.09 01:29, schrieb Jeremy Lavergne: > Load port:curl-ca-certificates > > the cert will be in ${prefix}/share/curl/curl-ca-bundle.crt Thanks for the hint! The port is called curl-ca-bundle, though, and unfortunately the checksums do not match: - ---> Checksumming certdata-1.56.txt Error: Checksum (md5) mismatch for certdata-1.56.txt Portfile checksum: certdata-1.56.txt md5 a5ad23bcd673dbce043b6a186125b678 Distfile checksum: certdata-1.56.txt md5 85e459aa8dcdddda6438216b67c6b7bb Error: Checksum (sha1) mismatch for certdata-1.56.txt Portfile checksum: certdata-1.56.txt sha1 59b7c651a8de466998a230e7f8afc6bd71d1e9b6 Distfile checksum: certdata-1.56.txt sha1 678d65dd3c1d1243d58668377ca945b17f33fba0 Error: Checksum (rmd160) mismatch for certdata-1.56.txt Portfile checksum: certdata-1.56.txt rmd160 72cb87687f74c05efd5ce7bb09b29561a272a1e6 Distfile checksum: certdata-1.56.txt rmd160 0a935823e5c5f533f987daaec9a845fcce31f186 Ryan, since you're maintaining the port, do you want to have a look at this? Thanks, Thomas. - -- GPG-Key 0x160D1092 | tommyd3mdi at jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksi5zEACgkQaf7NlBYNEJJNVQCg7lMANACjrKv+qEmXsvUzm3Be o7AAn19eLBDcXB0nYIwtfKqUtP3TSzgo =vylI -----END PGP SIGNATURE----- From tommyd at macports.org Fri Dec 11 16:48:13 2009 From: tommyd at macports.org (Thomas Keller) Date: Sat, 12 Dec 2009 01:48:13 +0100 Subject: py25-m2crypto / openssl / root certs and CAs on OSX In-Reply-To: <4B22E732.8090203@macports.org> References: <4B22E1F8.7040704@macports.org> <725CE253-2CB3-4F2F-A6B3-11E4D27CBA80@lavergne.gotdns.org> <4B22E732.8090203@macports.org> Message-ID: <4B22E84D.7090600@macports.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 12.12.09 01:43, schrieb Thomas Keller: > Am 12.12.09 01:29, schrieb Jeremy Lavergne: >> Load port:curl-ca-certificates > >> the cert will be in ${prefix}/share/curl/curl-ca-bundle.crt > > Thanks for the hint! The port is called curl-ca-bundle, though, and > unfortunately the checksums do not match: Nevermind, I saw you made this already on Dec 5th - I'm on an old tree apparently. Sorry again, Thomas. - -- GPG-Key 0x160D1092 | tommyd3mdi at jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksi6E0ACgkQaf7NlBYNEJLEZgCdG9nID6LhDLXDYDBWFSaYyep7 3pYAoPaRip6tIvXJCc5MyMC3lqlPDP3d =p5AO -----END PGP SIGNATURE----- From jeremyhu at macports.org Fri Dec 11 17:42:30 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Fri, 11 Dec 2009 17:42:30 -0800 Subject: [61254] trunk/dports/lang/ruby19/Portfile In-Reply-To: <20091207065157.0ADB337CDB63@beta.macosforge.org> References: <20091207065157.0ADB337CDB63@beta.macosforge.org> Message-ID: <53A37096-FBDC-4836-83DB-9DD2A193701C@macports.org> It's no longer build +universal here: /usr/bin/gcc-4.2 -ggdb3 -arch x86_64 -arch i386 -O2 -g -Wall -Wno-parentheses -fno-common -pipe -fno-common -L. -L/opt/local/lib -arch x86_64 -arch i386 -L/usr/local/lib main.o -lruby1.9 -lpthread -ldl -lobjc -o ruby1.9 ld: warning: in ./libruby1.9.dylib, file is not of required architecture Undefined symbols for architecture i386: "_ruby_options", referenced from: _main in main.o "_ruby_sysinit", referenced from: _main in main.o "_ruby_init_stack", referenced from: _main in main.o "_ruby_run_node", referenced from: _main in main.o "_ruby_init", referenced from: _main in main.o ld: symbol(s) not found for architecture i386 And looking through the build log, sure enough the arch flags were dropped: :info:build cc -dynamiclib -undefined suppress -flat_namespace -install_name /opt/local/lib/libruby1.9.dylib -current_version 1.9.1 -compatibility_version 1.9.1 dln. o encoding.o array.o bignum.o class.o compar.o complex.o dir.o enum.o enumerator.o error.o eval.o load.o proc.o file.o gc.o hash.o inits.o io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o random.o range.o rational.o re.o regcomp.o regenc.o regerror.o regexec.o regparse.o regsyntax.o ruby.o safe.o signal.o sprintf.o st.o strftime.o string.o struct.o time.o transcode.o util.o variable.o version.o compile.o debug.o iseq.o vm.o vm_dump.o thread.o cont.o ascii.o us_ascii.o unicode.o utf_8.o newline.o prelude.o dmyext.o -o libruby1.9.1.9.1.dylib On Dec 6, 2009, at 22:51, brett at macports.org wrote: > Revision: 61254 > http://trac.macports.org/changeset/61254 > Author: brett at macports.org > Date: 2009-12-06 22:51:56 -0800 (Sun, 06 Dec 2009) > Log Message: > ----------- > update ruby19 to p376 > > Modified Paths: > -------------- > trunk/dports/lang/ruby19/Portfile > > Modified: trunk/dports/lang/ruby19/Portfile > =================================================================== > --- trunk/dports/lang/ruby19/Portfile 2009-12-07 03:37:52 UTC (rev 61253) > +++ trunk/dports/lang/ruby19/Portfile 2009-12-07 06:51:56 UTC (rev 61254) > @@ -2,60 +2,60 @@ > > PortSystem 1.0 > > -name ruby19 > -version 1.9.1-p243 > +name ruby19 > +version 1.9.1-p376 > > -categories lang ruby > -maintainers febeling openmaintainer > -platforms darwin > -description Powerful and clean object-oriented scripting language > +categories lang ruby > +maintainers febeling openmaintainer > +platforms darwin > +description Powerful and clean object-oriented scripting language > long_description Ruby is the interpreted scripting language for quick \ > - and easy object-oriented programming. It has many \ > - features to process text files and to do system \ > - management tasks (as in Perl). It is simple, \ > - straight-forward, extensible, and portable. \ > - Version 1.9 contains a new VM called YARV, is faster \ > - and slightly incompatible from version 1.8. > + and easy object-oriented programming. It has many \ > + features to process text files and to do system \ > + management tasks (as in Perl). It is simple, \ > + straight-forward, extensible, and portable. \ > + Version 1.9 contains a new VM called YARV, is faster \ > + and slightly incompatible from version 1.8. > > -homepage http://www.ruby-lang.org/ > +homepage http://www.ruby-lang.org/ > > master_sites ruby:1.9 > use_bzip2 yes > distname ruby-${version} > > -checksums md5 66d4f8403d13623051091347764881a0 > +checksums md5 e019ae9c643c5efe91be49e29781fb94 > use_parallel_build yes > > -depends_lib port:libiconv \ > - port:readline \ > - port:openssl \ > - port:zlib \ > - port:ncurses > +depends_lib port:libiconv \ > + port:readline \ > + port:openssl \ > + port:zlib \ > + port:ncurses > > configure.args --enable-shared \ > - --mandir="${prefix}/share/man" \ > - --enable-pthread \ > - --without-tk \ > - --program-suffix=1.9 > + --mandir="${prefix}/share/man" \ > + --enable-pthread \ > + --without-tk \ > + --program-suffix=1.9 > > # Ignore minor version for archdir, like i686-darwin9. > # Port "ruby" does the same. > -configure.env UNAME_RELEASE=${os.major} > +configure.env UNAME_RELEASE=${os.major} > > post-destroot { > - foreach type {site vendor} { > - set libdir ${destroot}${prefix}/lib/ruby1.9/${type}_ruby > - xinstall -m 0755 -d ${libdir} > - xinstall -m 0644 ${filespath}/${type}-specific.rb ${libdir} > - } > + foreach type {site vendor} { > + set libdir ${destroot}${prefix}/lib/ruby1.9/${type}_ruby > + xinstall -m 0755 -d ${libdir} > + xinstall -m 0644 ${filespath}/${type}-specific.rb ${libdir} > + } > > - foreach subdir [exec find ${libdir} -type d -empty] { > - destroot.keepdirs-append ${subdir} > - } > + foreach subdir [exec find ${libdir} -type d -empty] { > + destroot.keepdirs-append ${subdir} > + } > } > > variant nosuffix description "Don't add the 1.9 program suffix to the executables. Note: that makes the port conflict with ruby (1.8), rb-rubygems, and rb-rake ports." { > - configure.args-delete --program-suffix=1.9 > + configure.args-delete --program-suffix=1.9 > } > > variant c_api_docs description "Generate documentation for Ruby C API" { > @@ -79,15 +79,15 @@ > } > > variant tk conflicts mactk description "Build using MacPorts Tk" { > - configure.args-delete --without-tk > - configure.args-append --with-tk > - depends_lib-append port:tcl \ > - port:tk > + configure.args-delete --without-tk > + configure.args-append --with-tk > + depends_lib-append port:tcl \ > + port:tk > } > > variant mactk conflicts tk description "Build using Mac OS X Tk Framework" { > - configure.args-delete --without-tk > - configure.args-append --enable-tcltk-framework > + configure.args-delete --without-tk > + configure.args-append --enable-tcltk-framework > } > > livecheck.type regex > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3333 bytes Desc: not available URL: From ryandesign at macports.org Sun Dec 13 04:10:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 13 Dec 2009 06:10:03 -0600 Subject: [61491] trunk/dports In-Reply-To: <20091213075425.BEF3138A13FD@beta.macosforge.org> References: <20091213075425.BEF3138A13FD@beta.macosforge.org> Message-ID: <2A4A5672-06AA-4F05-BDCA-BB2E0513ECBA@macports.org> On Dec 13, 2009, at 01:54, portindex at macports.org wrote: > Revision: 61491 > http://trac.macports.org/changeset/61491 > Author: portindex at macports.org > Date: 2009-12-12 23:54:23 -0800 (Sat, 12 Dec 2009) > Log Message: > ----------- > > Total number of ports parsed: 6436 > Ports successfully parsed: 6433 > Ports failed: 3 > > > Failed to parse file php/php5-http/Portfile: invalid command name "php5extension.extensions" > Failed to parse file php/php5-oracle/Portfile: invalid command name "php5extension.extensions" > Failed to parse file php/php5-postgresql/Portfile: invalid command name "php5extension.extensions" These ports work fine here. Is the portindex regeneration machine forgetting to update the _resources directory? From ryandesign at macports.org Sun Dec 13 04:32:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 13 Dec 2009 06:32:13 -0600 Subject: [61491] trunk/dports In-Reply-To: <2A4A5672-06AA-4F05-BDCA-BB2E0513ECBA@macports.org> References: <20091213075425.BEF3138A13FD@beta.macosforge.org> <2A4A5672-06AA-4F05-BDCA-BB2E0513ECBA@macports.org> Message-ID: <1A3B3322-1C19-4885-8E01-74191F04A659@macports.org> On Dec 13, 2009, at 06:10, Ryan Schmidt wrote: > On Dec 13, 2009, at 01:54, portindex at macports.org wrote: > >> Revision: 61491 >> http://trac.macports.org/changeset/61491 >> Author: portindex at macports.org >> Date: 2009-12-12 23:54:23 -0800 (Sat, 12 Dec 2009) >> Log Message: >> ----------- >> >> Total number of ports parsed: 6436 >> Ports successfully parsed: 6433 >> Ports failed: 3 >> >> >> Failed to parse file php/php5-http/Portfile: invalid command name "php5extension.extensions" >> Failed to parse file php/php5-oracle/Portfile: invalid command name "php5extension.extensions" >> Failed to parse file php/php5-postgresql/Portfile: invalid command name "php5extension.extensions" > > These ports work fine here. Is the portindex regeneration machine forgetting to update the _resources directory? Another possibility would be that I forget to commit the change to the portgroup. How about I do that now. :) From brooks at clarksonline.net Sun Dec 13 09:14:54 2009 From: brooks at clarksonline.net (M. Brooks Clark) Date: Sun, 13 Dec 2009 11:14:54 -0600 Subject: Please commit new portfiles for radlib and wview Message-ID: <020F1D10-3A27-45EC-8EB0-A21EF0CD614C@clarksonline.net> I have submitted new ports for radlib (http://trac.macports.org/ticket/22873) and wview(http://trac.macports.org/ticket/22875). Can someone commit the new portfiles? Thanks, Brooks http://www.clarkwx.net ________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmr at macports.org Sun Dec 13 09:28:13 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 14 Dec 2009 04:28:13 +1100 Subject: [61506] trunk/dports/www/webdot/Portfile In-Reply-To: <20091213131404.68FBA38ACCE2@beta.macosforge.org> References: <20091213131404.68FBA38ACCE2@beta.macosforge.org> Message-ID: <4B25242D.3080801@macports.org> On 2009-12-14 00:14 , ryandesign at macports.org wrote: > Revision: 61506 > http://trac.macports.org/changeset/61506 > Author: ryandesign at macports.org > Date: 2009-12-13 05:14:03 -0800 (Sun, 13 Dec 2009) > Log Message: > ----------- > webdot: fix ui_msg to match MacPorts 1.8's command line flags > > Modified Paths: > -------------- > trunk/dports/www/webdot/Portfile > > Modified: trunk/dports/www/webdot/Portfile > =================================================================== > --- trunk/dports/www/webdot/Portfile 2009-12-13 13:13:11 UTC (rev 61505) > +++ trunk/dports/www/webdot/Portfile 2009-12-13 13:14:03 UTC (rev 61506) > @@ -36,7 +36,7 @@ > } > ui_msg "${name} requires that ${graphviz_port} first be installed with the +tcl variant." > ui_msg "Rebuild ${graphviz_port} using:" > - ui_msg " sudo port -nf upgrade ${graphviz_port} +tcl" > + ui_msg " sudo port -n upgrade --force ${graphviz_port} +tcl" > return -code error "${graphviz_port} missing +tcl variant" > } > } What if tcl is not installed when the user runs this command? Wouldn't this be more appropriate? Index: Portfile =================================================================== --- Portfile (revision 61513) +++ Portfile (working copy) @@ -36,7 +36,7 @@ } ui_msg "${name} requires that ${graphviz_port} first be installed with the +tcl variant." ui_msg "Rebuild ${graphviz_port} using:" - ui_msg " sudo port -n upgrade --force ${graphviz_port} +tcl" + ui_msg " sudo port upgrade --enforce-variants ${graphviz_port} +tcl" return -code error "${graphviz_port} missing +tcl variant" } } - Josh From macsforever2000 at macports.org Sun Dec 13 11:04:24 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Sun, 13 Dec 2009 12:04:24 -0700 Subject: Please commit new portfiles for radlib and wview In-Reply-To: <020F1D10-3A27-45EC-8EB0-A21EF0CD614C@clarksonline.net> References: <020F1D10-3A27-45EC-8EB0-A21EF0CD614C@clarksonline.net> Message-ID: Hi Brooks, On Dec 13, 2009, at 10:14 AM, M. Brooks Clark wrote: > I have submitted new ports for radlib (http://trac.macports.org/ticket/22873) and wview(http://trac.macports.org/ticket/22875). Can someone commit the new portfiles? > > > Thanks, > > Brooks > > http://www.clarkwx.net I'll try to get to them today. In the meantime, it would be nice if you could use one email address so it's easy to identify you. For instance you use: - mac.com:mbrooksclark in the maintainer address of your ports. - earthlink.net:mbrooksclark in the tickets. - clarksonline.net:brooks in this email. Cheers! Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From software at macfreek.nl Sun Dec 13 11:22:06 2009 From: software at macfreek.nl (Freek Dijkstra) Date: Sun, 13 Dec 2009 20:22:06 +0100 Subject: -devel ports In-Reply-To: <71A9F1B1-BD09-4E7F-B451-AD56AD8AA47A@macports.org> References: <4B1CE97F.9070100@macfreek.nl> <4B1CF0C8.40901@macports.org> <4B1D2647.4000001@macfreek.nl> <4B1D3829.3030701@macfreek.nl> <71A9F1B1-BD09-4E7F-B451-AD56AD8AA47A@macports.org> Message-ID: <4B253EDE.6020501@macfreek.nl> [resent, I used the wrong sender address] Hi Ryan, Your ramblings are *much* appreciated. For one thing, it did took my frustration away. I had been writing the following e-mail, but some serious timing consuming got in the way (I just became dad). I was planning to use wxPython for some hobby projects, but those are now also on hold for a while. I fully agree that in this particular case, it is very odd that a stable release of wxWidgets 2.9 is out since September, while there is no release of wxPython that works for that version. I did ask on the wxPython list, but got no response yet. So it is obvious that there is no stable 64-bit wxPython. It seems to me that there are three options here: * keep the stable versions of wxWidgets and wxPython at 2.8, so that Leopard (10.5) users can enjoy both, and Snow Leopard users can't use wxPython. * update the stable version of wxWidgets to 2.9, meaning that there can not be a stable wxPython (only a SVN-based wxPython). * retain wxWidgets and wxPython at 2.8, and make a wxWidgets-devel for 2.9 and a wxPython-devel for the wxPython SVN version. I presume that the last solution is the best, even though that is slightly confusing (at least to me: to me wxWidgets 2.9 *is* stable as it is released). As an upgrade path to Snow Leopard users, I wonder if it is possible to change the wxPython to display a warning saying it will not work, with a note to use wxPython-devel. For this to work, the existing wxPython ports need to be tested. As Jyrki said, the change from carbon to cocoa might in fact be just as big a change! I planned to submit a portfile for a wxPython-devel above (I did compile wxPython with cocoa using a subversion revision), but a quick test did still indicate not all was 64-bit. I was not able to check if that is caused by wxWidget, wxPython, or some old hand-installed version -- it is at least clear that you guys are indeed much more experienced in creating portfile than I am (thanks!) Regards, Freek From jmr at macports.org Sun Dec 13 12:32:22 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 14 Dec 2009 07:32:22 +1100 Subject: -devel ports In-Reply-To: <4B253EDE.6020501@macfreek.nl> References: <4B1CE97F.9070100@macfreek.nl> <4B1CF0C8.40901@macports.org> <4B1D2647.4000001@macfreek.nl> <4B1D3829.3030701@macfreek.nl> <71A9F1B1-BD09-4E7F-B451-AD56AD8AA47A@macports.org> <4B253EDE.6020501@macfreek.nl> Message-ID: <4B254F56.6070908@macports.org> On 2009-12-14 06:22 , Freek Dijkstra wrote: > I fully agree that in this particular case, it is very odd that a stable > release of wxWidgets 2.9 is out since September, while there is no > release of wxPython that works for that version. 2.9 is not a stable release. From the wxWidgets website: Current Stable Release: 2.8.10 Development Snapshot: 2.9.0 > to me wxWidgets 2.9 *is* stable as > it is released). Are all the odd-numbered GNOME releases also stable? They are released. So are alpha and beta versions of a lot of software. So are nightly builds, for that matter. - Josh From ryandesign at macports.org Sun Dec 13 14:34:44 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 13 Dec 2009 16:34:44 -0600 Subject: [61506] trunk/dports/www/webdot/Portfile In-Reply-To: <4B25242D.3080801@macports.org> References: <20091213131404.68FBA38ACCE2@beta.macosforge.org> <4B25242D.3080801@macports.org> Message-ID: On Dec 13, 2009, at 11:28, Joshua Root wrote: > Wouldn't this be more appropriate? > - ui_msg " sudo port -n upgrade --force ${graphviz_port} +tcl" > + ui_msg " sudo port upgrade --enforce-variants > ${graphviz_port} +tcl" Thanks, I agree; changed in r61523. From ryandesign at macports.org Sun Dec 13 17:52:12 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 13 Dec 2009 19:52:12 -0600 Subject: [61530] trunk/dports/gnome/liferea/Portfile In-Reply-To: <20091214013902.995BE38B65E2@beta.macosforge.org> References: <20091214013902.995BE38B65E2@beta.macosforge.org> Message-ID: On Dec 13, 2009, at 19:39, vinc17 at macports.org wrote: > Revision: 61530 > http://trac.macports.org/changeset/61530 > Author: vinc17 at macports.org > Date: 2009-12-13 17:38:58 -0800 (Sun, 13 Dec 2009) > Log Message: > ----------- > Bump to 1.6.1. Fixed livecheck. > > Modified Paths: > -------------- > trunk/dports/gnome/liferea/Portfile > > Modified: trunk/dports/gnome/liferea/Portfile > =================================================================== > --- trunk/dports/gnome/liferea/Portfile 2009-12-14 00:54:15 UTC (rev 61529) > +++ trunk/dports/gnome/liferea/Portfile 2009-12-14 01:38:58 UTC (rev 61530) > @@ -3,8 +3,7 @@ > PortSystem 1.0 > > name liferea > -version 1.6.0 > -epoch 20090731 > +version 1.6.1 I put the epoch line back in the portfile, because the epoch line can never be removed from a portfile; the epoch can only ever increase, otherwise MacPorts will not report the port as being outdated. I put the epoch line above the version line now, to better indicate that the epoch takes precedence over the version. From ryandesign at macports.org Sun Dec 13 21:24:01 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 13 Dec 2009 23:24:01 -0600 Subject: [61539] trunk/dports/security/cyrus-sasl2/Portfile In-Reply-To: <20091214043710.992F138B7A58@beta.macosforge.org> References: <20091214043710.992F138B7A58@beta.macosforge.org> Message-ID: On Dec 13, 2009, at 22:37, jeremyhu at macports.org wrote: > Modified: trunk/dports/security/cyrus-sasl2/Portfile > =================================================================== > --- trunk/dports/security/cyrus-sasl2/Portfile 2009-12-14 03:54:27 UTC (rev 61538) > +++ trunk/dports/security/cyrus-sasl2/Portfile 2009-12-14 04:37:05 UTC (rev 61539) > @@ -1,9 +1,12 @@ > # $Id$ > > PortSystem 1.0 > +PortGroup muniversal 1.0 > +PortGroup archcheck 1.0 The only reason to use the archcheck portgroup is if you plan to check the architecture of dependencies using the archcheck.files directive. From jmr at macports.org Mon Dec 14 12:47:36 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 15 Dec 2009 07:47:36 +1100 Subject: Remaining tickets for 1.8.2 release Message-ID: <4B26A468.6020204@macports.org> The only remaining obstacles to a 1.8.2 release are these two tickets: Both may already be fixed in trunk, but someone affected by the problems described needs to confirm this. #18736 is currently in the 1.8.2 milestone as well, but as no working patch has been forthcoming we really have no choice but to kick it out into MacPorts Future. - Josh From ryandesign at macports.org Mon Dec 14 15:53:33 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 14 Dec 2009 17:53:33 -0600 Subject: [61551] trunk/dports/devel/apr-util/Portfile In-Reply-To: <20091214163214.C59E838BFB84@beta.macosforge.org> References: <20091214163214.C59E838BFB84@beta.macosforge.org> Message-ID: On Dec 14, 2009, at 10:32, dluke at macports.org wrote: > Revision: 61551 > http://trac.macports.org/changeset/61551 > Author: dluke at macports.org > Date: 2009-12-14 08:32:12 -0800 (Mon, 14 Dec 2009) > Log Message: > ----------- > Remove trailing whitespace (that lint missed). If you use "port lint --nitpick" it does catch the whitespace issues, but I agree it should have caught that line without --nitpick, since whitespace after a backslash is not a nitpick, it's a functional problem. From wsiegrist at apple.com Mon Dec 14 16:26:38 2009 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 14 Dec 2009 16:26:38 -0800 Subject: Fwd: PortIndex2MySQL run failure on Monday 2009-12-14 at 16:10:00 References: <20091215001013.DAC363A0F294@gamma.macosforge.org> Message-ID: <22D556F2-4AC7-4C17-9803-C69F8C1A2CAB@apple.com> There are now 2 box2d ports. https://trac.macports.org/changeset/60951 https://trac.macports.org/changeset/61558 -Bill Begin forwarded message: > From: macports-mgr at lists.macosforge.org > Date: December 14, 2009 4:10:13 PM PST > To: wms at macports.org > Subject: PortIndex2MySQL run failure on Monday 2009-12-14 at 16:10:00 > > > Synchronizing local ports tree from file:///rsync/macports-san/release/ports/ > Error: CHILDSTATUS 64449 1: ERROR 1062 (23000) at line 13457: Duplicate entry 'Box2D' for key 1 From vincent-opdarw at vinc17.org Tue Dec 15 04:21:02 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue, 15 Dec 2009 13:21:02 +0100 Subject: [61530] trunk/dports/gnome/liferea/Portfile In-Reply-To: References: <20091214013902.995BE38B65E2@beta.macosforge.org> Message-ID: <20091215122102.GA5160@prunille.vinc17.org> On 2009-12-13 19:52:12 -0600, Ryan Schmidt wrote: > I put the epoch line back in the portfile, because the epoch line > can never be removed from a portfile; the epoch can only ever > increase, otherwise MacPorts will not report the port as being > outdated. I put the epoch line above the version line now, to better > indicate that the epoch takes precedence over the version. OK. This is a bit strange that "port -v upgrade liferea" worked. I think it should do nothing in such a case (perhaps except if -f is given). -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Ar?naire project (LIP, ENS-Lyon) From ryandesign at macports.org Tue Dec 15 04:58:11 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 15 Dec 2009 06:58:11 -0600 Subject: PortIndex2MySQL run failure on Monday 2009-12-14 at 16:10:00 In-Reply-To: <22D556F2-4AC7-4C17-9803-C69F8C1A2CAB@apple.com> References: <20091215001013.DAC363A0F294@gamma.macosforge.org> <22D556F2-4AC7-4C17-9803-C69F8C1A2CAB@apple.com> Message-ID: <269CDC56-17F3-4720-8CC5-A24536B7A56F@macports.org> Forgive me, Anthony, but I deleted your Box2D. Ordinarily I would have sent you an email, but I didn't know if you were around, and as it stands, the PortIndex2MySQL failure means our web site only had 1/4 of our ports in its database. Your files are of course still available in the repository history if you need to access them, and if you have any improvements to make to the existing box2d port, please do so. -Ryan On Dec 14, 2009, at 18:26, William Siegrist wrote: > There are now 2 box2d ports. > > https://trac.macports.org/changeset/60951 > https://trac.macports.org/changeset/61558 > > -Bill > > > Begin forwarded message: > >> From: macports-mgr at lists.macosforge.org >> Date: December 14, 2009 4:10:13 PM PST >> To: wms at macports.org >> Subject: PortIndex2MySQL run failure on Monday 2009-12-14 at 16:10:00 >> >> >> Synchronizing local ports tree from file:///rsync/macports-san/release/ports/ >> Error: CHILDSTATUS 64449 1: ERROR 1062 (23000) at line 13457: Duplicate entry 'Box2D' for key 1 From ryandesign at macports.org Tue Dec 15 05:11:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 15 Dec 2009 07:11:42 -0600 Subject: PortIndex2MySQL.tcl should be atomic Message-ID: <7FDA0120-F0FD-4277-A2B2-42BFE31B1678@macports.org> PortIndex2MySQL.tcl seems to have some odd behavior. It seems to DROP and re-CREATE all the tables every time it runs. It has a --create-tables command line option, but it seems to recreate the tables whether or not that option is given. Partly as a consequence of that, I think, if something causes the update to fail partway through (like a duplicate port, like we just had with box2d) then the database is left in an incomplete state (for example, right now the web site claims we have 1571 ports, when of course we really have over 6400 ports. It seems to me that the tables should only be recreated when needed (i.e. only when the schema changes, which should be rare), and that the update should occur inside a transaction, so that if anything fails, the transaction is automatically rolled back and there will no longer be a way for the database to exist in an incomplete state. Is there any reason you can think of why we should not make these changes? From panayotis at panayotis.com Wed Dec 16 09:53:25 2009 From: panayotis at panayotis.com (Panayotis Katsaloulis) Date: Wed, 16 Dec 2009 19:53:25 +0200 Subject: submit a port for launch4j Message-ID: <9D75F42F-381B-4371-8A29-DACDBB32F07C@panayotis.com> I have created a new port (actually for launch4j) What should I do to send it to macports? From jeremy at lavergne.gotdns.org Wed Dec 16 09:54:07 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 16 Dec 2009 12:54:07 -0500 Subject: submit a port for launch4j In-Reply-To: <9D75F42F-381B-4371-8A29-DACDBB32F07C@panayotis.com> References: <9D75F42F-381B-4371-8A29-DACDBB32F07C@panayotis.com> Message-ID: <7FB56202-0C4A-4065-96C0-FCC5EBFA13EA@lavergne.gotdns.org> Make a submission ticket at trac.macports.org On Dec 16, 2009, at 12:53 PM, Panayotis Katsaloulis wrote: > I have created a new port (actually for launch4j) > > What should I do to send it to macports? > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From dweber at macports.org Wed Dec 16 16:10:50 2009 From: dweber at macports.org (Darren Weber) Date: Wed, 16 Dec 2009 16:10:50 -0800 Subject: /opt/local/lib/libgcc_s.1.dylib, binutils, llvm-gcc42 Message-ID: There seem to be many ports that build and install /opt/local/lib/libiberty.a One potential consequence is failure for installations or upgrades. For example, $ sudo port install llvm-gcc42 ---> Computing dependencies for llvm-gcc42 ---> Activating llvm-gcc42 @2.6_0+darwin+darwin_i386 Error: Unable to execute port: Image error: /opt/local/lib/libiberty.a is being used by the active binutils port. Please deactivate this port first, or use 'port -f activate llvm-gcc42' to force the activation. Is it possible and desirable to have a single port to control the libiberty.a and have all other ports depend on it? (This probably requires ways to switch off the build of libiberty.a in the config for various ports like binutils, gcc stuff, etc.). Take care, Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: From dports at ambulatoryclam.net Wed Dec 16 16:43:22 2009 From: dports at ambulatoryclam.net (Dan Ports) Date: Wed, 16 Dec 2009 16:43:22 -0800 Subject: /opt/local/lib/libgcc_s.1.dylib, binutils, llvm-gcc42 In-Reply-To: References: Message-ID: <20091217004322.GC28726@ambulatoryclam.net> On Wed, Dec 16, 2009 at 04:10:50PM -0800, Darren Weber wrote: > Is it possible and desirable to have a single port to control the > libiberty.a and have all other ports depend on it? (This probably requires > ways to switch off the build of libiberty.a in the config for various ports > like binutils, gcc stuff, etc.). I don't think so -- as far as I can tell, and for reasons I have never quite grasped, libiberty isn't distributed separately, or even really versioned; its source is directly included in the gcc sources. I think the right solution here is for each port to install its own version of libiberty in a separate place. It look like some ports already do this (gcc43, for one). Maybe the actual problem you're running into is that llvm-gcc doesn't do this? It's possible that it isn't even necessary to install libiberty.a in the first place. (isn't it typically linked in to gcc and friends statically?) But I'm less sure about this. Dan -- Dan R. K. Ports Research Henchman Massachusetts Institute of Technology Computer Science and Artificial Intelligence Lab From ryandesign at macports.org Wed Dec 16 19:04:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 16 Dec 2009 21:04:13 -0600 Subject: /opt/local/lib/libgcc_s.1.dylib, binutils, llvm-gcc42 In-Reply-To: <20091217004322.GC28726@ambulatoryclam.net> References: <20091217004322.GC28726@ambulatoryclam.net> Message-ID: <1FA59F8E-E0C2-410B-B54A-DF0B76A1DC90@macports.org> On Dec 16, 2009, at 18:43, Dan Ports wrote: > On Wed, Dec 16, 2009 at 04:10:50PM -0800, Darren Weber wrote: >> Is it possible and desirable to have a single port to control the >> libiberty.a and have all other ports depend on it? I don't believe it's desirable. >> (This probably requires >> ways to switch off the build of libiberty.a in the config for various ports >> like binutils, gcc stuff, etc.). > > I don't think so -- as far as I can tell, and for reasons I have never quite > grasped, libiberty isn't distributed separately, or even really > versioned; its source is directly included in the gcc sources. > > I think the right solution here is for each port to install its own > version of libiberty in a separate place. It look like some ports > already do this (gcc43, for one). Maybe the actual problem you're > running into is that llvm-gcc doesn't do this? > > It's possible that it isn't even necessary to install libiberty.a in > the first place. (isn't it typically linked in to gcc and friends > statically?) But I'm less sure about this. I filed the bug report about llvm-gcc42's /opt/local/lib/libgcc_s.1.dylib here: http://trac.macports.org/ticket/20889 Unfortunately the maintainer has not reacted to the problem. My recommendation is to not install llvm-gcc42 until this issue is resolved. If anyone can assist in resolving this issue, it would be appreciated. From ryandesign at macports.org Wed Dec 16 19:06:36 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 16 Dec 2009 21:06:36 -0600 Subject: [61602] branches/release_1_8/base In-Reply-To: <20091216200523.E33913900752@beta.macosforge.org> References: <20091216200523.E33913900752@beta.macosforge.org> Message-ID: On Dec 16, 2009, at 14:05, jmr at macports.org wrote: > Revision: 61602 > http://trac.macports.org/changeset/61602 > Author: jmr at macports.org > Date: 2009-12-16 12:05:20 -0800 (Wed, 16 Dec 2009) > Log Message: > ----------- > bump branch version to 1.8.2 I guess I should test those 1.8.2 fixes you've been bugging me about, and merge back those other changes from trunk I've been meaning to do, real soon now, huh? :) From ryandesign at macports.org Wed Dec 16 19:42:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 16 Dec 2009 21:42:42 -0600 Subject: [61596] trunk/dports/graphics/wxWidgets/Portfile In-Reply-To: <20091216192443.5A05F38FFCA8@beta.macosforge.org> References: <20091216192443.5A05F38FFCA8@beta.macosforge.org> Message-ID: On Dec 16, 2009, at 13:24, jwa at macports.org wrote: > Revision: 61596 > http://trac.macports.org/changeset/61596 > Author: jwa at macports.org > Date: 2009-12-16 11:24:42 -0800 (Wed, 16 Dec 2009) > Log Message: > ----------- > make wxWidgets build on 10.6, hopefully nothing else breaks > > Modified Paths: > -------------- > trunk/dports/graphics/wxWidgets/Portfile > > Modified: trunk/dports/graphics/wxWidgets/Portfile > =================================================================== > --- trunk/dports/graphics/wxWidgets/Portfile 2009-12-16 18:54:45 UTC (rev 61595) > +++ trunk/dports/graphics/wxWidgets/Portfile 2009-12-16 19:24:42 UTC (rev 61596) > @@ -1,6 +1,7 @@ > # $Id$ > > PortSystem 1.0 > +PortGroup archcheck 1.0 There is no reason to add the archcheck portgroup unless you use the archcheck.files directive to check the architectures of the dependencies. However... On Dec 16, 2009, at 13:24, jwa at macports.org wrote: > +universal_variant no > use_parallel_build no > > +platform darwin 10 { > + configure.build_arch i386 > +# configure.cflags "-arch i386" > + configure.cppflags "-arch i386" > +# configure.cxxflags "-arch i386" > +# configure.objcflags "-arch i386" > + configure.ldflags "-arch i386" > +} ...since you are forcing a 32-bit build, checking the architectures of the dependencies would be an excellent idea. But why are you forcing a 32-bit build only on Snow Leopard? Wouldn't it also be necessary on Leopard if the user has set build_arch to x86_64 or ppc64? Attached is a patch for wxWidgets to address these issues. Unfortunately, the only way this will really be useful for anyone on Snow Leopard is if every port that depends on wxWidgets (I count 20 ports), and every port that depends on those ports (no idea how many), and so on, also forces itself to 32-bit and checks dependencies' architectures. Not pretty. -------------- next part -------------- A non-text attachment was scrubbed... Name: wxWidgets.diff Type: application/octet-stream Size: 1160 bytes Desc: not available URL: From dports at ambulatoryclam.net Wed Dec 16 20:37:34 2009 From: dports at ambulatoryclam.net (Dan Ports) Date: Wed, 16 Dec 2009 20:37:34 -0800 Subject: /opt/local/lib/libgcc_s.1.dylib, binutils, llvm-gcc42 In-Reply-To: <1FA59F8E-E0C2-410B-B54A-DF0B76A1DC90@macports.org> References: <20091217004322.GC28726@ambulatoryclam.net> <1FA59F8E-E0C2-410B-B54A-DF0B76A1DC90@macports.org> Message-ID: <20091217043734.GD28726@ambulatoryclam.net> On Wed, Dec 16, 2009 at 09:04:13PM -0600, Ryan Schmidt wrote: > My recommendation is to not install llvm-gcc42 until this issue is resolved. If anyone can assist in resolving this issue, it would be appreciated. Isn't the solution to both of these problems (libiberty & libgcc_s) just a matter of adding --libdir=${prefix}/lib/${name} --libexecdir=${prefix}/libexec/${name} --includedir=${prefix}/include/${name} to configure.args? (I don't use llvm-gcc at all myself, but in my experience this is typically the answer to such problems with gcc.) Dan -- Dan R. K. Ports Research Henchman Massachusetts Institute of Technology Computer Science and Artificial Intelligence Lab From ryandesign at macports.org Wed Dec 16 23:12:01 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 17 Dec 2009 01:12:01 -0600 Subject: /opt/local/lib/libgcc_s.1.dylib, binutils, llvm-gcc42 In-Reply-To: <20091217043734.GD28726@ambulatoryclam.net> References: <20091217004322.GC28726@ambulatoryclam.net> <1FA59F8E-E0C2-410B-B54A-DF0B76A1DC90@macports.org> <20091217043734.GD28726@ambulatoryclam.net> Message-ID: <2EE4AE27-A981-434D-84EC-709752BC55FB@macports.org> On Dec 16, 2009, at 22:37, Dan Ports wrote: > On Wed, Dec 16, 2009 at 09:04:13PM -0600, Ryan Schmidt wrote: >> My recommendation is to not install llvm-gcc42 until this issue is resolved. If anyone can assist in resolving this issue, it would be appreciated. > > Isn't the solution to both of these problems (libiberty & libgcc_s) just a > matter of adding > --libdir=${prefix}/lib/${name} > --libexecdir=${prefix}/libexec/${name} > --includedir=${prefix}/include/${name} > to configure.args? > > (I don't use llvm-gcc at all myself, but in my experience this is > typically the answer to such problems with gcc.) It's possible that's all that's needed. I haven't tried it. What we need is for someone to try it and attach to the ticket a patch that works. I would say that ports that use llvm-gcc42 should also be tested to ensure they still work with this change, but fortunately there aren't any such ports. From brad at pixilla.com Thu Dec 17 00:20:46 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 17 Dec 2009 00:20:46 -0800 Subject: macports dovecot sieve In-Reply-To: <28CF2767-550B-4341-86DC-70FAD0EE51ED@macports.org> References: <28CF2767-550B-4341-86DC-70FAD0EE51ED@macports.org> Message-ID: <979AABCE-1338-455B-9669-935BD58ABB4D@pixilla.com> On Dec 16, 2009, at 11:59 PM, Ryan Schmidt wrote: > > On Dec 17, 2009, at 01:26, Bradley Giesbrecht wrote: > >> I'm building the dovecot-1.2-sieve plugin and am doing a portfile >> while I'm at it. >> >> The file download is dovecot-1.2-sieve-0.1.13.tar.gz. >> >> Later I will also be building dovecot-1.2-managesieve-0.11.9.tar.gz. >> >> It looks like the authors add the dovecot version in the name >> because there are different versions of the plugin depending on the >> version of dovecot. >> >> I'm using my own dovecot Portfile and I'm at the most recent 1.2 >> version while ports has 1.1.16. >> >> Should I bother submitting dovecot sieve and if so what should I >> name it? > > Maybe dovecot-sieve? There is an open request to add a +sieve > variant to dovecot; maybe your separate port would satisfy this > request. A separate port is probably better for usability than a > variant anyway. > > http://trac.macports.org/ticket/11810 There are two sieve options for dovecot, Dovecot Sieve for Dovecot 1.2 and newer and CMU Sieve for Dovecot 1.0 through 1.2. So dovecot-sieve and later if someone wants the other they could create dovecot-cmu-sieve? >> Should I also submit my dovecot 1.2 Portfile? > > That would be great. > If so should I trac it to the current dovecot or rename it to > dovecot12 or something? > > My instinct would be no. Is there any reason someone would still > want dovecot 1.1? You could ask the maintainer of dovecot for > guidance if you're unsure. When I have this working on my production server, hopefully tonight, I'll send my Portfile to the maintainer. >> Also, dovecot v2 is in beta, I won't be building it real soon but >> thought I'd mention. >> >> BTW, the dovecot 1.1 branch is at 1.1.20. 1.1.16 was release June >> 1st 2009. >> >> I'm only moving to dovecot 1.2 because dovecot-sieve is for dovecot >> 1.2 or newer. > > As far as I can tell, 1.2.9 is the stable version of dovecot, so I > would assume the port should be updated to that version. It looks > like the maintainer last touched the port the month before 1.2.0 was > released. // Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Thu Dec 17 00:28:21 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 17 Dec 2009 02:28:21 -0600 Subject: macports dovecot sieve In-Reply-To: <979AABCE-1338-455B-9669-935BD58ABB4D@pixilla.com> References: <28CF2767-550B-4341-86DC-70FAD0EE51ED@macports.org> <979AABCE-1338-455B-9669-935BD58ABB4D@pixilla.com> Message-ID: On Dec 17, 2009, at 02:20, Bradley Giesbrecht wrote: > On Dec 16, 2009, at 11:59 PM, Ryan Schmidt wrote: > >> On Dec 17, 2009, at 01:26, Bradley Giesbrecht wrote: >> >>> Should I bother submitting dovecot sieve and if so what should I name it? >> >> Maybe dovecot-sieve? There is an open request to add a +sieve variant to dovecot; maybe your separate port would satisfy this request. A separate port is probably better for usability than a variant anyway. >> >> http://trac.macports.org/ticket/11810 > > There are two sieve options for dovecot, Dovecot Sieve for Dovecot 1.2 and newer and CMU Sieve for Dovecot 1.0 through 1.2. > > So dovecot-sieve and later if someone wants the other they could create dovecot-cmu-sieve? Oh, I see. Well that sounds ok. In any case it will be good to have any sieve option for dovecot in MacPorts. From ryandesign at macports.org Thu Dec 17 20:29:27 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 17 Dec 2009 22:29:27 -0600 Subject: [61662] trunk/dports/net/libpcapnav/ In-Reply-To: <20091217230624.25F6F3917A09@beta.macosforge.org> References: <20091217230624.25F6F3917A09@beta.macosforge.org> Message-ID: <4F58DB70-6E43-48A0-9E01-1EF5FE0BE160@macports.org> Eric, You appear to have committed only three empty directories, without Portfiles inside. :) On Dec 17, 2009, at 17:06, ecronin at macports.org wrote: > Revision: 61662 > http://trac.macports.org/changeset/61662 > Author: ecronin at macports.org > Date: 2009-12-17 15:06:21 -0800 (Thu, 17 Dec 2009) > Log Message: > ----------- > net/libpcapnav: New port > > Added Paths: > ----------- > trunk/dports/net/libpcapnav/ On Dec 17, 2009, at 17:21, ecronin at macports.org wrote: > Revision: 61663 > http://trac.macports.org/changeset/61663 > Author: ecronin at macports.org > Date: 2009-12-17 15:21:03 -0800 (Thu, 17 Dec 2009) > Log Message: > ----------- > net/libnetdude: New port > > Added Paths: > ----------- > trunk/dports/net/libnetdude/ On Dec 17, 2009, at 17:39, ecronin at macports.org wrote: > Revision: 61664 > http://trac.macports.org/changeset/61664 > Author: ecronin at macports.org > Date: 2009-12-17 15:38:57 -0800 (Thu, 17 Dec 2009) > Log Message: > ----------- > net/netdude: New port > > Added Paths: > ----------- > trunk/dports/net/netdude/ From emer at emer.net Fri Dec 18 08:50:01 2009 From: emer at emer.net (Mark Anderson) Date: Fri, 18 Dec 2009 11:50:01 -0500 Subject: Ticket #22512 Message-ID: <2cf4100f0912180850j4a182638tf65e6f187485c63e@mail.gmail.com> Can someone please commit ticket 22512? I have a diff attached that should fix geda-gaf's problem. Mark From dports at ambulatoryclam.net Sat Dec 19 01:56:28 2009 From: dports at ambulatoryclam.net (Dan Ports) Date: Sat, 19 Dec 2009 01:56:28 -0800 Subject: Combined build and destroot Message-ID: <20091219095628.GB84569@ambulatoryclam.net> I'm working on packaging MacFUSE 2.0 (ref: ticket #18671). This process is made rather painful by the fact that MacFUSE includes its own (surprisingly complicated) build script. One complication is that the script essentially does the build and destroot phases together (because it's trying to create a .pkg). The easiest way to get it working would be to patch the build script to install into ${destpath}. But then it would populate ${destpath} during the build phase rather than destroot -- how egregious of an offense is this? (Alternatively we could do both the compilation and installation during destroot, but that doesn't seem a lot better) Properly separating the build and destroot phases would require a fairly intrusive patch to macfuse's build script, which I would like to avoid. Another option is to have the build phase stage everything somewhere in ${workpath} and then copy all of its contents directly to ${destpath} during destroot, but that feels a little silly. Has this come up for other ports? Is there a best practice for dealing with it? Thanks, Dan -- Dan R. K. Ports Research Henchman Massachusetts Institute of Technology Computer Science and Artificial Intelligence Lab From ryandesign at macports.org Sat Dec 19 08:20:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 19 Dec 2009 10:20:05 -0600 Subject: Combined build and destroot In-Reply-To: <20091219095628.GB84569@ambulatoryclam.net> References: <20091219095628.GB84569@ambulatoryclam.net> Message-ID: <553C9DC3-1452-43F7-9D31-94A08BEDC5DA@macports.org> On Dec 19, 2009, at 03:56, Dan Ports wrote: > I'm working on packaging MacFUSE 2.0 (ref: ticket #18671). This process > is made rather painful by the fact that MacFUSE includes its own > (surprisingly complicated) build script. > > One complication is that the script essentially does the build and > destroot phases together (because it's trying to create a .pkg). > > The easiest way to get it working would be to patch the build script to > install into ${destpath}. But then it would populate ${destpath} during > the build phase rather than destroot -- how egregious of an offense is > this? Not an offense, I think. Most autoconf software is simply designed to build in the source directory and then install to a final directory, so MacPorts mirrors this method by default. Note that the destroot directory doesn't exist until the destroot phase begins, so if you wanted to install into it during the build phase, you'd have to create the destroot directory yourself. I'm not sure if this will impede MacPorts' own attempts to create the destroot directory (and the dozens of other directories inside it) but it might work ok, and I'd give it a try. > (Alternatively we could do both the compilation and installation > during destroot, but that doesn't seem a lot better) Yeah, that's probably worse. > Properly separating the build and destroot phases would require a > fairly intrusive patch to macfuse's build script, which I would like to > avoid. Agreed. > Another option is to have the build phase stage everything > somewhere in ${workpath} and then copy all of its contents directly to > ${destpath} during destroot, but that feels a little silly. Yes, this would probably just serve to introduce extra delays for the user while things are copied. From ryandesign at macports.org Sun Dec 20 13:41:44 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 20 Dec 2009 15:41:44 -0600 Subject: Ticket #22512 In-Reply-To: <2cf4100f0912180850j4a182638tf65e6f187485c63e@mail.gmail.com> References: <2cf4100f0912180850j4a182638tf65e6f187485c63e@mail.gmail.com> Message-ID: On Dec 18, 2009, at 10:50, Mark Anderson wrote: > Can someone please commit ticket 22512? I have a diff attached that > should fix geda-gaf's problem. Jann committed it. Thanks. From ryandesign at macports.org Sun Dec 20 22:31:33 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 21 Dec 2009 00:31:33 -0600 Subject: [61770] trunk/base/src/pextlib1.0/filemap.c In-Reply-To: <20091221062108.174563942427@beta.macosforge.org> References: <20091221062108.174563942427@beta.macosforge.org> Message-ID: On Dec 21, 2009, at 00:21, jmr at macports.org wrote: > Revision: 61770 > http://trac.macports.org/changeset/61770 > Author: jmr at macports.org > Date: 2009-12-20 22:21:07 -0800 (Sun, 20 Dec 2009) > Log Message: > ----------- > fix fd leak (#22959) I'm impressed you were able to find this! How'd you do that? :) And why does this change fix the problem? > Modified Paths: > -------------- > trunk/base/src/pextlib1.0/filemap.c > > Modified: trunk/base/src/pextlib1.0/filemap.c > =================================================================== > --- trunk/base/src/pextlib1.0/filemap.c 2009-12-21 05:14:02 UTC (rev 61769) > +++ trunk/base/src/pextlib1.0/filemap.c 2009-12-21 06:21:07 UTC (rev 61770) > @@ -210,7 +210,7 @@ > ssize_t theFileSize; > > /* Open the file for reading, creating it if necessary. */ > - int theFD = open(inDatabasePath, O_RDONLY | O_CREAT, 0664); > + theFD = open(inDatabasePath, O_RDONLY | O_CREAT, 0664); > if (theFD < 0) > { > theErr = errno; From jmr at macports.org Sun Dec 20 22:45:00 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 21 Dec 2009 17:45:00 +1100 Subject: [61770] trunk/base/src/pextlib1.0/filemap.c In-Reply-To: References: <20091221062108.174563942427@beta.macosforge.org> Message-ID: <4B2F196C.2090205@macports.org> On 2009-12-21 17:31 , Ryan Schmidt wrote: > > On Dec 21, 2009, at 00:21, jmr at macports.org wrote: > >> Revision: 61770 >> http://trac.macports.org/changeset/61770 >> Author: jmr at macports.org >> Date: 2009-12-20 22:21:07 -0800 (Sun, 20 Dec 2009) >> Log Message: >> ----------- >> fix fd leak (#22959) > > I'm impressed you were able to find this! How'd you do that? :) And why does this change fix the problem? The existing variable with the same name declared outside the loop is what is closed later on. - Josh From macsforever2000 at macports.org Mon Dec 21 10:13:37 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Mon, 21 Dec 2009 11:13:37 -0700 Subject: [61786] trunk/dports/www In-Reply-To: <20091221161014.210933946C8B@beta.macosforge.org> References: <20091221161014.210933946C8B@beta.macosforge.org> Message-ID: <3DF2BFCC-85D2-4EBF-BA0D-3499D5153957@macports.org> On Dec 21, 2009, at 9:10 AM, jann at macports.org wrote: > Revision > 61786 > Author > jann at macports.org > Date > 2009-12-21 08:10:10 -0800 (Mon, 21 Dec 2009) > Log Message > > New port: #21712 > Added Paths > > trunk/dports/www/drush/ > trunk/dports/www/drush/Portfile > Diff > > Added: trunk/dports/www/drush/Portfile (0 => 61786) > > --- trunk/dports/www/drush/Portfile (rev 0) > +++ trunk/dports/www/drush/Portfile 2009-12-21 16:10:10 UTC (rev 61786) > @@ -0,0 +1,41 @@ > +# $Id$ > + > +PortSystem 1.0 > + > +name drush > +version 2.1 > +categories www php > +platforms darwin > + > +maintainers chuck at acquia.com The email address should be obfuscated like this - acquia.com:chuck > +description The DRUpal SHell > +long_description drush is a command line shell and Unix scripting interface for Drupal, a veritable Swiss Army \ > + knife designed to make life easier for those of us who spend some of our working hours hacking \ > + away at the command prompt. > + > +homepage http://drupal.org/project/drush > +distfiles drush-All-Versions-$version.tar.gz > +master_sites http://ftp.drupal.org/files/projects/ \ > + http://ftp.osuosl.org/pub/drupal/files/projects/ > +checksums md5 dd4b55c7d1e98f35c51c69788d6dffee \ > + sha1 d49d05baa26d8ce7aa7f0250c6f0e01ba2f5aebb \ > + rmd160 5d78cd177ae53d4844ca8f6cdb427ec286393881 > +depends_lib port:php52 > + > +variant drupal5 description "use with Drupal 5 port" { > + depends_lib-append port:drupal5 > +} > + > +variant drupal6 description "use with Drupal 6 port" { > + depends_lib-append port:drupal6 > +} > + > +worksrcdir drush > +use_configure no > +build { } > + > +destroot { > + xinstall -d -m 0755 ${destroot}/${prefix}/libexec/drush > + eval file copy [glob ${worksrcpath}/*] ${destroot}/${prefix}/libexec/drush > + ln -s ${prefix}/libexec/drush/drush ${destroot}/${prefix}/bin/drush > +} > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Mon Dec 21 10:41:59 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 21 Dec 2009 12:41:59 -0600 Subject: [61786] trunk/dports/www In-Reply-To: <3DF2BFCC-85D2-4EBF-BA0D-3499D5153957@macports.org> References: <20091221161014.210933946C8B@beta.macosforge.org> <3DF2BFCC-85D2-4EBF-BA0D-3499D5153957@macports.org> Message-ID: On Dec 21, 2009, at 12:13, Frank Schima wrote: >> +maintainers chuck at acquia.com > > The email address should be obfuscated like this - acquia.com:chuck It does not need to be, but it is probably better to do so, to avoid being harvested by some spambots. I made this change in r61813. From ryandesign at macports.org Mon Dec 21 11:40:06 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 21 Dec 2009 13:40:06 -0600 Subject: [61822] trunk/dports/net In-Reply-To: <20091221185952.EDEB739490CC@beta.macosforge.org> References: <20091221185952.EDEB739490CC@beta.macosforge.org> Message-ID: <79B4A2D8-C8EC-4FB2-8033-B4215A9DDC47@macports.org> On Dec 21, 2009, at 12:59, ecronin at macports.org wrote: > Revision: 61822 > http://trac.macports.org/changeset/61822 > Author: ecronin at macports.org > Date: 2009-12-21 10:59:51 -0800 (Mon, 21 Dec 2009) > Log Message: > ----------- > new port: net/py26-scapy (clone of py25's net/scapy) But is scapy a python module, or software that just happens to use python? If the former, then scapy should be renamed py25-scapy. If the latter, then scapy should be updated to use python 2.6 and py26-scapy should be deleted. From ecronin at macports.org Mon Dec 21 12:32:19 2009 From: ecronin at macports.org (Eric Cronin) Date: Mon, 21 Dec 2009 15:32:19 -0500 Subject: [61822] trunk/dports/net In-Reply-To: <79B4A2D8-C8EC-4FB2-8033-B4215A9DDC47@macports.org> References: <20091221185952.EDEB739490CC@beta.macosforge.org> <79B4A2D8-C8EC-4FB2-8033-B4215A9DDC47@macports.org> Message-ID: <0018CF4A-15E3-4509-ACC0-96E6326B360C@macports.org> On Dec 21, 2009, at 2:40 PM, Ryan Schmidt wrote: > > On Dec 21, 2009, at 12:59, ecronin at macports.org wrote: > >> Revision: 61822 >> http://trac.macports.org/changeset/61822 >> Author: ecronin at macports.org >> Date: 2009-12-21 10:59:51 -0800 (Mon, 21 Dec 2009) >> Log Message: >> ----------- >> new port: net/py26-scapy (clone of py25's net/scapy) > > But is scapy a python module, or software that just happens to use python? If the former, then scapy should be renamed py25-scapy. If the latter, then scapy should be updated to use python 2.6 and py26-scapy should be deleted. > It is (largely) software written in python. I based the name on py26-markdown which is also a tool written in python that can be installed against py25 or py26. I didn't want to step on pmq's port or force current users to have to update to py26, but I have a py25-free install and so it seemed useful to have in dports... Thanks, Eric From brad at pixilla.com Tue Dec 22 10:07:58 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 22 Dec 2009 10:07:58 -0800 Subject: dovecot-sieve Message-ID: Hi, I'm building a Portfile for dovecot-sieve and to get the dovecot-sieve command line tools I also need to download the dovecot sources. How do I add an additional download to my Portfile so the sources end up in the work directory? Also, I'd prefer to grab the same version that 'port download dovecot' would download. In my situation I'm building a newer version of dovecot then is in MacPorts. So this is what the work dir would look like: ./work/dovecot-1.2-sieve-0.1.14 ./work/dovecot-1.2.9 and dovecot-sieve configure args would be: ./configure --with-dovecot=${workpath}/dovecot-1.2.9/ So from the configure line you see I either need to know the full dovecot version or need to extract it to: ./work/dovecot Any tips on doing this would be groovy. Thanks, Brad From panayotis at panayotis.com Tue Dec 22 10:41:50 2009 From: panayotis at panayotis.com (Panayotis Katsaloulis) Date: Tue, 22 Dec 2009 20:41:50 +0200 Subject: launch4j port Message-ID: Hello I have created a new port for launch4j a week ago, but there is no feedback. The ticket is here http://trac.macports.org/ticket/22914 Could you have a look? Thanks! From brad at pixilla.com Tue Dec 22 12:34:20 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 22 Dec 2009 12:34:20 -0800 Subject: dovecot-sieve In-Reply-To: References: Message-ID: On Dec 22, 2009, at 10:07 AM, Bradley Giesbrecht wrote: > Hi, > > > I'm building a Portfile for dovecot-sieve and to get the dovecot- > sieve command line tools I also need to download the dovecot sources. > > How do I add an additional download to my Portfile so the sources > end up in the work directory? > > Also, I'd prefer to grab the same version that 'port download > dovecot' would download. In my situation I'm building a newer > version of dovecot then is in MacPorts. > > > So this is what the work dir would look like: > > ./work/dovecot-1.2-sieve-0.1.14 > ./work/dovecot-1.2.9 I know there is a desire to reduce variants in MacPorts but dovecot- sieve seems a prime candidate for a variant. To get the command line tools of dovecot-sieve you need the dovecot compiled sources dir and pass that to configure. http://wiki.dovecot.org/LDA/Sieve/Dovecot Compiling Compilation is identical among the CMUSieve and the new Sieve plugin. Use --with-dovecot= to point to dovecot-config file's directory. There are two possibilities where this could exist: ? If you configured Dovecot with --enable-header-install, you'll have dovecot-config installed in $prefix/lib/dovecot/ directory. For example: ./configure --with-dovecot=/usr/local/lib/dovecot make sudo make install ? Compiled Dovecot sources' root directory. For example: ./configure --with-dovecot=../dovecot-1.2.0/ make make install If you downloaded the sources using Mercurial, you will need to execute ./autogen.sh first to build the automake structure in your source tree. This process requires autotools and libtool to be installed. Dovecot Sieve includes several command line tools to perform tasks such as compile, verify and debug Sieve scripts (refer to the README file for more information). These are built only if you use method 2, because they need to link Dovecot's .a libraries, which can only be found from Dovecot's source tree (make install doesn't install them). Currently I'm downloading the dovecot sources, doing an extract.only for dovecot-sieve and then this in post-extract: post-extract { system "cd ${workpath} && tar xzf ${distpath}/dovecot-$ {dovecot_minor_version}.tar.gz" system "cd ${workpath}/dovecot-${dovecot_minor_version} && ./ configure --prefix=${prefix} && make" } I borrowed this from the i386-elf-gcc port. I submitted a new port for dovecot-sieve and dovecot which appears to build clean on my system. I am currently using the new dovecot 1.2.9 port and it seems to be working fine. I have not worked with teh dovecot-sieve tools but as I said they build clean and the command line tools I checked out execute without error other then complaining for lack of input. I haven't actually tested any sieve-scripts yet. // Brad From dports at ambulatoryclam.net Tue Dec 22 23:36:55 2009 From: dports at ambulatoryclam.net (Dan Ports) Date: Tue, 22 Dec 2009 23:36:55 -0800 Subject: Combined build and destroot In-Reply-To: <553C9DC3-1452-43F7-9D31-94A08BEDC5DA@macports.org> References: <20091219095628.GB84569@ambulatoryclam.net> <553C9DC3-1452-43F7-9D31-94A08BEDC5DA@macports.org> Message-ID: <20091223073655.GB1836@ambulatoryclam.net> On Sat, Dec 19, 2009 at 10:20:05AM -0600, Ryan Schmidt wrote: > Note that the destroot directory doesn't exist until the destroot phase begins, so if you wanted to install into it during the build phase, you'd have to create the destroot directory yourself. I'm not sure if this will impede MacPorts' own attempts to create the destroot directory (and the dozens of other directories inside it) but it might work ok, and I'd give it a try. This turns out not to be a problem -- MacPorts just skips over any directories that already exist in the destroot when populating it at the beginning of the destroot phase. So this is likely the way to go if anyone finds themselves with a similar problem. Obviously the port's build script needs to create any missing directories in the destroot, but anything with a non-trivial build script probably knows how to do that. Dan -- Dan R. K. Ports Research Henchman Massachusetts Institute of Technology Computer Science and Artificial Intelligence Lab From dark.panda+macports at gmail.com Wed Dec 23 19:35:20 2009 From: dark.panda+macports at gmail.com (J Smith) Date: Wed, 23 Dec 2009 23:35:20 -0400 Subject: Debugging symbols? Message-ID: Hi list... Apologies if I'm missing something terribly obvious, but is there any way to build a port with debugging symbols enabled for debugging in gdb? I've looked around and haven't found an option, but I may be missing something rather obvious... Cheers From ryandesign at macports.org Wed Dec 23 23:16:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 24 Dec 2009 01:16:08 -0600 Subject: Debugging symbols? In-Reply-To: References: Message-ID: On Dec 23, 2009, at 21:35, J Smith wrote: > Apologies if I'm missing something terribly obvious, but is there any > way to build a port with debugging symbols enabled for debugging in > gdb? I've looked around and haven't found an option, but I may be > missing something rather obvious... I don't think you're missing anything; I don't recall anybody asking for this before so there isn't anything built into MacPorts to accommodate that. How would one build a piece of software with debugging symbols? Is it a configure option? an environment variable? Perhaps it varies by software? Which specific ports were you wanting this for? Some individual ports do offer debugging options, e.g. php5 has a debug variant. From jeremyhu at macports.org Thu Dec 24 07:51:20 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Thu, 24 Dec 2009 07:51:20 -0800 Subject: Debugging symbols? In-Reply-To: References: Message-ID: <36918B06-1377-4658-804D-6331DAC30509@macports.org> I just use configure.optflags in src/port1.0/portconfigure.tcl: -default configure.optflags {-O2} +default configure.optflags {-ggdb3 -O0} We should probably let the optflags be customizable via macports.conf, but this works fine for me. On Dec 23, 2009, at 23:16, Ryan Schmidt wrote: > > On Dec 23, 2009, at 21:35, J Smith wrote: > >> Apologies if I'm missing something terribly obvious, but is there any >> way to build a port with debugging symbols enabled for debugging in >> gdb? I've looked around and haven't found an option, but I may be >> missing something rather obvious... > > I don't think you're missing anything; I don't recall anybody asking for this before so there isn't anything built into MacPorts to accommodate that. > > How would one build a piece of software with debugging symbols? Is it a configure option? an environment variable? Perhaps it varies by software? Which specific ports were you wanting this for? Some individual ports do offer debugging options, e.g. php5 has a debug variant. > > > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5820 bytes Desc: not available URL: From dark.panda+macports at gmail.com Thu Dec 24 09:15:33 2009 From: dark.panda+macports at gmail.com (J Smith) Date: Thu, 24 Dec 2009 13:15:33 -0400 Subject: Debugging symbols? In-Reply-To: <36918B06-1377-4658-804D-6331DAC30509@macports.org> References: <36918B06-1377-4658-804D-6331DAC30509@macports.org> Message-ID: On Thu, Dec 24, 2009 at 11:51 AM, Jeremy Huddleston wrote: > I just use configure.optflags in src/port1.0/portconfigure.tcl: > > -default configure.optflags ?{-O2} > +default configure.optflags ?{-ggdb3 -O0} > > We should probably let the optflags be customizable via macports.conf, but this works fine for me. > Aha, sweet, that's what I was looking for. Yeah, it would be pretty cool if options like these (CFLAGS, LDFLAGS, CPPFLAGS, etc.) were available right in the main macports.conf file without having to dig through TCL source or could be overridden via environment variables or something. The trade-off might be Gentoo-style "my CFLAGS are better than your CFLAGS" competitions and a possible increase in bug reports and the like as people may accidentally break their builds by futzing around too much with those types of settings, but I think that such levels of customizations are one of the primary benefits of ports systems since everything is built locally anyways. Anyways, cheers, this will definitely come in handy. I'm going to look into a segfault I'm experiencing with the gd2 library when using the Ruby wrapper, and the partial stack trace was making things more difficult than need be. Being able to set these flags will definitely help. Again, thanks and cheers! From howarth at bromo.med.uc.edu Thu Dec 24 12:31:05 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Thu, 24 Dec 2009 15:31:05 -0500 Subject: Debugging symbols? In-Reply-To: References: Message-ID: <20091224203105.GA13176@bromo.med.uc.edu> On Thu, Dec 24, 2009 at 01:16:08AM -0600, Ryan Schmidt wrote: > > On Dec 23, 2009, at 21:35, J Smith wrote: > > > Apologies if I'm missing something terribly obvious, but is there any > > way to build a port with debugging symbols enabled for debugging in > > gdb? I've looked around and haven't found an option, but I may be > > missing something rather obvious... > > I don't think you're missing anything; I don't recall anybody asking for this before so there isn't anything built into MacPorts to accommodate that. > > How would one build a piece of software with debugging symbols? Is it a configure option? an environment variable? Perhaps it varies by software? Which specific ports were you wanting this for? Some individual ports do offer debugging options, e.g. php5 has a debug variant. > > > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev Ryan, Darwin stores its debug symbols in the object files... http://developer.apple.com/mac/library/documentation/DeveloperTools/gdb/gdb/gdb_5.html#SEC19 On fink, I usually work around this by using 'fink -k rebuild' to retain the populated build directory for the code of the program being debugged. I suspect the same approach would work if the port was invoked to retain the build directory as well. Jack From raimue at macports.org Sat Dec 26 09:14:15 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 26 Dec 2009 18:14:15 +0100 Subject: Debugging symbols? In-Reply-To: <36918B06-1377-4658-804D-6331DAC30509@macports.org> References: <36918B06-1377-4658-804D-6331DAC30509@macports.org> Message-ID: <4B364467.4000900@macports.org> On 2009-12-24 16:51 , Jeremy Huddleston wrote: > I just use configure.optflags in src/port1.0/portconfigure.tcl: > > -default configure.optflags {-O2} > +default configure.optflags {-ggdb3 -O0} > > We should probably let the optflags be customizable via macports.conf, but this works fine for me. We once had this discussion already and decided better not to support too many custom flags as it makes debugging broken builds much more complicated. We have enough problems supporting multiple Mac OS X versions in my opinion. If we allow software to be compiled with flags like -O3, -fomit-frame-pointer, etc. this could result in more bug reports with broken build caused by those flags. Rainer From ryandesign at macports.org Sat Dec 26 12:57:30 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 26 Dec 2009 14:57:30 -0600 Subject: [61961] trunk/dports/editors/sigil In-Reply-To: <20091226083345.45AAE398B5BA@beta.macosforge.org> References: <20091226083345.45AAE398B5BA@beta.macosforge.org> Message-ID: <8CBE76D9-F5DC-4902-90EC-5258051D2937@macports.org> On Dec 26, 2009, at 02:33, krischik at macports.org wrote: > platform x86_64 { > pre-configure { > - reinplace "s|ppc;i386|x86_64|g" ${workpath}/Sigil_code_${version}/CMakeLists.txt > + reinplace "s|ppc;i386|x86_64|g" ${workpath}/Sigil-${version}-Code/CMakeLists.txt > } > } Remember that there is no such thing as "platform x86_64" in MacPorts. > pre-configure { > + ui_msg "######################################################" > + ui_msg "# Note: SnowLeopard might need explicit +x86_64 #" > + ui_msg "######################################################" > + > file mkdir ${worksrcpath} > } Not really the way we want to handle this. Please inspect the variable ${configure.build_arch} (or, if you want to support universal builds, ${configure.universal_archs}) and act appropriately on all operating system versions. From ryandesign at macports.org Sat Dec 26 13:10:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 26 Dec 2009 15:10:05 -0600 Subject: [61964] trunk/dports/science In-Reply-To: <20091226085731.A15D0398BA6D@beta.macosforge.org> References: <20091226085731.A15D0398BA6D@beta.macosforge.org> Message-ID: <6F870282-DB29-4D91-BD55-BB238347AA40@macports.org> On Dec 26, 2009, at 02:57, takeshi at macports.org wrote: > Revision: 61964 > http://trac.macports.org/changeset/61964 > Author: takeshi at macports.org > Date: 2009-12-26 00:57:30 -0800 (Sat, 26 Dec 2009) > Log Message: > ----------- > magicspp: adding magicspp > Added: trunk/dports/science/magicspp/Portfile > +set submatch "" > +set flib "" > +regexp {\+([[:alnum:]]+) \(active\)} [exec port installed emos] match submatch > +if {${submatch}=="gcc43"} { > + set flib "-L${prefix}/lib/gcc43 -lgfortran" > + configure.compiler macports-gcc-4.3 > +} elseif {${submatch}=="g95"} { > + set flib -lf95 > + configure.f77 ${prefix}/bin/g95 > +} > +configure.env-append LIBS=\"-lgrib_api -lopenjpeg -lpng\" > +configure.ldflags-append "-lgrib_api -lopenjpeg -lpng -lemosR64 $flib -lnetcdf_c++ -lnetcdf" > +configure.cppflags-append -I${prefix}/include/freetype2/ You can't do this; calling "port installed emos" is causing the portindex to fail, because on the portindex machine, emos is not installed. Therefore: > Revision: 61966 > http://trac.macports.org/changeset/61966 > Author: portindex at macports.org > Date: 2009-12-26 01:54:57 -0800 (Sat, 26 Dec 2009) > Log Message: > ----------- > > Total number of ports parsed: 6457 > Ports successfully parsed: 6456 > Ports failed: 1 > > > Failed to parse file science/magicspp/Portfile: None of the specified ports are installed. You could do your checks in a pre-configure phase. But it would be better to ditch this whole method and instead provide normal gcc43 and g95 variants, like other ports including emos do. (You should probably also abstract it so you can easily add a gcc44 variant, and later a gcc45 variant when that version is final.) Then within each variant, put code to ensure dependencies like emos have been installed with the same variant. Using "port installed emos" to determine that is not recommended. Instead, use the existence of or contents of a file emos installs to guide this decision. For many programs, the -config script or .pc file might tell you, but emos doesn't seem to provide either of those. If it's not possible to determine from the existence of or contents of an existing emos file what variant it was installed with, modify the emos port to install a file which will tell you, then use that file in magicspp. From brooks at clarksonline.net Sat Dec 26 14:36:37 2009 From: brooks at clarksonline.net (M. Brooks Clark) Date: Sat, 26 Dec 2009 17:36:37 -0500 Subject: Please commit new portfile wview-5.9.5 In-Reply-To: References: <020F1D10-3A27-45EC-8EB0-A21EF0CD614C@clarksonline.net> Message-ID: <6A86B0A7-B14E-4291-A333-306E1944772B@clarksonline.net> I have submitted an updated portfile for the latest release of wview (https://trac.macports.org/attachment/ticket/23039/). Would someone be kind enough to commit the update? Thanks, Brooks From jmr at macports.org Sat Dec 26 20:49:09 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 27 Dec 2009 15:49:09 +1100 Subject: Remaining tickets for 1.8.2 release In-Reply-To: <4B26A468.6020204@macports.org> References: <4B26A468.6020204@macports.org> Message-ID: <4B36E745.7020506@macports.org> On 2009-12-15 07:47 , Joshua Root wrote: > The only remaining obstacles to a 1.8.2 release are these two tickets: > > > > > Both may already be fixed in trunk, but someone affected by the problems > described needs to confirm this. It's been 12 days and one of these is still open. I'm going to set a deadline for 1.8.2 fixes. Anything not done by the new year will have to wait for a later release. - Josh From nox at macports.org Sun Dec 27 10:25:17 2009 From: nox at macports.org (nox) Date: Sun, 27 Dec 2009 19:25:17 +0100 Subject: SDL frameworks Message-ID: <7B9A7BF5-66E2-4751-AAC6-B51CA79FC57A@macports.org> Hi there, I think someone already discussed that earlier on the mailing-list, but I don't think any conclusion has been reached, so I'm asking again: should we nuke the various libsdl*-framework ports? Is there anyone really using them? Regards. From nox at macports.org Sun Dec 27 15:00:28 2009 From: nox at macports.org (nox) Date: Mon, 28 Dec 2009 00:00:28 +0100 Subject: php5 extensions' versions Message-ID: Hi Ryan, Is there a particular reason as for why php5-zip (and possibly other extensions) follows php5 versioning even though they have their own versioning through PECL [1]? Regards. [1] http://pecl.php.net/package/zip From ryandesign at macports.org Sun Dec 27 15:08:48 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 27 Dec 2009 17:08:48 -0600 Subject: php5 extensions' versions In-Reply-To: References: Message-ID: <88B94086-B2D0-4496-821B-DAEF9BA2FA58@macports.org> On Dec 27, 2009, at 17:00, nox wrote: > Is there a particular reason as for why php5-zip (and possibly other extensions) follows php5 versioning even though > they have their own versioning through PECL [1]? > > Regards. > > [1] http://pecl.php.net/package/zip Exclusively because I was not aware the zip extension existed in PECL. For other extensions that I have found in PECL, they were older versions than the ones available in the PHP source; I understood that the versions in PECL were no longer being maintained, and that the latest version was available in the PHP source. If that's not the case for zip and other extensions, they can be changed to use the source from PECL. Please file tickets if that's the case. I'm just confused as to why the developers of PHP still bundle it with the PHP source, if newer versions are available elsewhere. From ryandesign at macports.org Sun Dec 27 15:17:22 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 27 Dec 2009 17:17:22 -0600 Subject: SDL frameworks In-Reply-To: <7B9A7BF5-66E2-4751-AAC6-B51CA79FC57A@macports.org> References: <7B9A7BF5-66E2-4751-AAC6-B51CA79FC57A@macports.org> Message-ID: <4F4353D4-B9FC-4B60-B51E-3DCECD6CB08F@macports.org> On Dec 27, 2009, at 12:25, nox wrote: > I think someone already discussed that earlier on the mailing-list, but I don't think any conclusion has been reached, so I'm asking again: should we nuke the various libsdl*-framework ports? Is there anyone really using them? I was trying to create a port for enigma, which wants to use the SDL frameworks. But I never got it to work, and that was years ago. Now, I see the SDL frameworks don't even build. Maybe enigma can be convinced to use the non-framework versions instead. (I'd appreciate any help you can offer on that.) http://trac.macports.org/ticket/14354 From nox at macports.org Sun Dec 27 16:18:09 2009 From: nox at macports.org (nox) Date: Mon, 28 Dec 2009 01:18:09 +0100 Subject: SDL frameworks In-Reply-To: <4F4353D4-B9FC-4B60-B51E-3DCECD6CB08F@macports.org> References: <7B9A7BF5-66E2-4751-AAC6-B51CA79FC57A@macports.org> <4F4353D4-B9FC-4B60-B51E-3DCECD6CB08F@macports.org> Message-ID: <290D08AC-079F-4663-A27B-22076F4174B7@macports.org> Le 28 d?c. 2009 ? 00:17, Ryan Schmidt a ?crit : > > On Dec 27, 2009, at 12:25, nox wrote: > >> I think someone already discussed that earlier on the mailing-list, but I don't think any conclusion has been reached, so I'm asking again: should we nuke the various libsdl*-framework ports? Is there anyone really using them? > > I was trying to create a port for enigma, which wants to use the SDL frameworks. But I never got it to work, and that was years ago. Now, I see the SDL frameworks don't even build. Maybe enigma can be convinced to use the non-framework versions instead. (I'd appreciate any help you can offer on that.) > > http://trac.macports.org/ticket/14354 > > I asked the question cause I just realized that none of the SDL frameworks ports have correct install names. And it seems your enigma suffers of this problem, I'll try to look into making it use bare libraries. From ryandesign at macports.org Sun Dec 27 17:57:16 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 27 Dec 2009 19:57:16 -0600 Subject: [62001] trunk/dports/python In-Reply-To: <20091227134833.3430639AB99B@beta.macosforge.org> References: <20091227134833.3430639AB99B@beta.macosforge.org> Message-ID: <7B143B31-7E10-49A2-85CE-12662F322512@macports.org> On Dec 27, 2009, at 07:48, krischik at macports.org wrote: > Revision: 62001 > http://trac.macports.org/changeset/62001 > Author: krischik at macports.org > Date: 2009-12-27 05:48:29 -0800 (Sun, 27 Dec 2009) > Log Message: > ----------- > Python modules needed for calibre. > Property changes on: trunk/dports/python/py26-clientform > ___________________________________________________________________ > Added: svn:ignore > + .backups > work I suggest you add ".backups" and "work" to your Subversion client's global ignores; it's not efficient to add the svn:ignore property to every port directory in the repository. > Modified: trunk/dports/python/py26-clientform/Portfile > =================================================================== > --- trunk/dports/python/py25-clientform/Portfile 2009-12-26 11:54:37 UTC (rev 61972) > +++ trunk/dports/python/py26-clientform/Portfile 2009-12-27 13:48:29 UTC (rev 62001) > @@ -1,36 +1,37 @@ > -# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 > +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- > # $Id$ > +# vim: set fileencoding=utf-8 tabstop=8 shiftwidth=4 softtabstop=4 noexpandtab filetype=tcl : It would be better to use the standard modeline defined in the Guide. http://guide.macports.org/chunked/development.creating-portfile.html > -PortSystem 1.0 > -PortGroup python25 1.0 > +PortSystem 1.0 > +PortGroup python26 1.0 > > -name py25-clientform > -version 0.2.9 > -categories python www > -platforms darwin > -maintainers openmaintainer akitada > -description python module for handling HTML forms > +name py26-clientform > +version 0.2.9 > +categories python www > +platforms darwin > +maintainers openmaintainer krischik > +description python module for handling HTML forms When there are multiple ports for a single piece of software (e.g. py25-something and py26-something) they should be kept as similar as possible. This means not making whitespace or functional changes to one without making the same changes to the other. If I look at a diff between the py25 and py26 versions of a port, I should only see the necessary functional differences. You changed the ports from space-only indentation to a mix of tab and space indentation; we want spaces only. See the Guide: http://guide.macports.org/chunked/development.practices.html#development.practices.portstyle It's also best if these ports are maintained (or co-maintained) by the same mainatiner(s) (though having openmaintainer is fine and allows either maintainer to update the other port). From reid at orthogonalspace.ca Sun Dec 27 20:25:13 2009 From: reid at orthogonalspace.ca (Reid Nichol) Date: Mon, 28 Dec 2009 04:25:13 -0000 (Canada/Mountain) Subject: SDL frameworks In-Reply-To: <7B9A7BF5-66E2-4751-AAC6-B51CA79FC57A@macports.org> References: <7B9A7BF5-66E2-4751-AAC6-B51CA79FC57A@macports.org> Message-ID: <61088.68.147.209.140.1261974313.squirrel@mail.orthogonalspace.ca> > Hi there, > > I think someone already discussed that earlier on the mailing-list, but I > don't think any conclusion has been reached, so I'm asking again: should > we nuke the various libsdl*-framework ports? Is there anyone really using > them? > I submitted a port a little while back that uses one of them. I'd appreciate these ports sticking around. https://trac.macports.org/ticket/22888 Regards, Reid From tommyd at macports.org Mon Dec 28 03:44:13 2009 From: tommyd at macports.org (Thomas Keller) Date: Mon, 28 Dec 2009 12:44:13 +0100 Subject: SDL frameworks In-Reply-To: <7B9A7BF5-66E2-4751-AAC6-B51CA79FC57A@macports.org> References: <7B9A7BF5-66E2-4751-AAC6-B51CA79FC57A@macports.org> Message-ID: <4B389A0D.8050506@macports.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 27.12.09 19:25, schrieb nox: > Hi there, > > I think someone already discussed that earlier on the mailing-list, > but I don't think any conclusion has been reached, so I'm asking > again: should we nuke the various libsdl*-framework ports? Is there > anyone really using them? I've tried to create a port for unknown horizons (ex-openAnno) and all its dependencies, but failed to get libguichan to compile under OSX. Anyways, I'd like to pick this topic up in the future and need SDL for this, too. Thomas. - -- GPG-Key 0x160D1092 | tommyd3mdi at jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks4mg0ACgkQaf7NlBYNEJJifQCgq7V+grbrYdLNLYo5GmWLwg6t LGAAmwcndisIFvPNDxEsGR3dlBV2PPdn =1S2t -----END PGP SIGNATURE----- From nox at macports.org Mon Dec 28 05:11:30 2009 From: nox at macports.org (nox) Date: Mon, 28 Dec 2009 14:11:30 +0100 Subject: SDL frameworks In-Reply-To: <61088.68.147.209.140.1261974313.squirrel@mail.orthogonalspace.ca> References: <7B9A7BF5-66E2-4751-AAC6-B51CA79FC57A@macports.org> <61088.68.147.209.140.1261974313.squirrel@mail.orthogonalspace.ca> Message-ID: <93CC5F95-4C2A-42B4-ADE3-4AD81F05031D@macports.org> Le 28 d?c. 2009 ? 05:25, Reid Nichol a ?crit : >> Hi there, >> >> I think someone already discussed that earlier on the mailing-list, but I >> don't think any conclusion has been reached, so I'm asking again: should >> we nuke the various libsdl*-framework ports? Is there anyone really using >> them? >> > > I submitted a port a little while back that uses one of them. I'd > appreciate these ports sticking around. > > https://trac.macports.org/ticket/22888 > > The frameworks could also be a simple set of symlinks created by the main non-framework port. From brooks at clarksonline.net Mon Dec 28 18:58:51 2009 From: brooks at clarksonline.net (M. Brooks Clark) Date: Mon, 28 Dec 2009 21:58:51 -0500 Subject: Updated portfile for wview-5.10.0 -- Please commit Message-ID: <335F896F-9CB1-4F7B-8A85-735BB5E8096C@clarksonline.net> I've added an updated portfile to this ticket for a new release of wview. Can someone go ahead and commit? Thanks. https://trac.macports.org/ticket/23039 Brooks -------------- next part -------------- An HTML attachment was scrubbed... URL: From emer at emer.net Tue Dec 29 11:26:37 2009 From: emer at emer.net (Mark Anderson) Date: Tue, 29 Dec 2009 14:26:37 -0500 Subject: gEDA on MacPorts In-Reply-To: References: Message-ID: <2cf4100f0912291126i746f1b74lb0a20c7ad393b564@mail.gmail.com> That should probably be bumped to 20091103? Submit a ticket on the website ( http://www.macports.org ) asking for an upgrade. I have a patch that might work, but Adam is the maintainer, so he'll have to approve the changes. Mark On Tue, Dec 29, 2009 at 2:02 PM, Donald Tillman wrote: > [try again, 'goofed an email address] > > Gents, > > I understand you guys are maintaining the geda-gaf and pcb ports on > MacPorts. > > I'm trying to set up and run gEDA (Mac PowerBook Pro, MAC OS X 1.5.8) > and design some boards. ?Fink has failed me, and so I'm trying to get > the MacPorts version running. ?(Specifically, Fink only has very old > releases in binary form: gschem version 20071231, pcb version > 20060822. ?And Fink errors out with something incomprensible > attempting to compile more modern versions.) > > I need a modern version of gschem because I need to use the path > feature in the symbol files. ?And I need a modern version of pcb > because the version of gsch2pcb that I'm using generates files that > are not compatible with pcb 20060822. > > So I'm looking to MacPorts. ?MacPorts geda-gaf gives me a modern > version of gschem, 20091004. ?And that seems to work well. ?But for > some reason pcb isn't included in that package. ?I discover that > MacPorts pcb is a separate package, I try that, but it's pcb is only > at version 20060321. > > So can you help? ?How can I get a modern version of pcb? > > Thanks much. > > ?-- Don > > -- > Don Tillman > Palo Alto, California > don at till.com > http://www.till.com > From jeremy at lavergne.gotdns.org Tue Dec 29 12:30:15 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 29 Dec 2009 15:30:15 -0500 Subject: [62139] trunk/dports/aqua/osxvnc In-Reply-To: <20091229202741.0A58839E43D4@beta.macosforge.org> References: <20091229202741.0A58839E43D4@beta.macosforge.org> Message-ID: > Modified: trunk/dports/aqua/osxvnc/Portfile (62138 => 62139) > > name osxvnc > > -version 3.0 > -revision 1 > > +version 3.1 > +replaced_by vineserver > It's been a while, but is it correct that replaced_by operates before revision checking? From ryandesign at macports.org Tue Dec 29 12:32:34 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 29 Dec 2009 14:32:34 -0600 Subject: [62139] trunk/dports/aqua/osxvnc In-Reply-To: References: <20091229202741.0A58839E43D4@beta.macosforge.org> Message-ID: On Dec 29, 2009, at 14:30, Jeremy Lavergne wrote: >> Modified: trunk/dports/aqua/osxvnc/Portfile (62138 => 62139) >> >> name osxvnc >> >> -version 3.0 >> -revision 1 >> >> +version 3.1 >> +replaced_by vineserver >> > > It's been a while, but is it correct that replaced_by operates before revision checking? I don't really know... Whenever I've added replaced_by to a port, I've increased the epoch, version or revision to ensure the port shows up in "port outdated", just to be sure. From evenson at panix.com Thu Dec 24 07:07:23 2009 From: evenson at panix.com (Mark Evenson) Date: Thu, 24 Dec 2009 15:07:23 -0000 Subject: [MacPorts] #20904: sbcl 1.0.29 fails to build on 10.6 In-Reply-To: <064.ce9207b0b6bbbbe042ec8603f4e5cb31@macports.org> References: <055.eeb7769bc9bfcd0b8ac2c7f3cafb107a@macports.org> <064.ce9207b0b6bbbbe042ec8603f4e5cb31@macports.org> Message-ID: <4B3383A3.6030402@panix.com> On 12/24/09 10:02 AM, MacPorts wrote: > #20904: sbcl 1.0.29 fails to build on 10.6 > ----------------------------------+----------------------------------------- > Reporter: luis.beca@? | Owner: easieste@? > Type: defect | Status: closed > Priority: Normal | Milestone: > Component: ports | Version: 1.8.0 > Resolution: fixed | Keywords: snowleopard > Port: sbcl | > ----------------------------------+----------------------------------------- > > Comment(by jabial@?): > > When is it going to be available through selfupdate? > Dunno. I committed it to [svn in the usual place][1] about ten minutes ago, but it hasn't shown up via 'selfupdate'. Is there an additional step to take that I didn't know about or have forgotten about? I'll move the port status back to 'assigned' until I see it "take". [1]: https://svn.macports.org/repository/macports/trunk/dports/lang/sbcl -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." From evenson at panix.com Fri Dec 25 13:37:25 2009 From: evenson at panix.com (Mark Evenson) Date: Fri, 25 Dec 2009 21:37:25 -0000 Subject: [MacPorts] #20904: sbcl 1.0.29 fails to build on 10.6 In-Reply-To: <064.c507dca80702fa481d02355253179040@macports.org> References: <055.eeb7769bc9bfcd0b8ac2c7f3cafb107a@macports.org> <064.c507dca80702fa481d02355253179040@macports.org> Message-ID: <4B35308E.4050804@panix.com> On 12/24/09 2:34 PM, MacPorts wrote: [?] > Somehow, sometimes the POSIX return values for various tests on the > filesystem return different values then expected. I think the port > itself has compiled ok, and would be okay to install. > > Not sure how to track this down in a reproducible manner. A dim memory came to me in the meantime: fixing the disk permissions via the Apple supplied Disk Utility "Repair Disk Permissions" got the system that this occurred on working again. Could you possibly try this, reporting if it had any effect? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."