From afb at macports.org Sat Mar 1 01:07:04 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sat, 1 Mar 2008 10:07:04 +0100 Subject: Google SoC 2008 In-Reply-To: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> Message-ID: James Berry wrote: > I'm writing to attempt to gauge interest in whether and how MacPorts > should participate in Google Summer of Code (GSoC) for 2008. See > http://code.google.com/soc/2008/ > . There's also the old MacPorts Summer of Code pages from GSoc 2007: http://trac.macports.org/projects/macports/wiki/SummerOfCode And there is the old organization page from last years 3 projects: http://code.google.com/soc/2007/macports/about.html > You might be inclined to address any of the following questions: > > - Do you feel MacPorts should participate in GSoC 2008? If there are any mentors available to participate, sure why not... Though I am not sure what eventually came out of GSoc 2007, even if I did see the new "merge.rb" and "port trace" and "registry2.0" ?? i.e. - Automate and beautify creation of universal binaries - Port isolation while building - Dependencies - New Repository Backend Maybe one of last years mentors (or students) can share thoughts ? > - Are there particular MacPorts projects you'd like to suggest? I think the following would be nice to have: - Binaries / Packages ("Task 4" in Wiki) Using archives (tgz/tbz/tlz) would probably be easiest to implement, but packages (pkg/deb/rpm) would be the most useful in my opinion. For a more ambitious project, re-uniting the backend so that it can work with both ports (source) and packages (binary) would be cool... - Graphical user interface ("Task 5" in Wiki) Completing dp-cocoa/dpgui/PortsManager/Pallet/etc to provide an open source user interface for managing ports would make it more available. The ambitious is making an Objective-C framework and a real application, but a nice looking front-end implemented by scripting is not too bad... We've also here recently talked about these: - Root privileges ("Task 7" in Wiki) - Mirroring ("Task 9" in Wiki) Following was done in MacPorts 1.6.0 already: - Lint ("Task 10" in Wiki) - Documentation and Website ("Task A2" in Wiki) Cleaning up the old ports tree (including python and ruby) and taking care of the large amount of tickets is also "nice to have" of course, but not really something for such a student summer project (I think) ? But, for all you bored students that don't get into a SoC program... ;-) --anders From ebgssth at gmail.com Sat Mar 1 05:30:14 2008 From: ebgssth at gmail.com (js) Date: Sat, 1 Mar 2008 22:30:14 +0900 Subject: RFC: Changing apache2 to install its files to /opt/local/ instead of /opt/local/apache2 Message-ID: Hi James, As you know, current apache2 port uses /opt/local/apache2 as a prefix. This is a bit different from other ports using /opt/local as a prefix. This problem always confused me, so I think it would be nice if it changed to use the same prefix. This change, however, would need a lot of work, like changing paths inside the httpd.conf, but if you'd like this idea, I'd be willing to help to get it done. Could you please give me some comments/suggestions on this? Thanks. From narf_tm at macports.org Sat Mar 1 06:56:00 2008 From: narf_tm at macports.org (Matthew Ross) Date: Sat, 1 Mar 2008 08:56:00 -0600 Subject: RFC: Changing apache2 to install its files to /opt/local/ instead of /opt/local/apache2 In-Reply-To: References: Message-ID: <4F6FF124-A316-4791-9CAF-9D53AA156A65@macports.org> I have been wanting this for a long time. If I were you, I would look at patching the config.layout with a new layout. You can then configure with --enable-layout=LAYOUT. I believe this takes care of the paths in the default httpd.conf file for you. On Mar 1, 2008, at 7:30 AM, js wrote: > Hi James, > > As you know, current apache2 port uses /opt/local/apache2 as a prefix. > This is a bit different from other ports using /opt/local as a prefix. > This problem always confused me, so I think it would be nice if > it changed to use the same prefix. > This change, however, would need a lot of work, > like changing paths inside the httpd.conf, > but if you'd like this idea, I'd be willing to help to get it done. > > Could you please give me some comments/suggestions on this? > > Thanks. > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From dluke at geeklair.net Sat Mar 1 08:15:29 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Sat, 1 Mar 2008 11:15:29 -0500 Subject: Google SoC 2008 In-Reply-To: References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> Message-ID: <32C67EF9-140B-4134-A2ED-EC58FC929001@geeklair.net> On Mar 1, 2008, at 4:07 AM, Anders F Bj?rklund wrote: > - Binaries / Packages ("Task 4" in Wiki) > > Using archives (tgz/tbz/tlz) would probably be easiest to implement, > but packages (pkg/deb/rpm) would be the most useful in my opinion. How would this be different from the dp-light work? (I believe that that was working and several people were using it). So, it seems to me like it will take more than just a working patch to get buy-in as the way forward for Macports. Historically, Macports rejected deb/rpm as package formats because we wanted tight integration with Apple's package format (so we could use the installer receipts to check for dependencies, for example). There was even some talk of a new apple package format (apkg) that we would start using. -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080301/2944fa25/attachment.bin From afb at macports.org Sat Mar 1 09:05:26 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sat, 1 Mar 2008 18:05:26 +0100 Subject: Google SoC 2008 In-Reply-To: <32C67EF9-140B-4134-A2ED-EC58FC929001@geeklair.net> References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> <32C67EF9-140B-4134-A2ED-EC58FC929001@geeklair.net> Message-ID: <4250FB0F-4B81-4AE6-B2B8-196DCDADAD4A@macports.org> Daniel J. Luke wrote: >> - Binaries / Packages ("Task 4" in Wiki) >> >> Using archives (tgz/tbz/tlz) would probably be easiest to implement, >> but packages (pkg/deb/rpm) would be the most useful in my opinion. > > How would this be different from the dp-light work? (I believe that > that was working and several people were using it). So, it seems to > me like it will take more than just a working patch to get buy-in > as the way forward for Macports. Just tossing out SoC ideas at this point... (i.e. "I don't know") Not familiar with the dp-light work either, as I haven't used it. Just now that users want binary packages rather than source ports. And those two seem to be the major paths to offering such a thing ? > Historically, Macports rejected deb/rpm as package formats because > we wanted tight integration with Apple's package format (so we > could use the installer receipts to check for dependencies, for > example). There was even some talk of a new apple package format > (apkg) that we would start using. Both Leopard and RPM5 now supports the XAR format for packages, even though they do use different "package database" systems. One planned feature for rpm-5.1 is to have the same .xar file work as a package both for Installer.app and for RPM.app too... --anders From ram at macports.org Sat Mar 1 20:21:47 2008 From: ram at macports.org (Adam Mercer) Date: Sat, 1 Mar 2008 23:21:47 -0500 Subject: Checking if a given port is installed in pre-fetch Message-ID: <799406d60803012021s508d4e9pcddfce77263cda05@mail.gmail.com> Hi Is there a way that I can check if a given port is installed in a pre-fetch phase and display a message, e.g. using ui_msg, if the port is installed? Cheers Adam From ryandesign at macports.org Sat Mar 1 22:57:53 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 2 Mar 2008 00:57:53 -0600 Subject: RFC: Changing apache2 to install its files to /opt/local/ instead of /opt/local/apache2 In-Reply-To: <4F6FF124-A316-4791-9CAF-9D53AA156A65@macports.org> References: <4F6FF124-A316-4791-9CAF-9D53AA156A65@macports.org> Message-ID: On Mar 1, 2008, at 08:56, Matthew Ross wrote: > On Mar 1, 2008, at 7:30 AM, js wrote: > >> As you know, current apache2 port uses /opt/local/apache2 as a >> prefix. >> This is a bit different from other ports using /opt/local as a >> prefix. >> This problem always confused me, so I think it would be nice if >> it changed to use the same prefix. >> This change, however, would need a lot of work, >> like changing paths inside the httpd.conf, >> but if you'd like this idea, I'd be willing to help to get it done. >> >> Could you please give me some comments/suggestions on this? > > I have been wanting this for a long time. > If I were you, I would look at patching the config.layout with a new > layout. > You can then configure with --enable-layout=LAYOUT. > I believe this takes care of the paths in the default httpd.conf file > for you. Before anyone does anything, I'd like to know why you want this change. Let's figure out the pros and cons. A con would be that all ports that depend on apache2 would have to be checked. They may have hard-coded the location where apache2 puts its files now. Also, all existing users of apache2 would have to move their httpd.conf files to the new location, and maybe update paths in it. Anyone who just runs "sudo port upgrade apache2" will find their web server suddenly broken. Note that the apache port has a variant "apache_layout" which puts files in a different place than usual. I think this is problematic because some ports that depend on apache assume that the apache port is installed either with or without this variant, and don't work in the other case. There should be no such variant; the port should just install files in a single place. The apache, apache2 and apache20 ports should be kept in sync if possible. The apache port should be able to coexist with either the apache2 or the apache20 port. Currently, they cannot coexist: $ sudo port activate apache Password: ---> Activating apache Error: port activate failed: Image error: /opt/local/share/man/man1/ dbmmanage.1.gz is being used by the active apache2 port. Please deactivate this port first, or use the -f flag to force the activation. $ From ebgssth at gmail.com Sun Mar 2 05:01:14 2008 From: ebgssth at gmail.com (js) Date: Sun, 2 Mar 2008 22:01:14 +0900 Subject: RFC: Changing apache2 to install its files to /opt/local/ instead of /opt/local/apache2 In-Reply-To: References: <4F6FF124-A316-4791-9CAF-9D53AA156A65@macports.org> Message-ID: > Before anyone does anything, I'd like to know why you want this > change. Consistency, period. When I upgraded from apache1 to apache2, it surprized me that there is no conf dir in /opt/local/etc and apachectl is in /opt/local/apache2/bin/. > Let's figure out the pros and cons. > > A con would be that all ports that depend on apache2 would have to be > checked. They may have hard-coded the location where apache2 puts its > files now. > > Also, all existing users of apache2 would have to move their > httpd.conf files to the new location, and maybe update paths in it. > Anyone who just runs "sudo port upgrade apache2" will find their web > server suddenly broken. Agreed, but an easy migration script that handling this job would be ease the impact. > Note that the apache port has a variant "apache_layout" which puts > files in a different place than usual. I think this is problematic > because some ports that depend on apache assume that the apache port > is installed either with or without this variant, and don't work in > the other case. There should be no such variant; the port should just > install files in a single place. I think options are good. I remember once you disagreed this idea, but this is not a point of discussion. Let's skip this. > The apache, apache2 and apache20 ports should be kept in sync if > possible. > > The apache port should be able to coexist with either the apache2 or > the apache20 port. Currently, they cannot coexist: > > $ sudo port activate apache > Password: > ---> Activating apache > Error: port activate failed: Image error: /opt/local/share/man/man1/ > dbmmanage.1.gz is being used by the active apache2 port. Please > deactivate this port first, or use the -f flag to force the activation. > $ suffix would fix this issue. From raimue at macports.org Sun Mar 2 07:44:53 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 02 Mar 2008 16:44:53 +0100 Subject: RFC: Changing apache2 to install its files to /opt/local/ instead of /opt/local/apache2 In-Reply-To: References: <4F6FF124-A316-4791-9CAF-9D53AA156A65@macports.org> Message-ID: <47CACB75.1070504@macports.org> js wrote: >> Before anyone does anything, I'd like to know why you want this >> change. > > Consistency, period. > When I upgraded from apache1 to apache2, it surprized me that > there is no conf dir in /opt/local/etc and apachectl is in > /opt/local/apache2/bin/. I agree. Even more, the current apache2 layout violates the mtree which should be avoided. >> Let's figure out the pros and cons. >> >> A con would be that all ports that depend on apache2 would have to be >> checked. They may have hard-coded the location where apache2 puts its >> files now. >> >> Also, all existing users of apache2 would have to move their >> httpd.conf files to the new location, and maybe update paths in it. >> Anyone who just runs "sudo port upgrade apache2" will find their web >> server suddenly broken. > > Agreed, but an easy migration script that handling this job would be ease > the impact. Also present some ui_msg how to do it. Isn't it just a cp from the old to the new location? Also, users have always been responsible for the config themself as they have to copy it from httpd.conf.sample to httpd.conf at the moment. Even if it is "suddenly broken", they can go back by using port deactivate/activate as described in the guide. >> Note that the apache port has a variant "apache_layout" which puts >> files in a different place than usual. I think this is problematic >> because some ports that depend on apache assume that the apache port >> is installed either with or without this variant, and don't work in >> the other case. There should be no such variant; the port should just >> install files in a single place. > > I think options are good. I remember once you disagreed this idea, > but this is not a point of discussion. Let's skip this. File locations should not be changed by variants. apache +apache_layout violates the mtree and does not even declare that. >> The apache, apache2 and apache20 ports should be kept in sync if >> possible. >> >> The apache port should be able to coexist with either the apache2 or >> the apache20 port. Currently, they cannot coexist: >> >> $ sudo port activate apache >> Password: >> ---> Activating apache >> Error: port activate failed: Image error: /opt/local/share/man/man1/ >> dbmmanage.1.gz is being used by the active apache2 port. Please >> deactivate this port first, or use the -f flag to force the activation. >> $ > > suffix would fix this issue. Do you mean dbmmanage.1{apache,apache20,apache2}.gz? That would be good. Then you can read the man pages by using e.g. man 1apache2 dbmmanage. Rainer From dluke at geeklair.net Sun Mar 2 09:16:59 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Sun, 2 Mar 2008 12:16:59 -0500 Subject: Checking if a given port is installed in pre-fetch In-Reply-To: <799406d60803012021s508d4e9pcddfce77263cda05@mail.gmail.com> References: <799406d60803012021s508d4e9pcddfce77263cda05@mail.gmail.com> Message-ID: <70DDFF47-40AF-4ECD-B585-F49E45B890C8@geeklair.net> On Mar 1, 2008, at 11:21 PM, Adam Mercer wrote: > Is there a way that I can check if a given port is installed in a > pre-fetch phase and display a message, e.g. using ui_msg, if the port > is installed? You can do almost anything from within a portfile, but there are lots of things that you maybe shouldn't. What are you trying to accomplish? -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From ram at macports.org Sun Mar 2 11:09:33 2008 From: ram at macports.org (Adam Mercer) Date: Sun, 2 Mar 2008 14:09:33 -0500 Subject: Checking if a given port is installed in pre-fetch In-Reply-To: <70DDFF47-40AF-4ECD-B585-F49E45B890C8@geeklair.net> References: <799406d60803012021s508d4e9pcddfce77263cda05@mail.gmail.com> <70DDFF47-40AF-4ECD-B585-F49E45B890C8@geeklair.net> Message-ID: <799406d60803021109h1eeae683ree85158d305feb17@mail.gmail.com> On Sun, Mar 2, 2008 at 12:16 PM, Daniel J. Luke wrote: > You can do almost anything from within a portfile, but there are lots > of things that you maybe shouldn't. > > What are you trying to accomplish? I want to upgrade the science/geos port to 3.0.0 but matplotlib-basemap requires geos-2.2.3 and will not work with geos-3.0.0. Unfortunately it doesn't appear possible to install both geos-2.2.3 and geos-3.0.0 at the the same time, so I was wondering if there was a way that I could make a port for each version and mark them as conflicting? Cheers Adam From opendarwin.org at darkart.com Sun Mar 2 15:43:26 2008 From: opendarwin.org at darkart.com (Eric Hall) Date: Sun, 2 Mar 2008 23:43:26 +0000 Subject: Google SoC 2008 In-Reply-To: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> Message-ID: <20080302234326.GD94215@darkart.com> On Fri, Feb 29, 2008 at 03:48:56PM -0800, James Berry wrote: > I'm writing to attempt to gauge interest in whether and how MacPorts > should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ > . > > You might be inclined to address any of the following questions: > > - Do you feel MacPorts should participate in GSoC 2008? > - Are there particular MacPorts projects you'd like to suggest? I'd like to see dependencies that include variants. -eric From randall.h.wood at alexandriasoftware.com Sun Mar 2 16:58:34 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sun, 2 Mar 2008 19:58:34 -0500 Subject: Google SoC 2008 In-Reply-To: <20080302234326.GD94215@darkart.com> References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> <20080302234326.GD94215@darkart.com> Message-ID: On 3/2/08, Eric Hall wrote: > On Fri, Feb 29, 2008 at 03:48:56PM -0800, James Berry wrote: > > I'm writing to attempt to gauge interest in whether and how MacPorts > > should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ > > . > > > > You might be inclined to address any of the following questions: > > > > - Do you feel MacPorts should participate in GSoC 2008? > > - Are there particular MacPorts projects you'd like to suggest? > I would like to see MacPorts use RPM for its installation database instead of whatever we have now. -- Randall Wood randall.h.wood at alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From blair at orcaware.com Sun Mar 2 18:39:02 2008 From: blair at orcaware.com (Blair Zajac) Date: Sun, 02 Mar 2008 18:39:02 -0800 Subject: Google SoC 2008 In-Reply-To: References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> <20080302234326.GD94215@darkart.com> Message-ID: <47CB64C6.6040408@orcaware.com> Randall Wood wrote: > On 3/2/08, Eric Hall wrote: >> On Fri, Feb 29, 2008 at 03:48:56PM -0800, James Berry wrote: >> > I'm writing to attempt to gauge interest in whether and how MacPorts >> > should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ >> > . >> > >> > You might be inclined to address any of the following questions: >> > >> > - Do you feel MacPorts should participate in GSoC 2008? >> > - Are there particular MacPorts projects you'd like to suggest? >> > I would like to see MacPorts use RPM for its installation database > instead of whatever we have now. I would rather see dpkg instead of RPM, but it's a little bike sheddy. BTW, Fink uses dpkg also. Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies Subversion training, consulting and support http://www.orcaware.com/svn/ From jkh at apple.com Sun Mar 2 19:58:09 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Sun, 2 Mar 2008 19:58:09 -0800 Subject: Google SoC 2008 In-Reply-To: References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> <20080302234326.GD94215@darkart.com> Message-ID: <0D70FD0D-5A5D-4F79-945F-C55D58DF43B1@apple.com> On Mar 2, 2008, at 4:58 PM, Randall Wood wrote: > I would like to see MacPorts use RPM for its installation database > instead of whatever we have now. We don't have anything now. We've also tried to use rpm at various times in the past, but the impedance matching requirements have always proved problematic (rpm expects its packages to be built via srpms and dependencies to be handled in a very specific way, just to name two of many). My personal opinion is that we should start building xar files. For the first cut, they can be essentially dumb and we can focus on extracting enough dependency information from them to do package dependency tracking. That's pretty straight-forward and quite achievable with existing technology. For the second cut, we can embed a minimal macports runtime (in the form of a universal dylib and some collection of tcl files) in each xarball, allowing us to run the same install/post-install/activate/ post-activate routines at install time. A properly formed package represents, after all, little more than everything up to and including the destroot phase, archived up. It's what to do with the specialized actions (add user foo, present message bar to the user, etc - just grep through dports looking for post-install to get a good feel for how varied the landscape currently is) and how to provide the same activate/deactivate metaphor for packages that has always held us up Once we get to that stage, we can behead the current installation procedures for macports and turn that into pkg install actions. Then macports just needs to carry the load up to the destroot / package stage and then hand things off to the package system for the install/ activate heavy lifting. But, we also need to crawl before we try to run, which is why I think simple archives (which work for all the "simple" ports) is the right place to start. Excellent SoC project! - Jordan From randall.h.wood at alexandriasoftware.com Mon Mar 3 02:12:35 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Mon, 3 Mar 2008 05:12:35 -0500 Subject: Google SoC 2008 In-Reply-To: <0D70FD0D-5A5D-4F79-945F-C55D58DF43B1@apple.com> References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> <20080302234326.GD94215@darkart.com> <0D70FD0D-5A5D-4F79-945F-C55D58DF43B1@apple.com> Message-ID: On 3/2/08, Jordan K. Hubbard wrote: > > On Mar 2, 2008, at 4:58 PM, Randall Wood wrote: > > > I would like to see MacPorts use RPM for its installation database > > instead of whatever we have now. > > > We don't have anything now. We've also tried to use rpm at various > times in the past, but the impedance matching requirements have always > proved problematic (rpm expects its packages to be built via srpms and > dependencies to be handled in a very specific way, just to name two of > many). > > My personal opinion is that we should start building xar files. > > For the first cut, they can be essentially dumb and we can focus on > extracting enough dependency information from them to do package > dependency tracking. That's pretty straight-forward and quite > achievable with existing technology. > > For the second cut, we can embed a minimal macports runtime (in the > form of a universal dylib and some collection of tcl files) in each > xarball, allowing us to run the same install/post-install/activate/ > post-activate routines at install time. A properly formed package > represents, after all, little more than everything up to and including > the destroot phase, archived up. It's what to do with the specialized > actions (add user foo, present message bar to the user, etc - just > grep through dports looking for post-install to get a good feel for > how varied the landscape currently is) and how to provide the same > activate/deactivate metaphor for packages that has always held us up > > Once we get to that stage, we can behead the current installation > procedures for macports and turn that into pkg install actions. Then > macports just needs to carry the load up to the destroot / package > stage and then hand things off to the package system for the install/ > activate heavy lifting. But, we also need to crawl before we try to > run, which is why I think simple archives (which work for all the > "simple" ports) is the right place to start. Excellent SoC project! Whichever the student feels like then...I don't really care except that I am becoming more and more familiar with RPM as I now work in a shop[1] that uses Red Hat Enterprise Linux 5 as the basis for all its products. As far as the complexity of RPM goes, I think that a lot of the dp-light work is still hanging around and may be reusable, but it may simply be a good idea for port to do a Portfile to .spec file transform (and maybe build the SRPM) and then hand everything off to an RPM-based configure/build/distribute/install process. I know that a lot of the GTK/GNOME ports already build the .spec files for creating the [S]RPMs anyway. [1] Trusted Computer Solutions (http://www.trustedcs.com) -- Randall Wood randall.h.wood at alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From dluke at geeklair.net Mon Mar 3 07:05:53 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon, 3 Mar 2008 10:05:53 -0500 Subject: Google SoC 2008 In-Reply-To: <0D70FD0D-5A5D-4F79-945F-C55D58DF43B1@apple.com> References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> <20080302234326.GD94215@darkart.com> <0D70FD0D-5A5D-4F79-945F-C55D58DF43B1@apple.com> Message-ID: On Mar 2, 2008, at 10:58 PM, Jordan K. Hubbard wrote: > On Mar 2, 2008, at 4:58 PM, Randall Wood wrote: > >> I would like to see MacPorts use RPM for its installation database >> instead of whatever we have now. > > We don't have anything now. We've also tried to use rpm at various > times in the past, but the impedance matching requirements have always > proved problematic (rpm expects its packages to be built via srpms and > dependencies to be handled in a very specific way, just to name two of > many). > > My personal opinion is that we should start building xar files. You already can build xar files with archive mode (although I don't believe that it supports any of xar's more interesting features). > For the second cut, we can embed a minimal macports runtime (in the > form of a universal dylib and some collection of tcl files) in each > xarball, allowing us to run the same install/post-install/activate/ > post-activate routines at install time. I think landon tried this a long time ago and it ended up that the 'minimal' runtime was basically all of macports. As an alternative, if we either keep the portfile api relatively stable and/or make use of our ability to version the portsystem we may be able to make things work (most of the time) by simply requiring macports to be installed on the system that wants to use the binary xar package. The archives built now already contain a copy of the portfile used to generate them (although they're currently not used anywhere). > how to provide the same > activate/deactivate metaphor for packages that has always held us up Given how the activate/deactivate system works now, it offers no real advantage over having binary packages. (I know, you want to have the dependencies make use of the versions installed by this method, but I still don't see it as a net advantage). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080303/6dc72367/attachment.bin From dluke at geeklair.net Mon Mar 3 08:18:34 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon, 3 Mar 2008 11:18:34 -0500 Subject: Checking if a given port is installed in pre-fetch In-Reply-To: <799406d60803021109h1eeae683ree85158d305feb17@mail.gmail.com> References: <799406d60803012021s508d4e9pcddfce77263cda05@mail.gmail.com> <70DDFF47-40AF-4ECD-B585-F49E45B890C8@geeklair.net> <799406d60803021109h1eeae683ree85158d305feb17@mail.gmail.com> Message-ID: <05E83155-F549-49F4-9374-0BE2991AC4EA@geeklair.net> On Mar 2, 2008, at 2:09 PM, Adam Mercer wrote: > On Sun, Mar 2, 2008 at 12:16 PM, Daniel J. Luke > wrote: >> You can do almost anything from within a portfile, but there are lots >> of things that you maybe shouldn't. >> >> What are you trying to accomplish? > > I want to upgrade the science/geos port to 3.0.0 but > matplotlib-basemap requires geos-2.2.3 and will not work with > geos-3.0.0. Unfortunately it doesn't appear possible to install both > geos-2.2.3 and geos-3.0.0 at the the same time, so I was wondering if > there was a way that I could make a port for each version and mark > them as conflicting? There's not a built-in way to do this (but it might be a nice base/ feature), and I don't know of a really good way of doing it (you could probably check for an installed binary in a pre-fetch action and output an appropriate ui_error message). Ideally, it would be good to modify one or both of the ports so that they can both be installed (or get things patched/updated so they can work with the newer version of the port). As an alternative, having the science/geos port updated and adding a new port for the old version that matplotlib-basemap uses might be ok (especially if it's unlikely that someone might want both ports). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080303/47598cc1/attachment.bin From blair at orcaware.com Mon Mar 3 10:59:07 2008 From: blair at orcaware.com (Blair Zajac) Date: Mon, 03 Mar 2008 10:59:07 -0800 Subject: Python framework location and Python 3.0 conflict with 2.4 Message-ID: <47CC4A7B.6000202@orcaware.com> Hi, This is to follow up on this commit: http://trac.macports.org/projects/macports/changeset/34702 We've discussed this briefly before on the list, but I'm of the mind that all new Python frameworks must be installed in a separate directory from the Python 2.4 framework for several reasons: 1) There's a conflict on the ${prefix}/Library/Frameworks/Python.framework/Versions file. 2) I have a requirement that we have multiple framework Pythons installed at the same time. With a deployment to a hundred Mac's or so running PyQt apps running on 2.4, I need to maintain that environment. It would be nice to have Python 3.0 with a framework build installed along side 2.4 so we can port our applications to Python 3.0 (which is source incompatible with 2.x). So I don't care really where the Python 3.0 framework gets installed, but its base must not be ${prefix}/Library/Frameworks. A directory such as ${prefix}/Library/Frameworks/${name} would work for me. Regards, Blair From afb at macports.org Mon Mar 3 11:02:16 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 3 Mar 2008 20:02:16 +0100 Subject: Google SoC 2008 In-Reply-To: References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> <20080302234326.GD94215@darkart.com> <0D70FD0D-5A5D-4F79-945F-C55D58DF43B1@apple.com> Message-ID: <07EF962C-B08D-40EB-8EF1-32C708DE2433@macports.org> Randall Wood wrote: > As far as the complexity of RPM goes, I think that a lot of the > dp-light work is still hanging around and may be reusable, but it may > simply be a good idea for port to do a Portfile to .spec file > transform (and maybe build the SRPM) and then hand everything off to > an RPM-based configure/build/distribute/install process. I know that a > lot of the GTK/GNOME ports already build the .spec files for creating > the [S]RPMs anyway. Isn't that what the current "rpm" and "srpm" targets do ? "rpm" was formerly known as "rpmpackage", and uses RPM just as an archiver to package up a pre-created destroot while filling in some basic metadata and dependencies, but it doesn't really use the .spec file for building: %prep %build %install %clean There is also a new "srpm" target, that creates a SRPM (Source RPM) which contains the Portfile and all files/. RPM doesn't have a Tcl script handler (yet?), so it calls on port(1) to do the various operations in the RPM phases: %prep %setup -c -a 1 -T cp -p %{SOURCE0} Portfile #prepare work area port fetch port checksum port extract port patch %build port configure port build %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT port destroot port rpm %clean port clean This way, the RPM is comparable to the tgz/tgz/tlz/xar archives and the SRPM is comparable to the xar portpkg. (as you might be aware of, MPWA creates such portpkg for all port submissions - at http://db.macports.org) But the registry/install/upgrade/uninstall hasn't been updated with the rest of the dp_light stuff, that added the capability to use RPM packages instead of archives. (somewhat like Fink uses DEB packages to do installs...) --anders From raimue at macports.org Mon Mar 3 12:04:12 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 03 Mar 2008 21:04:12 +0100 Subject: Python framework location and Python 3.0 conflict with 2.4 In-Reply-To: <47CC4A7B.6000202@orcaware.com> References: <47CC4A7B.6000202@orcaware.com> Message-ID: <47CC59BC.9050407@macports.org> Blair Zajac wrote: > We've discussed this briefly before on the list, but I'm of the mind that all > new Python frameworks must be installed in a separate directory from the Python > 2.4 framework for several reasons: > > 1) There's a conflict on the > ${prefix}/Library/Frameworks/Python.framework/Versions file. Also on Python.framework/{Headers,Python,Resources}. See below. > 2) I have a requirement that we have multiple framework Pythons installed at the > same time. With a deployment to a hundred Mac's or so running PyQt apps running > on 2.4, I need to maintain that environment. > > It would be nice to have Python 3.0 with a framework build installed along side > 2.4 so we can port our applications to Python 3.0 (which is source incompatible > with 2.x). > > So I don't care really where the Python 3.0 framework gets installed, but its > base must not be ${prefix}/Library/Frameworks. A directory such as > ${prefix}/Library/Frameworks/${name} would work for me. I discussed this with reiffert today on IRC. If everything would work as it should, we would have Python.framework/Versions/{2.4,2.5,3.0} and python_select would link Python.framework/Versions/Current to the according version. And now comes the big "but...": All three ports try to add Headers,Python,Resources symlinks to Versions/Current/{Headers,Python,Resources}. So if another port gets activated it fails on these files. They have to exist, but can't be owned by a port. Sure, we could symlink like Headers -> Versions/3.0/Headers with python_select. But that makes python_select a dependency to get a working framework install. Another solution would be Python24.framework, Python25.framework, Python30.framework. But as frameworks are meant to be installed with different versions (by this Current symlink) we should find some solution to make use of it. Rainer From raimue at macports.org Mon Mar 3 13:06:35 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 03 Mar 2008 22:06:35 +0100 Subject: Checking if a given port is installed in pre-fetch In-Reply-To: <05E83155-F549-49F4-9374-0BE2991AC4EA@geeklair.net> References: <799406d60803012021s508d4e9pcddfce77263cda05@mail.gmail.com> <70DDFF47-40AF-4ECD-B585-F49E45B890C8@geeklair.net> <799406d60803021109h1eeae683ree85158d305feb17@mail.gmail.com> <05E83155-F549-49F4-9374-0BE2991AC4EA@geeklair.net> Message-ID: <47CC685B.3080608@macports.org> Daniel J. Luke wrote: > There's not a built-in way to do this (but it might be a nice base/ > feature), and I don't know of a really good way of doing it (you could > probably check for an installed binary in a pre-fetch action and > output an appropriate ui_error message). Which would issue a warning in tracemode or make it fail at all. Rainer From ryandesign at macports.org Mon Mar 3 13:13:16 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 3 Mar 2008 15:13:16 -0600 Subject: Checking if a given port is installed in pre-fetch In-Reply-To: <05E83155-F549-49F4-9374-0BE2991AC4EA@geeklair.net> References: <799406d60803012021s508d4e9pcddfce77263cda05@mail.gmail.com> <70DDFF47-40AF-4ECD-B585-F49E45B890C8@geeklair.net> <799406d60803021109h1eeae683ree85158d305feb17@mail.gmail.com> <05E83155-F549-49F4-9374-0BE2991AC4EA@geeklair.net> Message-ID: <423297EB-6213-4E79-B350-4C1874CF5B3D@macports.org> On Mar 3, 2008, at 10:18, Daniel J. Luke wrote: > On Mar 2, 2008, at 2:09 PM, Adam Mercer wrote: > >> On Sun, Mar 2, 2008 at 12:16 PM, Daniel J. Luke wrote: >> >>> You can do almost anything from within a portfile, but there are >>> lots >>> of things that you maybe shouldn't. >>> >>> What are you trying to accomplish? >> >> I want to upgrade the science/geos port to 3.0.0 but >> matplotlib-basemap requires geos-2.2.3 and will not work with >> geos-3.0.0. Unfortunately it doesn't appear possible to install both >> geos-2.2.3 and geos-3.0.0 at the the same time, so I was wondering if >> there was a way that I could make a port for each version and mark >> them as conflicting? > > There's not a built-in way to do this (but it might be a nice base/ > feature), and I don't know of a really good way of doing it (you > could probably check for an installed binary in a pre-fetch action > and output an appropriate ui_error message). Not in pre-fetch, please. This would trip up anybody trying to "sudo port upgrade" the port. > Ideally, it would be good to modify one or both of the ports so > that they can both be installed Yes, that would be the best way to have two different versioned ports. We don't always meet this goal (apache can't be installed with apache2; php4 can't be installed with php5...) but we should. > (or get things patched/updated so they can work with the newer > version of the port). That would be ideal. > As an alternative, having the science/geos port updated and adding > a new port for the old version that matplotlib-basemap uses might > be ok (especially if it's unlikely that someone might want both > ports). From ram at macports.org Mon Mar 3 13:17:19 2008 From: ram at macports.org (Adam Mercer) Date: Mon, 3 Mar 2008 16:17:19 -0500 Subject: Checking if a given port is installed in pre-fetch In-Reply-To: <423297EB-6213-4E79-B350-4C1874CF5B3D@macports.org> References: <799406d60803012021s508d4e9pcddfce77263cda05@mail.gmail.com> <70DDFF47-40AF-4ECD-B585-F49E45B890C8@geeklair.net> <799406d60803021109h1eeae683ree85158d305feb17@mail.gmail.com> <05E83155-F549-49F4-9374-0BE2991AC4EA@geeklair.net> <423297EB-6213-4E79-B350-4C1874CF5B3D@macports.org> Message-ID: <799406d60803031317s43378206k49decc3f0cbe2098@mail.gmail.com> On Mon, Mar 3, 2008 at 4:13 PM, Ryan Schmidt wrote: > > (or get things patched/updated so they can work with the newer > > version of the port). > > That would be ideal. Agreed. At the moment I don't think theres many people, besides myself, who are interested in a geos-3.0.0 port so I think the best thing to do is keep the geos port at 2.2.3 and find a way to get basemap to work with the latest geos version. Cheers Adam From blair at orcaware.com Mon Mar 3 13:30:22 2008 From: blair at orcaware.com (Blair Zajac) Date: Mon, 03 Mar 2008 13:30:22 -0800 Subject: Python framework location and Python 3.0 conflict with 2.4 In-Reply-To: <47CC59BC.9050407@macports.org> References: <47CC4A7B.6000202@orcaware.com> <47CC59BC.9050407@macports.org> Message-ID: <47CC6DEE.9060402@orcaware.com> Rainer M?ller wrote: > Blair Zajac wrote: >> We've discussed this briefly before on the list, but I'm of the mind >> that all new Python frameworks must be installed in a separate >> directory from the Python 2.4 framework for several reasons: >> >> 1) There's a conflict on the >> ${prefix}/Library/Frameworks/Python.framework/Versions file. > > Also on Python.framework/{Headers,Python,Resources}. See below. > >> 2) I have a requirement that we have multiple framework Pythons >> installed at the same time. With a deployment to a hundred Mac's or >> so running PyQt apps running on 2.4, I need to maintain that environment. >> >> It would be nice to have Python 3.0 with a framework build installed >> along side 2.4 so we can port our applications to Python 3.0 (which is >> source incompatible with 2.x). >> >> So I don't care really where the Python 3.0 framework gets installed, >> but its base must not be ${prefix}/Library/Frameworks. A directory >> such as >> ${prefix}/Library/Frameworks/${name} would work for me. > > I discussed this with reiffert today on IRC. > > If everything would work as it should, we would have > Python.framework/Versions/{2.4,2.5,3.0} and python_select would link > Python.framework/Versions/Current to the according version. > > And now comes the big "but...": > All three ports try to add Headers,Python,Resources symlinks to > Versions/Current/{Headers,Python,Resources}. So if another port gets > activated it fails on these files. They have to exist, but can't be > owned by a port. > > Sure, we could symlink like Headers -> Versions/3.0/Headers with > python_select. But that makes python_select a dependency to get a > working framework install. > > Another solution would be Python24.framework, Python25.framework, > Python30.framework. But as frameworks are meant to be installed with > different versions (by this Current symlink) we should find some > solution to make use of it. If we can get the build scripts to automatically run python_select python24 when it's going to build a Python 2.4 Port and then run python_select python25 for Python 2.5 ports, then that would work. But it seems that python_select is for runtime use of MacPorts installed binaries, not build time. Maybe we add a different set of flags to python_select for build time. Blair From randall.h.wood at alexandriasoftware.com Tue Mar 4 02:53:15 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Tue, 4 Mar 2008 05:53:15 -0500 Subject: Google SoC 2008 In-Reply-To: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> Message-ID: On 2/29/08, James Berry wrote: > I'm writing to attempt to gauge interest in whether and how MacPorts > should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ > . > > You might be inclined to address any of the following questions: > > - Do you feel MacPorts should participate in GSoC 2008? > - Are there particular MacPorts projects you'd like to suggest? I have another possible MacPorts project: The MacPorts port should be the source for updating a user's MacPorts installation. Currently the MacPorts port is used to build the .dmg installer for MacPorts that is used for the initial installation of MacPorts, and port uses the "selfupdate" mechanism for maintaining the MacPorts installation. The selfupdate mechanism is (at least not documented as such) not accessible through the MacPorts API and does not use the MacPorts mechanisms for maintaining ports. I guess this is for historical reasons and to make the installer simpler. I would like to see "sudo port sync ; sudo port upgrade MacPorts" achieve the exact same results as "sudo port selfupdate" and suggest that the .dmg installer should be some sort of temporary bootstrapping installation of port with all its supporting libraries that installs the MacPorts installation in /opt/local, /Library/Tcl and wherever else it needs to park itself and registers those items in the repository just like any other port. Sorry about the over-caffeinated early morning ramble, I'll revisit to clarify, but I think that could be a neat project. > - Are you willing to be a GSoC mentor? > - Would you be interested, as a student, in participating in a GSoC > project for MacPorts? > > GSoC pays students a wage for the summer to work on open source > projects, and also a stipend to the project for each student project. > > If interested, we need to move very quickly. As the Google GSoC FAQ > says: > > "We'll begin accepting applications from open source mentoring > organizations on Monday, March 3, 2008; we'll stop accepting > organization applications on Wednesday, March 12th." > > Your feedback is welcome > > James > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -- Randall Wood randall.h.wood at alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From randall.h.wood at alexandriasoftware.com Tue Mar 4 03:28:20 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Tue, 4 Mar 2008 06:28:20 -0500 Subject: Google SoC 2008 In-Reply-To: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> Message-ID: On 2/29/08, James Berry wrote: > I'm writing to attempt to gauge interest in whether and how MacPorts > should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ > . > > You might be inclined to address any of the following questions: > > - Do you feel MacPorts should participate in GSoC 2008? > - Are there particular MacPorts projects you'd like to suggest? Yet another possible project (sorry for yapping about like this): Add support for a mechanism similar to Finks init.[c]sh mechanisms for providing basic and port-provided environmental services to users in the .profile, .cshrc, and .xinitrc files, so that instead of manipulating the user's .profile to modify certain paths, all we do is append something like "source /opt/local/etc/bash.rc" to the end of a user's .profile file and that bash.rc would be like /etc/rc and would source all the files in /opt/local/etc/bash.d This would require: 1) Adding support to the Portfiles for setting key value pairs that can then be written out at some phase (install?) into both correct bash and csh (and maybe other shell) syntaxes and stored in ${prefix}/etc/init.d/${portname}.shell 2) Adding support for managing X11-specific key value pairs that would be stored into ${prefix}/etc/xinit.d/${portname} 3) Writing the files ${prefix}/etc/init.shell for each shell we decide to support. These files need only support correcting the PATH and MANPATH for macports and then sourcing all of the files in init.d ending in the correct shell. 4) Writing ${prefix}/etc/init.X11 that would source ${prefix}/etc/init.sh (the xinit mechanism is a bash shell, I believe) and then source all the files in init.d ending in X11. 5) Provide a simple command line utility that can correctly enable/disable sourcing the init.shell|X11 files for a user. What gets inserted into a user's .profile/.xinitrc/.cshrc file? It should be a couple of lines of comment explaining the single command line that we added to the file followed by the command line (in bash: source /opt/local/etc/init.sh) > - Are you willing to be a GSoC mentor? > - Would you be interested, as a student, in participating in a GSoC > project for MacPorts? > > GSoC pays students a wage for the summer to work on open source > projects, and also a stipend to the project for each student project. > > If interested, we need to move very quickly. As the Google GSoC FAQ > says: > > "We'll begin accepting applications from open source mentoring > organizations on Monday, March 3, 2008; we'll stop accepting > organization applications on Wednesday, March 12th." > > Your feedback is welcome > > James > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -- Randall Wood randall.h.wood at alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From ebgssth at gmail.com Tue Mar 4 04:19:57 2008 From: ebgssth at gmail.com (js) Date: Tue, 4 Mar 2008 21:19:57 +0900 Subject: RFC: Changing apache2 to install its files to /opt/local/ instead of /opt/local/apache2 In-Reply-To: <47CACB75.1070504@macports.org> References: <4F6FF124-A316-4791-9CAF-9D53AA156A65@macports.org> <47CACB75.1070504@macports.org> Message-ID: > >> The apache port should be able to coexist with either the apache2 or > >> the apache20 port. Currently, they cannot coexist: > >> > >> $ sudo port activate apache > >> Password: > >> ---> Activating apache > >> Error: port activate failed: Image error: /opt/local/share/man/man1/ > >> dbmmanage.1.gz is being used by the active apache2 port. Please > >> deactivate this port first, or use the -f flag to force the activation. > >> $ > > > > suffix would fix this issue. > > Do you mean dbmmanage.1{apache,apache20,apache2}.gz? That would be good. > Then you can read the man pages by using e.g. man 1apache2 dbmmanage. I feel a bit odd, though. I prefer python's style. - /opt/local/share/man/man1/python2.5.1.gz - /opt/local/share/man/man1/python2.4.1.gz Anyway, this issue is not a point here. Let's get back to the apache2's problem. I seems more people's having the same frustration with this. Does this mean we can change apache2 port as it's supposed to be? From ebgssth at gmail.com Tue Mar 4 04:27:03 2008 From: ebgssth at gmail.com (js) Date: Tue, 4 Mar 2008 21:27:03 +0900 Subject: py-twistedweb2 and py25-twisted-web2 uses different name convension In-Reply-To: <081DE1AD-319D-4D10-BC09-EF36773A594F@macports.org> References: <1578ADF8-7075-4E12-8B26-7EF3931628CB@macports.org> <081DE1AD-319D-4D10-BC09-EF36773A594F@macports.org> Message-ID: Then, is my request rejected? Who has the power to decide this kind of issue? On Sat, Mar 1, 2008 at 6:07 AM, Ryan Schmidt wrote: > On Feb 29, 2008, at 14:33, Kevin Ballard wrote: > > > On Feb 29, 2008, at 3:28 PM, Ryan Schmidt wrote: > > > >> On Feb 29, 2008, at 09:20, js wrote: > >> > >>> I noticed that twisted for python2.4 and 2.5 uses different name > >>> convension. > >>> I opened new ticket http://trac.macosforge.org/projects/macports/ > >>> ticket/14375 > >>> > >>> Shouldn' they use the same convension? > >> > >> Sure, it would make sense for the common parts of the port name to > >> be the same. > > > > > The problem is this breaks the upgrade path. Anybody with py25- > > twisted- > > web2 will lose the ability to update their port if it gets renamed to > > py25-twistedweb2. They'll have to discover this problem on their own > > and uninstall py25-twisted-web2 and install py25-twistedweb2. > > > > The only workaround I can think of for this is to push a dummy update > > for py25-twisted-web2 that errors out on fetch with a message saying > > to uninstall and reinstall py25-twistedweb2, but that's ugly and > > unfriendly. > > Still wish we had the "superseded_by" feature in MacPorts base so it > would be easier to rename a port: > > http://lists.macosforge.org/pipermail/macports-dev/2007-July/002219.html > > http://lists.macosforge.org/pipermail/macports-dev/2007-December/ > 003767.html > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From ebgssth at gmail.com Tue Mar 4 05:16:52 2008 From: ebgssth at gmail.com (js) Date: Tue, 4 Mar 2008 22:16:52 +0900 Subject: RFC: MacPorts Filesystem Hierarchy Standard Message-ID: Hi, I wrote the Filename hierarchy standard for MacPorts. I know there's already porthier(7), but I thought it would be nice to have more specific standard. As you can see, this standard is still incomplete intentionally, becauses this kind of task should be not done in solely and I'd like to check if there are demands for this. I am really like to hear from all of you. Any comments, suggestions and even critique would be appreciated. Thanks. -------------------------------------------------------------------------------- MacPorts Filesystem Hierarchy Standard Purpose This document defines the standard placement of file and directory installed by MacPorts. This document also intended to replace the existing porthier(7)[1]. Every ports in MacPorts project should follow this standard. Most of this based on hier(7)[2]. Naming Convension When two or more ports have files in common, e.g. apachectl in apache and apache2, each port must prepend the part of its major version number to the files as a suffix. (e.g. apachectl for apache, apachectl2 for apapche2) When a port need to install multiple files, it must create a directory named its port name and installs the files in it. (e.g. macports/macports.conf, macports/mp_version) The Filesystem Prefix Everything installed by MacPorts must be in /opt/local or /Applications/MacPorts. The former is used for non-aqua applications and may be changed by modifying macports.conf. The latter is for aqua applications and cannot be changed. Non Aqua Applications ${prefix} contains the following directories. - bin contains common utilities, programming tools, and applications. - etc contains system configuration files and scripts. - include Standard C include files. - lib System libraries. - libexec System daemons and utilities (executed by other programs). For example, mysqld(a system daemon), apache/modules(a utility) - sbin System daemons and utilities (executed by users). for example, httpd(a system daemon), ifstat(a utility) - share - info Texinfo source files. - man - cat[0-9ln] - man[0-9ln] Manual pages. - nls National Language Support (NLS) catalogs. - (LANGS) - skel Example `.' (dot) files for new accounts. (FIXME: wonder we really need this) - src Doesn't exist... - var Multi-purpose log, temporary, transient and spool files. - macports - distfiles - receipts - registry - distfiles - software - sources - db Miscellaneous, automatically generated system-specific database files. For example, ... what? (Note that currently mysql data directory is created here. This is not correct.) - run System information files describing various info about the system since it was booted. For example, pid files. - log Log files. Every program in MacPorts should write it logs to this place. For example, var/log/apache/access, var/log/mysql/mysqld.err - www ServerRoot point for httpd(8). [1] MacPorts File Hierarchy http://guide.macports.org/#internals.hierarchy [2] OpenBSD Reference Manual HIER(7) http://www.openbsd.org/cgi-bin/man.cgi?query=hier&sektion=7 From afb at macports.org Tue Mar 4 05:44:29 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue, 4 Mar 2008 14:44:29 +0100 Subject: RFC: MacPorts Filesystem Hierarchy Standard In-Reply-To: References: Message-ID: js wrote: > I am really like to hear from all of you. > Any comments, suggestions and even critique would be appreciated. ... > Everything installed by MacPorts must be in /opt/local or > /Applications/MacPorts. The former is used for non-aqua applications > and may be changed by modifying macports.conf. The latter is for aqua > applications and cannot be changed. Work is in progress to allow the applications and frameworks directories to be changed, to allow for non-root installations. Currently they are /Applications/MacPorts and /Library/Frameworks, though. So it is correct for the present, but might change later. > - src > Doesn't exist... RPM uses (a subdirectory of) this directory when building as root. Not that building as root is recommended, but it is still default... src |-- apple `-- macports |-- BUILD |-- RPMS | |-- fat | |-- i386 | |-- noarch | `-- ppc |-- SOURCES |-- SPECS `-- SRPMS Note: the name "macports" will change to the default name "rpm", when upgrading from old RPM 4.4.9 to newer RPM 4.5 or to RPM 5.0 --anders From raimue at macports.org Tue Mar 4 06:08:03 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 04 Mar 2008 15:08:03 +0100 Subject: RFC: Changing apache2 to install its files to /opt/local/ instead of /opt/local/apache2 In-Reply-To: References: <4F6FF124-A316-4791-9CAF-9D53AA156A65@macports.org> <47CACB75.1070504@macports.org> Message-ID: <47CD57C3.9000406@macports.org> js wrote: >> Do you mean dbmmanage.1{apache,apache20,apache2}.gz? That would be good. >> Then you can read the man pages by using e.g. man 1apache2 dbmmanage. > > I feel a bit odd, though. > I prefer python's style. > - /opt/local/share/man/man1/python2.5.1.gz > - /opt/local/share/man/man1/python2.4.1.gz Which would also be a bit odd. If I would have to type `man dbmmanage2' I would expect a function with that name. But it is still dbmmanage(). The way I proposed is common, and is for example used for OpenSSL by Apple (/usr/share/man/man3/*3ssl*) as it also contains conflicting manual pages. > Anyway, this issue is not a point here. > Let's get back to the apache2's problem. > > I seems more people's having the same frustration with this. > Does this mean we can change apache2 port as it's supposed to be? I don't see objections, so go on. Rainer From raimue at macports.org Tue Mar 4 07:03:24 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 04 Mar 2008 16:03:24 +0100 Subject: RFC: MacPorts Filesystem Hierarchy Standard In-Reply-To: References: Message-ID: <47CD64BC.5020606@macports.org> js wrote: > I wrote the Filename hierarchy standard for MacPorts. > I know there's already porthier(7), but I thought it would be nice > to have more specific standard. So is this meant to replace porthier(7)? Than you should write it up as a patch for the manual page. I don't think we need yet another place for it. Coordinate with markd and simon on this. > MacPorts Filesystem Hierarchy Standard > > Purpose > > This document defines the standard placement of file and directory > installed by MacPorts. This document also intended to replace the > existing porthier(7)[1]. Every ports in MacPorts project should follow > this standard. Most of this based on hier(7)[2]. Why are you referencing to OpenBSD hier? Mac OS X also has a man page `hier'. > Naming Convension > > When two or more ports have files in common, e.g. apachectl in apache > and apache2, each port must prepend the part of its major version > number to the files as a suffix. (e.g. apachectl for apache, > apachectl2 for apapche2) Append, not prepend. > When a port need to install multiple files, it must create a > directory named its port name and installs the files in > it. (e.g. macports/macports.conf, macports/mp_version) > > The Filesystem > > Prefix > > Everything installed by MacPorts must be in /opt/local or > /Applications/MacPorts. The former is used for non-aqua applications > and may be changed by modifying macports.conf. The latter is for aqua > applications and cannot be changed. Write ${prefix} instead of /opt/local, or if it goes into the man page, it could be expanded during install. The applications dir should be changeable in future versions, but at the moment it is still hardcoded in ports, so this is right. [snip] > - db > Miscellaneous, automatically generated system-specific database > files. For example, ... what? > (Note that currently mysql data directory is created here. This is > not correct.) No idea what is meant to reside here. Sure, mysqlX could also go into var/mysqlX. Rainer From jberry at macports.org Tue Mar 4 08:27:34 2008 From: jberry at macports.org (James Berry) Date: Tue, 4 Mar 2008 08:27:34 -0800 Subject: Google SoC 2008 In-Reply-To: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> Message-ID: <8C51D842-0EB6-48B0-A7E6-1C4CF23FB791@macports.org> Thanks to everybody who pitched ideas for GSoC 2008. Now the rubber needs to meet the road. We need: - Somebody to head up our GSoC 2008 effort (get us signed up with Google, document the proposed projects, etc). - And committed mentors for any projects. Volunteers? As Paul Guyot points out, one thing we found last year was that google seems to allocate project funding to a project based on the total number of student applications. So a project that gets applications from 50 students is likely to be allocated more student slots than a project that gets only 3 student applications. The number of student applications is probably guided in part by several factors: promotion and appeal to the student community; number and appeal of project proposals; etc. James On Feb 29, 2008, at 3:48 PM, James Berry wrote: > I'm writing to attempt to gauge interest in whether and how MacPorts > should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ > . > > You might be inclined to address any of the following questions: > > - Do you feel MacPorts should participate in GSoC 2008? > - Are there particular MacPorts projects you'd like to suggest? > - Are you willing to be a GSoC mentor? > - Would you be interested, as a student, in participating in a GSoC > project for MacPorts? > > GSoC pays students a wage for the summer to work on open source > projects, and also a stipend to the project for each student project. > > If interested, we need to move very quickly. As the Google GSoC FAQ > says: > > "We'll begin accepting applications from open source mentoring > organizations on Monday, March 3, 2008; we'll stop accepting > organization applications on Wednesday, March 12th." > > Your feedback is welcome > > James > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From gwright at antiope.com Tue Mar 4 12:47:34 2008 From: gwright at antiope.com (Gregory Wright) Date: Tue, 4 Mar 2008 15:47:34 -0500 Subject: ghc port vanished Message-ID: Hi, I checked in a version bump of ghc to 6.8.2 yesterday. The portfile is in the svn repo, but someone emailed me to say that it did not appear in their dports tree. I notice as well that it is missing from the "available ports" on the web page. Did something go awry or should just advise people to wait until some script syncs things up? Best Wishes, Greg From ramercer at gmail.com Tue Mar 4 13:00:27 2008 From: ramercer at gmail.com (Adam Mercer) Date: Tue, 4 Mar 2008 16:00:27 -0500 Subject: ghc port vanished In-Reply-To: References: Message-ID: <799406d60803041300y20c21eb6u8db4ac2bb7a08206@mail.gmail.com> On Tue, Mar 4, 2008 at 3:47 PM, Gregory Wright wrote: > > > Hi, > > I checked in a version bump of ghc to 6.8.2 yesterday. The portfile > is in the svn > repo, but someone emailed me to say that it did not appear in their > dports tree. > I notice as well that it is missing from the "available ports" on the > web page. > > Did something go awry or should just advise people to wait until some > script syncs > things up? Looks like theres a problem with the port, from the latest PortIndex mailing Total number of ports parsed: 4543 Ports successfully parsed: 4542 Ports failed: 1 Failed to parse file lang/ghc/Portfile: Error evaluating variants So you've got somthing wrong with the variants, I guess its: variant no_opengl { configure.args-append --disable-opengl configure.args-append --disable-glut } which should be: variant no_opengl { configure.args-append --disable-opengl configure.args-append --disable-glut } lint also gives a lot of warnings: ---> Verifying Portfile for ghc Warning: Line 4 should be a newline (after PortSystem) Warning: Line 21 has trailing whitespace before newline Warning: Variant no_opengl does not have a description Warning: Patchfile patch-configure.ac does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-libraries-Makefile does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-libraries-base-base.cabal does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-libraries-base-base.buildinfo.in does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-libraries-base-configure.ac does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-libraries-base-aclocal.m4 does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-libraries-hpc-Setup.hs does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-libraries-hpc-hpc.cabal does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-libraries-hpc-hpc.buildinfo.in does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-libraries-hpc-configure.ac does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-libraries-hpc-aclocal.m4 does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-rts-posix-FileLock.c does not follow the source patch naming policy "patch-*.diff" Warning: Patchfile patch-libraries-Cabal-Distribution-Simple-Configure.hs does not follow the source patch naming policy "patch-*.diff" ---> 0 errors and 16 warnings found. Cheers Adam From dluke at geeklair.net Tue Mar 4 13:05:26 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue, 4 Mar 2008 16:05:26 -0500 Subject: ghc port vanished In-Reply-To: <799406d60803041300y20c21eb6u8db4ac2bb7a08206@mail.gmail.com> References: <799406d60803041300y20c21eb6u8db4ac2bb7a08206@mail.gmail.com> Message-ID: <361E8987-1707-476D-9899-9B2955B2A31C@geeklair.net> On Mar 4, 2008, at 4:00 PM, Adam Mercer wrote: > Failed to parse file lang/ghc/Portfile: Error evaluating variants It's because portindex runs on a 10.5 ppc machine, and the ghc port specifically errors out on that platform. I've checked in an update that wraps the error return in a pre-fetch block which fixes it. -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080304/9bb0026c/attachment.bin From gwright at antiope.com Tue Mar 4 13:29:51 2008 From: gwright at antiope.com (Gregory Wright) Date: Tue, 4 Mar 2008 16:29:51 -0500 Subject: ghc port vanished In-Reply-To: <799406d60803041300y20c21eb6u8db4ac2bb7a08206@mail.gmail.com> References: <799406d60803041300y20c21eb6u8db4ac2bb7a08206@mail.gmail.com> Message-ID: <8239654A-3775-4B54-8CBE-F9E7EE4D82B1@antiope.com> Hi Adam, On Mar 4, 2008, at 4:00 PM, Adam Mercer wrote: > On Tue, Mar 4, 2008 at 3:47 PM, Gregory Wright > wrote: >> >> >> Hi, >> >> I checked in a version bump of ghc to 6.8.2 yesterday. The portfile >> is in the svn >> repo, but someone emailed me to say that it did not appear in their >> dports tree. >> I notice as well that it is missing from the "available ports" on the >> web page. >> >> Did something go awry or should just advise people to wait until some >> script syncs >> things up? > > Looks like theres a problem with the port, from the latest PortIndex > mailing > > Total number of ports parsed: 4543 > Ports successfully parsed: 4542 > Ports failed: 1 > > Failed to parse file lang/ghc/Portfile: Error evaluating variants > > So you've got somthing wrong with the variants, I guess its: > > variant no_opengl { configure.args-append --disable-opengl > configure.args-append --disable-glut > } > > which should be: > > variant no_opengl { > configure.args-append --disable-opengl > configure.args-append --disable-glut > } > I am a bit confused by this since the Portfile built successfully. Does portindex enforce a stricter syntax or is it this just a quirk? > lint also gives a lot of warnings: > > ---> Verifying Portfile for ghc > Warning: Line 4 should be a newline (after PortSystem) > Warning: Line 21 has trailing whitespace before newline > Warning: Variant no_opengl does not have a description > Warning: Patchfile patch-configure.ac does not follow the source patch I'll canonicalize the patch names at the next minor revision. Best Wishes, Greg From gwright at antiope.com Tue Mar 4 13:49:32 2008 From: gwright at antiope.com (Gregory Wright) Date: Tue, 4 Mar 2008 16:49:32 -0500 Subject: ghc port vanished In-Reply-To: <361E8987-1707-476D-9899-9B2955B2A31C@geeklair.net> References: <799406d60803041300y20c21eb6u8db4ac2bb7a08206@mail.gmail.com> <361E8987-1707-476D-9899-9B2955B2A31C@geeklair.net> Message-ID: Hi Daniel, On Mar 4, 2008, at 4:05 PM, Daniel J. Luke wrote: > On Mar 4, 2008, at 4:00 PM, Adam Mercer wrote: >> Failed to parse file lang/ghc/Portfile: Error evaluating variants > > It's because portindex runs on a 10.5 ppc machine, and the ghc port > specifically errors out on that platform. > > I've checked in an update that wraps the error return in a pre-fetch > block which fixes it. > Thank you for the explanation, and the fix. Best Wishes, Greg From simon at ruderich.com Tue Mar 4 15:20:07 2008 From: simon at ruderich.com (Simon Ruderich) Date: Wed, 5 Mar 2008 00:20:07 +0100 Subject: Splitting the guide In-Reply-To: References: Message-ID: <20080304232006.GB415@ruderich.com> On Sat, Feb 16, 2008 at 02:46:33PM -0800, markd at macports.org wrote: >> Hey guys! >> >> The guide is advancing so nicely that I'm afraid we've hit the >> point when it's maybe becoming a tad too large for a single page, wouldn't >> y'all think? >> >> Every time I have to load a section of the guide a have a moment >> of hesitation in fear of loading such a large document! At this point in >> time, wouldn't it be better to have a single html page per chapter? >> >> Just my thoughts,... >> >> -jmpp > > Juan, > > Well I agree it is really too big, but on the other hand we hated to split > it and have cumbersome "forward" and "back" buttons. Also it makes > searching easier in one page, but then I suppose indexing might solve > that. But then maybe a page for each chapter wouldn't be too bad. I > guess we should experiment and see how it looks and drives. > > Mark Hi all, sorry for the late reply. I just created a chunked version of the guide and uploaded it on my homepage: http://ruderich.com/macports/chunked/ Please tell me what you think and if I should change anything. Thanks, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080305/83188595/attachment.bin From reiffert at macports.org Tue Mar 4 23:15:52 2008 From: reiffert at macports.org (Thomas Reifferscheid) Date: Wed, 05 Mar 2008 08:15:52 +0100 Subject: Splitting the guide In-Reply-To: <20080304232006.GB415@ruderich.com> References: <20080304232006.GB415@ruderich.com> Message-ID: <47CE48A8.3030308@macports.org> Hi, great work Simon! For doing this automatically (e.g. every night), we could need some kind of shell (bash) script doing this. Do you think thats possible for fully automation? Kind regards Thomas Simon Ruderich wrote: [...] > Hi all, > sorry for the late reply. > > I just created a chunked version of the guide and uploaded it on my homepage: > http://ruderich.com/macports/chunked/ > > Please tell me what you think and if I should change anything. > From lutz.horn at fastmail.fm Wed Mar 5 00:49:37 2008 From: lutz.horn at fastmail.fm (Lutz Horn) Date: Wed, 05 Mar 2008 09:49:37 +0100 Subject: Splitting the guide In-Reply-To: <20080304232006.GB415@ruderich.com> References: <20080304232006.GB415@ruderich.com> Message-ID: <1204706977.5218.1240652709@webmail.messagingengine.com> Hi Simon, On Wed, 5 Mar 2008 00:20:07 +0100, "Simon Ruderich" said: > I just created a chunked version of the guide and uploaded it on my > homepage: http://ruderich.com/macports/chunked/ > > Please tell me what you think and if I should change anything. Nice! Could you add Up links at the top and the bottom of the page? This would allow the user not only to navigate to the next and previous page but also back to the TOC. Lutz -- GnuPG Key: 1024D/6EBDA359 1999-09-20 Key fingerprint = 438D 31FC 9300 CED0 1CDE A19D CD0F 9CA2 6EBD A359 http://dev-random.dnsalias.net/0x6EBDA35.asc http://pgp.cs.uu.nl/stats/6EBDA359.html From raimue at macports.org Wed Mar 5 09:14:46 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 05 Mar 2008 18:14:46 +0100 Subject: Splitting the guide In-Reply-To: <20080304232006.GB415@ruderich.com> References: <20080304232006.GB415@ruderich.com> Message-ID: <47CED506.9090804@macports.org> Hi Simon, Simon Ruderich wrote: > I just created a chunked version of the guide and uploaded it on my homepage: > http://ruderich.com/macports/chunked/ Looks good so far. But I would like the TOC to be on each page for easier switching of chapters. Could the current chapter be marked inside the list then? Also, as said before, Back/Next/Up links would be nice-to-have. I think you just used the chunked docbook XSL? Do you have any experience with XSL and are you able to improve that? :-) Rainer From raimue at macports.org Wed Mar 5 09:16:44 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 05 Mar 2008 18:16:44 +0100 Subject: Splitting the guide In-Reply-To: <47CE48A8.3030308@macports.org> References: <20080304232006.GB415@ruderich.com> <47CE48A8.3030308@macports.org> Message-ID: <47CED57C.4030403@macports.org> Thomas Reifferscheid wrote: > For doing this automatically (e.g. every night), > we could need some kind of shell (bash) script doing this. Do you think > thats possible for fully automation? I think finally this should go on guide.macports.org, there the guide is already built automatically. We would need to decide if we want to keep both versions with some intro page to choose or if we want to eliminate the all-on-one-page guide. Rainer From jmpp at macports.org Wed Mar 5 09:22:46 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Wed, 5 Mar 2008 12:52:46 -0430 Subject: Splitting the guide In-Reply-To: <47CE48A8.3030308@macports.org> References: <20080304232006.GB415@ruderich.com> <47CE48A8.3030308@macports.org> Message-ID: On Mar 5, 2008, at 2:45 AM, Thomas Reifferscheid wrote: > Hi, great work Simon! > > For doing this automatically (e.g. every night), > we could need some kind of shell (bash) script doing this. Do you > think > thats possible for fully automation? > > Kind regards > Thomas Guide regen is already automated in the base/portmgr/jobs/ GuideRegen.sh script, which runs as an svn post-commit hook on our subversion repo to keep guide.macports.org always up-to-date. What Simon is providing us here with is a view of the guide as a chapter per page alternative, per a request of mine. Simon, I like it and I still think the entire thing in a single page is a bit too much, but I would like to go over what Mark originally replied 'cause he did raise some valid points there (and it's been a while and I don't remember them at the moment ;-). One thing I would comment about your alternative, however, is with respect to the sidebar. Is is possible to keep it with us in every single chapter- page? At the moment we see it if we're on the front page, but as soon as we move to any chapter it disappears, and that's not incredibly friendly. Thanks for the initiative! Regards,... -jmpp > > > Simon Ruderich wrote: > > [...] >> Hi all, >> sorry for the late reply. >> >> I just created a chunked version of the guide and uploaded it on my >> homepage: >> http://ruderich.com/macports/chunked/ >> >> Please tell me what you think and if I should change anything. >> > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From simon at ruderich.com Wed Mar 5 08:55:39 2008 From: simon at ruderich.com (Simon Ruderich) Date: Wed, 5 Mar 2008 17:55:39 +0100 Subject: Splitting the guide In-Reply-To: <47CE48A8.3030308@macports.org> References: <20080304232006.GB415@ruderich.com> <47CE48A8.3030308@macports.org> Message-ID: <20080305165539.GA2577@ruderich.com> On Wed, Mar 05, 2008 at 08:15:52AM +0100, Thomas Reifferscheid wrote: > Hi, great work Simon! Hi, I'm glad you like it. > For doing this automatically (e.g. every night), > we could need some kind of shell (bash) script doing this. Do you think > thats possible for fully automation? This shouldn't be a problem. I already modified my local Makefile for the documentation generation. The question is how we should provide these two versions (maybe also a third: a downloadable version of the guide). Maybe http://guide.macports.org/ should display a selection so the user can choose a version. I don't know enough about the server structure. Juan, or anybody who knows this. What's the best way to add this selection (or something similar) and what changes needs the Makefile? > Kind regards > Thomas Thanks, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080305/cb39ddcb/attachment.bin From raimue at macports.org Wed Mar 5 09:42:19 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 05 Mar 2008 18:42:19 +0100 Subject: Splitting the guide In-Reply-To: <20080305165539.GA2577@ruderich.com> References: <20080304232006.GB415@ruderich.com> <47CE48A8.3030308@macports.org> <20080305165539.GA2577@ruderich.com> Message-ID: <47CEDB7B.6030600@macports.org> Simon Ruderich wrote: > This shouldn't be a problem. I already modified my local Makefile for the > documentation generation. The question is how we should provide these two > versions (maybe also a third: a downloadable version of the guide). Maybe > http://guide.macports.org/ should display a selection so the user can choose a > version. A selection page would be good, yes. > I don't know enough about the server structure. Juan, or anybody who knows > this. What's the best way to add this selection (or something similar) and > what changes needs the Makefile? I think currently the guide/html/ directory is made available on http://guide.macports.org. I am CC'ing Bill to confirm that :-) So we could add like * guide/html/one-page/ * guide/html/multipage/ With guide/html/index.html being some static selection page. Rainer From wsiegrist at apple.com Wed Mar 5 12:53:40 2008 From: wsiegrist at apple.com (William Siegrist) Date: Wed, 05 Mar 2008 12:53:40 -0800 Subject: Splitting the guide In-Reply-To: <47CEDB7B.6030600@macports.org> References: <20080304232006.GB415@ruderich.com> <47CE48A8.3030308@macports.org> <20080305165539.GA2577@ruderich.com> <47CEDB7B.6030600@macports.org> Message-ID: <2101735E-F312-4D6D-B17E-23C9EB690F4C@apple.com> Its handled via the Makefile. The post-commit job performs 1 copy when make is done: cp doc-new/guide/html/* So if you make subdirectories, I'll add a -R, otherwise it should work. -Bill On Mar 5, 2008, at 9:42 AM, Rainer M?ller wrote: > Simon Ruderich wrote: >> This shouldn't be a problem. I already modified my local Makefile >> for the >> documentation generation. The question is how we should provide >> these two >> versions (maybe also a third: a downloadable version of the guide). >> Maybe >> http://guide.macports.org/ should display a selection so the user >> can choose a >> version. > > A selection page would be good, yes. > >> I don't know enough about the server structure. Juan, or anybody >> who knows >> this. What's the best way to add this selection (or something >> similar) and >> what changes needs the Makefile? > > I think currently the guide/html/ directory is made available on http://guide.macports.org > . I am CC'ing Bill to confirm that :-) > > So we could add like > * guide/html/one-page/ > * guide/html/multipage/ > With guide/html/index.html being some static selection page. > > Rainer ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080305/9636961a/attachment-0001.bin From simon at ruderich.com Wed Mar 5 14:41:54 2008 From: simon at ruderich.com (Simon Ruderich) Date: Wed, 5 Mar 2008 23:41:54 +0100 Subject: Splitting the guide In-Reply-To: <47CED506.9090804@macports.org> References: <20080304232006.GB415@ruderich.com> <47CED506.9090804@macports.org> Message-ID: <20080305224154.GC3694@ruderich.com> On Wed, Mar 05, 2008 at 06:14:46PM +0100, Rainer M?ller wrote: > Hi Simon, > > Simon Ruderich wrote: >> I just created a chunked version of the guide and uploaded it on my homepage: >> http://ruderich.com/macports/chunked/ > > Looks good so far. But I would like the TOC to be on each page for easier > switching of chapters. Could the current chapter be marked inside the list > then? Also, as said before, Back/Next/Up links would be nice-to-have. See my mail to Juan about the table of contents. > I think you just used the chunked docbook XSL? Do you have any experience > with XSL and are you able to improve that? :-) > > Rainer Yes, I used the chunked version. But my experience with XSL is basic at best. I did some minor changes for the man pages but that is all. If someone can help me with the XSL for the guide I would be very happy. Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080305/d4fe39da/attachment.bin From markd at macports.org Wed Mar 5 18:38:51 2008 From: markd at macports.org (markd at macports.org) Date: Wed, 05 Mar 2008 18:38:51 -0800 Subject: Splitting the guide Message-ID: > Simon, I like it and I still think the entire thing in a single >page >is a bit too much, but I would like to go over what Mark originally >replied 'cause he did raise some valid points there (and it's been a >while and I don't remember them at the moment ;-). One thing I would >comment about your alternative, however, is with respect to the >sidebar. Is is possible to keep it with us in every single chapter- >page? At the moment we see it if we're on the front page, but as soon >as we move to any chapter it disappears, and that's not incredibly >friendly. I didn't really have any special ideas at the time. But I do think the TOC should be easily accessible from any section as already mentioned. Would it be possible to have the TOC float at the side within the chapters? Actually, I'm not sure that is desirable and I've have to see it, but it does seem like switching from the main page to a chapter you get an entirely different look and feel and I think that distracts. Mark From raimue at macports.org Wed Mar 5 18:41:37 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 06 Mar 2008 03:41:37 +0100 Subject: New HOWTO section in the wiki In-Reply-To: References: <47BA1D15.9050907@macports.org> Message-ID: <47CF59E1.4070103@macports.org> js wrote: > HOWTOs I'd like to see there are > - How to upgrate outdated ports most effectively (port upgrade -fun ?) > - How to uninstall MacPorts completely > - How to start writing Portfile Thanks, these are good topics! I added your suggestions to the list in the wiki. But with one exception: I think uninstalling is already covered in the FAQ and is not a "daily usage" thing. Is it? Should we add a "How to uninstall MacPorts" page and just link to that from the FAQ page? I don't want to cover that at multiple places, because it would tend to get out of sync. Rainer From simon at ruderich.com Wed Mar 5 14:25:06 2008 From: simon at ruderich.com (Simon Ruderich) Date: Wed, 5 Mar 2008 23:25:06 +0100 Subject: Splitting the guide In-Reply-To: <47B78089.1020505@macports.org> References: <47B78089.1020505@macports.org> Message-ID: <20080305222505.GA4146@ruderich.com> On Sun, Feb 17, 2008 at 01:32:09AM +0100, Rainer M?ller wrote: > > But as we are talking about the guide, I might also bring up another > issue with the current presentation. I find it difficult to link to > specific headlines. Could the headlines made clickable with a link > target on themself? Or maybe some marker item on mouse-move like trac > does? At the moment I always look into the source to find out how the > anchor was named which is a little bit annoying. Consider this as a > nice-to-have issue ;-) > > I already looked into the generation scripts for this, but it seems to > use a xslt stylesheet provided completely by docbook, so I don't know if > I would have to file my request there... > > Rainer Hi Rainer, I just tried this using DocBook but it didn't work for me. So I used a simple sed replacement to get this working. I created two examples: http://ruderich.com/macports/guide-link.html http://ruderich.com/macports/guide-title.html The first one wraps the sections (h1-h9) in links so you can click on them to see the anchor. The second one adds a title attribute which should display the anchor when you mouse over it for some time. Please tell me which you like more and I will add it to the documentation Makefile to add it to the guide. Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080305/5e933f07/attachment.bin From simon at ruderich.com Wed Mar 5 14:37:11 2008 From: simon at ruderich.com (Simon Ruderich) Date: Wed, 5 Mar 2008 23:37:11 +0100 Subject: Splitting the guide In-Reply-To: References: <20080304232006.GB415@ruderich.com> <47CE48A8.3030308@macports.org> Message-ID: <20080305223711.GA3694@ruderich.com> On Wed, Mar 05, 2008 at 12:52:46PM -0430, Juan Manuel Palacios wrote: > > [snip] > > Simon, I like it and I still think the entire thing in a single page is a > bit too much, but I would like to go over what Mark originally replied > 'cause he did raise some valid points there (and it's been a while and I > don't remember them at the moment ;-). One thing I would comment about your > alternative, however, is with respect to the sidebar. Is is possible to keep > it with us in every single chapter-page? At the moment we see it if we're on > the front page, but as soon as we move to any chapter it disappears, and > that's not incredibly friendly. > > Thanks for the initiative! Regards,... > > -jmpp Hi Juan, I tried to add the sidebar on every page but it didn't work. If anybody knows how this is done with DocBook please tell me. Thanks. What I could do is to modify the html with a simple script (sed or tcl) to add the sidebar on every chunk. What do you think? My main concern with an only chunked version is that searching doesn't work. So I think we should keep a big version and add a chunked version if someone just wants to read some sections. Thanks, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080305/005fde9f/attachment.bin From simon at ruderich.com Wed Mar 5 14:39:34 2008 From: simon at ruderich.com (Simon Ruderich) Date: Wed, 5 Mar 2008 23:39:34 +0100 Subject: Splitting the guide In-Reply-To: <1204706977.5218.1240652709@webmail.messagingengine.com> References: <20080304232006.GB415@ruderich.com> <1204706977.5218.1240652709@webmail.messagingengine.com> Message-ID: <20080305223934.GB3694@ruderich.com> On Wed, Mar 05, 2008 at 09:49:37AM +0100, Lutz Horn wrote: > Hi Simon, > > Nice! Could you add Up links at the top and the bottom of the page? This > would allow the user not only to navigate to the next and previous page > but also back to the TOC. > > Lutz There is a "Home" link at the bottom of the page. I'm not sure how to add an "Home"/"Up" link with DocBook (if somebody does, please tell me), but if we succeed adding the sidebar (table of contents) to every page/chunk this shouldn't be a problem. Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080305/bb23ca91/attachment.bin From markd at macports.org Wed Mar 5 22:39:56 2008 From: markd at macports.org (markd at macports.org) Date: Wed, 05 Mar 2008 22:39:56 -0800 Subject: Splitting the guide Message-ID: >> But as we are talking about the guide, I might also bring up another >> issue with the current presentation. I find it difficult to link to >> specific headlines. Could the headlines made clickable with a link >> target on themself? Or maybe some marker item on mouse-move like trac >> does? At the moment I always look into the source to find out how the >> anchor was named which is a little bit annoying. Consider this as a >> nice-to-have issue ;-) >> >> I already looked into the generation scripts for this, but it seems to >> use a xslt stylesheet provided completely by docbook, so I don't know if >> I would have to file my request there... >> >> Rainer > >Hi Rainer, > >I just tried this using DocBook but it didn't work for me. So I used a >simple >sed replacement to get this working. I created two examples: >http://ruderich.com/macports/guide-link.html >http://ruderich.com/macports/guide-title.html >The first one wraps the sections (h1-h9) in links so you can click on >them to >see the anchor. The second one adds a title attribute which should >display the >anchor when you mouse over it for some time. > >Please tell me which you like more and I will add it to the documentation >Makefile to add it to the guide. I don't understand. The TOC entries are all linkable, and the TOC entries correspond to the titles. What is it that is missing? Mark From raimue at macports.org Thu Mar 6 05:04:48 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 06 Mar 2008 14:04:48 +0100 Subject: Splitting the guide In-Reply-To: References: Message-ID: <47CFEBF0.40901@macports.org> simon at ruderich.com wrote: >> I just tried this using DocBook but it didn't work for me. So I used a >> simple >> sed replacement to get this working. I created two examples: >> http://ruderich.com/macports/guide-link.html I like this one with the links. It makes it easy to get the URL which links exactly to this section. Good work! >> http://ruderich.com/macports/guide-title.html >> The first one wraps the sections (h1-h9) in links so you can click on >> them to >> see the anchor. The second one adds a title attribute which should >> display the >> anchor when you mouse over it for some time. >> >> Please tell me which you like more and I will add it to the documentation >> Makefile to add it to the guide. Thanks a lot, I think this is a real good improvement for the guide. markd at macports.org wrote: > I don't understand. The TOC entries are all linkable, and the TOC entries > correspond to the titles. What is it that is missing? If I want to link to a specific section, it is not easy to find out which anchor it has. By making the headlines links, you can just click on them and copy the URL from the browser. Rainer From ebgssth at gmail.com Thu Mar 6 05:48:09 2008 From: ebgssth at gmail.com (js) Date: Thu, 6 Mar 2008 22:48:09 +0900 Subject: RFC: MacPorts Filesystem Hierarchy Standard In-Reply-To: <47CD64BC.5020606@macports.org> References: <47CD64BC.5020606@macports.org> Message-ID: > > I wrote the Filename hierarchy standard for MacPorts. > > I know there's already porthier(7), but I thought it would be nice > > to have more specific standard. > > So is this meant to replace porthier(7)? Than you should write it up as > a patch for the manual page. I don't think we need yet another place for > it. Coordinate with markd and simon on this. No, I meant to replace hier part of the Guide. After this change, porthier change would be followed. > > This document defines the standard placement of file and directory > > installed by MacPorts. This document also intended to replace the > > existing porthier(7)[1]. Every ports in MacPorts project should follow > > this standard. Most of this based on hier(7)[2]. > > Why are you referencing to OpenBSD hier? Mac OS X also has a man page > `hier'. In my experience, OpenBSD is the most rigid system with high quality documentations. That's why I refered to it. > > Naming Convension > > > > When two or more ports have files in common, e.g. apachectl in apache > > and apache2, each port must prepend the part of its major version > > number to the files as a suffix. (e.g. apachectl for apache, > > apachectl2 for apapche2) > > Append, not prepend. Bad English writer... Thanks. > > Everything installed by MacPorts must be in /opt/local or > > /Applications/MacPorts. The former is used for non-aqua applications > > and may be changed by modifying macports.conf. The latter is for aqua > > applications and cannot be changed. > > Write ${prefix} instead of /opt/local, or if it goes into the man page, > it could be expanded during install. > > The applications dir should be changeable in future versions, but at the > moment it is still hardcoded in ports, so this is right. I'll change this line like "${prefix}, which is changeable and default to /opt/local" > > - db > > Miscellaneous, automatically generated system-specific database > > files. For example, ... what? > > (Note that currently mysql data directory is created here. This is > > not correct.) > > No idea what is meant to reside here. Sure, mysqlX could also go into > var/mysqlX. BSDs save system-specific data like locate.database here. might be good place to put macports dir. From Emil.Lundberg at bmc.uu.se Thu Mar 6 05:53:21 2008 From: Emil.Lundberg at bmc.uu.se (Emil Lundberg) Date: Thu, 6 Mar 2008 14:53:21 +0100 Subject: universal broken in trunk Message-ID: <84A2C7DF-67DB-41FB-A916-0FF1911C44B2@bmc.uu.se> In wanting to play around some more with 64-bit macports, I've installed 1.7 trunk (rev. 34799) from SVN on my PPC G5, 10.5.1. Installation went well but when I try to use the "universal" variant (no 64-bit stuff yet!) it breaks, like so: # port -d install jpeg +universal DEBUG: Found port in file:///opt/local/var/macports/sources/ rsync.macports.org/release/ports/graphics/jpeg DEBUG: Changing to port directory: /opt/local/var/macports/sources/ rsync.macports.org/release/ports/graphics/jpeg DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: Requested variant powerpc is not provided by port jpeg. DEBUG: Requested variant darwin is not provided by port jpeg. DEBUG: Requested variant macosx is not provided by port jpeg. DEBUG: Executing variant universal provides universal DEBUG: can't read "configure.universal_cflags": can't read "configure.universal_target": no such variable while executing "eval configure.cflags-append ${configure.universal_cflags}" (procedure "variant-universal" line 13) invoked from within "variant-universal" invoked from within "catch "variant-${name}" result" Error: Error executing universal: can't read "configure.universal_cflags": can't read "configure.universal_target": no such variable DEBUG: Error evaluating variants while executing "error "Error evaluating variants"" (procedure "mportopen" line 51) invoked from within "mportopen $porturl [array get options] [array get variations]" Error: Unable to open port: Error evaluating variants Same thing happens with any port if I set "+universal" in variants.conf. This all works fine on a different machine (PPC, G5, 10.4.11, trunk rev. 34088). Does anyone have a clue? TIA, /Emil From raimue at macports.org Thu Mar 6 06:04:04 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 06 Mar 2008 15:04:04 +0100 Subject: RFC: MacPorts Filesystem Hierarchy Standard In-Reply-To: References: <47CD64BC.5020606@macports.org> Message-ID: <47CFF9D4.4020205@macports.org> js wrote: >>> - db >> > Miscellaneous, automatically generated system-specific database >> > files. For example, ... what? >> > (Note that currently mysql data directory is created here. This is >> > not correct.) >> >> No idea what is meant to reside here. Sure, mysqlX could also go into >> var/mysqlX. > > BSDs save system-specific data like locate.database here. > might be good place to put macports dir. var/macports moved from var/db/dports in the DarwinPorts -> MacPorts rename effort. Rainer From ebgssth at gmail.com Thu Mar 6 08:48:03 2008 From: ebgssth at gmail.com (js) Date: Fri, 7 Mar 2008 01:48:03 +0900 Subject: RFC: MacPorts Filesystem Hierarchy Standard In-Reply-To: <47CFF9D4.4020205@macports.org> References: <47CD64BC.5020606@macports.org> <47CFF9D4.4020205@macports.org> Message-ID: > > BSDs save system-specific data like locate.database here. > > might be good place to put macports dir. > > var/macports moved from var/db/dports in the DarwinPorts -> MacPorts > rename effort. Any reason? From markd at macports.org Thu Mar 6 09:33:18 2008 From: markd at macports.org (markd at macports.org) Date: Thu, 06 Mar 2008 09:33:18 -0800 Subject: RFC: MacPorts Filesystem Hierarchy Standard Message-ID: >> > I wrote the Filename hierarchy standard for MacPorts. >> > I know there's already porthier(7), but I thought it would be nice >> > to have more specific standard. >> >> So is this meant to replace porthier(7)? Than you should write it up as >> a patch for the manual page. I don't think we need yet another place >for >> it. Coordinate with markd and simon on this. > >No, I meant to replace hier part of the Guide. >After this change, porthier change would be followed. > >> > This document defines the standard placement of file and directory >> > installed by MacPorts. This document also intended to replace the >> > existing porthier(7)[1]. Every ports in MacPorts project should >follow >> > this standard. Most of this based on hier(7)[2]. The hier part of the guide is meant to provide the source for the porthier.7 man page. It doesn't right now, but we are intending to base all manpages on the guide very shortly, so changing the guide is how to get the man pages changed. Right now the guide has the most up-to-date information because of this pending new way. > I'm not really qualified to comment on the technical merits of your proposal. But I'd be happy to look over what you've written for style and format if it passes approval by our base developers. Mark From raimue at macports.org Thu Mar 6 10:00:48 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 06 Mar 2008 19:00:48 +0100 Subject: Python framework transition Message-ID: <47D03150.7040508@macports.org> Hi Thomas, Following the IRC discussion from today with afb and mdickens, I wrote together a wiki page which documents how we want to do the transition to build pythonXX as frameworks. http://trac.macosforge.org/projects/macports/wiki/PythonFrameworkTransition Any comments so far? Also see the new branch at branches/python-frameworks. I already committed the efforts from #11267 there. With the branch, we can easily test the transition code. Rainer From bwaters at nrao.edu Thu Mar 6 10:34:03 2008 From: bwaters at nrao.edu (Boyd Waters) Date: Thu, 6 Mar 2008 11:34:03 -0700 Subject: Python framework transition In-Reply-To: <47D03150.7040508@macports.org> References: <47D03150.7040508@macports.org> Message-ID: <26756254-5B46-414C-B5E7-5596105F1A51@nrao.edu> > ? because we change lib/python2.5 from a directory into a symlink. > Otherwise you will see errors with file_map.db. > ? Because of the directory-to-symlink change, deactivate/activate > does not work. This will be the main challenge. > I think that this is why I haven't committed anything; I've been building all Python 2.5 stuff via MacPorts as a framework build for about a year now. I had to modify all of my Python ports that I use so that they understand the symlink. I attempted to modify MacPorts Tcl so that it would not die as it attempted to traverse a symlink, but I failed. I must not understand Tcl very well. I am pretty sure I don't understand all the issues, I still think that MacPorts versioning (-24, -25, -30) is profoundly flawed, aside from installation issues. But I'd be happy to show my awful hacked-up Python ports... - boyd Boyd Waters Scientific Programmer National Radio Astronomy Observatory Socorro, New Mexico On Mar 6, 2008, at 11:00 AM, Rainer M?ller wrote: > Hi Thomas, > > Following the IRC discussion from today with afb and mdickens, I wrote > together a wiki page which documents how we want to do the > transition to > build pythonXX as frameworks. > > http://trac.macosforge.org/projects/macports/wiki/PythonFrameworkTransition > > Any comments so far? > > Also see the new branch at branches/python-frameworks. I already > committed the efforts from #11267 there. With the branch, we can > easily > test the transition code. > > Rainer > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From raimue at macports.org Thu Mar 6 10:48:44 2008 From: raimue at macports.org (=?windows-1252?Q?Rainer_M=FCller?=) Date: Thu, 06 Mar 2008 19:48:44 +0100 Subject: Python framework transition In-Reply-To: <26756254-5B46-414C-B5E7-5596105F1A51@nrao.edu> References: <47D03150.7040508@macports.org> <26756254-5B46-414C-B5E7-5596105F1A51@nrao.edu> Message-ID: <47D03C8C.6070409@macports.org> Boyd Waters wrote: > I think that this is why I haven't committed anything; I've been > building all Python 2.5 stuff via MacPorts as a framework build for > about a year now. > > I had to modify all of my Python ports that I use so that they > understand the symlink. Should be working out-of-the-box, once the python25 port group gets updated to install directly into the framework. > I attempted to modify MacPorts Tcl so that it would not die as it > attempted to traverse a symlink, but I failed. I must not understand > Tcl very well. It is not a problem of traversing the symlink, but the file_map.db stores the information that a symlink owned by pyhon25 is at this place. If a py25-* port tries to make a directory at this place, it will fail. > I am pretty sure I don't understand all the issues, I still think that > MacPorts versioning (-24, -25, -30) is profoundly flawed, aside from > installation issues. Do you have any other solution? This is a bit unrelated to the framework transition. Multiple versions of the same software also apply to gcc and perl. Rainer From bwaters at nrao.edu Thu Mar 6 11:16:54 2008 From: bwaters at nrao.edu (Boyd Waters) Date: Thu, 6 Mar 2008 12:16:54 -0700 Subject: Versioned ports (again) In-Reply-To: <47D03C8C.6070409@macports.org> References: <47D03150.7040508@macports.org> <26756254-5B46-414C-B5E7-5596105F1A51@nrao.edu> <47D03C8C.6070409@macports.org> Message-ID: Rainer: Thanks for the clarification! Ah, I see... put things in the portgroup. Of course... On Mar 6, 2008, at 11:48 AM, Rainer M?ller wrote: >> I am pretty sure I don't understand all the issues, I still think >> that MacPorts versioning (-24, -25, -30) is profoundly flawed, >> aside from installation issues. > > Do you have any other solution? This is a bit unrelated to the > framework transition. Multiple versions of the same software also > apply to gcc and perl. Well, I don't want to kick over old sand, but I came to MacPorts after years of Gentoo on Linux. It may not seem like a big deal to have some port dirs with versions, and some without, but I find it quite difficult to manage. I prefer having the Port *files* have versions. The way MacPorts manages the *installation* of gcc versions is fine: * specify a trailing version specifier on the files or dirs that get installed: for example gcc-mp-4.2 * provide a "packagename-select" utility to modify symlinks that point gcc -> gcc-mp-4.2 (among other things) Gentoo also had this notion of "provides" and "slots". I haven't used Gentoo for a while, so I'm trying to think of an example relevant to MacPorts. Well, I know that the Python Tkinter port has a variant to use the system (OS X-provided) Tk, rather than a MacPorts one. Another example might be X11 packages, or GCC (Apple 4.x versus MacPorts 4.x) -- the idea that a port dep can be satisfied by something that occupies a certain "slot" or "role", rather than a specific file at a specific location. So the GCC 4.x dependency could be satisfied by either Apple's or MacPort's package. Not a great example, perhaps someone else can help explain. But I don't think it's OK to add a specific version number to each port dir, without some notion of "slot". Port groups are some of that, but upside-down, as every leaf-level port needs to be aware of a particular port group. For example I've been hacking through the Python ports on Leopard, teaching them about the Apple-supplied Python 2.5.1... I added a port group "python-25-apple" to make that happen, but now I need to touch *every* python port and change their port group membership. In this case, it isn't a version: both the MacPort and the Apple Pythons are 2.5.1. It's something else, and the leaf- level ports should NOT have to know about that. I felt comfortable contributing Gentoo ports, because I could add versions or whatnot without changing the whole framework, and it was easy to drop something in. I have been quite nervous about perturbing the MacPorts, because if I have a different notion of Python deployment (for example) then that's too destructive, the framework has to be changed a bit to accommodate that, and certainly not everyone is going to want to do it my way. But I can't provide easy hooks to switch between my way and the default way. I hope these comments help. I suspect they won't make any sense to people who haven't used Gentoo much. It's not the same thing as the FreeBSD ports tree. Thanks! - boyd Boyd Waters http://www.aoc.nrao.edu/~bwaters From ebgssth at gmail.com Fri Mar 7 07:01:31 2008 From: ebgssth at gmail.com (js) Date: Sat, 8 Mar 2008 00:01:31 +0900 Subject: RFC: MacPorts Filesystem Hierarchy Standard In-Reply-To: References: Message-ID: > The hier part of the guide is meant to provide the source for the > porthier.7 man page. It doesn't right now, but we are intending to base > all manpages on the guide very shortly, so changing the guide is how to > get the man pages changed. Right now the guide has the most up-to-date > information because of this pending new way. It would be nice. > I'm not really qualified to comment on the technical merits of your > proposal. But I'd be happy to look over what you've written for style and > format if it passes approval by our base developers. The main advantage I hope this guideline would bring to MacPorts is consistency. No one wants to be in an inconsistent filesystem. Unfortunately MacPorts filesystem is not so good at this point. Let's say I just installed mysql5 and apache2. Where's the configuration files? for mysq5, It's located in ${prefix}/etc/mysql5 by default. for apache2 ${prefix}/apache2/conf/ by default. Where's the log files? mysql5 uses /opt/local/var/db/mysql5 apache2 uses /opt/local/apache2/logs/ Who can say MacPorts' filesystem is consistent? If MacPorts had a strict hier guideline and the project recommended port developer to follow that guide, every conf would be in ${prefix}/etc/${name}/, logs in ${prefix}/var/logs/${name}. It's so clear and easy to remember where to look at when I need it. I believe this would improve MacPorts's usability so much. From ebgssth at gmail.com Fri Mar 7 07:22:42 2008 From: ebgssth at gmail.com (js) Date: Sat, 8 Mar 2008 00:22:42 +0900 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't In-Reply-To: References: <047.9fe0e7798e644f83e5bea8fec8b4d764@macosforge.org> <056.59f733d9934ac6e311002f4555f790ca@macosforge.org> <47B9B1FF.7080105@macports.org> <6B342869-BC6E-48D4-960A-254D89BE16AC@macports.org> Message-ID: Apparently more people like this change. I'll get back to trac ticket and start working on this. On Thu, Feb 21, 2008 at 12:39 AM, js wrote: > > > Thanks for thorough explanation. That makes sense. > > > The reason why I started this discussion is that > > > I want to make python24 to be python25-like port. > > > What if I created patches for this, > > > Would you accept that changes? > > > > > > > well, what else do you want to change? There already are py-bsddb, py- > > readline, .. which provide modules not build by default (by the > > python24 port). > > I'd like to drop modules from python24 the same way python25 do currently. > This would help writing Portfile for python2[45] easier. > > > > > If you _really_ don't bother which python you end up with (and it > > doesn't matter if that changes), then you can use the "python_select: > > port to do just that. > > It basically provides symlinks to the real executables which you can > > change by calling python_select(1). > > Attention: If your port makes note of the exact location of you python > > executable, this might create an implicit dependency (which will cause > > breakage if you uninstall the "wrong" python) > > No, I don't want default python on MacPorts. > Explicit python24 and python25 would be clearer. > just wanted to say python-minimal + py25-* ports would be nice. > > > > > To be honest, I also want to change py- prefix ports to py24- > > > but this plan is rejected recently... > > > > Rejected? Most probably due to the amount of work on both the project > > and the users' side. > > I think this would be cool, but if someone tackles this: Do a single > > commit on _all_ renamed ports and ports that depend on those AND write > > a mail to macports-users@ AND put something on the FAQ how to handle > > potential breakage. > > If I prepared patches for this, would you bother to review/accept them? > From raimue at macports.org Fri Mar 7 07:48:57 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 07 Mar 2008 16:48:57 +0100 Subject: RFC: MacPorts Filesystem Hierarchy Standard In-Reply-To: References: Message-ID: <47D163E9.4070202@macports.org> js wrote: > Let's say I just installed mysql5 and apache2. > > Where's the configuration files? > for mysq5, It's located in ${prefix}/etc/mysql5 by default. > for apache2 ${prefix}/apache2/conf/ by default. > > Where's the log files? > mysql5 uses /opt/local/var/db/mysql5 > apache2 uses /opt/local/apache2/logs/ That's a special case for apache2 there we came to the conclusion that it should be changed. Rainer From jberry at macports.org Fri Mar 7 08:38:00 2008 From: jberry at macports.org (James Berry) Date: Fri, 7 Mar 2008 08:38:00 -0800 Subject: Google SoC 2008 In-Reply-To: <8C51D842-0EB6-48B0-A7E6-1C4CF23FB791@macports.org> References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> <8C51D842-0EB6-48B0-A7E6-1C4CF23FB791@macports.org> Message-ID: I haven't heard back from anybody regarding this plea/opportunity. I don't have time to shepherd GSoC this year. If no body steps up to do so, or to be mentors, I'm going to let this opportunity slide by. Deadline for us to apply to Google, with projects in hand, is next Wednesday, March 12. Anybody? James On Mar 4, 2008, at 8:27 AM, James Berry wrote: > Thanks to everybody who pitched ideas for GSoC 2008. > > Now the rubber needs to meet the road. We need: > > - Somebody to head up our GSoC 2008 effort (get us signed up with > Google, document the proposed projects, etc). > - And committed mentors for any projects. > > Volunteers? > > As Paul Guyot points out, one thing we found last year was that > google seems to allocate project funding to a project based on the > total number of student applications. So a project that gets > applications from 50 students is likely to be allocated more student > slots than a project that gets only 3 student applications. The > number of student applications is probably guided in part by several > factors: promotion and appeal to the student community; number and > appeal of project proposals; etc. > > James > > > > On Feb 29, 2008, at 3:48 PM, James Berry wrote: > >> I'm writing to attempt to gauge interest in whether and how MacPorts >> should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ >> . >> >> You might be inclined to address any of the following questions: >> >> - Do you feel MacPorts should participate in GSoC 2008? >> - Are there particular MacPorts projects you'd like to suggest? >> - Are you willing to be a GSoC mentor? >> - Would you be interested, as a student, in participating in a GSoC >> project for MacPorts? >> >> GSoC pays students a wage for the summer to work on open source >> projects, and also a stipend to the project for each student project. >> >> If interested, we need to move very quickly. As the Google GSoC FAQ >> says: >> >> "We'll begin accepting applications from open source mentoring >> organizations on Monday, March 3, 2008; we'll stop accepting >> organization applications on Wednesday, March 12th." >> >> Your feedback is welcome >> >> James >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From blair at orcaware.com Fri Mar 7 09:07:31 2008 From: blair at orcaware.com (Blair Zajac) Date: Fri, 07 Mar 2008 09:07:31 -0800 Subject: Pre-commit script to reject commits Message-ID: <47D17653.4090108@orcaware.com> I was thinking that we should have a pre-commit script reject commits if a portfile does not increment a revision or version if it changes any of its depends_*. I find this pretty annoying to see commits that add a dependency that don't bump a version or revision. Any other things we should reject commits on? Blair From raimue at macports.org Fri Mar 7 09:58:28 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 07 Mar 2008 18:58:28 +0100 Subject: Pre-commit script to reject commits In-Reply-To: <47D17653.4090108@orcaware.com> References: <47D17653.4090108@orcaware.com> Message-ID: <47D18244.6070209@macports.org> Blair Zajac wrote: > I was thinking that we should have a pre-commit script reject commits if a > portfile does not increment a revision or version if it changes any of its > depends_*. I find this pretty annoying to see commits that add a dependency > that don't bump a version or revision. I don't see why changing depends_* should change the revision. Either it prevented the installation at all or users installed the dependency by hand before. It doesn't change the files which are going to be installed. Incrementing the revision would force them to do an unnecessary recompile. The only thing I can think of is that the output of `port dependents' could be 'wrong'. But that's reflecting the state of the port as it was installed, so it is kind of correct. Rainer From blair at orcaware.com Fri Mar 7 10:08:23 2008 From: blair at orcaware.com (Blair Zajac) Date: Fri, 07 Mar 2008 10:08:23 -0800 Subject: Pre-commit script to reject commits In-Reply-To: <47D18244.6070209@macports.org> References: <47D17653.4090108@orcaware.com> <47D18244.6070209@macports.org> Message-ID: <47D18497.2070003@orcaware.com> Rainer M?ller wrote: > Blair Zajac wrote: >> I was thinking that we should have a pre-commit script reject commits >> if a portfile does not increment a revision or version if it changes >> any of its depends_*. I find this pretty annoying to see commits that >> add a dependency that don't bump a version or revision. > > I don't see why changing depends_* should change the revision. Either it > prevented the installation at all or users installed the dependency by > hand before. It doesn't change the files which are going to be > installed. Incrementing the revision would force them to do an > unnecessary recompile. > > The only thing I can think of is that the output of `port dependents' > could be 'wrong'. But that's reflecting the state of the port as it was > installed, so it is kind of correct. If you have the base port installed, say libfoo, but it's not listed as a dependency, then if you remove it, then you'll unintentionally break any ports that picked up a dependency upon it at configure time. Blair From raimue at macports.org Fri Mar 7 10:24:08 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 07 Mar 2008 19:24:08 +0100 Subject: Pre-commit script to reject commits In-Reply-To: <47D18497.2070003@orcaware.com> References: <47D17653.4090108@orcaware.com> <47D18244.6070209@macports.org> <47D18497.2070003@orcaware.com> Message-ID: <47D18848.2000604@macports.org> Blair Zajac wrote: > If you have the base port installed, say libfoo, but it's not listed as a > dependency, then if you remove it, then you'll unintentionally break any ports > that picked up a dependency upon it at configure time. Thanks for the clarification, I think you are kind of right. But it will always hit someone not affected by the update. For example, changing depends_* inside some variants and incrementing the revsion forces all users to recompile - even if they don't use this variant... As an additional comment, I don't think port lint is yet stable enough to be used as a commit filter (rejecting commits not passing port lint). Rainer From ryandesign at macports.org Fri Mar 7 11:07:25 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 7 Mar 2008 13:07:25 -0600 Subject: Pre-commit script to reject commits In-Reply-To: <47D18848.2000604@macports.org> References: <47D17653.4090108@orcaware.com> <47D18244.6070209@macports.org> <47D18497.2070003@orcaware.com> <47D18848.2000604@macports.org> Message-ID: <3BF62055-542C-45AD-A3A8-27636073F72B@macports.org> On Mar 7, 2008, at 12:24, Rainer M?ller wrote: > Blair Zajac wrote: > >> If you have the base port installed, say libfoo, but it's not >> listed as a >> dependency, then if you remove it, then you'll unintentionally >> break any ports >> that picked up a dependency upon it at configure time. > > Thanks for the clarification, I think you are kind of right. But it > will > always hit someone not affected by the update. For example, changing > depends_* inside some variants and incrementing the revsion forces all > users to recompile - even if they don't use this variant... And yet, incrementing the revision is the correct thing to do, if doing so will fix the install for even just a few users, even at the risk of unnecessarily rebuilding the port for others. For example, perl5.8 was updated from revision 1 to 2 in r34508. As I understand it, the change was irrelevant for those using gcc 4.0 (i.e. at least all Mac users), but was necessary for those using gcc 4.2 (perhaps Linux or FreeBSD users). Oh well. I'm not sure such a pre-commit hook is practical to write. How would one write it? > As an additional comment, I don't think port lint is yet stable enough > to be used as a commit filter (rejecting commits not passing port > lint). I agree, but my plan wasn't ever to reject commits based on port lint. It should be as it is now: an informational post-commit task. From jkh at apple.com Fri Mar 7 11:14:52 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Fri, 7 Mar 2008 11:14:52 -0800 Subject: Google SoC 2008 In-Reply-To: References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> <8C51D842-0EB6-48B0-A7E6-1C4CF23FB791@macports.org> Message-ID: Gah! If it's me or nobody, I'll do it. :-) We really shouldn't let the opportunity just slip through our fingers. Hey, Jumpy, where are you? :-) - Jordan On Mar 7, 2008, at 8:38 AM, James Berry wrote: > I haven't heard back from anybody regarding this plea/opportunity. > > I don't have time to shepherd GSoC this year. If no body steps up to > do so, or to be mentors, I'm going to let this opportunity slide by. > Deadline for us to apply to Google, with projects in hand, is next > Wednesday, March 12. > > Anybody? > > James > > On Mar 4, 2008, at 8:27 AM, James Berry wrote: > >> Thanks to everybody who pitched ideas for GSoC 2008. >> >> Now the rubber needs to meet the road. We need: >> >> - Somebody to head up our GSoC 2008 effort (get us signed up with >> Google, document the proposed projects, etc). >> - And committed mentors for any projects. >> >> Volunteers? >> >> As Paul Guyot points out, one thing we found last year was that >> google seems to allocate project funding to a project based on the >> total number of student applications. So a project that gets >> applications from 50 students is likely to be allocated more student >> slots than a project that gets only 3 student applications. The >> number of student applications is probably guided in part by several >> factors: promotion and appeal to the student community; number and >> appeal of project proposals; etc. >> >> James >> >> >> >> On Feb 29, 2008, at 3:48 PM, James Berry wrote: >> >>> I'm writing to attempt to gauge interest in whether and how MacPorts >>> should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ >>> . >>> >>> You might be inclined to address any of the following questions: >>> >>> - Do you feel MacPorts should participate in GSoC 2008? >>> - Are there particular MacPorts projects you'd like to suggest? >>> - Are you willing to be a GSoC mentor? >>> - Would you be interested, as a student, in participating in a GSoC >>> project for MacPorts? >>> >>> GSoC pays students a wage for the summer to work on open source >>> projects, and also a stipend to the project for each student >>> project. >>> >>> If interested, we need to move very quickly. As the Google GSoC FAQ >>> says: >>> >>> "We'll begin accepting applications from open source mentoring >>> organizations on Monday, March 3, 2008; we'll stop accepting >>> organization applications on Wednesday, March 12th." >>> >>> Your feedback is welcome >>> >>> James >>> _______________________________________________ >>> macports-dev mailing list >>> macports-dev at lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From markd at macports.org Fri Mar 7 15:05:36 2008 From: markd at macports.org (markd at macports.org) Date: Fri, 07 Mar 2008 15:05:36 -0800 Subject: Pre-commit script to reject commits Message-ID: >> Thanks for the clarification, I think you are kind of right. But it >> will >> always hit someone not affected by the update. For example, changing >> depends_* inside some variants and incrementing the revsion forces all >> users to recompile - even if they don't use this variant... > >And yet, incrementing the revision is the correct thing to do, if >doing so will fix the install for even just a few users, even at the >risk of unnecessarily rebuilding the port for others. For example, >perl5.8 was updated from revision 1 to 2 in r34508. As I understand >it, the change was irrelevant for those using gcc 4.0 (i.e. at least >all Mac users), but was necessary for those using gcc 4.2 (perhaps >Linux or FreeBSD users). Oh well. I don't think we're all have the same understanding of when the port revision number should be incremented. If there are guidelines we could all agree to it could be documented, and (along with some nagging) we'd probably see a lot less variance, not that automation wouldn't be fine too. Mark From ebgssth at gmail.com Fri Mar 7 15:47:57 2008 From: ebgssth at gmail.com (js) Date: Sat, 8 Mar 2008 08:47:57 +0900 Subject: RFC: MacPorts Filesystem Hierarchy Standard In-Reply-To: <47D163E9.4070202@macports.org> References: <47D163E9.4070202@macports.org> Message-ID: > js wrote: > > Let's say I just installed mysql5 and apache2. > > > > Where's the configuration files? > > for mysq5, It's located in ${prefix}/etc/mysql5 by default. > > for apache2 ${prefix}/apache2/conf/ by default. > > > > Where's the log files? > > mysql5 uses /opt/local/var/db/mysql5 > > apache2 uses /opt/local/apache2/logs/ > > That's a special case for apache2 there we came to the conclusion that > it should be changed. Hmm, taking apache2 for example was not fair. Instead, take php5 for example. it installs the followings. /opt/local/etc/php.ini-dist /opt/local/etc/php.ini-recommended From ebgssth at gmail.com Fri Mar 7 20:55:18 2008 From: ebgssth at gmail.com (js) Date: Sat, 8 Mar 2008 13:55:18 +0900 Subject: py-twistedweb2 and py25-twisted-web2 uses different name convension In-Reply-To: References: <1578ADF8-7075-4E12-8B26-7EF3931628CB@macports.org> <081DE1AD-319D-4D10-BC09-EF36773A594F@macports.org> Message-ID: BTW, Twisted Web2 is still under development and recommend using svn trunk until next release. So I assume there're not so many people using twisted web2 port. I think now is the time to fix this portname. On Tue, Mar 4, 2008 at 9:27 PM, js wrote: > Then, is my request rejected? > Who has the power to decide this kind of issue? > > > > On Sat, Mar 1, 2008 at 6:07 AM, Ryan Schmidt wrote: > > On Feb 29, 2008, at 14:33, Kevin Ballard wrote: > > > > > On Feb 29, 2008, at 3:28 PM, Ryan Schmidt wrote: > > > > > >> On Feb 29, 2008, at 09:20, js wrote: > > >> > > >>> I noticed that twisted for python2.4 and 2.5 uses different name > > >>> convension. > > >>> I opened new ticket http://trac.macosforge.org/projects/macports/ > > >>> ticket/14375 > > >>> > > >>> Shouldn' they use the same convension? > > >> > > >> Sure, it would make sense for the common parts of the port name to > > >> be the same. > > > > > > > > The problem is this breaks the upgrade path. Anybody with py25- > > > twisted- > > > web2 will lose the ability to update their port if it gets renamed to > > > py25-twistedweb2. They'll have to discover this problem on their own > > > and uninstall py25-twisted-web2 and install py25-twistedweb2. > > > > > > The only workaround I can think of for this is to push a dummy update > > > for py25-twisted-web2 that errors out on fetch with a message saying > > > to uninstall and reinstall py25-twistedweb2, but that's ugly and > > > unfriendly. > > > > Still wish we had the "superseded_by" feature in MacPorts base so it > > would be easier to rename a port: > > > > http://lists.macosforge.org/pipermail/macports-dev/2007-July/002219.html > > > > http://lists.macosforge.org/pipermail/macports-dev/2007-December/ > > 003767.html > > > > > > _______________________________________________ > > macports-dev mailing list > > macports-dev at lists.macosforge.org > > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > From ebgssth at gmail.com Fri Mar 7 21:02:37 2008 From: ebgssth at gmail.com (js) Date: Sat, 8 Mar 2008 14:02:37 +0900 Subject: py-twistedweb2 and py25-twisted-web2 uses different name convension In-Reply-To: References: <1578ADF8-7075-4E12-8B26-7EF3931628CB@macports.org> <081DE1AD-319D-4D10-BC09-EF36773A594F@macports.org> Message-ID: More people apparently agreed this change. I attached the fix below. http://trac.macosforge.org/projects/macports/ticket/14375 Closing this discussion. On Sat, Mar 8, 2008 at 1:55 PM, js wrote: > BTW, Twisted Web2 is still under development and > recommend using svn trunk until next release. > So I assume there're not so many people using twisted web2 port. > I think now is the time to fix this portname. > > > > On Tue, Mar 4, 2008 at 9:27 PM, js wrote: > > Then, is my request rejected? > > Who has the power to decide this kind of issue? > > > > > > > > On Sat, Mar 1, 2008 at 6:07 AM, Ryan Schmidt wrote: > > > On Feb 29, 2008, at 14:33, Kevin Ballard wrote: > > > > > > > On Feb 29, 2008, at 3:28 PM, Ryan Schmidt wrote: > > > > > > > >> On Feb 29, 2008, at 09:20, js wrote: > > > >> > > > >>> I noticed that twisted for python2.4 and 2.5 uses different name > > > >>> convension. > > > >>> I opened new ticket http://trac.macosforge.org/projects/macports/ > > > >>> ticket/14375 > > > >>> > > > >>> Shouldn' they use the same convension? > > > >> > > > >> Sure, it would make sense for the common parts of the port name to > > > >> be the same. > > > > > > > > > > > The problem is this breaks the upgrade path. Anybody with py25- > > > > twisted- > > > > web2 will lose the ability to update their port if it gets renamed to > > > > py25-twistedweb2. They'll have to discover this problem on their own > > > > and uninstall py25-twisted-web2 and install py25-twistedweb2. > > > > > > > > The only workaround I can think of for this is to push a dummy update > > > > for py25-twisted-web2 that errors out on fetch with a message saying > > > > to uninstall and reinstall py25-twistedweb2, but that's ugly and > > > > unfriendly. > > > > > > Still wish we had the "superseded_by" feature in MacPorts base so it > > > would be easier to rename a port: > > > > > > http://lists.macosforge.org/pipermail/macports-dev/2007-July/002219.html > > > > > > http://lists.macosforge.org/pipermail/macports-dev/2007-December/ > > > 003767.html > > > > > > > > > _______________________________________________ > > > macports-dev mailing list > > > macports-dev at lists.macosforge.org > > > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > > > > From afb at macports.org Sat Mar 8 00:31:22 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sat, 8 Mar 2008 09:31:22 +0100 Subject: RFC: MacPorts Filesystem Hierarchy Standard In-Reply-To: References: <47D163E9.4070202@macports.org> Message-ID: js wrote: >> That's a special case for apache2 there we came to the conclusion >> that >> it should be changed. > > Hmm, taking apache2 for example was not fair. > Instead, take php5 for example. > it installs the followings. > > /opt/local/etc/php.ini-dist > /opt/local/etc/php.ini-recommended The current system has a problem with configuration files, so it can only install sample/documentation configuration or it would overwrite any settings the user has done... In this case, it needs copying to php.ini to take effect. http://trac.macports.org/projects/macports/ticket/12797 http://trac.macports.org/projects/macports/ticket/2365 Using package managers such as RPM/DEB handles all these, and systems such as Ports uses install/deinstall scripts. --anders From meissnem at gmail.com Sat Mar 8 14:37:49 2008 From: meissnem at gmail.com (Matthew K. Meissner) Date: Sat, 8 Mar 2008 16:37:49 -0600 Subject: Ticket #14569: update pv Message-ID: <708C1C62-ED2D-4B5D-B5C9-38F4092F29CD@gmail.com> Hi, Would a committer mind taking a look at ticket #14569 and committing it if deemed OK? I submitted the ticket on Thursday and had a user of the port inquire today on the status. Thanks, Matt -- Matt Meissner meissnem at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2419 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080308/a73300eb/attachment-0001.bin From raimue at macports.org Sat Mar 8 15:55:56 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 09 Mar 2008 00:55:56 +0100 Subject: Ticket #14569: update pv In-Reply-To: <708C1C62-ED2D-4B5D-B5C9-38F4092F29CD@gmail.com> References: <708C1C62-ED2D-4B5D-B5C9-38F4092F29CD@gmail.com> Message-ID: <47D3278C.6080401@macports.org> Matthew K. Meissner wrote: > Would a committer mind taking a look at ticket #14569 and committing > it if deemed OK? I submitted the ticket on Thursday and had a user of > the port inquire today on the status. Committed in r34849. Rainer From ebgssth at gmail.com Sat Mar 8 17:49:45 2008 From: ebgssth at gmail.com (js) Date: Sun, 9 Mar 2008 10:49:45 +0900 Subject: Portfile skelton generator? Message-ID: Hi, I've just thought it would be very convenient to have Portfile skelton generator in base MacPorts system. The generator would works this way. Let's say I wanted to add a new port named foo. $ port skelton foo 1.0 > Portfile The content of Portfile would looks like # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 # $Id$ PortSystem 1.0 name foo version 1.0 #categories unknown #maintainers unknown #description unknown #long_description RRDtool is a system to store and display time-series data #homepage homepage #platforms darwin #master_sites # master_sites #checksums md5 \ # sha1 \ # rmd160 #depends_lib ...continued The generated Portfile contains many informative comments to help developers write a good Portfile. Generator itself would be very easy to implement once the skelton file itself was created. Any comments? From simon at ruderich.com Sat Mar 8 13:59:53 2008 From: simon at ruderich.com (Simon Ruderich) Date: Sat, 8 Mar 2008 22:59:53 +0100 Subject: Splitting the guide In-Reply-To: <2101735E-F312-4D6D-B17E-23C9EB690F4C@apple.com> References: <20080304232006.GB415@ruderich.com> <47CE48A8.3030308@macports.org> <20080305165539.GA2577@ruderich.com> <47CEDB7B.6030600@macports.org> <2101735E-F312-4D6D-B17E-23C9EB690F4C@apple.com> Message-ID: <20080308215953.GA9978@ruderich.com> On Wed, Mar 05, 2008 at 12:53:40PM -0800, William Siegrist wrote: > Its handled via the Makefile. The post-commit job performs 1 copy when make > is done: > > cp doc-new/guide/html/* > > So if you make subdirectories, I'll add a -R, otherwise it should work. > > -Bill Hi Bill, thanks for your quick response. It would be perfect if you could make this change (-R) so we can decide which method we use and then just modify the html directory in the guide. Thanks for your help, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080308/a9e2fb0d/attachment.bin From kvv at apple.com Sat Mar 8 20:59:38 2008 From: kvv at apple.com (Kevin Van Vechten) Date: Sat, 08 Mar 2008 20:59:38 -0800 Subject: Portfile skelton generator? In-Reply-To: References: Message-ID: <045A47E4-518C-423A-955B-3CC5D9EFABDF@apple.com> I'd pass a URL to a source archive as the parameter, and then derive the port name and version from that. You could also generate the checksums, etc. - Kevin On Mar 8, 2008, at 5:49 PM, js wrote: > Hi, > > I've just thought it would be very convenient to have Portfile skelton > generator in base MacPorts system. > > The generator would works this way. > Let's say I wanted to add a new port named foo. > > $ port skelton foo 1.0 > Portfile > > The content of Portfile would looks like > > # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; > c-basic-offset: 4 -*- vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 > # $Id$ > PortSystem 1.0 > > name foo > version 1.0 > #categories unknown > #maintainers unknown > #description unknown > #long_description RRDtool is a system to store and display time- > series data > #homepage homepage > #platforms darwin > #master_sites # master_sites > > #checksums md5 \ > # sha1 \ > # rmd160 > > #depends_lib > ...continued > > > The generated Portfile contains many informative comments to help > developers write a good Portfile. > Generator itself would be very easy to implement once the skelton file > itself was created. > > Any comments? From derek at chocolate-fish.com Sun Mar 9 12:30:10 2008 From: derek at chocolate-fish.com (Derek Harland) Date: Mon, 10 Mar 2008 08:30:10 +1300 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js) In-Reply-To: References: Message-ID: On 8/03/2008, at 8:06 AM, macports-dev-request at lists.macosforge.org wrote: > Date: Sat, 8 Mar 2008 00:22:42 +0900 > From: js > Subject: Re: [MacPorts] #14342: python25 drops modules by default, but > python25 doesn't > To: "Markus Weissmann" > Cc: MacPorts Developers > > Apparently more people like this change. > I'll get back to trac ticket and start working on this. I'm not sure I particularly like this proposed change. As I understand it, you explicitly want to *downgrade* the functionality of python24 to make it more like python25, by for example, removing hashlib and zlib. I cannot understand the logic of this. This can only conceivably break python24 installations. Even if all existing py-* ports are altered to bring in extra required dependencies, peoples (and institutions) own proprietary code that previously assumed the existence of these standard libraries will break. And that will annoy them greatly. Why are you proposing to explicitly *downgrade* python24, instead of *upgrading* python25? I also do not buy into the inference that's been made in this thread in the past that more people must be using python25 than python24. For institutions with large proprietary codebases (eg financial companies), shifting python versions *is* a costly business that is not worth the often negligible benefit. I would suggest that many are still running more code off 2.4 than 2.5 (companies I have been involved with have moved from 1.5->20->2.2->2.4->2.6). I'm not suggesting many such companies run code on OSX, but mine certainly is. derek. From yann at daysofwonder.com Sun Mar 9 13:39:11 2008 From: yann at daysofwonder.com (Yann Corno) Date: Sun, 09 Mar 2008 21:39:11 +0100 Subject: Rails 2.0 port ? Message-ID: <47D44AEF.90401@daysofwonder.com> Dear MacPorts developers: Does anyone know if (or when) Ruby on Rails 2.0 will be available in MacPorts ? Thanks for the info. Keep up the wonderful work! Yann. From raimue at macports.org Sun Mar 9 17:07:07 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 10 Mar 2008 01:07:07 +0100 Subject: livecheck not finding latest version In-Reply-To: <20080309192812.GA1574@ruderich.com> References: <799406d60802271141q5d209bd8y70bb47b26e8808c9@mail.gmail.com> <8D34450C-DB62-40DD-A9D4-D006C936BFFC@macports.org> <47C62B2C.7020901@macports.org> <20080309192812.GA1574@ruderich.com> Message-ID: <47D47BAB.6010603@macports.org> Simon Ruderich wrote: > I found another small problem with the livecheck. I have a port in my local > repository which uses ${name}-${version} as livecheck.version. With the > current version it gives me the following. First it says it matched and then > it doesn't. I can also reproduce the issue with e.g. enblend from the macports port tree. [...] > I looked into this and the problem is that [rpm-vercomp $upver > $updated_version] returns -1 if $updated_version is 0 and $upver is something > like fdm-1.5 which is true before any version is found. It works fine for > $upvar 1.5. Hm, you are right. rpm-vercomp just skips any alphabetic characters at the begin of the string if they appear in both versions. > The following patch fixes the problem for me but I'm not sure if it causes any > other problems. Please check if it works fine. > > --- src/port1.0/portlivecheck.tcl (revision 34864) > +++ src/port1.0/portlivecheck.tcl (working copy) > @@ -187,7 +187,7 @@ > while {[gets $chan line] >= 0} { > if {[regexp $the_re $line matched upver]} { > set foundmatch 1 > - if {[rpm-vercomp $upver $updated_version] > 0} { > + if {[rpm-vercomp $upver $updated_version] > 0 || $updated_version == 0} { > set updated_version $upver > } > ui_debug "The regex matched \"$matched\", extracted \"$upver\"" I committed a similar fix in r34874. Rainer From raimue at macports.org Sun Mar 9 18:08:21 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 10 Mar 2008 02:08:21 +0100 Subject: Maintainer away tracking Message-ID: <47D48A05.2080301@macports.org> Hi, It happens from time to time that some maintainer is busy with work or school, has to move, is on vacation or attends some other event which prevents him from taking action on new tickets. So I want to setup a new wiki page (like MaintainerAway) where anybody can add himself with a small explanation how long he is going to be away and maybe also why. If someone adds himself onto this wiki page all of his/her ports will be treated like if they have openmaintainer on them, so anybody can commit updates without explicit permission. This should be taken like a temporarily openmaintainer status. Or the maintainer could also add someone else who should take care of his/her ports for this time. The main advantage would be that the 72h delay does not have to pass as the maintainer will not answer anyway. The wiki page could look like this (with a proper table, of course): maintainer1 at example.org | 2008-04-01 to 2008-04-10 | On vacation, please ask foobar@ maintainer2 at example.org | 2008-03-14 to 2008-04-01 | Exams Of course this would also need to be documented in our guide. Any comments appreciated. Do you think this would be an improvement to our infrastructure? Rainer PS: I am writing to both lists as I think this is also an interesting topic for our users. From simon at ruderich.com Sun Mar 9 12:28:12 2008 From: simon at ruderich.com (Simon Ruderich) Date: Sun, 9 Mar 2008 20:28:12 +0100 Subject: livecheck not finding latest version In-Reply-To: <47C62B2C.7020901@macports.org> References: <799406d60802271141q5d209bd8y70bb47b26e8808c9@mail.gmail.com> <8D34450C-DB62-40DD-A9D4-D006C936BFFC@macports.org> <47C62B2C.7020901@macports.org> Message-ID: <20080309192812.GA1574@ruderich.com> On Thu, Feb 28, 2008 at 04:31:56AM +0100, Rainer M?ller wrote: > Anders F Bj?rklund wrote: > > That's probably because livecheck doesn't check to see if the > > new version is actually *newer*, it only checks if it changed... > > > > if {$updated_version != ${livecheck.version}} { > > set updated 1 > > } else { > > set updated 0 > > } > > We could also use rpm-vercomp here, but you would never notice if the > site being checked is not updated anymore (happens e.g. with freshmeat). > So if the port version is newer than the version livecheck finds, we > should at least issue a warning that livecheck needs to be tweaked. > > Rainer Hi, I found another small problem with the livecheck. I have a port in my local repository which uses ${name}-${version} as livecheck.version. With the current version it gives me the following. First it says it matched and then it doesn't. DEBUG: The regex matched "fdm fdm-1.5 released (Tue, 04 Mar 2008 08:33:08 GMT)", extracted "fdm-1.5" DEBUG: The regex matched "fdm fdm-1.4 released (Mon, 01 Oct 2007 12:45:11 GMT)", extracted "fdm-1.4" DEBUG: The regex matched "fdm fdm-1.3 released (Mon, 30 Jul 2007 17:38:15 GMT)", extracted "fdm-1.3" DEBUG: The regex matched "fdm fdm-1.2 released (Wed, 27 Jun 2007 08:16:56 GMT)", extracted "fdm-1.2" DEBUG: The regex matched "fdm fdm-1.1 released (Fri, 06 Apr 2007 13:40:32 GMT)", extracted "fdm-1.1" DEBUG: The regex matched "fdm fdm-1.0 released (Tue, 27 Feb 2007 23:45:33 GMT)", extracted "fdm-1.0" DEBUG: The regex matched "fdm fdm-0.9 released (Thu, 25 Jan 2007 16:49:31 GMT)", extracted "fdm-0.9" DEBUG: The regex matched "fdm fdm-0.8 released (Tue, 09 Jan 2007 16:53:07 GMT)", extracted "fdm-0.8" DEBUG: The regex matched "fdm fdm-0.7 released (Tue, 12 Dec 2006 17:59:35 GMT)", extracted "fdm-0.7" DEBUG: The regex matched "fdm fdm-0.6 released (Mon, 04 Dec 2006 14:11:36 GMT)", extracted "fdm-0.6" Error: cannot check if fdm was updated (regex didn't match) I looked into this and the problem is that [rpm-vercomp $upver $updated_version] returns -1 if $updated_version is 0 and $upver is something like fdm-1.5 which is true before any version is found. It works fine for $upvar 1.5. The following patch fixes the problem for me but I'm not sure if it causes any other problems. Please check if it works fine. --- src/port1.0/portlivecheck.tcl (revision 34864) +++ src/port1.0/portlivecheck.tcl (working copy) @@ -187,7 +187,7 @@ while {[gets $chan line] >= 0} { if {[regexp $the_re $line matched upver]} { set foundmatch 1 - if {[rpm-vercomp $upver $updated_version] > 0} { + if {[rpm-vercomp $upver $updated_version] > 0 || $updated_version == 0} { set updated_version $upver } ui_debug "The regex matched \"$matched\", extracted \"$upver\"" Thanks, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080309/d123defd/attachment-0001.bin From lutz.horn at fastmail.fm Mon Mar 10 00:45:39 2008 From: lutz.horn at fastmail.fm (Lutz Horn) Date: Mon, 10 Mar 2008 08:45:39 +0100 Subject: Rails 2.0 port ? In-Reply-To: <47D44AEF.90401@daysofwonder.com> References: <47D44AEF.90401@daysofwonder.com> Message-ID: <1205135139.5119.1241488809@webmail.messagingengine.com> Hi Yann On Sun, 09 Mar 2008 21:39:11 +0100, "Yann Corno" said: > Does anyone know if (or when) Ruby on Rails 2.0 will be available in > MacPorts ? There is an open ticket that asks for RoR 2.0. Unfortunately the maintainer of the RoR related ports seems not to be reachable. I'd try like to take over maintainership of these ports but before this I'd have to look deeper into the specifics of Ruby ports. An open question is if the RoR ports should go to 2.x from 1.x in the existing ports or if the existing ports should be kept and new ports for RoR 2.x should be created. Regards Lutz -- GnuPG Key: 1024D/6EBDA359 1999-09-20 Key fingerprint = 438D 31FC 9300 CED0 1CDE A19D CD0F 9CA2 6EBD A359 http://dev-random.dnsalias.net/0x6EBDA35.asc http://pgp.cs.uu.nl/stats/6EBDA359.html From jmr at macports.org Mon Mar 10 02:12:05 2008 From: jmr at macports.org (Joshua Root) Date: Mon, 10 Mar 2008 20:12:05 +1100 Subject: gv and ghostview - both needed? Message-ID: <47D4FB65.1080309@macports.org> Hi all, Looking at , I'm wondering if the best resolution might be to simply remove the ghostview port. From my perusal of their homepages, it appears that (1) gv is based on ghostview, and (2) that ghostview has not been updated since 1993, while the latest gv release is from 2007. So I just wanted to ask the list: Is there anything I'm missing? Is there a situation where ghostview would be a better choice than gv? Cheers, Josh From takeshi at enomosphere.net Mon Mar 10 05:41:55 2008 From: takeshi at enomosphere.net (Takeshi Enomoto) Date: Mon, 10 Mar 2008 21:41:55 +0900 Subject: gv and ghostview - both needed? In-Reply-To: <47D4FB65.1080309@macports.org> References: <47D4FB65.1080309@macports.org> Message-ID: <02EFB2B6-B7C4-4B94-8E94-8D99A6FB5A46@enomosphere.net> Hi, I have not been aware of the difference between ghostview and gv until I found the installation error of the former. gv-3.5.8 also has some problems with Leopard. So I recently updated gv to 3.6.3. I don't see any problems with removing ghostview. Takeshi From ebgssth at gmail.com Mon Mar 10 07:43:00 2008 From: ebgssth at gmail.com (js) Date: Mon, 10 Mar 2008 23:43:00 +0900 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js) In-Reply-To: References: Message-ID: Hi Derek, Thanks for your feedback. My intention was to make python24 and python25 looks the same as possible, not to downgrade python24. I thoguht I would be confused if I upgraded python port from 2.4 to 2.5 and found that I cannot import zlib anymore. Yes, this is an FAQ but the thing is python24 and python25 don't have the same policy. However, I think you're right. This change would likely break existing systems badly. And I must confess I didn't expect there're people using MacPorts for enterprise. To lower this risk, I could resign python24 port to separate some of its standard modules and add them as dependencies, but I doubt you would like this idea. Thanks. On Mon, Mar 10, 2008 at 4:30 AM, Derek Harland wrote: > > On 8/03/2008, at 8:06 AM, macports-dev-request at lists.macosforge.org > wrote: > > Date: Sat, 8 Mar 2008 00:22:42 +0900 > > From: js > > Subject: Re: [MacPorts] #14342: python25 drops modules by default, but > > python25 doesn't > > To: "Markus Weissmann" > > Cc: MacPorts Developers > > > > Apparently more people like this change. > > I'll get back to trac ticket and start working on this. > > I'm not sure I particularly like this proposed change. As I > understand it, you explicitly want to *downgrade* the functionality > of python24 to make it more like python25, by for example, removing > hashlib and zlib. > > I cannot understand the logic of this. This can only conceivably > break python24 installations. Even if all existing py-* ports are > altered to bring in extra required dependencies, peoples (and > institutions) own proprietary code that previously assumed the > existence of these standard libraries will break. And that will > annoy them greatly. > > Why are you proposing to explicitly *downgrade* python24, instead of > *upgrading* python25? > > I also do not buy into the inference that's been made in this thread > in the past that more people must be using python25 than python24. > For institutions with large proprietary codebases (eg financial > companies), shifting python versions *is* a costly business that is > not worth the often negligible benefit. I would suggest that many > are still running more code off 2.4 than 2.5 (companies I have been > involved with have moved from 1.5->20->2.2->2.4->2.6). I'm not > suggesting many such companies run code on OSX, but mine certainly is. > > derek. > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From raimue at macports.org Mon Mar 10 08:21:50 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 10 Mar 2008 16:21:50 +0100 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js) In-Reply-To: References: Message-ID: <47D5520E.8020206@macports.org> Derek Harland wrote: > I'm not sure I particularly like this proposed change. As I > understand it, you explicitly want to *downgrade* the functionality > of python24 to make it more like python25, by for example, removing > hashlib and zlib. > > I cannot understand the logic of this. This can only conceivably > break python24 installations. Even if all existing py-* ports are > altered to bring in extra required dependencies, peoples (and > institutions) own proprietary code that previously assumed the > existence of these standard libraries will break. And that will > annoy them greatly. I don't care about software outside of MacPorts. The user is responsible him-/herself to install the appropriate dependencies for it. > Why are you proposing to explicitly *downgrade* python24, instead of > *upgrading* python25? The disabled_modules was chosen wisely as Markus and Boyd explained earlier in this thread. I don't see a reason to change python25 again. > I also do not buy into the inference that's been made in this thread > in the past that more people must be using python25 than python24. > For institutions with large proprietary codebases (eg financial > companies), shifting python versions *is* a costly business that is > not worth the often negligible benefit. I would suggest that many > are still running more code off 2.4 than 2.5 (companies I have been > involved with have moved from 1.5->20->2.2->2.4->2.6). I'm not > suggesting many such companies run code on OSX, but mine certainly is. Wouldn't it be the responsibility of their sysadmins to test new releases and do upgrades only if it works? It would be their job to install new py-* dependencies if needed. Rainer From ebgssth at gmail.com Mon Mar 10 08:46:32 2008 From: ebgssth at gmail.com (js) Date: Tue, 11 Mar 2008 00:46:32 +0900 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js) In-Reply-To: References: Message-ID: > To lower this risk, I could resign python24 port to separate some of sorry, another typo s/resign/redesign/ From cbellot at sky.fr Mon Mar 10 09:13:22 2008 From: cbellot at sky.fr (Cyril Bellot) Date: Mon, 10 Mar 2008 17:13:22 +0100 Subject: NEW PORT: ipv6calc Message-ID: <47D55E22.5000809@sky.fr> Could someone have a look at this new port proposal : http://trac.macosforge.org/projects/macports/ticket/14611 Thanks From wsiegrist at apple.com Mon Mar 10 11:58:08 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 10 Mar 2008 11:58:08 -0700 Subject: Splitting the guide In-Reply-To: <20080308215953.GA9978@ruderich.com> References: <20080304232006.GB415@ruderich.com> <47CE48A8.3030308@macports.org> <20080305165539.GA2577@ruderich.com> <47CEDB7B.6030600@macports.org> <2101735E-F312-4D6D-B17E-23C9EB690F4C@apple.com> <20080308215953.GA9978@ruderich.com> Message-ID: Done. -Bill On Mar 8, 2008, at 1:59 PM, Simon Ruderich wrote: > On Wed, Mar 05, 2008 at 12:53:40PM -0800, William Siegrist wrote: >> Its handled via the Makefile. The post-commit job performs 1 copy >> when make >> is done: >> >> cp doc-new/guide/html/* >> >> So if you make subdirectories, I'll add a -R, otherwise it should >> work. >> >> -Bill > > Hi Bill, > > thanks for your quick response. It would be perfect if you could > make this > change (-R) so we can decide which method we use and then just > modify the html > directory in the guide. > > Thanks for your help, > Simon > -- > + privacy is necessary > + using http://gnupg.org > + public key id: 0x6115F804EFB33229 ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080310/cae51803/attachment-0001.bin From derek at chocolate-fish.com Mon Mar 10 12:54:56 2008 From: derek at chocolate-fish.com (Derek Harland) Date: Tue, 11 Mar 2008 08:54:56 +1300 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js) In-Reply-To: <47D5520E.8020206@macports.org> References: <47D5520E.8020206@macports.org> Message-ID: <281D0D55-2886-4402-8BFB-EEABF8753531@chocolate-fish.com> On 11/03/2008, at 4:21 AM, Rainer M?ller wrote: > Derek Harland wrote: >> I'm not sure I particularly like this proposed change. As I >> understand it, you explicitly want to *downgrade* the >> functionality of python24 to make it more like python25, by for >> example, removing hashlib and zlib. >> I cannot understand the logic of this. This can only conceivably >> break python24 installations. Even if all existing py-* ports >> are altered to bring in extra required dependencies, peoples >> (and institutions) own proprietary code that previously assumed >> the existence of these standard libraries will break. And that >> will annoy them greatly. > > I don't care about software outside of MacPorts. The user is > responsible him-/herself to install the appropriate dependencies > for it. From my point of view, I can certainly agree that users are responsible for doing so upon *installation* of python. A typical user is going to install macports python and then whatever other external modules they require. They are then conceivably going to write their own tools, scripts and applications using this python environment they have developed for themselves. The proposal is now that they will run "port upgrade" and in fact receive a veritable downgrade of the environment they have crafted. Their own code will crash and possibly inexplicably to them ("it ran fine the other day ...") And for what reason will a downgrade be pushed out to all users? Because there is an "inconsistency" in the disabled modules. Does it really matter that much? > >> Why are you proposing to explicitly *downgrade* python24, instead >> of *upgrading* python25? > > The disabled_modules was chosen wisely as Markus and Boyd explained > earlier in this thread. I don't see a reason to change python25 again. My point was more that the problem is "X contains more functionality than Y" and the proposed solution is "downgrade X so it looks like Y". In reality I think there is little benefit in changing either of python24 or python25. > >> I also do not buy into the inference that's been made in this >> thread in the past that more people must be using python25 than >> python24. For institutions with large proprietary codebases (eg >> financial companies), shifting python versions *is* a costly >> business that is not worth the often negligible benefit. I would >> suggest that many are still running more code off 2.4 than 2.5 >> (companies I have been involved with have moved from 1.5->20->2.2- >> >2.4->2.6). I'm not suggesting many such companies run code on >> OSX, but mine certainly is. > > Wouldn't it be the responsibility of their sysadmins to test new > releases and do upgrades only if it works? It would be their job to > install new py-* dependencies if needed. But this is the point. It can be a struggle to prove that a large developed code base will work across a big number shift in python version (2.4->2.5). Is the expectation now that users should be proving all incremental updates of their python24 installation in case there's been an upstream downgrade in functionality? Its inevitable that at times macports will need to break its users codebases. But to break them over a relatively trivial matter like this seems overdone. des From yann at daysofwonder.com Mon Mar 10 12:59:44 2008 From: yann at daysofwonder.com (Yann Corno) Date: Mon, 10 Mar 2008 20:59:44 +0100 Subject: Rails 2.0 port ? In-Reply-To: References: Message-ID: <47D59330.9060406@daysofwonder.com> Hi Lutz: > Hi Yann > > On Sun, 09 Mar 2008 21:39:11 +0100, "Yann Corno" > said: >> Does anyone know if (or when) Ruby on Rails 2.0 will be available in >> MacPorts ? > > There is an open ticket that asks for RoR > 2.0. Unfortunately the maintainer of the RoR related ports seems not to > be reachable. I'd try like to take over maintainership of these ports > but before this I'd have to look deeper into the specifics of Ruby > ports. Thanks for your answer. It sure would be very nice to see it happening. > An open question is if the RoR ports should go to 2.x from 1.x in the > existing ports or if the existing ports should be kept and new ports for > RoR 2.x should be created. This is always the $1 question when a major upgrade happens on a framework. You probably want to keep the old 1.x port, at least for some time, so that legacy applications can still work. My (short) experience with upgrading my RoR app to 2.0 showed me that on the surface, there were not many changes to perform on my app to make it work. But at the same time, the RoR architecture has been reworked a lot, with more use of plug-ins for previously built-in classes, etc. So you are probably looking at a rework of the port - but then again, I am no expert. Best, Yann From derek at chocolate-fish.com Mon Mar 10 13:11:12 2008 From: derek at chocolate-fish.com (Derek Harland) Date: Tue, 11 Mar 2008 09:11:12 +1300 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js) In-Reply-To: References: Message-ID: <6593B69C-50D9-4286-82FB-6A44CA734C93@chocolate-fish.com> On 11/03/2008, at 3:43 AM, js wrote: > Hi Derek, > > Thanks for your feedback. > > My intention was to make python24 and python25 looks the same as > possible, > not to downgrade python24. > I thoguht I would be confused if I upgraded python port from 2.4 to > 2.5 and > found that I cannot import zlib anymore. Yes, that may be confusing. But it seems that your solution is to make everyone that runs a port upgrade python24 discover they don't have zlib anymore. Thats all I'm pointing out. It also presumably involves you running through every py-* port and discovering whether they depend on zlib etc (at least I hope it does) > To lower this risk, I could resign python24 port to separate some of > its standard modules and > add them as dependencies, but I doubt you would like this idea. I'm fine with that as it won't break existing installations. But it doesn't solve your original gripe ... that people can install python24 and have zlib, and then install python25 and not have zlib. [Which I'm not sure is that great an issue] des. From wsiegrist at apple.com Mon Mar 10 15:15:53 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 10 Mar 2008 15:15:53 -0700 Subject: Google SoC 2008 In-Reply-To: References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> <8C51D842-0EB6-48B0-A7E6-1C4CF23FB791@macports.org> Message-ID: I can shepherd the GSoC effort for macports. I've gone through the wiki page and made the initial changes for 2008. http://trac.macosforge.org/projects/macports/wiki/SummerOfCode The next thing we need to do is to verify which of those tasks are obsolete or completed, and which tasks we should add. If you can be mentor for the project, please add your name to the list and any tasks you can help with. I'll be working on the application today and tomorrow, so we need to move quickly. Thanks -Bill On Mar 7, 2008, at 11:14 AM, Jordan K. Hubbard wrote: > Gah! If it's me or nobody, I'll do it. :-) We really shouldn't let > the opportunity just slip through our fingers. Hey, Jumpy, where are > you? :-) > > - Jordan > > On Mar 7, 2008, at 8:38 AM, James Berry wrote: > >> I haven't heard back from anybody regarding this plea/opportunity. >> >> I don't have time to shepherd GSoC this year. If no body steps up to >> do so, or to be mentors, I'm going to let this opportunity slide by. >> Deadline for us to apply to Google, with projects in hand, is next >> Wednesday, March 12. >> >> Anybody? >> >> James >> >> On Mar 4, 2008, at 8:27 AM, James Berry wrote: >> >>> Thanks to everybody who pitched ideas for GSoC 2008. >>> >>> Now the rubber needs to meet the road. We need: >>> >>> - Somebody to head up our GSoC 2008 effort (get us signed up with >>> Google, document the proposed projects, etc). >>> - And committed mentors for any projects. >>> >>> Volunteers? >>> >>> As Paul Guyot points out, one thing we found last year was that >>> google seems to allocate project funding to a project based on the >>> total number of student applications. So a project that gets >>> applications from 50 students is likely to be allocated more student >>> slots than a project that gets only 3 student applications. The >>> number of student applications is probably guided in part by several >>> factors: promotion and appeal to the student community; number and >>> appeal of project proposals; etc. >>> >>> James >>> >>> >>> >>> On Feb 29, 2008, at 3:48 PM, James Berry wrote: >>> >>>> I'm writing to attempt to gauge interest in whether and how >>>> MacPorts >>>> should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ >>>> . >>>> >>>> You might be inclined to address any of the following questions: >>>> >>>> - Do you feel MacPorts should participate in GSoC 2008? >>>> - Are there particular MacPorts projects you'd like to suggest? >>>> - Are you willing to be a GSoC mentor? >>>> - Would you be interested, as a student, in participating in a GSoC >>>> project for MacPorts? >>>> >>>> GSoC pays students a wage for the summer to work on open source >>>> projects, and also a stipend to the project for each student >>>> project. >>>> >>>> If interested, we need to move very quickly. As the Google GSoC FAQ >>>> says: >>>> >>>> "We'll begin accepting applications from open source mentoring >>>> organizations on Monday, March 3, 2008; we'll stop accepting >>>> organization applications on Wednesday, March 12th." >>>> >>>> Your feedback is welcome >>>> >>>> James >>>> _______________________________________________ >>>> macports-dev mailing list >>>> macports-dev at lists.macosforge.org >>>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >>> >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080310/11ec7b83/attachment.bin From wsiegrist at apple.com Mon Mar 10 18:20:30 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 10 Mar 2008 18:20:30 -0700 Subject: Mac OS Forge Downtime: Wednesday, 6-7pm PDT Message-ID: We need to move our servers to a new rack. This will require shutting everything down (SVN, Trac, www.macports.org, RSync, etc) for about an hour this Wednesday night (the 12th). Everything should be back around 7pm. Sorry for the inconvenience. -Bill ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080310/43e52584/attachment-0001.bin From mp at dpj.sent.com Tue Mar 11 03:07:50 2008 From: mp at dpj.sent.com (Daniel Horwood) Date: Tue, 11 Mar 2008 18:07:50 +0800 Subject: gnucash & guile16: please commit patches for #12496 and #12497 Message-ID: <2A5CC19F-9B9F-4521-BF53-BC749DEF2736@dpj.sent.com> Hi, I opened two tickets about a month ago relating to gnucash (#12497) and guile16 (#12496). The patches I attached to these tickets work for me and I have heard from two other users that they work as well. Could someone please commit these patches? Once they are committed then I can update the gnucash portfile to the latest version (which was only just released). Thanks, Dan From ebgssth at gmail.com Tue Mar 11 05:47:47 2008 From: ebgssth at gmail.com (js) Date: Tue, 11 Mar 2008 21:47:47 +0900 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js) In-Reply-To: <6593B69C-50D9-4286-82FB-6A44CA734C93@chocolate-fish.com> References: <6593B69C-50D9-4286-82FB-6A44CA734C93@chocolate-fish.com> Message-ID: > Yes, that may be confusing. But it seems that your solution is to > make everyone that runs a port upgrade python24 discover they don't > have zlib anymore. Thats all I'm pointing out. That would be avoidable without any hassle. depend_lib or ui_msg? > It also presumably involves you running through every py-* port and > discovering whether they depend on zlib etc (at least I hope it does) I think you're right. > > To lower this risk, I could resign python24 port to separate some of > > its standard modules and > > add them as dependencies, but I doubt you would like this idea. > > I'm fine with that as it won't break existing installations. But it > doesn't solve your original gripe ... that people can install > python24 and have zlib, and then install python25 and not have zlib. > [Which I'm not sure is that great an issue] If I add zlib dependency to python24, I'd also add it to python25. From jberry at macports.org Tue Mar 11 08:31:53 2008 From: jberry at macports.org (James Berry) Date: Tue, 11 Mar 2008 08:31:53 -0700 Subject: [macports-mgr] Google SoC 2008 In-Reply-To: References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> <8C51D842-0EB6-48B0-A7E6-1C4CF23FB791@macports.org> Message-ID: <95F8BFA5-D50B-42B3-9A8F-A83B5BCCF4B3@macports.org> Bill, Glad to hear you'll be able to help out with this. I'd like to ask anybody who would be willing to mentor to please communicate with Bill. Our timeframe is very short to get an application together by noon PDT tomorrow. James On Mar 10, 2008, at 3:15 PM, William Siegrist wrote: > I can shepherd the GSoC effort for macports. I've gone through the > wiki page and made the initial changes for 2008. > > http://trac.macosforge.org/projects/macports/wiki/SummerOfCode > > The next thing we need to do is to verify which of those tasks are > obsolete or completed, and which tasks we should add. If you can be > mentor for the project, please add your name to the list and any > tasks you can help with. > > I'll be working on the application today and tomorrow, so we need to > move quickly. > > Thanks > > -Bill > > > > On Mar 7, 2008, at 11:14 AM, Jordan K. Hubbard wrote: >> Gah! If it's me or nobody, I'll do it. :-) We really shouldn't >> let >> the opportunity just slip through our fingers. Hey, Jumpy, where are >> you? :-) >> >> - Jordan >> >> On Mar 7, 2008, at 8:38 AM, James Berry wrote: >> >>> I haven't heard back from anybody regarding this plea/opportunity. >>> >>> I don't have time to shepherd GSoC this year. If no body steps up to >>> do so, or to be mentors, I'm going to let this opportunity slide by. >>> Deadline for us to apply to Google, with projects in hand, is next >>> Wednesday, March 12. >>> >>> Anybody? >>> >>> James >>> >>> On Mar 4, 2008, at 8:27 AM, James Berry wrote: >>> >>>> Thanks to everybody who pitched ideas for GSoC 2008. >>>> >>>> Now the rubber needs to meet the road. We need: >>>> >>>> - Somebody to head up our GSoC 2008 effort (get us signed up with >>>> Google, document the proposed projects, etc). >>>> - And committed mentors for any projects. >>>> >>>> Volunteers? >>>> >>>> As Paul Guyot points out, one thing we found last year was that >>>> google seems to allocate project funding to a project based on the >>>> total number of student applications. So a project that gets >>>> applications from 50 students is likely to be allocated more >>>> student >>>> slots than a project that gets only 3 student applications. The >>>> number of student applications is probably guided in part by >>>> several >>>> factors: promotion and appeal to the student community; number and >>>> appeal of project proposals; etc. >>>> >>>> James >>>> >>>> >>>> >>>> On Feb 29, 2008, at 3:48 PM, James Berry wrote: >>>> >>>>> I'm writing to attempt to gauge interest in whether and how >>>>> MacPorts >>>>> should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ >>>>> . >>>>> >>>>> You might be inclined to address any of the following questions: >>>>> >>>>> - Do you feel MacPorts should participate in GSoC 2008? >>>>> - Are there particular MacPorts projects you'd like to suggest? >>>>> - Are you willing to be a GSoC mentor? >>>>> - Would you be interested, as a student, in participating in a >>>>> GSoC >>>>> project for MacPorts? >>>>> >>>>> GSoC pays students a wage for the summer to work on open source >>>>> projects, and also a stipend to the project for each student >>>>> project. >>>>> >>>>> If interested, we need to move very quickly. As the Google GSoC >>>>> FAQ >>>>> says: >>>>> >>>>> "We'll begin accepting applications from open source mentoring >>>>> organizations on Monday, March 3, 2008; we'll stop accepting >>>>> organization applications on Wednesday, March 12th." >>>>> >>>>> Your feedback is welcome >>>>> >>>>> James >>>>> _______________________________________________ >>>>> macports-dev mailing list >>>>> macports-dev at lists.macosforge.org >>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >>>> >>> >>> _______________________________________________ >>> macports-dev mailing list >>> macports-dev at lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > > > ---- > William Siegrist > Software Support Engineer > Mac OS Forge > http://macosforge.org/ > wsiegrist at apple.com > 408 862 7337 > > > > > > _______________________________________________ > macports-mgr mailing list > macports-mgr at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-mgr From ebgssth at gmail.com Tue Mar 11 08:43:35 2008 From: ebgssth at gmail.com (js) Date: Wed, 12 Mar 2008 00:43:35 +0900 Subject: Enabling configureccache by default? Message-ID: Hi, ccache really saves so much time, but it is off by default. Assuming this is just because MacPorts installer does not contain ccache, how about adding ccache into the installer and making configurecache on by default? I think this would help many users who don't know about ccache, just like I used to be. If ccache has no bad side-effect, I think it's reasonable to make it enabled always. Thanks. From simon at ruderich.com Mon Mar 10 15:58:54 2008 From: simon at ruderich.com (Simon Ruderich) Date: Mon, 10 Mar 2008 23:58:54 +0100 Subject: livecheck not finding latest version In-Reply-To: <47D47BAB.6010603@macports.org> References: <799406d60802271141q5d209bd8y70bb47b26e8808c9@mail.gmail.com> <8D34450C-DB62-40DD-A9D4-D006C936BFFC@macports.org> <47C62B2C.7020901@macports.org> <20080309192812.GA1574@ruderich.com> <47D47BAB.6010603@macports.org> Message-ID: <20080310225854.GA25444@ruderich.com> On Mon, Mar 10, 2008 at 01:07:07AM +0100, Rainer M?ller wrote: > Simon Ruderich wrote: > >> I looked into this and the problem is that [rpm-vercomp $upver >> $updated_version] returns -1 if $updated_version is 0 and $upver is something >> like fdm-1.5 which is true before any version is found. It works fine for >> $upvar 1.5. > > Hm, you are right. rpm-vercomp just skips any alphabetic characters at the > begin of the string if they appear in both versions. > > [snip] > > I committed a similar fix in r34874. > > Rainer Hi Rainer, thanks for your quick help. Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080310/93bad495/attachment.bin From wsiegrist at apple.com Tue Mar 11 12:58:06 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 11 Mar 2008 12:58:06 -0700 Subject: Google SoC 2008 In-Reply-To: References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> Message-ID: <62179526-A903-4FF1-BA67-48EE7A0F7A0E@apple.com> Ok, I added both of Randall's tasks (#3 and #10 now). Randall, can you be a mentor for these? If so, can you add yourself to the wiki page? http://trac.macosforge.org/projects/macports/wiki/SummerOfCode -Bill On Mar 4, 2008, at 3:28 AM, Randall Wood wrote: > On 2/29/08, James Berry wrote: >> I'm writing to attempt to gauge interest in whether and how MacPorts >> should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ >> . >> >> You might be inclined to address any of the following questions: >> >> - Do you feel MacPorts should participate in GSoC 2008? >> - Are there particular MacPorts projects you'd like to suggest? > > Yet another possible project (sorry for yapping about like this): > > Add support for a mechanism similar to Finks init.[c]sh mechanisms for > providing basic and port-provided environmental services to users in > the .profile, .cshrc, and .xinitrc files, so that instead of > manipulating the user's .profile to modify certain paths, all we do is > append something like "source /opt/local/etc/bash.rc" to the end of a > user's .profile file and that bash.rc would be like /etc/rc and would > source all the files in /opt/local/etc/bash.d > > This would require: > 1) Adding support to the Portfiles for setting key value pairs that > can then be written out at some phase (install?) into both correct > bash and csh (and maybe other shell) syntaxes and stored in > ${prefix}/etc/init.d/${portname}.shell > 2) Adding support for managing X11-specific key value pairs that > would be stored into ${prefix}/etc/xinit.d/${portname} > 3) Writing the files ${prefix}/etc/init.shell for each shell we > decide to support. These files need only support correcting the PATH > and MANPATH for macports and then sourcing all of the files in init.d > ending in the correct shell. > 4) Writing ${prefix}/etc/init.X11 that would source > ${prefix}/etc/init.sh (the xinit mechanism is a bash shell, I believe) > and then source all the files in init.d ending in X11. > 5) Provide a simple command line utility that can correctly > enable/disable sourcing the init.shell|X11 files for a user. > > What gets inserted into a user's .profile/.xinitrc/.cshrc file? It > should be a couple of lines of comment explaining the single command > line that we added to the file followed by the command line (in bash: > source /opt/local/etc/init.sh) > >> - Are you willing to be a GSoC mentor? >> - Would you be interested, as a student, in participating in a GSoC >> project for MacPorts? >> >> GSoC pays students a wage for the summer to work on open source >> projects, and also a stipend to the project for each student project. >> >> If interested, we need to move very quickly. As the Google GSoC FAQ >> says: >> >> "We'll begin accepting applications from open source mentoring >> organizations on Monday, March 3, 2008; we'll stop accepting >> organization applications on Wednesday, March 12th." >> >> Your feedback is welcome >> >> James >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> > > > -- > Randall Wood > randall.h.wood at alexandriasoftware.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 at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080311/efd35f87/attachment.bin From raimue at macports.org Tue Mar 11 14:04:47 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 11 Mar 2008 22:04:47 +0100 Subject: Enabling configureccache by default? In-Reply-To: References: Message-ID: <47D6F3EF.1020602@macports.org> js wrote: > ccache really saves so much time, but it is off by default. > Assuming this is just because MacPorts installer does not contain ccache, > how about adding ccache into the installer and making configurecache > on by default? > I think this would help many users who don't know about ccache, just > like I used to be. > If ccache has no bad side-effect, I think it's reasonable to make it > enabled always. I would leave this to the users to configure it. We already have an easy installation howto for it and I think this is enough. Maybe we could announce this howto more by e.g. adding a reference in the FAQ to it. Rainer From raimue at macports.org Tue Mar 11 14:12:30 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 11 Mar 2008 22:12:30 +0100 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js) In-Reply-To: References: <6593B69C-50D9-4286-82FB-6A44CA734C93@chocolate-fish.com> Message-ID: <47D6F5BE.20605@macports.org> js wrote: > If I add zlib dependency to python24, I'd also add it to python25. But if you you add it as dependency, what is the benefit from putting it in its own port? Rainer From afb at macports.org Tue Mar 11 16:14:47 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 12 Mar 2008 00:14:47 +0100 Subject: Enabling configureccache by default? In-Reply-To: References: Message-ID: <29708467-AC14-4AAD-8FBD-6E38E75D50E2@macports.org> js wrote: > ccache really saves so much time, but it is off by default. > Assuming this is just because MacPorts installer does not contain > ccache, > how about adding ccache into the installer and making configurecache > on by default? > I think this would help many users who don't know about ccache, just > like I used to be. > If ccache has no bad side-effect, I think it's reasonable to make it > enabled always. Currently enabling ccache sets CC="ccache /usr/bin/gcc-4.0" Unfortunately some of the ports don't build with that setting, trying to use ccache as the compiler or otherwise not working. Even though it is easy to override with "configure.ccache=no", it's probably a good idea to leave it disabled in the default ? Also, tracemode doesn't really work with ccache enabled: http://trac.macports.org/projects/macports/ticket/12218 --anders From wsiegrist at apple.com Tue Mar 11 18:14:49 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 11 Mar 2008 18:14:49 -0700 Subject: Google SoC 2008 In-Reply-To: <62179526-A903-4FF1-BA67-48EE7A0F7A0E@apple.com> References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> <62179526-A903-4FF1-BA67-48EE7A0F7A0E@apple.com> Message-ID: <4FE706D2-AE27-4778-A18F-A9A0004DA02F@apple.com> I just finished submitting our application. -Bill On Mar 11, 2008, at 12:58 PM, William Siegrist wrote: > Ok, I added both of Randall's tasks (#3 and #10 now). > > Randall, can you be a mentor for these? If so, can you add yourself > to the wiki page? > > http://trac.macosforge.org/projects/macports/wiki/SummerOfCode > > > -Bill > > > On Mar 4, 2008, at 3:28 AM, Randall Wood wrote: >> On 2/29/08, James Berry wrote: >>> I'm writing to attempt to gauge interest in whether and how MacPorts >>> should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ >>> . >>> >>> You might be inclined to address any of the following questions: >>> >>> - Do you feel MacPorts should participate in GSoC 2008? >>> - Are there particular MacPorts projects you'd like to suggest? >> >> Yet another possible project (sorry for yapping about like this): >> >> Add support for a mechanism similar to Finks init.[c]sh mechanisms >> for >> providing basic and port-provided environmental services to users in >> the .profile, .cshrc, and .xinitrc files, so that instead of >> manipulating the user's .profile to modify certain paths, all we do >> is >> append something like "source /opt/local/etc/bash.rc" to the end of a >> user's .profile file and that bash.rc would be like /etc/rc and would >> source all the files in /opt/local/etc/bash.d >> >> This would require: >> 1) Adding support to the Portfiles for setting key value pairs that >> can then be written out at some phase (install?) into both correct >> bash and csh (and maybe other shell) syntaxes and stored in >> ${prefix}/etc/init.d/${portname}.shell >> 2) Adding support for managing X11-specific key value pairs that >> would be stored into ${prefix}/etc/xinit.d/${portname} >> 3) Writing the files ${prefix}/etc/init.shell for each shell we >> decide to support. These files need only support correcting the PATH >> and MANPATH for macports and then sourcing all of the files in init.d >> ending in the correct shell. >> 4) Writing ${prefix}/etc/init.X11 that would source >> ${prefix}/etc/init.sh (the xinit mechanism is a bash shell, I >> believe) >> and then source all the files in init.d ending in X11. >> 5) Provide a simple command line utility that can correctly >> enable/disable sourcing the init.shell|X11 files for a user. >> >> What gets inserted into a user's .profile/.xinitrc/.cshrc file? It >> should be a couple of lines of comment explaining the single command >> line that we added to the file followed by the command line (in bash: >> source /opt/local/etc/init.sh) >> >>> - Are you willing to be a GSoC mentor? >>> - Would you be interested, as a student, in participating in a GSoC >>> project for MacPorts? >>> >>> GSoC pays students a wage for the summer to work on open source >>> projects, and also a stipend to the project for each student >>> project. >>> >>> If interested, we need to move very quickly. As the Google GSoC FAQ >>> says: >>> >>> "We'll begin accepting applications from open source mentoring >>> organizations on Monday, March 3, 2008; we'll stop accepting >>> organization applications on Wednesday, March 12th." >>> >>> Your feedback is welcome >>> >>> James >>> _______________________________________________ >>> macports-dev mailing list >>> macports-dev at lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >>> >> >> >> -- >> Randall Wood >> randall.h.wood at alexandriasoftware.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 at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > > > ---- > William Siegrist > Software Support Engineer > Mac OS Forge > http://macosforge.org/ > wsiegrist at apple.com > 408 862 7337 > > > > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080311/15bfee05/attachment.bin From raimue at macports.org Wed Mar 12 01:55:56 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Wed, 12 Mar 2008 09:55:56 +0100 Subject: [34938] trunk/dports/lang/python23/Portfile In-Reply-To: <20080312071232.A4092149B986@beta.macosforge.org> References: <20080312071232.A4092149B986@beta.macosforge.org> Message-ID: <47D79A9C.1050103@macports.org> jmr at macports.org wrote: > Revision: 34938 > http://trac.macosforge.org/projects/macports/changeset/34938 > Author: jmr at macports.org > Date: 2008-03-12 00:12:32 -0700 (Wed, 12 Mar 2008) > > Log Message: > ----------- > python23: use appropriate dependency type > > Modified Paths: > -------------- > trunk/dports/lang/python23/Portfile > > Modified: trunk/dports/lang/python23/Portfile > =================================================================== > --- trunk/dports/lang/python23/Portfile 2008-03-12 07:08:49 UTC (rev 34937) > +++ trunk/dports/lang/python23/Portfile 2008-03-12 07:12:32 UTC (rev 34938) > @@ -21,7 +21,7 @@ > sha1 11ae8960fb4a5a57be0f57bdc86d901fedc92f66 > > # Should be depends_extract, but that isn't implemented > -depends_build bin:gnutar:gnutar > +depends_lib port:gnutar Why do you think depends_lib is more appropriate? gnutar is only needed to extract the downloaded distfile, as noted in the comment. So it should be kept as depends_build and not depends_lib. Rainer From randall.h.wood at alexandriasoftware.com Wed Mar 12 02:01:41 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Wed, 12 Mar 2008 05:01:41 -0400 Subject: Google SoC 2008 In-Reply-To: <62179526-A903-4FF1-BA67-48EE7A0F7A0E@apple.com> References: <6F6895E0-FCFF-4272-AC84-AF172AE1F806@macports.org> <62179526-A903-4FF1-BA67-48EE7A0F7A0E@apple.com> Message-ID: On 3/11/08, William Siegrist wrote: > Ok, I added both of Randall's tasks (#3 and #10 now). > > Randall, can you be a mentor for these? If so, can you add yourself to > the wiki page? I can Mentor, and the Wiki page is up to date. > > http://trac.macosforge.org/projects/macports/wiki/SummerOfCode > > > > -Bill > > > > On Mar 4, 2008, at 3:28 AM, Randall Wood wrote: > > On 2/29/08, James Berry wrote: > >> I'm writing to attempt to gauge interest in whether and how MacPorts > >> should participate in Google Summer of Code (GSoC) for 2008. See http://code.google.com/soc/2008/ > >> . > >> > >> You might be inclined to address any of the following questions: > >> > >> - Do you feel MacPorts should participate in GSoC 2008? > >> - Are there particular MacPorts projects you'd like to suggest? > > > > Yet another possible project (sorry for yapping about like this): > > > > Add support for a mechanism similar to Finks init.[c]sh mechanisms for > > providing basic and port-provided environmental services to users in > > the .profile, .cshrc, and .xinitrc files, so that instead of > > manipulating the user's .profile to modify certain paths, all we do is > > append something like "source /opt/local/etc/bash.rc" to the end of a > > user's .profile file and that bash.rc would be like /etc/rc and would > > source all the files in /opt/local/etc/bash.d > > > > This would require: > > 1) Adding support to the Portfiles for setting key value pairs that > > can then be written out at some phase (install?) into both correct > > bash and csh (and maybe other shell) syntaxes and stored in > > ${prefix}/etc/init.d/${portname}.shell > > 2) Adding support for managing X11-specific key value pairs that > > would be stored into ${prefix}/etc/xinit.d/${portname} > > 3) Writing the files ${prefix}/etc/init.shell for each shell we > > decide to support. These files need only support correcting the PATH > > and MANPATH for macports and then sourcing all of the files in init.d > > ending in the correct shell. > > 4) Writing ${prefix}/etc/init.X11 that would source > > ${prefix}/etc/init.sh (the xinit mechanism is a bash shell, I believe) > > and then source all the files in init.d ending in X11. > > 5) Provide a simple command line utility that can correctly > > enable/disable sourcing the init.shell|X11 files for a user. > > > > What gets inserted into a user's .profile/.xinitrc/.cshrc file? It > > should be a couple of lines of comment explaining the single command > > line that we added to the file followed by the command line (in bash: > > source /opt/local/etc/init.sh) > > > >> - Are you willing to be a GSoC mentor? > >> - Would you be interested, as a student, in participating in a GSoC > >> project for MacPorts? > >> > >> GSoC pays students a wage for the summer to work on open source > >> projects, and also a stipend to the project for each student project. > >> > >> If interested, we need to move very quickly. As the Google GSoC FAQ > >> says: > >> > >> "We'll begin accepting applications from open source mentoring > >> organizations on Monday, March 3, 2008; we'll stop accepting > >> organization applications on Wednesday, March 12th." > >> > >> Your feedback is welcome > >> > >> James > >> _______________________________________________ > >> macports-dev mailing list > >> macports-dev at lists.macosforge.org > >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > >> > > > > > > -- > > Randall Wood > > randall.h.wood at alexandriasoftware.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 at lists.macosforge.org > > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > > > > ---- > William Siegrist > Software Support Engineer > Mac OS Forge > http://macosforge.org/ > wsiegrist at apple.com > 408 862 7337 > > > > > > > -- Randall Wood randall.h.wood at alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From afb at macports.org Wed Mar 12 02:19:11 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 12 Mar 2008 10:19:11 +0100 Subject: applications_dir and frameworks_dir Message-ID: <93D4504E-D6C6-4F0E-8CFE-98C6D28EE115@macports.org> I was getting some questions about the configuration applications_dir and frameworks_dir that were added... (and their matching autoconf / configure options of --with-applications-dir and --with-frameworks-dir) They were intended to replace the (currently hardcoded) paths of /Applications/MacPorts and /Library/Frameworks, for when you want to use a different installation location. Just as we already have ${prefix} and now also ${x11prefix} ? They haven't found a suitable variable name yet, though... (so there isn't a way to use them from Portfile/Portgroup) --anders From ebgssth at gmail.com Wed Mar 12 05:54:42 2008 From: ebgssth at gmail.com (js) Date: Wed, 12 Mar 2008 21:54:42 +0900 Subject: Enabling configureccache by default? In-Reply-To: <29708467-AC14-4AAD-8FBD-6E38E75D50E2@macports.org> References: <29708467-AC14-4AAD-8FBD-6E38E75D50E2@macports.org> Message-ID: > Currently enabling ccache sets CC="ccache /usr/bin/gcc-4.0" > > Unfortunately some of the ports don't build with that setting, > trying to use ccache as the compiler or otherwise not working. > Even though it is easy to override with "configure.ccache=no", > it's probably a good idea to leave it disabled in the default ? > > Also, tracemode doesn't really work with ccache enabled: > http://trac.macports.org/projects/macports/ticket/12218 Thanks for the information. Could you add this informatioin to the ccache doc on the FAQ page as a warning? I didn't know that ccache sometimes make build failed. From ebgssth at gmail.com Wed Mar 12 06:08:28 2008 From: ebgssth at gmail.com (js) Date: Wed, 12 Mar 2008 22:08:28 +0900 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js) In-Reply-To: <47D6F5BE.20605@macports.org> References: <6593B69C-50D9-4286-82FB-6A44CA734C93@chocolate-fish.com> <47D6F5BE.20605@macports.org> Message-ID: The benefit is that python24 and python25 both uses almost same standard mods. Please note that I'm not sure adding this dependency is good thing. I just wanted to say keeping python ports similar would preferable, in my opinion. On Wed, Mar 12, 2008 at 6:12 AM, Rainer M?ller wrote: > js wrote: > > If I add zlib dependency to python24, I'd also add it to python25. > > But if you you add it as dependency, what is the benefit from putting it > in its own port? > > Rainer > From lutz.horn at fastmail.fm Thu Mar 13 06:00:51 2008 From: lutz.horn at fastmail.fm (Lutz Horn) Date: Thu Mar 13 06:00:27 2008 Subject: gnucash & guile16: please commit patches for #12496 and #12497 In-Reply-To: <2A5CC19F-9B9F-4521-BF53-BC749DEF2736@dpj.sent.com> References: <2A5CC19F-9B9F-4521-BF53-BC749DEF2736@dpj.sent.com> Message-ID: <1205413251.30003.1242193601@webmail.messagingengine.com> Hi, On Tue, 11 Mar 2008 18:07:50 +0800, "Daniel Horwood" said: > I opened two tickets about a month ago relating to gnucash (#12497) > and guile16 (#12496). > > The patches I attached to these tickets work for me and I have heard > from two other users that they work as well. > > Could someone please commit these patches? Once they are committed > then I can update the gnucash portfile to the latest version (which > was only just released). I've used the patches to install gnucash and it works fine on my 10.5.2 machine. So I support to commit these patches. Lutz -- Strike Out - Reading Unedited Text http://www.fourmilab.ch/documents/strikeout/ From ebgssth at gmail.com Thu Mar 13 09:52:02 2008 From: ebgssth at gmail.com (js) Date: Thu Mar 13 09:51:38 2008 Subject: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js) In-Reply-To: References: <6593B69C-50D9-4286-82FB-6A44CA734C93@chocolate-fish.com> <47D6F5BE.20605@macports.org> Message-ID: I think it's about a time to decide how we handle this. I wanted to change python24 to be python25-like design for consistency. Derek disagreed this idea from python24 users standpoint. Rainer seemed to agree with me, but might not like adding dropped mods to python port as dependencies. Options: 1. Change python24 to drop standard mods just as python25 does. 2. Don't change anything. 3. 1+add dropped mods to python24 and python25 as dependencies I like the first one. How about you? On Wed, Mar 12, 2008 at 10:08 PM, js wrote: > The benefit is that python24 and python25 both uses almost same standard mods. > Please note that I'm not sure adding this dependency is good thing. > I just wanted to say keeping python ports similar would preferable, in > my opinion. > > > > > On Wed, Mar 12, 2008 at 6:12 AM, Rainer M?ller wrote: > > js wrote: > > > If I add zlib dependency to python24, I'd also add it to python25. > > > > But if you you add it as dependency, what is the benefit from putting it > > in its own port? > > > > Rainer > > > From erickt at macports.org Thu Mar 13 11:58:41 2008 From: erickt at macports.org (Erick Tryzelaar) Date: Thu Mar 13 11:58:21 2008 Subject: did oracle move the db-44 files? Message-ID: <1ef034530803131158q4a0d5dffm32b0de5b0ede61cd@mail.gmail.com> It looks like for at least db44's master_sites http://downloads.sleepycat.com doesn't work anymore. I found the files here though: http://www.oracle.com/technology/software/products/berkeley-db/db/index.html My subversions busted so could someone else make the change? -e From erickt at macports.org Thu Mar 13 12:26:39 2008 From: erickt at macports.org (Erick Tryzelaar) Date: Thu Mar 13 12:26:24 2008 Subject: did oracle move the db-44 files? In-Reply-To: <1ef034530803131158q4a0d5dffm32b0de5b0ede61cd@mail.gmail.com> References: <1ef034530803131158q4a0d5dffm32b0de5b0ede61cd@mail.gmail.com> Message-ID: <1ef034530803131226k64f063dct7386dbbc778f5180@mail.gmail.com> On Thu, Mar 13, 2008 at 11:58 AM, Erick Tryzelaar wrote: > It looks like for at least db44's master_sites > http://downloads.sleepycat.com doesn't work anymore. I found the files > here though: > > http://www.oracle.com/technology/software/products/berkeley-db/db/index.html > > My subversions busted so could someone else make the change? Nevermind, I got it. From reiffert at macports.org Sun Mar 16 03:47:00 2008 From: reiffert at macports.org (Thomas Reifferscheid) Date: Sun Mar 16 03:46:51 2008 Subject: [35062] trunk/dports/www/firefox-x11/Portfile In-Reply-To: <20080316103605.C285A14B68BF@beta.macosforge.org> References: <20080316103605.C285A14B68BF@beta.macosforge.org> Message-ID: <47DCFAA4.40202@macports.org> I think you have a typo in port:nsrp. It should be port:nspr Kind regards Thomas rhwood@macports.org wrote: > > Revision > 35062 > Author > rhwood@macports.org > Date > 2008-03-16 03:36:03 -0700 (Sun, 16 Mar 2008) > > > Log Message > > Add dependency on nspr so that firefox-x11 does not conflict with ports that do depend on port:nspr > > > Modified Paths > > * trunk/dports/www/firefox-x11/Portfile > <#trunkdportswwwfirefoxx11Portfile> > > > Diff > > > Modified: trunk/dports/www/firefox-x11/Portfile (35061 => 35062) > > > --- trunk/dports/www/firefox-x11/Portfile 2008-03-16 09:38:38 UTC (rev 35061) > +++ trunk/dports/www/firefox-x11/Portfile 2008-03-16 10:36:03 UTC (rev 35062) > @@ -5,6 +5,7 @@ > name firefox-x11 > categories www x11 > version 2.0.0.11 > +revision 1 > platforms darwin > maintainers nomaintainer > description Mozilla.org's popular stand-alone browser > @@ -44,7 +45,8 @@ > port:gtk2 \ > port:gnome-vfs \ > port:gnome-icon-theme \ > - port:cairo > + port:cairo \ > + port:nsrp > > > configure.args --enable-application=browser \ > @@ -69,7 +71,10 @@ > --with-system-zlib=${prefix} \ > --with-system-png=${prefix} \ > --enable-system-cairo \ > - --with-system-cairo=${prefix} > + --with-system-cairo=${prefix} \ > + --with-system-nspr \ > + --with-nspr-prefix=${prefix} > + > > variant debug { > configure.args-delete --disable-debug \ > ------------------------------------------------------------------------ > > _______________________________________________ > macports-changes mailing list > macports-changes@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-changes > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080316/fe989dff/attachment.html From raimue at macports.org Mon Mar 17 06:37:14 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Mar 17 06:36:44 2008 Subject: Maintainer away tracking In-Reply-To: <47D48A05.2080301@macports.org> References: <47D48A05.2080301@macports.org> Message-ID: <47DE740A.20904@macports.org> Rainer M?ller wrote: > It happens from time to time that some maintainer is busy with work or > school, has to move, is on vacation or attends some other event which > prevents him from taking action on new tickets. > > So I want to setup a new wiki page (like MaintainerAway) where anybody > can add himself with a small explanation how long he is going to be away > and maybe also why. > > If someone adds himself onto this wiki page all of his/her ports will be > treated like if they have openmaintainer on them, so anybody can commit > updates without explicit permission. This should be taken like a > temporarily openmaintainer status. Or the maintainer could also add > someone else who should take care of his/her ports for this time. > > The main advantage would be that the 72h delay does not have to pass as > the maintainer will not answer anyway. So, this proposal was out now for about a week and nobody replied. If you don't like it, please tell me at least why you think it is not a good idea. Normally if I get no reply on a proposal, I would just take this as "no objections". But this time it is important that you as developers and maintainers are going to accept and use it. Therefore it would have been nice to get some replies what you think about this topic. Now it seems like nobody cares about it. Do you think we don't need this at all? Do you think nobody would use it? Or do you have another better solution? Rainer From sal at ri.cmu.edu Mon Mar 17 06:52:01 2008 From: sal at ri.cmu.edu (Salvatore Domenick Desiano) Date: Mon Mar 17 06:51:25 2008 Subject: Maintainer away tracking In-Reply-To: <47DE740A.20904@macports.org> References: <47D48A05.2080301@macports.org> <47DE740A.20904@macports.org> Message-ID: As a maintainer who is sometimes "away", I like the idea in principle, but I think there may be a simpler problem that will affect whether this is necesary. The volume on the MP lists has gone up astronomically of late, meaning that I have to shunt my MP email into a folder and read it itermittently. If there was some way to indicate that something required action by me, I would be much more responsive. I can't think of anything particularly good, but perhaps a standard prefix of "action: username" that I can filter for... As for the proposal, it seems fine, since people can easily opt out. I tend to think that people won't use it, but I see no harm in it. I would, however, like to be a more responsive maintainer, so it would be nice if there were some standard way to see which of the MP e-mails I really need to read, and which can wait for a week or so. -- Sal smile. On Mon, 17 Mar 2008, Rainer M?ller wrote: o Rainer M?ller wrote: o > It happens from time to time that some maintainer is busy with work or o > school, has to move, is on vacation or attends some other event which o > prevents him from taking action on new tickets. o > o > So I want to setup a new wiki page (like MaintainerAway) where anybody can o > add himself with a small explanation how long he is going to be away and o > maybe also why. o > o > If someone adds himself onto this wiki page all of his/her ports will be o > treated like if they have openmaintainer on them, so anybody can commit o > updates without explicit permission. This should be taken like a temporarily o > openmaintainer status. Or the maintainer could also add someone else who o > should take care of his/her ports for this time. o > o > The main advantage would be that the 72h delay does not have to pass as the o > maintainer will not answer anyway. o o So, this proposal was out now for about a week and nobody replied. If you o don't like it, please tell me at least why you think it is not a good idea. o o Normally if I get no reply on a proposal, I would just take this as "no o objections". But this time it is important that you as developers and o maintainers are going to accept and use it. Therefore it would have been nice o to get some replies what you think about this topic. o o Now it seems like nobody cares about it. Do you think we don't need this at o all? Do you think nobody would use it? Or do you have another better solution? o o Rainer o _______________________________________________ o macports-users mailing list o macports-users@lists.macosforge.org o http://lists.macosforge.org/mailman/listinfo/macports-users o o -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University From dluke at geeklair.net Mon Mar 17 07:00:40 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon Mar 17 07:00:01 2008 Subject: Maintainer away tracking In-Reply-To: References: <47D48A05.2080301@macports.org> <47DE740A.20904@macports.org> Message-ID: <3D90B934-B5C4-445E-ADE2-A967B40D1311@geeklair.net> On Mar 17, 2008, at 9:52 AM, Salvatore Domenick Desiano wrote: > If there was some way to indicate that something > required action by me, like say, a ticket assigned or CC'd to you? ;-) -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080317/8c667f13/PGP.bin From dluke at geeklair.net Mon Mar 17 07:03:07 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon Mar 17 07:04:04 2008 Subject: Maintainer away tracking In-Reply-To: <47DE740A.20904@macports.org> References: <47D48A05.2080301@macports.org> <47DE740A.20904@macports.org> Message-ID: On Mar 17, 2008, at 9:37 AM, Rainer M?ller wrote: > So, this proposal was out now for about a week and nobody replied. > If you don't like it, please tell me at least why you think it is > not a good idea. We already have the 72 hour timeout, the option of putting 'openmaintainer' on our ports or having co-maintainers who can also commit. In addition, ports that are seriously broken (ie, don't build, security vulnerability, distfile no longer available) can be fixed to work (without major changes) without waiting for the timeout already. I don't see the additional speed benefit as worth the extra book keeping. That said, I'm not going to object if others want to use it (I do know that I don't really plan on advertising to the world any time I may be going away on vacation). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080317/2c055c9e/PGP.bin From raimue at macports.org Mon Mar 17 07:26:18 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Mar 17 07:25:42 2008 Subject: Maintainer away tracking In-Reply-To: References: <47D48A05.2080301@macports.org> <47DE740A.20904@macports.org> Message-ID: <47DE7F8A.3080908@macports.org> Daniel J. Luke wrote: > On Mar 17, 2008, at 9:37 AM, Rainer M?ller wrote: >> So, this proposal was out now for about a week and nobody replied. >> If you don't like it, please tell me at least why you think it is >> not a good idea. > > We already have the 72 hour timeout, the option of putting > 'openmaintainer' on our ports or having co-maintainers who can also > commit. Exactly, we have to wait 72h even if the person in question will not respond anyway. > In addition, ports that are seriously broken (ie, don't build, > security vulnerability, distfile no longer available) can be fixed to > work (without major changes) without waiting for the timeout already. These points are not exactly clarified in the guide. # A critical port is broken that affects many users. Doesn't sound like 'missing distfile' or 'doesn't build' to me. I can't find another section regarding committing without maintainers' acknowledgment. > I don't see the additional speed benefit as worth the extra book > keeping. The extra book keeping is done my each individual maintainer. So not much work for a maintainers themself. > That said, I'm not going to object if others want to use it (I do know > that I don't really plan on advertising to the world any time I may be > going away on vacation). Hm, why not? You are not going to be around for any work on MacPorts, so tell the project about it. If we know you are just away for a few days, someone could also hold on committing not-so-important tickets until the known date at which you are back. Rainer From harrylparker at gmail.com Mon Mar 17 07:30:11 2008 From: harrylparker at gmail.com (Harry Parker) Date: Mon Mar 17 07:29:35 2008 Subject: [MacPorts] #14342: python25 drops modules by default, but python2[4] doesn't (js) Message-ID: <2a77b9140803170730u254a5c28re56d9d64cd6f00ab@mail.gmail.com> Hi js and Rainer, I've been following the MacPorts threads about Python for a few months now, trying to understand the problems and issues. My vote would be for Option 3: Add dropped mods to python24 and python25 as dependencies. My main goal is to write portable scientific Python applications that will work on both Mac and Windows On Fri, 14 Mar 2008 01:52:02 +0900, js wrote: I think it's about a time to decide how we handle this. I wanted to change python24 to be python25-like design for consistency. Derek disagreed this idea from python24 users standpoint. Rainer seemed to agree with me, but might not like adding dropped mods to python port as dependencies. Options: 1. Change python24 to drop standard mods just as python25 does. 2. Don't change anything. 3. 1+add dropped mods to python24 and python25 as dependencies I like the first one. How about you? On Wed, Mar 12, 2008 at 10:08 PM, js wrote: > The benefit is that python24 and python25 both uses almost same standard mods. > Please note that I'm not sure adding this dependency is good thing. > I just wanted to say keeping python ports similar would preferable, in > my opinion. > > > > > On Wed, Mar 12, 2008 at 6:12 AM, Rainer M?ller wrote: > > js wrote: > > > If I add zlib dependency to python24, I'd also add it to python25. > > > > But if you you add it as dependency, what is the benefit from putting it > > in its own port? > > > > Rainer From dluke at geeklair.net Mon Mar 17 07:32:22 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon Mar 17 07:31:46 2008 Subject: Maintainer away tracking In-Reply-To: <47DE7F8A.3080908@macports.org> References: <47D48A05.2080301@macports.org> <47DE740A.20904@macports.org> <47DE7F8A.3080908@macports.org> Message-ID: <1133D61D-1EA0-456C-AF96-2AB84764FE52@geeklair.net> On Mar 17, 2008, at 10:26 AM, Rainer M?ller wrote: >> In addition, ports that are seriously broken (ie, don't build, >> security vulnerability, distfile no longer available) can be fixed >> to work (without major changes) without waiting for the timeout >> already. > > These points are not exactly clarified in the guide. > # A critical port is broken that affects many users. > Doesn't sound like 'missing distfile' or 'doesn't build' to me. I > can't find another section regarding committing without maintainers' > acknowledgment. I don't recall where it was documented, but it had been discussed on the mailing lists (perhaps quite a while ago). It may have even been in the old darwinports committer information. A committer may make a minimal change to a port that is broken in order to fix it without waiting for the 72hr timeout (it's good to still ping the maintainer, though). If it's not documented anywhere anymore, we should probably get the documentation updated. >> I don't see the additional speed benefit as worth the extra book >> keeping. > > The extra book keeping is done my each individual maintainer. So not > much work for a maintainers themself. it's still extra work ;-) >> That said, I'm not going to object if others want to use it (I do >> know that I don't really plan on advertising to the world any time >> I may be going away on vacation). > > Hm, why not? You are not going to be around for any work on > MacPorts, so tell the project about it. If we know you are just away > for a few days, someone could also hold on committing not-so- > important tickets until the known date at which you are back. ... because I feel that the 72 hour timeout is sufficient, and I don't like the idea of a public place where people could get a good indication that my house is probably empty. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080317/fe5cb2f0/PGP.bin From sal at ri.cmu.edu Mon Mar 17 07:44:50 2008 From: sal at ri.cmu.edu (Salvatore Domenick Desiano) Date: Mon Mar 17 07:52:13 2008 Subject: Maintainer away tracking In-Reply-To: <3D90B934-B5C4-445E-ADE2-A967B40D1311@geeklair.net> References: <47D48A05.2080301@macports.org> <47DE740A.20904@macports.org> <3D90B934-B5C4-445E-ADE2-A967B40D1311@geeklair.net> Message-ID: o > If there was some way to indicate that something o > required action by me, o o like say, a ticket assigned or CC'd to you? ;-) Is that true? If I, at a minimum, look at all e-mails cc'd to me, will that be sufficent to make sure I'm not holding anyone up? If not, maybe that would be a good policy. I'm pretty sure there are tasks that don't require tickets, so, I don't think that's enough, but maybe that would work... Maybe, if someone is about to clarify the 72 hour rule, they could add "the 72 hours begins when the maintainer has been directly e-mailed regarding the change". Then I'll update my filters. As for the vacation page, I also would not advertise being on "vacation", but I don't mind if anyone else does. -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University From harrylparker at gmail.com Mon Mar 17 07:46:51 2008 From: harrylparker at gmail.com (Harry Parker) Date: Mon Mar 17 07:54:24 2008 Subject: [MacPorts] #14342: python25 drops modules by default, but python2[4] doesn't (js) In-Reply-To: <2a77b9140803170730u254a5c28re56d9d64cd6f00ab@mail.gmail.com> References: <2a77b9140803170730u254a5c28re56d9d64cd6f00ab@mail.gmail.com> Message-ID: <2a77b9140803170746q6b7fdec5hcaf821a2d55d6cd8@mail.gmail.com> Hi js and Rainer, [I accidentally hit send, before I finished my last message. Here is what I wanted to write.] I've been following the MacPorts threads about Python for a few months now, trying to understand the problems and issues. My vote would be for Option 3: Add dropped mods to python24 and python25 as dependencies. My main Python goal is to write portable scientific Python applications that will work on both Mac and Windows. To that end, Python on Mac should be as close to the standard distribution of Python as possible. Dropping modules from the standard distribution breaks things. I spent most of a week tracking down problems why my simple, portable application did not work on MacPorts' Python, only to finally discover that I had to add additional ports to get what was one install on Windows or Unix or Linux. (py-hashlib was missing.) Why? I thought the main goal of MacPorts was to make installation simple. Splitting standard distributions into multiple ports is going in the opposite direction. If someone wants a minimal install, that could be a variant, but the default should be a full install. Thanks for working on this. -- Harry Parker On Fri, 14 Mar 2008 01:52:02 +0900, js wrote: > > I think it's about a time to decide how we handle this. > I wanted to change python24 to be python25-like design for consistency. > Derek disagreed this idea from python24 users standpoint. > Rainer seemed to agree with me, but might not like adding dropped mods > to python port as dependencies. > > Options: > 1. Change python24 to drop standard mods just as python25 does. > 2. Don't change anything. > 3. 1+add dropped mods to python24 and python25 as dependencies > > I like the first one. > How about you? > > > On Wed, Mar 12, 2008 at 10:08 PM, js wrote: > > The benefit is that python24 and python25 both uses almost same > standard mods. > > Please note that I'm not sure adding this dependency is good thing. > > I just wanted to say keeping python ports similar would preferable, in > > my opinion. > > > > > > > > > > On Wed, Mar 12, 2008 at 6:12 AM, Rainer M?ller wrote: > > > js wrote: > > > > If I add zlib dependency to python24, I'd also add it to python25. > > > > > > But if you you add it as dependency, what is the benefit from putting it > > > in its own port? > > > > > > Rainer > From raimue at macports.org Mon Mar 17 07:53:57 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Mar 17 08:05:16 2008 Subject: Maintainer away tracking In-Reply-To: References: <47D48A05.2080301@macports.org> <47DE740A.20904@macports.org> <3D90B934-B5C4-445E-ADE2-A967B40D1311@geeklair.net> Message-ID: <47DE8605.9070509@macports.org> Salvatore Domenick Desiano wrote: > o > If there was some way to indicate that something > o > required action by me, > o > o like say, a ticket assigned or CC'd to you? ;-) > > Is that true? If I, at a minimum, look at all e-mails cc'd to me, will > that be sufficent to make sure I'm not holding anyone up? If not, maybe > that would be a good policy. I'm pretty sure there are tasks that don't > require tickets, so, I don't think that's enough, but maybe that would > work... You can also query the Trac database to find cc'ed tickets: http://trac.macosforge.org/projects/macports/query?cc=$EMAIL If you are set on CC for a ticket, Trac also sends the mail with your email address in the CC header. If you are the reporter or assignee, your email address is in the To header. > Maybe, if someone is about to clarify the 72 hour rule, they could add > "the 72 hours begins when the maintainer has been directly e-mailed > regarding the change". Right, this should be added. Rainer From sal at ri.cmu.edu Mon Mar 17 09:22:47 2008 From: sal at ri.cmu.edu (Salvatore Domenick Desiano) Date: Mon Mar 17 09:22:07 2008 Subject: Maintainer away tracking In-Reply-To: <47DE8605.9070509@macports.org> References: <47D48A05.2080301@macports.org> <47DE740A.20904@macports.org> <3D90B934-B5C4-445E-ADE2-A967B40D1311@geeklair.net> <47DE8605.9070509@macports.org> Message-ID: o > o > If there was some way to indicate that something o > o > required action by me, o > o o like say, a ticket assigned or CC'd to you? ;-) o > o > Is that true? If I, at a minimum, look at all e-mails cc'd to me, will that o > be sufficent to make sure I'm not holding anyone up? If not, maybe that o > would be a good policy. I'm pretty sure there are tasks that don't require o > tickets, so, I don't think that's enough, but maybe that would work... o o You can also query the Trac database to find cc'ed tickets: o http://trac.macosforge.org/projects/macports/query?cc=$EMAIL o o If you are set on CC for a ticket, Trac also sends the mail with your email o address in the CC header. If you are the reporter or assignee, your email o address is in the To header. This requires polling. Is there a "push" way to ensure that you know about any tickets for your ports? Can we guarantee that the maintainer(s) are listed as CC's (I can't think of a situation where they shouldn't be). -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University From ryandesign at macports.org Tue Mar 18 14:15:19 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 18 Mar 2008 16:15:19 -0500 Subject: curl 7.16.3 on Mac OS X 10.4.11 Tiger Message-ID: Looks like Security Update 2008-02 updates curl on Mac OS X 10.4.11 Tiger from 7.13.1 to 7.16.3. Thought this might be relevant to the -- remote-time option Anders was using / trying to use... From afb at macports.org Wed Mar 19 00:23:52 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 19 Mar 2008 08:23:52 +0100 Subject: curl 7.16.3 on Mac OS X 10.4.11 Tiger In-Reply-To: References: Message-ID: Ryan Schmidt wrote: > Looks like Security Update 2008-02 updates curl on Mac OS X 10.4.11 > Tiger from 7.13.1 to 7.16.3. Thought this might be relevant to the > --remote-time option Anders was using / trying to use... Yeah, I guess it's good that it is finally updated - already worked around the issue for original Tiger though. So we could enable the feature now, just that there isn't many that actually care about timestamps it seems... --anders From ryandesign at macports.org Wed Mar 19 00:44:20 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 19 Mar 2008 02:44:20 -0500 Subject: curl 7.16.3 on Mac OS X 10.4.11 Tiger In-Reply-To: References: Message-ID: On Mar 19, 2008, at 02:23, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >> Looks like Security Update 2008-02 updates curl on Mac OS X >> 10.4.11 Tiger from 7.13.1 to 7.16.3. Thought this might be >> relevant to the --remote-time option Anders was using / trying to >> use... > > Yeah, I guess it's good that it is finally updated - already worked > around the issue for original Tiger though. > > So we could enable the feature now, just that there isn't many that > actually care about timestamps it seems... I like timestamps! :) From ryandesign at macports.org Wed Mar 19 04:32:32 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 19 Mar 2008 06:32:32 -0500 Subject: [35110] trunk/dports/gnome/gnucash In-Reply-To: <20080317174748.5275014BD313@beta.macosforge.org> References: <20080317174748.5275014BD313@beta.macosforge.org> Message-ID: <01A9F86B-0BDD-4DEF-9FE3-EAD4D1357872@macports.org> On Mar 17, 2008, at 12:47, reiffert at macports.org wrote: > Revision: 35110 > http://trac.macosforge.org/projects/macports/changeset/35110 > Author: reiffert at macports.org > Date: 2008-03-17 10:47:47 -0700 (Mon, 17 Mar 2008) > > Log Message: > ----------- > gnucash 2.2.4, fixing: > #14297 (Update gnucash) > #13316 (binreloc error) > #13472 (Fails to build on leopard) > #13852 (Fails to compile) [snip] > -default_variants +guile16 > +default_variants +guile16 +without-docs > -variant without_docs { > +variant without_docs description {Does not build gnucash-docs} { > depends_lib-delete port:gnucash-docs > } In the default variants, hyphen is not a valid character in variant names, and the variant is in fact named without_docs (with an underscore, not a hyphen). However, if you're going to make it the default to build without documentation, then the variant should be changed to be called "docs" (or "with_docs" if you insist on that nonstandard naming convention). Default variants are buggy during upgrades and should be avoided. From reiffert at macports.org Wed Mar 19 04:36:45 2008 From: reiffert at macports.org (Thomas Reifferscheid) Date: Wed, 19 Mar 2008 12:36:45 +0100 Subject: [35110] trunk/dports/gnome/gnucash In-Reply-To: <01A9F86B-0BDD-4DEF-9FE3-EAD4D1357872@macports.org> References: <20080317174748.5275014BD313@beta.macosforge.org> <01A9F86B-0BDD-4DEF-9FE3-EAD4D1357872@macports.org> Message-ID: <47E0FACD.6040208@macports.org> Thanks for pointing that out. Besides I'm currently fixing another problem along with gnucash: It doesnt find its docs. I'm actually getting closer to a solution, so I think I'll upload a new revision later this day. Kind regards Thomas Ryan Schmidt wrote: > On Mar 17, 2008, at 12:47, reiffert at macports.org wrote: > >> Revision: 35110 >> http://trac.macosforge.org/projects/macports/changeset/35110 >> Author: reiffert at macports.org >> Date: 2008-03-17 10:47:47 -0700 (Mon, 17 Mar 2008) >> >> Log Message: >> ----------- >> gnucash 2.2.4, fixing: >> #14297 (Update gnucash) >> #13316 (binreloc error) >> #13472 (Fails to build on leopard) >> #13852 (Fails to compile) > > [snip] > >> -default_variants +guile16 >> +default_variants +guile16 +without-docs > >> -variant without_docs { >> +variant without_docs description {Does not build gnucash-docs} { >> depends_lib-delete port:gnucash-docs >> } > > In the default variants, hyphen is not a valid character in variant > names, and the variant is in fact named without_docs (with an > underscore, not a hyphen). > > However, if you're going to make it the default to build without > documentation, then the variant should be changed to be called "docs" > (or "with_docs" if you insist on that nonstandard naming convention). > Default variants are buggy during upgrades and should be avoided. > From ryandesign at macports.org Wed Mar 19 04:44:16 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 19 Mar 2008 06:44:16 -0500 Subject: [35147] trunk/dports/editors/efte/Portfile In-Reply-To: <20080318123245.E350714C178E@beta.macosforge.org> References: <20080318123245.E350714C178E@beta.macosforge.org> Message-ID: <8BDD85CF-B376-47BA-BF88-3528407233CC@macports.org> On Mar 18, 2008, at 07:32, reiffert at macports.org wrote: > Revision: 35147 > http://trac.macosforge.org/projects/macports/changeset/35147 > Author: reiffert at macports.org > Date: 2008-03-18 05:32:43 -0700 (Tue, 18 Mar 2008) > > Log Message: > ----------- > efte: making variant x11 the default variant > > Modified Paths: > -------------- > trunk/dports/editors/efte/Portfile > > Modified: trunk/dports/editors/efte/Portfile > =================================================================== > --- trunk/dports/editors/efte/Portfile 2008-03-18 10:39:45 UTC (rev > 35146) > +++ trunk/dports/editors/efte/Portfile 2008-03-18 12:32:43 UTC (rev > 35147) > @@ -16,7 +16,7 @@ > homepage http://efte.sourceforge.net > master_sites http://downloads.sourceforge.net/sourceforge/efte/ > checksums efte-${version}.tar.gz md5 > ae60a3056e73d4655569f455e4c6283e > - > +default_variants +x11 Here also you'll want to instead convert the x11 variant to a no_x11 variant, and not use default_variants. From afb at macports.org Wed Mar 19 05:00:47 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 19 Mar 2008 13:00:47 +0100 Subject: default_variants / upgrades In-Reply-To: <01A9F86B-0BDD-4DEF-9FE3-EAD4D1357872@macports.org> References: <20080317174748.5275014BD313@beta.macosforge.org> <01A9F86B-0BDD-4DEF-9FE3-EAD4D1357872@macports.org> Message-ID: <45A2F370-7301-473C-8E35-2D6F2FEBA8C2@macports.org> Ryan Schmidt wrote: > However, if you're going to make it the default to build without > documentation, then the variant should be changed to be called > "docs" (or "with_docs" if you insist on that nonstandard naming > convention). Default variants are buggy during upgrades and should be > avoided. ... > Here also you'll want to instead convert the x11 variant to a no_x11 > variant, and not use default_variants. So, you think "default_variants" should be removed instead of fixed ? Or is this one of those interim workarounds, until upgrades work OK ? Does it work when not using "upgrade", but just deactivate/activate ? I hardly ever get upgrades to work at all, but that's probably just me. --anders From raimue at macports.org Wed Mar 19 06:39:19 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 19 Mar 2008 14:39:19 +0100 Subject: default_variants / upgrades In-Reply-To: <45A2F370-7301-473C-8E35-2D6F2FEBA8C2@macports.org> References: <20080317174748.5275014BD313@beta.macosforge.org> <01A9F86B-0BDD-4DEF-9FE3-EAD4D1357872@macports.org> <45A2F370-7301-473C-8E35-2D6F2FEBA8C2@macports.org> Message-ID: <47E11787.5060604@macports.org> Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >> However, if you're going to make it the default to build without >> documentation, then the variant should be changed to be called >> "docs" (or "with_docs" if you insist on that nonstandard naming >> convention). Default variants are buggy during upgrades and should be >> avoided. > ... >> Here also you'll want to instead convert the x11 variant to a no_x11 >> variant, and not use default_variants. > > So, you think "default_variants" should be removed instead of fixed ? > Or is this one of those interim workarounds, until upgrades work OK ? I also don't like these "no_*" variants, because they are semantically incorrect. And once we get this fixed we should rename these variants to get rid of the "no_" prefix. And that will cause some more trouble for people using them... But I neither know a better workaround at the moment, nor do I know how to fix it properly. Not sure what the fix would be; store deselected variants in the registry or remove default_variants when using upgrade. I think ticket #2377 [1] is related, although I can't find a ticket exactly for this default_variants problem. Maybe it does not include the right keywords? As our tickets are growing exponentially, it is not easy to find a specific ticket... Rainer [1] http://trac.macosforge.org/projects/macports/ticket/2377 From raimue at macports.org Wed Mar 19 18:15:51 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Thu, 20 Mar 2008 02:15:51 +0100 Subject: [34977] trunk/base In-Reply-To: <20080313141352.0844714A0BA2@beta.macosforge.org> References: <20080313141352.0844714A0BA2@beta.macosforge.org> Message-ID: <47E1BAC7.6020807@macports.org> eridius at macports.org wrote: > Revision > 34977 > Author > eridius at macports.org > Date > 2008-03-13 07:13:51 -0700 (Thu, 13 Mar 2008) > > > Log Message > > Add new --recursive option to port uninstall to uninstall dependents (#14637) I'm not quite happy with the name --recursive, because it does not imply in which direction we recurse. I would rather propose something like --with-dependents or --follow-dependents. Although this is longer, but much more clear. We were also talking about 'recursive dependencies' before, especially for 'port deps'. But in that case it was meant following dependencies, not dependents. So --recursive might really lead to confusion here. In order to provide a consistent interface, we should define two options for this. One for following dependencies and one for following dependents. (And even one for doing both?) Currently, we also have the global -R und -n flags which are only used by upgrade and -u which is used by uninstall and upgrade. In my opinion these should not be global because they are only used by one or two targets. Therefore these should use the same naming convention. Rainer From simon at ruderich.com Thu Mar 20 06:34:50 2008 From: simon at ruderich.com (Simon Ruderich) Date: Thu, 20 Mar 2008 14:34:50 +0100 Subject: Splitting the guide In-Reply-To: <47CFEBF0.40901@macports.org> References: <47CFEBF0.40901@macports.org> Message-ID: <20080320133450.GA6155@ruderich.com> On Thu, Mar 06, 2008 at 02:04:48PM +0100, Rainer M?ller wrote: > simon at ruderich.com wrote: >>> I just tried this using DocBook but it didn't work for me. So I used a >>> simple >>> sed replacement to get this working. I created two examples: >>> http://ruderich.com/macports/guide-link.html > > I like this one with the links. It makes it easy to get the URL which links > exactly to this section. Good work! > > [snip] > > Rainer Hi Rainer, sorry for the late reply. I'm glad you like it. I just [1] committed the change and now the guide makes it easy to link to subsections. Thanks for the suggestion. Simon [1]: http://trac.macports.org/projects/macports/changeset/35199 -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080320/dadaffb3/attachment.bin From ryandesign at macports.org Thu Mar 20 15:11:10 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 20 Mar 2008 17:11:10 -0500 Subject: new port search format Message-ID: <1F9310FF-C538-4B9A-AC16-06D5F61F7B69@macports.org> I must say I find the new "port search" output format that's in trunk very hard to read. Before, we had roughly a table, and I could scan down the left column to read the port names. Now the description is in roughly the same place -- albeit indented by a couple spaces but it still interferes with my ability to scan the left column, which is no longer a column. From raimue at macports.org Thu Mar 20 16:00:04 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 21 Mar 2008 00:00:04 +0100 Subject: Splitting the guide In-Reply-To: <20080320133450.GA6155@ruderich.com> References: <47CFEBF0.40901@macports.org> <20080320133450.GA6155@ruderich.com> Message-ID: <47E2EC74.6020407@macports.org> Simon Ruderich wrote: > Hi Rainer, > > sorry for the late reply. > > I'm glad you like it. I just [1] committed the change and now the guide makes > it easy to link to subsections. Thanks for the suggestion. Thanks for the implementation :) I really like it. Rainer From raimue at macports.org Thu Mar 20 16:01:26 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 21 Mar 2008 00:01:26 +0100 Subject: new port search format In-Reply-To: <1F9310FF-C538-4B9A-AC16-06D5F61F7B69@macports.org> References: <1F9310FF-C538-4B9A-AC16-06D5F61F7B69@macports.org> Message-ID: <47E2ECC6.9020704@macports.org> Ryan Schmidt wrote: > I must say I find the new "port search" output format that's in trunk > very hard to read. Before, we had roughly a table, and I could scan > down the left column to read the port names. Now the description is > in roughly the same place -- albeit indented by a couple spaces but > it still interferes with my ability to scan the left column, which is > no longer a column. I found it unreadable before. The old format used a scheme which did not work with any terminal size. If your window was smaller than the description, it was wrapped to the next line. So there wasn't a clear first column before either, because the descriptions were 'too long'. So I decided to use an output format which will work on any terminal size with at least 80 columns (the often used standard). And with a break at 80 chars also longer descriptions are nice to read. Maybe we could also put the version and categories in a new line, so there will be always the first line of a output block with the port's name and nothing else? Rainer From macports-mgr at lists.macosforge.org Thu Mar 20 17:33:11 2008 From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org) Date: Thu, 20 Mar 2008 17:33:11 -0700 (PDT) Subject: PortIndex2MySQL run failure on Thursday 2008-03-20 at 17:33:11 Message-ID: <20080321003311.E0E9CAC5D82@extol.apple.com> Testing fail emails: 3 From jkh at apple.com Thu Mar 20 18:07:00 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Thu, 20 Mar 2008 18:07:00 -0700 Subject: new port search format In-Reply-To: <47E2ECC6.9020704@macports.org> References: <1F9310FF-C538-4B9A-AC16-06D5F61F7B69@macports.org> <47E2ECC6.9020704@macports.org> Message-ID: <043EAB26-2D18-413A-A069-DF4F02EA1F01@apple.com> It should be customizable, using some sort of format string. - Jordan On Mar 20, 2008, at 4:01 PM, Rainer M?ller wrote: > Maybe we could also put the version and categories in a new line, so > there will be always the first line of a output block with the port's > name and nothing else? From wsiegrist at apple.com Thu Mar 20 18:16:08 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 20 Mar 2008 18:16:08 -0700 Subject: new port search format In-Reply-To: <47E2ECC6.9020704@macports.org> References: <1F9310FF-C538-4B9A-AC16-06D5F61F7B69@macports.org> <47E2ECC6.9020704@macports.org> Message-ID: <8FB86FE7-FF6D-41B3-A7E5-757FDF3826F7@apple.com> Maybe something along the lines of the "w" option to ps? Or a verbose flag that turns on/off the descriptions? -Bill On Mar 20, 2008, at 4:01 PM, Rainer M?ller wrote: > Ryan Schmidt wrote: >> I must say I find the new "port search" output format that's in trunk >> very hard to read. Before, we had roughly a table, and I could scan >> down the left column to read the port names. Now the description is >> in roughly the same place -- albeit indented by a couple spaces but >> it still interferes with my ability to scan the left column, which is >> no longer a column. > > I found it unreadable before. The old format used a scheme which did > not > work with any terminal size. If your window was smaller than the > description, it was wrapped to the next line. So there wasn't a clear > first column before either, because the descriptions were 'too long'. > > So I decided to use an output format which will work on any terminal > size with at least 80 columns (the often used standard). And with a > break at 80 chars also longer descriptions are nice to read. > > Maybe we could also put the version and categories in a new line, so > there will be always the first line of a output block with the port's > name and nothing else? > > Rainer > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080320/a3e6906c/attachment-0001.bin From raimue at macports.org Thu Mar 20 18:18:08 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 21 Mar 2008 02:18:08 +0100 Subject: new port search format In-Reply-To: <043EAB26-2D18-413A-A069-DF4F02EA1F01@apple.com> References: <1F9310FF-C538-4B9A-AC16-06D5F61F7B69@macports.org> <47E2ECC6.9020704@macports.org> <043EAB26-2D18-413A-A069-DF4F02EA1F01@apple.com> Message-ID: <47E30CD0.2090207@macports.org> Jordan K. Hubbard wrote: > It should be customizable, using some sort of format string. Sounds like over-engineering. Rainer From raimue at macports.org Thu Mar 20 18:23:40 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 21 Mar 2008 02:23:40 +0100 Subject: new port search format In-Reply-To: <8FB86FE7-FF6D-41B3-A7E5-757FDF3826F7@apple.com> References: <1F9310FF-C538-4B9A-AC16-06D5F61F7B69@macports.org> <47E2ECC6.9020704@macports.org> <8FB86FE7-FF6D-41B3-A7E5-757FDF3826F7@apple.com> Message-ID: <47E30E1C.1020502@macports.org> William Siegrist wrote: > Maybe something along the lines of the "w" option to ps? Or a verbose > flag that turns on/off the descriptions? Hm, we could remove the descriptions by default and only show it in verbose mode. Although, then users might miss the descriptions at all? If you only want the port names without version information or descriptions, you can already use `port -q search`. Rainer From reiffert at macports.org Thu Mar 20 18:48:34 2008 From: reiffert at macports.org (Thomas Reifferscheid) Date: Fri, 21 Mar 2008 02:48:34 +0100 Subject: Guidance needed for fixing gnome Message-ID: <47E313F2.7030705@macports.org> Hi, please help me to improve the gnome situation and validate Ticket 14729 [1] to be correct. How should we proceed here? Kind regards Thomas [1] http://trac.macosforge.org/projects/macports/ticket/14729 From macports-mgr at lists.macosforge.org Thu Mar 20 19:33:30 2008 From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org) Date: Thu, 20 Mar 2008 19:33:30 -0700 (PDT) Subject: PortIndex2MySQL run failure on Thursday 2008-03-20 at 19:33:30 Message-ID: <20080321023330.97EB03629CB@localhost> Testing fail emails: 3 From rbeyer at rossbeyer.net Thu Mar 20 21:21:57 2008 From: rbeyer at rossbeyer.net (Ross A. Beyer) Date: Thu, 20 Mar 2008 21:21:57 -0700 Subject: Ticket #14679 Message-ID: <78E2DE52-9540-4ED6-A843-BF3E41D1725B@rossbeyer.net> dev, I'm new to submitting Trac tickets, and I "assigned" Ticket #14679 ( http://trac.macports.org/projects/macports/ticket/14679 ) to macports-tickets at lists.macosforge.org. However, in reading the documentation again, I see I should have "assigned" this ticket to the maintainer, minskim at bawi.org. Could you change that for me, so the maintainer can be properly contacted? Thanks. I informally e-mailed the maintainer a week before I submitted the ticket without a response, so they may not respond anyway. Thanks. Ross From ryandesign at macports.org Thu Mar 20 21:37:08 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 20 Mar 2008 23:37:08 -0500 Subject: new port search format In-Reply-To: <47E30E1C.1020502@macports.org> References: <1F9310FF-C538-4B9A-AC16-06D5F61F7B69@macports.org> <47E2ECC6.9020704@macports.org> <8FB86FE7-FF6D-41B3-A7E5-757FDF3826F7@apple.com> <47E30E1C.1020502@macports.org> Message-ID: <08FD6EC8-24E3-4A45-89C5-5D2BC1CBB1FF@macports.org> On Mar 20, 2008, at 20:23, Rainer M?ller wrote: > William Siegrist wrote: > >> Maybe something along the lines of the "w" option to ps? Or a >> verbose flag that turns on/off the descriptions? > > Hm, we could remove the descriptions by default and only show it in > verbose mode. Although, then users might miss the descriptions at all? > > If you only want the port names without version information or > descriptions, you can already use `port -q search`. No, I don't want any of that, I just want what we had before. :) I agree it got to be a mess when descriptions were longer than the terminal window, which is why I have a shortcut to maximize a window, and use it often in the terminal. A better solution would be intelligent word wrapping in the software, so thank you for implementing that. But it would be better if we could keep the 3- column format we had before, and just wrap the description within that third column if necessary. From peter at pogma.com Thu Mar 20 22:57:49 2008 From: peter at pogma.com (Peter O'Gorman) Date: Fri, 21 Mar 2008 00:57:49 -0500 Subject: new port search format In-Reply-To: <47E2ECC6.9020704@macports.org> References: <1F9310FF-C538-4B9A-AC16-06D5F61F7B69@macports.org> <47E2ECC6.9020704@macports.org> Message-ID: <47E34E5D.7050001@pogma.com> Rainer M?ller wrote: > Ryan Schmidt wrote: >> I must say I find the new "port search" output format that's in trunk >> very hard to read. Before, we had roughly a table, and I could scan >> down the left column to read the port names. Now the description is >> in roughly the same place -- albeit indented by a couple spaces but >> it still interferes with my ability to scan the left column, which is >> no longer a column. > > I found it unreadable before. The old format used a scheme which did not > work with any terminal size. If your window was smaller than the > description, it was wrapped to the next line. So there wasn't a clear > first column before either, because the descriptions were 'too long'. Work out the width of the terminal `tput cols', default to 80 if you can't figure it out, and work from there (test first if it is a tty, of course, if not output can be as verbose as you like, it's either going to a file or a pipe). Peter -- Peter O'Gorman http://pogma.com From randall.h.wood at alexandriasoftware.com Fri Mar 21 01:04:23 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Fri, 21 Mar 2008 04:04:23 -0400 Subject: Fwd: Guidance needed for fixing gnome In-Reply-To: References: <47E313F2.7030705@macports.org> Message-ID: Should have sent to the mailing list... ---------- Forwarded message ---------- From: Randall Wood Date: Fri, Mar 21, 2008 at 4:03 AM Subject: Re: Guidance needed for fixing gnome To: Thomas Reifferscheid On Thu, Mar 20, 2008 at 9:48 PM, Thomas Reifferscheid wrote: > Hi, > > please help me to improve the gnome situation and validate Ticket 14729 [1] > to be correct. > > How should we proceed here? I think that the best (long term) way to succeed would be to create a gnome portgroup that provides port with some generic mechanism to discover the schema files that need installation and do it auto-magically. > Kind regards > Thomas > > [1] http://trac.macosforge.org/projects/macports/ticket/14729 > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -- Randall Wood randall.h.wood at alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From ryandesign at macports.org Fri Mar 21 02:29:26 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 21 Mar 2008 04:29:26 -0500 Subject: Ticket #14679 In-Reply-To: <78E2DE52-9540-4ED6-A843-BF3E41D1725B@rossbeyer.net> References: <78E2DE52-9540-4ED6-A843-BF3E41D1725B@rossbeyer.net> Message-ID: <87054A00-6C57-49A5-A65D-44A9444F9689@macports.org> On Mar 20, 2008, at 23:21, Ross A. Beyer wrote: > I'm new to submitting Trac tickets, and I "assigned" Ticket #14679 > ( http://trac.macports.org/projects/macports/ticket/14679 ) > to macports-tickets at lists.macosforge.org. However, in reading the > documentation again, I see I should have "assigned" this ticket to > the maintainer, minskim at bawi.org. Could you change that for me, so > the maintainer can be properly contacted? Thanks. > > I informally e-mailed the maintainer a week before I submitted the > ticket without a response, so they may not respond anyway. Thanks. minskim is not a committer and so doesn't appear in the "Assign To" popup menu. You've already Cc'd the maintainer, which is the next best thing. If the maintainer does not respond to the ticket within 72 hours another committer can commit the fix. Since it's already been 5 days, any committer should feel free to handle this ticket now. From raimue at macports.org Fri Mar 21 04:55:16 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 21 Mar 2008 12:55:16 +0100 Subject: new port search format In-Reply-To: <08FD6EC8-24E3-4A45-89C5-5D2BC1CBB1FF@macports.org> References: <1F9310FF-C538-4B9A-AC16-06D5F61F7B69@macports.org> <47E2ECC6.9020704@macports.org> <8FB86FE7-FF6D-41B3-A7E5-757FDF3826F7@apple.com> <47E30E1C.1020502@macports.org> <08FD6EC8-24E3-4A45-89C5-5D2BC1CBB1FF@macports.org> Message-ID: <47E3A224.5040601@macports.org> Ryan Schmidt wrote: > No, I don't want any of that, I just want what we had before. :) You really just want to revert back to the old messy format? > I agree it got to be a mess when descriptions were longer than the > terminal window, which is why I have a shortcut to maximize a window, > and use it often in the terminal. A better solution would be > intelligent word wrapping in the software, so thank you for > implementing that. But it would be better if we could keep the 3- > column format we had before, and just wrap the description within > that third column if necessary. So you use a workaround with maximizing the window for you personally. Why use a workaround instead of fixing it by using a new output format? Should we add a line like "Please maximize your terminal window if you want readable output" to the guide? Please not! New word wrapping wouldn't help in the old format. The third column would not become more readable in a 80 columns terminal. There is not even a 'third column' in the old output, the description just starts anywhere. Also the path to the Portfile is totally unnecessary, categories are a much more important information. Developers can use `port dir` to find the path. And in general the path is always $category/$name. For example the old output: $ port search python dbus-python24 devel/dbus-python24 0.82.2 Python bindings for the dbus message bus system. dbus-python25 devel/dbus-python25 0.82.4 Python bindings for the dbus message bus system. gnome-bindings-python devel/gnome-bindings-python 2.12 The GNOME bindings for Python ice-python devel/ice-python 3.2.1 Fast, object-oriented RPC for C++, Java, Python, Ruby, PHP subversion-python24bindings devel/subversion-python24bindings 1.4.6 Python bindings for the subversion version control system. ... And now the new output: $ port search python dbus-python24 @0.82.2 (devel) Python bindings for the dbus message bus system. dbus-python25 @0.82.4 (devel) Python bindings for the dbus message bus system. gnome-bindings-python @2.12 (devel, gnome) The GNOME bindings for Python ice-python @3.2.1 (devel, python) Fast, object-oriented RPC for C++, Java, Python, Ruby, PHP subversion-python24bindings @1.4.6 (devel, python) Python bindings for the subversion version control system. ... And you really want that old mess back? I am open for improvement to the new format, but I am clearly against reverting back to the old format. I changed the format because it was so unreadable and annoyed me that much. Rainer From db.evans at gmail.com Fri Mar 21 10:41:48 2008 From: db.evans at gmail.com (David Evans) Date: Fri, 21 Mar 2008 10:41:48 -0700 Subject: Committer help requested In-Reply-To: <048.506218bcde5d2c27d2012ad6cd6e743f@macosforge.org> References: <048.506218bcde5d2c27d2012ad6cd6e743f@macosforge.org> Message-ID: <47E3F35C.2050305@gmail.com> This is to solicit the help of some kind committer in reviewing the following two tickets: Upgrade gconf-editor to 2.22.0 (including registration of schemas with gconf) http://trac.macosforge.org/projects/macports/ticket/14742 Upgrade glade3 to 3.4.3 http://trac.macosforge.org/projects/macports/ticket/14622 Thanks Dave From reiffert at macports.org Fri Mar 21 16:45:38 2008 From: reiffert at macports.org (Thomas Reifferscheid) Date: Sat, 22 Mar 2008 00:45:38 +0100 Subject: Guidance needed for fixing gnome In-Reply-To: References: <47E313F2.7030705@macports.org> Message-ID: <47E448A2.6080207@macports.org> I made some progress. All the details are in Ticket 14729 [1]. Next thing is to do it with a portgroup. Do you think we can use it 1:1? [1]: http://trac.macosforge.org/projects/macports/ticket/14729 Randall Wood wrote: > On Thu, Mar 20, 2008 at 9:48 PM, Thomas Reifferscheid > wrote: > >> Hi, >> >> please help me to improve the gnome situation and validate Ticket 14729 [1] >> to be correct. >> >> How should we proceed here? >> > > I think that the best (long term) way to succeed would be to create a > gnome portgroup that provides port with some generic mechanism to > discover the schema files that need installation and do it > auto-magically. > From raimue at macports.org Sat Mar 22 01:57:04 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Sat, 22 Mar 2008 09:57:04 +0100 Subject: [35247] trunk/dports/net/heimdal/Portfile In-Reply-To: <20080322044557.5D10414CF0BF@beta.macosforge.org> References: <20080322044557.5D10414CF0BF@beta.macosforge.org> Message-ID: <47E4C9E0.9040301@macports.org> landonf at macports.org wrote: > Revision: 35247 > http://trac.macosforge.org/projects/macports/changeset/35247 > Author: landonf at macports.org > Date: 2008-03-21 21:45:53 -0700 (Fri, 21 Mar 2008) > > Log Message: > ----------- > Put heimdal in a seperate prefix. No other ports depend on it, it conflicts with the system kerberos. > Shame, since it's so much nicer than the included MIT kerberos. This port needs destroot.violate_mtree yes as it now installs outside the usual mtree layout. Rainer From m.des at mac.com Sat Mar 22 17:21:25 2008 From: m.des at mac.com (Michelangelo) Date: Sun, 23 Mar 2008 01:21:25 +0100 Subject: Architectural proposal Message-ID: <3598B813-141E-4AEA-8B01-F4B1F1E9A454@mac.com> Hello, I've been thinking about this proposal for the whole day; William has suggested me to write it here, to hear directly from you, to hear your feedbacks and, most thing important for me, your objections. Ah! I was about to forget, my name's Michelangelo De Simone, I'm very pleased to meet you all.:) Synopsis MacPortsDaemon (?MaPoD?) is an additional layer above the existing MacPorts utilities and API that provides asynchronous access to MacPorts functionalities (and new ones) to upper layer clients. It?s based on a pluggable architecture. Visionary scenarios Mike (limited user) wants to use an Adium version built on his own, to accomplish that he launches a MacPorts/MaPoD client, search for Adium in the search box, once he has found it he chooses to build and install it. The client confirms the action to Mike and giving him a notification that his version of Adium will be delivered directly into his ~/ Applications folder once the build process is over. The client becomes immediatly available for new commands. Amanda (limited user) already built Cyberduck but she needs it no more and then she decides to uninstall it. To accomplish that Amanda launches a MacPorts/MaPoD client, search for installed apps, once she has found Cyberduck she select it and mark it for removal. Her client confirms the action and becomes immediatly available for new commands. John (administrator on his own system) decides that Mike and Amanda need Gimp, so he decides to build and install it in order to let Amanda and Mike use it. To do that he launches a MacPorts/MaPoD client, search for Gimp; once he has found it he tells the client to install Gimp system wide, for users to use it. His client confirms the action and becomes immediatly available for new commands. Amanda (limited user) needs Gimp, so she starts looking for it with her MacPorts/MaPoD client and asks the client to build and install it. Client notifies Amanda that Gimp is already being built because of John choice to deploy it system wide and that she we?ll be able to use in some time; MacPorts/MaPoD will notify her with a Growl notification when Gimp will be ready to be used. Mike (limted user) asks himself how to remove objects and ?stuff? produced by MacPorts/MaPoD and finds out that there?s no reason to be concerned about because MacPorts/MaPoD mantains itself scheduling maintance operations at the right time. Amanda (limted user) worries about tree sync and tries to manually update it using her client but it notifies her that the latest sync has been done automatically by MacPorts/MaPoD itself yesterday night. MaPoD Architecture Overview MaPoD aims to provide MacPorts additional features applying de- coupling among actual and future software components. See pic here: http://snipurl.com/22dyy The whole architecture of MaPoD shall be developed as a system service (LaunchDaemon), letting the clients at the upper layer request services asynchronously (?Build Adium, notify me when you are done?); users could also benefit from scheduled/automatic maintance operations such as self-update, application upgrades, tree syncs, objects cleanup. MaPoD Core ?s task is to accomplish basic functionalities, wrapping those already provided by MacPorts? port and adding them mechanism such scheduling, permission managment, event notifications (?Adium succesfully built by John?). No user on the system should sudo to build an app for his own use. MaPoD Interface is the real glue between MaPoD/MacPorts and GUI. Clients and MaPoD are completely loosly coupled because MaPod Interface provides a neutral way for them to communicate. Third party MacPorts developers could develop plugins to extend core functionalities (?Build Adium, notify me when you are done with a Growl notification? or ?Build Adium, notify me when you are done with an email to jdoe at apple.com?). Conclusions With the appropriate choices any user on the same system, even limited ones, would see a full-featured MacPorts ?distribution?; any user will have the possibility to search, install (from source or normal binary), remove his application with no touch to MacPorts at all. System administrator would also benefit from a fine grained permission system (?Do not let Mike build Adium? or ?John can build and install only between 3pm and 9pm?). MacPorts installation would be ?piloted? by MaPoD itself, so there will be no need to sudo-run it for occasional users. It?s clean, it?s ?secure? (you know, Santa believes in security...:)). Whis this architecture possibilities are endless: how long would be needed to develop a plugin to mirror the tree among multiple nodes? How long to develop a web client and an adapter to manage the same build on multiple nodes? Obviuosly MacPorts core should never be used by users/clients, preferring MaPoD way to accomplish tasks. Back to the ground, there is much effort to spend and many issues to solve; first of all: how should MaPoD be launched, with whose privileges and permissions? Which technology should be used to develop all this stuff? Obj-C or C++ would be either good choices, once a good threading model has been decided (NSThread in 10.5 is a slightly forced choice). What about dependencies overlap? To respect decoupling how should MaPoD interface expose its own services? Stream/Socket interface? -- // Et quid amabo nisi quod rerum enigma est? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2409 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080323/5a6d097a/attachment.bin From wsiegrist at apple.com Sat Mar 22 17:42:08 2008 From: wsiegrist at apple.com (William Siegrist) Date: Sat, 22 Mar 2008 17:42:08 -0700 Subject: Architectural proposal In-Reply-To: <3598B813-141E-4AEA-8B01-F4B1F1E9A454@mac.com> References: <3598B813-141E-4AEA-8B01-F4B1F1E9A454@mac.com> Message-ID: By the way, Michelangelo is proposing this in general, but is also looking to do part of this for GSoC. I wanted him to solicit feedback, especially since this idea touches on a lot of the tasks we're looking for in GSoC (privilege separation, GUIs, etc). -Bill On Mar 22, 2008, at 5:21 PM, Michelangelo wrote: > Hello, > > I've been thinking about this proposal for the whole day; William > has suggested me to write it here, to hear directly from you, to > hear your feedbacks and, most thing important for me, your objections. > Ah! I was about to forget, my name's Michelangelo De Simone, I'm > very pleased to meet you all.:) > > Synopsis > MacPortsDaemon (?MaPoD?) is an additional layer above the existing > MacPorts utilities and API that provides asynchronous access to > MacPorts functionalities (and new ones) to upper layer clients. It?s > based on a pluggable architecture. > > Visionary scenarios > Mike (limited user) wants to use an Adium version built on his own, > to accomplish that he launches a MacPorts/MaPoD client, search for > Adium in the search box, once he has found it he chooses to build > and install it. > The client confirms the action to Mike and giving him a notification > that his version of Adium will be delivered directly into his ~/ > Applications folder once the build process is over. The client > becomes immediatly available for new commands. > > Amanda (limited user) already built Cyberduck but she needs it no > more and then she decides to uninstall it. To accomplish that Amanda > launches a MacPorts/MaPoD client, search for installed apps, once > she has found Cyberduck she select it and mark it for removal. Her > client confirms the action and becomes immediatly available for new > commands. > > John (administrator on his own system) decides that Mike and Amanda > need Gimp, so he decides to build and install it in order to let > Amanda and Mike use it. To do that he launches a MacPorts/MaPoD > client, search for Gimp; once he has found it he tells the client to > install Gimp system wide, for users to use it. His client confirms > the action and becomes immediatly available for new commands. > > Amanda (limited user) needs Gimp, so she starts looking for it with > her MacPorts/MaPoD client and asks the client to build and install > it. Client notifies Amanda that Gimp is already being built because > of John choice to deploy it system wide and that she we?ll be able > to use in some time; MacPorts/MaPoD will notify her with a Growl > notification when Gimp will be ready to be used. > > Mike (limted user) asks himself how to remove objects and ?stuff? > produced by MacPorts/MaPoD and finds out that there?s no reason to > be concerned about because MacPorts/MaPoD mantains itself scheduling > maintance operations at the right time. > > Amanda (limted user) worries about tree sync and tries to manually > update it using her client but it notifies her that the latest sync > has been done automatically by MacPorts/MaPoD itself yesterday night. > > MaPoD Architecture Overview > MaPoD aims to provide MacPorts additional features applying de- > coupling among actual and future software components. See pic here: http://snipurl.com/22dyy > > The whole architecture of MaPoD shall be developed as a system > service (LaunchDaemon), letting the clients at the upper layer > request services asynchronously (?Build Adium, notify me when you > are done?); users could also benefit from scheduled/automatic > maintance operations such as self-update, application upgrades, tree > syncs, objects cleanup. > > MaPoD Core ?s task is to accomplish basic functionalities, wrapping > those already provided by MacPorts? port and adding them mechanism > such scheduling, permission managment, event notifications (?Adium > succesfully built by John?). No user on the system should sudo to > build an app for his own use. > > MaPoD Interface is the real glue between MaPoD/MacPorts and GUI. > Clients and MaPoD are completely loosly coupled because MaPod > Interface provides a neutral way for them to communicate. > > Third party MacPorts developers could develop plugins to extend core > functionalities (?Build Adium, notify me when you are done with a > Growl notification? or ?Build Adium, notify me when you are done > with an email to jdoe at apple.com?). > > Conclusions > With the appropriate choices any user on the same system, even > limited ones, would see a full-featured MacPorts ?distribution?; any > user will have the possibility to search, install (from source or > normal binary), remove his application with no touch to MacPorts at > all. System administrator would also benefit from a fine grained > permission system (?Do not let Mike build Adium? or ?John can build > and install only between 3pm and 9pm?). MacPorts installation would > be ?piloted? by MaPoD itself, so there will be no need to sudo-run > it for occasional users. It?s clean, it?s ?secure? (you know, Santa > believes in security...:)). > > Whis this architecture possibilities are endless: how long would be > needed to develop a plugin to mirror the tree among multiple nodes? > How long to develop a web client and an adapter to manage the same > build on multiple nodes? > > Obviuosly MacPorts core should never be used by users/clients, > preferring MaPoD way to accomplish tasks. > > Back to the ground, there is much effort to spend and many issues to > solve; first of all: how should MaPoD be launched, with whose > privileges and permissions? Which technology should be used to > develop all this stuff? Obj-C or C++ would be either good choices, > once a good threading model has been decided (NSThread in 10.5 is a > slightly forced choice). > > What about dependencies overlap? > > To respect decoupling how should MaPoD interface expose its own > services? Stream/Socket interface? > -- > // Et quid amabo nisi quod rerum enigma est? > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080322/65c4825e/attachment-0001.bin From jkh at apple.com Sun Mar 23 01:11:01 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Sun, 23 Mar 2008 01:11:01 -0700 Subject: Architectural proposal In-Reply-To: <3598B813-141E-4AEA-8B01-F4B1F1E9A454@mac.com> References: <3598B813-141E-4AEA-8B01-F4B1F1E9A454@mac.com> Message-ID: <41FA56A6-2EC5-468A-8D9E-1249E755E801@apple.com> On Mar 22, 2008, at 5:21 PM, Michelangelo wrote: > MacPortsDaemon (?MaPoD?) is an additional layer above the existing > MacPorts utilities and API that provides asynchronous access to > MacPorts functionalities (and new ones) to upper layer clients. It?s > based on a pluggable architecture. Hmmm. OK, so, I read through this description and I read through all the scenarios, then I went back and read the message from start to finish again, just to make sure I hadn't missed any of the subtle details, and my conclusion was the same as the first time: An additional layer to get what you want in the scenarios described sounds like over- engineering. All of the scenarios could just as easily be satisfied by another Cocoa port front-end that does the Growl notifications and the UI and everything else you've described. Such an application could also use the existing port(1) infrastructure directly, no intermediate layer or management daemon would be necessary to install / manage ports in the manner you describe (some of your per-user scenarios aren't particularly compelling, btw, seeing that macports pretty much assumes a single global $prefix and starts to break once you retarget ports piecemeal). If you wanted this capability on the command line, then things become a little different in design and scope, but you still don't need a separate daemon or layer to accomplish something similar to shell job control for multiple outstanding port operations. Don't get me wrong, I think something which lets you manage multiple in-flight operations and provides a good segregated status UI for managing them all is a fine idea, I simply think that a single application can accomplish those goals without needing to change or substantially augment the ports infrastructure at all. Given how limited a commodity time is, I also think that's a good thing. - Jordan From m.des at mac.com Sun Mar 23 11:34:30 2008 From: m.des at mac.com (Michelangelo De Simone) Date: Sun, 23 Mar 2008 19:34:30 +0100 Subject: Architectural proposal In-Reply-To: <41FA56A6-2EC5-468A-8D9E-1249E755E801@apple.com> References: <3598B813-141E-4AEA-8B01-F4B1F1E9A454@mac.com> <41FA56A6-2EC5-468A-8D9E-1249E755E801@apple.com> Message-ID: <69B792C1-BC15-4967-AFBE-DDCF99445171@mac.com> Il giorno 23/mar/08, alle ore 09:11, Jordan K. Hubbard ha scritto: > All of the scenarios could just as easily be satisfied by another > Cocoa port front-end that does the Growl notifications and the UI > and everything else you've described. Such an application could > also use the existing port(1) infrastructure directly, no Thanks for your answer Jordan, hearing your opinion is very important to me. You are right, a classical Cocoa app would solve some of the basic tasks I mentioned, if all that we want is having MacPorts being used by one (experienced) user:); but this would lead to some major challenge once someone will want to setup another client, perhaps a web-based one or a Java-based one (it's just an example:)): he shall write from scratch the entire lower layers of his app to make it work the way he wants, dealing with permissions as well (Task 7). No word about cuncurrent MacPorts running on the same system or the fact that a solution of this kind would be future-proof, in case MacPorts evolved. Generally speaking Task 5 ("GUI") would be easily addressed with an upper layer to manage MacPorts Core. One of the reasons for all this is to make MacPorts easy and affordable even to "naive users" with the help of third party developers who could count on an efficient and no trouble way to use the local MacPorts installation. As you can see I'm speaking quite generally without touching any techincal issue in detail, so I'd really be happy to hear more of your opinions, "just in case".:) Anyway thank you and don't be concerned, I really appreciate direct approaches.:) -- // Et quid amabo nisi quod rerum enigma est? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2409 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080323/086ab791/attachment.bin From raimue at macports.org Sun Mar 23 13:30:12 2008 From: raimue at macports.org (=?windows-1252?Q?Rainer_M=FCller?=) Date: Sun, 23 Mar 2008 21:30:12 +0100 Subject: Architectural proposal In-Reply-To: <3598B813-141E-4AEA-8B01-F4B1F1E9A454@mac.com> References: <3598B813-141E-4AEA-8B01-F4B1F1E9A454@mac.com> Message-ID: <47E6BDD4.90500@macports.org> Michelangelo wrote: > Hello, Hello Michelangelo, > I've been thinking about this proposal for the whole day; William has > suggested me to write it here, to hear directly from you, to hear your > feedbacks and, most thing important for me, your objections. > Ah! I was about to forget, my name's Michelangelo De Simone, I'm very > pleased to meet you all.:) I read your proposal careful to make sure I fully understand it. But I added comments on items where I think this can be solved in other ways or are already possible. > Synopsis > MacPortsDaemon (?MaPoD?) is an additional layer above the existing > MacPorts utilities and API that provides asynchronous access to > MacPorts functionalities (and new ones) to upper layer clients. It?s > based on a pluggable architecture. So this should be a daemon running in the background. I don't like the idea of running compile jobs in the background. Also, I don't see real advantages from it, see comments below. > Visionary scenarios > Mike (limited user) wants to use an Adium version built on his own, to > accomplish that he launches a MacPorts/MaPoD client, search for Adium > in the search box, once he has found it he chooses to build and > install it. > The client confirms the action to Mike and giving him a notification > that his version of Adium will be delivered directly into his ~/ > Applications folder once the build process is over. The client becomes > immediatly available for new commands. So this is mostly a request for running MacPorts as non-root. This could really be improved, for example with an easier installation. Anders already made some additions to make it possible. But currently it needs ./configure flags which are not obvious. > Amanda (limited user) already built Cyberduck but she needs it no more > and then she decides to uninstall it. To accomplish that Amanda > launches a MacPorts/MaPoD client, search for installed apps, once she > has found Cyberduck she select it and mark it for removal. Her client > confirms the action and becomes immediatly available for new commands. Comments below. > John (administrator on his own system) decides that Mike and Amanda > need Gimp, so he decides to build and install it in order to let > Amanda and Mike use it. To do that he launches a MacPorts/MaPoD > client, search for Gimp; once he has found it he tells the client to > install Gimp system wide, for users to use it. His client confirms the > action and becomes immediatly available for new commands. Already possible. If you add /opt/local/bin to the system wide PATH, software installed by MacPorts is available for all users. > Amanda (limited user) needs Gimp, so she starts looking for it with > her MacPorts/MaPoD client and asks the client to build and install it. > Client notifies Amanda that Gimp is already being built because of > John choice to deploy it system wide and that she we?ll be able to use > in some time; MacPorts/MaPoD will notify her with a Growl notification > when Gimp will be ready to be used. I don't think this will happen often. Most Mac OS X installations are used with a single user only and especially not with multiple users at a time. How many times will a user request software to be installed while a system-wide build is running? Also, why should a user not be allowed to compile his/her own version (maybe even newer)? > Mike (limted user) asks himself how to remove objects and ?stuff? > produced by MacPorts/MaPoD and finds out that there?s no reason to be > concerned about because MacPorts/MaPoD mantains itself scheduling > maintance operations at the right time. Who wants jobs kicking in at random time and removing stuff? Also, there is no stuff left from a successful build. Users may decide to keep stuff from unsuccessfull builds in order to try to fix it. > Amanda (limted user) worries about tree sync and tries to manually > update it using her client but it notifies her that the latest sync > has been done automatically by MacPorts/MaPoD itself yesterday night. Install a cronjob. No need for a daemon to accomplish this task. > MaPoD Architecture Overview > MaPoD aims to provide MacPorts additional features applying de- > coupling among actual and future software components. See pic here: http://snipurl.com/22dyy Do you really think anyone wants a web interface for compiling stuff? I doubt that. I also doubt that anyone will write additional clients - for what purpose? > The whole architecture of MaPoD shall be developed as a system service > (LaunchDaemon), letting the clients at the upper layer request > services asynchronously (?Build Adium, notify me when you are done?); > users could also benefit from scheduled/automatic maintance operations > such as self-update, application upgrades, tree syncs, objects cleanup. Leaving out the daemon thing here, you are requesting an API for these task. I think you are right; currently the API does not export these functionality. > MaPoD Core ?s task is to accomplish basic functionalities, wrapping > those already provided by MacPorts? port and adding them mechanism > such scheduling, permission managment, event notifications (?Adium > succesfully built by John?). No user on the system should sudo to > build an app for his own use. As noted above, using MacPorts as non-root needs improvement, but can already be done. > MaPoD Interface is the real glue between MaPoD/MacPorts and GUI. > Clients and MaPoD are completely loosly coupled because MaPod > Interface provides a neutral way for them to communicate. > > Third party MacPorts developers could develop plugins to extend core > functionalities (?Build Adium, notify me when you are done with a > Growl notification? or ?Build Adium, notify me when you are done with > an email to jdoe at apple.com?). What kind of plugins do you think of? Adding a general hook to the API "run-when-ready" would be enough, I think. > Conclusions > With the appropriate choices any user on the same system, even limited > ones, would see a full-featured MacPorts ?distribution?; any user will > have the possibility to search, install (from source or normal > binary), remove his application with no touch to MacPorts at all. > System administrator would also benefit from a fine grained permission > system (?Do not let Mike build Adium? or ?John can build and install > only between 3pm and 9pm?). MacPorts installation would be ?piloted? > by MaPoD itself, so there will be no need to sudo-run it for > occasional users. It?s clean, it?s ?secure? (you know, Santa believes > in security...:)). Add cronjobs, set permissions using chmod... No need to engineer a full new system? Why would anyone prohibit to install a specific port? Users can always build them outside MacPorts or install a binary. Also see the comment above about multi-user installations. As noted, non-root is possible. > Whis this architecture possibilities are endless: how long would be > needed to develop a plugin to mirror the tree among multiple nodes? > How long to develop a web client and an adapter to manage the same > build on multiple nodes? Mirror the tree? Run rsync and done? I don't get the point here. I already commented on a web interface above. If you want to build software for use on multiple nodes, compile it on one and create archives from it (already possible with MacPorts) and distribute it in your preferred way. Or provide archives to be installed on the clients. > Obviuosly MacPorts core should never be used by users/clients, > preferring MaPoD way to accomplish tasks. A user should never call the API manually also, what's the point? Users use clients like port on the command line or a GUI. I don't see any advantage from compiling in the background with a daemon. A GUI could provide queued builds which fits your request for "giving control back immediately." So, after all I don't see any real improvements for MacPorts from your proposal to add another layer. To achieve most parts of your proposal, install MacPorts system-wide and let the systems administrator compile software every user needs. Now every user itself can decide to also install MacPorts on his/her own in his/her home directory and install software there. No need to engineer new stuff. I don't think this needs to be synchronized, as I doubt anybody will install software at the same time as the system administrator does. Th whole point of installing software yourself is that you need another version or some other variants. And this synchronization is the only point which can't be achieved here. But is it really needed? My opinion is, what MacPorts would really need is a good API to be used by clients. The command line client should use the same API as any GUI client would use. This would need separation of interface and logic. And I see your request was merely a good GUI client which provides queuing, growl notifications and all the functionality MacPorts command line interface does. No need for a daemon to achieve this. Rainer From marcuscalhounlopez at mac.com Sun Mar 23 16:11:56 2008 From: marcuscalhounlopez at mac.com (Marcus Calhoun-Lopez) Date: Sun, 23 Mar 2008 16:11:56 -0700 Subject: destroot and (build && destroot) yield different results Message-ID: A few days ago, I submitted a ticket outlining situations in which it takes two runs of the port command for correct installation (http://trac.macosforge.org/projects/macports/ticket/14687 ). Is this a known behavior? I have attempted to track down the problem myself, but it has been slow going as I am not well versed in either Tcl or the MacPorts code base. Can anyone offer suggestions as to which parts of the MacPorts code to look at to determine why "port destroot" and "port build && port destroot" might have different results? Thank you, Marcus From raimue at macports.org Sun Mar 23 16:29:21 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 24 Mar 2008 00:29:21 +0100 Subject: destroot and (build && destroot) yield different results In-Reply-To: References: Message-ID: <47E6E7D1.2040203@macports.org> Marcus Calhoun-Lopez wrote: > A few days ago, I submitted a ticket outlining situations in which it > takes two runs of the port command for correct installation (http://trac.macosforge.org/projects/macports/ticket/14687 > ). > > Is this a known behavior? Don't think so... > I have attempted to track down the problem myself, but it has been > slow going as I am not well versed in either Tcl or the MacPorts code > base. Could you try to provide a minimal test Portfile which can be used to track this down? I don't want to test with mzscheme or boost. For example something like this should do (untested): build.env FOO='bar' destroot.env FOO='qux' build { system {echo "build: $FOO"} } destroot { system {echo "destroot: $FOO"} } > Can anyone offer suggestions as to which parts of the MacPorts code to > look at to determine why "port destroot" and "port build && port > destroot" might have different results? Seems to be some problem with exporting build.env? Rainer From jkh at apple.com Sun Mar 23 18:36:46 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Sun, 23 Mar 2008 18:36:46 -0700 Subject: Architectural proposal In-Reply-To: <69B792C1-BC15-4967-AFBE-DDCF99445171@mac.com> References: <3598B813-141E-4AEA-8B01-F4B1F1E9A454@mac.com> <41FA56A6-2EC5-468A-8D9E-1249E755E801@apple.com> <69B792C1-BC15-4967-AFBE-DDCF99445171@mac.com> Message-ID: On Mar 23, 2008, at 11:34 AM, Michelangelo De Simone wrote: > Thanks for your answer Jordan, hearing your opinion is very > important to me. You are right, a classical Cocoa app would solve > some of the basic tasks I mentioned, if all that we want is having > MacPorts being used by one (experienced) user:); but this would lead > to some major challenge once someone will want to setup another > client, perhaps a web-based one or a Java-based one (it's just an > example:)): he shall write from scratch the entire lower layers of > his app to make it work the way he wants, dealing with permissions > as well (Task 7). No word about cuncurrent MacPorts running on the > same system or the fact that a solution of this kind would be future- > proof, in case MacPorts evolved. > Generally speaking Task 5 ("GUI") would be easily addressed with an > upper layer to manage MacPorts Core. OK, so, let's take your points on order: 1. A Cocoa app would actually be aimed at the inexperienced user, not the experienced one, so I'm not sure I see your point. It's also an unquestionable fact that 99.9% of all Macs are single user (even on an XServe sitting in a rack somewhere, it's a single admin configuring it to provide services to multiple people) so there's no need to add per- user ACLs or have per-user interfaces. 2. Your raise the issue of multiple types of clients (Cocoa, web, etc) and that's a fair one, particularly if the ports collection on a given machine is going to need to be administered both locally and remotely, but that's more of an argument for making the existing set of port(1) APIs more robust and/or complete than adding an additional layer. In other words, if we really want to support multiple interfaces (and writing a web interface is a very different challenge, with different constraints, than a Cocoa UI) then I think the right approach isn't to create a complex interpositioning layer with a daemon managing the collection, the right approach is to provide the right port APIs for making the creation of such alternative UIs easier and more straight- forward. I also say this because the existing Tcl / C APIs for MacPorts were designed with this kind of thing very much in mind (the ui_foo APIs, for example, are implemented as abstractions for just this reason), though their evolution may not be (and probably is not) complete. The shortest distance between where we are and where you want to go would, therefore, seem to be to enhance what we have rather than create another layer. Again, MacPorts is already architected with embedding / external management in mind, so the question would be more one of "how can I make it do what I want" vs "how can I create another management layer." I see Rainer has already said many of the same things, so I'm clearly not alone. :-) > Anyway thank you and don't be concerned, I really appreciate direct > approaches.:) I'm glad to hear that since those are the kind I like best. :-) I also really don't want you to read all this as "they don't like my ideas!" or "clearly they do not see how another indirection layer could be useful", since I think we DO like your ideas and, with our academic researcher hats on, can always see the potential application for another abstraction layer (dozens of such layers can, in fact, be easily imagined if you put your mind to it). What we're trying to say is that it's also sometimes very important to focus purely on the goal and see how it can be done with the least amount of time and effort, then pick an approach which is somewhere in between "most flexible" and "quickest" if you want to successfully create software that people actually use. I think your first approach is too oriented towards flexibility and not enough towards the pragmatic and more quickly achievable. - Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080323/ce864e31/attachment.html From reiffert at macports.org Sun Mar 23 19:05:41 2008 From: reiffert at macports.org (Thomas Reifferscheid) Date: Mon, 24 Mar 2008 03:05:41 +0100 Subject: [35275] trunk/dports In-Reply-To: <20080323155447.69E8314D3B90@beta.macosforge.org> References: <20080323155447.69E8314D3B90@beta.macosforge.org> Message-ID: <47E70C75.50308@macports.org> Dear James, I dont feel well with your changes. It will make life even harder for submitters to the ticket database choosing the right maintainer. Regarding "automated ticket assignment to maintainers" your changes will make it harder for trac itself. How to solve this, have a port <=> maintainer map at a secret hidden place? Kind regards Thomas jberry at macports.org wrote: > > Revision > 35275 > Author > jberry at macports.org > Date > 2008-03-23 08:54:42 -0700 (Sun, 23 Mar 2008) > > > Log Message > > obfuscate my maintainer email addresses From ram at macports.org Sun Mar 23 20:58:58 2008 From: ram at macports.org (Adam Mercer) Date: Sun, 23 Mar 2008 23:58:58 -0400 Subject: [35275] trunk/dports In-Reply-To: <47E70C75.50308@macports.org> References: <20080323155447.69E8314D3B90@beta.macosforge.org> <47E70C75.50308@macports.org> Message-ID: <799406d60803232058j319327aew703be2c0b055cef5@mail.gmail.com> On Sun, Mar 23, 2008 at 10:05 PM, Thomas Reifferscheid wrote: > Dear James, I dont feel well with your changes. It will make life even > harder for submitters to the ticket database choosing the right maintainer. Why? MacPorts understands this obfuscation, it will expand to the appropriate address. For example, running 'port info' for these ports will return the correct email address: 'user' will be expanded to user at macports.org and 'example.com:user' will be expanded to user at example.com I use this on all my ports, along with many other maintainers. Cheers Adam From raimue at macports.org Mon Mar 24 02:41:59 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Mon, 24 Mar 2008 10:41:59 +0100 Subject: [35256] trunk/base/src/port1.0/portdistfiles.tcl In-Reply-To: <20080322221819.D8F8014D14A2@beta.macosforge.org> References: <20080322221819.D8F8014D14A2@beta.macosforge.org> Message-ID: <47E77767.8040902@macports.org> wsiegrist at apple.com wrote: > Revision: 35256 > http://trac.macosforge.org/projects/macports/changeset/35256 > Author: wsiegrist at apple.com > Date: 2008-03-22 15:18:17 -0700 (Sat, 22 Mar 2008) > > Log Message: > ----------- > added checksum display and an early exit when master_sites is not provided > > Modified Paths: > -------------- > trunk/base/src/port1.0/portdistfiles.tcl Just that you are aware of it, there is already a `port mirror` target which may do the same or similar things. Maybe it could just be extended? I want to note this to avoid code duplication or something like this... Also, I think you forgot to add 'distfiles' to the action_array in port/port.tcl. Otherwise it will not be usable with `port distfiles`. Rainer PS: Sorry for sending this twice, Bill. I used an not subscribed email address... From jberry at macports.org Mon Mar 24 07:05:24 2008 From: jberry at macports.org (James Berry) Date: Mon, 24 Mar 2008 07:05:24 -0700 Subject: [35275] trunk/dports In-Reply-To: <799406d60803232058j319327aew703be2c0b055cef5@mail.gmail.com> References: <20080323155447.69E8314D3B90@beta.macosforge.org> <47E70C75.50308@macports.org> <799406d60803232058j319327aew703be2c0b055cef5@mail.gmail.com> Message-ID: <72EDB79C-00D6-43B2-8484-82DA297571EB@macports.org> Hi Thomas, On Mar 23, 2008, at 8:58 PM, Adam Mercer wrote: > On Sun, Mar 23, 2008 at 10:05 PM, Thomas Reifferscheid > wrote: >> Dear James, I dont feel well with your changes. It will make life >> even >> harder for submitters to the ticket database choosing the right >> maintainer. > > Why? MacPorts understands this obfuscation, it will expand to the > appropriate address. For example, running 'port info' for these ports > will return the correct email address: 'user' will be expanded to > user at macports.org and 'example.com:user' will be expanded to > user at example.com > > I use this on all my ports, along with many other maintainers. Yes, as Adam says, this is our standard and supported behavior, and is used for many ports. I'm not sure it's documented anywhere however, but Adam's explanation is correct; we support two forms of obfuscation, a specific one for the macports.org case, and a more general variety for any email address. The rationale is to cut down on the possibility of spam to committers, though this is only one leak of email addresses, and there are others that remain unfixed (bug reports, irc logs, etc). Implemented by the following code in port.tcl: proc unobscure_maintainers { list } { set result {} foreach m $list { if {[string first "@" $m] < 0} { if {[string first ":" $m] >= 0} { set m [regsub -- "(.*):(.*)" $m "\\2@\\1"] } else { set m "$m at macports.org" } } lappend result $m } return $result } James -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2740 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080324/d75e5aee/attachment.bin From jberry at macports.org Mon Mar 24 07:36:29 2008 From: jberry at macports.org (James Berry) Date: Mon, 24 Mar 2008 07:36:29 -0700 Subject: [35275] trunk/dports In-Reply-To: <799406d60803232058j319327aew703be2c0b055cef5@mail.gmail.com> References: <20080323155447.69E8314D3B90@beta.macosforge.org> <47E70C75.50308@macports.org> <799406d60803232058j319327aew703be2c0b055cef5@mail.gmail.com> Message-ID: <96E09FF0-1848-4DFE-BC50-61D32C0A1DA1@macports.org> Hi Thomas, On Mar 23, 2008, at 8:58 PM, Adam Mercer wrote: > On Sun, Mar 23, 2008 at 10:05 PM, Thomas Reifferscheid > wrote: >> Dear James, I dont feel well with your changes. It will make life >> even >> harder for submitters to the ticket database choosing the right >> maintainer. > > Why? MacPorts understands this obfuscation, it will expand to the > appropriate address. For example, running 'port info' for these ports > will return the correct email address: 'user' will be expanded to > user at macports.org and 'example.com:user' will be expanded to > user at example.com > > I use this on all my ports, along with many other maintainers. Yes, as Adam says, this is our standard and supported behavior, and is used for many ports. I'm not sure it's documented anywhere however, but Adam's explanation is correct; we support two forms of obfuscation, a specific one for the macports.org case, and a more general variety for any email address. The rationale is to cut down on the possibility of spam to committers, though this is only one leak of email addresses, and there are others that remain unfixed (bug reports, irc logs, etc). Implemented by the following code in port.tcl: proc unobscure_maintainers { list } { set result {} foreach m $list { if {[string first "@" $m] < 0} { if {[string first ":" $m] >= 0} { set m [regsub -- "(.*):(.*)" $m "\\2@\\1"] } else { set m "$m at macports.org" } } lappend result $m } return $result } James -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2740 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080324/a39b67db/attachment-0001.bin From wsiegrist at apple.com Mon Mar 24 09:52:18 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 24 Mar 2008 09:52:18 -0700 Subject: [35256] trunk/base/src/port1.0/portdistfiles.tcl In-Reply-To: <47E77767.8040902@macports.org> References: <20080322221819.D8F8014D14A2@beta.macosforge.org> <47E77767.8040902@macports.org> Message-ID: I already committed the changes to port.tcl, port.1, and the Makefile earlier. The point of the command is to let a post-commit script parse it when a Portfile is committed. The mirror target does mostly what I want, but I did want to avoid fetching all of these files into the server's $prefix. I could go move the files after the mirror stage of course, but I wanted some separation and a little more control over the fetching. (Like not fetching a file we already have). I dont remember anyone mentioning the mirror target either when we discussed distfile mirroring, so I did overlook this. Maybe I will just extend mirror with some options for alternate destinations and such. I'll have to see how easy that will be. The other benefit I thought distfiles would add is portfile devs could get a list of files/urls that fetch would use. Thats probably not terribly useful, but its something that didnt exist before? Thanks for catching my oversight though. -Bill On Mar 24, 2008, at 2:41 AM, Rainer M?ller wrote: > wsiegrist at apple.com wrote: >> Revision: 35256 >> http://trac.macosforge.org/projects/macports/changeset/35256 >> Author: wsiegrist at apple.com >> Date: 2008-03-22 15:18:17 -0700 (Sat, 22 Mar 2008) >> Log Message: >> ----------- >> added checksum display and an early exit when master_sites is not >> provided >> Modified Paths: >> -------------- >> trunk/base/src/port1.0/portdistfiles.tcl > > Just that you are aware of it, there is already a `port mirror` target > which may do the same or similar things. Maybe it could just be > extended? I want to note this to avoid code duplication or something > like this... > > Also, I think you forgot to add 'distfiles' to the action_array in > port/port.tcl. Otherwise it will not be usable with `port distfiles`. > > Rainer > > PS: Sorry for sending this twice, Bill. I used an not subscribed > email address... ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080324/4557fae4/attachment.bin From marc at let.de Mon Mar 24 13:30:39 2008 From: marc at let.de (Marc Manthey) Date: Mon, 24 Mar 2008 21:30:39 +0100 Subject: how to change makefile for osx ppc Message-ID: <1E91EBB7-9940-4942-A7DF-F8573AC284E9@let.de> hello experts, sorry for crossposting , while i got no reply on xcode and several others told me to ask here. I like to test 2 programms , one is a multicast daemon , the other a toolset , on my macintosh osx ppc leopard machine. i try to compile the avalable sources with "make" which gave me the following errors mini:ecmh-2005.02.09 mini$ make dist if [ -f configure-stamp ]; then debian/rules clean; fi; rm -f mtrace6.o mtrace6 cd ..; tar -zclof ecmh_2005.02.09.tar.gz ecmh-2005.02.09 tar: Semantics of -l option will change in the future releases. tar: Please use --one-file-system option instead. cd ..; tar -jclof ecmh_2005.02.09.tar.bz2 ecmh-2005.02.09 tar: Semantics of -l option will change in the future releases. tar: Please use --one-file-system option instead. # Copy the changelog debian/rules binary dh_testdir make[1]: dh_testdir: Command not found make[1]: *** [configure-stamp] Error 127 make: *** [deb] Error 2 thats the "makefile" cd into the main folder autoconf ./configure --prefic=/usr/local Sorry that should have been: ./configure --prefix=/usr/local make this does not work too thanks for any hints and pointers Marc -- "You see, all the problems in the world are created by those who want 'perfection.' " Sri Sri Ravi Shankar Les Enfants terribes - research and deployment jabber :mini at stattfernsehen.com blog: http://www.let.de ipv6 http://www.stattfernsehen.com/matrix -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080324/7cc8c35d/attachment.html From raimue at macports.org Mon Mar 24 13:56:06 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 24 Mar 2008 21:56:06 +0100 Subject: [35256] trunk/base/src/port1.0/portdistfiles.tcl: In-Reply-To: References: <20080322221819.D8F8014D14A2@beta.macosforge.org> <47E77767.8040902@macports.org> Message-ID: <47E81566.7010209@macports.org> William Siegrist wrote: > I already committed the changes to port.tcl, port.1, and the Makefile > earlier. Hm, okay, must have overlooked this. I just build from trunk today and tried `port distfiles` and it didn't work. > The point of the command is to let a post-commit script parse it when a > Portfile is committed. The mirror target does mostly what I want, but I > did want to avoid fetching all of these files into the server's $prefix. > I could go move the files after the mirror stage of course, but I wanted > some separation and a little more control over the fetching. (Like not > fetching a file we already have). I dont remember anyone mentioning the > mirror target either when we discussed distfile mirroring, so I did > overlook this. Maybe I will just extend mirror with some options for > alternate destinations and such. I'll have to see how easy that will be. I didn't know about `port mirror` before today either. Just discovered it as I looked at your changes So you are implementing this with an external script? I thought publishing the /opt/local/var/macports/distfiles directory over HTTP would be enough. `port fetch` does also only fetch non-existing files. Maybe install a non-root installation of MacPorts just for fetching? > The other benefit I thought distfiles would add is portfile devs could > get a list of files/urls that fetch would use. Thats probably not > terribly useful, but its something that didnt exist before? Something like `port fetch --pretend`? :-) Rainer From marcuscalhounlopez at mac.com Mon Mar 24 14:28:53 2008 From: marcuscalhounlopez at mac.com (Marcus Calhoun-Lopez) Date: Mon, 24 Mar 2008 14:28:53 -0700 Subject: destroot and (build && destroot) yield different results In-Reply-To: <47E6E7D1.2040203@macports.org> References: <47E6E7D1.2040203@macports.org> Message-ID: Rainer M?ller wrote: > Could you try to provide a minimal test Portfile which can be used > to track this down? I don't want to test with mzscheme or boost. It is difficult to construct a small Portfile for this problem. MacPorts runs make, and make calls another program (jam for boost and a variant of mzscheme for mzscheme). It is in these secondary programs that the problem occurs. At the point of error in the boost code, the author has included the comment "# VP: I have no idea now 'native' can be empty here! But it can!" This is not an encouraging comment, but I shall continue to try to track down the problem. -Marcus From reiffert at macports.org Mon Mar 24 15:28:28 2008 From: reiffert at macports.org (Thomas Reifferscheid) Date: Mon, 24 Mar 2008 23:28:28 +0100 Subject: [35275] trunk/dports In-Reply-To: <96E09FF0-1848-4DFE-BC50-61D32C0A1DA1@macports.org> References: <20080323155447.69E8314D3B90@beta.macosforge.org> <47E70C75.50308@macports.org> <799406d60803232058j319327aew703be2c0b055cef5@mail.gmail.com> <96E09FF0-1848-4DFE-BC50-61D32C0A1DA1@macports.org> Message-ID: <47E82B0C.2030900@macports.org> Dear Adam and James, thx for making that clear. Wasn't aware of. Kind regards Thomas James Berry wrote: [...] > Implemented by the following code in port.tcl: [...] From ryandesign at macports.org Mon Mar 24 15:49:55 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 24 Mar 2008 17:49:55 -0500 Subject: [35275] trunk/dports In-Reply-To: <72EDB79C-00D6-43B2-8484-82DA297571EB@macports.org> References: <20080323155447.69E8314D3B90@beta.macosforge.org> <47E70C75.50308@macports.org> <799406d60803232058j319327aew703be2c0b055cef5@mail.gmail.com> <72EDB79C-00D6-43B2-8484-82DA297571EB@macports.org> Message-ID: <30712857-1EBA-4538-9492-3CD5A990D1D2@macports.org> On Mar 24, 2008, at 09:05, James Berry wrote: > Yes, as Adam says, this is our standard and supported behavior, and > is used for many ports. I'm not sure it's documented anywhere > however, but Adam's explanation is correct; we support two forms of > obfuscation, a specific one for the macports.org case, and a more > general variety for any email address. The rationale is to cut down > on the possibility of spam to committers, though this is only one > leak of email addresses, and there are others that remain unfixed > (bug reports, irc logs, etc). The $Id$ tag at the top of every portfile. :( From wsiegrist at apple.com Mon Mar 24 16:03:12 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 24 Mar 2008 16:03:12 -0700 Subject: [35256] trunk/base/src/port1.0/portdistfiles.tcl: In-Reply-To: <47E81566.7010209@macports.org> References: <20080322221819.D8F8014D14A2@beta.macosforge.org> <47E77767.8040902@macports.org> <47E81566.7010209@macports.org> Message-ID: <27123F64-4EB0-4580-AAA3-5F87D7575C59@apple.com> On Mar 24, 2008, at 1:56 PM, Rainer M?ller wrote: > William Siegrist wrote: >> I already committed the changes to port.tcl, port.1, and the Makefile >> earlier. > > Hm, okay, must have overlooked this. I just build from trunk today and > tried `port distfiles` and it didn't work. > Oops. Missed my changes in src/port. Thanks >> The point of the command is to let a post-commit script parse it >> when a >> Portfile is committed. The mirror target does mostly what I want, >> but I >> did want to avoid fetching all of these files into the server's >> $prefix. >> I could go move the files after the mirror stage of course, but I >> wanted >> some separation and a little more control over the fetching. (Like >> not >> fetching a file we already have). I dont remember anyone mentioning >> the >> mirror target either when we discussed distfile mirroring, so I did >> overlook this. Maybe I will just extend mirror with some options for >> alternate destinations and such. I'll have to see how easy that >> will be. > > I didn't know about `port mirror` before today either. Just discovered > it as I looked at your changes > > So you are implementing this with an external script? I thought > publishing the /opt/local/var/macports/distfiles directory over HTTP > would be enough. `port fetch` does also only fetch non-existing files. > > Maybe install a non-root installation of MacPorts just for fetching? > Yes, I will have a Perl script done eventually similar to what I did with linting. The perl script will be committed of course, once its done. (I havnt even started it yet) I didnt want to just point apache at the server's macports install. In fact, this wont work at all currently due to our disk layout. But in any case, I dont think its a good idea mixing live server software with a service we're trying to provide. And installing yet another copy of MacPorts just to get a separate file tree seems like overkill... I know fetch/mirror would save me work, but it just didnt seem like it was easy to make it clean and separate. So I figured the distfiles command would add an extra debugging tool plus let me parse it server side however I wanted. >> The other benefit I thought distfiles would add is portfile devs >> could >> get a list of files/urls that fetch would use. Thats probably not >> terribly useful, but its something that didnt exist before? > > Something like `port fetch --pretend`? :-) distfiles prints out a list of URLs for each distfile plus the checksums. Doesnt seem like --pretend has the same output, though I guess with my botched commit you couldnt see that :) -Bill ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080324/0d15359e/attachment.bin From raimue at macports.org Mon Mar 24 17:00:50 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 25 Mar 2008 01:00:50 +0100 Subject: [35275] trunk/dports In-Reply-To: <30712857-1EBA-4538-9492-3CD5A990D1D2@macports.org> References: <20080323155447.69E8314D3B90@beta.macosforge.org> <47E70C75.50308@macports.org> <799406d60803232058j319327aew703be2c0b055cef5@mail.gmail.com> <72EDB79C-00D6-43B2-8484-82DA297571EB@macports.org> <30712857-1EBA-4538-9492-3CD5A990D1D2@macports.org> Message-ID: <47E840B2.4050102@macports.org> Ryan Schmidt wrote: > On Mar 24, 2008, at 09:05, James Berry wrote: > >> Yes, as Adam says, this is our standard and supported behavior, and >> is used for many ports. I'm not sure it's documented anywhere >> however, but Adam's explanation is correct; we support two forms of >> obfuscation, a specific one for the macports.org case, and a more >> general variety for any email address. The rationale is to cut down >> on the possibility of spam to committers, though this is only one >> leak of email addresses, and there are others that remain unfixed >> (bug reports, irc logs, etc). > > The $Id$ tag at the top of every portfile. :( Uh, you are so right. I never thought about that, but this really makes obfuscation rather useless for committers... Rainer From ryandesign at macports.org Mon Mar 24 18:45:02 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 24 Mar 2008 20:45:02 -0500 Subject: [35275] trunk/dports In-Reply-To: <47E840B2.4050102@macports.org> References: <20080323155447.69E8314D3B90@beta.macosforge.org> <47E70C75.50308@macports.org> <799406d60803232058j319327aew703be2c0b055cef5@mail.gmail.com> <72EDB79C-00D6-43B2-8484-82DA297571EB@macports.org> <30712857-1EBA-4538-9492-3CD5A990D1D2@macports.org> <47E840B2.4050102@macports.org> Message-ID: <35EAE1BA-F42F-4817-8091-C92129702E6D@macports.org> On Mar 24, 2008, at 19:00, Rainer M?ller wrote: > Ryan Schmidt wrote: > >> On Mar 24, 2008, at 09:05, James Berry wrote: >> >>> Yes, as Adam says, this is our standard and supported behavior, and >>> is used for many ports. I'm not sure it's documented anywhere >>> however, but Adam's explanation is correct; we support two forms of >>> obfuscation, a specific one for the macports.org case, and a more >>> general variety for any email address. The rationale is to cut down >>> on the possibility of spam to committers, though this is only one >>> leak of email addresses, and there are others that remain unfixed >>> (bug reports, irc logs, etc). >> >> The $Id$ tag at the top of every portfile. :( > > Uh, you are so right. I never thought about that, but this really > makes > obfuscation rather useless for committers... Well, we had to start somewhere. We started with the maintainer line in the portfiles. Next, we need a solution for obfuscating the $Id$ line and trac tickets (use obfuscated Trac/svn logins?) From ryandesign at macports.org Mon Mar 24 20:22:01 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 24 Mar 2008 22:22:01 -0500 Subject: how to change makefile for osx ppc In-Reply-To: <1E91EBB7-9940-4942-A7DF-F8573AC284E9@let.de> References: <1E91EBB7-9940-4942-A7DF-F8573AC284E9@let.de> Message-ID: On Mar 24, 2008, at 15:30, Marc Manthey wrote: > sorry for crossposting , while i got no reply on xcode and several > others told me to ask here. > > I like to test 2 programms , one is a multicast daemon , the > other a toolset , > on my macintosh osx ppc leopard machine. projects/ecmh/> > > i try to compile the avalable sources with "make" > > which gave me the following errors > > mini:ecmh-2005.02.09 mini$ make dist > if [ -f configure-stamp ]; then debian/rules clean; fi; > rm -f mtrace6.o mtrace6 > cd ..; tar -zclof ecmh_2005.02.09.tar.gz ecmh-2005.02.09 > tar: Semantics of -l option will change in the future releases. > tar: Please use --one-file-system option instead. > cd ..; tar -jclof ecmh_2005.02.09.tar.bz2 ecmh-2005.02.09 > tar: Semantics of -l option will change in the future releases. > tar: Please use --one-file-system option instead. > # Copy the changelog > debian/rules binary > dh_testdir > make[1]: dh_testdir: Command not found > make[1]: *** [configure-stamp] Error 127 > make: *** [deb] Error 2 > > thats the "makefile" > > > > cd into the main folder > autoconf > ./configure --prefic=/usr/local > > Sorry that should have been: > ./configure --prefix=/usr/local > > make > > this does not work too > > thanks for any hints and pointers This isn't really on-topic for this list. This list is for discussing the development of MacPorts base or portfiles. For help compiling a given program in the first place, ask the developers of that software. Also, your pastebin posting doesn't seem to exist; it says "Unknown post id, it may have expired or been deleted" From landonf at macports.org Tue Mar 25 11:21:19 2008 From: landonf at macports.org (Landon Fuller) Date: Tue, 25 Mar 2008 11:21:19 -0700 Subject: Fwd: [35353] tinyca2 Lint Report References: <20080325181453.7D8F628050@relay13.apple.com> Message-ID: <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> I'd like to formally request that these new style guideline be removed from port lint -- there's nothing wrong with the port. This kind of style pedantry wastes everyone's time. It doesn't matter. The last thing I need is an e-mail about it. I didn't place newline between the $Id: $ tag and the PortSystem line: # $Id: Portfile 35353 2008-03-25 18:13:44Z landonf at macports.org $ PortSystem 1.0 I named my patch file 'patch-tinyca2'. -landonf Begin forwarded message: > From: noreply at macports.org > Date: March 25, 2008 11:13:49 AM PDT > To: landonf at macports.org > Subject: [35353] tinyca2 Lint Report > > Portfile: tinyca2 > > > Warning: Line 2 should be a newline (after RCS tag) > Warning: Patchfile patch-tinyca2 does not follow the source patch > naming policy "patch-*.diff" > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080325/661456f4/attachment.html From blair at orcaware.com Tue Mar 25 11:25:44 2008 From: blair at orcaware.com (Blair Zajac) Date: Tue, 25 Mar 2008 11:25:44 -0700 Subject: Fwd: [35353] tinyca2 Lint Report In-Reply-To: <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> Message-ID: <47E943A8.8090307@orcaware.com> How long does it take to fix it? One minute. It took longer to write this email then to commit those changes :) Blair Landon Fuller wrote: > I'd like to formally request that these new style guideline be removed > from port lint -- there's nothing wrong with the port. > This kind of style pedantry wastes everyone's time. It doesn't matter. > The last thing I need is an e-mail about it. > > I didn't place newline between the $Id: $ tag and the PortSystem line: > > # $Id: Portfile 35353 2008-03-25 18:13:44Z landonf at macports.org > $ > PortSystem 1.0 > > I named my patch file 'patch-tinyca2'. > > -landonf > > Begin forwarded message: > >> *From: *noreply at macports.org >> *Date: *March 25, 2008 11:13:49 AM PDT >> *To: *landonf at macports.org >> *Subject: **[35353] tinyca2 Lint Report* >> >> Portfile: tinyca2 >> >> >> Warning: Line 2 should be a newline (after RCS tag) >> Warning: Patchfile patch-tinyca2 does not follow the source patch >> naming policy "patch-*.diff" From landonf at macports.org Tue Mar 25 11:27:08 2008 From: landonf at macports.org (Landon Fuller) Date: Tue, 25 Mar 2008 11:27:08 -0700 Subject: [35353] tinyca2 Lint Report In-Reply-To: <47E943A8.8090307@orcaware.com> References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> Message-ID: <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote: > How long does it take to fix it? One minute. It's not broken. It's just like a spell checker that gets annoyed when you type "colour" instead of "color". -landonf From blair at orcaware.com Tue Mar 25 11:31:40 2008 From: blair at orcaware.com (Blair Zajac) Date: Tue, 25 Mar 2008 11:31:40 -0700 Subject: [35353] tinyca2 Lint Report In-Reply-To: <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> Message-ID: <47E9450C.4020907@orcaware.com> Landon Fuller wrote: > > On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote: > >> How long does it take to fix it? One minute. > > It's not broken. It's just like a spell checker that gets annoyed when > you type "colour" instead of "color". Teams have style guides for everything, such as no space before a ( for the Subversion source code, everybody plays along with it. Just go along with it. I found a bunch of stuff in my port files and cleaned it up. I don't have an issue with it. There's more important stuff to discuss about. Blair From landonf at macports.org Tue Mar 25 11:35:19 2008 From: landonf at macports.org (Landon Fuller) Date: Tue, 25 Mar 2008 11:35:19 -0700 Subject: [35353] tinyca2 Lint Report In-Reply-To: <47E9450C.4020907@orcaware.com> References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> Message-ID: <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> On Mar 25, 2008, at 11:31 AM, Blair Zajac wrote: > Landon Fuller wrote: >> On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote: >>> How long does it take to fix it? One minute. >> It's not broken. It's just like a spell checker that gets annoyed >> when you type "colour" instead of "color". > > Teams have style guides for everything, such as no space before a > ( for the Subversion source code, everybody plays along with it. The original style guidelines only tried to enforce things that mattered. > Just go along with it. I found a bunch of stuff in my port files > and cleaned it up. I don't have an issue with it. There's more > important stuff to discuss about. So why do we have a machine auto-emailing humans about stuff that doesn't matter that much? -landonf From blair at orcaware.com Tue Mar 25 11:40:26 2008 From: blair at orcaware.com (Blair Zajac) Date: Tue, 25 Mar 2008 11:40:26 -0700 Subject: [35353] tinyca2 Lint Report In-Reply-To: <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> Message-ID: <47E9471A.6070304@orcaware.com> Landon Fuller wrote: > > On Mar 25, 2008, at 11:31 AM, Blair Zajac wrote: > >> Landon Fuller wrote: >>> On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote: >>>> How long does it take to fix it? One minute. >>> It's not broken. It's just like a spell checker that gets annoyed >>> when you type "colour" instead of "color". >> >> Teams have style guides for everything, such as no space before a ( >> for the Subversion source code, everybody plays along with it. > > The original style guidelines only tried to enforce things that mattered. > >> Just go along with it. I found a bunch of stuff in my port files and >> cleaned it up. I don't have an issue with it. There's more important >> stuff to discuss about. > > So why do we have a machine auto-emailing humans about stuff that > doesn't matter that much? I'm guessing by the few emails I've seen taking issue with the style emails that most people don't mind and that that the people that wrote the tool felt that style does matter. I'm in that camp. I like seeing all the ports having the same style. Blair From landonf at macports.org Tue Mar 25 11:45:12 2008 From: landonf at macports.org (Landon Fuller) Date: Tue, 25 Mar 2008 11:45:12 -0700 Subject: [35353] tinyca2 Lint Report In-Reply-To: <47E9471A.6070304@orcaware.com> References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> Message-ID: On Mar 25, 2008, at 11:40 AM, Blair Zajac wrote: > Landon Fuller wrote: >> On Mar 25, 2008, at 11:31 AM, Blair Zajac wrote: >>> Landon Fuller wrote: >>>> On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote: >>>>> How long does it take to fix it? One minute. >>>> It's not broken. It's just like a spell checker that gets annoyed >>>> when you type "colour" instead of "color". >>> >>> Teams have style guides for everything, such as no space before a >>> ( for the Subversion source code, everybody plays along with it. >> The original style guidelines only tried to enforce things that >> mattered. >>> Just go along with it. I found a bunch of stuff in my port files >>> and cleaned it up. I don't have an issue with it. There's more >>> important stuff to discuss about. >> So why do we have a machine auto-emailing humans about stuff that >> doesn't matter that much? > > I'm guessing by the few emails I've seen taking issue with the style > emails that most people don't mind and that that the people that > wrote the tool felt that style does matter. > > I'm in that camp. I like seeing all the ports having the same style. OK. If that's the prevailing opinion I'll just /dev/null the lint warnings, hopefully not miss anything truly important, and get on with work. -landonf From opendarwin.org at darkart.com Tue Mar 25 11:52:06 2008 From: opendarwin.org at darkart.com (Eric Hall) Date: Tue, 25 Mar 2008 18:52:06 +0000 Subject: [35353] tinyca2 Lint Report In-Reply-To: References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> Message-ID: <20080325185205.GR42614@darkart.com> On Tue, Mar 25, 2008 at 11:45:12AM -0700, Landon Fuller wrote: > > On Mar 25, 2008, at 11:40 AM, Blair Zajac wrote: > > > Landon Fuller wrote: > >> On Mar 25, 2008, at 11:31 AM, Blair Zajac wrote: > >>> Landon Fuller wrote: > >>>> On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote: > >>>>> How long does it take to fix it? One minute. > >>>> It's not broken. It's just like a spell checker that gets annoyed > >>>> when you type "colour" instead of "color". > >>> > >>> Teams have style guides for everything, such as no space before a > >>> ( for the Subversion source code, everybody plays along with it. > >> The original style guidelines only tried to enforce things that > >> mattered. > >>> Just go along with it. I found a bunch of stuff in my port files > >>> and cleaned it up. I don't have an issue with it. There's more > >>> important stuff to discuss about. > >> So why do we have a machine auto-emailing humans about stuff that > >> doesn't matter that much? > > > > I'm guessing by the few emails I've seen taking issue with the style > > emails that most people don't mind and that that the people that > > wrote the tool felt that style does matter. > > > > I'm in that camp. I like seeing all the ports having the same style. > > OK. If that's the prevailing opinion I'll just /dev/null the lint > warnings, hopefully not miss anything truly important, and get on with > work. > Is it? I don't like the 'port lint' stuff that complains about whitespace - its invisible to humans and to port (so far as I know), why do we bother people about it? I also don't like having patchfiles ending in '.diff', used to be they matched FreeBSD's style (IIRC, and that was a purposeful decision). If somebody has a hair about their editor "properly" displaying patches, why not teach the editor to match on 'patch-' for highlighting/? -eric From landonf at macports.org Tue Mar 25 12:00:36 2008 From: landonf at macports.org (Landon Fuller) Date: Tue, 25 Mar 2008 12:00:36 -0700 Subject: Erlang category? Message-ID: Any votes for/against creating an Erlang category, to match the Python/ Ruby/etc categories? First port I'd like to add is eunit 2.0 (erlang unit test library). -landonf From kvv at apple.com Tue Mar 25 12:18:56 2008 From: kvv at apple.com (Kevin Van Vechten) Date: Tue, 25 Mar 2008 12:18:56 -0700 Subject: Erlang category? In-Reply-To: References: Message-ID: Might as well have its own category. On Mar 25, 2008, at 12:00 PM, Landon Fuller wrote: > Any votes for/against creating an Erlang category, to match the > Python/ > Ruby/etc categories? First port I'd like to add is eunit 2.0 (erlang > unit test library). > > -landonf From opendarwin.org at darkart.com Tue Mar 25 13:24:12 2008 From: opendarwin.org at darkart.com (Eric Hall) Date: Tue, 25 Mar 2008 20:24:12 +0000 Subject: [35353] tinyca2 Lint Report In-Reply-To: <20080325185205.GR42614@darkart.com> References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> Message-ID: <20080325202412.GT42614@darkart.com> There's now a ticket with a patch to reduce 'port lint' pedantry: http://trac.macosforge.org/projects/macports/ticket/14799 -eric From florian.ebeling at gmail.com Tue Mar 25 13:36:07 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Tue, 25 Mar 2008 21:36:07 +0100 Subject: [35353] tinyca2 Lint Report In-Reply-To: <20080325185205.GR42614@darkart.com> References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> Message-ID: <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> > > > I'm guessing by the few emails I've seen taking issue with the style > > > emails that most people don't mind and that that the people that > > > wrote the tool felt that style does matter. > > > > > > I'm in that camp. I like seeing all the ports having the same style. > > > > OK. If that's the prevailing opinion I'll just /dev/null the lint > > warnings, hopefully not miss anything truly important, and get on with > > work. > > > > Is it? I don't like the 'port lint' stuff that complains about > whitespace - its invisible to humans and to port (so far as I know), why > do we bother people about it? I also don't like having patchfiles ending > in '.diff', used to be they matched FreeBSD's style (IIRC, and that was > a purposeful decision). If somebody has a hair about their editor "properly" > displaying patches, why not teach the editor to match on 'patch-' for > highlighting/? The pedantery of port lint is particularly embarassing for occasional maintainers like me who don't have commit bit. The thing is I can't really ask the list to "please delete the space at the and of line 14", as lint suggests and expect that people still take me serious. Effectively, I can't really do anything about this stream of little nagging notes, and that's not good. Florian -- Florian Ebeling florian.ebeling at gmail.com From ryandesign at macports.org Wed Mar 26 00:13:46 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 26 Mar 2008 02:13:46 -0500 Subject: [35353] tinyca2 Lint Report In-Reply-To: <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> Message-ID: <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> On Mar 25, 2008, at 15:36, Florian Ebeling wrote: >>>> I'm guessing by the few emails I've seen taking issue with the >>>> style >>>> emails that most people don't mind and that that the people that >>>> wrote the tool felt that style does matter. >>>> >>>> I'm in that camp. I like seeing all the ports having the same >>>> style. >>> >>> OK. If that's the prevailing opinion I'll just /dev/null the lint >>> warnings, hopefully not miss anything truly important, and get on >>> with >>> work. >>> >> >> Is it? I don't like the 'port lint' stuff that complains >> about >> whitespace - its invisible to humans and to port (so far as I >> know), why >> do we bother people about it? I also don't like having >> patchfiles ending >> in '.diff', used to be they matched FreeBSD's style (IIRC, and >> that was >> a purposeful decision). If somebody has a hair about their >> editor "properly" >> displaying patches, why not teach the editor to match on 'patch-' >> for >> highlighting/? > > The pedantery of port lint is particularly embarassing for > occasional maintainers like me who don't have commit bit. > The thing is I can't really ask the list to "please delete the > space at the > and of line 14", as lint suggests and expect that people still take > me serious. Effectively, I can't really do anything about this > stream of little nagging notes, and that's not good. Maintainers who don't have commit access: I would expect everyone who is a maintainer but not a committer to have a commit-buddy whom they email to commit such things for them. If you don't have one, it would be advantageous to find one. For example, who has committed the patches you supplied in your last tickets? Ask them. Patchfile naming: The old guide was contradictory, and in one place, recommended the naming scheme "patch-*" while in another place it recommended "patch-*.diff". The new guide is now consistent in recommending "patch-*.diff". As I have explained over and over on this list, I prefer this because my editor can then syntax-highlight diff files like diff files, instead of like whatever the underlying file type is, which would be an error, because, e.g., the difference of two C files IS NOT a C file; it is a difference file and should be treated as such. Mac OS X cannot assign applications based on file prefixes. It can only assign applications based on file extensions. Therefore diff files must have a unique extension, as should all other types of files. Trailing whitespace: trailing whitespace after a backslash causes an error (the line is not continued as expected). Such whitespace must not exist. I'm not sure if there are other trailing whitespace issues that were being caught by this check. If not, the check could be reduced to catching trailing whitespace following a backslash. From cbellot at sky.fr Wed Mar 26 01:49:38 2008 From: cbellot at sky.fr (Cyril Bellot) Date: Wed, 26 Mar 2008 09:49:38 +0100 Subject: NEW PORT: ipv6calc In-Reply-To: <47D55E22.5000809@sky.fr> References: <47D55E22.5000809@sky.fr> Message-ID: <47EA0E22.2040002@sky.fr> Cyril Bellot a ?crit : > Could someone have a look at this new port proposal : > http://trac.macosforge.org/projects/macports/ticket/14611 > Could someone have a look and commit please ? Regards From florian.ebeling at gmail.com Wed Mar 26 03:42:33 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Wed, 26 Mar 2008 11:42:33 +0100 Subject: [35353] tinyca2 Lint Report In-Reply-To: <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> References: <20080325181453.7D8F628050@relay13.apple.com> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> Message-ID: <5cbbe4ae0803260342o516ee4f8y35faab5fd31ee4b6@mail.gmail.com> > Trailing whitespace: trailing whitespace after a backslash causes an > error (the line is not continued as expected). Such whitespace must > not exist. I'm not sure if there are other trailing whitespace issues > that were being caught by this check. If not, the check could be > reduced to catching trailing whitespace following a backslash. Agreed, that's maybe a good idea. It seems to be hard to eliminate problems which lint warns about beforehand. To give you just one example, the last 2 commits on "my" port libsvm were done by you, and I got a lint warning each time, for an empty line containing a space. -- Florian Ebeling florian.ebeling at gmail.com From ryandesign at macports.org Wed Mar 26 04:33:42 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 26 Mar 2008 06:33:42 -0500 Subject: [35353] tinyca2 Lint Report In-Reply-To: <5cbbe4ae0803260342o516ee4f8y35faab5fd31ee4b6@mail.gmail.com> References: <20080325181453.7D8F628050@relay13.apple.com> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> <5cbbe4ae0803260342o516ee4f8y35faab5fd31ee4b6@mail.gmail.com> Message-ID: On Mar 26, 2008, at 05:42, Florian Ebeling wrote: >> Trailing whitespace: trailing whitespace after a backslash causes an >> error (the line is not continued as expected). Such whitespace must >> not exist. I'm not sure if there are other trailing whitespace >> issues >> that were being caught by this check. If not, the check could be >> reduced to catching trailing whitespace following a backslash. > > Agreed, that's maybe a good idea. It seems to be hard to eliminate > problems which lint warns about beforehand. To give you just one > example, the last 2 commits on "my" port libsvm were done by you, > and I got a lint warning each time, for an empty line containing a > space. Empty lines containing a space should not be reported as erroneous by port lint. port lint had a bug. It was fixed in trunk but that fix has not yet made it to a released version of MacPorts. http://trac.macosforge.org/projects/macports/ticket/14165 From florian.ebeling at gmail.com Wed Mar 26 04:48:09 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Wed, 26 Mar 2008 12:48:09 +0100 Subject: [35353] tinyca2 Lint Report In-Reply-To: References: <20080325181453.7D8F628050@relay13.apple.com> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> <5cbbe4ae0803260342o516ee4f8y35faab5fd31ee4b6@mail.gmail.com> Message-ID: <5cbbe4ae0803260448u6faa9987vcb0c83267b6c4a85@mail.gmail.com> > Empty lines containing a space should not be reported as erroneous by > port lint. port lint had a bug. It was fixed in trunk but that fix > has not yet made it to a released version of MacPorts. Ok, fair enough. Btw, is there a way to run port lint locally? It's not mentioned in the macports guide, IIRC. -- Florian Ebeling florian.ebeling at gmail.com From landonf at macports.org Wed Mar 26 08:53:11 2008 From: landonf at macports.org (Landon Fuller) Date: Wed, 26 Mar 2008 08:53:11 -0700 Subject: [35353] tinyca2 Lint Report In-Reply-To: <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> Message-ID: On Mar 26, 2008, at 12:13 AM, Ryan Schmidt wrote: > Patchfile naming: The old guide was contradictory, and in one place, > recommended the naming scheme "patch-*" while in another place it > recommended "patch-*.diff". The new guide is now consistent in > recommending "patch-*.diff". The original documentation (which I wrote) was originally consistent with the FreeBSD patch specification: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/slow-patch.html We then adopted the semantic of patch-foobar.diff, where 'foobar' was a feature that covered many files -- this was due to the headache of patch-per-file for a sizable set of diffs. I don't actually think it matters what name you use, as long as it makes sense. > As I have explained over and over on this list, I prefer this > because my > editor can then syntax-highlight > diff files like diff files, instead of like whatever the underlying > file type is, which would be an error, because, e.g., the difference > of two C files IS NOT a C file; it is a difference file and should be > treated as such. Mac OS X cannot assign applications based on file > prefixes. It can only assign applications based on file extensions. > Therefore diff files must have a unique extension, as should all > other types of files. I don't want to get e-mailed when I name a patch that makes *your* editor unhappy when you double-click a file. The e-mail should be saved for something that's actually an error. > Trailing whitespace: trailing whitespace after a backslash causes an > error (the line is not continued as expected). Such whitespace must > not exist. I'm not sure if there are other trailing whitespace issues > that were being caught by this check. If not, the check could be > reduced to catching trailing whitespace following a backslash. My original newline complaint was: Warning: Line 2 should be a newline (after RCS tag) # $Id: Portfile 35353 2008-03-25 18:13:44Z landonf at macports.org $ PortSystem 1.0 Why does that matter? These "your contribution is in error!" mails are soul draining. It makes one feel as if you've stumbled into the Department of Motor Vehicles and forgot registration form B.5. -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/20080326/71c39c03/attachment.bin From jberry at macports.org Wed Mar 26 09:03:09 2008 From: jberry at macports.org (James Berry) Date: Wed, 26 Mar 2008 09:03:09 -0700 Subject: [35353] tinyca2 Lint Report In-Reply-To: References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> Message-ID: On Mar 26, 2008, at 8:53 AM, Landon Fuller wrote: > Why does that matter? These "your contribution is in error!" mails > are soul draining. > It makes one feel as if you've stumbled into the Department of Motor > Vehicles and > forgot registration form B.5. I agree fully with Landon. The automated lint on submit should be limited, if even allowed, to severe errors that will cause the port to be unusable. We have enough of a hard time getting people to keep their ports up to date, without adding layers of unneeded complexity. I don't mind if somebody wants to be able to run a lint that shows tweaky and silly warnings, but that should be their choice, on their system. We should either: - Disable the automated link-on-submit - Or cause it to show severe errors only James -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2740 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080326/a3163afe/attachment-0001.bin From blair at orcaware.com Wed Mar 26 09:26:50 2008 From: blair at orcaware.com (Blair Zajac) Date: Wed, 26 Mar 2008 09:26:50 -0700 Subject: [35353] tinyca2 Lint Report In-Reply-To: <5cbbe4ae0803260448u6faa9987vcb0c83267b6c4a85@mail.gmail.com> References: <20080325181453.7D8F628050@relay13.apple.com> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> <5cbbe4ae0803260342o516ee4f8y35faab5fd31ee4b6@mail.gmail.com> <5cbbe4ae0803260448u6faa9987vcb0c83267b6c4a85@mail.gmail.com> Message-ID: <47EA794A.5070905@orcaware.com> Florian Ebeling wrote: >> Empty lines containing a space should not be reported as erroneous by >> port lint. port lint had a bug. It was fixed in trunk but that fix >> has not yet made it to a released version of MacPorts. > > Ok, fair enough. Btw, is there a way to run port lint locally? It's > not mentioned in the macports guide, IIRC. $ port lint PORT_NAME Blair -- Blair Zajac, Ph.D. http://www.orcaware.com/svn/ From afb at macports.org Wed Mar 26 09:28:55 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 26 Mar 2008 17:28:55 +0100 Subject: [35353] tinyca2 Lint Report In-Reply-To: References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> Message-ID: <27ACEBE0-37B1-4C27-9BC4-AE67687AB5EF@macports.org> Landon Fuller wrote: > On Mar 26, 2008, at 12:13 AM, Ryan Schmidt wrote: > >> Patchfile naming: The old guide was contradictory, and in one place, >> recommended the naming scheme "patch-*" while in another place it >> recommended "patch-*.diff". The new guide is now consistent in >> recommending "patch-*.diff". > > The original documentation (which I wrote) was originally > consistent with the FreeBSD > patch specification: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ > slow-patch.html > > We then adopted the semantic of patch-foobar.diff, where 'foobar' > was a feature that > covered many files -- this was due to the headache of patch-per- > file for a sizable set > of diffs. I agree with Landon here, the current lint warning seems misguided ? This was discussed at length before it was implemented too, with there being two different kinds of patches. But apparently "consistency" once again triumphed, and one of the types of patch naming was warned about. If anything, it should be eased up to allow anything like "patch-*"... We had "patch-foo.c" and "patch-bar.h", and also "patch-foobar.diff". i.e. either patch-FILENAME (BSD style) or patch-ISSUE.diff (multi-file) > My original newline complaint was: > Warning: Line 2 should be a newline (after RCS tag) > > # $Id: Portfile 35353 2008-03-25 18:13:44Z landonf at macports.org $ > PortSystem 1.0 > > Why does that matter? Actually the whitespace checks were originally supposed to be optional, but I didn't know how to make "port lint" read options in Tcl... :-) The inspiration for the issued warnings was portlint(1), naturally enough. http://www.freebsd.org/doc/en/books/porters-handbook/porting- portlint.html Stylistic newlines could be made optional, with an extra port parameter ? --anders From simon at ruderich.com Wed Mar 26 18:25:54 2008 From: simon at ruderich.com (Simon Ruderich) Date: Thu, 27 Mar 2008 02:25:54 +0100 Subject: NEW PORT: ipv6calc In-Reply-To: <47EA0E22.2040002@sky.fr> References: <47D55E22.5000809@sky.fr> <47EA0E22.2040002@sky.fr> Message-ID: <20080327012554.GA27771@ruderich.com> On Wed, Mar 26, 2008 at 09:49:38AM +0100, Cyril Bellot wrote: > Cyril Bellot a ?crit : > > Could someone have a look at this new port proposal : > > http://trac.macosforge.org/projects/macports/ticket/14611 > > > > Could someone have a look and commit please ? > > Regards Hi, Sorry for the late reply. I added your port to macports with the following changes [1]: + Added required $Id$ comment to the beginning of the Portfile. + Obfuscated your email so you don't get any spam (hopefully). + Removed unnecessary distfiles setting, it's automatically set to $name-$version.tar.gz (see also [2]). + Removed build.type as it defaults to gnu [3]. + Added post-destroot phase so man pages get correctly installed into ${prefix}/share/man. If you don't like any of my changes just tell me and I will revert them. Your port will be available to other users via "port sync" or "port selfupdate" in the next 24 hours. Thanks for your help, Simon [1]: http://trac.macosforge.org/projects/macports/changeset/35379 [2]: http://guide.macports.org/#reference.phases.fetch [3]: http://guide.macports.org/#reference.phases.build -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080327/e4a63571/attachment.bin From master at iaas.msu.ru Thu Mar 27 04:14:18 2008 From: master at iaas.msu.ru (Michail Vidiassov) Date: Thu, 27 Mar 2008 14:14:18 +0300 Subject: ncurses patch 12605 Message-ID: <001801c88ffb$b337f010$fc03a8c0@csiaas.msu.ru> Dear All, the patch for ncurses (an offer to unify ncurses and ncursesw back into one port, to be more like the mac os x itself is setup and the ideal world, also fixing potential bugs when curses libs may be not found) seems to be forgotten for more than a quarter of a year, the initial reaction of Ryan did not result in a yes or no verdict, the maintainer/owner did not say a word. Please, direct some attention to the problem. Sincerely, Michail From ryandesign at macports.org Thu Mar 27 04:42:35 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 27 Mar 2008 06:42:35 -0500 Subject: [35353] tinyca2 Lint Report In-Reply-To: <27ACEBE0-37B1-4C27-9BC4-AE67687AB5EF@macports.org> References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> <27ACEBE0-37B1-4C27-9BC4-AE67687AB5EF@macports.org> Message-ID: <61ACFE89-1DF5-4232-B594-A1A8216925F9@macports.org> On Mar 26, 2008, at 11:28, Anders F Bj?rklund wrote: > Landon Fuller wrote: > >> On Mar 26, 2008, at 12:13 AM, Ryan Schmidt wrote: >> >>> Patchfile naming: The old guide was contradictory, and in one place, >>> recommended the naming scheme "patch-*" while in another place it >>> recommended "patch-*.diff". The new guide is now consistent in >>> recommending "patch-*.diff". >> >> The original documentation (which I wrote) was originally >> consistent with the FreeBSD >> patch specification: >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ >> slow-patch.html >> >> We then adopted the semantic of patch-foobar.diff, where 'foobar' >> was a feature that >> covered many files -- this was due to the headache of patch-per- >> file for a sizable set >> of diffs. > > I agree with Landon here, the current lint warning seems misguided ? > > This was discussed at length before it was implemented too, with there > being two different kinds of patches. But apparently "consistency" > once > again triumphed, and one of the types of patch naming was warned > about. > If anything, it should be eased up to allow anything like "patch-*"... > > We had "patch-foo.c" and "patch-bar.h", and also "patch-foobar.diff". > i.e. either patch-FILENAME (BSD style) or patch-ISSUE.diff (multi- > file) Thanks for clarifying that. I didn't realize the .diff extension was previously only used for multi-file patches, or rather, that the recommendation to use the .diff extension was meant only for multi- file patches. I had assumed someone had added something to the guide in one place and forgotten to update the recommendation in the other place. It seems an arbitrary distinction to me. A diff file is after all *always* a diff file, whether it patches one file or five. But at least now I understand the previously unexplained discrepancy in patchfile name recommendations. I still believe diff/patch files should always have the .diff extension but I'll admit that having port lint warn about it is a bit pedantic. Let's change port lint to only check for "patch-*". The guide doesn't mention the .diff extension for patchfiles at all. It has several examples of patchfile used in a port, none of which end in .diff. I would like to suggest that we change the guide to suggest using the .diff extension always. If people are against this suggestion, then we should at least add to the guide the recommended patchfile naming scheme for multi-file patches. I thought I had filed a ticket about this topic before but I can't find it now, but I would be happy to file one once we decide what the documentation should say. >> My original newline complaint was: >> Warning: Line 2 should be a newline (after RCS tag) >> >> # $Id: Portfile 35353 2008-03-25 18:13:44Z landonf at macports.org $ >> PortSystem 1.0 >> >> Why does that matter? > > Actually the whitespace checks were originally supposed to be > optional, > but I didn't know how to make "port lint" read options in Tcl... :-) > > The inspiration for the issued warnings was portlint(1), naturally > enough. > http://www.freebsd.org/doc/en/books/porters-handbook/porting- > portlint.html > > Stylistic newlines could be made optional, with an extra port > parameter ? I don't remember why whitespace checks were originally put into port lint, with the exception of checking for trailing whitespace following a backslash which is indeed a fatal error. Unfortunately, the error is so fatal that if you put trailing whitespace after a backslash, port lint might not even run until you fix it. For example, if I put this in a portfile... checksums md5 d6ca3009eee24a8e396b8f667b3bd8df \ sha1 38a94e4eefb3e262fbd0e2c7716ce721a6ecd73c \ rmd160 86694271fd7b657c7ede77671844376322bb3fef ...but I have a trailing space after the first line, port lint says this: $ port lint Can't map the URL 'file://.' to a port description file ("wrong # args: should be "sha1 action ?file?""). Please verify that the directory and portfile syntax are correct. To use the current port, you must be in a port's directory. (you might also see this message if a pseudo-port such as outdated or installed expands to no ports). can't read "portvariants": no such variable Error: Status 1 encountered during processing. $ We can change port lint to just check for trailing whitespace after a backslash. In light of the above, it seems it won't even get executed, but maybe we should still leave a check in there, in case we can some day improve port lint to be able to run in spite of such a syntax error. The warnings about missing blank lines are a bit too pedantic even for my taste and I would remove them. I attached new proposed patches to the ticket: http://trac.macosforge.org/projects/macports/ticket/14799 While we're deciding all this, and until we release a new version of MacPorts containing these fixes, let's also turn off automatic port lint emails. I filed a ticket for that: http://trac.macosforge.org/projects/macports/ticket/14817 From ryandesign at macports.org Thu Mar 27 04:46:31 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 27 Mar 2008 06:46:31 -0500 Subject: [35353] tinyca2 Lint Report In-Reply-To: References: <20080325181453.7D8F628050@relay13.apple.com> <20955E4D-EBC5-4312-A716-23DC50120CB7@macports.org> <47E943A8.8090307@orcaware.com> <02E5826B-A5F1-4276-9B67-9B997002C8D8@macports.org> <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> Message-ID: <547DFDD4-0621-45BF-8C5F-D1904104FDF3@macports.org> On Mar 26, 2008, at 11:03, James Berry wrote: > I agree fully with Landon. The automated lint on submit should be > limited, if even allowed, to severe errors that will cause the port > to be unusable. We have enough of a hard time getting people to > keep their ports up to date, without adding layers of unneeded > complexity. I think automated port lint is useful, if lint shows things that truly need fixing in a port. For example, we do want all ports to have certain required variables, and an $Id$ line, and we do want descriptions on variants, so it's good to be reminded when we've forgotten these things. We currently send the port lint report in a separate email to the committer and maintainer (I think). Would it be better if the report were appended to the change email that gets sent to macports-changes? From opendarwin.org at darkart.com Thu Mar 27 10:30:42 2008 From: opendarwin.org at darkart.com (Eric Hall) Date: Thu, 27 Mar 2008 17:30:42 +0000 Subject: [35353] tinyca2 Lint Report In-Reply-To: <547DFDD4-0621-45BF-8C5F-D1904104FDF3@macports.org> References: <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> <547DFDD4-0621-45BF-8C5F-D1904104FDF3@macports.org> Message-ID: <20080327173042.GU42614@darkart.com> On Thu, Mar 27, 2008 at 06:46:31AM -0500, Ryan Schmidt wrote: > > On Mar 26, 2008, at 11:03, James Berry wrote: > > > I agree fully with Landon. The automated lint on submit should be > > limited, if even allowed, to severe errors that will cause the port > > to be unusable. We have enough of a hard time getting people to > > keep their ports up to date, without adding layers of unneeded > > complexity. > > I think automated port lint is useful, if lint shows things that > truly need fixing in a port. For example, we do want all ports to > have certain required variables, and an $Id$ line, and we do want > descriptions on variants, so it's good to be reminded when we've > forgotten these things. > > We currently send the port lint report in a separate email to the > committer and maintainer (I think). Would it be better if the report > were appended to the change email that gets sent to macports-changes? > I think the automated port lint is good for errors, and its good as a separate email from the change email - the lint stands out that way, vs. being buried inside of change notices. -eric From opendarwin.org at darkart.com Thu Mar 27 10:40:01 2008 From: opendarwin.org at darkart.com (Eric Hall) Date: Thu, 27 Mar 2008 17:40:01 +0000 Subject: [35353] tinyca2 Lint Report In-Reply-To: <61ACFE89-1DF5-4232-B594-A1A8216925F9@macports.org> References: <47E9450C.4020907@orcaware.com> <8247EC1F-A14F-4483-A7F7-69A8CB2E4982@macports.org> <47E9471A.6070304@orcaware.com> <20080325185205.GR42614@darkart.com> <5cbbe4ae0803251336pde50c7eifec6d42e7f211920@mail.gmail.com> <245FD61F-F705-40D2-927A-BCE3554C4EA6@macports.org> <27ACEBE0-37B1-4C27-9BC4-AE67687AB5EF@macports.org> <61ACFE89-1DF5-4232-B594-A1A8216925F9@macports.org> Message-ID: <20080327174001.GV42614@darkart.com> On Thu, Mar 27, 2008 at 06:42:35AM -0500, Ryan Schmidt wrote: > On Mar 26, 2008, at 11:28, Anders F Bj?rklund wrote: > > > Landon Fuller wrote: > > > >> On Mar 26, 2008, at 12:13 AM, Ryan Schmidt wrote: > >> > >>> Patchfile naming: The old guide was contradictory, and in one place, > >>> recommended the naming scheme "patch-*" while in another place it > >>> recommended "patch-*.diff". The new guide is now consistent in > >>> recommending "patch-*.diff". > >> > >> The original documentation (which I wrote) was originally > >> consistent with the FreeBSD > >> patch specification: > >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ > >> slow-patch.html > >> > >> We then adopted the semantic of patch-foobar.diff, where 'foobar' > >> was a feature that > >> covered many files -- this was due to the headache of patch-per- > >> file for a sizable set > >> of diffs. > > > > I agree with Landon here, the current lint warning seems misguided ? > > > > This was discussed at length before it was implemented too, with there > > being two different kinds of patches. But apparently "consistency" > > once > > again triumphed, and one of the types of patch naming was warned > > about. > > If anything, it should be eased up to allow anything like "patch-*"... > > > > We had "patch-foo.c" and "patch-bar.h", and also "patch-foobar.diff". > > i.e. either patch-FILENAME (BSD style) or patch-ISSUE.diff (multi- > > file) > > Thanks for clarifying that. I didn't realize the .diff extension was > previously only used for multi-file patches, or rather, that the > recommendation to use the .diff extension was meant only for multi- > file patches. I had assumed someone had added something to the guide > in one place and forgotten to update the recommendation in the other > place. It seems an arbitrary distinction to me. A diff file is after > all *always* a diff file, whether it patches one file or five. But at > least now I understand the previously unexplained discrepancy in > patchfile name recommendations. > > I still believe diff/patch files should always have the .diff > extension but I'll admit that having port lint warn about it is a bit > pedantic. Let's change port lint to only check for "patch-*". > > The guide doesn't mention the .diff extension for patchfiles at all. > It has several examples of patchfile used in a port, none of which > end in .diff. I would like to suggest that we change the guide to > suggest using the .diff extension always. If people are against this > suggestion, then we should at least add to the guide the recommended > patchfile naming scheme for multi-file patches. I thought I had filed > a ticket about this topic before but I can't find it now, but I would > be happy to file one once we decide what the documentation should say. > I'd prefer that patches don't always end in .diff, but map to the filenames for the single-file patches. Patches that are multi-file I lean towards no .diff extension, that's a very minor preference. [snip] > ...but I have a trailing space after the first line, port lint says > this: > > $ port lint > Can't map the URL 'file://.' to a port description file ("wrong # > args: should be "sha1 action ?file?""). > Please verify that the directory and portfile syntax are correct. > To use the current port, you must be in a port's directory. > (you might also see this message if a pseudo-port such as > outdated or installed expands to no ports). > can't read "portvariants": no such variable > Error: Status 1 encountered during processing. > $ > > We can change port lint to just check for trailing whitespace after a > backslash. In light of the above, it seems it won't even get > executed, but maybe we should still leave a check in there, in case > we can some day improve port lint to be able to run in spite of such > a syntax error. I agree, trailing whitespace after a backslash (that's intended to make a multi-line continuation) is an error, and port lint should catch that. It'd be better if it caught it w/o being fatal, at least its a very obvious error as shown above. > > The warnings about missing blank lines are a bit too pedantic even > for my taste and I would remove them. > > I attached new proposed patches to the ticket: > > http://trac.macosforge.org/projects/macports/ticket/14799 Looks good to me, thanks for improving the missing blank lines part (I'll was being lazy there). -eric From ryandesign at macports.org Thu Mar 27 13:27:25 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 27 Mar 2008 15:27:25 -0500 Subject: Trac ticket Cc list should be changeable by anybody In-Reply-To: References: Message-ID: <70AF8475-DAAB-4579-B414-782BBC4A0CE1@macports.org> On Oct 2, 2007, at 09:44, Juan Manuel Palacios wrote: > On Oct 1, 2007, at 4:19 AM, Ryan Schmidt wrote: > >> Apparently our Trac install doesn't allow just anybody to add >> themselves to a ticket's Cc list. I think it should. Can we change >> it? > > This requires tweaking trac privileges for each user, which trac > doesn't support out of the box. I'm currently lobbying Mac OS Forge > admins to install the appropriate plugin to let us do just that > (see ticket #12595), but I reckon it's gonna take some time given > that they are currently moving to new servers (wooooot!). > > I'll inform of any updates. Regards,... The ticket was closed as wontfix 4 months ago saying a new system was being developed to address these needs. What's the status? From wsiegrist at apple.com Thu Mar 27 13:52:34 2008 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 27 Mar 2008 13:52:34 -0700 Subject: Trac ticket Cc list should be changeable by anybody In-Reply-To: <70AF8475-DAAB-4579-B414-782BBC4A0CE1@macports.org> References: <70AF8475-DAAB-4579-B414-782BBC4A0CE1@macports.org> Message-ID: <27B3835F-F752-486A-A213-14638DA2D499@apple.com> Trac v0.11 which has the better permission system is delayed due to a memory leak. I dont have time to make a plugin for 0.10 right now, though if someone else wants to develop it I'll install it on the server. -Bill On Mar 27, 2008, at 1:27 PM, Ryan Schmidt wrote: > > On Oct 2, 2007, at 09:44, Juan Manuel Palacios wrote: > >> On Oct 1, 2007, at 4:19 AM, Ryan Schmidt wrote: >> >>> Apparently our Trac install doesn't allow just anybody to add >>> themselves to a ticket's Cc list. I think it should. Can we change >>> it? >> >> This requires tweaking trac privileges for each user, which trac >> doesn't support out of the box. I'm currently lobbying Mac OS Forge >> admins to install the appropriate plugin to let us do just that >> (see ticket #12595), but I reckon it's gonna take some time given >> that they are currently moving to new servers (wooooot!). >> >> I'll inform of any updates. Regards,... > > The ticket was closed as wontfix 4 months ago saying a new system was > being developed to address these needs. What's the status? > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist at apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080327/44f70be7/attachment.bin From blb at macports.org Fri Mar 28 00:48:59 2008 From: blb at macports.org (Bryan Blackburn) Date: Fri Mar 28 00:48:25 2008 Subject: Fwd: using an http proxy? References: <47E821A5.3090403@macports.org> Message-ID: Rainer M?ller wrote on the MacPorts Users list: > > Bryan Blackburn wrote: >> If you set the standard curl proxy environment variables (http_proxy, >> FTP_PROXY, etc; see 'man curl'), this should get fetching of sources >> to work through the proxy. > > According to ticket #13158 [1], you have to specify your proxy on the > command line if using sudo, as it normally unsets environment > variables: > > $ sudo env http_proxy='foobar' port fetch $portname > I've just attached a patch to that ticket which should solve the proxy/ root issue. Basically, what it does is query the SystemConfiguration framework for the proper HTTP, HTTPS, and FTP proxy information (as well as names which should skip the proxy) and sets the proper libcurl environment variables appropriately. This is an issue on, I believe, 10.5 clean-install systems; my MBP was upgraded to 10.5 and didn't initially see it, as /etc/sudoers is left alone on an upgrade. If you clean install, the 10.5 sudoers cleans the environment, hence proxy-related variables not working through sudo. It was mentioned in the ticket that using the scutil command might be a good idea, but since that then requires parsing the output of another command, it could run into issues. My patch just adds to MacPorts (the Pextlib.dylib) what scutil does when querying for proxy information. Not to mention this makes it a bit more Mac-like since people no longer have to update .profile (or equivalent) when updating proxies, and it of course should follow location changes... Any comments? Bryan > ... > Rainer > > [1] http://trac.macosforge.org/projects/macports/ticket/13158 > From ryandesign at macports.org Sat Mar 29 04:13:38 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Mar 29 04:13:26 2008 Subject: [35495] trunk/dports/python/py25-pyprotocols/Portfile In-Reply-To: <20080329104342.5864F1519F1B@beta.macosforge.org> References: <20080329104342.5864F1519F1B@beta.macosforge.org> Message-ID: <2B70CF31-B679-4E38-9D49-47B3BAE04917@macports.org> On Mar 29, 2008, at 05:43, akira@macports.org wrote: > Added docs. [snip] > +post-destroot { > + file delete -force ${destroot}${prefix}/share/doc/${name} > + file copy ${worksrcpath}/docs/ref \ > + ${destroot}${prefix}/share/doc/${name} > + xinstall -m 644 -W ${worksrcpath} \ > + CHANGES.txt README.txt TODO.txt UPGRADING.txt \ > + ${destroot}${prefix}/share/doc/${name} > +} This changes the complement of files installed by the port, therefore the port revision should be incremented so everyone gets those new files. I did so in r35501. From ryandesign at macports.org Sat Mar 29 04:40:08 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Mar 29 04:40:00 2008 Subject: [35394] trunk/dports/lang/spidermonkey In-Reply-To: <20080327144611.43D621505B77@beta.macosforge.org> References: <20080327144611.43D621505B77@beta.macosforge.org> Message-ID: <7ABA99F0-EAC6-48A8-B566-04D840B2E84C@macports.org> On Mar 27, 2008, at 09:46, akira@macports.org wrote: > Revision: 35394 > http://trac.macosforge.org/projects/macports/changeset/35394 > Author: akira@macports.org > Date: 2008-03-27 07:45:58 -0700 (Thu, 27 Mar 2008) > > Log Message: > ----------- > Updated spidermonkey to 1.7.0 and took maintainership > -version 1.60 > -revision 1 > +version 1.7.0 Hmm... users who have 1.60 installed probably won't get informed of this upgrade, since numerically 7 < 60, right? :-( From ryandesign at macports.org Sat Mar 29 04:43:15 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat Mar 29 04:43:36 2008 Subject: [35395] trunk/dports/games In-Reply-To: <20080327144827.667621505C47@beta.macosforge.org> References: <20080327144827.667621505C47@beta.macosforge.org> Message-ID: On Mar 27, 2008, at 09:48, phw@macports.org wrote: > Create new Port of SuperTuxKart. Enjoz the race! > +name supertuxkart > +version 0.4 > +revision 1 Thanks for the port! For future ports and updates, remember that the initial revision of a given version of a port should be 0, not 1. From raimue at macports.org Sat Mar 29 05:00:03 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat Mar 29 04:59:17 2008 Subject: [35394] trunk/dports/lang/spidermonkey In-Reply-To: <7ABA99F0-EAC6-48A8-B566-04D840B2E84C@macports.org> References: <20080327144611.43D621505B77@beta.macosforge.org> <7ABA99F0-EAC6-48A8-B566-04D840B2E84C@macports.org> Message-ID: <47EE2F43.1020902@macports.org> Ryan Schmidt wrote: >> -version 1.60 >> -revision 1 >> +version 1.7.0 > > Hmm... users who have 1.60 installed probably won't get informed of > this upgrade, since numerically 7 < 60, right? :-( You are right. epoch should be set, too. Rainer From jmr at macports.org Sat Mar 29 16:54:17 2008 From: jmr at macports.org (Joshua Root) Date: Sat Mar 29 16:53:26 2008 Subject: Tester needed for ZopeEditManager Message-ID: <47EED6A9.3040102@macports.org> Could someone who is not using Leopard, and who is thereby able to build py-pyobjc, please test the patch in #5798? Thanks, Josh From dgou at mac.com Sat Mar 29 18:34:55 2008 From: dgou at mac.com (Douglas Philips) Date: Sat Mar 29 18:34:04 2008 Subject: py25-paramiko going back in time? Message-ID: # port upgrade py25-paramiko ---> Unable to uninstall py25-paramiko 1.7.3_0, the following ports depend on it: ---> bzr ---> bzrError: Uninstall py25-paramiko 1.7.3_0 failed: Please uninstall the ports that depend on py25-paramiko first. from port outdated: py25-paramiko 1.7.3_0 < 1.7.2_0 Is my ports tree messed up or is this a bug? Thanks, --Doug From marcuscalhounlopez at mac.com Sat Mar 29 18:44:11 2008 From: marcuscalhounlopez at mac.com (Marcus Calhoun-Lopez) Date: Sat Mar 29 18:43:19 2008 Subject: py25-paramiko going back in time? In-Reply-To: References: Message-ID: <9EB4584B-F242-47CB-B9AF-DBF838344D66@mac.com> Looking at the port history, this appears to be an intentional change in response to problems with version 1.7.3. rollback: http://trac.macports.org/projects/macports/changeset/35415 bug report: http://trac.macports.org/projects/macports/ticket/14805 -Marcus On Mar 29, 2008, at 7:34 PM, Douglas Philips wrote: > # port upgrade py25-paramiko > ---> Unable to uninstall py25-paramiko 1.7.3_0, the following ports > depend on it: > ---> bzr > ---> bzrError: Uninstall py25-paramiko 1.7.3_0 failed: Please > uninstall the ports that depend on py25-paramiko first. > > from port outdated: > py25-paramiko 1.7.3_0 < 1.7.2_0 > > > Is my ports tree messed up or is this a bug? > > Thanks, > --Doug > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From dgou at mac.com Sat Mar 29 19:00:36 2008 From: dgou at mac.com (Douglas Philips) Date: Sat Mar 29 18:59:46 2008 Subject: py25-paramiko going back in time? In-Reply-To: <9EB4584B-F242-47CB-B9AF-DBF838344D66@mac.com> References: <9EB4584B-F242-47CB-B9AF-DBF838344D66@mac.com> Message-ID: <6417982E-05D5-4271-A35C-E42C22D3F72D@mac.com> On 2008 Mar 29, at 9:44 PM, Marcus Calhoun-Lopez wrote: > Looking at the port history, this appears to be an intentional > change in response to problems with version 1.7.3. > > rollback: http://trac.macports.org/projects/macports/changeset/35415 > bug report: http://trac.macports.org/projects/macports/ticket/14805 I'm all down-up-graded now. Thanks! --Doug From ram at macports.org Sat Mar 29 19:33:34 2008 From: ram at macports.org (Adam Mercer) Date: Sat Mar 29 19:32:40 2008 Subject: py25-paramiko going back in time? In-Reply-To: References: Message-ID: <799406d60803291933w2e2d7dm2a65467b9e14b621@mail.gmail.com> On Sat, Mar 29, 2008 at 8:34 PM, Douglas Philips wrote: > # port upgrade py25-paramiko > ---> Unable to uninstall py25-paramiko 1.7.3_0, the following ports > depend on it: > ---> bzr > ---> bzrError: Uninstall py25-paramiko 1.7.3_0 failed: Please > uninstall the ports that depend on py25-paramiko first. > > from port outdated: > py25-paramiko 1.7.3_0 < 1.7.2_0 > > > Is my ports tree messed up or is this a bug? bzr fails when pushing to sftp with paramiko 1.7.3, I'm trying to find out why so in the mean time I reverted to 1.7.2 so that bzr can push to sftp. Cheers Adam From markd at macports.org Sat Mar 29 21:52:56 2008 From: markd at macports.org (markd@macports.org) Date: Sat Mar 29 21:51:59 2008 Subject: Document variant description in guide Message-ID: >We need to document variant descriptions in the guide. There doesn't >appear to be much on that now. > >It needs to say that all variants should have a description, except >for platform "variants" and other MacPorts-provided variants (only >"universal", I guess), for which MacPorts base should be providing >descriptions (but currently doesn't; we don't need to document that >but we do need to fix this in base). It should say that the variant >description should be short but clear, and ideally not merely repeat >the name of the variant. It should say that the syntax can be either > >variant bar description {foo} {...} > >or > >variant bar description "foo" {...} > >but that with "foo" one will need more quoting / escaping than with >{foo}. (Or maybe there should be a general section of the guide >describing these two different kinds of strings; then the variant >description section can just say that the variant description is any >valid kind of string.) It should say that because the variant >description is a string, one should take care not to put whitespace >between the brackets or quotation marks and the beginning and end of >the variant description, and also to watch whitespace within the >description. This is in contrast to the port description and >long_description, which aren't strings in that sense (what are they?) >and don't have these whitespace constraints. > >If we provide recommendations for the wording of the variant >description, my recommendation would be to write it as a sentence >fragment, with a capitalized first letter but no trailing >punctuation, and to think of the variant description as a radio >button or checkbox label. (Envision a GUI installation mechanism for >MacPorts in which variants are shown as checkboxes (for variants that >stand alone) or radio buttons (for a set of variants which are >mutually exclusive (using the "conflicts" syntax)).) Thus, it would >be better to write "Build with support for foo" instead of "Builds >with support for foo"; "Add support for foo" would be better than >"Adds support for foo". Well it took awhile, but here's my best shot at this. Very good suggestions. Revisions are in r35548. Mark From markd at macports.org Sat Mar 29 22:05:42 2008 From: markd at macports.org (markd@macports.org) Date: Sat Mar 29 22:04:43 2008 Subject: Unable to install devel/bazaar with MP 1.6 Message-ID: > Take a look at r31808 which I just committed, it turned out to be >a >bug in the way the Portfile was declaring its environment requirements: > >Correct erroneous quoting in environment variables passed to >MacPorts. These we written with nested quoting >as, e.g, "-L'${prefix}/lib'", but ever since Paul reworked our >environemt parser back in 1.4.x days and then >Anders fixed a bug in the new parser in r30273 (which happened after >the 1.5.2 release), the '' subquoting >level is illegal. Now a simple "-L${prefix}/lib", or even -L${prefix}/ >lib without any quoting at all, suffices. > >This commit fixes building and destrooting of bazaar per Adam Mercer >(ram)'s bug on the dev list. It turned out >to not be a regression with respect to 1.5.s as I anticipated, but >rather and improper declaration of the environment, >which only worked back in 1.5.2 days as a side effect of the bug >Anders fixed in r30273, if I'm not mistaken. > > Mark, would it be possible to have this (guidelines for proper >environment declarations within a Portfile) documented somewhere in >the guide? Thanks! > > Regards,... > > >-jmpp Hi Juan, I'm running a few months behind, but I'm not really sure how to describe proper environment declarations generally. What other guidelines can we come up with besides "no double quoting"? Mark From markd at macports.org Sat Mar 29 22:13:39 2008 From: markd at macports.org (markd@macports.org) Date: Sat Mar 29 22:12:42 2008 Subject: Guide should warn about default_variants Message-ID: >The guide says this about default_variants: > >> If variants are defined, then the default_variants value lists >> which variants are enabled by default. This allows for Portfile >> modularity and also allows users to suppress default variants if >> they wish. >> >> * Default: none >> * Example: default_variants +ssl +tcpd >> >> Default variants may be suppressed by preceding a variant name >> with a "-" as shown in this example. >> >> %% port install foo -ssl > >A MacPorts bug makes default_variants inadvisable to use for variants >that you might conceivably want to disable. (If, as in the example >above, you "port install foo -ssl", foo -ssl is installed. But when >you later need to upgrade foo, default_variants +ssl will take >precedence and you'll be left with just "foo" (no "-ssl") installed.) >Therefore, this section should add a note like this: > > >"The use of default_variants is discouraged. Instead, it's recommend >that a port be built such that the most commonly requested >functionality is on, and if needed, can be disabled with a >"+no_something" variant. To extend the above example, build the port >so that ssl and tcpd functionality is on, without needing to select >any variant. Provide "no_ssl" and "no_tcpd" variants if there's a >good reason someone might want to disable those features." Is this still the best advice on default variants? I recalled (or so I thought) of a distant thread that had recommended them, so I have a few ports that use them. Is this view stated here the consensus view now? I just want to be sure. Also, is the bug referred to in v1.6 (still a bug) for ports that still use default variants? Mark From randall.h.wood at alexandriasoftware.com Sun Mar 30 02:33:01 2008 From: randall.h.wood at alexandriasoftware.com (Randall Wood) Date: Sun Mar 30 02:32:08 2008 Subject: rarian and scrollkeeper Message-ID: Does the rarian port completely obsolete scrollkeeper or does it merely conflict with scrollkeeper? I'm getting the following message and am wondering if I can simply uninstall scrollkeeper and replace all dependencies on it with a dependency on rarian? ---> Activating rarian 0.8.0_0 Error: Target org.macports.activate returned: Image error: /opt/local/bin/scrollkeeper-config is being used by the active scrollkeeper port. Please deactivate this port first, or use the -f flag to force the activation. Error: The following dependencies failed to build: rarian I know that rarian is supposed to be a drop-in replacement for scrollkeeper. but is it really? -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." From guido.soranzio at gmail.com Sun Mar 30 02:58:54 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Sun Mar 30 02:58:07 2008 Subject: rarian and scrollkeeper In-Reply-To: References: Message-ID: <8BA06BCF-031D-40C8-8770-70D7640880BB@gmail.com> On Mar 30, 2008, at 11:33 AM, Randall Wood wrote: > > I know that rarian is supposed to be a drop-in replacement for > scrollkeeper. but is it really? Yes, scrollkeeper has been deprecated in Gnome 2.22: rarian provides its own substitutes of the "scrollkeeper-*" commands required for backward compatibility. -- Guido From ryandesign at macports.org Sun Mar 30 03:23:50 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Mar 30 03:23:37 2008 Subject: [35533] trunk/dports/www/firefox-x11 In-Reply-To: <20080329205712.39C4D151C06B@beta.macosforge.org> References: <20080329205712.39C4D151C06B@beta.macosforge.org> Message-ID: <9C1C7DB5-1574-4134-8067-1A4004C1A697@macports.org> On Mar 29, 2008, at 15:57, jmr@macports.org wrote: > Revision: 35533 > http://trac.macosforge.org/projects/macports/changeset/35533 > Author: jmr@macports.org > Date: 2008-03-29 13:57:11 -0700 (Sat, 29 Mar 2008) > > Log Message: > ----------- > firefox-x11: install shared libs with correct paths. This changes the files that get installed by the port, right? If so, the port revision should be incremented, so everyone gets this change. I incremented the revision in r35568. From ryandesign at macports.org Sun Mar 30 03:41:25 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Mar 30 03:50:59 2008 Subject: [35371] trunk/dports/editors In-Reply-To: <20080326091547.947DA14EA2D4@beta.macosforge.org> References: <20080326091547.947DA14EA2D4@beta.macosforge.org> Message-ID: <2F967D89-D979-4BDD-92A3-D4C094E4BC7E@macports.org> On Mar 26, 2008, at 04:15, reiffert@macports.org wrote: > +configure.ldflags-append -L${prefix}/lib -L/usr/X11R6/lib > +configure.cflags-append -I${prefix}/include -I/usr/X11R6/include Thanks for the port! But could you please use ${x11prefix} instead of /usr/X11R6? Also, you don't need to append -L${prefix}/lib to LDFLAGS because -L${prefix}/lib is already in LDFLAGS by default. And you may not need -I${prefix}/include in CFLAGS because MacPorts already puts -I${prefix}/include in CPPFLAGS. From gerhard.reitmayr at gmail.com Sun Mar 30 05:30:04 2008 From: gerhard.reitmayr at gmail.com (Gerhard Reitmayr) Date: Sun Mar 30 05:29:10 2008 Subject: fix for omniORB portfile In-Reply-To: <144a3b8b0803300526r48dacb60n1ff119e8f279446f@mail.gmail.com> References: <144a3b8b0803300526r48dacb60n1ff119e8f279446f@mail.gmail.com> Message-ID: <144a3b8b0803300530j4edaa978i321b390ff226c658@mail.gmail.com> Hi, I am the maintainer of omniORB portfile and submitted a ticket for a small fix in the portfile: http://trac.macosforge.org/projects/macports/ticket/14863 would a committer take a look at it and commit it ? thank you, Gerhard From reiffert at macports.org Sun Mar 30 05:33:44 2008 From: reiffert at macports.org (Thomas Reifferscheid) Date: Sun Mar 30 05:32:55 2008 Subject: [35371] trunk/dports/editors In-Reply-To: <2F967D89-D979-4BDD-92A3-D4C094E4BC7E@macports.org> References: <20080326091547.947DA14EA2D4@beta.macosforge.org> <2F967D89-D979-4BDD-92A3-D4C094E4BC7E@macports.org> Message-ID: <47EF88A8.9080505@macports.org> Please have a look at the beautiful broken Makefiles yourself and tell me how to do it correctly. It just beats me. Kind regards Thomas Ryan Schmidt wrote: > > On Mar 26, 2008, at 04:15, reiffert@macports.org wrote: > >> +configure.ldflags-append -L${prefix}/lib -L/usr/X11R6/lib >> +configure.cflags-append -I${prefix}/include -I/usr/X11R6/include > > Thanks for the port! But could you please use ${x11prefix} instead of > /usr/X11R6? Also, you don't need to append -L${prefix}/lib to LDFLAGS > because -L${prefix}/lib is already in LDFLAGS by default. And you may > not need -I${prefix}/include in CFLAGS because MacPorts already puts > -I${prefix}/include in CPPFLAGS. > From raimue at macports.org Sun Mar 30 19:06:42 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun Mar 30 19:05:48 2008 Subject: Fwd: using an http proxy? In-Reply-To: References: <47E821A5.3090403@macports.org> Message-ID: <47F04732.8060901@macports.org> Bryan Blackburn wrote: > I've just attached a patch to that ticket which should solve the proxy/ > root issue. Basically, what it does is query the SystemConfiguration > framework for the proper HTTP, HTTPS, and FTP proxy information (as > well as names which should skip the proxy) and sets the proper libcurl > environment variables appropriately. > > [...] > > Not to mention this makes it a bit more Mac-like since people no > longer have to update .profile (or equivalent) when updating proxies, > and it of course should follow location changes... > > Any comments? Awesome patch! Looks very good so far. Although I have not had time or a proxy to test it. Rainer From akalin at akalin.cx Sun Mar 30 20:38:32 2008 From: akalin at akalin.cx (Frederick Akalin) Date: Sun Mar 30 20:37:33 2008 Subject: Forcing the test phase to be run by default in a Portfile? In-Reply-To: References: Message-ID: I want to have the test phase run automatically for a particular port because it is important to guarantee correctness for that port (in this case, I'm working with gmp). I couldn't find a switch to do it; test.run only enables the test phase and does not have it run. Is there an easy way to do this? Thanks! -- Frederick Akalin From ryandesign at macports.org Sun Mar 30 22:40:10 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun Mar 30 22:39:51 2008 Subject: Forcing the test phase to be run by default in a Portfile? In-Reply-To: References: Message-ID: <59F429DC-6755-4453-A6EF-CCA5F7EB3F63@macports.org> On Mar 30, 2008, at 22:38, Frederick Akalin wrote: > I want to have the test phase run automatically for a particular port > because it is important to guarantee correctness for that port (in > this case, I'm working with gmp). I couldn't find a switch to do it; > test.run only enables the test phase and does not have it run. Is > there an easy way to do this? I'm not sure. In the absence of such an option, consider sudo port -d test foo && sudo port clean --work foo && sudo port install foo or sudo port -d test foo && sudo port clean --work foo && sudo port upgrade foo From afb at macports.org Sun Mar 30 23:56:46 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun Mar 30 23:55:57 2008 Subject: Forcing the test phase to be run by default in a Portfile? In-Reply-To: References: Message-ID: Frederick Akalin wrote: > I want to have the test phase run automatically for a particular port > because it is important to guarantee correctness for that port (in > this case, I'm working with gmp). I couldn't find a switch to do it; > test.run only enables the test phase and does not have it run. Is > there an easy way to do this? If the test is indeed mandatory, then move it from the "test" phase to the "build" phase instead. Worst case, it is just being run twice... --anders From exodusd at gmx.de Mon Mar 31 03:30:15 2008 From: exodusd at gmx.de (Robert Hinn) Date: Mon Mar 31 03:29:20 2008 Subject: Ticket #14796 (pike): please commit Message-ID: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> Hello, I updated the pike Portfile five days ago, but the ticket hasn't been processed yet. Could you commit the changes for me since I have no commit rights myself? Here's the URL to the ticket: http://trac.macosforge.org/projects/macports/ticket/14796 Thanks in advance, Robert From florian.ebeling at gmail.com Mon Mar 31 03:42:22 2008 From: florian.ebeling at gmail.com (Florian Ebeling) Date: Mon Mar 31 03:41:24 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> Message-ID: <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> > I updated the pike Portfile five days ago, but the ticket hasn't been > processed yet. Could you commit the changes for me since I have no commit > rights myself? I come to the impression that there are too few committers. What do others think on this? And how many are there currently, anyway? Florian -- Florian Ebeling florian.ebeling@gmail.com From guido.soranzio at gmail.com Mon Mar 31 04:32:35 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Mon Mar 31 04:31:48 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> Message-ID: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> On Mar 31, 2008, at 12:42 PM, Florian Ebeling wrote: >> > I come to the impression that there are too few committers. What do > others think on this? We are in serious need of: 1. An open repository where to exchange precompiled archives in order to avoid the lengthy compilations of the dependencies. 2. A buildbot on a central server which automatically builds and tests the proposed portfiles in a chroot'ed environment. 3. A "testing" branch for the beta-testers who would like to help transitioning to development releases without breaking the main trunk (i.e. Gnome 2.22, Python 3.0, KDE 4.0, ...). -Guido From afb at macports.org Mon Mar 31 04:33:21 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon Mar 31 04:32:22 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> Message-ID: <4D36B79D-6748-42DD-8C5E-EFAFE327612E@macports.org> Florian Ebeling wrote: >> I updated the pike Portfile five days ago, but the ticket hasn't >> been >> processed yet. Could you commit the changes for me since I have no >> commit >> rights myself? > > I come to the impression that there are too few committers. What do > others think on this? And how many are there currently, anyway? "None", as far as I know... If you mean people that regularly go through the entire list of outstanding port upgrade/addition tickets and commit all changes ? And not just port maintainers that have a self-interest in seeing their own ports and their dependencies being somewhat up-to-date. --anders From raimue at macports.org Mon Mar 31 06:16:59 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Mar 31 06:16:02 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> Message-ID: <47F0E44B.3040106@macports.org> Guido Soranzio wrote: > We are in serious need of: > > 1. An open repository where to exchange precompiled archives in > order to avoid the lengthy compilations of the dependencies. Which requires 2. > 2. A buildbot on a central server which automatically builds > and tests the proposed portfiles in a chroot'ed environment. This would require the LoggingProposal [1] to be implemented first. > 3. A "testing" branch for the beta-testers who would like to help > transitioning to development releases without breaking > the main trunk (i.e. Gnome 2.22, Python 3.0, KDE 4.0, ...). We discussed this before and voted against it. We already have the *-devel ports. What we really need would be a better dependency engine which can handle alternatives and versions. Also, multiple versions of a port would be good. There is of course much to do with MacPorts, but we are still lacking a roadmap... Rainer [1] http://trac.macosforge.org/projects/macports/wiki/LoggingProposal From guido.soranzio at gmail.com Mon Mar 31 06:55:23 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Mon Mar 31 06:54:29 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <47F0E44B.3040106@macports.org> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> Message-ID: On Mar 31, 2008, at 3:16 PM, Rainer M?ller wrote: >> 1. An open repository where to exchange precompiled archives in >> order to avoid the lengthy compilations of the dependencies. > > Which requires 2. I meant a simple hosting infrastructure outside of the subversion repository where the submitters and the committers could upload and share their precompiled packages/archives: we already have the archive mode and the support for RPM. "DPLight" and the http://packages.opendarwin.org were naive solutions but they could greatly help the committers to avoid building themselves the lengthy dependencies which weren't of their particular interest. -Guido From raimue at macports.org Mon Mar 31 07:03:43 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Mon Mar 31 07:02:47 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> Message-ID: <47F0EF3F.6090906@macports.org> Guido Soranzio wrote: > I meant a simple hosting infrastructure outside of the subversion > repository where the submitters and the committers could upload and > share their precompiled packages/archives: we already have the > archive mode and the support for RPM. Sure, but it doesn't integrate with MacPorts and installs outside the registry. So it will rather screw up your existing installation. > "DPLight" and the http://packages.opendarwin.org were naive > solutions but they could greatly help the committers to avoid > building themselves the lengthy dependencies which weren't of > their particular interest. Yes, as far as I know, it was planned to integrate dp-light into each of the packages in order to register it properly with the registry. But that never happened because it required to include nearly the whole base. Rainer From guido.soranzio at gmail.com Mon Mar 31 08:53:48 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Mon Mar 31 08:52:53 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <47F0EF3F.6090906@macports.org> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> Message-ID: <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> On Mar 31, 2008, at 4:03 PM, Rainer M?ller wrote: > Sure, but it doesn't integrate with MacPorts and installs outside the > registry. So it will rather screw up your existing installation. Let's talk on more practical terms. On trunk several pieces of Gnome 2.22 have been already committed sparsely without coordination: almost a nightmare. Let's suppose that someone (me!) is busy building Gnome again from scratch and he is offering his archives/packages to the others in order to save humanly the battery life of their portable: why shouldn't you trust him (me!)? Currently MacPorts doesn't offer OpenOffice, nor Mono, nor KDE 4, nor X.org, nor Java 6: how can we afford to accomplish these valuable porting efforts if every committer/submitter is building again and again his personal tree? FreeBSD has them thanks to dedicated teams and a building cluster: that's the way to go. It's really sad that we are hosted in the same "community" infrastructure of WebKit and of his buildbots but you have to spend hours to recompile it yourself in order to test the latest new Gnome application which makes use of WebKit's latest daily features. Ever heard of MacRuby? Yes, it is here on Mac OS Forge. -Guido From wsiegrist at apple.com Mon Mar 31 09:07:06 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon Mar 31 09:07:36 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> Message-ID: <020C4646-A9A2-4F29-9C59-3F8AB6E01F05@apple.com> On Mar 31, 2008, at 8:53 AM, Guido Soranzio wrote: > It's really sad that we are hosted in the same "community" > infrastructure of WebKit and of his buildbots but you have to > spend hours to recompile it yourself in order to test the latest > new Gnome application which makes use of WebKit's latest daily > features. > You might want to check your facts before posting. bash:~# host build.webkit.org build.webkit.org has address 72.36.164.203 bash:~# host www.macports.org www.macports.org has address 17.254.17.248 Thanks -Bill ---- William Siegrist Software Support Engineer Mac OS Forge http://macosforge.org/ wsiegrist@apple.com 408 862 7337 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080331/f2a05140/smime.bin From jkh at apple.com Mon Mar 31 09:14:44 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon Mar 31 09:15:15 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> Message-ID: There are two few committers for dports/ and REALLY very few committers for base/ - I think we should be more liberal in allowing new committers, being ever mindful of the fact that source control always means you can back things out (and, as we grow, I think it's also important to be flexible about that during/because of any dispute). - Jordan On Mar 31, 2008, at 3:42 AM, Florian Ebeling wrote: >> I updated the pike Portfile five days ago, but the ticket hasn't been >> processed yet. Could you commit the changes for me since I have no >> commit >> rights myself? > > I come to the impression that there are too few committers. What do > others think on this? And how many are there currently, anyway? > > Florian > > > > > > > > > > -- > Florian Ebeling > florian.ebeling@gmail.com > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo/macports-dev From jkh at apple.com Mon Mar 31 09:36:36 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon Mar 31 09:37:08 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> Message-ID: <64073CB3-7B4A-4562-86BE-F23FA71C00A8@apple.com> On Mar 31, 2008, at 4:32 AM, Guido Soranzio wrote: > We are in serious need of: > > 1. An open repository where to exchange precompiled archives in > order to avoid the lengthy compilations of the dependencies. One might argue instead that we are in serious need of a binary packages collection, any package from which could/should be detectable by the dependency checking machinery and, if suitable, used in lieu of a build. That would kill two birds with one stone - make development easier and also give end-users what they've wanted since the project was announced. > 2. A buildbot on a central server which automatically builds > and tests the proposed portfiles in a chroot'ed environment. That would be nice (and, given a centralized package building/hosting structure, would also give us this for all the existing ports as a side-effect), but the project has also claimed to want such a thing for a long time without actually being motivated enough to create the software for driving such a buildbot, so the actual need remains debatable. In lieu of this possible future development, I think it would be useful enough just to be able to turn any individual machine into a "buildbot" for short periods of time since disk space and CPU horsepower are getting cheaper and cheaper and I doubt even 20% of Mac users these days really push their machines to the limit. It could be something as simple as this to start: port chroot-create /tmp/mychroot [optional target describing flags] while ; do port chroot-exec target portname|portfile done port chroot-destroy /tmp/mychroot The mechanics of chroot-create wouldn't even be particularly complex, but creating an effective chroot environment on MacOSX is a little harder than on less dynamically linked/less complex systems like Linux and FreeBSD and requires knowledge of what files to copy in as well as what specialized filesystems to mount in order to keep, among other things, Carbon apps from blowing up (see macports/base/portmgr/ packaging/buildall.sh for an earlier attempt to do this for each port in the collection as a regression test). The chroot-destroy command would, of course, be responsible for unmounting stuff and properly nuking the chroot environment again. Either way, you've provided a nice abstraction boundary for the developer and can refine the definition of "chroot" as various edge cases are found without having to disseminate updated instructions to everyone. I probably updated my chroot definition about 20 times while I was creating that buildall.sh script I just mentioned and I still don't think I got it totally right in terms of "minimum functional footprint." > 3. A "testing" branch for the beta-testers who would like to help > transitioning to development releases without breaking > the main trunk (i.e. Gnome 2.22, Python 3.0, KDE 4.0, ...). We could do that, or we could do what many other projects seem to do, which is to get most people living on the -stable branch, where the releases also come from, and get trunk back to the purpose of doing just that sort of testing. Developers shouldn't be so terrified of breaking trunk, assuming that they're also willing to be responsible enough to quickly fix what they break (and, if they don't, there's the back-out rule). - Jordan From jkh at apple.com Mon Mar 31 09:41:45 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon Mar 31 09:41:14 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <47F0E44B.3040106@macports.org> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> Message-ID: <91F75F41-FE15-46B9-AEFB-EAE8BB8DA6BF@apple.com> On Mar 31, 2008, at 6:16 AM, Rainer M?ller wrote: > There is of course much to do with MacPorts, but we are still > lacking a roadmap... No offense to jmpp intended, but I think what macports is really lacking is effective technical leadership. There are a lot of good ideas floating around, but nobody really driving the bus. I also used to think that you could elect someone to drive the bus and was a strong proponent of the democratic process which led FreeBSD to elect its core team, but I was wrong. Completely, utterly and totally wrong. :-) - Jordan From dluke at geeklair.net Mon Mar 31 09:47:40 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon Mar 31 09:46:41 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <91F75F41-FE15-46B9-AEFB-EAE8BB8DA6BF@apple.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <91F75F41-FE15-46B9-AEFB-EAE8BB8DA6BF@apple.com> Message-ID: <644666F6-D6A9-4D80-84FC-818D28E589D9@geeklair.net> On Mar 31, 2008, at 12:41 PM, Jordan K. Hubbard wrote: > No offense to jmpp intended, but I think what macports is really > lacking is effective technical leadership. There are a lot of good > ideas floating around, but nobody really driving the bus. I also > used to think that you could elect someone to drive the bus and was > a strong proponent of the democratic process which led FreeBSD to > elect its core team, but I was wrong. Completely, utterly and > totally wrong. :-) In this case, I don't think you were totally wrong ;-) When we originally did our Portmgr elections the plan was for a limited term (but allowing people to run for re-election). Additionally, there was an at least tacit understanding that people who ended up not having enough time to dedicate to the project would step down. I'm not trying to call anyone out (and I'm not trying to start a power struggle - I certainly don't have enough time to dedicate to MacPorts right now to consider being on portmgr). -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080331/c64d4356/PGP.bin From jberry at macports.org Mon Mar 31 09:47:55 2008 From: jberry at macports.org (James Berry) Date: Mon Mar 31 09:47:08 2008 Subject: MacPorts GSoC application!!! Extended!!! Students can earn summer money $$$ and prestige!!! Message-ID: Those of you who are a college student, work on a college campus, know college students, or have a college student as a child, please notice: The Google Summer of Code student application deadline for 2008 has been extended for one week to April 7. This means that students have one additional week to apply for a summer job to help extend MacPorts!!! This is a great opportunity for students to get real, live, on the ground programming experience, work on an exciting open source project with an experienced adult mentor, and (best of all) to be paid $4500 USD by google for the summer of work. MacPorts has many great tasks that could use attention, and still has lots of slots for volunteers; we could use more applicants. Please pass the word to qualified and interested student applicants: the more applicants we get, the more slots we'll positions we'll be granted by google. This is a great opportunity not just for the students, but to foster and extend the MacPorts project. Please see http://trac.macosforge.org/projects/macports/wiki/SummerOfCode for more details. If you have questions, do hesitate to directly contact me, William Siegrist, or any of the other mentors. James -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2761 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080331/74d5d923/smime.bin From jkh at apple.com Mon Mar 31 09:47:08 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon Mar 31 09:47:37 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> Message-ID: <6CB60617-5D9C-4C7E-96FA-F26BC3EB50F0@apple.com> On Mar 31, 2008, at 6:55 AM, Guido Soranzio wrote: > I meant a simple hosting infrastructure outside of the subversion > repository where the submitters and the committers could upload and > share their precompiled packages/archives: we already have the > archive mode and the support for RPM. That's a nice idea in theory, and finding such a place to stick such things on MacOSForge would be comparatively simple, but I think that's a recipe for failure and bizarre behavior until such time as we get all the submitters and committers building things in a consistent way. What I mean is, committer A could be building on Tiger/PPC, committer B on Leopard 10.5.0 and committer C on Leopard 10.5.2 (just to name 3 of the many possible permutations). Now they all go to upload their bits to a common place which others start to download and depend on. Will it work? Who knows? You could, of course, put big warning signs up saying "Do not build on anything but 10.5.2/i386 if you are going to upload here!!" but people don't read signs, so now what? I think a way of enforcing consistency in the build process is a prerequisite to a precompiled pile of bits that just anyone can contribute to. Having a centralized build infrastructure create them would, at least, eliminate one half of the problem. - Jordan From raimue at macports.org Mon Mar 31 09:53:15 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Mar 31 09:52:17 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> Message-ID: <47F116FB.6080303@macports.org> Guido Soranzio wrote: > On trunk several pieces of Gnome 2.22 have been already committed > sparsely without coordination: almost a nightmare. Why is this a nightmare? Gnome ports got no maintainer, so others did what they could. > Let's suppose that someone (me!) is busy building Gnome again from > scratch and he is offering his archives/packages to the others in > order to save humanly the battery life of their portable: why > shouldn't you trust him (me!)? We have a lot of supported platforms: Panther ppc, Tiger i386, Tiger ppc, Leopard i386, Leopard x86_64, Leopard ppc, Leopard ppc64. Can you provide packages for all those? > Currently MacPorts doesn't offer OpenOffice, nor Mono, nor KDE 4, > nor X.org, nor Java 6: how can we afford to accomplish these valuable > porting efforts if every committer/submitter is building again > and again his personal tree? FreeBSD has them thanks to dedicated > teams and a building cluster: that's the way to go. Step up and provide ports for them if you think they are valuable. What's the problem with building them yourself? So you can choose the variants you want. > [...] > Ever heard of MacRuby? Yes, it is here on Mac OS Forge. We have a port for ruby. If they provide valuable patches, integrate them (upstream, as variant or just as default patchfiles). Rainer From jberry at macports.org Mon Mar 31 10:02:58 2008 From: jberry at macports.org (James Berry) Date: Mon Mar 31 10:01:58 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <644666F6-D6A9-4D80-84FC-818D28E589D9@geeklair.net> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <91F75F41-FE15-46B9-AEFB-EAE8BB8DA6BF@apple.com> <644666F6-D6A9-4D80-84FC-818D28E589D9@geeklair.net> Message-ID: <84ABA62E-4D36-43F6-8BEF-A1E9F3354B6D@macports.org> On Mar 31, 2008, at 9:47 AM, Daniel J. Luke wrote: > On Mar 31, 2008, at 12:41 PM, Jordan K. Hubbard wrote: >> No offense to jmpp intended, but I think what macports is really >> lacking is effective technical leadership. There are a lot of good >> ideas floating around, but nobody really driving the bus. I also >> used to think that you could elect someone to drive the bus and was >> a strong proponent of the democratic process which led FreeBSD to >> elect its core team, but I was wrong. Completely, utterly and >> totally wrong. :-) > > > In this case, I don't think you were totally wrong ;-) > > When we originally did our Portmgr elections the plan was for a > limited term (but allowing people to run for re-election). > Additionally, there was an at least tacit understanding that people > who ended up not having enough time to dedicate to the project would > step down. I don't think anybody would disagree that many of us don't have enough time to dedicate to the project at present. Of the three elected members of PortMgr, and know that mww has effectively stepped away from the project and would be happy to have a replacement. I know I have been far too busy elsewhere lately to effectively lead the MacPorts effort, and would be happy to step away if there are other people with the time and energy to step in and make progress. I won't speak for jmpp. The last time the three of us discussed this, the best thing for the project seemed to be to encourage a continuity of leadership. It's been several years since that discussion, our respective time commitments have changed, and things have stabilized to a large degree, not to mention that we've transitioned to a new name and home, all of which have helped. It may be time to address this situation. I am encouraged by some of those who have recently brought in a new surge of energy (I'm thinking of afb, raim, and Ryan, in particular, not to mention wms, though I'm sure I'm missing others, to whom I apologize). If anyone is interested in taking a more direct and sanctioned leadership role, please do speak up: your destiny may lie just ahead! James -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2761 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080331/e65114f2/smime.bin From jberry at macports.org Mon Mar 31 10:06:27 2008 From: jberry at macports.org (James Berry) Date: Mon Mar 31 10:05:28 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> Message-ID: <748BEF7B-0BC6-453D-B5CF-922B929A9F8F@macports.org> On Mar 31, 2008, at 9:14 AM, Jordan K. Hubbard wrote: > There are two few committers for dports/ and REALLY very few > committers for base/ - I think we should be more liberal in allowing > new committers, being ever mindful of the fact that source control > always means you can back things out (and, as we grow, I think it's > also important to be flexible about that during/because of any > dispute). We have tried over the last year to really loosen up the committer requirements, solicit new committers, etc. We've called a number of times for new submitter applications and basically take anybody who has shown any sort of commitment or experience with MacPorts. So I'll say it once more: if you're interested in being a macports committer, please just ask: http://trac.macosforge.org/projects/macports/wiki/NewCommittersGuide . James -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2761 bytes Desc: not available Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080331/073b7069/smime.bin From afb at macports.org Mon Mar 31 10:25:09 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon Mar 31 10:24:11 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <64073CB3-7B4A-4562-86BE-F23FA71C00A8@apple.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <64073CB3-7B4A-4562-86BE-F23FA71C00A8@apple.com> Message-ID: <8354D9E4-5AFE-4098-9A84-55D654226804@macports.org> Jordan K. Hubbard wrote: > Either way, you've provided a nice abstraction boundary for the > developer and can refine the definition of "chroot" as various edge > cases are found without having to disseminate updated instructions > to everyone. I probably updated my chroot definition about 20 > times while I was creating that buildall.sh script I just mentioned > and I still don't think I got it totally right in terms of "minimum > functional footprint." chroot was discussed last year, but somewhat discarded as overkill compared to trace mode and flexible logging... I updated the chroot scripts from OpenDarwin to install Tiger instead, but there never was a "minimum footprint" decided so it installed most of it - or about 4 GB in total. (this was when installed from the Mac OS X + Xcode Tools installation packages, before any pruning) I do think a chroot setup, combined with the SDKs and cross- compilation, could allow for building a lot of binary packages. --anders From guido.soranzio at gmail.com Mon Mar 31 10:47:40 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Mon Mar 31 10:46:44 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <47F116FB.6080303@macports.org> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> Message-ID: <3EBDEABF-0FFD-42D5-BF15-B2E75474EA23@gmail.com> On Mar 31, 2008, at 6:53 PM, Rainer M?ller wrote: > > Step up and provide ports for them if you think they are valuable. Done: I have proposed the first WebKit's portfile, I have fixed it and I have patched the makefiles for all the ports depending on PyGTK: I asked for commit privileges to PortMgr because my reports weren't committed promptly and without them Gnome was not buildable on Leopard. > We have a port for ruby. No: MacRuby is a new project which is porting Ruby 1.9 directly on the Objective-C runtime. I only wished that the other projects reachable from the same MacOSForge's home page could have a portfile and could share more resources. On the Xquartz mailing list someone still suggests not to use MacPorts... -Guido From raimue at macports.org Mon Mar 31 11:17:59 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon Mar 31 11:17:00 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <3EBDEABF-0FFD-42D5-BF15-B2E75474EA23@gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <3EBDEABF-0FFD-42D5-BF15-B2E75474EA23@gmail.com> Message-ID: <47F12AD7.2010307@macports.org> Guido Soranzio wrote: > On Mar 31, 2008, at 6:53 PM, Rainer M?ller wrote: >> We have a port for ruby. > > No: MacRuby is a new project which is porting Ruby 1.9 directly on the > Objective-C runtime. Okay, so it is different from the default Ruby and seems to be a separate project. Make a ruby-mac port or something like that. See, someone with experience with this project has to create a port. > I only wished that the other projects reachable from the same MacOSForge's > home page could have a portfile and could share more resources. Sure. Who wants to provide and maintain Portfiles for them? E.g. a request for a calendarserver port is lying around for a long time in the tickets database already. > On the Xquartz mailing list someone still suggests not to use MacPorts... And what should we do about it? If someone recommends against using MacPorts he might have reasons. And we would need to know his reasons in order to improve MacPorts. Rainer From jkh at apple.com Mon Mar 31 12:27:26 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon Mar 31 12:27:25 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <8354D9E4-5AFE-4098-9A84-55D654226804@macports.org> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <64073CB3-7B4A-4562-86BE-F23FA71C00A8@apple.com> <8354D9E4-5AFE-4098-9A84-55D654226804@macports.org> Message-ID: <814AE8AD-B027-4E6D-83B9-62111DADAA79@apple.com> On Mar 31, 2008, at 10:25 AM, Anders F Bj?rklund wrote: > chroot was discussed last year, but somewhat discarded as overkill > compared to trace mode and flexible logging... I updated the chroot > scripts from OpenDarwin to install Tiger instead, but there never > was a "minimum footprint" decided so it installed most of it - or > about 4 GB in total. (this was when installed from the Mac OS X + > Xcode Tools installation packages, before any pruning) As Paul and I discussed a number of times, "trace mode" could indeed effectively simulate a chroot by confining all reads/stats to a specific namespace (which, presumably, would be defined by a "target" configuration file somewhere) and redirecting all open-for-write requests to a scratch location, possibly with copy-on-write semantics if that becomes necessary. Sounds like an excellent GSOC project. ;-) - Jordan From nick at recoil.org Mon Mar 31 16:24:56 2008 From: nick at recoil.org (Nick Ludlam) Date: Mon Mar 31 16:23:58 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> Message-ID: <76E6D499-AB3F-4881-AF4F-B07C13B34FEE@recoil.org> Speaking as someone who's applied, and is awaiting a response on whether I'll be allowed to take over an existing port, I'm sure that new committer blood is out here. However, I'm still awaiting a reply. How many people process the commit requests at the moment? I'm not chasing up, as I've spoken to jmmp on IRC, but it's more of a general observation/query about the system as it stands. nick On 31 Mar 2008, at 17:14, Jordan K. Hubbard wrote: > There are two few committers for dports/ and REALLY very few > committers for base/ - I think we should be more liberal in allowing > new committers, being ever mindful of the fact that source control > always means you can back things out (and, as we grow, I think it's > also important to be flexible about that during/because of any > dispute). > > - Jordan > > On Mar 31, 2008, at 3:42 AM, Florian Ebeling wrote: > >>> I updated the pike Portfile five days ago, but the ticket hasn't >>> been >>> processed yet. Could you commit the changes for me since I have no >>> commit >>> rights myself? >> >> I come to the impression that there are too few committers. What do >> others think on this? And how many are there currently, anyway? >> >> Florian >> From guido.soranzio at gmail.com Mon Mar 31 19:32:27 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Mon Mar 31 19:31:30 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <47F116FB.6080303@macports.org> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> Message-ID: <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> On Mar 31, 2008, at 6:53 PM, Rainer M?ller wrote: > >> On trunk several pieces of Gnome 2.22 have been already committed >> sparsely without coordination: almost a nightmare. > > Why is this a nightmare? Gnome ports got no maintainer, so others did > what they could. So did I: as I said, I am trying to rebuild gnome 2.22 from scratch by applying the dependency chains suggested by garnome and jhbuild one by one: http://svn.gnome.org/viewvc/garnome/trunk/ http://svn.gnome.org/viewvc/jhbuild/trunk/modulesets/ There is no coherency in how the dependencies are expressed in MacPorts at the moment: some ports lists all the dependencies recursively while other ones limit to list only their direct dependencies, as garnome and jhbuild do the right way. This is a mess. If we had some simple tools like a buildbot or some "bulk" scripts like NetBSD's pkgsrc, the committers could automatically upload a report listing the packages that they already succeeded in building and the broken ones that they couldn't upload into their open repository. The other contributors could easily step up and help to spot the bug stopping the build process by testing directly the uploaded binaries in a few minutes and not hours. I committed poppler 0.8.0 and it seems that I broke evince. If I had access to the binary builds that other committers made available, I could check instantly if I had broken also Gimp and Inkscape, instead of having to recompile them for hours. I had to recompile boost for hours to check why Inkscape was warning about missing headers: if a binary of boost was made kindly available by some other MacPorts nice guy, I could test easily that issue by grabbing his packages from the "community" repository. Now I am stopped at trying to create a new "gnome-settings-daemon" but it is a difficult task because someone committed already the unstable version of gnome-control-center 2.21, while other committers already built some packages from the Gnome 2.22 stable branch, which shouldn't have be done in advance without testing the new features required at the base. I have to rebuild all that stuff again by myself, which could be easily avoided if I could have a look at some build logs made available by a buildbot or by other people sharing them. -Guido From dgou at mac.com Mon Mar 31 20:06:13 2008 From: dgou at mac.com (Douglas Philips) Date: Mon Mar 31 20:05:21 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> Message-ID: <64D95D6C-BB20-4CF8-B91B-BDBB1CCE8699@mac.com> On 2008 Mar 31, at 10:32 PM, Guido Soranzio wrote: > > On Mar 31, 2008, at 6:53 PM, Rainer M?ller wrote: >> >>> On trunk several pieces of Gnome 2.22 have been already committed >>> sparsely without coordination: almost a nightmare. >> >> Why is this a nightmare? Gnome ports got no maintainer, so others did >> what they could. > > So did I: as I said, I am trying to rebuild gnome 2.22 from scratch > by applying the dependency chains suggested by garnome and jhbuild Take a look at the dependencies on gnome-doc-utils. scrollkeeper and rarian are duking it out. Depending on which port you ask, either gnome-doc-utils depends on scrollkeeper or rarian, and they are mutually exclusive. I'm 1000% percent behind getting a buildbot system set up, though I don't have any host on-line consistently enough to be the buildmaster. I can offer a 1.5Ghz ppc 10.4 system to be a client for about 12-15 hours a day during the week, and probably 8-10 hours a day over the weekends. --Doug From jkh at apple.com Mon Mar 31 21:46:17 2008 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon Mar 31 21:46:47 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> Message-ID: On Mar 31, 2008, at 7:32 PM, Guido Soranzio wrote: > There is no coherency in how the dependencies are expressed in > MacPorts at the moment: some ports lists all the dependencies > recursively while other ones limit to list only their direct > dependencies, as garnome and jhbuild do the right way. > > This is a mess. If we had some simple tools like a buildbot or some > "bulk" scripts like NetBSD's pkgsrc, the committers could > automatically upload a report listing the packages that they already > succeeded in building and the broken ones that they couldn't upload > into their open repository. Well, let's also be careful not to conflate multiple, desirable goals here - that only increases the size of the task and the attendant risk of seeing nothing happen. History suggests that people tend to run away from large problems in this project. :-) First goal: Make it possible to batch build the entire ports collection, port by port, on a carefully configured machine, spitting out consistent (machine-parseable) diagnostics along the way. Metrics for success: Someone with a comparatively beefy XServe and attached RAID system is able to build the entire ports collection from top to bottom and deliver an initial matrix report of what ports failed and why. Second goal: Do a "lessons learned" assessment of the first goal and use it to polish the batch build infrastructure to the point where it can be moved to a more official buildbot machine. Metrics for success: Buildbot is up and running, with one or more automated web status pages providing concise summaries of overall "port collection health" as well as individual results for each port, similar in scope to http://portsmon.freebsd.org and http://pointyhat.freebsd.org but hopefully more concise. Third goal: Extend the buildbot slightly to generate full packages (of some variety) as a side-effect of the now already scheduled runs. Add some automation to scrape the resulting packages into some globally accessible location and extend the port machinery to make it possible to satisfy dependencies via package as well as via port install. Metrics for success: MacPorts now boasts a packages collection, similar in size and scope to that of other projects, which can also be used transparently by both users and developers. The "port install" target no longer actually installs bits on the target system, but rather becomes the internal equivalent of "port destroot foo; port package foo; package- install foo" A suitable command-and-control GUI should also exist by this point which provides a convenient interface to the packages collection. So, here's the deal. If you'd like to tackle the first goal, I can be the guy with the XServe + RAID to run the results on until the metrics for success have been achieved. :-) - Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080331/65c29456/attachment.html From guido.soranzio at gmail.com Mon Mar 31 23:53:59 2008 From: guido.soranzio at gmail.com (Guido Soranzio) Date: Mon Mar 31 23:53:04 2008 Subject: Ticket #14796 (pike): please commit In-Reply-To: References: <20CE10E5-C0E6-45A0-BFD2-C88DDF004801@gmx.de> <5cbbe4ae0803310342m66466feck25e579e27d85801@mail.gmail.com> <26120BAD-1D40-43FC-AE32-59F0A593C8AB@gmail.com> <47F0E44B.3040106@macports.org> <47F0EF3F.6090906@macports.org> <2DCB801D-F129-478D-828E-5C4CBD8707AB@gmail.com> <47F116FB.6080303@macports.org> <7278F51E-D2FF-4100-9C03-5AA0968E9FCC@gmail.com> Message-ID: <9B91E8F7-35AC-49BC-8633-14C2948777D4@gmail.com> On Apr 1, 2008, at 6:46 AM, Jordan K. Hubbard wrote: > Well, let's also be careful not to conflate multiple, desirable > goals here - that only increases the size of the task and the > attendant risk of seeing nothing happen. My initial propose was very simple and pragmatic, indeed. We don't have a central building machine, we don't have binary packages, we have difficulties in testing universal packages. But we have an "archive mode", we can produce packages, we can temporarily create a symbolic link to switch off /opt/local/sandbox. If you are a commiter or even a simple user that has spent hours while building a MacPorts subtree from scratch, please share it with us, so we can speed up the commits by the currently few volunteers. Do you have the latest Monodevelop compiled for Quartz or Carbon, an advanced scientific software packaged from SourceForge into /opt/local, an optimized Blender 3D? Please upload your archives so we can commit the new patches starting from there. I had to build for hours the latest LAMP server, GCC, boost, qt4-mac, GStremer codecs, WebKit, gnome 2.22 from scratch only in order to test the uncountable untested broken ports. It took me days to build them after assuring that I was using the latest available versions: other users/committers could make use of my GBs of precompiled binaries. Benjamin Reed from the Fink project is offering his 3 GB builds of KDE by using BitTorrent: that's a simple and effective initiative based on DMGs which even developers can benefits from. We have already the well-made free Porticus GUI and we have already the new sqlite receipt database engine in Leopard's Apple InstallerPackageMaker: we only need pkgutils to fully support --unlink, reference counting and dependency analysis. But even if pkgutil was hosted on MacOSForge, probably it would ignore MacPorts like the Xquartz, ZFS, MacRuby and WebKit projects are doing now, even if they are technically real "Mac ports"! - Guido