From ryandesign at macports.org Mon Dec 1 01:19:29 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 1 Dec 2008 03:19:29 -0600 Subject: No default port source specified in /mp/etc/macports/sources.conf In-Reply-To: <20081201074034.GK722@ninagal.withay.com> References: <9CF3E16B-A901-4061-B61C-572A265F7FBC@macports.org> <20081201074034.GK722@ninagal.withay.com> Message-ID: <0A72AFBA-F11C-4286-9A6A-05CFA7BF2389@macports.org> On Dec 1, 2008, at 01:40, Bryan Blackburn wrote: > On Mon, Dec 01, 2008 at 01:14:16AM -0600, Ryan Schmidt said: > >> On Dec 1, 2008, at 00:43, Ryan Schmidt wrote: >> >>> On Dec 1, 2008, at 00:29, Ryan Schmidt wrote: >>> >>>> I tried updating my MacPorts trunk base just now (r42837) and got >>>> this: >>>> >>>> >>>> ===> making install in src/programs/daemondo >>>> /usr/bin/install -c -o rschmidt -g admin -m 555 build/daemondo /mp/ >>>> bin >>>> /usr/bin/install -c -o rschmidt -g admin -m 444 setupenv.bash /mp/ >>>> share/macports/ >>>> /usr/bin/tclsh src/upgrade_sources_conf_default.tcl /mp >>>> /usr/bin/tclsh src/dep_map_clean.tcl /mp/Library/Tcl >>>> No default port source specified in /mp/etc/macports/sources.conf >>>> while executing >>>> "mportinit" >>>> (file "src/dep_map_clean.tcl" line 12) >>>> make: *** [install] Error 1 >>>> >>>> >>>> The only non-comment line in my sources.conf is: >>>> >>>> file:///Users/rschmidt/macports/dports >>>> >>>> So it does not have anything in brackets after the URL. >>> >>> And the port command doesn't work either now: >>> >>> $ port >>> No default port source specified in /mp/etc/macports/sources.conf >>> while executing >>> "mportinit ui_options global_options global_variations" >>> Error: /mp/bin/port: Failed to initialize MacPorts, No default port >>> source specified in /mp/etc/macports/sources.conf >>> $ >>> >>> Is there supposed to be code that changes my sources.conf to >>> designate >>> one as a default? > > Yes, base/src/upgrade_sources_conf_default.tcl does this. However > there are > a few cases where it is/was failing. The above source you used, > file:///Users/rschmidt/macports/dports, is that an svn-checkout? > If so, is > the URL for it at svn.macosforge.org instead of macports.org (use > 'svn info > /Users/rschmidt/macports/dports' to see)? If so, I'm working on > fixing that > at the moment. Yes it was a Subversion working copy from svn.macosforge.org, and your fix worked, thanks! >> On another machine, on which I have multiple MacPorts installs >> sharing a >> sources.conf, "[default]" appears to have been added by something. >> Because >> I updated one install, and then the other said: >> >> $ port sync >> Warning: /mp/etc/macports/sources.conf source 'file:///Volumes/data/ >> macports/ports [default]' specifies invalid flag 'default' >> Error: Synchronization of the local ports tree failed doing an svn >> update >> port sync failed: Synchronization of 1 source(s) failed >> $ >> >> And sources.conf does (now) have "[default]" at the end of the one >> non-comment line. > > Did this sources.conf have a tag already, most likely [nosync] in > it? That > was fixed in r42734 for trunk and r42736 for 1.7 branch, to use the > correct > '[nosync,default]' instead of '[nosync] [default]'. No, it had no existing tags. But it was a working copy from svn.macports.org. That explains it! From blb at macports.org Mon Dec 1 01:39:07 2008 From: blb at macports.org (Bryan Blackburn) Date: Mon, 1 Dec 2008 02:39:07 -0700 Subject: No default port source specified in /mp/etc/macports/sources.conf In-Reply-To: <0A72AFBA-F11C-4286-9A6A-05CFA7BF2389@macports.org> References: <9CF3E16B-A901-4061-B61C-572A265F7FBC@macports.org> <20081201074034.GK722@ninagal.withay.com> <0A72AFBA-F11C-4286-9A6A-05CFA7BF2389@macports.org> Message-ID: <20081201093907.GL722@ninagal.withay.com> On Mon, Dec 01, 2008 at 03:19:29AM -0600, Ryan Schmidt said: [...] > > Yes it was a Subversion working copy from svn.macosforge.org, and your fix > worked, thanks! Good to know, as of r42848 macports.org and macosforge.org should work for svn, and macports.org and darwinports.org for rsync (the latter just in case, since rsync.darwinports.org is still just CNAME'd to rsync.macosforge.org). It would appear that rsync.macosforge.org was never used in sources.conf, so hopefully nobody uses that. > > >>> On another machine, on which I have multiple MacPorts installs >>> sharing a >>> sources.conf, "[default]" appears to have been added by something. >>> Because >>> I updated one install, and then the other said: >>> >>> $ port sync >>> Warning: /mp/etc/macports/sources.conf source 'file:///Volumes/data/ >>> macports/ports [default]' specifies invalid flag 'default' >>> Error: Synchronization of the local ports tree failed doing an svn >>> update >>> port sync failed: Synchronization of 1 source(s) failed >>> $ >>> >>> And sources.conf does (now) have "[default]" at the end of the one >>> non-comment line. >> >> Did this sources.conf have a tag already, most likely [nosync] in it? >> That >> was fixed in r42734 for trunk and r42736 for 1.7 branch, to use the >> correct >> '[nosync,default]' instead of '[nosync] [default]'. > > No, it had no existing tags. But it was a working copy from > svn.macports.org. That explains it! Ah, so this machine is sharing a sources.conf between multiple versions of MacPorts, at least one being prior to 1.7b1 then? I wonder if we should update base to ignore unknown tags, maybe just warning, so this won't be an issue in the future? Bryan From raimue at macports.org Mon Dec 1 02:20:56 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 01 Dec 2008 11:20:56 +0100 Subject: No default port source specified in /mp/etc/macports/sources.conf In-Reply-To: <9CF3E16B-A901-4061-B61C-572A265F7FBC@macports.org> References: <9CF3E16B-A901-4061-B61C-572A265F7FBC@macports.org> Message-ID: <4933BA88.3070704@macports.org> Ryan Schmidt wrote: > On Dec 1, 2008, at 00:43, Ryan Schmidt wrote: > >> On Dec 1, 2008, at 00:29, Ryan Schmidt wrote: >> >>> I tried updating my MacPorts trunk base just now (r42837) and got >>> this: >>> >>> >>> ===> making install in src/programs/daemondo >>> /usr/bin/install -c -o rschmidt -g admin -m 555 build/daemondo /mp/ >>> bin >>> /usr/bin/install -c -o rschmidt -g admin -m 444 setupenv.bash /mp/ >>> share/macports/ >>> /usr/bin/tclsh src/upgrade_sources_conf_default.tcl /mp >>> /usr/bin/tclsh src/dep_map_clean.tcl /mp/Library/Tcl >>> No default port source specified in /mp/etc/macports/sources.conf >>> while executing >>> "mportinit" >>> (file "src/dep_map_clean.tcl" line 12) >>> make: *** [install] Error 1 >>> >>> >>> The only non-comment line in my sources.conf is: >>> >>> file:///Users/rschmidt/macports/dports >>> >>> So it does not have anything in brackets after the URL. >> And the port command doesn't work either now: >> >> $ port >> No default port source specified in /mp/etc/macports/sources.conf >> while executing >> "mportinit ui_options global_options global_variations" >> Error: /mp/bin/port: Failed to initialize MacPorts, No default port >> source specified in /mp/etc/macports/sources.conf >> $ >> >> Is there supposed to be code that changes my sources.conf to >> designate one as a default? > > On another machine, on which I have multiple MacPorts installs > sharing a sources.conf, "[default]" appears to have been added by > something. Because I updated one install, and then the other said: > > $ port sync > Warning: /mp/etc/macports/sources.conf source 'file:///Volumes/data/ > macports/ports [default]' specifies invalid flag 'default' > Error: Synchronization of the local ports tree failed doing an svn > update > port sync failed: Synchronization of 1 source(s) failed > $ This is just a warning, so it is not the real reason why it failed. Unknown flags are ignored with a warning. Please run 'port -d sync' and check svn_path in /Library/Tcl/macports1.0/macports_autoconf.tcl (or whatever you used for --with-tclpackage). Most probably svn_path is set to "/usr/bin/svn" triggering the "Please get a newer Subversion client" message. This is #15868 [1] and scheduled to be fixed in 1.7.1. Rainer [1] http://trac.macports.org/ticket/15868 From ryandesign at macports.org Mon Dec 1 02:44:06 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 1 Dec 2008 04:44:06 -0600 Subject: No default port source specified in /mp/etc/macports/sources.conf In-Reply-To: <4933BA88.3070704@macports.org> References: <9CF3E16B-A901-4061-B61C-572A265F7FBC@macports.org> <4933BA88.3070704@macports.org> Message-ID: On Dec 1, 2008, at 04:20, Rainer M?ller wrote: > Ryan Schmidt wrote: > >> On another machine, on which I have multiple MacPorts installs >> sharing a sources.conf, "[default]" appears to have been added by >> something. Because I updated one install, and then the other said: >> >> $ port sync >> Warning: /mp/etc/macports/sources.conf source 'file:///Volumes/data/ >> macports/ports [default]' specifies invalid flag 'default' >> Error: Synchronization of the local ports tree failed doing an svn >> update >> port sync failed: Synchronization of 1 source(s) failed >> $ > > This is just a warning, so it is not the real reason why it failed. > Unknown flags are ignored with a warning. > > Please run 'port -d sync' and check svn_path in > /Library/Tcl/macports1.0/macports_autoconf.tcl (or whatever you > used for > --with-tclpackage). > > Most probably svn_path is set to "/usr/bin/svn" triggering the "Please > get a newer Subversion client" message. This is #15868 [1] and > scheduled > to be fixed in 1.7.1. That's not relevant; this is on Tiger which has no /usr/bin/svn. We've figured the issue out and it's fixed in trunk; see my last message. From jmr at macports.org Mon Dec 1 03:52:14 2008 From: jmr at macports.org (Joshua Root) Date: Mon, 01 Dec 2008 22:52:14 +1100 Subject: [MacPorts] UsingMacPortsQuickStart modified In-Reply-To: <5EE88B08-9B65-406D-BF4A-8D38686BE67F@macports.org> References: <20081130211835.8FE342802F@relay14.apple.com> <5EE88B08-9B65-406D-BF4A-8D38686BE67F@macports.org> Message-ID: <4933CFEE.9050504@macports.org> Ryan Schmidt wrote: > On Nov 30, 2008, at 15:17, MacPorts wrote: > >> `sudo port upgrade outdated` >> >> -(you can add the `-v` flag following "port" in the above command if >> you'd like to watch the compiler output). >> +To upgrade all outdated ports and their dependencies: >> + >> +`sudo port upgrade -R outdated` >> + >> +(You can add the "`-v`" flag following "`port`" in the above commands >> if you'd like to watch the compiler output.) > > Do we really want to advise users, in the quick-start guide, to use the > -R option, which, according to multiple reports, doesn't work so great? We certainly don't want to encourage them to use it in the given example, where it's completely useless. - Josh From ryandesign at macports.org Mon Dec 1 12:54:15 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 1 Dec 2008 14:54:15 -0600 Subject: No default port source specified in /mp/etc/macports/sources.conf In-Reply-To: References: <9CF3E16B-A901-4061-B61C-572A265F7FBC@macports.org> <4933BA88.3070704@macports.org> Message-ID: <0D88624F-E746-48DC-A742-9A9467FAF226@macports.org> On Dec 1, 2008, at 04:44, Ryan Schmidt wrote: > On Dec 1, 2008, at 04:20, Rainer M?ller wrote: > >> Ryan Schmidt wrote: >> >>> On another machine, on which I have multiple MacPorts installs >>> sharing a sources.conf, "[default]" appears to have been added by >>> something. Because I updated one install, and then the other said: >>> >>> $ port sync >>> Warning: /mp/etc/macports/sources.conf source 'file:///Volumes/data/ >>> macports/ports [default]' specifies invalid flag 'default' >>> Error: Synchronization of the local ports tree failed doing an svn >>> update >>> port sync failed: Synchronization of 1 source(s) failed >>> $ >> >> This is just a warning, so it is not the real reason why it failed. >> Unknown flags are ignored with a warning. >> >> Please run 'port -d sync' and check svn_path in >> /Library/Tcl/macports1.0/macports_autoconf.tcl (or whatever you >> used for >> --with-tclpackage). >> >> Most probably svn_path is set to "/usr/bin/svn" triggering the >> "Please >> get a newer Subversion client" message. This is #15868 [1] and >> scheduled >> to be fixed in 1.7.1. > > That's not relevant; this is on Tiger which has no /usr/bin/svn. > We've figured the issue out and it's fixed in trunk; see my last > message. To clarify: By way of the above warning message, I was just pointing out that "[default]" did get added to sources.conf on this machine where it didn't on the other. And we found out why that was -- the working copies were from different hostnames. And you're right, the reason "port sync" failed was unrelated. From blb at macports.org Mon Dec 1 14:16:03 2008 From: blb at macports.org (Bryan Blackburn) Date: Mon, 1 Dec 2008 15:16:03 -0700 Subject: [42862] trunk/dports/lang/gst/Portfile In-Reply-To: <20081201180622.5AFE37D7A62@beta.macosforge.org> References: <20081201180622.5AFE37D7A62@beta.macosforge.org> Message-ID: <20081201221603.GG651@ninagal.withay.com> On Mon, Dec 01, 2008 at 10:06:22AM -0800, saispo at macports.org said: > Revision: 42862 > http://trac.macports.org/changeset/42862 > Author: saispo at macports.org > Date: 2008-12-01 10:06:21 -0800 (Mon, 01 Dec 2008) > Log Message: > ----------- > Upgrade port to gst v3.1 > > Modified Paths: > -------------- > trunk/dports/lang/gst/Portfile > > Modified: trunk/dports/lang/gst/Portfile [...] > -maintainers landonf openmaintainer > +maintainers saispo at macports.org Did you mean to drop Landon as a maintainer? Bryan [...] From frstan at bellsouth.net Mon Dec 1 14:46:13 2008 From: frstan at bellsouth.net (William Davis) Date: Mon, 1 Dec 2008 17:46:13 -0500 Subject: [MacPorts] UsingMacPortsQuickStart modified In-Reply-To: <5EE88B08-9B65-406D-BF4A-8D38686BE67F@macports.org> References: <20081130211835.8FE342802F@relay14.apple.com> <5EE88B08-9B65-406D-BF4A-8D38686BE67F@macports.org> Message-ID: <9CE9C77D-6D78-4B15-AF3B-0D88ABACA18D@bellsouth.net> On Dec 1, 2008, at 12:39 AM, Ryan Schmidt wrote: > On Nov 30, 2008, at 15:17, MacPorts wrote: > >> `sudo port upgrade outdated` >> >> -(you can add the `-v` flag following "port" in the above command >> if you'd like to watch the compiler output). >> +To upgrade all outdated ports and their dependencies: >> + >> +`sudo port upgrade -R outdated` >> + >> +(You can add the "`-v`" flag following "`port`" in the above >> commands if you'd like to watch the compiler output.) > > Do we really want to advise users, in the quick-start guide, to use > the -R option, which, according to multiple reports, doesn't work so > great? > It has been alleged that the -R option works as it should in version 1.7 ....... William Davis frstanATbellsouthDOTnet Mac OS X.5.5 Darwin 9.5.0 XQuartz 2.3.2_rc2 (xorg-server 1.4.2-apple25) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From andrea.damore at macports.org Tue Dec 2 07:27:13 2008 From: andrea.damore at macports.org (Andrea D'Amore) Date: Tue, 2 Dec 2008 16:27:13 +0100 Subject: Install Order In-Reply-To: <53370062-6682-455E-9632-2968554E86B8@voidfx.net> References: <493317C4.4060100@codingfarm.de> <53370062-6682-455E-9632-2968554E86B8@voidfx.net> Message-ID: <12F819A8-301E-45E5-880E-706409C163AD@macports.org> On 30/nov/08, at 23:50, Neil wrote: > Does MacPorts keep track of which ports were installed explicitly > and which were installed as deps? If I'm not wrong you're searching for something that is for macports what deborphan is for apt, I think a little scripting trough installed pseudo-port should and then a little parsing could do it. By the way the "steps" you're referring to are already called phases in macports slang, check The Guide*. Regards Andrea *DON'T PANIC From jeremyhu at macports.org Tue Dec 2 13:03:39 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Tue, 2 Dec 2008 13:03:39 -0800 Subject: noob question: can't find a new port Message-ID: <162297B2-851E-407F-B05A-E2DD9A6E3D6A@macports.org> This is a bit of a noob question, and I'm sure it's buried in documentation somewhere, but I didn't see it... I'm trying to test a new port which isn't committed yet that has a dependency on a just- committed port... but it's not finding it. Am I missing a step? Thanks, Jeremy ~/src/macports/trunk/dports/x11/xorg-libXext $ sudo port -v install ---> Installing xorg-libXext @1.0.4_0+universal ---> Activating xorg-libXext @1.0.4_0+universal ---> Cleaning xorg-libXext ---> Removing build directory for xorg-libXext ~/src/macports/trunk/dports/x11/xorg-libXext $ cd .. ~/src/macports/trunk/dports/x11 $ svn add xorg-libXext/ A xorg-libXext A xorg-libXext/Portfile ~/src/macports/trunk/dports/x11 $ cd xorg-libXext ~/src/macports/trunk/dports/x11/xorg-libXext $ svn ci -m "New port: xorg-libXext" Adding xorg-libXext Adding xorg-libXext/Portfile Transmitting file data . Committed revision 42951. ~/src/macports/trunk/dports/x11/xorg-libXext $ cd ../xorg-libAppleWM/ ~/src/macports/trunk/dports/x11/xorg-libAppleWM $ sudo port -v install Error: Dependency 'xorg-libXext' not found. Error: Status 1 encountered during processing. From ryandesign at macports.org Tue Dec 2 13:05:41 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 2 Dec 2008 15:05:41 -0600 Subject: [42951] trunk/dports/x11 In-Reply-To: <20081202205710.8AC727F4E04@beta.macosforge.org> References: <20081202205710.8AC727F4E04@beta.macosforge.org> Message-ID: On Dec 2, 2008, at 14:57, jeremyhu at macports.org wrote: > Revision: 42951 > http://trac.macports.org/changeset/42951 > Author: jeremyhu at macports.org > Date: 2008-12-02 12:57:09 -0800 (Tue, 02 Dec 2008) > Log Message: > ----------- > New port: xorg-libXext > > Added Paths: > ----------- > trunk/dports/x11/xorg-libXext/ > trunk/dports/x11/xorg-libXext/Portfile > > Added: trunk/dports/x11/xorg-libXext/Portfile > =================================================================== > --- trunk/dports/x11/xorg-libXext/Portfile > (rev 0) > +++ trunk/dports/x11/xorg-libXext/Portfile 2008-12-02 20:57:09 UTC > (rev 42951) > @@ -0,0 +1,26 @@ > +# $Id$ > + > +PortSystem 1.0 > + > +name xorg-libXext > +version 1.0.4 > +categories x11 devel > +maintainers jeremyhu > +description X.org libAppleWM Wait, this is the port for libXext, right? not libAppleWM? From jmr at macports.org Tue Dec 2 13:11:39 2008 From: jmr at macports.org (Joshua Root) Date: Wed, 03 Dec 2008 08:11:39 +1100 Subject: noob question: can't find a new port In-Reply-To: <162297B2-851E-407F-B05A-E2DD9A6E3D6A@macports.org> References: <162297B2-851E-407F-B05A-E2DD9A6E3D6A@macports.org> Message-ID: <4935A48B.6000502@macports.org> Jeremy Huddleston wrote: > This is a bit of a noob question, and I'm sure it's buried in > documentation somewhere, but I didn't see it... I'm trying to test a > new port which isn't committed yet that has a dependency on a > just-committed port... but it's not finding it. Am I missing a step? > > Thanks, > Jeremy > > ~/src/macports/trunk/dports/x11/xorg-libXext $ sudo port -v install > > ---> Installing xorg-libXext @1.0.4_0+universal > ---> Activating xorg-libXext @1.0.4_0+universal > ---> Cleaning xorg-libXext > ---> Removing build directory for xorg-libXext > > ~/src/macports/trunk/dports/x11/xorg-libXext $ cd .. > ~/src/macports/trunk/dports/x11 $ svn add xorg-libXext/ > A xorg-libXext > A xorg-libXext/Portfile > ~/src/macports/trunk/dports/x11 $ cd xorg-libXext > ~/src/macports/trunk/dports/x11/xorg-libXext $ svn ci -m "New port: > xorg-libXext" > Adding xorg-libXext > Adding xorg-libXext/Portfile > Transmitting file data . > Committed revision 42951. > > ~/src/macports/trunk/dports/x11/xorg-libXext $ cd ../xorg-libAppleWM/ > ~/src/macports/trunk/dports/x11/xorg-libAppleWM $ sudo port -v install > Error: Dependency 'xorg-libXext' not found. > Error: Status 1 encountered during processing. It hasn't reached the PortIndex yet (regenerated every hour if needed). You can regenerate it yourself with the portindex command if you want (but watch out for conflicts when updating). - Josh From jeremyhu at macports.org Tue Dec 2 13:24:49 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Tue, 2 Dec 2008 13:24:49 -0800 Subject: [42951] trunk/dports/x11 In-Reply-To: References: <20081202205710.8AC727F4E04@beta.macosforge.org> Message-ID: <69BAF9F3-FAE7-44C6-AFA8-CB7337A5B7E8@macports.org> Yeah, thanks. That was a missed copy/paste correction. I'll fix the description now ;) --Jeremy On Dec 2, 2008, at 13:05, Ryan Schmidt wrote: > > On Dec 2, 2008, at 14:57, jeremyhu at macports.org wrote: > >> Revision: 42951 >> http://trac.macports.org/changeset/42951 >> Author: jeremyhu at macports.org >> Date: 2008-12-02 12:57:09 -0800 (Tue, 02 Dec 2008) >> Log Message: >> ----------- >> New port: xorg-libXext >> >> Added Paths: >> ----------- >> trunk/dports/x11/xorg-libXext/ >> trunk/dports/x11/xorg-libXext/Portfile >> >> Added: trunk/dports/x11/xorg-libXext/Portfile >> =================================================================== >> --- trunk/dports/x11/xorg-libXext/Portfile >> (rev 0) >> +++ trunk/dports/x11/xorg-libXext/Portfile 2008-12-02 20:57:09 UTC >> (rev 42951) >> @@ -0,0 +1,26 @@ >> +# $Id$ >> + >> +PortSystem 1.0 >> + >> +name xorg-libXext >> +version 1.0.4 >> +categories x11 devel >> +maintainers jeremyhu >> +description X.org libAppleWM > > Wait, this is the port for libXext, right? not libAppleWM? > > From ryandesign at macports.org Tue Dec 2 14:41:11 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 2 Dec 2008 16:41:11 -0600 Subject: noob question: can't find a new port In-Reply-To: <4935A48B.6000502@macports.org> References: <162297B2-851E-407F-B05A-E2DD9A6E3D6A@macports.org> <4935A48B.6000502@macports.org> Message-ID: <413A1586-3F6D-44DF-900A-A543DD98D0EF@macports.org> On Dec 2, 2008, at 15:11, Joshua Root wrote: > Jeremy Huddleston wrote: > >> This is a bit of a noob question, and I'm sure it's buried in >> documentation somewhere, but I didn't see it... I'm trying to test a >> new port which isn't committed yet that has a dependency on a >> just-committed port... but it's not finding it. Am I missing a step? > > It hasn't reached the PortIndex yet (regenerated every hour if > needed). > You can regenerate it yourself with the portindex command if you want And note that you need to be in the dports directory when you issue the portindex command for it to work. cd $(port dir MacPorts)/../.. portindex On my machine the portindex command takes about 8 minutes to run, which is a bit annoying. > (but watch out for conflicts when updating). For this reason, I define my own "port sync" command which first reverts the PortIndex, in case I've made any modifications, then does the svn update. Simplified a bit from what's in my .bash_profile: port() { case "$1" in sync) PORTS_DIR=$(cd $(command port dir MacPorts)/../.. && pwd) svn revert ${PORTS_DIR}/PortIndex | sed s%${PORTS_DIR}/%% svn update ${PORTS_DIR} | sed s%${PORTS_DIR}/%% ;; *) command port "$@" ;; esac } From ryandesign at macports.org Tue Dec 2 17:25:15 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 2 Dec 2008 19:25:15 -0600 Subject: [42968] trunk/dports/audio/twolame In-Reply-To: <20081203003750.12E307F9013@beta.macosforge.org> References: <20081203003750.12E307F9013@beta.macosforge.org> Message-ID: <4BD62F4B-673A-4152-941D-0388E34FABC3@macports.org> On Dec 2, 2008, at 18:37, blb at macports.org wrote: > Revision: 42968 > http://trac.macports.org/changeset/42968 > Author: blb at macports.org > Date: 2008-12-02 16:37:49 -0800 (Tue, 02 Dec 2008) > Log Message: > ----------- > audio/twolame - make sure that, when building, it picks up its current > headers and not those from an older, still-active install (#17483) > Neat! Can we fix cyrus-sasl2 in the same way? From ryandesign at macports.org Tue Dec 2 18:12:27 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 2 Dec 2008 20:12:27 -0600 Subject: [42862] trunk/dports/lang/gst/Portfile In-Reply-To: <20081201221603.GG651@ninagal.withay.com> References: <20081201180622.5AFE37D7A62@beta.macosforge.org> <20081201221603.GG651@ninagal.withay.com> Message-ID: <50ECB78B-1099-4047-8928-97214D1DD30F@macports.org> On Dec 1, 2008, at 16:16, Bryan Blackburn wrote: > On Mon, Dec 01, 2008 at 10:06:22AM -0800, saispo at macports.org said: > >> Revision: 42862 >> http://trac.macports.org/changeset/42862 >> Author: saispo at macports.org >> Date: 2008-12-01 10:06:21 -0800 (Mon, 01 Dec 2008) >> Log Message: >> ----------- >> Upgrade port to gst v3.1 >> >> Modified Paths: >> -------------- >> trunk/dports/lang/gst/Portfile >> >> Modified: trunk/dports/lang/gst/Portfile > [...] >> -maintainers landonf openmaintainer >> +maintainers saispo at macports.org > > Did you mean to drop Landon as a maintainer? I noticed that too, and also this: >> +default_variants +gtk +tcltk >> + >> +variant gtk { >> + depends_lib-append port:gtk2 >> + configure.args-append --enable-gtk >> +} >> + >> +variant tcltk { >> + depends_lib-append port:tcl port:tk >> + configure.args-append --with-tk --with-tcl >> +} >> + >> +variant nox conflicts gtk conflicts tk { >> + configure.args-append \ >> + --without-x \ >> + --disable-gtk \ >> + --without-tk \ >> + --without-tcl >> +} The variant to disable X11 support should be called no_x11, not nox. The nox variant is marked as conflicting with tk but there is no valiant called tk. Did you mean tcltk? You shouldn't use the conflicts word twice in a single variant declaration; just list all the conflicting variants after the word "conflicts". gtk and tcltk should only be made the defaults if the user has not already chosen to disable X11. Attached is my initial pass at fixing this. However there remain these questions: What is the relationship between these variants? Is there ever a case when one would want to disable the gtk or tcltk variants? If so, it will be difficult for a user to do so, due to a long-standing MacPorts base bug which makes it so that if you install a port with negative variants (sudo port install gst -gtk -tcltk) and then upgrade it (sudo port upgrade gst), the deselected variants will be added again. Perhaps the variants should be changed to no_gtk and no_tcltk. Is there ever a case when a user would want to select neither gtk nor tcltk nor no_x11? Also, the variants need descriptions. -------------- next part -------------- A non-text attachment was scrubbed... Name: gst.diff Type: application/octet-stream Size: 1493 bytes Desc: not available URL: From blb at macports.org Tue Dec 2 18:42:27 2008 From: blb at macports.org (Bryan Blackburn) Date: Tue, 2 Dec 2008 19:42:27 -0700 Subject: [42968] trunk/dports/audio/twolame In-Reply-To: <4BD62F4B-673A-4152-941D-0388E34FABC3@macports.org> References: <20081203003750.12E307F9013@beta.macosforge.org> <4BD62F4B-673A-4152-941D-0388E34FABC3@macports.org> Message-ID: <20081203024227.GE11240@ninagal.withay.com> On Tue, Dec 02, 2008 at 07:25:15PM -0600, Ryan Schmidt said: > > On Dec 2, 2008, at 18:37, blb at macports.org wrote: > >> Revision: 42968 >> http://trac.macports.org/changeset/42968 >> Author: blb at macports.org >> Date: 2008-12-02 16:37:49 -0800 (Tue, 02 Dec 2008) >> Log Message: >> ----------- >> audio/twolame - make sure that, when building, it picks up its current >> headers and not those from an older, still-active install (#17483) >> > > Neat! Can we fix cyrus-sasl2 in the same way? Perhaps, how is cyrus failing? If it's an issue of older headers being incompatible with the new version, then you need to make sure the local -I stuff (-I./include, -I../includes, whatever it may use) appears before -I${prefix}/include in Makefiles. If it's with libraries, I believe a similar tactic with -L will work. Otherwise, it depends. Bryan From blb at macports.org Tue Dec 2 18:51:39 2008 From: blb at macports.org (Bryan Blackburn) Date: Tue, 2 Dec 2008 19:51:39 -0700 Subject: 1.7.0 beta 1 tagged and ready to test In-Reply-To: References: <20081129084018.GA505@ninagal.withay.com> <493161DA.6060705@macports.org> <20081129211832.GC525@ninagal.withay.com> Message-ID: <20081203025139.GF11240@ninagal.withay.com> On Sun, Nov 30, 2008 at 11:15:28AM +0100, Anders F Bj?rklund said: > Bryan Blackburn wrote: > >> On Sun, Nov 30, 2008 at 02:38:02AM +1100, Joshua Root said: >>> Anders F Bj?rklund wrote: >>>> And it probably needs a MacPorts-1.7.0-beta1.dmg disk image >>>> made to see any real (i.e. end user) beta testing, though ? >>> >>> @jmpp: I don't see any tarballs or dmgs for older rc/beta releases. >>> Did >>> they never exist, or are they kept somewhere I'm not looking? >> >> I checked and as far as I could tell, dmg's have always only been >> released >> when a version was finalized; that's why I did this the same way, with >> the >> svn tag only for now. > > Some of the earlier "unofficial" tarballs are in > http://trac.macports.org/browser/distfiles/MacPorts/ > > But QA testing packagings should go somewhere else, > to clearly separate from the "release" versions... ? I was pondering just dumping it into /users/blb or similar, to denote the non-release status... > >> Though, given Anders' error, maybe we should add a step into the >> ReleaseProcess that at least a dmg should be built before tagging, to >> test >> for such things? > > Judging from MacPorts 1.6.0 dmg, probably a good idea. > > That the MacPorts installation doesn't respect any > chroot/DESTDIR and requires admin/root privileges > shouldn't stop the release, though, as it's mostly > something "wrong" and can be worked around / lived with. The DESTDIR support should now work as of r42978 (trunk) and r42979 (branch release_1_7). The root priv bit can be worked around with the --with-install-(user|group) switches to configure, but I don't know what kind of an effect that may have on the final install from DMG. Bryan > > At least that was the way it has been handled earlier. > > --anders From ryandesign at macports.org Tue Dec 2 21:10:38 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 2 Dec 2008 23:10:38 -0600 Subject: [42996] trunk/dports/x11/xinit In-Reply-To: <20081203045943.67D8C804DAD@beta.macosforge.org> References: <20081203045943.67D8C804DAD@beta.macosforge.org> Message-ID: <2D5A6935-D4EE-4067-9E10-AFD8DDA6975E@macports.org> On Dec 2, 2008, at 22:59, jeremyhu at macports.org wrote: > Revision: 42996 > http://trac.macports.org/changeset/42996 > Author: jeremyhu at macports.org > Date: 2008-12-02 20:59:42 -0800 (Tue, 02 Dec 2008) > Log Message: > ----------- > xinit: Version bump to 1.1.0 plus latest git updates for better > Tiger support [snip] > +post-destroot { > + system "mv ${destroot}/Library/LaunchAgents/org.x.startx.plist $ > {destroot}/Library/LaunchAgents/org.macports.startx.plist" > + system "mv ${destroot}/Library/LaunchDaemons/ > org.x.privileged_startx.plist ${destroot}/Library/LaunchDaemons/ > org.macports.privileged_startx.plist" > + > + system "mkdir ${destroot}/${prefix}/lib/X11/xinit/xinitrc.d" > + system "cp ${filespath}/xinitrc.d/*.sh ${destroot}/${prefix}/lib/ > X11/xinit/xinitrc.d" > + system "chmod 755 ${destroot}/${prefix}/lib/X11/xinit/xinitrc.d/ > *.sh" > +} FYI it's preferable to use built-in tcl commands rather than starting a new shell using "system" where possible. So here's how that would look: post-destroot { move ${destroot}/Library/LaunchAgents/org.x.startx.plist ${destroot}/ Library/LaunchAgents/org.macports.startx.plist move ${destroot}/Library/LaunchDaemons/org.x.privileged_startx.plist ${destroot}/Library/LaunchDaemons/org.macports.privileged_startx.plist xinstall -d ${destroot}${prefix}/lib/X11/xinit/xinitrc.d eval xinstall -m 755 [glob ${filespath}/xinitrc.d/*.sh] ${destroot}$ {prefix}/lib/X11/xinit/xinitrc.d } I think this is right, but I've just typed it in here and haven't tested it. Also note you shouldn't put a slash before ${prefix}; $ {prefix} begins with a slash already. From jeremyhu at macports.org Tue Dec 2 23:41:30 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Tue, 2 Dec 2008 23:41:30 -0800 Subject: [42996] trunk/dports/x11/xinit In-Reply-To: <2D5A6935-D4EE-4067-9E10-AFD8DDA6975E@macports.org> References: <20081203045943.67D8C804DAD@beta.macosforge.org> <2D5A6935-D4EE-4067-9E10-AFD8DDA6975E@macports.org> Message-ID: <4619FF46-9BE4-420B-8ED4-3DEFD2401B61@macports.org> Thanks Ryan =) On Dec 2, 2008, at 21:10, Ryan Schmidt wrote: >> +post-destroot { >> + system "mv ${destroot}/Library/LaunchAgents/org.x.startx.plist $ >> {destroot}/Library/LaunchAgents/org.macports.startx.plist" >> + system "mv ${destroot}/Library/LaunchDaemons/ >> org.x.privileged_startx.plist ${destroot}/Library/LaunchDaemons/ >> org.macports.privileged_startx.plist" >> + >> + system "mkdir ${destroot}/${prefix}/lib/X11/xinit/xinitrc.d" >> + system "cp ${filespath}/xinitrc.d/*.sh ${destroot}/${prefix}/lib/ >> X11/xinit/xinitrc.d" >> + system "chmod 755 ${destroot}/${prefix}/lib/X11/xinit/xinitrc.d/ >> *.sh" >> +} > > FYI it's preferable to use built-in tcl commands rather than > starting a new shell using "system" where possible. So here's how > that would look: > > > post-destroot { > move ${destroot}/Library/LaunchAgents/org.x.startx.plist $ > {destroot}/Library/LaunchAgents/org.macports.startx.plist > move ${destroot}/Library/LaunchDaemons/ > org.x.privileged_startx.plist ${destroot}/Library/LaunchDaemons/ > org.macports.privileged_startx.plist > > xinstall -d ${destroot}${prefix}/lib/X11/xinit/xinitrc.d > eval xinstall -m 755 [glob ${filespath}/xinitrc.d/*.sh] ${destroot}$ > {prefix}/lib/X11/xinit/xinitrc.d > } > > > I think this is right, but I've just typed it in here and haven't > tested it. Also note you shouldn't put a slash before ${prefix}; $ > {prefix} begins with a slash already. From ryandesign at macports.org Wed Dec 3 00:08:01 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 3 Dec 2008 02:08:01 -0600 Subject: [43004] trunk/dports/graphics/netpbm In-Reply-To: <20081203070505.DE61880B55E@beta.macosforge.org> References: <20081203070505.DE61880B55E@beta.macosforge.org> Message-ID: <767CE4A6-F300-4E3B-8EE1-78AEEB959AB3@macports.org> On Dec 3, 2008, at 01:05, mcalhoun at macports.org wrote: > + eval move ${destroot}${prefix}/bin/doc.url [glob ${destroot}$ > {prefix}/misc/* ${destroot}${prefix}/share/netpbm] Shouldn't the closing bracket be after the asterisk instead? eval move ${destroot}${prefix}/bin/doc.url [glob ${destroot}$ {prefix}/misc/*] ${destroot}${prefix}/share/netpbm From mcalhoun at macports.org Wed Dec 3 00:17:38 2008 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Wed, 3 Dec 2008 08:17:38 +0000 (UTC) Subject: [43004] trunk/dports/graphics/netpbm References: <20081203070505.DE61880B55E@beta.macosforge.org> <767CE4A6-F300-4E3B-8EE1-78AEEB959AB3@macports.org> Message-ID: Ryan Schmidt writes: > Shouldn't the closing bracket be after the asterisk instead? Thank you for pointing this out. It was fixed in r43012. From ram at macports.org Wed Dec 3 13:08:43 2008 From: ram at macports.org (Adam Mercer) Date: Wed, 3 Dec 2008 15:08:43 -0600 Subject: [43026] trunk/dports/devel/git-core/Portfile In-Reply-To: <20081203210310.8EBC7821FDC@beta.macosforge.org> References: <20081203210310.8EBC7821FDC@beta.macosforge.org> Message-ID: <799406d60812031308k276e2e3dm5736c6c17c2191cd@mail.gmail.com> On Wed, Dec 3, 2008 at 15:03, wrote: > devel/git-core: Add missing dependency to variant svn. Why is this needed, I've been using git-svn for quite a while and don't have the unixODBC port installed and I've never ran into problems? Cheers Adam From ryandesign at macports.org Wed Dec 3 13:13:33 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 3 Dec 2008 15:13:33 -0600 Subject: Tracking which ports were installed explicitly Message-ID: Joshua proposed that we should track which ports were installed explicitly (via "sudo port install x") vs. which ports were installed via dependencies. As he said in the ticket -- http://trac.macports.org/ticket/15260 : > Keeping track of which ports the user explicitly asked to be > installed, as opposed to those installed only to fulfil > dependencies, would be quite useful. It would be analogous to > Gentoo's 'world'. With this information, we could do things like > uninstall all the ports that are no longer required after > uninstalling some other port. > > It shouldn't be hard to store the information by adding a magic > port name to the dep_map which depends on all the explicitly- > installed ports. We'd then need code to figure out during install > whether the port was explicitly asked for, and add the dep_map > entry. We'd also need to change the dependents check in uninstall > to not complain if the only dependent is the magic 'world' port. > > Some discussion has taken place in the ticket and I'd like to move that discussion to this mailing list so we can get more input, and since it's easier to discuss things on the mailing list without cluttering up the ticket. Once we reach a consensus on what should be done, a summary can go into the ticket. I mentioned the parallel with CPAN, which to my recollection has a feature where when you uninstall X, and if it depends on Y, and nothing else depends on Y, it will ask interactively if you want to uninstall Y as well. I pointed out that MacPorts has no interactivity at this time (except if you explicitly enter interactive mode by typing just "port"), and that I value this guarantee of non- interactivity. Rainer and I liked the idea of a new pseudo-port (I called it "unused"; Rainer called it "orphaned" which is probably better) that you could use to deal with the ports that had been installed as dependencies of things which themselves have already been uninstalled. Then you could do the usual things like "port installed orphaned" or "sudo port uninstall orphaned". The idea is to have MacPorts keep track of what you installed explicitly and what was installed automatically as a dependency. I think it might be of value to be able to manipulate this after the fact, both by changing something from an explicitly installed port to an automatically installed dependency (e.g. things that you would have let MacPorts install as a dependency except that you had to install it explicitly to get a particular variant) and by changing something from an automatically installed dependency to an explicitly installed port (e.g. things that you let MacPorts install as a dependency but which you want to keep around). Though I'm not convinced it's essential, and maybe it can be deferred until later anyway. I also brought up the need to consider how this feature would affect the MacPorts framework/API. Probably a new pseudo-port wouldn't need any special changes in the API which would be good. I'd like to solicit opinions on any and all of these matters, so let the discussion begin! From stechert at gmail.com Wed Dec 3 13:27:48 2008 From: stechert at gmail.com (Andre Stechert) Date: Wed, 3 Dec 2008 13:27:48 -0800 Subject: Tracking which ports were installed explicitly In-Reply-To: References: Message-ID: <12a697af0812031327p141d4e2av201de20da27fc05c@mail.gmail.com> Didn't see anything about counts of the implicit dependencies in the ticket or in this thread. The states of a port are probably "explicitly installed", "implicit against 1 other port", "implicit against 2 other ports", etc., right? Otherwise, you have the potential of setting the orphaned bit too early. Also, the "explicit" bit should probably be independent of the implicit dependency count. On Wed, Dec 3, 2008 at 1:13 PM, Ryan Schmidt wrote: > Joshua proposed that we should track which ports were installed explicitly > (via "sudo port install x") vs. which ports were installed via dependencies. > > As he said in the ticket -- http://trac.macports.org/ticket/15260 : > >> Keeping track of which ports the user explicitly asked to be installed, as >> opposed to those installed only to fulfil dependencies, would be quite >> useful. It would be analogous to Gentoo's 'world'. With this information, we >> could do things like uninstall all the ports that are no longer required >> after uninstalling some other port. >> >> It shouldn't be hard to store the information by adding a magic port name >> to the dep_map which depends on all the explicitly-installed ports. We'd >> then need code to figure out during install whether the port was explicitly >> asked for, and add the dep_map entry. We'd also need to change the >> dependents check in uninstall to not complain if the only dependent is the >> magic 'world' port. >> >> > > > Some discussion has taken place in the ticket and I'd like to move that > discussion to this mailing list so we can get more input, and since it's > easier to discuss things on the mailing list without cluttering up the > ticket. Once we reach a consensus on what should be done, a summary can go > into the ticket. > > > I mentioned the parallel with CPAN, which to my recollection has a feature > where when you uninstall X, and if it depends on Y, and nothing else depends > on Y, it will ask interactively if you want to uninstall Y as well. I > pointed out that MacPorts has no interactivity at this time (except if you > explicitly enter interactive mode by typing just "port"), and that I value > this guarantee of non-interactivity. > > Rainer and I liked the idea of a new pseudo-port (I called it "unused"; > Rainer called it "orphaned" which is probably better) that you could use to > deal with the ports that had been installed as dependencies of things which > themselves have already been uninstalled. Then you could do the usual things > like "port installed orphaned" or "sudo port uninstall orphaned". > > The idea is to have MacPorts keep track of what you installed explicitly and > what was installed automatically as a dependency. I think it might be of > value to be able to manipulate this after the fact, both by changing > something from an explicitly installed port to an automatically installed > dependency (e.g. things that you would have let MacPorts install as a > dependency except that you had to install it explicitly to get a particular > variant) and by changing something from an automatically installed > dependency to an explicitly installed port (e.g. things that you let > MacPorts install as a dependency but which you want to keep around). Though > I'm not convinced it's essential, and maybe it can be deferred until later > anyway. > > I also brought up the need to consider how this feature would affect the > MacPorts framework/API. Probably a new pseudo-port wouldn't need any special > changes in the API which would be good. > > I'd like to solicit opinions on any and all of these matters, so let the > discussion begin! > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From jmr at macports.org Wed Dec 3 13:35:42 2008 From: jmr at macports.org (Joshua Root) Date: Thu, 04 Dec 2008 08:35:42 +1100 Subject: Tracking which ports were installed explicitly In-Reply-To: <12a697af0812031327p141d4e2av201de20da27fc05c@mail.gmail.com> References: <12a697af0812031327p141d4e2av201de20da27fc05c@mail.gmail.com> Message-ID: <4936FBAE.6070805@macports.org> Andre Stechert wrote: > Didn't see anything about counts of the implicit dependencies in the > ticket or in this thread. The states of a port are probably > "explicitly installed", "implicit against 1 other port", "implicit > against 2 other ports", etc., right? Otherwise, you have the > potential of setting the orphaned bit too early. Also, the "explicit" > bit should probably be independent of the implicit dependency count. If it's done as proposed in the ticket, you would do 'port dependents foo' (or rather its internal equivalent) to see whether foo is orphaned. If it has no dependents, it's orphaned. Explicitly installing a port adds 'world' as a dependent. - Josh From ryandesign at macports.org Wed Dec 3 13:37:34 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 3 Dec 2008 15:37:34 -0600 Subject: [43024] trunk/dports/x11/xorg-xcb-proto/Portfile In-Reply-To: <20081203205844.958AC821E00@beta.macosforge.org> References: <20081203205844.958AC821E00@beta.macosforge.org> Message-ID: <60D85548-92C5-4A15-B22D-B3FE0D46BC92@macports.org> On Dec 3, 2008, at 14:58, jeremyhu at macports.org wrote: > Revision: 43024 > http://trac.macports.org/changeset/43024 > Author: jeremyhu at macports.org > Date: 2008-12-03 12:58:44 -0800 (Wed, 03 Dec 2008) > Log Message: > ----------- > Added missing dependencies on python and libxml2 - bug #17499 > +set pyversion 2.6 > +depends_run port:libxml2 \ > + port:python[strsed ${pyversion} {g/[.]//}] > +configure.env PYTHON=${prefix}/bin/python${pyversion} > + > +variant python25 description {Use python 2.5 for xcbgen} { > + depends_run-delete port:python[strsed ${pyversion} {g/ > [.]//}] > + configure.env-delete PYTHON=${prefix}/bin/python${pyversion} > + > + set pyversion 2.5 > + > + depends_lib-append port:python[strsed ${pyversion} {g/ > [.]//}] > + configure.env-append PYTHON=${prefix}/bin/python${pyversion} > +} > + > +variant python30 description {Use python 3.0 for xcbgen} { > + depends_run-delete port:python[strsed ${pyversion} {g/ > [.]//}] > + configure.env-delete PYTHON=${prefix}/bin/python${pyversion} > + > + set pyversion 3.0 > + > + depends_lib-append port:python[strsed ${pyversion} {g/ > [.]//}] > + configure.env-append PYTHON=${prefix}/bin/python${pyversion} > +} Presumably only one python version can be selected at a time? Right now, nothing prevents a user from selecting both the +python25 and +python30 variants. You should add a variant for python26 as well. You should mark all three variants as conflicting with one another. And you should have the new +python26 variant be the default, unless the user has chosen another one. You should also use configure.python instead of configure.env-append PYTHON=. I didn't remember if that was already in MacPorts 1.6.0 or whether it'll be new to 1.7.0, but the ChangeLog seems to indicate it was in 1.6.0. I don't think I've seen a strsed (or, any other string manipulation command) used as part of a depspec. Does that really work? I removed it in my patch and just wrote out the numbers. It also helps when people want to grep the portfiles to see e.g. what all depends on python26 ("grep :python26 */*/Portfile"). Your python26 was a runtime dependency but your python25 and python30 were library dependencies. I didn't know which is right. I made them all library dependencies in my version. Attached is my patch, though again I haven't tested it. -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg-xcb-proto.diff Type: application/octet-stream Size: 1867 bytes Desc: not available URL: From simon at ruderich.org Wed Dec 3 13:58:10 2008 From: simon at ruderich.org (Simon Ruderich) Date: Wed, 3 Dec 2008 22:58:10 +0100 Subject: [43026] trunk/dports/devel/git-core/Portfile In-Reply-To: <799406d60812031308k276e2e3dm5736c6c17c2191cd@mail.gmail.com> References: <20081203210310.8EBC7821FDC@beta.macosforge.org> <799406d60812031308k276e2e3dm5736c6c17c2191cd@mail.gmail.com> Message-ID: <20081203215809.GA18364@ruderich.org> On Wed, Dec 03, 2008 at 03:08:43PM -0600, Adam Mercer wrote: > On Wed, Dec 3, 2008 at 15:03, wrote: > >> devel/git-core: Add missing dependency to variant svn. > > Why is this needed, I've been using git-svn for quite a while and > don't have the unixODBC port installed and I've never ran into > problems? > > Cheers > > Adam I'm not sure. I've removed some unnecessary ports (found through port dependents) and then git-svn failed. After installing unixODBC it worked, so I thought adding it as dependency would fix it. 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: From jmr at macports.org Wed Dec 3 14:30:44 2008 From: jmr at macports.org (Joshua Root) Date: Thu, 04 Dec 2008 09:30:44 +1100 Subject: [43026] trunk/dports/devel/git-core/Portfile In-Reply-To: <20081203215809.GA18364@ruderich.org> References: <20081203210310.8EBC7821FDC@beta.macosforge.org> <799406d60812031308k276e2e3dm5736c6c17c2191cd@mail.gmail.com> <20081203215809.GA18364@ruderich.org> Message-ID: <49370894.2020604@macports.org> Simon Ruderich wrote: > On Wed, Dec 03, 2008 at 03:08:43PM -0600, Adam Mercer wrote: >> On Wed, Dec 3, 2008 at 15:03, wrote: >> >>> devel/git-core: Add missing dependency to variant svn. >> Why is this needed, I've been using git-svn for quite a while and >> don't have the unixODBC port installed and I've never ran into >> problems? >> >> Cheers >> >> Adam > > I'm not sure. I've removed some unnecessary ports (found through port > dependents) and then git-svn failed. After installing unixODBC it worked, so I > thought adding it as dependency would fix it. Could be that git-core includes code that uses unixODBC only if the latter is present at build time. If so, the alternative solution would be to make sure it never includes that support. - Josh From rowue at digitalis.org Wed Dec 3 15:55:44 2008 From: rowue at digitalis.org (=?ISO-8859-1?Q?Rolf_W=FCrdemann?=) Date: Thu, 4 Dec 2008 00:55:44 +0100 Subject: Port shared-mime-info: remove dependency of perl5? Message-ID: <8DCB4557-AA1D-4551-A441-90D4C0BE4362@digitalis.org> Hi everybody: The port shared-mime-info has an (Path) dependency on perl5 and an dependency on port p5-xml-parser. The port "p5-xml-parser" depends on perl5.8. On a an fresh installed macports (1.6) this can lead to problems (a2p) (see #17304, http://trac.macports.org/ticket/17304), 'cause perl5 gets installed from p5-xml-parser. I would like to remove the dependency from shared-mime-info. Any comments? (I know the discussion in #16830; http:// trac.macports.org/ticket/16830) but gtk2 is an often used package. bratapfel:~ rowue$ port deps shared-mime-info shared-mime-info has build dependencies on: pkgconfig perl5 p5-xml-parser intltool shared-mime-info has library dependencies on: gettext glib2 libiconv libxml2 zlib bratapfel:~ rowue$ port deps p5-xml-parser p5-xml-parser has library dependencies on: perl5.8 expat Reg's rowue -- Security is an illusion - Datasecurity twice Rolf W?rdemann - private: rowue at digitalis.org - office: rowue at crew-gmbh.de GnuPG fingerprint: 7383 348F 67D1 CD27 C90F DDD0 86A3 31B6 67F0 D02F jabber: rowue at digitalis.org ECF127C7 EAB85F87 BC75ACB5 2EC646D4 99211A31 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: Signierter Teil der Nachricht URL: From ryandesign at macports.org Wed Dec 3 17:40:15 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 3 Dec 2008 19:40:15 -0600 Subject: Port shared-mime-info: remove dependency of perl5? In-Reply-To: <8DCB4557-AA1D-4551-A441-90D4C0BE4362@digitalis.org> References: <8DCB4557-AA1D-4551-A441-90D4C0BE4362@digitalis.org> Message-ID: On Dec 3, 2008, at 17:55, Rolf W?rdemann wrote: > The port shared-mime-info has an (Path) dependency on perl5 and an > dependency > on port p5-xml-parser. The port "p5-xml-parser" depends on perl5.8. Actually p5-xml-parser is a member of the perl5 portgroup, which in MacPorts 1.6.0 depends on perl5.8 but which in MacPorts 1.7.0 will depend on perl5. > On a an fresh installed macports (1.6) this can lead to problems > (a2p) (see #17304, > http://trac.macports.org/ticket/17304), 'cause perl5 gets installed > from p5-xml-parser. Yes... > I would like to remove the dependency from shared-mime-info. Since shared-mime-info does have the line "configure.env-append INTLTOOL_PERL=${prefix}/bin/perl" it appears that it really does want to use perl itself, so it is proper to declare a dependency on perl.... > Any comments? (I know the discussion in #16830; http:// > trac.macports.org/ticket/16830) > but gtk2 is an often used package. If we release MacPorts 1.7.0 very soon, it's not an issue... We have a beta of 1.7.0 out already. Not sure how long it will take to turn that into release candidates and a final release. Not sure what we should do here. From neil at voidfx.net Wed Dec 3 17:44:43 2008 From: neil at voidfx.net (Neil) Date: Wed, 3 Dec 2008 20:44:43 -0500 Subject: Tracking which ports were installed explicitly In-Reply-To: References: Message-ID: On 3 Dec 2008, at 16:13, Ryan Schmidt wrote: > Joshua proposed that we should track which ports were installed > explicitly (via "sudo port install x") vs. which ports were > installed via dependencies. > > As he said in the ticket -- http://trac.macports.org/ticket/15260 : > >> Keeping track of which ports the user explicitly asked to be >> installed, as opposed to those installed only to fulfil >> dependencies, would be quite useful. It would be analogous to >> Gentoo's 'world'. With this information, we could do things like >> uninstall all the ports that are no longer required after >> uninstalling some other port. >> >> It shouldn't be hard to store the information by adding a magic >> port name to the dep_map which depends on all the explicitly- >> installed ports. We'd then need code to figure out during install >> whether the port was explicitly asked for, and add the dep_map >> entry. We'd also need to change the dependents check in uninstall >> to not complain if the only dependent is the magic 'world' port. >> >> > > > Some discussion has taken place in the ticket and I'd like to move > that discussion to this mailing list so we can get more input, and > since it's easier to discuss things on the mailing list without > cluttering up the ticket. Once we reach a consensus on what should > be done, a summary can go into the ticket. > I'm not a huge fan of "Me too." posts to mailing lists, but.... > > I mentioned the parallel with CPAN, which to my recollection has a > feature where when you uninstall X, and if it depends on Y, and > nothing else depends on Y, it will ask interactively if you want to > uninstall Y as well. I pointed out that MacPorts has no > interactivity at this time (except if you explicitly enter > interactive mode by typing just "port"), and that I value this > guarantee of non-interactivity. Me too. (I value the non-interactivity.) > > Rainer and I liked the idea of a new pseudo-port (I called it > "unused"; Rainer called it "orphaned" which is probably better) that > you could use to deal with the ports that had been installed as > dependencies of things which themselves have already been > uninstalled. Then you could do the usual things like "port installed > orphaned" or "sudo port uninstall orphaned". > This sounds like the right way to go about it to me. From raimue at macports.org Wed Dec 3 18:46:29 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 04 Dec 2008 03:46:29 +0100 Subject: Tracking which ports were installed explicitly In-Reply-To: <4936FBAE.6070805@macports.org> References: <12a697af0812031327p141d4e2av201de20da27fc05c@mail.gmail.com> <4936FBAE.6070805@macports.org> Message-ID: <49374485.6040308@macports.org> Joshua Root wrote: > If it's done as proposed in the ticket, you would do 'port dependents > foo' (or rather its internal equivalent) to see whether foo is orphaned. > If it has no dependents, it's orphaned. Explicitly installing a port > adds 'world' as a dependent. Using a pseudo-port like 'world' sounds like a very nice and elegant idea to me. But checking for dependents is currently a very expensive operation. To find all dependents the current code iterates over the whole dep_map, which can grow very large depending on the number of ports being installed. If you never heard about dep_map, take a look in your own install: bzless /opt/local/var/macports/receipts/dep_map.bz2 And then you will see why searching and modifying this file is so expensive. Therefore we should focus on finishing registry2.0. This was already started by Chris Pickel (sfiera) in Google Summer of Code 2007. The code was merged to trunk, and it is also already distributed with releases, but it is not used at all yet. registry2.0 plans to use a sqlite db instead of plain text files for dependency tracking (dep_map) and receipts. This should hopefully make such search operations a lot faster and also make the registry more extensible. I tried to get a statement about the status of registry2.0 from Chris some time ago in April, but the only response was that he is busy. So I don't know what is left to complete registry2.0. Rainer From raimue at macports.org Wed Dec 3 19:02:04 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 04 Dec 2008 04:02:04 +0100 Subject: Port shared-mime-info: remove dependency of perl5? In-Reply-To: References: <8DCB4557-AA1D-4551-A441-90D4C0BE4362@digitalis.org> Message-ID: <4937482C.7090302@macports.org> Ryan Schmidt wrote: > On Dec 3, 2008, at 17:55, Rolf W?rdemann wrote: > >> The port shared-mime-info has an (Path) dependency on perl5 and an >> dependency >> on port p5-xml-parser. The port "p5-xml-parser" depends on perl5.8. > > Actually p5-xml-parser is a member of the perl5 portgroup, which in > MacPorts 1.6.0 depends on perl5.8 but which in MacPorts 1.7.0 will > depend on perl5. >From perl5-1.0.tcl which shipped with MacPorts 1.6.0: set perl5.bin ${prefix}/bin/perl [...] depends_lib path:${perl5.bin}:perl5.8 So as a workaround uninstalling perl5.8 and any p5-* port and then installing perl5 before any p5-* port should satisfy this dependency. If changing dependencies from perl5.8 to perl5 breaks ports, we should delay the changes until 1.7.0 is out. [...] >> Any comments? (I know the discussion in #16830; http:// >> trac.macports.org/ticket/16830) >> but gtk2 is an often used package. > > If we release MacPorts 1.7.0 very soon, it's not an issue... We have > a beta of 1.7.0 out already. Not sure how long it will take to turn > that into release candidates and a final release. > > Not sure what we should do here. Either revert back to perl5.8 as dependency or make perl5 an "empty" port with 'depends_lib port:perl5.8' only. Rainer From ryandesign at macports.org Wed Dec 3 19:30:04 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 3 Dec 2008 21:30:04 -0600 Subject: Tracking which ports were installed explicitly In-Reply-To: <49374485.6040308@macports.org> References: <12a697af0812031327p141d4e2av201de20da27fc05c@mail.gmail.com> <4936FBAE.6070805@macports.org> <49374485.6040308@macports.org> Message-ID: <0017F276-CEE7-485B-B813-0938D9833BE3@macports.org> On Dec 3, 2008, at 20:46, Rainer M?ller wrote: > Joshua Root wrote: > >> If it's done as proposed in the ticket, you would do 'port dependents >> foo' (or rather its internal equivalent) to see whether foo is >> orphaned. >> If it has no dependents, it's orphaned. Explicitly installing a port >> adds 'world' as a dependent. > > Using a pseudo-port like 'world' sounds like a very nice and elegant > idea to me. But checking for dependents is currently a very expensive > operation. To find all dependents the current code iterates over the > whole dep_map, which can grow very large depending on the number of > ports being installed. > > If you never heard about dep_map, take a look in your own install: > bzless /opt/local/var/macports/receipts/dep_map.bz2 > And then you will see why searching and modifying this file is so > expensive. > > Therefore we should focus on finishing registry2.0. This was already > started by Chris Pickel (sfiera) in Google Summer of Code 2007. The > code > was merged to trunk, and it is also already distributed with releases, > but it is not used at all yet. > > registry2.0 plans to use a sqlite db instead of plain text files for > dependency tracking (dep_map) and receipts. This should hopefully make > such search operations a lot faster and also make the registry more > extensible. > > I tried to get a statement about the status of registry2.0 from Chris > some time ago in April, but the only response was that he is busy. > So I > don't know what is left to complete registry2.0. We also need to consider that changes have probably occurred in registry1.0 since then which may not have been merged into registry2.0. From ryandesign at macports.org Wed Dec 3 20:51:50 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 3 Dec 2008 22:51:50 -0600 Subject: [43073] trunk/doc-new/guide/xml/project.xml In-Reply-To: <20081204044101.C7C7882A9ED@beta.macosforge.org> References: <20081204044101.C7C7882A9ED@beta.macosforge.org> Message-ID: On Dec 3, 2008, at 22:41, jmr at macports.org wrote: > > Create patch file(s) as necessary, attach them to > a Trac > - ticket, and assign the ticket to the maintainer and Cc > him or > - her. > + ticket, and assign the ticket to the maintainer (or Cc > him or > + her, if you are unable to assign tickets). > Should we allow all users to assign tickets? From jeremyhu at macports.org Wed Dec 3 21:55:28 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Wed, 3 Dec 2008 21:55:28 -0800 Subject: [43024] trunk/dports/x11/xorg-xcb-proto/Portfile In-Reply-To: <60D85548-92C5-4A15-B22D-B3FE0D46BC92@macports.org> References: <20081203205844.958AC821E00@beta.macosforge.org> <60D85548-92C5-4A15-B22D-B3FE0D46BC92@macports.org> Message-ID: <05318EAA-6E67-4CF0-A23F-335B1968D59A@macports.org> > Presumably only one python version can be selected at a time? Right > now, nothing prevents a user from selecting both the +python25 and > +python30 variants. Yeah, but if they select both, only python30 is pulled in that case... > I don't think I've seen a strsed (or, any other string manipulation > command) used as part of a depspec. Does that really work? Yeah, I pulled it from another port... I forget which... > I removed it in my patch and just wrote out the numbers. It also > helps when people want to grep the portfiles to see e.g. what all > depends on python26 ("grep :python26 */*/Portfile"). Fair enough. I'm sold. > Your python26 was a runtime dependency but your python25 and > python30 were library dependencies. I didn't know which is right. I > made them all library dependencies in my version. > > Attached is my patch, though again I haven't tested it. Thanks. From ram at macports.org Thu Dec 4 21:55:57 2008 From: ram at macports.org (Adam Mercer) Date: Thu, 4 Dec 2008 23:55:57 -0600 Subject: [42765] trunk/dports/devel/swig/Portfile In-Reply-To: <20081130180825.789937CB8EA@beta.macosforge.org> References: <20081130180825.789937CB8EA@beta.macosforge.org> Message-ID: <799406d60812042155u35a93708jbb2afa4b60770eb@mail.gmail.com> On Sun, Nov 30, 2008 at 12:08, wrote: > Revision 42765 Author mcalhoun at macports.org Date 2008-11-30 10:08:24 -0800 > (Sun, 30 Nov 2008) > > Log Message > > swig: Added new languages (tcl, java, octave, and csharp). > Fixed languages (php and gcj). > Changed perl dependency (see #16830). > + python port:python26 python=${prefix}/bin/python2.6 This seems overkill to me, a while ago I submitted a ticket, #15854, that recomended the use of port:python_select for the python variant dependency as the contents of the swig python variant is identical no matter which python variant is used (a diff results in zero differences), and python_select defaults to the system python if no python port is installed (or specified) which is perfectly fine for swig. The only possible modification is that python_select should probably be modifed to suggest that a python port be installed, along the same lines of when a python port recommends the installation, and running of python_select. I should probably file a ticket for this... Cheers Adam From ryandesign at macports.org Fri Dec 5 13:44:33 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 5 Dec 2008 15:44:33 -0600 Subject: [43132] trunk/dports/x11/xorg-libAppleWM/Portfile In-Reply-To: <20081205211402.01B8185D21D@beta.macosforge.org> References: <20081205211402.01B8185D21D@beta.macosforge.org> Message-ID: <13B4AFDC-D7D7-4507-8F59-FD73236EE80B@macports.org> On Dec 5, 2008, at 15:14, jeremyhu at macports.org wrote: > Revision: 43132 > http://trac.macports.org/changeset/43132 > Author: jeremyhu at macports.org > Date: 2008-12-05 13:14:01 -0800 (Fri, 05 Dec 2008) > Log Message: > ----------- > libAppleWM: autoreconf to build universal > > Modified Paths: > -------------- > trunk/dports/x11/xorg-libAppleWM/Portfile > > Modified: trunk/dports/x11/xorg-libAppleWM/Portfile > =================================================================== > --- trunk/dports/x11/xorg-libAppleWM/Portfile 2008-12-05 21:12:35 > UTC (rev 43131) > +++ trunk/dports/x11/xorg-libAppleWM/Portfile 2008-12-05 21:14:01 > UTC (rev 43132) > @@ -4,6 +4,7 @@ > > name xorg-libAppleWM > version 1.0.0 > +revision 1 > categories x11 devel > maintainers jeremyhu > description X.org libAppleWM > @@ -21,8 +22,18 @@ > use_parallel_build yes > > depends_build port:pkgconfig \ > + port:libtool \ > port:xorg-applewmproto \ > port:xorg-xproto \ > port:xorg-xextproto > depends_lib port:xorg-libX11 \ > port:xorg-libXext > + > +pre-configure { > + system "cd ${worksrcpath} && autoreconf -fvi" > +} If you're going to run autoreconf, you need to declare a build dependency on the port that provides autoreconf... That would be the autoconf port. Probably declaring a build dependency on all three (autoconf, automake, libtool) is required. There was quite a lot of confusion around this with the libxml2 port; see r38015, r38175, r39322, r39551. And what's "-fvi" and is it really necessary? We have a preferred method in MacPorts for running autoreconf, which currently is: use_autoconf yes autoconf.cmd autoreconf In MacPorts 1.7.0 you'll be able to just: use_autoreconf yes From ryandesign at macports.org Fri Dec 5 13:46:13 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 5 Dec 2008 15:46:13 -0600 Subject: py26 ports Message-ID: <3DFEF42E-F078-4F91-981A-632372198FA1@macports.org> I see a lot of py26 ports being added. It looks like we've given up on the consolidation idea? http://trac.macports.org/ticket/16723 From mcalhoun at macports.org Fri Dec 5 14:01:20 2008 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Fri, 5 Dec 2008 22:01:20 +0000 (UTC) Subject: py26 ports References: <3DFEF42E-F078-4F91-981A-632372198FA1@macports.org> Message-ID: Ryan Schmidt writes: > > I see a lot of py26 ports being added. It looks like we've given up > on the consolidation idea? > > http://trac.macports.org/ticket/16723 > > I still think consolidation is a good idea, but, as noted in the ticket, it would be very difficult to get it to work without a fix to http://trac.macports.org/ticket/126. I can only speak for myself, but I did not want python26 to wait on the fix. From jeremyhu at macports.org Fri Dec 5 14:09:14 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Fri, 5 Dec 2008 14:09:14 -0800 Subject: [43132] trunk/dports/x11/xorg-libAppleWM/Portfile In-Reply-To: <13B4AFDC-D7D7-4507-8F59-FD73236EE80B@macports.org> References: <20081205211402.01B8185D21D@beta.macosforge.org> <13B4AFDC-D7D7-4507-8F59-FD73236EE80B@macports.org> Message-ID: On Dec 5, 2008, at 13:44, Ryan Schmidt wrote: > On Dec 5, 2008, at 15:14, jeremyhu at macports.org wrote: > >> Revision: 43132 >> http://trac.macports.org/changeset/43132 >> Author: jeremyhu at macports.org >> Date: 2008-12-05 13:14:01 -0800 (Fri, 05 Dec 2008) >> Log Message: >> ----------- >> libAppleWM: autoreconf to build universal >> >> Modified Paths: >> -------------- >> trunk/dports/x11/xorg-libAppleWM/Portfile >> >> Modified: trunk/dports/x11/xorg-libAppleWM/Portfile >> =================================================================== >> --- trunk/dports/x11/xorg-libAppleWM/Portfile 2008-12-05 21:12:35 >> UTC (rev 43131) >> +++ trunk/dports/x11/xorg-libAppleWM/Portfile 2008-12-05 21:14:01 >> UTC (rev 43132) >> @@ -4,6 +4,7 @@ >> >> name xorg-libAppleWM >> version 1.0.0 >> +revision 1 >> categories x11 devel >> maintainers jeremyhu >> description X.org libAppleWM >> @@ -21,8 +22,18 @@ >> use_parallel_build yes >> >> depends_build port:pkgconfig \ >> + port:libtool \ >> port:xorg-applewmproto \ >> port:xorg-xproto \ >> port:xorg-xextproto >> depends_lib port:xorg-libX11 \ >> port:xorg-libXext >> + >> +pre-configure { >> + system "cd ${worksrcpath} && autoreconf -fvi" >> +} > > If you're going to run autoreconf, you need to declare a build > dependency on the port that provides autoreconf... > That would be the autoconf port. Probably declaring a build > dependency on all three (autoconf, automake, libtool) is required. That's what that port:libtool dependency is for. libtool depends on automake which depends on autoconf. I didn't realize I needed to explicitly require all three. I'll update that. > There was quite a lot of confusion around this with the libxml2 > port; see r38015, r38175, r39322, r39551. > > And what's "-fvi" and is it really necessary? We have a preferred > method in MacPorts for running autoreconf, which currently is: force (assumes all files are too old and reinstalls them all) verbose (better debugging output) install (copies missing aux files to make autoconf not complain) > use_autoconf yes > autoconf.cmd autoreconf Does this trigger the dependencies as well, or do I need to explicitly do that? I just copied this behavior from another port. > In MacPorts 1.7.0 you'll be able to just: > > use_autoreconf yes And I assume there is a corresponding autoreconf.cmd, so I could set '- fvi' if needed? From ryandesign at macports.org Fri Dec 5 14:29:47 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 5 Dec 2008 16:29:47 -0600 Subject: [43132] trunk/dports/x11/xorg-libAppleWM/Portfile In-Reply-To: References: <20081205211402.01B8185D21D@beta.macosforge.org> <13B4AFDC-D7D7-4507-8F59-FD73236EE80B@macports.org> Message-ID: <8323440F-1D6E-4F11-A5C4-A1E5402DD987@macports.org> On Dec 5, 2008, at 16:09, Jeremy Huddleston wrote: > On Dec 5, 2008, at 13:44, Ryan Schmidt wrote: > >> If you're going to run autoreconf, you need to declare a build >> dependency on the port that provides autoreconf... >> That would be the autoconf port. Probably declaring a build >> dependency on all three (autoconf, automake, libtool) is required. > > That's what that port:libtool dependency is for. libtool depends > on automake which depends on autoconf. I didn't realize I needed > to explicitly require all three. I'll update that. libtool only has a build dependency on automake which only has a build dependency on autoconf. That means as soon as automake is installed, a user would be perfectly free to uninstall autoconf and expect no problems. And once libtool is installed, the user would expect to be able to uninstall automake with no problems. And MacPorts will allow uninstallation of those ports with no complaints, since those ports are not library or runtime dependencies but only build dependencies. So if you want to use those ports to build something, you need to declare build dependencies on them. >> There was quite a lot of confusion around this with the libxml2 >> port; see r38015, r38175, r39322, r39551. >> >> And what's "-fvi" and is it really necessary? We have a preferred >> method in MacPorts for running autoreconf, which currently is: > > force (assumes all files are too old and reinstalls them all) > verbose (better debugging output) > install (copies missing aux files to make autoconf not complain) > >> use_autoconf yes >> autoconf.cmd autoreconf > > Does this trigger the dependencies as well, or do I need to > explicitly do that? I just copied this behavior from another port. I'm not sure what you mean by triggering dependencies. I expect it just runs "autoreconf". Is there more that's needed? >> In MacPorts 1.7.0 you'll be able to just: >> >> use_autoreconf yes > > And I assume there is a corresponding autoreconf.cmd, so I could > set '-fvi' if needed? There might be. Is "-fvi" something unique to this port or should this change be made in MacPorts base? From jmr at macports.org Fri Dec 5 14:32:41 2008 From: jmr at macports.org (Joshua Root) Date: Sat, 06 Dec 2008 09:32:41 +1100 Subject: py26 ports In-Reply-To: <3DFEF42E-F078-4F91-981A-632372198FA1@macports.org> References: <3DFEF42E-F078-4F91-981A-632372198FA1@macports.org> Message-ID: <4939AC09.9090902@macports.org> Ryan Schmidt wrote: > I see a lot of py26 ports being added. It looks like we've given up on > the consolidation idea? > > http://trac.macports.org/ticket/16723 For now, yes. It needs #126 fixed to be practical. - Josh From jmr at macports.org Fri Dec 5 14:50:56 2008 From: jmr at macports.org (Joshua Root) Date: Sat, 06 Dec 2008 09:50:56 +1100 Subject: [43132] trunk/dports/x11/xorg-libAppleWM/Portfile In-Reply-To: <8323440F-1D6E-4F11-A5C4-A1E5402DD987@macports.org> References: <20081205211402.01B8185D21D@beta.macosforge.org> <13B4AFDC-D7D7-4507-8F59-FD73236EE80B@macports.org> <8323440F-1D6E-4F11-A5C4-A1E5402DD987@macports.org> Message-ID: <4939B050.7050203@macports.org> Ryan Schmidt wrote: > On Dec 5, 2008, at 16:09, Jeremy Huddleston wrote: > >> On Dec 5, 2008, at 13:44, Ryan Schmidt wrote: >> >>> If you're going to run autoreconf, you need to declare a build >>> dependency on the port that provides autoreconf... >>> That would be the autoconf port. Probably declaring a build >>> dependency on all three (autoconf, automake, libtool) is required. >> >> That's what that port:libtool dependency is for. libtool depends on >> automake which depends on autoconf. I didn't realize I needed to >> explicitly require all three. I'll update that. > > libtool only has a build dependency on automake which only has a build > dependency on autoconf. That means as soon as automake is installed, a > user would be perfectly free to uninstall autoconf and expect no > problems. And once libtool is installed, the user would expect to be > able to uninstall automake with no problems. And MacPorts will allow > uninstallation of those ports with no complaints, since those ports are > not library or runtime dependencies but only build dependencies. So if > you want to use those ports to build something, you need to declare > build dependencies on them. Not that this is only an issue with depends_build, in general there's no policy against pulling in dependencies indirectly. Doing so can prevent trace mode from working, however. >>> There was quite a lot of confusion around this with the libxml2 port; >>> see r38015, r38175, r39322, r39551. >>> >>> And what's "-fvi" and is it really necessary? We have a preferred >>> method in MacPorts for running autoreconf, which currently is: >> >> force (assumes all files are too old and reinstalls them all) >> verbose (better debugging output) >> install (copies missing aux files to make autoconf not complain) >> >>> use_autoconf yes >>> autoconf.cmd autoreconf >> >> Does this trigger the dependencies as well, or do I need to explicitly >> do that? I just copied this behavior from another port. > > I'm not sure what you mean by triggering dependencies. I expect it just > runs "autoreconf". Is there more that's needed? "use_autoconf yes' doesn't add a dependency on autoconf, you have to add it explicitly. There are a number of use_foo options which should really add a dep but don't, see for example . >>> In MacPorts 1.7.0 you'll be able to just: >>> >>> use_autoreconf yes >> >> And I assume there is a corresponding autoreconf.cmd, so I could set >> '-fvi' if needed? It uses the 'command' infrastructure, i.e. the 'commands' and 'command_exec' procs in port1.0/portutil.tcl. So yes, there is an autoreconf.cmd option, but you probably want autoreconf.args. The defaults currently set in portconfigure.tcl for autoreconf are: default autoreconf.dir {${worksrcpath}} default autoreconf.pre_args {--install} - Josh From ryandesign at macports.org Fri Dec 5 15:15:05 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 5 Dec 2008 17:15:05 -0600 Subject: [43140] trunk/base/src/upgrade_sources_conf_default.tcl In-Reply-To: <20081205223641.5DC1285F87D@beta.macosforge.org> References: <20081205223641.5DC1285F87D@beta.macosforge.org> Message-ID: <5675EBB5-3744-4C59-A2C7-D02CF3A4F4B3@macports.org> On Dec 5, 2008, at 16:36, blb at macports.org wrote: > +Warning, your source config file at: > + > + $sourcesConf > + > +needs to have a \[default\] tag added to the primary MacPorts > repository, > +however I was unable to determine which one is the proper one. > Please > +add it manually by either appending \[default\] to the end of the > correct > +line, or if there are already tags, adding it to the list, eg, > +\[nosync,default\]. I'd rather MacPorts didn't refer to itself in the first person. Apple hasn't used "I" in any error messages that I can recall, and I don't think MacPorts has until now either. How about: Warning, your source config file at: $sourcesConf needs to have a \[default\] tag added to the primary ports repository, but MacPorts was unable to determine which entry that is. Please add the tag manually by either appending \[default\] to the end of the correct line, or if there are already tags, adding it to the list, eg, \[nosync,default\]. From jeremyhu at macports.org Fri Dec 5 16:16:18 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Fri, 5 Dec 2008 16:16:18 -0800 Subject: [43132] trunk/dports/x11/xorg-libAppleWM/Portfile In-Reply-To: <8323440F-1D6E-4F11-A5C4-A1E5402DD987@macports.org> References: <20081205211402.01B8185D21D@beta.macosforge.org> <13B4AFDC-D7D7-4507-8F59-FD73236EE80B@macports.org> <8323440F-1D6E-4F11-A5C4-A1E5402DD987@macports.org> Message-ID: <52C08C55-5E7A-4C3A-BE18-F77ACF36BD6A@macports.org> On Dec 5, 2008, at 14:29, Ryan Schmidt wrote: > On Dec 5, 2008, at 16:09, Jeremy Huddleston wrote: > >> On Dec 5, 2008, at 13:44, Ryan Schmidt wrote: >> >>> If you're going to run autoreconf, you need to declare a build >>> dependency on the port that provides autoreconf... >>> That would be the autoconf port. Probably declaring a build >>> dependency on all three (autoconf, automake, libtool) is required. >> >> That's what that port:libtool dependency is for. libtool depends >> on automake which depends on autoconf. I didn't realize I needed >> to explicitly require all three. I'll update that. > > libtool only has a build dependency on automake which only has a > build dependency on autoconf. That means as soon as automake is > installed, a user would be perfectly free to uninstall autoconf and > expect no problems. And once libtool is installed, the user would > expect to be able to uninstall automake with no problems. And > MacPorts will allow uninstallation of those ports with no > complaints, since those ports are not library or runtime > dependencies but only build dependencies. So if you want to use > those ports to build something, you need to declare build > dependencies on them. That's what I thought originally, but it didn't match with what I experienced (so can you explain this behavior): ~ $ sudo port -v uninstall xorg-xproto ---> Unable to uninstall xorg-xproto 7.0.14_1, the following ports depend on it: ---> Xft2 ---> xorg-libXau Error: port uninstall failed: Please uninstall the ports that depend on xorg-xproto first. (16:10:59 Fri Dec 05 2008 jeremy at tifa i386) ~ $ grep -C2 xorg-xproto src/macports/trunk/dports/x11/xorg-libXau/ Portfile depends_build port:pkgconfig \ port:xorg-xproto > I'm not sure what you mean by triggering dependencies. I expect it > just runs "autoreconf". Is there more that's needed? I meant does that also cause 'depends_build-append port:autoconf' to be run, or do I need to manage the dependencies still? > There might be. > > Is "-fvi" something unique to this port or should this change be > made in MacPorts base? I do it more for habit and consistency. I just feel better knowing everything is being remade rather than testing if something is up to date beforehand. It might be nice to do in base. From jmr at macports.org Fri Dec 5 16:26:48 2008 From: jmr at macports.org (Joshua Root) Date: Sat, 06 Dec 2008 11:26:48 +1100 Subject: [43132] trunk/dports/x11/xorg-libAppleWM/Portfile In-Reply-To: <52C08C55-5E7A-4C3A-BE18-F77ACF36BD6A@macports.org> References: <20081205211402.01B8185D21D@beta.macosforge.org> <13B4AFDC-D7D7-4507-8F59-FD73236EE80B@macports.org> <8323440F-1D6E-4F11-A5C4-A1E5402DD987@macports.org> <52C08C55-5E7A-4C3A-BE18-F77ACF36BD6A@macports.org> Message-ID: <4939C6C8.1090509@macports.org> Jeremy Huddleston wrote: > > On Dec 5, 2008, at 14:29, Ryan Schmidt wrote: >> libtool only has a build dependency on automake which only has a build >> dependency on autoconf. That means as soon as automake is installed, a >> user would be perfectly free to uninstall autoconf and expect no >> problems. And once libtool is installed, the user would expect to be >> able to uninstall automake with no problems. And MacPorts will allow >> uninstallation of those ports with no complaints, since those ports >> are not library or runtime dependencies but only build dependencies. >> So if you want to use those ports to build something, you need to >> declare build dependencies on them. > > That's what I thought originally, but it didn't match with what I > experienced (so can you explain this behavior): > > ~ $ sudo port -v uninstall xorg-xproto > ---> Unable to uninstall xorg-xproto 7.0.14_1, the following ports > depend on it: > ---> Xft2 > ---> xorg-libXau > Error: port uninstall failed: Please uninstall the ports that depend on > xorg-xproto first. You switched the dep from depends_lib to depends_build just recently, so this would be . - Josh From ryandesign at macports.org Fri Dec 5 22:53:55 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 6 Dec 2008 00:53:55 -0600 Subject: [43140] trunk/base/src/upgrade_sources_conf_default.tcl In-Reply-To: <5675EBB5-3744-4C59-A2C7-D02CF3A4F4B3@macports.org> References: <20081205223641.5DC1285F87D@beta.macosforge.org> <5675EBB5-3744-4C59-A2C7-D02CF3A4F4B3@macports.org> Message-ID: <1C705DFD-209D-44CD-98B1-F2A793952884@macports.org> > On Dec 5, 2008, at 17:15, Ryan Schmidt wrote: > >> On Dec 5, 2008, at 16:36, blb at macports.org wrote: >> >>> +Warning, your source config file at: >>> + >>> + $sourcesConf >>> + >>> +needs to have a \[default\] tag added to the primary MacPorts >>> repository, >>> +however I was unable to determine which one is the proper one. >>> Please >>> +add it manually by either appending \[default\] to the end of >>> the correct >>> +line, or if there are already tags, adding it to the list, eg, >>> +\[nosync,default\]. >> >> I'd rather MacPorts didn't refer to itself in the first person. >> Apple hasn't used "I" in any error messages that I can recall, and >> I don't think MacPorts has until now either. >> >> How about: >> >> >> Warning, your source config file at: >> >> $sourcesConf >> >> needs to have a \[default\] tag added to the primary ports >> repository, >> but MacPorts was unable to determine which entry that is. Please add >> the tag manually by either appending \[default\] to the end of the >> correct >> line, or if there are already tags, adding it to the list, eg, >> \[nosync,default\]. blb wrote: > needs to have a \[default\] tag added to the primary MacPorts > repository, > -however I was unable to determine which one is the proper one. > Please > -add it manually by either appending \[default\] to the end of the > correct > -line, or if there are already tags, adding it to the list, eg, > +however the proper entry could not be determined. Please add the tag > +manually by either appending \[default\] to the end of the correct > line, > +or if there are already tags, adding it to the list, eg, I like it! Thanks. From mp+d at v6shell.org Fri Dec 5 22:58:17 2008 From: mp+d at v6shell.org (J.A. Neitzel) Date: Sat, 06 Dec 2008 06:58:17 +0000 Subject: release_1_7_0-beta1 test results Message-ID: <493a2289.Q7jbCdSi2R7Lzcrm%mp+d@v6shell.org> Hello, I do not know your preference regarding test results. No feedback == implicit success, or no feedback == nobody testing. In any case, I thought this could be useful, but feel free to tell me otherwise. See [0] for machine info if needed. The only anomaly I have noticed so far is: % ./configure [snip] configure: creating ./config.status config.status: creating src/programs/daemondo/Makefile config.status: WARNING: src/programs/daemondo/Makefile.in seems to \ ignore the --datarootdir setting config.status: creating Doxyfile config.status: creating Makefile [snip] ... which may or may not be important. For the record, my minimal complement of required ports: antiword, curl +sftp_scp +ssl, lynx +ssl, nmap, optipng, osh, pstree, rxvt, rxvt-unicode, splint, subversion, vim, vim-app, wget ... installed w/o problem. HTH -- J.A. Neitzel V6 Thompson Shell Port - http://v6shell.org/ [0] Machine info: Hardware Overview: Model Name: iMac Model Identifier: iMac5,1 Processor Name: Intel Core 2 Duo Processor Speed: 2.16 GHz Number Of Processors: 1 Total Number Of Cores: 2 L2 Cache: 4 MB Memory: 2 GB Bus Speed: 667 MHz Boot ROM Version: IM51.0090.B09 SMC Version: 1.9f4 System Software Overview: Xcode Version: 3.1.2 System Version: Mac OS X 10.5.5 (9F33) Kernel Version: Darwin 9.5.0 Time since boot: 1 day22:50 From raimue at macports.org Sat Dec 6 06:54:16 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 06 Dec 2008 15:54:16 +0100 Subject: release_1_7_0-beta1 test results In-Reply-To: <493a2289.Q7jbCdSi2R7Lzcrm%mp+d@v6shell.org> References: <493a2289.Q7jbCdSi2R7Lzcrm%mp+d@v6shell.org> Message-ID: <493A9218.7070603@macports.org> J.A. Neitzel wrote: > Hello, > > I do not know your preference regarding test results. > No feedback == implicit success, or no feedback == nobody testing. > In any case, I thought this could be useful, but feel free to tell > me otherwise. See [0] for machine info if needed. Thanks for your testing results! Feedback is always welcome, no matter if it's good or bad. Have you done a clean install or did you install on top of an older installation? > The only anomaly I have noticed so far is: > > % ./configure > [snip] > configure: creating ./config.status > config.status: creating src/programs/daemondo/Makefile > config.status: WARNING: src/programs/daemondo/Makefile.in seems to \ > ignore the --datarootdir setting > config.status: creating Doxyfile > config.status: creating Makefile > [snip] > > ... > which may or may not be important. I don't know what that means. I couldn't see anything wrong in the referenced Makefile. Rainer From mp+d at v6shell.org Sat Dec 6 09:04:28 2008 From: mp+d at v6shell.org (J.A. Neitzel) Date: Sat, 06 Dec 2008 17:04:28 +0000 Subject: release_1_7_0-beta1 test results In-Reply-To: <493A9218.7070603@macports.org> References: <493a2289.Q7jbCdSi2R7Lzcrm%mp+d@v6shell.org> <493A9218.7070603@macports.org> Message-ID: <493ab09c.cCuxHoCf8C8DDfTm%mp+d@v6shell.org> Rainer M?ller wrote: > J.A. Neitzel wrote: [snip] > > I do not know your preference regarding test results. > > No feedback == implicit success, or no feedback == nobody testing. > > In any case, I thought this could be useful, but feel free to tell > > me otherwise. See [0] for machine info if needed. > > Thanks for your testing results! Feedback is always welcome, no matter > if it's good or bad. Understood, happy to help! > Have you done a clean install or did you install on top of an older > installation? >From the MacPorts perspective, it is a clean install. Meaning that I did the following before doing ./configure, make, and sudo make install for 1_7_0-beta1: % sudo port uninstall vim-app ; sudo mv /opt /opt.old ... since I have some stuff in /opt.old/local/etc/* and /opt.old/local/var/db/* that I need to transfer. > > The only anomaly I have noticed so far is: > > > > % ./configure > > [snip] > > configure: creating ./config.status > > config.status: creating src/programs/daemondo/Makefile > > config.status: WARNING: src/programs/daemondo/Makefile.in seems to \ > > ignore the --datarootdir setting > > config.status: creating Doxyfile > > config.status: creating Makefile > > [snip] > > > > ... > > which may or may not be important. > > I don't know what that means. I couldn't see anything wrong in the > referenced Makefile. It seems to be related to the GNU autotools. According to [1], adding "datarootdir = @datarootdir@" to Makefile.in might help? Sorry, I do not know or use GNU autotools. Jeff [1] - http://www.gnu.org/software/automake/manual/autoconf/Changed-Directory-Variables.html From peter at pogma.com Sat Dec 6 09:17:45 2008 From: peter at pogma.com (Peter O'Gorman) Date: Sat, 06 Dec 2008 11:17:45 -0600 Subject: release_1_7_0-beta1 test results In-Reply-To: <493ab09c.cCuxHoCf8C8DDfTm%mp+d@v6shell.org> References: <493a2289.Q7jbCdSi2R7Lzcrm%mp+d@v6shell.org> <493A9218.7070603@macports.org> <493ab09c.cCuxHoCf8C8DDfTm%mp+d@v6shell.org> Message-ID: <493AB3B9.9090509@pogma.com> J.A. Neitzel wrote: > > It seems to be related to the GNU autotools. According to [1], > adding "datarootdir = @datarootdir@" to Makefile.in might help? > Sorry, I do not know or use GNU autotools. The test in autoconf is not very smart, @datarootdir@ appears in macports.autoconf.mk.in, but autoconf looks for it in Makefile.in. So this is just a harmless warning. If it did not appear at all, you'd find stuff installed to /share instead of /opt/local/share. Peter -- Peter O'Gorman http://pogma.com From peter at pogma.com Sat Dec 6 09:22:02 2008 From: peter at pogma.com (Peter O'Gorman) Date: Sat, 06 Dec 2008 11:22:02 -0600 Subject: release_1_7_0-beta1 test results In-Reply-To: <493AB3B9.9090509@pogma.com> References: <493a2289.Q7jbCdSi2R7Lzcrm%mp+d@v6shell.org> <493A9218.7070603@macports.org> <493ab09c.cCuxHoCf8C8DDfTm%mp+d@v6shell.org> <493AB3B9.9090509@pogma.com> Message-ID: <493AB4BA.1070108@pogma.com> Peter O'Gorman wrote: > J.A. Neitzel wrote: > >> It seems to be related to the GNU autotools. According to [1], >> adding "datarootdir = @datarootdir@" to Makefile.in might help? >> Sorry, I do not know or use GNU autotools. > > The test in autoconf is not very smart, @datarootdir@ appears in > macports.autoconf.mk.in, but autoconf looks for it in Makefile.in. So > this is just a harmless warning. If it did not appear at all, you'd find > stuff installed to /share instead of /opt/local/share. I should have read the manual before posting. http://www.gnu.org/software/autoconf/manual/html_node/Changed-Directory-Variables.html " In some cases, however, the checks may not be able to detect that a suitable initialization of datarootdir is in place, or they may fail to detect that such an initialization is necessary in the output file. If, after auditing your package, there are still spurious configure warnings about datarootdir, you may add the line AC_DEFUN([AC_DATAROOTDIR_CHECKED]) to your configure.ac to disable the warnings." From ram at macports.org Sat Dec 6 17:51:19 2008 From: ram at macports.org (Adam Mercer) Date: Sat, 6 Dec 2008 19:51:19 -0600 Subject: [43102] trunk/dports/python In-Reply-To: <20081205080515.DEBAF853F64@beta.macosforge.org> References: <20081205080515.DEBAF853F64@beta.macosforge.org> Message-ID: <799406d60812061751i55c46083h83730f64d55af537@mail.gmail.com> On Fri, Dec 5, 2008 at 02:05, wrote: > Revision 43102 Author mcalhoun at macports.org Date 2008-12-05 00:05:10 -0800 > (Fri, 05 Dec 2008) > > Log Message > > py26-numpy: New Port I was under the impression from upstream that numpy will not be fully compatible with python26 on Mac OS X until 1.3.0, which is currently scheduled for around Christmas, what testing have you done with this? Cheers Adam From ram at macports.org Sat Dec 6 18:09:09 2008 From: ram at macports.org (Adam Mercer) Date: Sat, 6 Dec 2008 20:09:09 -0600 Subject: [43150] trunk/dports/python In-Reply-To: <20081205234952.C8327865076@beta.macosforge.org> References: <20081205234952.C8327865076@beta.macosforge.org> Message-ID: <799406d60812061809l47d404bboc6a1305659f5ba7d@mail.gmail.com> On Fri, Dec 5, 2008 at 17:49, wrote: > Revision 43150 > Author jmr at macports.org Date > 2008-12-05 15:49:52 -0800 (Fri, 05 Dec 2008) > > Log Message > > New port: py26-scipy > > Modified Paths > > trunk/dports/python/py26-scipy/Portfile > > Added Paths > > trunk/dports/python/py26-scipy/ > trunk/dports/python/py26-scipy/files/patch-abs-r4767.diff I was under the impression from upstream that scipy will not be compatible with python26 until 0.7.0 (0.7.0rc1 is scheduled to be tagged pretty soon). I assume the above patch solved the superlu compilation problem but does it looks like it doesn't solve the related issue reported in this upstream message: http://projects.scipy.org/pipermail/scipy-dev/2008-November/010155.html I get quite a few errors when running the test suite, most related to the above issue. FAILED (failures=1, errors=99) Cheers Adam From lists-macports at shopwatch.org Sat Dec 6 18:24:45 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Sat, 06 Dec 2008 21:24:45 -0500 Subject: 1.7.0 beta: working great! Message-ID: <493B33ED.7080804@shopwatch.org> I usually have all sorts of bad luck with the TCL environment bug, dependencies, etc. I just did a port upgrade on all my outdated ports - about 8 or 9 of them, including ImageMagick, which is known for never building easily - and it worked perfectly. OSX 10.5.5, Mac Pro (early 2008). Woohoo. Jay From jeremyhu at macports.org Sat Dec 6 19:48:48 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 6 Dec 2008 19:48:48 -0800 Subject: autoreconf.env - ACLOCAL Message-ID: I'd like to see the following added to autoreconf.env autoreconf.env ACLOCAL="aclocal -I ${prefix}/share/aclocal -I $ {x11prefix}/share/aclocal" That way we'll pick up m4 macros from /usr/X11/share/aclocal if they're using the system libs on Leopard or later. Thoughts? From mcalhoun at macports.org Sat Dec 6 20:52:59 2008 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Sun, 7 Dec 2008 04:52:59 +0000 (UTC) Subject: [43102] trunk/dports/python References: <20081205080515.DEBAF853F64@beta.macosforge.org> <799406d60812061751i55c46083h83730f64d55af537@mail.gmail.com> Message-ID: Adam Mercer writes: > I was under the impression from upstream that numpy will not be fully > compatible with python26 on Mac OS X until 1.3.0, which is currently > scheduled for around Christmas, what testing have you done with this? You are correct. /opt/local/bin/python2.6 -c 'import numpy; numpy.test()' failes in the same way as http://projects.scipy.org/ /pipermail/numpy-tickets/2008-September/002329.html py26-numpy compiled and worked for my limited needs. That is as far as I had gotten. Since a fix should be available reasonable soon, I just added a warning in r43208. -Marcus From frstan at bellsouth.net Sat Dec 6 23:19:56 2008 From: frstan at bellsouth.net (William Davis) Date: Sun, 7 Dec 2008 02:19:56 -0500 Subject: [43102] trunk/dports/python In-Reply-To: References: <20081205080515.DEBAF853F64@beta.macosforge.org> <799406d60812061751i55c46083h83730f64d55af537@mail.gmail.com> Message-ID: <4C050C8B-3844-44C5-B7B5-BDEC89DD8B6B@bellsouth.net> On Dec 6, 2008, at 11:52 PM, Marcus Calhoun-Lopez wrote: > /opt/local/bin/python2.6 -c 'import numpy; numpy.test()' when I ran this it produced: Ran 1740 tests in 12.286s FAILED (KNOWNFAIL=1, errors=1, failures=1) macintosh:~ frstan$ William Davis frstanATbellsouthDOTnet Mac OS X.5.5 Darwin 9.5.0 XQuartz 2.3.2_rc2 (xorg-server 1.4.2-apple25) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From ryandesign at macports.org Sun Dec 7 01:16:59 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 7 Dec 2008 03:16:59 -0600 Subject: [43188] trunk/dports/x11/xorg-server/Portfile In-Reply-To: <20081207012256.474A0874DF7@beta.macosforge.org> References: <20081207012256.474A0874DF7@beta.macosforge.org> Message-ID: On Dec 6, 2008, at 19:22, jeremyhu at macports.org wrote: > +post-destroot { > + system "ln -s Xquartz ${prefix}/bin/X" > +} You don't need to use "system" to make a symlink; just write: ln -s Xquartz ${prefix}/bin/X From blb at macports.org Sun Dec 7 01:44:39 2008 From: blb at macports.org (Bryan Blackburn) Date: Sun, 7 Dec 2008 02:44:39 -0700 Subject: 1.7.0 release candidate 1 available for testing Message-ID: <20081207094439.GM847@ninagal.withay.com> I've created a tag for the first release candidate for 1.7.0 [1]; most of the changes from beta1 involve the script which updates sources.conf to include a [default] tag for the default MacPorts repository. Two code changes were made: one to better set configure.* variables to sane default values even if the configure phase is overridden (#17426), and the other to fix use_lzma support (#16788). The rest of the changes involve building a DMG for distribution so should have only affected me (and maybe Anders)... You can either checkout the code from [1] via svn, or if you're not in the mood, I've put both the source tarball and DMGs for 10.3-10.5 in my svn homedir [2]. Bryan [1] - [2] - From jeremyhu at macports.org Sun Dec 7 01:51:47 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 7 Dec 2008 01:51:47 -0800 Subject: [43188] trunk/dports/x11/xorg-server/Portfile In-Reply-To: References: <20081207012256.474A0874DF7@beta.macosforge.org> Message-ID: <1DB154F1-2D6E-4287-A126-A66202A771D2@macports.org> On Dec 7, 2008, at 01:16, Ryan Schmidt wrote: > On Dec 6, 2008, at 19:22, jeremyhu at macports.org wrote: > >> +post-destroot { >> + system "ln -s Xquartz ${prefix}/bin/X" >> +} > > You don't need to use "system" to make a symlink; just write: > > ln -s Xquartz ${prefix}/bin/X tcl scares me. Give me time, and I'll adapt ;) --Jeremy From ryandesign at macports.org Sun Dec 7 02:02:33 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 7 Dec 2008 04:02:33 -0600 Subject: [43176] trunk/dports/x11/lesstif/Portfile In-Reply-To: <20081206224839.072FF8731CD@beta.macosforge.org> References: <20081206224839.072FF8731CD@beta.macosforge.org> Message-ID: <44A53844-530C-4366-AC8E-C4DCB5B7F6C6@macports.org> On Dec 6, 2008, at 16:48, jeremyhu at macports.org wrote: > Revision: 43176 > http://trac.macports.org/changeset/43176 > Author: jeremyhu at macports.org > Date: 2008-12-06 14:48:38 -0800 (Sat, 06 Dec 2008) > Log Message: > ----------- > lesstif: Install to correct prefix. Fixes bug #17508 - maintainer > timeout Also you changed the dependencies, added the homepage variable, and turned off the universal variant. I'm sure these are fine changes, but make sure your log messages describe everything you do, and ideally say why if it's not obvious. You added the homepage because it is a required variable and port lint probably reminded you of that; you changed dependencies because you probably found with otool -L that lesstif did link against all those things; and I'm not sure why you turned off the universal variant, but probably because you either got an error building or it didn't end up building universal, or one of the dependencies isn't universal. > Modified Paths: > -------------- > trunk/dports/x11/lesstif/Portfile > > Modified: trunk/dports/x11/lesstif/Portfile > =================================================================== > --- trunk/dports/x11/lesstif/Portfile 2008-12-06 22:47:27 UTC (rev > 43175) > +++ trunk/dports/x11/lesstif/Portfile 2008-12-06 22:48:38 UTC (rev > 43176) > @@ -3,18 +3,29 @@ > PortSystem 1.0 > name lesstif > version 0.95.0 > +revision 1 > categories x11 > maintainers lomion at mac.com > description An Open Source implementation of OSF/Motif. > long_description This is an independent implementation of the > Motif widget set, originally developed by the Hungry Programmers. > It has been somewhat superceded by the openMotif toolkit now that > the OSF has open-sourced the original reference bits. > platforms darwin > +homepage http://www.lesstif.org > master_sites sourceforge > checksums md5 ab895165c149d7f95843c7584b1c7ad4 > use_bzip2 yes > -depends_lib lib:libX11.6:XFree86 > -prefix ${x11prefix} > configure.args --enable-production --without-freetype-includes > +universal_variant no > > +depends_lib \ > + lib:libICE.6:xorg-libice \ > + lib:libSM.6:xorg-libsm \ > + lib:libX11.6:xorg-libX11 \ > + lib:libXau.6:xorg-libXau \ > + lib:libXdmcp.6:xorg-libXdmcp \ > + lib:libXext.6:xorg-libXext \ > + lib:libXp.6:xorg-libXp \ > + lib:libXt.6:xorg-libXt > + > variant motif12 { configure.args-append --enable-build-12 } > variant motif20 { configure.args-append --enable-build-20 } > variant xdnd { configure.args-append --enable-xdnd } From ryandesign at macports.org Sun Dec 7 02:06:50 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 7 Dec 2008 04:06:50 -0600 Subject: [43207] trunk/dports/x11/openmotif/Portfile In-Reply-To: <20081207041326.8653D876BA5@beta.macosforge.org> References: <20081207041326.8653D876BA5@beta.macosforge.org> Message-ID: On Dec 6, 2008, at 22:13, jeremyhu at macports.org wrote: > Revision: 43207 > http://trac.macports.org/changeset/43207 > Author: jeremyhu at macports.org > Date: 2008-12-06 20:13:25 -0800 (Sat, 06 Dec 2008) > Log Message: > ----------- > openmotif: updated configure.args to properly build. updated depends. In what way did you find openmotif didn't build properly? It seemed to build properly for me when I updated it to 2.3.1-1 recently, though I only tested on Tiger on Intel, and I don't really know what to do with openmotif once it's installed so I didn't test it. From ryandesign at macports.org Sun Dec 7 02:12:43 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 7 Dec 2008 04:12:43 -0600 Subject: 1.7.0 beta: working great! In-Reply-To: <493B33ED.7080804@shopwatch.org> References: <493B33ED.7080804@shopwatch.org> Message-ID: <43830B6B-FCC8-40B8-ADFB-86C044BF2327@macports.org> On Dec 6, 2008, at 20:24, Jay Levitt wrote: > I usually have all sorts of bad luck with the TCL environment bug, I'm sure everybody running MacPorts 1.6.0 on Leopard does. > dependencies, etc. What dependency problems do you mean? > I just did a port upgrade on all my outdated ports - about 8 or 9 > of them, including ImageMagick, which is known for never building > easily - What ImageMagick build problems are you talking about? I'm not aware of any. > and it worked perfectly. I'm glad to hear it! > OSX 10.5.5, Mac Pro (early 2008). Woohoo. From ryandesign at macports.org Sun Dec 7 02:31:53 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 7 Dec 2008 04:31:53 -0600 Subject: 1.7.0 release candidate 1 available for testing In-Reply-To: <20081207094439.GM847@ninagal.withay.com> References: <20081207094439.GM847@ninagal.withay.com> Message-ID: <0D412574-6004-4D81-BA2D-CAC5F5DF6C74@macports.org> On Dec 7, 2008, at 03:44, Bryan Blackburn wrote: > I've created a tag for the first release candidate for 1.7.0 [1]; > most of > the changes from beta1 involve the script which updates > sources.conf to > include a [default] tag for the default MacPorts repository. > > Two code changes were made: one to better set configure.* variables > to sane > default values even if the configure phase is overridden (#17426), > and the > other to fix use_lzma support (#16788). > > The rest of the changes involve building a DMG for distribution so > should > have only affected me (and maybe Anders)... > > You can either checkout the code from [1] via svn, or if you're not > in the > mood, I've put both the source tarball and DMGs for 10.3-10.5 in my > svn > homedir [2]. > > Bryan > > [1] - release_1_7_0-rc1> > [2] - Thanks for taking the initiative with the 1.7.0 release here. Is there a reason we don't put the 1.7.0-rc1 files in the regular downloads directory? http://trac.macports.org/browser/downloads From ryandesign at macports.org Sun Dec 7 02:34:19 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 7 Dec 2008 04:34:19 -0600 Subject: [43188] trunk/dports/x11/xorg-server/Portfile In-Reply-To: <1DB154F1-2D6E-4287-A126-A66202A771D2@macports.org> References: <20081207012256.474A0874DF7@beta.macosforge.org> <1DB154F1-2D6E-4287-A126-A66202A771D2@macports.org> Message-ID: <60774615-3D01-42DF-B69A-5CFAC0EEABF4@macports.org> On Dec 7, 2008, at 03:51, Jeremy Huddleston wrote: > On Dec 7, 2008, at 01:16, Ryan Schmidt wrote: > >> On Dec 6, 2008, at 19:22, jeremyhu at macports.org wrote: >> >>> +post-destroot { >>> + system "ln -s Xquartz ${prefix}/bin/X" >>> +} >> >> You don't need to use "system" to make a symlink; just write: >> >> ln -s Xquartz ${prefix}/bin/X > > tcl scares me. Give me time, and I'll adapt ;) :) Actually, this was wrong anyway: you need to create the symlink (like everything else) in the destroot. So you need: ln -s Xquartz ${destroot}${prefix}/bin/X From jmr at macports.org Sun Dec 7 02:34:55 2008 From: jmr at macports.org (Joshua Root) Date: Sun, 07 Dec 2008 21:34:55 +1100 Subject: [43102] trunk/dports/python In-Reply-To: <799406d60812061751i55c46083h83730f64d55af537@mail.gmail.com> References: <20081205080515.DEBAF853F64@beta.macosforge.org> <799406d60812061751i55c46083h83730f64d55af537@mail.gmail.com> Message-ID: <493BA6CF.1040501@macports.org> Adam Mercer wrote: > On Fri, Dec 5, 2008 at 02:05, wrote: >> Revision 43102 Author mcalhoun at macports.org Date 2008-12-05 00:05:10 -0800 >> (Fri, 05 Dec 2008) >> >> Log Message >> >> py26-numpy: New Port > > I was under the impression from upstream that numpy will not be fully > compatible with python26 on Mac OS X until 1.3.0, which is currently > scheduled for around Christmas, what testing have you done with this? I don't know how broken it it in general, but I know it works enough for pyopengl to work. - Josh From jmr at macports.org Sun Dec 7 02:45:41 2008 From: jmr at macports.org (Joshua Root) Date: Sun, 07 Dec 2008 21:45:41 +1100 Subject: [43150] trunk/dports/python In-Reply-To: <799406d60812061809l47d404bboc6a1305659f5ba7d@mail.gmail.com> References: <20081205234952.C8327865076@beta.macosforge.org> <799406d60812061809l47d404bboc6a1305659f5ba7d@mail.gmail.com> Message-ID: <493BA955.2050000@macports.org> Adam Mercer wrote: > On Fri, Dec 5, 2008 at 17:49, wrote: >> Revision 43150 >> Author jmr at macports.org Date >> 2008-12-05 15:49:52 -0800 (Fri, 05 Dec 2008) >> >> Log Message >> >> New port: py26-scipy >> >> Modified Paths >> >> trunk/dports/python/py26-scipy/Portfile >> >> Added Paths >> >> trunk/dports/python/py26-scipy/ >> trunk/dports/python/py26-scipy/files/patch-abs-r4767.diff > > I was under the impression from upstream that scipy will not be > compatible with python26 until 0.7.0 (0.7.0rc1 is scheduled to be > tagged pretty soon). I assume the above patch solved the superlu > compilation problem but does it looks like it doesn't solve the > related issue reported in this upstream message: > > http://projects.scipy.org/pipermail/scipy-dev/2008-November/010155.html > > I get quite a few errors when running the test suite, most related to > the above issue. > > FAILED (failures=1, errors=99) > You're right of course. I added a warning like numpy's in r43239. - Josh From jmr at macports.org Sun Dec 7 02:56:03 2008 From: jmr at macports.org (Joshua Root) Date: Sun, 07 Dec 2008 21:56:03 +1100 Subject: [43188] trunk/dports/x11/xorg-server/Portfile In-Reply-To: References: <20081207012256.474A0874DF7@beta.macosforge.org> Message-ID: <493BABC3.7050208@macports.org> Ryan Schmidt wrote: > On Dec 6, 2008, at 19:22, jeremyhu at macports.org wrote: > >> +post-destroot { >> + system "ln -s Xquartz ${prefix}/bin/X" >> +} > > You don't need to use "system" to make a symlink; just write: > > ln -s Xquartz ${prefix}/bin/X Actually I think maybe you do in this case. Tcl's 'file link' won't work when the specified link target doesn't exist. A real problem, though, is that the link should be created in ${destroot}${prefix}, not ${prefix}. - Josh From jeremyhu at macports.org Sun Dec 7 02:56:52 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 7 Dec 2008 02:56:52 -0800 Subject: [43207] trunk/dports/x11/openmotif/Portfile In-Reply-To: References: <20081207041326.8653D876BA5@beta.macosforge.org> Message-ID: <12F40180-94EF-4528-9492-41164022510D@macports.org> On Dec 7, 2008, at 02:06, Ryan Schmidt wrote: > > On Dec 6, 2008, at 22:13, jeremyhu at macports.org wrote: > >> Revision: 43207 >> http://trac.macports.org/changeset/43207 >> Author: jeremyhu at macports.org >> Date: 2008-12-06 20:13:25 -0800 (Sat, 06 Dec 2008) >> Log Message: >> ----------- >> openmotif: updated configure.args to properly build. updated >> depends. > > In what way did you find openmotif didn't build properly? It seemed > to build properly for me when I updated it to 2.3.1-1 recently, > though I only tested on Tiger on Intel, and I don't really know what > to do with openmotif once it's installed so I didn't test it. It was a freetype issue. We were setting the include path for freetype.h to /opt/local/include, but it's really in /opt/local/ include/freetype2 (or something similar), so removing that explicit line and letting it figure it out from freetype-config worked better. From simon at ruderich.org Sun Dec 7 04:46:41 2008 From: simon at ruderich.org (Simon Ruderich) Date: Sun, 7 Dec 2008 13:46:41 +0100 Subject: [43026] trunk/dports/devel/git-core/Portfile In-Reply-To: <49370894.2020604@macports.org> References: <20081203210310.8EBC7821FDC@beta.macosforge.org> <799406d60812031308k276e2e3dm5736c6c17c2191cd@mail.gmail.com> <20081203215809.GA18364@ruderich.org> <49370894.2020604@macports.org> Message-ID: <20081207124640.GA19923@ruderich.org> On Thu, Dec 04, 2008 at 09:30:44AM +1100, Joshua Root wrote: > Could be that git-core includes code that uses unixODBC only if the > latter is present at build time. If so, the alternative solution would > be to make sure it never includes that support. > > - Josh That would be a good solution. Unfortunately I don't know enough about git-svn's internals. 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: From lists-macports at shopwatch.org Sun Dec 7 08:40:32 2008 From: lists-macports at shopwatch.org (Jay Levitt) Date: Sun, 07 Dec 2008 11:40:32 -0500 Subject: 1.7.0 beta: working great! In-Reply-To: <43830B6B-FCC8-40B8-ADFB-86C044BF2327@macports.org> References: <493B33ED.7080804@shopwatch.org> <43830B6B-FCC8-40B8-ADFB-86C044BF2327@macports.org> Message-ID: <493BFC80.6040609@shopwatch.org> Ryan Schmidt wrote: > > On Dec 6, 2008, at 20:24, Jay Levitt wrote: > >> I usually have all sorts of bad luck with the TCL environment bug, > > I'm sure everybody running MacPorts 1.6.0 on Leopard does. > >> dependencies, etc. > > What dependency problems do you mean? I'm not entirely sure, because I hadn't been paying attention until the 1.7.0 train started rolling in. I just have vague memories of "can't install this thing". >> I just did a port upgrade on all my outdated ports - about 8 or 9 of >> them, including ImageMagick, which is known for never building easily - > > What ImageMagick build problems are you talking about? I'm not aware of > any. I used to build it from source all the time, and on every machine I ever tried (whether Windows or Mac or Linux), there was some not-quite-anticipated dependency on a system library that was the wrong version but that autoconf thought was good, or something like that.. this was a while ago. Recently, I know I tried installing the latest ImageMagick with MacPorts 1.6.0 on a Mac that already had a previous version, and I remember an error about having to manually deactivate the one port before activating the new one - an error I didn't get when I upgraded with 1.7.0. Jay From mp+d at v6shell.org Sun Dec 7 10:17:00 2008 From: mp+d at v6shell.org (J.A. Neitzel) Date: Sun, 07 Dec 2008 18:17:00 +0000 Subject: 1.7.0 release candidate 1 available for testing In-Reply-To: <20081207094439.GM847@ninagal.withay.com> References: <20081207094439.GM847@ninagal.withay.com> Message-ID: <493c131c.CYPSgo0mBjKy1qGz%mp+d@v6shell.org> > I've created a tag for the first release candidate for 1.7.0 [1]; most of > the changes from beta1 involve the script which updates sources.conf to > include a [default] tag for the default MacPorts repository. [snip] Except for the previously mentioned ./configure warning and the following version number hiccup from selfupdate: MacPorts base version 1.700 installed DEBUG: Rebuilding and reinstalling MacPorts if needed Downloaded MacPorts base version 1.600 ... 1.7.0 release candidate 1 is performing as expected for me so far. -- J.A. Neitzel V6 Thompson Shell Port - http://v6shell.org/ From mp+d at v6shell.org Sun Dec 7 10:35:44 2008 From: mp+d at v6shell.org (J.A. Neitzel) Date: Sun, 07 Dec 2008 18:35:44 +0000 Subject: 1.7.0 release candidate 1 available for testing In-Reply-To: <493c131c.CYPSgo0mBjKy1qGz%mp+d@v6shell.org> References: <20081207094439.GM847@ninagal.withay.com> <493c131c.CYPSgo0mBjKy1qGz%mp+d@v6shell.org> Message-ID: <493c1780.DUoQaxajUkUtuJt2%mp+d@v6shell.org> > Except for the previously mentioned ./configure warning Here are the details about it from my previous post. I guess it is some sort of autoconf weirdness. > The only anomaly I have noticed so far is: > > % ./configure > [snip] > configure: creating ./config.status > config.status: creating src/programs/daemondo/Makefile > config.status: WARNING: src/programs/daemondo/Makefile.in seems to \ > ignore the --datarootdir setting > config.status: creating Doxyfile > config.status: creating Makefile > [snip] > > ... > which may or may not be important. It seems to be related to the GNU autotools. According to [1], adding "datarootdir = @datarootdir@" to Makefile.in might help? Sorry, I do not know or use GNU autotools. Jeff [1] - http://www.gnu.org/software/automake/manual/autoconf/Changed-Directory-Variables.html -- J.A. Neitzel V6 Thompson Shell Port - http://v6shell.org/ From jmpp at macports.org Sun Dec 7 12:12:34 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun, 7 Dec 2008 15:42:34 -0430 Subject: Moving MacPorts to the x.y.z version format internally for 1.7.1/1.8.0 Message-ID: <556BA986-F83C-4F01-B73E-F8B2E91A2500@macports.org> A while ago I did most of the needed work to move MacPorts to a more standard version number formatting, that is x.y.z, both for its internal workings (e.g. selfupdate) and for the UI. If I'm not mistaken, most of that code has not been released to the public yet, which is why the change can't just be pushed onto people in a single release because of the way version numbers used to be compared previously (simple mathematical comparison, through which, e.g., 1.610 > 1.7.0). Once 1.7.0 is released, the code I wrote (in base/src/ macports/macports.tcl, proc macports::selfupdate) will be in people's hands and a comparison between 1.700 Vs. 1.7.1 will work positively either through rpm-vercomp or a simple forcing of the selfupdate. Therefore I propose MacPorts name its next release after 1.7.0 (1.700) either 1.7.1 or 1.8.0, but in any case in the more standard x.y.z formatting. Attached is a patch to finish this work, which should *NOT* be applied to the 1.7.0 (1.700) release. It's been quite a while since I made the first round of changes, so there's a chance this fresh patch is incomplete in some way (admittedly, I haven't tested it yet). So please review and complete if needed. I'd appreciated it if release engineering considered this work for inclusion in trunk/release_1_7, thanks! Regards,... -jmpp -------------- next part -------------- A non-text attachment was scrubbed... Name: macports_x.y.z_version.diff Type: application/octet-stream Size: 2501 bytes Desc: not available URL: -------------- next part -------------- From jmpp at macports.org Sun Dec 7 12:17:16 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun, 7 Dec 2008 15:47:16 -0430 Subject: Moving MacPorts to the x.y.z version format internally for 1.7.1/1.8.0 In-Reply-To: <556BA986-F83C-4F01-B73E-F8B2E91A2500@macports.org> References: <556BA986-F83C-4F01-B73E-F8B2E91A2500@macports.org> Message-ID: <7AAE7F64-6568-4EB5-9D2A-EBDCD6F25248@macports.org> On Dec 7, 2008, at 3:42 PM, Juan Manuel Palacios wrote: > > A while ago I did most of the needed work to move MacPorts to a > more standard version number formatting, that is x.y.z, both for its > internal workings (e.g. selfupdate) and for the UI. If I'm not > mistaken, most of that code has not been released to the public yet, > which is why the change can't just be pushed onto people in a single > release because of the way version numbers used to be compared > previously (simple mathematical comparison, through which, e.g., > 1.610 > 1.7.0). Once 1.7.0 is released, the code I wrote (in base/ > src/macports/macports.tcl, proc macports::selfupdate) will be in > people's hands and a comparison between 1.700 Vs. 1.7.1 will work > positively either through rpm-vercomp or a simple forcing of the > selfupdate. > > Therefore I propose MacPorts name its next release after 1.7.0 > (1.700) either 1.7.1 or 1.8.0, but in any case in the more standard > x.y.z formatting. Attached is a patch to finish this work, which > should *NOT* be applied to the 1.7.0 (1.700) release. It's been > quite a while since I made the first round of changes, so there's a > chance this fresh patch is incomplete in some way (admittedly, I > haven't tested it yet). So please review and complete if needed. > > I'd appreciated it if release engineering considered this work for > inclusion in trunk/release_1_7, thanks! > > Regards,... > > > -jmpp > > Two things I forgot to mention: 1) An autoreconf would be needed after modifying the configure.ac file; 2) The base/config/mp_version file could be safely deleted if my work is indeed complete; Do let me know if I'm missing anything, thanks! -jmpp From blb at macports.org Sun Dec 7 12:40:04 2008 From: blb at macports.org (Bryan Blackburn) Date: Sun, 7 Dec 2008 13:40:04 -0700 Subject: 1.7.0 release candidate 1 available for testing In-Reply-To: <0D412574-6004-4D81-BA2D-CAC5F5DF6C74@macports.org> References: <20081207094439.GM847@ninagal.withay.com> <0D412574-6004-4D81-BA2D-CAC5F5DF6C74@macports.org> Message-ID: <20081207204004.GD506@ninagal.withay.com> On Sun, Dec 07, 2008 at 04:31:53AM -0600, Ryan Schmidt said: > On Dec 7, 2008, at 03:44, Bryan Blackburn wrote: [...] >> >> [1] - > release_1_7_0-rc1> >> [2] - > > Thanks for taking the initiative with the 1.7.0 release here. > > > Is there a reason we don't put the 1.7.0-rc1 files in the regular > downloads directory? > > http://trac.macports.org/browser/downloads I chose putting it in /users since it's not a final release, so I don't want anyone seeing 1.7.0 under downloads and thinking otherwise; also, I've heard MacUpdate has an automated method for detecting new versions and I don't want it to pick up a release candidate and show it as the current version. Note that from what I've found, DMGs have only been offered for final releases in the past, so we have no policy about this. So I would say now is a good time to create one. Bryan From blb at macports.org Sun Dec 7 12:41:48 2008 From: blb at macports.org (Bryan Blackburn) Date: Sun, 7 Dec 2008 13:41:48 -0700 Subject: 1.7.0 release candidate 1 available for testing In-Reply-To: <493c131c.CYPSgo0mBjKy1qGz%mp+d@v6shell.org> References: <20081207094439.GM847@ninagal.withay.com> <493c131c.CYPSgo0mBjKy1qGz%mp+d@v6shell.org> Message-ID: <20081207204148.GE506@ninagal.withay.com> On Sun, Dec 07, 2008 at 06:17:00PM +0000, J.A. Neitzel said: > > I've created a tag for the first release candidate for 1.7.0 [1]; most of > > the changes from beta1 involve the script which updates sources.conf to > > include a [default] tag for the default MacPorts repository. > > [snip] > > Except for the previously mentioned ./configure warning and the > following version number hiccup from selfupdate: > > MacPorts base version 1.700 installed > DEBUG: Rebuilding and reinstalling MacPorts if needed > Downloaded MacPorts base version 1.600 This isn't a hiccup since the rsync server which offers the code for selfupdate is still at 1.6, since 1.7 is still in testing. It shouldn't have actually downgraded though, right? 'port version' still says 1.700? Bryan > > ... > 1.7.0 release candidate 1 is performing as expected for me so far. > -- > J.A. Neitzel > V6 Thompson Shell Port - http://v6shell.org/ From blb at macports.org Sun Dec 7 12:44:03 2008 From: blb at macports.org (Bryan Blackburn) Date: Sun, 7 Dec 2008 13:44:03 -0700 Subject: Moving MacPorts to the x.y.z version format internally for 1.7.1/1.8.0 In-Reply-To: <7AAE7F64-6568-4EB5-9D2A-EBDCD6F25248@macports.org> References: <556BA986-F83C-4F01-B73E-F8B2E91A2500@macports.org> <7AAE7F64-6568-4EB5-9D2A-EBDCD6F25248@macports.org> Message-ID: <20081207204403.GF506@ninagal.withay.com> On Sun, Dec 07, 2008 at 03:47:16PM -0430, Juan Manuel Palacios said: > > On Dec 7, 2008, at 3:42 PM, Juan Manuel Palacios wrote: > >> >> A while ago I did most of the needed work to move MacPorts to a more >> standard version number formatting, that is x.y.z, both for its >> internal workings (e.g. selfupdate) and for the UI. If I'm not >> mistaken, most of that code has not been released to the public yet, >> which is why the change can't just be pushed onto people in a single >> release because of the way version numbers used to be compared >> previously (simple mathematical comparison, through which, e.g., 1.610 > >> 1.7.0). Once 1.7.0 is released, the code I wrote (in base/ >> src/macports/macports.tcl, proc macports::selfupdate) will be in >> people's hands and a comparison between 1.700 Vs. 1.7.1 will work >> positively either through rpm-vercomp or a simple forcing of the >> selfupdate. >> >> Therefore I propose MacPorts name its next release after 1.7.0 (1.700) >> either 1.7.1 or 1.8.0, but in any case in the more standard x.y.z >> formatting. Attached is a patch to finish this work, which should *NOT* >> be applied to the 1.7.0 (1.700) release. It's been quite a while since I >> made the first round of changes, so there's a chance this fresh patch is >> incomplete in some way (admittedly, I haven't tested it yet). So please >> review and complete if needed. >> >> I'd appreciated it if release engineering considered this work for >> inclusion in trunk/release_1_7, thanks! >> >> Regards,... >> >> >> -jmpp >> >> > > > Two things I forgot to mention: > > 1) An autoreconf would be needed after modifying the configure.ac file; > 2) The base/config/mp_version file could be safely deleted if my work is > indeed complete; So this will basically take care of #17420: I did see some of the stuff you had done for moving to x.y.z fully, but wasn't aware of just how much was left to implement, hence the ticket. Bryan > > Do let me know if I'm missing anything, thanks! > > > -jmpp > From jmr at macports.org Sun Dec 7 12:55:21 2008 From: jmr at macports.org (Joshua Root) Date: Mon, 08 Dec 2008 07:55:21 +1100 Subject: 1.7.0 release candidate 1 available for testing In-Reply-To: <20081207204004.GD506@ninagal.withay.com> References: <20081207094439.GM847@ninagal.withay.com> <0D412574-6004-4D81-BA2D-CAC5F5DF6C74@macports.org> <20081207204004.GD506@ninagal.withay.com> Message-ID: <493C3839.9030900@macports.org> Bryan Blackburn wrote: > On Sun, Dec 07, 2008 at 04:31:53AM -0600, Ryan Schmidt said: >> On Dec 7, 2008, at 03:44, Bryan Blackburn wrote: > [...] >>> [1] - >> release_1_7_0-rc1> >>> [2] - >> Thanks for taking the initiative with the 1.7.0 release here. >> >> >> Is there a reason we don't put the 1.7.0-rc1 files in the regular >> downloads directory? >> >> http://trac.macports.org/browser/downloads > > I chose putting it in /users since it's not a final release, so I don't want > anyone seeing 1.7.0 under downloads and thinking otherwise; also, I've heard > MacUpdate has an automated method for detecting new versions and I don't > want it to pick up a release candidate and show it as the current version. > > Note that from what I've found, DMGs have only been offered for final > releases in the past, so we have no policy about this. So I would say now > is a good time to create one. Putting the non-final versions in a testing/ subdir should sufficiently distinguish them, I think. - Josh From ryandesign at macports.org Sun Dec 7 13:50:30 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 7 Dec 2008 15:50:30 -0600 Subject: 1.7.0 beta: working great! In-Reply-To: <493BFC80.6040609@shopwatch.org> References: <493B33ED.7080804@shopwatch.org> <43830B6B-FCC8-40B8-ADFB-86C044BF2327@macports.org> <493BFC80.6040609@shopwatch.org> Message-ID: <238A10DE-0A3A-4C33-B622-C7BF735D4D01@macports.org> On Dec 7, 2008, at 10:40, Jay Levitt wrote: > Ryan Schmidt wrote: >> On Dec 6, 2008, at 20:24, Jay Levitt wrote: >>> I usually have all sorts of bad luck with the TCL environment bug, >> I'm sure everybody running MacPorts 1.6.0 on Leopard does. >>> dependencies, etc. >> What dependency problems do you mean? > > I'm not entirely sure, because I hadn't been paying attention until > the 1.7.0 train started rolling in. I just have vague memories of > "can't install this thing". Ok, if you encounter a problem again, be sure to report it right away with exact error messages and such so that we can look into it. :) >>> I just did a port upgrade on all my outdated ports - about 8 or 9 >>> of them, including ImageMagick, which is known for never building >>> easily - >> What ImageMagick build problems are you talking about? I'm not >> aware of any. > > I used to build it from source all the time, and on every machine I > ever tried (whether Windows or Mac or Linux), there was some not- > quite-anticipated dependency on a system library that was the wrong > version but that autoconf thought was good, or something like > that.. this was a while ago. A great reason to use MacPorts -- it handles dependencies correctly for you, and only one person (the maintainer -- me for ImageMagick) has to figure out the quirks of the software, so that everyone else gets to install it as easy as "sudo port install ImageMagick". > Recently, I know I tried installing the latest ImageMagick with > MacPorts 1.6.0 on a Mac that already had a previous version, and I > remember an error about having to manually deactivate the one port > before activating the new one - an error I didn't get when I > upgraded with 1.7.0. If you already had an older version of the ImageMagick port installed, and then typed "sudo port install ImageMagick" to get the new one, then MacPorts will at the end issue an error message that it cannot activate the new version because another version is already active. That's the correct behavior. To deal with it, you need to then deactivate (and, if you like, uninstall) the old version, then activate the new version. To avoid all this, instead of typing "sudo port install ImageMagick" when you already have it installed, you should type "sudo port upgrade ImageMagick" which will cause MacPorts to first deactivate the old version before activating the new one. Or you can type "sudo port -u upgrade ImageMagick" to do that *and* uninstall the old version afterward. From jmpp at macports.org Sun Dec 7 13:57:31 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun, 7 Dec 2008 17:27:31 -0430 Subject: Moving MacPorts to the x.y.z version format internally for 1.7.1/1.8.0 In-Reply-To: <20081207204403.GF506@ninagal.withay.com> References: <556BA986-F83C-4F01-B73E-F8B2E91A2500@macports.org> <7AAE7F64-6568-4EB5-9D2A-EBDCD6F25248@macports.org> <20081207204403.GF506@ninagal.withay.com> Message-ID: On Dec 7, 2008, at 4:14 PM, Bryan Blackburn wrote: > So this will basically take care of #17420: > > In a way, yes: the logic to choose either the mp_version file or macports_version is in the currently 1.610 released sources of MacPorts, so if mp_version does not exist in the rsycn'd sources (coming from svn), users' installations will still catch the freshly downloaded macports_version file for the selfupdate run. So on that aspect we're safe to delete mp_version. However: > > > I did see some of the stuff you had done for moving to x.y.z fully, > but > wasn't aware of just how much was left to implement, hence the ticket. The way I see it (unless I'm brain dead at the moment and missing something incredibly obvious, or completely misunderstanding the way rpm-vercomp works), the real problem is in the contents of both files: -) mp_version contains 1.610 in the release_1_6 branch (what regular uses currently have), 1.700 in the release_1_7 branch (what will be released next); -) macports_version contains 1.6.1 and 1.7.0, respectively; -) in both 1.610 and 1.700, the necessity to rebuild base in a selfupdate run is as follows; from base/src/macprots1.0/macports.tcl: if {$use_the_force_luke == "yes" || [rpm-vercomp $macports_version_new $macports::autoconf::macports_version] > 0} { and $macports::autoconf::macports_version comes from base/src/ macports1.0/macports_autoconf.tcl.in: 36 variable macports_version "@MP_VERSION@" and @MP_VERSION@, in turn, is determined from base/config/mp_version in base/configure.ac: 15 # Read the old, floating point format version, which we still use internally, and export it for the $macports::autoconf::macports_version variable 16 MP_VERSION=$(cat config/mp_version | tr -d '\n') 17 AC_SUBST(MP_VERSION) So the real problem is determining when switching $macports::autoconf::macports_version from @MP_VERSION@ to @MACPORTS_VERSION@, the latter being determined from base/config/ macports_version, is appropriate. If done for 1.7.0, users' installations will be doing an rpm-vercom of 1.610.0 against 1.7.0, which will obviously fail. If we do it by 1.7.0, then it'll be 1.700.0 against 1.7.1, and I'm unsure of the result (though my guess is 1.7.1 < 1.700.0, which would also fail). Answering this question would clear the way to apply the patch I attached here originally (cf. my last comment in r32364). All this, of course, would be easily dealt with by instructing users to force the selfupdate, but do we really want to consider that as a alternative...? Regards,... -jmpp From jmpp at macports.org Sun Dec 7 14:00:48 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Sun, 7 Dec 2008 17:30:48 -0430 Subject: Moving MacPorts to the x.y.z version format internally for 1.7.1/1.8.0 In-Reply-To: References: <556BA986-F83C-4F01-B73E-F8B2E91A2500@macports.org> <7AAE7F64-6568-4EB5-9D2A-EBDCD6F25248@macports.org> <20081207204403.GF506@ninagal.withay.com> Message-ID: And, of course, reading my message a good number of times to assure accuracy still did not clear out all bugs! > If we do it by 1.7.0, then it'll be 1.700.0 against 1.7.1, and I'm > unsure of the result (though my guess is 1.7.1 < 1.700.0, which > would also fail). There I meant "if we do it by 1.7.1", of course. -jmpp From mp+d at v6shell.org Sun Dec 7 15:11:39 2008 From: mp+d at v6shell.org (J.A. Neitzel) Date: Sun, 07 Dec 2008 23:11:39 +0000 Subject: 1.7.0 release candidate 1 available for testing In-Reply-To: <20081207204148.GE506@ninagal.withay.com> References: <20081207094439.GM847@ninagal.withay.com> <493c131c.CYPSgo0mBjKy1qGz%mp+d@v6shell.org> <20081207204148.GE506@ninagal.withay.com> Message-ID: <493c582b.PCACQqjOqqHc6/Wu%mp+d@v6shell.org> Bryan Blackburn wrote: > On Sun, Dec 07, 2008 at 06:17:00PM +0000, J.A. Neitzel said: [snip] > > Except for the previously mentioned ./configure warning and the > > following version number hiccup from selfupdate: > > > > MacPorts base version 1.700 installed > > DEBUG: Rebuilding and reinstalling MacPorts if needed > > Downloaded MacPorts base version 1.600 > This isn't a hiccup since the rsync server which offers the code for > selfupdate is still at 1.6, since 1.7 is still in testing. It shouldn't > have actually downgraded though, right? 'port version' still says 1.700? Oops, my mistake; your description makes perfect sense in fact. Thanks for the info. Jeff > Bryan From ryandesign at macports.org Sun Dec 7 17:30:51 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 7 Dec 2008 19:30:51 -0600 Subject: [43188] trunk/dports/x11/xorg-server/Portfile In-Reply-To: <493BABC3.7050208@macports.org> References: <20081207012256.474A0874DF7@beta.macosforge.org> <493BABC3.7050208@macports.org> Message-ID: <26329F3F-929D-44BE-99E0-BEB88438BC8A@macports.org> On Dec 7, 2008, at 04:56, Joshua Root wrote: > Ryan Schmidt wrote: > >> On Dec 6, 2008, at 19:22, jeremyhu at macports.org wrote: >> >>> +post-destroot { >>> + system "ln -s Xquartz ${prefix}/bin/X" >>> +} >> >> You don't need to use "system" to make a symlink; just write: >> >> ln -s Xquartz ${prefix}/bin/X > > Actually I think maybe you do in this case. Tcl's 'file link' won't > work > when the specified link target doesn't exist. Xquartz doesn't exist? Why would we want to create a symlink to something that doesn't exist? > A real problem, though, is that the link should be created in > ${destroot}${prefix}, not ${prefix}. Right. From ryandesign at macports.org Sun Dec 7 17:47:46 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 7 Dec 2008 19:47:46 -0600 Subject: [43265] trunk/dports/textproc/doxygen/Portfile In-Reply-To: <20081207232041.1D0DC88408E@beta.macosforge.org> References: <20081207232041.1D0DC88408E@beta.macosforge.org> Message-ID: <4095DB8B-6F6D-4586-8E33-2C2059896183@macports.org> On Dec 7, 2008, at 17:20, css at macports.org wrote: > Revision: 43265 > http://trac.macports.org/changeset/43265 > Author: css at macports.org > Date: 2008-12-07 15:20:40 -0800 (Sun, 07 Dec 2008) > Log Message: > ----------- > Fixed syntax for the texlive dependency to match #12913, per request. > > Modified Paths: > -------------- > trunk/dports/textproc/doxygen/Portfile > > Modified: trunk/dports/textproc/doxygen/Portfile > =================================================================== > --- trunk/dports/textproc/doxygen/Portfile 2008-12-07 22:51:59 UTC > (rev 43264) > +++ trunk/dports/textproc/doxygen/Portfile 2008-12-07 23:20:40 UTC > (rev 43265) > @@ -70,7 +70,7 @@ > variant docs description {Include the doxygen PDF documentation > and LaTeX} { > build.target-append pdf > destroot.target-append install_docs > - depends_lib-append path:${prefix}/bin/pdflatex:texlive \ > + depends_lib-append path:pdflatex:texlive \ That doesn't work. It needs to be "path:bin/pdflatex:texlive" (if you want to ensure a pdflatex binary provided by a MacPorts port) or "bin:pdflatex:texlive" (if you want to allow a pdflatex binary anywhere in the binpath configured in the user's macports.conf). From blb at macports.org Sun Dec 7 18:59:34 2008 From: blb at macports.org (Bryan Blackburn) Date: Sun, 7 Dec 2008 19:59:34 -0700 Subject: 64bit variant naming scheme Message-ID: <20081208025934.GM506@ninagal.withay.com> Currently there are only a few ports with 64bit variants: nbench-byte +use_64_bit ubench +use_64_bit judy +bit64 john-devel +use_64_bit (john-devel was updated with 64bit support by me, picking the more common name). Before there are many more ports with such variants, we need to decide on a standard name; I found that +64bit isn't liked by port as it thinks that is the name of a port, not a variant so I guess it doesn't like a variant name to start with a number. The only issue I have with +use_64_bit is it's long and a pain to type... Bryan From jmr at macports.org Sun Dec 7 19:34:47 2008 From: jmr at macports.org (Joshua Root) Date: Mon, 08 Dec 2008 14:34:47 +1100 Subject: [43188] trunk/dports/x11/xorg-server/Portfile In-Reply-To: <26329F3F-929D-44BE-99E0-BEB88438BC8A@macports.org> References: <20081207012256.474A0874DF7@beta.macosforge.org> <493BABC3.7050208@macports.org> <26329F3F-929D-44BE-99E0-BEB88438BC8A@macports.org> Message-ID: <493C95D7.7010800@macports.org> Ryan Schmidt wrote: > > On Dec 7, 2008, at 04:56, Joshua Root wrote: > >> Ryan Schmidt wrote: >> >>> On Dec 6, 2008, at 19:22, jeremyhu at macports.org wrote: >>> >>>> +post-destroot { >>>> + system "ln -s Xquartz ${prefix}/bin/X" >>>> +} >>> >>> You don't need to use "system" to make a symlink; just write: >>> >>> ln -s Xquartz ${prefix}/bin/X >> >> Actually I think maybe you do in this case. Tcl's 'file link' won't work >> when the specified link target doesn't exist. > > Xquartz doesn't exist? Why would we want to create a symlink to > something that doesn't exist? ${destroot}${prefix}/bin/Xquartz exists, but Xquartz doesn't exist unless the interpreter's working directory is ${destroot}${prefix}/bin, which I don't think is the case. And to answer your question more generally, you often want to link to something in ${prefix} which won't be there until the port is activated. - Josh From jmr at macports.org Sun Dec 7 21:54:49 2008 From: jmr at macports.org (Joshua Root) Date: Mon, 08 Dec 2008 16:54:49 +1100 Subject: [43188] trunk/dports/x11/xorg-server/Portfile In-Reply-To: References: <20081207012256.474A0874DF7@beta.macosforge.org> <493BABC3.7050208@macports.org> <26329F3F-929D-44BE-99E0-BEB88438BC8A@macports.org> <493C95D7.7010800@macports.org> Message-ID: <493CB6A9.2050805@macports.org> Jeremy Huddleston wrote: > On Dec 7, 2008, at 19:34, Joshua Root wrote: >> Ryan Schmidt wrote: >>> On Dec 7, 2008, at 04:56, Joshua Root wrote: >>>> Ryan Schmidt wrote: >>>>> You don't need to use "system" to make a symlink; just write: >>>>> >>>>> ln -s Xquartz ${prefix}/bin/X >>>> >>>> Actually I think maybe you do in this case. Tcl's 'file link' won't >>>> work >>>> when the specified link target doesn't exist. >>> >>> Xquartz doesn't exist? Why would we want to create a symlink to >>> something that doesn't exist? >> >> ${destroot}${prefix}/bin/Xquartz exists, but Xquartz doesn't exist >> unless the interpreter's working directory is ${destroot}${prefix}/bin, >> which I don't think is the case. >> >> And to answer your question more generally, you often want to link to >> something in ${prefix} which won't be there until the port is activated. > > Right... but "Xquartz" is a relative-path link and what I was intending. I know that's what you intended, the point was I don't think Tcl would cope with it. Thus justifying your use of system post hoc. :-) - Josh From ryandesign at macports.org Sun Dec 7 21:58:14 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 7 Dec 2008 23:58:14 -0600 Subject: [43188] trunk/dports/x11/xorg-server/Portfile In-Reply-To: <493C95D7.7010800@macports.org> References: <20081207012256.474A0874DF7@beta.macosforge.org> <493BABC3.7050208@macports.org> <26329F3F-929D-44BE-99E0-BEB88438BC8A@macports.org> <493C95D7.7010800@macports.org> Message-ID: <8D4735FC-4BCD-49A6-AA04-F07CAFB5EC35@macports.org> On Dec 7, 2008, at 21:34, Joshua Root wrote: > Ryan Schmidt wrote: > >> On Dec 7, 2008, at 04:56, Joshua Root wrote: >> >>> Ryan Schmidt wrote: >>> >>>> On Dec 6, 2008, at 19:22, jeremyhu at macports.org wrote: >>>> >>>>> +post-destroot { >>>>> + system "ln -s Xquartz ${prefix}/bin/X" >>>>> +} >>>> >>>> You don't need to use "system" to make a symlink; just write: >>>> >>>> ln -s Xquartz ${prefix}/bin/X >>> >>> Actually I think maybe you do in this case. Tcl's 'file link' >>> won't work >>> when the specified link target doesn't exist. >> >> Xquartz doesn't exist? Why would we want to create a symlink to >> something that doesn't exist? > > ${destroot}${prefix}/bin/Xquartz exists, but Xquartz doesn't exist > unless the interpreter's working directory is ${destroot}${prefix}/ > bin, > which I don't think is the case. > > And to answer your question more generally, you often want to link to > something in ${prefix} which won't be there until the port is > activated. Surely MacPorts doesn't have a problem creating such symlinks... I do that in several of my ports: graphviz/graphviz-devel, oracle- instantclient... From jmr at macports.org Sun Dec 7 22:03:18 2008 From: jmr at macports.org (Joshua Root) Date: Mon, 08 Dec 2008 17:03:18 +1100 Subject: [43188] trunk/dports/x11/xorg-server/Portfile In-Reply-To: <8D4735FC-4BCD-49A6-AA04-F07CAFB5EC35@macports.org> References: <20081207012256.474A0874DF7@beta.macosforge.org> <493BABC3.7050208@macports.org> <26329F3F-929D-44BE-99E0-BEB88438BC8A@macports.org> <493C95D7.7010800@macports.org> <8D4735FC-4BCD-49A6-AA04-F07CAFB5EC35@macports.org> Message-ID: <493CB8A6.6050408@macports.org> Ryan Schmidt wrote: > > On Dec 7, 2008, at 21:34, Joshua Root wrote: > >> Ryan Schmidt wrote: >> >>> On Dec 7, 2008, at 04:56, Joshua Root wrote: >>> >>>> Ryan Schmidt wrote: >>>> >>>>> On Dec 6, 2008, at 19:22, jeremyhu at macports.org wrote: >>>>> >>>>>> +post-destroot { >>>>>> + system "ln -s Xquartz ${prefix}/bin/X" >>>>>> +} >>>>> >>>>> You don't need to use "system" to make a symlink; just write: >>>>> >>>>> ln -s Xquartz ${prefix}/bin/X >>>> >>>> Actually I think maybe you do in this case. Tcl's 'file link' won't >>>> work >>>> when the specified link target doesn't exist. >>> >>> Xquartz doesn't exist? Why would we want to create a symlink to >>> something that doesn't exist? >> >> ${destroot}${prefix}/bin/Xquartz exists, but Xquartz doesn't exist >> unless the interpreter's working directory is ${destroot}${prefix}/bin, >> which I don't think is the case. >> >> And to answer your question more generally, you often want to link to >> something in ${prefix} which won't be there until the port is activated. > > > Surely MacPorts doesn't have a problem creating such symlinks... I do > that in several of my ports: graphviz/graphviz-devel, > oracle-instantclient... Yeah, I just tested and it's happy with relative links. It's only linking to paths that don't yet exist where Tcl fails and 'system "ln -s"' succeeds. - Josh From jmpp at macports.org Sun Dec 7 23:02:47 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Mon, 8 Dec 2008 02:32:47 -0430 Subject: Moving MacPorts to the x.y.z version format internally for 1.7.1/1.8.0 In-Reply-To: References: <556BA986-F83C-4F01-B73E-F8B2E91A2500@macports.org> <7AAE7F64-6568-4EB5-9D2A-EBDCD6F25248@macports.org> <20081207204403.GF506@ninagal.withay.com> Message-ID: <48F60532-EF4A-4B4B-B899-5A208D09AD26@macports.org> On Dec 7, 2008, at 5:27 PM, Juan Manuel Palacios wrote: > The way I see it (unless I'm brain dead at the moment and missing > something incredibly obvious, or completely misunderstanding the way > rpm-vercomp works), the real problem is in the contents of both files: > > -) mp_version contains 1.610 in the release_1_6 branch (what regular > uses currently have), 1.700 in the release_1_7 branch (what will be > released next); > -) macports_version contains 1.6.1 and 1.7.0, respectively; > -) in both 1.610 and 1.700, the necessity to rebuild base in a > selfupdate run is as follows; > > from base/src/macprots1.0/macports.tcl: > if {$use_the_force_luke == "yes" || [rpm-vercomp > $macports_version_new $macports::autoconf::macports_version] > 0} { > > and $macports::autoconf::macports_version comes from base/src/ > macports1.0/macports_autoconf.tcl.in: > 36 variable macports_version "@MP_VERSION@" > > and @MP_VERSION@, in turn, is determined from base/config/mp_version > in base/configure.ac: > 15 # Read the old, floating point format version, which we still use > internally, and export it for the > $macports::autoconf::macports_version variable > 16 MP_VERSION=$(cat config/mp_version | tr -d '\n') > 17 AC_SUBST(MP_VERSION) > > So the real problem is determining when switching > $macports::autoconf::macports_version from @MP_VERSION@ to > @MACPORTS_VERSION@, the latter being determined from base/config/ > macports_version, is appropriate. If done for 1.7.0, users' > installations will be doing an rpm-vercom of 1.610.0 against 1.7.0, > which will obviously fail. If we do it by 1.7.0, then it'll be > 1.700.0 against 1.7.1, and I'm unsure of the result (though my guess > is 1.7.1 < 1.700.0, which would also fail). Answering this question > would clear the way to apply the patch I attached here originally > (cf. my last comment in r32364). I played with rpm-vercomp for a while and confirmed that 1.7.1 would not be seen as newer than 1.700, as I expected; on the other hand, the only way for users to selfupdate at present, other than forcing, is for the new release to be called 1.700, as currently planned, since 1.7 < 1.610 and 1.7.0 < 1.610. So as you can easily see, all we would be doing is pushing the problem one-more-release away by carrying on with floating point numbers until something else is done. So, if we want to solve the problem, if we consider it a problem in the first place (do count me in with those who consider floating point version numbers a little odd), I see no other solution but to special- case the selfupdate proc that's soon to be released with 1.700: Index: macports.tcl =================================================================== --- macports.tcl (revision 43285) +++ macports.tcl (working copy) @@ -1876,6 +1876,10 @@ # get downloaded MacPorts version gets $fd macports_version_new close $fd + # Temporary and lame special-case to move away from floating point version numbers: + if { $macports_version_new == "1.700" } { + set $macports_version_new "1.7.0" + } # echo downloaded MacPorts version ui_msg "Downloaded MacPorts base version $macports_version_new" The selfupdate currently in users' hands would still do a simple [rpm- vercomp 1.700 1.610] and would successfully proceed with the upgrade. The special-cased selfupdate in 1.700 would then allow us to release 1.7.1 or 1.8.0 and finally move away from floating point version numbers by performing a manipulated [rpm-vercomp 1.7.0 1.7.1]. We could also, of course, choose to stick with floating point version numbers forever more, but those being a tad odd is the whole point of this thread ;-) Or we could also instruct users to force... Opinions? Regards,... -jmpp From cssdev at mac.com Mon Dec 8 05:20:07 2008 From: cssdev at mac.com (cssdev at mac.com) Date: Mon, 08 Dec 2008 08:20:07 -0500 Subject: 64bit variant naming scheme In-Reply-To: <20081208025934.GM506@ninagal.withay.com> References: <20081208025934.GM506@ninagal.withay.com> Message-ID: <11179264151176422671870138510967245255-Webmail@me.com> On Sunday, December 07, 2008, at 09:59PM, "Bryan Blackburn" wrote: >Before there are many more ports with such variants, we need to decide on a >standard name; I found that +64bit isn't liked by port as it thinks that is >the name of a port, not a variant so I guess it doesn't like a variant name >to start with a number. Sounds like a bug to me. ;) Naming a variant with "use" seems redundant IMO, but it might be needed a temporary solution until we can name variants starting with numbers. Underscores can make it harder to remember, but otherwise I think +64bit would be the ideal choice. Chris From cssdev at mac.com Mon Dec 8 05:26:51 2008 From: cssdev at mac.com (cssdev at mac.com) Date: Mon, 08 Dec 2008 08:26:51 -0500 Subject: [43265] trunk/dports/textproc/doxygen/Portfile Message-ID: <145114075544730961274877155766649266792-Webmail@me.com> On Sunday, December 07, 2008, at 08:47PM, "Ryan Schmidt" wrote: >On Dec 7, 2008, at 17:20, css at macports.org wrote: > >> Revision: 43265 ]>> - depends_lib-append path:${prefix}/bin/pdflatex:texlive \ >> + depends_lib-append path:pdflatex:texlive \ > >That doesn't work. It needs to be "path:bin/pdflatex:texlive" (if you >want to ensure a pdflatex binary provided by a MacPorts port) or >"bin:pdflatex:texlive" (if you want to allow a pdflatex binary >anywhere in the binpath configured in the user's macports.conf). Arg, I was too quick to pull the trigger on that one. I'll fix that tonight. Thanks, Ryan! Chris From toby at macports.org Mon Dec 8 10:43:33 2008 From: toby at macports.org (Toby Peterson) Date: Mon, 8 Dec 2008 10:43:33 -0800 Subject: 64bit variant naming scheme In-Reply-To: <20081208025934.GM506@ninagal.withay.com> References: <20081208025934.GM506@ninagal.withay.com> Message-ID: <74c219d30812081043u5f3a60f6r7c6779ee453691f0@mail.gmail.com> On Sun, Dec 7, 2008 at 6:59 PM, Bryan Blackburn wrote: > Currently there are only a few ports with 64bit variants: > > nbench-byte +use_64_bit > ubench +use_64_bit > judy +bit64 > john-devel +use_64_bit > > (john-devel was updated with 64bit support by me, picking the more common > name). > > Before there are many more ports with such variants, we need to decide on a > standard name; I found that +64bit isn't liked by port as it thinks that is > the name of a port, not a variant so I guess it doesn't like a variant name > to start with a number. > > The only issue I have with +use_64_bit is it's long and a pain to type... Seems like a rather inappropriate use of variants in the first place. 64bit-related build foo should simply be applied if the port is being built 64bit (via universal_archs or other method). - Toby From jmr at macports.org Mon Dec 8 11:10:48 2008 From: jmr at macports.org (Joshua Root) Date: Tue, 09 Dec 2008 06:10:48 +1100 Subject: 64bit variant naming scheme In-Reply-To: <74c219d30812081043u5f3a60f6r7c6779ee453691f0@mail.gmail.com> References: <20081208025934.GM506@ninagal.withay.com> <74c219d30812081043u5f3a60f6r7c6779ee453691f0@mail.gmail.com> Message-ID: <493D7138.6020409@macports.org> Toby Peterson wrote: > On Sun, Dec 7, 2008 at 6:59 PM, Bryan Blackburn wrote: >> Currently there are only a few ports with 64bit variants: >> >> nbench-byte +use_64_bit >> ubench +use_64_bit >> judy +bit64 >> john-devel +use_64_bit >> >> (john-devel was updated with 64bit support by me, picking the more common >> name). >> >> Before there are many more ports with such variants, we need to decide on a >> standard name; I found that +64bit isn't liked by port as it thinks that is >> the name of a port, not a variant so I guess it doesn't like a variant name >> to start with a number. >> >> The only issue I have with +use_64_bit is it's long and a pain to type... > > Seems like a rather inappropriate use of variants in the first place. > 64bit-related build foo should simply be applied if the port is being > built 64bit (via universal_archs or other method). Right, the reason I added those variants to nbench-byte and ubench was simply so they could be built 64-bit with MP 1.6. With 1.7, it seems like universal_archs and configure.m64 should take care of the issue between them. - Josh From blb at macports.org Mon Dec 8 13:29:32 2008 From: blb at macports.org (Bryan Blackburn) Date: Mon, 8 Dec 2008 14:29:32 -0700 Subject: 64bit variant naming scheme In-Reply-To: <493D7138.6020409@macports.org> References: <20081208025934.GM506@ninagal.withay.com> <74c219d30812081043u5f3a60f6r7c6779ee453691f0@mail.gmail.com> <493D7138.6020409@macports.org> Message-ID: <20081208212932.GE506@ninagal.withay.com> On Tue, Dec 09, 2008 at 06:10:48AM +1100, Joshua Root said: > Toby Peterson wrote: > > On Sun, Dec 7, 2008 at 6:59 PM, Bryan Blackburn wrote: > >> Currently there are only a few ports with 64bit variants: > >> > >> nbench-byte +use_64_bit > >> ubench +use_64_bit > >> judy +bit64 > >> john-devel +use_64_bit > >> > >> (john-devel was updated with 64bit support by me, picking the more common > >> name). > >> > >> Before there are many more ports with such variants, we need to decide on a > >> standard name; I found that +64bit isn't liked by port as it thinks that is > >> the name of a port, not a variant so I guess it doesn't like a variant name > >> to start with a number. > >> > >> The only issue I have with +use_64_bit is it's long and a pain to type... > > > > Seems like a rather inappropriate use of variants in the first place. > > 64bit-related build foo should simply be applied if the port is being > > built 64bit (via universal_archs or other method). > > Right, the reason I added those variants to nbench-byte and ubench was > simply so they could be built 64-bit with MP 1.6. With 1.7, it seems > like universal_archs and configure.m64 should take care of the issue > between them. So if someone wants to have 64bit support from a port, they'll need to build it +universal? This would have to require people adding the requisite setting to universal_archs in macports.conf as well right, since trunk still specifies only 'ppc i386'? Also, what about ports where building 64bit is easier than universal, if there are such ports? Bryan > > - Josh From ryandesign at macports.org Mon Dec 8 13:47:23 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 8 Dec 2008 15:47:23 -0600 Subject: 64bit variant naming scheme In-Reply-To: <20081208212932.GE506@ninagal.withay.com> References: <20081208025934.GM506@ninagal.withay.com> <74c219d30812081043u5f3a60f6r7c6779ee453691f0@mail.gmail.com> <493D7138.6020409@macports.org> <20081208212932.GE506@ninagal.withay.com> Message-ID: On Dec 8, 2008, at 15:29, Bryan Blackburn wrote: > So if someone wants to have 64bit support from a port, they'll need > to build > it +universal? This would have to require people adding the requisite > setting to universal_archs in macports.conf as well right, since > trunk still > specifies only 'ppc i386'? > > Also, what about ports where building 64bit is easier than > universal, if > there are such ports? To chime in: I also don't like having a variant for 64-bit support and also think it should be part of the universal mechanism. But I also don't like how setting the architectures you want in macports.conf is the only way to influence what archs a port builds for. I would like each port to be able to declare which architectures it can be built for in universal mode. If a port does not specify, it is assumed it can be built for all architectures. This way, a port can specify that it only works on, say, i386 and ppc (if 64-bit doesn't work), or that it only works on i386 and x86_64 (for ports like wine that are Intel-only). Ports that are arch-agnostic would be able to indicate that in some way too. All this would replace "universal_variant no". This would be in addition to the setting in macports.conf. For example, a user requests in macports.conf that they prefer all 4 archs, and then individual ports can decide to only build a subset of those. MacPorts should also record which architectures a port was built for, not just that it was built "universal". Otherwise it's painful to upgrade from, say, a 2-arch universal to a 4-arch universal build of a port. MacPorts needs to be able to ensure that if you try to build port X universal, and it depends on port Y, then the set of architectures port X gets built for can be at most the set of architectures port Y was built for. I'm sure there was a previous discussion on the topic where I said much the same thing, but I haven't tried to find it in the archives. From ryandesign at macports.org Mon Dec 8 13:52:05 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 8 Dec 2008 15:52:05 -0600 Subject: Moving MacPorts to the x.y.z version format internally for 1.7.1/1.8.0 In-Reply-To: <48F60532-EF4A-4B4B-B899-5A208D09AD26@macports.org> References: <556BA986-F83C-4F01-B73E-F8B2E91A2500@macports.org> <7AAE7F64-6568-4EB5-9D2A-EBDCD6F25248@macports.org> <20081207204403.GF506@ninagal.withay.com> <48F60532-EF4A-4B4B-B899-5A208D09AD26@macports.org> Message-ID: On Dec 8, 2008, at 01:02, Juan Manuel Palacios wrote: > On Dec 7, 2008, at 5:27 PM, Juan Manuel Palacios wrote: > >> The way I see it (unless I'm brain dead at the moment and missing >> something incredibly obvious, or completely misunderstanding the >> way rpm-vercomp works), the real problem is in the contents of >> both files: >> >> -) mp_version contains 1.610 in the release_1_6 branch (what >> regular uses currently have), 1.700 in the release_1_7 branch >> (what will be released next); >> -) macports_version contains 1.6.1 and 1.7.0, respectively; >> -) in both 1.610 and 1.700, the necessity to rebuild base in a >> selfupdate run is as follows; >> >> from base/src/macprots1.0/macports.tcl: >> if {$use_the_force_luke == "yes" || [rpm-vercomp >> $macports_version_new $macports::autoconf::macports_version] > 0} { >> >> and $macports::autoconf::macports_version comes from base/src/ >> macports1.0/macports_autoconf.tcl.in: >> 36 variable macports_version "@MP_VERSION@" >> >> and @MP_VERSION@, in turn, is determined from base/config/ >> mp_version in base/configure.ac: >> 15 # Read the old, floating point format version, which we still >> use internally, and export it for the >> $macports::autoconf::macports_version variable >> 16 MP_VERSION=$(cat config/mp_version | tr -d '\n') >> 17 AC_SUBST(MP_VERSION) >> >> So the real problem is determining when switching >> $macports::autoconf::macports_version from @MP_VERSION@ to >> @MACPORTS_VERSION@, the latter being determined from base/config/ >> macports_version, is appropriate. If done for 1.7.0, users' >> installations will be doing an rpm-vercom of 1.610.0 against >> 1.7.0, which will obviously fail. If we do it by 1.7.0, then it'll >> be 1.700.0 against 1.7.1, and I'm unsure of the result (though my >> guess is 1.7.1 < 1.700.0, which would also fail). Answering this >> question would clear the way to apply the patch I attached here >> originally (cf. my last comment in r32364). > > > I played with rpm-vercomp for a while and confirmed that 1.7.1 > would not be seen as newer than 1.700, as I expected; on the other > hand, the only way for users to selfupdate at present, other than > forcing, is for the new release to be called 1.700, as currently > planned, since 1.7 < 1.610 and 1.7.0 < 1.610. So as you can easily > see, all we would be doing is pushing the problem one-more-release > away by carrying on with floating point numbers until something > else is done. > > So, if we want to solve the problem, if we consider it a problem > in the first place (do count me in with those who consider floating > point version numbers a little odd), I see no other solution but to > special-case the selfupdate proc that's soon to be released with > 1.700: > > Index: macports.tcl > =================================================================== > --- macports.tcl (revision 43285) > +++ macports.tcl (working copy) > @@ -1876,6 +1876,10 @@ > # get downloaded MacPorts version > gets $fd macports_version_new > close $fd > + # Temporary and lame special-case to move away from floating > point version numbers: > + if { $macports_version_new == "1.700" } { > + set $macports_version_new "1.7.0" > + } > # echo downloaded MacPorts version > ui_msg "Downloaded MacPorts base version $macports_version_new" > > > The selfupdate currently in users' hands would still do a simple > [rpm-vercomp 1.700 1.610] and would successfully proceed with the > upgrade. The special-cased selfupdate in 1.700 would then allow us > to release 1.7.1 or 1.8.0 and finally move away from floating point > version numbers by performing a manipulated [rpm-vercomp 1.7.0 1.7.1]. > > We could also, of course, choose to stick with floating point > version numbers forever more, but those being a tad odd is the > whole point of this thread ;-) Or we could also instruct users to > force... > > Opinions? Regards,... Definitely in favor of getting rid of the odd floating point version numbers of MacPorts proper, especially since the version numbers of all the software installed by MacPorts are assumed to be dotted decimal numbers. (That of course needs to be fixed too, for the perl ports and perhaps others that are released on a floating point version numbering scheme [1].) However, we have already cut 1.7.0-rc1 and it contains a year's worth of great changes. I don't want to delay it any further, unless to fix critical bugs, which this isn't. Let's put this in 1.8.0. There's no reason we can't release 1.8.0 very soon after 1.7.0. [1] http://trac.macports.org/ticket/11873 From ryandesign at macports.org Mon Dec 8 14:02:00 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 8 Dec 2008 16:02:00 -0600 Subject: 1.7.0 release candidate 1 available for testing In-Reply-To: <493C3839.9030900@macports.org> References: <20081207094439.GM847@ninagal.withay.com> <0D412574-6004-4D81-BA2D-CAC5F5DF6C74@macports.org> <20081207204004.GD506@ninagal.withay.com> <493C3839.9030900@macports.org> Message-ID: On Dec 7, 2008, at 14:55, Joshua Root wrote: > Bryan Blackburn wrote: >> On Sun, Dec 07, 2008 at 04:31:53AM -0600, Ryan Schmidt said: >>> On Dec 7, 2008, at 03:44, Bryan Blackburn wrote: >> [...] >>>> [1] - >>> release_1_7_0-rc1> >>>> [2] - >>> Thanks for taking the initiative with the 1.7.0 release here. >>> >>> >>> Is there a reason we don't put the 1.7.0-rc1 files in the regular >>> downloads directory? >>> >>> http://trac.macports.org/browser/downloads >> >> I chose putting it in /users since it's not a final release, so I >> don't want >> anyone seeing 1.7.0 under downloads and thinking otherwise; also, >> I've heard >> MacUpdate has an automated method for detecting new versions and I >> don't >> want it to pick up a release candidate and show it as the current >> version. > > Putting the non-final versions in a testing/ subdir should > sufficiently > distinguish them, I think. That would work. Other projects also differentiate. Graphviz uses "stable" and "development" directories. Cairo uses "releases" and "snapshots" directories. Others just use even version numbers for stable and odd numbers for development releases (I'm glad we're not using that particular strategy for MacPorts). >> Note that from what I've found, DMGs have only been offered for final >> releases in the past, so we have no policy about this. So I would >> say now >> is a good time to create one. Well we certainly need DMGs of 1.7.0-rc1 (so thank you for making them) so that we can verify that the bugs in the 1.6.0 DMG have been fixed. I don't see why we don't release DMGs for every version of MacPorts. I also find it odd how the MacPorts installer runs selfupdate. You install, say, MacPorts 1.5.0 from DMG, and after it's done, you have MacPorts 1.6.0 on your hard drive. Strange behavior. Why don't we do what other software does to check for updates? When you run the port command, check with the MacPorts server to see if a new version of MacPorts is available, and if so, print a line notifying the user they should update. It would only check once a week of course, or rather at an interval configurable in macports.conf (where it could also be turned off entirely). From jmpp at macports.org Mon Dec 8 14:12:55 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Mon, 8 Dec 2008 17:42:55 -0430 Subject: Moving MacPorts to the x.y.z version format internally for 1.7.1/1.8.0 In-Reply-To: References: <556BA986-F83C-4F01-B73E-F8B2E91A2500@macports.org> <7AAE7F64-6568-4EB5-9D2A-EBDCD6F25248@macports.org> <20081207204403.GF506@ninagal.withay.com> <48F60532-EF4A-4B4B-B899-5A208D09AD26@macports.org> Message-ID: On Dec 8, 2008, at 5:22 PM, Ryan Schmidt wrote: > Definitely in favor of getting rid of the odd floating point version > numbers of MacPorts proper, especially since the version numbers of > all the software installed by MacPorts are assumed to be dotted > decimal numbers. (That of course needs to be fixed too, for the perl > ports and perhaps others that are released on a floating point > version numbering scheme [1].) > > However, we have already cut 1.7.0-rc1 and it contains a year's > worth of great changes. I don't want to delay it any further, unless > to fix critical bugs, which this isn't. Let's put this in 1.8.0. > There's no reason we can't release 1.8.0 very soon after 1.7.0. > Funny enough, if I hadn't changed selfupdate to use rpm-vercomp in r32364, we could release 1.7 (rather than 1.700) and fix the problem right now, since mathematically 1.7 > 1.610; these new sources would then carry the switch to rpm-vercomp and thus take care of 1.7.1 or 1.8.0 > 1.7. All I can say about that is a big "UUUPPSSS!". But well, after whining about what would have been better, I'll await your green light to include the extremely lame special-case hack to move trunk away from floating point version numbers, by manipulating 1.800 into 1.8.0, unless a better approach is devised. Following that, I'll commit the patch I sent originally. Regards,... -jmpp From blb at macports.org Mon Dec 8 14:36:08 2008 From: blb at macports.org (Bryan Blackburn) Date: Mon, 8 Dec 2008 15:36:08 -0700 Subject: 1.7.0 release candidate 1 available for testing In-Reply-To: References: <20081207094439.GM847@ninagal.withay.com> <0D412574-6004-4D81-BA2D-CAC5F5DF6C74@macports.org> <20081207204004.GD506@ninagal.withay.com> <493C3839.9030900@macports.org> Message-ID: <20081208223608.GJ506@ninagal.withay.com> On Mon, Dec 08, 2008 at 04:02:00PM -0600, Ryan Schmidt said: [...] > > Well we certainly need DMGs of 1.7.0-rc1 (so thank you for making them) so > that we can verify that the bugs in the 1.6.0 DMG have been fixed. > > I don't see why we don't release DMGs for every version of MacPorts. Actually, unless someone has issues with it, I was planning on creating DMGs for 1.7.1 as well, since there really isn't any value to only doing DMGs for X.Y.0 then selfupdate. Though I thought it quite funny that creating the DMGs was the event that actually had me install from DMGs for the first time ever... > > I also find it odd how the MacPorts installer runs selfupdate. You > install, say, MacPorts 1.5.0 from DMG, and after it's done, you have > MacPorts 1.6.0 on your hard drive. Strange behavior. Why don't we do what > other software does to check for updates? When you run the port command, > check with the MacPorts server to see if a new version of MacPorts is > available, and if so, print a line notifying the user they should update. > It would only check once a week of course, or rather at an interval > configurable in macports.conf (where it could also be turned off > entirely). You do have to admit that MacPorts is a bit different than the average Mac app; we already have the selfupdate procedure and adding something like Sparkle would be a bit of work to basically do the same thing. Running a sync is a must when first installing from DMG since no Portfiles are included with the DMG, which means that port is quite useless. Also, if notifying the user will cause them to run a selfupdate anyway, why shouldn't we do it on install? Bryan From blb at macports.org Mon Dec 8 14:39:18 2008 From: blb at macports.org (Bryan Blackburn) Date: Mon, 8 Dec 2008 15:39:18 -0700 Subject: Moving MacPorts to the x.y.z version format internally for 1.7.1/1.8.0 In-Reply-To: References: <556BA986-F83C-4F01-B73E-F8B2E91A2500@macports.org> <7AAE7F64-6568-4EB5-9D2A-EBDCD6F25248@macports.org> <20081207204403.GF506@ninagal.withay.com> <48F60532-EF4A-4B4B-B899-5A208D09AD26@macports.org> Message-ID: <20081208223918.GK506@ninagal.withay.com> On Mon, Dec 08, 2008 at 05:42:55PM -0430, Juan Manuel Palacios said: > > On Dec 8, 2008, at 5:22 PM, Ryan Schmidt wrote: > >> Definitely in favor of getting rid of the odd floating point version >> numbers of MacPorts proper, especially since the version numbers of all >> the software installed by MacPorts are assumed to be dotted decimal >> numbers. (That of course needs to be fixed too, for the perl ports and >> perhaps others that are released on a floating point version numbering >> scheme [1].) >> >> However, we have already cut 1.7.0-rc1 and it contains a year's worth of >> great changes. I don't want to delay it any further, unless to fix >> critical bugs, which this isn't. Let's put this in 1.8.0. There's no >> reason we can't release 1.8.0 very soon after 1.7.0. >> > > Funny enough, if I hadn't changed selfupdate to use rpm-vercomp in > r32364, we could release 1.7 (rather than 1.700) and fix the problem > right now, since mathematically 1.7 > 1.610; these new sources would > then carry the switch to rpm-vercomp and thus take care of 1.7.1 or 1.8.0 > > 1.7. All I can say about that is a big "UUUPPSSS!". Note that there will definitely be some people who don't upgrade right away, so they may not see the fix in 1.7.0. So the issue is going to come up regardless, and the best way to deal with it is probably to just have them install from the current DMG. > > But well, after whining about what would have been better, I'll await > your green light to include the extremely lame special-case hack to move > trunk away from floating point version numbers, by manipulating 1.800 into > 1.8.0, unless a better approach is devised. Following that, I'll commit > the patch I sent originally. It can go into trunk since that's been 1.8 for over a week now... Bryan > > Regards,... > > -jmpp > From jmr at macports.org Mon Dec 8 15:00:38 2008 From: jmr at macports.org (Joshua Root) Date: Tue, 09 Dec 2008 10:00:38 +1100 Subject: 64bit variant naming scheme In-Reply-To: <20081208212932.GE506@ninagal.withay.com> References: <20081208025934.GM506@ninagal.withay.com> <74c219d30812081043u5f3a60f6r7c6779ee453691f0@mail.gmail.com> <493D7138.6020409@macports.org> <20081208212932.GE506@ninagal.withay.com> Message-ID: <493DA716.1070704@macports.org> Bryan Blackburn wrote: > On Tue, Dec 09, 2008 at 06:10:48AM +1100, Joshua Root said: >> Toby Peterson wrote: >>> On Sun, Dec 7, 2008 at 6:59 PM, Bryan Blackburn wrote: >>>> Currently there are only a few ports with 64bit variants: >>>> >>>> nbench-byte +use_64_bit >>>> ubench +use_64_bit >>>> judy +bit64 >>>> john-devel +use_64_bit >>>> >>>> (john-devel was updated with 64bit support by me, picking the more common >>>> name). >>>> >>>> Before there are many more ports with such variants, we need to decide on a >>>> standard name; I found that +64bit isn't liked by port as it thinks that is >>>> the name of a port, not a variant so I guess it doesn't like a variant name >>>> to start with a number. >>>> >>>> The only issue I have with +use_64_bit is it's long and a pain to type... >>> Seems like a rather inappropriate use of variants in the first place. >>> 64bit-related build foo should simply be applied if the port is being >>> built 64bit (via universal_archs or other method). >> Right, the reason I added those variants to nbench-byte and ubench was >> simply so they could be built 64-bit with MP 1.6. With 1.7, it seems >> like universal_archs and configure.m64 should take care of the issue >> between them. > > So if someone wants to have 64bit support from a port, they'll need to build > it +universal? This would have to require people adding the requisite > setting to universal_archs in macports.conf as well right, since trunk still > specifies only 'ppc i386'? > > Also, what about ports where building 64bit is easier than universal, if > there are such ports? Hang on, can configure.m64 be set in macports.conf? Overridden on the command line? I thought it could be, and if not, then it should be. - Josh From afb at macports.org Mon Dec 8 15:17:29 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue, 9 Dec 2008 00:17:29 +0100 Subject: 64bit variant naming scheme In-Reply-To: <493DA716.1070704@macports.org> References: <20081208025934.GM506@ninagal.withay.com> <74c219d30812081043u5f3a60f6r7c6779ee453691f0@mail.gmail.com> <493D7138.6020409@macports.org> <20081208212932.GE506@ninagal.withay.com> <493DA716.1070704@macports.org> Message-ID: Joshua Root wrote: >> Also, what about ports where building 64bit is easier than >> universal, if >> there are such ports? > > Hang on, can configure.m64 be set in macports.conf? Nope. (not yet) > Overridden on the command line? Sure. (try it) > I thought it could be, and if not, then it should be. But everyone just loves the fat stuff, so it's more likely to start building things with configure.universal_archs= "i386 x86_64" than to build "native" 64-bit ports with something resembling a +m64 variant. At least until Snow ? There was also the problem that just adding -m64 to CFLAGS is not enough to build 64-bit ports... There's plenty of things that like to guess settings from --host and friends, giving you a 64-bit binary with 32-bit settings (= ouch). Whichever approach is chosen, it probably needs some thought. "# We could have m32/m64/march/mtune be global configurable at some point." Ditto for debugging builds, if anyone ever attempts those... "# We could have debug/optimizations be global configurable at some point." There's some hacks in configure right now that started on it, including crazy things like cross-compiling over SDKs, but there is a lot to do before +universal and +m64 "work". I think I had a plan a year ago, just forgot what it was... --anders From afb at macports.org Tue Dec 9 03:22:17 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Tue, 9 Dec 2008 12:22:17 +0100 Subject: release_1_7_0-beta1 test results In-Reply-To: <493ab09c.cCuxHoCf8C8DDfTm%mp+d@v6shell.org> References: <493a2289.Q7jbCdSi2R7Lzcrm%mp+d@v6shell.org> <493A9218.7070603@macports.org> <493ab09c.cCuxHoCf8C8DDfTm%mp+d@v6shell.org> Message-ID: J.A. Neitzel wrote: >>> The only anomaly I have noticed so far is: >>> >>> % ./configure >>> [snip] >>> configure: creating ./config.status >>> config.status: creating src/programs/daemondo/Makefile >>> config.status: WARNING: src/programs/daemondo/Makefile.in seems >>> to \ >>> ignore the --datarootdir setting >>> config.status: creating Doxyfile >>> config.status: creating Makefile >>> [snip] >>> >>> ... >>> which may or may not be important. >> >> I don't know what that means. I couldn't see anything wrong in the >> referenced Makefile. > > It seems to be related to the GNU autotools. According to [1], > adding "datarootdir = @datarootdir@" to Makefile.in might help? > Sorry, I do not know or use GNU autotools. > > Jeff > > [1] - http://www.gnu.org/software/automake/manual/autoconf/Changed- > Directory-Variables.html > _______________________________________________ Thanks, fixed in http://trac.macports.org/changeset/43335 Should be backported to release_1_7 as well, I suppose ? --anders From Ian.Grant at cl.cam.ac.uk Tue Dec 9 08:08:31 2008 From: Ian.Grant at cl.cam.ac.uk (Ian Grant) Date: Tue, 9 Dec 2008 16:08:31 +0000 Subject: Loggin build/destroot stages Message-ID: <20081209160831.0d31ecee@vignemale.cl.cam.ac.uk> Hi All Is there a way to collect/see the output from the build and destroot stages of a port install? Ian From wsiegrist at apple.com Tue Dec 9 08:13:14 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 09 Dec 2008 08:13:14 -0800 Subject: Loggin build/destroot stages In-Reply-To: <20081209160831.0d31ecee@vignemale.cl.cam.ac.uk> References: <20081209160831.0d31ecee@vignemale.cl.cam.ac.uk> Message-ID: On Dec 9, 2008, at 8:08 AM, Ian Grant wrote: > Hi All > > Is there a way to collect/see the output from the build and destroot > stages of a port install? > Use the -d option, like: port -d install foo -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available URL: From bfulg at pacbell.net Tue Dec 9 20:11:25 2008 From: bfulg at pacbell.net (Brent Fulgham) Date: Tue, 9 Dec 2008 20:11:25 -0800 Subject: [MacPorts] #17525: defect: checksum error with smlnj In-Reply-To: <066.a3cfe0998cf6c12d1df3d5d2856603c6@macports.org> References: <057.cebe15d5f519d7467a25bf2cac84fad2@macports.org> <066.a3cfe0998cf6c12d1df3d5d2856603c6@macports.org> Message-ID: <038D73B8-80AB-4699-91C7-FAD6E3473020@pacbell.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes! Please do. Thanks, - -Brent On Dec 9, 2008, at 11:00 AM, MacPorts wrote: > #17525: defect: checksum error with smlnj > ----------------------------------- > +---------------------------------------- > Reporter: mcalhoun@? | Owner: bfulgham@? > Type: defect | Status: new > Priority: Normal | Milestone: Port Bugs > Component: ports | Version: 1.6.0 > Keywords: | Port: smlnj > ----------------------------------- > +---------------------------------------- > > Comment(by mcalhoun@?): > > May I go ahead and commit this change? > > -- > Ticket URL: > MacPorts > Ports system for Mac OS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkk/QW0ACgkQzGDdrzfvUpWyggCaAwM6s9WySfA2DHG/VZLz4W7O 3XQAnRXy76Y6Q12EEGBA9ftgm9LN0NSA =N4Bi -----END PGP SIGNATURE----- From jmpp at macports.org Tue Dec 9 21:16:07 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Wed, 10 Dec 2008 00:46:07 -0430 Subject: Moving MacPorts to the x.y.z version format internally for 1.7.1/1.8.0 In-Reply-To: <20081208223918.GK506@ninagal.withay.com> References: <556BA986-F83C-4F01-B73E-F8B2E91A2500@macports.org> <7AAE7F64-6568-4EB5-9D2A-EBDCD6F25248@macports.org> <20081207204403.GF506@ninagal.withay.com> <48F60532-EF4A-4B4B-B899-5A208D09AD26@macports.org> <20081208223918.GK506@ninagal.withay.com> Message-ID: <0A783D50-A94F-46BC-A878-ECD4FC2719AA@macports.org> On Dec 8, 2008, at 6:09 PM, Bryan Blackburn wrote: > Note that there will definitely be some people who don't upgrade > right away, > so they may not see the fix in 1.7.0. So the issue is going to come > up > regardless, and the best way to deal with it is probably to just > have them > install from the current DMG. > >> >> But well, after whining about what would have been better, I'll >> await >> your green light to include the extremely lame special-case hack to >> move >> trunk away from floating point version numbers, by manipulating >> 1.800 into >> 1.8.0, unless a better approach is devised. Following that, I'll >> commit >> the patch I sent originally. > > It can go into trunk since that's been 1.8 for over a week now... > > Bryan This work is now completed in r43375, at least in theory. I took care of testing extensively with the help of a local rsync server so I don't think I broke anything, but upgrading an installation can have so many faces that I'm keeping my eyes open. Let me know if anything runs afoul. As for the special-case hack, I chose to force the upgrade if the version number encountered is smaller or equal to 1.800, per the explanatory comment I wrote in the selfupdate proc in base/macports1.0/ macports.tcl. Also, the "or equal to" extension to my original proposal will help us catch those who lag behind and don't jump right away onto 1.8.0. The question now is when to remove the hack... Anything I missed...? Anyone against this lame hack...? Regards,... -jmpp From ryandesign at macports.org Wed Dec 10 00:49:40 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 10 Dec 2008 02:49:40 -0600 Subject: release_1_7_0-beta1 test results In-Reply-To: References: <493a2289.Q7jbCdSi2R7Lzcrm%mp+d@v6shell.org> <493A9218.7070603@macports.org> <493ab09c.cCuxHoCf8C8DDfTm%mp+d@v6shell.org> Message-ID: <446EDAA5-9BCC-4F19-BE7C-08F08BCE7A5E@macports.org> On Dec 9, 2008, at 05:22, Anders F Bj?rklund wrote: > J.A. Neitzel wrote: > >>>> The only anomaly I have noticed so far is: >>>> >>>> % ./configure >>>> [snip] >>>> configure: creating ./config.status >>>> config.status: creating src/programs/daemondo/Makefile >>>> config.status: WARNING: src/programs/daemondo/Makefile.in seems >>>> to \ >>>> ignore the --datarootdir setting >>>> config.status: creating Doxyfile >>>> config.status: creating Makefile >>>> [snip] >>>> >>>> ... >>>> which may or may not be important. >>> >>> I don't know what that means. I couldn't see anything wrong in the >>> referenced Makefile. >> >> It seems to be related to the GNU autotools. According to [1], >> adding "datarootdir = @datarootdir@" to Makefile.in might help? >> Sorry, I do not know or use GNU autotools. >> >> Jeff >> >> [1] - http://www.gnu.org/software/automake/manual/autoconf/Changed- >> Directory-Variables.html >> _______________________________________________ > > Thanks, fixed in http://trac.macports.org/changeset/43335 > > Should be backported to release_1_7 as well, I suppose ? Does daemondo actually do anything with datarootdir? From ryandesign at macports.org Wed Dec 10 00:49:53 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 10 Dec 2008 02:49:53 -0600 Subject: [43346] trunk/dports/net/network-weathermap/Portfile In-Reply-To: <20081209195524.C81C28B3CBF@beta.macosforge.org> References: <20081209195524.C81C28B3CBF@beta.macosforge.org> Message-ID: <67C5E209-C06F-48E4-87BD-9E933E1E8181@macports.org> On Dec 9, 2008, at 13:55, markd at macports.org wrote: > Revision: 43346 > http://trac.macports.org/changeset/43346 > Author: markd at macports.org > Date: 2008-12-09 11:55:23 -0800 (Tue, 09 Dec 2008) > Log Message: > ----------- > Remove the .htaccess file. > > Modified Paths: > -------------- > trunk/dports/net/network-weathermap/Portfile > > Modified: trunk/dports/net/network-weathermap/Portfile > =================================================================== > --- trunk/dports/net/network-weathermap/Portfile 2008-12-09 > 18:52:37 UTC (rev 43345) > +++ trunk/dports/net/network-weathermap/Portfile 2008-12-09 > 19:55:23 UTC (rev 43346) > @@ -4,7 +4,7 @@ > > name network-weathermap > version 0.95b > -revision 1 > +revision 2 > categories net > maintainers markd > platforms darwin > @@ -40,9 +40,15 @@ > reinplace "s|/usr/local/|/opt/local/|g" \ > ${worksrcpath}/weathermap \ > ${worksrcpath}/weathermap-cacti-rebuild.php > + > +# Set perl location > + reinplace "s|/usr/bin/perl|/opt/local/bin/perl|g" \ > + ${worksrcpath}/random-bits/auto-overlib.pl > } This perl location change seems unrelated, and also not correct since you're hard-coding /opt/local instead of using ${prefix}. You also need a runtime dependency on path:bin/perl:perl5 then. Actually the port already hardcodes /opt/local in another reinplace above, so that needs to be fixed too. > destroot { > + file delete ${worksrcpath}/configs/.htaccess > + > file mkdir ${destroot}${pluginsdir}/weathermap > system "cp -R ${worksrcpath}/* ${destroot}${pluginsdir}/weathermap" From afb at macports.org Wed Dec 10 00:52:19 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 10 Dec 2008 09:52:19 +0100 Subject: release_1_7_0-beta1 test results In-Reply-To: <446EDAA5-9BCC-4F19-BE7C-08F08BCE7A5E@macports.org> References: <493a2289.Q7jbCdSi2R7Lzcrm%mp+d@v6shell.org> <493A9218.7070603@macports.org> <493ab09c.cCuxHoCf8C8DDfTm%mp+d@v6shell.org> <446EDAA5-9BCC-4F19-BE7C-08F08BCE7A5E@macports.org> Message-ID: Ryan Schmidt wrote: >>> It seems to be related to the GNU autotools. According to [1], >>> adding "datarootdir = @datarootdir@" to Makefile.in might help? >>> Sorry, I do not know or use GNU autotools. >>> >>> Jeff >>> >>> [1] - http://www.gnu.org/software/automake/manual/autoconf/ >>> Changed-Directory-Variables.html >>> _______________________________________________ >> >> Thanks, fixed in http://trac.macports.org/changeset/43335 >> >> Should be backported to release_1_7 as well, I suppose ? > > Does daemondo actually do anything with datarootdir? No, only with mandir - which is now based on datarootdir. It's all automatic when you use automake, which we don't. --anders From jeremyhu at macports.org Wed Dec 10 02:16:36 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Wed, 10 Dec 2008 02:16:36 -0800 Subject: xorg-server on Macports (works with Tiger) Message-ID: <5A7BC45F-195E-4561-8C7F-8F325E6B50FD@macports.org> I've been spending some time these past few weeks updating the x.org ports in Macports as well as pushing patches to get the latest X.org bits building on Tiger. I'm proud to announce that the latest Xquartz code can now be built using macports (even on Tiger!!!). To test this out, just do: port install xorg-server # if you don't get version 1.4.2_apple27_2, resync in a bit and try again then you can run the resulting /Applications/MacPorts/X11.app For now, you will still need your existing X11 installation (there are no xorg font packages in portage yet, so I'm using fonts out of $ {x11prefix}), but I hope to start adding font packages in the near future to eliminate this dependency. Notes / Cavaets: If you're on Tiger, you should disable the pasteboard proxying in X11- >Preferences->Clipboard or xpbproxy and quartz-wm will fight with each other. If you're on Leopard, I recommend you install Xquartz-2.3.2_rc3 or later first in order to get the latest quartz-wm (otherwise, you'll be in the same boat as the Tiger folks with the outdated quartz-wm). --- I'd like to get some feedback from other devs about this before mentioning it to users. The one big "gotcha" is an issue that results when there's a mixture of xorg-bits in Macports and Tiger-X11 bits in / usr/X11R6... http://trac.macports.org/ticket/17558 From ian.grant at cl.cam.ac.uk Wed Dec 10 06:24:03 2008 From: ian.grant at cl.cam.ac.uk (Ian Grant) Date: Wed, 10 Dec 2008 14:24:03 +0000 Subject: Moscow ML port on MacPorts/DarwinPorts Message-ID: <8EC959E9-F9C5-4BB3-A5F0-FE0D0BFC09D1@cl.cam.ac.uk> Dear cso at rift.dk I have made a port of the Moscow ML dynamic libraries: intinf, crypt, munix, mregex, msocket, mgdbm, mgd on MacOS X. It requires a small change to the current mosml port. Attached is a diff of the Portfile change and a new patch (which is needed by both ports), as well as a Portfile for the new mosml-dynlibs port. Since the mosml-dynlibs port requires the patched mosml port I guess the mosml-dynlibs port should be made to depend on the newer mosml so people with the older mosml will be forced to upgrade to the newer before adding mosml-dynlibs. But I don't know how to specify the port version in a dependency. Is this possible? Could you let me know whether you would be happy to commit these changes (if not tell me what I need to change) and also whether you would be able to be the maintainer of the dynamic libraries port as well? (I am not a registered MacPorts developer and have no svn access.) Best wishes Ian Grant -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile-lang-mosml.diff Type: application/octet-stream Size: 1109 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile-lang-mosml-dynlibs Type: application/octet-stream Size: 1076 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-src-dynlibs.diff Type: application/octet-stream Size: 6192 bytes Desc: not available URL: From markd at macports.org Wed Dec 10 12:19:02 2008 From: markd at macports.org (markd at macports.org) Date: Wed, 10 Dec 2008 12:19:02 -0800 Subject: [43346] trunk/dports/net/network-weathermap/Portfile Message-ID: >> @@ -40,9 +40,15 @@ >> reinplace "s|/usr/local/|/opt/local/|g" \ >> ${worksrcpath}/weathermap \ >> ${worksrcpath}/weathermap-cacti-rebuild.php >> + >> +# Set perl location >> + reinplace "s|/usr/bin/perl|/opt/local/bin/perl|g" \ >> + ${worksrcpath}/random-bits/auto-overlib.pl >> } > >This perl location change seems unrelated, That change should have been in the commit comments too, but I forgot. Or are you saying the reinplace should have been in a separate commit from the file delete one? > and also not correct since >you're hard-coding /opt/local instead of using ${prefix}. > >Actually the port already hardcodes /opt/local in another reinplace >above, so that needs to be fixed too. I must have been caffeine deprived. I fixed those in r43416. Thanks for catching that. >You also >need a runtime dependency on path:bin/perl:perl5 then. The rrdtool port depends on perl, so I didn't think it necessary to repeat it. Though sometimes I do anyway in these cases. Not sure what the rule is, or the best practice either. If you think the perl one should be there anyway I can add it. Mark From frstan at bellsouth.net Wed Dec 10 13:30:35 2008 From: frstan at bellsouth.net (William Davis) Date: Wed, 10 Dec 2008 16:30:35 -0500 Subject: xorg-server on Macports (works with Tiger) In-Reply-To: <5A7BC45F-195E-4561-8C7F-8F325E6B50FD@macports.org> References: <5A7BC45F-195E-4561-8C7F-8F325E6B50FD@macports.org> Message-ID: <8D148610-7BD8-47C5-A9EF-F7C78798A326@bellsouth.net> On Dec 10, 2008, at 5:16 AM, Jeremy Huddleston wrote: > I've been spending some time these past few weeks updating the x.org > ports in Macports as well as pushing patches to get the latest X.org > bits building on Tiger. I'm proud to announce that the latest > Xquartz code can now be built using macports (even on Tiger!!!). > > To test this out, just do: > > port install xorg-server # if you don't get version 1.4.2_apple27_2, > resync in a bit and try again > > then you can run the resulting /Applications/MacPorts/X11.app > > For now, you will still need your existing X11 installation (there > are no xorg font packages in portage yet, so I'm using fonts out of $ > {x11prefix}), but I hope to start adding font packages in the near > future to eliminate this dependency. > xorg-server failed to build for me with this error: /bin/sh ../../libtool --tag=CC --mode=compile /usr/bin/gcc-4.0 - DHAVE_CONFIG_H -I. -I../../include -I../../hw/xfree86/os-support - I../../hw/xfree86/os-support/bus -I../../hw/xfree86/common -I../../hw/ xfree86/dri -I../../mi -I/opt/local/include -I/opt/local/var/macports/ build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- apple27/../Mesa-7.0.4/include -I/opt/local/include -I/opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- apple27/../Mesa-7.0.4/include -DHAVE_DIX_CONFIG_H -Wall -Wpointer- arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations - Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN - DHAS_STICKY_DIR_BIT -I/opt/local/include -I/opt/local/include/ freetype2 -I/opt/local/include/pixman-1 -I../../include -I../../ include -I../../Xext -I../../damageext -I../../xfixes -I../../Xi - I../../mi -I../../miext/shadow -I../../miext/damage -I../../render - I../../randr -I../../fb -I/opt/local/include -I/opt/local/include -I/ opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- apple27/../Mesa-7.0.4/src/mesa/glapi -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- apple27/../Mesa-7.0.4/src/mesa/main -DXFree86Server -O2 - DROOTLESS_WORKAROUND -DROOTLESS_SAFEALPHA -DNO_ALLOCA -MT glcontextmodes.lo -MD -MP -MF .deps/glcontextmodes.Tpo -c -o glcontextmodes.lo glcontextmodes.c /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I../../include -I../../hw/ xfree86/os-support -I../../hw/xfree86/os-support/bus -I../../hw/ xfree86/common -I../../hw/xfree86/dri -I../../mi -I/opt/local/include - I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- apple27/../Mesa-7.0.4/include -I/opt/local/include -I/opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- apple27/../Mesa-7.0.4/include -DHAVE_DIX_CONFIG_H -Wall -Wpointer- arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations - Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN - DHAS_STICKY_DIR_BIT -I/opt/local/include -I/opt/local/include/ freetype2 -I/opt/local/include/pixman-1 -I../../include -I../../ include -I../../Xext -I../../damageext -I../../xfixes -I../../Xi - I../../mi -I../../miext/shadow -I../../miext/damage -I../../render - I../../randr -I../../fb -I/opt/local/include -I/opt/local/include -I/ opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- apple27/../Mesa-7.0.4/src/mesa/glapi -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- apple27/../Mesa-7.0.4/src/mesa/main -DXFree86Server -O2 - DROOTLESS_WORKAROUND -DROOTLESS_SAFEALPHA -DNO_ALLOCA -MT glcontextmodes.lo -MD -MP -MF .deps/glcontextmodes.Tpo -c glcontextmodes.c -fno-common -DPIC -o .libs/glcontextmodes.o glcontextmodes.c: In function '_gl_copy_visual_to_context_mode': glcontextmodes.c:193: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgb' glcontextmodes.c:194: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgba' glcontextmodes.c:196: error: 'struct __GLcontextModesRec' has no member named 'bindToMipmapTexture' glcontextmodes.c:197: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureTargets' glcontextmodes.c:200: error: 'struct __GLcontextModesRec' has no member named 'yInverted' glcontextmodes.c: In function '_gl_get_context_mode_data': glcontextmodes.c:333: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgb' glcontextmodes.c:336: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgba' glcontextmodes.c:339: error: 'struct __GLcontextModesRec' has no member named 'bindToMipmapTexture' glcontextmodes.c:342: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureTargets' glcontextmodes.c:345: error: 'struct __GLcontextModesRec' has no member named 'yInverted' glcontextmodes.c: In function '_gl_context_modes_create': glcontextmodes.c:417: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgb' glcontextmodes.c:418: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgba' glcontextmodes.c:419: error: 'struct __GLcontextModesRec' has no member named 'bindToMipmapTexture' glcontextmodes.c:420: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureTargets' glcontextmodes.c:421: error: 'struct __GLcontextModesRec' has no member named 'yInverted' glcontextmodes.c: In function '_gl_context_modes_are_same': glcontextmodes.c:535: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgb' glcontextmodes.c:535: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgb' glcontextmodes.c:536: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgba' glcontextmodes.c:536: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgba' glcontextmodes.c:537: error: 'struct __GLcontextModesRec' has no member named 'bindToMipmapTexture' glcontextmodes.c:537: error: 'struct __GLcontextModesRec' has no member named 'bindToMipmapTexture' glcontextmodes.c:538: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureTargets' glcontextmodes.c:538: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureTargets' glcontextmodes.c:539: error: 'struct __GLcontextModesRec' has no member named 'yInverted' glcontextmodes.c:539: error: 'struct __GLcontextModesRec' has no member named 'yInverted' make[2]: *** [glcontextmodes.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Error: Target org.macports.build returned: shell command " cd "/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- apple27" && make all " returned error 2 Command output: glcontextmodes.c:194: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgba' glcontextmodes.c:196: error: 'struct __GLcontextModesRec' has no member named 'bindToMipmapTexture' glcontextmodes.c:197: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureTargets' glcontextmodes.c:200: error: 'struct __GLcontextModesRec' has no member named 'yInverted' glcontextmodes.c: In function '_gl_get_context_mode_data': glcontextmodes.c:333: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgb' glcontextmodes.c:336: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgba' glcontextmodes.c:339: error: 'struct __GLcontextModesRec' has no member named 'bindToMipmapTexture' glcontextmodes.c:342: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureTargets' glcontextmodes.c:345: error: 'struct __GLcontextModesRec' has no member named 'yInverted' glcontextmodes.c: In function '_gl_context_modes_create': glcontextmodes.c:417: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgb' glcontextmodes.c:418: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgba' glcontextmodes.c:419: error: 'struct __GLcontextModesRec' has no member named 'bindToMipmapTexture' glcontextmodes.c:420: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureTargets' glcontextmodes.c:421: error: 'struct __GLcontextModesRec' has no member named 'yInverted' glcontextmodes.c: In function '_gl_context_modes_are_same': glcontextmodes.c:535: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgb' glcontextmodes.c:535: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgb' glcontextmodes.c:536: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgba' glcontextmodes.c:536: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureRgba' glcontextmodes.c:537: error: 'struct __GLcontextModesRec' has no member named 'bindToMipmapTexture' glcontextmodes.c:537: error: 'struct __GLcontextModesRec' has no member named 'bindToMipmapTexture' glcontextmodes.c:538: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureTargets' glcontextmodes.c:538: error: 'struct __GLcontextModesRec' has no member named 'bindToTextureTargets' glcontextmodes.c:539: error: 'struct __GLcontextModesRec' has no member named 'yInverted' glcontextmodes.c:539: error: 'struct __GLcontextModesRec' has no member named 'yInverted' make[2]: *** [glcontextmodes.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Warning: the following items did not execute (for xorg-server): org.macports.activate org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. macintosh:~ frstan$ William Davis frstanATbellsouthDOTnet Mac OS X.5.5 Darwin 9.5.0 XQuartz 2.3.2_rc3 (xorg-server 1.4.2-apple27) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From jeremyhu at macports.org Wed Dec 10 15:18:50 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Wed, 10 Dec 2008 15:18:50 -0800 Subject: xorg-server on Macports (works with Tiger) In-Reply-To: <8D148610-7BD8-47C5-A9EF-F7C78798A326@bellsouth.net> References: <5A7BC45F-195E-4561-8C7F-8F325E6B50FD@macports.org> <8D148610-7BD8-47C5-A9EF-F7C78798A326@bellsouth.net> Message-ID: <5D970649-3D7A-4F86-98C9-21D531841E73@macports.org> Hrm... yeah, there's some problem where the wrong glcore.h is being used... that was the point of the: # Otherwise glcore.h will be pulled in from glproto in /opt/local/ include/GL/internal configure.cppflags -I${worksrcpath}/../Mesa-${mesavers}/include -I$ {prefix}/include but I guess that's not working now for some reason... maybe it's grabbing /usr/X11/include/GL/glcore.h ... you can try just adding --disable-glx to configure.args for now. On Dec 10, 2008, at 13:30, William Davis wrote: > > On Dec 10, 2008, at 5:16 AM, Jeremy Huddleston wrote: > >> I've been spending some time these past few weeks updating the >> x.org ports in Macports as well as pushing patches to get the >> latest X.org bits building on Tiger. I'm proud to announce that >> the latest Xquartz code can now be built using macports (even on >> Tiger!!!). >> >> To test this out, just do: >> >> port install xorg-server # if you don't get version >> 1.4.2_apple27_2, resync in a bit and try again >> >> then you can run the resulting /Applications/MacPorts/X11.app >> >> For now, you will still need your existing X11 installation (there >> are no xorg font packages in portage yet, so I'm using fonts out of >> ${x11prefix}), but I hope to start adding font packages in the near >> future to eliminate this dependency. >> > > xorg-server failed to build for me with this error: > > /bin/sh ../../libtool --tag=CC --mode=compile /usr/bin/gcc-4.0 - > DHAVE_CONFIG_H -I. -I../../include -I../../hw/xfree86/os-support - > I../../hw/xfree86/os-support/bus -I../../hw/xfree86/common -I../../ > hw/xfree86/dri -I../../mi -I/opt/local/include -I/opt/local/var/ > macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- > apple27/../Mesa-7.0.4/include -I/opt/local/include -I/opt/local/var/ > macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- > apple27/../Mesa-7.0.4/include -DHAVE_DIX_CONFIG_H -Wall -Wpointer- > arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing- > declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE - > DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/opt/local/include -I/opt/local/ > include/freetype2 -I/opt/local/include/pixman-1 -I../../include - > I../../include -I../../Xext -I../../damageext -I../../xfixes - > I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage - > I../../render -I../../randr -I../../fb -I/opt/local/include -I/opt/ > local/include -I/opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- > apple27/../Mesa-7.0.4/src/mesa/glapi -I/opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- > apple27/../Mesa-7.0.4/src/mesa/main -DXFree86Server -O2 - > DROOTLESS_WORKAROUND -DROOTLESS_SAFEALPHA -DNO_ALLOCA -MT > glcontextmodes.lo -MD -MP -MF .deps/glcontextmodes.Tpo -c -o > glcontextmodes.lo glcontextmodes.c > /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I../../include -I../../hw/ > xfree86/os-support -I../../hw/xfree86/os-support/bus -I../../hw/ > xfree86/common -I../../hw/xfree86/dri -I../../mi -I/opt/local/ > include -I/opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- > apple27/../Mesa-7.0.4/include -I/opt/local/include -I/opt/local/var/ > macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- > apple27/../Mesa-7.0.4/include -DHAVE_DIX_CONFIG_H -Wall -Wpointer- > arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing- > declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE - > DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/opt/local/include -I/opt/local/ > include/freetype2 -I/opt/local/include/pixman-1 -I../../include - > I../../include -I../../Xext -I../../damageext -I../../xfixes -I../../ > Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../ > render -I../../randr -I../../fb -I/opt/local/include -I/opt/local/ > include -I/opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- > apple27/../Mesa-7.0.4/src/mesa/glapi -I/opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- > apple27/../Mesa-7.0.4/src/mesa/main -DXFree86Server -O2 - > DROOTLESS_WORKAROUND -DROOTLESS_SAFEALPHA -DNO_ALLOCA -MT > glcontextmodes.lo -MD -MP -MF .deps/glcontextmodes.Tpo -c > glcontextmodes.c -fno-common -DPIC -o .libs/glcontextmodes.o > glcontextmodes.c: In function '_gl_copy_visual_to_context_mode': > glcontextmodes.c:193: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgb' > glcontextmodes.c:194: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgba' > glcontextmodes.c:196: error: 'struct __GLcontextModesRec' has no > member named 'bindToMipmapTexture' > glcontextmodes.c:197: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureTargets' > glcontextmodes.c:200: error: 'struct __GLcontextModesRec' has no > member named 'yInverted' > glcontextmodes.c: In function '_gl_get_context_mode_data': > glcontextmodes.c:333: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgb' > glcontextmodes.c:336: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgba' > glcontextmodes.c:339: error: 'struct __GLcontextModesRec' has no > member named 'bindToMipmapTexture' > glcontextmodes.c:342: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureTargets' > glcontextmodes.c:345: error: 'struct __GLcontextModesRec' has no > member named 'yInverted' > glcontextmodes.c: In function '_gl_context_modes_create': > glcontextmodes.c:417: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgb' > glcontextmodes.c:418: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgba' > glcontextmodes.c:419: error: 'struct __GLcontextModesRec' has no > member named 'bindToMipmapTexture' > glcontextmodes.c:420: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureTargets' > glcontextmodes.c:421: error: 'struct __GLcontextModesRec' has no > member named 'yInverted' > glcontextmodes.c: In function '_gl_context_modes_are_same': > glcontextmodes.c:535: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgb' > glcontextmodes.c:535: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgb' > glcontextmodes.c:536: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgba' > glcontextmodes.c:536: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgba' > glcontextmodes.c:537: error: 'struct __GLcontextModesRec' has no > member named 'bindToMipmapTexture' > glcontextmodes.c:537: error: 'struct __GLcontextModesRec' has no > member named 'bindToMipmapTexture' > glcontextmodes.c:538: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureTargets' > glcontextmodes.c:538: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureTargets' > glcontextmodes.c:539: error: 'struct __GLcontextModesRec' has no > member named 'yInverted' > glcontextmodes.c:539: error: 'struct __GLcontextModesRec' has no > member named 'yInverted' > make[2]: *** [glcontextmodes.lo] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all-recursive] Error 1 > Error: Target org.macports.build returned: shell command " cd "/opt/ > local/var/macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- > apple27" && make all " returned error 2 > Command output: glcontextmodes.c:194: error: 'struct > __GLcontextModesRec' has no member named 'bindToTextureRgba' > glcontextmodes.c:196: error: 'struct __GLcontextModesRec' has no > member named 'bindToMipmapTexture' > glcontextmodes.c:197: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureTargets' > glcontextmodes.c:200: error: 'struct __GLcontextModesRec' has no > member named 'yInverted' > glcontextmodes.c: In function '_gl_get_context_mode_data': > glcontextmodes.c:333: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgb' > glcontextmodes.c:336: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgba' > glcontextmodes.c:339: error: 'struct __GLcontextModesRec' has no > member named 'bindToMipmapTexture' > glcontextmodes.c:342: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureTargets' > glcontextmodes.c:345: error: 'struct __GLcontextModesRec' has no > member named 'yInverted' > glcontextmodes.c: In function '_gl_context_modes_create': > glcontextmodes.c:417: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgb' > glcontextmodes.c:418: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgba' > glcontextmodes.c:419: error: 'struct __GLcontextModesRec' has no > member named 'bindToMipmapTexture' > glcontextmodes.c:420: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureTargets' > glcontextmodes.c:421: error: 'struct __GLcontextModesRec' has no > member named 'yInverted' > glcontextmodes.c: In function '_gl_context_modes_are_same': > glcontextmodes.c:535: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgb' > glcontextmodes.c:535: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgb' > glcontextmodes.c:536: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgba' > glcontextmodes.c:536: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureRgba' > glcontextmodes.c:537: error: 'struct __GLcontextModesRec' has no > member named 'bindToMipmapTexture' > glcontextmodes.c:537: error: 'struct __GLcontextModesRec' has no > member named 'bindToMipmapTexture' > glcontextmodes.c:538: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureTargets' > glcontextmodes.c:538: error: 'struct __GLcontextModesRec' has no > member named 'bindToTextureTargets' > glcontextmodes.c:539: error: 'struct __GLcontextModesRec' has no > member named 'yInverted' > glcontextmodes.c:539: error: 'struct __GLcontextModesRec' has no > member named 'yInverted' > make[2]: *** [glcontextmodes.lo] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all-recursive] Error 1 > > Warning: the following items did not execute (for xorg-server): > org.macports.activate org.macports.build org.macports.destroot > org.macports.install > Error: Status 1 encountered during processing. > macintosh:~ frstan$ > > > William Davis > frstanATbellsouthDOTnet > Mac OS X.5.5 Darwin 9.5.0 > XQuartz 2.3.2_rc3 (xorg-server 1.4.2-apple27) > Mac Mini Intel Duo @ 1.86 GHz > > Mundus vult decepi, ego non > From ryandesign at macports.org Wed Dec 10 16:01:38 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 10 Dec 2008 18:01:38 -0600 Subject: [43346] trunk/dports/net/network-weathermap/Portfile In-Reply-To: References: Message-ID: <9B54C7E5-A1A2-4274-9104-369F2A90B3C9@macports.org> On Dec 10, 2008, at 14:19, markd at macports.org wrote: >>> @@ -40,9 +40,15 @@ >>> reinplace "s|/usr/local/|/opt/local/|g" \ >>> ${worksrcpath}/weathermap \ >>> ${worksrcpath}/weathermap-cacti-rebuild.php >>> + >>> +# Set perl location >>> + reinplace "s|/usr/bin/perl|/opt/local/bin/perl|g" \ >>> + ${worksrcpath}/random-bits/auto-overlib.pl >>> } >> >> This perl location change seems unrelated, > > That change should have been in the commit comments too, but I > forgot. Or > are you saying the reinplace should have been in a separate commit > from > the file delete one? I was just saying since you didn't mention it in the commit message I wasn't sure if you meant to commit that change as well. >> and also not correct since >> you're hard-coding /opt/local instead of using ${prefix}. >> >> Actually the port already hardcodes /opt/local in another reinplace >> above, so that needs to be fixed too. > > I must have been caffeine deprived. I fixed those in r43416. > Thanks for > catching that. Hehe! >> You also >> need a runtime dependency on path:bin/perl:perl5 then. > > The rrdtool port depends on perl, so I didn't think it necessary to > repeat > it. Though sometimes I do anyway in these cases. Not sure what > the rule > is, or the best practice either. If you think the perl one should be > there anyway I can add it. I think since network-weathermap itself uses perl, it should itself declare a dependency on perl. From ryandesign at macports.org Wed Dec 10 16:06:12 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 10 Dec 2008 18:06:12 -0600 Subject: [43452] trunk/dports/perl/p5-test-object/Portfile In-Reply-To: <20081210230525.62D228DCB5C@beta.macosforge.org> References: <20081210230525.62D228DCB5C@beta.macosforge.org> Message-ID: <6DEA841D-4688-4ADA-B82A-FC725E884A54@macports.org> On Dec 10, 2008, at 17:05, narf_tm at macports.org wrote: > Revision: 43452 > http://trac.macports.org/changeset/43452 > Author: narf_tm at macports.org > Date: 2008-12-10 15:05:24 -0800 (Wed, 10 Dec 2008) > Log Message: > ----------- > Fixed dependancies. "dependencies". :) I've been fixing your log messages. Don't forget to list everything you change in your commit messages. For example here you also made whitespace changes. Ideally you would commit whitespace changes in a separate commit from other changes, so that it's easier to ignore the whitespace changes when looking through the revisions and more clearly see the changes that actually matter. > Modified Paths: > -------------- > trunk/dports/perl/p5-test-object/Portfile > > Modified: trunk/dports/perl/p5-test-object/Portfile > =================================================================== > --- trunk/dports/perl/p5-test-object/Portfile 2008-12-10 23:03:56 > UTC (rev 43451) > +++ trunk/dports/perl/p5-test-object/Portfile 2008-12-10 23:05:24 > UTC (rev 43452) > @@ -1,15 +1,17 @@ > # $Id$ > > -PortSystem 1.0 > -PortGroup perl5 1.0 > +PortSystem 1.0 > +PortGroup perl5 1.0 > > -perl5.setup Test-Object 0.07 > -maintainers narf_tm openmaintainer > -description Thoroughly testing objects via registered > handlers > -long_description ${description} > +perl5.setup Test-Object 0.07 > +maintainers narf_tm openmaintainer > +description Thoroughly testing objects via registered > handlers > +long_description ${description} > > -platforms darwin > +platforms darwin > > -checksums md5 ab71791756faaabc3b4fad5bcc1df50f \ > - sha1 7bd76d09c81aef0ef32e6f4edf042ba88e514f52 \ > - rmd160 012db64b0895ce838a081c2c8cb6e7635a9814e4 > +checksums md5 ab71791756faaabc3b4fad5bcc1df50f \ > + sha1 7bd76d09c81aef0ef32e6f4edf042ba88e514f52 \ > + rmd160 012db64b0895ce838a081c2c8cb6e7635a9814e4 > + > +depends_lib-append port:p5-test-simple From ryandesign at macports.org Wed Dec 10 16:13:15 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 10 Dec 2008 18:13:15 -0600 Subject: [43452] trunk/dports/perl/p5-test-object/Portfile In-Reply-To: <6DEA841D-4688-4ADA-B82A-FC725E884A54@macports.org> References: <20081210230525.62D228DCB5C@beta.macosforge.org> <6DEA841D-4688-4ADA-B82A-FC725E884A54@macports.org> Message-ID: <462E1838-C5A3-45E2-A5A7-544D6B813F00@macports.org> On Dec 10, 2008, at 18:06, Ryan Schmidt wrote: > On Dec 10, 2008, at 17:05, narf_tm at macports.org wrote: > >> Revision: 43452 >> http://trac.macports.org/changeset/43452 >> Author: narf_tm at macports.org >> Date: 2008-12-10 15:05:24 -0800 (Wed, 10 Dec 2008) >> Log Message: >> ----------- >> Fixed dependancies. > > "dependencies". :) I've been fixing your log messages. Hmm. On second thought, while the Mac OS X Dictionary.app doesn't have "dependancies" (only had "dependencies" -- on Tiger, anyway), the spell checker recognizes both. I guess it's an alternate spelling. So never mind this bit, sorry for the noise. :) > Don't forget to list everything you change in your commit messages. > For example here you also made whitespace changes. Ideally you > would commit whitespace changes in a separate commit from other > changes, so that it's easier to ignore the whitespace changes when > looking through the revisions and more clearly see the changes that > actually matter. From frstan at bellsouth.net Wed Dec 10 19:47:41 2008 From: frstan at bellsouth.net (William Davis) Date: Wed, 10 Dec 2008 22:47:41 -0500 Subject: xorg-server on Macports (works with Tiger) In-Reply-To: <5D970649-3D7A-4F86-98C9-21D531841E73@macports.org> References: <5A7BC45F-195E-4561-8C7F-8F325E6B50FD@macports.org> <8D148610-7BD8-47C5-A9EF-F7C78798A326@bellsouth.net> <5D970649-3D7A-4F86-98C9-21D531841E73@macports.org> Message-ID: confirming that xorg-server does build with --disable-glx added to config.args WD On Dec 10, 2008, at 6:18 PM, Jeremy Huddleston wrote: > Hrm... yeah, there's some problem where the wrong glcore.h is being > used... that was the point of the: > > # Otherwise glcore.h will be pulled in from glproto in /opt/local/ > include/GL/internal > configure.cppflags -I${worksrcpath}/../Mesa-${mesavers}/include -I$ > {prefix}/include > > but I guess that's not working now for some reason... > > maybe it's grabbing /usr/X11/include/GL/glcore.h ... > > you can try just adding --disable-glx to configure.args for now. > > On Dec 10, 2008, at 13:30, William Davis wrote: > >> >> On Dec 10, 2008, at 5:16 AM, Jeremy Huddleston wrote: >> >>> I've been spending some time these past few weeks updating the >>> x.org ports in Macports as well as pushing patches to get the >>> latest X.org bits building on Tiger. I'm proud to announce that >>> the latest Xquartz code can now be built using macports (even on >>> Tiger!!!). >>> >>> To test this out, just do: >>> >>> port install xorg-server # if you don't get version >>> 1.4.2_apple27_2, resync in a bit and try again >>> >>> then you can run the resulting /Applications/MacPorts/X11.app >>> >>> For now, you will still need your existing X11 installation (there >>> are no xorg font packages in portage yet, so I'm using fonts out >>> of ${x11prefix}), but I hope to start adding font packages in the >>> near future to eliminate this dependency. >>> >> >> xorg-server failed to build for me with this error: >> >> /bin/sh ../../libtool --tag=CC --mode=compile /usr/bin/gcc-4.0 - >> DHAVE_CONFIG_H -I. -I../../include -I../../hw/xfree86/os-support - >> I../../hw/xfree86/os-support/bus -I../../hw/xfree86/common -I../../ >> hw/xfree86/dri -I../../mi -I/opt/local/include -I/opt/local/var/ >> macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- >> apple27/../Mesa-7.0.4/include -I/opt/local/include -I/opt/local/var/ >> macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- >> apple27/../Mesa-7.0.4/include -DHAVE_DIX_CONFIG_H -Wall -Wpointer- >> arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing- >> declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE - >> DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/opt/local/include -I/opt/local/ >> include/freetype2 -I/opt/local/include/pixman-1 -I../../include - >> I../../include -I../../Xext -I../../damageext -I../../xfixes - >> I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage - >> I../../render -I../../randr -I../../fb -I/opt/local/include -I/opt/ >> local/include -I/opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- >> apple27/../Mesa-7.0.4/src/mesa/glapi -I/opt/local/var/macports/ >> build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- >> apple27/../Mesa-7.0.4/src/mesa/main -DXFree86Server -O2 - >> DROOTLESS_WORKAROUND -DROOTLESS_SAFEALPHA -DNO_ALLOCA -MT >> glcontextmodes.lo -MD -MP -MF .deps/glcontextmodes.Tpo -c -o >> glcontextmodes.lo glcontextmodes.c >> /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I../../include -I../../hw/ >> xfree86/os-support -I../../hw/xfree86/os-support/bus -I../../hw/ >> xfree86/common -I../../hw/xfree86/dri -I../../mi -I/opt/local/ >> include -I/opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- >> apple27/../Mesa-7.0.4/include -I/opt/local/include -I/opt/local/var/ >> macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- >> apple27/../Mesa-7.0.4/include -DHAVE_DIX_CONFIG_H -Wall -Wpointer- >> arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing- >> declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE - >> DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/opt/local/include -I/opt/local/ >> include/freetype2 -I/opt/local/include/pixman-1 -I../../include - >> I../../include -I../../Xext -I../../damageext -I../../xfixes - >> I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage - >> I../../render -I../../randr -I../../fb -I/opt/local/include -I/opt/ >> local/include -I/opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- >> apple27/../Mesa-7.0.4/src/mesa/glapi -I/opt/local/var/macports/ >> build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- >> apple27/../Mesa-7.0.4/src/mesa/main -DXFree86Server -O2 - >> DROOTLESS_WORKAROUND -DROOTLESS_SAFEALPHA -DNO_ALLOCA -MT >> glcontextmodes.lo -MD -MP -MF .deps/glcontextmodes.Tpo -c >> glcontextmodes.c -fno-common -DPIC -o .libs/glcontextmodes.o >> glcontextmodes.c: In function '_gl_copy_visual_to_context_mode': >> glcontextmodes.c:193: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgb' >> glcontextmodes.c:194: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgba' >> glcontextmodes.c:196: error: 'struct __GLcontextModesRec' has no >> member named 'bindToMipmapTexture' >> glcontextmodes.c:197: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureTargets' >> glcontextmodes.c:200: error: 'struct __GLcontextModesRec' has no >> member named 'yInverted' >> glcontextmodes.c: In function '_gl_get_context_mode_data': >> glcontextmodes.c:333: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgb' >> glcontextmodes.c:336: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgba' >> glcontextmodes.c:339: error: 'struct __GLcontextModesRec' has no >> member named 'bindToMipmapTexture' >> glcontextmodes.c:342: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureTargets' >> glcontextmodes.c:345: error: 'struct __GLcontextModesRec' has no >> member named 'yInverted' >> glcontextmodes.c: In function '_gl_context_modes_create': >> glcontextmodes.c:417: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgb' >> glcontextmodes.c:418: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgba' >> glcontextmodes.c:419: error: 'struct __GLcontextModesRec' has no >> member named 'bindToMipmapTexture' >> glcontextmodes.c:420: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureTargets' >> glcontextmodes.c:421: error: 'struct __GLcontextModesRec' has no >> member named 'yInverted' >> glcontextmodes.c: In function '_gl_context_modes_are_same': >> glcontextmodes.c:535: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgb' >> glcontextmodes.c:535: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgb' >> glcontextmodes.c:536: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgba' >> glcontextmodes.c:536: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgba' >> glcontextmodes.c:537: error: 'struct __GLcontextModesRec' has no >> member named 'bindToMipmapTexture' >> glcontextmodes.c:537: error: 'struct __GLcontextModesRec' has no >> member named 'bindToMipmapTexture' >> glcontextmodes.c:538: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureTargets' >> glcontextmodes.c:538: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureTargets' >> glcontextmodes.c:539: error: 'struct __GLcontextModesRec' has no >> member named 'yInverted' >> glcontextmodes.c:539: error: 'struct __GLcontextModesRec' has no >> member named 'yInverted' >> make[2]: *** [glcontextmodes.lo] Error 1 >> make[1]: *** [all-recursive] Error 1 >> make: *** [all-recursive] Error 1 >> Error: Target org.macports.build returned: shell command " cd "/opt/ >> local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_x11_xorg-server/work/xorg-server-1.4.2- >> apple27" && make all " returned error 2 >> Command output: glcontextmodes.c:194: error: 'struct >> __GLcontextModesRec' has no member named 'bindToTextureRgba' >> glcontextmodes.c:196: error: 'struct __GLcontextModesRec' has no >> member named 'bindToMipmapTexture' >> glcontextmodes.c:197: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureTargets' >> glcontextmodes.c:200: error: 'struct __GLcontextModesRec' has no >> member named 'yInverted' >> glcontextmodes.c: In function '_gl_get_context_mode_data': >> glcontextmodes.c:333: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgb' >> glcontextmodes.c:336: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgba' >> glcontextmodes.c:339: error: 'struct __GLcontextModesRec' has no >> member named 'bindToMipmapTexture' >> glcontextmodes.c:342: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureTargets' >> glcontextmodes.c:345: error: 'struct __GLcontextModesRec' has no >> member named 'yInverted' >> glcontextmodes.c: In function '_gl_context_modes_create': >> glcontextmodes.c:417: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgb' >> glcontextmodes.c:418: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgba' >> glcontextmodes.c:419: error: 'struct __GLcontextModesRec' has no >> member named 'bindToMipmapTexture' >> glcontextmodes.c:420: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureTargets' >> glcontextmodes.c:421: error: 'struct __GLcontextModesRec' has no >> member named 'yInverted' >> glcontextmodes.c: In function '_gl_context_modes_are_same': >> glcontextmodes.c:535: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgb' >> glcontextmodes.c:535: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgb' >> glcontextmodes.c:536: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgba' >> glcontextmodes.c:536: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureRgba' >> glcontextmodes.c:537: error: 'struct __GLcontextModesRec' has no >> member named 'bindToMipmapTexture' >> glcontextmodes.c:537: error: 'struct __GLcontextModesRec' has no >> member named 'bindToMipmapTexture' >> glcontextmodes.c:538: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureTargets' >> glcontextmodes.c:538: error: 'struct __GLcontextModesRec' has no >> member named 'bindToTextureTargets' >> glcontextmodes.c:539: error: 'struct __GLcontextModesRec' has no >> member named 'yInverted' >> glcontextmodes.c:539: error: 'struct __GLcontextModesRec' has no >> member named 'yInverted' >> make[2]: *** [glcontextmodes.lo] Error 1 >> make[1]: *** [all-recursive] Error 1 >> make: *** [all-recursive] Error 1 >> >> Warning: the following items did not execute (for xorg-server): >> org.macports.activate org.macports.build org.macports.destroot >> org.macports.install >> Error: Status 1 encountered during processing. >> macintosh:~ frstan$ >> >> >> William Davis >> frstanATbellsouthDOTnet >> Mac OS X.5.5 Darwin 9.5.0 >> XQuartz 2.3.2_rc3 (xorg-server 1.4.2-apple27) >> Mac Mini Intel Duo @ 1.86 GHz >> >> Mundus vult decepi, ego non >> > William Davis frstanATbellsouthDOTnet Mac OS X.5.5 Darwin 9.5.0 XQuartz 2.3.2_rc3 (xorg-server 1.4.2-apple27) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From jeremyhu at macports.org Wed Dec 10 23:10:31 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Wed, 10 Dec 2008 23:10:31 -0800 Subject: path: dependency for files NOT in macports Message-ID: Is there a way for me to do something like: path:lib/pkgconfig/x11.pc:xorg-libX11 but have that dependency satisfied by /usr/X11/lib/pkgconfig/x11.pc ? From andrea.damore at macports.org Wed Dec 10 23:23:47 2008 From: andrea.damore at macports.org (Andrea D'Amore) Date: Thu, 11 Dec 2008 08:23:47 +0100 Subject: About porting mesa3d Message-ID: Lately I was trying to build an app that had mesa3d in requirements, I didn't even check if Leopard had it (it does btw) and after searching in ports I built the portfile. The portfile breaks ${prefix} directory tree at destroot phase as it tries to install stuff in /usr/ X11 , being cloesly tied to X11 . After the recent discussion on Xqartz moving to ports how should mesa3d (libGL and so) port be handled? And should it have some "- software" in name to specify it's not hw accelerated? Andrea From ryandesign at macports.org Wed Dec 10 23:45:19 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 11 Dec 2008 01:45:19 -0600 Subject: path: dependency for files NOT in macports In-Reply-To: References: Message-ID: On Dec 11, 2008, at 01:10, Jeremy Huddleston wrote: > Is there a way for me to do something like: > > path:lib/pkgconfig/x11.pc:xorg-libX11 > > but have that dependency satisfied by /usr/X11/lib/pkgconfig/x11.pc ? Hmm. In path:-style dependencies, you specify the absolute path to the file you require. The path:-style dependency is for when you know exactly the path to the file you want, but there are multiple ports that can provide it and you don't care which one. If you specify a path that is not absolute (does not begin with a slash), ${prefix} is prepended, as a convenience. See the _pathtest procedure here: http://trac.macports.org/browser/trunk/base/src/macports1.0/macports.tcl bin:-style dependencies check for a binary anywhere in $PATH (not the user's $PATH, but the $PATH that's set while MacPorts is running, which is configured by the binpath variable in macports.conf). See the _bintest procedure in the same tcl file above. lib:-style dependencies check for a library anywhere in various library directories. See the _libtest procedure. If you want to depend on a particular pkgconfig file but don't care whether X11 or MacPorts provides it, we may need (I can't believe I'm saying this) a new pkgconfig:-style of dependency that searches the various pkgconfig directories. Or perhaps you can instead depend on a binary or a library. From afb at macports.org Thu Dec 11 00:18:02 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 11 Dec 2008 09:18:02 +0100 Subject: path: dependency for files NOT in macports In-Reply-To: References: Message-ID: <59556BE5-DCE5-4F04-83D3-A8AF39ED7D9D@macports.org> Jeremy Huddleston wrote: > Is there a way for me to do something like: > > path:lib/pkgconfig/x11.pc:xorg-libX11 > > but have that dependency satisfied by /usr/X11/lib/pkgconfig/x11.pc ? You can use "${x11prefix}/lib/pkgconfig/x11.pc", but it's not guaranteed to work or be portable... i.e. the .pc files don't have to be in "lib", they could also be in a "libdata" or something. So maybe pkconfig:x11:xorg-libX11 is in order ? (would need "base" to grow a feature, though) --anders From ryandesign at macports.org Thu Dec 11 02:53:52 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 11 Dec 2008 04:53:52 -0600 Subject: [43527] trunk/dports/print In-Reply-To: <20081211090348.7854C8E58AD@beta.macosforge.org> References: <20081211090348.7854C8E58AD@beta.macosforge.org> Message-ID: On Dec 11, 2008, at 03:03, blb at macports.org wrote: > Revision: 43527 > http://trac.macports.org/changeset/43527 > Author: blb at macports.org > Date: 2008-12-11 01:03:47 -0800 (Thu, 11 Dec 2008) > Log Message: > ----------- > New port - prit/cups-pdf, provides a print-to-PDF feature through CUPS [snip] > +build { > + system "cd ${worksrcpath}/src && ${configure.cc} -Os -o cups- > pdf cups-pdf.c" > +} [snip] We need to either release MacPorts 1.7.0 real soon, since $ {configure.cc} doesn't exist outside the configure phase in MacPorts 1.6.0, or that bit in the port needs to be changed so that configure.cc is written to a Makefile in the post-configure phase and then you use that Makefile in the build phase. http://trac.macports.org/ticket/17426 From ryandesign at macports.org Thu Dec 11 03:00:07 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 11 Dec 2008 05:00:07 -0600 Subject: path: dependency for files NOT in macports In-Reply-To: <59556BE5-DCE5-4F04-83D3-A8AF39ED7D9D@macports.org> References: <59556BE5-DCE5-4F04-83D3-A8AF39ED7D9D@macports.org> Message-ID: <0D5D5809-A6A8-4561-A3D3-F719CF03BF27@macports.org> On Dec 11, 2008, at 02:18, Anders F Bj?rklund wrote: > Jeremy Huddleston wrote: > >> Is there a way for me to do something like: >> >> path:lib/pkgconfig/x11.pc:xorg-libX11 >> >> but have that dependency satisfied by /usr/X11/lib/pkgconfig/x11.pc ? > > You can use "${x11prefix}/lib/pkgconfig/x11.pc", Actually I'm told you currently can't because variables are not expanded in depspecs. http://trac.macports.org/ticket/17182 > but it's not guaranteed to work or be portable... > i.e. the .pc files don't have to be in "lib", > they could also be in a "libdata" or something. MacPorts pkgconfig only searches three paths: * ${prefix}/lib/pkgconfig * ${prefix}/share/pkgconfig * ${x11prefix}/lib/pkgconfig But I think what Jeremy was getting at is that he doesn't know which of those three locations the file might be in. > So maybe pkconfig:x11:xorg-libX11 is in order ? > (would need "base" to grow a feature, though) That's what I was thinking (s/pkconfig/pkgconfig/). From ryandesign at macports.org Thu Dec 11 03:01:51 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 11 Dec 2008 05:01:51 -0600 Subject: 1.7.0 blocker: xcode portgroup and universal variants Message-ID: <904BAD94-63D3-450A-A9F4-1A78412D1ECA@macports.org> I don't know what anyone else's thoughts were about how long we wanted to let 1.7.0-rc1 simmer before releasing 1.7.0 final, but I would like to not release 1.7.0 until this regression I just found is fixed: http://trac.macports.org/ticket/17610 From afb at macports.org Thu Dec 11 03:18:27 2008 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 11 Dec 2008 12:18:27 +0100 Subject: path: dependency for files NOT in macports In-Reply-To: <0D5D5809-A6A8-4561-A3D3-F719CF03BF27@macports.org> References: <59556BE5-DCE5-4F04-83D3-A8AF39ED7D9D@macports.org> <0D5D5809-A6A8-4561-A3D3-F719CF03BF27@macports.org> Message-ID: <91CA5411-8B61-4679-87B7-9EC90A4F78C1@macports.org> Ryan Schmidt wrote: > On Dec 11, 2008, at 02:18, Anders F Bj?rklund wrote: > >> Jeremy Huddleston wrote: >> >>> Is there a way for me to do something like: >>> >>> path:lib/pkgconfig/x11.pc:xorg-libX11 >>> >>> but have that dependency satisfied by /usr/X11/lib/pkgconfig/ >>> x11.pc ? >> >> You can use "${x11prefix}/lib/pkgconfig/x11.pc", > > Actually I'm told you currently can't because variables are not > expanded in depspecs. > > http://trac.macports.org/ticket/17182 Intriguing... Make that "/usr/X11/lib/pkgconfig/x11.pc" then. :-) >> but it's not guaranteed to work or be portable... >> i.e. the .pc files don't have to be in "lib", >> they could also be in a "libdata" or something. > > MacPorts pkgconfig only searches three paths: > > * ${prefix}/lib/pkgconfig > * ${prefix}/share/pkgconfig > * ${x11prefix}/lib/pkgconfig > > But I think what Jeremy was getting at is that he doesn't know > which of those three locations the file might be in. But if one uses an "outside"/System X11, then it might be located somewhere else completely. For instance FreeBSD has x11prefix=/usr/local and the .pc in /usr/local/libdata/pkgconfig ? >> So maybe pkconfig:x11:xorg-libX11 is in order ? >> (would need "base" to grow a feature, though) > > That's what I was thinking (s/pkconfig/pkgconfig/). It doesn't help much on Tiger (i.e. without xorg) either, since it doesn't have a x11.pc anywhere. Sometimes it's possible to hack around that, instead: http://trac.macports.org/browser/users/afb/Hopper/xfce4-settings --anders From takeshi at enomosphere.net Thu Dec 11 06:18:30 2008 From: takeshi at enomosphere.net (Takeshi Enomoto) Date: Thu, 11 Dec 2008 23:18:30 +0900 Subject: 64bit variant naming scheme In-Reply-To: References: <20081208025934.GM506@ninagal.withay.com> <74c219d30812081043u5f3a60f6r7c6779ee453691f0@mail.gmail.com> <493D7138.6020409@macports.org> <20081208212932.GE506@ninagal.withay.com> <493DA716.1070704@macports.org> Message-ID: <6357C168-6C8F-45DE-90E2-0037581A48DA@enomosphere.net> I think scientific users want not universal (i386 and ppc) but 64-bit (x86_64 and ppc64) if they have a 64-bit machine. If a package is build for all the four (i386 x86_64 ppc ppc64), there will be not problem but it is not always easy to support this. For example source in fortran is problematic. gfortran in gcc43 -m64 option but not -arch x86_64 or ppc64. To build universal one needs to go through build process twice with - m32 and -m64 and use lipo later. I have not yet able to provide g95 64-bit. My point is building for two types of cpus and for 32/64 bit are not always the same and an average scientific user wants 64 bit version for the host (her/ his local) machine. A universal Portfile has been posted for fftw-3, which is under examination. It would be nice if port command itself have a similar function. Otherwise it would be nice to enable the user to choose 32/64 bit. Takeshi From jmr at macports.org Thu Dec 11 08:50:37 2008 From: jmr at macports.org (Joshua Root) Date: Fri, 12 Dec 2008 03:50:37 +1100 Subject: path: dependency for files NOT in macports In-Reply-To: <0D5D5809-A6A8-4561-A3D3-F719CF03BF27@macports.org> References: <59556BE5-DCE5-4F04-83D3-A8AF39ED7D9D@macports.org> <0D5D5809-A6A8-4561-A3D3-F719CF03BF27@macports.org> Message-ID: <494144DD.4080903@macports.org> Ryan Schmidt wrote: > > On Dec 11, 2008, at 02:18, Anders F Bj?rklund wrote: > >> Jeremy Huddleston wrote: >> >>> Is there a way for me to do something like: >>> >>> path:lib/pkgconfig/x11.pc:xorg-libX11 >>> >>> but have that dependency satisfied by /usr/X11/lib/pkgconfig/x11.pc ? >> >> You can use "${x11prefix}/lib/pkgconfig/x11.pc", > > Actually I'm told you currently can't because variables are not expanded > in depspecs. > > http://trac.macports.org/ticket/17182 Technically that only seems to be the case for $prefix - but expanding $x11prefix at indexing time is wrong anyway. Yet, it may do just what you want in this particular case. - Josh From blb at macports.org Thu Dec 11 12:42:06 2008 From: blb at macports.org (Bryan Blackburn) Date: Thu, 11 Dec 2008 13:42:06 -0700 Subject: 1.7.0 blocker: xcode portgroup and universal variants In-Reply-To: <904BAD94-63D3-450A-A9F4-1A78412D1ECA@macports.org> References: <904BAD94-63D3-450A-A9F4-1A78412D1ECA@macports.org> Message-ID: <20081211204206.GD507@ninagal.withay.com> On Thu, Dec 11, 2008 at 05:01:51AM -0600, Ryan Schmidt said: > I don't know what anyone else's thoughts were about how long we wanted to > let 1.7.0-rc1 simmer before releasing 1.7.0 final, but I would like to not > release 1.7.0 until this regression I just found is fixed: > > http://trac.macports.org/ticket/17610 Since the -sdk option is present in the Xcode group, this doesn't need to affect 1.7.0 at all, as the group code is in dports/ [1] and can be fixed whenever. Bryan [1] - From jmpp at macports.org Thu Dec 11 14:47:17 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Thu, 11 Dec 2008 18:17:17 -0430 Subject: 1.7.0 release candidate 1 available for testing In-Reply-To: References: <20081207094439.GM847@ninagal.withay.com> <0D412574-6004-4D81-BA2D-CAC5F5DF6C74@macports.org> <20081207204004.GD506@ninagal.withay.com> <493C3839.9030900@macports.org> Message-ID: On Dec 8, 2008, at 5:32 PM, Ryan Schmidt wrote: > > I also find it odd how the MacPorts installer runs selfupdate. You > install, say, MacPorts 1.5.0 from DMG, and after it's done, you have > MacPorts 1.6.0 on your hard drive. Strange behavior. Good point, the whole thing seems kinda sneaky. Changing it to respect what you installed is as easy as switching to a `port sync` call in the pkg's postflight script (base/portmgr/dmg/postflight), so that at least your ports tree is up to date. > Why don't we do what other software does to check for updates? When > you run the port command, check with the MacPorts server to see if a > new version of MacPorts is available, and if so, print a line > notifying the user they should update. It would only check once a > week of course, or rather at an interval configurable in > macports.conf (where it could also be turned off entirely). Checking for new releases either against a central authority or your rsync'd sources is fairly easy, as we would only need to poll (locally or across the network) either of the base/config/ {mp_version,macports_version} files [1] and take appropriate actions. Implementation details up for discussion, it wouldn't be at all complicated, I'm sure. Regards,... -jmpp [1] cf. my soon-to-come commit correcting a couple of selfupdate errors I introduced in r43375. From jeremyhu at macports.org Thu Dec 11 14:40:16 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Thu, 11 Dec 2008 14:40:16 -0800 Subject: path: dependency for files NOT in macports In-Reply-To: References: Message-ID: On Dec 10, 2008, at 23:45, Ryan Schmidt wrote: > On Dec 11, 2008, at 01:10, Jeremy Huddleston wrote: > >> Is there a way for me to do something like: >> >> path:lib/pkgconfig/x11.pc:xorg-libX11 >> >> but have that dependency satisfied by /usr/X11/lib/pkgconfig/x11.pc ? > > If you want to depend on a particular pkgconfig file but don't care > whether X11 or MacPorts provides it, we may need (I can't believe > I'm saying this) a new pkgconfig:-style of dependency that searches > the various pkgconfig directories. but then what if we want to make sure there's some m4 macro "somewhere" or some "module" somewhere... It seems like it'd be good to have a fileinpathsomewhere: dependency that takes a relative path and looks for that file in /, /usr/, $ {x11prefix}, ${prefix}, > Or perhaps you can instead depend on a binary or a library. Well the problem is that "old" X11 didn't provide these pkgconfig files, and we might want to check for them to make sure we have a "new enough" X11 lib in some cases (I don't have a concrete example right now, but I'm planning for that eventuality). From jeremyhu at macports.org Thu Dec 11 14:42:24 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Thu, 11 Dec 2008 14:42:24 -0800 Subject: path: dependency for files NOT in macports In-Reply-To: <494144DD.4080903@macports.org> References: <59556BE5-DCE5-4F04-83D3-A8AF39ED7D9D@macports.org> <0D5D5809-A6A8-4561-A3D3-F719CF03BF27@macports.org> <494144DD.4080903@macports.org> Message-ID: <171CB3A0-504B-4F30-8E13-EF13B5FE3968@macports.org> On Dec 11, 2008, at 08:50, Joshua Root wrote: > Ryan Schmidt wrote: >> >> On Dec 11, 2008, at 02:18, Anders F Bj?rklund wrote: >> >>> Jeremy Huddleston wrote: >>> >>>> Is there a way for me to do something like: >>>> >>>> path:lib/pkgconfig/x11.pc:xorg-libX11 >>>> >>>> but have that dependency satisfied by /usr/X11/lib/pkgconfig/ >>>> x11.pc ? >>> >>> You can use "${x11prefix}/lib/pkgconfig/x11.pc", >> >> Actually I'm told you currently can't because variables are not >> expanded >> in depspecs. >> >> http://trac.macports.org/ticket/17182 > > Technically that only seems to be the case for $prefix - but expanding > $x11prefix at indexing time is wrong anyway. Yet, it may do just what > you want in this particular case. either way, that's still checking that it's in ${x11prefix} only and doesn't let the macports one satisfy it =/ From jeremyhu at macports.org Thu Dec 11 14:48:33 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Thu, 11 Dec 2008 14:48:33 -0800 Subject: About porting mesa3d In-Reply-To: References: Message-ID: <9F786BF7-9963-46F2-8554-34F7C8975FA6@macports.org> On Dec 10, 2008, at 23:23, Andrea D'Amore wrote: > Lately I was trying to build an app that had mesa3d in requirements, > I didn't even check if Leopard had it (it does btw) and after > searching in ports I built the portfile. The portfile breaks $ > {prefix} directory tree at destroot phase as it tries to install > stuff in /usr/X11 , being cloesly tied to X11 . > > After the recent discussion on Xqartz moving to ports how should > mesa3d (libGL and so) port be handled? And should it have some "- > software" in name to specify it's not hw accelerated? I pushed some patches to mesa-7.2_branch a while back that will let it build with just 'make darwin' ... you can set RC_ARCHS="ppc i386" to make it build universal. The 'INSTALL_DIR' sets the prefix, so you'll need to get the Portfile to do: make darwin RC_ARCHS="ppc i386" INSTALL_DIR="${prefix}" make install INSTALL_DIR="${prefix}" DESTDIR=... I haven't even looked at mesa in macports right now, so I have no idea what state it's in, but I thuroughly simplified things upstream, so hopefully you can clean it up (if not, poke me, and I'll throw it in my queue). --Jeremy From jmr at macports.org Thu Dec 11 16:04:29 2008 From: jmr at macports.org (Joshua Root) Date: Fri, 12 Dec 2008 11:04:29 +1100 Subject: path: dependency for files NOT in macports In-Reply-To: <171CB3A0-504B-4F30-8E13-EF13B5FE3968@macports.org> References: <59556BE5-DCE5-4F04-83D3-A8AF39ED7D9D@macports.org> <0D5D5809-A6A8-4561-A3D3-F719CF03BF27@macports.org> <494144DD.4080903@macports.org> <171CB3A0-504B-4F30-8E13-EF13B5FE3968@macports.org> Message-ID: <4941AA8D.4070203@macports.org> Jeremy Huddleston wrote: > > On Dec 11, 2008, at 08:50, Joshua Root wrote: > >> Ryan Schmidt wrote: >>> >>> On Dec 11, 2008, at 02:18, Anders F Bj?rklund wrote: >>> >>>> Jeremy Huddleston wrote: >>>> >>>>> Is there a way for me to do something like: >>>>> >>>>> path:lib/pkgconfig/x11.pc:xorg-libX11 >>>>> >>>>> but have that dependency satisfied by /usr/X11/lib/pkgconfig/x11.pc ? >>>> >>>> You can use "${x11prefix}/lib/pkgconfig/x11.pc", >>> >>> Actually I'm told you currently can't because variables are not expanded >>> in depspecs. >>> >>> http://trac.macports.org/ticket/17182 >> >> Technically that only seems to be the case for $prefix - but expanding >> $x11prefix at indexing time is wrong anyway. Yet, it may do just what >> you want in this particular case. > > either way, that's still checking that it's in ${x11prefix} only and > doesn't let the macports one satisfy it =/ The dependency is satisfied if the named port is installed, regardless of whether it actually provides the specified file. - Josh From ryandesign at macports.org Thu Dec 11 17:14:16 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 11 Dec 2008 19:14:16 -0600 Subject: path: dependency for files NOT in macports In-Reply-To: <4941AA8D.4070203@macports.org> References: <59556BE5-DCE5-4F04-83D3-A8AF39ED7D9D@macports.org> <0D5D5809-A6A8-4561-A3D3-F719CF03BF27@macports.org> <494144DD.4080903@macports.org> <171CB3A0-504B-4F30-8E13-EF13B5FE3968@macports.org> <4941AA8D.4070203@macports.org> Message-ID: <503E96DA-1284-4388-BE95-CA6ECEB1F393@macports.org> On Dec 11, 2008, at 18:04, Joshua Root wrote: > Jeremy Huddleston wrote: > >> On Dec 11, 2008, at 08:50, Joshua Root wrote: >> >>> Ryan Schmidt wrote: >>>> >>>> On Dec 11, 2008, at 02:18, Anders F Bj?rklund wrote: >>>> >>>>> Jeremy Huddleston wrote: >>>>> >>>>>> Is there a way for me to do something like: >>>>>> >>>>>> path:lib/pkgconfig/x11.pc:xorg-libX11 >>>>>> >>>>>> but have that dependency satisfied by /usr/X11/lib/pkgconfig/ >>>>>> x11.pc ? >>>>> >>>>> You can use "${x11prefix}/lib/pkgconfig/x11.pc", >>>> >>>> Actually I'm told you currently can't because variables are not >>>> expanded >>>> in depspecs. >>>> >>>> http://trac.macports.org/ticket/17182 >>> >>> Technically that only seems to be the case for $prefix - but >>> expanding >>> $x11prefix at indexing time is wrong anyway. Yet, it may do just >>> what >>> you want in this particular case. >> >> either way, that's still checking that it's in ${x11prefix} only and >> doesn't let the macports one satisfy it =/ > > The dependency is satisfied if the named port is installed, regardless > of whether it actually provides the specified file. So in this case you would depend on path:/usr/X11/lib/pkgconfig/x11.pc:xorg-libX11 If /usr/X11/lib/pxkgconfig.x11.pc exists that will satisfy (would be the case on Leopard and later), and if not, then port xorg-libX11 will be installed (for Tiger and earlier). Once variables are expanded in depspecs, you could change /usr/X11 to ${x11prefix}. From jeremyhu at macports.org Thu Dec 11 18:34:46 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Thu, 11 Dec 2008 18:34:46 -0800 Subject: path: dependency for files NOT in macports In-Reply-To: <503E96DA-1284-4388-BE95-CA6ECEB1F393@macports.org> References: <59556BE5-DCE5-4F04-83D3-A8AF39ED7D9D@macports.org> <0D5D5809-A6A8-4561-A3D3-F719CF03BF27@macports.org> <494144DD.4080903@macports.org> <171CB3A0-504B-4F30-8E13-EF13B5FE3968@macports.org> <4941AA8D.4070203@macports.org> <503E96DA-1284-4388-BE95-CA6ECEB1F393@macports.org> Message-ID: On Dec 11, 2008, at 17:14, Ryan Schmidt wrote: >> The dependency is satisfied if the named port is installed, >> regardless >> of whether it actually provides the specified file. > > So in this case you would depend on > > path:/usr/X11/lib/pkgconfig/x11.pc:xorg-libX11 > > If /usr/X11/lib/pxkgconfig.x11.pc exists that will satisfy (would be > the case on Leopard and later), and if not, then port xorg-libX11 > will be installed (for Tiger and earlier). Yeah, but what if someone has it in /usr/local/... or whatever... I guess I could do it with ${x11prefix}, but it would still be nice to have a "is this file in any prefix that would be searched for bin: lib: dependencies" kind of dependency such that bin:myapp:myapp would be equivalent to thisnewone:bin/myapp:myapp From ryandesign at macports.org Thu Dec 11 20:06:06 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 11 Dec 2008 22:06:06 -0600 Subject: path: dependency for files NOT in macports In-Reply-To: References: <59556BE5-DCE5-4F04-83D3-A8AF39ED7D9D@macports.org> <0D5D5809-A6A8-4561-A3D3-F719CF03BF27@macports.org> <494144DD.4080903@macports.org> <171CB3A0-504B-4F30-8E13-EF13B5FE3968@macports.org> <4941AA8D.4070203@macports.org> <503E96DA-1284-4388-BE95-CA6ECEB1F393@macports.org> Message-ID: On Dec 11, 2008, at 20:34, Jeremy Huddleston wrote: > On Dec 11, 2008, at 17:14, Ryan Schmidt wrote: > >>> The dependency is satisfied if the named port is installed, >>> regardless >>> of whether it actually provides the specified file. >> >> So in this case you would depend on >> >> path:/usr/X11/lib/pkgconfig/x11.pc:xorg-libX11 >> >> If /usr/X11/lib/pxkgconfig.x11.pc exists that will satisfy (would >> be the case on Leopard and later), and if not, then port xorg- >> libX11 will be installed (for Tiger and earlier). > > Yeah, but what if someone has it in /usr/local/... or whatever... > I guess I could do it with ${x11prefix}, but it would still be nice > to have a "is this file in any prefix that would be searched for > bin: lib: dependencies" kind of dependency such that > bin:myapp:myapp would be equivalent to thisnewone:bin/myapp:myapp It is already unsupported for users to have anything in /usr/local while using MacPorts. We don't want to now reverse that policy. bin: and lib: dependency styles wouldn't search /usr/local. Well, I suppose, unless the user added /usr/local/bin to binpath in macports.conf. But that would be unsupportable. From ryandesign at macports.org Thu Dec 11 22:36:10 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 12 Dec 2008 00:36:10 -0600 Subject: 1.7.0 blocker: xcode portgroup and universal variants In-Reply-To: <20081211204206.GD507@ninagal.withay.com> References: <904BAD94-63D3-450A-A9F4-1A78412D1ECA@macports.org> <20081211204206.GD507@ninagal.withay.com> Message-ID: <466B3B30-BCFE-4AF0-9978-094231A7F330@macports.org> On Dec 11, 2008, at 14:42, Bryan Blackburn wrote: > On Thu, Dec 11, 2008 at 05:01:51AM -0600, Ryan Schmidt said: > >> I don't know what anyone else's thoughts were about how long we >> wanted to >> let 1.7.0-rc1 simmer before releasing 1.7.0 final, but I would >> like to not >> release 1.7.0 until this regression I just found is fixed: >> >> http://trac.macports.org/ticket/17610 > > Since the -sdk option is present in the Xcode group, this doesn't > need to > affect 1.7.0 at all, as the group code is in dports/ [1] and can be > fixed > whenever. > > Bryan > > [1] - port1.0/group/xcode-1.0.tcl> It's true that the xcode portgroup file has moved to the dports directory and that therefore we can fix this issue without needing a new MacPorts release. However, MacPorts 1.6.0 does not use the xcode portgroup file in the dports directory; it uses a different copy of that file which predates this change. So MacPorts 1.6.0 users can currently install xcode-portgroup ports with the universal variant (if the individual ports support it). Some ports like sleepwatcher presently even require the universal variant. If we release MacPorts 1.7.0 without having fixed this issue, Tiger users will no longer be able to install xcode-portgroup ports with the universal variant. So that is a regression I'd rather not have. From ryandesign at macports.org Thu Dec 11 22:40:27 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 12 Dec 2008 00:40:27 -0600 Subject: 64bit variant naming scheme In-Reply-To: <6357C168-6C8F-45DE-90E2-0037581A48DA@enomosphere.net> References: <20081208025934.GM506@ninagal.withay.com> <74c219d30812081043u5f3a60f6r7c6779ee453691f0@mail.gmail.com> <493D7138.6020409@macports.org> <20081208212932.GE506@ninagal.withay.com> <493DA716.1070704@macports.org> <6357C168-6C8F-45DE-90E2-0037581A48DA@enomosphere.net> Message-ID: <11184B2B-5FA2-4142-9584-46B7B2C3F40C@macports.org> On Dec 11, 2008, at 08:18, Takeshi Enomoto wrote: > I think scientific users want not universal (i386 and ppc) but 64- > bit (x86_64 and ppc64) > if they have a 64-bit machine. In MacPorts 1.6.0, "universal" means "i386 ppc" but in MacPorts 1.7.0 and up, it only means "build for multiple architectures". That's what the description next to "universal" says when you type "port variants". Which architectures those are is up to the user; it can be configured in macports.conf by changing the universal_archs variable -- be that "i386 ppc" (the default) or "i386 ppc x86_64 ppc64" or "x86_64 ppc64" or "i386 x86_64" or whatever other combination. > If a package is build for all the four (i386 x86_64 ppc ppc64), > there will be not problem but it is not always easy to support this. > > For example source in fortran is problematic. > gfortran in gcc43 -m64 option but not -arch x86_64 or ppc64. > To build universal one needs to go through build process twice with > -m32 and -m64 > and use lipo later. > I have not yet able to provide g95 64-bit. > > My point is building for two types of cpus and for 32/64 bit are > not always the same > and an average scientific user wants 64 bit version for the host > (her/his local) machine. > > A universal Portfile has been posted for fftw-3, which is under > examination. > > It would be nice if port command itself have a similar function. > > Otherwise it would be nice to enable the user to choose 32/64 bit. The user can choose -- by changing universal_archs in macports.conf. From jmpp at macports.org Thu Dec 11 22:48:12 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Fri, 12 Dec 2008 02:18:12 -0430 Subject: 1.7.0 blocker: xcode portgroup and universal variants In-Reply-To: <466B3B30-BCFE-4AF0-9978-094231A7F330@macports.org> References: <904BAD94-63D3-450A-A9F4-1A78412D1ECA@macports.org> <20081211204206.GD507@ninagal.withay.com> <466B3B30-BCFE-4AF0-9978-094231A7F330@macports.org> Message-ID: <487E4388-FCD0-44CA-BFBE-8B7672F73382@macports.org> On Dec 12, 2008, at 2:06 AM, Ryan Schmidt wrote: > > On Dec 11, 2008, at 14:42, Bryan Blackburn wrote: > >> On Thu, Dec 11, 2008 at 05:01:51AM -0600, Ryan Schmidt said: >> >>> I don't know what anyone else's thoughts were about how long we >>> wanted to >>> let 1.7.0-rc1 simmer before releasing 1.7.0 final, but I would >>> like to not >>> release 1.7.0 until this regression I just found is fixed: >>> >>> http://trac.macports.org/ticket/17610 >> >> Since the -sdk option is present in the Xcode group, this doesn't >> need to >> affect 1.7.0 at all, as the group code is in dports/ [1] and can be >> fixed >> whenever. >> >> Bryan >> >> [1] - > > I'm supposing 1.7.0 sources are properly routed to use the PortGroup files in the dports directory (big woot for that move!), but even still we should maybe consider some upgrade code to delete the soon-to- become-stale files in ${prefix}/share/macports/resources/port1.0/ group/ (and what about the other directories in ${prefix}/share/ macports/resources/, will they move to elsewhere too?). Regards,... -jmpp >> > > It's true that the xcode portgroup file has moved to the dports > directory and that therefore we can fix this issue without needing a > new MacPorts release. However, MacPorts 1.6.0 does not use the xcode > portgroup file in the dports directory; it uses a different copy of > that file which predates this change. So MacPorts 1.6.0 users can > currently install xcode-portgroup ports with the universal variant > (if the individual ports support it). Some ports like sleepwatcher > presently even require the universal variant. If we release MacPorts > 1.7.0 without having fixed this issue, Tiger users will no longer be > able to install xcode-portgroup ports with the universal variant. So > that is a regression I'd rather not have. > > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From jeremyhu at macports.org Fri Dec 12 00:32:22 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Fri, 12 Dec 2008 00:32:22 -0800 Subject: path: dependency for files NOT in macports In-Reply-To: References: <59556BE5-DCE5-4F04-83D3-A8AF39ED7D9D@macports.org> <0D5D5809-A6A8-4561-A3D3-F719CF03BF27@macports.org> <494144DD.4080903@macports.org> <171CB3A0-504B-4F30-8E13-EF13B5FE3968@macports.org> <4941AA8D.4070203@macports.org> <503E96DA-1284-4388-BE95-CA6ECEB1F393@macports.org> Message-ID: On Dec 11, 2008, at 20:06, Ryan Schmidt wrote: > On Dec 11, 2008, at 20:34, Jeremy Huddleston wrote: > >> On Dec 11, 2008, at 17:14, Ryan Schmidt wrote: >> >>>> The dependency is satisfied if the named port is installed, >>>> regardless >>>> of whether it actually provides the specified file. >>> >>> So in this case you would depend on >>> >>> path:/usr/X11/lib/pkgconfig/x11.pc:xorg-libX11 >>> >>> If /usr/X11/lib/pxkgconfig.x11.pc exists that will satisfy (would >>> be the case on Leopard and later), and if not, then port xorg- >>> libX11 will be installed (for Tiger and earlier). >> >> Yeah, but what if someone has it in /usr/local/... or whatever... >> I guess I could do it with ${x11prefix}, but it would still be nice >> to have a "is this file in any prefix that would be searched for >> bin: lib: dependencies" kind of dependency such that >> bin:myapp:myapp would be equivalent to thisnewone:bin/myapp:myapp > > It is already unsupported for users to have anything in /usr/local > while using MacPorts. We don't want to now reverse that policy. > > bin: and lib: dependency styles wouldn't search /usr/local. Well, I > suppose, unless the user added /usr/local/bin to binpath in > macports.conf. But that would be unsupportable. Ok, then I'm satisfied with the path:${x11prefix}/... once that gets expanded... Thanks. From ryandesign at macports.org Fri Dec 12 03:06:30 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 12 Dec 2008 05:06:30 -0600 Subject: [43599] trunk/dports/x11/emiclock/Portfile In-Reply-To: <20081212084134.2EFD5900578@beta.macosforge.org> References: <20081212084134.2EFD5900578@beta.macosforge.org> Message-ID: On Dec 12, 2008, at 02:41, jeremyhu at macports.org wrote: > Revision: 43599 > http://trac.macports.org/changeset/43599 > Author: jeremyhu at macports.org > Date: 2008-12-12 00:41:32 -0800 (Fri, 12 Dec 2008) > Log Message: > ----------- > emiclock: parallel build, not universal, install to correct prefix, > use FreeBSD mirror for master site since upstream 404s. If your change causes this port to install files to different locations than before, then you need to increase its revision so anyone who had it installed already gets forced to rebuild it. > Modified Paths: > -------------- > trunk/dports/x11/emiclock/Portfile > > Modified: trunk/dports/x11/emiclock/Portfile > =================================================================== > --- trunk/dports/x11/emiclock/Portfile 2008-12-12 08:29:07 UTC (rev > 43598) > +++ trunk/dports/x11/emiclock/Portfile 2008-12-12 08:41:32 UTC (rev > 43599) > @@ -12,8 +12,31 @@ > display the menu. > homepage http://www.noge.com/ > platforms darwin > -master_sites ftp://ftp.noge.com/pub/EmiClock/X11/ > +master_sites ftp://ftp.eenet.ee/pub/FreeBSD/distfiles/ > checksums md5 8815b24b928afe4601b8d6ff4c8fc9af > use_xmkmf yes > + > +use_parallel_build yes > +universal_variant no > + > depends_build bin:xmkmf:imake > -destroot.destdir DESTDIR=${destroot} BINDIR=${prefix}/bin > + > +depends_lib \ > + lib:libSM.6:xorg-libsm \ > + lib:libXaw.7:xorg-libXaw \ > + lib:libXmu.6:xorg-libXmu \ > + lib:libXp.6:xorg-libXp \ > + lib:libXpm.4:xpm > + > +build.target-append DESTDIR=${destroot} \ > + BINDIR=${prefix}/bin \ > + LIBDIR=${prefix}/lib \ > + MANDIR=${prefix}/share/man \ > + CONFDIR=${prefix}/lib/X11 > + > +destroot.destdir DESTDIR=${destroot} \ > + BINDIR=${prefix}/bin \ > + LIBDIR=${prefix}/lib \ > + MANDIR=${prefix}/share/man \ > + CONFDIR=${prefix}/lib/X11 > + From jmr at macports.org Fri Dec 12 09:49:14 2008 From: jmr at macports.org (Joshua Root) Date: Sat, 13 Dec 2008 04:49:14 +1100 Subject: 1.7.0 blocker: xcode portgroup and universal variants In-Reply-To: <466B3B30-BCFE-4AF0-9978-094231A7F330@macports.org> References: <904BAD94-63D3-450A-A9F4-1A78412D1ECA@macports.org> <20081211204206.GD507@ninagal.withay.com> <466B3B30-BCFE-4AF0-9978-094231A7F330@macports.org> Message-ID: <4942A41A.2000008@macports.org> Ryan Schmidt wrote: > > On Dec 11, 2008, at 14:42, Bryan Blackburn wrote: > >> On Thu, Dec 11, 2008 at 05:01:51AM -0600, Ryan Schmidt said: >> >>> I don't know what anyone else's thoughts were about how long we >>> wanted to >>> let 1.7.0-rc1 simmer before releasing 1.7.0 final, but I would like >>> to not >>> release 1.7.0 until this regression I just found is fixed: >>> >>> http://trac.macports.org/ticket/17610 >> >> Since the -sdk option is present in the Xcode group, this doesn't need to >> affect 1.7.0 at all, as the group code is in dports/ [1] and can be fixed >> whenever. >> >> Bryan >> >> [1] - >> >> > > It's true that the xcode portgroup file has moved to the dports > directory and that therefore we can fix this issue without needing a new > MacPorts release. However, MacPorts 1.6.0 does not use the xcode > portgroup file in the dports directory; it uses a different copy of that > file which predates this change. So MacPorts 1.6.0 users can currently > install xcode-portgroup ports with the universal variant (if the > individual ports support it). Some ports like sleepwatcher presently > even require the universal variant. If we release MacPorts 1.7.0 without > having fixed this issue, Tiger users will no longer be able to install > xcode-portgroup ports with the universal variant. So that is a > regression I'd rather not have. I'd debate this some more, but I figured this would be faster: "Fixed in r43621." ;-) - Josh From toby at macports.org Fri Dec 12 10:14:52 2008 From: toby at macports.org (Toby Peterson) Date: Fri, 12 Dec 2008 10:14:52 -0800 Subject: do not rely on the fix in r42697 until 1.7 Message-ID: <74c219d30812121014l180b674dxb1240e1bcb010738@mail.gmail.com> User ran into an issue with the 'metis' port because it was relying on a fix that isn't in 1.6. Basically, if you use a custom 'configure' target, ${configure.compiler} and related variables don't get set properly. This requires workarounds like http://trac.macports.org/changeset/43622 Here's the fix in base, for reference: http://trac.macports.org/changeset/42697 - Toby From raimue at macports.org Fri Dec 12 14:56:12 2008 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Fri, 12 Dec 2008 23:56:12 +0100 Subject: [43649] trunk/dports/x11/gtk2/Portfile In-Reply-To: <20081212225231.2D3C89194BD@beta.macosforge.org> References: <20081212225231.2D3C89194BD@beta.macosforge.org> Message-ID: <4942EC0C.6020705@macports.org> jeremyhu at macports.org wrote: > Revision > 43649 > Author > jeremyhu at macports.org > Date > 2008-12-12 14:52:30 -0800 (Fri, 12 Dec 2008) > > > Log Message > > gtk2: Reduce the gtk2 X11 dependencies since some of them are actually optional... Maybe we shold make some variants for the optional X11 extensions? > > > Modified Paths > > * trunk/dports/x11/gtk2/Portfile <#trunkdportsx11gtk2Portfile> > > > Diff > > > Modified: trunk/dports/x11/gtk2/Portfile (43648 => 43649) > > > --- trunk/dports/x11/gtk2/Portfile 2008-12-12 22:51:49 UTC (rev 43648) > +++ trunk/dports/x11/gtk2/Portfile 2008-12-12 22:52:30 UTC (rev 43649) > @@ -130,11 +130,15 @@ > > variant x11 conflicts quartz description {Enable rendering in X11 (default)} { > depends_lib-append \ > - lib:libXrandr.2:xorg-libXrandr \ > - lib:libXcursor.1:xorg-libXcursor \ > - lib:libXfixes.3:xorg-libXfixes \ > lib:libXi.6:xorg-libXi > > + # These are optional dependencies... variants? > + #lib:libXrandr.2:xorg-libXrandr \ > + #lib:libXcursor.1:xorg-libXcursor \ > + #lib:libXdamage.1:xorg-libXdamage \ > + #lib:libXcomposite.1:xorg-libXcomposite \ > + #lib:libXfixes.3:xorg-libXfixes \ > + > configure.args-append --with-xinput > } Will these libraries automatically be used when available? If so, we either need to specify --without-foo or if that is not possible, include them by default. Otherwise dependencies will not be correct in the registry and ports can break when other ports are deactivated/uninstalled, because no dependency was registered. Rainer From jeremyhu at macports.org Fri Dec 12 15:11:24 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Fri, 12 Dec 2008 15:11:24 -0800 Subject: [43649] trunk/dports/x11/gtk2/Portfile In-Reply-To: <4942EC0C.6020705@macports.org> References: <20081212225231.2D3C89194BD@beta.macosforge.org> <4942EC0C.6020705@macports.org> Message-ID: <298E0FCF-BF53-4671-86BF-2B074A9416AB@macports.org> On Dec 12, 2008, at 14:56, Rainer M?ller wrote: >> --- trunk/dports/x11/gtk2/Portfile 2008-12-12 22:51:49 UTC (rev >> 43648) >> +++ trunk/dports/x11/gtk2/Portfile 2008-12-12 22:52:30 UTC (rev >> 43649) >> @@ -130,11 +130,15 @@ >> >> variant x11 conflicts quartz description {Enable rendering in X11 >> (default)} { >> depends_lib-append \ >> - lib:libXrandr.2:xorg-libXrandr \ >> - lib:libXcursor.1:xorg-libXcursor \ >> - lib:libXfixes.3:xorg-libXfixes \ >> lib:libXi.6:xorg-libXi >> >> + # These are optional dependencies... variants? >> + #lib:libXrandr.2:xorg-libXrandr \ >> + #lib:libXcursor.1:xorg-libXcursor \ >> + #lib:libXdamage.1:xorg-libXdamage \ >> + #lib:libXcomposite.1:xorg-libXcomposite \ >> + #lib:libXfixes.3:xorg-libXfixes \ >> + >> configure.args-append --with-xinput >> } > > Will these libraries automatically be used when available? Yeah, they'll be used based on 'pkg-config --exists foo' http://git.testbit.eu/Gtk/tree/configure.in 1541 if $PKG_CONFIG --exists "xrandr >= 1.2" ; then 1542 AC_DEFINE(HAVE_RANDR, 1, [Have the Xrandr extension library]) 1543 1544 X_PACKAGES="$X_PACKAGES xrandr" 1545 fi > If so, we > either need to specify --without-foo or if that is not possible, It's not =/ > include > them by default. ugg... ok. > Otherwise dependencies will not be correct in the > registry and ports can break when other ports are > deactivated/uninstalled, because no dependency was registered. From jeremyhu at macports.org Fri Dec 12 15:45:28 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Fri, 12 Dec 2008 15:45:28 -0800 Subject: Mixing Tiger X11 and Macports X11 In-Reply-To: <298E0FCF-BF53-4671-86BF-2B074A9416AB@macports.org> References: <20081212225231.2D3C89194BD@beta.macosforge.org> <4942EC0C.6020705@macports.org> <298E0FCF-BF53-4671-86BF-2B074A9416AB@macports.org> Message-ID: <07097A37-8023-430B-997E-20FBE4F95C21@macports.org> So, this brings up the same issue as #17558. We have some problems with ports mix Tiger and macports versions of X11 libraries. I haven't narrowed down the exact problem, but we have some conflicts when a some lib that an app uses pulls in one version and the app then links with the other version... example these two cases fail: cairo built using /usr/X11R6/lib/libX11.dylib gtk2 built using /opt/local/lib/libX11.dylib or similarly cairo built using /opt/local/lib/libX11.dylib gtk2 built using /usr/X11R6/lib/libX11.dylib The first case results if you pull in cairo, then later pull in xorg- libX11, then pull in gtk2 (this also happens if we include "all" the gtk2 dependencies because some aren't in Tiger's X11... libCcomposite and libXdamage). The second case results if we pull in xorg-libX11 first, then cairo, then the gtk2 from a couple days ago before I removed the '--x- includes --x-libs configure arg). We get success if both cairo and gtk2 use the same version. Any thoughts about the best way to solve this issue? On Dec 12, 2008, at 15:11, Jeremy Huddleston wrote: > > On Dec 12, 2008, at 14:56, Rainer M?ller wrote: > >>> --- trunk/dports/x11/gtk2/Portfile 2008-12-12 22:51:49 UTC (rev >>> 43648) >>> +++ trunk/dports/x11/gtk2/Portfile 2008-12-12 22:52:30 UTC (rev >>> 43649) >>> @@ -130,11 +130,15 @@ >>> >>> variant x11 conflicts quartz description {Enable rendering in X11 >>> (default)} { >>> depends_lib-append \ >>> - lib:libXrandr.2:xorg-libXrandr \ >>> - lib:libXcursor.1:xorg-libXcursor \ >>> - lib:libXfixes.3:xorg-libXfixes \ >>> lib:libXi.6:xorg-libXi >>> >>> + # These are optional dependencies... variants? >>> + #lib:libXrandr.2:xorg-libXrandr \ >>> + #lib:libXcursor.1:xorg-libXcursor \ >>> + #lib:libXdamage.1:xorg-libXdamage \ >>> + #lib:libXcomposite.1:xorg-libXcomposite \ >>> + #lib:libXfixes.3:xorg-libXfixes \ >>> + >>> configure.args-append --with-xinput >>> } >> >> Will these libraries automatically be used when available? > > Yeah, they'll be used based on 'pkg-config --exists foo' > > http://git.testbit.eu/Gtk/tree/configure.in > > 1541 if $PKG_CONFIG --exists "xrandr >= 1.2" ; then > 1542 AC_DEFINE(HAVE_RANDR, 1, [Have the Xrandr extension library]) > 1543 > 1544 X_PACKAGES="$X_PACKAGES xrandr" > 1545 fi > >> If so, we >> either need to specify --without-foo or if that is not possible, > > It's not =/ > >> include >> them by default. > > ugg... ok. > >> Otherwise dependencies will not be correct in the >> registry and ports can break when other ports are >> deactivated/uninstalled, because no dependency was registered. > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From ryandesign at macports.org Fri Dec 12 17:34:03 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 12 Dec 2008 19:34:03 -0600 Subject: [43649] trunk/dports/x11/gtk2/Portfile In-Reply-To: <20081212225231.2D3C89194BD@beta.macosforge.org> References: <20081212225231.2D3C89194BD@beta.macosforge.org> Message-ID: <9AFD8003-8276-458E-97E0-2E5C9BB8AADF@macports.org> On Dec 12, 2008, at 16:52, jeremyhu at macports.org wrote: > Revision: 43649 > http://trac.macports.org/changeset/43649 > Author: jeremyhu at macports.org > Date: 2008-12-12 14:52:30 -0800 (Fri, 12 Dec 2008) > Log Message: > ----------- > gtk2: Reduce the gtk2 X11 dependencies since some of them are > actually optional... Maybe we shold make some variants for the > optional X11 extensions? Ports should build with maximal functionality by default, unless this is inconvenient due to the number or size of the needed dependencies. Variants should be added sparingly where truly needed. > Modified Paths: > -------------- > trunk/dports/x11/gtk2/Portfile > > Modified: trunk/dports/x11/gtk2/Portfile > =================================================================== > --- trunk/dports/x11/gtk2/Portfile 2008-12-12 22:51:49 UTC (rev 43648) > +++ trunk/dports/x11/gtk2/Portfile 2008-12-12 22:52:30 UTC (rev 43649) > @@ -130,11 +130,15 @@ > > variant x11 conflicts quartz description {Enable rendering in X11 > (default)} { > depends_lib-append \ > - lib:libXrandr.2:xorg-libXrandr \ > - lib:libXcursor.1:xorg-libXcursor \ > - lib:libXfixes.3:xorg-libXfixes \ > lib:libXi.6:xorg-libXi > > + # These are optional dependencies... variants? > + #lib:libXrandr.2:xorg-libXrandr \ > + #lib:libXcursor.1:xorg-libXcursor \ > + #lib:libXdamage.1:xorg-libXdamage \ > + #lib:libXcomposite.1:xorg-libXcomposite \ > + #lib:libXfixes.3:xorg-libXfixes \ > + If gtk2 will automatically find and use these libraries if present, then gtk2 either needs to declare dependencies on the libraries, or it needs to use configure arguments or other strategies to ensure it does not use those libraries even if they are present. From ryandesign at macports.org Fri Dec 12 17:45:00 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 12 Dec 2008 19:45:00 -0600 Subject: [43649] trunk/dports/x11/gtk2/Portfile In-Reply-To: <9AFD8003-8276-458E-97E0-2E5C9BB8AADF@macports.org> References: <20081212225231.2D3C89194BD@beta.macosforge.org> <9AFD8003-8276-458E-97E0-2E5C9BB8AADF@macports.org> Message-ID: <35B0521F-8945-4640-B11D-2BDC5E2B2FD1@macports.org> On Dec 12, 2008, at 19:34, Ryan Schmidt wrote: > Ports should build with maximal functionality by default, unless > this is inconvenient due to the number or size of the needed > dependencies. Variants should be added sparingly where truly needed. >> > If gtk2 will automatically find and use these libraries if present, > then gtk2 either needs to declare dependencies on the libraries, or > it needs to use configure arguments or other strategies to ensure > it does not use those libraries even if they are present. > Sorry, I didn't see Rainer's and your message earlier where you already addressed this. From ryandesign at macports.org Fri Dec 12 20:58:43 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 12 Dec 2008 22:58:43 -0600 Subject: [43656] trunk/dports/python In-Reply-To: <20081213032724.BB8469251F8@beta.macosforge.org> References: <20081213032724.BB8469251F8@beta.macosforge.org> Message-ID: On Dec 12, 2008, at 21:27, wsiegrist at apple.com wrote: > Revision: 43656 > http://trac.macports.org/changeset/43656 > Author: wsiegrist at apple.com > Date: 2008-12-12 19:27:23 -0800 (Fri, 12 Dec 2008) > Log Message: > ----------- > Branching py-ldap to make py25-ldap. Update to version 2.3.5. Could we also update py-ldap to the same version to keep these ports in sync? From ryandesign at macports.org Fri Dec 12 23:54:36 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 13 Dec 2008 01:54:36 -0600 Subject: [43662] trunk/dports/x11/fox/Portfile In-Reply-To: <20081213071849.46634927715@beta.macosforge.org> References: <20081213071849.46634927715@beta.macosforge.org> Message-ID: On Dec 13, 2008, at 01:18, jeremyhu at macports.org wrote: > Revision: 43662 > http://trac.macports.org/changeset/43662 > Author: jeremyhu at macports.org > Date: 2008-12-12 23:18:48 -0800 (Fri, 12 Dec 2008) > Log Message: > ----------- > fox: Updated dependencies, added prefix/include before x11prefix/ > include in cppflags to prefer macports includes over x11prefix ones. Wasn't it always doing that before? It said configure.cppflags-append "-I${x11prefix}/include" so it was appending "-I${x11prefix}/include" to what was already in the cppflags, which was "-I${prefix}/include" > Modified Paths: > -------------- > trunk/dports/x11/fox/Portfile > > Modified: trunk/dports/x11/fox/Portfile > =================================================================== > --- trunk/dports/x11/fox/Portfile 2008-12-13 06:35:29 UTC (rev 43661) > +++ trunk/dports/x11/fox/Portfile 2008-12-13 07:18:48 UTC (rev 43662) > @@ -16,16 +16,18 @@ > checksums md5 66f0a1d316d15d8eee78a8774e9dd8a7 \ > sha1 008acc27ed95d9b3631e63a5b67def4803c2dc4f \ > rmd160 0444c18aa89bf4d083cfba27d05d8a51d575a577 > -depends_lib port:tiff \ > - port:libpng \ > - port:jpeg \ > - port:fontconfig \ > - port:freetype \ > - port:Xft2 \ > - lib:libX11.6:XFree86 > -configure.cppflags-append "-I${x11prefix}/include" > +depends_lib \ > + port:tiff \ > + port:libpng \ > + port:jpeg \ > + lib:libXcursor.1:xorg-libXcursor \ > + lib:libXft.2:Xft2 \ > + lib:libXrandr.2:xorg-libXrandr > + > +configure.cppflags-append "-I${prefix}/include -I${x11prefix}/ > include" > platform darwin 9 { > configure.ldflags-append "-dylib_file /System/Library/Frameworks/ > OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/ > Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib" > } > + > configure.pre_args --prefix=${prefix} --mandir=${prefix}/share/man > configure.args --with-x --with-xft --with-opengl --enable-cups From ryandesign at macports.org Sat Dec 13 00:04:56 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 13 Dec 2008 02:04:56 -0600 Subject: [43663] trunk/dports/x11/fox/Portfile In-Reply-To: <20081213072442.889EA9277B1@beta.macosforge.org> References: <20081213072442.889EA9277B1@beta.macosforge.org> Message-ID: <2AED8E5A-784E-4894-94FD-D6720705C993@macports.org> On Dec 13, 2008, at 01:24, jeremyhu at macports.org wrote: > Revision: 43663 > http://trac.macports.org/changeset/43663 > Author: jeremyhu at macports.org > Date: 2008-12-12 23:24:42 -0800 (Fri, 12 Dec 2008) > Log Message: > ----------- > fox: Removed Xcode 3.0.0 libGL linking bug workaround since it's > been fixed for 3 versions now. Do you mean this problem doesn't occur anymore in the last 3 versions of Xcode (3.1.2, 3.1.1, 3.1.0)? If so, that's (good) news to me. But the Apple Developer Connection article on the problem doesn't mention that: http://developer.apple.com/qa/qa2007/qa1567.html If we're going to remove that bit from portfiles, we might want to in its place put a check to ensure the user has at least Xcode 3.1, e.g.: pre-fetch { if {${os.platform} == "darwin" && ${os.major} == 9} { set minimum_xcodeversion 3.1 set current_xcodeversion [exec defaults read /Developer/ Applications/Xcode.app/Contents/Info CFBundleShortVersionString] if {[rpm-vercomp ${current_xcodeversion} $ {minimum_xcodeversion}] < 0} { return -code error "You have Xcode $ {current_xcodeversion}. Please update to at least Xcode $ {minimum_xcodeversion}." } } } I do something similar in cairo to ensure the user has at least Xcode 2.4.1 on Tiger. > Modified Paths: > -------------- > trunk/dports/x11/fox/Portfile > > Modified: trunk/dports/x11/fox/Portfile > =================================================================== > --- trunk/dports/x11/fox/Portfile 2008-12-13 07:18:48 UTC (rev 43662) > +++ trunk/dports/x11/fox/Portfile 2008-12-13 07:24:42 UTC (rev 43663) > @@ -25,9 +25,6 @@ > lib:libXrandr.2:xorg-libXrandr > > configure.cppflags-append "-I${prefix}/include -I${x11prefix}/ > include" > -platform darwin 9 { > -configure.ldflags-append "-dylib_file /System/Library/Frameworks/ > OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/ > Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib" > -} > > configure.pre_args --prefix=${prefix} --mandir=${prefix}/share/man > configure.args --with-x --with-xft --with-opengl --enable-cups From jeremyhu at macports.org Sat Dec 13 00:31:28 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 13 Dec 2008 00:31:28 -0800 Subject: universal variant and lib: dependencies Message-ID: <94AF7FD2-B8BB-4A5B-8081-3172EDBBFF48@macports.org> When we use lib: dependencies, we search ${x11prefix}, but when we use +universal, we -isysroot /some/path.sdk There are some libs that are can be present in ${x11prefix} but not in the SDK. For instance, libpixman, libcairo, and xcb-util might be satisfied by ${x11prefix} from a user with XQuartz-2.3.2 installed, but those aren't in the actual 10.5.0 SDK that +universal pulls in. Should the search path be altered if we have +universal? From jeremyhu at macports.org Sat Dec 13 00:38:41 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 13 Dec 2008 00:38:41 -0800 Subject: [43662] trunk/dports/x11/fox/Portfile In-Reply-To: References: <20081213071849.46634927715@beta.macosforge.org> Message-ID: On Dec 12, 2008, at 23:54, Ryan Schmidt wrote: > > On Dec 13, 2008, at 01:18, jeremyhu at macports.org wrote: > >> Revision: 43662 >> http://trac.macports.org/changeset/43662 >> Author: jeremyhu at macports.org >> Date: 2008-12-12 23:18:48 -0800 (Fri, 12 Dec 2008) >> Log Message: >> ----------- >> fox: Updated dependencies, added prefix/include before x11prefix/ >> include in cppflags to prefer macports includes over x11prefix ones. > > Wasn't it always doing that before? It said > > configure.cppflags-append "-I${x11prefix}/include" > > so it was appending "-I${x11prefix}/include" to what was already in > the cppflags, which was "-I${prefix}/include" You're right... there were two '-I${x11prefix}/include' in the massive CFLAGS spew and my eyes were blind to the first one (which had the correct -I${prefix}/include already in front of it). From mark at dxradio.demon.co.uk Sat Dec 13 02:33:06 2008 From: mark at dxradio.demon.co.uk (Mark Hattam) Date: Sat, 13 Dec 2008 10:33:06 +0000 Subject: [MacPorts] #14062: Website does not render properly in IE7 In-Reply-To: <064.6777689a33ae965fba656f9c04faca6a@macports.org> References: <055.9b1b96888da488b10a2b6dab3bb48419@macports.org> <064.6777689a33ae965fba656f9c04faca6a@macports.org> Message-ID: The main page works in IE7 on XP Pro ... http://www.macports.org BUT ... some links from it to other pages don't eg the link to "5246 ports" http://www.macports.org/ports.php tries to download a file to you similarly the "get in touch with us" link tries to download a file. yet the link to "installation" http://www.macports.org/install.php does work Mark Hattam -- On 13 Dec 2008, at 06:18, MacPorts wrote: > #14062: Website does not render properly in IE7 > -------------------------------------- > +------------------------------------- > Reporter: wsiegrist@? | Owner: jmpp@? > Type: defect | Status: new > Priority: Normal | Milestone: Website & > Documentation > Component: website | Version: > Keywords: ie7 windows content-type | Port: > -------------------------------------- > +------------------------------------- > > Comment(by ryandesign@?): > > Ok, I tested [attachment:patch-macports-www-ie-mime.diff Rainer's > patch] > locally and committed it in r43660. I made some changes: > > * I included the AcceptMime class in the print_header() function > where > it's used instead of at the top of common.inc > * I put the new files into the existing includes directory instead of > making a new lib directory > * I added lines for the modeline, Id and copyright statement to the > new > files > * I converted tabs to spaces in the new files > * I removed the closing PHP tag in the new files, which is > unnecessary > and would cause a problem if anyone were to add whitespace after the > closing PHP tag > > I verified on my local web server that the page now displays on IE 6 > on > Windows XP. I haven't tested with IE 7 or 8; can someone else with > access > please do that and report back? > > -- > Ticket URL: > MacPorts > Ports system for Mac OS From cedric.lists at gmail.com Sat Dec 13 04:06:25 2008 From: cedric.lists at gmail.com (=?ISO-8859-1?Q?C=E9dric_Luthi?=) Date: Sat, 13 Dec 2008 13:06:25 +0100 Subject: New port: upx 3.03 Message-ID: <32ba1ee20812130406g4a471c2bk7fb10c1c6fad66ce@mail.gmail.com> Hello, I just submitted a new port: upx 3.03 Portfile is attached at https://trac.macports.org/ticket/17623 Could a committer please have a look at it and commit it ? Thanks C?dric Luthi From mcalhoun at macports.org Sat Dec 13 09:34:30 2008 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Sat, 13 Dec 2008 17:34:30 +0000 (UTC) Subject: Which python to use in glib2 Message-ID: I would like to submit a patch to glib2 which forces its python script to use a MacPorts python (see http://trac.macports.org/ticket/17530). I do not use the script in question (gtester-report), so I can not say with certainty which python to use. Might anyone who uses gtester-report be able to comment? -Marcus From illogical1 at gmail.com Sat Dec 13 12:23:06 2008 From: illogical1 at gmail.com (Big O) Date: Sat, 13 Dec 2008 15:23:06 -0500 Subject: [43452] trunk/dports/perl/p5-test-object/Portfile In-Reply-To: <462E1838-C5A3-45E2-A5A7-544D6B813F00@macports.org> References: <20081210230525.62D228DCB5C@beta.macosforge.org> <6DEA841D-4688-4ADA-B82A-FC725E884A54@macports.org> <462E1838-C5A3-45E2-A5A7-544D6B813F00@macports.org> Message-ID: On Dec 10, 2008, at 7:13 PM, Ryan Schmidt wrote: > > On Dec 10, 2008, at 18:06, Ryan Schmidt wrote: > >> On Dec 10, 2008, at 17:05, narf_tm at macports.org wrote: >> >>> Revision: 43452 >>> http://trac.macports.org/changeset/43452 >>> Author: narf_tm at macports.org >>> Date: 2008-12-10 15:05:24 -0800 (Wed, 10 Dec 2008) >>> Log Message: >>> ----------- >>> Fixed dependancies. >> >> "dependencies". :) I've been fixing your log messages. > > Hmm. On second thought, while the Mac OS X Dictionary.app doesn't > have "dependancies" (only had "dependencies" -- on Tiger, anyway), > the spell checker recognizes both. I guess it's an alternate > spelling. So never mind this bit, sorry for the noise. :) Nope dependancies is definately wrong. I even suspect this might have been delibarate. > > >> Don't forget to list everything you change in your commit messages. >> For example here you also made whitespace changes. Ideally you >> would commit whitespace changes in a separate commit from other >> changes, so that it's easier to ignore the whitespace changes when >> looking through the revisions and more clearly see the changes that >> actually matter. > > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From ryandesign at macports.org Sat Dec 13 13:12:54 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 13 Dec 2008 15:12:54 -0600 Subject: [43674] trunk/dports/audio/esound/Portfile In-Reply-To: <20081213165302.2E570929CAF@beta.macosforge.org> References: <20081213165302.2E570929CAF@beta.macosforge.org> Message-ID: <57652BBF-3E11-4B58-ACFF-501D44C0C3D1@macports.org> On Dec 13, 2008, at 10:53, mcalhoun at macports.org wrote: > Revision: 43674 > http://trac.macports.org/changeset/43674 > Author: mcalhoun at macports.org > Date: 2008-12-13 08:53:01 -0800 (Sat, 13 Dec 2008) > Log Message: > ----------- > esound: For OS X >= Leopard, prevent esound from trying to get the > host name from the DISPLAY environment variable. > Replace patchfiles with reinplace. > Fixes #13848. Just out of curiosity, why replace patchfiles with reinplace calls? I find patchfiles to be nicer because they give context on what's being changed (line numbers and a few lines before and after). If the source changes in a future version and a patch no longer applies, you can compare the source and the patch and usually get some idea of how the patch needs to be changed to apply again. Plus until we commit the patch in #15514 and release a new version of MacPorts, you won't get any warning if a reinplace fails. http://trac.macports.org/ticket/15514 If you really do want to use reinplace instead, then you should remove the patchfiles too. From ryandesign at macports.org Sat Dec 13 13:26:54 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 13 Dec 2008 15:26:54 -0600 Subject: Which python to use in glib2 In-Reply-To: References: Message-ID: <47E6DBA8-F52E-4111-862F-72B9B4CA18B2@macports.org> On Dec 13, 2008, at 11:34, Marcus Calhoun-Lopez wrote: > I would like to submit a patch to glib2 which forces its python > script to use > a MacPorts python (see http://trac.macports.org/ticket/17530). > > I do not use the script in question (gtester-report), so I can not > say with > certainty which python to use. > Might anyone who uses gtester-report be able to comment? Does gtester-report need a specific version of python? Does it need any python modules? I'm not sure we need to pull in a whole python port -- especially a specific version -- if the script would work just fine with the system python and I don't know if anyone uses it anyway. If we need MacPorts python, do we need to provide variants for the several python versions available? Or maybe we could depend on python_select? Your patch also adds a perl5 dependency for glib-mkenums. I see glib- mkenums does reference ${prefix}/bin/perl in its shebang line. So I guess there's no excuse for not adding that perl5 dependency. From andrea.damore at macports.org Sat Dec 13 14:01:15 2008 From: andrea.damore at macports.org (Andrea D'Amore) Date: Sat, 13 Dec 2008 23:01:15 +0100 Subject: [MacPorts] #14062: Website does not render properly in IE7 In-Reply-To: References: <055.9b1b96888da488b10a2b6dab3bb48419@macports.org> <064.6777689a33ae965fba656f9c04faca6a@macports.org> Message-ID: On 13/dic/08, at 11:33, Mark Hattam wrote: > The main page works in IE7 on XP Pro ... > http://www.macports.org "works" can have different meanings in this context, > BUT ... some links from it to other pages don't > eg the link to "5246 ports" > http://www.macports.org/ports.php > http://www.macports.org/install.php > does work Weird enough first and third link gives the same Content-Type and still you have different behaviors, can you try IE7 on a different system? Can you paste the headers you're actuall getting from the server? > Mark Hattam Andrea From mcalhoun at macports.org Sat Dec 13 14:39:54 2008 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Sat, 13 Dec 2008 22:39:54 +0000 (UTC) Subject: [43674] trunk/dports/audio/esound/Portfile References: <20081213165302.2E570929CAF@beta.macosforge.org> <57652BBF-3E11-4B58-ACFF-501D44C0C3D1@macports.org> Message-ID: Ryan Schmidt writes: > Just out of curiosity, why replace patchfiles with reinplace calls? You make a good case for patchfiles, but, just as a personal preference, I default to reinplace. Usually, I find them easier to understand as I read, line by line, through a Portfile. Of course, in either case, a well constructed comment is very helpful. I only use esound as a part of other ports, so I am happy to change it back if there are strong objections. > If you really do want to use reinplace instead, then you should > remove the patchfiles too. I was going to keep them around for a few days in case my use of reinplace caused problems. Although I suppose a call to "svn copy" to resurrect a deleted file is not too onerous a task. -Marcus From mcalhoun at macports.org Sat Dec 13 15:47:19 2008 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Sat, 13 Dec 2008 23:47:19 +0000 (UTC) Subject: Which python to use in glib2 References: <47E6DBA8-F52E-4111-862F-72B9B4CA18B2@macports.org> Message-ID: Ryan Schmidt writes: > Does gtester-report need a specific version of python? Does it need > any python modules? The configure script requires that the version >= 2.4. The script itself calls import sys, re, xml.dom.minidom I believe they are standard. From blb at macports.org Sat Dec 13 20:12:39 2008 From: blb at macports.org (Bryan Blackburn) Date: Sat, 13 Dec 2008 21:12:39 -0700 Subject: MacPorts 1.7.0 has been released Message-ID: <20081214041239.GF530@ninagal.withay.com> The MacPorts Project is happy to announce that, after nearly a year in the making, the 1.7.0 version has been released. It is now available via the usual methods: - selfupdate if you already have it installed - package installers in DMGs for 10.3 [1], 10.4 [2], and 10.5 [3] (the latter two being universal builds) - source tarballs, both .tar.bz2 [4] and .tar.gz [5] - subversion tag [6] The list of what's new in 1.7.0 is quite extensive (so I won't list it here), the details can be found in the NEWS [7] file or the somewhat more exhaustive ChangeLog [8]. A big thanks to the developers for their hard work with all of the various features and bug fixes in 1.7.0, and to everyone for your patience while waiting for this version. Detached PGP signatures for the DMGs and source tarballs have been made with my key, which is available on the keyservers and my MacPorts wiki page [9]. Bryan [1] - [2] - [3] - [4] - [5] - [6] - [7] - [8] - [9] - PS, my PGP key ID is 2952D7AF, fingerprint BEB4 6B21 320E 737F F176 2D15 C853 3784 2952 D7AF -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jm at poure.com Sun Dec 14 04:15:15 2008 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sun, 14 Dec 2008 13:15:15 +0100 Subject: Request for MLT and Kdenlive inclusion in MacPorts Message-ID: <1229256915.7749.2.camel@debian> Dear Friends, Kdenlive is a Free and Open-source video editor: http://www.kdenlive.org Would it be possible to include Kdenlive and MLT video engine in MacPorts. At Kdenlive team, we are ready to support and answer questions. Kind regards, Jean-Michel From apple at frinabulax.org Sun Dec 14 04:39:44 2008 From: apple at frinabulax.org (robert delius royar) Date: Sun, 14 Dec 2008 07:39:44 -0500 Subject: [43674] trunk/dports/audio/esound/Portfile In-Reply-To: <57652BBF-3E11-4B58-ACFF-501D44C0C3D1@macports.org> References: <20081213165302.2E570929CAF@beta.macosforge.org> <57652BBF-3E11-4B58-ACFF-501D44C0C3D1@macports.org> Message-ID: Sat, 13 Dec 2008 (15:12 -0600 UTC) Ryan Schmidt wrote: > > On Dec 13, 2008, at 10:53, mcalhoun at macports.org wrote: > >> Revision: 43674 >> http://trac.macports.org/changeset/43674 >> Author: mcalhoun at macports.org >> Date: 2008-12-13 08:53:01 -0800 (Sat, 13 Dec 2008) >> Log Message: >> ----------- >> esound: For OS X >= Leopard, prevent esound from trying to get the host >> name from the DISPLAY environment variable. >> Replace patchfiles with reinplace. >> Fixes #13848. > > Just out of curiosity, why replace patchfiles with reinplace calls? I find > patchfiles to be nicer because they give context on what's being changed > (line numbers and a few lines before and after). If the source changes in a > future version and a patch no longer applies, you can compare the source and > the patch and usually get some idea of how the patch needs to be changed to > apply again. Plus until we commit the patch in #15514 and release a new > version of MacPorts, you won't get any warning if a reinplace fails. > > http://trac.macports.org/ticket/15514 > > If you really do want to use reinplace instead, then you should remove the > patchfiles too. I tried to reopen this ticket (#13848), but I do not have the permission. I added a comment to it from another account (x11 at frinabulax dot org). The reinplace patch does not fix the original problem. It may be it fixes another problem. I grabbed the current sources after upgrading the macports installed port resulted in esdplay not being able to play sounds (nor was XEmacs able to play its alerts). I added back the "fix" I submitted in the original patch (ticket 13848), and both esdplay and XEmacs are making sounds again. I do not believe that the logic that encloses the reinplace change (the flow logic in esdlib.c) is reached in all cases, and the case where the esd program would fail for me was one of those. My original patch is not the correct way, that, I would leave to a programmer. The two problems with my patch are that it will not be correct if other servers than :0 are running, and it does not check to see if the OS X version is one that uses launchd sockets. -- Dr. Robert Delius Royar Associate Professor of English Morehead State University Morehead, Kentucky From jberry at macports.org Sun Dec 14 09:00:04 2008 From: jberry at macports.org (James Berry) Date: Sun, 14 Dec 2008 09:00:04 -0800 Subject: MacPorts 1.7.0 has been released In-Reply-To: <20081214041239.GF530@ninagal.withay.com> References: <20081214041239.GF530@ninagal.withay.com> Message-ID: <5C1DBB06-BC59-4D9D-A1F3-20B2F46F10E1@macports.org> Congratulations to all of those who worked so hard on this release, and who pulled the final rabbit out of the hat by releasing it! Well done. James On Dec 13, 2008, at 8:12 PM, Bryan Blackburn wrote: > The MacPorts Project is happy to announce that, after nearly a year in > the making, the 1.7.0 version has been released. It is now available > via the usual methods: From illogical1 at gmail.com Sun Dec 14 10:27:05 2008 From: illogical1 at gmail.com (O) Date: Sun, 14 Dec 2008 13:27:05 -0500 Subject: Request for MLT and Kdenlive inclusion in MacPorts In-Reply-To: <1229256915.7749.2.camel@debian> References: <1229256915.7749.2.camel@debian> Message-ID: <797cc39c0812141027y6761a852q5d4b1aebdd01b0a8@mail.gmail.com> On Sun, Dec 14, 2008 at 7:15 AM, Jean-Michel Pour? wrote: > Dear Friends, > > Kdenlive is a Free and Open-source video editor: > http://www.kdenlive.org > > Would it be possible to include Kdenlive and MLT video engine in > MacPorts. At Kdenlive team, we are ready to support and answer > questions. Looks like you guys the only thing missing are portfiles for MLT and kdenlive respectively. Do you guys know if MLT builds on OS X and if it doesn't would you be willing to do the dirty work of getting it to? > > Kind regards, > Jean-Michel > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -- Robert Orben - "Older people shouldn't eat health food, they need all the preservatives they can get." From jm at poure.com Sun Dec 14 10:34:55 2008 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sun, 14 Dec 2008 19:34:55 +0100 Subject: Request for MLT and Kdenlive inclusion in MacPorts In-Reply-To: <797cc39c0812141027y6761a852q5d4b1aebdd01b0a8@mail.gmail.com> References: <1229256915.7749.2.camel@debian> <797cc39c0812141027y6761a852q5d4b1aebdd01b0a8@mail.gmail.com> Message-ID: <1229279695.18180.10.camel@debian> On Sun, 2008-12-14 at 13:27 -0500, O wrote: > Do you guys know if MLT builds on OS X and if it doesn't would you be > willing to do the dirty work of getting it to? MLT latest SVN builds under MacOsX. I saw patches these last days. As regards Kdenlive, I don't run MacOsX, I am runnig Gnu/Linux otherwize I would help you. I think Kdenlive should compile rightaway. Compiling instructions: http://www.kdenlive.org/user-manual/downloading-and-installing-packages/installing-source Kind regards, Jean-Michel From illogical1 at gmail.com Sun Dec 14 10:47:27 2008 From: illogical1 at gmail.com (O) Date: Sun, 14 Dec 2008 13:47:27 -0500 Subject: Request for MLT and Kdenlive inclusion in MacPorts In-Reply-To: <1229279695.18180.10.camel@debian> References: <1229256915.7749.2.camel@debian> <797cc39c0812141027y6761a852q5d4b1aebdd01b0a8@mail.gmail.com> <1229279695.18180.10.camel@debian> Message-ID: <797cc39c0812141047i4db2480ar4c7b7977e6a5ed5c@mail.gmail.com> On Sun, Dec 14, 2008 at 1:34 PM, Jean-Michel Pour? wrote: > On Sun, 2008-12-14 at 13:27 -0500, O wrote: >> Do you guys know if MLT builds on OS X and if it doesn't would you be >> willing to do the dirty work of getting it to? > > MLT latest SVN builds under MacOsX. I saw patches these last days. Ryan will correct me if I'm wrong, but I believe only software with tarball releases are added to the ports tree except for a few necessary exceptions (ffmpeg for instance. which never releases a tarball), so we'd probably wait for a release with actual support for OS X. > As regards Kdenlive, I don't run MacOsX, I am runnig Gnu/Linux otherwize > I would help you. I think Kdenlive should compile rightaway. Having gotten some of kde4 into macports I've found gcc is a fickle beast however and that this is not necessarily so. > > Compiling instructions: > http://www.kdenlive.org/user-manual/downloading-and-installing-packages/installing-source Yeah I saw that. That's a lot of stuff, luckily most of it is already in macports. Given that most portfiles (which are maintained) are done by volunteers you'd need someone to step up and do this. I'd suggest emailing the kde-mac mailing list, or heading to the irc channel (#kde-mac) if no one here volunteers to adopt kdenlive. Alternatively you could provide the portfile and ask the kde-mac folks to test. I find that, for me, the greatest inertia in adding a new package is creating a portfile and once that done I'll keep at it till it compiles or I figure out why it isn't :-) > > Kind regards, > Jean-Michel > > -- Chevy Chase - "Parrots make great pets. They have more personality than goldfish." From florian.ebeling at gmail.com Sun Dec 14 12:08:03 2008 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Sun, 14 Dec 2008 21:08:03 +0100 Subject: MacPorts 1.7.0 has been released In-Reply-To: <20081214041239.GF530@ninagal.withay.com> References: <20081214041239.GF530@ninagal.withay.com> Message-ID: <5cbbe4ae0812141208x739f1785k458714c72c1559e4@mail.gmail.com> On Sun, Dec 14, 2008 at 5:12 AM, Bryan Blackburn wrote: > The MacPorts Project is happy to announce that, after nearly a year in > the making, the 1.7.0 version has been released. Congratulations to all the release and new management team! I didn't have any issues since. And it looks like a very rounded release as well. I might have released ealier and a bit less rounded but that's matter of taste for sure. I'm really happy to see this. Cheers, Florian -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From florian.ebeling at gmail.com Sun Dec 14 12:16:52 2008 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Sun, 14 Dec 2008 21:16:52 +0100 Subject: Fwd: MacPorts Bug? In-Reply-To: <49454ADA.5050908@utoronto.ca> References: <49454ADA.5050908@utoronto.ca> Message-ID: <5cbbe4ae0812141216v241847b0t218b833f2f7f895d@mail.gmail.com> This is a message from the couchdb list also involving MacPorts. ---------- Forwarded message ---------- From: Ivan Avery Frey Date: Sun, Dec 14, 2008 at 7:05 PM Subject: MacPorts Bug? To: dev at couchdb.apache.org I just got couchdb working again on my PowerBook G4 with Tiger (10.4.11). What happened was after I installed couchdb I did a "sudo port -d upgrade couchdb". The icu port got upgraded to 4.0. Now when I went to run couchdb it went looking for 3.8 versions of the ICU libraries which no longer existed. A uninstall install of couchdb fixed the problem. Have I reported this bug in the right place? --- snip --- Do we have any slick response for this, or does 'port upgrade' just keep the dependants binaries with dangling links to nothing. I would have thought that the nice answer would be that the dependant should actuallt point to the depot location of the library, which should be in the same location after the upgrde as before. Only I'm not sure that e.g. a autotool package as couchdb looks into depot, and not just in /opt/local/lib. Does a simple 'port upgrade' can leave broken packages behind? Is there maybe an open ticket for this? Florian -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From jmr at macports.org Sun Dec 14 12:32:26 2008 From: jmr at macports.org (Joshua Root) Date: Mon, 15 Dec 2008 07:32:26 +1100 Subject: Fwd: MacPorts Bug? In-Reply-To: <5cbbe4ae0812141216v241847b0t218b833f2f7f895d@mail.gmail.com> References: <49454ADA.5050908@utoronto.ca> <5cbbe4ae0812141216v241847b0t218b833f2f7f895d@mail.gmail.com> Message-ID: <49456D5A.4090907@macports.org> C. Florian Ebeling wrote: > This is a message from the couchdb list also involving MacPorts. > > ---------- Forwarded message ---------- > From: Ivan Avery Frey > Date: Sun, Dec 14, 2008 at 7:05 PM > Subject: MacPorts Bug? > To: dev at couchdb.apache.org > > I just got couchdb working again on my PowerBook G4 with Tiger (10.4.11). > > What happened was after I installed couchdb I did a "sudo port -d > upgrade couchdb". The icu port got upgraded to 4.0. Now when I went to > run couchdb it went looking for 3.8 versions of the ICU libraries which > no longer existed. > > A uninstall install of couchdb fixed the problem. Have I reported this > bug in the right place? > --- snip --- > > Do we have any slick response for this, or does 'port upgrade' just keep > the dependants binaries with dangling links to nothing. > > I would have thought that the nice answer would be that the dependant should > actuallt point to the depot location of the library, which should be > in the same > location after the upgrde as before. Only I'm not sure that e.g. a > autotool package > as couchdb looks into depot, and not just in /opt/local/lib. > > Does a simple 'port upgrade' can leave broken packages behind? Is there maybe an > open ticket for this? Yes, it's a real problem when library versions change. Ticket: - Josh From blb at macports.org Sun Dec 14 13:20:57 2008 From: blb at macports.org (Bryan Blackburn) Date: Sun, 14 Dec 2008 14:20:57 -0700 Subject: Request for MLT and Kdenlive inclusion in MacPorts In-Reply-To: <797cc39c0812141047i4db2480ar4c7b7977e6a5ed5c@mail.gmail.com> References: <1229256915.7749.2.camel@debian> <797cc39c0812141027y6761a852q5d4b1aebdd01b0a8@mail.gmail.com> <1229279695.18180.10.camel@debian> <797cc39c0812141047i4db2480ar4c7b7977e6a5ed5c@mail.gmail.com> Message-ID: <20081214212057.GD489@ninagal.withay.com> On Sun, Dec 14, 2008 at 01:47:27PM -0500, O said: > On Sun, Dec 14, 2008 at 1:34 PM, Jean-Michel Pour? wrote: > > > > MLT latest SVN builds under MacOsX. I saw patches these last days. > Ryan will correct me if I'm wrong, but I believe only software with > tarball releases are added to the ports tree except for a few > necessary exceptions (ffmpeg for instance. which never releases a > tarball), so we'd probably wait for a release with actual support for > OS X. If you call it mlt-devel there definitely wouldn't be an issue with pulling it from svn; if they only offer svn access, no tarballs, then there's really no choice but to pull from svn then. Bryan [...] > > > > Kind regards, > > Jean-Michel > > > -- > > Chevy Chase - "Parrots make great pets. They have more personality > than goldfish." From jeremyhu at macports.org Sun Dec 14 16:53:47 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 14 Dec 2008 16:53:47 -0800 Subject: X11 checks in configure phase for some packages In-Reply-To: References: Message-ID: <43C6E9D1-6217-4BF7-87FA-7DDAC6537E5D@macports.org> That is fixed in autoconf-2.63. The m4 macro you are referring to is AC_X_PATH. If you see a port failing this, first check if it is REALLY failing. Some ports do AC_X_PATH followed by some PKG_CONFIG checks for X11 (IMO, this itself is a bug since the PKG_CONFIG results are far superior to the AC_X_PATH results)... but none the less, make sure the port is actually failing to find X. If it is misbehaving, you probably need to: depends_build port:autoconf # and probably port:automake and port:libtool too use_autoreconf yes If that fails, you may need to do some autoreconf.env setting like: autoreconf.env ACLOCAL="aclocal -I " See the x11/lesstif port. That one was particularly annoying. Setting '--x-include=${x11prefix}/include --x-lib=${x11prefix}/lib' is not the best way to address that. --Jeremy On Dec 14, 2008, at 16:34, Fred Dushin wrote: > I've found a few ports that have had issues checking for X11 > libraries and headers during configuration. Hacking my way through > the configure scripts, I've found lines in the checking of X11 libs > like: > > for ac_extension in a so sl; do > > which of course works fine on Solaris, Linux, BSD, and HP/UX. > Changing this to: > > for ac_extension in a so sl dylib; do > > fixes the configure phase, and the package then installs properly. > > I found this lately with the start-notification package, and I'm > wonder if I am doing something fundamentally wrong. There have been > others like this in the past, but I didn't take record of them. > > Model Name: MacBook > Model Identifier: MacBook2,1 > System Version: Mac OS X 10.5.5 (9F33) > > > port version > Version: 1.700 > > XQuartz 2.3.1 > > I also installed the X11SDK from the Leopard install disk, just to > make sure. > _______________________________________________ > macports-users mailing list > macports-users at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-users From blb at macports.org Sun Dec 14 23:05:15 2008 From: blb at macports.org (Bryan Blackburn) Date: Mon, 15 Dec 2008 00:05:15 -0700 Subject: 1.7 and ports setting MDT Message-ID: <20081215070515.GB71970@ninagal.withay.com> Now that 1.7 has been released, I think we can update ports which manually set MACOSX_DEPLOYMENT_TARGET as that's done by port 1.7. The follow ports appear to set MDT either for one OS version or 10.3-10.5: devel/glib2 devel/glib2-devel devel/gnutls devel/libsigsegv gnome/evolution-data-server graphics/graphviz graphics/graphviz-devel graphics/vtk5 lang/clisp lang/pfe mail/gnupg2 net/ethereal net/ldns net/tcpflow net/wireshark perl/p5-mecab python/py-psycopg security/dirmngr security/gpg-agent security/xmlsec textproc/libiconv textproc/libxml2 textproc/libxslt textproc/mecab sysutils/burn-app Anyone see issues with removing the MDT stuff in those? Bryan From jm at poure.com Mon Dec 15 01:06:21 2008 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Mon, 15 Dec 2008 10:06:21 +0100 Subject: Request for MLT and Kdenlive inclusion in MacPorts In-Reply-To: <20081214212057.GD489@ninagal.withay.com> References: <1229256915.7749.2.camel@debian> <797cc39c0812141027y6761a852q5d4b1aebdd01b0a8@mail.gmail.com> <1229279695.18180.10.camel@debian> <797cc39c0812141047i4db2480ar4c7b7977e6a5ed5c@mail.gmail.com> <20081214212057.GD489@ninagal.withay.com> Message-ID: <1229331981.13247.2.camel@debian> On Sun, 2008-12-14 at 14:20 -0700, Bryan Blackburn wrote: > If you call it mlt-devel there definitely wouldn't be an issue with > pulling > it from svn; if they only offer svn access, no tarballs, then there's > really > no choice but to pull from svn then. Dan made changes lately in SVN to allow compilation under MacOsX. But I did not test myself. If you can compile MLT with the required options, then we can ask Dan to release MLT. Can you try compiling: http://www.kdenlive.org/user-manual/downloading-and-installing-kdenlive/installing-source Get back to me on macports list and we can organize a release soon. Kind regards, Jean-Michel From Ian.Grant at cl.cam.ac.uk Mon Dec 15 07:40:49 2008 From: Ian.Grant at cl.cam.ac.uk (Ian Grant) Date: Mon, 15 Dec 2008 15:40:49 +0000 Subject: Moscow ML port Message-ID: <20081215154049.71eb12f0@vignemale.cl.cam.ac.uk> Dear list, I sent this on Wednesday last week but I have no evidence it ever reached macports-devel. I have not yet had any response from the maintainer of the port. What should one do in this circumstance? For info, the dynamic libraries are a part of the Moscow ML distribution. I presume it was just because of technical difficulties that they were not enabled in the original mosml port. The technical difficulties have all been overcome! Ian Begin forwarded message: Date: Wed, 10 Dec 2008 14:24:03 +0000 From: Ian Grant To: cso at rift.dk Cc: Ian Grant , MacPorts Dev Subject: Moscow ML port on MacPorts/DarwinPorts Dear cso at rift.dk I have made a port of the Moscow ML dynamic libraries: intinf, crypt, munix, mregex, msocket, mgdbm, mgd on MacOS X. It requires a small change to the current mosml port. Attached is a diff of the Portfile change and a new patch (which is needed by both ports), as well as a Portfile for the new mosml-dynlibs port. Since the mosml-dynlibs port requires the patched mosml port I guess the mosml-dynlibs port should be made to depend on the newer mosml so people with the older mosml will be forced to upgrade to the newer before adding mosml-dynlibs. But I don't know how to specify the port version in a dependency. Is this possible? Could you let me know whether you would be happy to commit these changes (if not tell me what I need to change) and also whether you would be able to be the maintainer of the dynamic libraries port as well? (I am not a registered MacPorts developer and have no svn access.) Best wishes Ian Grant -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile-lang-mosml.diff Type: application/octet-stream Size: 1109 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile-lang-mosml-dynlibs Type: application/octet-stream Size: 1076 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-src-dynlibs.diff Type: application/octet-stream Size: 6192 bytes Desc: not available URL: From blb at macports.org Mon Dec 15 14:14:31 2008 From: blb at macports.org (Bryan Blackburn) Date: Mon, 15 Dec 2008 15:14:31 -0700 Subject: [43844] trunk/dports/lang/python25/Portfile In-Reply-To: <20081215215347.9B0E2973B75@beta.macosforge.org> References: <20081215215347.9B0E2973B75@beta.macosforge.org> Message-ID: <20081215221431.GB729@ninagal.withay.com> On Mon, Dec 15, 2008 at 01:53:47PM -0800, jeremyhu at macports.org said: > Revision: 43844 > http://trac.macports.org/changeset/43844 [...] > > variant universal { > - configure.args-append --enable-universalsdk > + configure.args-append --enable-universalsdk=${universal_sysroot} Do we have a preferred variable to use for the SDK location? I see both configure.universal_sysroot (which I use in python26) and universal_sysroot work in Portfiles. The latter is the name of the variable in macports.conf as well, which is then used to set the configure... version. Bryan From wsiegrist at apple.com Mon Dec 15 14:34:48 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 15 Dec 2008 14:34:48 -0800 Subject: [43656] trunk/dports/python In-Reply-To: References: <20081213032724.BB8469251F8@beta.macosforge.org> Message-ID: <67B4A803-A275-4C06-BE18-1A5FCC142382@apple.com> On Dec 12, 2008, at 8:58 PM, Ryan Schmidt wrote: > On Dec 12, 2008, at 21:27, wsiegrist at apple.com wrote: > >> Revision: 43656 >> http://trac.macports.org/changeset/43656 >> Author: wsiegrist at apple.com >> Date: 2008-12-12 19:27:23 -0800 (Fri, 12 Dec 2008) >> Log Message: >> ----------- >> Branching py-ldap to make py25-ldap. Update to version 2.3.5. > > Could we also update py-ldap to the same version to keep these ports > in sync? > I didnt want to bump it without testing, and I dont have a python24 install handy. I'll try to build python24 and test py-ldap with v2.3.5 later today. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available URL: From devans at macports.org Mon Dec 15 14:48:57 2008 From: devans at macports.org (David Evans) Date: Mon, 15 Dec 2008 14:48:57 -0800 Subject: [43834] trunk/dports/x11/gtk2/Portfile In-Reply-To: <20081215212310.03E9C9726D2@beta.macosforge.org> References: <20081215212310.03E9C9726D2@beta.macosforge.org> Message-ID: <4946DED9.6000900@macports.org> jeremyhu at macports.org wrote: > > Revision > 43834 > Author > jeremyhu at macports.org > Date > 2008-12-15 13:23:09 -0800 (Mon, 15 Dec 2008) > > > > - configure.args-append --with-xinput > + > + configure.args-append --with-xinput --enable-xinerama > } > > livecheck.check regex > Perhaps you should increment the revision since the libraries linked to may potentially change. From jeremyhu at macports.org Mon Dec 15 19:12:29 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Mon, 15 Dec 2008 19:12:29 -0800 Subject: [43834] trunk/dports/x11/gtk2/Portfile In-Reply-To: <4946DED9.6000900@macports.org> References: <20081215212310.03E9C9726D2@beta.macosforge.org> <4946DED9.6000900@macports.org> Message-ID: <1A7B4C40-C131-485C-9F5D-474F9A147E83@macports.org> On Dec 15, 2008, at 14:48, David Evans wrote: > jeremyhu at macports.org wrote: >> >> Revision >> 43834 >> Author >> jeremyhu at macports.org >> Date >> 2008-12-15 13:23:09 -0800 (Mon, 15 Dec 2008) >> >> >> >> - configure.args-append --with-xinput >> + >> + configure.args-append --with-xinput --enable-xinerama >> } >> >> livecheck.check regex >> > Perhaps you should increment the revision since the libraries linked > to > may potentially change. libXinerama is going to be on everyone's system unless they are testing out a macports-only X11 with x11prefix=$prefix ... If libXinerama is present, then it's automatically used. That configure setting was more to emphasize its use (so maybe it shouldn't be there now since libXinerama is in the depends_lib anyways) and guarantee backwards compatability if a future gtk2 release to ensure better compatibility... From devans at macports.org Mon Dec 15 21:53:35 2008 From: devans at macports.org (David Evans) Date: Mon, 15 Dec 2008 21:53:35 -0800 Subject: [43834] trunk/dports/x11/gtk2/Portfile In-Reply-To: <1A7B4C40-C131-485C-9F5D-474F9A147E83@macports.org> References: <20081215212310.03E9C9726D2@beta.macosforge.org> <4946DED9.6000900@macports.org> <1A7B4C40-C131-485C-9F5D-474F9A147E83@macports.org> Message-ID: <4947425F.3080609@macports.org> Jeremy Huddleston wrote: > > On Dec 15, 2008, at 14:48, David Evans wrote: > >> jeremyhu at macports.org wrote: >>> >>> Revision >>> 43834 >>> Author >>> jeremyhu at macports.org >>> Date >>> 2008-12-15 13:23:09 -0800 (Mon, 15 Dec 2008) >>> >>> >>> >>> - configure.args-append --with-xinput >>> + >>> + configure.args-append --with-xinput --enable-xinerama >>> } >>> >>> livecheck.check regex >>> >> Perhaps you should increment the revision since the libraries linked to >> may potentially change. > > libXinerama is going to be on everyone's system unless they are > testing out a macports-only X11 with x11prefix=$prefix ... If > libXinerama is present, then it's automatically used. That configure > setting was more to emphasize its use (so maybe it shouldn't be there > now since libXinerama is in the depends_lib anyways) and guarantee > backwards compatability if a future gtk2 release to ensure better > compatibility... > > > Not really what I meant. I meant that by adding dependencies, these libraries will be used instead of the default if they weren't already installed. So incrementing the revision causes this to happening predictably. From krischik at users.sourceforge.net Tue Dec 16 02:43:04 2008 From: krischik at users.sourceforge.net (Martin Krischik) Date: Tue, 16 Dec 2008 11:43:04 +0100 Subject: Gtk2: Library not loaded: /usr/X11/lib/libXdamage.1.dylib Message-ID: <9F0A0CA8-D11B-4194-98C3-2F40CA540748@users.sourceforge.net> Hello, Actually I wanted to file a bug report - but track does not work. Well, I get the following error message when I try to install gtk: ----------------------- libtool: link: ( cd ".libs" && rm -f "im-xim.la" && ln -s "../im- xim.la" "im-xim.la" ) ../../gtk/gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im- cyrillic-translit.la im-inuktitut.la im-ipa.la im-multipress.la im- thai.la im-ti-er.la im-ti-et.la im-viqr.la im-xim.la > gtk.immodules dyld: Library not loaded: /usr/X11/lib/libXdamage.1.dylib Referenced from: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_x11_gtk2/work/gtk+-2.14.5/gtk/.libs/gtk- query-immodules-2.0 Reason: Incompatible library version: gtk-query-immodules-2.0 requires version 3.0.0 or later, but libXdamage.1.dylib provides version 2.0.0 /bin/sh: line 1: 21923 Trace/BPT trap ../../gtk/gtk-query- immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-translit.la im- inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.la im-ti- et.la im-viqr.la im-xim.la > gtk.immodules make[3]: *** [gtk.immodules] Error 133 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ----------------------- Regards Martin -- Martin Krischik krischik at users.sourceforge.net From wsiegrist at apple.com Tue Dec 16 10:36:02 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 16 Dec 2008 10:36:02 -0800 Subject: [43656] trunk/dports/python In-Reply-To: <67B4A803-A275-4C06-BE18-1A5FCC142382@apple.com> References: <20081213032724.BB8469251F8@beta.macosforge.org> <67B4A803-A275-4C06-BE18-1A5FCC142382@apple.com> Message-ID: On Dec 15, 2008, at 2:34 PM, William Siegrist wrote: > On Dec 12, 2008, at 8:58 PM, Ryan Schmidt wrote: > >> On Dec 12, 2008, at 21:27, wsiegrist at apple.com wrote: >> >>> Revision: 43656 >>> http://trac.macports.org/changeset/43656 >>> Author: wsiegrist at apple.com >>> Date: 2008-12-12 19:27:23 -0800 (Fri, 12 Dec 2008) >>> Log Message: >>> ----------- >>> Branching py-ldap to make py25-ldap. Update to version 2.3.5. >> >> Could we also update py-ldap to the same version to keep these >> ports in sync? >> > > I didnt want to bump it without testing, and I dont have a python24 > install handy. I'll try to build python24 and test py-ldap with > v2.3.5 later today. > Ok, is the py-ldap version bump. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available URL: From jeremyhu at macports.org Tue Dec 16 19:16:12 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Tue, 16 Dec 2008 19:16:12 -0800 Subject: [43834] trunk/dports/x11/gtk2/Portfile In-Reply-To: <4947425F.3080609@macports.org> References: <20081215212310.03E9C9726D2@beta.macosforge.org> <4946DED9.6000900@macports.org> <1A7B4C40-C131-485C-9F5D-474F9A147E83@macports.org> <4947425F.3080609@macports.org> Message-ID: On Dec 15, 2008, at 21:53, David Evans wrote: >> libXinerama is going to be on everyone's system unless they are >> testing out a macports-only X11 with x11prefix=$prefix ... If >> libXinerama is present, then it's automatically used. That configure >> setting was more to emphasize its use (so maybe it shouldn't be there >> now since libXinerama is in the depends_lib anyways) and guarantee >> backwards compatability if a future gtk2 release to ensure better >> compatibility... >> > Not really what I meant. I meant that by adding dependencies, these > libraries will be used instead of > the default if they weren't already installed. So incrementing the > revision causes this to happening > predictably. Yes, but if they weren't installed before, then the Tiger X11User and X11SDK packages weren't installed, and the package wouldn't have compiled anyways. From jeremyhu at macports.org Tue Dec 16 19:19:13 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Tue, 16 Dec 2008 19:19:13 -0800 Subject: Gtk2: Library not loaded: /usr/X11/lib/libXdamage.1.dylib In-Reply-To: <9F0A0CA8-D11B-4194-98C3-2F40CA540748@users.sourceforge.net> References: <9F0A0CA8-D11B-4194-98C3-2F40CA540748@users.sourceforge.net> Message-ID: <0875B27D-AC00-454C-A2AA-D503965F007C@macports.org> Looks like you installed Xquartz from http://xquartz.macosforge.org, compiled some macports stuff, then updated your system with SU, and forgot to reinstall xquartz after the SU... On Dec 16, 2008, at 02:43, Martin Krischik wrote: > Hello, > > Actually I wanted to file a bug report - but track does not work. > Well, I get the following error message when I try to install gtk: > > ----------------------- > > libtool: link: ( cd ".libs" && rm -f "im-xim.la" && ln -s "../im- > xim.la" "im-xim.la" ) > ../../gtk/gtk-query-immodules-2.0 im-am-et.la im-cedilla.la im- > cyrillic-translit.la im-inuktitut.la im-ipa.la im-multipress.la im- > thai.la im-ti-er.la im-ti-et.la im-viqr.la im-xim.la > gtk.immodules > dyld: Library not loaded: /usr/X11/lib/libXdamage.1.dylib > Referenced from: /opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync > .macports.org_release_ports_x11_gtk2/work/gtk+-2.14.5/gtk/.libs/gtk- > query-immodules-2.0 > Reason: Incompatible library version: gtk-query-immodules-2.0 > requires version 3.0.0 or later, but libXdamage.1.dylib provides > version 2.0.0 > /bin/sh: line 1: 21923 Trace/BPT trap ../../gtk/gtk-query- > immodules-2.0 im-am-et.la im-cedilla.la im-cyrillic-translit.la im- > inuktitut.la im-ipa.la im-multipress.la im-thai.la im-ti-er.la im-ti- > et.la im-viqr.la im-xim.la > gtk.immodules > make[3]: *** [gtk.immodules] Error 133 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > ----------------------- From krischik at users.sourceforge.net Tue Dec 16 23:09:54 2008 From: krischik at users.sourceforge.net (Martin Krischik) Date: Wed, 17 Dec 2008 08:09:54 +0100 Subject: Gtk2: Library not loaded: /usr/X11/lib/libXdamage.1.dylib In-Reply-To: <0875B27D-AC00-454C-A2AA-D503965F007C@macports.org> References: <9F0A0CA8-D11B-4194-98C3-2F40CA540748@users.sourceforge.net> <0875B27D-AC00-454C-A2AA-D503965F007C@macports.org> Message-ID: <20081217080954.hbdm1d4rpc44oswc@server265-han.de-nserver.de> Zitat von Jeremy Huddleston : > Looks like you installed Xquartz from http://xquartz.macosforge.org, > compiled some macports stuff, then updated your system with SU, and > forgot to reinstall xquartz after the SU... Yes - almost. Only I did not install Xquartz. But I did install an updated Xcode and the rest of event chain is 100% head on - so could an Xcode update have a similar effect? Martin > > > On Dec 16, 2008, at 02:43, Martin Krischik wrote: > >> Hello, >> >> Actually I wanted to file a bug report - but track does not work. >> Well, I get the following error message when I try to install gtk: >> >> ----------------------- >> >> libtool: link: ( cd ".libs" && rm -f "im-xim.la" && ln -s >> "../im-xim.la" "im-xim.la" ) >> ../../gtk/gtk-query-immodules-2.0 im-am-et.la im-cedilla.la >> im-cyrillic-translit.la im-inuktitut.la im-ipa.la im-multipress.la >> im-thai.la im-ti-er.la im-ti-et.la im-viqr.la im-xim.la > >> gtk.immodules >> dyld: Library not loaded: /usr/X11/lib/libXdamage.1.dylib >> Referenced from: >> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_gtk2/work/gtk+-2.14.5/gtk/.libs/gtk-query-immodules-2.0 >> Reason: Incompatible library version: gtk-query-immodules-2.0 >> requires version 3.0.0 or later, but libXdamage.1.dylib provides >> version 2.0.0 >> /bin/sh: line 1: 21923 Trace/BPT trap >> ../../gtk/gtk-query-immodules-2.0 im-am-et.la im-cedilla.la >> im-cyrillic-translit.la im-inuktitut.la im-ipa.la im-multipress.la >> im-thai.la im-ti-er.la im-ti-et.la im-viqr.la im-xim.la > >> gtk.immodules >> make[3]: *** [gtk.immodules] Error 133 >> make[2]: *** [all-recursive] Error 1 >> make[1]: *** [all-recursive] Error 1 >> make: *** [all] Error 2 >> ----------------------- From jeremyhu at macports.org Tue Dec 16 23:30:04 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Tue, 16 Dec 2008 23:30:04 -0800 Subject: Gtk2: Library not loaded: /usr/X11/lib/libXdamage.1.dylib In-Reply-To: <20081217080954.hbdm1d4rpc44oswc@server265-han.de-nserver.de> References: <9F0A0CA8-D11B-4194-98C3-2F40CA540748@users.sourceforge.net> <0875B27D-AC00-454C-A2AA-D503965F007C@macports.org> <20081217080954.hbdm1d4rpc44oswc@server265-han.de-nserver.de> Message-ID: <2C9E7CEB-839B-45BD-8339-FFDF3EA247B3@macports.org> On Dec 16, 2008, at 23:09, Martin Krischik wrote: > Zitat von Jeremy Huddleston : > >> Looks like you installed Xquartz from http://xquartz.macosforge.org, >> compiled some macports stuff, then updated your system with SU, and >> forgot to reinstall xquartz after the SU... > > Yes - almost. Only I did not install Xquartz. But I did install an > updated Xcode and the rest of event chain is 100% head on - so could > an Xcode update have a similar effect? > > Martin Well... Xquartz is the only released package that would install a 3.0.0 versioned /usr/X11/lib/libXdamage.1.dylib ... so just go download Xquartz 2.3.2_rc3, and you'll be happier ;) http://static.macosforge.org/xquartz/downloads/X11-2.3.2_rc3.dmg --Jeremy From andrea.damore at macports.org Wed Dec 17 06:10:31 2008 From: andrea.damore at macports.org (Andrea D'Amore) Date: Wed, 17 Dec 2008 15:10:31 +0100 Subject: About porting mesa3d In-Reply-To: <0083BCDD-AB17-454C-8102-0C4A5398FE29@mac.com> References: <0083BCDD-AB17-454C-8102-0C4A5398FE29@mac.com> Message-ID: <041CA1E5-61F2-48E0-9D9D-F88A6E8950B6@macports.org> On 14/dic/08, at 13:05, Chris Scharver wrote: > http://trac.macports.org/ticket/17569 > I need to fix the x11 dependencies in the Portfile, but other than > that it seems to work. A full Mesa3d port would probably supercede > this one. Jeremy committed "mesa" port, check it on repository. > Chris Andrea From jeremyhu at macports.org Wed Dec 17 12:40:15 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Wed, 17 Dec 2008 12:40:15 -0800 Subject: About porting mesa3d In-Reply-To: <041CA1E5-61F2-48E0-9D9D-F88A6E8950B6@macports.org> References: <0083BCDD-AB17-454C-8102-0C4A5398FE29@mac.com> <041CA1E5-61F2-48E0-9D9D-F88A6E8950B6@macports.org> Message-ID: <5E3FDC17-E102-4E22-A597-0A8520B12FAE@macports.org> On Dec 17, 2008, at 06:10, Andrea D'Amore wrote: > > On 14/dic/08, at 13:05, Chris Scharver wrote: >> http://trac.macports.org/ticket/17569 >> I need to fix the x11 dependencies in the Portfile, but other than >> that it seems to work. A full Mesa3d port would probably supercede >> this one. > > > Jeremy committed "mesa" port, check it on repository. Yeah, but that mesa port doesn't include glw... Would you rather include GLw in this port as a variant, have it build GLw as well. or laeve GLw to this glw port? From Ian.Grant at cl.cam.ac.uk Thu Dec 18 06:42:02 2008 From: Ian.Grant at cl.cam.ac.uk (Ian Grant) Date: Thu, 18 Dec 2008 14:42:02 +0000 Subject: port revision depndency Message-ID: <20081218144202.2296b00d@vignemale.cl.cam.ac.uk> Dear List, Is there a way to specify a port is dependent on a certain revision (and version!) of another port? Ian From jmr at macports.org Thu Dec 18 09:11:51 2008 From: jmr at macports.org (Joshua Root) Date: Fri, 19 Dec 2008 04:11:51 +1100 Subject: port revision depndency In-Reply-To: <20081218144202.2296b00d@vignemale.cl.cam.ac.uk> References: <20081218144202.2296b00d@vignemale.cl.cam.ac.uk> Message-ID: <494A8457.8030204@macports.org> Ian Grant wrote: > Dear List, > > Is there a way to specify a port is dependent on a certain revision (and version!) of another port? Sadly, no. I forget if there's a ticket specifically for this, but it's definitely on the to-do list along with . - Josh From milosh at macports.org Thu Dec 18 09:35:24 2008 From: milosh at macports.org (Emmanuel Hainry) Date: Thu, 18 Dec 2008 18:35:24 +0100 Subject: port revision depndency In-Reply-To: <494A8457.8030204@macports.org> References: <20081218144202.2296b00d@vignemale.cl.cam.ac.uk> <494A8457.8030204@macports.org> Message-ID: <20081218173524.GA3276@velsheda.lateralis.org> Citando Joshua Root : > Ian Grant wrote: > > Dear List, > > > > Is there a way to specify a port is dependent on a certain revision (and version!) of another port? > > Sadly, no. I forget if there's a ticket specifically for this, but it's > definitely on the to-do list along with > . It would also imply being able to install a certain revision of a port. At the moment, you can only install the "current" version. I'm not sure the priority is high as the workaround (if a port depends on a specific old version, make a port for this old version and make the dependent explicitly link with that version) works better (at least simpler) than having each port install in a versioned prefix and virtual environments created for each dependent... Emmanuel From jmr at macports.org Thu Dec 18 09:49:38 2008 From: jmr at macports.org (Joshua Root) Date: Fri, 19 Dec 2008 04:49:38 +1100 Subject: port revision depndency In-Reply-To: <20081218173524.GA3276@velsheda.lateralis.org> References: <20081218144202.2296b00d@vignemale.cl.cam.ac.uk> <494A8457.8030204@macports.org> <20081218173524.GA3276@velsheda.lateralis.org> Message-ID: <494A8D32.7040804@macports.org> Emmanuel Hainry wrote: > Citando Joshua Root : >> Ian Grant wrote: >>> Dear List, >>> >>> Is there a way to specify a port is dependent on a certain revision (and version!) of another port? >> Sadly, no. I forget if there's a ticket specifically for this, but it's >> definitely on the to-do list along with >> . > > It would also imply being able to install a certain revision of a port. > At the moment, you can only install the "current" version. > > I'm not sure the priority is high as the workaround (if a port depends > on a specific old version, make a port for this old version and make the > dependent explicitly link with that version) works better (at least > simpler) than having each port install in a versioned prefix and virtual > environments created for each dependent... The idea is more that if you install A and a too-old version of its dependency B is already installed, port would automatically upgrade B first. - Josh From cssdev at mac.com Thu Dec 18 18:20:10 2008 From: cssdev at mac.com (cssdev at mac.com) Date: Thu, 18 Dec 2008 21:20:10 -0500 Subject: About porting mesa3d In-Reply-To: <5E3FDC17-E102-4E22-A597-0A8520B12FAE@macports.org> References: <0083BCDD-AB17-454C-8102-0C4A5398FE29@mac.com> <041CA1E5-61F2-48E0-9D9D-F88A6E8950B6@macports.org> <5E3FDC17-E102-4E22-A597-0A8520B12FAE@macports.org> Message-ID: <9B466D39-5818-4CA9-A142-F81DC19C64A8@mac.com> On Dec 17, 2008, at 3:40 PM, Jeremy Huddleston wrote: > On Dec 17, 2008, at 06:10, Andrea D'Amore wrote: > >> On 14/dic/08, at 13:05, Chris Scharver wrote: >>> http://trac.macports.org/ticket/17569 >>> I need to fix the x11 dependencies in the Portfile, but other than >>> that it seems to work. A full Mesa3d port would probably supercede >>> this one. >> >> >> Jeremy committed "mesa" port, check it on repository. > > > Yeah, but that mesa port doesn't include glw... > > Would you rather include GLw in this port as a variant, have it > build GLw as well. or laeve GLw to this glw port? GLw seems to be a strange animal due to its dependency on Motif. It's a small library, and since it's a requirement for Open Inventor, it would be best handled as a separate port. Otherwise the situation results in trying to depend on a variant. Although should the glw port be named mesa-glw to clarify the association? Chris From ryandesign at macports.org Sun Dec 14 03:05:08 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 14 Dec 2008 05:05:08 -0600 Subject: [MacPorts] #14062: Website does not render properly in IE7 In-Reply-To: References: <055.9b1b96888da488b10a2b6dab3bb48419@macports.org> <064.6777689a33ae965fba656f9c04faca6a@macports.org> Message-ID: On Dec 13, 2008, at 04:33, Mark Hattam wrote: > The main page works in IE7 on XP Pro ... > http://www.macports.org > > BUT ... some links from it to other pages don't > eg the link to "5246 ports" > http://www.macports.org/ports.php > tries to download a file to you > > similarly the "get in touch with us" link > tries to download a file. > > yet the link to "installation" > http://www.macports.org/install.php > does work Just a quick note to say thanks for testing, and I see this too on www.macports.org, but interestingly on my local web server all pages load just fine. Some more investigation is in order. From ram at macports.org Fri Dec 19 03:06:31 2008 From: ram at macports.org (Adam Mercer) Date: Fri, 19 Dec 2008 11:06:31 +0000 Subject: lint not finding python26 portgroup Message-ID: <799406d60812190306m28c3bb63nc0e2a6d8e89ca595@mail.gmail.com> Hi Just got the following from a commit I just made, I don't get this error when running lint myself. Is the server that runs the lint checks not been updated to 1.7.0 yet? Cheers Adam On Fri, Dec 19, 2008 at 11:01, wrote: > ram at macports.org, > Content-Transfer-Encoding: quoted-printable > From: noreply at macports.org > > Portfile: py26-boto > > > Warning: Group file could not be located. > Warning: Group file could not be located. > Error: Unknown PortGroup: python26-1.0 > =20 From ryandesign at macports.org Fri Dec 19 03:41:50 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 19 Dec 2008 05:41:50 -0600 Subject: 1.7 and ports setting MDT In-Reply-To: <20081215070515.GB71970@ninagal.withay.com> References: <20081215070515.GB71970@ninagal.withay.com> Message-ID: <1DC8B9FA-60B2-4B08-BEF3-7FC9F5BD83DB@macports.org> On Dec 15, 2008, at 01:05, Bryan Blackburn wrote: > Now that 1.7 has been released, I think we can update ports which > manually > set MACOSX_DEPLOYMENT_TARGET as that's done by port 1.7. The > follow ports > appear to set MDT either for one OS version or 10.3-10.5: > > devel/glib2 > devel/glib2-devel > devel/gnutls > devel/libsigsegv > gnome/evolution-data-server > graphics/graphviz > graphics/graphviz-devel > graphics/vtk5 > lang/clisp > lang/pfe > mail/gnupg2 > net/ethereal > net/ldns > net/tcpflow > net/wireshark > perl/p5-mecab > python/py-psycopg > security/dirmngr > security/gpg-agent > security/xmlsec > textproc/libiconv > textproc/libxml2 > textproc/libxslt > textproc/mecab > sysutils/burn-app > > Anyone see issues with removing the MDT stuff in those? Right, those parts should be removed. We could wait a month or so first to give people time to update to 1.7.0. Or we could do it now, and if people start reporting the problems that those passages fixed, we'll tell them to update to 1.7.0 then. From ryandesign at macports.org Fri Dec 19 03:44:16 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 19 Dec 2008 05:44:16 -0600 Subject: port revision depndency In-Reply-To: <20081218173524.GA3276@velsheda.lateralis.org> References: <20081218144202.2296b00d@vignemale.cl.cam.ac.uk> <494A8457.8030204@macports.org> <20081218173524.GA3276@velsheda.lateralis.org> Message-ID: On Dec 18, 2008, at 11:35, Emmanuel Hainry wrote: >>> Is there a way to specify a port is dependent on a certain >>> revision (and version!) of another port? >> >> Sadly, no. I forget if there's a ticket specifically for this, but >> it's >> definitely on the to-do list along with >> . > > It would also imply being able to install a certain revision of a > port. > At the moment, you can only install the "current" version. If you need an older version, you can use this workaround: http://trac.macports.org/wiki/howto/InstallingOlderPort From ryandesign at macports.org Fri Dec 19 03:47:34 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 19 Dec 2008 05:47:34 -0600 Subject: Short absence Message-ID: I apologize for not being around as much as usual lately. I won't have very much time for MacPorts activities again until after the weekend, so if any of my ports need attention in the next few days, please feel free to take care of them. From wsiegrist at apple.com Fri Dec 19 08:06:37 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 19 Dec 2008 08:06:37 -0800 Subject: lint not finding python26 portgroup In-Reply-To: <799406d60812190306m28c3bb63nc0e2a6d8e89ca595@mail.gmail.com> References: <799406d60812190306m28c3bb63nc0e2a6d8e89ca595@mail.gmail.com> Message-ID: Its running a pre-release 1.7. I'll update it to the latest trunk today. -Bill On Dec 19, 2008, at 3:06 AM, Adam Mercer wrote: > Hi > > Just got the following from a commit I just made, I don't get this > error when running lint myself. Is the server that runs the lint > checks not been updated to 1.7.0 yet? > > Cheers > > Adam > > On Fri, Dec 19, 2008 at 11:01, wrote: >> ram at macports.org, >> Content-Transfer-Encoding: quoted-printable >> From: noreply at macports.org >> >> Portfile: py26-boto >> >> >> Warning: Group file could not be located. >> Warning: Group file could not be located. >> Error: Unknown PortGroup: python26-1.0 >> =20 > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ---- William Siegrist Mac OS Forge http://macosforge.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available URL: From jmr at macports.org Fri Dec 19 09:44:55 2008 From: jmr at macports.org (Joshua Root) Date: Sat, 20 Dec 2008 04:44:55 +1100 Subject: 1.7 and ports setting MDT In-Reply-To: <1DC8B9FA-60B2-4B08-BEF3-7FC9F5BD83DB@macports.org> References: <20081215070515.GB71970@ninagal.withay.com> <1DC8B9FA-60B2-4B08-BEF3-7FC9F5BD83DB@macports.org> Message-ID: <494BDD97.5090005@macports.org> Ryan Schmidt wrote: > > On Dec 15, 2008, at 01:05, Bryan Blackburn wrote: > >> Now that 1.7 has been released, I think we can update ports which >> manually >> set MACOSX_DEPLOYMENT_TARGET as that's done by port 1.7. The follow >> ports >> appear to set MDT either for one OS version or 10.3-10.5: >> ... >> >> Anyone see issues with removing the MDT stuff in those? > > Right, those parts should be removed. We could wait a month or so first > to give people time to update to 1.7.0. Or we could do it now, and if > people start reporting the problems that those passages fixed, we'll > tell them to update to 1.7.0 then. I was going to give it a week before I started breaking 1.6. :-) Looks like the breakage has already begun though, so I see no reason to hold back. As well as MDT, there's the 'true as configure' configure.cc workaround, conditional use of applications_dir, frameworks_dir, and universal_archs, and the parallel destroot workarounds. - Josh From raimue at macports.org Fri Dec 19 10:01:56 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 19 Dec 2008 19:01:56 +0100 Subject: 1.7 and ports setting MDT In-Reply-To: <20081215070515.GB71970@ninagal.withay.com> References: <20081215070515.GB71970@ninagal.withay.com> Message-ID: <494BE194.8050806@macports.org> Bryan Blackburn wrote: > Now that 1.7 has been released, I think we can update ports which manually > set MACOSX_DEPLOYMENT_TARGET as that's done by port 1.7. The follow ports > appear to set MDT either for one OS version or 10.3-10.5: > sysutils/burn-app This is a false positive. This matches a reinplace on the Xcode project file, where I had to remove MDT in order to get it to build. Rainer From wsiegrist at apple.com Fri Dec 19 14:33:47 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 19 Dec 2008 14:33:47 -0800 Subject: lint not finding python26 portgroup In-Reply-To: References: <799406d60812190306m28c3bb63nc0e2a6d8e89ca595@mail.gmail.com> Message-ID: Servers have been updated. -Bill On Dec 19, 2008, at 8:06 AM, William Siegrist wrote: > Its running a pre-release 1.7. I'll update it to the latest trunk > today. > > -Bill > > > On Dec 19, 2008, at 3:06 AM, Adam Mercer wrote: > >> Hi >> >> Just got the following from a commit I just made, I don't get this >> error when running lint myself. Is the server that runs the lint >> checks not been updated to 1.7.0 yet? >> >> Cheers >> >> Adam >> >> On Fri, Dec 19, 2008 at 11:01, wrote: >>> ram at macports.org, >>> Content-Transfer-Encoding: quoted-printable >>> From: noreply at macports.org >>> >>> Portfile: py26-boto >>> >>> >>> Warning: Group file could not be located. >>> Warning: Group file could not be located. >>> Error: Unknown PortGroup: python26-1.0 >>> =20 >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > > > ---- > William Siegrist > Mac OS Forge > http://macosforge.org/ > > > > > > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ---- William Siegrist Mac OS Forge http://macosforge.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available URL: From ryandesign at macports.org Fri Dec 19 21:46:51 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 19 Dec 2008 23:46:51 -0600 Subject: [MacPorts] #14062: Website does not render properly in IE7 In-Reply-To: References: <055.9b1b96888da488b10a2b6dab3bb48419@macports.org> <064.6777689a33ae965fba656f9c04faca6a@macports.org> Message-ID: <20154919-3961-424E-94E9-A5C9BE6C7674@macports.org> On Dec 19, 2008, at 09:32, Marco Battistella wrote: > http://www.macports.com repose is correct, when "application/xhtml > +xml" is accepted the header response is application/xhtml+xml and > when it is not the header response is text/html > for some reason when requesting http://www.macports.com/ports.php > the response is always application/xhtml+xml > > I re-adapted a small php script i had written some time ago to > allow to test the pages behavior with or without the Accept: > application/xhtml+xml header. > > The little script works from the command line like this: > $ php testGet.php -uri http://www.macports.org -accept ie7 > or > $ php testGet.php -uri http://www.macports.org -accept safari > or > $ php testGet.php -uri http://www.macports.org/ports.php -accept ie7 > > you get the point. > It is a "works in my machine" type of script but i don't see why it > should not work in yours as well ;-) > It will return the header and then the content. > > I am part of this thread because i had originally sent a > modification suggestion for this issue, i'm not a macports > developer or a macports website maintainer but I could have a look > at the code if you guys think it would help. > If so what path should i use to do a checkout with subversion > (without downloading the whole macport project, just the relevant > part of the site, please).... You can get the web site code here: http://trac.macports.org/browser/trunk/www I haven't yet understood why I seem to be getting different behavior out of the different pages (and even different behavior of http:// www.macports.org/ vs. http://www.macports.org/index.php ) when they're all including the same common code to handle the headers. From wsiegrist at apple.com Fri Dec 19 22:06:48 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 19 Dec 2008 22:06:48 -0800 Subject: [MacPorts] #14062: Website does not render properly in IE7 In-Reply-To: <20154919-3961-424E-94E9-A5C9BE6C7674@macports.org> References: <055.9b1b96888da488b10a2b6dab3bb48419@macports.org> <064.6777689a33ae965fba656f9c04faca6a@macports.org> <20154919-3961-424E-94E9-A5C9BE6C7674@macports.org> Message-ID: <1D77EA76-719B-4E42-826C-D593CF5A3601@apple.com> On Dec 19, 2008, at 9:46 PM, Ryan Schmidt wrote: > > On Dec 19, 2008, at 09:32, Marco Battistella wrote: > >> http://www.macports.com repose is correct, when "application/xhtml >> +xml" is accepted the header response is application/xhtml+xml and >> when it is not the header response is text/html >> for some reason when requesting http://www.macports.com/ports.php >> the response is always application/xhtml+xml >> >> I re-adapted a small php script i had written some time ago to >> allow to test the pages behavior with or without the Accept: >> application/xhtml+xml header. >> >> The little script works from the command line like this: >> $ php testGet.php -uri http://www.macports.org -accept ie7 >> or >> $ php testGet.php -uri http://www.macports.org -accept safari >> or >> $ php testGet.php -uri http://www.macports.org/ports.php -accept ie7 >> >> you get the point. >> It is a "works in my machine" type of script but i don't see why it >> should not work in yours as well ;-) >> It will return the header and then the content. >> >> I am part of this thread because i had originally sent a >> modification suggestion for this issue, i'm not a macports >> developer or a macports website maintainer but I could have a look >> at the code if you guys think it would help. >> If so what path should i use to do a checkout with subversion >> (without downloading the whole macport project, just the relevant >> part of the site, please).... > > You can get the web site code here: > > http://trac.macports.org/browser/trunk/www > > I haven't yet understood why I seem to be getting different behavior > out of the different pages (and even different behavior of http://www.macports.org/ > vs. http://www.macports.org/index.php ) when they're all including > the same common code to handle the headers. > Getting consistent rendering with XHTML 1.1 is probably not worth the effort. I doubt the site does anything requiring XHTML 1.1 anyway, so why not just serve an HTML 4.01 page? There's a good WebKit blog post [1] about this issue too. -Bill [1] http://webkit.org/blog/68/understanding-html-xml-and-xhtml/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available URL: From ryandesign at macports.org Fri Dec 19 22:39:22 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 20 Dec 2008 00:39:22 -0600 Subject: [MacPorts] #14062: Website does not render properly in IE7 In-Reply-To: <1D77EA76-719B-4E42-826C-D593CF5A3601@apple.com> References: <055.9b1b96888da488b10a2b6dab3bb48419@macports.org> <064.6777689a33ae965fba656f9c04faca6a@macports.org> <20154919-3961-424E-94E9-A5C9BE6C7674@macports.org> <1D77EA76-719B-4E42-826C-D593CF5A3601@apple.com> Message-ID: <58372AE9-93B1-464C-B17E-9C1730954B05@macports.org> On Dec 20, 2008, at 00:06, William Siegrist wrote: > On Dec 19, 2008, at 9:46 PM, Ryan Schmidt wrote: > >> On Dec 19, 2008, at 09:32, Marco Battistella wrote: >> >>> http://www.macports.com repose is correct, when "application/xhtml >>> +xml" is accepted the header response is application/xhtml+xml >>> and when it is not the header response is text/html >>> for some reason when requesting http://www.macports.com/ports.php >>> the response is always application/xhtml+xml >>> >>> I re-adapted a small php script i had written some time ago to >>> allow to test the pages behavior with or without the Accept: >>> application/xhtml+xml header. >>> >>> The little script works from the command line like this: >>> $ php testGet.php -uri http://www.macports.org -accept ie7 >>> or >>> $ php testGet.php -uri http://www.macports.org -accept safari >>> or >>> $ php testGet.php -uri http://www.macports.org/ports.php -accept ie7 >>> >>> you get the point. >>> It is a "works in my machine" type of script but i don't see why >>> it should not work in yours as well ;-) >>> It will return the header and then the content. >>> >>> I am part of this thread because i had originally sent a >>> modification suggestion for this issue, i'm not a macports >>> developer or a macports website maintainer but I could have a >>> look at the code if you guys think it would help. >>> If so what path should i use to do a checkout with subversion >>> (without downloading the whole macport project, just the relevant >>> part of the site, please).... >> >> You can get the web site code here: >> >> http://trac.macports.org/browser/trunk/www >> >> I haven't yet understood why I seem to be getting different >> behavior out of the different pages (and even different behavior >> of http://www.macports.org/ vs. http://www.macports.org/ >> index.php ) when they're all including the same common code to >> handle the headers. > > Getting consistent rendering with XHTML 1.1 is probably not worth > the effort. I doubt the site does anything requiring XHTML 1.1 > anyway, so why not just serve an HTML 4.01 page? There's a good > WebKit blog post [1] about this issue too. > > -Bill > > [1] http://webkit.org/blog/68/understanding-html-xml-and-xhtml/ That article, written in September 2006, basically says forget XHTML and use HTML 4. Is that still the best advice today, over 2 years later? If so, I am given to wonder why we have the XHTML standard in the first place, if browser vendors recommend not using it. From wsiegrist at apple.com Fri Dec 19 22:59:08 2008 From: wsiegrist at apple.com (William Siegrist) Date: Fri, 19 Dec 2008 22:59:08 -0800 Subject: [MacPorts] #14062: Website does not render properly in IE7 In-Reply-To: <58372AE9-93B1-464C-B17E-9C1730954B05@macports.org> References: <055.9b1b96888da488b10a2b6dab3bb48419@macports.org> <064.6777689a33ae965fba656f9c04faca6a@macports.org> <20154919-3961-424E-94E9-A5C9BE6C7674@macports.org> <1D77EA76-719B-4E42-826C-D593CF5A3601@apple.com> <58372AE9-93B1-464C-B17E-9C1730954B05@macports.org> Message-ID: <59E072C9-E457-4F75-8E4A-7642E7C592E6@apple.com> On Dec 19, 2008, at 10:39 PM, Ryan Schmidt wrote: > On Dec 20, 2008, at 00:06, William Siegrist wrote: > >> On Dec 19, 2008, at 9:46 PM, Ryan Schmidt wrote: >> >>> On Dec 19, 2008, at 09:32, Marco Battistella wrote: >>> >>>> http://www.macports.com repose is correct, when "application/xhtml >>>> +xml" is accepted the header response is application/xhtml+xml >>>> and when it is not the header response is text/html >>>> for some reason when requesting http://www.macports.com/ports.php >>>> the response is always application/xhtml+xml >>>> >>>> I re-adapted a small php script i had written some time ago to >>>> allow to test the pages behavior with or without the Accept: >>>> application/xhtml+xml header. >>>> >>>> The little script works from the command line like this: >>>> $ php testGet.php -uri http://www.macports.org -accept ie7 >>>> or >>>> $ php testGet.php -uri http://www.macports.org -accept safari >>>> or >>>> $ php testGet.php -uri http://www.macports.org/ports.php -accept >>>> ie7 >>>> >>>> you get the point. >>>> It is a "works in my machine" type of script but i don't see why >>>> it should not work in yours as well ;-) >>>> It will return the header and then the content. >>>> >>>> I am part of this thread because i had originally sent a >>>> modification suggestion for this issue, i'm not a macports >>>> developer or a macports website maintainer but I could have a >>>> look at the code if you guys think it would help. >>>> If so what path should i use to do a checkout with subversion >>>> (without downloading the whole macport project, just the relevant >>>> part of the site, please).... >>> >>> You can get the web site code here: >>> >>> http://trac.macports.org/browser/trunk/www >>> >>> I haven't yet understood why I seem to be getting different >>> behavior out of the different pages (and even different behavior >>> of http://www.macports.org/ vs. http://www.macports.org/ >>> index.php ) when they're all including the same common code to >>> handle the headers. >> >> Getting consistent rendering with XHTML 1.1 is probably not worth >> the effort. I doubt the site does anything requiring XHTML 1.1 >> anyway, so why not just serve an HTML 4.01 page? There's a good >> WebKit blog post [1] about this issue too. >> >> -Bill >> >> [1] http://webkit.org/blog/68/understanding-html-xml-and-xhtml/ > > That article, written in September 2006, basically says forget XHTML > and use HTML 4. Is that still the best advice today, over 2 years > later? If so, I am given to wonder why we have the XHTML standard in > the first place, if browser vendors recommend not using it. > > Yes, its still valid due to browsers not behaving correctly with the xml tags and the application/xhtml+xml content type. The following pages are served as HTML 4.01: http://webkit.org/ http://mozilla.org/ These are served as XHTML 1.0, which doesnt have the leading xml tag, and they use an html content type, which is technically wrong but it makes browsers handle it better: http://microsoft.com/ http://opera.com/ So if the browser vendors are not using XHTML 1.1, why are we going through all this trouble? -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available URL: From ryandesign at macports.org Fri Dec 19 23:18:23 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 20 Dec 2008 01:18:23 -0600 Subject: Encouraging ports to include use_parallel_build Message-ID: Of our 5256 ports, 326 (6.2%) indicate they can build in parallel, and 33 (0.6%) indicate that they cannot. That leaves 4897 ports (93.1%) which do not indicate whether a parallel build is possible or not, and in this case, MacPorts will assume a parallel build is not possible. I would like to encourage port authors to indicate in their portfiles whether parallel building is possible or not. I'm considering whether we should add a check for this to "port lint". Hypothetical output: $ port lint giflib ---> Verifying Portfile for giflib Warning: Consider adding use_parallel_build ---> 0 errors and 1 warnings found. $ From ryandesign at macports.org Sat Dec 20 00:50:36 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 20 Dec 2008 02:50:36 -0600 Subject: [44043] trunk/dports/devel In-Reply-To: <20081219213629.733ED9E6892@beta.macosforge.org> References: <20081219213629.733ED9E6892@beta.macosforge.org> Message-ID: On Dec 19, 2008, at 15:36, wsiegrist at apple.com wrote: > Revision: 44043 > http://trac.macports.org/changeset/44043 > Author: wsiegrist at apple.com > Date: 2008-12-19 13:36:28 -0800 (Fri, 19 Dec 2008) > Log Message: > ----------- > New Port: darwinbuild > > Added Paths: > ----------- > trunk/dports/devel/darwinbuild/ > trunk/dports/devel/darwinbuild/Portfile > > Added: trunk/dports/devel/darwinbuild/Portfile > =================================================================== > --- trunk/dports/devel/darwinbuild/Portfile > (rev 0) > +++ trunk/dports/devel/darwinbuild/Portfile 2008-12-19 21:36:28 UTC > (rev 44043) > @@ -0,0 +1,34 @@ > +# $Id$ > + > +PortSystem 1.0 > + > +name darwinbuild > +version 0.8.0 > +categories devel > +platforms darwin > +maintainers wms > +description Darwinbuild is a set of tools that facilitate > building the sources \ > + released by Apple. > + > +long_description \ > + The Darwin Build Scripts are a collection of tools that assist > compilation of \ > + the many projects contained in Darwin, the open source base of > Apple's \ > + Mac OS X operating system. Apple publishes the sources of these > projects \ > + in an archive format (.tar.gz). An archive is published for > each project \ > + version on Apple's site. These tools will provide the proper > build environment as well as help to \ > + resolve any necessary dependencies prior to building. > + > +homepage http://darwinbuild.macosforge.org/ > +master_sites http://svn.macosforge.org/repository/darwinbuild/ > + > +fetch.type svn > +svn.url http://svn.macosforge.org/repository/darwinbuild/trunk/ > +svn.tag HEAD If there is no tag for the 0.8.0 version, then you should use the revision number that corresponds to the 0.8.0 version, not HEAD. Using HEAD means building the port at different times fetches different files from the darwinbuild repository, which we do not want to occur; we want every user to get the same build every time. Is 0.8.0 released yet? If not, the port name darwinbuild-devel might be more appropriate, and let the port darwinbuild be for the latest released version instead. Unless the latest released version is so old as to not be useful. > +worksrcdir trunk > + > +destroot.post_args-append PREFIX=${prefix} > + > +use_configure no From illogical1 at gmail.com Sat Dec 20 07:34:21 2008 From: illogical1 at gmail.com (O) Date: Sat, 20 Dec 2008 10:34:21 -0500 Subject: Encouraging ports to include use_parallel_build In-Reply-To: References: Message-ID: <797cc39c0812200734m79dbe622g6b4caae1ad45487b@mail.gmail.com> On Sat, Dec 20, 2008 at 2:18 AM, Ryan Schmidt wrote: > Of our 5256 ports, 326 (6.2%) indicate they can build in parallel, and 33 > (0.6%) indicate that they cannot. That leaves 4897 ports (93.1%) which do > not indicate whether a parallel build is possible or not, and in this case, > MacPorts will assume a parallel build is not possible. > > I would like to encourage port authors to indicate in their portfiles > whether parallel building is possible or not. I'm considering whether we > should add a check for this to "port lint". Hypothetical output: > > > $ port lint giflib > ---> Verifying Portfile for giflib > Warning: Consider adding use_parallel_build > ---> 0 errors and 1 warnings found. > $ > +1 -- Phyllis Diller - "I want my children to have all the things I couldn't afford. Then I want to move in with them." From wsiegrist at apple.com Sat Dec 20 12:23:32 2008 From: wsiegrist at apple.com (William Siegrist) Date: Sat, 20 Dec 2008 12:23:32 -0800 Subject: [44043] trunk/dports/devel In-Reply-To: References: <20081219213629.733ED9E6892@beta.macosforge.org> Message-ID: <80302B0B-3D10-45E7-B79A-E7907AFAB345@apple.com> On Dec 20, 2008, at 12:50 AM, Ryan Schmidt wrote: > On Dec 19, 2008, at 15:36, wsiegrist at apple.com wrote: > >> Revision: 44043 >> http://trac.macports.org/changeset/44043 >> Author: wsiegrist at apple.com >> Date: 2008-12-19 13:36:28 -0800 (Fri, 19 Dec 2008) >> Log Message: >> ----------- >> New Port: darwinbuild >> >> Added Paths: >> ----------- >> trunk/dports/devel/darwinbuild/ >> trunk/dports/devel/darwinbuild/Portfile >> >> Added: trunk/dports/devel/darwinbuild/Portfile >> =================================================================== >> --- trunk/dports/devel/darwinbuild/Portfile >> (rev 0) >> +++ trunk/dports/devel/darwinbuild/Portfile 2008-12-19 21:36:28 UTC >> (rev 44043) >> @@ -0,0 +1,34 @@ >> +# $Id$ >> + >> +PortSystem 1.0 >> + >> +name darwinbuild >> +version 0.8.0 >> +categories devel >> +platforms darwin >> +maintainers wms >> +description Darwinbuild is a set of tools that facilitate >> building the sources \ >> + released by Apple. >> + >> +long_description \ >> + The Darwin Build Scripts are a collection of tools that assist >> compilation of \ >> + the many projects contained in Darwin, the open source base of >> Apple's \ >> + Mac OS X operating system. Apple publishes the sources of these >> projects \ >> + in an archive format (.tar.gz). An archive is published for >> each project \ >> + version on Apple's site. These tools will provide the proper >> build environment as well as help to \ >> + resolve any necessary dependencies prior to building. >> + >> +homepage http://darwinbuild.macosforge.org/ >> +master_sites http://svn.macosforge.org/repository/darwinbuild/ >> + >> +fetch.type svn >> +svn.url http://svn.macosforge.org/repository/darwinbuild/trunk/ >> +svn.tag HEAD > > If there is no tag for the 0.8.0 version, then you should use the > revision number that corresponds to the 0.8.0 version, not HEAD. > Using HEAD means building the port at different times fetches > different files from the darwinbuild repository, which we do not > want to occur; we want every user to get the same build every time. > > Is 0.8.0 released yet? If not, the port name darwinbuild-devel might > be more appropriate, and let the port darwinbuild be for the latest > released version instead. Unless the latest released version is so > old as to not be useful. > >> There's no tag or revision for 0.8.0, thats just the version of trunk (like MP 1.8.0). There's also no stable released version, so I left off the -devel in the name. And yes, I know you get new files every time. I'm the primary developer of darwinbuild these days and recommend people live on trunk. This port is for people already running MP on a machine so they can "port upgrade darwinbuild" instead of doing the "svn up ... ; make ; make install" manually each time. Thanks -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available URL: From kngspook at gmail.com Sat Dec 20 15:49:41 2008 From: kngspook at gmail.com (Neil) Date: Sat, 20 Dec 2008 15:49:41 -0800 Subject: Encouraging ports to include use_parallel_build In-Reply-To: <797cc39c0812200734m79dbe622g6b4caae1ad45487b@mail.gmail.com> References: <797cc39c0812200734m79dbe622g6b4caae1ad45487b@mail.gmail.com> Message-ID: <77e4079b0812201549g23fc6645uca82247c0ca95564@mail.gmail.com> On Sat, Dec 20, 2008 at 7:34 AM, O wrote: > On Sat, Dec 20, 2008 at 2:18 AM, Ryan Schmidt wrote: >> Of our 5256 ports, 326 (6.2%) indicate they can build in parallel, and 33 >> (0.6%) indicate that they cannot. That leaves 4897 ports (93.1%) which do >> not indicate whether a parallel build is possible or not, and in this case, >> MacPorts will assume a parallel build is not possible. >> >> I would like to encourage port authors to indicate in their portfiles >> whether parallel building is possible or not. I'm considering whether we >> should add a check for this to "port lint". Hypothetical output: >> >> >> $ port lint giflib >> ---> Verifying Portfile for giflib >> Warning: Consider adding use_parallel_build >> ---> 0 errors and 1 warnings found. >> $ >> > +1 +1 Total: +2 From jwa at macports.org Sun Dec 21 06:02:05 2008 From: jwa at macports.org (Jyrki Wahlstedt) Date: Sun, 21 Dec 2008 16:02:05 +0200 Subject: port/svn Message-ID: Hi, one thing I noticed with the advent of 1.7.0. Previously port selfupdate happily updated my local svn ports tree. Now that update does not happen, as it requires 1.5.x svn client and port command for some reason launches /usr/bin/svn that is too old. Now, is there some easy way to get port to use MP-provided svn client (as that updates the local tree quite nicely)? ! ! Jyrki Wahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stechert at gmail.com Sun Dec 21 08:26:10 2008 From: stechert at gmail.com (Andre Stechert) Date: Sun, 21 Dec 2008 08:26:10 -0800 Subject: port/svn In-Reply-To: References: Message-ID: <12a697af0812210826w4f54e555ob92e3884d5031457@mail.gmail.com> See http://trac.macports.org/ticket/15868. The description of the bug will give you a short term fix. The milestone indicates it's a target for 1.7.1. The change history explains how it arises. Cheers, Andre On Sun, Dec 21, 2008 at 6:02 AM, Jyrki Wahlstedt wrote: > Hi, > one thing I noticed with the advent of 1.7.0. Previously port selfupdate > happily updated my local svn ports tree. Now that update does not happen, as > it requires 1.5.x svn client and port command for some reason launches > /usr/bin/svn that is too old. Now, is there some easy way to get port to use > MP-provided svn client (as that updates the local tree quite nicely)? > ! > ! Jyrki Wahlstedt > ! http://www.wahlstedt.fi/jyrki/ > ! > ! Our life is no dream; but it ought to become one and perhaps will. > ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 > EFD9 139C C386 > > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > From ryandesign at macports.org Sun Dec 21 23:03:36 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 22 Dec 2008 01:03:36 -0600 Subject: [44043] trunk/dports/devel In-Reply-To: <80302B0B-3D10-45E7-B79A-E7907AFAB345@apple.com> References: <20081219213629.733ED9E6892@beta.macosforge.org> <80302B0B-3D10-45E7-B79A-E7907AFAB345@apple.com> Message-ID: On Dec 20, 2008, at 14:23, William Siegrist wrote: > On Dec 20, 2008, at 12:50 AM, Ryan Schmidt wrote: > >> On Dec 19, 2008, at 15:36, wsiegrist at apple.com wrote: >> >>> +fetch.type svn >>> +svn.url http://svn.macosforge.org/repository/darwinbuild/trunk/ >>> +svn.tag HEAD >> >> If there is no tag for the 0.8.0 version, then you should use the >> revision number that corresponds to the 0.8.0 version, not HEAD. >> Using HEAD means building the port at different times fetches >> different files from the darwinbuild repository, which we do not >> want to occur; we want every user to get the same build every time. >> >> Is 0.8.0 released yet? If not, the port name darwinbuild-devel >> might be more appropriate, and let the port darwinbuild be for the >> latest released version instead. Unless the latest released >> version is so old as to not be useful. > > There's no tag or revision for 0.8.0, thats just the version of > trunk (like MP 1.8.0). There's also no stable released version, so > I left off the -devel in the name. And yes, I know you get new > files every time. I'm the primary developer of darwinbuild these > days and recommend people live on trunk. This port is for people > already running MP on a machine so they can "port upgrade > darwinbuild" instead of doing the "svn up ... ; make ; make > install" manually each time. Still, we want people to get the same software on their machine every time they build a given epoch+version+revision+variant combination of a given port. So you should pin this port to a specific upstream revision in the svn.tag. You can always increment the port's revision and svn.tag when you want to release new changes to MacPorts users; that way they will be informed via "port outdated" of the availability of the new changes. Otherwise you get the situation that two users install "version 0.8.0" at different times, and the software works one way for one user and another way (or even not at all) for a second user and because they have the same version installed they will think they have the same software when in fact unbeknownst to them they have different upstream revisions. From Ian.Grant at cl.cam.ac.uk Mon Dec 22 06:15:33 2008 From: Ian.Grant at cl.cam.ac.uk (Ian Grant) Date: Mon, 22 Dec 2008 14:15:33 +0000 Subject: port revision depndency In-Reply-To: <494A8D32.7040804@macports.org> References: <20081218144202.2296b00d@vignemale.cl.cam.ac.uk> <494A8457.8030204@macports.org> <20081218173524.GA3276@velsheda.lateralis.org> <494A8D32.7040804@macports.org> Message-ID: <20081222141533.3d43c45c@vignemale.cl.cam.ac.uk> On Fri, 19 Dec 2008 04:49:38 +1100 Joshua Root wrote: > The idea is more that if you install A and a too-old version of its > dependency B is already installed, port would automatically upgrade B > first. That's the problem with the mosml-dynlib port I submitted. It requires a newer mosml port than the current one and people may have the older one installed already. Is there a workaround for this situation as well? Ian From wsiegrist at apple.com Mon Dec 22 09:50:41 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 22 Dec 2008 09:50:41 -0800 Subject: [44043] trunk/dports/devel In-Reply-To: References: <20081219213629.733ED9E6892@beta.macosforge.org> <80302B0B-3D10-45E7-B79A-E7907AFAB345@apple.com> Message-ID: <59E594EA-A3CA-4AF2-BD2F-3ACF8A7DCA41@apple.com> On Dec 21, 2008, at 11:03 PM, Ryan Schmidt wrote: > On Dec 20, 2008, at 14:23, William Siegrist wrote: > >> On Dec 20, 2008, at 12:50 AM, Ryan Schmidt wrote: >> >>> On Dec 19, 2008, at 15:36, wsiegrist at apple.com wrote: >>> >>>> +fetch.type svn >>>> +svn.url http://svn.macosforge.org/repository/darwinbuild/trunk/ >>>> +svn.tag HEAD >>> >>> If there is no tag for the 0.8.0 version, then you should use the >>> revision number that corresponds to the 0.8.0 version, not HEAD. >>> Using HEAD means building the port at different times fetches >>> different files from the darwinbuild repository, which we do not >>> want to occur; we want every user to get the same build every time. >>> >>> Is 0.8.0 released yet? If not, the port name darwinbuild-devel >>> might be more appropriate, and let the port darwinbuild be for the >>> latest released version instead. Unless the latest released >>> version is so old as to not be useful. >> >> There's no tag or revision for 0.8.0, thats just the version of >> trunk (like MP 1.8.0). There's also no stable released version, so >> I left off the -devel in the name. And yes, I know you get new >> files every time. I'm the primary developer of darwinbuild these >> days and recommend people live on trunk. This port is for people >> already running MP on a machine so they can "port upgrade >> darwinbuild" instead of doing the "svn up ... ; make ; make >> install" manually each time. > > Still, we want people to get the same software on their machine > every time they build a given epoch+version+revision+variant > combination of a given port. So you should pin this port to a > specific upstream revision in the svn.tag. You can always increment > the port's revision and svn.tag when you want to release new changes > to MacPorts users; that way they will be informed via "port > outdated" of the availability of the new changes. > > Otherwise you get the situation that two users install "version > 0.8.0" at different times, and the software works one way for one > user and another way (or even not at all) for a second user and > because they have the same version installed they will think they > have the same software when in fact unbeknownst to them they have > different upstream revisions. > > Yes, I know how macports works. Like I said, I made the port like that on purpose. What would be nice is if MacPorts would support this class of port where you want to live on trunk of a project. So when svn.tag==HEAD, it automatically sets the revision of the port to whatever rev it got from subversion. I've had a few projects lately that I've had to manually keep around working copies and periodically update and install. Much like MacPorts between 1.6 and 1.7, sometimes trunk is the best and least buggy version. In any case, I'm going to try a few things in base to see if MacPorts can support this style of port better. I dont think everyone is going to rush our and start using darwinbuild just because I made a port of it, so it can stay as my little experiment for now. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available URL: From dluke at geeklair.net Mon Dec 22 10:29:36 2008 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon, 22 Dec 2008 13:29:36 -0500 Subject: [44043] trunk/dports/devel In-Reply-To: <59E594EA-A3CA-4AF2-BD2F-3ACF8A7DCA41@apple.com> References: <20081219213629.733ED9E6892@beta.macosforge.org> <80302B0B-3D10-45E7-B79A-E7907AFAB345@apple.com> <59E594EA-A3CA-4AF2-BD2F-3ACF8A7DCA41@apple.com> Message-ID: <1AAA6819-CEE1-486F-A29C-9F662EB58896@geeklair.net> On Dec 22, 2008, at 12:50 PM, William Siegrist wrote: > In any case, I'm going to try a few things in base to see if > MacPorts can support this style of port better. I dont think > everyone is going to rush our and start using darwinbuild just > because I made a port of it, so it can stay as my little experiment > for now. If it's just 'your little experiment' it doesn't need to be in the public repo. I think you really should peg the revision that your port pulls (and you can update it if necessary) as that's the current policy. -- 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: From raimue at macports.org Mon Dec 22 12:02:38 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 22 Dec 2008 21:02:38 +0100 Subject: port revision depndency In-Reply-To: <20081222141533.3d43c45c@vignemale.cl.cam.ac.uk> References: <20081218144202.2296b00d@vignemale.cl.cam.ac.uk> <494A8457.8030204@macports.org> <20081218173524.GA3276@velsheda.lateralis.org> <494A8D32.7040804@macports.org> <20081222141533.3d43c45c@vignemale.cl.cam.ac.uk> Message-ID: <494FF25E.6070300@macports.org> Ian Grant wrote: > That's the problem with the mosml-dynlib port I submitted. It > requires a newer mosml port than the current one and people may have > the older one installed already. Is there a workaround for this > situation as well? Users are supposed to keep their ports up-to-date by using 'port upgrade' regularly. Rainer From macsforever2000 at macports.org Mon Dec 22 12:19:28 2008 From: macsforever2000 at macports.org (Frank Schima) Date: Mon, 22 Dec 2008 13:19:28 -0700 Subject: Strange tk wish issue with Mac OS X 10.5.6 Message-ID: <0A8B610F-C9C8-455D-A824-BA4A2DFE7A27@macports.org> I'm seeing a strange error when I try to run wish - I checked and it's /opt/local/bin/wish8.4. Note that I'm running tk 8.4.19 in order to also run blt [1]. This error started when I updated to 10.5.6. Before that it has worked just fine. I've since reinstalled Xcode 3.1.2. and Xquartz 2.3.1. I've also reinstalled my tk 8.4.19 port (many times). Any ideas? I have checked and /opt/local/lib/tk8.4/tk/tcl does exist. {{{ $ wish Application initialization failed: Can't find a usable tk.tcl in the following directories: /opt/local/lib/tcl8.4/tk8.4 /opt/local/lib/tcl8.4/tk8.4/Resources/ Scripts /opt/local/lib/tk8.4 /opt/local/lib/tk8.4/Resources/Scripts / opt/lib/tk8.4 /opt/local/library /opt/library /opt/tk8.4.19/library / tk8.4.19/library /opt/local/lib/tk8.4/tk.tcl: no event type or button # or keysym no event type or button # or keysym while executing "bind Listbox { %W yview scroll [expr {- (%D / 120) * 4}] units }" invoked from within "if {[tk windowingsystem] eq "classic" || [tk windowingsystem] eq "aqua"} { bind Listbox { %W yview scroll [expr {- (%D)}] uni..." (file "/opt/local/lib/tk8.4/listbox.tcl" line 181) invoked from within "source /opt/local/lib/tk8.4/listbox.tcl" (in namespace eval "::" script line 1) invoked from within "namespace eval :: [list source [file join $::tk_library $file.tcl]]" (procedure "SourceLibFile" line 2) invoked from within "SourceLibFile listbox" (in namespace eval "::tk" script line 4) invoked from within "namespace eval ::tk { SourceLibFile button SourceLibFile entry SourceLibFile listbox SourceLibFile menu SourceLibFile panedwindow SourceLibFile ..." invoked from within "if {$::tk_library ne ""} { if {$tcl_platform(platform) eq "macintosh"} { proc ::tk::SourceLibFile {file} { if {[catch { namespace eval :: ..." (file "/opt/local/lib/tk8.4/tk.tcl" line 407) invoked from within "source /opt/local/lib/tk8.4/tk.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $file]" This probably means that tk wasn't installed properly. }}} [1] Cheers! Frank From wsiegrist at apple.com Mon Dec 22 13:08:22 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 22 Dec 2008 13:08:22 -0800 Subject: [44043] trunk/dports/devel In-Reply-To: <1AAA6819-CEE1-486F-A29C-9F662EB58896@geeklair.net> References: <20081219213629.733ED9E6892@beta.macosforge.org> <80302B0B-3D10-45E7-B79A-E7907AFAB345@apple.com> <59E594EA-A3CA-4AF2-BD2F-3ACF8A7DCA41@apple.com> <1AAA6819-CEE1-486F-A29C-9F662EB58896@geeklair.net> Message-ID: <667EAFA5-DBD7-4BB9-B7C0-BEA8707E5D6C@apple.com> On Dec 22, 2008, at 10:29 AM, Daniel J. Luke wrote: > On Dec 22, 2008, at 12:50 PM, William Siegrist wrote: >> In any case, I'm going to try a few things in base to see if >> MacPorts can support this style of port better. I dont think >> everyone is going to rush our and start using darwinbuild just >> because I made a port of it, so it can stay as my little experiment >> for now. > > > If it's just 'your little experiment' it doesn't need to be in the > public repo. > > I think you really should peg the revision that your port pulls (and > you can update it if necessary) as that's the current policy. > Ok, not worth the hassle, fixed the rev in r44163. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available URL: From ryandesign at macports.org Mon Dec 22 13:11:58 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 22 Dec 2008 15:11:58 -0600 Subject: port revision depndency In-Reply-To: <20081222141533.3d43c45c@vignemale.cl.cam.ac.uk> References: <20081218144202.2296b00d@vignemale.cl.cam.ac.uk> <494A8457.8030204@macports.org> <20081218173524.GA3276@velsheda.lateralis.org> <494A8D32.7040804@macports.org> <20081222141533.3d43c45c@vignemale.cl.cam.ac.uk> Message-ID: <4131D5FC-D023-48E9-A374-5D6AE36051BC@macports.org> On Dec 22, 2008, at 08:15, Ian Grant wrote: > That's the problem with the mosml-dynlib port I submitted. It > requires a newer mosml port than the current one and people may > have the older one installed already. Is there a workaround for > this situation as well? The mosml port is at version 2.01, which seems according to their web site to be the current version. You're saying your mosml-dynlib port requires a newer (in-development) version of moslm than that? If so, a new port mosml-devel should be created to track the latest development version of mosml. Then your mosml-dynlib port can depend on that -- via the path:-syntax, listing a file mosml provides. In your port, you can add a pre-configure check to make sure the version of mosml is at least the one you need. You can look in the pure and cairo ports for examples of how I've done this. (pure started requiring a newer llvm than the stable version, so we have an llvm- devel port, and I checked the version of llvm pre-configure to make sure it was at least 2.4.) From Ian.Grant at cl.cam.ac.uk Tue Dec 23 02:29:06 2008 From: Ian.Grant at cl.cam.ac.uk (Ian Grant) Date: Tue, 23 Dec 2008 10:29:06 +0000 Subject: [MacPorts] #17736: gnome-doc-utils 0.14.0 -- build failure In-Reply-To: <067.1fd5c07a9dbd998d2aa7dde8fcfbe973@macports.org> References: <058.e016e2737d2fa5ef54ff4e7cbae34843@macports.org> <067.1fd5c07a9dbd998d2aa7dde8fcfbe973@macports.org> Message-ID: <20081223102906.1d8bc96a@vignemale.cl.cam.ac.uk> On Mon, 22 Dec 2008 21:50:52 -0000 "MacPorts" wrote: > gnome-doc-utils upgraded to version 0.14.1 in r44154 and builds > without incident on 10.4.11 ppc. Thanks, 0.14.1 works for me too. I had been operating on the assumption that if I didn't do a selfupdate I would get some sort of consistent picture of the ports tree, albeit not the very latest. Should I just be running a selfupdate every time, before I install any port? bramley:~$ sudo port selfupdate Password: MacPorts base version 1.700 installed Downloaded MacPorts base version 1.700 The MacPorts installation is not outdated so it was not updated bramley:~$ sudo port clean --all gnome-doc-utils Portfile changed since last build; discarding previous state. ---> Cleaning gnome-doc-utils bramley:~$ sudo port install gnome-doc-utils ---> Fetching gnome-doc-utils ---> Attempting to fetch gnome-doc-utils-0.14.1.tar.bz2 from http://www.mirrorservice.org/sites/ftp.gnome.org/pub/GNOME/sources/gnome-doc-utils/0.14/ ---> Attempting to fetch gnome-doc-utils-0.14.1.tar.bz2 from http://ftp.linux.org.uk/mirrors/ftp.gnome.org/sources/gnome-doc-utils/0.14/ ---> Attempting to fetch gnome-doc-utils-0.14.1.tar.bz2 from http://ftp.belnet.be/mirror/ftp.gnome.org/sources/gnome-doc-utils/0.14/ ---> Verifying checksum(s) for gnome-doc-utils ---> Extracting gnome-doc-utils ---> Configuring gnome-doc-utils ---> Building gnome-doc-utils ---> Staging gnome-doc-utils into destroot ---> Installing gnome-doc-utils @0.14.1_0 ---> Activating gnome-doc-utils @0.14.1_0 ---> Cleaning gnome-doc-utils bramley:~$ From devans at macports.org Tue Dec 23 07:21:58 2008 From: devans at macports.org (David Evans) Date: Tue, 23 Dec 2008 07:21:58 -0800 Subject: [MacPorts] #17736: gnome-doc-utils 0.14.0 -- build failure In-Reply-To: <20081223102906.1d8bc96a@vignemale.cl.cam.ac.uk> References: <058.e016e2737d2fa5ef54ff4e7cbae34843@macports.org> <067.1fd5c07a9dbd998d2aa7dde8fcfbe973@macports.org> <20081223102906.1d8bc96a@vignemale.cl.cam.ac.uk> Message-ID: <49510216.3000800@macports.org> Ian Grant wrote: > On Mon, 22 Dec 2008 21:50:52 -0000 > "MacPorts" wrote: > >> gnome-doc-utils upgraded to version 0.14.1 in r44154 and builds >> without incident on 10.4.11 ppc. >> > > Thanks, 0.14.1 works for me too. > > I had been operating on the assumption that if I didn't do a selfupdate I would get some sort of consistent picture of the ports tree, albeit not the very latest. Should I just be running a selfupdate every time, before I install any port? > > bramley:~$ sudo port selfupdate > Password: > > MacPorts base version 1.700 installed > Downloaded MacPorts base version 1.700 > > The MacPorts installation is not outdated so it was not updated > bramley:~$ sudo port clean --all gnome-doc-utils > Portfile changed since last build; discarding previous state. > ---> Cleaning gnome-doc-utils > bramley:~$ sudo port install gnome-doc-utils > ---> Fetching gnome-doc-utils > ---> Attempting to fetch gnome-doc-utils-0.14.1.tar.bz2 from http://www.mirrorservice.org/sites/ftp.gnome.org/pub/GNOME/sources/gnome-doc-utils/0.14/ > ---> Attempting to fetch gnome-doc-utils-0.14.1.tar.bz2 from http://ftp.linux.org.uk/mirrors/ftp.gnome.org/sources/gnome-doc-utils/0.14/ > ---> Attempting to fetch gnome-doc-utils-0.14.1.tar.bz2 from http://ftp.belnet.be/mirror/ftp.gnome.org/sources/gnome-doc-utils/0.14/ > ---> Verifying checksum(s) for gnome-doc-utils > ---> Extracting gnome-doc-utils > ---> Configuring gnome-doc-utils > ---> Building gnome-doc-utils > ---> Staging gnome-doc-utils into destroot > ---> Installing gnome-doc-utils @0.14.1_0 > ---> Activating gnome-doc-utils @0.14.1_0 > ---> Cleaning gnome-doc-utils > bramley:~$ > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > Yes, before installing or upgrading, its a good idea to run selfupdate to make sure you have the latest port version. And, if you have a problem, its probably good as well before opening a ticket to make sure that your problem hasn't already been solved. In this particular case, the problem was a known bug in MacPorts 1.6.0 that had been fixed in trunk for a long time (version 0.14.0 built ok for me using trunk) but has only been available to the general public since the release of 1.7.0. Glad your problem is solved. Dave From jmr at macports.org Tue Dec 23 13:08:13 2008 From: jmr at macports.org (Joshua Root) Date: Wed, 24 Dec 2008 08:08:13 +1100 Subject: [MacPorts] #17736: gnome-doc-utils 0.14.0 -- build failure In-Reply-To: <20081223102906.1d8bc96a@vignemale.cl.cam.ac.uk> References: <058.e016e2737d2fa5ef54ff4e7cbae34843@macports.org> <067.1fd5c07a9dbd998d2aa7dde8fcfbe973@macports.org> <20081223102906.1d8bc96a@vignemale.cl.cam.ac.uk> Message-ID: <4951533D.6000503@macports.org> Ian Grant wrote: > I had been operating on the assumption that if I didn't do a selfupdate I would get some sort of consistent picture of the ports tree, albeit not the very latest. It's a consistent snapshot, but that doesn't mean it's not broken. :-) > Should I just be running a selfupdate every time, before I install any port? Yes, `sudo port selfupdate && sudo port upgrade outdated` before you install anything new gives (in general) the best chance of success. - Josh From blb at macports.org Tue Dec 23 14:48:45 2008 From: blb at macports.org (Bryan Blackburn) Date: Tue, 23 Dec 2008 15:48:45 -0700 Subject: ::ui_init invalid (was gtk2 fails to build - libXdamage wrong version) Message-ID: <20081223224845.GD592@ninagal.withay.com> >From the -users list [1]: [...] > Warning: the following items did not execute (for gtk2): > org.macports.destroot org.macports.build > DEBUG: invalid command name "::ui_init" > while executing > "::ui_init $priority $prefix $channels $message" > ("uplevel" body line 2) > invoked from within > "uplevel 1 $body" > Error: Unable to upgrade port: 1 This is the second time I've seen this error message (though I've not seen it running port myself). Since this call to ::ui_init is in a try/catch block [2] shouldn't this not be happening? Or is there another call that I'm not seeing? Bryan [1] - [2] - From jmr at macports.org Tue Dec 23 15:08:04 2008 From: jmr at macports.org (Joshua Root) Date: Wed, 24 Dec 2008 10:08:04 +1100 Subject: ::ui_init invalid (was gtk2 fails to build - libXdamage wrong version) In-Reply-To: <20081223224845.GD592@ninagal.withay.com> References: <20081223224845.GD592@ninagal.withay.com> Message-ID: <49516F54.9000800@macports.org> Bryan Blackburn wrote: >>From the -users list [1]: > [...] >> Warning: the following items did not execute (for gtk2): >> org.macports.destroot org.macports.build >> DEBUG: invalid command name "::ui_init" >> while executing >> "::ui_init $priority $prefix $channels $message" >> ("uplevel" body line 2) >> invoked from within >> "uplevel 1 $body" >> Error: Unable to upgrade port: 1 > > This is the second time I've seen this error message (though I've not seen > it running port myself). Since this call to ::ui_init is in a try/catch > block [2] shouldn't this not be happening? Or is there another call that > I'm not seeing? > > Bryan > > [1] - > [2] - I see this all the time when something fails with debug mode on, FWIW. See for example . - Josh From jm at poure.com Wed Dec 24 03:12:44 2008 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Wed, 24 Dec 2008 12:12:44 +0100 Subject: Live DVD to test Kdenlive video editor Message-ID: <1230117164.13730.3.camel@debian> Dear Friends, If some of you are interested to become maintainer of MLT and Kdenlive, you can make your own opinion downloading our live DVD: http://www.kdenlive.org/user-manual/downloading-and-installing-kdenlive/live-dvd This is extremely important for us, that MacOsX users can benefit from a Free NLE in MacPorts. We wish you a merry christmas and happy new year, hoping that Kdenlive can enter MacPorts quickly. Kind regards, Jean-Michel From ryandesign at macports.org Wed Dec 24 13:36:15 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 24 Dec 2008 15:36:15 -0600 Subject: [43772] trunk/dports/net/curl/Portfile In-Reply-To: <20081214182657.AF29993594B@beta.macosforge.org> References: <20081214182657.AF29993594B@beta.macosforge.org> Message-ID: <2AEB7B30-DA62-4886-A1B5-3F181525D079@macports.org> On Dec 14, 2008, at 12:26, mcalhoun at macports.org wrote: > Revision: 43772 > http://trac.macports.org/changeset/43772 > Author: mcalhoun at macports.org > Date: 2008-12-14 10:26:55 -0800 (Sun, 14 Dec 2008) > Log Message: > ----------- > curl: Supports only the MIT or Heimdal Kerberos 5 packages for > GSSAPI support > (see http://curl.haxx.se/docs/install.html ). > Use system Kerberos > (see #12805 and #14775 for a partial list of other ports which also > do this). > Fixes #14775 (maintainer timeout). > > Modified Paths: > -------------- > trunk/dports/net/curl/Portfile > > Modified: trunk/dports/net/curl/Portfile > =================================================================== > --- trunk/dports/net/curl/Portfile 2008-12-14 17:52:20 UTC (rev 43771) > +++ trunk/dports/net/curl/Portfile 2008-12-14 18:26:55 UTC (rev 43772) > @@ -125,8 +125,7 @@ > } > > variant gss { > - depends_lib-append port:gss > - configure.args-append --with-gssapi=${prefix} > + configure.args-append --with-gssapi > } So now the gss variant only adds a configure argument and no longer brings in a dependency. Does this option conflict with anything else? If not, we could enable gss by default and get rid of the variant. Is this appropriate only on Mac OS X or on all platforms? From ryandesign at macports.org Wed Dec 24 13:40:17 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 24 Dec 2008 15:40:17 -0600 Subject: [43775] trunk/dports/audio/mpg123/Portfile In-Reply-To: <20081214211712.2C2E894059B@beta.macosforge.org> References: <20081214211712.2C2E894059B@beta.macosforge.org> Message-ID: <0EB53A32-96AC-4078-AA14-334CE724D19C@macports.org> On Dec 14, 2008, at 15:17, jmr at macports.org wrote: > Revision: 43775 > http://trac.macports.org/changeset/43775 > Author: jmr at macports.org > Date: 2008-12-14 13:17:09 -0800 (Sun, 14 Dec 2008) > Log Message: > ----------- > mpg123: platform 'powerpc' -> 'ppc' > > Modified Paths: > -------------- > trunk/dports/audio/mpg123/Portfile > > Modified: trunk/dports/audio/mpg123/Portfile > =================================================================== > --- trunk/dports/audio/mpg123/Portfile 2008-12-14 18:52:09 UTC (rev > 43774) > +++ trunk/dports/audio/mpg123/Portfile 2008-12-14 21:17:09 UTC (rev > 43775) > @@ -27,6 +27,6 @@ > configure.args-append --with-cpu=x86 > } > > -platform macosx powerpc { > +platform macosx ppc { > configure.args-append --with-cpu=altivec > } We have 60 occurrences of something like "platform powerpc" in the ports tree and only 8 occurrences of something like "platform ppc"...... Do both work? The Guide only shows "powerpc". http://guide.macports.org/#reference.variants.platform From ryandesign at macports.org Wed Dec 24 13:56:42 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 24 Dec 2008 15:56:42 -0600 Subject: [43824] trunk/dports/lang/guile/Portfile In-Reply-To: <20081215192333.D38FD96CC55@beta.macosforge.org> References: <20081215192333.D38FD96CC55@beta.macosforge.org> Message-ID: <4CD0BD75-EF85-4FFC-84AE-D81035C17294@macports.org> On Dec 15, 2008, at 13:23, devans at macports.org wrote: > patchfiles patch-srfi-60.c.diff \ > patch-slib.scm.diff \ > - patch-libguile-_scm.h.diff \ > patch-libguile-fports.c.diff Can files/patch-libguile-_scm.h.diff then be removed from the repository? From devans at macports.org Wed Dec 24 15:12:10 2008 From: devans at macports.org (David Evans) Date: Wed, 24 Dec 2008 15:12:10 -0800 Subject: [43824] trunk/dports/lang/guile/Portfile In-Reply-To: <4CD0BD75-EF85-4FFC-84AE-D81035C17294@macports.org> References: <20081215192333.D38FD96CC55@beta.macosforge.org> <4CD0BD75-EF85-4FFC-84AE-D81035C17294@macports.org> Message-ID: <4952C1CA.1090308@macports.org> Ryan Schmidt wrote: > On Dec 15, 2008, at 13:23, devans at macports.org wrote: > >> patchfiles patch-srfi-60.c.diff \ >> patch-slib.scm.diff \ >> - patch-libguile-_scm.h.diff \ >> patch-libguile-fports.c.diff > > Can files/patch-libguile-_scm.h.diff then be removed from the repository? > > Yes, thanks for catching this oversight. Deleted in r44282. From ryandesign at macports.org Wed Dec 24 15:55:17 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 24 Dec 2008 17:55:17 -0600 Subject: [43915] trunk/dports/gnustep/gnustep-make/Portfile In-Reply-To: <20081217073757.18EEC9A50B8@beta.macosforge.org> References: <20081217073757.18EEC9A50B8@beta.macosforge.org> Message-ID: <32CDCCEE-22C8-42D5-9A5A-FCE0BDE4692E@macports.org> On Dec 17, 2008, at 01:37, jeremyhu at macports.org wrote: > Revision: 43915 > http://trac.macports.org/changeset/43915 > Author: jeremyhu at macports.org > Date: 2008-12-16 23:37:56 -0800 (Tue, 16 Dec 2008) > Log Message: > ----------- > gnustep-make: not universal... fixed gcc dependency to run > > Modified Paths: > -------------- > trunk/dports/gnustep/gnustep-make/Portfile > > Modified: trunk/dports/gnustep/gnustep-make/Portfile > =================================================================== > --- trunk/dports/gnustep/gnustep-make/Portfile 2008-12-17 07:32:32 > UTC (rev 43914) > +++ trunk/dports/gnustep/gnustep-make/Portfile 2008-12-17 07:37:56 > UTC (rev 43915) > @@ -24,7 +24,8 @@ > > destroot.violate_mtree yes > > -depends_lib port:gcc42 > +universal_variant no > +depends_run port:gcc42 > > configure.args CC=gcc-mp-4.2 \ > --with-library-combo=gnu-gnu-gnu But the port sets the CC environment variable to gcc-mp-4.2 in the configure phase, thus making it a build-time dependency at least, and I imagine it links with the installed gcc library too. (I don't have any gcc port installed here right now so I haven't tested.) I wonder if the port should be using configure.compiler instead of setting the CC environment variable manually. I also wonder if the port should be offering the option of using gcc42 or gcc43, or if it should just be unconditionally upgraded to use gcc43, since that is the latest stable version. I haven't tested if it works with gcc43 yet. From blb at macports.org Wed Dec 24 16:12:09 2008 From: blb at macports.org (Bryan Blackburn) Date: Wed, 24 Dec 2008 17:12:09 -0700 Subject: [43775] trunk/dports/audio/mpg123/Portfile In-Reply-To: <0EB53A32-96AC-4078-AA14-334CE724D19C@macports.org> References: <20081214211712.2C2E894059B@beta.macosforge.org> <0EB53A32-96AC-4078-AA14-334CE724D19C@macports.org> Message-ID: <20081225001209.GA521@ninagal.withay.com> On Wed, Dec 24, 2008 at 03:40:17PM -0600, Ryan Schmidt said: > > On Dec 14, 2008, at 15:17, jmr at macports.org wrote: > >> Revision: 43775 >> http://trac.macports.org/changeset/43775 >> Author: jmr at macports.org >> Date: 2008-12-14 13:17:09 -0800 (Sun, 14 Dec 2008) >> Log Message: >> ----------- >> mpg123: platform 'powerpc' -> 'ppc' >> >> Modified Paths: >> -------------- >> trunk/dports/audio/mpg123/Portfile >> >> Modified: trunk/dports/audio/mpg123/Portfile >> =================================================================== >> --- trunk/dports/audio/mpg123/Portfile 2008-12-14 18:52:09 UTC (rev >> 43774) >> +++ trunk/dports/audio/mpg123/Portfile 2008-12-14 21:17:09 UTC (rev >> 43775) >> @@ -27,6 +27,6 @@ >> configure.args-append --with-cpu=x86 >> } >> >> -platform macosx powerpc { >> +platform macosx ppc { >> configure.args-append --with-cpu=altivec >> } > > > We have 60 occurrences of something like "platform powerpc" in the ports > tree and only 8 occurrences of something like "platform ppc"...... Do both > work? The Guide only shows "powerpc". port [1] and portmain [2] both convert "Power Macintosh" to powerpc, for os_arch. Seems like powerpc is the one and those using ppc should be changed. If there's some places where it will report ppc instead, shouldn't we change that to powerpc as well? Bryan [1] - [2] - > > http://guide.macports.org/#reference.variants.platform > From ryandesign at macports.org Wed Dec 24 17:30:44 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 24 Dec 2008 19:30:44 -0600 Subject: [44018] trunk/dports/net/tcpflow/Portfile In-Reply-To: <20081219180406.8DBB09DF8DD@beta.macosforge.org> References: <20081219180406.8DBB09DF8DD@beta.macosforge.org> Message-ID: <4DD02972-A9B8-4185-92E3-6B3E2A658263@macports.org> On Dec 19, 2008, at 12:04, jmr at macports.org wrote: > Revision: 44018 > http://trac.macports.org/changeset/44018 > Author: jmr at macports.org > Date: 2008-12-19 10:04:06 -0800 (Fri, 19 Dec 2008) > Log Message: > ----------- > tcpflow: leave setting MDT to base, and don't break with libtool 2 > -platform darwin 9 { > -#macosx_deployment_target 10.4 > - configure.env-append MACOSX_DEPLOYMENT_TARGET=10.4 > - build.env-append MACOSX_DEPLOYMENT_TARGET=10.4 > - destroot.env-append MACOSX_DEPLOYMENT_TARGET=10.4 > -} Are you sure this change is ok? Because this was specifically setting the MACOSX_DEPLOYMENT_TARGET to 10.4 on Leopard to fix a problem encountered when it was set to its default value of 10.5: http://trac.macports.org/changeset/30652 http://trac.macports.org/changeset/31219 I haven't tested whether this is still a problem. From kngspook at gmail.com Wed Dec 24 17:40:42 2008 From: kngspook at gmail.com (Neil) Date: Wed, 24 Dec 2008 17:40:42 -0800 Subject: [43775] trunk/dports/audio/mpg123/Portfile In-Reply-To: <20081225001209.GA521@ninagal.withay.com> References: <20081214211712.2C2E894059B@beta.macosforge.org> <0EB53A32-96AC-4078-AA14-334CE724D19C@macports.org> <20081225001209.GA521@ninagal.withay.com> Message-ID: <77e4079b0812241740r24bc8472x6a130c97ce9211f2@mail.gmail.com> On Wed, Dec 24, 2008 at 4:12 PM, Bryan Blackburn wrote: > On Wed, Dec 24, 2008 at 03:40:17PM -0600, Ryan Schmidt said: >> >> On Dec 14, 2008, at 15:17, jmr at macports.org wrote: >> >>> Revision: 43775 >>> http://trac.macports.org/changeset/43775 >>> Author: jmr at macports.org >>> Date: 2008-12-14 13:17:09 -0800 (Sun, 14 Dec 2008) >>> Log Message: >>> ----------- >>> mpg123: platform 'powerpc' -> 'ppc' >>> >>> Modified Paths: >>> -------------- >>> trunk/dports/audio/mpg123/Portfile >>> >>> Modified: trunk/dports/audio/mpg123/Portfile >>> =================================================================== >>> --- trunk/dports/audio/mpg123/Portfile 2008-12-14 18:52:09 UTC (rev >>> 43774) >>> +++ trunk/dports/audio/mpg123/Portfile 2008-12-14 21:17:09 UTC (rev >>> 43775) >>> @@ -27,6 +27,6 @@ >>> configure.args-append --with-cpu=x86 >>> } >>> >>> -platform macosx powerpc { >>> +platform macosx ppc { >>> configure.args-append --with-cpu=altivec >>> } >> >> >> We have 60 occurrences of something like "platform powerpc" in the ports >> tree and only 8 occurrences of something like "platform ppc"...... Do both >> work? The Guide only shows "powerpc". > > port [1] and portmain [2] both convert "Power Macintosh" to powerpc, for > os_arch. Seems like powerpc is the one and those using ppc should be > changed. If there's some places where it will report ppc instead, shouldn't > we change that to powerpc as well? > > Bryan > > [1] - > [2] - > > >> >> http://guide.macports.org/#reference.variants.platform >> I suspect you'll find 'ppc' to be more intuitive to users, however. From ryandesign at macports.org Wed Dec 24 18:48:25 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 24 Dec 2008 20:48:25 -0600 Subject: [44037] trunk/dports/perl In-Reply-To: <20081219192618.D02D99E2799@beta.macosforge.org> References: <20081219192618.D02D99E2799@beta.macosforge.org> Message-ID: <763A9B00-BDB0-433D-9CEF-409D0EB5DC5E@macports.org> On Dec 19, 2008, at 13:26, narf_tm at macports.org wrote: > Revision: 44037 > http://trac.macports.org/changeset/44037 > Author: narf_tm at macports.org > Date: 2008-12-19 11:26:18 -0800 (Fri, 19 Dec 2008) > Log Message: > ----------- > New port p5-text-spellchecker 0.05. You also updated p5-xml-sax-expat to 0.40... intentional? > Modified Paths: > -------------- > trunk/dports/perl/p5-xml-sax-expat/Portfile > > Added Paths: > ----------- > trunk/dports/perl/p5-text-spellchecker/ > trunk/dports/perl/p5-text-spellchecker/Portfile > > Added: trunk/dports/perl/p5-text-spellchecker/Portfile > =================================================================== > --- trunk/dports/perl/p5-text-spellchecker/ > Portfile (rev 0) > +++ trunk/dports/perl/p5-text-spellchecker/Portfile 2008-12-19 > 19:26:18 UTC (rev 44037) > @@ -0,0 +1,17 @@ > +# $Id$ > + > +PortSystem 1.0 > +PortGroup perl5 1.0 > + > +perl5.setup Text-SpellChecker 0.05 > +maintainers narf_tm openmaintainer > +description OO interface for spell-checking a block of text > +long_description ${description} > + > +platforms darwin > + > +checksums md5 3a6be263bb08e82cb7a975ca799063a7 \ > + sha1 0ac032a447bca6a703cd60dec19c15f8b786241b \ > + rmd160 4153eb7567829f96ec67e6d91dae9ea2e82d6dae > + > +depends_lib-append port:p5-text-aspell > > > Property changes on: trunk/dports/perl/p5-text-spellchecker/Portfile > ___________________________________________________________________ > Added: svn:keywords > + Id > Added: svn:eol-style > + native > > Modified: trunk/dports/perl/p5-xml-sax-expat/Portfile > =================================================================== > --- trunk/dports/perl/p5-xml-sax-expat/Portfile 2008-12-19 19:23:42 > UTC (rev 44036) > +++ trunk/dports/perl/p5-xml-sax-expat/Portfile 2008-12-19 19:26:18 > UTC (rev 44037) > @@ -1,21 +1,25 @@ > # $Id$ > > -PortSystem 1.0 > -PortGroup perl5 1.0 > -perl5.setup XML-SAX-Expat 0.39 > -maintainers sal at email.arc.nasa.gov > -description SAX2 Driver for Expat (XML::Parser) > -long_description This is an implementation of a SAX2 driver \ > - sitting on top of Expat (XML::Parser) > +PortSystem 1.0 > +PortGroup perl5 1.0 > > -platforms darwin > +perl5.setup XML-SAX-Expat 0.40 > +maintainers sal at email.arc.nasa.gov > +description SAX2 Driver for Expat (XML::Parser) > +long_description This is an implementation of a SAX2 driver \ > + sitting on top of Expat (XML::Parser) > > -checksums md5 a31400a29eae0eec74650bd06dbc823f \ > - sha1 0f440b662a137705ee0e358fd1fc92e510500806 \ > - rmd160 da36f9b2a1c9a53729f4b0e1e35a15349c8f0101 > +platforms darwin > > -depends_lib-append port:p5-xml-parser port:p5-xml-sax port:p5-xml- > namespacesupport > +checksums md5 ca58d1e26c437b31c52456b4b4ae5c4a \ > + sha1 3fdbd7b5e83216bb24d1e83ff3a6c17fcde9ba3f \ > + rmd160 fd0452bc817b55607ebbb4e8de017c6fd99ecaea > > -post-activate { > - system "cd ${worksrcpath} && ${build.cmd} install_sax_expat" > -} > +depends_lib-append port:p5-xml-parser \ > + port:p5-xml-sax \ > + port:p5-xml-namespacesupport \ > + port:p5-xml-sax-base > + > +post-activate { > + system "cd ${worksrcpath} && ${build.cmd} install_sax_expat" > +} From ryandesign at macports.org Wed Dec 24 19:01:04 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 24 Dec 2008 21:01:04 -0600 Subject: [44109] trunk/dports/kde In-Reply-To: <20081222005207.65D6CA1664F@beta.macosforge.org> References: <20081222005207.65D6CA1664F@beta.macosforge.org> Message-ID: On Dec 21, 2008, at 18:52, illogic-al at macports.org wrote: > Revision: 44109 > http://trac.macports.org/changeset/44109 > Author: illogic-al at macports.org > Date: 2008-12-21 16:52:07 -0800 (Sun, 21 Dec 2008) > Log Message: > ----------- > Development version of amarok > +post-destroot { > + # put the bundle icons where they should go > + system "mv ${destroot}/${prefix}/bin/amarok.app/Contents/ > Resources ${destroot}/Applications/KDE4/Amarok.app/Contents/" > + system "rm -rf ${destroot}/${prefix}/bin" > +} Applications should go in ${applications_dir} (or in a subdirectory KDE4 of that directory, if you like) And there shouldn't be a need to use "system" to move and delete items; just use the tcl commands for those tasks. From ryandesign at macports.org Wed Dec 24 20:04:16 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 24 Dec 2008 22:04:16 -0600 Subject: [44299] trunk/dports/kde/amarok-devel/Portfile In-Reply-To: <20081225033304.C44FCA729AB@beta.macosforge.org> References: <20081225033304.C44FCA729AB@beta.macosforge.org> Message-ID: <3625CEF5-B4D9-4B37-8E42-3246DE61EFB3@macports.org> On Dec 24, 2008, at 21:33, illogic-al at macports.org wrote: > -svn.tag 901313 > +svn.tag 901293 I don't know if the previous revision built or not, but if it did, then you should increase the port's revision now, so that anyone who had the old revision installed will be prompted about this new one via "port outdated" From ryandesign at macports.org Wed Dec 24 21:33:39 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 24 Dec 2008 23:33:39 -0600 Subject: [43775] trunk/dports/audio/mpg123/Portfile In-Reply-To: <77e4079b0812241740r24bc8472x6a130c97ce9211f2@mail.gmail.com> References: <20081214211712.2C2E894059B@beta.macosforge.org> <0EB53A32-96AC-4078-AA14-334CE724D19C@macports.org> <20081225001209.GA521@ninagal.withay.com> <77e4079b0812241740r24bc8472x6a130c97ce9211f2@mail.gmail.com> Message-ID: <168AE2F9-D7C4-489B-90F9-6D502398DC16@macports.org> On Dec 24, 2008, at 19:40, Neil wrote: > On Wed, Dec 24, 2008 at 4:12 PM, Bryan Blackburn wrote: >> On Wed, Dec 24, 2008 at 03:40:17PM -0600, Ryan Schmidt said: >>> We have 60 occurrences of something like "platform powerpc" in >>> the ports >>> tree and only 8 occurrences of something like "platform >>> ppc"...... Do both >>> work? The Guide only shows "powerpc". >> >> port [1] and portmain [2] both convert "Power Macintosh" to >> powerpc, for >> os_arch. Seems like powerpc is the one and those using ppc should be >> changed. If there's some places where it will report ppc instead, >> shouldn't >> we change that to powerpc as well? >> >> Bryan >> >> [1] - > port.tcl#L1723> >> [2] - > portmain.tcl#L86> >> >> >>> http://guide.macports.org/#reference.variants.platform > > I suspect you'll find 'ppc' to be more intuitive to users, however. Not to those users used to MacPorts, which has used "powerpc" since forever. Then again, "ppc" is the arch needed to compile, and is what we use in universal_archs. We could change MacPorts base to use that for the platform variant as well, and then change all ports. But if that's what we're trying to do, we should first discuss it here and reach consensus that the effort is worth it. From ryandesign at macports.org Wed Dec 24 23:05:55 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 25 Dec 2008 01:05:55 -0600 Subject: [43783] trunk/base/src/port1.0/portconfigure.tcl In-Reply-To: <20081215031844.1E126952F83@beta.macosforge.org> References: <20081215031844.1E126952F83@beta.macosforge.org> Message-ID: <87D2DB80-9DB7-41CB-8655-EED8A675B1F4@macports.org> On Dec 14, 2008, at 21:18, raimue at macports.org wrote: > Revision: 43783 > http://trac.macports.org/changeset/43783 > Author: raimue at macports.org > Date: 2008-12-14 19:18:43 -0800 (Sun, 14 Dec 2008) > Log Message: > ----------- > port1.0/portconfigure.tcl: > Add correct dependencies for the different tools which can > be selected with use_*. Inspired by r43782. > Revision: 43784 > http://trac.macports.org/changeset/43784 > Author: raimue at macports.org > Date: 2008-12-14 19:27:48 -0800 (Sun, 14 Dec 2008) > Log Message: > ----------- > port1.0/portconfigure.tcl: > autoreconf is actually provided by autoconf > Revision: 43785 > http://trac.macports.org/changeset/43785 > Author: jmr at macports.org > Date: 2008-12-14 19:35:03 -0800 (Sun, 14 Dec 2008) > Log Message: > ----------- > More appropriate binaries for autoconf & automake deps > option_proc use_autoreconf set_configure_type > option_proc use_automake set_configure_type > option_proc use_autoconf set_configure_type > option_proc use_xmkmf set_configure_type > > proc set_configure_type {option action args} { > if {[string equal ${action} "set"] && [tbool args]} { > switch $option { > use_autoreconf { > depends_build-append bin:autoreconf:autoconf > } > use_automake { > depends_build-append bin:automake:automake > } > use_autoconf { > depends_build-append bin:autoconf:autoconf > } > use_xmkmf { > depends_build-append bin:xmkmf:imake > } > } > } > } While I like this in general, how this will interact with ports like the php5 port that override the command? php5 does this: depends_build \ port:pkgconfig \ port:autoconf213 [snip] use_autoconf yes autoconf.cmd ${prefix}/bin/autoconf213 So now due to the above change a dependency on autoconf gets added even though php5 won't be using a binary called autoconf. I guess the unnecessary autoconf port won't actually be installed because MacPorts will find the autoconf in /usr/bin to satisfy it... Hmm... From florian.ebeling at gmail.com Thu Dec 25 03:24:17 2008 From: florian.ebeling at gmail.com (C. Florian Ebeling) Date: Thu, 25 Dec 2008 12:24:17 +0100 Subject: Will ruby19 replace ruby? In-Reply-To: <77e4079b0812250306w187a28f6xd80f863fd4dee0c6@mail.gmail.com> References: <77e4079b0812250230n2f09367fk235f0ef98cdb82c@mail.gmail.com> <5cbbe4ae0812250259v47d5a655u7dab791f4eeeab0@mail.gmail.com> <77e4079b0812250306w187a28f6xd80f863fd4dee0c6@mail.gmail.com> Message-ID: <5cbbe4ae0812250324w4242c5d9v770bc7900ee1cc58@mail.gmail.com> On Thu, Dec 25, 2008 at 12:06 PM, Neil wrote: > On Thu, Dec 25, 2008 at 2:59 AM, C. Florian Ebeling > wrote: >> On Thu, Dec 25, 2008 at 11:30 AM, Neil wrote: >>> After ruby19 is stable, will it replace ruby? >> >> since 1.9 has a slightly, but incompatibly changed syntax, I don't >> think that would be a good idea. I find other dynamic languages >> being present in parallel in several versions and though we do >> the same with ruby. E.g we have php4/php5, >> python{21,22,23,24,25,26,30}, perl{5,5.8,5.10}, >> so it seems reasonable to do the same with ruby. >> > > I don't think it would be a good idea either, but I wasn't sure: > there's no 'perl' or 'python' ports, but there's a 'ruby'. > > So then for consistency's sake, there should be some renames; for example: > ruby -> ruby18 > py-* -> py24-* (or to their respective dep, all the ones I've seen are > depending on python24) > rb-* -> ruby18-* (perhaps) sounds like a lot of work to me for a small gain. you would probably need an empty "ruby" port with a sole "ruby18" dependency to avoid breaking all existing ports and installation, and then explain all this to puzzeled users. and probably the same for all ruby/rb-* ports. So quite some migration phase. but if somebody was willing to drive such an effort I wouldn't opposed it. we should still probably get quite detailed reasoning about all the implications for various scenarios and explaintions why it doesn't break things, before starting. PS. Please use Reply-All in list discussions, otherwise mails don't make it to the list. -- Florian Ebeling Twitter: febeling florian.ebeling at gmail.com From illogical1 at gmail.com Thu Dec 25 03:55:16 2008 From: illogical1 at gmail.com (O) Date: Thu, 25 Dec 2008 06:55:16 -0500 Subject: [44299] trunk/dports/kde/amarok-devel/Portfile In-Reply-To: <3625CEF5-B4D9-4B37-8E42-3246DE61EFB3@macports.org> References: <20081225033304.C44FCA729AB@beta.macosforge.org> <3625CEF5-B4D9-4B37-8E42-3246DE61EFB3@macports.org> Message-ID: <797cc39c0812250355p6c586959oe0dd346fb489d763@mail.gmail.com> On Wed, Dec 24, 2008 at 11:04 PM, Ryan Schmidt wrote: > > On Dec 24, 2008, at 21:33, illogic-al at macports.org wrote: > >> -svn.tag 901313 >> +svn.tag 901293 > > I don't know if the previous revision built or not, but if it did, then you > should increase the port's revision now, so that anyone who had the old > revision installed will be prompted about this new one via "port outdated" > > it didn't build, but it was only up in the cloud for a few seconds anyway :-) -- Henny Youngman - "If at first you don't succeed... so much for skydiving." From raimue at macports.org Thu Dec 25 05:33:56 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 25 Dec 2008 14:33:56 +0100 Subject: [43783] trunk/base/src/port1.0/portconfigure.tcl In-Reply-To: <87D2DB80-9DB7-41CB-8655-EED8A675B1F4@macports.org> References: <20081215031844.1E126952F83@beta.macosforge.org> <87D2DB80-9DB7-41CB-8655-EED8A675B1F4@macports.org> Message-ID: <49538BC4.6020907@macports.org> Ryan Schmidt wrote: > While I like this in general, how this will interact with ports like > the php5 port that override the command? php5 does this: > > depends_build \ > port:pkgconfig \ > port:autoconf213 > > [snip] > > use_autoconf yes > autoconf.cmd ${prefix}/bin/autoconf213 > > So now due to the above change a dependency on autoconf gets added > even though php5 won't be using a binary called autoconf. > > I guess the unnecessary autoconf port won't actually be installed > because MacPorts will find the autoconf in /usr/bin to satisfy it... > Hmm... You are right, this might pull in unnecessary dependencies. Should we remove the dependency if autoconf.cmd is not the default value and it has to be declared in the port itself? Rainer From vincent-opdarw at vinc17.org Thu Dec 25 06:48:49 2008 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Thu, 25 Dec 2008 15:48:49 +0100 Subject: gtk2 x11 category and quartz variant Message-ID: <20081225144849.GM17090@prunille.vinc17.org> Is it normal that gtk2 is still in the x11 category, though there's now a quartz variant, that doesn't depend on X11 at all? -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From ryandesign at macports.org Thu Dec 25 12:22:05 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 25 Dec 2008 14:22:05 -0600 Subject: [43783] trunk/base/src/port1.0/portconfigure.tcl In-Reply-To: <49538BC4.6020907@macports.org> References: <20081215031844.1E126952F83@beta.macosforge.org> <87D2DB80-9DB7-41CB-8655-EED8A675B1F4@macports.org> <49538BC4.6020907@macports.org> Message-ID: <01746DD5-C427-47A8-8EF6-578248970B23@macports.org> On Dec 25, 2008, at 07:33, Rainer M?ller wrote: > Ryan Schmidt wrote: >> While I like this in general, how this will interact with ports like >> the php5 port that override the command? php5 does this: >> >> depends_build \ >> port:pkgconfig \ >> port:autoconf213 >> >> [snip] >> >> use_autoconf yes >> autoconf.cmd ${prefix}/bin/autoconf213 >> >> So now due to the above change a dependency on autoconf gets added >> even though php5 won't be using a binary called autoconf. >> >> I guess the unnecessary autoconf port won't actually be installed >> because MacPorts will find the autoconf in /usr/bin to satisfy it... >> Hmm... > > You are right, this might pull in unnecessary dependencies. Should we > remove the dependency if autoconf.cmd is not the default value and it > has to be declared in the port itself? Do we know how to do that? That sounds ideal. From jeremyhu at macports.org Thu Dec 25 12:49:41 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Thu, 25 Dec 2008 12:49:41 -0800 Subject: gtk2 x11 category and quartz variant In-Reply-To: <20081225144849.GM17090@prunille.vinc17.org> References: <20081225144849.GM17090@prunille.vinc17.org> Message-ID: It's less weird than 'glui' which doesn't even use X11 and is in there... We could do something like qt which have separate qt4-mac and qt4-x11 variants... or we could create a separate 'toolkit' secondary category for all of these (lesstif, openmotif, fox, qt*, gtk, gtk2, etc etc) Honestly, I don't really think it's worth it... /shrug On Dec 25, 2008, at 06:48, Vincent Lefevre wrote: > Is it normal that gtk2 is still in the x11 category, though there's > now a quartz variant, that doesn't depend on X11 at all? > > -- > Vincent Lef?vre - Web: > 100% accessible validated (X)HTML - Blog: blog/> > Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS- > Lyon) > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From blb at macports.org Thu Dec 25 13:42:03 2008 From: blb at macports.org (Bryan Blackburn) Date: Thu, 25 Dec 2008 14:42:03 -0700 Subject: [44309] trunk/dports/kde/kdelibs4-devel/Portfile In-Reply-To: <20081225122757.B2034A77361@beta.macosforge.org> References: <20081225122757.B2034A77361@beta.macosforge.org> Message-ID: <20081225214203.GC629@ninagal.withay.com> On Thu, Dec 25, 2008 at 04:27:54AM -0800, illogic-al at macports.org said: > Revision: 44309 > http://trac.macports.org/changeset/44309 > Author: illogic-al at macports.org > Date: 2008-12-25 04:27:49 -0800 (Thu, 25 Dec 2008) > Log Message: > ----------- > Make the patch patch. Now patching kdelibs works. > > Modified Paths: > -------------- > trunk/dports/kde/kdelibs4-devel/Portfile > > Modified: trunk/dports/kde/kdelibs4-devel/Portfile > =================================================================== > --- trunk/dports/kde/kdelibs4-devel/Portfile 2008-12-25 05:51:42 UTC (rev 44308) > +++ trunk/dports/kde/kdelibs4-devel/Portfile 2008-12-25 12:27:49 UTC (rev 44309) > @@ -35,7 +35,7 @@ > configure.env-append QTDIR=${prefix}/libexec/qt4-mac > use_parallel_build yes > worksrcdir build > -pre-configure { file mkdir ${worksrcpath} } > +post-extract { file mkdir ${worksrcpath} } FYI, you can now use extract.mkdir yes instead, which does the mkdir in a pre-extract phase [1]. Though we do need to document it. Bryan [1] - From ryandesign at macports.org Thu Dec 25 13:59:23 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 25 Dec 2008 15:59:23 -0600 Subject: [44299] trunk/dports/kde/amarok-devel/Portfile In-Reply-To: <797cc39c0812250355p6c586959oe0dd346fb489d763@mail.gmail.com> References: <20081225033304.C44FCA729AB@beta.macosforge.org> <3625CEF5-B4D9-4B37-8E42-3246DE61EFB3@macports.org> <797cc39c0812250355p6c586959oe0dd346fb489d763@mail.gmail.com> Message-ID: On Dec 25, 2008, at 05:55, O wrote: > On Wed, Dec 24, 2008 at 11:04 PM, Ryan Schmidt wrote: > >> On Dec 24, 2008, at 21:33, illogic-al at macports.org wrote: >> >>> -svn.tag 901313 >>> +svn.tag 901293 >> >> I don't know if the previous revision built or not, but if it did, >> then you >> should increase the port's revision now, so that anyone who had >> the old >> revision installed will be prompted about this new one via "port >> outdated" > > it didn't build, but it was only up in the cloud for a few seconds > anyway :-) 901313 was there for only 2 minutes, but before that 899860 had been there for 10 hours, enough time to get into the portindex. Did 899860 build? From ryandesign at macports.org Thu Dec 25 14:03:25 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 25 Dec 2008 16:03:25 -0600 Subject: [44037] trunk/dports/perl In-Reply-To: References: <20081219192618.D02D99E2799@beta.macosforge.org> <763A9B00-BDB0-433D-9CEF-409D0EB5DC5E@macports.org> Message-ID: <7CDF78E7-40E6-488C-908A-B73D056BA1D3@macports.org> On Dec 25, 2008, at 11:15, Matthew Ross wrote: > On Dec 24, 2008, at 8:48 PM, Ryan Schmidt wrote: > >> On Dec 19, 2008, at 13:26, narf_tm at macports.org wrote: >> >>> Revision: 44037 >>> http://trac.macports.org/changeset/44037 >>> Author: narf_tm at macports.org >>> Date: 2008-12-19 11:26:18 -0800 (Fri, 19 Dec 2008) >>> Log Message: >>> ----------- >>> New port p5-text-spellchecker 0.05. >> >> You also updated p5-xml-sax-expat to 0.40... intentional? > > No, that was a mistake :-( > Wasn't sure how/if I should correct it. If you meant to update the version of p5-xml-sax-expat anyway (but had meant to do so in a separate commit), no problem; just add a note to the commit message to say that you did also update that port: cd /path/to/workingcopy svn propedit --revprop -r44037 svn:log I see it's not your port... Is that why you didn't mean to commit it? You could email the maintainer and ask if it's ok that you updated it; if so, you can just do as above. Otherwise if you need to undo the change, here's how: cd /path/to/workingcopy svn merge -c-44037 \ http://svn.macosforge.org/repository/macports/trunk/dports/perl/p5- xml-sax-expat Unfortunately the diff does not apply cleanly because other changes have been made to the port since then and r44037 not only updated the port version but also included lots of whitespace changes. This is another reason it's preferable to commit whitespace changes and functional changes separately from one another. You would also add "epoch 1" to the Portfile to ensure that anyone who had already updated to 0.40 will downgrade back to 0.39. Then commit all the changes: svn commit -m "p5-xml-sax-expat: undo inadvertent update from r44037" Then add a note to the log message for r44037 to indicate that the changes to p5-xml-sax-expat were inadvertent and undone in whatever revision it is: cd /path/to/workingcopy svn propedit --revprop -r44037 svn:log This is clearly a lot more work than the first option, so hopefully it will be ok to keep the updated version of p5-xml-sax-expat. >>> Modified Paths: >>> -------------- >>> trunk/dports/perl/p5-xml-sax-expat/Portfile >>> >>> Added Paths: >>> ----------- >>> trunk/dports/perl/p5-text-spellchecker/ >>> trunk/dports/perl/p5-text-spellchecker/Portfile >>> >>> Added: trunk/dports/perl/p5-text-spellchecker/Portfile >>> =================================================================== >>> --- trunk/dports/perl/p5-text-spellchecker/ >>> Portfile (rev 0) >>> +++ trunk/dports/perl/p5-text-spellchecker/Portfile 2008-12-19 >>> 19:26:18 UTC (rev 44037) >>> @@ -0,0 +1,17 @@ >>> +# $Id$ >>> + >>> +PortSystem 1.0 >>> +PortGroup perl5 1.0 >>> + >>> +perl5.setup Text-SpellChecker 0.05 >>> +maintainers narf_tm openmaintainer >>> +description OO interface for spell-checking a block of >>> text >>> +long_description ${description} >>> + >>> +platforms darwin >>> + >>> +checksums md5 3a6be263bb08e82cb7a975ca799063a7 \ >>> + sha1 >>> 0ac032a447bca6a703cd60dec19c15f8b786241b \ >>> + rmd160 >>> 4153eb7567829f96ec67e6d91dae9ea2e82d6dae >>> + >>> +depends_lib-append port:p5-text-aspell >>> >>> >>> Property changes on: trunk/dports/perl/p5-text-spellchecker/Portfile >>> ___________________________________________________________________ >>> Added: svn:keywords >>> + Id >>> Added: svn:eol-style >>> + native >>> >>> Modified: trunk/dports/perl/p5-xml-sax-expat/Portfile >>> =================================================================== >>> --- trunk/dports/perl/p5-xml-sax-expat/Portfile 2008-12-19 >>> 19:23:42 UTC (rev 44036) >>> +++ trunk/dports/perl/p5-xml-sax-expat/Portfile 2008-12-19 >>> 19:26:18 UTC (rev 44037) >>> @@ -1,21 +1,25 @@ >>> # $Id$ >>> >>> -PortSystem 1.0 >>> -PortGroup perl5 1.0 >>> -perl5.setup XML-SAX-Expat 0.39 >>> -maintainers sal at email.arc.nasa.gov >>> -description SAX2 Driver for Expat (XML::Parser) >>> -long_description This is an implementation of a SAX2 driver \ >>> - sitting on top of Expat (XML::Parser) >>> +PortSystem 1.0 >>> +PortGroup perl5 1.0 >>> >>> -platforms darwin >>> +perl5.setup XML-SAX-Expat 0.40 >>> +maintainers sal at email.arc.nasa.gov >>> +description SAX2 Driver for Expat (XML::Parser) >>> +long_description This is an implementation of a SAX2 driver \ >>> + sitting on top of Expat (XML::Parser) >>> >>> -checksums md5 a31400a29eae0eec74650bd06dbc823f \ >>> - sha1 0f440b662a137705ee0e358fd1fc92e510500806 \ >>> - rmd160 da36f9b2a1c9a53729f4b0e1e35a15349c8f0101 >>> +platforms darwin >>> >>> -depends_lib-append port:p5-xml-parser port:p5-xml-sax port:p5- >>> xml-namespacesupport >>> +checksums md5 ca58d1e26c437b31c52456b4b4ae5c4a \ >>> + sha1 >>> 3fdbd7b5e83216bb24d1e83ff3a6c17fcde9ba3f \ >>> + rmd160 >>> fd0452bc817b55607ebbb4e8de017c6fd99ecaea >>> >>> -post-activate { >>> - system "cd ${worksrcpath} && ${build.cmd} install_sax_expat" >>> -} >>> +depends_lib-append port:p5-xml-parser \ >>> + port:p5-xml-sax \ >>> + port:p5-xml-namespacesupport \ >>> + port:p5-xml-sax-base >>> + >>> +post-activate { >>> + system "cd ${worksrcpath} && ${build.cmd} install_sax_expat" >>> +} From kngspook at gmail.com Thu Dec 25 16:51:08 2008 From: kngspook at gmail.com (Neil) Date: Thu, 25 Dec 2008 16:51:08 -0800 Subject: Will ruby19 replace ruby? In-Reply-To: <5cbbe4ae0812250324w4242c5d9v770bc7900ee1cc58@mail.gmail.com> References: <77e4079b0812250230n2f09367fk235f0ef98cdb82c@mail.gmail.com> <5cbbe4ae0812250259v47d5a655u7dab791f4eeeab0@mail.gmail.com> <77e4079b0812250306w187a28f6xd80f863fd4dee0c6@mail.gmail.com> <5cbbe4ae0812250324w4242c5d9v770bc7900ee1cc58@mail.gmail.com> Message-ID: <77e4079b0812251651h78bfab58nde3319e28a9f8cb8@mail.gmail.com> On Thu, Dec 25, 2008 at 3:24 AM, C. Florian Ebeling wrote: > On Thu, Dec 25, 2008 at 12:06 PM, Neil wrote: >> On Thu, Dec 25, 2008 at 2:59 AM, C. Florian Ebeling >> wrote: >>> On Thu, Dec 25, 2008 at 11:30 AM, Neil wrote: >>>> After ruby19 is stable, will it replace ruby? >>> >>> since 1.9 has a slightly, but incompatibly changed syntax, I don't >>> think that would be a good idea. I find other dynamic languages >>> being present in parallel in several versions and though we do >>> the same with ruby. E.g we have php4/php5, >>> python{21,22,23,24,25,26,30}, perl{5,5.8,5.10}, >>> so it seems reasonable to do the same with ruby. >>> >> >> I don't think it would be a good idea either, but I wasn't sure: >> there's no 'perl' or 'python' ports, but there's a 'ruby'. >> >> So then for consistency's sake, there should be some renames; for example: >> ruby -> ruby18 >> py-* -> py24-* (or to their respective dep, all the ones I've seen are >> depending on python24) >> rb-* -> ruby18-* (perhaps) > > sounds like a lot of work to me for a small gain. you would probably need > an empty "ruby" port with a sole "ruby18" dependency to avoid breaking > all existing ports and installation, and then explain all this to puzzeled > users. and probably the same for all ruby/rb-* ports. So quite some migration > phase. > > but if somebody was willing to drive such an effort I wouldn't opposed > it. we should still probably get quite detailed reasoning about all the > implications for various scenarios and explaintions why it doesn't > break things, before starting. Well, if there's some consensus that it's a good long-term move, and the maintainers don't mind my mucking around, I'm happy to (attempt) the actual portfile changes. I think the steps would be: 1. copy the old portfiles into new ones with just the names changed 2. make the old ones depend on the new ones 3. grep (with a bit more finesse, obviously) the tree to have other ports that depend on the old ones changed over to the new ones 4. wait a while 5. eventually remove the old ones > PS. Please use Reply-All in list discussions, otherwise mails don't make > it to the list. My bad, intended to, sorry... From ryandesign at macports.org Thu Dec 25 18:03:42 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 25 Dec 2008 20:03:42 -0600 Subject: Will ruby19 replace ruby? In-Reply-To: <77e4079b0812251651h78bfab58nde3319e28a9f8cb8@mail.gmail.com> References: <77e4079b0812250230n2f09367fk235f0ef98cdb82c@mail.gmail.com> <5cbbe4ae0812250259v47d5a655u7dab791f4eeeab0@mail.gmail.com> <77e4079b0812250306w187a28f6xd80f863fd4dee0c6@mail.gmail.com> <5cbbe4ae0812250324w4242c5d9v770bc7900ee1cc58@mail.gmail.com> <77e4079b0812251651h78bfab58nde3319e28a9f8cb8@mail.gmail.com> Message-ID: <78603C14-13DC-4D16-9B06-14114E3834C0@macports.org> On Dec 25, 2008, at 18:51, Neil wrote: >>> So then for consistency's sake, there should be some renames; for >>> example: >>> ruby -> ruby18 >>> py-* -> py24-* (or to their respective dep, all the ones I've >>> seen are >>> depending on python24) >>> rb-* -> ruby18-* (perhaps) >> >> sounds like a lot of work to me for a small gain. you would >> probably need >> an empty "ruby" port with a sole "ruby18" dependency to avoid >> breaking >> all existing ports and installation, and then explain all this to >> puzzeled >> users. and probably the same for all ruby/rb-* ports. So quite >> some migration >> phase. >> >> but if somebody was willing to drive such an effort I wouldn't >> opposed >> it. we should still probably get quite detailed reasoning about >> all the >> implications for various scenarios and explaintions why it doesn't >> break things, before starting. > > Well, if there's some consensus that it's a good long-term move, and > the maintainers don't mind my mucking around, I'm happy to (attempt) > the actual portfile changes. > > I think the steps would be: > 1. copy the old portfiles into new ones with just the names changed > 2. make the old ones depend on the new ones If the old-name portfile and the new-name portfile both try to install the same files, this will cause a conflict and MacPorts will not allow both to be installed at the same time. > 3. grep (with a bit more finesse, obviously) the tree to have other > ports that depend on the old ones changed over to the new ones > 4. wait a while > 5. eventually remove the old ones We've had previous discussions about renaming py-* ports to py24-* for consistency and eventually decided against it because it would be a lot of work since MacPorts does not have any feature to help you rename ports or to indicate that one port has been superseded by another. I'm not even sure if a workable method was ever proposed. Consult the archives if you're interested in the whole discussion. I believe it would be a better use of time to first implement a port renaming / port superseding feature in MacPorts base, and only once that has been incorporated into a released version of MacPorts think about mass renaming of ports. Such a feature would be welcome in MacPorts base anyway, because we occasionally have the situation that software changes names and we have to rename a portfile, or sometimes a developer commits a new port for software that we already had a port for, and this goes unnoticed for some time, and later we have to clean it up. From ryandesign at macports.org Fri Dec 26 14:22:51 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 26 Dec 2008 16:22:51 -0600 Subject: [44340] trunk/base/src In-Reply-To: <20081226190842.DD09BA8FB42@beta.macosforge.org> References: <20081226190842.DD09BA8FB42@beta.macosforge.org> Message-ID: <81B77ED8-F7C5-4342-8EA3-900CC94116DE@macports.org> On Dec 26, 2008, at 13:08, gwhitney at macports.org wrote: > Revision: 44340 > http://trac.macports.org/changeset/44340 > Author: gwhitney at macports.org > Date: 2008-12-26 11:08:42 -0800 (Fri, 26 Dec 2008) > Log Message: > ----------- > Fix Ticket #11891 > > After a long hiatus (sorry) I have had a chance to resolve this > outstanding bug. Thank you! :) That's wonderful, I really appreciate it. Could you add a note to the ChangeLog too? From jmr at macports.org Fri Dec 26 16:04:31 2008 From: jmr at macports.org (Joshua Root) Date: Sat, 27 Dec 2008 11:04:31 +1100 Subject: [43775] trunk/dports/audio/mpg123/Portfile In-Reply-To: <0EB53A32-96AC-4078-AA14-334CE724D19C@macports.org> References: <20081214211712.2C2E894059B@beta.macosforge.org> <0EB53A32-96AC-4078-AA14-334CE724D19C@macports.org> Message-ID: <4955710F.3000008@macports.org> Ryan Schmidt wrote: > > On Dec 14, 2008, at 15:17, jmr at macports.org wrote: > >> Revision: 43775 >> http://trac.macports.org/changeset/43775 >> Author: jmr at macports.org >> Date: 2008-12-14 13:17:09 -0800 (Sun, 14 Dec 2008) >> Log Message: >> ----------- >> mpg123: platform 'powerpc' -> 'ppc' >> >> Modified Paths: >> -------------- >> trunk/dports/audio/mpg123/Portfile >> >> Modified: trunk/dports/audio/mpg123/Portfile >> =================================================================== >> --- trunk/dports/audio/mpg123/Portfile 2008-12-14 18:52:09 UTC (rev >> 43774) >> +++ trunk/dports/audio/mpg123/Portfile 2008-12-14 21:17:09 UTC (rev >> 43775) >> @@ -27,6 +27,6 @@ >> configure.args-append --with-cpu=x86 >> } >> >> -platform macosx powerpc { >> +platform macosx ppc { >> configure.args-append --with-cpu=altivec >> } > > > We have 60 occurrences of something like "platform powerpc" in the ports > tree and only 8 occurrences of something like "platform ppc"...... Do > both work? The Guide only shows "powerpc". > > http://guide.macports.org/#reference.variants.platform You're right, powerpc is correct, ppc is not. The change was motivated by the fact that the macosx_powerpc variant was not being selected on a ppc machine. However, it turns out that the actual problem is that 'platform $plat $arch' doesn't get selected automatically when $plat is not the same as ${os.platform}. This currently applies to macosx and puredarwin. The issue was clouded a little by the fact that 'platform $plat' does get selected in the same situation because there are some special cases in portmain.tcl. - Josh From mp+d at v6shell.org Sat Dec 27 12:39:33 2008 From: mp+d at v6shell.org (J.A. Neitzel) Date: Sat, 27 Dec 2008 20:39:33 +0000 Subject: Question about shells/osh/Portfile patch Message-ID: <49569285.0lrLyAWYo2VtXz/s%mp+d@v6shell.org> Hello, Before submitting a patch via Trac Ticket to make my osh port use "use_parallel_build yes" according to Ryan Schmidt's "Encouraging ports to include use_parallel_build" [1], should I go ahead and remove the following lines in the patch: # NOTE: INSTALL=... can be removed after MacPorts 1.7 is released. destroot.env INSTALL=${configure.install} ? NOTE: Removing the destroot.env line breaks installation of the osh port under MacPorts 1.6 because of something related to the old TCL env bug. Cheers, Jeff [1]: http://lists.macosforge.org/pipermail/macports-dev/2008-December/006768.html From blb at macports.org Sat Dec 27 13:04:00 2008 From: blb at macports.org (Bryan Blackburn) Date: Sat, 27 Dec 2008 14:04:00 -0700 Subject: Question about shells/osh/Portfile patch In-Reply-To: <49569285.0lrLyAWYo2VtXz/s%mp+d@v6shell.org> References: <49569285.0lrLyAWYo2VtXz/s%mp+d@v6shell.org> Message-ID: <20081227210400.GE1291@ninagal.withay.com> On Sat, Dec 27, 2008 at 08:39:33PM +0000, J.A. Neitzel said: > Hello, > > Before submitting a patch via Trac Ticket to make my osh port use > "use_parallel_build yes" according to Ryan Schmidt's "Encouraging > ports to include use_parallel_build" [1], should I go ahead and > remove the following lines in the patch: > > # NOTE: INSTALL=... can be removed after MacPorts 1.7 is released. > destroot.env INSTALL=${configure.install} > > ? > > NOTE: Removing the destroot.env line breaks installation of the osh > port under MacPorts 1.6 because of something related to the old TCL > env bug. Definitely, 1.7 has been out for a couple of weeks now and we really want people moving to it, because of all the bug fixes, workarounds, etc (including the Tcl env bug mentioned there). A number of ports that had 1.6-based workarounds have already had those workarounds removed, so this won't be the first one. Bryan > > Cheers, > Jeff > > [1]: > http://lists.macosforge.org/pipermail/macports-dev/2008-December/006768.html From mp+d at v6shell.org Sat Dec 27 14:19:15 2008 From: mp+d at v6shell.org (J.A. Neitzel) Date: Sat, 27 Dec 2008 22:19:15 +0000 Subject: Question about shells/osh/Portfile patch In-Reply-To: <20081227210400.GE1291@ninagal.withay.com> References: <49569285.0lrLyAWYo2VtXz/s%mp+d@v6shell.org> <20081227210400.GE1291@ninagal.withay.com> Message-ID: <4956a9e3.X71196P+VZMAF55/%mp+d@v6shell.org> Bryan Blackburn wrote: > On Sat, Dec 27, 2008 at 08:39:33PM +0000, J.A. Neitzel said: > > Hello, > > > > Before submitting a patch via Trac Ticket to make my osh port use > > "use_parallel_build yes" according to Ryan Schmidt's "Encouraging > > ports to include use_parallel_build" [1], should I go ahead and > > remove the following lines in the patch: > > > > # NOTE: INSTALL=... can be removed after MacPorts 1.7 is released. > > destroot.env INSTALL=${configure.install} > > > > ? > > > > NOTE: Removing the destroot.env line breaks installation of the osh > > port under MacPorts 1.6 because of something related to the old TCL > > env bug. > Definitely, 1.7 has been out for a couple of weeks now and we really want > people moving to it, because of all the bug fixes, workarounds, etc > (including the Tcl env bug mentioned there). > > A number of ports that had 1.6-based workarounds have already had those > workarounds removed, so this won't be the first one. ACK .. Ticket #17797 submitted .. Thanks, Jeff > Bryan From jeremyhu at macports.org Sun Dec 28 00:58:45 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 28 Dec 2008 00:58:45 -0800 Subject: Forcing Macports libs for X11 (Was Re: Error installing xpdf with openmotif) In-Reply-To: <0347CEA0-D11C-4632-BD2D-946DE3736D03@macports.org> References: <1229851171.494e0a23ad995@imp.free.fr> <0347CEA0-D11C-4632-BD2D-946DE3736D03@macports.org> Message-ID: <09232944-71BB-416F-A310-61039C6321BF@macports.org> This thread really should be on -dev, so I'm moving it here... >> If Xft2 in ${x11prefix} gets confused by using freetype in $ >> {prefix} then we should be using Xft2 in ${prefix}, which I would >> think we should be doing anyway because it's newer too. > > Well then where do you draw the line? Should we start forcing > libX11 in macports because it's newer? I'd be all for forcing > Macports X11 libs over system X11 libs, since it would throw all of > these issues (.la-fu, dependencies pulling in conflicting libX11s > (#17558), header-mixup-fu, ...) out the window! I'm sorry if this starts a major flame war, but this needs to be brought up. Mixing system and macports libs for X11 causes too many problems. Here are the two that stand out in my head most: http://trac.macports.org/ticket/17558 http://trac.macports.org/ticket/17631 Additionally, ignoring the system libs would allow us to get past the "bad .la files" bugs in X11SDK: http://trac.macports.org/ticket/17356 etc Changing the X11 policy to use port:* dependencies for X11 libs will allow us to control these variables and eliminate a major headache. Furthermore, I suggest we create a +system_x11 variant to all of the X11 lib packages which would cause them to just be stubs, so people could continue to use their system X11 by enabling that variant... >> But in r43207 you changed the port, Jeremy, from requiring the >> MacPorts Xft2 to accepting an Xft2 in ${x11prefix}. I do have the >> Xft2 port installed. Do you, "spam.spam.spam.spam", or are you >> using Xft2 in ${x11prefix}? > > Everything that I changed from using port:Xft2 to lib:libXft:Xft2 > (including openmotif), I tested with no Xft2 port installed on both > Tiger and Leopard. > > Unfortunately, I don't have my Tiger box with me over holiday, so I > can't be much help with this right now, but I'll be able to diagnose > it further next week. I just tested this on my Tiger box with macports freetype installed and no macports Xft2 installed, and it compiled fine for me. I bzip2'd the compile log and attached it to the report if you would like to compare (http://trac.macports.org/ticket/17631) --Jeremy From ryandesign at macports.org Sun Dec 28 01:36:22 2008 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 28 Dec 2008 03:36:22 -0600 Subject: Forcing Macports libs for X11 (Was Re: Error installing xpdf with openmotif) In-Reply-To: <09232944-71BB-416F-A310-61039C6321BF@macports.org> References: <1229851171.494e0a23ad995@imp.free.fr> <0347CEA0-D11C-4632-BD2D-946DE3736D03@macports.org> <09232944-71BB-416F-A310-61039C6321BF@macports.org> Message-ID: On Dec 28, 2008, at 02:58, Jeremy Huddleston wrote: > This thread really should be on -dev, so I'm moving it here... > >>> If Xft2 in ${x11prefix} gets confused by using freetype in $ >>> {prefix} then we should be using Xft2 in ${prefix}, which I would >>> think we should be doing anyway because it's newer too. >> >> Well then where do you draw the line? Should we start forcing >> libX11 in macports because it's newer? I'd be all for forcing >> Macports X11 libs over system X11 libs, since it would throw all >> of these issues (.la-fu, dependencies pulling in conflicting >> libX11s (#17558), header-mixup-fu, ...) out the window! > > I'm sorry if this starts a major flame war, but this needs to be > brought up. Mixing system and macports libs for X11 causes too many > problems. By all means! We should figure this situation out. I came to MacPorts after this decision was already in place. But it seemed like a good decision to me because Apple's X11.app worked well on Tiger and the alternative provided by the XFree86 port had some oddities. I never tried the xorg variety. In any case you could only choose to have one of the three because they all installed to ${x11prefix}. I think you're now changing it so xorg installs in ${prefix}, so it xorg could coexist with Apple X11? Will using xorg mean I would open an xorg-provided X11 app instead of Apple's X11.app, and if so, would it work the same as Apple's? > Here are the two that stand out in my head most: > > http://trac.macports.org/ticket/17558 > http://trac.macports.org/ticket/17631 > > Additionally, ignoring the system libs would allow us to get past > the "bad .la files" bugs in X11SDK: > http://trac.macports.org/ticket/17356 etc > > Changing the X11 policy to use port:* dependencies for X11 libs > will allow us to control these variables and eliminate a major > headache. > > Furthermore, I suggest we create a +system_x11 variant to all of > the X11 lib packages which would cause them to just be stubs, so > people could continue to use their system X11 by enabling that > variant... From blb at macports.org Sun Dec 28 01:51:32 2008 From: blb at macports.org (Bryan Blackburn) Date: Sun, 28 Dec 2008 02:51:32 -0700 Subject: Forcing Macports libs for X11 (Was Re: Error installing xpdf with openmotif) In-Reply-To: <09232944-71BB-416F-A310-61039C6321BF@macports.org> References: <1229851171.494e0a23ad995@imp.free.fr> <0347CEA0-D11C-4632-BD2D-946DE3736D03@macports.org> <09232944-71BB-416F-A310-61039C6321BF@macports.org> Message-ID: <20081228095132.GK1291@ninagal.withay.com> On Sun, Dec 28, 2008 at 12:58:45AM -0800, Jeremy Huddleston said: > This thread really should be on -dev, so I'm moving it here... > >>> If Xft2 in ${x11prefix} gets confused by using freetype in ${prefix} >>> then we should be using Xft2 in ${prefix}, which I would think we >>> should be doing anyway because it's newer too. >> >> Well then where do you draw the line? Should we start forcing libX11 in >> macports because it's newer? I'd be all for forcing Macports X11 libs >> over system X11 libs, since it would throw all of these issues (.la-fu, >> dependencies pulling in conflicting libX11s (#17558), header-mixup-fu, >> ...) out the window! > > I'm sorry if this starts a major flame war, but this needs to be brought > up. Mixing system and macports libs for X11 causes too many problems. > Here are the two that stand out in my head most: Then my question is can we cleanly build a full X11 out of MacPorts currently? Or are you not referring to all X11 libs, like libX11.6? [...] > > Furthermore, I suggest we create a +system_x11 variant to all of the X11 > lib packages which would cause them to just be stubs, so people could > continue to use their system X11 by enabling that variant... Wouldn't that then get right back to your point of moving away from it in the first place? Many people probably would prefer to use that variant to avoid building "unnecessary dependencies" so we'd end up back to the current situation. Bryan [...] > > --Jeremy > From jeremyhu at macports.org Sun Dec 28 02:09:05 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 28 Dec 2008 02:09:05 -0800 Subject: Forcing Macports libs for X11 (Was Re: Error installing xpdf with openmotif) In-Reply-To: References: <1229851171.494e0a23ad995@imp.free.fr> <0347CEA0-D11C-4632-BD2D-946DE3736D03@macports.org> <09232944-71BB-416F-A310-61039C6321BF@macports.org> Message-ID: On Dec 28, 2008, at 01:36, Ryan Schmidt wrote: > > On Dec 28, 2008, at 02:58, Jeremy Huddleston wrote: >> I'm sorry if this starts a major flame war, but this needs to be >> brought up. Mixing system and macports libs for X11 causes too many >> problems. > > > By all means! We should figure this situation out. I came to > MacPorts after this decision was already in place. But it seemed > like a good decision to me because Apple's X11.app worked well on > Tiger and the alternative provided by the XFree86 port had some > oddities. I never tried the xorg variety. In any case you could only > choose to have one of the three because they all installed to $ > {x11prefix}. > > I think you're now changing it so xorg installs in ${prefix}, so it > xorg could coexist with Apple X11? Yeah... in fact you can 'sudo port install xorg-server' and get a brand new /Applications/Macports/X11.app with libs and such in $ {prefix} ... the only caveats that I know of right now with this are: 1) The "mixing" problems referenced below 2) You still need the "Apple" X11 installed in ${x11prefix} since we use their fonts (I haven't gotten around to making the xorg-font-* ports yet) > Will using xorg mean I would open an xorg-provided X11 app instead > of Apple's X11.app, and if so, would it work the same as Apple's? I haven't touched the 'xorg' port itself... it's still antiquated... but I think it should become a meta-package for xorg-server and the expected "base" X11 applications. As for the xorg-server port itself, it creates almost the same X11.app as provided by http://xquartz.macosforge.org ... thus it does work the same as "Apple's" because it is Apple's... the only difference on Leopard is that it doesn't use the launchd startup mechanism (I didn't want to deal with conflit issues between the macports and "official" X11.app LaunchAgents for that...) >> Here are the two that stand out in my head most: >> >> http://trac.macports.org/ticket/17558 >> http://trac.macports.org/ticket/17631 >> >> Additionally, ignoring the system libs would allow us to get past >> the "bad .la files" bugs in X11SDK: >> http://trac.macports.org/ticket/17356 etc >> >> Changing the X11 policy to use port:* dependencies for X11 libs >> will allow us to control these variables and eliminate a major >> headache. >> >> Furthermore, I suggest we create a +system_x11 variant to all of >> the X11 lib packages which would cause them to just be stubs, so >> people could continue to use their system X11 by enabling that >> variant... From jeremyhu at macports.org Sun Dec 28 02:18:32 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 28 Dec 2008 02:18:32 -0800 Subject: Forcing Macports libs for X11 (Was Re: Error installing xpdf with openmotif) In-Reply-To: <20081228095132.GK1291@ninagal.withay.com> References: <1229851171.494e0a23ad995@imp.free.fr> <0347CEA0-D11C-4632-BD2D-946DE3736D03@macports.org> <09232944-71BB-416F-A310-61039C6321BF@macports.org> <20081228095132.GK1291@ninagal.withay.com> Message-ID: On Dec 28, 2008, at 01:51, Bryan Blackburn wrote: >> I'm sorry if this starts a major flame war, but this needs to be >> brought >> up. Mixing system and macports libs for X11 causes too many >> problems. >> Here are the two that stand out in my head most: > > Then my question is can we cleanly build a full X11 out of MacPorts > currently? Yeah... as for a server, do 'sudo port -v install xorg-server' ... There might be a couple libs that aren't yet (just because I haven't audited the list to make sure they're all here... but all the common ones are). The main packages not in Macports yet are fonts and base applications (xdpyinfo, xset, etc...) >> Furthermore, I suggest we create a +system_x11 variant to all of >> the X11 >> lib packages which would cause them to just be stubs, so people could >> continue to use their system X11 by enabling that variant... > > Wouldn't that then get right back to your point of moving away from > it in > the first place? Not exactly. The main problem we're facing is when some libs link against ${prefix}/lib/libX11.dylib and other libs link against $ {prefix}/lib/libX11.dylib ... this variant would work around that problem (assuming the user doesn't toggle the variant at some point without rebuilding dependent packages) because it would force all libs and executables we install to link against the same lib. From raimue at macports.org Sun Dec 28 04:18:28 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 28 Dec 2008 13:18:28 +0100 Subject: Forcing Macports libs for X11 (Was Re: Error installing xpdf with openmotif) In-Reply-To: References: <1229851171.494e0a23ad995@imp.free.fr> <0347CEA0-D11C-4632-BD2D-946DE3736D03@macports.org> <09232944-71BB-416F-A310-61039C6321BF@macports.org> <20081228095132.GK1291@ninagal.withay.com> Message-ID: <49576E94.10700@macports.org> Jeremy Huddleston wrote: > Yeah... as for a server, do 'sudo port -v install xorg-server' ... > There might be a couple libs that aren't yet (just because I haven't > audited the list to make sure they're all here... but all the common > ones are). The main packages not in Macports yet are fonts and base > applications (xdpyinfo, xset, etc...) Jeremy, first of all you are doing a great job with xorg in MacPorts! But if we want to use xorg-server, we would have to manually export DISPLAY. Or we would have to disable system's X11 in launchd and create our own .plist, right? Rainer From raimue at macports.org Sun Dec 28 12:14:09 2008 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 28 Dec 2008 21:14:09 +0100 Subject: [43783] trunk/base/src/port1.0/portconfigure.tcl In-Reply-To: <01746DD5-C427-47A8-8EF6-578248970B23@macports.org> References: <20081215031844.1E126952F83@beta.macosforge.org> <87D2DB80-9DB7-41CB-8655-EED8A675B1F4@macports.org> <49538BC4.6020907@macports.org> <01746DD5-C427-47A8-8EF6-578248970B23@macports.org> Message-ID: <4957DE11.4000108@macports.org> Ryan Schmidt wrote: >> You are right, this might pull in unnecessary dependencies. Should we >> remove the dependency if autoconf.cmd is not the default value and it >> has to be declared in the port itself? > > Do we know how to do that? That sounds ideal. I added a preliminary patch in ticket #17809 [1]. It adds hooks which get executed when you specify autoconf.cmd and remove the dependency if it was set before. The hook for use_autoconf was extended so now it checks if autoconf.cmd is the default or if it was set before. Same applies for use_{autoreconf,automake,xmkmf}. It is not ideal yet. If the Portfile already has something like 'depends_build port:autoconf' in it, deps still get modified. This could happen if the port author intended to explicitly use autoconf from MacPorts, but it still adds 'depends_build bin:autoconf:autoconf' which duplicates this dependency. Any thoughts how to avoid that? I don't want to add too much of such logic at that place in port1.0 as it slows down parsing the Portfile. What do other base hackers think about this? Rainer [1] http://trac.macports.org/ticket/17809 From jeremyhu at macports.org Sun Dec 28 12:56:30 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 28 Dec 2008 12:56:30 -0800 Subject: Forcing Macports libs for X11 (Was Re: Error installing xpdf with openmotif) In-Reply-To: <49576E94.10700@macports.org> References: <1229851171.494e0a23ad995@imp.free.fr> <0347CEA0-D11C-4632-BD2D-946DE3736D03@macports.org> <09232944-71BB-416F-A310-61039C6321BF@macports.org> <20081228095132.GK1291@ninagal.withay.com> <49576E94.10700@macports.org> Message-ID: <4CDD2F62-475C-4809-85BF-1D7429D68237@macports.org> On Dec 28, 2008, at 04:18, Rainer M?ller wrote: > Jeremy Huddleston wrote: >> Yeah... as for a server, do 'sudo port -v install xorg-server' ... >> There might be a couple libs that aren't yet (just because I haven't >> audited the list to make sure they're all here... but all the common >> ones are). The main packages not in Macports yet are fonts and base >> applications (xdpyinfo, xset, etc...) > > Jeremy, first of all you are doing a great job with xorg in MacPorts! > > But if we want to use xorg-server, we would have to manually export > DISPLAY. Or we would have to disable system's X11 in launchd and > create > our own .plist, right? Pretty much. The Macports X11.app behaves like the old Tiger X11.app in that it doesn't interact with launchd at all. In fact, there's code in xorg-server which specifically unsets the DISPLAY environment variable at startup if the CFBundleIdentifier is not org.x.X11 to avoid conflict (meaning the launchd DISPLAY environment variable is used *ONLY* by the org.x.X11 X11.app). Thus if you want to use the Macports X11.app instead of Leopard's with launchd, I'd recommend doing (you NEED to be on 10.5.5 or later to have the right LaunchAgent plist): # Not tested or guaranteed to be typo-free gsed -i 's:org.x.X11:org.x.X11Leopard:g' /Applications/Utilities/ X11.app/Contents/Info.plist gsed -i 's:org.macports.X11:org.x.X11:g' /Applications/MacPorts/ X11.app/Contents/Info.plist --- But if you don't care about the launchd support, it will work as-is. Applications started within /A*/MacPorts/X11.app will have the appropriate DISPLAY set for that server. From blb at macports.org Sun Dec 28 20:31:18 2008 From: blb at macports.org (Bryan Blackburn) Date: Sun, 28 Dec 2008 21:31:18 -0700 Subject: [44465] trunk/dports/x11/bitmap/Portfile In-Reply-To: <20081229033231.4A31FAB9364@beta.macosforge.org> References: <20081229033231.4A31FAB9364@beta.macosforge.org> Message-ID: <20081229043118.GB1138@ninagal.withay.com> On Sun, Dec 28, 2008 at 07:32:31PM -0800, jeremyhu at macports.org said: > Revision: 44465 > http://trac.macports.org/changeset/44465 > Author: jeremyhu at macports.org > Date: 2008-12-28 19:32:30 -0800 (Sun, 28 Dec 2008) > Log Message: > ----------- > bitmap: Simplified dependencies > > Modified Paths: > -------------- > trunk/dports/x11/bitmap/Portfile > > Modified: trunk/dports/x11/bitmap/Portfile > =================================================================== > --- trunk/dports/x11/bitmap/Portfile 2008-12-29 03:30:17 UTC (rev 44464) > +++ trunk/dports/x11/bitmap/Portfile 2008-12-29 03:32:30 UTC (rev 44465) > @@ -20,10 +20,8 @@ > > depends_build port:pkgconfig > > -depends_lib lib:libX11.6:xorg-libX11 lib:libXt:xorg-libXt \ > - lib:libXmu:xorg-libXmu lib:libSM:xorg-libsm \ > - lib:libXaw:xorg-libXaw lib:libXp:xorg-libXp \ > - lib:libXpm:xpm > +depends_lib \ > + lib:libXaw:xorg-libXaw >From a just-MacPorts point of view, I think we still need xorg-libXp since xorg-libXaw won't otherwise bring that one in; using 'port-rdeps -r xorg-libXaw' [1]: Dependencies of xorg-libXaw: xorg-libsm xorg-libice pkgconfig xorg-xproto bzip2 xorg-xtrans xorg-libXext xorg-libX11 xorg-libXdmcp xorg-libXau xorg-bigreqsproto xorg-xcmiscproto xorg-xextproto xorg-xf86bigfontproto xorg-inputproto xorg-kbproto xorg-libXmu xorg-libXt xpm Bryan [1] - From jeremyhu at macports.org Sun Dec 28 20:38:39 2008 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 28 Dec 2008 20:38:39 -0800 Subject: [44465] trunk/dports/x11/bitmap/Portfile In-Reply-To: <20081229043118.GB1138@ninagal.withay.com> References: <20081229033231.4A31FAB9364@beta.macosforge.org> <20081229043118.GB1138@ninagal.withay.com> Message-ID: Right, that would be true if bitmap actually used libXp, but it doesn't: /opt/local/bin/bitmap: /usr/X11/lib/libXaw.7.dylib (compatibility version 8.0.0, current version 8.0.0) /usr/X11/lib/libXpm.4.dylib (compatibility version 16.0.0, current version 16.0.0) /usr/X11/lib/libXmu.6.dylib (compatibility version 9.0.0, current version 9.0.0) /opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0) /opt/local/lib/libXt.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/local/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0) /opt/local/lib/libSM.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/local/lib/libXau.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/local/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/local/lib/libICE.6.dylib (compatibility version 10.0.0, current version 10.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) You are seeing libXp because you are using /usr/X11/lib/libXaw.8.dylib which uses libXp. On Dec 28, 2008, at 20:31, Bryan Blackburn wrote: > On Sun, Dec 28, 2008 at 07:32:31PM -0800, jeremyhu at macports.org said: >> Revision: 44465 >> http://trac.macports.org/changeset/44465 >> Author: jeremyhu at macports.org >> Date: 2008-12-28 19:32:30 -0800 (Sun, 28 Dec 2008) >> Log Message: >> ----------- >> bitmap: Simplified dependencies >> >> Modified Paths: >> -------------- >> trunk/dports/x11/bitmap/Portfile >> >> Modified: trunk/dports/x11/bitmap/Portfile >> =================================================================== >> --- trunk/dports/x11/bitmap/Portfile 2008-12-29 03:30:17 UTC (rev >> 44464) >> +++ trunk/dports/x11/bitmap/Portfile 2008-12-29 03:32:30 UTC (rev >> 44465) >> @@ -20,10 +20,8 @@ >> >> depends_build port:pkgconfig >> >> -depends_lib lib:libX11.6:xorg-libX11 lib:libXt:xorg-libXt \ >> - lib:libXmu:xorg-libXmu lib:libSM:xorg-libsm \ >> - lib:libXaw:xorg-libXaw lib:libXp:xorg-libXp \ >> - lib:libXpm:xpm >> +depends_lib \ >> + lib:libXaw:xorg-libXaw > > From a just-MacPorts point of view, I think we still need xorg-libXp > since > xorg-libXaw won't otherwise bring that one in; using 'port-rdeps -r > xorg-libXaw' [1]: > > Dependencies of xorg-libXaw: > xorg-libsm > xorg-libice > pkgconfig > xorg-xproto > bzip2 > xorg-xtrans > xorg-libXext > xorg-libX11 > xorg-libXdmcp > xorg-libXau > xorg-bigreqsproto > xorg-xcmiscproto > xorg-xextproto > xorg-xf86bigfontproto > xorg-inputproto > xorg-kbproto > xorg-libXmu > xorg-libXt > xpm > > Bryan > > [1] - > From blb at macports.org Sun Dec 28 20:55:41 2008 From: blb at macports.org (Bryan Blackburn) Date: Sun, 28 Dec 2008 21:55:41 -0700 Subject: [44465] trunk/dports/x11/bitmap/Portfile In-Reply-To: References: <20081229033231.4A31FAB9364@beta.macosforge.org> <20081229043118.GB1138@ninagal.withay.com> Message-ID: <20081229045541.GD1138@ninagal.withay.com> On Sun, Dec 28, 2008 at 08:38:39PM -0800, Jeremy Huddleston said: > Right, that would be true if bitmap actually used libXp, but it doesn't: [...] > You are seeing libXp because you are using /usr/X11/lib/libXaw.8.dylib > which uses libXp. Oops, my first building of the dep-list was based on otool output prior to adding the --disable-xprint, so yeah it did link to XAW8 then. The install as it is now, it doesn't use libXp, so you're right, no need for it. I should probably finalize the dep list after I have it linking to things only in ${prefix} instead of one step at a time... Bryan [...] From wsiegrist at apple.com Mon Dec 29 01:42:46 2008 From: wsiegrist at apple.com (William Siegrist) Date: Mon, 29 Dec 2008 01:42:46 -0800 Subject: [MacPorts] #14062: Website does not render properly in IE7 In-Reply-To: <91F4D6C7-A9B6-47BE-9DC7-F3FB01657912@bikemonkey.org> References: <055.9b1b96888da488b10a2b6dab3bb48419@macports.org> <064.6777689a33ae965fba656f9c04faca6a@macports.org> <20154919-3961-424E-94E9-A5C9BE6C7674@macports.org> <1D77EA76-719B-4E42-826C-D593CF5A3601@apple.com> <58372AE9-93B1-464C-B17E-9C1730954B05@macports.org> <59E072C9-E457-4F75-8E4A-7642E7C592E6@apple.com> <91F4D6C7-A9B6-47BE-9DC7-F3FB01657912@bikemonkey.org> Message-ID: <2B2D7F30-C36C-41B1-89F9-C4BCD1140BD9@apple.com> On Dec 28, 2008, at 9:13 PM, Landon Fuller wrote: >>>> >>> That article, written in September 2006, basically says forget >>> XHTML and use HTML 4. Is that still the best advice today, over 2 >>> years later? If so, I am given to wonder why we have the XHTML >>> standard in the first place, if browser vendors recommend not >>> using it. >>> >>> >> >> Yes, its still valid due to browsers not behaving correctly with >> the xml tags and the application/xhtml+xml content type. The >> following pages are served as HTML 4.01: >> >> http://webkit.org/ >> http://mozilla.org/ >> >> These are served as XHTML 1.0, which doesnt have the leading xml >> tag, and they use an html content type, which is technically wrong >> but it makes browsers handle it better: >> >> http://microsoft.com/ >> http://opera.com/ >> >> So if the browser vendors are not using XHTML 1.1, why are we going >> through all this trouble? > > While I worked at Three Rings, we moved all of Puzzle Pirates (www.puzzlepirates.com > ) to XHTML 1.0 without any issues -- and we had a very sizable IE- > using customer base. > > The reason that we did this is simple -- XHTML being well formed > XML, it is easily parsed, and and is easily validated. Our > translation system was implemented using XML tags () and > we were able to do a combination of runtime processing using JSPX > (templates defined with server-side custom XML tags), and build-time > processing using XML-based tools. Adding new XML tags wound up being > a very clean approach that our web designers quickly understood -- > and really liked (especially since they could write their own custom > tags very easily, too). > > The document processing also inherently validated document "well- > formedness". > > This was all done without any notable headaches incurred in serving > "tag soup" to IE users. We stuck to XHTML 1.0, and followed the > informative guidelines at http://www.w3.org/TR/xhtml1/#guidelines . > I thought we might have to translate the XHTML to normative HTML4 > content, but it was never necessary. > > So if I may be bold, arguments against XHTML simply do not consider > the potential value in having a document format that is both readily > extensible and parseable. Even dealing with XML is better than > implementing tools to safely and reproducibly parse (and modify) tag > soup. > > My two cents =) > Landon I believe there is a big difference between XHTML 1.0 and 1.1 when dealing with IE compatibility. Mac OS Forge uses a lot of XHTML 1.0 for Trac templates (Genshi), which is similar to your use of it for server side processing. My main point was that the MacPorts website was simple enough to be HTML4 and would be the least effort. XHTML 1.0 would be fine, especially if we want to localize it or use templates. Basically, I'm suggesting using anything but XHTML 1.1. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available URL: From jmpp at macports.org Mon Dec 29 23:39:37 2008 From: jmpp at macports.org (Juan Manuel Palacios) Date: Tue, 30 Dec 2008 03:09:37 -0430 Subject: [MacPorts] #14062: Website does not render properly in IE7 In-Reply-To: <2B2D7F30-C36C-41B1-89F9-C4BCD1140BD9@apple.com> References: <055.9b1b96888da488b10a2b6dab3bb48419@macports.org> <064.6777689a33ae965fba656f9c04faca6a@macports.org> <20154919-3961-424E-94E9-A5C9BE6C7674@macports.org> <1D77EA76-719B-4E42-826C-D593CF5A3601@apple.com> <58372AE9-93B1-464C-B17E-9C1730954B05@macports.org> <59E072C9-E457-4F75-8E4A-7642E7C592E6@apple.com> <91F4D6C7-A9B6-47BE-9DC7-F3FB01657912@bikemonkey.org> <2B2D7F30-C36C-41B1-89F9-C4BCD1140BD9@apple.com> Message-ID: On Dec 29, 2008, at 5:12 AM, William Siegrist wrote: > > > I believe there is a big difference between XHTML 1.0 and 1.1 when > dealing with IE compatibility. Mac OS Forge uses a lot of XHTML 1.0 > for Trac templates (Genshi), which is similar to your use of it for > server side processing. My main point was that the MacPorts website > was simple enough to be HTML4 and would be the least effort. XHTML > 1.0 would be fine, especially if we want to localize it or use > templates. > > Basically, I'm suggesting using anything but XHTML 1.1. > As the author of a fair bit of the website code, I can safely say (even though it might inspire some people around here to lynch me) that I had no real compelling reason to use xhtml 1.1, other than not exactly remembering the exact dtd line and copy&paste'ing it from another doc I was editing at the moment. Other than that, I could hardly say there's anything on that site that strictly requires 1.1, so I'm confident "downgrading" to xhtml 1.0 wont be a problem at all if it'll clear out some of these headaches. My two cents, in turn... -jmpp From jm at poure.com Tue Dec 30 01:27:17 2008 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Tue, 30 Dec 2008 10:27:17 +0100 Subject: Kdenlive 0.7.1 and MLT 0.3.3 are out Message-ID: <1230629237.7652.7.camel@debian> New releases of MLT and Kdenlive have been published. We hope that MacOsX users can benefit from the pure Unix video editor, so that there is more choice for the end user :) From wsiegrist at apple.com Tue Dec 30 09:58:43 2008 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 30 Dec 2008 09:58:43 -0800 Subject: [MacPorts] #14062: Website does not render properly in IE7 In-Reply-To: References: <055.9b1b96888da488b10a2b6dab3bb48419@macports.org> <064.6777689a33ae965fba656f9c04faca6a@macports.org> <20154919-3961-424E-94E9-A5C9BE6C7674@macports.org> <1D77EA76-719B-4E42-826C-D593CF5A3601@apple.com> <58372AE9-93B1-464C-B17E-9C1730954B05@macports.org> <59E072C9-E457-4F75-8E4A-7642E7C592E6@apple.com> <91F4D6C7-A9B6-47BE-9DC7-F3FB01657912@bikemonkey.org> <2B2D7F30-C36C-41B1-89F9-C4BCD1140BD9@apple.com> Message-ID: On Dec 29, 2008, at 11:39 PM, Juan Manuel Palacios wrote: > > On Dec 29, 2008, at 5:12 AM, William Siegrist wrote: > >> >> >> I believe there is a big difference between XHTML 1.0 and 1.1 when >> dealing with IE compatibility. Mac OS Forge uses a lot of XHTML 1.0 >> for Trac templates (Genshi), which is similar to your use of it for >> server side processing. My main point was that the MacPorts website >> was simple enough to be HTML4 and would be the least effort. XHTML >> 1.0 would be fine, especially if we want to localize it or use >> templates. >> >> Basically, I'm suggesting using anything but XHTML 1.1. >> > > As the author of a fair bit of the website code, I can safely say > (even though it might inspire some people around here to lynch me) > that I had no real compelling reason to use xhtml 1.1, other than > not exactly remembering the exact dtd line and copy&paste'ing it > from another doc I was editing at the moment. Other than that, I > could hardly say there's anything on that site that strictly > requires 1.1, so I'm confident "downgrading" to xhtml 1.0 wont be a > problem at all if it'll clear out some of these headaches. > > My two cents, in turn... > > Okay, as the server admin, I do not really care which one you use. I'll support your choice with whatever headers you need the server to produce. Just let me know if anything needs to change on the backend. (Apache should be able to handle the browser-specific mime types for you if that would help). -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2421 bytes Desc: not available URL: From mcalhoun at macports.org Tue Dec 30 22:57:20 2008 From: mcalhoun at macports.org (Marcus Calhoun-Lopez) Date: Wed, 31 Dec 2008 06:57:20 +0000 (UTC) Subject: Moving the location of a port Message-ID: The package qtoctave-mac is located in x11 with categories x11 math. Since it does not use X11 in any way, it seems to me it would be better to place it in in aqua with categories aqua math. Does renaming a directory cause any problems with MacPorts (svn mv x11/qtoctave-mac aqua/)? -Marcus From blb at macports.org Tue Dec 30 23:19:32 2008 From: blb at macports.org (Bryan Blackburn) Date: Wed, 31 Dec 2008 00:19:32 -0700 Subject: Moving the location of a port In-Reply-To: References: Message-ID: <20081231071932.GJ651@ninagal.withay.com> On Wed, Dec 31, 2008 at 06:57:20AM +0000, Marcus Calhoun-Lopez said: > The package qtoctave-mac is located in x11 with categories x11 math. > Since it does not use X11 in any way, it seems to me it would be > better to place it in in aqua with categories aqua math. > > Does renaming a directory cause any problems with MacPorts > (svn mv x11/qtoctave-mac aqua/)? I think it'll only have problems during that <= hour when the location doesn't agree with what's in PortIndex, otherwise it should be fine. Bryan > > -Marcus From akitada at macports.org Wed Dec 31 02:14:45 2008 From: akitada at macports.org (Akira Kitada) Date: Wed, 31 Dec 2008 19:14:45 +0900 Subject: Restructuring Python ports? Message-ID: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com> Folks, As noted in FAQ [1], 'A number of "standard python modules" are built separately from the python25 port' and which have been causing difficulty maintaining/using Python with MacPorts. The document says "People with a FreeBSD background will find themselves familiar with this schema.", but I have my doubt on this. Just look at FreeBSD Ports Search.[2] There is no py25-zlib. There is not py25-hashlib, and so on. These modules are essential to Python, so without these modules, it cannot work so well. So I would like to propose a reform of Python ports to brihg these essential ports back to python port itself, or at least add these moduels to the list of its dependencies, and make it more usable and user-friendly. Any thoughts? [1] MacPorts FAQ: Why can't I import foo in Python 2.5? http://trac.macports.org/wiki/FAQ#WhycantIimportfooinPython2.5 [2] About FreeBSD Ports http://www.freebsd.org/ports/ From Ian.Grant at cl.cam.ac.uk Wed Dec 31 05:18:09 2008 From: Ian.Grant at cl.cam.ac.uk (Ian Grant) Date: Wed, 31 Dec 2008 13:18:09 +0000 Subject: Running unreleased MacPorts Message-ID: <20081231131809.24925453@vignemale.cl.cam.ac.uk> Dear List Is there a way to upgrade my macports installation to the currently unreleased revision? I guess I would need to check out the revision from SVN and build from source. Is there a way to run an unreleased tree in parallel with a working 1.7.0 tree? Ian From jjstickel at vcn.com Wed Dec 31 08:54:15 2008 From: jjstickel at vcn.com (Jonathan Stickel) Date: Wed, 31 Dec 2008 09:54:15 -0700 Subject: qalculate-gtk Message-ID: <495BA3B7.9010103@vcn.com> A little while ago I submitted a ticket for new ports for libqalculate and qaluclate-gtk (http://trac.macports.org/ticket/17618). The ports worked fine for me when I submitted, but after upgrading to Macports 1.7 and dealing with the mixed X11 libraries bug on Tiger, qalculate-gtk is now giving me a "Bus error". Yes, I have rebuilt the port (in fact, I have rebuilt all of my Macports ports). Would someone be interested in testing qalculate-gtk on their system? Even knowing that it works (or not) on Leapord would be helpful. Thanks, Jonathan From jm at poure.com Wed Dec 31 10:26:31 2008 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Wed, 31 Dec 2008 19:26:31 +0100 Subject: Any Macintosh available via SSH? Message-ID: <1230747991.15562.1.camel@debian> Dear Friends, As there is still no Kdenlive+MLT port, would someone be so kind to provide SSH access to a MacOsX station, so I can prepare packages myself. Kdenlive is a really interesting software for video enthousiasts using MacOsX and I don't understand why it is not already in MacPorts. Kind regards, Jean-Michel From jmr at macports.org Wed Dec 31 17:33:33 2008 From: jmr at macports.org (Joshua Root) Date: Thu, 01 Jan 2009 12:33:33 +1100 Subject: Running unreleased MacPorts In-Reply-To: <20081231131809.24925453@vignemale.cl.cam.ac.uk> References: <20081231131809.24925453@vignemale.cl.cam.ac.uk> Message-ID: <495C1D6D.4010202@macports.org> Ian Grant wrote: > Dear List > > Is there a way to upgrade my macports installation to the currently unreleased revision? Sure, see . > I guess I would need to check out the revision from SVN and build from source. Is there a way to run an unreleased tree in parallel with a working 1.7.0 tree? To have multiple MP installs, you need each one to be built with different --prefix and --with-tclpackage arguments to configure. - Josh From jmr at macports.org Wed Dec 31 17:37:52 2008 From: jmr at macports.org (Joshua Root) Date: Thu, 01 Jan 2009 12:37:52 +1100 Subject: Restructuring Python ports? In-Reply-To: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com> References: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com> Message-ID: <495C1E70.6050907@macports.org> Akira Kitada wrote: > Folks, > > As noted in FAQ [1], 'A number of "standard python modules" are built > separately from the python25 port' > and which have been causing difficulty maintaining/using Python with MacPorts. > The document says "People with a FreeBSD background will find > themselves familiar with this schema.", > but I have my doubt on this. Just look at FreeBSD Ports Search.[2] > There is no py25-zlib. There is not py25-hashlib, and so on. > These modules are essential to Python, so without these modules, it > cannot work so well. > So I would like to propose a reform of Python ports to brihg these > essential ports back to python port itself, > or at least add these moduels to the list of its dependencies, and > make it more usable and user-friendly. > > Any thoughts? > > [1] MacPorts FAQ: Why can't I import foo in Python 2.5? > http://trac.macports.org/wiki/FAQ#WhycantIimportfooinPython2.5 > > [2] About FreeBSD Ports > http://www.freebsd.org/ports/ As background, here's the ticket about this: - Josh From blb at macports.org Wed Dec 31 17:39:46 2008 From: blb at macports.org (Bryan Blackburn) Date: Wed, 31 Dec 2008 18:39:46 -0700 Subject: Restructuring Python ports? In-Reply-To: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com> References: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com> Message-ID: <20090101013946.GD781@ninagal.withay.com> On Wed, Dec 31, 2008 at 07:14:45PM +0900, Akira Kitada said: > Folks, > > As noted in FAQ [1], 'A number of "standard python modules" are built > separately from the python25 port' > and which have been causing difficulty maintaining/using Python with MacPorts. > The document says "People with a FreeBSD background will find > themselves familiar with this schema.", > but I have my doubt on this. Just look at FreeBSD Ports Search.[2] > There is no py25-zlib. There is not py25-hashlib, and so on. > These modules are essential to Python, so without these modules, it > cannot work so well. > So I would like to propose a reform of Python ports to brihg these > essential ports back to python port itself, > or at least add these moduels to the list of its dependencies, and > make it more usable and user-friendly. > > Any thoughts? Like python26 does now? The advantage is of course that it works as some who expect it to work like the system python, or the official one you download from python.org. The disadvantage is that it is heavier on dependencies, adding the following to what python25 needs: zlib, openssl, sqlite3, db46, gdbm, tcl, tk, and X11 (because of tk). If we're not sure just yet which is preferred, do note that I haven't heard anything personally that python26 brings in too many dependencies, nor have any tickets been filed. Of course 2.6 is still pretty new, and doesn't yet have the module support the older versions do. Bryan > > [1] MacPorts FAQ: Why can't I import foo in Python 2.5? > http://trac.macports.org/wiki/FAQ#WhycantIimportfooinPython2.5 > > [2] About FreeBSD Ports > http://www.freebsd.org/ports/ From blb at macports.org Wed Dec 31 17:44:30 2008 From: blb at macports.org (Bryan Blackburn) Date: Wed, 31 Dec 2008 18:44:30 -0700 Subject: Running unreleased MacPorts In-Reply-To: <20081231131809.24925453@vignemale.cl.cam.ac.uk> References: <20081231131809.24925453@vignemale.cl.cam.ac.uk> Message-ID: <20090101014430.GE781@ninagal.withay.com> On Wed, Dec 31, 2008 at 01:18:09PM +0000, Ian Grant said: > Dear List > > Is there a way to upgrade my macports installation to the currently unreleased revision? > > I guess I would need to check out the revision from SVN and build from source. Is there a way to run an unreleased tree in parallel with a working 1.7.0 tree? You can either overwrite the base install with one from source (which doesn't require you to reinstall your currently-installed ports), or you can install it into a different prefix (which would need its own install of ports). The howto at discusses one method of running from the svn trunk. For installing to a location different than /opt/local, you want to use the --prefix, --with-tclpackage, --with-applications-dir, and --with-frameworks-dir switches with configure. I usually point the latter three to subdirectories within the prefix used, keeping it all contained. Bryan > > Ian From mark at dxradio.demon.co.uk Wed Dec 31 19:04:33 2008 From: mark at dxradio.demon.co.uk (Mark Hattam) Date: Thu, 1 Jan 2009 03:04:33 +0000 Subject: less 394 or 418 ? Message-ID: <456EDC4A-DD31-4174-B389-EAFD63BEE17C@dxradio.demon.co.uk> I did a sudo port install less and it installed @418. Yet, although it's in /opt/local/bin, when I type a less -V it reveals itself as the version supplied by Apple, that sits in /usr/ bin. iMac:~$ less -V less 394 Copyright (C) 1984-2005 Mark Nudelman less comes with NO WARRANTY, to the extent permitted by law. For information about the terms of redistribution, see the file named README in the less distribution. Homepage: http://www.greenwoodsoftware.com/less which is the same as iMac:~ mark$ /usr/bin/less -V less 394 Copyright (C) 1984-2005 Mark Nudelman less comes with NO WARRANTY, to the extent permitted by law. For information about the terms of redistribution, see the file named README in the less distribution. Homepage: http://www.greenwoodsoftware.com/less Forcing it to use the Macports installed version ... iMac:~$ /opt/local/bin/less -V less 418 Copyright (C) 1984-2007 Mark Nudelman less comes with NO WARRANTY, to the extent permitted by law. For information about the terms of redistribution, see the file named README in the less distribution. Homepage: http://www.greenwoodsoftware.com/less Checking my $PATH ... iMac:~$ echo $PATH /opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/ local/bin:/usr/X11/bin yet it does seem to know about the MacPorts version ... so why the "394" when I do a --version? iMac:~ mark$ which less /opt/local/bin/less in /opt/local/bin I see -rwxr-xr-x 2 root admin 153324 1 Jan 02:52 less and in /usr/bin I see -rwxr-xr-x 1 root wheel 254288 24 Sep 2007 less Mark From mark at dxradio.demon.co.uk Wed Dec 31 19:23:10 2008 From: mark at dxradio.demon.co.uk (Mark Hattam) Date: Thu, 1 Jan 2009 03:23:10 +0000 Subject: less 394 or 418 ? In-Reply-To: <456EDC4A-DD31-4174-B389-EAFD63BEE17C@dxradio.demon.co.uk> References: <456EDC4A-DD31-4174-B389-EAFD63BEE17C@dxradio.demon.co.uk> Message-ID: On 1 Jan 2009, at 03:04, Mark Hattam wrote: > I did a > sudo port install less > > and it installed @418. Yet, although it's in /opt/local/bin, when I > type a > less -V > it reveals itself as the version supplied by Apple, that sits in / > usr/bin. > > iMac:~$ less -V > less 394 > Copyright (C) 1984-2005 Mark Nudelman > > less comes with NO WARRANTY, to the extent permitted by law. > For information about the terms of redistribution, > see the file named README in the less distribution. > Homepage: http://www.greenwoodsoftware.com/less > > which is the same as > iMac:~ mark$ /usr/bin/less -V > less 394 > Copyright (C) 1984-2005 Mark Nudelman > > less comes with NO WARRANTY, to the extent permitted by law. > For information about the terms of redistribution, > see the file named README in the less distribution. > Homepage: http://www.greenwoodsoftware.com/less > > > > Forcing it to use the Macports installed version ... > > iMac:~$ /opt/local/bin/less -V > less 418 > Copyright (C) 1984-2007 Mark Nudelman > > less comes with NO WARRANTY, to the extent permitted by law. > For information about the terms of redistribution, > see the file named README in the less distribution. > Homepage: http://www.greenwoodsoftware.com/less > > Checking my $PATH ... > iMac:~$ echo $PATH > /opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/ > local/bin:/usr/X11/bin > > yet it does seem to know about the MacPorts version ... so why the > "394" when I do a --version? > iMac:~ mark$ which less > /opt/local/bin/less > > in /opt/local/bin I see > -rwxr-xr-x 2 root admin 153324 1 Jan 02:52 less > > and in /usr/bin I see > -rwxr-xr-x 1 root wheel 254288 24 Sep 2007 less > > > Mark Ah ... quitting and re-running Terminal does make it "behave" as expected ... ie less -V brings up 418 ... but why the need to quit/re-run (or quite possibly just open a new window/shell)? Mark From akitada at macports.org Wed Dec 31 21:13:29 2008 From: akitada at macports.org (Akira Kitada) Date: Thu, 1 Jan 2009 14:13:29 +0900 Subject: Restructuring Python ports? In-Reply-To: <20090101013946.GD781@ninagal.withay.com> References: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com> <20090101013946.GD781@ninagal.withay.com> Message-ID: <90bb445a0812312113x75d2cd6dn3c5dd69ba45e2f16@mail.gmail.com> Hi Bryan, > Like python26 does now? The advantage is of course that it works as some > who expect it to work like the system python, or the official one you > download from python.org. The disadvantage is that it is heavier on > dependencies, adding the following to what python25 needs: zlib, openssl, > sqlite3, db46, gdbm, tcl, tk, and X11 (because of tk). And it might be convenient to be able to update each dependent port independently, but I'm not sure we would really want to update each of them that way. As always, we could probably learn some ideas from our senior project, FreeBSD Ports. Here is the patch-setup.py from FreeBSD's. [1] # This global variable is used to hold the list of modules to be disabled. -disabled_module_list = [] +disabled_module_list = ["_bsddb", "_sqlite3", "_tkinter", "gdbm", "mpz"] To me, it looks moderate and more pragmatic configuration than MacPorts's, where it disables: # This global variable is used to hold the list of modules to be disabled. -disabled_module_list = [] +disabled_module_list = ["zlib","_hashlib","_ssl","_bsddb","_sqlite3","_tkinter","bz2","gdbm","readline","_curses","_curses_panel"] (By the way, I must confess I didn't know python26 changed the way how it's built *again*. I worry it would bring some more confusions to python ports.) [1] http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python25/files/patch-setup.py > If we're not sure just yet which is preferred, do note that I haven't heard > anything personally that python26 brings in too many dependencies, nor have > any tickets been filed. Of course 2.6 is still pretty new, and doesn't yet > have the module support the older versions do. I would like to go in the middle. Regards, > Bryan > > >> >> [1] MacPorts FAQ: Why can't I import foo in Python 2.5? >> http://trac.macports.org/wiki/FAQ#WhycantIimportfooinPython2.5 >> >> [2] About FreeBSD Ports >> http://www.freebsd.org/ports/ > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From stechert at gmail.com Wed Dec 31 22:07:24 2008 From: stechert at gmail.com (Andre Stechert) Date: Wed, 31 Dec 2008 22:07:24 -0800 Subject: less 394 or 418 ? In-Reply-To: References: <456EDC4A-DD31-4174-B389-EAFD63BEE17C@dxradio.demon.co.uk> Message-ID: <12a697af0812312207r2cd1f413nf609dad0d8df550a@mail.gmail.com> Google for "shell rehash". Cheers, Andre On Wed, Dec 31, 2008 at 7:23 PM, Mark Hattam wrote: > > On 1 Jan 2009, at 03:04, Mark Hattam wrote: > >> I did a >> sudo port install less >> >> and it installed @418. Yet, although it's in /opt/local/bin, when I type a >> less -V >> it reveals itself as the version supplied by Apple, that sits in /usr/bin. >> >> iMac:~$ less -V >> less 394 >> Copyright (C) 1984-2005 Mark Nudelman >> >> less comes with NO WARRANTY, to the extent permitted by law. >> For information about the terms of redistribution, >> see the file named README in the less distribution. >> Homepage: http://www.greenwoodsoftware.com/less >> >> which is the same as >> iMac:~ mark$ /usr/bin/less -V >> less 394 >> Copyright (C) 1984-2005 Mark Nudelman >> >> less comes with NO WARRANTY, to the extent permitted by law. >> For information about the terms of redistribution, >> see the file named README in the less distribution. >> Homepage: http://www.greenwoodsoftware.com/less >> >> >> >> Forcing it to use the Macports installed version ... >> >> iMac:~$ /opt/local/bin/less -V >> less 418 >> Copyright (C) 1984-2007 Mark Nudelman >> >> less comes with NO WARRANTY, to the extent permitted by law. >> For information about the terms of redistribution, >> see the file named README in the less distribution. >> Homepage: http://www.greenwoodsoftware.com/less >> >> Checking my $PATH ... >> iMac:~$ echo $PATH >> >> /opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin >> >> yet it does seem to know about the MacPorts version ... so why the "394" >> when I do a --version? >> iMac:~ mark$ which less >> /opt/local/bin/less >> >> in /opt/local/bin I see >> -rwxr-xr-x 2 root admin 153324 1 Jan 02:52 less >> >> and in /usr/bin I see >> -rwxr-xr-x 1 root wheel 254288 24 Sep 2007 less >> >> >> Mark > > > Ah ... quitting and re-running Terminal does make it "behave" as expected > ... ie > less -V > brings up 418 ... > > but why the need to quit/re-run (or quite possibly just open a new > window/shell)? > > > Mark > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From etiffany at alum.mit.edu Wed Dec 31 22:20:52 2008 From: etiffany at alum.mit.edu (Eric Tiffany) Date: Thu, 01 Jan 2009 01:20:52 -0500 Subject: less 394 or 418 ? In-Reply-To: Message-ID: On 12/31/08 10:23 PM, "Mark Hattam" wrote: > > On 1 Jan 2009, at 03:04, Mark Hattam wrote: > >> I did a >> sudo port install less >> >> and it installed @418. Yet, although it's in /opt/local/bin, when I >> type a >> less -V >> it reveals itself as the version supplied by Apple, that sits in / >> usr/bin. > but why the need to quit/re-run (or quite possibly just open a new > window/shell)? > > Perhaps the Apple version was in the shell's cache. There used to be a a "rehash" function in the shell, but now it is "hash -d". I have these aliases defined: alias more='less' alias rehash='hash -d' And doing 'hash -d' might have fixed your shell without having to kill/restart. ET -- ________________________________________________ Eric Tiffany | +1 413-458-3743 etiffany at alum.mit.edu | +1 413-627-1778 mobile