From rhwood at mac.com Sat Feb 3 08:00:39 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:39:57 2007 Subject: Recent GNOME ports breakage Message-ID: ALCON: Recently a number of ports required for GNOME programs were broken for PowerPC (G3/4/5) platforms (for about half these ports, this break was from fixing problems on the Intel platform). I am attempting to track down working fixes for these ports and hope to have everything fixed by 10 Feb 07. We apologize for these problems. If anyone has suggestions about how to avoid this situation in the future, other than requiring that maintainers (who are all volunteers) test their ports on both PowerPC and Intel platforms (a requirement that most of us can't afford to meet for both time and money reasons), please feel free to chime in with a suggestion. Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From landonf at macports.org Sat Feb 3 10:46:05 2007 From: landonf at macports.org (Landon Fuller) Date: Tue Oct 9 16:39:57 2007 Subject: Recent GNOME ports breakage In-Reply-To: References: Message-ID: On Feb 3, 2007, at 8:00 AM, Randall Wood wrote: > ALCON: > > Recently a number of ports required for GNOME programs were broken > for PowerPC (G3/4/5) platforms (for about half these ports, this > break was from fixing problems on the Intel platform). I am > attempting to track down working fixes for these ports and hope to > have everything fixed by 10 Feb 07. > > We apologize for these problems. > > If anyone has suggestions about how to avoid this situation in the > future, other than requiring that maintainers (who are all > volunteers) test their ports on both PowerPC and Intel platforms (a > requirement that most of us can't afford to meet for both time and > money reasons), please feel free to chime in with a suggestion. Did you rebuild all of the affected components? Nearly all of the changes added explicit dependencies on MacPorts-provided libraries, to prevent the symbol duplication that required compiler flags that broke Intel builds. It's possible that with remaining libraries hauling in duplicate symbols on your system, the new compiler flags broke in new and interesting ways. -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070203/b921dd72/PGP.bin From landonf at macports.org Sat Feb 3 11:08:15 2007 From: landonf at macports.org (Landon Fuller) Date: Tue Oct 9 16:39:57 2007 Subject: liboil fails to build/upgrade In-Reply-To: <2ED38E48-AAB1-4924-B546-B91F747ACEFB@gmail.com> References: <56900335-3127-4363-B5A4-6745B06A6F0E@macports.org> <90F829DC-3527-4940-8895-57BE410FB8EF@gmail.com> <481216C8-1369-4110-B27B-4A9DFC5C6646@austin.rr.com> <4190FFF4-4BA6-4CB1-A19C-5FFB245ADF04@macports.org> <2ED38E48-AAB1-4924-B546-B91F747ACEFB@gmail.com> Message-ID: <46C149F6-CE44-48BF-A361-3E47D26ACCA4@macports.org> On Feb 1, 2007, at 10:04 PM, Paul Beard wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Feb 1, 2007, at 9:59 PM, Landon Fuller wrote: > >> What version of gcc / Xcode? > > I was all prepared for an "aha" moment, but I have the same version > on both systems: > > Component versions: DevToolsCore-762.0; DevToolsSupport-764.0 > gcc version 4.0.1 (Apple Computer, Inc. build 5367) I just committed a fix; it tweaks the PowerPC assembly syntax for Apple's assembler. -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070203/3ea58b49/PGP.bin From mww at macports.org Sat Feb 3 14:14:57 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:39:57 2007 Subject: A 1.4 release In-Reply-To: <46d247143d6d0a68e82a124aad7eb806@macports.org> References: <46d247143d6d0a68e82a124aad7eb806@macports.org> Message-ID: On 30.01.2007, at 18:47, Juan Manuel Palacios wrote: > 4) Any other differences between trunk/base and /brances/ > release_1_3, to be integrated into a future release_1_4 branch, > including but not limited to: > -) the unarchive --> archive rollback of my earlier "fix", > performed by Daniel Luke; > -) Kevin Ballard's fast_load improvements; > -) a new portfile.7 man page, I think...? > -) anything else I'm missing...? Anyone care to diff the two code > bases? ;-) > there also is a group-code for python 2.5 now; cheers, -Markus --- Markus W. Weissmann http://www.mweissmann.de/ From jmpp at macports.org Sat Feb 3 17:11:09 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: Default svn properties Message-ID: <79a93353522e1eb10336596f47059243@macports.org> Hey everybody! I've been mailed privately concerning the log in one of my recent commits to our repo (r21682), so I guess I was successful at catching people's eyes ;-) I do know about svn pre and post commit hooks, but I'm not that well versed in the matter, I'm just learning as I go along. So I'd like to ask everyone for some help since we seem to have some pretty experienced users here. Mark suggested publishing an officially recommended .subversion/config file (most likely to our wiki), whereas Rolf spoke about a pre-commit hook. I believe we should use both options to both ensure we get everything we need in any given commit (.subversion/config file) and that we constantly remind our committers of our requirements if for any reason they happen to make an improper commit from a location without an appropriate conf file (pre-commit hook): the latter should check if all the properties we ask for are met for Portfiles and patchfiles upon commit, though we'd have to discuss how to properly recognize every single way to possibly name a patchfile; we could also toss in there checks for mime types and execute bits, if appropriate. Please discuss and make your recommendations, and if anyone is willing to do the writing, great! I can coordinate with kvv getting the pre-commit hook installed where we need it. Thanks to all for your help! Regards,... -jmpp From jmpp at macports.org Sun Feb 4 01:29:49 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: A 1.4 release In-Reply-To: References: <46d247143d6d0a68e82a124aad7eb806@macports.org> Message-ID: <081c8b24fed007d8907e4483acd18ded@macports.org> On Jan 30, 2007, at 1:56 PM, Mark Duling wrote: > Juan Manuel Palacios on Tuesday, January 30, 2007 > at > 9:47 AM -0800 wrote: >> 4) Any other differences between trunk/base and /brances/release_1_3, >> to be integrated into a future release_1_4 branch, including but not >> limited to: >> -) the unarchive --> archive rollback of my earlier "fix", performed >> by Daniel Luke; >> -) Kevin Ballard's fast_load improvements; >> -) a new portfile.7 man page, I think...? > > Hi Juan! Hey Mark! Nice to be back and see you're still with us! > > Yes, a new portfile.7 man page is ready and attached here. > > http://trac.macosforge.org/projects/macports/ticket/4905 Thanks for this, I'll review it when I first get a chance and will commit it to base. > > There are some other manpage additions/enhancements in trac I might be > able to get done before 1.4, depending on when that happens. Well, it turns out we're still rather early in the game, so I don't see why we shouldn't wait for your enhancements to be ready. Are you working with any ETA? > Do manpage > enhancements get added to HEAD so they just get automatically rolled > into > the next release? Or do they have to be explicitly added to a new > release > when that occurs? I'm planning on cutting a macports_1_4 branch off trunk to make the release (that is, no need to commit to trunk and then merge to the current release branch, darwinports_1_3), so anything new should be added there (trunk) and thus it'll be included in the release automatically whenever we branch. Let me know if you have any questions. > > Mark > Regards,... -jmpp From jmpp at macports.org Sun Feb 4 02:15:12 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: Defaulting --tclpackage to be inside of --prefix In-Reply-To: <45BFDDCE.70509@orcaware.com> References: <45BFDDCE.70509@orcaware.com> Message-ID: <95c2161374e9715f63f2f08cb883f2f0@macports.org> On Jan 30, 2007, at 8:07 PM, Blair Zajac wrote: > If you don't specify --tclpackage, then it may end up being > /Library/Tcl or /System/Library/Tcl. > > I sometimes do multiple installs of MacPorts on the same box and it > would be nice to have each MacPorts install keep its files in its own > prefix. Also, if you wish to tar up an installed MacPorts, you don't > also have to find stuff in /Library or /System. > > So can we change the default to be something like > $prefix/lib/tcl/macports? I'm not sure what the original rationale to choose /System/Library/Tcl (Jaguar) and /Library/Tcl (panther) to install the (at the time) DarwinPorts Tcl package was and if its still mandatory going forward (cf. Leopard), so here's hoping Landon can help us and shed some light on the matter. That put aside, I would be a bit hesitant to change the default value of such a crucial part of a MacPorts installation, not too sure what implications that might have for users who are upgrading rather than installing from scratch. Landon...? Basically we figure that a user experienced enough to need more than one installation will also be savvy enough to look for the configure script and leverage the flexibility it provides. Now.. that last concern being said, I do personally like the idea of having as much as possible contained in ${prefix}, so I would support the change if it happens to be a safe one. > > Regards, > Blair Regards,.... -jmpp > > -- > Blair Zajac, Ph.D. > > http://www.orcaware.com/svn/ > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From jmpp at macports.org Sun Feb 4 02:22:07 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: A 1.4 release In-Reply-To: <3BAD00A9-803B-479E-A2A0-9AE510BACD32@macports.org> References: <46d247143d6d0a68e82a124aad7eb806@macports.org> <3BAD00A9-803B-479E-A2A0-9AE510BACD32@macports.org> Message-ID: <82d6d44500704580ba5b3d79cf4fa2ae@macports.org> On Jan 31, 2007, at 1:08 AM, Kevin Ballard wrote: > Ok, this has been addressed in?r21621. Woot, great, thanks for this! Jotted down on the 1.4 ChangeLog I'll be committing to trunk soon. -jmpp > > On Jan 30, 2007, at 12:47 PM, Juan Manuel Palacios wrote: > >> 3) The addition of a MacPorts mirror list in the same file with a >> starting single entry pointing to a distfiles/ (or any other better >> idea) location in our svn repo, where we can start loading selected >> distfiles for projects missing them at their main sites. Such list >> could pave the way for a future MacPorts mirroring system, as adding >> new entries to it would be transparent to users and Portfiles, the >> latter only having to use "master_sites macports:foo:bar" to leverage >> our mirrors just as they currently do SourceForge's; > > --? > Kevin Ballard > http://kevin.sb.org > eridius@macports.org > http://www.tildesoft.com > > > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From jmpp at macports.org Sun Feb 4 02:26:25 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: A 1.4 release In-Reply-To: <21ACE595-39EB-42AB-A818-C207BC29AB0C@kallisys.net> References: <46d247143d6d0a68e82a124aad7eb806@macports.org> <21ACE595-39EB-42AB-A818-C207BC29AB0C@kallisys.net> Message-ID: On Jan 31, 2007, at 1:17 AM, Paul Guyot wrote: > > On 31 janv. 07, at 02:47, Juan Manuel Palacios wrote: > >> -) anything else I'm missing...? Anyone care to diff the two code >> bases? ;-) > > Diffing should definitely be done. I can't do it for the next three > weeks, though. I'll diff trunk and the release_1_3 branch (I incorrectly called it darwinports_1_3 in an earlier post) to see what else is new from the latest release, but as I'm planning to cut a fresh branch off trunk for 1.4 I don't think it'll be that crucial for other than the ChangeLog (that is, of course, assuming everything is working dandy on trunk ;-). > > There is also the ruby port group changes that currently make many > ports only compatible with HEAD. Did you author the group? Do you happen to know in what revision it was committed? > > Paul > Thanks for the information Paul! Regards,... -jmpp From pguyot at kallisys.net Sun Feb 4 03:03:15 2007 From: pguyot at kallisys.net (Paul Guyot) Date: Tue Oct 9 16:39:57 2007 Subject: A 1.4 release In-Reply-To: References: <46d247143d6d0a68e82a124aad7eb806@macports.org> <21ACE595-39EB-42AB-A818-C207BC29AB0C@kallisys.net> Message-ID: On Feb 4, 2007, at 19:26, Juan Manuel Palacios wrote: >> There is also the ruby port group changes that currently make many >> ports only compatible with HEAD. > > Did you author the group? Do you happen to know in what revision > it was committed? I just authored some changes: Paul From mark.duling at biola.edu Sun Feb 4 03:25:26 2007 From: mark.duling at biola.edu (Mark Duling) Date: Tue Oct 9 16:39:57 2007 Subject: A 1.4 release In-Reply-To: <081c8b24fed007d8907e4483acd18ded@macports.org> References: <081c8b24fed007d8907e4483acd18ded@macports.org> Message-ID: Juan Manuel Palacios on Sunday, February 4, 2007 at 1:29 AM -0800 wrote: >Hey Mark! Nice to be back and see you're still with us! Likewise! > Thanks for this, I'll review it when I first get a chance and will >commit it to base. > >> >> There are some other manpage additions/enhancements in trac I might be >> able to get done before 1.4, depending on when that happens. > > Well, it turns out we're still rather early in the game, so I don't >see why we shouldn't wait for your enhancements to be ready. Are you >working with any ETA? No, but I was referring for now was to clear out the tickets in category doc. -This is finished, pending review: http://trac.macosforge.org/projects/macports/ticket/4905 -I can do these pretty quickly: document binpath - http://trac.macosforge.org/projects/macports/ticket/6880 modify installer README - http://trac.macosforge.org/projects/macports/ticket/11010 -This one I need some help with. Where is portfile.1? I do not see that. Is that an error? http://trac.macosforge.org/projects/macports/ticket/10840 -And these I'll look at more closely soon and see if it is man pages that need updating or just web documentation, perhaps the latter. I've not looked closely at them yet. Any opinions are welcome. http://trac.macosforge.org/projects/macports/ticket/8822 http://trac.macosforge.org/projects/macports/ticket/10877 -This is the only one that I might have to defer this to after 1.4, though I may be able to get it. I want to try writing it in DocBook and transforming to a manpage. If I should do that can the source xml be stored also for future revisions? Or would that be a problem? http://trac.macosforge.org/projects/macports/ticket/5275 > >> Do manpage >> enhancements get added to HEAD so they just get automatically rolled >> into >> the next release? Or do they have to be explicitly added to a new >> release >> when that occurs? > > I'm planning on cutting a macports_1_4 branch off trunk to make the >release (that is, no need to commit to trunk and then merge to the >current release branch, darwinports_1_3), so anything new should be >added there (trunk) and thus it'll be included in the release >automatically whenever we branch. Let me know if you have any >questions. I see. That explains it. Thanks. Mark From mww at macports.org Sun Feb 4 05:21:20 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:39:57 2007 Subject: Spring-cleaning @opendarwin.org addresses Message-ID: Hi folks, to clean up some stale maintainerships, we will do a mass-update to Portfiles on 01. march and replace all @opendarwin.org maintainers with the nomaintainer@ tag. Most ports that still have @opendarwin.org maintainers are probably abandoned and for those who are not: You have one month left to (i) replace the address with your new (probably @macports.org) address or (ii) complain that you'll stick with your @opendarwin.org address and we should not nuke your maintainerships. In the meantime, @opendarwin.org maintainerships are not free to be nuked, you may take over maintainership of ports AFTER the reset to nomaintainer@. salut, -Markus --- Markus W. Weissmann http://www.mweissmann.de/ http://www.macports.org/ From yves at macports.org Sun Feb 4 09:11:58 2007 From: yves at macports.org (Yves de Champlain) Date: Tue Oct 9 16:39:57 2007 Subject: A 1.4 release In-Reply-To: <82d6d44500704580ba5b3d79cf4fa2ae@macports.org> References: <46d247143d6d0a68e82a124aad7eb806@macports.org> <3BAD00A9-803B-479E-A2A0-9AE510BACD32@macports.org> <82d6d44500704580ba5b3d79cf4fa2ae@macports.org> Message-ID: Le 07-02-04 ? 05:22, Juan Manuel Palacios a ?crit : > > On Jan 31, 2007, at 1:08 AM, Kevin Ballard wrote: > >> Ok, this has been addressed in r21621. > > Woot, great, thanks for this! Jotted down on the 1.4 ChangeLog > I'll be committing to trunk soon. Ready for 1.4, I hope ... https://svn.macosforge.org/projects/macports/ticket/11331 yves From rhwood at mac.com Sun Feb 4 11:24:31 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:39:57 2007 Subject: GNOME on MacPorts Weekly Report Message-ID: <4F319972-12E0-4074-9AF1-815BE0A17DB0@mac.com> ALCON: GNOME released version 2.16.3 this week. We'll be catching up over the week. Progress will be tracked at http://homepage.mac.com/rhwood/ macports/gnome.html Reports indicate that GNOME finally builds successfully on Intel machines. Go by Landon a beer for having made that work. Port liboil and port control-center do not seem to exactly get along on powerpc machines. I hope to be able to fix this relatively rapidly. I hope also to be able to add port java-gnome at the 4.0.x version sometime soon as well. Two patches have already been submitted back to the project. Unless there is some great demand, I'm going to ignore java-gnome at earlier versions. I know that over the past quarter I have been slack about sending this report (or even doing anything with MacPorts), but I do believe that I will be able keep up the project and port maintenance most weeks from this point forward. Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From 0x62_0x6c_0x62 at pobox.com Sun Feb 4 23:58:21 2007 From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn) Date: Tue Oct 9 16:39:57 2007 Subject: Spring-cleaning @opendarwin.org addresses In-Reply-To: References: Message-ID: On Feb 4, 2007, at 6:21 AM, Weissmann Markus wrote: > Hi folks, > (Welcome back) > to clean up some stale maintainerships, we will do a mass-update to > Portfiles on 01. march and replace all @opendarwin.org maintainers > with the nomaintainer@ tag. > Most ports that still have @opendarwin.org maintainers are probably > abandoned and for those who are not: You have one month left to (i) > replace the address with your new (probably @macports.org) address > or (ii) complain that you'll stick with your @opendarwin.org > address and we should not nuke your maintainerships. > Ticket 11336 () updates all of mine to @macports. Thanks, Bryan > In the meantime, @opendarwin.org maintainerships are not free to be > nuked, you may take over maintainership of ports AFTER the reset to > nomaintainer@. > > > salut, > > -Markus > > --- > Markus W. Weissmann > http://www.mweissmann.de/ > http://www.macports.org/ > From jmpp at macports.org Mon Feb 5 00:06:42 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: Spring-cleaning @opendarwin.org addresses In-Reply-To: References: Message-ID: <04c2f06781918ee6e8271179d7dc89ba@macports.org> Hey Bryan! On Feb 5, 2007, at 3:58 AM, Bryan Blackburn wrote: > > Ticket 11336 > () updates > all of mine to @macports. > > Thanks, I can commit this for you if you like... but just out of a curiosity, why don't you? Are you having problems with your svn commit bit? -jmpp > > Bryan From jmpp at macports.org Mon Feb 5 02:26:08 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: A 1.4 release In-Reply-To: References: <46d247143d6d0a68e82a124aad7eb806@macports.org> <3BAD00A9-803B-479E-A2A0-9AE510BACD32@macports.org> <82d6d44500704580ba5b3d79cf4fa2ae@macports.org> Message-ID: <8793cc4c14490cbecab16fe248630684@macports.org> On Feb 4, 2007, at 1:11 PM, Yves de Champlain wrote: > > Le 07-02-04 ? 05:22, Juan Manuel Palacios a ?crit : > >> >> On Jan 31, 2007, at 1:08 AM, Kevin Ballard wrote: >> >>> Ok, this has been addressed in r21621. >> >> Woot, great, thanks for this! Jotted down on the 1.4 ChangeLog I'll >> be committing to trunk soon. > > Ready for 1.4, I hope ... Other than pending review, I don't see why your additions shouldn't be included ;-) > > https://svn.macosforge.org/projects/macports/ticket/11331 I'll read it and try to get them in ASAP! > > yves Regards,... -jmpp From landonf at macports.org Mon Feb 5 09:56:17 2007 From: landonf at macports.org (Landon Fuller) Date: Tue Oct 9 16:39:57 2007 Subject: Defaulting --tclpackage to be inside of --prefix In-Reply-To: <95c2161374e9715f63f2f08cb883f2f0@macports.org> References: <45BFDDCE.70509@orcaware.com> <95c2161374e9715f63f2f08cb883f2f0@macports.org> Message-ID: <74810822-8AF5-4A31-8AB4-AA9D221354F2@macports.org> On Feb 4, 2007, at 02:15, Juan Manuel Palacios wrote: > > On Jan 30, 2007, at 8:07 PM, Blair Zajac wrote: > >> If you don't specify --tclpackage, then it may end up being / >> Library/Tcl or /System/Library/Tcl. >> >> I sometimes do multiple installs of MacPorts on the same box and >> it would be nice to have each MacPorts install keep its files in >> its own prefix. Also, if you wish to tar up an installed >> MacPorts, you don't also have to find stuff in /Library or /System. >> >> So can we change the default to be something like $prefix/lib/tcl/ >> macports? > > I'm not sure what the original rationale to choose /System/Library/ > Tcl (Jaguar) and /Library/Tcl (panther) to install the (at the > time) DarwinPorts Tcl package was and if its still mandatory going > forward (cf. Leopard), so here's hoping Landon can help us and shed > some light on the matter. > > That put aside, I would be a bit hesitant to change the default > value of such a crucial part of a MacPorts installation, not too > sure what implications that might have for users who are upgrading > rather than installing from scratch. Landon...? Basically we figure > that a user experienced enough to need more than one installation > will also be savvy enough to look for the configure script and > leverage the flexibility it provides. > > Now.. that last concern being said, I do personally like the idea > of having as much as possible contained in ${prefix}, so I would > support the change if it happens to be a safe one. 'darwinports1.0' was installed external to ${prefix} for the purpose of supporting external applications, such as the original Ports Manager.app, that would otherwise be unable to find the darwinports libraries. I tend to agree that as long as the configuration nob (-- tclpackage) is available, we should probably stick to /Library/Tcl as the default. -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070205/851b8cc7/PGP.bin From jmpp at macports.org Mon Feb 5 16:00:03 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: [21762] trunk/base/src/port1.0/resources/group/xcode-1.0.tcl In-Reply-To: <20070205232058.951AB49BEF8@cvs.opensource.apple.com> References: <20070205232058.951AB49BEF8@cvs.opensource.apple.com> Message-ID: <99b9b75964f398d6a92df30fd59fc1da@macports.org> On Feb 5, 2007, at 7:20 PM, source_changes@macosforge.org wrote: > Revision > 21762 > Author > eridius@macports.org > Date > 2007-02-05 15:20:58 -0800 (Mon, 05 Feb 2007) > > Log Message > Add OBJROOT and SYMROOT args to xcodebuild to ensure it builds within > the work dir. > Redefine destroot.destdir instead of passing DSTROOT manually to avoid > the useless DESTDIR arg to xcodebuild; also, it's cleaner this way > > Modified Paths > ? trunk/base/src/port1.0/resources/group/xcode-1.0.tcl Hey Kevin! I just checked in a revised base/doc/portgroup.7 file to add Yves' gnustep PortGroup documentation, you think you could please hack on it to adapt the Xcode PortGroup documentation to the changes your commit here implies, if any? Thanks! -jmpp From jmpp at macports.org Mon Feb 5 16:02:34 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: A 1.4 release In-Reply-To: References: <46d247143d6d0a68e82a124aad7eb806@macports.org> <3BAD00A9-803B-479E-A2A0-9AE510BACD32@macports.org> <82d6d44500704580ba5b3d79cf4fa2ae@macports.org> Message-ID: On Feb 4, 2007, at 1:11 PM, Yves de Champlain wrote: > > Le 07-02-04 ? 05:22, Juan Manuel Palacios a ?crit : > >> >> On Jan 31, 2007, at 1:08 AM, Kevin Ballard wrote: >> >>> Ok, this has been addressed in r21621. >> >> Woot, great, thanks for this! Jotted down on the 1.4 ChangeLog I'll >> be committing to trunk soon. > > Ready for 1.4, I hope ... > > https://svn.macosforge.org/projects/macports/ticket/11331 > > yves > Committed in r21764, thanks! -jmpp From jmpp at macports.org Mon Feb 5 16:03:20 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: A 1.4 release In-Reply-To: References: <46d247143d6d0a68e82a124aad7eb806@macports.org> <21ACE595-39EB-42AB-A818-C207BC29AB0C@kallisys.net> Message-ID: <6a0edc5502b475d0450b2fe8566f4fcb@macports.org> On Feb 4, 2007, at 7:03 AM, Paul Guyot wrote: > > On Feb 4, 2007, at 19:26, Juan Manuel Palacios wrote: > >>> There is also the ruby port group changes that currently make many >>> ports only compatible with HEAD. >> >> Did you author the group? Do you happen to know in what revision it >> was committed? > > I just authored some changes: > > port1.0/resources/group/ruby-1.0.tcl> > > Paul > Thanks for pointing that out, it's now properly annotated in the ChangeLog. -jmpp From jmpp at macports.org Mon Feb 5 16:34:00 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: SourceForge in mirror_sites.tcl In-Reply-To: <89D40965-8304-4C23-AE66-3CF7B884E3A2@macports.org> References: <89D40965-8304-4C23-AE66-3CF7B884E3A2@macports.org> Message-ID: <7c81b7c580726d8bd9d018f245c6b840@macports.org> Hello Ross! I wanted to inform you on behalf of the MacPorts team that our 1.4 upcoming release will use sf's new redirector mechanism (the fix is already in our sources, awaiting release), thanks for the heads-up! However, I'm a bit concerned about all our sf based downloads failing in case that main site is down, as you point out as a possible scenario in your message below. I like the idea of keeping a few (2? 3? ...5?) backup mirrors to prevent this from happening, but before adding them back I'd like to ask you which ones you would recommend; and while at it, also how many ;-) Thanks again for your help! Regards,... -jmpp >> From: Ross David Turk >> Date: January 5, 2007 3:58:05 PM EST >> To: macports-users@lists.macosforge.org >> Subject: SourceForge in mirror_sites.tcl >> >> Hey folks! >> >> I noticed that you guys are fetching SourceForge files from the >> mirrors directly, and did a little grepping. I'm not a >> macports/darwinports expert (or even a heavy user), but I think that >> it's set in mirror_sites.tcl: >> >> set portfetch::mirror_sites::sites(sourceforge) { >> ? http://easynews.dl.sourceforge.net/ >> ? http://surfnet.dl.sourceforge.net/ >> ? http://belnet.dl.sourceforge.net/ >> ? http://heanet.dl.sourceforge.net/ >> ? http://ovh.dl.sourceforge.net/ >> ? http://internap.dl.sourceforge.net/ >> ? http://jaist.dl.sourceforge.net/ >> ? http://umn.dl.sourceforge.net/ >> ? http://kent.dl.sourceforge.net/ >> ? http://mesh.dl.sourceforge.net/ >> ? http://ufpr.dl.sourceforge.net/ >> ? http://nchc.dl.sourceforge.net/ >> ? http://switch.dl.sourceforge.net/ >> ? http://superb-west.dl.sourceforge.net/ >> } >> >> In the old days, until about a month ago, users accessing a file like >> http://prdownloads.sourceforge.net/gaim/gaim-1.5.0.exe would be sent >> to a mirror selection page. Recently, we replaced that page with a >> more intelligent download redirector. >> >> I would love to see you change the snippet above to: >> >> set portfetch::mirror_sites::sites(sourceforge) { >> ? http://downloads.sourceforge.net/ >> } >> >> Doing this should provide these benefits: >> >> 1) You won't have to manage the mirror list as mirrors are added or >> removed. >> 2) You can ensure that the mirror you're sent to has the file you're >> looking for. Not all mirrors have all files. >> 3) Your users will probably get a faster download due to the >> geolocation. >> 4) SourceForge projects will get fair download statistics - going to >> the mirror directly bypasses our statistics hooks, so your downloads >> haven't been counting towards their SourceForge.net project activity >> rating. >> >> The risk is, of course, that if the SF.net website goes down, so will >> your ability to get these files. Perhaps you could list >> http://downloads.sourceforge.net first and keep a few other ones in >> there as a backup in case we're down? Does port try to fetch from the >> mirrors using the listed order? >> >> Let me know if you have any questions.. :) >> >> Thanks! >> Ross >> >> -- >> Ross David Turk >> SourceForge.net Community Manager > From jmpp at macports.org Mon Feb 5 17:53:33 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: SourceForge in mirror_sites.tcl In-Reply-To: References: <89D40965-8304-4C23-AE66-3CF7B884E3A2@macports.org> <7c81b7c580726d8bd9d018f245c6b840@macports.org> Message-ID: On Feb 5, 2007, at 9:33 PM, Ross Turk wrote: > I think that depends on the geographical breakdown of your users.? If > you have mostly users in the US, I would choose easynews (AZ), superb > (VA), and umn (MN).??If your audience skews global, you should > probably pick easynews (US), kent (UK), ufpr (Brazil), and jaist > (Japan). Hey Ross! Yeah, I think it's safe to assume we have users all around the globe (/me inflates chest! ;-), so I chose your worldwide distribution. Our SourceForge mirrors list will look like this when MacPorts 1.4 is released: set portfetch::mirror_sites::sites(sourceforge) { http://downloads.sourceforge.net/ http://easynews.dl.sourceforge.net/ http://ufpr.dl.sourceforge.net/ http://kent.dl.sourceforge.net/ http://jaist.dl.sourceforge.net } Do inform/warn me if I need to make any additins/corrections! > > Thanks for doing this!? I appreciate it. :) Thanks to you for the info, toggling the mirrors list manually whenever something happened to a particular mirror was becoming a bit of a problem ! > > Thx, > Ross > -- > Ross Turk, Community Manager > -jmpp From eridius at macports.org Mon Feb 5 20:06:10 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:39:57 2007 Subject: [21762] trunk/base/src/port1.0/resources/group/xcode-1.0.tcl In-Reply-To: <99b9b75964f398d6a92df30fd59fc1da@macports.org> References: <20070205232058.951AB49BEF8@cvs.opensource.apple.com> <99b9b75964f398d6a92df30fd59fc1da@macports.org> Message-ID: <9DF080F6-A191-40DA-847E-867C789465D5@macports.org> The changes here don't affect usage at all. The SYMROOT/OBJROOT just ensure that the build products end up in the work directory, as they do by default (but can be changed in Xcode global prefs). The destroot.destdir thing just cleans up the command line string a bit. No usage-related changes in here, no sirree! On Feb 5, 2007, at 7:00 PM, Juan Manuel Palacios wrote: > Hey Kevin! I just checked in a revised base/doc/portgroup.7 file to > add Yves' gnustep PortGroup documentation, you think you could > please hack on it to adapt the Xcode PortGroup documentation to the > changes your commit here implies, if any? -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070205/56dedd91/attachment.html From jmpp at macports.org Mon Feb 5 21:19:06 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: [21762] trunk/base/src/port1.0/resources/group/xcode-1.0.tcl In-Reply-To: <9DF080F6-A191-40DA-847E-867C789465D5@macports.org> References: <20070205232058.951AB49BEF8@cvs.opensource.apple.com> <99b9b75964f398d6a92df30fd59fc1da@macports.org> <9DF080F6-A191-40DA-847E-867C789465D5@macports.org> Message-ID: <360ac10caac6ab3793a746f7fafdab62@macports.org> On Feb 6, 2007, at 12:06 AM, Kevin Ballard wrote: > The changes here don't affect usage at all. The SYMROOT/OBJROOT just > ensure that the build products end up in the work directory, as they > do by default (but can be changed in Xcode global prefs). The > destroot.destdir thing just cleans up the command line string a bit. > No usage-related changes in here, no sirree! > OK, great! On a side note, I just annotated your improvements in the ChangeLog. -jmpp > On Feb 5, 2007, at 7:00 PM, Juan Manuel Palacios wrote: > >> Hey Kevin! I just checked in a revised base/doc/portgroup.7 file to >> add Yves' gnustep PortGroup documentation, you think you could please >> hack on it to adapt the Xcode PortGroup documentation to the changes >> your commit here implies, if any? > > --? > Kevin Ballard > http://kevin.sb.org > eridius@macports.org > http://www.tildesoft.com > > > From jmpp at macports.org Mon Feb 5 21:54:18 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:57 2007 Subject: svn macports - can not find pextib In-Reply-To: References: Message-ID: <400765bf92b33860c9195873f953e647@macports.org> Hi Gao! If you may, could you please open a ticket with a full description of the steps you took to trigger the error? Thanks for the report! -jmpp On Jan 30, 2007, at 8:12 AM, CHENG Gao wrote: > Sorry if this problem was reported already. If not, I'll report my > finding. > > With fresh installation of svn MacPorts (1.40), sudo port sync or port > selfupdate reports error message that pextlib 1.0 can not be found. > While 1.3.2 works well. > > This problem wont occur if you install 1.40 over existed version. > > It's with svn source of yesterday. > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From vincent-opdarw at vinc17.org Wed Feb 7 03:55:47 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:39:57 2007 Subject: portindex output depends on the locales Message-ID: <20070207115547.GT21558@prunille.vinc17.org> Hi, The output of the portindex commands depends on whether the character set is UTF-8 or, e.g., ISO-8859-1, due to non-ASCII characters in a description: the number after the port name seems to contain the number of characters instead of the number of bytes. For instance, I get: stardict-xmlittre 310 in ISO-8859-1, but stardict-xmlittre 308 in UTF-8. Is this difference important? -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From 0x62_0x6c_0x62 at pobox.com Fri Feb 9 00:04:01 2007 From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn) Date: Tue Oct 9 16:39:57 2007 Subject: Spring-cleaning @opendarwin.org addresses In-Reply-To: <04c2f06781918ee6e8271179d7dc89ba@macports.org> References: <04c2f06781918ee6e8271179d7dc89ba@macports.org> Message-ID: On Feb 5, 2007, at 1:06 AM, Juan Manuel Palacios wrote: > > Hey Bryan! > > On Feb 5, 2007, at 3:58 AM, Bryan Blackburn wrote: > >> >> Ticket 11336 (> 11336>) updates all of mine to @macports. >> >> Thanks, > > > I can commit this for you if you like... but just out of a > curiosity, why don't you? Are you having problems with your svn > commit bit? > Thanks for committing those updates Juan. As far as why I don't, I never requested svn commit rights on the DP->MP switch, due to my now- miniscule port count and general lack of time for things like ticket handling. Bryan > > -jmpp > > >> >> Bryan > From eridius at macports.org Fri Feb 9 08:50:04 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:39:58 2007 Subject: Spacing issues Message-ID: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> The spacing in MacPorts is a bit non-standard. We have mostly tabs, but there's a bunch of spaces in there as well, and it causes for some interesting indentation. I propose that all future edits be standardized at either 2-width or 4-width soft tabs (as in, spaces). I'd even be willing to convert all existing tcl files to use spaces instead of tabs in one batch, though that could leave indentation issues (but those can be fixed by hand the next time the file is edited). Is there any reason to keep tabs? Or any other comments? -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070209/835cee4c/attachment.html From jberry at macports.org Fri Feb 9 08:55:22 2007 From: jberry at macports.org (James Berry) Date: Tue Oct 9 16:39:58 2007 Subject: Spacing issues In-Reply-To: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> References: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> Message-ID: <77F10E6A-5273-43DE-BDA3-51E566875ED3@macports.org> On Feb 9, 2007, at 8:50 AM, Kevin Ballard wrote: > The spacing in MacPorts is a bit non-standard. We have mostly tabs, > but there's a bunch of spaces in there as well, and it causes for > some interesting indentation. > > I propose that all future edits be standardized at either 2-width > or 4-width soft tabs (as in, spaces). I'd even be willing to > convert all existing tcl files to use spaces instead of tabs in one > batch, though that could leave indentation issues (but those can be > fixed by hand the next time the file is edited). > > Is there any reason to keep tabs? Or any other comments? > Personally I prefer anarchy over regulation. Other than a lack of consistency, has anybody experienced real problems with the way things are? (Yes, I understand that with tabs spacing can get a bit wonky if one person's editor is set to 4 characters per tab, while another has theirs at 8 spaces, and that spacing when files are cat'd to a terminal at 8 spaces can look funny too... but is consistency worth the price of conformity?) James > -- > Kevin Ballard > http://kevin.sb.org > eridius@macports.org > http://www.tildesoft.com > > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070209/c4838293/attachment.html From ryandesign at macports.org Fri Feb 9 09:01:51 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:39:58 2007 Subject: Spacing issues In-Reply-To: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> References: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> Message-ID: <9D32A8FB-CBED-4678-AB0E-8FDB18A21D85@macports.org> On Feb 9, 2007, at 10:50, Kevin Ballard wrote: > The spacing in MacPorts is a bit non-standard. We have mostly tabs, > but there's a bunch of spaces in there as well, and it causes for > some interesting indentation. > > I propose that all future edits be standardized at either 2-width > or 4-width soft tabs (as in, spaces). I'd even be willing to > convert all existing tcl files to use spaces instead of tabs in one > batch, though that could leave indentation issues (but those can be > fixed by hand the next time the file is edited). > > Is there any reason to keep tabs? Or any other comments? Is there any reason why we shouldn't - have tabs at the beginnings of lines to provide indentation - use spaces within a line when we want to do something like align columns That would seem the most logical solution to me. Using only spaces seems not so good to me, because - spaces uses 2 or 4 times as much disk space as a tab - spaces need 2 or 4 times as many presses on the delete key as a tab to remove in my editor - I can't use my editor's tab width setting to see the amount of indentation I want to see From eridius at macports.org Fri Feb 9 09:02:18 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:39:58 2007 Subject: Spacing issues In-Reply-To: <77F10E6A-5273-43DE-BDA3-51E566875ED3@macports.org> References: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> <77F10E6A-5273-43DE-BDA3-51E566875ED3@macports.org> Message-ID: <12904CCE-A41F-416D-B760-7BB8F41C8483@macports.org> The lack of consistent indentation consistently causes me to misread code. On Feb 9, 2007, at 11:55 AM, James Berry wrote: > Personally I prefer anarchy over regulation. > > Other than a lack of consistency, has anybody experienced real > problems with the way things are? (Yes, I understand that with tabs > spacing can get a bit wonky if one person's editor is set to 4 > characters per tab, while another has theirs at 8 spaces, and that > spacing when files are cat'd to a terminal at 8 spaces can look > funny too... but is consistency worth the price of conformity?) -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070209/a86d8ca6/attachment.html From eridius at macports.org Fri Feb 9 09:06:21 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:39:58 2007 Subject: Spacing issues In-Reply-To: <9D32A8FB-CBED-4678-AB0E-8FDB18A21D85@macports.org> References: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> <9D32A8FB-CBED-4678-AB0E-8FDB18A21D85@macports.org> Message-ID: <8D6CC819-82B4-4B7F-AC10-0688B92019A6@macports.org> On Feb 9, 2007, at 12:01 PM, Ryan Schmidt wrote: > Is there any reason why we shouldn't > > - have tabs at the beginnings of lines to provide indentation > - use spaces within a line when we want to do something like align > columns > > That would seem the most logical solution to me. Because different editors use different widths for tabs. And people who use editors that don't visually show tabs may not realize that it's tabs and not spaces (I assume that's why there are plenty of lines that start with a few tabs and then have 4 spaces after that). > Using only spaces seems not so good to me, because > > - spaces uses 2 or 4 times as much disk space as a tab Do you honestly believe this is a problem? I'm sure I can spare the few extra kB it might take. > - spaces need 2 or 4 times as many presses on the delete key as a > tab to remove in my editor Then you need a better editor. Any modern editor should know how soft tabs work and allow you to delete them just like tabs. What editor are you using? > - I can't use my editor's tab width setting to see the amount of > indentation I want to see Is this ever actually a problem? lines should not be indented so much that 4-width soft tabs cause it to go off the end of the line. And besides, given the current state of indentation (mixture of tabs and spaces), this isn't viable with current source. -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070209/0d6fceb7/attachment.html From ryandesign at macports.org Fri Feb 9 09:39:20 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:39:58 2007 Subject: Spacing issues In-Reply-To: <8D6CC819-82B4-4B7F-AC10-0688B92019A6@macports.org> References: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> <9D32A8FB-CBED-4678-AB0E-8FDB18A21D85@macports.org> <8D6CC819-82B4-4B7F-AC10-0688B92019A6@macports.org> Message-ID: <218E50A3-74B5-4FC3-BFC6-13540128F34E@macports.org> On Feb 9, 2007, at 11:06, Kevin Ballard wrote: > On Feb 9, 2007, at 12:01 PM, Ryan Schmidt wrote: > >> Is there any reason why we shouldn't >> >> - have tabs at the beginnings of lines to provide indentation >> - use spaces within a line when we want to do something like align >> columns >> >> That would seem the most logical solution to me. > > Because different editors use different widths for tabs. And people > who use editors that don't visually show tabs may not realize that > it's tabs and not spaces (I assume that's why there are plenty of > lines that start with a few tabs and then have 4 spaces after that). I assume that's due to the stupid setting available in emacs or vi or whatever editor it is that actually encourages that behavior. The one where they've said "We want to indent to 4-space tabs. However, the editor is configured to print 8 spaces for a tab. Therefore, when we want to indent one level, we will use 4 spaces, and when we want to indent 2 levels, we will use one tab, and when we want to indent three levels, we will use one tab and then 4 spaces." And so forth. I'm convinced such an editor setting exists somewhere, because I have seen this nonsense in other projects too, even to the extreme of 2- space indentation. (Indent sequence: 2 spaces, 4 spaces, 6 spaces, one tab, one tab and 2 spaces, etc.) >> Using only spaces seems not so good to me, because >> >> - spaces uses 2 or 4 times as much disk space as a tab > > Do you honestly believe this is a problem? I'm sure I can spare the > few extra kB it might take. No, not really a problem. I would accept extra disk space if this solution brought significant advantages, but I'm saying it brings drawbacks. >> - spaces need 2 or 4 times as many presses on the delete key as a >> tab to remove in my editor > > Then you need a better editor. Any modern editor should know how > soft tabs work and allow you to delete them just like tabs. What > editor are you using? I use TextWrangler, the free sibbling of BBEdit. Also, if I press the Tab key on the keyboard, it inserts a tab character. Even if I could tell the editor to insert spaces instead, I would not configure my editor this way, because that is not how I want to use my editor in every other text file that I edit. Now I'm curious: What editor do other people use to edit their portfiles? >> - I can't use my editor's tab width setting to see the amount of >> indentation I want to see > > Is this ever actually a problem? lines should not be indented so > much that 4-width soft tabs cause it to go off the end of the line. > And besides, given the current state of indentation (mixture of > tabs and spaces), this isn't viable with current source. I'm just saying that you may like 2-space tabs, but I don't. If that's what we standardize on, I'll be unhappy. Someone else may like 3-space tabs, and they'll be unhappy unless we choose that. Why choose at all? Why not let the user choose with their editor's tab width setting? That's what it's for. From eridius at macports.org Fri Feb 9 09:43:59 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:39:58 2007 Subject: Spacing issues In-Reply-To: <218E50A3-74B5-4FC3-BFC6-13540128F34E@macports.org> References: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> <9D32A8FB-CBED-4678-AB0E-8FDB18A21D85@macports.org> <8D6CC819-82B4-4B7F-AC10-0688B92019A6@macports.org> <218E50A3-74B5-4FC3-BFC6-13540128F34E@macports.org> Message-ID: On Feb 9, 2007, at 12:39 PM, Ryan Schmidt wrote: > I assume that's due to the stupid setting available in emacs or vi > or whatever editor it is that actually encourages that behavior. > The one where they've said "We want to indent to 4-space tabs. > However, the editor is configured to print 8 spaces for a tab. > Therefore, when we want to indent one level, we will use 4 spaces, > and when we want to indent 2 levels, we will use one tab, and when > we want to indent three levels, we will use one tab and then 4 > spaces." And so forth. I'm convinced such an editor setting exists > somewhere, because I have seen this nonsense in other projects too, > even to the extreme of 2-space indentation. (Indent sequence: 2 > spaces, 4 spaces, 6 spaces, one tab, one tab and 2 spaces, etc.) I doubt that's the case. I see this in places where there's 2 tabs followed by 4 spaces. Why would somebody have their tabs set to width 8 and then want to indent 4 for a nesting level? That makes no sense. > No, not really a problem. I would accept extra disk space if this > solution brought significant advantages, but I'm saying it brings > drawbacks. Do you view commenting code as a drawback as well? That adds far more disk space than changing tabs to spaces does. The disk space is simply a non-issue. > I use TextWrangler, the free sibbling of BBEdit. > > Also, if I press the Tab key on the keyboard, it inserts a tab > character. Even if I could tell the editor to insert spaces > instead, I would not configure my editor this way, because that is > not how I want to use my editor in every other text file that I edit. Funny, I use soft tabs almost exclusively, and dislike it when I have to switch back to hard tabs just to fit the indentation used by a particular text file. > Now I'm curious: What editor do other people use to edit their > portfiles? Usually TextMate, but sometimes vim. > I'm just saying that you may like 2-space tabs, but I don't. If > that's what we standardize on, I'll be unhappy. Someone else may > like 3-space tabs, and they'll be unhappy unless we choose that. > Why choose at all? Why not let the user choose with their editor's > tab width setting? That's what it's for. Sure, that's what it's for, but it doesn't work. Go look around at the current source. Sure, it's mostly tabs, but I routinely run into spaces mixed among the tabs and it causes indentation problems. There's a reason that software projects often standardize their coding style, including spacing conventions. -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070209/5017eb3d/attachment.html From ryandesign at macports.org Fri Feb 9 09:53:19 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:39:58 2007 Subject: Spacing issues In-Reply-To: References: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> <9D32A8FB-CBED-4678-AB0E-8FDB18A21D85@macports.org> <8D6CC819-82B4-4B7F-AC10-0688B92019A6@macports.org> <218E50A3-74B5-4FC3-BFC6-13540128F34E@macports.org> Message-ID: <9D1ECBFC-65C3-47BE-8068-500826A2FEA6@macports.org> On Feb 9, 2007, at 11:43, Kevin Ballard wrote: > On Feb 9, 2007, at 12:39 PM, Ryan Schmidt wrote: > >> I assume that's due to the stupid setting available in emacs or vi >> or whatever editor it is that actually encourages that behavior. >> The one where they've said "We want to indent to 4-space tabs. >> However, the editor is configured to print 8 spaces for a tab. >> Therefore, when we want to indent one level, we will use 4 spaces, >> and when we want to indent 2 levels, we will use one tab, and when >> we want to indent three levels, we will use one tab and then 4 >> spaces." And so forth. I'm convinced such an editor setting exists >> somewhere, because I have seen this nonsense in other projects >> too, even to the extreme of 2-space indentation. (Indent sequence: >> 2 spaces, 4 spaces, 6 spaces, one tab, one tab and 2 spaces, etc.) > > I doubt that's the case. I see this in places where there's 2 tabs > followed by 4 spaces. Why would somebody have their tabs set to > width 8 and then want to indent 4 for a nesting level? That makes > no sense. It makes no sense to me either, but I have seen it occur, and hadn't come up with another explanation for how it could come about. Perhaps it comes about from one person using an editor that uses tabs, and then someone else who uses an editor that uses spaces. I don't know. >> No, not really a problem. I would accept extra disk space if this >> solution brought significant advantages, but I'm saying it brings >> drawbacks. > > Do you view commenting code as a drawback as well? That adds far > more disk space than changing tabs to spaces does. The disk space > is simply a non-issue. No, if course I don't object to comments, and I meant to say that I would happily accept the extra disk space needed by using only spaces, if using only spaces brought only advantages. However, I had intended to point out in the rest of my email that I see some disadvantages as a result of this practice. >> I use TextWrangler, the free sibbling of BBEdit. >> >> Also, if I press the Tab key on the keyboard, it inserts a tab >> character. Even if I could tell the editor to insert spaces >> instead, I would not configure my editor this way, because that is >> not how I want to use my editor in every other text file that I edit. > > Funny, I use soft tabs almost exclusively, and dislike it when I > have to switch back to hard tabs just to fit the indentation used > by a particular text file. > >> Now I'm curious: What editor do other people use to edit their >> portfiles? > > Usually TextMate, but sometimes vim. > >> I'm just saying that you may like 2-space tabs, but I don't. If >> that's what we standardize on, I'll be unhappy. Someone else may >> like 3-space tabs, and they'll be unhappy unless we choose that. >> Why choose at all? Why not let the user choose with their editor's >> tab width setting? That's what it's for. > > Sure, that's what it's for, but it doesn't work. Go look around at > the current source. Sure, it's mostly tabs, but I routinely run > into spaces mixed among the tabs and it causes indentation problems. > > There's a reason that software projects often standardize their > coding style, including spacing conventions. I agree that standardizing the spacing of a software project can be beneficial. I just want to encourage debate about the specific conventions you're proposing. If we do decide on an indentation convention, then a pre-commit hook in the repository should probably enforce it. One point in favor of your suggestion is that it makes the hook script very easy: if the file contains any tab character at all, it does not conform to your conventions. Writing a hook to verify conformance to my suggestion would be more complicated, though I think not impossible. From rhwood at mac.com Fri Feb 9 19:24:14 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:39:58 2007 Subject: Spacing issues In-Reply-To: <8D6CC819-82B4-4B7F-AC10-0688B92019A6@macports.org> References: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> <9D32A8FB-CBED-4678-AB0E-8FDB18A21D85@macports.org> <8D6CC819-82B4-4B7F-AC10-0688B92019A6@macports.org> Message-ID: <1E19638B-05E0-42AA-A87D-8DB76A16002B@mac.com> On 9 Feb 2007, at 12:06, Kevin Ballard wrote: > On Feb 9, 2007, at 12:01 PM, Ryan Schmidt wrote: > > Then you need a better editor. Any modern editor should know how > soft tabs work and allow you to delete them just like tabs. What > editor are you using? > gedit (installed by MacPorts) or vi BTW, I have vi set for 8-char tabs and gedit for 4-char tabs and switch back and forth between the two constantly. The shifting spacing has never bothered me, although the lines indented 24 spaces (someone had 8-char tabs and an editor using spaces) drive me up the wall. Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From thomas.e.zander at googlemail.com Sat Feb 10 08:06:13 2007 From: thomas.e.zander at googlemail.com (Thomas Zander) Date: Tue Oct 9 16:39:58 2007 Subject: Latest vim upgrade screws up aqua variant? Message-ID: <786602c60702100806l69e75demb01f565a9475349f@mail.gmail.com> Good day, since the vim port has been bumped to patchlevel 192, the aqua variant seems to have problems: E484: Can't open file /opt/local/Vim.app/Contents/Resources/vim/syntax/syntax.vim So it seems gvim looks for syntax highlighting definitions at the wrong place. Also the main menu does not have any entries except for the leftmost "vim". This happens under a recent OS X Tiger, Intel Mac. Building vim without aqua support however works fine. Has somebody else encountered this? Regards, Riggs From roederja at student.ethz.ch Sat Feb 10 09:48:28 2007 From: roederja at student.ethz.ch (=?UTF-8?B?SmFubiBSw7ZkZXI=?=) Date: Tue Oct 9 16:39:58 2007 Subject: Anyone watching the bugtracker ? Message-ID: Hello everyone, I'm wondering what the policy regarding updated ports / new ports and other patches on the bugtracker is. It seems to me that if you don't bother anyone with commit rights about commiting your update/new port it will never be put in the ports tree. There appear to be countless (valid) tickets that nobody even commented on. This seems a bit discouraging for new contributers. I don't want to accuse anyone, I just thought it might be good to bring up this topic. Cheers Jann From pipping at macports.org Sat Feb 10 10:23:56 2007 From: pipping at macports.org (Elias Pipping) Date: Tue Oct 9 16:39:58 2007 Subject: Latest vim upgrade screws up aqua variant? In-Reply-To: <786602c60702100806l69e75demb01f565a9475349f@mail.gmail.com> References: <786602c60702100806l69e75demb01f565a9475349f@mail.gmail.com> Message-ID: <661BCB6D-E803-4697-8C84-E207B904B54C@macports.org> Hello, sudo ln -s /Applications/MacPorts/Vim/Vim.app/Contents/Resources/ vim/ /opt/local/Vim.app/Contents/Resources/vim should fix the problem. (this is a workaround, I'm working on a solution) On Feb 10, 2007, at 5:06 PM, Thomas Zander wrote: > Good day, > > since the vim port has been bumped to patchlevel 192, the aqua variant > seems to have problems: > E484: Can't open file > /opt/local/Vim.app/Contents/Resources/vim/syntax/syntax.vim > > So it seems gvim looks for syntax highlighting definitions at the > wrong place. Also the main menu does not have any entries except for > the leftmost "vim". > This happens under a recent OS X Tiger, Intel Mac. > > Building vim without aqua support however works fine. > > Has somebody else encountered this? > > Regards, > Riggs > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From pipping at macports.org Sat Feb 10 12:08:04 2007 From: pipping at macports.org (Elias Pipping) Date: Tue Oct 9 16:39:58 2007 Subject: Latest vim upgrade screws up aqua variant? In-Reply-To: <786602c60702100806l69e75demb01f565a9475349f@mail.gmail.com> References: <786602c60702100806l69e75demb01f565a9475349f@mail.gmail.com> Message-ID: <2698C66A-F043-4FD5-B01F-A9FEA1974768@macports.org> This is a duplicate of #11315. https://svn.macosforge.org/projects/macports/ticket/11315 Regards, Elias On Feb 10, 2007, at 5:06 PM, Thomas Zander wrote: > Good day, > > since the vim port has been bumped to patchlevel 192, the aqua variant > seems to have problems: > E484: Can't open file > /opt/local/Vim.app/Contents/Resources/vim/syntax/syntax.vim > > So it seems gvim looks for syntax highlighting definitions at the > wrong place. Also the main menu does not have any entries except for > the leftmost "vim". > This happens under a recent OS X Tiger, Intel Mac. > > Building vim without aqua support however works fine. > > Has somebody else encountered this? > > Regards, > Riggs > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From thomas.e.zander at googlemail.com Sat Feb 10 12:14:58 2007 From: thomas.e.zander at googlemail.com (Thomas Zander) Date: Tue Oct 9 16:39:58 2007 Subject: Latest vim upgrade screws up aqua variant? In-Reply-To: <661BCB6D-E803-4697-8C84-E207B904B54C@macports.org> References: <786602c60702100806l69e75demb01f565a9475349f@mail.gmail.com> <661BCB6D-E803-4697-8C84-E207B904B54C@macports.org> Message-ID: <786602c60702101214k1347409au46965329c6db162e@mail.gmail.com> Hi, On 10/02/07, Elias Pipping wrote: > sudo ln -s /Applications/MacPorts/Vim/Vim.app/Contents/Resources/ > vim/ /opt/local/Vim.app/Contents/Resources/vim > > should fix the problem. (this is a workaround, I'm working on a > solution) okay, sounds good. So it is not a problem of my particular installation. Thanks in advance, Riggs From pipping at macports.org Sat Feb 10 12:22:58 2007 From: pipping at macports.org (Elias Pipping) Date: Tue Oct 9 16:39:58 2007 Subject: Latest vim upgrade screws up aqua variant? In-Reply-To: <786602c60702101214k1347409au46965329c6db162e@mail.gmail.com> References: <786602c60702100806l69e75demb01f565a9475349f@mail.gmail.com> <661BCB6D-E803-4697-8C84-E207B904B54C@macports.org> <786602c60702101214k1347409au46965329c6db162e@mail.gmail.com> Message-ID: Hello, the problem should no longer exist: https://svn.macosforge.org/projects/macports/changeset/21868 (you might need to wait for the portindex to be updated - that means no longer than 12 hours) Regards, Elias On Feb 10, 2007, at 9:14 PM, Thomas Zander wrote: > Hi, > > On 10/02/07, Elias Pipping wrote: > >> sudo ln -s /Applications/MacPorts/Vim/Vim.app/Contents/Resources/ >> vim/ /opt/local/Vim.app/Contents/Resources/vim >> >> should fix the problem. (this is a workaround, I'm working on a >> solution) > > okay, sounds good. So it is not a problem of my particular > installation. > > Thanks in advance, > Riggs From mark.duling at biola.edu Sat Feb 10 13:06:40 2007 From: mark.duling at biola.edu (Mark Duling) Date: Tue Oct 9 16:39:58 2007 Subject: Anyone watching the bugtracker ? In-Reply-To: References: Message-ID: Jann R?der on Saturday, February 10, 2007 at 9:48 AM -0800 wrote: >I'm wondering what the policy regarding updated ports / new ports and >other patches on the bugtracker is. It seems to me that if you don't >bother anyone with commit rights about commiting your update/new port it >will never be put in the ports tree. There appear to be countless >(valid) tickets that nobody even commented on. This seems a bit >discouraging for new contributers. I don't want to accuse anyone, I just >thought it might be good to bring up this topic. The process leaves a lot to be desired, but things have actually improved in the last year. Things may not be as bad as they appear, and I think "countless" is exaggerated. You must realize that: 1) Anyone can create a ticket for any reason, however trivial and esoteric, and many bugs are filed against ports that are little used or even not at all. 2) People are reluctant to close bugs unless it is confirmed that a fix works, and also when port submissions are made that are invalid and the author never responds to requests for changes. So the ticket list is part bug tracker and part community bulletin board system. For these reasons, I think the basic and unstated rule of thumb is, or should be, that people submitting updates and new ports should get top priority. And the for bugs that are being reported with no solution indicated in the ticket, there is no other way but to let them sit there until someone who knows how to fix it does so or someone discovers how to. Some port submissions that are pending responses from authors that will never come, and some tickets will never get fixed and the applications will never be updated and the port will eventually have to be deleted. Until then they take up a ticket and there isn't much we can do. If there was a way to file bugs under some minimal-impact-can't-be-fixed-and-it-probably-doesn't-matter-anyway category and we'd shed a lot of tickets from the open ticket list and it'd look a lot better. But we just have a big list right now. So for better or worse, pinging the mailing list once in awhile is one way for people to help us figure out what tickets are actionable, because it can be hard to tell sometimes. We need more people doing due diligence on the tickets list (who don't need to be highly technical), scanning for developer patches, contacting developers, etc. But the factors I mentioned may always be with us. Mark From blair at orcaware.com Sat Feb 10 17:33:42 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:39:58 2007 Subject: file delete -force not deleting everything Message-ID: <45CE7276.7010704@orcaware.com> On 10.3.9, but not 10.4, the db44 port doesn't build with this error: Installing documentation: /bztmp/MacPorts/var/db/dports/build/_bztmp_MacPorts_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_databases_db44/work/destroot/bztmp/MacPorts/share/db44-4.4.20/ ... DEBUG: Executing proc-post-com.apple.destroot-destroot-0 Error: Target com.apple.destroot returned: error deleting "/bztmp/MacPorts/var/db/dports/build/_bztmp_MacPorts_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_databases_db44/work/destroot/bztmp/MacPorts/share/db44-4.4.20/api_c": file already exists Warning: the following items did not execute (for db44): com.apple.activate com.apple.destroot com.apple.install Error: Status 1 encountered during processing. Doing a ktrace shows this: 19629 tclsh8.4 CALL lstat(0x69bc08,0xbfff9b30) 19629 tclsh8.4 NAMI "/bztmp/MacPorts/var/db/dports/build/_bztmp_MacPorts_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_databases_db44/work/destroot/bztmp/MacPorts/share/db44-4.4.20/api_c/memp_openfd.html" 19629 tclsh8.4 RET lstat 0 19629 tclsh8.4 CALL unlink(0x69bc08) 19629 tclsh8.4 NAMI "/bztmp/MacPorts/var/db/dports/build/_bztmp_MacPorts_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_databases_db44/work/destroot/bztmp/MacPorts/share/db44-4.4.20/api_c/memp_openfd.html" 19629 tclsh8.4 RET unlink 0 19629 tclsh8.4 CALL getdirentries(0xc,0x1807e00,0x1000,0x313884) 19629 tclsh8.4 RET getdirentries 0 19629 tclsh8.4 CALL lseek(0xc,0,0,0) 19629 tclsh8.4 RET lseek 0 19629 tclsh8.4 CALL close(0xc) 19629 tclsh8.4 RET close 0 19629 tclsh8.4 CALL rmdir(0x69bc08) 19629 tclsh8.4 NAMI "/bztmp/MacPorts/var/db/dports/build/_bztmp_MacPorts_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_databases_db44/work/destroot/bztmp/MacPorts/share/db44-4.4.20/api_c" 19629 tclsh8.4 RET rmdir -1 errno 66 Directory not empty And doing an ls in there shows all the files after memp_openfd.html. This is generated by this line in the Portfile post-destroot { file delete -force ${destroot}${prefix}/share Has anybody seen anything like this before? Is the "file delete" an operation provided by Tcl? It's odd that it would go through and try to delete everything, but not finish the job. I'm tempted to change the "file delete -force" into a system "rm -fr ..." call. Regards, Blair From eridius at macports.org Sat Feb 10 18:48:58 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:39:58 2007 Subject: file delete -force not deleting everything In-Reply-To: <45CE7276.7010704@orcaware.com> References: <45CE7276.7010704@orcaware.com> Message-ID: <3B22AB06-0D6B-4EDD-81CE-CB950F73F512@macports.org> file delete is a built-in Tcl command - do a `man n file` to see it. And yeah, it definitely should work. On Feb 10, 2007, at 8:33 PM, Blair Zajac wrote: > Has anybody seen anything like this before? > > Is the "file delete" an operation provided by Tcl? > > It's odd that it would go through and try to delete everything, but > not finish the job. > > I'm tempted to change the "file delete -force" into a system "rm - > fr ..." call. -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070210/7eb333f4/attachment.html From vincent-opdarw at vinc17.org Sat Feb 10 18:58:38 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:39:58 2007 Subject: Spacing issues In-Reply-To: <218E50A3-74B5-4FC3-BFC6-13540128F34E@macports.org> References: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> <9D32A8FB-CBED-4678-AB0E-8FDB18A21D85@macports.org> <8D6CC819-82B4-4B7F-AC10-0688B92019A6@macports.org> <218E50A3-74B5-4FC3-BFC6-13540128F34E@macports.org> Message-ID: <20070211025838.GL12319@prunille.vinc17.org> On 2007-02-09 11:39:20 -0600, Ryan Schmidt wrote: > I assume that's due to the stupid setting available in emacs or vi or > whatever editor it is that actually encourages that behavior. The one > where they've said "We want to indent to 4-space tabs. However, the > editor is configured to print 8 spaces for a tab. Therefore, when we > want to indent one level, we will use 4 spaces, and when we want to > indent 2 levels, we will use one tab, and when we want to indent > three levels, we will use one tab and then 4 spaces." And so forth. > I'm convinced such an editor setting exists somewhere, because I have > seen this nonsense in other projects too, even to the extreme of 2- > space indentation. (Indent sequence: 2 spaces, 4 spaces, 6 spaces, > one tab, one tab and 2 spaces, etc.) A mix of tabs and spaces is bad since it won't look right in diffs, for instance. Moreover, using tabs only is also a bad choice since one can't align columns and a 8-column space is often too much for a single indentation (even though some editors could be configured to use fewer columns, this is not the case of terminals and web browsers). And tabs are often not preserved in copy-paste. So, I'd say: let's use spaces only. > >>Using only spaces seems not so good to me, because > >> > >>- spaces uses 2 or 4 times as much disk space as a tab > > > >Do you honestly believe this is a problem? I'm sure I can spare the > >few extra kB it might take. > > No, not really a problem. I would accept extra disk space if this and compared to all the other files on a disk (in particular videos, images, binaries), one shouldn't noticed the difference. > solution brought significant advantages, but I'm saying it brings > drawbacks. I disagree. See above. > Now I'm curious: What editor do other people use to edit their > portfiles? Emacs. One can use: (setq indent-tabs-mode nil) to disable tabs in indentation. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From 0x62_0x6c_0x62 at pobox.com Sat Feb 10 19:56:30 2007 From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn) Date: Tue Oct 9 16:39:58 2007 Subject: file delete -force not deleting everything In-Reply-To: <3B22AB06-0D6B-4EDD-81CE-CB950F73F512@macports.org> References: <45CE7276.7010704@orcaware.com> <3B22AB06-0D6B-4EDD-81CE-CB950F73F512@macports.org> Message-ID: On Feb 10, 2007, at 7:48 PM, Kevin Ballard wrote: > file delete is a built-in Tcl command - do a `man n file` to see it. > > And yeah, it definitely should work. > Should, but there have been issues before; see for the first time I think it came up with MP...the bug (now in trac): According to the changeset for it MP has a 'delete' command which should do the trick instead of 'system "rm -rf"' ('delete' is definied in portutil.tcl for those curious). Bryan > On Feb 10, 2007, at 8:33 PM, Blair Zajac wrote: > >> Has anybody seen anything like this before? >> >> Is the "file delete" an operation provided by Tcl? >> >> It's odd that it would go through and try to delete everything, >> but not finish the job. >> >> I'm tempted to change the "file delete -force" into a system "rm - >> fr ..." call. > > -- > Kevin Ballard > http://kevin.sb.org > eridius@macports.org > http://www.tildesoft.com > > From mta at umich.edu Sat Feb 10 19:58:16 2007 From: mta at umich.edu (Mike Alexander) Date: Tue Oct 9 16:39:58 2007 Subject: file delete -force not deleting everything In-Reply-To: <3B22AB06-0D6B-4EDD-81CE-CB950F73F512@macports.org> References: <45CE7276.7010704@orcaware.com> <3B22AB06-0D6B-4EDD-81CE-CB950F73F512@macports.org> Message-ID: <1CAC353D4851AFFB5058D31F@fitzrovia.msalexander.com> --On February 10, 2007 9:48:58 PM -0500 Kevin Ballard wrote: > file delete is a built-in Tcl command - do a `man n file` to see it. > > And yeah, it definitely should work. > > On Feb 10, 2007, at 8:33 PM, Blair Zajac wrote: > >> Has anybody seen anything like this before? >> >> Is the "file delete" an operation provided by Tcl? >> >> It's odd that it would go through and try to delete everything, but >> not finish the job. >> >> I'm tempted to change the "file delete -force" into a system "rm - >> fr ..." call. "file delete -force" is broken in some versions of TCL on MacOSX. See and . -- Mike Alexander mta@umich.edu Ann Arbor, MI PGP key ID: BEA343A6 From andreacimino at gmail.com Sun Feb 11 02:47:11 2007 From: andreacimino at gmail.com (Andrea Cimino) Date: Tue Oct 9 16:39:58 2007 Subject: I am writing a Portfile and i would appreciate help Message-ID: <45CEF42F.9040401@gmail.com> I am writing a Portfile for the "Parma Polyhedra Library" project (http://www.cs.unipr.it/ppl) but i have some questions for you, developers. You can find a first snapshot of the Portfile here: http://www.cs.unipr.it/cgi-bin/viewvc/viewvc.cgi/ppl/DarwinPorts_Portfile?revision=1.1.2.1&view=markup&pathrev=ppl-0_9-branch This is my first Portfile so i don't expect that meets the MacPorts standards, here the questions: 1) Is really needed to have a ppl-dev package, with headers and so on? Or we can just provide a 'ppl' package with everything installed there? 2) The 'ppl' provides several Prolog interfaces so i decided to write some variants: is this the right way to help MacPorts users installing the 'ppl' and building the interfaces? 3) The 'ppl', depending on the presence of the 'glpk' library, builds the optional tool 'ppl_lpsol'. The glpk dependency should be declared in a variant or in the main section of the Portfile? Other suggestions obviously are welcome! Best regards, Andrea Cimino From rhwood at mac.com Sun Feb 11 03:05:51 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:39:58 2007 Subject: I am writing a Portfile and i would appreciate help In-Reply-To: <45CEF42F.9040401@gmail.com> References: <45CEF42F.9040401@gmail.com> Message-ID: On 11 Feb 2007, at 05:47, Andrea Cimino wrote: > I am writing a Portfile for the "Parma Polyhedra Library" project > (http://www.cs.unipr.it/ppl) > but i have some questions for you, developers. > > You can find a first snapshot of the Portfile here: > http://www.cs.unipr.it/cgi-bin/viewvc/viewvc.cgi/ppl/ > DarwinPorts_Portfile?revision=1.1.2.1&view=markup&pathrev=ppl-0_9- > branch > > This is my first Portfile so i don't expect that meets the MacPorts > standards, here the questions: > > 1) Is really needed to have a ppl-dev package, with headers and so > on? Or we can just provide a 'ppl' package with everything > installed there? No ppl-dev package is created. The whole thing, headers and all, goes in one package. MacPorts uses *-devel packages to note that the *- devel version is the non-stable version of a port. Run the "port search swi-prolog" and "port search yap" commands and you will see what I mean. You may wish to depend on swi-prolog and yap instead of on swi-prolog- devel and yap-devel. > 2) The 'ppl' provides several Prolog interfaces so i decided to > write some variants: is this the right way to help MacPorts users > installing the 'ppl' and building the interfaces? Yes, it is. However, your variants should ensure that ppl builds with the desired functionality only if the variant is selected using configure.args-append statements. You may wish to also name your variants enable_*/disable_*/with_*/without_* (so you have +with_yap instead of just +yap). Use the syntax most similar to the syntax used by the ppl build system (if it uses --include-something then the variant would be +include_something). > 3) The 'ppl', depending on the presence of the 'glpk' library, > builds the optional tool 'ppl_lpsol'. The glpk dependency should be > declared in a variant or in the main section of the Portfile? I would do this as a variant as well. > Other suggestions obviously are welcome! You may wish to make sure that for each variant you have, you have a conflicting variant that removes that variants functionality: for example: default_variants +with_yap variant with_yap conflicts without_yap { ... } variant without_yap conflicts with_yap { ... } This way if a user decides not to use the +without_yap variant, it will prevent the +with_yap variant from being used. > Best regards, > Andrea Cimino > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From andreacimino at gmail.com Sun Feb 11 03:43:09 2007 From: andreacimino at gmail.com (Andrea Cimino) Date: Tue Oct 9 16:39:58 2007 Subject: I am writing a Portfile and i would appreciate help In-Reply-To: References: <45CEF42F.9040401@gmail.com> Message-ID: <45CF014D.8070405@gmail.com> Randall Wood ha scritto: > > On 11 Feb 2007, at 05:47, Andrea Cimino wrote: > >> I am writing a Portfile for the "Parma Polyhedra Library" project >> (http://www.cs.unipr.it/ppl) >> but i have some questions for you, developers. >> >> You can find a first snapshot of the Portfile here: >> http://www.cs.unipr.it/cgi-bin/viewvc/viewvc.cgi/ppl/DarwinPorts_Portfile?revision=1.1.2.1&view=markup&pathrev=ppl-0_9-branch >> >> >> This is my first Portfile so i don't expect that meets the MacPorts >> standards, here the questions: >> >> 1) Is really needed to have a ppl-dev package, with headers and so >> on? Or we can just provide a 'ppl' package with everything installed >> there? > > No ppl-dev package is created. The whole thing, headers and all, goes > in one package. MacPorts uses *-devel packages to note that the > *-devel version is the non-stable version of a port. > > Run the "port search swi-prolog" and "port search yap" commands and > you will see what I mean. > > You may wish to depend on swi-prolog and yap instead of on > swi-prolog-devel and yap-devel. Thanks, i will fix the Portfile now. >> 2) The 'ppl' provides several Prolog interfaces so i decided to write >> some variants: is this the right way to help MacPorts users >> installing the 'ppl' and building the interfaces? > > Yes, it is. However, your variants should ensure that ppl builds with > the desired functionality only if the variant is selected using > configure.args-append statements. You may wish to also name your > variants enable_*/disable_*/with_*/without_* (so you have +with_yap > instead of just +yap). Use the syntax most similar to the syntax used > by the ppl build system (if it uses --include-something then the > variant would be +include_something). > I understand. The point is that our configure script tries to automatically detect the Prolog systems installed and builds the corresponding interface, but we don't have an option named "--disable-yap". I thought that having a variant like +yap, could help people to install the ppl configured in the right way. Do you think that is better to let the ppl build depending on the ports installed on the system? E.G. I have the Swi-prolog installed, so the ppl port builds also the Swi-prolog interface... >> 3) The 'ppl', depending on the presence of the 'glpk' library, builds >> the optional tool 'ppl_lpsol'. The glpk dependency should be declared >> in a variant or in the main section of the Portfile? > I would do this as a variant as well. > We also don't have in this case an option named --disable-glpk. The ppl automatically checks for the Glpk and tries to build the ppl-lpsol tool. With the variant i would have forced to build the ppl_lpsol tool. What do you think we should do? >> Other suggestions obviously are welcome! From rhwood at mac.com Sun Feb 11 05:28:47 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:39:58 2007 Subject: I am writing a Portfile and i would appreciate help In-Reply-To: <45CF014D.8070405@gmail.com> References: <45CEF42F.9040401@gmail.com> <45CF014D.8070405@gmail.com> Message-ID: <7CE0EB52-B223-4387-AC38-3484A3E836F0@mac.com> On 11 Feb 2007, at 06:43, Andrea Cimino wrote: > Randall Wood ha scritto: >> >> On 11 Feb 2007, at 05:47, Andrea Cimino wrote: >> >>> I am writing a Portfile for the "Parma Polyhedra Library" project >>> (http://www.cs.unipr.it/ppl) >>> but i have some questions for you, developers. >>> >>> You can find a first snapshot of the Portfile here: >>> http://www.cs.unipr.it/cgi-bin/viewvc/viewvc.cgi/ppl/ >>> DarwinPorts_Portfile?revision=1.1.2.1&view=markup&pathrev=ppl-0_9- >>> branch >>> >>> This is my first Portfile so i don't expect that meets the >>> MacPorts standards, here the questions: >>> >>> 1) Is really needed to have a ppl-dev package, with headers and >>> so on? Or we can just provide a 'ppl' package with everything >>> installed there? >> >> No ppl-dev package is created. The whole thing, headers and all, >> goes in one package. MacPorts uses *-devel packages to note that >> the *-devel version is the non-stable version of a port. >> >> Run the "port search swi-prolog" and "port search yap" commands >> and you will see what I mean. >> >> You may wish to depend on swi-prolog and yap instead of on swi- >> prolog-devel and yap-devel. > Thanks, i will fix the Portfile now. > >>> 2) The 'ppl' provides several Prolog interfaces so i decided to >>> write some variants: is this the right way to help MacPorts users >>> installing the 'ppl' and building the interfaces? >> >> Yes, it is. However, your variants should ensure that ppl builds >> with the desired functionality only if the variant is selected >> using configure.args-append statements. You may wish to also name >> your variants enable_*/disable_*/with_*/without_* (so you have >> +with_yap instead of just +yap). Use the syntax most similar to >> the syntax used by the ppl build system (if it uses --include- >> something then the variant would be +include_something). >> > I understand. The point is that our configure script tries to > automatically detect the Prolog systems installed and builds the > corresponding interface, but we don't have an option named "-- > disable-yap". I thought that having a variant like +yap, could help > people to install the ppl configured in the right way. Do you think > that is better to let the ppl build depending on the ports > installed on the system? E.G. I have the Swi-prolog installed, so > the ppl port builds also the Swi-prolog interface... I would include yap and swi-prolog as dependents in the main portion of the Portfile and remove the variants then. >>> 3) The 'ppl', depending on the presence of the 'glpk' library, >>> builds the optional tool 'ppl_lpsol'. The glpk dependency should >>> be declared in a variant or in the main section of the Portfile? >> I would do this as a variant as well. >> > We also don't have in this case an option named --disable-glpk. The > ppl automatically checks for the Glpk and tries to build > the ppl-lpsol tool. With the variant i would have forced to build > the ppl_lpsol tool. > What do you think we should do? In cases like this I would put the dependencies in the main section of the portfile. Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From thomas.e.zander at googlemail.com Sun Feb 11 06:30:38 2007 From: thomas.e.zander at googlemail.com (Thomas Zander) Date: Tue Oct 9 16:39:58 2007 Subject: Latest vim upgrade screws up aqua variant? In-Reply-To: References: <786602c60702100806l69e75demb01f565a9475349f@mail.gmail.com> <661BCB6D-E803-4697-8C84-E207B904B54C@macports.org> <786602c60702101214k1347409au46965329c6db162e@mail.gmail.com> Message-ID: <786602c60702110630p7de72452xc18ff016f3d4f930@mail.gmail.com> Hi, On 10/02/07, Elias Pipping wrote: > the problem should no longer exist: sorry, despite not upgrading but complete uninstall/install of the vim port (the _1 revision this time), it is still looking for the resources in the wrong place and I have to apply the symlink workaround manually. But it was a good idea to mention that the vim aqua port requires a complete deinstall / install procedure. When I crossed this in the first place it felt quite unexpected because the upgrading process usually works surprisingly fine with macports. Riggs From rhwood at mac.com Sun Feb 11 07:25:04 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:39:58 2007 Subject: Proposal: variants naming conventions Message-ID: I have noticed that most variants add or delete a configure flag in the form of --enable-*/--disable-*/--with-*/--without-* and maybe add or delete a related dependency. Therefore, I propose that all variants should fit the following forms: {en|dis}able_package: If a ported software package has optional compile-time features, the user can give configure command line options to specify whether to compile them. The options have one of these forms: --enable-feature --disable-feature (Note that this is slightly different then how configure scripts work [1]). with[out]_package: When a port requires, or can optionally use, other ports that can be or already are installed. The user can give configure command line options to specify which such external software to use. A port can be written with options have one of these forms: +with_package +without_package (Note that this is slightly different then how configure scripts work [2]). (Most configure scripts allow these options to passed with further information in the form of --option=arg where a reasonable default is set if =arg is not specified. port can't handle that, so =arg is not allowed in variant names and this proposal does not contemplate changing that) Changing this variant structure has, I believe, the following benefits: 1) Adding the verb enable/disable/use/with/without makes the variant more meaningful to users. I know there have been comments on the mailing list about the inability to comment on variants such that 'port info' is capable of explaining what each variant does. The verb will help address those complaints. 2) There are currently variants no-*, no_*, and no* These are inconsistent and do not tell me (the user) if I am disabling a feature (that some other port may depend on) or simply building the port without using some other package. 3) Negative variants are confusing. with_*/without_* or enable_*/ disable_* is more readable than +*/-* as an indicator of what is going on. References: [1] GNU Autoconf Manual Section 12.2: Choosing Package Options, http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_mono/ autoconf.html#SEC131 [2] GNU Autoconf Manual Section 12.1: Working With External Software, http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_mono/ autoconf.html#SEC130 Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From yves at macports.org Sun Feb 11 10:12:32 2007 From: yves at macports.org (Yves de Champlain) Date: Tue Oct 9 16:39:58 2007 Subject: Proposal: variants naming conventions In-Reply-To: References: Message-ID: Le 07-02-11 ? 10:25, Randall Wood a ?crit : > I have noticed that most variants add or delete a configure flag in > the form of --enable-*/--disable-*/--with-*/--without-* and maybe > add or delete a related dependency. > > Therefore, I propose that all variants should fit the following forms: > > {en|dis}able_package: If a ported software package has optional > compile-time features, the user can give configure command line > options to specify whether to compile them. The options have one of > these forms: > --enable-feature > --disable-feature > (Note that this is slightly different then how configure scripts > work[1]). > > with[out]_package: When a port requires, or can optionally use, > other ports that can be or already are installed. The user can give > configure command line options to specify which such external > software to use. A port can be written with options have one of > these forms: > +with_package > +without_package > (Note that this is slightly different then how configure scripts > work[2]). > > (Most configure scripts allow these options to passed with further > information in the form of --option=arg where a reasonable default > is set if =arg is not specified. port can't handle that, so =arg is > not allowed in variant names and this proposal does not contemplate > changing that) > > Changing this variant structure has, I believe, the following > benefits: > > 1) Adding the verb enable/disable/use/with/without makes the > variant more meaningful to users. I know there have been comments > on the mailing list about the inability to comment on variants such > that 'port info' is capable of explaining what each variant does. > The verb will help address those complaints. > > 2) There are currently variants no-*, no_*, and no* These are > inconsistent and do not tell me (the user) if I am disabling a > feature (that some other port may depend on) or simply building the > port without using some other package. > > 3) Negative variants are confusing. with_*/without_* or enable_*/ > disable_* is more readable than +*/-* as an indicator of what is > going on. I agree on both the usefulness of this undertaking and the logic of this proposal. However, two points are less clear for me : 1- You seem to propose "use" and "add" keywords, but I don't see their usefulness. [en|dis]able and with[out] look plain perfect to me, unless there is somme case I miss. 2- My experience is that variant names should not include "-" because of the way arguments are parsed. I always use underscore "_" because of that, but if I am wrong, I would be glad to know ! Finally, shouldn't ports build most of the functionnalities by default ? Maybe it is a good time to say it again. yves From mstevens at etla.org Sun Feb 11 11:56:32 2007 From: mstevens at etla.org (Michael Stevens) Date: Tue Oct 9 16:39:58 2007 Subject: zile port update Message-ID: <45CF74F0.5070600@etla.org> Hi. I've updated the zile port to version 2.2.28. The change is in trac as ticket #11370: http://trac.macosforge.org/projects/macports/ticket/11370 Michael From pipping at macports.org Sun Feb 11 12:02:40 2007 From: pipping at macports.org (Elias Pipping) Date: Tue Oct 9 16:39:58 2007 Subject: zile port update In-Reply-To: <45CF74F0.5070600@etla.org> References: <45CF74F0.5070600@etla.org> Message-ID: <703A2B58-44D9-493F-B73F-F97E304A1631@macports.org> fixed in r21932. On Feb 11, 2007, at 8:56 PM, Michael Stevens wrote: > Hi. > > I've updated the zile port to version 2.2.28. The change is in trac > as ticket #11370: > > http://trac.macosforge.org/projects/macports/ticket/11370 > > Michael > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From andreacimino at gmail.com Sun Feb 11 12:20:32 2007 From: andreacimino at gmail.com (Andrea Cimino) Date: Tue Oct 9 16:39:58 2007 Subject: I am writing a Portfile and i would appreciate help In-Reply-To: <7CE0EB52-B223-4387-AC38-3484A3E836F0@mac.com> References: <45CEF42F.9040401@gmail.com> <45CF014D.8070405@gmail.com> <7CE0EB52-B223-4387-AC38-3484A3E836F0@mac.com> Message-ID: <45CF7A90.3070002@gmail.com> Randall Wood ha scritto: >> We also don't have in this case an option named --disable-glpk. The >> ppl automatically checks for the Glpk and tries to build >> the ppl-lpsol tool. With the variant i would have forced to build the >> ppl_lpsol tool. >> What do you think we should do? > > In cases like this I would put the dependencies in the main section of > the portfile. > Ok. I don't know if this could be a good policy: if a kind of prolog system is installed in /opt/local, then the appropriate prolog interface is built, without taking care of the variants. The new Portfile is at: http://www.cs.unipr.it/cgi-bin/viewvc/viewvc.cgi/ppl/DarwinPorts_Portfile?view=markup&pathrev=ppl-0_9-branch Sorry for my questions, but i prefer to ask! If the Portfile is ok, where to ask for submission? The Darwinports docs links are now outdated. Greetings, Andrea From blair at orcaware.com Sun Feb 11 12:46:59 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:39:58 2007 Subject: file delete -force not deleting everything In-Reply-To: <1CAC353D4851AFFB5058D31F@fitzrovia.msalexander.com> References: <45CE7276.7010704@orcaware.com> <3B22AB06-0D6B-4EDD-81CE-CB950F73F512@macports.org> <1CAC353D4851AFFB5058D31F@fitzrovia.msalexander.com> Message-ID: <45CF80C3.3090200@orcaware.com> Mike Alexander wrote: > --On February 10, 2007 9:48:58 PM -0500 Kevin Ballard > wrote: > >> file delete is a built-in Tcl command - do a `man n file` to see it. >> >> And yeah, it definitely should work. >> >> On Feb 10, 2007, at 8:33 PM, Blair Zajac wrote: >> >>> Has anybody seen anything like this before? >>> >>> Is the "file delete" an operation provided by Tcl? >>> >>> It's odd that it would go through and try to delete everything, but >>> not finish the job. >>> >>> I'm tempted to change the "file delete -force" into a system "rm - >>> fr ..." call. > > "file delete -force" is broken in some versions of TCL on MacOSX. See > and > . > Thanks for all the info. I've updated the db44 Portfile and it builds fine on 10.3. Maybe we should do a global search and replace for all the Portfile's. Regards, Blair From blair at orcaware.com Sun Feb 11 13:05:50 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:39:58 2007 Subject: Revamping home page left sidebar Message-ID: <45CF852E.5050406@orcaware.com> Regarding the left sidebar of links on http://www.macports.org/ I have some suggestions. The term "Source Code" is not as obvious as "Download" which people are more familiar with. We can say, we only provide source downloads, no binaries. Also, adding links to the the users, developers, ticket (bug report) changes, and source code changes mailing lists would be nice, so you don't have to hunt down the home page. Regards, Blair From ryandesign at macports.org Sun Feb 11 13:41:27 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:39:58 2007 Subject: Revamping home page left sidebar In-Reply-To: <45CF852E.5050406@orcaware.com> References: <45CF852E.5050406@orcaware.com> Message-ID: On Feb 11, 2007, at 15:05, Blair Zajac wrote: > Regarding the left sidebar of links on > > http://www.macports.org/ > > I have some suggestions. > > The term "Source Code" is not as obvious as "Download" which people > are more familiar with. We can say, we only provide source > downloads, no binaries. But there are also binaries provided. This has come up before, and I still agree with it. Please change "Source Code" to "Download" or "Downloads". > Also, adding links to the the users, developers, ticket (bug > report) changes, and source code changes mailing lists would be > nice, so you don't have to hunt down the home page. By total coincidence, I see the mailing lists are available under the menu item "About Us." I would change that menu item to "Mailing Lists." Also, I would remove the links to other Mac OS Forge projects, unless having them there is a requirement of the deal. The MacPorts web site seems to have the standard Mac OS Forge "look." Is this required by the deal, or can it be changed to something completely different? I don't like the default Mac OS Forge theme. How can the MacPorts web site be changed? The old DarwinPorts web site was in the repository, but where is the MacPorts web site, and who all has the authority to change it? From olaf at foellinger.de Sun Feb 11 14:18:23 2007 From: olaf at foellinger.de (Olaf Foellinger) Date: Tue Oct 9 16:39:58 2007 Subject: possible to fetch sources from git repository? Message-ID: <20070211221823.GA24478@merlin.in-berlin.de> Hi, on the GCompris mailing list Yeves Combe announced that he has not only compiled GCompris on Mac OS X but also has used the gtk+ aqua port. It shoud be possible to provide some portfiles to make these results available to mapcports. Some of the sources are only available in git repositories so the question arise whether it is possible to fetch sources from git repositories? The man page only mentions cvs repositories. Gruss Olaf From ryandesign at macports.org Sun Feb 11 14:21:24 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:39:58 2007 Subject: file delete -force not deleting everything In-Reply-To: <45CF80C3.3090200@orcaware.com> References: <45CE7276.7010704@orcaware.com> <3B22AB06-0D6B-4EDD-81CE-CB950F73F512@macports.org> <1CAC353D4851AFFB5058D31F@fitzrovia.msalexander.com> <45CF80C3.3090200@orcaware.com> Message-ID: On Feb 11, 2007, at 14:46, Blair Zajac wrote: >>>> Has anybody seen anything like this before? >>>> >>>> Is the "file delete" an operation provided by Tcl? >>>> >>>> It's odd that it would go through and try to delete everything, but >>>> not finish the job. >>>> >>>> I'm tempted to change the "file delete -force" into a system "rm - >>>> fr ..." call. >>> >>> file delete is a built-in Tcl command - do a `man n file` to see it. >>> >>> And yeah, it definitely should work. >> >> "file delete -force" is broken in some versions of TCL on MacOSX. >> See > 2838168> and . > > Thanks for all the info. > > I've updated the db44 Portfile and it builds fine on 10.3. > > Maybe we should do a global search and replace for all the Portfile's. So we're saying that "file delete" which is provided by TCL is broken and should never be used? And "delete" which is provided by MacPorts should always be used instead? (And that calling system "rm -rf" is also a faux pas?) Then I would say that yes, we should globally search and replace in all portfiles. Also, when we finally get around to writing that pre-commit hook script for the repository, it should check for the use of file delete or system "rm -rf" and prevent such commits and recommend the "delete" alternative. From ryandesign at macports.org Sun Feb 11 14:40:00 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:39:58 2007 Subject: I am writing a Portfile and i would appreciate help In-Reply-To: References: <45CEF42F.9040401@gmail.com> Message-ID: On Feb 11, 2007, at 05:05, Randall Wood wrote: > You may wish to make sure that for each variant you have, you have > a conflicting variant that removes that variants functionality: for > example: > > default_variants +with_yap > > variant with_yap conflicts without_yap { ... } > > variant without_yap conflicts with_yap { ... } > > This way if a user decides not to use the +without_yap variant, it > will prevent the +with_yap variant from being used. I still don't understand this suggestion of providing both with_yap and without_yap variants. I haven't seen that in any existing ports, and don't see why you can't just have one of those variants, and not the other. If you have a variant called with_yap, then if you use the variant, you get yap; if you don't use the variant, you don't get yap. On the other hand, if you have a variant without_yap, and you use it, you don't get yap, and if you don't use it, you do get yap. Which variant you provide depends on whether you want yap to be enabled by default or not. I also don't see any need to use the default_variants feature. From mccdo at iastate.edu Sun Feb 11 19:13:16 2007 From: mccdo at iastate.edu (Doug McCorkle) Date: Tue Oct 9 16:39:58 2007 Subject: Update gmtl port Message-ID: <4A9FFC7B-D812-4D65-887A-957422C94A61@iastate.edu> Hello, http://trac.macosforge.org/projects/macports/ticket/11332 Could this patch be applied? Thanks. Doug Doug McCorkle - Research Assistant Iowa State University Virtual Engineering Research Group www.vrac.iastate.edu/~mccdo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070211/9cede87c/attachment.html From rhwood at mac.com Sun Feb 11 19:31:08 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:39:58 2007 Subject: Proposal: variants naming conventions In-Reply-To: References: Message-ID: On 11 Feb 2007, at 13:12, Yves de Champlain wrote: > > Le 07-02-11 ? 10:25, Randall Wood a ?crit : > >> I have noticed that most variants add or delete a configure flag >> in the form of --enable-*/--disable-*/--with-*/--without-* and >> maybe add or delete a related dependency. >> >> Therefore, I propose that all variants should fit the following >> forms: >> >> {en|dis}able_package: If a ported software package has optional >> compile-time features, the user can give configure command line >> options to specify whether to compile them. The options have one >> of these forms: >> --enable-feature >> --disable-feature These should be +enable_feature and +disable_feature >> (Note that this is slightly different then how configure scripts >> work[1]). >> >> with[out]_package: When a port requires, or can optionally use, >> other ports that can be or already are installed. The user can >> give configure command line options to specify which such external >> software to use. A port can be written with options have one of >> these forms: >> +with_package >> +without_package >> (Note that this is slightly different then how configure scripts >> work[2]). >> >> (Most configure scripts allow these options to passed with further >> information in the form of --option=arg where a reasonable default >> is set if =arg is not specified. port can't handle that, so =arg >> is not allowed in variant names and this proposal does not >> contemplate changing that) >> >> Changing this variant structure has, I believe, the following >> benefits: >> >> 1) Adding the verb enable/disable/use/with/without makes the >> variant more meaningful to users. I know there have been comments >> on the mailing list about the inability to comment on variants >> such that 'port info' is capable of explaining what each variant >> does. The verb will help address those complaints. >> >> 2) There are currently variants no-*, no_*, and no* These are >> inconsistent and do not tell me (the user) if I am disabling a >> feature (that some other port may depend on) or simply building >> the port without using some other package. >> >> 3) Negative variants are confusing. with_*/without_* or enable_*/ >> disable_* is more readable than +*/-* as an indicator of what is >> going on. > > I agree on both the usefulness of this undertaking and the logic of > this proposal. > > However, two points are less clear for me : > > 1- You seem to propose "use" and "add" keywords, but I don't see > their usefulness. [en|dis]able and with[out] look plain perfect to > me, unless there is somme case I miss. The "use" keyword was left over from a similar proposal from May 2006. Sorry about that. It should not have been in there. "add" keyword? I have not proposed any such thing; I merely hope my grammar it not that bad. > 2- My experience is that variant names should not include "-" > because of the way arguments are parsed. I always use underscore > "_" because of that, but if I am wrong, I would be glad to know ! I know. I would like it if that could change, although I don't see it changing as long as negative variants are allowed. > Finally, shouldn't ports build most of the functionnalities by > default ? Maybe it is a good time to say it again. I think that the richest port possible should be the default port, however, I also am aware that say, when a port needs a database and that the database requirement can be solved using 1 of 9 different ports, that the use of variants will be almost certainly required. There have been situations, at least in the GNOME ports, where I have had to turn off functionality for compatibility or reliability when shipping a port, and have left it optional for those who wanted it. > > yves > Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From ryandesign at macports.org Sun Feb 11 19:36:39 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:39:58 2007 Subject: Update gmtl port In-Reply-To: <4A9FFC7B-D812-4D65-887A-957422C94A61@iastate.edu> References: <4A9FFC7B-D812-4D65-887A-957422C94A61@iastate.edu> Message-ID: On Feb 11, 2007, at 21:13, Doug McCorkle wrote: > http://trac.macosforge.org/projects/macports/ticket/11332 > Could this patch be applied? Thanks. Done. From eridius at macports.org Sun Feb 11 20:56:23 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:39:58 2007 Subject: Spacing issues In-Reply-To: <20070211025838.GL12319@prunille.vinc17.org> References: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> <9D32A8FB-CBED-4678-AB0E-8FDB18A21D85@macports.org> <8D6CC819-82B4-4B7F-AC10-0688B92019A6@macports.org> <218E50A3-74B5-4FC3-BFC6-13540128F34E@macports.org> <20070211025838.GL12319@prunille.vinc17.org> Message-ID: <35EA3CE3-F9BE-410D-866F-4D05A2AA5ED6@macports.org> Are there any more thoughts on this matter? For now, every line I modify is going to have its hard tabs converted to 4-width soft tabs (and reindented if necessary). I'd really like to do a single pass and convert the entire source base over to 4- width soft tabs, but it seems we have at least one dissenter. Can we come to an agreement on an overall policy for this? -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070211/94ea216a/attachment.html From ryandesign at macports.org Sun Feb 11 22:06:56 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:39:58 2007 Subject: Revamping home page left sidebar In-Reply-To: <05E8FE2D-D950-4539-9EB0-F960267F9869@opendarwin.org> References: <45CF852E.5050406@orcaware.com> <05E8FE2D-D950-4539-9EB0-F960267F9869@opendarwin.org> Message-ID: On Feb 11, 2007, at 23:30, Jordan K. Hubbard wrote: > On Feb 11, 2007, at 1:41 PM, Ryan Schmidt wrote: > >> By total coincidence, I see the mailing lists are available under >> the menu item "About Us." I would change that menu item to >> "Mailing Lists." >> >> Also, I would remove the links to other Mac OS Forge projects, >> unless having them there is a requirement of the deal. >> >> The MacPorts web site seems to have the standard Mac OS Forge >> "look." Is this required by the deal, or can it be changed to >> something completely different? I don't like the default Mac OS >> Forge theme. > > All Mac OS Forge projects have to have a consistent look and feel, > so there's not a whole lot of leeway for change on the project page > itself, but changing "Source Code" to "Downloads" and having a link > for "Mailing Lists" seem to be reasonable requests. I'll look into > getting those sidebar changes made. But the WebKit web site looks different from the rest of Mac OS Forge... From jkh at brierdr.com Sun Feb 11 22:25:32 2007 From: jkh at brierdr.com (Jordan K. Hubbard) Date: Tue Oct 9 16:39:58 2007 Subject: Revamping home page left sidebar In-Reply-To: References: <45CF852E.5050406@orcaware.com> <05E8FE2D-D950-4539-9EB0-F960267F9869@opendarwin.org> Message-ID: <9BC8CC45-5445-4910-A52E-1E447A9F1198@brierdr.com> On Feb 11, 2007, at 10:06 PM, Ryan Schmidt wrote: > > On Feb 11, 2007, at 23:30, Jordan K. Hubbard wrote: > >> On Feb 11, 2007, at 1:41 PM, Ryan Schmidt wrote: >> >>> By total coincidence, I see the mailing lists are available under >>> the menu item "About Us." I would change that menu item to >>> "Mailing Lists." >>> >>> Also, I would remove the links to other Mac OS Forge projects, >>> unless having them there is a requirement of the deal. >>> >>> The MacPorts web site seems to have the standard Mac OS Forge >>> "look." Is this required by the deal, or can it be changed to >>> something completely different? I don't like the default Mac OS >>> Forge theme. >> >> All Mac OS Forge projects have to have a consistent look and feel, >> so there's not a whole lot of leeway for change on the project >> page itself, but changing "Source Code" to "Downloads" and having >> a link for "Mailing Lists" seem to be reasonable requests. I'll >> look into getting those sidebar changes made. > > But the WebKit web site looks different from the rest of Mac OS > Forge... That's largely for legacy reasons, but it's also allowed because it's under a different banner. I know that www.macports.org points to the equivalent of macports.macosforge.org right now, but since "macports.org" is notionally an independent site, there's nothing which disallows the project from establishing its own www.macports.org portal and having two different project faces, one at www.macports.org and one at macports.macosforge.org. It's only when people are "at macosforge" that they need to see a consistent L&F in order to meet Apple's style guidelines for macosforge. - Jordan From eridius at macports.org Mon Feb 12 07:16:32 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:39:58 2007 Subject: Revamping home page left sidebar In-Reply-To: <9BC8CC45-5445-4910-A52E-1E447A9F1198@brierdr.com> References: <45CF852E.5050406@orcaware.com> <05E8FE2D-D950-4539-9EB0-F960267F9869@opendarwin.org> <9BC8CC45-5445-4910-A52E-1E447A9F1198@brierdr.com> Message-ID: <1F3F5DD9-2EF2-4684-8CD2-8C14002C4594@macports.org> May I point out that macports.macosforge.org isn't a working domain? At the moment I see no way to be "at macosforge" when perusing the MacPorts project site. On Feb 12, 2007, at 1:25 AM, Jordan K. Hubbard wrote: > That's largely for legacy reasons, but it's also allowed because > it's under a different banner. I know that www.macports.org points > to the equivalent of macports.macosforge.org right now, but since > "macports.org" is notionally an independent site, there's nothing > which disallows the project from establishing its own > www.macports.org portal and having two different project faces, one > at www.macports.org and one at macports.macosforge.org. It's only > when people are "at macosforge" that they need to see a consistent > L&F in order to meet Apple's style guidelines for macosforge. -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070212/7db7357e/attachment.html From mark.duling at biola.edu Mon Feb 12 09:49:07 2007 From: mark.duling at biola.edu (Mark Duling) Date: Tue Oct 9 16:39:58 2007 Subject: possible to fetch sources from git repository? In-Reply-To: <20070211221823.GA24478@merlin.in-berlin.de> References: <20070211221823.GA24478@merlin.in-berlin.de> Message-ID: Olaf Foellinger on Sunday, February 11, 2007 at 2:18 PM -0800 wrote: >on the GCompris mailing list Yeves Combe announced that he has not only >compiled GCompris on Mac OS X but also has used the gtk+ aqua port. It >shoud be possible to provide some portfiles to make these results >available to mapcports. > >Some of the sources are only available in git repositories so the >question arise whether it is possible to fetch sources from git >repositories? The man page only mentions cvs repositories. I'm not sure what you mean by a git repository. How you you get sources for these files manually? Mark From pipping at macports.org Mon Feb 12 10:23:32 2007 From: pipping at macports.org (Elias Pipping) Date: Tue Oct 9 16:39:58 2007 Subject: possible to fetch sources from git repository? In-Reply-To: References: <20070211221823.GA24478@merlin.in-berlin.de> Message-ID: Git is a version control system originally developed by linus torvalds for the linux kernel http://git.or.cz/ On Feb 12, 2007, at 6:49 PM, Mark Duling wrote: > I'm not sure what you mean by a git repository. How you you get > sources > for these files manually? > > Mark > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From jkh at brierdr.com Mon Feb 12 11:04:23 2007 From: jkh at brierdr.com (Jordan K. Hubbard) Date: Tue Oct 9 16:39:58 2007 Subject: Revamping home page left sidebar In-Reply-To: <8670FF3C-5F59-4782-A934-369FE535A1F4@sb.org> References: <45CF852E.5050406@orcaware.com> <05E8FE2D-D950-4539-9EB0-F960267F9869@opendarwin.org> <9BC8CC45-5445-4910-A52E-1E447A9F1198@brierdr.com> <8670FF3C-5F59-4782-A934-369FE535A1F4@sb.org> Message-ID: <05CB8FBE-20CD-48BA-903D-6295C1C8B849@brierdr.com> I know, I've already filed a bug report on that with Kevin. Both macports and webkit SHOULD have cnames, it's merely an oversight that they do not. - Jordan On Feb 12, 2007, at 1:07 AM, Kevin Ballard wrote: > May I point out that macports.macosforge.org isn't a working > domain? At the moment I see no way to be "at macosforge" when > perusing the MacPorts project site. > > On Feb 12, 2007, at 1:25 AM, Jordan K. Hubbard wrote: > >> That's largely for legacy reasons, but it's also allowed because >> it's under a different banner. I know that www.macports.org >> points to the equivalent of macports.macosforge.org right now, but >> since "macports.org" is notionally an independent site, there's >> nothing which disallows the project from establishing its own >> www.macports.org portal and having two different project faces, >> one at www.macports.org and one at macports.macosforge.org. It's >> only when people are "at macosforge" that they need to see a >> consistent L&F in order to meet Apple's style guidelines for >> macosforge. > > -- > Kevin Ballard > http://kevin.sb.org > kevin@sb.org > http://www.tildesoft.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070212/778d23c0/attachment.html From kvv at apple.com Mon Feb 12 12:29:25 2007 From: kvv at apple.com (Kevin Van Vechten) Date: Tue Oct 9 16:39:58 2007 Subject: Revamping home page left sidebar In-Reply-To: <05CB8FBE-20CD-48BA-903D-6295C1C8B849@brierdr.com> References: <45CF852E.5050406@orcaware.com> <05E8FE2D-D950-4539-9EB0-F960267F9869@opendarwin.org> <9BC8CC45-5445-4910-A52E-1E447A9F1198@brierdr.com> <8670FF3C-5F59-4782-A934-369FE535A1F4@sb.org> <05CB8FBE-20CD-48BA-903D-6295C1C8B849@brierdr.com> Message-ID: <9F18BD9C-4946-4E43-96EF-5426BBCB51C6@apple.com> macports.macosforge.org should now redirect to www.macports.org. - Kevin On Feb 12, 2007, at 11:04 AM, Jordan K. Hubbard wrote: > I know, I've already filed a bug report on that with Kevin. Both > macports and webkit SHOULD have cnames, it's merely an oversight > that they do not. > > - Jordan > > On Feb 12, 2007, at 1:07 AM, Kevin Ballard wrote: > >> May I point out that macports.macosforge.org isn't a working >> domain? At the moment I see no way to be "at macosforge" when >> perusing the MacPorts project site. >> >> On Feb 12, 2007, at 1:25 AM, Jordan K. Hubbard wrote: >> >>> That's largely for legacy reasons, but it's also allowed because >>> it's under a different banner. I know that www.macports.org >>> points to the equivalent of macports.macosforge.org right now, >>> but since "macports.org" is notionally an independent site, >>> there's nothing which disallows the project from establishing its >>> own www.macports.org portal and having two different project >>> faces, one at www.macports.org and one at >>> macports.macosforge.org. It's only when people are "at >>> macosforge" that they need to see a consistent L&F in order to >>> meet Apple's style guidelines for macosforge. >> >> -- >> Kevin Ballard >> http://kevin.sb.org >> kevin@sb.org >> http://www.tildesoft.com >> >> > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070212/16097e15/attachment.html From cedric.luthi at gmail.com Mon Feb 12 12:44:37 2007 From: cedric.luthi at gmail.com (=?ISO-8859-1?Q?C=E9dric_Luthi?=) Date: Tue Oct 9 16:39:58 2007 Subject: possible to fetch sources from git repository? In-Reply-To: <20070211221823.GA24478@merlin.in-berlin.de> References: <20070211221823.GA24478@merlin.in-berlin.de> Message-ID: <4404760C-285C-4BDE-AED9-CDC0A81D8A7F@gmail.com> > Some of the sources are only available in git repositories so the > question arise whether it is possible to fetch sources from git > repositories? The man page only mentions cvs repositories. I think you could add depends_build port:git-core in the Portfile and cook your own fetch {} phase that uses ${prefix}/ bin/git-* to retrieve the sources. I never tried but I think it should work. HTH C?dric Luthi From jmpp at macports.org Mon Feb 12 14:14:18 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:39:58 2007 Subject: Fwd: [21973] trunk/dports/java/hibernate3/Portfile Message-ID: <0565d2a55268f31fa9531c7dda27ff3f@macports.org> Hey Kevin! Could I ask you to please take a look at this last commit of mine? You think your recent clean up in trunk/base/ might have something to do with these empty depends_lib lines causing indexing to fail? I can't think of anything else since you're practically the only one hacking on base at the moment (and a big woot for being so brave! ;-) Regards,.. -jmpp Begin forwarded message: > From: source_changes@macosforge.org > Date: February 12, 2007 6:09:23 PM GMT-04:00 > To: macports-changes@lists.macosforge.org > Subject: [21973] trunk/dports/java/hibernate3/Portfile > Reply-To: macports-dev@lists.macosforge.org > > Revision > 21973007-02-12 14:09:23 -0800 (Mon, 12 Feb 2007) > > Log Message > Cleaning another emtpy depends_lib line. This Portfile was last > updated back in December and hadn't failed indexing > until today, which clearly means something new in svn TOT is choking > with these empty lines. Though I do like this > stricter checking, I believe this matter should be looked into. > > Modified Paths > ? trunk/dports/java/hibernate3/Portfile > > Diff > > Modified: trunk/dports/java/hibernate3/Portfile (21972 => 21973) > --- trunk/dports/java/hibernate3/Portfile 2007-02-12 22:05:04 > UTC (rev 21972) > +++ trunk/dports/java/hibernate3/Portfile 2007-02-12 22:09:23 > UTC (rev 21973) > @@ -29,7 +29,6 @@ > bin:ant:apache-ant \ > bin:antlr:antlr \ > port:junit > -depends_lib > > use_configure no > > > _______________________________________________ > macports-changes mailing list > macports-changes@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3086 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070212/e9cb312f/attachment.bin From eridius at macports.org Mon Feb 12 17:38:57 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:39:59 2007 Subject: [21973] trunk/dports/java/hibernate3/Portfile In-Reply-To: <0565d2a55268f31fa9531c7dda27ff3f@macports.org> References: <0565d2a55268f31fa9531c7dda27ff3f@macports.org> Message-ID: Ok, I looked. I believe it has to do with a `set ${option} \$args` line that used to be part of an eval but is no longer. When it was double-evaluated if $args was empty it would evaluate to just `set $ {option}` which does a read, but in the current system it evaluates to the equivalent of `set ${option} {}`, which does a write with an empty value. This fails to validate, and so it raises an error. I believe this to be a good thing. I certainly believe we shouldn't code in a kludge to get the old double-eval behaviour back ;) I assume that with your fixes everything is indexing properly now, yes? So this shouldn't be a problem? -Kevin Ballard On Feb 12, 2007, at 5:14 PM, Juan Manuel Palacios wrote: > Hey Kevin! Could I ask you to please take a look at this last > commit of mine? You think your recent clean up in trunk/base/ might > have something to do with these empty depends_lib lines causing > indexing to fail? I can't think of anything else since you're > practically the only one hacking on base at the moment (and a big > woot for being so brave! ;-) -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070212/e60e7e5b/attachment.html From ryandesign at macports.org Mon Feb 12 21:21:45 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:39:59 2007 Subject: Spacing issues In-Reply-To: <20070211025838.GL12319@prunille.vinc17.org> References: <1B165E06-2367-4852-B292-37C27A0E7F1C@macports.org> <9D32A8FB-CBED-4678-AB0E-8FDB18A21D85@macports.org> <8D6CC819-82B4-4B7F-AC10-0688B92019A6@macports.org> <218E50A3-74B5-4FC3-BFC6-13540128F34E@macports.org> <20070211025838.GL12319@prunille.vinc17.org> Message-ID: On Feb 10, 2007, at 20: