From wyuenho at gmail.com Thu Mar 1 00:21:55 2007 From: wyuenho at gmail.com (Yuen Ho Wong) Date: Tue Oct 9 16:40:03 2007 Subject: Emacs major modes Message-ID: <45E68D23.5040605@gmail.com> Hi Macport Devs, Just out of curiosity, how come there is such a lack of ported emacs modes? Are there any plans to incorporate more emacs mode in Macports or do I have to roll my own? Yuen Ho Wong From ronaldoussoren at mac.com Thu Mar 1 03:38:21 2007 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue Oct 9 16:40:03 2007 Subject: Python 2.4 vs Python 2.5 and System vs MacPorts python In-Reply-To: References: <1D98552D-1A56-472F-B1CF-C9C9EF570984@macports.org> <02042CBD-EA8A-4AF2-91C4-A3FBE90BF925@mac.com> <8260B387-C1E9-438E-B409-912A86987D60@macports.org> Message-ID: <2F7C5CEF-039D-4989-811A-289C413EC37F@mac.com> On 22 Feb, 2007, at 20:29, Jordan K. Hubbard wrote: > This has been an interesting conversation, particularly given some > of the comments from folks claiming they're facing this scenario in > commercial / support scenarios where products are based on > (presumably forwards incompatible) Python version x and unable to > migrate to Python version y. Do such people simply bundle Python > with their applications (I've seen that approach used) or do they > rely in Framework versioning support? I bundle the python framework with applications, anyone that uses py2app will get that functionality for free when he's not using the system version of python. > That's mostly good for backwards compatibility but pretty hosed for > forwards compatibility since Apple didn't really take the Framework > approach to its fullest and there's really no way to say "I want - > framework Foo versionX" at the link stage, compiling newer stuff > against older bits (you pretty much have to go to the trouble of > keeping back-rev'd copies of MacOSX around for hosting your > builds). How does MacPorts help people with this, or does it? That's not entirely true, you can explicitly link with the dylib inside the framework. That is, '-framework Python' is the same as linking with /Library/Framework/Python.framework/Versions/Current/ Python. It's not as easy as linking a framework, especially when doing this from Xcode, but it's not very hard either. > > I ask because we're likely going to go with Python 2.5 for Leopard > (not in the seeds yet, but soon) and there's still time to rethink > that decision if it's really going to hose people. I'm +1 on Python2.5 in Leopard. Ronald From john at jacelridge.com Thu Mar 1 06:03:01 2007 From: john at jacelridge.com (John Ridgway) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts: extracting to multiple locations Message-ID: Friends - I'm working on a cleanup of the xemacs PortFile - splitting it into xemacs and xemacs-beta, and ensuring that without the sumo option you still get the base packages. In doing this I'm discovering that I need to extract different distribution files into different places in the build tree. Is there a standard way to do this, or can somebody point me to another port that does something similar? Peace - John From cssdev at mac.com Thu Mar 1 06:13:45 2007 From: cssdev at mac.com (cssdev@mac.com) Date: Tue Oct 9 16:40:03 2007 Subject: Emacs major modes In-Reply-To: <45E68D23.5040605@gmail.com> References: <45E68D23.5040605@gmail.com> Message-ID: <338A9B29-ABBC-47DC-BBC8-4BBC1FC94ED6@mac.com> On Mar 1, 2007, at 3:21 AM, Yuen Ho Wong wrote: > Just out of curiosity, how come there is such a lack of ported > emacs modes? Are there any plans to incorporate more emacs mode in > Macports or do I have to roll my own? I'm not sure. I just toss any customizations into my CVS'd Documents/ dotfiles/.lisp folder. I use a symbolic link so that my dotfiles load from my home folder. This makes it really easy to pull all my modes to any other system I use, regardless of operating system. It's nice to use a single set of features and keystrokes across Mac OS X, Linux, FreeBSD, and even Windows. :) It might be useful to add something like the Enhanced Carbon Emacs plugin as a port, but you ultimately still need to do something to have whatever flavor of emacs you're using load any extra modes. Were there any particular modes that you're interested in? For my own use, I have found it easier to manage my modes within my own user-space. Chris From anant at kix.in Thu Mar 1 07:41:28 2007 From: anant at kix.in (Anant Narayanan) Date: Tue Oct 9 16:40:03 2007 Subject: textproc/xercesc doesn't build Message-ID: <45E6F428.8030606@kix.in> Hi all, The textproc/xercesc port didn't build. I've attached a patch to the ticket (#11463) to correct the MD5 and ${worksrcdir}. http://trac.macports.org/projects/macports/ticket/11463 Cheers, -- Anant From blair at orcaware.com Thu Mar 1 08:40:26 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts: extracting to multiple locations In-Reply-To: References: Message-ID: <45E701FA.6070706@orcaware.com> John Ridgway wrote: > Friends - > I'm working on a cleanup of the xemacs PortFile - splitting it into > xemacs and xemacs-beta, and ensuring that without the sumo option you > still get the base packages. In doing this I'm discovering that I need > to extract different distribution files into different places in the > build tree. Is there a standard way to do this, or can somebody point > me to another port that does something similar? > > Peace > - John Hi John, I don't know the answer to your question, but I've been helping out on that package, so if you could email me the new Portfile before committing it to check it out, I would appreciate it. BTW, I think we have a standard of naming beta ports with -devel and not -beta, as I can't find a single Port with the string beta in it. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From anant at kix.in Thu Mar 1 08:53:50 2007 From: anant at kix.in (Anant Narayanan) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts and Summer of Code Message-ID: <45E7051E.1010306@kix.in> Hi All, Will MacPorts be participating in the Google Summer of Code 2007? I highly recommend you do so :) Last date for Mentoring organizations to apply is March 5th, so we still have time left. If MacPorts does apply and get selected; I for one, will surely send in an application ;) Best Regards, -- Anant P.S. For those of you who don't know what the Summer of Code is, http://code.google.com/soc/ is the place to go. Google sponsors several open source projects over the summer for tasks that are important to them. From blair at orcaware.com Thu Mar 1 08:56:51 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts and Summer of Code In-Reply-To: <45E7051E.1010306@kix.in> References: <45E7051E.1010306@kix.in> Message-ID: <45E705D3.709@orcaware.com> Anant Narayanan wrote: > Hi All, > > Will MacPorts be participating in the Google Summer of Code 2007? I > highly recommend you do so :) > > Last date for Mentoring organizations to apply is March 5th, so we still > have time left. If MacPorts does apply and get selected; I for one, will > surely send in an application ;) > > Best Regards, What kind of projects do you have in mind for the Summer of Code people to take on? Regards, Blair -- Blair Zajac, Ph.D. Subversion training, consulting and support http://www.orcaware.com/svn/ From anant at kix.in Thu Mar 1 09:21:58 2007 From: anant at kix.in (Anant Narayanan) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts and Summer of Code In-Reply-To: <45E705D3.709@orcaware.com> References: <45E7051E.1010306@kix.in> <45E705D3.709@orcaware.com> Message-ID: <45E70BB6.7060002@kix.in> Hi, > What kind of projects do you have in mind for the Summer of Code people > to take on? The project I personally was planning on doing was an official GUI for MacPorts. Currently, there's only a non-free (in all senses of the word) frontend. Apart from this, porting a major application: like the next big Gnome/KDE could also fit the bill. Surely, you guys must be having a TODO list? :) -- Anant From anant at kix.in Thu Mar 1 09:25:12 2007 From: anant at kix.in (Anant Narayanan) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts and Summer of Code In-Reply-To: <45E70BB6.7060002@kix.in> References: <45E7051E.1010306@kix.in> <45E705D3.709@orcaware.com> <45E70BB6.7060002@kix.in> Message-ID: <45E70C78.9020808@kix.in> >> What kind of projects do you have in mind for the Summer of Code people >> to take on? > > The project I personally was planning on doing was an official GUI for > MacPorts. Currently, there's only a non-free (in all senses of the word) > frontend. > > Apart from this, porting a major application: like the next big > Gnome/KDE could also fit the bill. Surely, you guys must be having a > TODO list? :) Additionally, any general *nix application that hasn't been ported to Darwin/OSX yet will qualify as a MacPorts project. There are tons of these out there, so a proposal could either contain porting several small applications or one big one; the coding time allowed is 3 months. -- Anant From opendarwin.org at darkart.com Thu Mar 1 14:57:12 2007 From: opendarwin.org at darkart.com (Eric Hall) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts and Summer of Code In-Reply-To: <45E70C78.9020808@kix.in> References: <45E7051E.1010306@kix.in> <45E705D3.709@orcaware.com> <45E70BB6.7060002@kix.in> <45E70C78.9020808@kix.in> Message-ID: <20070301225712.GW1279@darkart.com> On Thu, Mar 01, 2007 at 10:55:12PM +0530, Anant Narayanan wrote: > >> What kind of projects do you have in mind for the Summer of Code people > >> to take on? > > > > The project I personally was planning on doing was an official GUI for > > MacPorts. Currently, there's only a non-free (in all senses of the word) > > frontend. > > > > Apart from this, porting a major application: like the next big > > Gnome/KDE could also fit the bill. Surely, you guys must be having a > > TODO list? :) > > Additionally, any general *nix application that hasn't been ported to > Darwin/OSX yet will qualify as a MacPorts project. There are tons of > these out there, so a proposal could either contain porting several > small applications or one big one; the coding time allowed is 3 months. > One very useful thing I can think of is getting dependencies to support variants - i.e. port 1 need 'port 2 +variantA'. -eric From blair at orcaware.com Thu Mar 1 15:02:42 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts and Summer of Code In-Reply-To: <20070301225712.GW1279@darkart.com> References: <45E7051E.1010306@kix.in> <45E705D3.709@orcaware.com> <45E70BB6.7060002@kix.in> <45E70C78.9020808@kix.in> <20070301225712.GW1279@darkart.com> Message-ID: <45E75B92.6070600@orcaware.com> Eric Hall wrote: > On Thu, Mar 01, 2007 at 10:55:12PM +0530, Anant Narayanan wrote: >>>> What kind of projects do you have in mind for the Summer of Code people >>>> to take on? >>> The project I personally was planning on doing was an official GUI for >>> MacPorts. Currently, there's only a non-free (in all senses of the word) >>> frontend. >>> >>> Apart from this, porting a major application: like the next big >>> Gnome/KDE could also fit the bill. Surely, you guys must be having a >>> TODO list? :) >> Additionally, any general *nix application that hasn't been ported to >> Darwin/OSX yet will qualify as a MacPorts project. There are tons of >> these out there, so a proposal could either contain porting several >> small applications or one big one; the coding time allowed is 3 months. >> > > One very useful thing I can think of is getting dependencies > to support variants - i.e. port 1 need 'port 2 +variantA'. Yes, that would be good. A couple of other ideas: 1) Complete the work to have a single py-* portfile work for both Python 2.4 and 2.5. 2) Find a box to support compiling code on older OSes. Not everybody has a 10.3 box, but it would be good to have smoke tests on them and email the person who did the commit if a new Port broke on another older os. -- Blair Zajac, Ph.D. Subversion training, consulting and support http://www.orcaware.com/svn/ From fracai at mac.com Thu Mar 1 16:18:32 2007 From: fracai at mac.com (Arno Hautala) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts and Summer of Code In-Reply-To: <20070301225712.GW1279@darkart.com> References: <45E7051E.1010306@kix.in> <45E705D3.709@orcaware.com> <45E70BB6.7060002@kix.in> <45E70C78.9020808@kix.in> <20070301225712.GW1279@darkart.com> Message-ID: <8986B60E-1D9A-4391-9109-294FFCE883AE@mac.com> > What kind of projects do you have in mind for the Summer of Code > people > to take on? Another task could be to identify outdated ports, those that have recent source available but the Portfiles have not been updated. Some sources might lend themselves to automatically detecting recent versions. Those with standard versioning in the file name. This could be a project to add a section to Portfiles which would, in "developer mode", list the installed, available, and source available versions. -- -- arno s. hautala /-\ arno@alum.wpi.edu -- -- From pipping at macports.org Thu Mar 1 16:57:00 2007 From: pipping at macports.org (Elias Pipping) Date: Tue Oct 9 16:40:03 2007 Subject: textproc/xercesc doesn't build In-Reply-To: <45E6F428.8030606@kix.in> References: <45E6F428.8030606@kix.in> Message-ID: <44289594-F70C-40CD-983E-7C35D5D59B94@macports.org> I've just installed xercesc without the patch and it works. Are you sure your tarball isn't broken? could please sudo port clean --all xercesc sudo port -df destroot xercesc and confirm that the checksum mismatch persists? Regards, Elias Pipping On Mar 1, 2007, at 4:41 PM, Anant Narayanan wrote: > Hi all, > > The textproc/xercesc port didn't build. I've attached a patch to the > ticket (#11463) to correct the MD5 and ${worksrcdir}. > > http://trac.macports.org/projects/macports/ticket/11463 > > Cheers, > -- > Anant > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From pipping at macports.org Thu Mar 1 21:19:52 2007 From: pipping at macports.org (Elias Pipping) Date: Tue Oct 9 16:40:03 2007 Subject: Spring-cleaning @opendarwin.org addresses Message-ID: Carried out. see * mail: http://www.mail-archive.com/macports- dev@lists.macosforge.org/msg00309.html * ticket: http://trac.macosforge.org/projects/macports/ticket/11465 * changeset: http://trac.macosforge.org/projects/macports/changeset/ 22478 Regards, Elias Pipping From anant at kix.in Thu Mar 1 21:46:42 2007 From: anant at kix.in (Anant Narayanan) Date: Tue Oct 9 16:40:03 2007 Subject: textproc/xercesc doesn't build In-Reply-To: <44289594-F70C-40CD-983E-7C35D5D59B94@macports.org> References: <45E6F428.8030606@kix.in> <44289594-F70C-40CD-983E-7C35D5D59B94@macports.org> Message-ID: <45E7BA42.40704@kix.in> Hi Elias, > I've just installed xercesc without the patch and it works. Are you sure > your tarball isn't broken? I reinstalled xerces after a clean --all and it worked! Seems like I had a bad tarball earlier (it had the exact name, and it was shared from Gentoo's distfiles directory). Sorry for the false ticket, I've closed it. Best Regards, -- Anant From cedric.luthi at gmail.com Thu Mar 1 23:10:17 2007 From: cedric.luthi at gmail.com (=?ISO-8859-1?Q?C=E9dric_Luthi?=) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts and Summer of Code In-Reply-To: <20070301225712.GW1279@darkart.com> References: <45E7051E.1010306@kix.in> <45E705D3.709@orcaware.com> <45E70BB6.7060002@kix.in> <45E70C78.9020808@kix.in> <20070301225712.GW1279@darkart.com> Message-ID: <98432D83-BA88-4080-B425-B5D69D73BA3A@gmail.com> On 1 mars 07, at 23:57, Eric Hall wrote: > One very useful thing I can think of is getting dependencies > to support variants - i.e. port 1 need 'port 2 +variantA'. And also versions: port 1 need 'port 2 @2.6.27' Obviously, port 2 @2.6.28 would be correct also. And what about both ? port 1 need 'port 2 @2.6.27 +variantA' C?dric Luthi From ehainry at free.fr Fri Mar 2 00:30:01 2007 From: ehainry at free.fr (Emmanuel Hainry) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts and Summer of Code In-Reply-To: <8986B60E-1D9A-4391-9109-294FFCE883AE@mac.com> References: <45E7051E.1010306@kix.in> <45E705D3.709@orcaware.com> <45E70BB6.7060002@kix.in> <45E70C78.9020808@kix.in> <20070301225712.GW1279@darkart.com> <8986B60E-1D9A-4391-9109-294FFCE883AE@mac.com> Message-ID: <20070302083001.GA2794@velsheda.lateralis.org> Citando Arno Hautala : > >What kind of projects do you have in mind for the Summer of Code > >people > >to take on? > > Another task could be to identify outdated ports, those that have > recent source available but the Portfiles have not been updated. > Some sources might lend themselves to automatically detecting recent > versions. Those with standard versioning in the file name. This > could be a project to add a section to Portfiles which would, in > "developer mode", list the installed, available, and source available > versions. > Isn't it the "livecheck" feature? port livecheck lbdb tells that portfile is for version 0.30 and 0.34 is the current available version. Emmanuel From jkh at brierdr.com Fri Mar 2 00:32:21 2007 From: jkh at brierdr.com (Jordan K. Hubbard) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts and Summer of Code - first steps Message-ID: First, I think this is a great idea and thanks go to whomever suggested it - MacPorts is full of the sorts of projects that summer- of-coders could do in the time allotted. Second, before google is even approached I think the project needs to pull a wish-list together and demonstrate that it's not just looking for some free labor to get a bit of grunt work done, it's got some project ideas that will really move the project forward and demonstrably improve its utility to the Macintosh community at large. I've been one of the google SoC mentors (for FreeBSD) and I can say that the project ideas which tend to get funding aren't the ones which go "clean up our man pages and look for typos", they're more along the lines of "port ZFS to FreeBSD". Furthermore, I *know* that MacPorts has a number of long-stalled efforts in base/ which are just waiting for someone to go dive on them single-mindedly. Just thinking right off the top of my head, some of these are: 1. Finish the work Paul Guyot started with the trace code and create real "virtual chroot" environments for building ports, constraining what their configure scripts can see and validating that their explicit dependencies are correct and fully-formed. 2. Working in concert (or cooperatively) with whomever does #1, get package building working all the way to a point where complete package builds can be done for all of MacPorts and the results made available to users as pre-build package collections. 3. Come up with a front-end for installing packages (or building ports, where no package exists) for naive end-users. 4. Take what Will started with the notion of a depot location vs an installed location (e.g. /opt/local/var/db/dports/software/gawk/ 3.1.5_2/opt/local/bin/gawk vs /opt/local/bin/gawk) and finish the job, making depot-to-depot dependencies finally work. That is to say that if port foo depends on version 1.2.3 of port bar, it should be compiled and linked in such a way that it's wired to the depot location of bar, not the "activated" location. That will finally fix the fragility problem where deactivating port bar vers n-1 in order to install port bar vers n (because other things depend on n) won't also require breaking everything that relies on n-1. 5. Sweep through all Portfiles and look for useful opportunities to add more built-in Tcl functions that make Portfiles more (usefully) terse, powerful, flexible or easier to write. I'm sure there is an entirely family of helper functions yet to be written here. That's just 5 off the top of my head with about the same number of minutes work devoted to pulling them out of my memory. I know that I've seen easily 10 times that many "good idea, someone should do that!" emails fly by the lists over the last few years too, so I'm sure others can easily add to this list. Approaching google is also something that shouldn't be done ad-hoc by a number of people all claiming to represent macports in some way. Someone wearing the portmgr mantle needs to collect all these ideas, get some democratic input as to which ideas are truly the best, then approach google with the list and try to get added as a SoC project. They need to do it quickly too since we don't have much time. I nominate jmpp. - Jordan From anant at kix.in Fri Mar 2 02:58:37 2007 From: anant at kix.in (Anant Narayanan) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts and Summer of Code - first steps In-Reply-To: References: Message-ID: <45E8035D.4050003@kix.in> > Approaching google is also something that shouldn't be done ad-hoc by a > number of people all claiming to represent macports in some way. > Someone wearing the portmgr mantle needs to collect all these ideas, get > some democratic input as to which ideas are truly the best, then > approach google with the list and try to get added as a SoC project. > They need to do it quickly too since we don't have much time. I > nominate jmpp. +1. Someone can create a Wiki page and put all those ideas in it. I would have done so but I don't have enough privileges. Also someone (jmpp, pipping, ryan) can prepare a draft application and finalize it through the ML so that you can send it off by March 5th? I guess you can pick one program administrator amongst yourselves on IRC or something :) /me hopes MacPorts makes it to this years SoC. If you need any help in convincing Google ping me ;) -- Anant From mww at macports.org Fri Mar 2 03:30:28 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:03 2007 Subject: Spring-cleaning @opendarwin.org addresses In-Reply-To: References: Message-ID: <8F224809-EC81-4209-ACA6-F10C927D9B47@macports.org> Great job, thanks Elias! This of course means that there are a lot of poor orphaned ports now, which means a great opportunity to take maintainership of your favorite port and also - if you're not yet a developer - your chance to get involved in MacPorts... :) salut, -Markus On 02.03.2007, at 06:19, Elias Pipping wrote: > Carried out. see > > * mail: http://www.mail-archive.com/macports- > dev@lists.macosforge.org/msg00309.html > * ticket: http://trac.macosforge.org/projects/macports/ticket/ > 11465 > * changeset: http://trac.macosforge.org/projects/macports/ > changeset/22478 > > > Regards, > > Elias Pipping > > --- Markus W. Weissmann http://www.mweissmann.de/ http://www.macports.org/ From sal at ri.cmu.edu Fri Mar 2 10:07:39 2007 From: sal at ri.cmu.edu (Salvatore Domenick Desiano) Date: Tue Oct 9 16:40:03 2007 Subject: [22479] trunk/dports/PortIndex In-Reply-To: <20070302083948.632964C3F16@cvs.opensource.apple.com> References: <20070302083948.632964C3F16@cvs.opensource.apple.com> Message-ID: WOW. So, that 4.1MB e-mail never needs to happen again. Can we put a filter on the outgoing SVN e-mails? -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University From jkh at brierdr.com Fri Mar 2 10:25:01 2007 From: jkh at brierdr.com (Jordan K. Hubbard) Date: Tue Oct 9 16:40:03 2007 Subject: [22479] trunk/dports/PortIndex In-Reply-To: References: <20070302083948.632964C3F16@cvs.opensource.apple.com> Message-ID: I don't think that this is a problem which is likely to happen often enough that we need to engineer a solution. Also, emails are getting bigger and multi-megabyte ones aren't all that common. Ditch your modem and get a DSL/cablemodem connection like everybody else. :) - Jordan On Mar 2, 2007, at 10:07 AM, Salvatore Domenick Desiano wrote: > WOW. So, that 4.1MB e-mail never needs to happen again. Can we put a > filter on the outgoing SVN e-mails? > > -- Sal > smile. > > > -------------- > Salvatore Domenick Desiano > Doctoral Candidate > Robotics Institute > Carnegie Mellon University > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From blair at orcaware.com Fri Mar 2 10:48:45 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:03 2007 Subject: [22479] trunk/dports/PortIndex In-Reply-To: References: <20070302083948.632964C3F16@cvs.opensource.apple.com> Message-ID: <45E8718D.1050006@orcaware.com> Salvatore Domenick Desiano wrote: > WOW. So, that 4.1MB e-mail never needs to happen again. Can we put a > filter on the outgoing SVN e-mails? That's why I subscribe to the RSS commit feed :) http://trac.macports.org/projects/macports/timeline?milestone=on&changeset=on&wiki=on&max=50&daysback=90&format=rss Regards, Blair -- Blair Zajac, Ph.D. Subversion training, consulting and support http://www.orcaware.com/svn/ From fracai at mac.com Fri Mar 2 13:08:43 2007 From: fracai at mac.com (Arno Hautala) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts and Summer of Code In-Reply-To: <20070302083001.GA2794@velsheda.lateralis.org> References: <45E7051E.1010306@kix.in> <45E705D3.709@orcaware.com> <45E70BB6.7060002@kix.in> <45E70C78.9020808@kix.in> <20070301225712.GW1279@darkart.com> <8986B60E-1D9A-4391-9109-294FFCE883AE@mac.com> <20070302083001.GA2794@velsheda.lateralis.org> Message-ID: <446274B8-31EE-4F94-9F58-5761BDD1B133@mac.com> On 2007/03/02, at 03:30, Emmanuel Hainry wrote: > Citando Arno Hautala : >>> What kind of projects do you have in mind for the Summer of Code >>> people >>> to take on? >> >> Another task could be to identify outdated ports, those that have >> recent source available but the Portfiles have not been updated. >> Some sources might lend themselves to automatically detecting recent >> versions. Those with standard versioning in the file name. This >> could be a project to add a section to Portfiles which would, in >> "developer mode", list the installed, available, and source available >> versions. >> > > Isn't it the "livecheck" feature? > > port livecheck lbdb > > tells that portfile is for version 0.30 and 0.34 is the current > available version. WOW. Thanks so much. hmmm, some of these seem to need fixing. There are those that list an installed version greater than the new. So there's a task :) Thanks again. -- -- arno s. hautala /-\ arno@alum.wpi.edu -- -- From ryandesign at macports.org Fri Mar 2 16:45:39 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:03 2007 Subject: MacPorts and Summer of Code In-Reply-To: <98432D83-BA88-4080-B425-B5D69D73BA3A@gmail.com> References: <45E7051E.1010306@kix.in> <45E705D3.709@orcaware.com> <45E70BB6.7060002@kix.in> <45E70C78.9020808@kix.in> <20070301225712.GW1279@darkart.com> <98432D83-BA88-4080-B425-B5D69D73BA3A@gmail.com> Message-ID: On Mar 2, 2007, at 01:10, C?dric Luthi wrote: > On 1 mars 07, at 23:57, Eric Hall wrote: > >> One very useful thing I can think of is getting dependencies >> to support variants - i.e. port 1 need 'port 2 +variantA'. > > And also versions: > port 1 need 'port 2 @2.6.27' > > Obviously, port 2 @2.6.28 would be correct also. Well I don't think that's necessarily correct. Across minor versions (2.6.27 => 2.6.28) one would hope so... but across major versions (2.6.x => 2.7.x) things could certainly break. Subversion 1.4.3, for example, checks specifically for Neon 0.26.2, and complains if it finds 0.26.3. Neon 0.26.3 does in fact happen to work fine with Subversion, but from past experience the Subversion developers have learned to pin down the supported Neon version number quite specifically. Neon is still in initial development, hence the 0.x version number, and drastic changes can and sometimes do still occur. From rhwood at mac.com Sat Mar 3 01:48:03 2007 From: rhwood at mac.com (Randall Wood) Date: Tue Oct 9 16:40:03 2007 Subject: [22490] trunk/dports/www/apache2/Portfile In-Reply-To: <20070302215115.7CC534C5A4F@cvs.opensource.apple.com> References: <20070302215115.7CC534C5A4F@cvs.opensource.apple.com> Message-ID: <5ACF7BD3-1C80-43EA-826C-5FFF0E96AE82@mac.com> Is this +no_startupitem variant really smart? I recently had a request to add a +without_startupitem variant to a port I maintain and rejected the request; since startupitems simply enable a port to be started at boot time, but do not cause a port to be booted at start time, it simply seems stupid to deliberately cripple a server port such that a user would have to reinstall it if they wanted to start the port at boot time later. BTW: If the variant is to be retained, can it be named +without_startupitem instead? On 2 Mar 2007, at 16:51, source_changes@macosforge.org wrote: > Revision 22490 Author blair@macports.org Date 2007-03-02 13:51:15 > -0800 (Fri, 02 Mar 2007) Log MessageAdd a +no_startupitem variant > that prevents the automatic startup of the Apache web > server.Modified Paths > trunk/dports/www/apache2/Portfile > Diff > Modified: trunk/dports/www/apache2/Portfile (22489 => 22490)--- > trunk/dports/www/apache2/Portfile 2007-03-02 20:42:45 UTC (rev > 22489) +++ trunk/dports/www/apache2/Portfile 2007-03-02 21:51:15 > UTC (rev 22490) @@ -105,6 +105,10 @@ configure.args-append --with- > mpm=event } +variant no_startupitem { + startupitem.create no +} + > startupitem.create yes startupitem.start \ "\[ -x ${prefix}/apache2/ > bin/apachectl \] && ${prefix}/apache2/bin/apachectl start > /dev/ > null" @@ -112,4 +116,3 @@ "\[ -r ${prefix}/apache2/logs/httpd.pid > \] && ${prefix}/apache2/bin/apachectl stop > /dev/null" > startupitem.restart \ "\[ -r ${prefix}/apache2/logs/httpd.pid \] && > ${prefix}/apache2/bin/apachectl restart > /dev/null" - > _______________________________________________ > macports-changes mailing list > macports-changes@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From mww at macports.org Sat Mar 3 03:13:42 2007 From: mww at macports.org (Weissmann Markus) Date: Tue Oct 9 16:40:03 2007 Subject: [22490] trunk/dports/www/apache2/Portfile In-Reply-To: <5ACF7BD3-1C80-43EA-826C-5FFF0E96AE82@mac.com> References: <20070302215115.7CC534C5A4F@cvs.opensource.apple.com> <5ACF7BD3-1C80-43EA-826C-5FFF0E96AE82@mac.com> Message-ID: <014B3F19-81E1-4A9E-BDDE-851CBE3A1E40@macports.org> On 03.03.2007, at 10:48, Randall Wood wrote: > Is this +no_startupitem variant really smart? > > I recently had a request to add a +without_startupitem variant to a > port I maintain and rejected the request; since startupitems simply > enable a port to be started at boot time, but do not cause a port > to be booted at start time, it simply seems stupid to deliberately > cripple a server port such that a user would have to reinstall it > if they wanted to start the port at boot time later. > > BTW: If the variant is to be retained, can it be named > +without_startupitem instead? > The best way out of this would be to perform some port magic (that needs to be developed first...); this would be something along the idea Landon proposed for the Python ports (py-/py24-/py25-): We need a "common code" file that gets included by multiple Portfiles. The best thing imho would be, if we enable ports not to be recognized by the name "Portfile" but by a suffix - this way multiple Portfiles can live in one directory - e. g. apache2. Then we can create a common file with e. g. version, distfiles, etc. and two Portfiles "apache2" and "apache2-server". Those would both include the common file with e. g. the description, version number, dependencies, etc. but would consist of the "base apache2 installation" and the "startup-foo" respectively. cheers, -Markus PS: Oh and yes: As long as we don't have a clean solution like this, I'd say: Nuke the whatever_startupitem variant and create a "-server" Port - this way everybody can get happy. > On 2 Mar 2007, at 16:51, source_changes@macosforge.org wrote: > >> Revision 22490 Author blair@macports.org Date 2007-03-02 13:51:15 >> -0800 (Fri, 02 Mar 2007) Log MessageAdd a +no_startupitem variant >> that prevents the automatic startup of the Apache web >> server.Modified Paths >> trunk/dports/www/apache2/Portfile >> Diff >> Modified: trunk/dports/www/apache2/Portfile (22489 => 22490)--- >> trunk/dports/www/apache2/Portfile 2007-03-02 20:42:45 UTC (rev >> 22489) +++ trunk/dports/www/apache2/Portfile 2007-03-02 21:51:15 >> UTC (rev 22490) @@ -105,6 +105,10 @@ configure.args-append --with- >> mpm=event } +variant no_startupitem { + startupitem.create no +} + >> startupitem.create yes startupitem.start \ "\[ -x ${prefix}/ >> apache2/bin/apachectl \] && ${prefix}/apache2/bin/apachectl start >> > /dev/null" @@ -112,4 +116,3 @@ "\[ -r ${prefix}/apache2/logs/ >> httpd.pid \] && ${prefix}/apache2/bin/apachectl stop > /dev/null" >> startupitem.restart \ "\[ -r ${prefix}/apache2/logs/httpd.pid \] >> && ${prefix}/apache2/bin/apachectl restart > /dev/null" - >> _______________________________________________ >> macports-changes mailing list >> macports-changes@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-changes > > > Randall Wood > rhwood@mac.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 --- Markus W. Weissmann http://www.mweissmann.de/ http://www.macports.org/ From jberry at macports.org Sat Mar 3 12:38:19 2007 From: jberry at macports.org (James Berry) Date: Tue Oct 9 16:40:03 2007 Subject: [22490] trunk/dports/www/apache2/Portfile In-Reply-To: <5ACF7BD3-1C80-43EA-826C-5FFF0E96AE82@mac.com> References: <20070302215115.7CC534C5A4F@cvs.opensource.apple.com> <5ACF7BD3-1C80-43EA-826C-5FFF0E96AE82@mac.com> Message-ID: On Mar 3, 2007, at 1:48 AM, Randall Wood wrote: > Is this +no_startupitem variant really smart? > > I recently had a request to add a +without_startupitem variant to a > port I maintain and rejected the request; since startupitems simply > enable a port to be started at boot time, but do not cause a port > to be booted at start time, it simply seems stupid to deliberately > cripple a server port such that a user would have to reinstall it > if they wanted to start the port at boot time later. > > BTW: If the variant is to be retained, can it be named > +without_startupitem instead? Unless I'm missing something, I see no reason whatsoever for the no_startupitem variant, or anything like it. Using the startup item strategy, we have two cases, systemstarter (pre tiger) and launchd (tiger++): SystemStarter: The code generated by port for system starter automatically looks for an enable flag from /etc/hostconfig, and this is -NO- by default. So by default the port won't be run. Launchd: Likewise, the launchd.plist file generated for a port is not enabled by default, so by default the server won't be run. The only reason I see for having a +server variant in some cases is if building the server is way too onerous (like perhaps in the case of mysql where somebody just wants to build the client but not the server). Still this is debatable. Okay, so what possible rationale did I miss? James > > On 2 Mar 2007, at 16:51, source_changes@macosforge.org wrote: > >> Revision 22490 Author blair@macports.org Date 2007-03-02 13:51:15 >> -0800 (Fri, 02 Mar 2007) Log MessageAdd a +no_startupitem variant >> that prevents the automatic startup of the Apache web >> server.Modified Paths >> trunk/dports/www/apache2/Portfile >> Diff >> Modified: trunk/dports/www/apache2/Portfile (22489 => 22490)--- >> trunk/dports/www/apache2/Portfile 2007-03-02 20:42:45 UTC (rev >> 22489) +++ trunk/dports/www/apache2/Portfile 2007-03-02 21:51:15 >> UTC (rev 22490) @@ -105,6 +105,10 @@ configure.args-append --with- >> mpm=event } +variant no_startupitem { + startupitem.create no +} + >> startupitem.create yes startupitem.start \ "\[ -x ${prefix}/ >> apache2/bin/apachectl \] && ${prefix}/apache2/bin/apachectl start >> > /dev/null" @@ -112,4 +116,3 @@ "\[ -r ${prefix}/apache2/logs/ >> httpd.pid \] && ${prefix}/apache2/bin/apachectl stop > /dev/null" >> startupitem.restart \ "\[ -r ${prefix}/apache2/logs/httpd.pid \] >> && ${prefix}/apache2/bin/apachectl restart > /dev/null" - >> _______________________________________________ >> macports-changes mailing list >> macports-changes@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-changes > > > Randall Wood > rhwood@mac.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 From jberry at macports.org Sat Mar 3 12:49:45 2007 From: jberry at macports.org (James Berry) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal Message-ID: I'm quite distressed by the concept of too much work (and too much ugly code) going into building +universal variants of ports. I'd like to see people refrain from completely bastardizing portfiles in order to support universal builds. Let's be reasonable: the case for universal builds is fringe. We don't have easy ways to transport binary ports between systems, and it's not in general a safe thing to do. I'd much rather see: - Smaller, cleaner, more maintainable portfiles and no universal. - Work on binary packages and a build/distribution system that could deliver the pre-built port for a given architecture. Let's not see more ugliness like the universal variant in the OpenSSL port, please! (Feel free to chime in on this issue, all who care...) James From landonf at macports.org Sat Mar 3 13:09:51 2007 From: landonf at macports.org (Landon Fuller) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal In-Reply-To: References: Message-ID: On Mar 3, 2007, at 12:49 PM, James Berry wrote: > I'm quite distressed by the concept of too much work (and too much > ugly code) going into building +universal variants of ports. > > I'd like to see people refrain from completely bastardizing > portfiles in order to support universal builds. Let's be > reasonable: the case for universal builds is fringe. We don't have > easy ways to transport binary ports between systems, and it's not > in general a safe thing to do. > > I'd much rather see: > > - Smaller, cleaner, more maintainable portfiles and no universal. > > - Work on binary packages and a build/distribution system that > could deliver the pre-built port for a given architecture. > > Let's not see more ugliness like the universal variant in the > OpenSSL port, please! > > (Feel free to chime in on this issue, all who care...) I agree. It's not that universal builds are a bad idea; it's that supporting universal software requires serious bastardization of Portfiles in most cases. Assuming we implement some sort of binary distribution, I'd personally much rather use the approach that fkr and shantonu used for supporting Darwin x86 and PowerPC -- build the software on each system, natively, and then join the resultant RPMs into a single fat RPM. The example jberry notes is OpenSSL's universal-ized portfile. I don't mean to pick on Pipping -- I've personally implemented a very similar approach for building OpenVPN universally. It's pretty much the only way to do it without drastically changing the software's build system and source, but it's blindingly painful. It's not unique to OpenSSL, or OpenVPN -- most software is going to have the same issues: +variant universal { + + post-configure { + cd ${worksrcpath} + # prepare building for ppc + if [variant_isset darwin_i386] { + reinplace "s|PLATFORM=darwin-i386-cc|PLATFORM=darwin-ppc- cc|g" Makefile + reinplace "s|DL_ENDIAN|DB_ENDIAN|g" Makefile + } + reinplace "s|-O3 -DB_ENDIAN$|-O3 -DB_ENDIAN -arch ppc - isysroot /Developer/SDKs/MacOSX10.4u.sdk|" Makefile + reinplace "s|^LDFLAGS=.*|LDFLAGS=-arch ppc|g" Makefile.shared + } + + build { + cd ${worksrcpath} + # build for ppc + system [command build] + + # determine which files will need to be lipo'ed together + set lList {} + foreach s {0.9.8.dylib a} { + foreach n {crypto ssl} { + lappend lList lib${n}.${s} + } + } + set eList {} + foreach f [glob engines/*.so] { + lappend eList ${f} + } + set bList apps/openssl + set tList {} + foreach f [glob test/*test] { + lappend tList ${f} + } + lappend tList test/sha256t + lappend tList test/sha512t + + # define a backup procedure to a temporary location + proc backup {bakPath} { + xinstall -d ${bakPath} + foreach a {l e b t} b {. engines apps test} { + upvar 1 [set a]List [set a]List + xinstall -d ${bakPath}/$b + foreach n [set [set a]List] { + xinstall ${n} ${bakPath}/${b} + } + } + } + # backup the output of the first run (ppc) + set ppcPath ${workpath}/ppc + backup ${ppcPath} + + # cleanup the worksrcdir + system "make clean" + foreach f [glob lib*.0.9.8.dylib] { + delete ${f} + } + + # prepare building for i386 + reinplace "s|darwin-ppc-cc|darwin-i386-cc|g" ${worksrcpath}/ Makefile + reinplace "s|DB_ENDIAN|DL_ENDIAN|g" ${worksrcpath}/Makefile + reinplace "s|-arch ppc|-arch i386|g" ${worksrcpath}/Makefile + reinplace "s|-arch ppc|-arch i386|g" Makefile.shared + + # build for i386 + system [command build] + + # backup the output of the first run (ppc) + set i386Path ${workpath}/i386 + backup ${i386Path} + + # run lipo on the output of both runs + foreach n {l e b t} { + foreach m [set [set n]List] { + delete ${m} + system "lipo \ + -arch i386 ${i386Path}/${m} \ + -arch ppc ${ppcPath}/${m} \ + -create -output ${m}" + } + } + + # make sure installing won't rebuild + reinplace "s|install: all |install: |g" Makefile + } + + # make sure we don't build a third time + post-build {} +} + -------------- 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/20070303/e9f6a874/PGP.bin From jkh at brierdr.com Sat Mar 3 13:39:37 2007 From: jkh at brierdr.com (Jordan K. Hubbard) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal In-Reply-To: References: Message-ID: <354D9EDA-CF4D-499E-A22D-CDCB8DD1555C@brierdr.com> On Mar 3, 2007, at 12:49 PM, James Berry wrote: > I'm quite distressed by the concept of too much work (and too much > ugly code) going into building +universal variants of ports. > > I'd like to see people refrain from completely bastardizing > portfiles in order to support universal builds. Let's be > reasonable: the case for universal builds is fringe. We don't have > easy ways to transport binary ports between systems, and it's not > in general a safe thing to do. I understand what you're saying with respect to "lack of easy transport", but I can't agree that "the case for universal builds is fringe.". Perhaps you're talking about "fringe" purely with respect to MacPorts itself, but let's zoom out for a moment and look at the bigger picture again. First, universal binaries are here to stay and, once you start running Leopard, you will begin to look at anything which is NOT universal on your system with annoyance and disdain. The reason for this is something I've already covered - the Macintosh community is becoming increasingly heterogeneous in nature as more and more Intel machines join the PPC installed base, and the best thing we can do for this community ("we" being both Apple and its associated developers) is make it increasingly irrelevant just which architecture they're using, be it PPC, PPC64, x86_32 or x86_64. Stuff they download off the net or run off of a CD, network or firewire volume should Just Work? and work in a highly performant way - Rosetta is really a technology of last resort so please don't imagine that "ppc everywhere" is a good idea. We're already seeing the user community put a lot of pressure on folks like Adobe to get their stuff universal since things like plug- ins and extensions make a non-Universal world really a nightmare (particularly when you need a PPC-only plug-in and an x86-only plug- in running in a web browser - you end up having to run two browsers). So, bigger picture, Universal is the way to go and it's the message we're sending to everyone, both because it's the right thing to do from an advanced-technology perspective and because we want to present a united front on this issue to the commercial ISVs who might otherwise be tempted to let this one slide for awhile longer and continue to impact the overall Macintosh user experience in negative ways. So, enter MacPorts. Does MacPorts absolutely need to do this or nobody will ever use it again? Of course not. There is, however, still a lot of confusion and ignorance in the OSS community about how to build things universal (particularly in the presence of configure scripts, which definitely need to evolve). A build-framework like MacPorts has the ability to substantially lead the way here and, by example, demonstrate to literally thousands of open source developers just how to do it. Just as importantly, by grasping the nettle at the build stage, MacPorts is not setting itself up for more work at the packaging stage it (I hope) eventually wants to get to. Nobody is seriously suggesting (I HOPE) having parallel collections of many thousands of packages, one for x86 and one for ppc (and, at some point, one full of experimental 64-bit capable stuff), when it's perfectly possible and encouraged to have just ONE package collection that works for everything. By not figuring out how to build universal, MacPorts would merely be stealing resources from the future in order to be lazy in the present. There would be no net gain and definitely a net loss as the ability to share a single /opt among multiple machines on a network went out the window too. I also think MacPorts will increasingly find itself to be the odd man out if it doesn't go down the universal road. People ARE figuring out how to do it and it's become something of a badge of honor to get your application and frameworks building n-way universal so that your users don't have to think about anything more than which version of your product or project they want. People who are using xcode have an easier time of it - they just click the universal checkbox and, unless they've written something egregious into their code, it just works. I hope you're not saying that the Unix command-line driven community can't possibly build its stuff as well as xcode can since them's fightin' words. :-) Now, if you're saying that the initial efforts to get there have been clunky and inelegant then I'm not going to dispute that since you're probably right. That doesn't mean you throw the baby out with the bathwater, however, it means you figure out how to do a better job of it by learning from your early mistakes! - Jordan From jkh at brierdr.com Sat Mar 3 14:33:07 2007 From: jkh at brierdr.com (Jordan K. Hubbard) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal In-Reply-To: References: Message-ID: On Mar 3, 2007, at 1:09 PM, Landon Fuller wrote: > I agree. It's not that universal builds are a bad idea; it's that > supporting universal software requires serious bastardization of > Portfiles in most cases. Assuming we implement some sort of binary > distribution, I'd personally much rather use the approach that fkr > and shantonu used for supporting Darwin x86 and PowerPC -- build > the software on each system, natively, and then join the resultant > RPMs into a single fat RPM. I think this may have gotten lost in all my earlier verbiage, but I also pointed out early in the conversation that there are many many open source projects building universal at Apple without such "bastardization". The Makefile for OpenSSL is just 147 lines, for example, and of that at LEAST 50% has to do strictly with Apple's own requirements (the whole SRCROOT and DSTROOT thing, order files, all the things you probably still have nightmares about from time to time). Perhaps 5 lines in the Makefile are devoted to the fact that it's building universal. The rest is in the "generic machinery" and helper scripts (which, you'll instantly notice, have a lineage dating back to 10.1) like this one: -------------- next part -------------- A non-text attachment was scrubbed... Name: ar.sh Type: application/octet-stream Size: 1852 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070303/fe73dcbc/ar.obj -------------- next part -------------- This gets used by the generic CoreOS Makefile machinery in place of ar (1), given a bit of metadata expressed in other parts of the build system. Are lipo(1) tricks like this the best way to do it? Not even saying that. I'm simply saying that it's a fallacy to assume that OpenSSL, OpenVPN and hundreds of other ports are all going to need to grow universal variant rules as long and complex as the one you posted. Just because someone hasn't templated that stuff and stuck it somewhere for every port to use doesn't mean it can't be done, and Apple's own open source projects are living proof of that. I'm furthermore assuming that once a few more universal ports get done and the commonality in the rules starts to shine through the complexity, someone WILL sweep it into a pile and make it port- generic. I can recall a time when darwin^H^H^H^H^Hmacports had a lot of pretty crufty Portfiles which, over time, got substantially less crufty as more primitives were added and consolidation mechanisms like PortGroup got added. Why is everyone being so quick to slam pipping's changes before they even have a chance to go through an evolution or two? I know there are still a few people here who still don't get the whole point of universal builds, or doubt their value to MacPorts, but that's orthogonal to the whole issue of "quality of implementation", something which has to at least be given a chance to improve before coming to any firm conclusions about it. - Jordan From landonf at macports.org Sat Mar 3 14:56:16 2007 From: landonf at macports.org (Landon Fuller) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal In-Reply-To: References: Message-ID: <85DA9172-2586-4FDF-9D1A-FDC0352B345C@macports.org> On Mar 3, 2007, at 2:33 PM, Jordan K. Hubbard wrote: > > On Mar 3, 2007, at 1:09 PM, Landon Fuller wrote: > >> I agree. It's not that universal builds are a bad idea; it's that >> supporting universal software requires serious bastardization of >> Portfiles in most cases. Assuming we implement some sort of binary >> distribution, I'd personally much rather use the approach that fkr >> and shantonu used for supporting Darwin x86 and PowerPC -- build >> the software on each system, natively, and then join the resultant >> RPMs into a single fat RPM. > > I think this may have gotten lost in all my earlier verbiage, but I > also pointed out early in the conversation that there are many many > open source projects building universal at Apple without such > "bastardization". The Makefile for OpenSSL is just 147 lines, for > example, and of that at LEAST 50% has to do strictly with Apple's > own requirements (the whole SRCROOT and DSTROOT thing, order files, > all the things you probably still have nightmares about from time > to time). Perhaps 5 lines in the Makefile are devoted to the fact > that it's building universal. I don't think it's reasonable to compare Apple's static manually managed B&I build system to MacPorts. We could also write shell scripts and Makefiles and random glue to build software, but we don't -- MacPorts, instead, requires ports to be declarative, and then takes care of the rest. These are two different problem spaces. Apple, due to B&I's requirements, *needs* software to build universal on single systems. We don't, and there are arguably many benefits to not doing so, the greatest of which is reduced maintenance and implementation complexity. > Why is everyone being so quick to slam pipping's changes before > they even have a chance to go through an evolution or two? I know > there are still a few people here who still don't get the whole > point of universal builds, or doubt their value to MacPorts, but > that's orthogonal to the whole issue of "quality of > implementation", something which has to at least be given a chance > to improve before coming to any firm conclusions about it. Because the right place to fix this is in the upstream project's build, not as an add-on set of extensive hacks. It's admittedly not black and white -- if a project builds universal with a few CFLAG tweaks, and works fine under testing, then super! But blithely forcing software into the +universal universe just doesn't add up when there are only fringe benefits and *great cost* in terms of added complexity. -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070303/0dfc38f4/PGP.bin From landonf at macports.org Sat Mar 3 15:09:50 2007 From: landonf at macports.org (Landon Fuller) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal In-Reply-To: <354D9EDA-CF4D-499E-A22D-CDCB8DD1555C@brierdr.com> References: <354D9EDA-CF4D-499E-A22D-CDCB8DD1555C@brierdr.com> Message-ID: On Mar 3, 2007, at 1:39 PM, Jordan K. Hubbard wrote: > Now, if you're saying that the initial efforts to get there have > been clunky and inelegant then I'm not going to dispute that since > you're probably right. That doesn't mean you throw the baby out > with the bathwater, however, it means you figure out how to do a > better job of it by learning from your early mistakes! Nobody is arguing against universal builds. The goal is to avoid a mountain of impossibly complex, difficult to maintain code in the Ports tree. The fact that universal is a happy land of milk and honey is great, but I don't think any of your points refute jberry's original statement: I'd like to see people refrain from completely bastardizing portfiles in order to support universal builds. Me too. -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070303/751972ee/PGP.bin From jberry at macports.org Sat Mar 3 15:16:48 2007 From: jberry at macports.org (James Berry) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal In-Reply-To: <354D9EDA-CF4D-499E-A22D-CDCB8DD1555C@brierdr.com> References: <354D9EDA-CF4D-499E-A22D-CDCB8DD1555C@brierdr.com> Message-ID: On Mar 3, 2007, at 1:39 PM, Jordan K. Hubbard wrote: > > On Mar 3, 2007, at 12:49 PM, James Berry wrote: > >> I'm quite distressed by the concept of too much work (and too much >> ugly code) going into building +universal variants of ports. >> >> I'd like to see people refrain from completely bastardizing >> portfiles in order to support universal builds. Let's be >> reasonable: the case for universal builds is fringe. We don't have >> easy ways to transport binary ports between systems, and it's not >> in general a safe thing to do. > > I understand what you're saying with respect to "lack of easy > transport", but I can't agree that "the case for universal builds > is fringe.". Perhaps you're talking about "fringe" purely with > respect to MacPorts itself, but let's zoom out for a moment and > look at the bigger picture again. I am speaking about macports, not the general case. Adding huge hacks to individual portfiles in order to support universal builds gets us nowhere -- particularly when we don't have the distribution mechanisms in place to really do anything with such universal port builds. > So, enter MacPorts. Does MacPorts absolutely need to do this or > nobody will ever use it again? Of course not. There is, however, > still a lot of confusion and ignorance in the OSS community about > how to build things universal (particularly in the presence of > configure scripts, which definitely need to evolve). A build- > framework like MacPorts has the ability to substantially lead the > way here and, by example, demonstrate to literally thousands of > open source developers just how to do it. Just as importantly, by > grasping the nettle at the build stage, MacPorts is not setting > itself up for more work at the packaging stage it (I hope) > eventually wants to get to. Nobody is seriously suggesting (I > HOPE) having parallel collections of many thousands of packages, > one for x86 and one for ppc (and, at some point, one full of > experimental 64-bit capable stuff), when it's perfectly possible > and encouraged to have just ONE package collection that works for > everything. By not figuring out how to build universal, MacPorts > would merely be stealing resources from the future in order to be > lazy in the present. There would be no net gain and definitely a > net loss as the ability to share a single /opt among multiple > machines on a network went out the window too. Rather than big hacks on individual ports, it would seem better to have a couple of declarative statements for the universal strategy of a port: - port may be built universal: yes/no - port builds universal out of box: yes/no - port builds in single pass with flags: xxx - port can be built in multiple passes by lipoing together the following binaries... (all others are assumed the same builds) Something like that would allow us to declaratively describe what's needed to build many ports, and would allow macports to use several strategies to build universal ports: (1) This port can't be build universal (for whatever reason) (2) This port already builds universal (we don't need to do anything special) (3) This port can be built universal by setting these flags... (4) This port can be built as multiple versions that may then be lipoed together, using all binaries or those specified We already do (2), and can mostly do (3) using a default set of flags. I'll argue that I'd rather see support for (4) built-in once, than built into each portfile. James From jkh at brierdr.com Sat Mar 3 17:06:46 2007 From: jkh at brierdr.com (Jordan K. Hubbard) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal In-Reply-To: References: <354D9EDA-CF4D-499E-A22D-CDCB8DD1555C@brierdr.com> Message-ID: On Mar 3, 2007, at 3:16 PM, James Berry wrote: > I am speaking about macports, not the general case. Adding huge > hacks to individual portfiles in order to support universal builds > gets us nowhere -- particularly when we don't have the distribution > mechanisms in place to really do anything with such universal port > builds. And I hope I've made it clear that I'm not defending the "huge hacks" either. I don't like huge hacks. I like generic support that can be leveraged. So far, I think the generic support for universal building is still pretty green, however, and I guess the ultimate question is whether or not MacPorts wants to invest anything in this area at all if people are still questioning the worth of universal executables and frameworks (in the context of MP) at all. I've said my piece and if people still don't agree, that's cool, I just thought it was something worth taking a fairly strong stand over and I'm not going to go in the corner and cry if MP decides it's always going to be a "build your own stuff" solution (which still leaves a fairly big hole in what end-users are looking for, sadly). > Rather than big hacks on individual ports, it would seem better to > have a couple of declarative statements for the universal strategy > of a port: > > - port may be built universal: yes/no > - port builds universal out of box: yes/no > - port builds in single pass with flags: xxx > - port can be built in multiple passes by lipoing together the > following binaries... (all others are assumed the same builds) I'm not sure what value is added by having so many states. I think, as far as the builder is concerned, the only state that counts for anything is the first one. Does it build universal? Yes? OK, then the builder can choose to build it universal if that's valuable to them. If not, then it's a moot point. As far as an internal macports developer is concerned, there's also not a lot of value in splitting hairs here. If it builds universal out of the box vs tweaking it, that's great, but it's no different than having a port which compiles on MacOSX with no patches and respects $prefix properly in all ways vs one which has to be coerced into doing those things. Whether to lipo or not depends as much on what the macports developer wants to do (e.g. how much trouble to go through in the "coercion process") as anything else, so I don't see what value a declarative statement adds there either. - Jordan From rpz at cse.wustl.edu Sat Mar 3 18:58:22 2007 From: rpz at cse.wustl.edu (Bob Zimmermann) Date: Tue Oct 9 16:40:03 2007 Subject: How to contribute (was: (no subject)) Message-ID: Thanks for the informative post. I have an additional question: If I have multiple interdependent ports that I want to submit, should I submit them all in a single ticket or just make multiple tickets, each of which refers to its dependent tickets? Thanks, Bob > On Feb 23, 2007, at 19:14, Mark Dymek wrote: > > > Hi i would like to become a Developer/Contributer to macports how > > do i get started? In other words how do i find out which projects > > are not being done by someone or should i just look over the > > current projects and see one i like or should i just submit my own > > thing to you guys and see if you like it and want to include it? I > > know you are still transferring over from darwinports but i can't > > seem to find any documentation on either of the two sites that > > gives specific instructions to people who want to become part of > > the team. Any help would be appreciated thanks a lot. > > If you would like to write new portfiles or update existing ones, you > can do so locally, then submit a patch to a new ticket in Trac. Then > send a message to this list with the ticket URL and a committer will > evaluate the ticket and hopefully commit the change. Portfiles are > written in a language called tcl, but it's not hard to learn, and the > easiest way is probably to just look at some of the existing > portfiles to see how they do things. > > You can also help by looking through the open tickets, seeing which > don't have patches already, and writing and attaching the patches, > then informing the list which tickets you've done this for. > > Even finding open tickets that already have patches, that just > haven't been committed yet, and alerting the list about these can be > helpful. If you can first try the patch out locally and verify that > it fixes whatever the issue is, that's even better. > > You can find ports that are abandoned by looking for the maintainer > set to nomaintainer at macports.org, like this: > > $ port echo maintainer:nomaintainer at macports.org > > I currently see over a thousand unmaintained ports. If you see one in > the list that you would like to maintain, you can alert the list or a > committer and we can make you the maintainer. Then you can submit > updates to the port as above, and other users of that port will know > to contact you when they have questions or requests. > > Commit access can be granted to people who have made several positive > contributions. Generally you should be the maintainer of several > ports already before you request commit access. > > If you would like to develop the core MacPorts code, you can make > local changes and submit a patch to a new ticket in Trac, just like > with the ports, and then one of the core MacPorts code developers can > review your changes. I'm not sure if there's a current roadmap of > desired future changes at this point. If there is, that would be the > place to look for ideas for contributions. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070303/bc002732/smime.bin From jberry at macports.org Sat Mar 3 19:21:36 2007 From: jberry at macports.org (James Berry) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal In-Reply-To: References: <354D9EDA-CF4D-499E-A22D-CDCB8DD1555C@brierdr.com> Message-ID: <11F63B10-2699-4258-80B9-CA7CD3F462C3@macports.org> On Mar 3, 2007, at 5:06 PM, Jordan K. Hubbard wrote: >> Rather than big hacks on individual ports, it would seem better to >> have a couple of declarative statements for the universal strategy >> of a port: >> >> - port may be built universal: yes/no >> - port builds universal out of box: yes/no >> - port builds in single pass with flags: xxx >> - port can be built in multiple passes by lipoing together the >> following binaries... (all others are assumed the same builds) > > I'm not sure what value is added by having so many states. I > think, as far as the builder is concerned, the only state that > counts for anything is the first one. Does it build universal? > Yes? OK, then the builder can choose to build it universal if > that's valuable to them. If not, then it's a moot point. As far > as an internal macports developer is concerned, there's also not a > lot of value in splitting hairs here. If it builds universal out > of the box vs tweaking it, that's great, but it's no different than > having a port which compiles on MacOSX with no patches and respects > $prefix properly in all ways vs one which has to be coerced into > doing those things. Whether to lipo or not depends as much on > what the macports developer wants to do (e.g. how much trouble to > go through in the "coercion process") as anything else, so I don't > see what value a declarative statement adds there either. As always, my mind was racing ahead to implementation ;) What I was thinking out, though I didn't clearly say so, was what syntax we might need to add to portfiles to support building software universally in a more general fashion than having a separate implementation for each port. The user doesn't care about any of that, surely, except for #1. James From rnichol_rrc at yahoo.com Sat Mar 3 19:44:32 2007 From: rnichol_rrc at yahoo.com (Reid Nichol) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal In-Reply-To: <11F63B10-2699-4258-80B9-CA7CD3F462C3@macports.org> Message-ID: <851657.995.qm@web32113.mail.mud.yahoo.com> Hi all: I've been lurking for the past little while and have been reading the arguments for both sides. I think something has been missed though. To have any meaningful discussion one must specify what is the target audience. Now, if one only considers the typical user as the one that will be using MacPorts, then having universal binaries is, of course, optional. BUT, if one includes developers in the MacPorts user audience, then this is a different story. Now, as for the messing up the Portfile thing. Yes, everyone agrees that having the universal binary hack in every Portfile is messy and undesirable. Please, stop bringing this up as it really is beating a dead horse at this point. Also, to assume that this is the only option for including this functionality is ridiculous. So, instead of trashing one bad idea (over and over), how about discussing ways that might get this wanted functionality in with minimal pain. A couple ideas have already been thrown out there. How about sticking to discussing those (or other ones)? It's just that I've seen so many discussions got south because of some people's tendency to hyper-focus on one little thing. It'd be a shame to see universal binaries not be implemented if only because of this. best regards, Reid ____________________________________________________________________________________ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail From blair at orcaware.com Sat Mar 3 23:34:50 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:03 2007 Subject: [22490] trunk/dports/www/apache2/Portfile In-Reply-To: <5ACF7BD3-1C80-43EA-826C-5FFF0E96AE82@mac.com> References: <20070302215115.7CC534C5A4F@cvs.opensource.apple.com> <5ACF7BD3-1C80-43EA-826C-5FFF0E96AE82@mac.com> Message-ID: <45EA769A.4030405@orcaware.com> Hi Randall, I have a MacPorts build on a portable firewire/USB drive and on this drive is a Python app that starts Apache and MySQL and then points a browser at the local running Apache. So given that the Apache is on a portable drive, when I build the port, I don't need the startupitem, hence the variant. BTW, MySQL doesn't enable the automatic startup of the server unless the +server variant is supplied. Regards, Blair Randall Wood wrote: > Is this +no_startupitem variant really smart? > > I recently had a request to add a +without_startupitem variant to a port > I maintain and rejected the request; since startupitems simply enable a > port to be started at boot time, but do not cause a port to be booted at > start time, it simply seems stupid to deliberately cripple a server port > such that a user would have to reinstall it if they wanted to start the > port at boot time later. > > BTW: If the variant is to be retained, can it be named > +without_startupitem instead? > > On 2 Mar 2007, at 16:51, source_changes@macosforge.org wrote: > >> Revision 22490 Author blair@macports.org Date 2007-03-02 13:51:15 >> -0800 (Fri, 02 Mar 2007) Log MessageAdd a +no_startupitem variant that >> prevents the automatic startup of the Apache web server.Modified Paths >> trunk/dports/www/apache2/Portfile >> Diff >> Modified: trunk/dports/www/apache2/Portfile (22489 => 22490)--- >> trunk/dports/www/apache2/Portfile 2007-03-02 20:42:45 UTC (rev >> 22489) +++ trunk/dports/www/apache2/Portfile 2007-03-02 21:51:15 >> UTC (rev 22490) @@ -105,6 +105,10 @@ configure.args-append >> --with-mpm=event } +variant no_startupitem { + >> startupitem.create no +} + startupitem.create yes >> startupitem.start \ "\[ -x ${prefix}/apache2/bin/apachectl \] && >> ${prefix}/apache2/bin/apachectl start > /dev/null" @@ -112,4 +116,3 @@ >> "\[ -r ${prefix}/apache2/logs/httpd.pid \] && >> ${prefix}/apache2/bin/apachectl stop > /dev/null" >> startupitem.restart \ "\[ -r ${prefix}/apache2/logs/httpd.pid \] && >> ${prefix}/apache2/bin/apachectl restart > /dev/null" - >> _______________________________________________ >> macports-changes mailing list >> macports-changes@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-changes > > > Randall Wood > rhwood@mac.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 From blair at orcaware.com Sat Mar 3 23:38:27 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:03 2007 Subject: [22490] trunk/dports/www/apache2/Portfile In-Reply-To: <014B3F19-81E1-4A9E-BDDE-851CBE3A1E40@macports.org> References: <20070302215115.7CC534C5A4F@cvs.opensource.apple.com> <5ACF7BD3-1C80-43EA-826C-5FFF0E96AE82@mac.com> <014B3F19-81E1-4A9E-BDDE-851CBE3A1E40@macports.org> Message-ID: <45EA7773.40204@orcaware.com> Weissmann Markus wrote: > On 03.03.2007, at 10:48, Randall Wood wrote: > >> Is this +no_startupitem variant really smart? >> >> I recently had a request to add a +without_startupitem variant to a >> port I maintain and rejected the request; since startupitems simply >> enable a port to be started at boot time, but do not cause a port to >> be booted at start time, it simply seems stupid to deliberately >> cripple a server port such that a user would have to reinstall it if >> they wanted to start the port at boot time later. >> >> BTW: If the variant is to be retained, can it be named >> +without_startupitem instead? >> > > The best way out of this would be to perform some port magic (that needs > to be developed first...); this would be something along the idea Landon > proposed for the Python ports (py-/py24-/py25-): > We need a "common code" file that gets included by multiple Portfiles. > The best thing imho would be, if we enable ports not to be recognized by > the name "Portfile" but by a suffix - this way multiple Portfiles can > live in one directory - e. g. apache2. > Then we can create a common file with e. g. version, distfiles, etc. and > two Portfiles "apache2" and "apache2-server". Those would both include > the common file with e. g. the description, version number, > dependencies, etc. but would consist of the "base apache2 installation" > and the "startup-foo" respectively. > > > cheers, > > -Markus > > PS: Oh and yes: As long as we don't have a clean solution like this, I'd > say: Nuke the whatever_startupitem variant and create a "-server" Port - > this way everybody can get happy. That seems like a lot of work for one variant. I say keep it as is still the new include method can be worked out. While we're on the subject, it would be good to standardize on server startups. MySQL doesn't enable it by default. Blair From blair at orcaware.com Sat Mar 3 23:47:51 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:03 2007 Subject: [22490] trunk/dports/www/apache2/Portfile In-Reply-To: References: <20070302215115.7CC534C5A4F@cvs.opensource.apple.com> <5ACF7BD3-1C80-43EA-826C-5FFF0E96AE82@mac.com> Message-ID: <45EA79A7.2020508@orcaware.com> James Berry wrote: > > On Mar 3, 2007, at 1:48 AM, Randall Wood wrote: > >> Is this +no_startupitem variant really smart? >> >> I recently had a request to add a +without_startupitem variant to a >> port I maintain and rejected the request; since startupitems simply >> enable a port to be started at boot time, but do not cause a port to >> be booted at start time, it simply seems stupid to deliberately >> cripple a server port such that a user would have to reinstall it if >> they wanted to start the port at boot time later. >> >> BTW: If the variant is to be retained, can it be named >> +without_startupitem instead? > > Unless I'm missing something, I see no reason whatsoever for the > no_startupitem variant, or anything like it. > Using the startup item strategy, we have two cases, systemstarter (pre > tiger) and launchd (tiger++): > > SystemStarter: The code generated by port for system starter > automatically looks for an enable flag from /etc/hostconfig, and this is > -NO- by default. So by default the port won't be run. > > Launchd: Likewise, the launchd.plist file generated for a port is not > enabled by default, so by default the server won't be run. > > The only reason I see for having a +server variant in some cases is if > building the server is way too onerous (like perhaps in the case of > mysql where somebody just wants to build the client but not the server). > Still this is debatable. I still don't need that stuff installed on the system at all for this use of MacPorts, even if it isn't enabled by default. Definitely not a standard use of MacPorts, but I have a client that ships Firewire/USB drives with a MacPorts install in /Volumes/SOMENAME/. People plugin in the drive, launch a Python app which starts Apache and MySQL. Regards, Blair -- Blair Zajac, Ph.D. Subversion training, consulting and support http://www.orcaware.com/svn/ From vincent-opdarw at vinc17.org Sun Mar 4 04:23:41 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal In-Reply-To: <851657.995.qm@web32113.mail.mud.yahoo.com> References: <11F63B10-2699-4258-80B9-CA7CD3F462C3@macports.org> <851657.995.qm@web32113.mail.mud.yahoo.com> Message-ID: <20070304122341.GA18355@prunille.vinc17.org> On 2007-03-03 19:44:32 -0800, Reid Nichol wrote: [...] > Now, as for the messing up the Portfile thing. Yes, everyone agrees > that having the universal binary hack in every Portfile is messy and > undesirable. Please, stop bringing this up as it really is beating a > dead horse at this point. Also, to assume that this is the only option > for including this functionality is ridiculous. > > So, instead of trashing one bad idea (over and over), how about > discussing ways that might get this wanted functionality in with > minimal pain. A couple ideas have already been thrown out there. How > about sticking to discussing those (or other ones)? Yes, and as this has been said somewhere, this should be done upstream (perhaps at the autoconf level, with a new option --enable-universal). Indeed, I don't see why only MacPorts users could be interested in universal binaries. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From pipping at macports.org Sun Mar 4 06:10:52 2007 From: pipping at macports.org (Elias Pipping) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal In-Reply-To: <20070304122341.GA18355@prunille.vinc17.org> References: <11F63B10-2699-4258-80B9-CA7CD3F462C3@macports.org> <851657.995.qm@web32113.mail.mud.yahoo.com> <20070304122341.GA18355@prunille.vinc17.org> Message-ID: On Mar 4, 2007, at 1:23 PM, Vincent Lefevre wrote: > On 2007-03-03 19:44:32 -0800, Reid Nichol wrote: > [...] >> Now, as for the messing up the Portfile thing. Yes, everyone >> agrees >> that having the universal binary hack in every Portfile is messy and >> undesirable. Please, stop bringing this up as it really is beating a >> dead horse at this point. Also, to assume that this is the only >> option >> for including this functionality is ridiculous. >> >> So, instead of trashing one bad idea (over and over), how about >> discussing ways that might get this wanted functionality in with >> minimal pain. A couple ideas have already been thrown out there. >> How >> about sticking to discussing those (or other ones)? > > Yes, and as this has been said somewhere, this should be done upstream > (perhaps at the autoconf level, with a new option --enable-universal). > Indeed, I don't see why only MacPorts users could be interested in > universal binaries. > I guess nobody feels responsible for taking care of universal binaries: http://lists.gnu.org/archive/html/bug-coreutils/2007-02/msg00320.html > -- > Vincent Lef?vre - Web: > 100% accessible validated (X)HTML - Blog: blog/> > Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS- > Lyon) > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From jmpp at macports.org Sun Mar 4 16:25:27 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:03 2007 Subject: tbz or tbz2 In-Reply-To: <45E6025B.60704@orcaware.com> References: <45E6025B.60704@orcaware.com> Message-ID: <59e61d7930b027880df8bd9c271d2385@macports.org> On Feb 28, 2007, at 6:29 PM, Blair Zajac wrote: > I was messing around with the portarchivetype option today and tried > to set it to tbz2 according to ports.conf, but the resulting files, > while ending in .tbz2, were not: > > /opt/local/var/db/dports/packages/darwin/i386/coreutils > -6.7_1+with_default_names.i386.tbz2: POSIX tar archive This is because the switch statement taking care of setting up the archive type does not support a "bz2" ending for our tar based archives (as I'm sure you know by now if you read the proper source file, I'm just pasting here for discussion's sake ;-): in base/src/package1.0/portarchive.tcl: proc archive_command_setup {args} { (snip) switch -regex ${archive.type} { (snip) t(ar|bz|gz) { (snip) if {[regexp {z$} ${archive.type}]} { (snip) } } } } That '$' in "z$" kills our ability to handle "z2" as an extension ending, thus eliminating the possibility of dealing with either tbz or tbz2 named archives. "archivemode" having been questioned extensively before, I still say we fix this (in my opinion) rather important omission: personally, I would move from "tbz" to "tbz2" as I believe the latter is much more common; but I can understand how that would disrupt a maybe large portion if the user base already using "tbz", so instead I say we make room for both: - t(ar|bz|gz) { + t(ar|bz|bz2|gz) { - if {[regexp {z$} ${archive.type}]} { + if {[regexp {z2?$} ${archive.type}]} { - if {[regexp {bz$} ${archive.type}]} { + if {[regexp {bz2?$} ${archive.type}]} { (changes tested and working) > > So the code looks a little fragile in that it does regex matching on > the names to determine which archiver and compressor to use. It also > doesn't cover misspelled settings The "default" clause should cover them as errors in the ports.conf setting, prompting users to correct them, which seems sane to me. > > So a couple of things: > > 1) Should we decide on a standard tbz or tbz2? We should have the > documentation match the code. My changes above should allow for both "tbz" and "tbz2", allowing the user to choose his/her favorite. If checked in, we would also patch documentation to list both options (cf. your r22465 commit). Opinions? > 2) Have to code check for all valid types instead of trying regexps on > them? Maybe a tad too stringent....? Did you detect any errors (other than the one discussed here) in checking for supported archive types? > > Thanks, > Blair > Thanks for bringing this up! Regards,.. -jmpp PS: Truth be told, I think we should move to the by far much more standard "*.tar.gz" & "*.tar.bz2" naming convention, but I don't think many would care enough about "archivemode" to even dig into it to determine the effects such move would have. Do you? Hint, hint... ;-) From jmpp at macports.org Sun Mar 4 16:31:39 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:03 2007 Subject: tbz or tbz2 In-Reply-To: <59e61d7930b027880df8bd9c271d2385@macports.org> References: <45E6025B.60704@orcaware.com> <59e61d7930b027880df8bd9c271d2385@macports.org> Message-ID: <6fd85caa845e440554437310284d2d22@macports.org> On Mar 4, 2007, at 8:25 PM, Juan Manuel Palacios wrote: > - t(ar|bz|gz) { > + t(ar|bz|bz2|gz) { "t(ar|bz|gz)" matches both "tbz" & "tbz2" in the regexp, so that one change there wouldn't be necessary. But you get my point ;-) -jmpp From peter at pogma.com Sun Mar 4 20:32:48 2007 From: peter at pogma.com (Peter O'Gorman) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal In-Reply-To: References: <11F63B10-2699-4258-80B9-CA7CD3F462C3@macports.org> <851657.995.qm@web32113.mail.mud.yahoo.com> <20070304122341.GA18355@prunille.vinc17.org> Message-ID: <29B9D8DB-7106-4C48-BD41-F2FE69BA3C54@pogma.com> On Mar 4, 2007, at 11:10 PM, Elias Pipping wrote: > On Mar 4, 2007, at 1:23 PM, Vincent Lefevre wrote: > >> On 2007-03-03 19:44:32 -0800, Reid Nichol wrote: >> [...] >>> Now, as for the messing up the Portfile thing. Yes, everyone >>> agrees >>> that having the universal binary hack in every Portfile is messy and >>> undesirable. Please, stop bringing this up as it really is >>> beating a >>> dead horse at this point. Also, to assume that this is the only >>> option >>> for including this functionality is ridiculous. >>> >>> So, instead of trashing one bad idea (over and over), how about >>> discussing ways that might get this wanted functionality in with >>> minimal pain. A couple ideas have already been thrown out >>> there. How >>> about sticking to discussing those (or other ones)? >> >> Yes, and as this has been said somewhere, this should be done >> upstream >> (perhaps at the autoconf level, with a new option --enable- >> universal). >> Indeed, I don't see why only MacPorts users could be interested in >> universal binaries. >> > > > I guess nobody feels responsible for taking care of universal > binaries: > > http://lists.gnu.org/archive/html/bug-coreutils/2007-02/ > msg00320.html What do you mean? I spent dozens of hours getting GNU libtool to work with universal binaries. It could create and unpack fat static archives etc before Apple announced their switch to intel. Since the switch I have also added support for their odd -isysroot etc flags. My point about autoconf is vaild. The fix for AC_C_BIGENDIAN is incomplete, it does not work if the package does not use a config header, and the other issues with sizeof checks and offsetof etc still remain. Peter From pipping at macports.org Mon Mar 5 01:15:46 2007 From: pipping at macports.org (Elias Pipping) Date: Tue Oct 9 16:40:03 2007 Subject: Just say no to +universal In-Reply-To: <29B9D8DB-7106-4C48-BD41-F2FE69BA3C54@pogma.com> References: <11F63B10-2699-4258-80B9-CA7CD3F462C3@macports.org> <851657.995.qm@web32113.mail.mud.yahoo.com> <20070304122341.GA18355@prunille.vinc17.org> <29B9D8DB-7106-4C48-BD41-F2FE69BA3C54@pogma.com> Message-ID: <1E30071B-98C3-41A4-95A2-8EC6DEDCA39D@macports.org> On Mar 5, 2007, at 5:32 AM, Peter O'Gorman wrote: > > On Mar 4, 2007, at 11:10 PM, Elias Pipping wrote: > >> On Mar 4, 2007, at 1:23 PM, Vincent Lefevre wrote: >> >>> On 2007-03-03 19:44:32 -0800, Reid Nichol wrote: >>> [...] >>>> Now, as for the messing up the Portfile thing. Yes, everyone >>>> agrees >>>> that having the universal binary hack in every Portfile is messy >>>> and >>>> undesirable. Please, stop bringing this up as it really is >>>> beating a >>>> dead horse at this point. Also, to assume that this is the only >>>> option >>>> for including this functionality is ridiculous. >>>> >>>> So, instead of trashing one bad idea (over and over), how about >>>> discussing ways that might get this wanted functionality in with >>>> minimal pain. A couple ideas have already been thrown out >>>> there. How >>>> about sticking to discussing those (or other ones)? >>> >>> Yes, and as this has been said somewhere, this should be done >>> upstream >>> (perhaps at the autoconf level, with a new option --enable- >>> universal). >>> Indeed, I don't see why only MacPorts users could be interested in >>> universal binaries. >>> >> >> >> I guess nobody feels responsible for taking care of universal >> binaries: >> >> http://lists.gnu.org/archive/html/bug-coreutils/2007-02/ >> msg00320.html > > What do you mean? > > I spent dozens of hours getting GNU libtool to work with universal > binaries. Well, how would I know? Anyway - sorry, I must've misunderstood you. From iclaymore at gmail.com Mon Mar 5 04:15:48 2007 From: iclaymore at gmail.com (Isaac Huang) Date: Tue Oct 9 16:40:03 2007 Subject: build glib2 universal binary on PPC Message-ID: The glib2 configure script makes conclusions about endianness and atomic operations from host cpu type, and generates headers with such assumptions inside. I've searched this list and someone said glib2 needed a patch for this. But I couldn't find this patch, and I also lack enough knowledge about glib2 to fix it myself. Any hint or suggestion is appreciated. BTW, I don't have an Intel Mac so I can't build and lipo. Thanks, Isaac -- Regards, Isaac () ascii ribbon campaign - against html e-mail /\ - against microsoft attachments From vincent-opdarw at vinc17.org Mon Mar 5 04:47:36 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:03 2007 Subject: Messages with non-ASCII characters displayed with UTF-8 sequences Message-ID: <20070305124736.GA1538@prunille.vinc17.org> For those who are in non-UTF-8 locales and use non-English locales (with messages containing non-ASCII characters, such as accented characters) and wonder if something gets wrong with these messages: On my machine, all these messages suddenly appeared with undecoded UTF-8 sequences, and I took me some time to find out what the cause was: the new version of m4 (1.4.8b_1), that supplies a file /opt/local/lib/charset.alias whose effect is to regard any charset as UTF-8! I've reported the bug: http://trac.macosforge.org/projects/macports/ticket/11474 -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From giulio.eulisse at cern.ch Mon Mar 5 06:39:28 2007 From: giulio.eulisse at cern.ch (Giulio Eulisse) Date: Tue Oct 9 16:40:03 2007 Subject: sqlobject 0.8.0 Message-ID: Ciao, I've updated the sqlobject port to 0.8.0 in my private area. What's the preferred way of submitting a patch? Is there any "port" command that creates the patch for me? Is the "port submit" command supported at all? Ciao, Giulio From pipping at macports.org Mon Mar 5 07:32:20 2007 From: pipping at macports.org (Elias Pipping) Date: Tue Oct 9 16:40:03 2007 Subject: Messages with non-ASCII characters displayed with UTF-8 sequences In-Reply-To: <20070305124736.GA1538@prunille.vinc17.org> References: <20070305124736.GA1538@prunille.vinc17.org> Message-ID: <6B9C8C24-F8F3-4D16-9AE2-C1F1EE719491@macports.org> attached a patch http://trac.macosforge.org/projects/macports/attachment/ticket/11474/ m4-patch Regards, Elias Pipping On Mar 5, 2007, at 1:47 PM, Vincent Lefevre wrote: > For those who are in non-UTF-8 locales and use non-English locales > (with messages containing non-ASCII characters, such as accented > characters) and wonder if something gets wrong with these messages: > > On my machine, all these messages suddenly appeared with undecoded > UTF-8 sequences, and I took me some time to find out what the cause > was: the new version of m4 (1.4.8b_1), that supplies a file > /opt/local/lib/charset.alias whose effect is to regard any charset > as UTF-8! I've reported the bug: > > http://trac.macosforge.org/projects/macports/ticket/11474 > > -- > Vincent Lef?vre - Web: > 100% accessible validated (X)HTML - Blog: blog/> > Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS- > Lyon) > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From jmpp at macports.org Mon Mar 5 10:25:29 2007 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue Oct 9 16:40:04 2007 Subject: macports: diff 1.3.2 - 1.4.0 (after paul's variant addition) In-Reply-To: <6B74E468-45B4-494F-9AFE-BB6E74D7DCBE@macports.org> References: <6B74E468-45B4-494F-9AFE-BB6E74D7DCBE@macports.org> Message-ID: <433c9507527fb49f6e80869b6790d057@macports.org> On Feb 26, 2007, at 7:45 AM, Elias Pipping wrote: > Here's the current diff. > > Paul's changes are of course undocumented as of yet. > > Regards, > > Elias Pipping Thanks for the diff Elias, much appreciated! I just read it all and I can assert all changes listed in it between trunk (now 1.4 branch) and the 1.3.2 sources are accounted for (except for Paul's work on the universal variant, which is only in trunk and not in the 1.4 release branch -- adn I don't think we should include it, still too experimental--). Regards,... -jmpp From sal at ri.cmu.edu Mon Mar 5 12:24:41 2007 From: sal at ri.cmu.edu (Salvatore Domenick Desiano) Date: Tue Oct 9 16:40:04 2007 Subject: libgmalloc bug Message-ID: I'm not sure if this is a libgmalloc bug, a gcc bug, or a iostream bug, but I just spent 20 hours boiling a crash in opencv down to ten lines of code. Can somebody else on a MacBook Pro run the following and see if they get a seg fault? Input from a PPC based processor also welcome. If this is a problem, I'm not even sure how to go back and fix the OpenCV port, but if it's not, but at least I'll know I'm working on a real problem. So frustrating! Thanks! -- Sal smile. cat > bug.cpp #include void test () { for(unsigned i = 1; i < 3; ++i ) { std::cout << "HELLO"; } } int main (int argn, char * argv) { test(); return 0; } ^D g++ -Wall -fomit-frame-pointer -O1 -o bug bug.cpp setenv DYLD_INSERT_LIBRARIES /usr/lib/libgmalloc.dylib ./bug -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University From davidm at astro.berkeley.edu Mon Mar 5 13:10:27 2007 From: davidm at astro.berkeley.edu (David MacMahon) Date: Tue Oct 9 16:40:04 2007 Subject: libgmalloc bug In-Reply-To: References: Message-ID: FWIW, my MacBook Pro gets a segfault running your test program with DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib in the environment, too. Dave On Mar 5, 2007, at 12:24 , Salvatore Domenick Desiano wrote: > I'm not sure if this is a libgmalloc bug, a gcc bug, or a iostream > bug, but I just spent 20 hours boiling a crash in opencv down to > ten lines of code. Can somebody else on a MacBook Pro run the > following and see if they get a seg fault? Input from a PPC based > processor also welcome. > > If this is a problem, I'm not even sure how to go back and fix the > OpenCV port, but if it's not, but at least I'll know I'm working on > a real problem. > > So frustrating! > > Thanks! > > -- Sal > smile. > > > cat > bug.cpp > #include > > void test () > { > for(unsigned i = 1; i < 3; ++i ) > { > std::cout << "HELLO"; > } > } > > int main (int argn, char * argv) > { > test(); > return 0; > } > ^D > g++ -Wall -fomit-frame-pointer -O1 -o bug bug.cpp > setenv DYLD_INSERT_LIBRARIES /usr/lib/libgmalloc.dylib > ./bug > > > > -------------- > Salvatore Domenick Desiano > Doctoral Candidate > Robotics Institute > Carnegie Mellon University > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From sal at ri.cmu.edu Mon Mar 5 14:27:57 2007 From: sal at ri.cmu.edu (Salvatore Domenick Desiano) Date: Tue Oct 9 16:40:04 2007 Subject: libgmalloc bug In-Reply-To: References: Message-ID: Excellent. Thank you. -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University On Mon, 5 Mar 2007, David MacMahon wrote: o FWIW, my MacBook Pro gets a segfault running your test program with o DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib in the environment, too. o o Dave o o On Mar 5, 2007, at 12:24 , Salvatore Domenick Desiano wrote: o o > I'm not sure if this is a libgmalloc bug, a gcc bug, or a iostream bug, but o > I just spent 20 hours boiling a crash in opencv down to ten lines of code. o > Can somebody else on a MacBook Pro run the following and see if they get a o > seg fault? Input from a PPC based processor also welcome. o > o > If this is a problem, I'm not even sure how to go back and fix the OpenCV o > port, but if it's not, but at least I'll know I'm working on a real problem. o > o > So frustrating! o > o > Thanks! o > o > -- Sal o > smile. o > o > o > cat > bug.cpp o > #include o > o > void test () o > { o > for(unsigned i = 1; i < 3; ++i ) o > { o > std::cout << "HELLO"; o > } o > } o > o > int main (int argn, char * argv) o > { o > test(); o > return 0; o > } o > ^D o > g++ -Wall -fomit-frame-pointer -O1 -o bug bug.cpp o > setenv DYLD_INSERT_LIBRARIES /usr/lib/libgmalloc.dylib o > ./bug o > o > o > o > -------------- o > Salvatore Domenick Desiano o > Doctoral Candidate o > Robotics Institute o > Carnegie Mellon University o > _______________________________________________ o > macports-dev mailing list o > macports-dev@lists.macosforge.org o > http://lists.macosforge.org/mailman/listinfo/macports-dev o o _______________________________________________ o macports-dev mailing list o macports-dev@lists.macosforge.org o http://lists.macosforge.org/mailman/listinfo/macports-dev o From sal at ri.cmu.edu Mon Mar 5 14:31:32 2007 From: sal at ri.cmu.edu (Salvatore Domenick Desiano) Date: Tue Oct 9 16:40:04 2007 Subject: libgmalloc bug In-Reply-To: References: Message-ID: Thank you for everyone's help. Looks like a confirmed bug, and only on the Pros. Now to figure out what to do with it. -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University On Mon, 5 Mar 2007, Salvatore Domenick Desiano wrote: o Excellent. Thank you. o o -- Sal o smile. o o o -------------- o Salvatore Domenick Desiano o Doctoral Candidate o Robotics Institute o Carnegie Mellon University o o On Mon, 5 Mar 2007, David MacMahon wrote: o o o FWIW, my MacBook Pro gets a segfault running your test program with o o DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib in the environment, too. o o o o Dave o o o o On Mar 5, 2007, at 12:24 , Salvatore Domenick Desiano wrote: o o o o > I'm not sure if this is a libgmalloc bug, a gcc bug, or a iostream bug, but o o > I just spent 20 hours boiling a crash in opencv down to ten lines of code. o o > Can somebody else on a MacBook Pro run the following and see if they get a o o > seg fault? Input from a PPC based processor also welcome. o o > o o > If this is a problem, I'm not even sure how to go back and fix the OpenCV o o > port, but if it's not, but at least I'll know I'm working on a real problem. o o > o o > So frustrating! o o > o o > Thanks! o o > o o > -- Sal o o > smile. o o > o o > o o > cat > bug.cpp o o > #include o o > o o > void test () o o > { o o > for(unsigned i = 1; i < 3; ++i ) o o > { o o > std::cout << "HELLO"; o o > } o o > } o o > o o > int main (int argn, char * argv) o o > { o o > test(); o o > return 0; o o > } o o > ^D o o > g++ -Wall -fomit-frame-pointer -O1 -o bug bug.cpp o o > setenv DYLD_INSERT_LIBRARIES /usr/lib/libgmalloc.dylib o o > ./bug o o > o o > o o > o o > -------------- o o > Salvatore Domenick Desiano o o > Doctoral Candidate o o > Robotics Institute o o > Carnegie Mellon University o o > _______________________________________________ o o > macports-dev mailing list o o > macports-dev@lists.macosforge.org o o > http://lists.macosforge.org/mailman/listinfo/macports-dev o o o o _______________________________________________ o o macports-dev mailing list o o macports-dev@lists.macosforge.org o o http://lists.macosforge.org/mailman/listinfo/macports-dev o o o _______________________________________________ o macports-dev mailing list o macports-dev@lists.macosforge.org o http://lists.macosforge.org/mailman/listinfo/macports-dev o o From ryandesign at macports.org Mon Mar 5 16:10:30 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:04 2007 Subject: sqlobject 0.8.0 In-Reply-To: References: Message-ID: On Mar 5, 2007, at 08:39, Giulio Eulisse wrote: > I've updated the sqlobject port to 0.8.0 in my private area. What's > the preferred way of submitting a patch? Create a ticket in Trac. Attach the patch to the ticket. Then send an email to this list telling us the ticket number so that someone will know to go look at it. > Is there any "port" command that creates the patch for me? I don't think so. If you have checked out your ports tree using Subversion, you can use "svn diff" to get a diff of your changes, and submit that. If not, you can make a copy of your portfile before making changes (cp Portfile Portfile.orig), then make your changes, then get a diff between the original and your changed one (diff -u Portfile.orig Portfile) and submit that. > Is the "port submit" command supported at all? I don't know. I hadn't heard of "port submit" before. From ryandesign at macports.org Mon Mar 5 16:21:26 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:04 2007 Subject: build glib2 universal binary on PPC In-Reply-To: References: Message-ID: <34E383F8-9CF4-478B-ADEC-0E9768901452@macports.org> On Mar 5, 2007, at 06:15, Isaac Huang wrote: > The glib2 configure script makes conclusions about endianness and > atomic operations from host cpu type, and generates headers with such > assumptions inside. I've searched this list and someone said glib2 > needed a patch for this. But I couldn't find this patch, and I also > lack enough knowledge about glib2 to fix it myself. > > Any hint or suggestion is appreciated. > > BTW, I don't have an Intel Mac so I can't build and lipo. Well, building twice and using lipo can be possible on a single Mac, depending on the software. However, that's not the way that MacPorts will attempt to make the universal binary, so it's not relevant here. When I was researching how to compile glib2 universal, I found these instructions: http://code.google.com/p/macfuse/wiki/HOWTO Specifically this part: > If you are on a PowerPC Macintosh, comment out one line in > config.h: // #define G_ATOMIC_POWERPC 1 You do that after you run ./configure, and before you run make. You can make that one change by hand, or use the attached patch. It looks like glib uses some assembly code, so if you're building on a 32-bit PowerPC Mac, it tries to include 32-bit PowerPC assembly even in the Intel executable, which fails. glib doesn't appear to have any 32-bit Intel assembly code which is why the problem shouldn't occur when building a universal binary on a 32-bit Intel Mac. glib does include 64-bit Intel assembly, however, so I wonder if the same problem will occur when attempting to build a universal binary on a 64-bit Intel Mac, like an Xserve. But I don't have access to an Intel Xserve to test it. Jim, you'll probably want to add this patch file to glib2 when building the +universal variant. -------------- next part -------------- A non-text attachment was scrubbed... Name: glib2-config.h-ppc.diff Type: application/octet-stream Size: 314 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070305/caca33f2/glib2-config.h-ppc.obj From ryandesign at macports.org Mon Mar 5 16:24:46 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:04 2007 Subject: How to contribute (was: (no subject)) In-Reply-To: References: Message-ID: <5D97D107-7FFC-4AE9-802A-80CA71484341@macports.org> On Mar 3, 2007, at 20:58, Bob Zimmermann wrote: > If I have multiple interdependent ports that I want to submit, > should I submit them all in a single ticket or just make multiple > tickets, each of which refers to its dependent tickets? I would recommend submitting separate tickets if the ports function independently. This way someone can commit one of them and close that ticket, even if they don't have time to deal with the others at the moment. From ryandesign at macports.org Mon Mar 5 17:27:05 2007 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue Oct 9 16:40:04 2007 Subject: One commit = one change Message-ID: <310E8027-E1A4-4059-B10F-C723A60090D6@macports.org> Dear MacPorts committers, I've seen a lot of commits to portfiles that do more than one thing. For example, a commit that updates the port to a new version, adds a new variant, and changes the indentation of the entire file. This makes it incredibly difficult to see what actually changed, and I would very much appreciate it if we could get into the habit of committing each logical change separately. For example, if you want to change the indentation of the file, do only that, then commit it, with a log message that says you're changing the whitespace. If you want to upgrade to a new version, do just that, and commit it with an appropriate log message. If you want to add a variant, do that, and commit it. This way it is much easier to look through the Subversion log and especially the diffs and see what was changed and why. If you do it all at once in a single commit, especially whitespace changes which like to affect every line, it's very difficult to see what was really changed, and this hinders people like me who are trying to learn more about MacPorts, portfiles, and compiling software in general. Hand in hand with the idea of one change per commit is the idea of accurate log messages. Your Subversion log message should say exactly what you changed. Don't omit anything! Just looking at some of the recent commits to the repository: http://trac.macports.org/projects/macports/changeset/22590 The log message says the port was updated to a new version, but also the maintainer was changed, which IMHO should have been a separate commit. http://trac.macports.org/projects/macports/changeset/22583 This revision updates the port version, changes the maintainer, changes whitespace, and adds the livecheck feature. I would have preferred separate commits, but at least the log does say that all of that was done. http://trac.macports.org/projects/macports/changeset/22543 The log message here says that livecheck was added, but also the software version was increased, which the log didn't say. http://trac.macports.org/projects/macports/changeset/22515 The whitespace of most of the file was changed, the maintainer was changed, the configure args were changed, and some patches were added, though it doesn't say why or what issue they were supposed to fix. I don't mean to be singling anybody out with the above commits; they're just some apt recent examples I found. I also should point out that I do most certainly thank all the MacPorts committers, since I am very much benefitting from all your hard work. But I not only use MacPorts to install software on my machine, I also like reading the portfiles to see how things were done, and especially, looking through the changes that were made to portfiles, and to read about why those changes were done. This is where one-change-per-commit and accurate (and, where appropriate, even detailed) log messages are so important, which is why I bring it up. From blair at orcaware.com Mon Mar 5 17:32:22 2007 From: blair at orcaware.com (Blair Zajac) Date: Tue Oct 9 16:40:04 2007 Subject: One commit = one change In-Reply-To: <310E8027-E1A4-4059-B10F-C723A60090D6@macports.org> References: <310E8027-E1A4-4059-B10F-C723A60090D6@macports.org> Message-ID: <45ECC4A6.2070104@orcaware.com> Ryan Schmidt wrote: > Dear MacPorts committers, > > I've seen a lot of commits to portfiles that do more than one thing. For > example, a commit that updates the port to a new version, adds a new > variant, and changes the indentation of the entire file. This makes it > incredibly difficult to see what actually changed, and I would very much > appreciate it if we could get into the habit of committing each logical > change separately. > > For example, if you want to change the indentation of the file, do only > that, then commit it, with a log message that says you're changing the > whitespace. If you want to upgrade to a new version, do just that, and > commit it with an appropriate log message. If you want to add a variant, > do that, and commit it. This way it is much easier to look through the > Subversion log and especially the diffs and see what was changed and > why. If you do it all at once in a single commit, especially whitespace > changes which like to affect every line, it's very difficult to see what > was really changed, and this hinders people like me who are trying to > learn more about MacPorts, portfiles, and compiling software in general. > > Hand in hand with the idea of one change per commit is the idea of > accurate log messages. Your Subversion log message should say exactly > what you changed. Don't omit anything! I totally agree on separate commits for logical changes in general, however, I'm of the mind that only whitespace change commits should be separate. I don't see the need to have separate commits for a new version and a new variant, after all, the developer may have tested them together, and testing them separately may be more work. Now if there's a complicated update and there's also other things that change, then yes, split them up. Regards, Blair From vincent-opdarw at vinc17.org Mon Mar 5 18:28:11 2007 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue Oct 9 16:40:04 2007 Subject: One commit = one change In-Reply-To: <310E8027-E1A4-4059-B10F-C723A60090D6@macports.org> References: <310E8027-E1A4-4059-B10F-C723A60090D6@macports.org> Message-ID: <20070306022811.GJ1538@prunille.vinc17.org> On 2007-03-05 19:27:05 -0600, Ryan Schmidt wrote: > For example, if you want to change the indentation of the file, do > only that, then commit it, with a log message that says you're > changing the whitespace. Some changes will also change the indentation as a consequence (well, perhaps more rarely in Portfiles than in C code...). That's why diff (and Subversion, via -x) has the -w option to ignore all white space change in diffs. > http://trac.macports.org/projects/macports/changeset/22515 > > The whitespace of most of the file was changed, the maintainer was > changed, the configure args were changed, and some patches were > added, You can see it more or less as a complete rewrite. There were outdated things and options that probably should never been used (but no comments saying why they were added). > though it doesn't say why or what issue they were supposed to > fix. Just look at the MPFR web site. The full description of what the patches fix would be a bit too much for the log file (IMHO, MacPorts lacks ChangeLog support). BTW, what homepage should be? The home page of the software or the home page of the particular version of the software? -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From yves at macports.org Mon Mar 5 19:22:35 2007 From: yves at macports.org (Yves de Champlain) Date: Tue Oct 9 16:40:04 2007 Subject: One commit = one change In-Reply-To: <310E8027-E1A4-4059-B10F-C723A60090D6@macports.org> References: <310E8027-E1A4-4059-B10F-C723A60090D6@macports.org> Message-ID: Le 07-03-05 ? 20:27, Ryan Schmidt a ?crit : > Dear MacPorts committers, > > I've seen a lot of commits to portfiles that do more than one > thing. For example, a commit that updates the port to a new > version, adds a new variant, and changes the indentation of the > entire file. This makes it incredibly difficult to see what > actually changed, and I would very much appreciate it if we could > get into the habit of committing each logical change separately. > > For example, if you want to change the indentation of the file, do > only that, then commit it, with a log message that says you're > changing the whitespace. If you want to upgrade to a new version, > do just that, and commit it with an appropriate log message. If you > want to add a variant, do that, and commit it. This way it is much > easier to look through the Subversion log and especially the diffs > and see what was changed and why. If you do it all at once in a > single commit, especially whitespace changes which like to affect > every line, it's very difficult to see what was really changed, and > this hinders people like me who are trying to learn more about > MacPorts, portfiles, and compiling software in general. > > Hand in hand with the idea of one change per commit is the idea of > accurate log messages. Your Subversion log message should say > exactly what you changed. Don't omit anything! Hi This sure makes sense, but it does not really fit with how a Portfile is worked. For example, I recently updated e17 stuff and had to change versions, dependencies, configure environment and arguments, and I finally decided to also opt in as maintainer. But there is no "logical order" to do this. 1 commit / change would have meant artificially creating many versions of the Portfiles afterwards with a few changes in each one. However, it is true log messages should be very clear as to what is happening. i.e. bump to version ... change configure.env ... change deps ... change configure.args ... change maintainer ... Lots of changes, but everything is written clearly. yves From iclaymore at gmail.com Mon Mar 5 21:06:34 2007 From: iclaymore at gmail.com (Isaac Huang) Date: Tue Oct 9 16:40:04 2007 Subject: build glib2 universal binary on PPC In-Reply-To: <34E383F8-9CF4-478B-ADEC-0E9768901452@macports.org> References: <34E383F8-9CF4-478B-ADEC-0E9768901452@macports.org> Message-ID: On 3/6/07, Ryan Schmidt wrote: > > On Mar 5, 2007, at 06:15, Isaac Huang wrote: > > > The glib2 configure script makes conclusions about endianness and > > atomic operations from host cpu type, and generates headers with such > > assumptions inside. I've searched this list and someone said glib2 > > needed a patch for this. But I couldn't find this patch, and I also > > lack enough knowledge about glib2 to fix it myself. > > > > Any hint or suggestion is appreciated. > > > > BTW, I don't have an Intel Mac so I can't build and lipo. > > Well, building twice and using lipo can be possible on a single Mac, > depending on the software. However, that's not the way that MacPorts > will attempt to make the universal binary, so it's not relevant here. > > > When I was researching how to compile glib2 universal, I found these > instructions: > > http://code.google.com/p/macfuse/wiki/HOWTO > > Specifically this part: > > > If you are on a PowerPC Macintosh, comment out one line in > > config.h: // #define G_ATOMIC_POWERPC 1 I found this too, but I don't think that's sufficient because there's still the endianness problem. In glibconfig.h for ppc we should have: ...... #define GLONG_TO_BE(val) ((glong) GINT32_TO_BE (val)) #define GULONG_TO_BE(val) ((gulong) GUINT32_TO_BE (val)) #define GINT_TO_LE(val) ((gint) GINT32_TO_LE (val)) #define GUINT_TO_LE(val) ((guint) GUINT32_TO_LE (val)) #define GINT_TO_BE(val) ((gint) GINT32_TO_BE (val)) #define GUINT_TO_BE(val) ((guint) GUINT32_TO_BE (val)) #define G_BYTE_ORDER G_BIG_ENDIAN If we just get rid of G_ATOMIC_POWERPC, glib2 compiles OK on ppc, but the resulting glibconfig.h will assume G_BIG_ENDIAN which won't work for compiling for i386. Furthermore, I've discovered this weird thing with glib2 configure script on my ppc: ppc/glib-2.12.9 [1044:1]% CFLAGS='-I/opt/local/include' LDFLAGS='-L/opt/local/lib' ./configure ...... checking whether byte ordering is bigendian... yes ...... Which is correct, _but_: CFLAGS="-O3 -funroll-loops -fstrict-aliasing -I/opt/local/include -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk" LDFLAGS="-L/opt/local/lib -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk" ./configure --prefix=/usr/local --disable-dependency-tracking ...... checking whether byte ordering is bigendian... no ...... So whenever "-arch ppc -arch i386" is specified the configure script believes that my ppc iBook isn't bigendian - glib2 still builds OK, but some programs will definitely break. > You do that after you run ./configure, and before you run make. You > can make that one change by hand, or use the attached patch. > > It looks like glib uses some assembly code, so if you're building on > a 32-bit PowerPC Mac, it tries to include 32-bit PowerPC assembly > even in the Intel executable, which fails. > > glib doesn't appear to have any 32-bit Intel assembly code which is > why the problem shouldn't occur when building a universal binary on a > 32-bit Intel Mac. > > glib does include 64-bit Intel assembly, however, so I wonder if the > same problem will occur when attempting to build a universal binary > on a 64-bit Intel Mac, like an Xserve. But I don't have access to an > Intel Xserve to test it. > > > Jim, you'll probably want to add this patch file to glib2 when > building the +universal variant. > > > -- Regards, Isaac () ascii ribbon campaign - against html e-mail /\ - against microsoft attachments From davidm at astro.berkeley.edu Mon Mar 5 21:19:14 2007 From: davidm at astro.berkeley.edu (David MacMahon) Date: Tue Oct 9 16:40:04 2007 Subject: One commit = one change In-Reply-To: <310E8027-E1A4-4059-B10F-C723A60090D6@macports.org> References: <310E8027-E1A4-4059-B10F-C723A60090D6@macports.org> Message-ID: <085BD310-3098-4966-8232-5421CDED4E7C@astro.berkeley.edu> On Mar 5, 2007, at 17:27 , Ryan Schmidt wrote: > I would very much appreciate it if we could get into the habit of > committing each logical change separately. That might work OK if the committer is the person making the changes, but if non-committers are to submit patches to Portfiles and patches (yes, patches to patches) via the wiki with one change per patch, then that creates a lot of extra work for the person making the patches and the person applying/committing the patches. It also leaves more room for error (forgotten patch, patches applied in wrong order, etc) than if the change (or changes) is (are) in one patch file. > Hand in hand with the idea of one change per commit is the idea of > accurate log messages. Your Subversion log message should say > exactly what you changed. Don't omit anything! While I agree in principle, there is a fine balance to be maintained between completeness and conciseness. IMHO, the log message should be a comprehensive summary of what was done in the changeset, but not a verbose description that essentially duplicates the info that "svn diff" can provide. Just my two cents' worth, Dave From pipping at macports.org Mon Mar 5 22:00:35 2007 From: pipping at macports.org (Elias Pipping) Date: Tue Oct 9 16:40:04 2007 Subject: build glib2 universal binary on PPC In-Reply-To: References: <34E383F8-9CF4-478B-ADEC-0E9768901452@macports.org> Message-ID: I hate to break it to you but I guess glib2 will have to go to the same steps as openssl: 0.) configure 1.) build for ppc 1.1) modify the makefile if needed (make sure BIG ENDIAN is used, comment out assembler inclusion) 1.2) build for ppc 1.3) backup the files from the first run to a temporary location 1.4) cleanup the worksrcpath 2.) build for i386 ... 3.) lipo the results of both runs from the temporary locations together and stage to destroot see http://svn.macports.org/repository/macports/trunk/dports/devel/ openssl/Portfile for an example and http://paste.lisp.org/display/37714,1/raw for a very preliminary idea of what a groupfile might look like. Regards, Elias Pipping On Mar 6, 2007, at 6:06 AM, Isaac Huang wrote: > On 3/6/07, Ryan Schmidt wrote: >> >> On Mar 5, 2007, at 06:15, Isaac Huang wrote: >> >> > The glib2 configure script makes conclusions about endianness and >> > atomic operations from host cpu type, and generates headers with >> such >> > assumptions inside. I've searched this list and someone said glib2 >> > needed a patch for this. But I couldn't find this patch, and I also >> > lack enough knowledge about glib2 to fix it myself. >> > >> > Any hint or suggestion is appreciated. >> > >> > BTW, I don't have an Intel Mac so I can't build and lipo. >> >> Well, building twice and using lipo can be possible on a single Mac, >> depending on the software. However, that's not the way that MacPorts >> will attempt to make the universal binary, so it's not relevant here. >> >> >> When I was researching how to compile glib2 universal, I found these >> instructions: >> >> http://code.google.com/p/macfuse/wiki/HOWTO >> >> Specifically this part: >> >> > If you are on a PowerPC Macintosh, comment out one line in >> > config.h: // #define G_ATOMIC_POWERPC 1 > > I found this too, but I don't think that's sufficient because there's > still the endianness problem. In glibconfig.h for ppc we should have: > ...... > #define GLONG_TO_BE(val) ((glong) GINT32_TO_BE (val)) > #define GULONG_TO_BE(val) ((gulong) GUINT32_TO_BE (val)) > #define GINT_TO_LE(val) ((gint) GINT32_TO_LE (val)) > #define GUINT_TO_LE(val) ((guint) GUINT32_TO_LE (val)) > #define GINT_TO_BE(val) ((gint) GINT32_TO_BE (val)) > #define GUINT_TO_BE(val) ((guint) GUINT32_TO_BE (val)) > #define G_BYTE_ORDER G_BIG_ENDIAN > > If we just get rid of G_ATOMIC_POWERPC, glib2 compiles OK on ppc, but > the resulting glibconfig.h will assume G_BIG_ENDIAN which won't work > for compiling for i386. > > Furthermore, I've discovered this weird thing with glib2 configure > script on my ppc: > ppc/glib-2.12.9 [1044:1]% CFLAGS='-I/opt/local/include' > LDFLAGS='-L/opt/local/lib' ./configure > ...... > checking whether byte ordering is bigendian... yes > ...... > > Which is correct, _but_: > CFLAGS="-O3 -funroll-loops -fstrict-aliasing -I/opt/local/include > -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk" > LDFLAGS="-L/opt/local/lib -arch ppc -arch i386 -isysroot > /Developer/SDKs/MacOSX10.4u.sdk" ./configure --prefix=/usr/local > --disable-dependency-tracking > ...... > checking whether byte ordering is bigendian... no > ...... > > So whenever "-arch ppc -arch i386" is specified the configure script > believes that my ppc iBook isn't bigendian - glib2 still builds OK, > but some programs will definitely break. > >> You do that after you run ./configure, and before you run make. You >> can make that one change by hand, or use the attached patch. >> >> It looks like glib uses some assembly code, so if you're building on >> a 32-bit PowerPC Mac, it tries to include 32-bit PowerPC assembly >> even in the Intel executable, which fails. >> >> glib doesn't appear to have any 32-bit Intel assembly code which is >> why the problem shouldn't occur when building a universal binary on a >> 32-bit Intel Mac. >> >> glib does include 64-bit Intel assembly, however, so I wonder if the >> same problem will occur when attempting to build a universal binary >> on a 64-bit Intel Mac, like an Xserve. But I don't have access to an >> Intel Xserve to test it. >> >> >> Jim, you'll probably want to add this patch file to glib2 when >> building the +universal variant. >> >> >> > > > -- > > Regards, Isaac > () ascii ribbon campaign - against html e-mail > /\