From jmpp at macports.org Fri Jun 1 11:34:51 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:20 2007 Subject: (no subject) Message-ID: <58831F7D-4D6B-4C17-A51E-1B48F52A51FA@macports.org> Good afternoon everyone! At long last, I consider the work on my dp2mp-move branch almost 100% done, 99.99% lets say ;-) Here's a doc explaining all the implications moving to these sources has: http://trac.macports.org/projects/macports/wiki/MacPortsRenaming I'd love to get as much feedback as possible on all the renaming and moves, and an overall opinion of how things look like in a standard MacPorts installation after upgrading to this branch. I ask because this branch moves stuff like "/opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports" to "/opt/local/var/ macports/sources/rsync.macports.org/release/ports", as explained in the wiki doc, so if the chosen new paths are not what the majority regards as the best choice, corrections could be easily made before these sources are distributed to the masses. It is my intention to merge all of the branch back into trunk ASAP, after consensus is reached on best "new conventions", since people writing code against current trunk will surely have to rewrite some parts of it after this is merged, albeit changes will hopefully be small. Nevertheless, I'd very much like to minimize this negative (and quite hateful, I understand) side effect. And finally, I say "almost 100%" and not "100%" because there are still a couple of small pending things, detailed in the "Pending" section of the doc. Taking care of them shouldn't take too long at all (remaining 0.01% ;-) Regards,.... -jmpp PS: The branch mirrors trunk minus sfiera's latest commit, which we could easily merge. Therefore merging should be painless, other than the drawback detailed above. Also, branch has been tested extensively and everything works "as expected", but please do not hesitate to send me any feedback/error reports. Thanks! From jmpp at macports.org Fri Jun 1 11:43:45 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:21 2007 Subject: GSoC2007 work Message-ID: <304E651A-781F-4FBB-A658-B1EE68D67D1E@macports.org> Afternoon all, again! Sfiera already started work on his GSoC2007 project, so big woot for that! However, he committed to trunk since no decision was ever made on how GSoC work was to be coordinated. I can't stress enough how much I would prefer to see this go into a branch for itself, rather than trunk, since we'll probably have three students committing potentially unstable code to the same place at the same time. We're working with an scm system and rolling back to a working revision is always possible should anything bad happen, I know, but with so many things added it can also be a real pain (considering that some others might also commit new code/bug fixes while GSoC takes place)! Again, many reasons to move GSoC work to branches and very little to have it happen right on trunk, in my opinion. I'll make the move if no one presents a case against it, so please speak up if you feel you have valid arguments against moving to branches. Thanks! Regards,... -jmpp From jmpp at macports.org Fri Jun 1 11:48:21 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:21 2007 Subject: dp2mp-move branch work done & merging into trunk Message-ID: <2E029F56-2C69-48A3-8DCA-726C856634BD@macports.org> (same mail as before, resent with a proper subject!) Good afternoon everyone! At long last, I consider the work on my dp2mp-move branch almost 100% done, 99.99% lets say ;-) Here's a doc explaining all the implications moving to these sources has: http://trac.macports.org/projects/macports/wiki/MacPortsRenaming I'd love to get as much feedback as possible on all the renaming and moves, and an overall opinion of how things look like in a standard MacPorts installation after upgrading to this branch. I ask because this branch moves stuff like "/opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports" to "/opt/local/var/ macports/sources/rsync.macports.org/release/ports", as explained in the wiki doc, so if the chosen new paths are not what the majority regards as the best choice, corrections could be easily made before these sources are distributed to the masses. It is my intention to merge all of the branch back into trunk ASAP, after consensus is reached on best "new conventions", since people writing code against current trunk will surely have to rewrite some parts of it after this is merged, albeit changes will hopefully be small. Nevertheless, I'd very much like to minimize this negative (and quite hateful, I understand) side effect. And finally, I say "almost 100%" and not "100%" because there are still a couple of small pending things, detailed in the "Pending" section of the doc. Taking care of them shouldn't take too long at all (remaining 0.01% ;-) Regards,.... -jmpp PS: The branch mirrors trunk minus sfiera's latest commit, which we could easily merge. Therefore merging should be painless, other than the drawback detailed above. Also, branch has been tested extensively and everything works "as expected", but please do not hesitate to send me any feedback/error reports. Thanks! From jberry at macports.org Fri Jun 1 12:01:22 2007 From: jberry at macports.org (James Berry) Date: Tue Oct 9 16:40:21 2007 Subject: GSoC2007 work In-Reply-To: <304E651A-781F-4FBB-A658-B1EE68D67D1E@macports.org> References: <304E651A-781F-4FBB-A658-B1EE68D67D1E@macports.org> Message-ID: <65AF43BC-0390-47A8-BA1F-B61ED947EF4C@macports.org> Hi Juan, On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote: > > Afternoon all, again! Sfiera already started work on his GSoC2007 > project, so big woot for that! However, he committed to trunk since > no decision was ever made on how GSoC work was to be coordinated. I > can't stress enough how much I would prefer to see this go into a > branch for itself, rather than trunk, since we'll probably have > three students committing potentially unstable code to the same > place at the same time. We're working with an scm system and > rolling back to a working revision is always possible should > anything bad happen, I know, but with so many things added it can > also be a real pain (considering that some others might also commit > new code/bug fixes while GSoC takes place)! > > Again, many reasons to move GSoC work to branches and very little > to have it happen right on trunk, in my opinion. I'll make the move > if no one presents a case against it, so please speak up if you > feel you have valid arguments against moving to branches. Thanks! I'm strongly in favor of giving the GSoC students and their mentors the latitude to decide which components of their projects should be commited on a branch, and which to trunk. I believe that choice will depend on a number of factors including the nature of the change, how risky it is, how long it will take to stability, etc. In general, however, I have a preference that changes should be made on trunk unless they are destabilizing over a long period or are regarded as strictly experimental. I believe that sfiera's recent change to sqlite3 is an excellant example of something that _should_ be done on trunk: it's relatively antonymous, low-risk, and generally useful. James. > Regards,... > > > -jmpp > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From anant at kix.in Fri Jun 1 12:09:28 2007 From: anant at kix.in (Anant Narayanan) Date: Tue Oct 9 16:40:21 2007 Subject: GSoC2007 work In-Reply-To: <65AF43BC-0390-47A8-BA1F-B61ED947EF4C@macports.org> References: <304E651A-781F-4FBB-A658-B1EE68D67D1E@macports.org> <65AF43BC-0390-47A8-BA1F-B61ED947EF4C@macports.org> Message-ID: <46606EE8.7060309@kix.in> James Berry wrote: > I'm strongly in favor of giving the GSoC students and their mentors the > latitude to decide which components of their projects should be commited > on a branch, and which to trunk. I believe that choice will depend on a > number of factors including the nature of the change, how risky it is, > how long it will take to stability, etc. In general, however, I have a > preference that changes should be made on trunk unless they are > destabilizing over a long period or are regarded as strictly experimental. > > I believe that sfiera's recent change to sqlite3 is an excellant example > of something that _should_ be done on trunk: it's relatively antonymous, > low-risk, and generally useful. Please do keep in mind that the students are required to submit a URL and possibly even upload code that they have authored during the summer to code.google.com at the end of the term. Committing directly to trunk poses a practical problem as it will be difficult for the students to distinctly show their work for audit. I see no harm in instructing the students to commit primarily to a branch and *then* cherry-picking out the commits that would be of immediate benefit into trunk. Cheers, -- Anant From markd at macports.org Fri Jun 1 12:14:48 2007 From: markd at macports.org (markd@macports.org) Date: Tue Oct 9 16:40:21 2007 Subject: Startupitems don't work as advertised Message-ID: It has come to my attention that startupitems are not disabled by default. Yet they were intended to be as shown by the message: ########################################################### # A startup item has been generated that will aid in # starting XXXX with launchd. It is disabled # by default. Execute the following command to start it, # and to cause it to launch at startup: # # sudo launchctl load -w /Library/LaunchDaemons/org.macports.XXXX.plist ########################################################### Yet startupitems have this by default: Disabled Can anyone shed light on this behavior? Mark From jberry at macports.org Fri Jun 1 12:23:23 2007 From: jberry at macports.org (James Berry) Date: Tue Oct 9 16:40:21 2007 Subject: Startupitems don't work as advertised In-Reply-To: References: Message-ID: <82458CB7-704B-43ED-9A71-17DFAB94B1F2@macports.org> Hi Mark, On Jun 1, 2007, at 12:14 PM, markd@macports.org wrote: > It has come to my attention that startupitems are not disabled by > default. > Yet they were intended to be as shown by the message: > > > ########################################################### > # A startup item has been generated that will aid in > # starting XXXX with launchd. It is disabled > # by default. Execute the following command to start it, > # and to cause it to launch at startup: > # > # sudo launchctl load -w /Library/LaunchDaemons/ > org.macports.XXXX.plist > ########################################################### > > > Yet startupitems have this by default: > > Disabled > > Can anyone shed light on this behavior? Hmm. A discrepancy between the documentation and the code. Which way should we change it? (a) Change the emitted text to say that startup item will be started at reboot or if the load command is given, or (b) Default the key to true, and leave the emitted text as it is. Personally, I think (b) is better. Your thoughts? James From jmpp at macports.org Fri Jun 1 12:29:52 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:21 2007 Subject: GSoC2007 work In-Reply-To: <46606EE8.7060309@kix.in> References: <304E651A-781F-4FBB-A658-B1EE68D67D1E@macports.org> <65AF43BC-0390-47A8-BA1F-B61ED947EF4C@macports.org> <46606EE8.7060309@kix.in> Message-ID: <0DFE2410-DC07-48FC-8C2C-8A2B652E3F8D@macports.org> On Jun 1, 2007, at 3:09 PM, Anant Narayanan wrote: > James Berry wrote: >> I'm strongly in favor of giving the GSoC students and their >> mentors the >> latitude to decide which components of their projects should be >> commited >> on a branch, and which to trunk. I believe that choice will depend >> on a >> number of factors including the nature of the change, how risky it >> is, >> how long it will take to stability, etc. In general, however, I >> have a >> preference that changes should be made on trunk unless they are >> destabilizing over a long period or are regarded as strictly >> experimental. >> >> I believe that sfiera's recent change to sqlite3 is an excellant >> example >> of something that _should_ be done on trunk: it's relatively >> antonymous, >> low-risk, and generally useful. > > Please do keep in mind that the students are required to submit a URL > and possibly even upload code that they have authored during the > summer > to code.google.com at the end of the term. Committing directly to > trunk > poses a practical problem as it will be difficult for the students to > distinctly show their work for audit. > > I see no harm in instructing the students to commit primarily to a > branch and *then* cherry-picking out the commits that would be of > immediate benefit into trunk. > > Cheers, > -- > Anant Thanks for the hint Anant! Though I do not oppose jberry's argument, I believe this is yet one more reason to isolate GSoC commits in dedicated branches. Regards,... -jmpp From dluke at geeklair.net Fri Jun 1 12:33:01 2007 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue Oct 9 16:40:21 2007 Subject: Startupitems don't work as advertised In-Reply-To: <82458CB7-704B-43ED-9A71-17DFAB94B1F2@macports.org> References: <82458CB7-704B-43ED-9A71-17DFAB94B1F2@macports.org> Message-ID: <2F354DA3-1BFA-4E6B-AAC8-0426D2B17C48@geeklair.net> On Jun 1, 2007, at 3:23 PM, James Berry wrote: > Which way should we change it? > > (a) Change the emitted text to say that startup item will be > started at reboot or if the load command is given, > > or (b) Default the key to true, and leave the emitted text as it is. > > Personally, I think (b) is better. > > Your thoughts? b I prefer having that extra chance to make sure I really want to run some daemon (especially if it's going to be listening on a network). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070601/24a27731/PGP.bin From markd at macports.org Fri Jun 1 12:35:27 2007 From: markd at macports.org (markd@macports.org) Date: Tue Oct 9 16:40:21 2007 Subject: Startupitems don't work as advertised In-Reply-To: <82458CB7-704B-43ED-9A71-17DFAB94B1F2@macports.org> References: <82458CB7-704B-43ED-9A71-17DFAB94B1F2@macports.org> Message-ID: James Berry on Friday, June 1, 2007 at 12:23 PM -0800 wrote: >> It has come to my attention that startupitems are not disabled by >> default. >> Yet they were intended to be as shown by the message: >> >> >> ########################################################### >> # A startup item has been generated that will aid in >> # starting XXXX with launchd. It is disabled >> # by default. Execute the following command to start it, >> # and to cause it to launch at startup: >> # >> # sudo launchctl load -w /Library/LaunchDaemons/ >> org.macports.XXXX.plist >> ########################################################### >> >> >> Yet startupitems have this by default: >> >> Disabled >> >> Can anyone shed light on this behavior? > >Hmm. A discrepancy between the documentation and the code. > >Which way should we change it? > > (a) Change the emitted text to say that startup item will be >started at reboot or if the load command is given, > >or (b) Default the key to true, and leave the emitted text as it is. > >Personally, I think (b) is better. > >Your thoughts? I agree that B is better. Option (a) presents security problems, and making server variants only to avoid those security problems has the consequence that that a port rebuild is required just to get the .plist file. So B seems like a far better choice to me. Mark From chpickel at stwing.upenn.edu Fri Jun 1 12:36:12 2007 From: chpickel at stwing.upenn.edu (Chris Pickel) Date: Tue Oct 9 16:40:21 2007 Subject: GSoC2007 work In-Reply-To: <46606EE8.7060309@kix.in> References: <304E651A-781F-4FBB-A658-B1EE68D67D1E@macports.org> <65AF43BC-0390-47A8-BA1F-B61ED947EF4C@macports.org> <46606EE8.7060309@kix.in> Message-ID: <73778C7E-F8EC-423E-BECA-E12455A50A15@stwing.upenn.edu> On 01 Jun, 2007, at 14:43, Juan Manuel Palacios wrote: > Again, many reasons to move GSoC work to branches and very little > to have it happen right on trunk, in my opinion. I'll make the move > if no one presents a case against it, so please speak up if you > feel you have valid arguments against moving to branches. Thanks! Keep in mind, one of the biggest reasons not to branch is the same reason you're encountering now: feedback. In general, I think the best solution is to work in trunk with hooks that disable the new behavior for users who aren't adventurous. That lowers the barrier for feedback, while keeping it up for safety. On 01 Jun, 2007, at 15:09, Anant Narayanan wrote: > Please do keep in mind that the students are required to submit a URL > and possibly even upload code that they have authored during the > summer > to code.google.com at the end of the term. Committing directly to > trunk > poses a practical problem as it will be difficult for the students to > distinctly show their work for audit. This should not be a problem. My project will produce a fairly sizable body of code that's completely new, which can be shown to Google. The logic to hook that code into the rest of MacPorts doesn't really need to be shown, and it would be difficult to separate this out even in a branch. Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070601/655e36a9/PGP.bin From davidm at astro.berkeley.edu Fri Jun 1 12:45:47 2007 From: davidm at astro.berkeley.edu (David MacMahon) Date: Tue Oct 9 16:40:21 2007 Subject: dp2mp-move branch work done & merging into trunk In-Reply-To: <2E029F56-2C69-48A3-8DCA-726C856634BD@macports.org> References: <2E029F56-2C69-48A3-8DCA-726C856634BD@macports.org> Message-ID: Sounds great! Will this automatically affect the gcc binary names (i.e. gcc-dp-4.2 -> gcc-mp-4.2) or is a port specific change needed? Thanks, Dave From ryandesign at macports.org Fri Jun 1 13:11:40 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:21 2007 Subject: configure script of "macports" should not link against "/usr/local/" In-Reply-To: References: Message-ID: On Jun 1, 2007, at 00:04, markd@macports.org wrote: > Could someone with more programming skills than I comment on this > ticket? > A user thinks there should be a global fix to the problem we have > with a > manually installed readline. I think this must be done on a case- > by-case > basis. Am I missing something? > > http://trac.macports.org/projects/macports/ticket/12041 My read of the ticket is that he wasn't asking us to fix the configure scripts of any particular port, but of MacPorts itself. He was saying not that some particular port was linking against a readline in /usr/local, but that the MacPorts "port" binary itself was linking against that readline. He would like us to fix the MacPorts configure script so that MacPorts itself does not link against things in /usr/local. I don't know if that's still an issue with 1.4.42, nor if it is, how or whether it can be fixed. From jmpp at macports.org Fri Jun 1 12:47:22 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:21 2007 Subject: Startupitems don't work as advertised In-Reply-To: <2F354DA3-1BFA-4E6B-AAC8-0426D2B17C48@geeklair.net> References: <82458CB7-704B-43ED-9A71-17DFAB94B1F2@macports.org> <2F354DA3-1BFA-4E6B-AAC8-0426D2B17C48@geeklair.net> Message-ID: On Jun 1, 2007, at 3:33 PM, Daniel J. Luke wrote: > On Jun 1, 2007, at 3:23 PM, James Berry wrote: >> Which way should we change it? >> >> (a) Change the emitted text to say that startup item will be >> started at reboot or if the load command is given, >> >> or (b) Default the key to true, and leave the emitted text as it is. >> >> Personally, I think (b) is better. >> >> Your thoughts? > > b > > I prefer having that extra chance to make sure I really want to run > some daemon (especially if it's going to be listening on a network). > -- > Daniel J. Luke Seconded! -jmpp From jmpp at macports.org Fri Jun 1 12:50:17 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:21 2007 Subject: dp2mp-move branch work done & merging into trunk In-Reply-To: References: <2E029F56-2C69-48A3-8DCA-726C856634BD@macports.org> Message-ID: <5ABBCAF8-C9B0-4AD7-9E1A-16B2AD3B6D73@macports.org> On Jun 1, 2007, at 3:45 PM, David MacMahon wrote: > Sounds great! Thanks for the feedback! (even if it is only to tell me that things look good overall ;-) Appreciated! > Will this automatically affect the gcc binary names (i.e. gcc- > dp-4.2 -> gcc-mp-4.2) or is a port specific change needed? This is a port specific change, but one I believe mww already put in place. Nevertheless, strings in MP base sources referencing gcc-dp* have been updated to gcc-mp*, so there should be added consistency. > > Thanks, > Dave > Regards,... -jmpp From ryandesign at macports.org Fri Jun 1 13:13:59 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:21 2007 Subject: dp2mp-move branch work done & merging into trunk In-Reply-To: References: <2E029F56-2C69-48A3-8DCA-726C856634BD@macports.org> Message-ID: <4557E6FD-3885-45FA-B47F-D55ED8405927@macports.org> On Jun 1, 2007, at 14:45, David MacMahon wrote: > Sounds great! Will this automatically affect the gcc binary names > (i.e. gcc-dp-4.2 -> gcc-mp-4.2) or is a port specific change needed? Changes will be needed to each port. gcc42 already installs itself as gcc-mp-42 since 2007-04-27. From chpickel at stwing.upenn.edu Fri Jun 1 14:03:42 2007 From: chpickel at stwing.upenn.edu (Chris Pickel) Date: Tue Oct 9 16:40:21 2007 Subject: Startupitems don't work as advertised In-Reply-To: <82458CB7-704B-43ED-9A71-17DFAB94B1F2@macports.org> References: <82458CB7-704B-43ED-9A71-17DFAB94B1F2@macports.org> Message-ID: On 01 Jun, 2007, at 15:23, James Berry wrote: > or (b) Default the key to true, and leave the emitted text as it is. Actually, this introduces another problem; asking launchctl to load a disabled script (as many ports now do) won't cause it to run. To fix this, the text will need to be edited in all such ports. It should tell the user to edit the launchd script and change that flag. Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070601/61d5d1fe/PGP.bin From ryandesign at macports.org Fri Jun 1 14:07:44 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:21 2007 Subject: Startupitems don't work as advertised In-Reply-To: References: <82458CB7-704B-43ED-9A71-17DFAB94B1F2@macports.org> Message-ID: On Jun 1, 2007, at 16:03, Chris Pickel wrote: > On 01 Jun, 2007, at 15:23, James Berry wrote: > >> or (b) Default the key to true, and leave the emitted text as it is. > > Actually, this introduces another problem; asking launchctl to load > a disabled script (as many ports now do) won't cause it to run. To > fix this, the text will need to be edited in all such ports. It > should tell the user to edit the launchd script and change that flag. What? No no no. That's what the -w flag to launchctl is for -- to add or remove the "disabled" key. And port already outputs instructions which tell you to use -w when calling launchctl. From the first mail in this thread: > ########################################################### > # A startup item has been generated that will aid in > # starting XXXX with launchd. It is disabled > # by default. Execute the following command to start it, > # and to cause it to launch at startup: > # > # sudo launchctl load -w /Library/LaunchDaemons/ > org.macports.XXXX.plist > ########################################################### From chpickel at stwing.upenn.edu Fri Jun 1 14:08:58 2007 From: chpickel at stwing.upenn.edu (Chris Pickel) Date: Tue Oct 9 16:40:21 2007 Subject: Startupitems don't work as advertised In-Reply-To: References: <82458CB7-704B-43ED-9A71-17DFAB94B1F2@macports.org> Message-ID: <2BEFC7F8-C7C3-4B5A-AB37-DD3BBF0B8149@stwing.upenn.edu> On 01 Jun, 2007, at 17:03, Chris Pickel wrote: > Actually, this introduces another problem; asking launchctl to load > a disabled script (as many ports now do) won't cause it to run. To > fix this, the text will need to be edited in all such ports. It > should tell the user to edit the launchd script and change that flag. Oops. It has been brought to my attention that the instructions include the "-w" flag, which has that exact behavior. My previous message can be safely ignored. Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070601/48b6eacc/PGP.bin From yeled at macports.org Sat Jun 2 12:53:18 2007 From: yeled at macports.org (Charlie Allom) Date: Tue Oct 9 16:40:21 2007 Subject: dp2mp-move branch work done & merging into trunk In-Reply-To: <2E029F56-2C69-48A3-8DCA-726C856634BD@macports.org> References: <2E029F56-2C69-48A3-8DCA-726C856634BD@macports.org> Message-ID: <20070602195316.GA1553@eatyourpets.com> On Fri, Jun 01, 2007 at 02:48:21PM -0400, Juan Manuel Palacios wrote: > > detailed above. Also, branch has been tested extensively and everything Juan - can you detail specific instructions for testing the branch? I'm sure some people would be happy to help test some more.. and do you have an ETA on when you would like to merge? C. -- hail eris http://rubberduck.com/ From jberry at macports.org Sat Jun 2 22:51:18 2007 From: jberry at macports.org (James Berry) Date: Tue Oct 9 16:40:21 2007 Subject: [25283] trunk/base/src In-Reply-To: References: <20070517044407.D43825FE258@cvs.opensource.apple.com> Message-ID: <94F997DE-FB84-4B8F-AE52-A5BA404FD395@macports.org> On May 17, 2007, at 1:58 AM, Ryan Schmidt wrote: >>> outdated or installed expands to no ports). prints the path to >>> the workdir, if there is one. These changes make it possible to >>> have a port repository that is entirely readonly and not written >>> to during build, etc. Note that by keeping place_worksymlink at >>> its default value of yes, no behavior should be changed for the >>> user/developer. (until we decide to default this to no ;). There >>> exists about three ports that use workdir, and these will need to >>> be modified to use workpath instead. > > Looks like ten ports are affected: > > $ grep '{workdir}' */*/Portfile | cut -d ':' -f 1 | uniq > aqua/AssignmentTrackerX/Portfile > aqua/Lingon/Portfile > aqua/MorsX/Portfile > aqua/Smultron/Portfile > devel/perforce/Portfile > irc/infobot/Portfile > net/arpwatch/Portfile > news/nnap/Portfile > x11/gtk-extra/Portfile > x11/gtk2-extra/Portfile Thanks Ryan, I just went through and changed each of these that hadn't already been fixed. James From rhwood at mac.com Sun Jun 3 07:32:09 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:21 2007 Subject: [25842] trunk/dports/audio/esound/Portfile In-Reply-To: <20070603142041.58A8662ECB8@cvs.opensource.apple.com> References: <20070603142041.58A8662ECB8@cvs.opensource.apple.com> Message-ID: Forgot to mention a whitespace change in the patchfiles list unrelated to any other changes. Sorry about that. On 3 Jun 2007, at 10:20, source_changes@macosforge.org wrote: > Revision 25842 Author rhwood@macports.org Date 2007-06-03 07:20:41 > -0700 (Sun, 03 Jun 2007) Log MessageUpgrade to version 0.2.38 Add > md5 and rmd160 checksums Claim maintainership Change dependencies > into port:-style dependencies Add some dependencies based on trace > output (and then accidentally delete my logs so that I don't get > all of the dependencies) Add explicit --enable-local-sound > configure argument Fix variant puredarwin to account for --enable- > local-sound (should this variant be a platform statement instead?) > Comment out pre-configure commands since they don't seem to have > any effect (please correct me if I'm wrong)Modified Paths > trunk/dports/audio/esound/Portfile > Diff > Modified: trunk/dports/audio/esound/Portfile (25841 => 25842)--- > trunk/dports/audio/esound/Portfile 2007-06-03 14:18:20 UTC (rev > 25841) +++ trunk/dports/audio/esound/Portfile 2007-06-03 14:20:41 > UTC (rev 25842) @@ -2,25 +2,35 @@ PortSystem 1.0 name esound - > version 0.2.37 +version 0.2.38 revision 1 categories audio - > maintainers nomaintainer@macports.org +maintainers > rhwood@macports.org openmaintainer@macports.org description > Enlightened Sound Daemon homepage http://www.tux.org/~ricdude/ > EsounD.html platforms darwin master_sites gnome:sources/esound/0.2 > use_autoconf yes use_bzip2 yes -depends_lib lib:audiofile. > 0:audiofile -depends_build path:${prefix}/bin/aclocal:automake \ - > path:${prefix}/bin/glibtool:libtool -checksums sha1 > f5fd4a138598b01471907cd758077513c45a0dc4 -configure.args --enable- > ipv6 --with-audiofile -patchfiles patch-esd.conf patch-esd_config.c > +depends_lib port:audiofile +checksums sha1 > 29133b0acd17ddac10c3a6769afa40a7cb596c91 \ + md5 > 1c48c100b450d617b58dacb59837d34f \ + rmd160 > d12605bcd24b697a5525b0e266d2bbca43edea32 +configure.args \ + -- > enable-ipv6 \ + --with-audiofile \ + --enable-local-sound > +patchfiles \ + patch-esd.conf \ + patch-esd_config.c > +build_depends \ + port:autoconf \ + port:perl5.8 \ + > port:pkgconfig variant puredarwin { - configure.args-append -- > disable-local-sound + configure.args-delete --enable-local-sound + > configure.args-append --disable-local-sound } long_description > EsounD, the Enlightened Sound Daemon, is a server \ @@ -30,9 +40,7 > @@ sound-related event from ICQ, the two applications won't \ have > to jockey for the use of your sound card. -pre-configure { cd $ > {worksrcpath} - system "env LIBTOOLIZE=${prefix}/bin/glibtoolize > autoreconf -vif" - } +#pre-configure { cd ${worksrcpath} +# > system "env LIBTOOLIZE=${prefix}/bin/glibtoolize autoreconf -vif" > +# } - - > _______________________________________________ > macports-changes mailing list > macports-changes@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From mmoll at cs.rice.edu Sun Jun 3 07:40:13 2007 From: mmoll at cs.rice.edu (Mark Moll) Date: Tue Oct 9 16:40:21 2007 Subject: [25728] trunk/dports/python/py-numpy In-Reply-To: References: <20070530030631.5D882627611@cvs.opensource.apple.com> Message-ID: On May 30, 2007, at 7:44 AM, Jochen K?pper wrote: > On 30.05.2007, at 05:06, source_changes@macosforge.org wrote: > >> updated to py-numpy version 1.0.3 swapped dependency from gcc41/ >> gcc42 to g95, much to the joy of everyone > > Not for me! > I very much prefer gfortran over g95 for various reasons -- > performance and political ones. > > Why don't you create variants for either fortran compiler, or use > the one that is already installed? Also, gcc42 seems to be the de facto choice for a fortran compiler for almost every other port: > grep depends `grep -rl fortran */*/Portfile`|grep gcc42 graphics/pgplot/Portfile: depends_lib-append port:gcc42 lang/gcc42/Portfile:depends_lib port:gmp port:mpfr port:libiconv lang/gcc42/Portfile: depends_lib-append bin:odas:odcctools math/R/Portfile: depends_lib-append port:gcc42 math/arpack/Portfile:depends_build port:gcc42 math/octave-forge/Portfile: depends_lib-append port:gcc42 math/octave/Portfile: depends_lib-append port:gcc42 science/libnc-dap/Portfile: depends_lib-append port:gcc42 science/openmpi/Portfile: depends_build port:gcc42 > grep depends `grep -rl fortran */*/Portfile`|grep g95 math/fftw-3/Portfile: depends_lib-append port:g95 math/octave-forge/Portfile: depends_lib-append port:g95 math/octave/Portfile: depends_lib-append port:g95 science/libnc-dap/Portfile: depends_lib-append port:g95 In the ports that use g95 it is used as a variant. Perhaps one fortran compiler should be the "*officially* recommended fortran compiler," while the others can be made available in variants. I'd vote for gcc42 to provide the official fortran compiler, since it's already the de facto standard, plus---as Jochen writes---there are performance and political reasons to favor gcc42. -- Mark From jberry at macports.org Sun Jun 3 09:54:00 2007 From: jberry at macports.org (James Berry) Date: Tue Oct 9 16:40:21 2007 Subject: Two ports with name libgda Message-ID: Hey guys, Investigating a discrepancy between port count numbers between PortIndex and db.macports.org, I see that we have two ports with the same name: The ports with file names libgda and libgda3 both carry port name libgda. I assume libgda3 should be named libgda3? James From n.oxyde at gmail.com Sun Jun 3 09:59:41 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:21 2007 Subject: [25842] trunk/dports/audio/esound/Portfile In-Reply-To: References: <20070603142041.58A8662ECB8@cvs.opensource.apple.com> Message-ID: <42EF908B-D72E-4E91-A2A7-038D599EAAED@gmail.com> By the way i've just fixed a little typo in it, you wrote build_depends instead of depends_build. Le 3 juin 07 ? 16:32, Randall Wood a ?crit : > Forgot to mention a whitespace change in the patchfiles list > unrelated to any other changes. Sorry about that. > On 3 Jun 2007, at 10:20, source_changes@macosforge.org wrote: > >> Revision 25842 Author rhwood@macports.org Date 2007-06-03 07:20:41 >> -0700 (Sun, 03 Jun 2007) Log MessageUpgrade to version 0.2.38 Add >> md5 and rmd160 checksums Claim maintainership Change dependencies >> into port:-style dependencies Add some dependencies based on trace >> output (and then accidentally delete my logs so that I don't get >> all of the dependencies) Add explicit --enable-local-sound >> configure argument Fix variant puredarwin to account for --enable- >> local-sound (should this variant be a platform statement instead?) >> Comment out pre-configure commands since they don't seem to have >> any effect (please correct me if I'm wrong)Modified Paths >> trunk/dports/audio/esound/Portfile >> Diff >> Modified: trunk/dports/audio/esound/Portfile (25841 => 25842)--- >> trunk/dports/audio/esound/Portfile 2007-06-03 14:18:20 UTC (rev >> 25841) +++ trunk/dports/audio/esound/Portfile 2007-06-03 14:20:41 >> UTC (rev 25842) @@ -2,25 +2,35 @@ PortSystem 1.0 name esound - >> version 0.2.37 +version 0.2.38 revision 1 categories audio - >> maintainers nomaintainer@macports.org +maintainers >> rhwood@macports.org openmaintainer@macports.org description >> Enlightened Sound Daemon homepage http://www.tux.org/~ricdude/ >> EsounD.html platforms darwin master_sites gnome:sources/esound/0.2 >> use_autoconf yes use_bzip2 yes -depends_lib lib:audiofile. >> 0:audiofile -depends_build path:${prefix}/bin/aclocal:automake \ >> - path:${prefix}/bin/glibtool:libtool -checksums sha1 >> f5fd4a138598b01471907cd758077513c45a0dc4 -configure.args --enable- >> ipv6 --with-audiofile -patchfiles patch-esd.conf patch- >> esd_config.c +depends_lib port:audiofile +checksums sha1 >> 29133b0acd17ddac10c3a6769afa40a7cb596c91 \ + md5 >> 1c48c100b450d617b58dacb59837d34f \ + rmd160 >> d12605bcd24b697a5525b0e266d2bbca43edea32 +configure.args \ + -- >> enable-ipv6 \ + --with-audiofile \ + --enable-local-sound >> +patchfiles \ + patch-esd.conf \ + patch-esd_config.c >> +build_depends \ + port:autoconf \ + port:perl5.8 \ + >> port:pkgconfig variant puredarwin { - configure.args-append -- >> disable-local-sound + configure.args-delete --enable-local-sound + >> configure.args-append --disable-local-sound } long_description >> EsounD, the Enlightened Sound Daemon, is a server \ @@ -30,9 +40,7 >> @@ sound-related event from ICQ, the two applications won't \ have >> to jockey for the use of your sound card. -pre-configure { cd $ >> {worksrcpath} - system "env LIBTOOLIZE=${prefix}/bin/glibtoolize >> autoreconf -vif" - } +#pre-configure { cd ${worksrcpath} +# >> system "env LIBTOOLIZE=${prefix}/bin/glibtoolize autoreconf -vif" >> +# } - - >> _______________________________________________ >> macports-changes mailing list >> macports-changes@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-changes > > > > Randall Wood > rhwood@mac.com > http://shyramblings.blogspot.com > > "The rules are simple: The ball is round. The game lasts 90 > minutes. All the > rest is just philosophy." > > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev -- Anthony Ramine, a lazy french student. nox@macports.org From rhwood at mac.com Sun Jun 3 10:09:03 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:21 2007 Subject: Two ports with name libgda In-Reply-To: References: Message-ID: On 3 Jun 2007, at 12:54, James Berry wrote: > Hey guys, > > Investigating a discrepancy between port count numbers between > PortIndex and db.macports.org, I see that we have two ports with > the same name: > > The ports with file names libgda and libgda3 both carry port name > libgda. I assume libgda3 should be named libgda3? Correct. Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From rhwood at mac.com Sun Jun 3 10:31:04 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:21 2007 Subject: Two ports with name libgda In-Reply-To: References: Message-ID: <1CB7B931-9E7F-4DE6-8E51-FFC3D15D03C5@mac.com> I think I fixed this in changeset:25849 On 3 Jun 2007, at 13:09, Randall Wood wrote: > > On 3 Jun 2007, at 12:54, James Berry wrote: > >> Hey guys, >> >> Investigating a discrepancy between port count numbers between >> PortIndex and db.macports.org, I see that we have two ports with >> the same name: >> >> The ports with file names libgda and libgda3 both carry port name >> libgda. I assume libgda3 should be named libgda3? > > Correct. > > Randall Wood > rhwood@mac.com > http://shyramblings.blogspot.com > > "The rules are simple: The ball is round. The game lasts 90 > minutes. All the > rest is just philosophy." > > Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From ryandesign at macports.org Sun Jun 3 22:21:07 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:21 2007 Subject: [25842] trunk/dports/audio/esound/Portfile In-Reply-To: References: <20070603142041.58A8662ECB8@cvs.opensource.apple.com> Message-ID: <6DB27C09-9AD7-4E4D-AA6C-73BF4B47309A@macports.org> Then you should correct your log message by typing: $ svn propedit --revprop -r 25842 svn:log https://svn.macosforge.org/ repository/macports/trunk And, again, to the powers that be, we need a post-revprop-change hook, in addition to the existing post-commit hook, to send email to macports-changes when someone changes a revision property. On Jun 3, 2007, at 09:32, Randall Wood wrote: > Forgot to mention a whitespace change in the patchfiles list > unrelated to any other changes. Sorry about that. > > > On Jun 3, 2007, at 09:20, source_changes@macosforge.org wrote: > >> Revision: 25842 >> http://trac.macosforge.org/projects/macports/changeset/ >> 25842 >> Author: rhwood@macports.org >> Date: 2007-06-03 07:20:41 -0700 (Sun, 03 Jun 2007) >> >> Log Message: >> ----------- >> Upgrade to version 0.2.38 >> Add md5 and rmd160 checksums >> Claim maintainership >> Change dependencies into port:-style dependencies >> Add some dependencies based on trace output (and then accidentally >> delete my logs so that I don't get all of the dependencies) >> Add explicit --enable-local-sound configure argument >> Fix variant puredarwin to account for --enable-local-sound (should >> this variant be a platform statement instead?) >> Comment out pre-configure commands since they don't seem to have >> any effect (please correct me if I'm wrong) >> >> Modified Paths: >> -------------- >> trunk/dports/audio/esound/Portfile >> >> Modified: trunk/dports/audio/esound/Portfile >> =================================================================== >> --- trunk/dports/audio/esound/Portfile 2007-06-03 14:18:20 UTC >> (rev 25841) >> +++ trunk/dports/audio/esound/Portfile 2007-06-03 14:20:41 UTC >> (rev 25842) >> @@ -2,25 +2,35 @@ >> >> PortSystem 1.0 >> name esound >> -version 0.2.37 >> +version 0.2.38 >> revision 1 >> categories audio >> -maintainers nomaintainer@macports.org >> +maintainers rhwood@macports.org openmaintainer@macports.org >> description Enlightened Sound Daemon >> homepage http://www.tux.org/~ricdude/EsounD.html >> platforms darwin >> master_sites gnome:sources/esound/0.2 >> use_autoconf yes >> use_bzip2 yes >> -depends_lib lib:audiofile.0:audiofile >> -depends_build path:${prefix}/bin/aclocal:automake \ >> - path:${prefix}/bin/glibtool:libtool >> -checksums sha1 f5fd4a138598b01471907cd758077513c45a0dc4 >> -configure.args --enable-ipv6 --with-audiofile >> -patchfiles patch-esd.conf patch-esd_config.c >> +depends_lib port:audiofile >> +checksums sha1 29133b0acd17ddac10c3a6769afa40a7cb596c91 \ >> + md5 1c48c100b450d617b58dacb59837d34f \ >> + rmd160 d12605bcd24b697a5525b0e266d2bbca43edea32 >> +configure.args \ >> + --enable-ipv6 \ >> + --with-audiofile \ >> + --enable-local-sound >> +patchfiles \ >> + patch-esd.conf \ >> + patch-esd_config.c >> +build_depends \ >> + port:autoconf \ >> + port:perl5.8 \ >> + port:pkgconfig >> >> variant puredarwin { >> - configure.args-append --disable-local-sound >> + configure.args-delete --enable-local-sound >> + configure.args-append --disable-local-sound >> } >> >> long_description EsounD, the Enlightened Sound Daemon, is a server \ >> @@ -30,9 +40,7 @@ >> sound-related event from ICQ, the two applications won't \ >> have to jockey for the use of your sound card. >> >> -pre-configure { cd ${worksrcpath} >> - system "env LIBTOOLIZE=${prefix}/bin/glibtoolize autoreconf - >> vif" >> - } >> +#pre-configure { cd ${worksrcpath} >> +# system "env LIBTOOLIZE=${prefix}/bin/glibtoolize autoreconf - >> vif" >> +# } >> >> - >> - >> >> _______________________________________________ >> macports-changes mailing list >> macports-changes@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-changes > From ryandesign at macports.org Sun Jun 3 23:16:09 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:21 2007 Subject: UPDATE: take maintainership of sysutils/duplicity In-Reply-To: <799406d60705270703w6df3a8fpdf53fdb7b70ab8@mail.gmail.com> References: <799406d60705261405t2fb2155foad1e32a17c58f559@mail.gmail.com> <485EF84F-108B-4362-84B2-5ACD9CD3AB3C@macports.org> <799406d60705270703w6df3a8fpdf53fdb7b70ab8@mail.gmail.com> Message-ID: On May 27, 2007, at 09:03, Adam Mercer wrote: > On 27/05/07, Ryan Schmidt wrote: > >> If you want to submit another patch that just reformats the port or >> just makes other substantive changes, I can commit that too. > > Attached. And committed! http://trac.macosforge.org/projects/macports/changeset/25862 From cedric.luthi at gmail.com Mon Jun 4 01:42:44 2007 From: cedric.luthi at gmail.com (=?ISO-8859-1?Q?C=E9dric_Luthi?=) Date: Tue Oct 9 16:40:21 2007 Subject: Ticket #12042 (NEW AtomicParsley port) Message-ID: <49108774-D1B3-4EB1-8EAF-C4DE65C3CCC8@epfl.ch> It seems nobody committed the new AtomicParsley port I submitted a few days ago :-( http://trac.macosforge.org/projects/macports/ticket/12042 C?dric Luthi -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1938 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070604/b1453d55/smime.bin From rhwood at mac.com Mon Jun 4 02:59:48 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:21 2007 Subject: Ticket #12042 (NEW AtomicParsley port) In-Reply-To: <49108774-D1B3-4EB1-8EAF-C4DE65C3CCC8@epfl.ch> References: <49108774-D1B3-4EB1-8EAF-C4DE65C3CCC8@epfl.ch> Message-ID: <616AAC67-8C65-4B1F-B2DA-78BC3B9DFE30@mac.com> Done. See changeset:25877 On 4 Jun 2007, at 04:42, C?dric Luthi wrote: > It seems nobody committed the new AtomicParsley port I submitted a > few days ago :-( > http://trac.macosforge.org/projects/macports/ticket/12042 > > C?dric Luthi_______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From jkh at brierdr.com Fri Jun 1 19:10:38 2007 From: jkh at brierdr.com (Jordan K. Hubbard) Date: Tue Oct 9 16:40:21 2007 Subject: GSoC2007 work In-Reply-To: <46606EE8.7060309@kix.in> References: <304E651A-781F-4FBB-A658-B1EE68D67D1E@macports.org> <65AF43BC-0390-47A8-BA1F-B61ED947EF4C@macports.org> <46606EE8.7060309@kix.in> Message-ID: <28042131-CBD3-4C0B-843E-857497BA471E@brierdr.com> On Jun 1, 2007, at 12:09 PM, Anant Narayanan wrote: > Please do keep in mind that the students are required to submit a URL > and possibly even upload code that they have authored during the > summer > to code.google.com at the end of the term. Committing directly to > trunk > poses a practical problem as it will be difficult for the students to > distinctly show their work for audit. I don't think that's true with Subversion. It's more than possible to demonstrate the changes between tags or cite specific changes by URL. Branches don't even really exist in subversion as far as that's concerned, they're just another type of tag. - Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070601/83ffdd7d/attachment.html From jkh at brierdr.com Fri Jun 1 19:23:43 2007 From: jkh at brierdr.com (Jordan K. Hubbard) Date: Tue Oct 9 16:40:21 2007 Subject: GSoC2007 work In-Reply-To: <304E651A-781F-4FBB-A658-B1EE68D67D1E@macports.org> References: <304E651A-781F-4FBB-A658-B1EE68D67D1E@macports.org> Message-ID: On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote: > Again, many reasons to move GSoC work to branches and very little > to have it happen right on trunk, in my opinion. I'll make the move > if no one presents a case against it, so please speak up if you feel > you have valid arguments against moving to branches. Thanks! I object. I'm completely in agreement with James - the SoC contributors shouldn't be treated any differently than other contributors (lest we create 2nd class citizens in what is otherwise supposed to be an open project, regardless of how someone gets here). A branch also isn't a quarantine mechanism to be arbitrarily placed on a contributor* - it's an organizational tool to be used in certain situations which depend ENTIRELY on the types of changes in question. That should be left to the discretion of the contributor. Artificially constraining things to branches is also generally the first step in ensuring their decay and eventual death. That's a fairly strong argument against. - Jordan * Yes, I'm also familiar with the "untrustworthy contributor" scenario, but the solution there still isn't a branch, it's a committer proxy. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070601/2afa483c/attachment.html From sfiera at macports.org Mon Jun 4 13:10:10 2007 From: sfiera at macports.org (Chris Pickel) Date: Tue Oct 9 16:40:21 2007 Subject: libmd vs. openssl Message-ID: (having thought about it, if I want to ask the developers something, it's better to mail this list than to put the question in the footer of a -users message) Since it stopped shelling out for md5, MacPorts has supported two libraries for checksums: libmd and libcrypto. It prefers to compile with libmd support, but apparently this doesn't always work [1]. The reasons for preferring libmd are pretty obvious: it supports the algorithms we want and doesn't have any more unnecessary bloat. The reasons against libmd are a) that Apple doesn't provide it, b) MacPorts officially supports only Apple, and b) apparently it doesn't always work. So, a couple of questions: 1. Has anyone successfully compiled MacPorts against libmd recently? 2. Would it be desirable to prefer libcrypto? 3. Would it be desirable to bundle libmd with MacPorts? It's a pretty lightweight library (152K compressed), so it would not be unreasonable to go with #3. Chris [1] http://lists.macosforge.org/pipermail/macports-users/2007-June/ 003691.html -------------- 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/20070604/5cde1f8a/PGP.bin From ryandesign at macports.org Mon Jun 4 13:38:55 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:21 2007 Subject: [25869] users/jberry/mpwa In-Reply-To: <20070604054455.D039762FA05@cvs.opensource.apple.com> References: <20070604054455.D039762FA05@cvs.opensource.apple.com> Message-ID: <3592259A-756E-4FC5-A731-1F22C49B23DA@macports.org> On Jun 4, 2007, at 00:44, source_changes@macosforge.org wrote: > Revision: 25869 > http://trac.macosforge.org/projects/macports/changeset/25869 > Author: jberry@macports.org > Date: 2007-06-03 22:44:55 -0700 (Sun, 03 Jun 2007) > > Log Message: > ----------- > mpwa: in progress work to support user validation and registration I haven't looked at the code in this revision (or any of the mpwa code, really), but this is going to be a part of the MacPorts web site, yes? I think we should therefore be thinking about how we can create a single login system that works for every part of the site -- issue tracker, mpwa, news items, and anything else we might have. I'm not familiar with WordPres or Trac setup so I don't know what options are available. I know that I personally dislike the type of login we currently have for Trac -- that browser alert box. It's ugly. I much prefer login forms on web pages, since you can make them look pretty. So... have we given any thought to how to make every part of the MacPorts web site recognize a global login? From ryandesign at macports.org Mon Jun 4 13:40:24 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:21 2007 Subject: [25845] trunk/dports/devel/dialog/Portfile In-Reply-To: <20070603160906.07B8062EEB7@cvs.opensource.apple.com> References: <20070603160906.07B8062EEB7@cvs.opensource.apple.com> Message-ID: On Jun 3, 2007, at 11:09, source_changes@macosforge.org wrote: > Revision: 25845 > http://trac.macosforge.org/projects/macports/changeset/25845 > Author: jwa@macports.org > Date: 2007-06-03 09:09:05 -0700 (Sun, 03 Jun 2007) > > Log Message: > ----------- > a crude way to solve the problem of having the distfile with always > the > same name - no version number, seems to work even at upgrade > > Modified Paths: > -------------- > trunk/dports/devel/dialog/Portfile > > Modified: trunk/dports/devel/dialog/Portfile > =================================================================== > --- trunk/dports/devel/dialog/Portfile 2007-06-03 15:51:40 UTC (rev > 25844) > +++ trunk/dports/devel/dialog/Portfile 2007-06-03 16:09:05 UTC (rev > 25845) > @@ -21,6 +21,11 @@ > master_sites ftp://invisible-island.net/dialog/ > distname ${name} > worksrcdir ${name}-${version} > + > +pre-fetch { > + file delete -force ${distpath}/${distname}.tar.gz > +} > + > checksums sha1 1912ce21d9590b9fbf85e9159a2f428eaece1894 > configure.args --mandir=${prefix}/share/man Hmm..... won't that cause the archive to be re-downloaded every time you try to install, even if the archive hasn't changed? Isn't there a syntax you can use where you tell MacPorts to store the distfile under a different name? From ryandesign at macports.org Mon Jun 4 13:41:59 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:21 2007 Subject: [25816] trunk/dports/graphics/gqview/Portfile In-Reply-To: <20070602232651.1F72762E479@cvs.opensource.apple.com> References: <20070602232651.1F72762E479@cvs.opensource.apple.com> Message-ID: <3F8B98C8-99C3-4403-AB0D-35338269827D@macports.org> On Jun 2, 2007, at 18:26, source_changes@macosforge.org wrote: > Revision: 25816 > http://trac.macosforge.org/projects/macports/changeset/25816 > Author: markd@macports.org > Date: 2007-06-02 16:26:50 -0700 (Sat, 02 Jun 2007) > > Log Message: > ----------- > Closes #11833. Remove superfluous configure.env. > > Modified Paths: > -------------- > trunk/dports/graphics/gqview/Portfile > > Modified: trunk/dports/graphics/gqview/Portfile > =================================================================== > --- trunk/dports/graphics/gqview/Portfile 2007-06-02 22:56:09 UTC > (rev 25815) > +++ trunk/dports/graphics/gqview/Portfile 2007-06-02 23:26:50 UTC > (rev 25816) > @@ -3,6 +3,7 @@ > PortSystem 1.0 > name gqview > version 2.0.4 > +revision 1 > categories graphics x11 > platforms darwin > maintainers mvitocruz@gmail.com > @@ -14,5 +15,3 @@ > checksums md5 7196deab04db94cec2167637cddc02f9 > depends_lib port:gtk2 > configure.args --mandir=${prefix}/share/man > -configure.env LDFLAGS=-L${prefix}/lib CPPFLAGS=-I${prefix}/ > include \ > - CFLAGS=-flat_namespace There's no mention in the log message or in the ticket notes about why -flat_namespace was removed from the CFLAGS? From mgrimes at macports.org Mon Jun 4 14:56:09 2007 From: mgrimes at macports.org (Mark Grimes) Date: Tue Oct 9 16:40:21 2007 Subject: GSoC2007 work In-Reply-To: Message-ID: On 6/4/2007, "Jordan K. Hubbard" wrote: > >On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote: > >> Again, many reasons to move GSoC work to branches and very little >> to have it happen right on trunk, in my opinion. I'll make the move >> if no one presents a case against it, so please speak up if you feel >> you have valid arguments against moving to branches. Thanks! > >I object. I'm completely in agreement with James - the SoC >contributors shouldn't be treated any differently than other >contributors (lest we create 2nd class citizens in what is otherwise >supposed to be an open project, regardless of how someone gets >here). A branch also isn't a quarantine mechanism to be arbitrarily >placed on a contributor* - it's an organizational tool to be used in >certain situations which depend ENTIRELY on the types of changes in >question. That should be left to the discretion of the contributor. > >Artificially constraining things to branches is also generally the >first step in ensuring their decay and eventual death. That's a >fairly strong argument against. > >- Jordan > >* Yes, I'm also familiar with the "untrustworthy contributor" >scenario, but the solution there still isn't a branch, it's a >committer proxy.) Subversion does not currently support merge tracking (without svk), so this makes cherry picking a micromanagement burden and probably weighs in somewhat on the branching stigma as well. Only rudimentary support is targeted for Subversion 1.5, but presumably more robust by 1.6, so additionally I don't think this (merging branches back to trunk) aversion will change from that perspective anytime soon. But the lack of merge tracking is probably the only reason from the arguments I've read that I would not be quick to branch if there's reason to believe the changes are strong enough to potentially break trunk. Otherwise I have to agree with Juan that branching any potentially damaging, several revision change over time is the right way to do it. I can't see feedback as a reason to keep things in trunk anymore then I can understand third party code submittal as a reason to branch. These are existential to keeping a clean trunk. And he existing subversion feature-set lets you manage these scenarios without making implementation decisions based on outside-the-box concerns. -Mark From blair at orcaware.com Mon Jun 4 16:08:34 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:21 2007 Subject: GSoC2007 work In-Reply-To: References: Message-ID: <46649B72.90806@orcaware.com> Mark Grimes wrote: > On 6/4/2007, "Jordan K. Hubbard" wrote: >> On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote: >> >>> Again, many reasons to move GSoC work to branches and very little >>> to have it happen right on trunk, in my opinion. I'll make the move >>> if no one presents a case against it, so please speak up if you feel >>> you have valid arguments against moving to branches. Thanks! >> I object. I'm completely in agreement with James - the SoC >> contributors shouldn't be treated any differently than other >> contributors (lest we create 2nd class citizens in what is otherwise >> supposed to be an open project, regardless of how someone gets >> here). A branch also isn't a quarantine mechanism to be arbitrarily >> placed on a contributor* - it's an organizational tool to be used in >> certain situations which depend ENTIRELY on the types of changes in >> question. That should be left to the discretion of the contributor. >> >> Artificially constraining things to branches is also generally the >> first step in ensuring their decay and eventual death. That's a >> fairly strong argument against. >> >> - Jordan >> >> * Yes, I'm also familiar with the "untrustworthy contributor" >> scenario, but the solution there still isn't a branch, it's a >> committer proxy.) > > Subversion does not currently support merge tracking (without svk), so > this makes cherry picking a micromanagement burden and probably weighs > in somewhat on the branching stigma as well. Not true. There is svnmerge.py, which makes this very easy: http://www.orcaware.com/svn/wiki/Svnmerge.py It supports cherry picking and already has most of the feature set that 1.5 will have. I would recommend using svnmerge.py to manage feature branches and it's easy to keep development on a branch that may break trunk. We use it all the time at work. Regards, Blair -- Blair Zajac, Ph.D. Subversion training, consulting and support http://www.orcaware.com/svn/ From mgrimes at macports.org Mon Jun 4 17:10:51 2007 From: mgrimes at macports.org (Mark Grimes) Date: Tue Oct 9 16:40:21 2007 Subject: GSoC2007 work In-Reply-To: <46649B72.90806@orcaware.com> Message-ID: <7h66seNW.1181002251.9146030.mgrimes@harwood.textdrive.com> On 6/4/2007, "Blair Zajac" wrote: >Mark Grimes wrote: >> On 6/4/2007, "Jordan K. Hubbard" wrote: >>> On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote: >>> >>>> Again, many reasons to move GSoC work to branches and very little >>>> to have it happen right on trunk, in my opinion. I'll make the move >>>> if no one presents a case against it, so please speak up if you feel >>>> you have valid arguments against moving to branches. Thanks! >>> I object. I'm completely in agreement with James - the SoC >>> contributors shouldn't be treated any differently than other >>> contributors (lest we create 2nd class citizens in what is otherwise >>> supposed to be an open project, regardless of how someone gets >>> here). A branch also isn't a quarantine mechanism to be arbitrarily >>> placed on a contributor* - it's an organizational tool to be used in >>> certain situations which depend ENTIRELY on the types of changes in >>> question. That should be left to the discretion of the contributor. >>> >>> Artificially constraining things to branches is also generally the >>> first step in ensuring their decay and eventual death. That's a >>> fairly strong argument against. >>> >>> - Jordan >>> >>> * Yes, I'm also familiar with the "untrustworthy contributor" >>> scenario, but the solution there still isn't a branch, it's a >>> committer proxy.) >> >> Subversion does not currently support merge tracking (without svk), so >> this makes cherry picking a micromanagement burden and probably weighs >> in somewhat on the branching stigma as well. ; >Not true. There is svnmerge.py, which makes this very easy: > >http://www.orcaware.com/svn/wiki/Svnmerge.py > >It supports cherry picking and already has most of the feature set that >1.5 will have. > >I would recommend using svnmerge.py to manage feature branches and it's >easy to keep development on a branch that may break trunk. We use it >all the time at work. > >Regards, >Blair > >-- >Blair Zajac, Ph.D. > >Subversion training, consulting and support >http://www.orcaware.com/svn/ Maybe I'm missing something when I evaluated the tool prior to switching to svk, but my understanding is that it's better then nothing but far from a merge tracking solution as it only works at the directory level which makes microbranches a tough sell (can cause double merging). From what I've researched the consensus seems to be that you cannot merge a single file and unless you only merge from project's root every time you're stuck with manual merge tracking. I would imagine the last mile is being handled by subversion's roadmap, but I would tend to think that in large multi-developer project's something that coarse grain wouldn't be ideal. I didn't mean to slant this discussion into battle of the tools -- but what I've researched (granted opted out of) doesn't chalk svnmerge.py as a complete solution in the slightest. I'm more inclined to believe someone like yourself that has used it, but I'm pretty scared off about there being a "manual merge tracking" path at all when it comes to making decisions about being quick to branch or not. I've always been quick to branch because svk does a very nice job of this whilest keeping my sanity entact, but my scorecard only shows 2 committers using svk thus far, so I wanted to bring up subversion's work-in-progress on the technical slant. Noone needs the headache of branching if the technical merging is not up to par with what people envision they can do. You don't find that many subversion projects that are branch happy, but I'm not necessarily convinced it is because of JKH's reasons as much as it is an implementation pitfall and known weakness on the Subversion side that are currently being milestoned (http://subversion.tigris.org/merge-tracking/) -Mark From blair at orcaware.com Mon Jun 4 17:25:13 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:21 2007 Subject: GSoC2007 work In-Reply-To: <7h66seNW.1181002251.9146030.mgrimes@harwood.textdrive.com> References: <7h66seNW.1181002251.9146030.mgrimes@harwood.textdrive.com> Message-ID: <4664AD69.3030303@orcaware.com> Mark Grimes wrote: > On 6/4/2007, "Blair Zajac" wrote: > >> Mark Grimes wrote: >>> On 6/4/2007, "Jordan K. Hubbard" wrote: >>>> On Jun 1, 2007, at 11:43 AM, Juan Manuel Palacios wrote: >>>> >>>>> Again, many reasons to move GSoC work to branches and very little >>>>> to have it happen right on trunk, in my opinion. I'll make the move >>>>> if no one presents a case against it, so please speak up if you feel >>>>> you have valid arguments against moving to branches. Thanks! >>>> I object. I'm completely in agreement with James - the SoC >>>> contributors shouldn't be treated any differently than other >>>> contributors (lest we create 2nd class citizens in what is otherwise >>>> supposed to be an open project, regardless of how someone gets >>>> here). A branch also isn't a quarantine mechanism to be arbitrarily >>>> placed on a contributor* - it's an organizational tool to be used in >>>> certain situations which depend ENTIRELY on the types of changes in >>>> question. That should be left to the discretion of the contributor. >>>> >>>> Artificially constraining things to branches is also generally the >>>> first step in ensuring their decay and eventual death. That's a >>>> fairly strong argument against. >>>> >>>> - Jordan >>>> >>>> * Yes, I'm also familiar with the "untrustworthy contributor" >>>> scenario, but the solution there still isn't a branch, it's a >>>> committer proxy.) >>> Subversion does not currently support merge tracking (without svk), so >>> this makes cherry picking a micromanagement burden and probably weighs >>> in somewhat on the branching stigma as well. > ; >> Not true. There is svnmerge.py, which makes this very easy: >> >> http://www.orcaware.com/svn/wiki/Svnmerge.py >> >> It supports cherry picking and already has most of the feature set that >> 1.5 will have. >> >> I would recommend using svnmerge.py to manage feature branches and it's >> easy to keep development on a branch that may break trunk. We use it >> all the time at work. >> >> Regards, >> Blair >> >> -- >> Blair Zajac, Ph.D. >> >> Subversion training, consulting and support >> http://www.orcaware.com/svn/ > > Maybe I'm missing something when I evaluated the tool prior to switching > to svk, but my understanding is that it's better then nothing but far > from a merge tracking solution as it only works at the directory level > which makes microbranches a tough sell (can cause double merging). From > what I've researched the consensus seems to be that you cannot merge a > single file and unless you only merge from project's root every time > you're stuck with manual merge tracking. Yes, that's true, but for this type of work, I don't see very often merging on the file level. Maybe that's a limitation of the tool, but I typically see merges at the directory level and of complete revisions. > I would imagine the last mile is being handled by subversion's roadmap, > but I would tend to think that in large multi-developer project's > something that coarse grain wouldn't be ideal. > > I didn't mean to slant this discussion into battle of the tools -- but > what I've researched (granted opted out of) doesn't chalk svnmerge.py > as a complete solution in the slightest. I think you're being a little dismissive here. For 90% of the merging people do, merging complete revisions and at a top level directory is sufficient. We're not talking about the big project here for MacPorts. We use svnmerge.py in the Subversion project itself on feature branches. Here, most of the time you want to just merge changes from trunk into the feature branch en-masse to keep the branch up to date and not have to keep track of what you have already merged over. When the branch work is ready, you merge it by hand back into trunk. I don't see this being much different for a MacPorts feature branch. So svnmerge.py works fine here. > I'm more inclined to believe someone like yourself that has used it, but > I'm pretty scared off about there being a "manual merge tracking" > path at all when it comes to making decisions about being quick to > branch or not. I've always been quick to branch because svk does a very > nice job of this whilest keeping my sanity entact, but my scorecard only > shows 2 committers using svk thus far, so I wanted to bring up > subversion's work-in-progress on the technical slant. Noone needs the > headache of branching if the technical merging is not up to par with > what people envision they can do. You don't find that many subversion > projects that are branch happy, but I'm not necessarily convinced it is > because of JKH's reasons as much as it is an implementation pitfall and > known weakness on the Subversion side that are currently being > milestoned (http://subversion.tigris.org/merge-tracking/) > > -Mark I use svk also, but more for having a copy of a repository on my laptop and being able to do commits then for its merge tracking. We use branches at work all the time. Each developer gets their own branch and we use trunk to track what's in production web site (Java, HTML code). So we do svnmerge.py merges from trunk into each developers branch when they want to, and also use svnmerge.py for merge from the developer's branch back into trunk for when new code is being deployed. In this case, svnmerge.py does all we need. Does svk support more fine grained branch management where the branches live on the server and not in ~/.svk? Regards, Blair From vincent-opdarw at vinc17.org Mon Jun 4 19:14:26 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:21 2007 Subject: dependency bug? Message-ID: <20070605021426.GK6414@prunille.vinc17.org> prunille:~> sudo port -v -d uninstall docbook-xml-412 DEBUG: scrollkeeper depends on this port DEBUG: scrollkeeper depends on this port ---> Unable to uninstall docbook-xml-412 4.1.2_0, the following ports depend on it: ---> scrollkeeper ---> scrollkeeper DEBUG: Please uninstall the ports that depend on docbook-xml-412 first. while executing "portuninstall::uninstall $portname [composite_version $portversion [array get variations]] [array get options]" Error: port uninstall failed: Please uninstall the ports that depend on docbook-xml-412 first. but... prunille:~> port info scrollkeeper Warning: Found 2 port scrollkeeper definitions, displaying first one. scrollkeeper 0.3.14, Revision 4, textproc/scrollkeeper (Variants: universal) http://scrollkeeper.sourceforge.net/ ScrollKeeper is a cataloging system for documentation on open systems. It manages documentation metadata (as specified by the Open Source Metadata Framework (OMF) and provides a simple API to allow help browsers to find, sort, and search the document catalog. It will also be able to communicate with catalog servers on the Net to search for documents which are not on the local system. Build Dependencies: pkgconfig, intltool Library Dependencies: libxslt, libxml2, gettext, expat, fontconfig, docbook-xml-scrollkeeper, docbook-xsl, docbook-xml, docbook-xml-4.1.2 Platforms: darwin Maintainers: rhwood@macports.org openmaintainer@macports.org I don't see docbook-xml-412 in the dependencies. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From blair at orcaware.com Mon Jun 4 19:25:29 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:21 2007 Subject: GSoC2007 work In-Reply-To: <28042131-CBD3-4C0B-843E-857497BA471E@brierdr.com> References: <304E651A-781F-4FBB-A658-B1EE68D67D1E@macports.org> <65AF43BC-0390-47A8-BA1F-B61ED947EF4C@macports.org> <46606EE8.7060309@kix.in> <28042131-CBD3-4C0B-843E-857497BA471E@brierdr.com> Message-ID: <4664C999.7060101@orcaware.com> Jordan K. Hubbard wrote: > > On Jun 1, 2007, at 12:09 PM, Anant Narayanan wrote: > >> Please do keep in mind that the students are required to submit a URL >> and possibly even upload code that they have authored during the summer >> to code.google.com at the end of the term. Committing directly to trunk >> poses a practical problem as it will be difficult for the students to >> distinctly show their work for audit. > > I don't think that's true with Subversion. It's more than possible to > demonstrate the changes between tags or cite specific changes by URL. > Branches don't even really exist in subversion as far as that's > concerned, they're just another type of tag. Actually, it's better to think about tags as a type of branch where you agree not to make commits on the tag after you create it. Regards, Blair From ryandesign at macports.org Mon Jun 4 19:49:31 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:21 2007 Subject: dependency bug? In-Reply-To: <20070605021426.GK6414@prunille.vinc17.org> References: <20070605021426.GK6414@prunille.vinc17.org> Message-ID: <1DBC694A-AA72-4B5B-B332-0B9303833BD2@macports.org> On Jun 4, 2007, at 21:14, Vincent Lefevre wrote: > prunille:~> sudo port -v -d uninstall docbook-xml-412 > DEBUG: scrollkeeper depends on this port > DEBUG: scrollkeeper depends on this port > ---> Unable to uninstall docbook-xml-412 4.1.2_0, the following > ports depend on it: > ---> scrollkeeper > ---> scrollkeeper > DEBUG: Please uninstall the ports that depend on docbook-xml-412 > first. > while executing > "portuninstall::uninstall $portname [composite_version $portversion > [array get variations]] [array get options]" > Error: port uninstall failed: Please uninstall the ports that > depend on docbook-xml-412 first. > > but... > > prunille:~> port info scrollkeeper > Warning: Found 2 port scrollkeeper definitions, displaying first one. I don't have that message when I "port info scrollkeeper". Maybe you have a local copy of a scrollkeeper port somewhere. > scrollkeeper 0.3.14, Revision 4, textproc/scrollkeeper (Variants: > universal) > http://scrollkeeper.sourceforge.net/ > > ScrollKeeper is a cataloging system for documentation on open > systems. It manages documentation metadata (as specified by the > Open Source Metadata Framework (OMF) and provides a simple API to > allow help browsers to find, sort, and search the document catalog. > It will also be able to communicate with catalog servers on the Net > to search for documents which are not on the local system. > > Build Dependencies: pkgconfig, intltool > Library Dependencies: libxslt, libxml2, gettext, expat, fontconfig, > docbook-xml-scrollkeeper, docbook-xsl, docbook-xml, docbook-xml-4.1.2 > Platforms: darwin > Maintainers: rhwood@macports.org openmaintainer@macports.org > > I don't see docbook-xml-412 in the dependencies. Maybe not now, but it used to be, before this change on 2007-05-31: http://trac.macosforge.org/projects/macports/changeset/25756 Just force the uninstall with -f. From ryandesign at macports.org Mon Jun 4 23:38:15 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:21 2007 Subject: Script to obscure your email address in your ports Message-ID: <6DC4F140-B132-45B7-BC5A-3045F5BF2DB0@macports.org> Dear portfile maintainers, There was a recent discussion on the list in which it was decided that we should support obscuring the email addresses in the maintainer line of our portfiles. If your email address is "bob@foo.example.com", then the obscured address entered into the portfile would be "foo.example.com:bob". If your email address ends with @macports.org, then your obscured address is simply the username before the @ sign. A future version of MacPorts will automatically un- obscure the email addresses again for commands like "port info". Some maintainers have already started obscuring their email addresses in their ports. If you would like to obscure your email address in the ports you maintain, you can use the attached script to do so. Assuming you have a Subversion working copy of the ports tree, change to that directory and run the script in that directory with your current maintainer email address as the only argument. The script will obscure the address and swap it out in all your portfiles. You can then examine the output of "svn diff" to ensure the change is correct (and that you have no other unrelated changes in your working copy) and then you can "svn commit" it. # Change to ports tree $ cd /path/to/dports # Make sure there are no other uncommitted changes $ svn status # Make sure we're up to date $ svn update # Obscure maintainer email addresses $ ~/Desktop/portfile-email-fix.sh bob@foo.example.com # Check the changes $ svn diff # Commit it $ svn commit -m "Obscuring my email address in the ports I maintain." Caveat: The script will not find any ports of yours where your email address is not on the line that begins with the command "maintainers", for example if the maintainers are split across multiple lines. However, I think there are only four ports to which this applies, and in all four of them, only "openmaintainer@macports.org" is on the second line. -------------- next part -------------- A non-text attachment was scrubbed... Name: portfile-email-fix.sh Type: application/octet-stream Size: 576 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070605/345f9b62/portfile-email-fix.obj From eridius at macports.org Tue Jun 5 00:36:29 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:40:21 2007 Subject: [25876] trunk/base/src/registry1.0/receipt_flat.tcl In-Reply-To: <20070604083736.0C66162FC10@cvs.opensource.apple.com> References: <20070604083736.0C66162FC10@cvs.opensource.apple.com> Message-ID: Please don't do this. Our source files really should be using soft tabs if possible, so if we are going to do file-wide changes we should move to that standard. On Jun 4, 2007, at 1:37 AM, source_changes@macosforge.org wrote: > Revision > 25876 > Author > boeyms@macports.org > Date > 2007-06-04 01:37:35 -0700 (Mon, 04 Jun 2007) > Log Message > > base/sre/registry1.0/receipt_flat.tcl: > * Whitespace changes only (most of the file uses tab characters, > so I'm making > it tab characters only). -- 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/20070605/9eb39849/attachment.html From mgrimes at macports.org Tue Jun 5 00:53:01 2007 From: mgrimes at macports.org (Mark Grimes) Date: Tue Oct 9 16:40:21 2007 Subject: GSoC2007 work In-Reply-To: <4664AD69.3030303@orcaware.com> References: <7h66seNW.1181002251.9146030.mgrimes@harwood.textdrive.com> <4664AD69.3030303@orcaware.com> Message-ID: <20070605005301553983.c75fda65@macports.org> On Mon, 04 Jun 2007 17:25:13 -0700, Blair Zajac wrote: > Mark Grimes wrote: >> On 6/4/2007, "Blair Zajac" wrote: >> I would imagine the last mile is being handled by subversion's roadmap, >> but I would tend to think that in large multi-developer project's >> something that coarse grain wouldn't be ideal. >> >> I didn't mean to slant this discussion into battle of the tools -- but >> what I've researched (granted opted out of) doesn't chalk svnmerge.py >> as a complete solution in the slightest. > > I think you're being a little dismissive here. For 90% of the > merging people do, merging complete revisions and at a top level > directory is sufficient. Ya I most certainly am being dismissive, it's not on purpose it's easy to lose sight on where svk extends svn, as for years svk has vested energy on exactly this problem -- svk's no-brainer merge tracking has saved my bacon more then a few times, simply because a small contingent of developers I work with are branch happy while the rest don't acknowledge there is anything but trunk (both dangerous, but the former shouldn't be... or at least living with the others that are branch happy shouldn't be) I think it's more of a question of where you want to spend your time and not "can from can't do", which is the attitude I think I originally aired. Of course you can do it... but wouldn't you rather be focused on content then playing chess with your version control system. I'd have a general fear of branching with svn a la carte, but thanks for the tip on svnmerge.py, I should reinvestigate it for the colleagues that don't listen to my thunderous svk advocacy in the hallways at the office. ;) > We're not talking about the big project here for MacPorts. We use > svnmerge.py in the Subversion project itself on feature branches. > Here, most of the time you want to just merge changes from trunk into > the feature branch en-masse to keep the branch up to date and not > have to keep track of what you have already merged over. When the > branch work is ready, you merge it by hand back into trunk. Yeah if you don't care about double merging nor evil twins that is. Unfortunately, evil twins have bit me all over the place in svn a la carte. > I use svk also, but more for having a copy of a repository on my > laptop and being able to do commits then for its merge tracking. The decentralization is just the most recognized feature, it's certainly not the most powerful. When 2.0 was cut at the beginning of 2007, things got significantly more impressive on a few fronts (http://bestpractical.typepad.com/worst_impractical/2007/01/svk_20_is_bette.html) > We use branches at work all the time. Each developer gets their own > branch and we use trunk to track what's in production web site (Java, > HTML code). So we do svnmerge.py merges from trunk into each > developers branch when they want to, and also use svnmerge.py for > merge from the developer's branch back into trunk for when new code > is being deployed. Sounds like an architectural design crafted around coarse grain merge tracking. At my work, we create functional branches that >1 people play in. Without fine grain merge tracking it is hard to divvy up the merges between developers... it does seem like the svn players in our repos are afraid to branch, maybe from fear that the tree will diverge too much from any lengthy work in a branch. Who can blame them, especially when the trees themselves are not very atomic with respect to control of what other developers are doing. There are countless examples of evil twin problems, and in general it's hard to merge by hand when you can't control other users that may be doing more immediate merges between branches. > In this case, svnmerge.py does all we need. > > Does svk support more fine grained branch management where the > branches live on the server and not in ~/.svk? You are still doing your work against a mirrored path that throws svk:merge tickets all over macports directory structure, so I don't see this as acting any different then dealing with local branches that offer the same merge ticket system. svk can inspect remotely mirrored svk:merge tickets on the macports tree just the same, so I would gather your granularity is at the same level. If you want to pull local branch management out of the loop, engage all your svk commands against the mirrored path and that would basically give you "svn" + merge tracking via tickets. This is not a way I've ever operated, but I suppose it's completely conceivable since the merge tickets litter the server svn repo as props. Tying the fun tangent back to GSoC, it sounds like it [GSoC] being more or less a student exercise then pair programming would benefit from svnmerge.py or coarse grain merge tracking if branching is warranted or even used discretionarily. -Mark From vincent-opdarw at vinc17.org Tue Jun 5 02:08:11 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:21 2007 Subject: dependency bug? In-Reply-To: <1DBC694A-AA72-4B5B-B332-0B9303833BD2@macports.org> References: <20070605021426.GK6414@prunille.vinc17.org> <1DBC694A-AA72-4B5B-B332-0B9303833BD2@macports.org> Message-ID: <20070605090811.GM6414@prunille.vinc17.org> On 2007-06-04 21:49:31 -0500, Ryan Schmidt wrote: > On Jun 4, 2007, at 21:14, Vincent Lefevre wrote: >> prunille:~> port info scrollkeeper >> Warning: Found 2 port scrollkeeper definitions, displaying first one. > > I don't have that message when I "port info scrollkeeper". Maybe you > have a local copy of a scrollkeeper port somewhere. Yes, this is normal: I have several sources, and in particular the rsync one with a lower precedence (ignored except for MacPorts upgrades): file:///Users/vinc17/wd/macosx/dports [nosync] file:///Users/vinc17/software/dports [nosync] rsync://rsync.macports.org/dpupdate/dports [...] >> I don't see docbook-xml-412 in the dependencies. > > Maybe not now, but it used to be, before this change on 2007-05-31: > > http://trac.macosforge.org/projects/macports/changeset/25756 OK, you mean that this dependency is still recorded somewhere? > Just force the uninstall with -f. This fixes the problem. prunille:~> port installed | grep scrollkeeper scrollkeeper @0.3.14_4 (active) Now, this is strange as scrollkeeper depends on docbook-xml-scrollkeeper, but this can be explained because docbook-xml-scrollkeeper contains nothing. however, shouldn't scrollkeeper depend on docbook-xml-4.2 directly? -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From rhwood at mac.com Tue Jun 5 02:31:33 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:21 2007 Subject: dependency bug? In-Reply-To: <20070605090811.GM6414@prunille.vinc17.org> References: <20070605021426.GK6414@prunille.vinc17.org> <1DBC694A-AA72-4B5B-B332-0B9303833BD2@macports.org> <20070605090811.GM6414@prunille.vinc17.org> Message-ID: <44D2D3C9-5462-43D2-8205-1A212E98DEA8@mac.com> On 5 Jun 2007, at 05:08, Vincent Lefevre wrote: > On 2007-06-04 21:49:31 -0500, Ryan Schmidt wrote: >> On Jun 4, 2007, at 21:14, Vincent Lefevre wrote: >>> prunille:~> port info scrollkeeper >>> Warning: Found 2 port scrollkeeper definitions, displaying first >>> one. >> >> I don't have that message when I "port info scrollkeeper". Maybe you >> have a local copy of a scrollkeeper port somewhere. > > Yes, this is normal: I have several sources, and in particular the > rsync > one with a lower precedence (ignored except for MacPorts upgrades): > > file:///Users/vinc17/wd/macosx/dports [nosync] > file:///Users/vinc17/software/dports [nosync] > rsync://rsync.macports.org/dpupdate/dports > > [...] >>> I don't see docbook-xml-412 in the dependencies. >> >> Maybe not now, but it used to be, before this change on 2007-05-31: >> >> http://trac.macosforge.org/projects/macports/changeset/25756 > > OK, you mean that this dependency is still recorded somewhere? > >> Just force the uninstall with -f. > > This fixes the problem. > > prunille:~> port installed | grep scrollkeeper > scrollkeeper @0.3.14_4 (active) > > Now, this is strange as scrollkeeper depends on docbook-xml- > scrollkeeper, > but this can be explained because docbook-xml-scrollkeeper contains > nothing. however, shouldn't scrollkeeper depend on docbook-xml-4.2 > directly? Yes, it should, but not yet. docbook-xml-scrollkeeper and docbook- xml-4.2 conflicted last week. docbook-xml-scrollkeeper is now an empty port that depends on docbook-xml-4.2. We need to wait before redoing scrollkeeper's depenedencies to ensure all users have ample time to have *4.2 installed. Simply changing scrollkeeper's dependencies would cause attempts to install docbook-xml-4.2 over docbook-xml-scrollkeeper instead of upgrading it out of the way. > -- > Vincent Lef?vre - Web: > 100% accessible validated (X)HTML - Blog: blog/> > Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS- > Lyon) > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From jwa at macports.org Tue Jun 5 05:32:42 2007 From: jwa at macports.org (Jyrki Wahlstedt) Date: Tue Oct 9 16:40:21 2007 Subject: [25845] trunk/dports/devel/dialog/Portfile In-Reply-To: References: <20070603160906.07B8062EEB7@cvs.opensource.apple.com> Message-ID: On 4.6.2007, at 23.40, Ryan Schmidt wrote: > On Jun 3, 2007, at 11:09, source_changes@macosforge.org wrote: > > > > Hmm..... won't that cause the archive to be re-downloaded every > time you try to install, even if the archive hasn't changed? Isn't > there a syntax you can use where you tell MacPorts to store the > distfile under a different name? > > Thanks, I just implemented something to avoid this in the latest version (r25912). ! ! Jyrki Wahlstedt ! skype:jyrkiwahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386 From mgrimes at macports.org Tue Jun 5 08:45:18 2007 From: mgrimes at macports.org (Mark Grimes) Date: Tue Oct 9 16:40:21 2007 Subject: Subversion repo issue Message-ID: <20070605084518171151.5ac62d96@macports.org> Here's one I've never seen before... anyone else having trouble with the MP repo? Now svk does apply props for merge tickets as mentioned prior, and this has always worked before... I suppose I could one-off these commits until I narrow down the problem, but wanted to ask here at the sake of multiple commits per single functional change (email obscurity in this case). ===> Auto-merging (25942, 25943) /local/trunk to /mirror/trunk (base /mirror/trunk:25941). Merging back to mirror source https://svn.macports.org/repository/macports. U dports/net/libdnet/Portfile U dports/perl/p5-xml-apachefop/Portfile U dports/perl/p5-params-util/Portfile U dports/perl/p5-java/Portfile U dports/perl/p5-path-class/Portfile U dports/perl/p5-app-cli/Portfile U dports/perl/p5-pdf-reuse/Portfile U dports/perl/p5-list-moreutils/Portfile U dports/security/ike-scan/Portfile U dports/security/metasploit3/Portfile New merge ticket: e4b2a6a8-e742-4924-8f8a-3771363e925e:/local/trunk:25943 Failed to execute WebDAV PROPPATCH: At least one property change failed; repository is unchanged Mark Grimes, Principal Developer Stateful Labs From ryandesign at macports.org Tue Jun 5 08:57:55 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:21 2007 Subject: Subversion repo issue In-Reply-To: <20070605084518171151.5ac62d96@macports.org> References: <20070605084518171151.5ac62d96@macports.org> Message-ID: On Jun 5, 2007, at 10:45, Mark Grimes wrote: > Here's one I've never seen before... anyone else having trouble with > the MP repo? Now svk does apply props for merge tickets as mentioned > prior, and this has always worked before... > I suppose I could one-off these commits until I narrow down the > problem, but wanted to ask here at the sake of multiple commits per > single functional change (email obscurity in this case). > > ===> Auto-merging (25942, 25943) /local/trunk to /mirror/trunk (base > /mirror/trunk:25941). > Merging back to mirror source > https://svn.macports.org/repository/macports. > U dports/net/libdnet/Portfile > U dports/perl/p5-xml-apachefop/Portfile > U dports/perl/p5-params-util/Portfile > U dports/perl/p5-java/Portfile > U dports/perl/p5-path-class/Portfile > U dports/perl/p5-app-cli/Portfile > U dports/perl/p5-pdf-reuse/Portfile > U dports/perl/p5-list-moreutils/Portfile > U dports/security/ike-scan/Portfile > U dports/security/metasploit3/Portfile > New merge ticket: > e4b2a6a8-e742-4924-8f8a-3771363e925e:/local/trunk:25943 > Failed to execute WebDAV PROPPATCH: At least one property change > failed; repository is unchanged I had to obscurify my ports in two commits because it wouldn't go in one. I frequently have this problem with commits which span many files. I don't use svk, I just use plain svn. I get a message about the SSL somethingorother. Oh, wait, here, I still have it: Transmitting file data ........................svn: Commit failed (details follow): svn: PUT of '/repository/macports/!svn/wrk/55dfb2b4-ae74-47ff-b412- db15fdc83ddd/trunk/dports/sysutils/cronolog/Portfile': SSL negotiation failed: SSL error: sslv3 alert bad record mac (https:// svn.macosforge.org) In my case, I tried many times and it was always sysutils/cronolog/ Portfile that was mentioned. From kvv at apple.com Tue Jun 5 10:02:38 2007 From: kvv at apple.com (Kevin Van Vechten) Date: Tue Oct 9 16:40:21 2007 Subject: Subversion repo issue In-Reply-To: References: <20070605084518171151.5ac62d96@macports.org> Message-ID: <2A138320-03F4-4ABD-8A75-470E1D435D9A@apple.com> It's not necessary to use SSL to access the repository (we use digest authentication), and using the plain http:// URL will probably be more robust. - Kevin On Jun 5, 2007, at 8:57 AM, Ryan Schmidt wrote: > Transmitting file data ........................svn: Commit failed > (details follow): > svn: PUT of '/repository/macports/!svn/wrk/55dfb2b4-ae74-47ff-b412- > db15fdc83ddd/trunk/dports/sysutils/cronolog/Portfile': SSL > negotiation failed: SSL error: sslv3 alert bad record mac (https:// > svn.macosforge.org) From mgrimes at macports.org Tue Jun 5 13:23:53 2007 From: mgrimes at macports.org (Mark Grimes) Date: Tue Oct 9 16:40:21 2007 Subject: Subversion repo issue In-Reply-To: <2A138320-03F4-4ABD-8A75-470E1D435D9A@apple.com> Message-ID: Unfortunately, it (SSL) is actually necessary in my case (at least while I'm at work)... Most corporate web proxies don't proxy all the HTTP methods required to make WebDAV work. This is denoted in the form of an Error 500. (mark@entropy ~) svk sync /macports/mirror Syncing https://svn.macports.org/repository/macports Retrieving log information from 25914 to 25914 Committed revision 25947 from revision 25914. (mark@entropy ~) svk mirror -l | grep macports /macports/mirror https://svn.macports.org/repository/macports (mark@entropy ~) svk mirror --relocate /macports/mirror http://svn.macports.org/repository/macports Mirror relocated. (mark@entropy /Code/MacPorts) svk sync /macports/mirror Syncing http://svn.macports.org/repository/macports Retrieving log information from 25915 to 25916 RA layer request failed: REPORT request failed on '/repository/macports/!svn/bc/25916': REPORT of '/repository/macports/!svn/bc/25916': 500 Server Error (http://svn.macports.org) -Mark On 6/5/2007, "Kevin Van Vechten" wrote: >It's not necessary to use SSL to access the repository (we use digest >authentication), and using the plain http:// URL will probably be >more robust. > >- Kevin > >On Jun 5, 2007, at 8:57 AM, Ryan Schmidt wrote: > >> Transmitting file data ........................svn: Commit failed >> (details follow): >> svn: PUT of '/repository/macports/!svn/wrk/55dfb2b4-ae74-47ff-b412- >> db15fdc83ddd/trunk/dports/sysutils/cronolog/Portfile': SSL >> negotiation failed: SSL error: sslv3 alert bad record mac (https:// >> svn.macosforge.org) > From cbellot at sky.fr Wed Jun 6 10:20:10 2007 From: cbellot at sky.fr (Cyril Bellot) Date: Tue Oct 9 16:40:21 2007 Subject: NEW: p5-io-multiplex & mailqfmt Message-ID: <4666ECCA.3040805@sky.fr> Hello, could someone commit theses ones : http://trac.macosforge.org/projects/macports/ticket/12061 http://trac.macosforge.org/projects/macports/ticket/12062 Last one may be reviewed first. Thanks From jmpp at macports.org Wed Jun 6 19:37:22 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:21 2007 Subject: dp2mp-move branch work done & merging into trunk In-Reply-To: <20070602195316.GA1553@eatyourpets.com> References: <2E029F56-2C69-48A3-8DCA-726C856634BD@macports.org> <20070602195316.GA1553@eatyourpets.com> Message-ID: <2E008386-698E-4EF4-8B21-CDAFB35B87AF@macports.org> Hey Charlie, good to see you're back! On Jun 2, 2007, at 3:53 PM, Charlie Allom wrote: > On Fri, Jun 01, 2007 at 02:48:21PM -0400, Juan Manuel Palacios wrote: >> >> detailed above. Also, branch has been tested extensively and >> everything > > Juan - can you detail specific instructions for testing the branch? > I'm > sure some people would be happy to help test some more.. Testing the branch should be no different from simply installing off of it and using the resulting MacPorts installation on a regular basis, everything should just work as expected and just as trunk/base does (there's feature parity); if it doesn't then there's a bug in one/some of my various renaming edits and I should look into it, report it to me right away! (mail, ticket assigned to me, both, whatever you prefer). I have, however, been using the branch for long already (installing ports, upgrading them, using them, etc...) and haven't experienced a single anomaly (or at least none that I haven't fixed already ;-), so I wouldn't expect anything to turn up (anything that's not also in trunk, of course). Some others have told me it's the same case for them, but anyways I always appreciate more eyes looking ;-) The only one count in which the testing protocol is particular to this branch is in the install target of the main Makefile (base/ Makefile): said target calls an 'upgrade' prerequisite that takes care of moving all of an existing MacPorts installation to the new layout outlined in the branch (installation paths, config settings, etc), so that should be carefully tested. However, this is not too difficult in itself: -) manually upgrading an existing MacPorts installation with this branch (make && make install); -) selfupdating an existing installation to this branch. Both of those upgrading methods should produce a MacPorts installation identical to one from scratch off the branch. Take a look at [1] for an idea of how things should look like. Also, installing off this branch over an already renamed MacPorts installation should work flawlessly too, so maybe you could test that as well (I've done it here myself and things look fine). The only thing I don't support is installing trunk on top of this branch and then trying to upgrade that in turn... but who in their right mind would do that....? ;-) About selfupdating to this branch, as you may have guessed it's not possible doing so off of the MacPorts rsync server, since we're still feeding the 1.4.42 tag to users. Minor manual intervention is required: -) install the branches/dp2mp-move/base/portmgr/rsync.repos file as a local rsyncd.conf file and start a local rsync server; -) point the ports.conf file to this server and to the "release/ base/" rsync module ('rsync_dir' key); -) run a local copy of the branches/dp2mp-move/base/portmgr/ mprsyncup.new script with a RELEASE_URL value of "http:// svn.macports.org/repository/macports/branches/dp2mp-move/base" (this new script fully bootstraps and populates the rsync repos); -) selfupdate. See? Minor manual intervention! ;-) Feel free to send me any suggestions/corrections you might have for the 'upgrade' target in the Makefile, it is probably the most important part of the work so it could use as much sanitizing as it can get! However, I have, again, done a lot of local testing and have progressively polished it over time, so it should be alright. Feel free to ping me if you'd like me to explain it, it's a bit involved ;-) There are some comments at the end of the target detailing some minor thoughts/doubts I still have, feel free to look into them and provide feedback if you're so inclined. > > and do you have an ETA on when you would like to merge? Unfortunately I haven't received much feedback on the branch nor on the roadmap doc at [1], so I can only assume everything is looking up and good. In fact, the only feedback I've received is two people telling me the changes look great (the new layout) and some others telling me the branch is working as expected.... so therefore I'm feeling more than ready to merge it back into trunk ASAP. The only outstanding requirement is updating the rsync server with the new modules (rsync.repos file) and the new mprsyncup script, and I'm already coordinating that with Kevin. Therefore merging should happen real soon now! > > C. > -- > hail eris > http://rubberduck.com/ Thanks for the help in testing the branch, much appreciated! Regards,... -jmpp [1] http://trac.macports.org/projects/macports/wiki/MacPortsRenaming From jmpp at macports.org Thu Jun 7 08:18:42 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:21 2007 Subject: HEADS-UP: merging dp2mp-move into trunk ASAP now Message-ID: <870AB831-0BAF-4825-BF49-2EFB18264B17@macports.org> Well, the subject of this post pretty much says what it is all about, I'm ready to merge my branch back into trunk waiting only for some adjustments on the rsync server to take place. But the reason I consider this heads-up necessary is that this merge, as opposed to others we've seen around here, will change not only naming of some of the functions/routines/procs in our sources but also paths in svn (like base/src/darwinports1.0 to base/src/macports1.0, among others), so I would advice anyone writing new code against base to use branches/dp2mp-move/base as the point of reference from now on, as that will become trunk really soon now. I would also prefer it, if possible, that you don't commit to base until this merge is in, but I understand sticking to that petition can be a bit of a nuisance at times... so consider it only that, a petition from me. If you can withhold from committing to base until my merge is in I would appreciate it, but other than consider trunk open for work. About timing, as already said the commit should come really soon now, so in any case it's not much what you would have to wait holding your commits. I'm all ready on my side but I need to wait for Kevin to make some adaptations on the rsync server, we need to coordinate both things (otherwise "sync" and "selfupdate" will break for existing users). We're aiming for some time next Monday or Tuesday, if we don't get lucky and happen to sync up and do it earlier. I'll let the list know in any case. Thanks for your attention and help! Regards,... -jmpp From ryandesign at macports.org Thu Jun 7 15:10:51 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:21 2007 Subject: Automatic out-of-dateness checking for base and ports tree References: <00224473-B631-4205-AEBA-D231DC893AF7@dekorte.com> Message-ID: <0056A856-36A3-4151-8559-E6422F260748@macports.org> With some of the fundamental changes that have gone on in MacPorts 1.4.x since the 1.4.0 release, and since we only do downloadable disk images for the major releases, we have this problem that a lot of people seem to be downloading 1.4.0 and attempting to use it before selfupdating and reporting a whole slew of problems to the list which we then have to diagnose and it's always the same suggestion to fix it: update MacPorts. Or, people are installing MacPorts and not realizing that they have to periodically inform it to update itself. People may be under one of two reasonable expectations: 1) software keeps itself up to date, or 2) software that is not updated continues to function. MacPorts does neither: it doesn't auto-update the base software, but if you update the ports tree (or do a fresh install of MacPorts, which pulls down a current ports tree), it may not work with your old version of MacPorts. And this is a problem I think we should solve. Below is one such message. Steve says it might be nice if MacPorts would suggest updating itself if it encounters an error. I think we can probably do better than that, can't we? Couldn't we have MacPorts periodically (weekly?) check if a new version of MacPorts is available, and alert the user to this fact if they haven't run selfupdate themselves? I don't mean a cron task; I just mean, if the user happens to be running "port" right now and it's been a week since the last selfupdate, then print a message. There should be a file somewhere indicating the last time MacPorts checked its version, and this file would not exist for new installs, such that the first time somebody runs "port", it would check to see if it's outdated. It wouldn't have to update itself automatically. But it should inform the user if it is outdated. For those who are paranoid about apps phoning home, there could be a way to disable this feature. Something similar could be done for the ports tree, but for that we probably don't even need to check the server -- we know that ports get updated very frequently. We could just store the last time that a sync was done, and if it's been awhile (a day? a week?), alert the user that they should sync again. Thoughts? Begin forwarded message: > From: Steve Dekorte > Date: June 7, 2007 02:14:49 CDT > To: Ryan Schmidt > Cc: macports-users@lists.macosforge.org > Subject: Re: llvm port problem > > > On 6 Jun 2007, at 06:36 pm, Ryan Schmidt wrote: > >> I tried it just now, and llvm 2.0_0 installs just fine for me on >> Intel Core 2 Duo with Mac OS X 10.4.9 and MacPorts 1.4.42 and >> Xcode 2.4.1. >> >> What MacPorts version do you have? Is your ports tree up to date? >> Try "sudo port selfupdate" to update both. >> >> Do you have the latest Xcode? > > Thanks Ryan, the port version was the problem. It might save some > frustration and support requests if port suggest what you did when > a port fails. From mark at dxradio.demon.co.uk Thu Jun 7 18:06:44 2007 From: mark at dxradio.demon.co.uk (Mark Hattam) Date: Tue Oct 9 16:40:22 2007 Subject: Automatic out-of-dateness checking for base and ports tree In-Reply-To: <0056A856-36A3-4151-8559-E6422F260748@macports.org> References: <00224473-B631-4205-AEBA-D231DC893AF7@dekorte.com> <0056A856-36A3-4151-8559-E6422F260748@macports.org> Message-ID: Couldn't a version check be done when a user attempts a sudo port install and only if the MacPorts version is up to date, then the install goes ahead, otherwise it echoes a "please update" warning? Mark -- At 17:10 -0500 7/6/07, Ryan Schmidt wrote: >With some of the fundamental changes that have gone on in MacPorts >1.4.x since the 1.4.0 release, and since we only do downloadable >disk images for the major releases, we have this problem that a lot >of people seem to be downloading 1.4.0 and attempting to use it >before selfupdating and reporting a whole slew of problems to the >list which we then have to diagnose and it's always the same >suggestion to fix it: update MacPorts. Or, people are installing >MacPorts and not realizing that they have to periodically inform it >to update itself. People may be under one of two reasonable >expectations: 1) software keeps itself up to date, or 2) software >that is not updated continues to function. MacPorts does neither: it >doesn't auto-update the base software, but if you update the ports >tree (or do a fresh install of MacPorts, which pulls down a current >ports tree), it may not work with your old version of MacPorts. And >this is a problem I think we should solve. > >Below is one such message. Steve says it might be nice if MacPorts >would suggest updating itself if it encounters an error. I think we >can probably do better than that, can't we? Couldn't we have >MacPorts periodically (weekly?) check if a new version of MacPorts >is available, and alert the user to this fact if they haven't run >selfupdate themselves? I don't mean a cron task; I just mean, if the >user happens to be running "port" right now and it's been a week >since the last selfupdate, then print a message. There should be a >file somewhere indicating the last time MacPorts checked its >version, and this file would not exist for new installs, such that >the first time somebody runs "port", it would check to see if it's >outdated. > >It wouldn't have to update itself automatically. But it should >inform the user if it is outdated. For those who are paranoid about >apps phoning home, there could be a way to disable this feature. > >Something similar could be done for the ports tree, but for that we >probably don't even need to check the server -- we know that ports >get updated very frequently. We could just store the last time that >a sync was done, and if it's been awhile (a day? a week?), alert the >user that they should sync again. > >Thoughts? > > >Begin forwarded message: > >>From: Steve Dekorte >>Date: June 7, 2007 02:14:49 CDT >>To: Ryan Schmidt >>Cc: macports-users@lists.macosforge.org >>Subject: Re: llvm port problem >> >> >>On 6 Jun 2007, at 06:36 pm, Ryan Schmidt wrote: >> >>>I tried it just now, and llvm 2.0_0 installs just fine for me on >>>Intel Core 2 Duo with Mac OS X 10.4.9 and MacPorts 1.4.42 and >>>Xcode 2.4.1. >>> >>>What MacPorts version do you have? Is your ports tree up to date? >>>Try "sudo port selfupdate" to update both. >>> >>>Do you have the latest Xcode? >> >>Thanks Ryan, the port version was the problem. It might save some >>frustration and support requests if port suggest what you did when >>a port fails. > >_______________________________________________ >macports-dev mailing list >macports-dev@lists.macosforge.org >http://lists.macosforge.org/mailman/listinfo/macports-dev From ryandesign at macports.org Thu Jun 7 18:50:14 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:22 2007 Subject: Automatic out-of-dateness checking for base and ports tree In-Reply-To: References: <00224473-B631-4205-AEBA-D231DC893AF7@dekorte.com> <0056A856-36A3-4151-8559-E6422F260748@macports.org> Message-ID: <99618255-E7EF-4314-9700-BC8AACD69E6C@macports.org> On Jun 7, 2007, at 20:06, Mark Hattam wrote: > Couldn't a version check be done when a user attempts a > > sudo port install > > and only if the MacPorts version is up to date, then the install > goes ahead, otherwise it echoes a "please update" warning? Something like that is what I was thinking, yes. However, I wouldn't limit it to "port install"; I'd do it on any "port" command. Also, I wouldn't check every time, as that would be an unnecessary load on the server. That's why I suggested a timestamp file and checking only once a day, say. From sfiera at macports.org Thu Jun 7 19:01:08 2007 From: sfiera at macports.org (Chris Pickel) Date: Tue Oct 9 16:40:22 2007 Subject: Automatic out-of-dateness checking for base and ports tree In-Reply-To: <0056A856-36A3-4151-8559-E6422F260748@macports.org> References: <00224473-B631-4205-AEBA-D231DC893AF7@dekorte.com> <0056A856-36A3-4151-8559-E6422F260748@macports.org> Message-ID: On 07 Jun, 2007, at 18:10, Ryan Schmidt wrote: > MacPorts does neither: it doesn't auto-update the base software, > but if you update the ports tree (or do a fresh install of > MacPorts, which pulls down a current ports tree), it may not work > with your old version of MacPorts. And this is a problem I think we > should solve. You've identified a key point here: the problem occurs when the ports tree is synced without a selfupdate. It seems that this could be solved by keeping a file containing the target version in the ports tree. That file would be compared against ${prefix}/etc/macports/ mp_version to see if the installed version is new enough. This would require no periodic checking, other than the `port sync` which has to happen anyway. Nor would there be any possibility of the user having problems in the intermittent period between the server update and their check. Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070607/5003d50a/PGP.bin From ryandesign at macports.org Thu Jun 7 19:13:45 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:22 2007 Subject: Automatic out-of-dateness checking for base and ports tree In-Reply-To: References: <00224473-B631-4205-AEBA-D231DC893AF7@dekorte.com> <0056A856-36A3-4151-8559-E6422F260748@macports.org> Message-ID: <67D9CD1E-D3B9-481A-A01B-12F33AEF23AE@macports.org> On Jun 7, 2007, at 21:01, Chris Pickel wrote: > On 07 Jun, 2007, at 18:10, Ryan Schmidt wrote: > >> MacPorts does neither: it doesn't auto-update the base software, >> but if you update the ports tree (or do a fresh install of >> MacPorts, which pulls down a current ports tree), it may not work >> with your old version of MacPorts. And this is a problem I think >> we should solve. > > You've identified a key point here: the problem occurs when the > ports tree is synced without a selfupdate. It seems that this could > be solved by keeping a file containing the target version in the > ports tree. That file would be compared against ${prefix}/etc/ > macports/mp_version to see if the installed version is new enough. > > This would require no periodic checking, other than the `port sync` > which has to happen anyway. Nor would there be any possibility of > the user having problems in the intermittent period between the > server update and their check. Why do we even have two commands -- sync and selfupdate? Why can't we just have a single command which always does the right thing? From 0x62_0x6c_0x62 at pobox.com Fri Jun 8 16:45:59 2007 From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn) Date: Tue Oct 9 16:40:22 2007 Subject: New port: ajp-wsgi Message-ID: <8C602B0F-2B48-4006-BD73-641671B319FE@pobox.com> I forgot to email the list when I first added the ticket for ajp- wsgi, but I've just updated the ticket for version 1.0: If someone could commit, it'd be much appreciated. Bryan From ryandesign at macports.org Sat Jun 9 01:04:08 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:22 2007 Subject: [26000] trunk/dports/games/neverball/Portfile In-Reply-To: <20070609063745.E38086369AB@cvs.opensource.apple.com> References: <20070609063745.E38086369AB@cvs.opensource.apple.com> Message-ID: On Jun 9, 2007, at 01:37, source_changes@macosforge.org wrote: > Revision: 26000 > http://trac.macosforge.org/projects/macports/changeset/26000 > Author: markd@macports.org > Date: 2007-06-08 23:37:45 -0700 (Fri, 08 Jun 2007) > > Log Message: > ----------- > Closes #11834. Maintainer cleanup of portfile. > > Modified Paths: > -------------- > trunk/dports/games/neverball/Portfile > > Modified: trunk/dports/games/neverball/Portfile > =================================================================== > --- trunk/dports/games/neverball/Portfile 2007-06-09 06:25:49 UTC > (rev 25999) > +++ trunk/dports/games/neverball/Portfile 2007-06-09 06:37:45 UTC > (rev 26000) > @@ -2,34 +2,32 @@ > > PortSystem 1.0 > > -name neverball > -version 1.4.0 > -revision 1 > -categories games > -platforms darwin > -maintainers mvitocruz@gmail.com > -description Tilt the floor to roll a ball through an obstacle > course. > -long_description Tilt the floor to roll a ball through an obstacle \ > - course before time runs out. Neverball is part puzzle \ > - game, part action game, and entirely a test of skill. > +name neverball > +version 1.4.0 > +revision 2 > +categories games > +platforms darwin > +maintainers mvitocruz@gmail.com > +description Tilt the floor to roll a ball through an obstacle course. > +long_description \ > + Tilt the floor to roll a ball through an obstacle \ > + course before time runs out. Neverball is part puzzle \ > + game, part action game, and entirely a test of skill. > > -homepage http://icculus.org/neverball/ > +homepage http://icculus.org/neverball/ > master_sites ${homepage} > -checksums md5 a6cd860f1c2b7d8cecbcfc05ff228ef0 > -patchfiles patch-Makefile.diff patch-ball-main.c patch-putt-main.c > +checksums md5 a6cd860f1c2b7d8cecbcfc05ff228ef0 > +patchfiles patch-Makefile.diff patch-ball-main.c patch-putt-main.c > > -depends_lib bin:sdl-config:libsdl \ > - lib:libSDL_image:libsdl_image \ > - lib:libSDL_mixer:libsdl_mixer \ > - lib:libSDL_ttf:libsdl_ttf > +depends_lib bin:sdl-config:libsdl \ > + lib:libSDL_image:libsdl_image \ > + lib:libSDL_mixer:libsdl_mixer \ > + lib:libSDL_ttf:libsdl_ttf > > configure { > reinplace "s|./data|${prefix}/share/${name}|g" ${worksrcpath}/ > share/config.h > } > > -build.env CFLAGS=-I${prefix}/include \ > - LDFLAGS=-L${prefix}/lib > - > destroot { > xinstall -d -m 755 ${destroot}${prefix}/share/ > file copy ${worksrcpath}/data ${destroot}${prefix}/share/${name} The port revision should not have been bumped if the only changes were portfile cleanup. Only bump the revision if you want to force all users who already have the port installed to reinstall it. From ryandesign at macports.org Sat Jun 9 01:20:59 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:22 2007 Subject: livecheck.url containing semicolon Message-ID: <03E41122-4356-4746-B1DD-C52F3E7FD27A@macports.org> I want to set up livecheck for fontconfig and I want to use the following livecheck URL: ${homepage}release/?C=M;O=D How can I do this? I've tried: livecheck.url ${homepage}release/?C=M;O=D --> doesn't work because it gets cut off at the semicolon; "port -dv livecheck" shows: DEBUG: Fetching http://fontconfig.org/release/?C=M livecheck.url ${homepage}release/?C=M\;O=D --> doesn't work because of "unsupported protocol" which is weird: DEBUG: Fetching {http://fontconfig.org/release/?C=M;O=D} Error: cannot check if fontconfig was updated (unsupported protocol) livecheck.url "${homepage}release/?C=M;O=D" --> doesn't work for the same reason as above: "unsupported protocol". livecheck.url ${homepage}release/?C=M%3BO=D --> doesn't work because the server does not deliver the same response when I encode the semicolon as %3B. From cbellot at sky.fr Sat Jun 9 01:36:42 2007 From: cbellot at sky.fr (Cyril Bellot) Date: Tue Oct 9 16:40:22 2007 Subject: p5-berkeleydb dyld problem Message-ID: <20070609083642.GA23991@galapiat.desiles.bagolu.eu.org> Hello, Is there anyone here successfully using p5-berkeleydb ? I have a linking problem and wanted to check it out before posting a ticket : $ /opt/local/bin/perl -wc -T postgrey dyld: lazy symbol binding failed: Symbol not found: _db_version Referenced from: /opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level/auto/BerkeleyDB/BerkeleyDB.bundle Expected in: dynamic lookup dyld: Symbol not found: _db_version Referenced from: /opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level/auto/BerkeleyDB/BerkeleyDB.bundle Expected in: dynamic lookup Trace/BPT trap Maybe a linking problem at build, but I am not sure as the fail is about a dynamic lookup. $otool -L /opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level/auto/BerkeleyDB/BerkeleyDB.bundle /opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level/auto/BerkeleyDB/BerkeleyDB.bundle: /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.4.1) I've allready tried to reinstall this port... From n.oxyde at gmail.com Sat Jun 9 06:46:58 2007 From: n.oxyde at gmail.com (N_Ox) Date: Tue Oct 9 16:40:22 2007 Subject: livecheck.url containing semicolon In-Reply-To: <03E41122-4356-4746-B1DD-C52F3E7FD27A@macports.org> References: <03E41122-4356-4746-B1DD-C52F3E7FD27A@macports.org> Message-ID: <06191E32-B30A-4A2E-960A-689158E3026A@gmail.com> Sure, it's a bug with MacPorts. But you can usually fix it by replacing the semicolon with an &. Apache generally understand this character as a parameter separator. Le 9 juin 07 ? 10:20, Ryan Schmidt a ?crit : > I want to set up livecheck for fontconfig and I want to use the > following livecheck URL: > > ${homepage}release/?C=M;O=D > > How can I do this? I've tried: > > > livecheck.url ${homepage}release/?C=M;O=D > > --> doesn't work because it gets cut off at the semicolon; "port - > dv livecheck" shows: > > DEBUG: Fetching http://fontconfig.org/release/?C=M > > > livecheck.url ${homepage}release/?C=M\;O=D > > --> doesn't work because of "unsupported protocol" which is weird: > > DEBUG: Fetching {http://fontconfig.org/release/?C=M;O=D} > Error: cannot check if fontconfig was updated (unsupported protocol) > > > livecheck.url "${homepage}release/?C=M;O=D" > > --> doesn't work for the same reason as above: "unsupported protocol". > > > livecheck.url ${homepage}release/?C=M%3BO=D > > --> doesn't work because the server does not deliver the same > response when I encode the semicolon as %3B. > > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev -- Anthony Ramine, a lazy french student. nox@macports.org From ryandesign at macports.org Sat Jun 9 12:03:02 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:22 2007 Subject: livecheck.url containing semicolon In-Reply-To: <06191E32-B30A-4A2E-960A-689158E3026A@gmail.com> References: <03E41122-4356-4746-B1DD-C52F3E7FD27A@macports.org> <06191E32-B30A-4A2E-960A-689158E3026A@gmail.com> Message-ID: On Jun 9, 2007, at 08:46, N_Ox wrote: > Le 9 juin 07 ? 10:20, Ryan Schmidt a ?crit : > >> I want to set up livecheck for fontconfig and I want to use the >> following livecheck URL: >> >> ${homepage}release/?C=M;O=D >> >> How can I do this? I've tried: > > Sure, it's a bug with MacPorts. > But you can usually fix it by replacing the semicolon with an &. > Apache generally understand this character as a parameter separator. Thanks for the tip; I didn't even think to try that. That works great. Still, we should probably fix the bug... From eridius at macports.org Sat Jun 9 16:17:14 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:40:22 2007 Subject: livecheck.url containing semicolon In-Reply-To: References: <03E41122-4356-4746-B1DD-C52F3E7FD27A@macports.org> <06191E32-B30A-4A2E-960A-689158E3026A@gmail.com> Message-ID: It's not a bug. It's the fact that the semicolon character is treated the same as a newline, in that it separates commands. This is a Tcl language feature. If you want a semicolon, either surround the entire value with double- quotes, or use a backslash to escape the semicolon. livecheck.url "${homepage}release/?C=M;O=D" livecheck.url ${homepage}release/?C=M\;O=D On Jun 9, 2007, at 12:03 PM, Ryan Schmidt wrote: > On Jun 9, 2007, at 08:46, N_Ox wrote: > >> Le 9 juin 07 ? 10:20, Ryan Schmidt a ?crit : >> >>> I want to set up livecheck for fontconfig and I want to use the >>> following livecheck URL: >>> >>> ${homepage}release/?C=M;O=D >>> >>> How can I do this? I've tried: >> >> Sure, it's a bug with MacPorts. >> But you can usually fix it by replacing the semicolon with an &. >> Apache generally understand this character as a parameter separator. > > Thanks for the tip; I didn't even think to try that. That works great. > > Still, we should probably fix the bug... -- 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/20070609/6dd65f94/attachment.html From eridius at macports.org Sat Jun 9 17:44:15 2007 From: eridius at macports.org (Kevin Ballard) Date: Tue Oct 9 16:40:22 2007 Subject: livecheck.url containing semicolon In-Reply-To: References: <03E41122-4356-4746-B1DD-C52F3E7FD27A@macports.org> <06191E32-B30A-4A2E-960A-689158E3026A@gmail.com> Message-ID: <8DC28926-A609-49D9-9B68-81C6512B14E6@macports.org> Ok, it actually was a bug, but not with semicolons - the livecheck target wasn't de-escaping the URL, so the presence of any whitespace, semicolons, or curly braces would cause this issue. I've fixed the problem in r26041. On Jun 9, 2007, at 4:17 PM, Kevin Ballard wrote: > It's not a bug. It's the fact that the semicolon character is > treated the same as a newline, in that it separates commands. This > is a Tcl language feature. > > If you want a semicolon, either surround the entire value with > double-quotes, or use a backslash to escape the semicol