From simon at ruderich.com Wed Aug 1 09:09:10 2007 From: simon at ruderich.com (Simon Ruderich) Date: Tue Oct 9 16:40:29 2007 Subject: Trac tickets Message-ID: <46B0B026.3000305@ruderich.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, because I recently said that there are fixes in Trac which aren't noticed I just started collecting them to help the developers with svn access. Here is an (incomplete) list of tickets which should be ready for checkin. (I'm also CCing the maintainers of the ports which have one.) + http://trac.macports.org/projects/macports/ticket/12068 Patch for +universal builds fine on my Intel MacBook, but fails on my PowerPC iMac. But the non universal build works fine on both. So I think the patch should be submitted to svn. + http://trac.macports.org/projects/macports/ticket/12207 Patch submitted to update to newest version, fixes the bug. + http://trac.macports.org/projects/macports/ticket/12364 Patch works fine for me. + http://trac.macports.org/projects/macports/ticket/12368 portfile worked for me but I added a patch which also downloads the data file and so lets the user directly use raceintospace without doing anything else. + http://trac.macports.org/projects/macports/ticket/11895 My fix for the portfile could also be added. But there seems to be an error in macports with build.env which should be checked. + http://trac.macports.org/projects/macports/ticket/11802 portfile works for me. But I think the configure.env line is not necessary anymore; I also don't know if port:python24 is really necessary. I created a portfile before I found this and it worked without python24. + http://trac.macports.org/projects/macports/ticket/11509 portfile installs fine for me, I don't have any application which uses it so I can't say for sure it works. + http://trac.macports.org/projects/macports/ticket/12203 Fix for the portfile (there was a new release). Also added a patch for the mplayer portfile as suggested by the ticket. Thanks for your help, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGsLAmYRX4BO+zMikRCrqWAJ95hIHWPNuuDrsyfPU9OzixG73P9wCgjsrj 2vnV8ElWGbGouKm7qwNR63M= =P3fp -----END PGP SIGNATURE----- From simon at ruderich.com Wed Aug 1 09:13:59 2007 From: simon at ruderich.com (Simon Ruderich) Date: Tue Oct 9 16:40:29 2007 Subject: Update p7zip to version 4.51 In-Reply-To: <022936FF-0BEE-40F6-9E4E-ED5DF801260A@macports.org> References: <46AF6327.4090800@ruderich.com> <022936FF-0BEE-40F6-9E4E-ED5DF801260A@macports.org> Message-ID: <46B0B147.7020800@ruderich.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Ryan Schmidt wrote: > On Jul 31, 2007, at 11:28, Simon Ruderich wrote: > >> could you please update the Portfile for p7zip to version 4.51. I >> attached a patch for this. It works fine for me. > > Done in r27377. Thanks. Thanks for your quick help, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGsLFHYRX4BO+zMikRCmJ/AJ0XiyG89xGyc64CI9K0fgZDIOq5WwCgt0RF vpXBGFTMzmJs6p8UGn63u34= =FOSj -----END PGP SIGNATURE----- From simon at ruderich.com Wed Aug 1 09:18:05 2007 From: simon at ruderich.com (Simon Ruderich) Date: Tue Oct 9 16:40:29 2007 Subject: Trac tickets In-Reply-To: <46B0B026.3000305@ruderich.com> References: <46B0B026.3000305@ruderich.com> Message-ID: <46B0B23D.1040105@ruderich.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Sorry, I forgot to CC the maintainers. Doing this now. Simon Simon Ruderich wrote: > Hi, > > because I recently said that there are fixes in Trac which aren't > noticed I just started collecting them to help the developers with svn > access. Here is an (incomplete) list of tickets which should be ready > for checkin. (I'm also CCing the maintainers of the ports which have one.) > > + http://trac.macports.org/projects/macports/ticket/12068 > Patch for +universal builds fine on my Intel MacBook, but fails on my > PowerPC iMac. But the non universal build works fine on both. So I > think the patch should be submitted to svn. > > + http://trac.macports.org/projects/macports/ticket/12207 > Patch submitted to update to newest version, fixes the bug. > > + http://trac.macports.org/projects/macports/ticket/12364 > Patch works fine for me. > > + http://trac.macports.org/projects/macports/ticket/12368 > portfile worked for me but I added a patch which also downloads the > data file and so lets the user directly use raceintospace without > doing anything else. > > + http://trac.macports.org/projects/macports/ticket/11895 > My fix for the portfile could also be added. But there seems to be an > error in macports with build.env which should be checked. > > + http://trac.macports.org/projects/macports/ticket/11802 > portfile works for me. But I think the configure.env line is not > necessary anymore; I also don't know if port:python24 is really > necessary. I created a portfile before I found this and it worked > without python24. > > + http://trac.macports.org/projects/macports/ticket/11509 > portfile installs fine for me, I don't have any application which uses > it so I can't say for sure it works. > > + http://trac.macports.org/projects/macports/ticket/12203 > Fix for the portfile (there was a new release). Also added a patch for > the mplayer portfile as suggested by the ticket. > > Thanks for your help, > Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGsLI9YRX4BO+zMikRCq8WAJ9rXPVArNgEhXAftLzgxZohocBaRQCg2ee/ 1AvPT9ZCt984aZuVcUg+DRw= =xX5B -----END PGP SIGNATURE----- From jmpp at macports.org Wed Aug 1 09:51:08 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:29 2007 Subject: MacPorts 1.5.1? Message-ID: <0D29483E-8C3A-45CD-8DE4-E539019C3D6A@macports.org> Good afternoon everyone! Thankfully there haven't been any major issues reported against MacPorts 1.5.0, but there has been an important number of small bug fixes against base committed to trunk since the release. So, are we ripe for 1.5.1? Or does anyone want me to wait for something else? Or, on the other hand, would someone prefer to see something currently in trunk *not* committed to the release branch? How about Eugene''s and Chris' GSoC work? Are those safe for general public consumption? I'll work through the ChangeLog while I wait for replies to this message and work on merging the (entire?) delta to the branch. Once that's ready I'll see about releasing 1.5.1 on a light schedule (no rushes) but hopefully sooner than later, so that the delta doesn't keep on piling up. So get your feedback in! Regards to all,... -jmpp From ernest.prabhakar at gmail.com Wed Aug 1 10:55:30 2007 From: ernest.prabhakar at gmail.com (Ernest Prabhakar) Date: Tue Oct 9 16:40:29 2007 Subject: MacPorts 1.5.1? In-Reply-To: <0D29483E-8C3A-45CD-8DE4-E539019C3D6A@macports.org> References: <0D29483E-8C3A-45CD-8DE4-E539019C3D6A@macports.org> Message-ID: <37C44023-6698-49F5-86E4-F0AAAD0DBB72@gmail.com> Hi Juan, My gut sense would be to do a 1.5.1 sooner, and do a 1.6 with the GSoC changes -- as that is likely to require some "bake" time... -enp On Aug 1, 2007, at 9:51 AM, Juan Manuel Palacios wrote: > > Good afternoon everyone! > > Thankfully there haven't been any major issues reported against > MacPorts 1.5.0, but there has been an important number of small bug > fixes against base committed to trunk since the release. > > So, are we ripe for 1.5.1? Or does anyone want me to wait for > something else? Or, on the other hand, would someone prefer to see > something currently in trunk *not* committed to the release branch? > How about Eugene''s and Chris' GSoC work? Are those safe for > general public consumption? > > I'll work through the ChangeLog while I wait for replies to this > message and work on merging the (entire?) delta to the branch. Once > that's ready I'll see about releasing 1.5.1 on a light schedule (no > rushes) but hopefully sooner than later, so that the delta doesn't > keep on piling up. So get your feedback in! > > Regards to all,... > > > -jmpp > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From simon at ruderich.com Wed Aug 1 14:17:41 2007 From: simon at ruderich.com (Simon Ruderich) Date: Tue Oct 9 16:40:29 2007 Subject: Trac tickets In-Reply-To: <46B0B23D.1040105@ruderich.com> References: <46B0B026.3000305@ruderich.com> <46B0B23D.1040105@ruderich.com> Message-ID: <46B0F875.5020105@ruderich.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I found some more patches in Trac which can be checked into subversion. - - http://trac.macports.org/projects/macports/ticket/12208 Works fine for me. But additionally to the patch the "revision" entry should be removed with the upgrade. - - http://trac.macports.org/projects/macports/ticket/12378 Added patch which fixes the reported bug. - - http://trac.macports.org/projects/macports/ticket/12118 Added patch for what the ticket creator reported. But maybe the patchfile should be stored in the files directory and not longer be loaded from a server because it's only 40 lines and then we are independent from this other server. - - http://trac.macports.org/projects/macports/ticket/12056 Added patch for the ticket reporter's request. - - http://trac.macports.org/projects/macports/ticket/12063 Used patch of the ticket reporter and added the newest version update to it; also fixed the livecheck. - - http://trac.macports.org/projects/macports/ticket/12064 Again used the patch of the ticket reporter, but now only fixed the livecheck. - - http://trac.macports.org/projects/macports/ticket/12122 This ticket should be closed, it was fixed in r26191. - - http://trac.macports.org/projects/macports/ticket/12380 A new ticket of me to update pstoedit; found out it needs an update. - - http://trac.macports.org/projects/macports/ticket/11614 Used patch of the ticket reporter and added epoch data to cause an update (I hope this works, please check it; found no documentation about it); also remove unnecessary configure.env data from the portfile. All these tickets work fine for me, on a PowerPC and an Intel mac. Thanks for your help, Simon PS: I'm going on holiday tomorrow for nearly a week without internet access so I can't answer you in this time. Will do it when I'm back. - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGsPh0YRX4BO+zMikRCulzAKCMnXBvRXoT8Z1bsdFQ98hi3DGs9wCgwiHP Sh0KVN3ck45L3ZSZq69lyFo= =jQi6 -----END PGP SIGNATURE----- From bentley at crenelle.com Thu Aug 2 00:24:47 2007 From: bentley at crenelle.com (Michael Brian Bentley) Date: Tue Oct 9 16:40:29 2007 Subject: stackless Message-ID: I posted this question to the users list on Monday but received no reply. I'd like to work/play with the stackless (www.stackless.com) variant of python. How hard would it be for me to create a variant of the mac ports python25 installer that installs an independent copy of python25 with the stackless additions from http://www.stackless.com and the relevant svn repository? The macports file tree appears to be straightforward, altho I haven't found a road map. -Mike From simon at ruderich.com Thu Aug 2 03:20:06 2007 From: simon at ruderich.com (Simon Ruderich) Date: Tue Oct 9 16:40:29 2007 Subject: Problem with liveupdate (zlib) In-Reply-To: References: <4694FA43.3060403@ruderich.com> <46950973.5080007@ruderich.com> <20070711170707.GA5961@velsheda.lateralis.org> <46952D5D.9000909@ruderich.com> <33C3A31F-F90D-48E1-ABC7-FA981E1B38C3@macports.org> <46AF683E.4080905@ruderich.com> Message-ID: <46B1AFD6.6030109@ruderich.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Ryan Schmidt wrote: > Reading portlivecheck.tcl, I see that if the homepage is not available, > it already prints "cannot check if $portname was updated ($error)". > > It already prints the regex if the regex does not match. I suggested 2 > weeks ago that the regex should always be printed, and since there have > been no objections since then, I implemented that now (r27379). > > This is all in debug mode only. Thanks for this fix, I hope it makes it into the next release. > Yes, I found the revision that broke it (r26041), Kevin Ballard provided > a fix, and I tested and committed it (r27079). Also thanks for this fix, but we should remember it means all the portfiles will need to be updated after this fix when the next version of macports is released. > Trac is our bug tracking system, and the mailing list is our discussion > system, so it seems to me that bugs are properly reported to Trac. > However, the reporter must remember to Cc the appropriate people, > otherwise nobody is notified of the ticket's existence. Also we don't > have a good system in place for ports that are unmaintained. I'm not sure if this is mentioned in the documentation but it should also be displayed on the "New ticket" page. So it's clear for the reporter of the ticket to add this. > If you find forgotten patches in Trac, and the ticket is not assigned to > someone and the port has no maintainer, email the list with the ticket > URL and someone can have a look at them and commit them. If the ticket > is assigned to someone, email that person. If the port has a maintainer, > email that person. I just did some search in Trac and send the links for the tickes to macports-dev. I also CCed the maintainers if the ports had one. Thanks for your help, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGsa/WYRX4BO+zMikRCuLUAKDBD0119lpB0YowG9abAvPWIMRQBwCgjq6m fqu/NR9p8dVrwy/aqOaBfY0= =yK6y -----END PGP SIGNATURE----- From dluke at geeklair.net Thu Aug 2 07:30:49 2007 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue Oct 9 16:40:29 2007 Subject: stackless In-Reply-To: References: Message-ID: On Aug 2, 2007, at 3:24 AM, Michael Brian Bentley wrote: > I posted this question to the users list on Monday but received no > reply. > > I'd like to work/play with the stackless (www.stackless.com) > variant of python. > > How hard would it be for me to create a variant of the mac ports > python25 installer that installs an independent copy of python25 > with the stackless additions from http://www.stackless.com and the > relevant svn repository? The macports file tree appears to be > straightforward, altho I haven't found a road map. I would probably make sense to make a separate port (based off of the python25 port) if you want to be able to install them at the same time. You could check out the old an new guides (new guide in progress and will eventually replace the old one). http://geeklair.net/macports_guide/ http://geeklair.net/new_macports_guide/ Between them and the portfile manpage, you should be able to get started figuring it out. -- 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/20070802/29b023ba/PGP.bin From ryandesign at macports.org Thu Aug 2 15:24:01 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:29 2007 Subject: Problem with liveupdate (zlib) In-Reply-To: <46B1AFD6.6030109@ruderich.com> References: <4694FA43.3060403@ruderich.com> <46950973.5080007@ruderich.com> <20070711170707.GA5961@velsheda.lateralis.org> <46952D5D.9000909@ruderich.com> <33C3A31F-F90D-48E1-ABC7-FA981E1B38C3@macports.org> <46AF683E.4080905@ruderich.com> <46B1AFD6.6030109@ruderich.com> Message-ID: <21F7C0FF-4ACB-4241-8A24-D35BCD603A2A@macports.org> Sn Aug 2, 2007, at 05:20, Simon Ruderich wrote: > Ryan Schmidt wrote: > >> Reading portlivecheck.tcl, I see that if the homepage is not >> available, >> it already prints "cannot check if $portname was updated ($error)". >> >> It already prints the regex if the regex does not match. I >> suggested 2 >> weeks ago that the regex should always be printed, and since there >> have >> been no objections since then, I implemented that now (r27379). >> >> This is all in debug mode only. > > Thanks for this fix, I hope it makes it into the next release. So do I. >> Yes, I found the revision that broke it (r26041), Kevin Ballard >> provided >> a fix, and I tested and committed it (r27079). > > Also thanks for this fix, but we should remember it means all the > portfiles will need to be updated after this fix when the next version > of macports is released. Only portfiles whose livecheck regexen have been updated to work with the "broken" livecheck code will again have to be updated to work with the "fixed" code. Portfiles which were never initially modified will work as usual again once 1.5.1 is released. >> Trac is our bug tracking system, and the mailing list is our >> discussion >> system, so it seems to me that bugs are properly reported to Trac. >> However, the reporter must remember to Cc the appropriate people, >> otherwise nobody is notified of the ticket's existence. Also we don't >> have a good system in place for ports that are unmaintained. > > I'm not sure if this is mentioned in the documentation but it should > also be displayed on the "New ticket" page. So it's clear for the > reporter of the ticket to add this. It is quite clearly mentioned in the TracTicketing wiki page. >> If you find forgotten patches in Trac, and the ticket is not >> assigned to >> someone and the port has no maintainer, email the list with the >> ticket >> URL and someone can have a look at them and commit them. If the >> ticket >> is assigned to someone, email that person. If the port has a >> maintainer, >> email that person. > > I just did some search in Trac and send the links for the tickes to > macports-dev. I also CCed the maintainers if the ports had one. Thanks, I'll have a look at those. From jmpp at macports.org Fri Aug 3 00:54:40 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:29 2007 Subject: New Trac ticketing guidelines implemented Message-ID: <55FC0A80-E4F8-4330-863D-D2CA28E7F1BF@macports.org> Hello everyone! Not long ago some of us discussed on this list a new set of ticketing guidelines to match our current practices with Trac. The result of such brainstorming was the Wiki doc I compiled at [1] and which Mark has been fleshing out into the new guide at [2] After much waiting I finally went ahead and implemented most of what's said there through Trac's admin interface, so everyone should now see new fields in new ticket submissions per the new guidelines. Legacy fields need to be updated directly in Trac's database through SQL magic as follows: 1) Ticket Type: * task & contribution --> enhancement; 2) Priorities: * Expected --> Normal; * Important & Blocker --> High; * Nice to have --> Low; 3) Component: * dp-cocoa & uninstaller --> deprecated; Chris Pickel suggested the following template: 1) * update ticket set type='enhancement' where type='task' or type='contribution' 2) * update ticket set component='deprecated' where component='uninstaller' or component='dp-cocoa' * update ticket set priority='High' where priority='Important' or priority='Blocker' * update ticket set priority='Normal' where priority='Expected' 3) * update ticket set priority='Low' where priority='Nice to have' I can ask kvv to apply this for us straight into the DB, but would love it if they could be verified to work (I don't have Trac installed at the moment to test locally). New Roadmap is also in place, with new self-explanatory "MacPorts base enhancements" and "MacPorts base bugs" milestones created to hold tickets detailing MacPorts' own bugs and improvements separately, mirroring "Port Enhancements" and "Port Bugs" respectively. We toyed for a while with the idea of using the "core" moniker rather than base, arguing that the latter might be a bit confusing.... but I ultimately stuck with base 'cause I figured we prefer people who are clueful enough to figure out what "base" stands for in MacPorts parlance as the ones submitting tickets against such a, eeehhmmm, core component of the project. Added to that is the fact that "base" is already all over the place, so it only makes sense... Tickets in the former "Needs developer review" milestone were moved to base bugs and "Feature requests" to base enhancements; please feel free to relocate your ticket appropriately if you feel this reordering does not do it justice. Thanks to all who helped polish such an important user <--> developer interface as the ticketing guidelines! If you have suggestions and/or corrections (am I missing anything here in this message? I surely am, it's 4am ;-).... you know what to do, *cough* ticket per the new guidelines *cough*. Regards,... -jmpp [1] http://trac.macports.org/projects/macports/wiki/NewTracTicketing [2] http://geeklair.net/new_macports_guide/#id942789 From jmpp at macports.org Fri Aug 3 01:05:30 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:29 2007 Subject: MacPorts 1.5.1? In-Reply-To: <37C44023-6698-49F5-86E4-F0AAAD0DBB72@gmail.com> References: <0D29483E-8C3A-45CD-8DE4-E539019C3D6A@macports.org> <37C44023-6698-49F5-86E4-F0AAAD0DBB72@gmail.com> Message-ID: <00A1B347-6B83-4934-AB66-0E6FFD5B187F@macports.org> On Aug 1, 2007, at 1:55 PM, Ernest Prabhakar wrote: > Hi Juan, > > My gut sense would be to do a 1.5.1 sooner, and do a 1.6 with the > GSoC changes -- as that is likely to require some "bake" time... > > -enp Even though (IIRC) some of the GSoC work is still "unhooked" from the main code (defaulting to off in the code and/or lack of autoconf hooks), deferring it to 1.6 is my current inclination. I'll work with this mindset until recommended otherwise, which I would openly accept. Regards,.... -jmpp From rhwood at mac.com Fri Aug 3 02:53:56 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:29 2007 Subject: New Trac ticketing guidelines implemented In-Reply-To: <55FC0A80-E4F8-4330-863D-D2CA28E7F1BF@macports.org> References: <55FC0A80-E4F8-4330-863D-D2CA28E7F1BF@macports.org> Message-ID: UNDO THIS! All but 1 active ticket assigned to me have been deactivated, and there are now only 10 active tickets in the database. All tickets by Milestone (including closed) only returns 180 items. Most of my tickets are now just gone including tasks that I created for myself. Please unroll these changes until you can figure out how to apply them without destroying the database. I missed the original discussion, but I do not want to lose the ability to create tasks marked as Ticket Type: task. On 3 Aug 2007, at 03:54, Juan Manuel Palacios wrote: > > Hello everyone! > > Not long ago some of us discussed on this list a new set of > ticketing guidelines to match our current practices with Trac. The > result of such brainstorming was the Wiki doc I compiled at [1] and > which Mark has been fleshing out into the new guide at [2] > > After much waiting I finally went ahead and implemented most of > what's said there through Trac's admin interface, so everyone > should now see new fields in new ticket submissions per the new > guidelines. Legacy fields need to be updated directly in Trac's > database through SQL magic as follows: > > 1) Ticket Type: > * task & contribution --> enhancement; > > 2) Priorities: > * Expected --> Normal; > * Important & Blocker --> High; > * Nice to have --> Low; > > 3) Component: > * dp-cocoa & uninstaller --> deprecated; > > > Chris Pickel suggested the following template: > > 1) > * update ticket set type='enhancement' where type='task' or > type='contribution' > > 2) > * update ticket set component='deprecated' where > component='uninstaller' or component='dp-cocoa' > * update ticket set priority='High' where priority='Important' or > priority='Blocker' > * update ticket set priority='Normal' where priority='Expected' > > 3) > * update ticket set priority='Low' where priority='Nice to have' > > > I can ask kvv to apply this for us straight into the DB, but would > love it if they could be verified to work (I don't have Trac > installed at the moment to test locally). > > New Roadmap is also in place, with new self-explanatory "MacPorts > base enhancements" and "MacPorts base bugs" milestones created to > hold tickets detailing MacPorts' own bugs and improvements > separately, mirroring "Port Enhancements" and "Port Bugs" > respectively. We toyed for a while with the idea of using the > "core" moniker rather than base, arguing that the latter might be a > bit confusing.... but I ultimately stuck with base 'cause I figured > we prefer people who are clueful enough to figure out what "base" > stands for in MacPorts parlance as the ones submitting tickets > against such a, eeehhmmm, core component of the project. Added to > that is the fact that "base" is already all over the place, so it > only makes sense... Tickets in the former "Needs developer review" > milestone were moved to base bugs and "Feature requests" to base > enhancements; please feel free to relocate your ticket > appropriately if you feel this reordering does not do it justice. > > Thanks to all who helped polish such an important user <--> > developer interface as the ticketing guidelines! If you have > suggestions and/or corrections (am I missing anything here in this > message? I surely am, it's 4am ;-).... you know what to do, *cough* > ticket per the new guidelines *cough*. > > Regards,... > > > -jmpp > > [1] http://trac.macports.org/projects/macports/wiki/NewTracTicketing > [2] http://geeklair.net/new_macports_guide/#id942789 > _______________________________________________ > 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 rhwood at mac.com Fri Aug 3 03:03:26 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:29 2007 Subject: New Trac ticketing guidelines implemented In-Reply-To: References: <55FC0A80-E4F8-4330-863D-D2CA28E7F1BF@macports.org> Message-ID: On 3 Aug 2007, at 05:53, Randall Wood wrote: > UNDO THIS! > > All but 1 active ticket assigned to me have been deactivated, and > there are now only 10 active tickets in the database. All tickets > by Milestone (including closed) only returns 180 items. I was able to find 6000+ tickets using a custom query, but still, can you revert this change until you figure out how to do it without closing every single affected ticket? If I do a custom query for my not closed tickets, I find all my open tickets, but for some reason they are considered inactive, and do not show up in report 8 "Active tickets (mine first)" > Most of my tickets are now just gone including tasks that I created > for myself. I found them but they seem to be in some strange limbo land. See above. > Please unroll these changes until you can figure out how to apply > them without destroying the database. > > I missed the original discussion, but I do not want to lose the > ability to create tasks marked as Ticket Type: task. > > On 3 Aug 2007, at 03:54, Juan Manuel Palacios wrote: > >> >> Hello everyone! >> >> Not long ago some of us discussed on this list a new set of >> ticketing guidelines to match our current practices with Trac. The >> result of such brainstorming was the Wiki doc I compiled at [1] >> and which Mark has been fleshing out into the new guide at [2] >> >> After much waiting I finally went ahead and implemented most of >> what's said there through Trac's admin interface, so everyone >> should now see new fields in new ticket submissions per the new >> guidelines. Legacy fields need to be updated directly in Trac's >> database through SQL magic as follows: >> >> 1) Ticket Type: >> * task & contribution --> enhancement; >> >> 2) Priorities: >> * Expected --> Normal; >> * Important & Blocker --> High; >> * Nice to have --> Low; >> >> 3) Component: >> * dp-cocoa & uninstaller --> deprecated; >> >> >> Chris Pickel suggested the following template: >> >> 1) >> * update ticket set type='enhancement' where type='task' or >> type='contribution' >> >> 2) >> * update ticket set component='deprecated' where >> component='uninstaller' or component='dp-cocoa' >> * update ticket set priority='High' where priority='Important' or >> priority='Blocker' >> * update ticket set priority='Normal' where priority='Expected' >> >> 3) >> * update ticket set priority='Low' where priority='Nice to have' >> >> >> I can ask kvv to apply this for us straight into the DB, but >> would love it if they could be verified to work (I don't have Trac >> installed at the moment to test locally). >> >> New Roadmap is also in place, with new self-explanatory "MacPorts >> base enhancements" and "MacPorts base bugs" milestones created to >> hold tickets detailing MacPorts' own bugs and improvements >> separately, mirroring "Port Enhancements" and "Port Bugs" >> respectively. We toyed for a while with the idea of using the >> "core" moniker rather than base, arguing that the latter might be >> a bit confusing.... but I ultimately stuck with base 'cause I >> figured we prefer people who are clueful enough to figure out what >> "base" stands for in MacPorts parlance as the ones submitting >> tickets against such a, eeehhmmm, core component of the project. >> Added to that is the fact that "base" is already all over the >> place, so it only makes sense... Tickets in the former "Needs >> developer review" milestone were moved to base bugs and "Feature >> requests" to base enhancements; please feel free to relocate your >> ticket appropriately if you feel this reordering does not do it >> justice. >> >> Thanks to all who helped polish such an important user <--> >> developer interface as the ticketing guidelines! If you have >> suggestions and/or corrections (am I missing anything here in this >> message? I surely am, it's 4am ;-).... you know what to do, >> *cough* ticket per the new guidelines *cough*. >> >> Regards,... >> >> >> -jmpp >> >> [1] http://trac.macports.org/projects/macports/wiki/NewTracTicketing >> [2] http://geeklair.net/new_macports_guide/#id942789 >> _______________________________________________ >> 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." > > > _______________________________________________ > 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 jmpp at macports.org Fri Aug 3 07:54:25 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:29 2007 Subject: New Trac ticketing guidelines implemented In-Reply-To: References: <55FC0A80-E4F8-4330-863D-D2CA28E7F1BF@macports.org> Message-ID: <03F43833-523A-48D6-9649-D9EBAC42B9D9@macports.org> On Aug 3, 2007, at 6:03 AM, Randall Wood wrote: > > On 3 Aug 2007, at 05:53, Randall Wood wrote: > >> UNDO THIS! >> >> All but 1 active ticket assigned to me have been deactivated, and >> there are now only 10 active tickets in the database. All tickets >> by Milestone (including closed) only returns 180 items. > > I was able to find 6000+ tickets using a custom query, but still, > can you revert this change until you figure out how to do it > without closing every single affected ticket? > > If I do a custom query for my not closed tickets, I find all my > open tickets, but for some reason they are considered inactive, and > do not show up in report 8 "Active tickets (mine first)" > >> Most of my tickets are now just gone including tasks that I >> created for myself. > > I found them but they seem to be in some strange limbo land. See > above. I'm sure this is nothing to worry about, I'm positive actual tickets have actually *not* been affected in any way (you can for example browse the roadmap, actually diving into each milestone, and realize there are many more than just 10 active tickets in the database). I believe the only thing at fault here is Trac's ability to query its db for tickets on an automated fashion through the reports facility, given how some of the fields changed per the new guidelines. Each report is just an SQL statement (that we can thankfully tailor to our needs), so I'm sure what we need to do is figure out how they broke and thus edit them. Can you please provide me the queries that worked for you in order to compare? Thanks for your feedback! Regards,.... -jmpp From jmpp at macports.org Fri Aug 3 08:02:27 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:29 2007 Subject: Trac Ticketing guidelines In-Reply-To: References: <633E9FD3-E5F4-4843-BEFB-235A5A8A664A@macports.org> Message-ID: <7525FA1E-4A8F-428D-A653-89C0EE3900CE@macports.org> On Jul 27, 2007, at 2:42 AM, markd@macports.org wrote: > Juan Manuel Palacios writes: >> >> http://trac.macports.org/projects/macports/wiki/NewTracTicketing > > I just committed a try at the Trac guidelines in the new guide. > See what > you think and modify. I also threw in a screenshot in that > section. If > it seems unnecessary or not helpful it could be yanked. > Thanks for embarking on this Mark, great work! And also nice going with the picture, I think it looks great in there! Going forward I would love to see the TracTicketing document be turned into a redirect to these new guidelines and also somehow link them off the http://trac.macports.org/projects/macports/newticket page through some kind of banner at top right corner.I'll talk to Kvv about that. We can also delete my NewTicketingGuidelines document, but I would like to first finish all the pending items before doing so. > Also, can we describe better the difference between "component" and > "milestone". The overlap is confusing. Or could these two be > combined in > some way? > I'll see how the descriptions can be improved, but I'd very much prefer either keeping them separate or on the other hand safeguarding the milestones as much as possible, since they are what feeds the roadmap. On the topic of correcting documentation, I uploaded two patches to the corresponding milestone and will shortly provide a couple more, have a look if you may ;-) > Mark > Regards,... -jmpp From mccdo at iastate.edu Fri Aug 3 08:55:25 2007 From: mccdo at iastate.edu (Doug McCorkle) Date: Tue Oct 9 16:40:29 2007 Subject: Updated Portfile for flagpoll Message-ID: <2FAA2E1B-40F1-4186-BD32-0753099D253F@iastate.edu> Hello, I have attached an updated Portfile for flagpoll. Thanks. Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 1017 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070803/781477c2/Portfile.obj -------------- next part -------------- From mmoll at cs.rice.edu Fri Aug 3 09:27:17 2007 From: mmoll at cs.rice.edu (Mark Moll) Date: Tue Oct 9 16:40:29 2007 Subject: updated portfile for games/xmj Message-ID: <80B625D8-690C-469F-BA68-B62D816458F5@cs.rice.edu> Can someone please commit http://trac.macports.org/projects/macports/ ticket/12078, a version bump for games/xmj? -- Mark From raimue at macports.org Fri Aug 3 09:47:33 2007 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Tue Oct 9 16:40:29 2007 Subject: [27427] trunk/dports/graphics/gimp2/Portfile In-Reply-To: <20070803163045.EB02471F533@cvs.opensource.apple.com> References: <20070803163045.EB02471F533@cvs.opensource.apple.com> Message-ID: <46B35C25.7000006@macports.org> source_changes@macosforge.org wrote: > Revision > 27427 > Author > yves@macports.org > Date > 2007-08-03 09:30:45 -0700 (Fri, 03 Aug 2007) [...] > +variant without_python conflicts python24 { > + depends_lib-delete port:py25-gtk > + configure.env-delete PYTHON=${prefix}/bin/python2.5 > + configure.args-append --disable-python > +} > + I don't like this name without_*. I would prefer a variant +python and setting default_variants +python So if someone does not want python he/she can overwrite that using port install gimp2 -python What do you think about that? Rainer From adamore at email.it Fri Aug 3 09:59:18 2007 From: adamore at email.it (Andrea D'Amore) Date: Tue Oct 9 16:40:29 2007 Subject: new update ticket Message-ID: <2FA88E42-7B5A-4B69-BF83-D38B46B4DD90@email.it> Hi, I've created a new ticket to update aewm, I've patched the Portfile, deleted a patch file, and patched another patch file. Here it is: . Andrea adamore@email.it -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Una settimana da sogno nelle più belle località di vacanza, con Mondolastminute trovi ogni settimana l'offerta che fa per te! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6852&d=3-8 From yves at macports.org Fri Aug 3 10:04:19 2007 From: yves at macports.org (Yves de Champlain) Date: Tue Oct 9 16:40:29 2007 Subject: [27427] trunk/dports/graphics/gimp2/Portfile In-Reply-To: <46B35C25.7000006@macports.org> References: <20070803163045.EB02471F533@cvs.opensource.apple.com> <46B35C25.7000006@macports.org> Message-ID: <32A779CC-7D45-4B89-B520-8804433A1221@macports.org> Le 07-08-03 ? 12:47, Rainer M?ller a ?crit : > source_changes@macosforge.org wrote: >> Revision >> 27427 > 27427> >> Author >> yves@macports.org >> Date >> 2007-08-03 09:30:45 -0700 (Fri, 03 Aug 2007) > [...] >> +variant without_python conflicts python24 { >> + depends_lib-delete port:py25-gtk >> + configure.env-delete PYTHON=${prefix}/bin/python2.5 >> + configure.args-append --disable-python >> +} >> + > > I don't like this name without_*. I would prefer a variant +python and > setting > default_variants +python > > So if someone does not want python he/she can overwrite that using > port install gimp2 -python > > What do you think about that? For my part, I don't like default variants ... I think MacPorts really needs some sort of variants naming guidelines. yves From smilerliu at gmail.com Fri Aug 3 10:16:34 2007 From: smilerliu at gmail.com (Xin Liu) Date: Tue Oct 9 16:40:29 2007 Subject: [27427] trunk/dports/graphics/gimp2/Portfile In-Reply-To: <46B35C25.7000006@macports.org> References: <20070803163045.EB02471F533@cvs.opensource.apple.com> <46B35C25.7000006@macports.org> Message-ID: I don't like default variants either (except for those system-wide ones like darwin_8). Does "port info " show default variants? If it does not, it's not a good idea to use default variants. Best Regards, Xin Liu On 8/3/07, Rainer M?ller wrote: > source_changes@macosforge.org wrote: > > Revision > > 27427 > > Author > > yves@macports.org > > Date > > 2007-08-03 09:30:45 -0700 (Fri, 03 Aug 2007) > [...] > > +variant without_python conflicts python24 { > > + depends_lib-delete port:py25-gtk > > + configure.env-delete PYTHON=${prefix}/bin/python2.5 > > + configure.args-append --disable-python > > +} > > + > > I don't like this name without_*. I would prefer a variant +python and > setting > default_variants +python > > So if someone does not want python he/she can overwrite that using > port install gimp2 -python > > What do you think about that? > > Rainer From raimue at macports.org Fri Aug 3 10:45:35 2007 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Oct 9 16:40:29 2007 Subject: [27427] trunk/dports/graphics/gimp2/Portfile In-Reply-To: References: <20070803163045.EB02471F533@cvs.opensource.apple.com> <46B35C25.7000006@macports.org> Message-ID: <46B369BF.4010600@macports.org> Xin Liu wrote: > I don't like default variants either (except for those system-wide > ones like darwin_8). Does "port info " show default variants? If > it does not, it's not a good idea to use default variants. It could be changed to do so :-) I don't like the syntax +without_foo as it reads "with without foo" for me. Why do we have that +/- syntax if we don't use it? The syntax is straightforward as + selects and - deselects a feature provided by a variant. I like that more than deselecting variants with +no_foo or +without_foo And as Yves said, variant naming is totally inconsistent at the moment. There are variants which do the same but are named differently as +no_bdb or +without_bdb. As far as I could find there are the following prefixes: with_ without_ enable_ disable_ no_ If the naming were "correct" we could also make more use of variants.conf. Someone could set -bdb to never include BDB if it can be left out. Or +x11 to always build with support for x11. I would like that more than setting +no_bdb. But as said, port info should show default variants. And they could be also marked (with a star or something) in port variants. Rainer From dluke at geeklair.net Fri Aug 3 11:48:46 2007 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue Oct 9 16:40:29 2007 Subject: [27427] trunk/dports/graphics/gimp2/Portfile In-Reply-To: <46B369BF.4010600@macports.org> References: <20070803163045.EB02471F533@cvs.opensource.apple.com> <46B35C25.7000006@macports.org> <46B369BF.4010600@macports.org> Message-ID: On Aug 3, 2007, at 1:45 PM, Rainer M?ller wrote: > I don't like the syntax +without_foo as it reads "with without foo" > for > me. Why do we have that +/- syntax if we don't use it? We don't use it because it's currently broken (ie, the -variants that are selected aren't stored, so when you go to upgrade the port, it doesn't keep the same variant selection. Meanwhile, the +variants are stored, so things 'work' when you do an upgrade). > But as said, port info should show default variants. And they could be > also marked (with a star or something) in port variants. That seems like a good idea. You want to submit a patch? :) -- 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/20070803/6d825c63/PGP.bin From jmpp at macports.org Fri Aug 3 13:02:48 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:29 2007 Subject: GSoC Update: Registry In-Reply-To: <561510DC-573D-4CC2-B21F-B731306F5D20@macports.org> References: <561510DC-573D-4CC2-B21F-B731306F5D20@macports.org> Message-ID: Hello Chris! So good to hear about your progress on the revamped registry, kudos! Some comments following: On Jul 28, 2007, at 5:28 PM, Chris Pickel wrote: > So, here's the deal: > > > As (a couple of) you are aware, my project is to build a more > advanced registry; to keep more state for installed ports and in a > more structured fashion. > > I have written a pretty much feature-complete sqlite3-based > replacement for receipts and the filemap at this point. There is a > C library that's compiled as a static lib (cregistry), which is > later compiled into a Tcl module (registry2.0). There's a test > case; errors are thrown in such a way that they work with try/catch. > > I've also written a script to up-convert a user's existing receipts/ > filemap into the new format. It's reasonably fast (and was not so > before I got smarter with sqlite transactions). How would that script be run? Each user manually at their own discretion? Or through some upgrade glue internal to MacPorts? I would very much prefer the latter approach, something like my "upgrade" target in base/Makefile.in (later on I'll remove all that code once we consider enough time has gone by to upgrade most of our user base to the macports namespace, in the mean time I'm sure we can share that target for other upgrade purposes). > > > The Tcl code that makes *use* of the registry has not yet been > modified. So, I could commit registry2 now without screwing > anything up Not sure what you mean by this. What hasn't been modified and where? You mean that if you commit registry2.0 now, trunk would still be using the old registry & filemap until you "hook up" your code? > but I have two concerns: > > * Doing so would commit my local history (12 commits, I think). > CIA has the annoying habit of squaring the number of commit > messages sent out in sequence, and I don't want to flood #macports > with 144 commit messages. I would not worry one bit about this, message duplication is due to a misconfiguration on our side and we can always silence the CIA bot in the channel. Just let me know when you plan on committing and I'll take care of it. > > * I don't feel there's a need to include it in 1.5.1. If someone > wanted to go ahead and tag 1.5.1, that'd be great :) I'm working my way toward 1.5.1, hopefully soonish now (targeting mid next week). But, likewise, nothing to worry about here, I'm working with the sweet svnmerge.py on the 1.5 branch so I can cherry pick what we merge in from turnk and what stays out. Also, the release tags are created off release branches, not trunk, so that's more leeway there. > > > I'm still working on three things before I move on to the > dependency graph: > > * I'm probably leaking memory like crazy. I'm currently trying to > clamp down on this with `gdb` and `leaks`, but I've no previous > experience with the latter. If anyone has suggestions in this > category, I'd be happy to hear them (Paul mentioned TCL_MEM_DEBUG). > > * Improving its speed, particularly as pertains to Eugene's usage > of cregistry. > > * Documentation. cregistry is largely documented, in the doxygen > style, but I'm not sure of the best way to document registry2.0. I > could do a manpage (but what to call it?), or more doxygen-style > (but tools would confuse the C parameters of the actual functions > with the Tcl parameters I'd document). Registry2.0 should not have a man page for itself, those are mostly for higher level stuff like the port(1) utility and Portfile writing facilities. Our code should all be documented in a doxygen-like fashion, however, so that one day we can build up an easily accessible API reference. Kudos for getting the ball rolling with cregistry! I'd encourage you to do the same for registry2.0 and later on figure out what tool we use to produce the docs if doxygen can't handle the tcl format, what matters the most is that the documentation is already there in place. The new guide is also a great place to put this type of stuff in, but I'm figuring what we should really do is include this automagically generated API reference into the guide directly off the output of doxygen or a similar tool. So, in short, feel free to commit once you feel comfortable with your code for others to look at it, don't worry about anything else. Really looking forward to see this stuff go live! > > > Chris Regards,... -jmpp From sfiera at macports.org Fri Aug 3 13:19:58 2007 From: sfiera at macports.org (Chris Pickel) Date: Tue Oct 9 16:40:29 2007 Subject: GSoC Update: Registry In-Reply-To: References: <561510DC-573D-4CC2-B21F-B731306F5D20@macports.org> Message-ID: On 03 Aug, 2007, at 16:02, Juan Manuel Palacios wrote: >> I've also written a script to up-convert a user's existing >> receipts/filemap into the new format. It's reasonably fast (and >> was not so before I got smarter with sqlite transactions). > > How would that script be run? Each user manually at their own > discretion? Or through some upgrade glue internal to MacPorts? I > would very much prefer the latter approach, something like my > "upgrade" target in base/Makefile.in (later on I'll remove all that > code once we consider enough time has gone by to upgrade most of > our user base to the macports namespace, in the mean time I'm sure > we can share that target for other upgrade purposes). I had assumed an 'upgrade' target. However, since the script is external to the Makefile, it wouldn't be difficult to do the second method - i.e., at the end of mportinit, if file doesn't exist $ {registry.path}/registry/, source ${prefix}/share/macports/scripts/ reg_upgrade.tcl >> The Tcl code that makes *use* of the registry has not yet been >> modified. So, I could commit registry2 now without screwing >> anything up > > Not sure what you mean by this. What hasn't been modified and > where? You mean that if you commit registry2.0 now, trunk would > still be using the old registry & filemap until you "hook up" your > code? Exactly. The APIs are similar, but not identical. >> * I don't feel there's a need to include it in 1.5.1. If someone >> wanted to go ahead and tag 1.5.1, that'd be great :) > > I'm working my way toward 1.5.1, hopefully soonish now (targeting > mid next week). But, likewise, nothing to worry about here, I'm > working with the sweet svnmerge.py on the 1.5 branch so I can > cherry pick what we merge in from turnk and what stays out. Also, > the release tags are created off release branches, not trunk, so > that's more leeway there. OK. So to be clear, if I commit to trunk, there will be no trouble with keeping it out of 1.5.1? Then I'll go ahead and commit. >> * Documentation. cregistry is largely documented, in the doxygen >> style, but I'm not sure of the best way to document registry2.0. I >> could do a manpage (but what to call it?), or more doxygen-style >> (but tools would confuse the C parameters of the actual functions >> with the Tcl parameters I'd document). > > I'd encourage you to do the same for registry2.0 and later on > figure out what tool we use to produce the docs if doxygen can't > handle the tcl format, what matters the most is that the > documentation is already there in place. Alright. I think I'll probably use the doxygen style, but use /* instead of /**. Tools won't detect it as documentation, so they won't screw up when they try to associate it with the function signature ;) 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/20070803/ef333d3e/PGP.bin From yves at macports.org Fri Aug 3 13:37:30 2007 From: yves at macports.org (Yves de Champlain) Date: Tue Oct 9 16:40:29 2007 Subject: [27427] trunk/dports/graphics/gimp2/Portfile In-Reply-To: References: <20070803163045.EB02471F533@cvs.opensource.apple.com> <46B35C25.7000006@macports.org> <46B369BF.4010600@macports.org> Message-ID: <22160BA5-CA6E-4861-9637-E3C22AA2D814@macports.org> Le 07-08-03 ? 14:48, Daniel J. Luke a ?crit : > On Aug 3, 2007, at 1:45 PM, Rainer M?ller wrote: >> I don't like the syntax +without_foo as it reads "with without >> foo" for >> me. Why do we have that +/- syntax if we don't use it? > > We don't use it because it's currently broken (ie, the -variants > that are selected aren't stored, so when you go to upgrade the > port, it doesn't keep the same variant selection. Meanwhile, the > +variants are stored, so things 'work' when you do an upgrade). > >> But as said, port info should show default variants. And they >> could be >> also marked (with a star or something) in port variants. > > That seems like a good idea. You want to submit a patch? :) There is something else. Right now, gimp2 has python24 without_gnome without_python To follow your (rainer's) logic, gimp2 would then have python24 python25 gnome with gnome and python25 both as default. Is this possible with the current implementation? Next, let's say I want python24, then I will have to do port install gimp2 +python24 +gnome If I don't want gnome I'll have to do port install gimp2 +python25 The point is that internals and default become less transparant and more complex for the user. Many might do "-gnome" and miss python or "python24" and miss gnome ... That is the problem with default variants. yves From ryandesign at macports.org Fri Aug 3 15:35:24 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:29 2007 Subject: [27427] trunk/dports/graphics/gimp2/Portfile In-Reply-To: <46B369BF.4010600@macports.org> References: <20070803163045.EB02471F533@cvs.opensource.apple.com> <46B35C25.7000006@macports.org> <46B369BF.4010600@macports.org> Message-ID: On Aug 3, 2007, at 12:45, Rainer M?ller wrote: > But as said, port info should show default variants. And they could be > also marked (with a star or something) in port variants. I have taken to using the variant description to indicate whether a variant is the default, among other things. See "port variants minivmac" and "port variants pdfkt". From raimue at macports.org Sat Aug 4 02:03:22 2007 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Oct 9 16:40:29 2007 Subject: [27427] trunk/dports/graphics/gimp2/Portfile In-Reply-To: <22160BA5-CA6E-4861-9637-E3C22AA2D814@macports.org> References: <20070803163045.EB02471F533@cvs.opensource.apple.com> <46B35C25.7000006@macports.org> <46B369BF.4010600@macports.org> <22160BA5-CA6E-4861-9637-E3C22AA2D814@macports.org> Message-ID: <46B440DA.1090307@macports.org> Yves de Champlain wrote: > There is something else. > > Right now, gimp2 has > > python24 > without_gnome > without_python > > To follow your (rainer's) logic, gimp2 would then have > > python24 > python25 > gnome > > with gnome and python25 both as default. > > Is this possible with the current implementation? > > Next, let's say I want python24, then I will have to do > > port install gimp2 +python24 +gnome No, you would have to do port install gimp2 -python25 +python24 We don't want python25, but we want to use python24 instead. python25 needs to be explicitely deselected since both would be conflicting. But +gnome would be not affected and is still selected automatically from default_variants. > If I don't want gnome I'll have to do > > port install gimp2 +python25 No, it should be port install gimp2 -gnome Which would still install python25, as this wasn't overwritten from default_variants. > The point is that internals and default become less transparant and more > complex for the user. I admit it is a little bit more complex to deselect default_variants if they are conflicting, like in the python24/python25 case... But after all, it makes sense to write something like -python25 +python24 (think that as "without python25, with python24"). > Many might do "-gnome" and miss python or "python24" and miss gnome ... > That is the problem with default variants. Default variants are implemented as they have to be explicitely deselected if someone does not want them. But deselecting one variant does still select others from default_variants. I find a good example is the herrie port. It has some default_variants set, but you can deselect them and/or select additional variants. Some examples: port install herrie installs herrie 1.8.1_0+http+mp3+scrobbler+vorbis+xspf port install herrie -http installs herrie 1.8.1_0+mp3+scrobbler+vorbis+xspf port install herrie -http +modplug installs herrie 1.8.1_0+modplug+mp3+scrobbler+vorbis+xspf Hope it is now more clear how that works and what I meant. Rainer From ryandesign at macports.org Sat Aug 4 03:43:38 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:29 2007 Subject: Trac tickets In-Reply-To: <46B0B026.3000305@ruderich.com> References: <46B0B026.3000305@ruderich.com> Message-ID: <32850BFC-B778-41DD-B4D9-530DEDA10017@macports.org> On Aug 1, 2007, at 11:09, Simon Ruderich wrote: > because I recently said that there are fixes in Trac which aren't > noticed I just started collecting them to help the developers with svn > access. Here is an (incomplete) list of tickets which should be ready > for checkin. (I'm also CCing the maintainers of the ports which > have one.) Thanks for pointing these out to us, Simon. I've taken care of all of them except qt3-mac which I'm leaving to its maintainer. > + http://trac.macports.org/projects/macports/ticket/12068 > Patch for +universal builds fine on my Intel MacBook, but fails > on my > PowerPC iMac. But the non universal build works fine on both. So I > think the patch should be submitted to svn. libogg has no maintainer so I committed the patch. > + http://trac.macports.org/projects/macports/ticket/12207 > Patch submitted to update to newest version, fixes the bug. clex has no maintainer so I committed the patch. I also added a patchfile released by the developers to fix a crashing bug. > + http://trac.macports.org/projects/macports/ticket/12364 > Patch works fine for me. fping: markd already resolved this ticket. > + http://trac.macports.org/projects/macports/ticket/12368 > portfile worked for me but I added a patch which also downloads the > data file and so lets the user directly use raceintospace without > doing anything else. New port raceintospace. I committed it with some changes, and also a version of your patch. See ticket for details. > + http://trac.macports.org/projects/macports/ticket/11895 > My fix for the portfile could also be added. But there seems to > be an > error in macports with build.env which should be checked. qt3-mac is maintained by blair so I'll leave this ticket to him. > + http://trac.macports.org/projects/macports/ticket/11802 > portfile works for me. But I think the configure.env line is not > necessary anymore; I also don't know if port:python24 is really > necessary. I created a portfile before I found this and it worked > without python24. New port kcachegrind. Committed, with changes; see ticket. > + http://trac.macports.org/projects/macports/ticket/11509 > portfile installs fine for me, I don't have any application which > uses > it so I can't say for sure it works. New port libptp2. Committed. > + http://trac.macports.org/projects/macports/ticket/12203 > Fix for the portfile (there was a new release). Also added a > patch for > the mplayer portfile as suggested by the ticket. New port live555. Committed. Also committed the corresponding new variant for MPlayer. From ryandesign at macports.org Sat Aug 4 03:53:23 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:29 2007 Subject: [27427] trunk/dports/graphics/gimp2/Portfile In-Reply-To: <46B440DA.1090307@macports.org> References: <20070803163045.EB02471F533@cvs.opensource.apple.com> <46B35C25.7000006@macports.org> <46B369BF.4010600@macports.org> <22160BA5-CA6E-4861-9637-E3C22AA2D814@macports.org> <46B440DA.1090307@macports.org> Message-ID: On Aug 4, 2007, at 04:03, Rainer M?ller wrote: >> The point is that internals and default become less transparant >> and more >> complex for the user. > > I admit it is a little bit more complex to deselect > default_variants if > they are conflicting, like in the python24/python25 case... But after > all, it makes sense to write something like -python25 +python24 (think > that as "without python25, with python24"). See my ports minivmac and pdftk for workarounds to make this easier for the user. I only select the default_variants if no conflicting variants have been selected. minivmac can emulate several early Mac models. If you don't specify otherwise, it emulates a Mac Plus. if { ![variant_isset mac128k] && ![variant_isset mac512k] && ! [variant_isset mac512ke] && ![variant_isset macse] } { default_variants +macplus } variant mac128k conflicts mac512k mac512ke macplus macse description {Emulate a Macintosh with 128K RAM and 2 drives} { patchfiles-append patch-CNFGGLOB.h-mac128k.diff } variant mac512k conflicts mac128k mac512ke macplus macse description {Emulate a Macintosh 512K with 512K RAM and 2 drives} { patchfiles-append patch-CNFGGLOB.h-mac512k.diff } variant mac512ke conflicts mac128k mac512k macplus macse description {Emulate a Macintosh 512Ke with 512K RAM and 6 drives} { patchfiles-append patch-CNFGGLOB.h-mac512ke.diff } variant macplus conflicts mac128k mac512k mac512ke macse description {Emulate a Macintosh Plus with 4 MB RAM and 6 drives (default)} { # Mac Plus emulation is the default so we don't need to do anything here } variant macse conflicts mac128k mac512k mac512ke macplus description {Emulate a Macintosh SE with 4 MB RAM and 6 drives} { patchfiles-append patch-CNFGGLOB.h-macse.diff } pdftk can be compiled with any version of gcc. By default I want to use the latest, gcc42, but if the user is on a slow PowerPC Mac and already has an earlier gcc and doesn't want to spend a day upgrading, they can use another variant. if { ![variant_isset with_gcc34] && ![variant_isset with_gcj34] && ! [variant_isset with_gcc41] && ![variant_isset with_gcc42] } { default_variants +with_gcc42 } variant with_gcc34 conflicts with_gcj34 with_gcc41 with_gcc42 i386 description {Build using gcc34 (PowerPC only)} { depends_lib-append port:gcc34 build.args-append VERSUFF=-dp-3.4 } variant with_gcj34 conflicts with_gcc34 with_gcc41 with_gcc42 i386 description {Build using gcj34 (PowerPC only)} { depends_lib-append port:gcj34 build.args-append TOOLPATH=${prefix}/gcj34-3.4.5/bin/ } variant with_gcc41 conflicts with_gcc34 with_gcj34 with_gcc42 i386 description {Build using gcc41 (PowerPC only)} { depends_lib-append port:gcc41 build.args-append TOOLPATH=${prefix}/bin/ VERSUFF=-mp-4.1 } variant with_gcc42 conflicts with_gcc34 with_gcj34 with_gcc41 description {Build using gcc42 (default)} { depends_lib-append port:gcc42 build.args-append TOOLPATH=${prefix}/bin/ VERSUFF=-mp-4.2 } platform i386 {} From ryandesign at macports.org Sat Aug 4 03:59:47 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:29 2007 Subject: new update ticket In-Reply-To: <2FA88E42-7B5A-4B69-BF83-D38B46B4DD90@email.it> References: <2FA88E42-7B5A-4B69-BF83-D38B46B4DD90@email.it> Message-ID: <06312264-3A9C-43E4-A329-F89F4EDDC04C@macports.org> On Aug 3, 2007, at 11:59, Andrea D'Amore wrote: > I've created a new ticket to update aewm, I've patched the > Portfile, deleted a patch file, and patched another patch file. > > Here it is: 12388> . I've committed your changes. Thanks. From ryandesign at macports.org Sat Aug 4 14:52:32 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:29 2007 Subject: updated portfile for games/xmj In-Reply-To: <80B625D8-690C-469F-BA68-B62D816458F5@cs.rice.edu> References: <80B625D8-690C-469F-BA68-B62D816458F5@cs.rice.edu> Message-ID: <92812A8F-0EC0-47A4-B9D2-2A7D03CBD762@macports.org> On Aug 3, 2007, at 11:27, Mark Moll wrote: > Can someone please commit http://trac.macports.org/projects/ > macports/ticket/12078, a version bump for games/xmj? raimue resolved this ticket. From ryandesign at macports.org Sat Aug 4 14:54:22 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:29 2007 Subject: Updated Portfile for flagpoll In-Reply-To: <2FAA2E1B-40F1-4186-BD32-0753099D253F@iastate.edu> References: <2FAA2E1B-40F1-4186-BD32-0753099D253F@iastate.edu> Message-ID: <2F582129-0975-464A-87EC-9ABBF20F934C@macports.org> On Aug 3, 2007, at 10:55, Doug McCorkle wrote: > I have attached an updated Portfile for flagpoll. Thanks. Committed in r27478. Thanks. From raimue at macports.org Sat Aug 4 16:08:18 2007 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Oct 9 16:40:29 2007 Subject: updated portfile for games/xmj In-Reply-To: <92812A8F-0EC0-47A4-B9D2-2A7D03CBD762@macports.org> References: <80B625D8-690C-469F-BA68-B62D816458F5@cs.rice.edu> <92812A8F-0EC0-47A4-B9D2-2A7D03CBD762@macports.org> Message-ID: <46B506E2.50201@macports.org> Ryan Schmidt wrote: > On Aug 3, 2007, at 11:27, Mark Moll wrote: > >> Can someone please commit >> http://trac.macports.org/projects/macports/ticket/12078, a version >> bump for games/xmj? > > raimue resolved this ticket. Uh, I just mentioned that my message didn't made it through... Sorry, I used the wrong sender mail address. | Done. | http://trac.macports.org/projects/macports/changeset/27428 Rainer From ryandesign at macports.org Sat Aug 4 21:57:56 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:29 2007 Subject: Trac tickets In-Reply-To: <46B0F875.5020105@ruderich.com> References: <46B0B026.3000305@ruderich.com> <46B0B23D.1040105@ruderich.com> <46B0F875.5020105@ruderich.com> Message-ID: On Aug 1, 2007, at 16:17, Simon Ruderich wrote: > I found some more patches in Trac which can be checked into > subversion. Thanks again. These should all be taken care of now. > - - http://trac.macports.org/projects/macports/ticket/12208 > Works fine for me. But additionally to the patch the "revision" > entry > should be removed with the upgrade. aacgain: maintainer update. Committed. > - - http://trac.macports.org/projects/macports/ticket/12378 > Added patch which fixes the reported bug. jpeg2ps: fix download location and homepage. Has no maintainer. Committed. > - - http://trac.macports.org/projects/macports/ticket/12118 > Added patch for what the ticket creator reported. But maybe the > patchfile should be stored in the files directory and not longer be > loaded from a server because it's only 40 lines and then we are > independent from this other server. makepasswd: fix download location for patch file. I committed the fix as-is; if you feel strongly about this issue you can submit another patch. > - - http://trac.macports.org/projects/macports/ticket/12056 > Added patch for the ticket reporter's request. wavpack: update to newer version. Committed because nomaintainer. > - - http://trac.macports.org/projects/macports/ticket/12063 > Used patch of the ticket reporter and added the newest version > update > to it; also fixed the livecheck. less: update to newer version. Maintainer hasn't responded to this mail or the ticket mails so I'll go ahead and commit it. > - - http://trac.macports.org/projects/macports/ticket/12064 > Again used the patch of the ticket reporter, but now only fixed the > livecheck. unrar: update version, add livecheck. Committed, since we haven't heard from this maintainer either. > - - http://trac.macports.org/projects/macports/ticket/12122 > This ticket should be closed, it was fixed in r26191. weechat: update to 0.2.5. I added a note and closed the ticket. > - - http://trac.macports.org/projects/macports/ticket/12380 > A new ticket of me to update pstoedit; found out it needs an update. pstoedit: update to version 3.44. No maintainer, so I committed it. > - - http://trac.macports.org/projects/macports/ticket/11614 > Used patch of the ticket reporter and added epoch data to cause an > update (I hope this works, please check it; found no documentation > about > it); also remove unnecessary configure.env data from the portfile. libssh: update to 0.2. Maintainer hasn't commented, so I committed it. > All these tickets work fine for me, on a PowerPC and an Intel mac. > > Thanks for your help, > Simon And thank you! From adamore at email.it Sun Aug 5 00:44:38 2007 From: adamore at email.it (Andrea D'Amore) Date: Tue Oct 9 16:40:29 2007 Subject: ion3 update Message-ID: <099B8977-EEB3-4606-A5EB-4C84BB0A8515@email.it> Hi, I've updated the ion3 portfile. Ticket: . Andrea adamore@email.it -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: SPECIALE SALDI: collezioni moda GIRO D’ITALIA FASHION. 100 anni di storia italiana raccontata attraverso l’abbigliamento ufficiale Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6910&d=5-8 From ryandesign at macports.org Sun Aug 5 01:41:06 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:29 2007 Subject: depends_lib, depends_build, depends_run, oh my Message-ID: <23127E16-0D79-42BB-A59D-B3340C7FB996@macports.org> Have various dependency questions here. I couldn't find info on this in the new guide. Why do we have depends_lib, depends_build and depends_run? Why not just a single "depends"? Why does it matter which phase requires the other software? Isn't it enough to know that the other software is required at some point, and so MacPorts should install that other software first? What are these three keywords supposed to denote? I thought "depends_lib" was for libraries a program links with (e.g. gettext), "depends_build" was for things only the build system needs (e.g. pkgconfig) and "depends_run" was for binaries that need to be present at runtime (e.g. I have no idea). To this end, I tried adding "depends_build pkgconfig" to a port that needs it (graphviz), and then I forcibly deactivated the installed pkgconfig to make sure that worked. Well, it didn't. "sudo port install graphviz" proceeded to build just graphviz, without attempting to activate the required pkgconfig first. If, on the other hand, I completely uninstalled pkgconfig first, it then correctly installed pkgconfig when I tried to install graphviz. Why does a deactivated port seem to satisfy the dependency? That should not be. Hm... could it be that the point is that it should be fine to uninstall a build dependency later, but uninstalling a library or runtime dependency would cause installed ports to fail? Is that the reasoning? MacPorts trunk (past 1.5.0), Xcode 2.4.1, Intel Core 2 Duo From blair at orcaware.com Sun Aug 5 11:20:45 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:29 2007 Subject: Trac tickets In-Reply-To: <32850BFC-B778-41DD-B4D9-530DEDA10017@macports.org> References: <46B0B026.3000305@ruderich.com> <32850BFC-B778-41DD-B4D9-530DEDA10017@macports.org> Message-ID: <807989BF-5410-46B5-BFE2-299D5651371D@orcaware.com> On Aug 4, 2007, at 3:43 AM, Ryan Schmidt wrote: > > On Aug 1, 2007, at 11:09, Simon Ruderich wrote: > >> because I recently said that there are fixes in Trac which aren't >> noticed I just started collecting them to help the developers with >> svn >> access. Here is an (incomplete) list of tickets which should be ready >> for checkin. (I'm also CCing the maintainers of the ports which >> have one.) > > Thanks for pointing these out to us, Simon. I've taken care of all > of them except qt3-mac which I'm leaving to its maintainer. > >> + http://trac.macports.org/projects/macports/ticket/11895 >> My fix for the portfile could also be added. But there seems to >> be an >> error in macports with build.env which should be checked. > > qt3-mac is maintained by blair so I'll leave this ticket to him. The odd thing is that this Portfile did work a while ago and it sets the environment already: configure.env QMAKESPEC='' QTDIR='' DYLD_LIBRARY_PATH='' build.env QMAKESPEC='' QTDIR='' DYLD_LIBRARY_PATH="$ {worksrcpath}/lib" So the environment isn't working now. I tried different formats, but none of them work, such as: build.env 'QMAKESPEC="" QTDIR="" DYLD_LIBRARY_PATH="$ {worksrcpath}/lib"' Any ideas? I'm not going to apply the suggested change to build.cmd, since it should not be necessary. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From jmpp at macports.org Sun Aug 5 22:45:48 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:29 2007 Subject: Ports info SQL database feeder (Fwd: [27415] trunk/base/portmgr/packaging) References: <20070803031512.BE23E71CEB5@cvs.opensource.apple.com> Message-ID: <52622414-8DD5-4A2E-A7D0-596187AA776B@macports.org> Evening everyone! Per the message below, in r27415 I committed a rather big facelift to the PortIndex2MySQL script that basically gives us an updated tool that extracts important information out of every single port in our tree (per a valid entry in sources.conf) and injects it as SQL statements into any (I think) SQL based db of our choosing, first printing them to a temporary flat file. I haven't tested database functionality yet as I've been struggling to find some time to setup MySQL5 locally, but for the rest I can account for 100% functionality. I would love it if some of our database savvy members (Ryan? Chris? James? Anyone else?) could take the time to look at the script and find interesting ways to improve and extend it; for instance, what other tables could we create with valuable information out of our ports? One obvious thing we need to think about is, of course, what to do with the script's results. That is to say, we need to put this baby to good use! The old ports.php page (trunk/www/ports.php, OpenDarwin days) was, I believe, a good database client, so I'll work on it next to bring it up to par with the new PortIndex2MySQL script. But other than that, it's no secret that our current webpage is a sorry excuse for an information portal and working on ports.php without knowing if it can be integrated into a reworked site (Kevin?) might be a bit of a waste of time. I personally would love to "donate" my time to such cause if it helps us get on track to start working on a revamped site -- and I'm positive a lively updated page with ports information is a corner stone of any new design! There's also the issue of James' http://db.macports.org portal for mpwa, which is written in Ruby on Rails. Are there any plans to use mpwa and autosubmit (trunk/base/portmgr/autosubmit.tcl) to improve our web presence? Could such portal benefit from the results of PortIndex2MySQL? I would hate to see our little team waste its time working on two different approaches (php & RoR) to fix the same problem: a page with always up to date information of our ports, a la ports.php. So people, feedback please! Running PortIndex2MySQL is now as simple as creating a cron/launchd entry for it as it stands, but we still need to put the results to good use. We most definitely need a completely revamped web presence and I would love us to start working on it sooner than later (lets admit it, there's a disgustingly obvious reason why darwinports.com is so successful, as much as we may hate it!). I can interface with Mac OS Forge for resources and setup (there's also the issue of integrating the new guide), but we first need to agree on what we want to see in a new site and how to implement it. Regards,... -jmpp Begin forwarded message: > From: source_changes@macosforge.org > Date: August 2, 2007 11:15:12 PM GMT-04:00 > To: macports-changes@lists.macosforge.org > Subject: [27415] trunk/base/portmgr/packaging > Reply-To: macports-dev@lists.macosforge.org > > Revision 27415 > Author jmpp@macports.org > Date 2007-08-02 20:15:11 -0700 (Thu, 02 Aug 2007) > Log Message: > Sizeable facelift to the PortIndex2MySQK.tcl script. Highlights: > * Bring it up to date wrt the macports1.0 api and into the new > namespace; > * Make it self-contained, writing its sql output to a flat file > directly and then piping its contents to a proper database command > (like mysql5(1)); this eliminates both the need to load the > mysqltcl library or, the other case, wrap the tcl code with a shell > script to do all the needed redirection to get the information into > the db; > * Get rid of a lot of now unnecessary code due to the rework above; > * Provide abstraction variables to easily adapt the script to any > scenario and a proc to read the db password from a file that must > exist (this bit could definitely use some improvements, like for > passwordless db's); > * Add build and run dependencies for a given port as sql statements > into the db (previously only lib deps were being recorded); > * For fields with multiple and hierarchycal values, like > categories, index them sequentially up from 1 (1 being topmost), > rather than 1 for the first one (most important) and 0 for the rest > (flat second place) as it was being done; > * Use procs in the macports1.0 package, like ui_error; > * Provide a Makefile (currently unhooked from MacPorts build > system) to tie the script into an already configured MacPorts > installation. > So, in a nutshell, the script now works to generate valid SQL > statements for our ports tree, we can extend it to do anything else > we want and then find a client that will read such db and thus put > it to good use ;-) (old ports.php page, here I come!) > Modified Paths > trunk/base/portmgr/packaging/PortIndex2MySQL.tcl > > Added Paths > trunk/base/portmgr/packaging/Makefile From jmpp at macports.org Sun Aug 5 23:11:27 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:29 2007 Subject: GSoC Update: Registry In-Reply-To: References: <561510DC-573D-4CC2-B21F-B731306F5D20@macports.org> Message-ID: On Aug 3, 2007, at 4:19 PM, Chris Pickel wrote: >> >> How would that script be run? Each user manually at their own >> discretion? Or through some upgrade glue internal to MacPorts? I >> would very much prefer the latter approach, something like my >> "upgrade" target in base/Makefile.in (later on I'll remove all >> that code once we consider enough time has gone by to upgrade most >> of our user base to the macports namespace, in the mean time I'm >> sure we can share that target for other upgrade purposes). > > I had assumed an 'upgrade' target. However, since the script is > external to the Makefile, it wouldn't be difficult to do the second > method When I said "internal to MacPorts" I was referring precisely to the upgrade target in base/Makefile.in (as opposed to a tool, some separate script, that the user has to run manually after reinstalling MacPorts, which is what I meant by the implied "external"). So I guess we're in "violent agreement" there ;-) > - i.e., at the end of mportinit, if file doesn't exist $ > {registry.path}/registry/, source ${prefix}/share/macports/scripts/ > reg_upgrade.tcl I would personally prefer a Makefile target, MacPorts innards are already quite filled with upgrade hacks here and there to account for stuff we've changed in non backwards compatible ways throughout our history; but I'll let you be the judge for what'll work best for your upgrade. On a related note, cleaning up the legacy cruft would be lovely, IIRC registry1.0 is filled with it and I'm positive we don't need it any longer ;-) > > OK. So to be clear, if I commit to trunk, there will be no trouble > with keeping it out of 1.5.1? Then I'll go ahead and commit. There shouldn't be, regardless of svnmerge.py if I have careful and detailed eyes. But now that you mention it, it's no secret that waiting until I merge to release_1_5 and release 1.5.1 will only make my life easier (I do have to analyze trunk to figure out what I'll merge). So if you're not pressed to commit then I guess waiting a couple of days will not hurt. > >> >> I'd encourage you to do the same for registry2.0 and later on >> figure out what tool we use to produce the docs if doxygen can't >> handle the tcl format, what matters the most is that the >> documentation is already there in place. > > Alright. I think I'll probably use the doxygen style, but use /* > instead of /**. Tools won't detect it as documentation, so they > won't screw up when they try to associate it with the function > signature ;) Most cool! Having the documentation already in place will rock, later on we'll figure out how to extract it on an automated basis. > > > Chris Thanks for this great work, Chris. Keep it up! Regards,... -jmpp From rhwood at mac.com Mon Aug 6 01:22:55 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:29 2007 Subject: depends_lib, depends_build, depends_run, oh my In-Reply-To: <23127E16-0D79-42BB-A59D-B3340C7FB996@macports.org> References: <23127E16-0D79-42BB-A59D-B3340C7FB996@macports.org> Message-ID: A dependency is considered satisfied if the dependency is installed, not if it is activated. I think this should be considered a bug. You encountered a problem unrelated to the separation of dependencies into runtime (_run), linked against (_lib), and build time (_build) dependencies. On 5 Aug 2007, at 04:41, Ryan Schmidt wrote: > Have various dependency questions here. I couldn't find info on > this in the new guide. > > Why do we have depends_lib, depends_build and depends_run? Why not > just a single "depends"? Why does it matter which phase requires > the other software? Isn't it enough to know that the other software > is required at some point, and so MacPorts should install that > other software first? > > What are these three keywords supposed to denote? I thought > "depends_lib" was for libraries a program links with (e.g. > gettext), "depends_build" was for things only the build system > needs (e.g. pkgconfig) and "depends_run" was for binaries that need > to be present at runtime (e.g. I have no idea). > > To this end, I tried adding "depends_build pkgconfig" to a port > that needs it (graphviz), and then I forcibly deactivated the > installed pkgconfig to make sure that worked. Well, it didn't. > "sudo port install graphviz" proceeded to build just graphviz, > without attempting to activate the required pkgconfig first. If, on > the other hand, I completely uninstalled pkgconfig first, it then > correctly installed pkgconfig when I tried to install graphviz. Why > does a deactivated port seem to satisfy the dependency? That should > not be. > > Hm... could it be that the point is that it should be fine to > uninstall a build dependency later, but uninstalling a library or > runtime dependency would cause installed ports to fail? Is that the > reasoning? > > MacPorts trunk (past 1.5.0), Xcode 2.4.1, Intel Core 2 Duo > > _______________________________________________ > 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 jmpp at macports.org Mon Aug 6 04:38:31 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:29 2007 Subject: [27512] distfiles In-Reply-To: <20070806100922.9FFDB7239BB@cvs.opensource.apple.com> References: <20070806100922.9FFDB7239BB@cvs.opensource.apple.com> Message-ID: <60393B9E-BD63-434C-8E1C-0EB1A4E202AA@macports.org> On Aug 6, 2007, at 6:09 AM, source_changes@macosforge.org wrote: > Revision > 27512 > Author > mas@macports.org > Date > 2007-08-06 03:09:22 -0700 (Mon, 06 Aug 2007) > Log Message > > move to correct location, hopefully Actually, correct location is where the file was when you first committed it ;-) Distfiles are located in user specific dirs for distfiles belonging to ports they maintain or, in the case of nomaintainer, in the general dir. But you maintain slib so the distfile should be in your personal distfile directory. Regards,... -jmpp > Added Paths > > distfiles/slib/ > Removed Paths > > distfiles/mas/ > Diff > > Copied: distfiles/slib (from rev 27511, distfiles/mas) > > _______________________________________________ > macports-changes mailing list > macports-changes@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070806/80db1f30/attachment.html From raimue at macports.org Mon Aug 6 04:43:15 2007 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue Oct 9 16:40:29 2007 Subject: [27512] distfiles In-Reply-To: <60393B9E-BD63-434C-8E1C-0EB1A4E202AA@macports.org> References: <20070806100922.9FFDB7239BB@cvs.opensource.apple.com> <60393B9E-BD63-434C-8E1C-0EB1A4E202AA@macports.org> Message-ID: <46B70953.8080608@macports.org> Juan Manuel Palacios wrote: > Actually, correct location is where the file was when you first > committed it ;-) Distfiles are located in user specific dirs for > distfiles belonging to ports they maintain or, in the case of > nomaintainer, in the general dir. But you maintain slib so the distfile > should be in your personal distfile directory. But MacPorts has this URL as fallback directory for every port. Therefore it is in the right place as the report about slib on the users list [1] shows. | ---> Fetching slib | ---> Attempting to fetch slib3a3.zip from http://swissnet.ai.mit.edu/ftpdir/scm/ | ---> Attempting to fetch slib3a3.zip from http://swissnet.ai.mit.edu/ftpdir/scm/OLD/ | ---> Attempting to fetch slib3a3.zip from http://svn.macports.org/repository/macports/distfiles/slib | ---> Attempting to fetch slib3a3.zip from http://svn.macports.org/repository/macports/distfiles/general/ | ---> Attempting to fetch slib3a3.zip from http://svn.macports.org/repository/macports/downloads/slib | Error: Target org.macports.fetch returned: fetch failed | Error: The following dependencies failed to build: slib slib-guile16 | Error: Status 1 encountered during processing. Now it will be fetched from there without changing the Portfile. Rainer [1] http://lists.macosforge.org/pipermail/macports-users/2007-August/004852.html From jmpp at macports.org Mon Aug 6 05:32:06 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:29 2007 Subject: [27512] distfiles In-Reply-To: <46B70953.8080608@macports.org> References: <20070806100922.9FFDB7239BB@cvs.opensource.apple.com> <60393B9E-BD63-434C-8E1C-0EB1A4E202AA@macports.org> <46B70953.8080608@macports.org> Message-ID: On Aug 6, 2007, at 7:43 AM, Rainer M?ller wrote: > Juan Manuel Palacios wrote: >> Actually, correct location is where the file was when you first >> committed it ;-) Distfiles are located in user specific dirs for >> distfiles belonging to ports they maintain or, in the case of >> nomaintainer, in the general dir. But you maintain slib so the >> distfile >> should be in your personal distfile directory. > > But MacPorts has this URL as fallback directory for every port. > Therefore it is in the right place as the report about slib on the > users > list [1] shows. Yes, true. But still, mas is the maintainer of slib and it is our policy to put our distfiles (for ports we maintain) in our own distfile directories. Fetching from /distfiles/mas is as simple as listing "macports:mas" as the master_sites entry for the port. We can change that policy if we find something better, of course, I'm not opposing improvements. I'm just advocating consistency, as long as we have a policy lets stick to it ;-) Regards,... -jmpp From yves at macports.org Mon Aug 6 06:10:38 2007 From: yves at macports.org (Yves de Champlain) Date: Tue Oct 9 16:40:30 2007 Subject: [27427] trunk/dports/graphics/gimp2/Portfile In-Reply-To: References: <20070803163045.EB02471F533@cvs.opensource.apple.com> <46B35C25.7000006@macports.org> <46B369BF.4010600@macports.org> <22160BA5-CA6E-4861-9637-E3C22AA2D814@macports.org> <46B440DA.1090307@macports.org> Message-ID: <8F20B027-D4B7-43A6-A2AD-854EBFD70EB8@macports.org> Le 07-08-04 ? 06:53, Ryan Schmidt a ?crit : > > On Aug 4, 2007, at 04:03, Rainer M?ller wrote: > >>> The point is that internals and default become less transparant >>> and more >>> complex for the user. >> >> I admit it is a little bit more complex to deselect >> default_variants if >> they are conflicting, like in the python24/python25 case... But after >> all, it makes sense to write something like -python25 +python24 >> (think >> that as "without python25, with python24"). > > See my ports minivmac and pdftk for workarounds to make this easier > for the user. I only select the default_variants if no conflicting > variants have been selected. > > > > minivmac can emulate several early Mac models. If you don't specify > otherwise, it emulates a Mac Plus. > > > if { ![variant_isset mac128k] && ![variant_isset mac512k] && ! > [variant_isset mac512ke] && ![variant_isset macse] } { > default_variants +macplus > } > > variant mac128k conflicts mac512k mac512ke macplus macse > description {Emulate a Macintosh with 128K RAM and 2 drives} { > patchfiles-append patch-CNFGGLOB.h-mac128k.diff > } > > variant mac512k conflicts mac128k mac512ke macplus macse > description {Emulate a Macintosh 512K with 512K RAM and 2 drives} { > patchfiles-append patch-CNFGGLOB.h-mac512k.diff > } > > variant mac512ke conflicts mac128k mac512k macplus macse > description {Emulate a Macintosh 512Ke with 512K RAM and 6 drives} { > patchfiles-append patch-CNFGGLOB.h-mac512ke.diff > } > > variant macplus conflicts mac128k mac512k mac512ke macse > description {Emulate a Macintosh Plus with 4 MB RAM and 6 drives > (default)} { > # Mac Plus emulation is the default so we don't need to do > anything here > } > > variant macse conflicts mac128k mac512k mac512ke macplus > description {Emulate a Macintosh SE with 4 MB RAM and 6 drives} { > patchfiles-append patch-CNFGGLOB.h-macse.diff > } > > > > pdftk can be compiled with any version of gcc. By default I want to > use the latest, gcc42, but if the user is on a slow PowerPC Mac and > already has an earlier gcc and doesn't want to spend a day > upgrading, they can use another variant. > > > if { ![variant_isset with_gcc34] && ![variant_isset with_gcj34] && ! > [variant_isset with_gcc41] && ![variant_isset with_gcc42] } { > default_variants +with_gcc42 > } > > variant with_gcc34 conflicts with_gcj34 with_gcc41 with_gcc42 i386 > description {Build using gcc34 (PowerPC only)} { > depends_lib-append port:gcc34 > build.args-append VERSUFF=-dp-3.4 > } > > variant with_gcj34 conflicts with_gcc34 with_gcc41 with_gcc42 i386 > description {Build using gcj34 (PowerPC only)} { > depends_lib-append port:gcj34 > build.args-append TOOLPATH=${prefix}/gcj34-3.4.5/bin/ > } > > variant with_gcc41 conflicts with_gcc34 with_gcj34 with_gcc42 i386 > description {Build using gcc41 (PowerPC only)} { > depends_lib-append port:gcc41 > build.args-append TOOLPATH=${prefix}/bin/ VERSUFF=-mp-4.1 > } > > variant with_gcc42 conflicts with_gcc34 with_gcj34 with_gcc41 > description {Build using gcc42 (default)} { > depends_lib-append port:gcc42 > build.args-append TOOLPATH=${prefix}/bin/ VERSUFF=-mp-4.2 > } > > platform i386 {} This is exactly my point. Everything gets complex and confusing. I understand the use of default variants in the 2 cases above because you have many excluding options. But it's just not the best solution when adding or leaving an option. Maybe "+wihout" is not nice in a logical point of view, but it's simple and straightforward. yves From markd at macports.org Mon Aug 6 10:07:15 2007 From: markd at macports.org (markd@macports.org) Date: Tue Oct 9 16:40:30 2007 Subject: depends_lib, depends_build, depends_run, oh my In-Reply-To: <23127E16-0D79-42BB-A59D-B3340C7FB996@macports.org> References: <23127E16-0D79-42BB-A59D-B3340C7FB996@macports.org> Message-ID: Oops. Resending to the list with the correct address minus the cc's. >Have various dependency questions here. I couldn't find info on this >in the new guide. > >Why do we have depends_lib, depends_build and depends_run? Why not >just a single "depends"? Why does it matter which phase requires the >other software? Isn't it enough to know that the other software is >required at some point, and so MacPorts should install that other >software first? > >What are these three keywords supposed to denote? I thought >"depends_lib" was for libraries a program links with (e.g. gettext), >"depends_build" was for things only the build system needs (e.g. >pkgconfig) and "depends_run" was for binaries that need to be present >at runtime (e.g. I have no idea). I have the same questions. I would really like to get accurate information on this into the new guide. The only section of the old guide relating to it that I can find is not helpful: http://geeklair.net/macports_guide/ch03.html#additional%20options The portfile.7 has more (pasted below), but is there any real functional difference between these? It seems llike they are functionally the same in practice and ports listed as dependencies all get installed before any phases of a port are begun. Were the three distinguished for some future use not yet implemented? Can someone explain this so it can be documented? Mark depends_build List of dependencies to check before build, destroot, install, and package targets. Type: optional Example: depends_build port:autoconf depends_run List of dependencies to check before destroot, install and package targets. Type: optional Example: depends_run port:bash depends_lib List of dependencies to check before configure, build, destroot, install, and package targets. Type: optional Example: depends_lib port:libfetch From frank.mcpherson at janusresearch.com Mon Aug 6 10:14:35 2007 From: frank.mcpherson at janusresearch.com (Frank McPherson) Date: Tue Oct 9 16:40:30 2007 Subject: Updated port commit request: ufraw to 0.12. Fixes ticket 12308 Message-ID: ufraw has been upgraded to ufraw-0.12 upstream. There was a slight problem with building the new version, easily fixed by adding a small patch. The patches for the source file and Portfile are attached to the ticket, http://trac.macports.org/ projects/macports/ticket/12308. Could someone with commit access please commit these changes and close this ticket? Thanks, Frank From kvv at apple.com Mon Aug 6 10:49:11 2007 From: kvv at apple.com (Kevin Van Vechten) Date: Tue Oct 9 16:40:30 2007 Subject: Ports info SQL database feeder (Fwd: [27415] trunk/base/portmgr/packaging) In-Reply-To: <52622414-8DD5-4A2E-A7D0-596187AA776B@macports.org> References: <20070803031512.BE23E71CEB5@cvs.opensource.apple.com> <52622414-8DD5-4A2E-A7D0-596187AA776B@macports.org> Message-ID: <6EB7D5F5-8395-4D44-8699-1D37EA01AF5B@apple.com> We can host the ports page on Mac OS Forge. On Aug 5, 2007, at 10:45 PM, Juan Manuel Palacios wrote: > > Evening everyone! > > Per the message below, in r27415 I committed a rather big facelift > to the PortIndex2MySQL script that basically gives us an updated > tool that extracts important information out of every single port > in our tree (per a valid entry in sources.conf) and injects it as > SQL statements into any (I think) SQL based db of our choosing, > first printing them to a temporary flat file. I haven't tested > database functionality yet as I've been struggling to find some > time to setup MySQL5 locally, but for the rest I can account for > 100% functionality. > > I would love it if some of our database savvy members (Ryan? > Chris? James? Anyone else?) could take the time to look at the > script and find interesting ways to improve and extend it; for > instance, what other tables could we create with valuable > information out of our ports? One obvious thing we need to think > about is, of course, what to do with the script's results. That is > to say, we need to put this baby to good use! The old ports.php > page (trunk/www/ports.php, OpenDarwin days) was, I believe, a good > database client, so I'll work on it next to bring it up to par with > the new PortIndex2MySQL script. But other than that, it's no secret > that our current webpage is a sorry excuse for an information > portal and working on ports.php without knowing if it can be > integrated into a reworked site (Kevin?) might be a bit of a waste > of time. I personally would love to "donate" my time to such cause > if it helps us get on track to start working on a revamped site -- > and I'm positive a lively updated page with ports information is a > corner stone of any new design! > > There's also the issue of James' http://db.macports.org portal for > mpwa, which is written in Ruby on Rails. Are there any plans to use > mpwa and autosubmit (trunk/base/portmgr/autosubmit.tcl) to improve > our web presence? Could such portal benefit from the results of > PortIndex2MySQL? I would hate to see our little team waste its time > working on two different approaches (php & RoR) to fix the same > problem: a page with always up to date information of our ports, a > la ports.php. > > So people, feedback please! Running PortIndex2MySQL is now as > simple as creating a cron/launchd entry for it as it stands, but we > still need to put the results to good use. We most definitely need > a completely revamped web presence and I would love us to start > working on it sooner than later (lets admit it, there's a > disgustingly obvious reason why darwinports.com is so successful, > as much as we may hate it!). I can interface with Mac OS Forge for > resources and setup (there's also the issue of integrating the new > guide), but we first need to agree on what we want to see in a new > site and how to implement it. > > Regards,... > > > -jmpp > > > Begin forwarded message: > >> From: source_changes@macosforge.org >> Date: August 2, 2007 11:15:12 PM GMT-04:00 >> To: macports-changes@lists.macosforge.org >> Subject: [27415] trunk/base/portmgr/packaging >> Reply-To: macports-dev@lists.macosforge.org >> >> Revision 27415 > >> Author jmpp@macports.org > >> Date 2007-08-02 20:15:11 -0700 (Thu, 02 Aug 2007) > >> Log Message: >> Sizeable facelift to the PortIndex2MySQK.tcl script. Highlights: >> * Bring it up to date wrt the macports1.0 api and into the new >> namespace; >> * Make it self-contained, writing its sql output to a flat file >> directly and then piping its contents to a proper database command >> (like mysql5(1)); this eliminates both the need to load the >> mysqltcl library or, the other case, wrap the tcl code with a >> shell script to do all the needed redirection to get the >> information into the db; >> * Get rid of a lot of now unnecessary code due to the rework above; >> * Provide abstraction variables to easily adapt the script to any >> scenario and a proc to read the db password from a file that must >> exist (this bit could definitely use some improvements, like for >> passwordless db's); >> * Add build and run dependencies for a given port as sql >> statements into the db (previously only lib deps were being >> recorded); >> * For fields with multiple and hierarchycal values, like >> categories, index them sequentially up from 1 (1 being topmost), >> rather than 1 for the first one (most important) and 0 for the >> rest (flat second place) as it was being done; >> * Use procs in the macports1.0 package, like ui_error; >> * Provide a Makefile (currently unhooked from MacPorts build >> system) to tie the script into an already configured MacPorts >> installation. >> So, in a nutshell, the script now works to generate valid SQL >> statements for our ports tree, we can extend it to do anything >> else we want and then find a client that will read such db and >> thus put it to good use ;-) (old ports.php page, here I come!) > >> Modified Paths >> trunk/base/portmgr/packaging/PortIndex2MySQL.tcl >> > >> Added Paths >> trunk/base/portmgr/packaging/Makefile > From kvv at apple.com Mon Aug 6 11:00:05 2007 From: kvv at apple.com (Kevin Van Vechten) Date: Tue Oct 9 16:40:30 2007 Subject: depends_lib, depends_build, depends_run, oh my In-Reply-To: References: <23127E16-0D79-42BB-A59D-B3340C7FB996@macports.org> Message-ID: <3319FCFA-4B70-462A-917F-83BBDB361FC5@apple.com> On Aug 6, 2007, at 10:07 AM, markd@macports.org wrote: >> Why do we have depends_lib, depends_build and depends_run? Why not >> just a single "depends"? Why does it matter which phase requires the >> other software? Isn't it enough to know that the other software is >> required at some point, and so MacPorts should install that other >> software first? Depends_build dependencies are only needed if you're actually building the software. They're not needed at all once the software is built and installed. (Think of gcc). Depends_run dependencies are needed when the software is run, but not necessarily to build the software. (Think of a program that does a fork/exec of /usr/bin/foo at runtime). Depends_lib dependencies are needed both at build time (for headers and libraries to link against) and at run time (to provide necessary code). For binary packages, you'd only need to consider depends_lib + depends_run. Even for those building their own software, it makes sense to distinguish since it gives a better sense of what uninstalls might break (i.e. gcc is a depends_build for most projects, but uninstalling it wouldn't interfere with many ports operation). - kvv From markd at macports.org Mon Aug 6 15:37:12 2007 From: markd at macports.org (markd@macports.org) Date: Tue Oct 9 16:40:30 2007 Subject: depends_lib, depends_build, depends_run, oh my In-Reply-To: <3319FCFA-4B70-462A-917F-83BBDB361FC5@apple.com> References: <23127E16-0D79-42BB-A59D-B3340C7FB996@macports.org> <3319FCFA-4B70-462A-917F-83BBDB361FC5@apple.com> Message-ID: Kevin Van Vechten >> Why do we have depends_lib, depends_build and depends_run? Why not >>> just a single "depends"? Why does it matter which phase requires the >>> other software? Isn't it enough to know that the other software is >>> required at some point, and so MacPorts should install that other >>> software first? > >Depends_build dependencies are only needed if you're actually >building the software. They're not needed at all once the software >is built and installed. (Think of gcc). > >Depends_run dependencies are needed when the software is run, but not >necessarily to build the software. (Think of a program that does a >fork/exec of /usr/bin/foo at runtime). > >Depends_lib dependencies are needed both at build time (for headers >and libraries to link against) and at run time (to provide necessary >code). > >For binary packages, you'd only need to consider depends_lib + >depends_run. Even for those building their own software, it makes >sense to distinguish since it gives a better sense of what uninstalls >might break (i.e. gcc is a depends_build for most projects, but >uninstalling it wouldn't interfere with many ports operation). Thanks, Kevin. I'll review this more closely in a bit and document it in the new guide. Mark From yves at macports.org Mon Aug 6 16:34:12 2007 From: yves at macports.org (Yves de Champlain) Date: Tue Oct 9 16:40:30 2007 Subject: depends_lib, depends_build, depends_run, oh my In-Reply-To: References: <23127E16-0D79-42BB-A59D-B3340C7FB996@macports.org> Message-ID: Le 07-08-06 ? 04:22, Randall Wood a ?crit : > A dependency is considered satisfied if the dependency is > installed, not if it is activated. I think this should be > considered a bug. It is https://trac.macosforge.org/projects/macports/ticket/7361 yves From meissnem at gmail.com Mon Aug 6 21:35:06 2007 From: meissnem at gmail.com (Matthew K. Meissner) Date: Tue Oct 9 16:40:30 2007 Subject: Trac tickets In-Reply-To: <32850BFC-B778-41DD-B4D9-530DEDA10017@macports.org> References: <46B0B026.3000305@ruderich.com> <32850BFC-B778-41DD-B4D9-530DEDA10017@macports.org> Message-ID: On Aug 4, 2007, at 5:43 AM, Ryan Schmidt wrote: >> + http://trac.macports.org/projects/macports/ticket/12068 >> Patch for +universal builds fine on my Intel MacBook, but fails >> on my >> PowerPC iMac. But the non universal build works fine on both. So I >> think the patch should be submitted to svn. > > libogg has no maintainer so I committed the patch. I submitted the patch for libogg -- it works fine on my iBook G4. Mac OS X 10.4.10. Xcode 2.4.1. powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367) macports 1.5 Simon, could you please provide more details on how it fails on your ppc iMac, versions, etc.? Thanks, Matt -- Matt Meissner meissnem at gmail.com From ryandesign at macports.org Tue Aug 7 00:45:39 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:30 2007 Subject: Updated port commit request: ufraw to 0.12. Fixes ticket 12308 In-Reply-To: References: Message-ID: <82EC61BC-A726-4544-901E-60B046EC35E2@macports.org> On Aug 6, 2007, at 12:14, Frank McPherson wrote: > ufraw has been upgraded to ufraw-0.12 upstream. > > There was a slight problem with building the new version, easily > fixed by adding a small patch. The patches for the source file and > Portfile are attached to the ticket, http://trac.macports.org/ > projects/macports/ticket/12308. > > Could someone with commit access please commit these changes and > close this ticket? Yves resolved the ticket. From ryandesign at macports.org Tue Aug 7 00:56:47 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:30 2007 Subject: depends_lib, depends_build, depends_run, oh my In-Reply-To: References: <23127E16-0D79-42BB-A59D-B3340C7FB996@macports.org> <3319FCFA-4B70-462A-917F-83BBDB361FC5@apple.com> Message-ID: <50F46CD9-DAF8-4695-98D4-8AF642099AFE@macports.org> On Aug 6, 2007, at 17:37, Mark Duling wrote: > Kevin Van Vechten writes: > >>>> Why do we have depends_lib, depends_build and depends_run? Why not >>>> just a single "depends"? Why does it matter which phase requires >>>> the >>>> other software? Isn't it enough to know that the other software is >>>> required at some point, and so MacPorts should install that other >>>> software first? >> >> Depends_build dependencies are only needed if you're actually >> building the software. They're not needed at all once the software >> is built and installed. (Think of gcc). >> >> Depends_run dependencies are needed when the software is run, but not >> necessarily to build the software. (Think of a program that does a >> fork/exec of /usr/bin/foo at runtime). >> >> Depends_lib dependencies are needed both at build time (for headers >> and libraries to link against) and at run time (to provide necessary >> code). >> >> For binary packages, you'd only need to consider depends_lib + >> depends_run. Even for those building their own software, it makes >> sense to distinguish since it gives a better sense of what uninstalls >> might break (i.e. gcc is a depends_build for most projects, but >> uninstalling it wouldn't interfere with many ports operation). > > Thanks, Kevin. I'll review this more closely in a bit and document > it in > the new guide. Curiously, even though I fixed the four ports I had installed that required pkgconfig to list it as a build dependency instead of a library, "port uninstall" still won't let me uninstall pkgconfig, saying those four ports depend on it. Oh, I see, I have to reinstall those four ports first. So, for the documentation, another consequence is: if you try to "port uninstall" something, it will prevent you from doing so if any port depends on it via depends_lib, but doesn't complain if a port depends on it via depends_build (and I don't know about depends_run). From markd at macports.org Tue Aug 7 07:45:19 2007 From: markd at macports.org (markd@macports.org) Date: Tue Oct 9 16:40:30 2007 Subject: Documentation terminology change Message-ID: I'm trying to clarify conceptually what MacPorts is and how it works in the new guide. In the old guide the term "initialization phase" is used for what I think we may commonly refer to this as the "global section" of a portfile. http://geeklair.net/macports_guide/ch04.html#id927488 I don't like the term "initialization phase" because it seems counterintuitive for many keywords such as "maintainer", "description", etc. I prefer to call those "global" keywords, thereby disguishing between the global port/Portfile stuff and port/Portfile installation phases. Seen that way the global part is not termed an installation phase at all and I like the separation conceptually. I think this is more clear and more or less clearly explains the murky relationship between a port and a Portfile. To see how I have explained it, see the brief intro in section "Portfile Introduction" in 4.1 of the new guide. http://geeklair.net/macports_guide/ Does anyone see any problem with this characterization? Mark From peter at thoughtspot.net Tue Aug 7 14:05:06 2007 From: peter at thoughtspot.net (Peter Schmiedeskamp) Date: Tue Oct 9 16:40:30 2007 Subject: Port submission - InsightToolkit Message-ID: <44caad960708071405s4bd8fdc4hdab3e896d97f307c@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 1114 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070808/3224a02d/Portfile.obj From peter at thoughtspot.net Tue Aug 7 16:14:28 2007 From: peter at thoughtspot.net (Peter Schmiedeskamp) Date: Tue Oct 9 16:40:30 2007 Subject: Port submission - InsightToolkit take 2 Message-ID: <44caad960708071614n1c8826fat19436076727e3a6@mail.gmail.com> Eek, I just noticed that I unwittingly submitted an HTML formatted e-mail to a mailing list. Many apologies. Since it looks like the content was blocked, I'll try this again: I recently needed to install the InsightToolkit (http://www.itk.org), and thought it best if I took the opportunity to build up a MacPort for it. I'm attaching a copy of the Portfile (loosely based on the VTK port) in hopes that folks can: 1. Point out any errors I've made. 2. Help me out with how to make a new submission. (Sorry if I missed this on the website somewhere) Best, Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 1114 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070808/0273a3e9/Portfile.obj From nox at macports.org Tue Aug 7 16:22:15 2007 From: nox at macports.org (N_Ox) Date: Tue Oct 9 16:40:30 2007 Subject: Port submission - InsightToolkit take 2 In-Reply-To: <44caad960708071614n1c8826fat19436076727e3a6@mail.gmail.com> References: <44caad960708071614n1c8826fat19436076727e3a6@mail.gmail.com> Message-ID: <5AD7793A-67CE-4E14-8A14-FB2DBC39FF0F@macports.org> Le 8 ao?t 07 ? 01:14, Peter Schmiedeskamp a ?crit : > Eek, I just noticed that I unwittingly submitted an HTML formatted > e-mail to a mailing list. Many apologies. Since it looks like the > content was blocked, I'll try this again: > > I recently needed to install the InsightToolkit (http://www.itk.org), > and thought it best if I took the opportunity to build up a MacPort > for it. > > I'm attaching a copy of the Portfile (loosely based on the VTK port) > in hopes that folks can: > 1. Point out any errors I've made. > 2. Help me out with how to make a new submission. (Sorry if I missed > this on the website somewhere) > > Best, > Peter Here some links to help you: * The new MacPorts guide: http://geeklair.net/new_macports_guide/ * The new Trac ticketing guidelines: http://trac.macports.org/projects/macports/wiki/NewTracTicketing To submit a new port, you should file a new ticket into Trac, with the help provided in my second link. Regards, -- Anthony Ramine, a lazy french student. nox@macports.org From peter at thoughtspot.net Tue Aug 7 16:30:41 2007 From: peter at thoughtspot.net (Peter Schmiedeskamp) Date: Tue Oct 9 16:40:30 2007 Subject: Port submission - InsightToolkit take 2 In-Reply-To: <5AD7793A-67CE-4E14-8A14-FB2DBC39FF0F@macports.org> References: <44caad960708071614n1c8826fat19436076727e3a6@mail.gmail.com> <5AD7793A-67CE-4E14-8A14-FB2DBC39FF0F@macports.org> Message-ID: <44caad960708071630s1345a8b2yc98c93f12b85875f@mail.gmail.com> Thank you very much! I've submitted the port to Trac. It is at http://trac.macports.org/projects/macports/ticket/12413 just incase anyone catches this thread and wonders where the submission went. Cheers, Peter On 8/8/07, N_Ox wrote: > Le 8 ao?t 07 ? 01:14, Peter Schmiedeskamp a ?crit : > > > Eek, I just noticed that I unwittingly submitted an HTML formatted > > e-mail to a mailing list. Many apologies. Since it looks like the > > content was blocked, I'll try this again: > > > > I recently needed to install the InsightToolkit (http://www.itk.org), > > and thought it best if I took the opportunity to build up a MacPort > > for it. > > > > I'm attaching a copy of the Portfile (loosely based on the VTK port) > > in hopes that folks can: > > 1. Point out any errors I've made. > > 2. Help me out with how to make a new submission. (Sorry if I missed > > this on the website somewhere) > > > > Best, > > Peter > > Here some links to help you: > > * The new MacPorts guide: > http://geeklair.net/new_macports_guide/ > > * The new Trac ticketing guidelines: > http://trac.macports.org/projects/macports/wiki/NewTracTicketing > > To submit a new port, you should file a new ticket into Trac, with the > help provided in my second link. > > Regards, > > -- > Anthony Ramine, a lazy french student. > nox@macports.org > > > From rhwood at mac.com Wed Aug 8 01:34:24 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:30 2007 Subject: Documentation terminology change In-Reply-To: References: Message-ID: On 7 Aug 2007, at 10:45, markd@macports.org wrote: > I'm trying to clarify conceptually what MacPorts is and how it > works in > the new guide. In the old guide the term "initialization phase" is > used > for what I think we may commonly refer to this as the "global > section" of > a portfile. > > http://geeklair.net/macports_guide/ch04.html#id927488 > > I don't like the term "initialization phase" because it seems > counterintuitive for many keywords such as "maintainer", > "description", > etc. I prefer to call those "global" keywords, thereby disguishing > between the global port/Portfile stuff and port/Portfile installation > phases. Seen that way the global part is not termed an > installation phase > at all and I like the separation conceptually. I think this is > more clear > and more or less clearly explains the murky relationship between a > port > and a Portfile. To see how I have explained it, see the brief > intro in > section "Portfile Introduction" in 4.1 of the new guide. > http://geeklair.net/macports_guide/ > > Does anyone see any problem with this characterization? Seems good to me. 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 Wed Aug 8 02:41:37 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:30 2007 Subject: [27554] trunk/doc/guide/new/xml/portfileref.xml In-Reply-To: <20070808043045.E846E72B631@cvs.opensource.apple.com> References: <20070808043045.E846E72B631@cvs.opensource.apple.com> Message-ID: On Aug 7, 2007, at 23:30, source_changes@macosforge.org wrote: > Revision: 27554 > http://trac.macosforge.org/projects/macports/changeset/27554 > Author: markd@macports.org > Date: 2007-08-07 21:30:45 -0700 (Tue, 07 Aug 2007) > > Log Message: > ----------- > Add a Port Dependencies section to the Port Reference section. > > Modified Paths: > -------------- > trunk/doc/guide/new/xml/portfileref.xml > > Modified: trunk/doc/guide/new/xml/portfileref.xml [snip] > + Non-Port Dependencies > + > + Port dependencies should refer to other MacPort ports > whenever > + possible. However, if satisfying a dependency with a port is > not > + practical or desirable for a special reason, you may specify > + dependencies in the Unix standard binary, library, or a > specified > + path. The end of this is reading a little weird. "you may specify dependencies in the Unix standard binary, library, or a specified path"? > + > + In this lib style dependency, if the file > + libX11.6.2.dylib is not found in the > library path > + the XFree86 port will be installed to satisfy it. > + > + depends_lib lib:libX11.6:XFree86 programlisting> > + > + In this bin style dependency, if the > rrdtool > + binary is not found in the binary path the port rrdtool will be > + installed. > + > + depends_lib bin:python:python24 programlisting> The paragraph talks of rrdtool, but the example shows python24. The python24 binary is not a library dependency so should not be introduced with depends_lib. It is perhaps a run-time dependency or possibly a build-time dependency. > + > + In this path style dependency, if the nano filename> > + binary is not found in the path /usr/bin/nano the nano port > will be > + installed. > + > + depends_lib path:/usr/bin/nano:nano programlisting> This should also not be shown as depends_lib because it isn't a library; it's a binary. From simon at ruderich.com Wed Aug 8 04:02:41 2007 From: simon at ruderich.com (Simon Ruderich) Date: Tue Oct 9 16:40:30 2007 Subject: Trac tickets In-Reply-To: References: <46B0B026.3000305@ruderich.com> <32850BFC-B778-41DD-B4D9-530DEDA10017@macports.org> Message-ID: <46B9A2D1.6000509@ruderich.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Matthew K. Meissner wrote: > Simon, could you please provide more details on how it fails on your ppc > iMac, versions, etc.? > > Thanks, > Matt Hi, I tried it on my iMac G4, Mac OS X 10.4.10 with Xcode 2.4.1 with the following result (only configure and build information) I attached to this mail. Without +universal it builds fine for me on my iMac. Thanks for your help, Simon - -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGuaKqYRX4BO+zMikRCg/QAJ0U0xpHhwuTz+bRA8/I+LVpt+g6pACfd25J 6KKMCnpa57L9dB0LV3CItAc= =BGN8 -----END PGP SIGNATURE----- -------------- next part -------------- ---> Configuring libogg DEBUG: Executing org.macports.configure (libogg) DEBUG: Environment: CXXFLAGS='-O2 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc' CPPFLAGS='-I/opt/local/include' CFLAGS='-O2 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc' LDFLAGS='-L/opt/local/lib -arch i386 -arch ppc' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_libogg/work/libogg-1.1.3" && ./configure --prefix=/opt/local --disable-dependency-tracking' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... none checking build system type... powerpc-apple-darwin8.10.0 checking host system type... powerpc-apple-darwin8.10.0 checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -p checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... none checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 65536 checking command to parse /usr/bin/nm -p output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fno-common checking if gcc PIC flag -fno-common works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.10.0 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fno-common checking if g++ PIC flag -fno-common works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin8.10.0 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking for ANSI C header files... (cached) yes checking for an ANSI C-conforming const... yes checking for int16_t... yes checking for int32_t... yes checking for uint32_t... yes checking for uint16_t... yes checking for u_int32_t... yes checking for u_int16_t... yes checking for int64_t... yes checking for short... yes checking size of short... 2 checking for int... yes checking size of int... 4 checking for long... yes checking size of long... 4 checking for long long... yes checking size of long long... 8 checking for working memcmp... yes configure: cr