From audiodude at gmail.com Tue Sep 1 14:31:27 2009 From: audiodude at gmail.com (Travis Briggs) Date: Tue, 1 Sep 2009 17:31:27 -0400 Subject: Contributing a partially-functional port for nted Message-ID: <76e7b5990909011431j2bf55901off62702ad39d5db6@mail.gmail.com> Hi, I recently patched nted (http://vsr.informatik.tu-chemnitz.de/staff/jan/nted/nted.xhtml) to work in my macports environment. As distributed, it depends on ALSA for music score playback. I removed all references to ALSA data types, and made any functions that utilized them non functioning. So now the program works well, you can create and edit documents, but when you try to configure MIDI playback, or activate MIDI playback (using the play button), nothing happens. I was wondering if this sort of patch would be useful for the project. If so, I'll look into the documentation about how to create a port file (and volunteer to maintain it). If not, I'll probably just distribute the patch files myself. Thanks, -Travis From jeremy at lavergne.gotdns.org Tue Sep 1 16:09:58 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 1 Sep 2009 19:09:58 -0400 Subject: [MacPorts] Migration modified In-Reply-To: <20090901230644.53A1174CB627@mail-out4.apple.com> References: <20090901230644.53A1174CB627@mail-out4.apple.com> Message-ID: <7F473092-BE29-434A-9E22-BB8757E01502@lavergne.gotdns.org> > + 2. Clean any partially completed builds, and uninstall all > installed ports: > {{{ > +sudo port clean installed It be much faster and thorough to use `sudo rm -rf ${prefix}/var/ macports/build/*` Even `sudo port clean all` would be better. From ryandesign at macports.org Tue Sep 1 23:29:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Sep 2009 01:29:08 -0500 Subject: [56717] trunk/dports/perl/p5-version/Portfile In-Reply-To: <20090901202031.3362625688E2@beta.macosforge.org> References: <20090901202031.3362625688E2@beta.macosforge.org> Message-ID: <2C26BE1D-4DBC-4D48-A89F-84FA21EB2AED@macports.org> On Sep 1, 2009, at 15:20, narf_tm at macports.org wrote: > Revision: 56717 > http://trac.macports.org/changeset/56717 > Author: narf_tm at macports.org > Date: 2009-09-01 13:20:30 -0700 (Tue, 01 Sep 2009) > Log Message: > ----------- > Updated to 0.7701. > > Modified Paths: > -------------- > trunk/dports/perl/p5-version/Portfile > > Modified: trunk/dports/perl/p5-version/Portfile > =================================================================== > --- trunk/dports/perl/p5-version/Portfile 2009-09-01 19:53:50 UTC > (rev 56716) > +++ trunk/dports/perl/p5-version/Portfile 2009-09-01 20:20:30 UTC > (rev 56717) > @@ -3,8 +3,7 @@ > PortSystem 1.0 > PortGroup perl5 1.0 > > -epoch 1 > -perl5.setup version 0.76 ../by-authors/id/J/JP/JPEACOCK/ > +perl5.setup version 0.7701 ../by-authors/id/J/JP/JPEACOCK/ Please note that you can never remove an epoch from a portfile or decrease it, otherwise users who already have the port installed would not be informed via "port outdated" that the port is outdated. I put the epoch back in r56781. From ryandesign at macports.org Tue Sep 1 23:33:59 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Sep 2009 01:33:59 -0500 Subject: Portgroup copyrights In-Reply-To: <20090902033726.91FF8256F37B@beta.macosforge.org> References: <20090902033726.91FF8256F37B@beta.macosforge.org> Message-ID: <7F195460-8A8F-4EEB-8ED5-1A976D8BB69E@macports.org> On Sep 1, 2009, at 22:37, jmr at macports.org wrote: > Revision: 56777 > http://trac.macports.org/changeset/56777 > Author: jmr at macports.org > Date: 2009-09-01 20:37:21 -0700 (Tue, 01 Sep 2009) > Log Message: > ----------- > add python31 portgroup > > Added Paths: > ----------- > trunk/dports/_resources/port1.0/group/python31-1.0.tcl > > Copied: trunk/dports/_resources/port1.0/group/python31-1.0.tcl (from > rev 56732, trunk/dports/_resources/port1.0/group/python30-1.0.tcl) > =================================================================== > --- trunk/dports/_resources/port1.0/group/ > python31-1.0.tcl (rev 0) > +++ trunk/dports/_resources/port1.0/group/python31-1.0.tcl > 2009-09-02 03:37:21 UTC (rev 56777) > @@ -0,0 +1,59 @@ > +# et:ts=4 > +# python31-1.0.tcl > +# > +# $Id$ > +# > +# Copyright (c) 2007 Markus W. Weissman , > +# All rights reserved. [snip] This doesn't seem right. Besides the obvious point that Markus did not commit this portgroup and it is not 2007, does it make sense for portgroups to be marked as copyrighted by a particular person? We don't do that for portfiles. Some of the portgroups are marked as copyright by the MacPorts Project. Maybe they could all say that? From ryandesign at macports.org Tue Sep 1 23:57:27 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Sep 2009 01:57:27 -0500 Subject: --disable-dependency-tracking In-Reply-To: <20090902002656.11B25256C6E7@beta.macosforge.org> References: <20090902002656.11B25256C6E7@beta.macosforge.org> Message-ID: On Sep 1, 2009, at 19:26, vinc17 at macports.org wrote: > Revision: 56752 > http://trac.macports.org/changeset/56752 > Author: vinc17 at macports.org > Date: 2009-09-01 17:26:55 -0700 (Tue, 01 Sep 2009) > Log Message: > ----------- > optipng: workaround for problem with MacPorts 1.8.0, which adds > the --disable-dependency-tracking configure option with the > universal variant, even though this option is not standard: > http://www.gnu.org/prep/standards/standards.html#Configuration > Closes #21002. As I recall, all versions of MacPorts that have had a universal variant have added the --disable-dependency-tracking configure argument in that variant, because Apple shows the use of that option in their technote on how to build universal binaries of configure- based software: http://developer.apple.com/mac/library/technotes/tn2005/tn2137.html They do point out indirectly that not all software supports this configure argument. For software that doesn't, your solution is fine. But I would not characterize it as a problem with MacPorts to be worked around; rather, it's simply a difference in how optipng's configure script functions vs. how some other programs' configure scripts function. MacPorts has to have some sort of default behavior, and the default of including --disable-dependency-tracking reflected the best guess on what would work with most software. I wasn't sure if there was a specific passage of the How Configuration Should Work section of the GNU Coding Standards document you wanted us to read. I'm not an expert at Makefiles and documents like that are pretty dense. If there was a specific passage you felt was relevant to the --disable-dependency-tracking option, please point it out. From ryandesign at macports.org Wed Sep 2 00:04:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Sep 2009 02:04:02 -0500 Subject: [56741] trunk/dports/perl/p5-crypt-appletwofish/Portfile In-Reply-To: <20090902000506.DD7EF256BE3E@beta.macosforge.org> References: <20090902000506.DD7EF256BE3E@beta.macosforge.org> Message-ID: <674C3746-7152-4B9B-AE3C-009C4C9EEEC4@macports.org> On Sep 1, 2009, at 19:05, narf_tm at macports.org wrote: > Revision: 56741 > http://trac.macports.org/changeset/56741 > Author: narf_tm at macports.org > Date: 2009-09-01 17:05:02 -0700 (Tue, 01 Sep 2009) > Log Message: > ----------- > Added missing dependency. If you want to make whitespace changes, please do so in a separate commit from functional changes (such as adding a dependency). Otherwise it's difficult to see from the diff what functional changes you made. When you add a library or runtime dependency, you should probably increase the revision so that everybody who already has the port gets that new dependency properly recorded in their registry. I increased the revision in r56787. > Modified Paths: > -------------- > trunk/dports/perl/p5-crypt-appletwofish/Portfile > > Modified: trunk/dports/perl/p5-crypt-appletwofish/Portfile > =================================================================== > --- trunk/dports/perl/p5-crypt-appletwofish/Portfile 2009-09-02 > 00:00:51 UTC (rev 56740) > +++ trunk/dports/perl/p5-crypt-appletwofish/Portfile 2009-09-02 > 00:05:02 UTC (rev 56741) > @@ -1,20 +1,22 @@ > # $Id$ > > -PortSystem 1.0 > -PortGroup perl5 1.0 > +PortSystem 1.0 > +PortGroup perl5 1.0 > > -perl5.setup Crypt-AppleTwoFish 0.051 > -maintainers narf_tm openmaintainer > -description two Apple iTMS/iTunes key descrambling algorithms > -long_description The first algorithm appears to have only > cursory \ > - resemblance to Bruce Schneier's blowfish and > twofish \ > - algorithms in that it too has a table-based > decoder. \ > - The second algorithm is more standard > encryption using \ > - S-box type permutations and lookup tables, and > might \ > - have started out something like Twofish or > Blowfish. > +perl5.setup Crypt-AppleTwoFish 0.051 > +maintainers narf_tm openmaintainer > +description two Apple iTMS/iTunes key descrambling > algorithms > +long_description The first algorithm appears to have only > cursory \ > + resemblance to Bruce Schneier's blowfish and > twofish \ > + algorithms in that it too has a table-based > decoder. \ > + The second algorithm is more standard > encryption using \ > + S-box type permutations and lookup tables, > and might \ > + have started out something like Twofish or > Blowfish. > > -platforms darwin > +platforms darwin > > -checksums md5 b37a913ad65a66a8b039d577e7c3b83b \ > - sha1 21122281f52938960270cdff3baebd58f3250b79 \ > - rmd160 a3056423752533c1255a98e6476cffe2602e1b36 > +checksums md5 b37a913ad65a66a8b039d577e7c3b83b \ > + sha1 21122281f52938960270cdff3baebd58f3250b79 \ > + rmd160 a3056423752533c1255a98e6476cffe2602e1b36 > + > +depends_lib-append port:p5-digest-sha From ryandesign at macports.org Wed Sep 2 00:12:53 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Sep 2009 02:12:53 -0500 Subject: Contributing a partially-functional port for nted In-Reply-To: <76e7b5990909011431j2bf55901off62702ad39d5db6@mail.gmail.com> References: <76e7b5990909011431j2bf55901off62702ad39d5db6@mail.gmail.com> Message-ID: <662F630D-E5D2-41E4-98BB-BCBCBD65CE57@macports.org> On Sep 1, 2009, at 16:31, Travis Briggs wrote: > I recently patched nted > (http://vsr.informatik.tu-chemnitz.de/staff/jan/nted/nted.xhtml) to > work in my macports environment. As distributed, it depends on ALSA > for music score playback. I removed all references to ALSA data types, > and made any functions that utilized them non functioning. So now the > program works well, you can create and edit documents, but when you > try to configure MIDI playback, or activate MIDI playback (using the > play button), nothing happens. > > I was wondering if this sort of patch would be useful for the project. > If so, I'll look into the documentation about how to create a port > file (and volunteer to maintain it). If not, I'll probably just > distribute the patch files myself. Possibly. I note that ALSA stands for Advanced Linux Sound Architecture, so I do not know if it can work on Mac OS X. If it can, then a port for it should be added and then nted would presumably work without patches. If ALSA cannot work on Mac OS X, then you should contribute your patches upstream, since they would be useful to all Mac users, not just those using MacPorts. Until the patches are accepted upstream, a portfile in MacPorts could apply those patches itself. You could file a port request ticket for nted and attach your patches, and a portfile if you've written one. From vincent-opdarw at vinc17.org Wed Sep 2 01:39:41 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Wed, 2 Sep 2009 10:39:41 +0200 Subject: --disable-dependency-tracking In-Reply-To: References: <20090902002656.11B25256C6E7@beta.macosforge.org> Message-ID: <20090902083941.GC1002@prunille.vinc17.org> On 2009-09-02 01:57:27 -0500, Ryan Schmidt wrote: > They do point out indirectly that not all software supports this > configure argument. For software that doesn't, your solution is > fine. But I would not characterize it as a problem with MacPorts to > be worked around; rather, it's simply a difference in how optipng's > configure script functions vs. how some other programs' configure > scripts function. MacPorts has to have some sort of default > behavior, and the default of including --disable-dependency-tracking > reflected the best guess on what would work with most software. > > I wasn't sure if there was a specific passage of the How > Configuration Should Work section of the GNU Coding Standards > document you wanted us to read. I'm not an expert at Makefiles and > documents like that are pretty dense. If there was a specific > passage you felt was relevant to the --disable-dependency-tracking > option, please point it out. The GNU Coding Standards don't mention --disable-dependency-tracking because it is not an option universally recognized. In fact, this is a specific option defined by automake. Software not based on automake probably don't have such an option. The exit status of the command grep -qe --disable-dependency-tracking configure should tell you whether the --disable-dependency-tracking is supported or not. Couldn't MacPorts use that (replacing "configure" by the real configure script name, if this can be changed) in order to decide whether this option should be used or not? BTW, using --disable-dependency-tracking always when supported (instead of just for universal builds) would make the build behavior more consistent and the build probably faster (since gcc won't take time for dependency tracking). -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Ar?naire project (LIP, ENS-Lyon) From ryandesign at macports.org Wed Sep 2 02:16:50 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Sep 2009 04:16:50 -0500 Subject: --disable-dependency-tracking In-Reply-To: <20090902083941.GC1002@prunille.vinc17.org> References: <20090902002656.11B25256C6E7@beta.macosforge.org> <20090902083941.GC1002@prunille.vinc17.org> Message-ID: <86CBAD7C-E5C1-4EDC-8F93-FD898398D97D@macports.org> On Sep 2, 2009, at 03:39, Vincent Lefevre wrote: > The GNU Coding Standards don't mention --disable-dependency-tracking > because it is not an option universally recognized. In fact, this is > a specific option defined by automake. Software not based on automake > probably don't have such an option. The exit status of the command > > grep -qe --disable-dependency-tracking configure > > should tell you whether the --disable-dependency-tracking is supported > or not. Couldn't MacPorts use that (replacing "configure" by the real > configure script name, if this can be changed) in order to decide > whether this option should be used or not? That sounds possible. I don't think MacPorts makes any other decisions based on the contents of the distfile... How do we feel about introducing such a change? > BTW, using --disable-dependency-tracking always when supported > (instead of just for universal builds) would make the build behavior > more consistent and the build probably faster (since gcc won't take > time for dependency tracking). I don't know what dependency tracking does, but since the default is to enable it, I assume it's useful for something. Does anybody know what it's for or what consequences disabling it could have? From ryandesign at macports.org Wed Sep 2 04:07:33 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Sep 2009 06:07:33 -0500 Subject: [56794] trunk/dports/print/libspectre/Portfile In-Reply-To: <20090902094531.5978925746D6@beta.macosforge.org> References: <20090902094531.5978925746D6@beta.macosforge.org> Message-ID: <734E3E5E-41B8-4086-B2A0-4F84CB672EAA@macports.org> On Sep 2, 2009, at 04:45, illogic-al at macports.org wrote: > Revision: 56794 > http://trac.macports.org/changeset/56794 > Author: illogic-al at macports.org > Date: 2009-09-02 02:45:30 -0700 (Wed, 02 Sep 2009) > Log Message: > ----------- > Build libspectre without documentation, to avoid x11 dependencies > from doxygen by default. Also adds +docs variant for those wanting > documentation and bumps revision. > > Modified Paths: > -------------- > trunk/dports/print/libspectre/Portfile > > Modified: trunk/dports/print/libspectre/Portfile > =================================================================== > --- trunk/dports/print/libspectre/Portfile 2009-09-02 09:18:14 UTC > (rev 56793) > +++ trunk/dports/print/libspectre/Portfile 2009-09-02 09:45:30 UTC > (rev 56794) > @@ -5,6 +5,7 @@ > > name libspectre > version 0.2.2 > +revision 1 > description Libspectre is a small library for rendering > PostScript documents. > long_description \ > ${description} \ > @@ -20,12 +21,15 @@ > sha1 d5968d34c4bc93cd280ea35d8db53cf41f811edc \ > rmd160 aca3ec7b9ffb521c4e38cf32a14cb9af07d2f009 > > -depends_build port:pkgconfig \ > - port:doxygen > +depends_build port:pkgconfig > > depends_lib port:ghostscript \ > path:lib/pkgconfig/cairo.pc:cairo > > +variant docs description "Build documentation" { > + depends_build port:doxygen > +} The variant needs to do more than just add a dependency on doxygen. It needs to also inform the software it is ok to use doxygen, or probably, the port needs to inform the software it is *not* ok to use doxygen *unless* the +docs variant is selected. From raimue at macports.org Wed Sep 2 05:37:12 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 02 Sep 2009 14:37:12 +0200 Subject: Portgroup copyrights In-Reply-To: <7F195460-8A8F-4EEB-8ED5-1A976D8BB69E@macports.org> References: <20090902033726.91FF8256F37B@beta.macosforge.org> <7F195460-8A8F-4EEB-8ED5-1A976D8BB69E@macports.org> Message-ID: <4A9E66F8.2030100@macports.org> On 2009-09-02 08:33 , Ryan Schmidt wrote: > This doesn't seem right. Besides the obvious point that Markus did not > commit this portgroup and it is not 2007, does it make sense for > portgroups to be marked as copyrighted by a particular person? We > don't do that for portfiles. Some of the portgroups are marked as > copyright by the MacPorts Project. Maybe they could all say that? We do not add any explicit copyright notice to Portfiles, of which some are even more complicated than PortGroups. In my opinion that header should just be removed from the groups. Rainer From ryandesign at macports.org Wed Sep 2 06:06:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Sep 2009 08:06:02 -0500 Subject: Snow Leopard +universal necessity Message-ID: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> On Snow Leopard, we build x86_64 by default. But there are some ports, e.g. wine, that cannot build 64-bit, so they force themselves to build 32-bit instead. But that means all the dependencies must also be 32- bit, or 32-/64-bit universal. So it seems like it should probably be our recommendation to all Snow Leopard users to install all possible ports +universal for x86_64/i386, to avoid pain down the road when the user wants to install a port that happens to only be available as 32- bit. Most easily this could be accomplished by putting "+universal" into variants.conf. Maybe we should even do so in the default variants.conf on Snow Leopard. Not installing dependencies universal causes issues like this: http://trac.macports.org/ticket/20912 From jeremy at lavergne.gotdns.org Wed Sep 2 06:09:16 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 2 Sep 2009 09:09:16 -0400 Subject: Snow Leopard +universal necessity In-Reply-To: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> Message-ID: > On Snow Leopard, we build x86_64 by default. But there are some > ports, e.g. wine, that cannot build 64-bit, so they force themselves > to build 32-bit instead. But that means all the dependencies must > also be 32-bit, or 32-/64-bit universal. So it seems like it should > probably be our recommendation to all Snow Leopard users to install > all possible ports +universal for x86_64/i386, to avoid pain down > the road when the user wants to install a port that happens to only > be available as 32-bit. Most easily this could be accomplished by > putting "+universal" into variants.conf. Maybe we should even do so > in the default variants.conf on Snow Leopard. > > Not installing dependencies universal causes issues like this: > > http://trac.macports.org/ticket/20912 Sounds reasonable, however I wonder if this is a temporary issue that impacts a handful of ports. Do you know if there are many projects apart from wine that need 32-bit? I'd say that, if it does impact several ports to go for it. If it's only wine or one or two other ports, I'd leave things as they are and post it as a known bug. From ryandesign at macports.org Wed Sep 2 06:18:45 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Sep 2009 08:18:45 -0500 Subject: Snow Leopard +universal necessity In-Reply-To: References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> Message-ID: <52ED5B20-23C4-4D69-8A7A-3CE9184FBA4A@macports.org> On Sep 2, 2009, at 08:09, Jeremy Lavergne wrote: >> On Snow Leopard, we build x86_64 by default. But there are some >> ports, e.g. wine, that cannot build 64-bit, so they force >> themselves to build 32-bit instead. But that means all the >> dependencies must also be 32-bit, or 32-/64-bit universal. So it >> seems like it should probably be our recommendation to all Snow >> Leopard users to install all possible ports +universal for x86_64/ >> i386, to avoid pain down the road when the user wants to install a >> port that happens to only be available as 32-bit. Most easily this >> could be accomplished by putting "+universal" into variants.conf. >> Maybe we should even do so in the default variants.conf on Snow >> Leopard. >> >> Not installing dependencies universal causes issues like this: >> >> http://trac.macports.org/ticket/20912 > > Sounds reasonable, however I wonder if this is a temporary issue > that impacts a handful of ports. Do you know if there are many > projects apart from wine that need 32-bit? > > I'd say that, if it does impact several ports to go for it. If it's > only wine or one or two other ports, I'd leave things as they are > and post it as a known bug. I guess there are several ports that will not work 64-bit, we just haven't come across them yet. I imagine a lot of the bugs currently classified as Snow Leopard-related issues are in fact 64-bit-related. So far I see the following ports forcing themselves to 32-bit builds: bochs synergy wine wine-crossover-games wine-devel From jeremy at lavergne.gotdns.org Wed Sep 2 06:26:07 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 2 Sep 2009 09:26:07 -0400 Subject: Snow Leopard +universal necessity In-Reply-To: <52ED5B20-23C4-4D69-8A7A-3CE9184FBA4A@macports.org> References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> <52ED5B20-23C4-4D69-8A7A-3CE9184FBA4A@macports.org> Message-ID: <2B853B9B-2721-4A63-85ED-0C349CF52ECA@lavergne.gotdns.org> >>> On Snow Leopard, we build x86_64 by default. But there are some >>> ports, e.g. wine, that cannot build 64-bit, so they force >>> themselves to build 32-bit instead. But that means all the >>> dependencies must also be 32-bit, or 32-/64-bit universal. So it >>> seems like it should probably be our recommendation to all Snow >>> Leopard users to install all possible ports +universal for x86_64/ >>> i386, to avoid pain down the road when the user wants to install a >>> port that happens to only be available as 32-bit. Most easily this >>> could be accomplished by putting "+universal" into variants.conf. >>> Maybe we should even do so in the default variants.conf on Snow >>> Leopard. >>> >>> Not installing dependencies universal causes issues like this: >>> >>> http://trac.macports.org/ticket/20912 >> >> Sounds reasonable, however I wonder if this is a temporary issue >> that impacts a handful of ports. Do you know if there are many >> projects apart from wine that need 32-bit? >> >> I'd say that, if it does impact several ports to go for it. If >> it's only wine or one or two other ports, I'd leave things as they >> are and post it as a known bug. > > I guess there are several ports that will not work 64-bit, we just > haven't come across them yet. I imagine a lot of the bugs currently > classified as Snow Leopard-related issues are in fact 64-bit- > related. So far I see the following ports forcing themselves to 32- > bit builds: > > bochs > synergy > wine > wine-crossover-games > wine-devel Alright, we should do that then. In the future when these start becoming 64-bit capable, are we going to switch back to non-universal by default? Will we simply maintain that universal should be used? From ryandesign at macports.org Wed Sep 2 07:11:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Sep 2009 09:11:13 -0500 Subject: Snow Leopard +universal necessity In-Reply-To: <2B853B9B-2721-4A63-85ED-0C349CF52ECA@lavergne.gotdns.org> References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> <52ED5B20-23C4-4D69-8A7A-3CE9184FBA4A@macports.org> <2B853B9B-2721-4A63-85ED-0C349CF52ECA@lavergne.gotdns.org> Message-ID: <184E0AF5-9A27-4D86-88AA-30FC66E8E7E1@macports.org> On Sep 2, 2009, at 08:26, Jeremy Lavergne wrote: >> I guess there are several ports that will not work 64-bit, we just >> haven't come across them yet. I imagine a lot of the bugs currently >> classified as Snow Leopard-related issues are in fact 64-bit- >> related. So far I see the following ports forcing themselves to 32- >> bit builds: >> >> bochs >> synergy >> wine >> wine-crossover-games >> wine-devel > > Alright, we should do that then. In the future when these start > becoming 64-bit capable, are we going to switch back to non- > universal by default? Will we simply maintain that universal should > be used? I don't know. My guess is that some software will never be 64-bit capable. I don't think we should remove ports from the tree solely for that reason, so it is a situation a user might run into. When they do, it's pretty annoying for MacPorts to happily install all the dependencies 64-bit, and then fail with an unpredictable error when actually compiling the requested port 32-bit. Granted the user can now probably rebuild all ports with the universal variant with a single "upgrade --force" command, but a lot of the user's time has been wasted. Wine 64-bit support is in progress: http://wiki.winehq.org/Wine64 It sounds like there is a lot of work to do. What's not clear to me is whether 64-bit wine can be used to run 32-bit Windows programs. If not, then there would continue to be a reason for a user to want to build wine 32-bit. From ryandesign at macports.org Wed Sep 2 07:51:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Sep 2009 09:51:42 -0500 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: <4A9C6651.7040807@macports.org> References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> <4A9C6651.7040807@macports.org> Message-ID: <23DCC792-F565-4CC4-A9C8-6BF324407E90@macports.org> On Aug 31, 2009, at 19:09, Rainer M?ller wrote: > I am totally in favor of a batch change, but I would like to give > users > a few days of grace period for updating their MacPorts installations. > Let's say a week is enough? That would be next friday. Note that we already crippled MacPorts for users of 1.7.1 and earlier on August 29 by adding license info to 35 ports, including openssl (which has 274 dependents) and most of the gcc ports (50 dependents). We've set livecheck.type in git-core, so anything that fetches via git won't work (13 ports). Before realizing the implications, I used depends_extract in pango, thus making unavailable on 1.7.1 it and all its dependents (30 ports) -- one of which is gtk2 (219 dependents). We could undo these changes now and redo them at a later time, but really I would rather focus on moving forward with 1.8.0. Here's the full list of ports that currently cannot be parsed by MacPorts 1.7.1: 1 Error: Unable to open port: can't read "build_arch": no such variable 1 Error: Unable to open port: can't read "configure.build_arch": no such variable 3 Error: Unable to open port: invalid command name "configure.build_arch" mpg123 synergy wine wine-crossover-games wine-devel 2 Error: Unable to open port: invalid command name "depends_extract" pango pango-devel 35 Error: Unable to open port: invalid command name "license" bacula bison c-ares cclive cdo ctags flex gcc33 gcc40 gcc41 gcc42 gcc43 gcc44 gcc45 gst-plugins-bad ii isabelle isabelle-devel javacc libANN mathomatic mono ne openssl openssl97 py25-cvxopt py25-pymc py26-cvxopt py26-pymc py26-scikits-talkbox sic treecc uthash xephem ykpers 2 Error: Unable to open port: invalid command name "livecheck.type" git-core GraphicsMagick From audiodude at gmail.com Wed Sep 2 08:00:28 2009 From: audiodude at gmail.com (Travis Briggs) Date: Wed, 2 Sep 2009 11:00:28 -0400 Subject: Contributing a partially-functional port for nted In-Reply-To: <662F630D-E5D2-41E4-98BB-BCBCBD65CE57@macports.org> References: <76e7b5990909011431j2bf55901off62702ad39d5db6@mail.gmail.com> <662F630D-E5D2-41E4-98BB-BCBCBD65CE57@macports.org> Message-ID: <76e7b5990909020800j5a0f075ev125865d0f242ca3d@mail.gmail.com> I've been hoping for an ALSA port for OS X since the early days of Darwin. Unfortunately, it largely consists of kernel modules, so it really ain't gonna happen. I have thought about writing a bridging interface between ALSA and CoreAudio...but a project like that would likely take years. I'll contribute the patches to the author of nted and also put them together in a portfile. -Travis On Wed, Sep 2, 2009 at 3:12 AM, Ryan Schmidt wrote: > > On Sep 1, 2009, at 16:31, Travis Briggs wrote: > >> I recently patched nted >> (http://vsr.informatik.tu-chemnitz.de/staff/jan/nted/nted.xhtml) to >> work in my macports environment. As distributed, it depends on ALSA >> for music score playback. I removed all references to ALSA data types, >> and made any functions that utilized them non functioning. So now the >> program works well, you can create and edit documents, but when you >> try to configure MIDI playback, or activate MIDI playback (using the >> play button), nothing happens. >> >> I was wondering if this sort of patch would be useful for the project. >> If so, I'll look into the documentation about how to create a port >> file (and volunteer to maintain it). If not, I'll probably just >> distribute the patch files myself. > > Possibly. > > I note that ALSA stands for Advanced Linux Sound Architecture, so I do not > know if it can work on Mac OS X. If it can, then a port for it should be > added and then nted would presumably work without patches. > > If ALSA cannot work on Mac OS X, then you should contribute your patches > upstream, since they would be useful to all Mac users, not just those using > MacPorts. Until the patches are accepted upstream, a portfile in MacPorts > could apply those patches itself. You could file a port request ticket for > nted and attach your patches, and a portfile if you've written one. > > From jeremyhu at macports.org Wed Sep 2 08:44:29 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Wed, 2 Sep 2009 08:44:29 -0700 Subject: Snow Leopard +universal necessity In-Reply-To: <52ED5B20-23C4-4D69-8A7A-3CE9184FBA4A@macports.org> References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> <52ED5B20-23C4-4D69-8A7A-3CE9184FBA4A@macports.org> Message-ID: <24F0D155-7A1D-4FE5-87CD-25B26A08CA30@macports.org> >> Sounds reasonable, however I wonder if this is a temporary issue >> that impacts a handful of ports. Do you know if there are many >> projects apart from wine that need 32-bit? >> >> I'd say that, if it does impact several ports to go for it. If >> it's only wine or one or two other ports, I'd leave things as they >> are and post it as a known bug. > > I guess there are several ports that will not work 64-bit, we just > haven't come across them yet. I imagine a lot of the bugs currently > classified as Snow Leopard-related issues are in fact 64-bit- > related. So far I see the following ports forcing themselves to 32- > bit builds: > > bochs > synergy > wine > wine-crossover-games > wine-devel These also have inline-asm and need to be 32bit, but I haven't added the build_arch-fu to them yet: xulrunner xulrunner-devel firefox-x11 firefox-x11-devel From jeremyhu at macports.org Wed Sep 2 08:46:59 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Wed, 2 Sep 2009 08:46:59 -0700 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: <23DCC792-F565-4CC4-A9C8-6BF324407E90@macports.org> References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> <4A9C6651.7040807@macports.org> <23DCC792-F565-4CC4-A9C8-6BF324407E90@macports.org> Message-ID: <17B5EF2D-E36A-4A8D-B5A2-F59D28568D62@macports.org> On Sep 2, 2009, at 07:51, Ryan Schmidt wrote: > > On Aug 31, 2009, at 19:09, Rainer M?ller wrote: > >> I am totally in favor of a batch change, but I would like to give >> users >> a few days of grace period for updating their MacPorts installations. >> Let's say a week is enough? That would be next friday. > > > Note that we already crippled MacPorts for users of 1.7.1 and > earlier on August 29 by adding license info to 35 ports, including > openssl (which has 274 dependents) and most of the gcc ports (50 > dependents). We've set livecheck.type in git-core, so anything that > fetches via git won't work (13 ports). Before realizing the > implications, I used depends_extract in pango, thus making > unavailable on 1.7.1 it and all its dependents (30 ports) -- one of > which is gtk2 (219 dependents). We could undo these changes now and > redo them at a later time, but really I would rather focus on moving > forward with 1.8.0. I agree. Let's keep moving forward. In the future, perhaps we should wait a week after a new release, but now that it's done, let's not back track. From raimue at macports.org Wed Sep 2 08:51:23 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 02 Sep 2009 17:51:23 +0200 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: <17B5EF2D-E36A-4A8D-B5A2-F59D28568D62@macports.org> References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> <4A9C6651.7040807@macports.org> <23DCC792-F565-4CC4-A9C8-6BF324407E90@macports.org> <17B5EF2D-E36A-4A8D-B5A2-F59D28568D62@macports.org> Message-ID: <4A9E947B.2030305@macports.org> On 2009-09-02 17:46 , Jeremy Huddleston wrote: > > On Sep 2, 2009, at 07:51, Ryan Schmidt wrote: > >> Note that we already crippled MacPorts for users of 1.7.1 and >> earlier on August 29 by adding license info to 35 ports, including >> openssl (which has 274 dependents) and most of the gcc ports (50 >> dependents). We've set livecheck.type in git-core, so anything that >> fetches via git won't work (13 ports). Before realizing the >> implications, I used depends_extract in pango, thus making >> unavailable on 1.7.1 it and all its dependents (30 ports) -- one of >> which is gtk2 (219 dependents). We could undo these changes now and >> redo them at a later time, but really I would rather focus on moving >> forward with 1.8.0. > > I agree. Let's keep moving forward. In the future, perhaps we should > wait a week after a new release, but now that it's done, let's not > back track. Okay, we just need to remember next time that we should discuss this before doing the release :-) Rainer From frstan at bellsouth.net Wed Sep 2 09:04:07 2009 From: frstan at bellsouth.net (William Davis) Date: Wed, 2 Sep 2009 12:04:07 -0400 Subject: [Bulk] Snow Leopard +universal necessity In-Reply-To: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> Message-ID: On Sep 2, 2009, at 9:06 AM, Ryan Schmidt wrote: > On Snow Leopard, we build x86_64 by default. But there are some > ports, e.g. wine, that cannot build 64-bit, so they force themselves > to build 32-bit instead. But that means all the dependencies must > also be 32-bit, or 32-/64-bit universal. So it seems like it should > probably be our recommendation to all Snow Leopard users to install > all possible ports +universal for x86_64/i386, to avoid pain down > the road when the user wants to install a port that happens to only > be available as 32-bit. Most easily this could be accomplished by > putting "+universal" into variants.conf. Maybe we should even do so > in the default variants.conf on Snow Leopard. > > Not installing dependencies universal causes issues like this: > > http://trac.macports.org/ticket/20912 > Its just my opinion of course but I intensely dislike the idea of being forced to build all of my numerous ports "universal" instead of just fixing the ones that need to be 32 bit. William Davis frstanATbellsouthDOTnet Mac OS X ver 10.6 Darwin 10.6 XQuartz 2.4.0 (xorg-server 1.5.3-apple14) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From jeremyhu at macports.org Wed Sep 2 09:06:11 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Wed, 2 Sep 2009 09:06:11 -0700 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: <4A9E947B.2030305@macports.org> References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> <4A9C6651.7040807@macports.org> <23DCC792-F565-4CC4-A9C8-6BF324407E90@macports.org> <17B5EF2D-E36A-4A8D-B5A2-F59D28568D62@macports.org> <4A9E947B.2030305@macports.org> Message-ID: <2F449D41-966F-48A8-AE01-F1E7A0E79289@macports.org> Maybe there can be a note in the parse-error notification for users: Sometime a parse error can occur when features of a new MacPorts release are included in Portfiles. Please run 'sudo port -v selfupdate' to ensure you have the latest MacPorts base distribution. On Sep 2, 2009, at 08:51, Rainer M?ller wrote: > On 2009-09-02 17:46 , Jeremy Huddleston wrote: >> >> On Sep 2, 2009, at 07:51, Ryan Schmidt wrote: >> >>> Note that we already crippled MacPorts for users of 1.7.1 and >>> earlier on August 29 by adding license info to 35 ports, including >>> openssl (which has 274 dependents) and most of the gcc ports (50 >>> dependents). We've set livecheck.type in git-core, so anything that >>> fetches via git won't work (13 ports). Before realizing the >>> implications, I used depends_extract in pango, thus making >>> unavailable on 1.7.1 it and all its dependents (30 ports) -- one of >>> which is gtk2 (219 dependents). We could undo these changes now and >>> redo them at a later time, but really I would rather focus on moving >>> forward with 1.8.0. >> >> I agree. Let's keep moving forward. In the future, perhaps we >> should >> wait a week after a new release, but now that it's done, let's not >> back track. > > Okay, we just need to remember next time that we should discuss this > before doing the release :-) > > Rainer From jeremyhu at macports.org Wed Sep 2 09:08:25 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Wed, 2 Sep 2009 09:08:25 -0700 Subject: [Bulk] Snow Leopard +universal necessity In-Reply-To: References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> Message-ID: <5D19019D-3F40-49EF-AE90-F40D94475057@macports.org> >> Not installing dependencies universal causes issues like this: >> >> http://trac.macports.org/ticket/20912 > > Its just my opinion of course but I intensely dislike the idea of > being forced to build all of my numerous ports "universal" instead > of just fixing the ones that need to be 32 bit. While some (xulrunner, firefox) just need new inline-asm to be written for 64bit support, others (wine) may *NEVER* actually work in 64bit. It may be the case that users need a 32bit wine for win32 and a 64bit wine for win64. ... so it's not really trivially fixable when it is by design. From frstan at bellsouth.net Wed Sep 2 09:14:19 2009 From: frstan at bellsouth.net (William Davis) Date: Wed, 2 Sep 2009 12:14:19 -0400 Subject: [Bulk] Re: [Bulk] Snow Leopard +universal necessity In-Reply-To: <5D19019D-3F40-49EF-AE90-F40D94475057@macports.org> References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> <5D19019D-3F40-49EF-AE90-F40D94475057@macports.org> Message-ID: On Sep 2, 2009, at 12:08 PM, Jeremy Huddleston wrote: >>> Not installing dependencies universal causes issues like this: >>> >>> http://trac.macports.org/ticket/20912 >> >> Its just my opinion of course but I intensely dislike the idea of >> being forced to build all of my numerous ports "universal" instead >> of just fixing the ones that need to be 32 bit. > > While some (xulrunner, firefox) just need new inline-asm to be > written for 64bit support, others (wine) may *NEVER* actually work > in 64bit. It may be the case that users need a 32bit wine for win32 > and a 64bit wine for win64. ... so it's not really trivially > fixable when it is by design. > Jeremy, I'm sorry to be that unclear: what I meant was "modify the port file to build universal" for each port that needed that. In other words fix the individual port files as needed instead of building all ports universal.. William Davis frstanATbellsouthDOTnet Mac OS X ver 10.6 Darwin 10.6 XQuartz 2.3.4 (xorg-server 1.4.2-apple45) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From dluke at geeklair.net Wed Sep 2 09:35:30 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed, 2 Sep 2009 12:35:30 -0400 Subject: [Bulk] Re: [Bulk] Snow Leopard +universal necessity In-Reply-To: References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> <5D19019D-3F40-49EF-AE90-F40D94475057@macports.org> Message-ID: On Sep 2, 2009, at 12:14 PM, William Davis wrote: >> While some (xulrunner, firefox) just need new inline-asm to be >> written for 64bit support, others (wine) may *NEVER* actually work >> in 64bit. It may be the case that users need a 32bit wine for >> win32 and a 64bit wine for win64. ... so it's not really trivially >> fixable when it is by design. > > Jeremy, I'm sorry to be that unclear: what I meant was "modify the > port file to build universal" for each port that needed that. In > other words fix the individual port files as needed instead of > building all ports universal.. William, You seem to be missing the idea that the 64bit version of a port needs 64bit versions of all its dependencies (and a 32bit version likewise needs a 32bit version of all of its dependencies). -- 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 jeremyhu at macports.org Wed Sep 2 09:43:22 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Wed, 2 Sep 2009 09:43:22 -0700 Subject: [Bulk] Re: [Bulk] Snow Leopard +universal necessity In-Reply-To: References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> <5D19019D-3F40-49EF-AE90-F40D94475057@macports.org> Message-ID: On Sep 2, 2009, at 09:14, William Davis wrote: > On Sep 2, 2009, at 12:08 PM, Jeremy Huddleston wrote: > >>>> Not installing dependencies universal causes issues like this: >>>> >>>> http://trac.macports.org/ticket/20912 >>> >>> Its just my opinion of course but I intensely dislike the idea of >>> being forced to build all of my numerous ports "universal" instead >>> of just fixing the ones that need to be 32 bit. >> >> While some (xulrunner, firefox) just need new inline-asm to be >> written for 64bit support, others (wine) may *NEVER* actually work >> in 64bit. It may be the case that users need a 32bit wine for >> win32 and a 64bit wine for win64. ... so it's not really trivially >> fixable when it is by design. > > Jeremy, I'm sorry to be that unclear: what I meant was "modify the > port file to build universal" for each port that needed that. In > other words fix the individual port files as needed instead of > building all ports universal.. But then we'd need to force all of wine's dependencies to be built universal... And what about when wine needs a new dependency, we then need to add that one to the list of ports to be forced universal. From ryandesign at macports.org Wed Sep 2 09:46:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Sep 2009 11:46:35 -0500 Subject: [Bulk] Snow Leopard +universal necessity In-Reply-To: References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> Message-ID: On Sep 2, 2009, at 11:04, William Davis wrote: > > On Sep 2, 2009, at 9:06 AM, Ryan Schmidt wrote: > >> On Snow Leopard, we build x86_64 by default. But there are some >> ports, e.g. wine, that cannot build 64-bit, so they force >> themselves to build 32-bit instead. But that means all the >> dependencies must also be 32-bit, or 32-/64-bit universal. So it >> seems like it should probably be our recommendation to all Snow >> Leopard users to install all possible ports +universal for x86_64/ >> i386, to avoid pain down the road when the user wants to install a >> port that happens to only be available as 32-bit. Most easily this >> could be accomplished by putting "+universal" into variants.conf. >> Maybe we should even do so in the default variants.conf on Snow >> Leopard. >> >> Not installing dependencies universal causes issues like this: >> >> http://trac.macports.org/ticket/20912 > > Its just my opinion of course but I intensely dislike the idea of > being forced to build all of my numerous ports "universal" instead > of just fixing the ones that need to be 32 bit. You mean fixing them so they can build 64-bit? Feel free to read over the link I posted describing what still needs to be done before wine can build 64-bit. What do you dislike about building universal? Nobody's forcing you to build universal. I was recommending universal because I believe it will resolve some issues before they even occur. If you would rather encounter the issues, you could certainly ignore the recommendation, or if we change MacPorts to include universal in the default variants.conf on Snow Leopard, you could remove it from there again if desired. From toby at macports.org Wed Sep 2 09:56:08 2009 From: toby at macports.org (Toby Peterson) Date: Wed, 2 Sep 2009 09:56:08 -0700 Subject: --disable-dependency-tracking In-Reply-To: <86CBAD7C-E5C1-4EDC-8F93-FD898398D97D@macports.org> References: <20090902002656.11B25256C6E7@beta.macosforge.org> <20090902083941.GC1002@prunille.vinc17.org> <86CBAD7C-E5C1-4EDC-8F93-FD898398D97D@macports.org> Message-ID: <74c219d30909020956l5031154ew6a0ae18c38d9984@mail.gmail.com> On Wed, Sep 2, 2009 at 02:16, Ryan Schmidt wrote: > On Sep 2, 2009, at 03:39, Vincent Lefevre wrote: > >> The GNU Coding Standards don't mention --disable-dependency-tracking >> because it is not an option universally recognized. In fact, this is >> a specific option defined by automake. Software not based on automake >> probably don't have such an option. The exit status of the command >> >> ?grep -qe --disable-dependency-tracking configure >> >> should tell you whether the --disable-dependency-tracking is supported >> or not. Couldn't MacPorts use that (replacing "configure" by the real >> configure script name, if this can be changed) in order to decide >> whether this option should be used or not? > > That sounds possible. I don't think MacPorts makes any other decisions based > on the contents of the distfile... How do we feel about introducing such a > change? Pointless overengineering. It's simple enough to remove the flag if it isn't supported. > I don't know what dependency tracking does, but since the default is to > enable it, I assume it's useful for something. Does anybody know what it's > for or what consequences disabling it could have? The primary consequence is that builds would be faster. :-) - Toby From ryandesign at macports.org Wed Sep 2 09:59:44 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 2 Sep 2009 11:59:44 -0500 Subject: --disable-dependency-tracking In-Reply-To: <74c219d30909020956l5031154ew6a0ae18c38d9984@mail.gmail.com> References: <20090902002656.11B25256C6E7@beta.macosforge.org> <20090902083941.GC1002@prunille.vinc17.org> <86CBAD7C-E5C1-4EDC-8F93-FD898398D97D@macports.org> <74c219d30909020956l5031154ew6a0ae18c38d9984@mail.gmail.com> Message-ID: <92DF145D-A677-4B7A-B9A3-C5A41D03F6B0@macports.org> On Sep 2, 2009, at 11:56, Toby Peterson wrote: >> I don't know what dependency tracking does, but since the default >> is to >> enable it, I assume it's useful for something. Does anybody know >> what it's >> for or what consequences disabling it could have? > > The primary consequence is that builds would be faster. :-) Ok. What does it do when it is enabled? Why did whoever designed the feature decide that most people would want it enabled? From toby at macports.org Wed Sep 2 10:24:21 2009 From: toby at macports.org (Toby Peterson) Date: Wed, 2 Sep 2009 10:24:21 -0700 Subject: --disable-dependency-tracking In-Reply-To: <92DF145D-A677-4B7A-B9A3-C5A41D03F6B0@macports.org> References: <20090902002656.11B25256C6E7@beta.macosforge.org> <20090902083941.GC1002@prunille.vinc17.org> <86CBAD7C-E5C1-4EDC-8F93-FD898398D97D@macports.org> <74c219d30909020956l5031154ew6a0ae18c38d9984@mail.gmail.com> <92DF145D-A677-4B7A-B9A3-C5A41D03F6B0@macports.org> Message-ID: <74c219d30909021024s10a9b1b3qb2882d13bacf6709@mail.gmail.com> On Wed, Sep 2, 2009 at 09:59, Ryan Schmidt wrote: > On Sep 2, 2009, at 11:56, Toby Peterson wrote: > >>> I don't know what dependency tracking does, but since the default is to >>> enable it, I assume it's useful for something. Does anybody know what >>> it's >>> for or what consequences disabling it could have? >> >> The primary consequence is that builds would be faster. :-) > > Ok. What does it do when it is enabled? Why did whoever designed the feature > decide that most people would want it enabled? It generates some additional dependency information to make future builds faster. However, since we almost always do clean builds it doesn't serve a useful purpose. - Toby From frstan at bellsouth.net Wed Sep 2 10:35:29 2009 From: frstan at bellsouth.net (William Davis) Date: Wed, 2 Sep 2009 13:35:29 -0400 Subject: [Bulk] Re: [Bulk] Snow Leopard +universal necessity In-Reply-To: References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> Message-ID: On Sep 2, 2009, at 12:46 PM, Ryan Schmidt wrote: > > On Sep 2, 2009, at 11:04, William Davis wrote: > >> >> On Sep 2, 2009, at 9:06 AM, Ryan Schmidt wrote: >> >>> On Snow Leopard, we build x86_64 by default. But there are some >>> ports, e.g. wine, that cannot build 64-bit, so they force >>> themselves to build 32-bit instead. But that means all the >>> dependencies must also be 32-bit, or 32-/64-bit universal. So it >>> seems like it should probably be our recommendation to all Snow >>> Leopard users to install all possible ports +universal for x86_64/ >>> i386, to avoid pain down the road when the user wants to install a >>> port that happens to only be available as 32-bit. Most easily this >>> could be accomplished by putting "+universal" into variants.conf. >>> Maybe we should even do so in the default variants.conf on Snow >>> Leopard. >>> >>> Not installing dependencies universal causes issues like this: >>> >>> http://trac.macports.org/ticket/20912 >> >> Its just my opinion of course but I intensely dislike the idea of >> being forced to build all of my numerous ports "universal" instead >> of just fixing the ones that need to be 32 bit. > > You mean fixing them so they can build 64-bit? Feel free to read > over the link I posted describing what still needs to be done before > wine can build 64-bit. > > What do you dislike about building universal? > > Nobody's forcing you to build universal. I was recommending > universal because I believe it will resolve some issues before they > even occur. If you would rather encounter the issues, you could > certainly ignore the recommendation, or if we change MacPorts to > include universal in the default variants.conf on Snow Leopard, you > could remove it from there again if desired. > > Yes I can just remove it. I would, I suppose, have to set up my own local port system and modify all the portfiles needing 32-bit builds individually...... It just seems simpler to me to have port rebuild dependents as universal whenever that was needed instead of building them all universal, whether needed or not. My own programing experience goes back to the days when I had to change the cords in a patch-panel to reformat a reports output so I have a built in antipathy to waste. But that's just me, "your milage may vary!" William Davis frstanATbellsouthDOTnet Mac OS X ver 10.6 Darwin 10.6 XQuartz 2.3.4 (xorg-server 1.4.2-apple45) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From frstan at bellsouth.net Wed Sep 2 10:36:38 2009 From: frstan at bellsouth.net (William Davis) Date: Wed, 2 Sep 2009 13:36:38 -0400 Subject: [Bulk] Re: [Bulk] Snow Leopard +universal necessity In-Reply-To: References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> <5D19019D-3F40-49EF-AE90-F40D94475057@macports.org> Message-ID: <887ADF01-9A39-4D3A-B7BF-13F5384E9BBC@bellsouth.net> On Sep 2, 2009, at 12:35 PM, Daniel J. Luke wrote: > On Sep 2, 2009, at 12:14 PM, William Davis wrote: >>> While some (xulrunner, firefox) just need new inline-asm to be >>> written for 64bit support, others (wine) may *NEVER* actually work >>> in 64bit. It may be the case that users need a 32bit wine for >>> win32 and a 64bit wine for win64. ... so it's not really >>> trivially fixable when it is by design. >> >> Jeremy, I'm sorry to be that unclear: what I meant was "modify the >> port file to build universal" for each port that needed that. In >> other words fix the individual port files as needed instead of >> building all ports universal.. > > > William, > > You seem to be missing the idea that the 64bit version of a port > needs 64bit versions of all its dependencies (and a 32bit version > likewise needs a 32bit version of all of its dependencies). > > -- > Daniel J. Luke No, I'm not but see my last answer to Ryan. William Davis frstanATbellsouthDOTnet Mac OS X ver 10.6 Darwin 10.6 XQuartz 2.3.4 (xorg-server 1.4.2-apple45) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From jeremy at lavergne.gotdns.org Wed Sep 2 10:38:53 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 2 Sep 2009 13:38:53 -0400 Subject: archive mode Message-ID: Has anyone else noticed that archive mode always places things in darwin/i386 even when doing other architectures? Bug or just careless directory scheme? From dluke at geeklair.net Wed Sep 2 10:48:45 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed, 2 Sep 2009 13:48:45 -0400 Subject: archive mode In-Reply-To: References: Message-ID: <7BE5D9DA-DB8B-4DF7-8C09-1F6F3E4DAD67@geeklair.net> On Sep 2, 2009, at 1:38 PM, Jeremy Lavergne wrote: > Has anyone else noticed that archive mode always places things in > darwin/i386 even when doing other architectures? It's probably using the arch of the build host and not the arch that you are building (on my ppc machine, the packages are all in /opt/ local/var/macports/packages/darwin/powerpc/) > Bug or just careless directory scheme? -- 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 jeremy at lavergne.gotdns.org Wed Sep 2 10:53:17 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 2 Sep 2009 13:53:17 -0400 Subject: archive mode In-Reply-To: <7BE5D9DA-DB8B-4DF7-8C09-1F6F3E4DAD67@geeklair.net> References: <7BE5D9DA-DB8B-4DF7-8C09-1F6F3E4DAD67@geeklair.net> Message-ID: <7FEC1714-0847-411C-8C6B-3D25B129CACA@lavergne.gotdns.org> >> Has anyone else noticed that archive mode always places things in >> darwin/i386 even when doing other architectures? > > It's probably using the arch of the build host and not the arch that > you are building (on my ppc machine, the packages are all in /opt/ > local/var/macports/packages/darwin/powerpc/) ah, from `uname -m`? I'd think that 64-bit binaries from an x86_64 machine wouldn't do for i386, though. :-\ Hmm. Must just be my misunderstanding. From dluke at geeklair.net Wed Sep 2 11:00:09 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed, 2 Sep 2009 14:00:09 -0400 Subject: archive mode In-Reply-To: <7FEC1714-0847-411C-8C6B-3D25B129CACA@lavergne.gotdns.org> References: <7BE5D9DA-DB8B-4DF7-8C09-1F6F3E4DAD67@geeklair.net> <7FEC1714-0847-411C-8C6B-3D25B129CACA@lavergne.gotdns.org> Message-ID: On Sep 2, 2009, at 1:53 PM, Jeremy Lavergne wrote: >>> Has anyone else noticed that archive mode always places things in >>> darwin/i386 even when doing other architectures? >> >> It's probably using the arch of the build host and not the arch >> that you are building (on my ppc machine, the packages are all in / >> opt/local/var/macports/packages/darwin/powerpc/) > > ah, from `uname -m`? you mean uname -p? > I'd think that 64-bit binaries from an x86_64 machine wouldn't do > for i386, though. :-\ Hmm. Yeah, I think this could be considered a base bug. > Must just be my misunderstanding. Looks like port uses [option os.arch] for that dir (and for the package filename) -- 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 jmr at macports.org Wed Sep 2 14:31:21 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 03 Sep 2009 07:31:21 +1000 Subject: [Bulk] Re: [Bulk] Snow Leopard +universal necessity In-Reply-To: References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> Message-ID: <4A9EE429.1020800@macports.org> On 2009-9-3 03:35, William Davis wrote: > It just seems simpler to me to have port rebuild > dependents as universal whenever that was needed instead of building > them all universal, whether needed or not. Well of course that's simpler for you, but it's not simpler for whoever has to implement that feature! ;-) There is already a ticket open for this feature request: As you can see, Ryan is well aware of it. I believe he has been discussing what we can do in the meantime to mitigate these issues, not saying that these interim measures would be the ideal solution. My initial thought is that ports that can only be built for limited architectures should be checking the archs of their dependencies and giving an informative error message if they are not what's needed. - Josh From raimue at macports.org Wed Sep 2 15:10:17 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Thu, 03 Sep 2009 00:10:17 +0200 Subject: End of life for python23 Message-ID: <4A9EED49.6040805@macports.org> Hi, python23 is very old and outdated. It is a non-framework build, not supported by python_select and should not be used anymore. There are a few dependents, most of which have also not been updated in years, so I assume nobody cares anymore. nonpareil zope zopeedit gwee waitfor Martin, if you do not object I am going to remove nonpareil with the others as well. Rainer From frstan at bellsouth.net Wed Sep 2 16:33:44 2009 From: frstan at bellsouth.net (William Davis) Date: Wed, 2 Sep 2009 19:33:44 -0400 Subject: [Bulk] Re: [Bulk] Re: [Bulk] Snow Leopard +universal necessity In-Reply-To: <4A9EE429.1020800@macports.org> References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> <4A9EE429.1020800@macports.org> Message-ID: On Sep 2, 2009, at 5:31 PM, Joshua Root wrote: > On 2009-9-3 03:35, William Davis wrote: >> It just seems simpler to me to have port rebuild >> dependents as universal whenever that was needed instead of building >> them all universal, whether needed or not. > > Well of course that's simpler for you, but it's not simpler for > whoever > has to implement that feature! ;-) Yes, well, there is that aspect of it! I'm very conscious of all the work Ryan does around here, and didn't mean to sound unappreciative. > There is already a ticket open for this feature request: > > > As you can see, Ryan is well aware of it. I believe he has been > discussing what we can do in the meantime to mitigate these issues, > not > saying that these interim measures would be the ideal solution. I do see that he wasn't proposing +universal as a permanent fix . > My initial thought is that ports that can only be built for limited > architectures should be checking the archs of their dependencies and > giving an informative error message if they are not what's needed. > > - Josh To me that seems the preferable temp fix, but of course the person doing the work should have the greatest weight. William Davis frstanATbellsouthDOTnet Mac OS X ver 10.6 Darwin 10.6 XQuartz 2.3.4 (xorg-server 1.4.2-apple45) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From ryandesign at macports.org Wed Sep 2 23:03:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 3 Sep 2009 01:03:02 -0500 Subject: Snow Leopard +universal necessity In-Reply-To: <4A9EE429.1020800@macports.org> References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> <4A9EE429.1020800@macports.org> Message-ID: On Sep 2, 2009, at 16:31, Joshua Root wrote: > There is already a ticket open for this feature request: > > My initial thought is that ports that can only be built for limited > architectures should be checking the archs of their dependencies and > giving an informative error message if they are not what's needed. Until we have #20739 and related, that's what I'd like to do. What's the best way for a port to figure out the architecture of a file? Do I have to use [exec lipo -info ${prefix}/lib/some.dylib] and parse the output or is there an easier way? From ryandesign at macports.org Thu Sep 3 06:40:37 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 3 Sep 2009 08:40:37 -0500 Subject: [56907] trunk/dports/emulators/nonpareil In-Reply-To: <20090903131050.BA19E25A0B1C@beta.macosforge.org> References: <20090903131050.BA19E25A0B1C@beta.macosforge.org> Message-ID: <656079B7-0013-4E4D-8A6B-6E7DE57BFC87@macports.org> On Sep 3, 2009, at 08:10, krischik at macports.org wrote: > Revision: 56907 > http://trac.macports.org/changeset/56907 > Author: krischik at macports.org > Date: 2009-09-03 06:10:50 -0700 (Thu, 03 Sep 2009) > Log Message: > ----------- > Use Python 2.5 > Added: trunk/dports/emulators/nonpareil/files/osx.patch > =================================================================== > --- trunk/dports/emulators/nonpareil/files/ > osx.patch (rev 0) > +++ trunk/dports/emulators/nonpareil/files/osx.patch 2009-09-03 > 13:10:50 UTC (rev 56907) > +! pkg_config_cmd = '/opt/local/bin/pkg-config' > + pkg_config_cmd += ' --cflags --libs ' > + > +! sdl_pkg_config_cmd = '/opt/local/bin/sdl-config --cflags --libs' You mustn't hardcode /opt/local; you must make it use ${prefix}. From ryandesign at macports.org Thu Sep 3 07:08:36 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 3 Sep 2009 09:08:36 -0500 Subject: [56907] trunk/dports/emulators/nonpareil In-Reply-To: <21D5C130-241C-4DDA-BAEB-C21E22B5201E@krischik.com> References: <20090903131050.BA19E25A0B1C@beta.macosforge.org> <656079B7-0013-4E4D-8A6B-6E7DE57BFC87@macports.org> <21D5C130-241C-4DDA-BAEB-C21E22B5201E@krischik.com> Message-ID: <3FF21FD4-088F-463B-BABE-D5531ECACC36@macports.org> On Sep 3, 2009, at 09:05, Dipl. Inform. Martin Krischik wrote: > Am 03.09.2009 um 15:40 schrieb Ryan Schmidt: > >>> Added: trunk/dports/emulators/nonpareil/files/osx.patch >>> =================================================================== >>> --- trunk/dports/emulators/nonpareil/files/ >>> osx.patch (rev 0) >>> +++ trunk/dports/emulators/nonpareil/files/osx.patch 2009-09-03 >>> 13:10:50 UTC (rev 56907) >> >>> +! pkg_config_cmd = '/opt/local/bin/pkg-config' >>> + pkg_config_cmd += ' --cflags --libs ' >>> + >>> +! sdl_pkg_config_cmd = '/opt/local/bin/sdl-config --cflags --libs' >> >> You mustn't hardcode /opt/local; you must make it use ${prefix}. > > Damm another one escaped me. Of course that is a patch file - won't > I need to use reinplace in the pre-patch phase instead? You could use "@PREFIX@/bin" in the patch, and then reinplace @PREFIX@ with ${prefix} in post-patch. It would probably work fine without the patch, though, since ${prefix}/ bin is already in the binpath by default. Only reason to use such a patch would be if you expect users to modify the binpath -- something we don't recommend they do. From ryandesign at macports.org Thu Sep 3 08:55:51 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 3 Sep 2009 10:55:51 -0500 Subject: [56916] trunk/dports/emulators/nonpareil In-Reply-To: <20090903152227.7159E25A517D@beta.macosforge.org> References: <20090903152227.7159E25A517D@beta.macosforge.org> Message-ID: <58BE626E-12F2-427C-871C-A4B55CEB79D6@macports.org> On Sep 3, 2009, at 10:22, krischik at macports.org wrote: > + pre-patch { > + file copy ${filespath}/osx.patch ${filespath}/osx.patch.diff > + reinplace s|@PREFIX@|${prefix}|g ${filespath}/osx.patch.diff > + } You should not create or modify files in ${filespath}. Instead, just use the patch as is, and then use reinplace on the file that got patched, in the post-patch phase. From ryandesign at macports.org Thu Sep 3 10:31:27 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 3 Sep 2009 12:31:27 -0500 Subject: [56939] trunk/dports/editors/sigil/Portfile In-Reply-To: <20090903172748.3AFF125AA597@beta.macosforge.org> References: <20090903172748.3AFF125AA597@beta.macosforge.org> Message-ID: On Sep 3, 2009, at 12:27, krischik at macports.org wrote: > Revision: 56939 > http://trac.macports.org/changeset/56939 > Author: krischik at macports.org > Date: 2009-09-03 10:27:45 -0700 (Thu, 03 Sep 2009) > Log Message: > ----------- > New Version > > Modified Paths: > -------------- > trunk/dports/editors/sigil/Portfile > > Modified: trunk/dports/editors/sigil/Portfile > =================================================================== > --- trunk/dports/editors/sigil/Portfile 2009-09-03 17:24:27 UTC (rev > 56938) > +++ trunk/dports/editors/sigil/Portfile 2009-09-03 17:27:45 UTC (rev > 56939) > platform x86_64 { > pre-configure { > - reinplace "s|ppc;i386|x86_64|g" ${worksrcpath}/CMakeLists.txt > + reinplace "s|ppc;i386|x86_64|g" ${workpath}/Sigil_code_${version}/ > CMakeLists.txt > } > } There is still no such thing as "platform x86_64" in MacPorts. > platform powerpc { > pre-configure { > - reinplace "s|ppc;i386|ppc|g" ${worksrcpath}/CMakeLists.txt > + reinplace "s|ppc;i386|ppc|g" ${workpath}/Sigil_code_${version}/ > CMakeLists.txt > } > } > > platform i386 { > pre-configure { > - reinplace "s|ppc;i386|i386|g" ${worksrcpath}/CMakeLists.txt > + reinplace "s|ppc;i386|i386|g" ${workpath}/Sigil_code_${version}/ > CMakeLists.txt > } > } Now that MacPorts 1.8.0 is out, consider replacing the above with a single pre-configure block which uses ${configure.build_arch}. From jeremy at lavergne.gotdns.org Thu Sep 3 10:49:10 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 3 Sep 2009 13:49:10 -0400 Subject: [56941] trunk/dports/archivers/unnks/Portfile In-Reply-To: <20090903173221.27B3525AA853@beta.macosforge.org> References: <20090903173221.27B3525AA853@beta.macosforge.org> Message-ID: > unnks: allow glib2-devel to satisfy glib2 dependency Would it be better yet to use lib:glib-2.0:glib2 ? From ryandesign at macports.org Thu Sep 3 11:04:39 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 3 Sep 2009 13:04:39 -0500 Subject: [56941] trunk/dports/archivers/unnks/Portfile In-Reply-To: References: <20090903173221.27B3525AA853@beta.macosforge.org> Message-ID: On Sep 3, 2009, at 12:49, Jeremy Lavergne wrote: >> unnks: allow glib2-devel to satisfy glib2 dependency > > Would it be better yet to use lib:glib-2.0:glib2 ? No, because that would allow a glib2 installed outside of MacPorts to satisfy the dependency, and we don't want that. From jeremy at lavergne.gotdns.org Thu Sep 3 11:11:14 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 3 Sep 2009 14:11:14 -0400 Subject: [56941] trunk/dports/archivers/unnks/Portfile In-Reply-To: References: <20090903173221.27B3525AA853@beta.macosforge.org> Message-ID: <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> >>> unnks: allow glib2-devel to satisfy glib2 dependency >> >> Would it be better yet to use lib:glib-2.0:glib2 ? > > No, because that would allow a glib2 installed outside of MacPorts > to satisfy the dependency, and we don't want that. Why do we allow bin:...:latex? From ryandesign at macports.org Thu Sep 3 11:32:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 3 Sep 2009 13:32:42 -0500 Subject: [56941] trunk/dports/archivers/unnks/Portfile In-Reply-To: <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> References: <20090903173221.27B3525AA853@beta.macosforge.org> <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> Message-ID: On Sep 3, 2009, at 13:11, Jeremy Lavergne wrote: >>>> unnks: allow glib2-devel to satisfy glib2 dependency >>> >>> Would it be better yet to use lib:glib-2.0:glib2 ? >> >> No, because that would allow a glib2 installed outside of MacPorts >> to satisfy the dependency, and we don't want that. > > Why do we allow bin:...:latex? Because we want to allow MacTeX installed outside of MacPorts to satisfy the dependency. This is an exception to the usual rule, because TeX is hard to build and the MacPorts TeX ports tend to lag far behind TeX releases. And I'm told by those who use TeX that MacTeX is pretty good. http://trac.macports.org/ticket/20939 From jeremy at lavergne.gotdns.org Thu Sep 3 11:42:21 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 3 Sep 2009 14:42:21 -0400 Subject: [56941] trunk/dports/archivers/unnks/Portfile In-Reply-To: References: <20090903173221.27B3525AA853@beta.macosforge.org> <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> Message-ID: <72771DF3-20D5-45A1-B590-A289A6A89A95@lavergne.gotdns.org> >>>>> unnks: allow glib2-devel to satisfy glib2 dependency >>>> >>>> Would it be better yet to use lib:glib-2.0:glib2 ? >>> >>> No, because that would allow a glib2 installed outside of MacPorts >>> to satisfy the dependency, and we don't want that. >> >> Why do we allow bin:...:latex? > > Because we want to allow MacTeX installed outside of MacPorts to > satisfy the dependency. This is an exception to the usual rule, > because TeX is hard to build and the MacPorts TeX ports tend to lag > far behind TeX releases. And I'm told by those who use TeX that > MacTeX is pretty good. > > http://trac.macports.org/ticket/20939 Awesome, thanks for clearing that up :-) From dports at ambulatoryclam.net Thu Sep 3 19:35:36 2009 From: dports at ambulatoryclam.net (Dan Ports) Date: Thu, 3 Sep 2009 19:35:36 -0700 Subject: TeX (texlive) port status? In-Reply-To: References: <20090903173221.27B3525AA853@beta.macosforge.org> <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> Message-ID: <20090904023536.GF1400@ambulatoryclam.net> On Thu, Sep 03, 2009 at 01:32:42PM -0500, Ryan Schmidt wrote: > Because we want to allow MacTeX installed outside of MacPorts to > satisfy the dependency. This is an exception to the usual rule, > because TeX is hard to build and the MacPorts TeX ports tend to lag > far behind TeX releases. And I'm told by those who use TeX that MacTeX > is pretty good. On that note, what is the state of the MacPorts TeX ports? Are there major open issues? (If this question has already been beaten to death, apologies; I only started reading this list a couple weeks ago. Pointers to other threads or tickets are appreciated.) I'm a pretty heavy TeX user (what academic isn't?) and, all other things being equal, I'd prefer to stick to texlive for compatibility with my Linux/BSD systems that use it. I haven't run into any problems with the ports yet, though I only recently started using them and haven't done much serious tex hacking yet. I'd be happy to work on this a bit, although obviously how much would depend on what needs to be done and what my calendar looks like for the next couple months. Dan -- Dan R. K. Ports Research Henchman Massachusetts Institute of Technology Computer Science and Artificial Intelligence Lab From blb at macports.org Thu Sep 3 22:18:00 2009 From: blb at macports.org (Bryan Blackburn) Date: Thu, 3 Sep 2009 23:18:00 -0600 Subject: X11 etc dir Message-ID: <20090904051800.GU827@ninagal.withay.com> Should we update the xorg-cf-files port to have the /etc dir moved to ${prefix}/etc (by updating EtcX11Directory in ${prefix}/lib/X11/config/X11.tmpl)? Otherwise we have ports installing into /etc: Bryan From keybounce at gmail.com Thu Sep 3 23:49:11 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Thu, 3 Sep 2009 23:49:11 -0700 Subject: [MacPorts] #21072: Cannot force a change to +universal In-Reply-To: <1bd71ad80909032319l2866e6a4r3a5ce675c56469f2@mail.gmail.com> References: <068.f020099ad5468fcad18c55497364e584@macports.org> <077.73cfeb7d775244b96c1d8858fc5baad6@macports.org> <1bd71ad80909032308x42935391l6869416c3cd8fe36@mail.gmail.com> <1bd71ad80909032319l2866e6a4r3a5ce675c56469f2@mail.gmail.com> Message-ID: <1bd71ad80909032349s1e1ccf1ewdae52d5eb3d5ae50@mail.gmail.com> I cannot submit a change (including "re-open") on the tracker. I am responding here instead. On Thu, Sep 3, 2009 at 8:10 PM, MacPorts wrote: > #21072: Cannot force a change to +universal > -----------------------------------------------+---------------------------- > ?Reporter: ?michael-macports@? ? ? ? ? ? ? ? ?| ? ? ? Owner: ?macports-tickets@? > ? ? ?Type: ?defect ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ?Status: ?closed > ?Priority: ?Normal ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? Milestone: > ?Component: ?ports ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? Version: ?1.8.0 > Resolution: ?invalid ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?Keywords: ?--enforce-variants > ? ? ?Port: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| > -----------------------------------------------+---------------------------- > Changes (by toby@?): > > ?* status: ?new => closed > ?* resolution: ?=> invalid > > > Comment: > > ?You obviously don't need --enforce-variants when installing, since there's > ?nothing to enforce. The rest of your report is #126. > > -- > Ticket URL: > MacPorts > Ports system for Mac OS This isn't #126, and there is a need at install time. If I am installing X, and specifying +universal, then any uninstalled dependency of X also gets +universal. But existing dependencies that do not have +universal are not upgraded, and cannot be forced to upgrade. There is no current option to "Enforce the variants that I'm installing with on the child dependents". Equally, there is no way I can find to determine the complete list of currently installed dependents and the list of not-yet-installed dependents. If there was, I could just get the installed dependents, and do an upgrade --enforce-variants on them. But that is exactly what I want -- when installing X +universal, any not-yet-installed dependents get installed with +universal, and any already-installed dependents get upgrade --enforce-variants. This is something that is "trivial" (for some value of trivial) for the code to do as it does the install and dependency check, and very, very time consuming/painful for humans to do. Nor is it easy to uninstall things. As in, uninstall all the dependencies to re-install them. All it takes is one other program using them (very very common on some low-level libraries). #126 -- 7 years??? -- would address the issue of "If I'm installed with +darwin9, then I need X installed with +darwin". It does nothing to address the "I'm going in as +universal, now that one needs to be changed to +universal. I'm going in as +darwin, now that one needs to be changed to +darwin". In a very serious vein, it is (more than) conceivable that you may need a given library in two different variants for two different programs; the library in question should appears twice in the file system, in two different locations, with different names. That isn't a MacPort issue -- that's a general flawed unix file system layout issue -- /usr/lib/library.a should be /usr/lib//library.a, and searching the libraries should be sufficiently smarter :-). Put it this way: If you say that there is no need for this, then please tell me how I can easily get my relevant installed ports to be upgraded to +universal? Please do not say "sudo port upgrade --enforce-variant +universal installed" -- that will upgrade everything under the sun to universal, even the things that are perfectly fine as PPC only. From audiodude at gmail.com Fri Sep 4 01:15:22 2009 From: audiodude at gmail.com (Travis Briggs) Date: Fri, 4 Sep 2009 04:15:22 -0400 Subject: TeX (texlive) port status? In-Reply-To: <20090904023536.GF1400@ambulatoryclam.net> References: <20090903173221.27B3525AA853@beta.macosforge.org> <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> <20090904023536.GF1400@ambulatoryclam.net> Message-ID: <76e7b5990909040115j3a5856d1n11d3ffa3077e3daf@mail.gmail.com> > On that note, what is the state of the MacPorts TeX ports? FWIW, I just installed texlive in MacPorts prior to compiling GNU Lilypond from source. Lilypond heavily relies on metafont for its custom music notation fonts. Everything is working correctly at the moment for me. -Travis On Thu, Sep 3, 2009 at 10:35 PM, Dan Ports wrote: > On Thu, Sep 03, 2009 at 01:32:42PM -0500, Ryan Schmidt wrote: >> Because we want to allow MacTeX installed outside of MacPorts to >> satisfy the dependency. This is an exception to the usual rule, >> because TeX is hard to build and the MacPorts TeX ports tend to lag >> far behind TeX releases. And I'm told by those who use TeX that MacTeX >> is pretty good. > > ?On that note, what is the state of the MacPorts TeX ports? Are there > major open issues? (If this question has already been beaten to death, > apologies; I only started reading this list a couple weeks ago. > Pointers to other threads or tickets are appreciated.) > > ?I'm a pretty heavy TeX user (what academic isn't?) and, all other > things being equal, I'd prefer to stick to texlive for compatibility > with my Linux/BSD systems that use it. I haven't run into any problems > with the ports yet, though I only recently started using them and > haven't done much serious tex hacking yet. > > ?I'd be happy to work on this a bit, although obviously how much would > depend on what needs to be done and what my calendar looks like for the > next couple months. > > ?Dan > > -- > Dan R. K. Ports ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > Research Henchman > Massachusetts Institute of Technology ? ? ? ? ? ? ? ? ? ? > Computer Science and Artificial Intelligence Lab ? ? > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From milosh at macports.org Fri Sep 4 02:04:15 2009 From: milosh at macports.org (Emmanuel Hainry) Date: Fri, 4 Sep 2009 11:04:15 +0200 Subject: TeX (texlive) port status? In-Reply-To: <20090904023536.GF1400@ambulatoryclam.net> References: <20090903173221.27B3525AA853@beta.macosforge.org> <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> <20090904023536.GF1400@ambulatoryclam.net> Message-ID: <20090904090415.GB16833@weetamoe.loria.fr> Citando Dan Ports : > On Thu, Sep 03, 2009 at 01:32:42PM -0500, Ryan Schmidt wrote: > > Because we want to allow MacTeX installed outside of MacPorts to > > satisfy the dependency. This is an exception to the usual rule, > > because TeX is hard to build and the MacPorts TeX ports tend to lag > > far behind TeX releases. And I'm told by those who use TeX that MacTeX > > is pretty good. > > On that note, what is the state of the MacPorts TeX ports? Are there > major open issues? (If this question has already been beaten to death, > apologies; I only started reading this list a couple weeks ago. > Pointers to other threads or tickets are appreciated.) Texlive in macports is version 2007. It is lagging behind upstream as 2008 is the current release and 2009 is in pretesting. The status of texlive in macports is summed up in http://trac.macports.org/ticket/16492 There has been no change since that (apart from the fact that I have abandoned the texlive port since). > I'm a pretty heavy TeX user (what academic isn't?) and, all other > things being equal, I'd prefer to stick to texlive for compatibility > with my Linux/BSD systems that use it. I haven't run into any problems > with the ports yet, though I only recently started using them and > haven't done much serious tex hacking yet. Texlive 2007 is working well. It is not the latest version, but you probably don't need the latest version (I don't). Note that the debian texlive package is also still 2007. The preferred (by texlive) distribution of texlive for macosx is mactex, which is uptodate, contains great apps and is configured to work out of the box. And which may be recognised by macports as filling the dependency for tex... > I'd be happy to work on this a bit, although obviously how much would > depend on what needs to be done and what my calendar looks like for the > next couple months. The texlive port is orphaned (has no maintainer) so anybody interested in updating it can adopt it. Emmanuel From toby at macports.org Fri Sep 4 03:15:59 2009 From: toby at macports.org (Toby Peterson) Date: Fri, 4 Sep 2009 03:15:59 -0700 Subject: [MacPorts] #21072: Cannot force a change to +universal In-Reply-To: <1bd71ad80909032349s1e1ccf1ewdae52d5eb3d5ae50@mail.gmail.com> References: <068.f020099ad5468fcad18c55497364e584@macports.org> <077.73cfeb7d775244b96c1d8858fc5baad6@macports.org> <1bd71ad80909032308x42935391l6869416c3cd8fe36@mail.gmail.com> <1bd71ad80909032319l2866e6a4r3a5ce675c56469f2@mail.gmail.com> <1bd71ad80909032349s1e1ccf1ewdae52d5eb3d5ae50@mail.gmail.com> Message-ID: <74c219d30909040315vfc5e3c1t5aff292c0829c4c5@mail.gmail.com> On Thu, Sep 3, 2009 at 23:49, Michael_google gmail_Gersten wrote: > I cannot submit a change (including "re-open") on the tracker. I am > responding here instead. > > On Thu, Sep 3, 2009 at 8:10 PM, MacPorts wrote: >> #21072: Cannot force a change to +universal >> -----------------------------------------------+---------------------------- >> ?Reporter: ?michael-macports@? ? ? ? ? ? ? ? ?| ? ? ? Owner: ?macports-tickets@? >> ? ? ?Type: ?defect ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ?Status: ?closed >> ?Priority: ?Normal ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? Milestone: >> ?Component: ?ports ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? Version: ?1.8.0 >> Resolution: ?invalid ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?Keywords: ?--enforce-variants >> ? ? ?Port: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| >> -----------------------------------------------+---------------------------- >> Changes (by toby@?): >> >> ?* status: ?new => closed >> ?* resolution: ?=> invalid >> >> >> Comment: >> >> ?You obviously don't need --enforce-variants when installing, since there's >> ?nothing to enforce. The rest of your report is #126. >> >> -- >> Ticket URL: >> MacPorts >> Ports system for Mac OS > > This isn't #126, and there is a need at install time. > > If I am installing X, and specifying +universal, then any uninstalled > dependency of X also gets +universal. But existing dependencies that > do not have +universal are not upgraded, and cannot be forced to > upgrade. There is no current option to "Enforce the variants that I'm > installing with on the child dependents". > > Equally, there is no way I can find to determine the complete list of > currently installed dependents and the list of not-yet-installed > dependents. If there was, I could just get the installed dependents, > and do an upgrade --enforce-variants on them. > > But that is exactly what I want -- when installing X +universal, any > not-yet-installed dependents get installed with +universal, and any > already-installed dependents get upgrade --enforce-variants. > > This is something that is "trivial" (for some value of trivial) for > the code to do as it does the install and dependency check, and very, > very time consuming/painful for humans to do. > > Nor is it easy to uninstall things. As in, uninstall all the > dependencies to re-install them. All it takes is one other program > using them (very very common on some low-level libraries). > > #126 -- 7 years??? -- would address the issue of "If I'm installed > with +darwin9, then I need X installed with +darwin". It does nothing > to address the "I'm going in as +universal, now that one needs to be > changed to +universal. I'm going in as +darwin, now that one needs to > be changed to +darwin". > > In a very serious vein, it is (more than) conceivable that you may > need a given library in two different variants for two different > programs; the library in question should appears twice in the file > system, in two different locations, with different names. That isn't a > MacPort issue -- that's a general flawed unix file system layout issue > -- /usr/lib/library.a should be /usr/lib//library.a, and > searching the libraries should be sufficiently smarter :-). > > Put it this way: If you say that there is no need for this, then > please tell me how I can easily get my relevant installed ports to be > upgraded to +universal? Please do not say "sudo port upgrade > --enforce-variant +universal installed" -- that will upgrade > everything under the sun to universal, even the things that are > perfectly fine as PPC only. You happen to be running into a variety of related issues. A short (but incomplete) list: (1) ports cannot specify the archs they actually support (2) we do not record the built archs in the registry (3) +universal shouldn't be a variant (4) +universal doesn't necessarily mean the same thing in all situations (due to a number of broken ports, as well as possible configuration changes - see #2) And so on... basically, what you're asking for requires some pretty significant infrastructure overhauls - realistically, it's something that won't happen until we manage to gather the willpower required to almost entirely rewrite MacPorts. >From your point of view, I can see why you might think these changes are easy (NOT trivial, look it up), but you'd be wrong. - Toby From mnick at macports.org Fri Sep 4 03:48:02 2009 From: mnick at macports.org (Maximilian Nickel) Date: Fri, 4 Sep 2009 12:48:02 +0200 Subject: TeX (texlive) port status? In-Reply-To: <20090904090415.GB16833@weetamoe.loria.fr> References: <20090903173221.27B3525AA853@beta.macosforge.org> <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> <20090904023536.GF1400@ambulatoryclam.net> <20090904090415.GB16833@weetamoe.loria.fr> Message-ID: <7bad5d350909040348s6ea027ecy85fe9062b6048363@mail.gmail.com> On Fri, Sep 4, 2009 at 11:04 AM, Emmanuel Hainry wrote: > The texlive port is orphaned (has no maintainer) so anybody interested > in updating it can adopt it. The problem here is, that the old texlive_* ports followed the OpenBSD layout and had the distinction between texlive_texmf-minimal and -full. Unfortunatly since the 2008 release there are no -minimal/-full tarballs anymore, just one big texmf tarball. It seems unreasonable to me to fetch 890+MB and then just copy some part of it into destroot, as it would be the case for texmf-minimal. The options i see are 1) stick with current distinction, fetch whole distribution and just copy the parts into destroot that are needed 2) stick with current distinction and provide -minimal/-full tarballs 3) drop -minmal and rename -full to texlive_texm Max From milosh at macports.org Fri Sep 4 04:32:36 2009 From: milosh at macports.org (Emmanuel Hainry) Date: Fri, 4 Sep 2009 13:32:36 +0200 Subject: TeX (texlive) port status? In-Reply-To: <7bad5d350909040348s6ea027ecy85fe9062b6048363@mail.gmail.com> References: <20090903173221.27B3525AA853@beta.macosforge.org> <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> <20090904023536.GF1400@ambulatoryclam.net> <20090904090415.GB16833@weetamoe.loria.fr> <7bad5d350909040348s6ea027ecy85fe9062b6048363@mail.gmail.com> Message-ID: <20090904113236.GA23002@weetamoe.loria.fr> Citando Maximilian Nickel : > > On Fri, Sep 4, 2009 at 11:04 AM, Emmanuel Hainry wrote: > > The texlive port is orphaned (has no maintainer) so anybody interested > > in updating it can adopt it. > > The problem here is, that the old texlive_* ports followed the OpenBSD > layout and had the distinction between texlive_texmf-minimal and > -full. Unfortunatly since the 2008 release there are no -minimal/-full > tarballs anymore, just one big texmf tarball. > It seems unreasonable to me to fetch 890+MB and then just copy some > part of it into destroot, as it would be the case for texmf-minimal. > The options i see are > > 1) stick with current distinction, fetch whole distribution and just > copy the parts into destroot that are needed > 2) stick with current distinction and provide -minimal/-full tarballs > 3) drop -minmal and rename -full to texlive_texm > My goal was the second point. As we have distfile mirrors now, it should not have been a problem to distribute our own tarballs. But before that, making the whole thing compile* was needed. Note that there is yet another solution which is install precompiled binaries as they come with mactex instead of compiling as texlive_base does. Problem is, it installs in /usr/texbin and is probably not flexible about that. *: and not step over other ports as ps2eps, t1utils, xdvipdfmx, ... and install in destroot properly. Emmanuel From ryandesign at macports.org Fri Sep 4 05:21:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 4 Sep 2009 07:21:29 -0500 Subject: TeX (texlive) port status? In-Reply-To: <20090904113236.GA23002@weetamoe.loria.fr> References: <20090903173221.27B3525AA853@beta.macosforge.org> <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> <20090904023536.GF1400@ambulatoryclam.net> <20090904090415.GB16833@weetamoe.loria.fr> <7bad5d350909040348s6ea027ecy85fe9062b6048363@mail.gmail.com> <20090904113236.GA23002@weetamoe.loria.fr> Message-ID: On Sep 4, 2009, at 06:32, Emmanuel Hainry wrote: > Note that there is yet another solution which is install precompiled > binaries as they come with mactex instead of compiling as texlive_base > does. Problem is, it installs in /usr/texbin and is probably not > flexible about that. These kinds of things can sometimes be fixed retroactively using install_name_tool. See the oracle-instantclient port for an example of this. From ryandesign at macports.org Fri Sep 4 05:54:50 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 4 Sep 2009 07:54:50 -0500 Subject: X11 etc dir In-Reply-To: <20090904051800.GU827@ninagal.withay.com> References: <20090904051800.GU827@ninagal.withay.com> Message-ID: <2D773EAD-3975-487D-A7F9-15DE2A74BB20@macports.org> On Sep 4, 2009, at 00:18, Bryan Blackburn wrote: > Should we update the xorg-cf-files port to have the /etc dir moved to > ${prefix}/etc (by updating EtcX11Directory in > ${prefix}/lib/X11/config/X11.tmpl)? Otherwise we have ports > installing into > /etc: > > That sounds like a good idea to me. From jeremy at lavergne.gotdns.org Fri Sep 4 07:13:18 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 4 Sep 2009 10:13:18 -0400 Subject: replaced_by question Message-ID: <750C4614-0F70-4212-958E-16E06D5E61D9@lavergne.gotdns.org> Why don't we block the installation of ports that have replaced_by set? http://trac.macports.org/changeset/57005 I just wrote our first replaced_by and it shows up in port outdated if it's revision 1 you have installed and run upgrade, but you can install this revision 2 and then it never shows up as outdated and won't get replaced. How about the following ideas: * anytime replaced_by is found, it's epoch_override is turned on * if installing a port that has replaced_by, fail (or just switch it out for the replacement) From keybounce at gmail.com Fri Sep 4 09:55:53 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Fri, 4 Sep 2009 09:55:53 -0700 Subject: [MacPorts] #21072: Cannot force a change to +universal In-Reply-To: <74c219d30909040315vfc5e3c1t5aff292c0829c4c5@mail.gmail.com> References: <068.f020099ad5468fcad18c55497364e584@macports.org> <077.73cfeb7d775244b96c1d8858fc5baad6@macports.org> <1bd71ad80909032308x42935391l6869416c3cd8fe36@mail.gmail.com> <1bd71ad80909032319l2866e6a4r3a5ce675c56469f2@mail.gmail.com> <1bd71ad80909032349s1e1ccf1ewdae52d5eb3d5ae50@mail.gmail.com> <74c219d30909040315vfc5e3c1t5aff292c0829c4c5@mail.gmail.com> Message-ID: <1bd71ad80909040955i50af9f1u6156c248ff7884f5@mail.gmail.com> > From your point of view, I can see why you might think these changes > are easy (NOT trivial, look it up), but you'd be wrong. > > - Toby Fair enough. Can you tell me what I can do in this situation? For example, is there any way to get a full list of the dependencies needed for a given package, separated into "These are installed (and may be upgraded)" and "These are not installed (and will cause an error if you try to upgrade, but will install without problem)"? From ryandesign at macports.org Fri Sep 4 10:39:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 4 Sep 2009 12:39:05 -0500 Subject: [MacPorts] #21072: Cannot force a change to +universal In-Reply-To: <1bd71ad80909040955i50af9f1u6156c248ff7884f5@mail.gmail.com> References: <068.f020099ad5468fcad18c55497364e584@macports.org> <077.73cfeb7d775244b96c1d8858fc5baad6@macports.org> <1bd71ad80909032308x42935391l6869416c3cd8fe36@mail.gmail.com> <1bd71ad80909032319l2866e6a4r3a5ce675c56469f2@mail.gmail.com> <1bd71ad80909032349s1e1ccf1ewdae52d5eb3d5ae50@mail.gmail.com> <74c219d30909040315vfc5e3c1t5aff292c0829c4c5@mail.gmail.com> <1bd71ad80909040955i50af9f1u6156c248ff7884f5@mail.gmail.com> Message-ID: On Sep 4, 2009, at 11:55, Michael_google gmail_Gersten wrote: > > For example, is there any way to get a full list of the dependencies > needed for a given package, port-rdeps does this. http://trac.macports.org/browser/contrib/port-rdeps/ For example, the dependencies of php5: $ port-rdeps -r php5 Dependencies of php5: gsed gettext libiconv gperf ncurses ncursesw expat libtool automake perl5 perl5.8 autoconf m4 help2man p5-locale-gettext libxml2 zlib bzip2 mhash pcre readline apache2 apr apr-util db46 sqlite3 openssl pkgconfig autoconf213 gawk $ > separated into "These are installed (and > may be upgraded)" and "These are not installed (and will cause an > error if you try to upgrade, but will install without problem)"? Not directly, but you can use port-rdeps in a clever series of pipes and subshells to achieve this. For example, here I echo the dependencies of php5 that I already installed: $ port echo installed and \( $(port-rdeps -r php5 | sed 1d) \) autoconf @2.64_2 automake @1.11_0+universal bzip2 @1.0.5_2+darwin+universal expat @2.0.1_0+universal gettext @0.17_4+universal gperf @3.0.4_0+universal help2man @1.36.4_1+universal libiconv @1.13_0+universal libtool @2.2.6a_0+universal libxml2 @2.7.3_0+universal m4 @1.4.13_0+universal mhash @0.9.9.9_0+universal ncurses @5.7_0+darwin_10+universal ncursesw @5.7_0+darwin_10+universal openssl @0.9.8k_0+darwin+universal p5-locale-gettext @1.05_0 pcre @7.9_0+universal perl5 @5.8.9_0 perl5.8 @5.8.9_3 pkgconfig @0.23_1+universal readline @6.0.000_1+darwin+universal zlib @1.2.3_2+universal $ And here, the dependencies of php5 that are not installed on my system: $ port echo not installed and \( $(port-rdeps -r php5 | sed 1d) \) apache2 apr apr-util autoconf213 db46 gawk gsed sqlite3 $ Instead of "port echo" I could have used any other port command, such as "port install" or "port upgrade", and I could add variants at the end. I already have the universal variant selected for all the installed dependencies of php5, but if I hadn't, I could rebuild them with that variant by using (I think -- I haven't tested): port upgrade --enforce-variants installed and \( $(port-rdeps -r php5 | sed 1d) \) +universal From ryandesign at macports.org Fri Sep 4 13:28:33 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 4 Sep 2009 15:28:33 -0500 Subject: [MacPorts] #21072: Cannot force a change to +universal In-Reply-To: <1bd71ad80909041318s6f96b85blf91310dced9926f5@mail.gmail.com> References: <068.f020099ad5468fcad18c55497364e584@macports.org> <077.73cfeb7d775244b96c1d8858fc5baad6@macports.org> <1bd71ad80909032308x42935391l6869416c3cd8fe36@mail.gmail.com> <1bd71ad80909032319l2866e6a4r3a5ce675c56469f2@mail.gmail.com> <1bd71ad80909032349s1e1ccf1ewdae52d5eb3d5ae50@mail.gmail.com> <74c219d30909040315vfc5e3c1t5aff292c0829c4c5@mail.gmail.com> <1bd71ad80909040955i50af9f1u6156c248ff7884f5@mail.gmail.com> <1bd71ad80909041318s6f96b85blf91310dced9926f5@mail.gmail.com> Message-ID: <5E9D7E57-E607-451C-A0D1-645E55FDD82D@macports.org> On Sep 4, 2009, at 15:18, Michael_google gmail_Gersten wrote: >> I already have the universal variant selected for all the installed >> dependencies of php5, but if I hadn't, I could rebuild them with that >> variant by using (I think -- I haven't tested): >> >> >> port upgrade --enforce-variants installed and \( $(port-rdeps -r >> php5 | sed >> 1d) \) +universal > > I tested; it didn't work. > > Kleiman-ibook:Development michael$ sudo port upgrade > --enforce-variants installed and \( $(port-rdeps -r gtkglext | sed 1d) > \) +universal > Password: > Can't map the URL 'file://.' to a port description file ("Could not > find Portfile in /Users/michael/Documents/Development"). > Please verify that the directory and portfile syntax are correct. > Error: A default port name could not be supplied. > ---> Computing dependencies for p5-locale-gettext > ---> Fetching p5-locale-gettext > ---> Verifying checksum(s) for p5-locale-gettext > ---> Extracting p5-locale-gettext > ---> Applying patches to p5-locale-gettext > ---> Configuring p5-locale-gettext > ---> Building p5-locale-gettext > ---> Staging p5-locale-gettext into destroot > ---> Deactivating p5-locale-gettext @1.05_0+universal > ---> Computing dependencies for p5-locale-gettext > ---> Installing p5-locale-gettext @1.05_0 > ---> Activating p5-locale-gettext @1.05_0 > ---> Cleaning p5-locale-gettext > Error: is not installed > Kleiman-ibook:Development michael$ You did first download port-rdeps and put it somewhere in your PATH and make sure it works? If so, what does port-rdeps -r gtkglext say? If that works, what does port echo installed and \( $(port-rdeps -r gtkglext | sed 1d) say? From keybounce at gmail.com Fri Sep 4 14:11:39 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Fri, 4 Sep 2009 14:11:39 -0700 Subject: [MacPorts] #21072: Cannot force a change to +universal In-Reply-To: <5E9D7E57-E607-451C-A0D1-645E55FDD82D@macports.org> References: <068.f020099ad5468fcad18c55497364e584@macports.org> <077.73cfeb7d775244b96c1d8858fc5baad6@macports.org> <1bd71ad80909032308x42935391l6869416c3cd8fe36@mail.gmail.com> <1bd71ad80909032319l2866e6a4r3a5ce675c56469f2@mail.gmail.com> <1bd71ad80909032349s1e1ccf1ewdae52d5eb3d5ae50@mail.gmail.com> <74c219d30909040315vfc5e3c1t5aff292c0829c4c5@mail.gmail.com> <1bd71ad80909040955i50af9f1u6156c248ff7884f5@mail.gmail.com> <1bd71ad80909041318s6f96b85blf91310dced9926f5@mail.gmail.com> <5E9D7E57-E607-451C-A0D1-645E55FDD82D@macports.org> Message-ID: <1bd71ad80909041411n193d0e8dse66218db63dc8f2d@mail.gmail.com> > If so, what does > > ? ? ? ?port-rdeps -r gtkglext > > say? Dependencies of gtkglext: mesa xorg-glproto xorg-dri2proto xorg-libXfixes xorg-libX11 xorg-libXdmcp xorg-xproto pkgconfig xorg-libXau xorg-bigreqsproto xorg-xcmiscproto xorg-xextproto xorg-xf86bigfontproto xorg-inputproto xorg-kbproto xorg-xtrans libtool automake perl5 perl5.8 autoconf m4 help2man p5-locale-gettext gettext libiconv gperf ncurses ncursesw expat xorg-util-macros xorg-fixesproto xorg-libXi xorg-libXext xorg-libXmu xorg-libXt xorg-libsm xorg-libice makedepend glut tcl gtk2 cairo libpixman xrender xorg-renderproto fontconfig freetype zlib libpng glib2 python_select jpeg tiff jasper atk pango Xft2 xorg-libXrandr xorg-randrproto xorg-libXcursor xorg-libXinerama xorg-xineramaproto xorg-libXdamage xorg-damageproto xorg-libXcomposite xorg-compositeproto shared-mime-info libxml2 p5-xml-parser intltool p5-getopt-long p5-pathtools p5-scalar-list-utils gnome-common Wait ... libtool requires automake and autoconf? I can understand saying "We need these to compile", but ... The Mesa library requires xorg-libXfixes; that requires xorg-libX11. Fine. It seems a little bloated in this case (distributing libX11, when it's likely already there?), but not completely unreasonable (different versions of what I'm assuming is a toolkit for using the X server). But libX11 claims to require libtool, for creating and playing with archives? ... but libtool then needs to have automake and autoconf around to to run??? And glib2 -- gnu C library -- requires python select? You need to change python to use the library?? Are those dependencies overkill? > If that works, what does > > ? ? ? ?port echo installed and \( $(port-rdeps -r gtkglext | sed 1d) > > say? atk @1.26.0_1+universal autoconf @2.63_0+universal autoconf @2.64_2 automake @1.10.2_0+universal automake @1.11_0+universal cairo @1.8.8_0+macosx+universal expat @2.0.1_0+universal fontconfig @2.7.1_0+macosx fontconfig @2.7.2_0+macosx fontconfig @2.7.2_0+macosx+universal freetype @2.3.8_0+macosx+universal freetype @2.3.9_0+macosx+universal gettext @0.17_4+universal glib2 @2.20.4_0+darwin+universal gperf @3.0.4_0+universal help2man @1.36.4_1+universal jasper @1.900.1_4+universal jpeg @6b_3+universal libiconv @1.12_2+universal libiconv @1.13_0+universal libpixman @0.16.0_0+universal libpng @1.2.35_0+universal libpng @1.2.38_0+universal libtool @2.2.6a_0+universal m4 @1.4.12_1+universal m4 @1.4.13_0+universal ncurses @5.7_0+universal ncursesw @5.7_0+universal p5-locale-gettext @1.05_0 p5-locale-gettext @1.05_0+universal perl5 @5.8.9_0 perl5.8 @5.8.9_2 perl5.8 @5.8.9_3 pkgconfig @0.23_1+universal python_select @0.2.1_0+darwin_9 tcl @8.5.6_0+darwin Xft2 @2.1.13_2 xorg-bigreqsproto @1.0.2_0 xorg-bigreqsproto @1.1.0_0 xorg-inputproto @1.5.0_0 xorg-inputproto @1.5.1_0 xorg-kbproto @1.0.3_0 xorg-libX11 @1.2_0+universal xorg-libX11 @1.2.2_0+universal xorg-libXau @1.0.4_0+universal xorg-libXau @1.0.5_0+universal xorg-libXdmcp @1.0.2_0+universal xorg-libXdmcp @1.0.2_1+universal xorg-libXext @1.0.5_0+universal xorg-libXext @1.0.99.4_1+universal xorg-libXrandr @1.2.3_0+universal xorg-libXrandr @1.3.0_1+universal xorg-randrproto @1.2.1_0 xorg-randrproto @1.3.0_0 xorg-renderproto @0.9.3_0 xorg-renderproto @0.11_0 xorg-util-macros @1.2.2_0 xorg-xcmiscproto @1.1.2_0 xorg-xcmiscproto @1.2.0_0 xorg-xextproto @7.0.5_0 xorg-xextproto @7.1.1_0 xorg-xf86bigfontproto @1.1.2_0 xorg-xf86bigfontproto @1.2.0_0 xorg-xproto @7.0.14_1 xorg-xproto @7.0.15_0 xorg-xtrans @1.2.3_0 xorg-xtrans @1.2.4_0 xrender @0.9.4_5+universal xrender @0.9.4_6+universal zlib @1.2.3_2+universal Now, I did come up with the idea of filtering out the non-universals. That lead to a file looking like: Kleiman-ibook:Development michael$ head Lacking2 autoconf fontconfig fontconfig p5-locale-gettext perl5 perl5.8 perl5.8 python_select tcl Xft2 And a second file looking like Kleiman-ibook:Development michael$ head -5 Wanted autoconf +universal fontconfig +universal fontconfig +universal p5-locale-gettext +universal perl5 +universal And a command line looking like Kleiman-ibook:Development michael$ echo sudo port upgrade --enforce-variants `cat Wanted` which expanded to sudo port upgrade --enforce-variants autoconf +universal fontconfig +universal fontconfig +universal p5-locale-gettext +universal perl5 +universal perl5.8 +universal perl5.8 +universal python_select +universal tcl +universal Xft2 +universal xorg-bigreqsproto +universal xorg-bigreqsproto +universal xorg-inputproto +universal xorg-inputproto +universal xorg-kbproto +universal xorg-randrproto +universal xorg-randrproto +universal xorg-renderproto +universal xorg-renderproto +universal xorg-util-macros +universal xorg-xcmiscproto +universal xorg-xcmiscproto +universal xorg-xextproto +universal xorg-xextproto +universal xorg-xf86bigfontproto +universal xorg-xf86bigfontproto +universal xorg-xproto +universal xorg-xproto +universal xorg-xtrans +universal xorg-xtrans +universal Which looks correct to me. And it works. Seems to, anyways. On the third package now. From keybounce at gmail.com Fri Sep 4 14:35:37 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Fri, 4 Sep 2009 14:35:37 -0700 Subject: [MacPorts] #21072: Cannot force a change to +universal In-Reply-To: <1bd71ad80909041411n193d0e8dse66218db63dc8f2d@mail.gmail.com> References: <068.f020099ad5468fcad18c55497364e584@macports.org> <1bd71ad80909032308x42935391l6869416c3cd8fe36@mail.gmail.com> <1bd71ad80909032319l2866e6a4r3a5ce675c56469f2@mail.gmail.com> <1bd71ad80909032349s1e1ccf1ewdae52d5eb3d5ae50@mail.gmail.com> <74c219d30909040315vfc5e3c1t5aff292c0829c4c5@mail.gmail.com> <1bd71ad80909040955i50af9f1u6156c248ff7884f5@mail.gmail.com> <1bd71ad80909041318s6f96b85blf91310dced9926f5@mail.gmail.com> <5E9D7E57-E607-451C-A0D1-645E55FDD82D@macports.org> <1bd71ad80909041411n193d0e8dse66218db63dc8f2d@mail.gmail.com> Message-ID: <1bd71ad80909041435m69fa0d4bof96ae609a44f6c4c@mail.gmail.com> > which expanded to > > sudo port upgrade --enforce-variants autoconf +universal fontconfig > +universal fontconfig +universal p5-locale-gettext +universal perl5 > +universal perl5.8 +universal perl5.8 +universal python_select > +universal tcl +universal Xft2 +universal xorg-bigreqsproto +universal > xorg-bigreqsproto +universal xorg-inputproto +universal > xorg-inputproto +universal xorg-kbproto +universal xorg-randrproto > +universal xorg-randrproto +universal xorg-renderproto +universal > xorg-renderproto +universal xorg-util-macros +universal > xorg-xcmiscproto +universal xorg-xcmiscproto +universal xorg-xextproto > +universal xorg-xextproto +universal xorg-xf86bigfontproto +universal > xorg-xf86bigfontproto +universal xorg-xproto +universal xorg-xproto > +universal xorg-xtrans +universal xorg-xtrans +universal > > Which looks correct to me. > > And it works. Seems to, anyways. On the third package now. Sadly, it only did three packages -- python_select, tcl, and Xft2. The others were ignored. Anyone see what I'm missing? From ryandesign at macports.org Fri Sep 4 14:42:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 4 Sep 2009 16:42:40 -0500 Subject: [MacPorts] #21072: Cannot force a change to +universal In-Reply-To: <1bd71ad80909041411n193d0e8dse66218db63dc8f2d@mail.gmail.com> References: <068.f020099ad5468fcad18c55497364e584@macports.org> <077.73cfeb7d775244b96c1d8858fc5baad6@macports.org> <1bd71ad80909032308x42935391l6869416c3cd8fe36@mail.gmail.com> <1bd71ad80909032319l2866e6a4r3a5ce675c56469f2@mail.gmail.com> <1bd71ad80909032349s1e1ccf1ewdae52d5eb3d5ae50@mail.gmail.com> <74c219d30909040315vfc5e3c1t5aff292c0829c4c5@mail.gmail.com> <1bd71ad80909040955i50af9f1u6156c248ff7884f5@mail.gmail.com> <1bd71ad80909041318s6f96b85blf91310dced9926f5@mail.gmail.com> <5E9D7E57-E607-451C-A0D1-645E55FDD82D@macports.org> <1bd71ad80909041411n193d0e8dse66218db63dc8f2d@mail.gmail.com> Message-ID: <3DDA08F8-9BBE-4928-84F0-602BF8EC879F@macports.org> On Sep 4, 2009, at 16:11, Michael_google gmail_Gersten wrote: >> If so, what does >> >> port-rdeps -r gtkglext >> >> say? > > Dependencies of gtkglext: > mesa > xorg-glproto > xorg-dri2proto > xorg-libXfixes > xorg-libX11 > xorg-libXdmcp > xorg-xproto > pkgconfig > xorg-libXau > xorg-bigreqsproto > xorg-xcmiscproto > xorg-xextproto > xorg-xf86bigfontproto > xorg-inputproto > xorg-kbproto > xorg-xtrans > libtool > automake > perl5 > perl5.8 > autoconf > m4 > help2man > p5-locale-gettext > gettext > libiconv > gperf > ncurses > ncursesw > expat > xorg-util-macros > xorg-fixesproto > xorg-libXi > xorg-libXext > xorg-libXmu > xorg-libXt > xorg-libsm > xorg-libice > makedepend > glut > tcl > gtk2 > cairo > libpixman > xrender > xorg-renderproto > fontconfig > freetype > zlib > libpng > glib2 > python_select > jpeg > tiff > jasper > atk > pango > Xft2 > xorg-libXrandr > xorg-randrproto > xorg-libXcursor > xorg-libXinerama > xorg-xineramaproto > xorg-libXdamage > xorg-damageproto > xorg-libXcomposite > xorg-compositeproto > shared-mime-info > libxml2 > p5-xml-parser > intltool > p5-getopt-long > p5-pathtools > p5-scalar-list-utils > gnome-common Ok, port-rdeps appears to be functioning properly. > Wait ... libtool requires automake and autoconf? I can understand > saying "We need these to compile", but ... libtool needs automake to build. automake needs autoconf to build. They do not need these to run. MacPorts distinguishes between different types of dependencies but port-rdeps does not. From the comment block at the top of the script: # Todo: # Does not differentiate, in output, between bin/lib/run type dependencies > The Mesa library requires xorg-libXfixes; that requires xorg-libX11. > Fine. It seems a little bloated in this case (distributing libX11, > when it's likely already there?), but not completely unreasonable > (different versions of what I'm assuming is a toolkit for using the X > server). MacPorts uses its own copy of X, not the system's. This is consistent with MacPorts policy of using its own software, not system software. This prevents problems when Apple decides to update its software, and also makes the MacPorts experience more consistent across different versions of Mac OS X. The versions of X in Tiger and Leopard are drastically different from one another, for example, and this was a frequent cause of problems before we started using X in MacPorts instead. > But libX11 claims to require libtool, for creating and playing with > archives? ... but libtool then needs to have automake and autoconf > around to to run??? xorg-libX11 needs libtool to build only. > And glib2 -- gnu C library -- requires python select? You need to > change python to use the library?? Because: http://trac.macports.org/ticket/17530 > Are those dependencies overkill? > >> If that works, what does >> >> port echo installed and \( $(port-rdeps -r gtkglext | sed 1d) >> >> say? > > atk @1.26.0_1+universal > autoconf @2.63_0+universal > autoconf @2.64_2 > automake @1.10.2_0+universal > automake @1.11_0+universal > cairo @1.8.8_0+macosx+universal > expat @2.0.1_0+universal > fontconfig @2.7.1_0+macosx > fontconfig @2.7.2_0+macosx > fontconfig @2.7.2_0+macosx+universal > freetype @2.3.8_0+macosx+universal > freetype @2.3.9_0+macosx+universal > gettext @0.17_4+universal > glib2 @2.20.4_0+darwin+universal > gperf @3.0.4_0+universal > help2man @1.36.4_1+universal > jasper @1.900.1_4+universal > jpeg @6b_3+universal > libiconv @1.12_2+universal > libiconv @1.13_0+universal > libpixman @0.16.0_0+universal > libpng @1.2.35_0+universal > libpng @1.2.38_0+universal > libtool @2.2.6a_0+universal > m4 @1.4.12_1+universal > m4 @1.4.13_0+universal > ncurses @5.7_0+universal > ncursesw @5.7_0+universal > p5-locale-gettext @1.05_0 > p5-locale-gettext @1.05_0+universal > perl5 @5.8.9_0 > perl5.8 @5.8.9_2 > perl5.8 @5.8.9_3 > pkgconfig @0.23_1+universal > python_select @0.2.1_0+darwin_9 > tcl @8.5.6_0+darwin > Xft2 @2.1.13_2 > xorg-bigreqsproto @1.0.2_0 > xorg-bigreqsproto @1.1.0_0 > xorg-inputproto @1.5.0_0 > xorg-inputproto @1.5.1_0 > xorg-kbproto @1.0.3_0 > xorg-libX11 @1.2_0+universal > xorg-libX11 @1.2.2_0+universal > xorg-libXau @1.0.4_0+universal > xorg-libXau @1.0.5_0+universal > xorg-libXdmcp @1.0.2_0+universal > xorg-libXdmcp @1.0.2_1+universal > xorg-libXext @1.0.5_0+universal > xorg-libXext @1.0.99.4_1+universal > xorg-libXrandr @1.2.3_0+universal > xorg-libXrandr @1.3.0_1+universal > xorg-randrproto @1.2.1_0 > xorg-randrproto @1.3.0_0 > xorg-renderproto @0.9.3_0 > xorg-renderproto @0.11_0 > xorg-util-macros @1.2.2_0 > xorg-xcmiscproto @1.1.2_0 > xorg-xcmiscproto @1.2.0_0 > xorg-xextproto @7.0.5_0 > xorg-xextproto @7.1.1_0 > xorg-xf86bigfontproto @1.1.2_0 > xorg-xf86bigfontproto @1.2.0_0 > xorg-xproto @7.0.14_1 > xorg-xproto @7.0.15_0 > xorg-xtrans @1.2.3_0 > xorg-xtrans @1.2.4_0 > xrender @0.9.4_5+universal > xrender @0.9.4_6+universal > zlib @1.2.3_2+universal Well it looks ok. Perhaps it's not liking multiple versions of individual ports installed; I didn't test with that. > Now, I did come up with the idea of filtering out the non-universals. > > That lead to a file looking like: > Kleiman-ibook:Development michael$ head Lacking2 > autoconf > fontconfig > fontconfig > p5-locale-gettext > perl5 > perl5.8 > perl5.8 > python_select > tcl > Xft2 > > And a second file looking like > Kleiman-ibook:Development michael$ head -5 Wanted > autoconf +universal > fontconfig +universal > fontconfig +universal > p5-locale-gettext +universal > perl5 +universal > > And a command line looking like > Kleiman-ibook:Development michael$ echo sudo port upgrade > --enforce-variants `cat Wanted` > > which expanded to > > sudo port upgrade --enforce-variants autoconf +universal fontconfig > +universal fontconfig +universal p5-locale-gettext +universal perl5 > +universal perl5.8 +universal perl5.8 +universal python_select > +universal tcl +universal Xft2 +universal xorg-bigreqsproto +universal > xorg-bigreqsproto +universal xorg-inputproto +universal > xorg-inputproto +universal xorg-kbproto +universal xorg-randrproto > +universal xorg-randrproto +universal xorg-renderproto +universal > xorg-renderproto +universal xorg-util-macros +universal > xorg-xcmiscproto +universal xorg-xcmiscproto +universal xorg-xextproto > +universal xorg-xextproto +universal xorg-xf86bigfontproto +universal > xorg-xf86bigfontproto +universal xorg-xproto +universal xorg-xproto > +universal xorg-xtrans +universal xorg-xtrans +universal > > Which looks correct to me. > > And it works. Seems to, anyways. On the third package now. I'm glad you got it working. From ryandesign at macports.org Fri Sep 4 14:43:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 4 Sep 2009 16:43:49 -0500 Subject: [MacPorts] #21072: Cannot force a change to +universal In-Reply-To: <1bd71ad80909041435m69fa0d4bof96ae609a44f6c4c@mail.gmail.com> References: <068.f020099ad5468fcad18c55497364e584@macports.org> <1bd71ad80909032308x42935391l6869416c3cd8fe36@mail.gmail.com> <1bd71ad80909032319l2866e6a4r3a5ce675c56469f2@mail.gmail.com> <1bd71ad80909032349s1e1ccf1ewdae52d5eb3d5ae50@mail.gmail.com> <74c219d30909040315vfc5e3c1t5aff292c0829c4c5@mail.gmail.com> <1bd71ad80909040955i50af9f1u6156c248ff7884f5@mail.gmail.com> <1bd71ad80909041318s6f96b85blf91310dced9926f5@mail.gmail.com> <5E9D7E57-E607-451C-A0D1-645E55FDD82D@macports.org> <1bd71ad80909041411n193d0e8dse66218db63dc8f2d@mail.gmail.com> <1bd71ad80909041435m69fa0d4bof96ae609a44f6c4c@mail.gmail.com> Message-ID: On Sep 4, 2009, at 16:35, Michael_google gmail_Gersten wrote: >> which expanded to >> >> sudo port upgrade --enforce-variants autoconf +universal fontconfig >> +universal fontconfig +universal p5-locale-gettext +universal perl5 >> +universal perl5.8 +universal perl5.8 +universal python_select >> +universal tcl +universal Xft2 +universal xorg-bigreqsproto >> +universal >> xorg-bigreqsproto +universal xorg-inputproto +universal >> xorg-inputproto +universal xorg-kbproto +universal xorg-randrproto >> +universal xorg-randrproto +universal xorg-renderproto +universal >> xorg-renderproto +universal xorg-util-macros +universal >> xorg-xcmiscproto +universal xorg-xcmiscproto +universal xorg- >> xextproto >> +universal xorg-xextproto +universal xorg-xf86bigfontproto +universal >> xorg-xf86bigfontproto +universal xorg-xproto +universal xorg-xproto >> +universal xorg-xtrans +universal xorg-xtrans +universal >> >> Which looks correct to me. >> >> And it works. Seems to, anyways. On the third package now. > > Sadly, it only did three packages -- python_select, tcl, and Xft2. The > others were ignored. > > Anyone see what I'm missing? Maybe none of the others have universal variants. All the proto packages, for example, do not install binaries; they only install headers, so there is nothing to be build universal. Use "port variants foo" to discover if the port foo has a universal variant. From keybounce at gmail.com Fri Sep 4 14:52:25 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Fri, 4 Sep 2009 14:52:25 -0700 Subject: [MacPorts] #21072: Cannot force a change to +universal In-Reply-To: References: <068.f020099ad5468fcad18c55497364e584@macports.org> <1bd71ad80909032349s1e1ccf1ewdae52d5eb3d5ae50@mail.gmail.com> <74c219d30909040315vfc5e3c1t5aff292c0829c4c5@mail.gmail.com> <1bd71ad80909040955i50af9f1u6156c248ff7884f5@mail.gmail.com> <1bd71ad80909041318s6f96b85blf91310dced9926f5@mail.gmail.com> <5E9D7E57-E607-451C-A0D1-645E55FDD82D@macports.org> <1bd71ad80909041411n193d0e8dse66218db63dc8f2d@mail.gmail.com> <1bd71ad80909041435m69fa0d4bof96ae609a44f6c4c@mail.gmail.com> Message-ID: <1bd71ad80909041452p11b238d6k95b5c7923ec2c2af@mail.gmail.com> >> Sadly, it only did three packages -- python_select, tcl, and Xft2. The >> others were ignored. >> >> Anyone see what I'm missing? > > Maybe none of the others have universal variants. All the proto packages, > for example, do not install binaries; they only install headers, so there is > nothing to be build universal. Hey, it seems to be working just fine now. Lets see if this all compiles... From jmr at macports.org Fri Sep 4 18:44:12 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 05 Sep 2009 11:44:12 +1000 Subject: [MacPorts] #21072: Cannot force a change to +universal In-Reply-To: <1bd71ad80909041411n193d0e8dse66218db63dc8f2d@mail.gmail.com> References: <068.f020099ad5468fcad18c55497364e584@macports.org> <077.73cfeb7d775244b96c1d8858fc5baad6@macports.org> <1bd71ad80909032308x42935391l6869416c3cd8fe36@mail.gmail.com> <1bd71ad80909032319l2866e6a4r3a5ce675c56469f2@mail.gmail.com> <1bd71ad80909032349s1e1ccf1ewdae52d5eb3d5ae50@mail.gmail.com> <74c219d30909040315vfc5e3c1t5aff292c0829c4c5@mail.gmail.com> <1bd71ad80909040955i50af9f1u6156c248ff7884f5@mail.gmail.com> <1bd71ad80909041318s6f96b85blf91310dced9926f5@mail.gmail.com> <5E9D7E57-E607-451C-A0D1-645E55FDD82D@macports.org> <1bd71ad80909041411n193d0e8dse66218db63dc8f2d@mail.gmail.com> Message-ID: <4AA1C26C.4030707@macports.org> On 2009-9-5 07:11, Michael_google gmail_Gersten wrote: > And glib2 -- gnu C library -- requires python select? You need to > change python to use the library?? No. That's a completely useless dependency. It needs python but doesn't care which version. However, depending on python_select won't cause python to be installed if you're on a system that doesn't already have it. - Josh From keybounce at gmail.com Fri Sep 4 21:47:47 2009 From: keybounce at gmail.com (Michael Gersten) Date: Fri, 4 Sep 2009 21:47:47 -0700 Subject: Open Al: No universal variant in the port tree In-Reply-To: <4AA1C26C.4030707@macports.org> References: <068.f020099ad5468fcad18c55497364e584@macports.org> <077.73cfeb7d775244b96c1d8858fc5baad6@macports.org> <1bd71ad80909032308x42935391l6869416c3cd8fe36@mail.gmail.com> <1bd71ad80909032319l2866e6a4r3a5ce675c56469f2@mail.gmail.com> <1bd71ad80909032349s1e1ccf1ewdae52d5eb3d5ae50@mail.gmail.com> <74c219d30909040315vfc5e3c1t5aff292c0829c4c5@mail.gmail.com> <1bd71ad80909040955i50af9f1u6156c248ff7884f5@mail.gmail.com> <1bd71ad80909041318s6f96b85blf91310dced9926f5@mail.gmail.com> <5E9D7E57-E607-451C-A0D1-645E55FDD82D@macports.org> <1bd71ad80909041411n193d0e8dse66218db63dc8f2d@mail.gmail.com> <4AA1C26C.4030707@macports.org> Message-ID: "openal" does not have a +universal option defined. Manually adding the line PortGroup muniversal 1.0 to the port file did NOT suffice -- this is the output sudo port install openal +universal ---> Computing dependencies for openal ---> Fetching openal ---> Verifying checksum(s) for openal ---> Extracting openal ---> Configuring openal ---> Configuring openal for architecture ppc ---> Configuring openal for architecture i386 ---> Building openal ---> Building openal for architecture ppc ---> Building openal for architecture i386 Error: Target org.macports.build returned: shell command "cd /opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_audio_openal/work/openal-1.0/macosx && make all PREFIX=/opt/local" returned error 2 Command output: g++ -dynamiclib -install_name /opt/local/lib/ libopenal1.0.0.dylib -o libopenal1.0.0.dylib -L./build/Default -F./ build/Default -filelist ./build/al_osx.build/Default/ openal.dylib.build/Objects-normal/LinkFileList -framework vecLib - framework CoreAudio -framework CoreFoundation -framework AudioToolbox - framework AudioUnit -framework CoreServices -compatibility_version 1 - current_version 1 ld: -filelist file not found: ./build/al_osx.build/Default/ openal.dylib.build/Objects-normal/LinkFileList collect2: ld returned 1 exit status make: *** [libopenal1.0.0.dylib] Error 1 Error: Status 1 encountered during processing. Kleiman-ibook:Preferences michael$ OpenAl is listed as having no maintainer. Can someone help with this? From jeremyhu at macports.org Sat Sep 5 12:50:07 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 5 Sep 2009 12:50:07 -0700 Subject: xcb fubar'd Message-ID: $prefix/lib/X11/app-defaults is not supposed to be a symlink: app-defaults -> ../../../../opt/local/etc/X11/app-defaults ---> Activating xcb @2.4_2 Error: Target org.macports.activate returned: Image error: /opt/local/ lib/X11/app-defaults already exists and does not belong to a registered port. Unable to activate port xcb. Warning: the following items did not execute (for xcb): org.macports.activate Error: Status 1 encountered during processing. From devans at macports.org Sat Sep 5 15:27:17 2009 From: devans at macports.org (David Evans) Date: Sat, 05 Sep 2009 15:27:17 -0700 Subject: [57052] trunk/dports/gnome/gnome-desktop-suite/Portfile In-Reply-To: <20090905201621.781E025FD2CA@beta.macosforge.org> References: <20090905201621.781E025FD2CA@beta.macosforge.org> Message-ID: <4AA2E5C5.3020304@macports.org> jeremyhu at macports.org wrote: > > Revision > 57052 > Author > jeremyhu at macports.org > Date > 2009-09-05 13:16:18 -0700 (Sat, 05 Sep 2009) > > > Log Message > > gnome-desktop-suite: Don't install gnome-sharp2 on ppc systems since mono fails. > > > Modified Paths > > * trunk/dports/gnome/gnome-desktop-suite/Portfile > <#trunkdportsgnomegnomedesktopsuitePortfile> > > > Diff > > > Modified: trunk/dports/gnome/gnome-desktop-suite/Portfile > (57051 => 57052) > > > --- trunk/dports/gnome/gnome-desktop-suite/Portfile 2009-09-05 20:14:03 UTC (rev 57051) > +++ trunk/dports/gnome/gnome-desktop-suite/Portfile 2009-09-05 20:16:18 UTC (rev 57052) > @@ -129,6 +129,11 @@ > port:libgnomeprint \ > port:libgnomeprintui > > +# mono fails on ppc - #17996 > +if {${configure.build_arch} == "ppc"} { > + depends_lib-delete port:gnome-sharp2 > +} > + > distfiles > use_configure no > build { } Are you sure about this? This seems like an old bug and mono seems to work for me on tiger ppc. Dave From roederja at ethz.ch Sat Sep 5 16:51:50 2009 From: roederja at ethz.ch (=?UTF-8?B?SmFubiBSw7bCmmRlcg==?=) Date: Sun, 06 Sep 2009 01:51:50 +0200 Subject: [Bulk] Re: [Bulk] Re: [Bulk] Snow Leopard +universal necessity In-Reply-To: References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> <4A9EE429.1020800@macports.org> Message-ID: Two more reasons for being in favor of the default universal variant for i386 and x86_64: 1. Apple also does it. They even include the ppc code even though snow leopard doesn't even run on ppc anymore... so maybe they do it to support cross compilation. 2. The eiffelstudio port would also benefit from 32bit libraries since a 32bit development environment is needed in case you want to build 32bit binaries. Jann William Davis schrieb: > > On Sep 2, 2009, at 5:31 PM, Joshua Root wrote: > >> On 2009-9-3 03:35, William Davis wrote: >>> It just seems simpler to me to have port rebuild >>> dependents as universal whenever that was needed instead of building >>> them all universal, whether needed or not. >> >> Well of course that's simpler for you, but it's not simpler for whoever >> has to implement that feature! ;-) > > Yes, well, there is that aspect of it! I'm very conscious of all the > work Ryan does around here, and didn't mean to sound unappreciative. > > > >> There is already a ticket open for this feature request: >> >> >> As you can see, Ryan is well aware of it. I believe he has been >> discussing what we can do in the meantime to mitigate these issues, not >> saying that these interim measures would be the ideal solution. > > I do see that he wasn't proposing +universal as a permanent fix . > >> My initial thought is that ports that can only be built for limited >> architectures should be checking the archs of their dependencies and >> giving an informative error message if they are not what's needed. >> >> - Josh > > To me that seems the preferable temp fix, but of course the person doing > the work should have the greatest weight. > > William Davis > frstanATbellsouthDOTnet > Mac OS X ver 10.6 Darwin 10.6 > XQuartz 2.3.4 (xorg-server 1.4.2-apple45) > Mac Mini Intel Duo @ 1.86 GHz > > Mundus vult decepi, ego non > From jkh at apple.com Sat Sep 5 20:14:46 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Sat, 5 Sep 2009 20:14:46 -0700 Subject: [Bulk] Re: [Bulk] Re: [Bulk] Snow Leopard +universal necessity In-Reply-To: References: <390C7F76-D176-41C3-AF87-19CC37EF23D3@macports.org> <4A9EE429.1020800@macports.org> Message-ID: <4D2A54A8-8ADE-4973-BF83-BBDB17F5D71B@apple.com> On Sep 5, 2009, at 4:51 PM, Jann R??der wrote: > 1. Apple also does it. They even include the ppc code even though snow > leopard doesn't even run on ppc anymore... so maybe they do it to > support cross compilation. Not so much that as Rosetta. - Jordan From keybounce at gmail.com Sat Sep 5 22:19:11 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Sat, 5 Sep 2009 22:19:11 -0700 Subject: Libraries not being installed with +universal Message-ID: <1bd71ad80909052219w42891456k686850877f4084c0@mail.gmail.com> Trying to reinstall a bunch of libraries. Starting with everything gone ... Kleiman-ibook:trunk michael$ sudo port install gtk2 +universal Password: ---> Computing dependencies for pkgconfig ---> Configuring pkgconfig ---> Building pkgconfig ---> Staging pkgconfig into destroot ---> Installing pkgconfig @0.23_1 ---> Activating pkgconfig @0.23_1 ---> Cleaning pkgconfig ---> Computing dependencies for libiconv ---> Fetching libiconv ---> Verifying checksum(s) for libiconv ---> Extracting libiconv ---> Applying patches to libiconv ---> Configuring libiconv ---> Building libiconv ---> Staging libiconv into destroot ---> Installing libiconv @1.13_0 ---> Activating libiconv @1.13_0 ---> Cleaning libiconv ---> Computing dependencies for gettext ---> Fetching gettext ---> Verifying checksum(s) for gettext ---> Extracting gettext ---> Applying patches to gettext ---> Configuring gettext ---> Building gettext ---> Staging gettext into destroot ---> Installing gettext @0.17_4 ---> Activating gettext @0.17_4 ---> Cleaning gettext ---> Computing dependencies for glib2 ---> Fetching glib2 ---> Verifying checksum(s) for glib2 ---> Extracting glib2 ---> Applying patches to glib2 ---> Configuring glib2 ---> Building glib2 ---> Staging glib2 into destroot ---> Installing glib2 @2.20.4_0+darwin ---> Activating glib2 @2.20.4_0+darwin ---> Cleaning glib2 ---> Computing dependencies for zlib ---> Fetching zlib ---> Verifying checksum(s) for zlib ---> Extracting zlib ---> Applying patches to zlib ---> Configuring zlib ---> Building zlib ---> Staging zlib into destroot ---> Installing zlib @1.2.3_3 ---> Activating zlib @1.2.3_3 ---> Cleaning zlib ---> Computing dependencies for gtk2 ---> Fetching atk ---> Verifying checksum(s) for atk ---> Extracting atk ---> Configuring atk ---> Configuring atk for architecture ppc ---> Configuring atk for architecture i386 pkgconfig, I can understand being non-universal -- it's needed to build gtk2. But others in that list -- zlib, for example -- are needed to run. Being installed non-universal causes libpng to fail for i386 later on. I'm guessing that these are needed for pkgconfig; since pkgconfig is a build dependency, it doesn't go in as +universal, and the libraries that it needs -- EVEN IF NEEDED BY THE OTHER STUFF -- also do not go in as +universal. From talklists at newgeo.com Sat Sep 5 23:21:05 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sat, 5 Sep 2009 23:21:05 -0700 Subject: php.ini for production Message-ID: <151AA7CE-15F6-4A4F-BFC8-98C32777ECEB@newgeo.com> Does anyone know more about why in php.ini for production the below is set? request_order = "GP" This makes $_REQUEST not contain cookies, which for one reason or another took me a long time to pin down. I can not really think of why this would be a bad thing to have C or S in that list for that matter. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Sun Sep 6 04:34:14 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 6 Sep 2009 06:34:14 -0500 Subject: php.ini for production In-Reply-To: <151AA7CE-15F6-4A4F-BFC8-98C32777ECEB@newgeo.com> References: <151AA7CE-15F6-4A4F-BFC8-98C32777ECEB@newgeo.com> Message-ID: On Sep 6, 2009, at 01:21, Scott Haneda wrote: > Does anyone know more about why in php.ini for production the below > is set? > request_order = "GP" > > This makes $_REQUEST not contain cookies, which for one reason or > another took me a long time to pin down. I can not really think of > why this would be a bad thing to have C or S in that list for that > matter. Googling for 'request_order = "GP"' I found this explanation which is quite detailed: http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/ I had no idea! Looks like it's a good idea they've changed it. From ryandesign at macports.org Sun Sep 6 04:37:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 6 Sep 2009 06:37:23 -0500 Subject: Libraries not being installed with +universal In-Reply-To: <1bd71ad80909052219w42891456k686850877f4084c0@mail.gmail.com> References: <1bd71ad80909052219w42891456k686850877f4084c0@mail.gmail.com> Message-ID: <4D2D226D-9593-4D96-B36B-FCFA03166B3C@macports.org> On Sep 6, 2009, at 00:19, Michael_google gmail_Gersten wrote: > Trying to reinstall a bunch of libraries. Starting with everything > gone ... > > Kleiman-ibook:trunk michael$ sudo port install gtk2 +universal > Password: > ---> Computing dependencies for pkgconfig > ---> Configuring pkgconfig > ---> Building pkgconfig > ---> Staging pkgconfig into destroot > ---> Installing pkgconfig @0.23_1 > ---> Activating pkgconfig @0.23_1 > ---> Cleaning pkgconfig > ---> Computing dependencies for libiconv > ---> Fetching libiconv > ---> Verifying checksum(s) for libiconv > ---> Extracting libiconv > ---> Applying patches to libiconv > ---> Configuring libiconv > ---> Building libiconv > ---> Staging libiconv into destroot > ---> Installing libiconv @1.13_0 > ---> Activating libiconv @1.13_0 > ---> Cleaning libiconv > ---> Computing dependencies for gettext > ---> Fetching gettext > ---> Verifying checksum(s) for gettext > ---> Extracting gettext > ---> Applying patches to gettext > ---> Configuring gettext > ---> Building gettext > ---> Staging gettext into destroot > ---> Installing gettext @0.17_4 > ---> Activating gettext @0.17_4 > ---> Cleaning gettext > ---> Computing dependencies for glib2 > ---> Fetching glib2 > ---> Verifying checksum(s) for glib2 > ---> Extracting glib2 > ---> Applying patches to glib2 > ---> Configuring glib2 > ---> Building glib2 > ---> Staging glib2 into destroot > ---> Installing glib2 @2.20.4_0+darwin > ---> Activating glib2 @2.20.4_0+darwin > ---> Cleaning glib2 > ---> Computing dependencies for zlib > ---> Fetching zlib > ---> Verifying checksum(s) for zlib > ---> Extracting zlib > ---> Applying patches to zlib > ---> Configuring zlib > ---> Building zlib > ---> Staging zlib into destroot > ---> Installing zlib @1.2.3_3 > ---> Activating zlib @1.2.3_3 > ---> Cleaning zlib > ---> Computing dependencies for gtk2 > ---> Fetching atk > ---> Verifying checksum(s) for atk > ---> Extracting atk > ---> Configuring atk > ---> Configuring atk for architecture ppc > ---> Configuring atk for architecture i386 I can't explain why this is happening for you. pkgconfig, libiconv, gettext, glib2, zlib -- they can all be built universal. They do get built universal when I request it. I just tried in a fresh MacPorts install on Snow Leopard and it works fine. I'll paste my output at the bottom of this email. There are differences between my output and yours: 1. Your output keeps stating "Computing dependencies for" before every dependency; I've only ever seen that shown as the very first line for the port you requested, not for the dependencies. 2. Your output starts with "Configuring pkgconfig" -- what happened to fetching, verifying checksums, and extracting? Maybe the port was not clean. 3. Your output shows these ports being installed: pkgconfig, libiconv, gettext, glib2, zlib, atk. My output shows many more ports and in a different order: expat, gperf, libiconv, ncursesw, ncurses, gettext, perl5.8, perl5, pkgconfig, glib2, atk, zlib, etc. Did you actually type "sudo port install gtk2 +universal" or did you separately install each port? 4. My universal build is x86_64/i386 because I am on Snow Leopard. Yours shows ppc/i386 so I assume you are on Leopard or Tiger? On what kind of computer? Are you using MacPorts 1.8.0 or some version from trunk? Do you have any variants specified in variants.conf? If so, what are they? > pkgconfig, I can understand being non-universal -- it's needed to > build gtk2. > But others in that list -- zlib, for example -- are needed to run. > Being installed non-universal causes libpng to fail for i386 later on. > > I'm guessing that these are needed for pkgconfig; "port deps pkgconfig" shows it has no dependencies at all. If it had any, they would have been built before pkgconfig, not after. > since pkgconfig is a > build dependency, it doesn't go in as +universal, If a port has a universal variant, and you request the universal variant, it should get installed with the universal variant. MacPorts makes no distinctions here based on the type of dependency. > and the libraries > that it needs -- EVEN IF NEEDED BY THE OTHER STUFF -- also do not go > in as +universal. I have not observed that behavior before. If you specify a variant on the command line, or in variants.conf, any port that gets installed, whether directly by you or indirectly as a dependency, should use that variant (if applicable). My output, after installing a fresh MacPorts in the prefix /michael and pointing it at my distfiles and portfiles: $ sudo /michael/bin/port install gtk2 +universal ---> Computing dependencies for gtk2 ---> Fetching expat ---> Verifying checksum(s) for expat ---> Extracting expat ---> Configuring expat ---> Building expat ---> Staging expat into destroot ---> Installing expat @2.0.1_0+universal ---> Activating expat @2.0.1_0+universal ---> Cleaning expat ---> Fetching gperf ---> Verifying checksum(s) for gperf ---> Extracting gperf ---> Configuring gperf ---> Configuring gperf for architecture x86_64 ---> Configuring gperf for architecture i386 ---> Building gperf ---> Building gperf for architecture x86_64 ---> Building gperf for architecture i386 ---> Staging gperf into destroot ---> Staging gperf into destroot for architecture x86_64 ---> Staging gperf into destroot for architecture i386 ---> Installing gperf @3.0.4_0+universal ---> Activating gperf @3.0.4_0+universal ---> Cleaning gperf ---> Fetching libiconv ---> Verifying checksum(s) for libiconv ---> Extracting libiconv ---> Applying patches to libiconv ---> Configuring libiconv ---> Configuring libiconv for architecture x86_64 ---> Configuring libiconv for architecture i386 ---> Building libiconv ---> Building libiconv for architecture x86_64 ---> Building libiconv for architecture i386 ---> Staging libiconv into destroot ---> Staging libiconv into destroot for architecture x86_64 ---> Staging libiconv into destroot for architecture i386 ---> Installing libiconv @1.13_0+universal ---> Activating libiconv @1.13_0+universal ---> Cleaning libiconv ---> Fetching ncursesw ---> Verifying checksum(s) for ncursesw ---> Extracting ncursesw ---> Applying patches to ncursesw ---> Configuring ncursesw ---> Configuring ncursesw for architecture x86_64 ---> Configuring ncursesw for architecture i386 ---> Building ncursesw ---> Building ncursesw for architecture x86_64 ---> Building ncursesw for architecture i386 ---> Staging ncursesw into destroot ---> Staging ncursesw into destroot for architecture x86_64 ---> Staging ncursesw into destroot for architecture i386 ---> Installing ncursesw @5.7_0+darwin_10+universal ---> Activating ncursesw @5.7_0+darwin_10+universal ---> Cleaning ncursesw ---> Fetching ncurses ---> Verifying checksum(s) for ncurses ---> Extracting ncurses ---> Applying patches to ncurses ---> Configuring ncurses ---> Configuring ncurses for architecture x86_64 ---> Configuring ncurses for architecture i386 ---> Building ncurses ---> Building ncurses for architecture x86_64 ---> Building ncurses for architecture i386 ---> Staging ncurses into destroot ---> Staging ncurses into destroot for architecture x86_64 ---> Staging ncurses into destroot for architecture i386 ---> Installing ncurses @5.7_0+darwin_10+universal ---> Activating ncurses @5.7_0+darwin_10+universal ---> Cleaning ncurses ---> Fetching gettext ---> Verifying checksum(s) for gettext ---> Extracting gettext ---> Applying patches to gettext ---> Configuring gettext ---> Configuring gettext for architecture x86_64 ---> Configuring gettext for architecture i386 ---> Building gettext ---> Building gettext for architecture x86_64 ---> Building gettext for architecture i386 ---> Staging gettext into destroot ---> Staging gettext into destroot for architecture x86_64 ---> Staging gettext into destroot for architecture i386 ---> Installing gettext @0.17_4+universal ---> Activating gettext @0.17_4+universal ---> Cleaning gettext ---> Fetching perl5.8 ---> Verifying checksum(s) for perl5.8 ---> Extracting perl5.8 ---> Applying patches to perl5.8 ---> Configuring perl5.8 ---> Building perl5.8 ---> Staging perl5.8 into destroot ---> Installing perl5.8 @5.8.9_3 ---> Activating perl5.8 @5.8.9_3 ---> Cleaning perl5.8 ---> Fetching perl5 ---> Verifying checksum(s) for perl5 ---> Extracting perl5 ---> Configuring perl5 ---> Building perl5 ---> Staging perl5 into destroot ---> Installing perl5 @5.8.9_0 ---> Activating perl5 @5.8.9_0 ---> Cleaning perl5 ---> Fetching pkgconfig ---> Verifying checksum(s) for pkgconfig ---> Extracting pkgconfig ---> Configuring pkgconfig ---> Building pkgconfig ---> Staging pkgconfig into destroot ---> Installing pkgconfig @0.23_1+universal ---> Activating pkgconfig @0.23_1+universal ---> Cleaning pkgconfig ---> Fetching glib2 ---> Verifying checksum(s) for glib2 ---> Extracting glib2 ---> Applying patches to glib2 ---> Configuring glib2 ---> Configuring glib2 for architecture x86_64 ---> Configuring glib2 for architecture i386 ---> Building glib2 ---> Building glib2 for architecture x86_64 ---> Building glib2 for architecture i386 ---> Staging glib2 into destroot ---> Staging glib2 into destroot for architecture x86_64 ---> Staging glib2 into destroot for architecture i386 ---> Installing glib2 @2.20.4_0+darwin+universal ---> Activating glib2 @2.20.4_0+darwin+universal ---> Cleaning glib2 ---> Fetching atk ---> Verifying checksum(s) for atk ---> Extracting atk ---> Configuring atk ---> Configuring atk for architecture x86_64 ---> Configuring atk for architecture i386 ---> Building atk ---> Building atk for architecture x86_64 ---> Building atk for architecture i386 ---> Staging atk into destroot ---> Staging atk into destroot for architecture x86_64 ---> Staging atk into destroot for architecture i386 ---> Installing atk @1.26.0_1+universal ---> Activating atk @1.26.0_1+universal ---> Cleaning atk ---> Fetching zlib ---> Verifying checksum(s) for zlib ---> Extracting zlib ---> Applying patches to zlib ---> Configuring zlib ---> Building zlib ---> Staging zlib into destroot ---> Installing zlib @1.2.3_3+universal ---> Activating zlib @1.2.3_3+universal ---> Cleaning zlib ---> Fetching freetype ^C $ From ryandesign at macports.org Sun Sep 6 05:26:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 6 Sep 2009 07:26:23 -0500 Subject: [57082] trunk/dports/lang In-Reply-To: <20090906122104.85CED2609739@beta.macosforge.org> References: <20090906122104.85CED2609739@beta.macosforge.org> Message-ID: On Sep 6, 2009, at 07:21, easieste at macports.org wrote: > Added: trunk/dports/lang/abcl/Portfile > +distfiles abcl-src-${version}.tar.gz > +worksrcdir abcl-src-${version} FYI, these two lines can be replaced with: distname abcl-src-${version} From brad at pixilla.com Sun Sep 6 05:39:10 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sun, 6 Sep 2009 08:39:10 -0400 Subject: php5-soap Message-ID: <6E85F092-D065-4FA2-905F-8BFB6BD75FD9@pixilla.com> After php5-soap repeatedly failing to build I uninstalled everything using "port -f uninstalled installed" and then issued "port install php5-soap". Still failing with: /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_php_php5-soap/work/php-5.3.0/ext/soap/ soap.c:3535: warning: pointer targets in passing argument 1 of 'strcmp' differ in signedness make: *** [soap.lo] Error 1 Error: Status 1 encountered during processing. // Brad From ryandesign at macports.org Sun Sep 6 05:48:32 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 6 Sep 2009 07:48:32 -0500 Subject: build_arch vs. configure.build_arch Message-ID: <86BAB60A-4028-4574-A935-032CF27A8F6F@macports.org> What is the difference between build_arch and configure.build_arch? Which should we compare against in Portfiles when we want to know? Which should we set when we want to force the build one way or another? Is there an easy way to say "this port doesn't support 64-bit" or do we have to do the "if x86_64 is requested then use i386 else if ppc64 is requested then use ppc" dance? From ryandesign at macports.org Sun Sep 6 05:53:07 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 6 Sep 2009 07:53:07 -0500 Subject: php5-soap In-Reply-To: <6E85F092-D065-4FA2-905F-8BFB6BD75FD9@pixilla.com> References: <6E85F092-D065-4FA2-905F-8BFB6BD75FD9@pixilla.com> Message-ID: On Sep 6, 2009, at 07:39, Bradley Giesbrecht wrote: > After php5-soap repeatedly failing to build I uninstalled everything > using "port -f uninstalled installed" and then issued "port install > php5-soap". > > Still failing with: > /opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync.macports.org_release_ports_php_php5 > -soap/work/php-5.3.0/ext/soap/soap.c:3535: warning: pointer targets > in passing argument 1 of 'strcmp' differ in signedness > make: *** [soap.lo] Error 1 > > Error: Status 1 encountered during processing. It installs fine for me. That just looks like a warning (i.e. it should not be fatal). Could you please file a ticket for this problem and attach the full debug output? Thanks. From jeremy at lavergne.gotdns.org Sun Sep 6 06:37:43 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sun, 6 Sep 2009 09:37:43 -0400 Subject: php5-soap In-Reply-To: <6E85F092-D065-4FA2-905F-8BFB6BD75FD9@pixilla.com> References: <6E85F092-D065-4FA2-905F-8BFB6BD75FD9@pixilla.com> Message-ID: Have you tried cleaning the port prior to attempting to rebuild? On Sep 6, 2009, at 8:39 AM, Bradley Giesbrecht wrote: > After php5-soap repeatedly failing to build I uninstalled everything > using "port -f uninstalled installed" and then issued "port install > php5-soap". > > Still failing with: > /opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync.macports.org_release_ports_php_php5 > -soap/work/php-5.3.0/ext/soap/soap.c:3535: warning: pointer targets > in passing argument 1 of 'strcmp' differ in signedness > make: *** [soap.lo] Error 1 > > Error: Status 1 encountered during processing. > > > // Brad > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From brad at pixilla.com Sun Sep 6 07:09:28 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Sun, 6 Sep 2009 10:09:28 -0400 Subject: php5-soap In-Reply-To: References: <6E85F092-D065-4FA2-905F-8BFB6BD75FD9@pixilla.com> Message-ID: <9E0837B2-E367-4946-8B13-93E43F205615@pixilla.com> Yes. Same error. I'm not rebuilding because I `port uninstall installed`. I verified I had no ports installed and then issued `port install php5-soap` and after building all the dependancies it continues to fail as I reported. It's the same error I received before uninstalling all of my ports. So my env is as clean as I it can reasonably be short of nuking /opt and the rest. // Brad On Sep 6, 2009, at 9:37 AM, Jeremy Lavergne wrote: > Have you tried cleaning the port prior to attempting to rebuild? > > On Sep 6, 2009, at 8:39 AM, Bradley Giesbrecht wrote: > >> After php5-soap repeatedly failing to build I uninstalled >> everything using "port -f uninstalled installed" and then issued >> "port install php5-soap". >> >> Still failing with: >> /opt/local/var/macports/build/ >> _opt_local_var_macports_sources_rsync >> .macports.org_release_ports_php_php5-soap/work/php-5.3.0/ext/soap/ >> soap.c:3535: warning: pointer targets in passing argument 1 of >> 'strcmp' differ in signedness >> make: *** [soap.lo] Error 1 >> >> Error: Status 1 encountered during processing. >> >> >> // Brad >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> > From and.damore at macports.org Sun Sep 6 07:56:49 2009 From: and.damore at macports.org (Andrea D'Amore) Date: Sun, 6 Sep 2009 16:56:49 +0200 Subject: TeX (texlive) port status? In-Reply-To: <20090904090415.GB16833@weetamoe.loria.fr> References: <20090903173221.27B3525AA853@beta.macosforge.org> <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> <20090904023536.GF1400@ambulatoryclam.net> <20090904090415.GB16833@weetamoe.loria.fr> Message-ID: <6C177AD7-647A-4E66-A3FF-F0456893433A@macports.org> On 04/set/09, at 11:04, Emmanuel Hainry wrote: > Note that the debian texlive package is also still 2007. iirc this is due to TeXLive 2008 having its own file manager, tlmgr, and that could conflict with Debian packaging system. How do Macports cope with ports that have their own packaging system, i.e. octave or luarocks (that I ported) for instance? Is there an official guideline? > The preferred (by texlive) distribution of texlive for macosx is > mactex, which is uptodate, > contains great apps and is configured to work out of the box. And > which > may be recognised by macports as filling the dependency for tex... I'm interested in this, do you mean by using file dependencies rather than port dependencies in single portfiles that depend on texlive or is there a general way to make Macports aware of an installed TeX distribution? I found myself having very small typesetting needs thus I ended using BasicTeX that, as far as I understand, is from MacTeX core too. I'd like to use binaries I already have rather than building texlive that is kind of a big port. Regards -- Andrea -- Andrea From blb at macports.org Sun Sep 6 12:44:00 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 6 Sep 2009 13:44:00 -0600 Subject: build_arch vs. configure.build_arch In-Reply-To: <86BAB60A-4028-4574-A935-032CF27A8F6F@macports.org> References: <86BAB60A-4028-4574-A935-032CF27A8F6F@macports.org> Message-ID: <20090906194400.GJ614@ninagal.withay.com> On Sun, Sep 06, 2009 at 07:48:32AM -0500, Ryan Schmidt said: > What is the difference between build_arch and configure.build_arch? > Which should we compare against in Portfiles when we want to know? > Which should we set when we want to force the build one way or > another? configure.build_arch defaults to whatever build_arch is: > > Is there an easy way to say "this port doesn't support 64-bit" or do > we have to do the "if x86_64 is requested then use i386 else if ppc64 > is requested then use ppc" dance? The problem with this is, what do we do about dependencies? If port B depends on A, and A was built 64bit but B says "I only do 32bit", then what? Bryan From ryandesign at macports.org Sun Sep 6 13:28:59 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 6 Sep 2009 15:28:59 -0500 Subject: TeX (texlive) port status? In-Reply-To: <6C177AD7-647A-4E66-A3FF-F0456893433A@macports.org> References: <20090903173221.27B3525AA853@beta.macosforge.org> <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> <20090904023536.GF1400@ambulatoryclam.net> <20090904090415.GB16833@weetamoe.loria.fr> <6C177AD7-647A-4E66-A3FF-F0456893433A@macports.org> Message-ID: On Sep 6, 2009, at 09:56, Andrea D'Amore wrote: > On 04/set/09, at 11:04, Emmanuel Hainry wrote: > >> Note that the debian texlive package is also still 2007. > > iirc this is due to TeXLive 2008 having its own file manager, tlmgr, > and that could conflict with Debian packaging system. > How do Macports cope with ports that have their own packaging > system, i.e. octave or luarocks (that I ported) for instance? Is > there an official guideline? MacPorts is The Package Manager. Consider CPAN, the system for installing Perl modules. We do not want users to use CPAN with MacPorts; instead, we want the user to install a p5-something port representing the module they want. We repackage the Perl modules as ports. The same would apply to anything provided by tlmgr or any other similar system (Ruby gems, PHP PEAR or PECL modules, etc.). >> The preferred (by texlive) distribution of texlive for macosx is >> mactex, which is uptodate, >> contains great apps and is configured to work out of the box. And >> which >> may be recognised by macports as filling the dependency for tex... > > I'm interested in this, do you mean by using file dependencies > rather than port dependencies in single portfiles that depend on > texlive or is there a general way to make Macports aware of an > installed TeX distribution? > I found myself having very small typesetting needs thus I ended > using BasicTeX that, as far as I understand, is from MacTeX core > too. I'd like to use binaries I already have rather than building > texlive that is kind of a big port. Thus far the suggestion has been to modify every single port that depends on texlive, to ensure the dependency is written "bin:something:texlive", so that if some other software installed by the user in a place identified by binpath provides that something, then the texlive port will not be installed. An alternate solution could be to write a tex meta-port that would do this. Then we would update every single port that depends on texlive to depend on that metaport instead. From ryandesign at macports.org Sun Sep 6 13:30:39 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 6 Sep 2009 15:30:39 -0500 Subject: [57093] trunk/dports/lang/abcl/Portfile In-Reply-To: <20090906145018.8D351260C37F@beta.macosforge.org> References: <20090906145018.8D351260C37F@beta.macosforge.org> Message-ID: <3BE73BD9-89DF-4C61-AB35-930B29E36CCA@macports.org> On Sep 6, 2009, at 09:50, easieste at macports.org wrote: > Revision: 57093 > http://trac.macports.org/changeset/57093 > Author: easieste at macports.org > Date: 2009-09-06 07:50:18 -0700 (Sun, 06 Sep 2009) > Log Message: > ----------- > Use 'distname' to replace use of 'distfiles' and 'worksrcdir' (Ryan > Schmidt). > > Modified Paths: > -------------- > trunk/dports/lang/abcl/Portfile > > Modified: trunk/dports/lang/abcl/Portfile > =================================================================== > --- trunk/dports/lang/abcl/Portfile 2009-09-06 14:49:25 UTC (rev > 57092) > +++ trunk/dports/lang/abcl/Portfile 2009-09-06 14:50:18 UTC (rev > 57093) > @@ -5,6 +5,7 @@ > > name abcl > version 0.16.0 > +revision 1 Don't change it now, but for future reference, you don't need to increase the revision unless there are changes in the files the port installs or the dependencies it declares. Bumping the revision causes everyone who already had the port installed to be prompted to rebuild it and upgrade; in this case, there is no reason to cause that to happen. From keybounce at gmail.com Sun Sep 6 13:53:22 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Sun, 6 Sep 2009 13:53:22 -0700 Subject: Libraries not being installed with +universal In-Reply-To: <4D2D226D-9593-4D96-B36B-FCFA03166B3C@macports.org> References: <1bd71ad80909052219w42891456k686850877f4084c0@mail.gmail.com> <4D2D226D-9593-4D96-B36B-FCFA03166B3C@macports.org> Message-ID: <1bd71ad80909061353h12489320i5cbb0bd8e4f4f083@mail.gmail.com> >> Trying to reinstall a bunch of libraries. Starting with everything gone > > I can't explain why this is happening for you. pkgconfig, libiconv, gettext, > glib2, zlib -- they can all be built universal. They do get built universal > when I request it. I just tried in a fresh MacPorts install on Snow Leopard > and it works fine. I'll paste my output at the bottom of this email. There > are differences between my output and yours: > > 1. Your output keeps stating "Computing dependencies for" before every > dependency; I've only ever seen that shown as the very first line for the > port you requested, not for the dependencies. > > 2. Your output starts with "Configuring pkgconfig" -- what happened to > fetching, verifying checksums, and extracting? Maybe the port was not clean. > > 3. Your output shows these ports being installed: pkgconfig, libiconv, > gettext, glib2, zlib, atk. My output shows many more ports and in a > different order: expat, gperf, libiconv, ncursesw, ncurses, gettext, > perl5.8, perl5, pkgconfig, glib2, atk, zlib, etc. Did you actually type > "sudo port install gtk2 +universal" or did you separately install each port? I stopped there because after that point it was making both x86 and PPC. Those were the ones that only built PPC. > 4. My universal build is x86_64/i386 because I am on Snow Leopard. Yours > shows ppc/i386 so I assume you are on Leopard or Tiger? On what kind of > computer? Are you using MacPorts 1.8.0 or some version from trunk? Do you > have any variants specified in variants.conf? If so, what are they? 10.5 (I can't keep the names straight), 1.8.0, PPC mac (universal = PPC/i386, not i386/x86_64). (Yea, I have to remember that "x86" is now ambiguous -- it's either i386 or x86_64.) Alright, so the most likely explanation is that I wasn't as clean as I thought. Kleiman-ibook:~ michael$ port-rdeps gtk2 | awk '{print $1}' | sort | uniq > /tmp/portlist Kleiman-ibook:~ michael$ head /tmp/portlist Dependencies Xft2 atk autoconf automake cairo expat fontconfig freetype gettext Whoops -- forgot that first line. Fix that. Kleiman-ibook:~ michael$ sudo !! sudo port -f uninstall `cat /tmp/portlist` Password: ---> Unable to uninstall Xft2 2.1.13_2+universal, the following ports depend on it: ---> tk Warning: Uninstall forced. Proceeding despite dependencies. ---> Deactivating Xft2 @2.1.13_2+universal ---> Uninstalling Xft2 @2.1.13_2+universal ---> Deactivating atk @1.26.0_1+universal ---> Uninstalling atk @1.26.0_1+universal ---> Deactivating autoconf @2.64_2 ---> Uninstalling autoconf @2.64_2 ---> Deactivating automake @1.11_0+universal ---> Uninstalling automake @1.11_0+universal ---> Unable to uninstall expat 2.0.1_0+universal, the following ports depend on it: ---> p5-xml-parser ---> intltool - snip - Kleiman-ibook:~ michael$ Kleiman-ibook:~ michael$ port installed The following ports are currently installed: bzip2 @1.0.5_2+darwin (active) db46 @4.6.21_5 (active) gdbm @1.8.3_1 (active) libogg @1.1.4_0+universal (active) libsdl @1.2.13_6+universal (active) libsdl_mixer @1.2.8_1+universal (active) libsdl_ttf @2.0.9_0+universal (active) libtheora @1.0_0+darwin_powerpc+universal (active) libvorbis @1.2.3_0+universal (active) openssl @0.9.8k_0+darwin (active) python25 @2.5.4_6+darwin_9+macosx+universal (active) readline @6.0.000_1+darwin (active) smpeg @0.4.4_8+universal (active) sqlite3 @3.6.17_0 (active) tcl @8.5.6_0+darwin+universal (active) tk @8.5.6_1+darwin (active) xorg-libXScrnSaver @1.2.0_0 (active) xorg-scrnsaverproto @1.2.0_0 (active) XviD @1.2.2_0+universal (active) Kleiman-ibook:~ michael$ Kleiman-ibook:~ michael$ port installed | grep -v universal The following ports are currently installed: bzip2 @1.0.5_2+darwin (active) db46 @4.6.21_5 (active) gdbm @1.8.3_1 (active) openssl @0.9.8k_0+darwin (active) readline @6.0.000_1+darwin (active) sqlite3 @3.6.17_0 (active) tk @8.5.6_1+darwin (active) xorg-libXScrnSaver @1.2.0_0 (active) xorg-scrnsaverproto @1.2.0_0 (active) I think that's pretty clean. Compile: Kleiman-ibook:~ michael$ sudo port install gtk2 +universal Password: ---> Computing dependencies for gtk2 ---> Fetching expat ---> Verifying checksum(s) for expat ---> Extracting expat ---> Configuring expat ---> Building expat ---> Staging expat into destroot ---> Installing expat @2.0.1_0+universal ---> Activating expat @2.0.1_0+universal ---> Cleaning expat ---> Fetching gperf ---> Verifying checksum(s) for gperf ---> Extracting gperf ---> Configuring gperf ---> Configuring gperf for architecture ppc ... Alright, it's compiling, but that first port -- expat -- going in as universal in only one form? Lets see how it continues From keybounce at gmail.com Sun Sep 6 14:01:47 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Sun, 6 Sep 2009 14:01:47 -0700 Subject: Libraries not being installed with +universal In-Reply-To: <1bd71ad80909061353h12489320i5cbb0bd8e4f4f083@mail.gmail.com> References: <1bd71ad80909052219w42891456k686850877f4084c0@mail.gmail.com> <4D2D226D-9593-4D96-B36B-FCFA03166B3C@macports.org> <1bd71ad80909061353h12489320i5cbb0bd8e4f4f083@mail.gmail.com> Message-ID: <1bd71ad80909061401q42cc6f1bna3736112da9adea0@mail.gmail.com> Does not work. Kleiman-ibook:~ michael$ sudo port install gtk2 +universal Password: ---> Computing dependencies for gtk2 ---> Fetching expat ---> Verifying checksum(s) for expat ---> Extracting expat ---> Configuring expat ---> Building expat ---> Staging expat into destroot ---> Installing expat @2.0.1_0+universal ---> Activating expat @2.0.1_0+universal ---> Cleaning expat ---> Fetching gperf ---> Verifying checksum(s) for gperf ---> Extracting gperf ---> Configuring gperf ---> Configuring gperf for architecture ppc ---> Configuring gperf for architecture i386 ---> Building gperf ---> Building gperf for architecture ppc ---> Building gperf for architecture i386 ---> Staging gperf into destroot ---> Staging gperf into destroot for architecture ppc ---> Staging gperf into destroot for architecture i386 ---> Installing gperf @3.0.4_0+universal ---> Activating gperf @3.0.4_0+universal ---> Cleaning gperf ---> Building libiconv ---> Building libiconv for architecture ppc ---> Building libiconv for architecture i386 ---> Staging libiconv into destroot ---> Staging libiconv into destroot for architecture ppc ---> Staging libiconv into destroot for architecture i386 ---> Installing libiconv @1.13_0+universal ---> Activating libiconv @1.13_0+universal ---> Cleaning libiconv ---> Fetching ncursesw ---> Verifying checksum(s) for ncursesw ---> Extracting ncursesw ---> Applying patches to ncursesw ---> Configuring ncursesw ---> Configuring ncursesw for architecture ppc ---> Configuring ncursesw for architecture i386 Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_ncursesw/work/ncurses-5.7-i386" && ./configure --prefix=/opt/local --disable-dependency-tracking --disable-dependency-tracking --enable-widec --disable-rpath --with-shared --without-debug --without-ada --enable-safe-sprintf --enable-sigwinch --mandir=/opt/local/share/man --with-manpage-format=normal --disable-dependency-tracking --host=i386-apple-darwin9.8.0 --with-build-cc='/usr/bin/gcc-4.0' --with-build-cpp='/usr/bin/cpp-4.0' --with-build-cppflags=-D_XOPEN_SOURCE_EXTENDED --enable-big-core --with-chtype=long --with-bool='unsigned char' " returned error 1 Command output: checking for nawk... no checking for awk... awk checking for egrep... (cached) grep -E checking for a BSD compatible install... /usr/bin/install -c checking for tdlint... no checking for lint... no checking for alint... no checking whether ln -s works... yes checking for long file names... yes checking if we should assume mixed-case filenames... auto checking if filesystem supports mixed-case filenames... no checking whether make sets ${MAKE}... yes checking for ctags... yes checking for makeflags variable... checking for i386-apple-darwin9.8.0-ranlib... no checking for ranlib... ranlib checking for i386-apple-darwin9.8.0-ld... no checking for ld... ld checking for i386-apple-darwin9.8.0-ar... no checking for ar... ar checking for archiver options (symbol AR_OPTS)... rv checking if you have specified an install-prefix... checking for native build C compiler... /usr/bin/gcc-4.0 checking for native build C preprocessor... /usr/bin/cpp-4.0 checking for native build C flags... checking for native build C preprocessor-flags... -D_XOPEN_SOURCE_EXTENDED checking for native build linker-flags... checking for native build linker-libraries... configure: error: Cross-build requires two compilers. Use --with-build-cc to specify the native compiler. Error: The following dependencies failed to build: atk gettext ncurses ncursesw glib2 perl5 perl5.8 pkgconfig cairo fontconfig freetype zlib libpixman libpng xrender xorg-libX11 autoconf help2man p5-locale-gettext m4 automake libtool xorg-bigreqsproto xorg-inputproto xorg-kbproto xorg-libXau xorg-xproto xorg-libXdmcp xorg-util-macros xorg-xcmiscproto xorg-xextproto xorg-xf86bigfontproto xorg-xtrans xorg-renderproto jasper jpeg pango Xft2 shared-mime-info intltool gnome-common p5-getopt-long p5-pathtools p5-scalar-list-utils p5-xml-parser libxml2 tiff xorg-libXcomposite xorg-compositeproto xorg-libXext xorg-libXfixes xorg-fixesproto xorg-libXcursor xorg-libXdamage xorg-damageproto xorg-libXi xorg-libXinerama xorg-xineramaproto xorg-libXrandr xorg-randrproto Error: Status 1 encountered during processing. Kleiman-ibook:~ michael$ I am out of ideas. Help? From ryandesign at macports.org Sun Sep 6 14:13:31 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 6 Sep 2009 16:13:31 -0500 Subject: build_arch vs. configure.build_arch In-Reply-To: <20090906194400.GJ614@ninagal.withay.com> References: <86BAB60A-4028-4574-A935-032CF27A8F6F@macports.org> <20090906194400.GJ614@ninagal.withay.com> Message-ID: <7121EDAF-4972-4A0A-AE18-8825486AC1AA@macports.org> On Sep 6, 2009, at 14:44, Bryan Blackburn wrote: > On Sun, Sep 06, 2009 at 07:48:32AM -0500, Ryan Schmidt said: >> What is the difference between build_arch and configure.build_arch? >> Which should we compare against in Portfiles when we want to know? >> Which should we set when we want to force the build one way or >> another? > > configure.build_arch defaults to whatever build_arch is: > > > So, why are there two variables, and which one should we use? >> Is there an easy way to say "this port doesn't support 64-bit" or do >> we have to do the "if x86_64 is requested then use i386 else if ppc64 >> is requested then use ppc" dance? > > The problem with this is, what do we do about dependencies? If port B > depends on A, and A was built 64bit but B says "I only do 32bit", > then what? I don't care about dependencies right now; that's #20728. http://trac.macports.org/ticket/20728 I guess my request for an easy way to indicate that only 32-bit is supported is the "archs i386 ppc" syntax proposed here: http://trac.macports.org/ticket/20739 I'll just do it the long way for now, like the other ports have been doing it. http://trac.macports.org/changeset/56602 From ryandesign at macports.org Sun Sep 6 14:29:22 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 6 Sep 2009 16:29:22 -0500 Subject: Libraries not being installed with +universal In-Reply-To: <1bd71ad80909061353h12489320i5cbb0bd8e4f4f083@mail.gmail.com> References: <1bd71ad80909052219w42891456k686850877f4084c0@mail.gmail.com> <4D2D226D-9593-4D96-B36B-FCFA03166B3C@macports.org> <1bd71ad80909061353h12489320i5cbb0bd8e4f4f083@mail.gmail.com> Message-ID: On Sep 6, 2009, at 15:53, Michael_google gmail_Gersten wrote: > Kleiman-ibook:~ michael$ port installed | grep -v universal > The following ports are currently installed: > bzip2 @1.0.5_2+darwin (active) > db46 @4.6.21_5 (active) > gdbm @1.8.3_1 (active) > openssl @0.9.8k_0+darwin (active) > readline @6.0.000_1+darwin (active) > sqlite3 @3.6.17_0 (active) > tk @8.5.6_1+darwin (active) > xorg-libXScrnSaver @1.2.0_0 (active) > xorg-scrnsaverproto @1.2.0_0 (active) > > I think that's pretty clean. Note that openssl and readline are pretty common dependencies. You should build them, and bzip2, db46 and sqlite3, as universal as well so you don't run into problems later. > Compile: > > Kleiman-ibook:~ michael$ sudo port install gtk2 +universal > Password: > ---> Computing dependencies for gtk2 > ---> Fetching expat > ---> Verifying checksum(s) for expat > ---> Extracting expat > ---> Configuring expat > ---> Building expat > ---> Staging expat into destroot > ---> Installing expat @2.0.1_0+universal > ---> Activating expat @2.0.1_0+universal > ---> Cleaning expat > ---> Fetching gperf > ---> Verifying checksum(s) for gperf > ---> Extracting gperf > ---> Configuring gperf > ---> Configuring gperf for architecture ppc > ... > > Alright, it's compiling, but that first port -- expat -- going in as > universal in only one form? It looks like expat was successfully built universal. You should be able to verify this using the "file" or "lipo -info" commands, e.g. on my system: $ lipo -info /opt/local/lib/libexpat.1.5.2.dylib Architectures in the fat file: /opt/local/lib/libexpat.1.5.2.dylib are: x86_64 i386 $ If you base your "only one form" statement on the fact that the expat build did not include lines like "Configuring expat for architecture ppc", then that is only because the expat port does not use the muniversal portgroup which produces that output; expat uses the built- in universal variant that does all architectures all at once, so there are not separate stages for the separate architectures about which separate messages could be printed. From blb at macports.org Sun Sep 6 14:32:19 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 6 Sep 2009 15:32:19 -0600 Subject: build_arch vs. configure.build_arch In-Reply-To: <7121EDAF-4972-4A0A-AE18-8825486AC1AA@macports.org> References: <86BAB60A-4028-4574-A935-032CF27A8F6F@macports.org> <20090906194400.GJ614@ninagal.withay.com> <7121EDAF-4972-4A0A-AE18-8825486AC1AA@macports.org> Message-ID: <20090906213219.GN614@ninagal.withay.com> On Sun, Sep 06, 2009 at 04:13:31PM -0500, Ryan Schmidt said: > > On Sep 6, 2009, at 14:44, Bryan Blackburn wrote: > > >On Sun, Sep 06, 2009 at 07:48:32AM -0500, Ryan Schmidt said: > >>What is the difference between build_arch and configure.build_arch? > >>Which should we compare against in Portfiles when we want to know? > >>Which should we set when we want to force the build one way or > >>another? > > > >configure.build_arch defaults to whatever build_arch is: > > > > >> > > So, why are there two variables, and which one should we use? configure.build_arch, just like the other configure.* variables; since build_arch is meant to be settable from macports.conf, it shouldn't have to worry about which target is used when a port is actually built. But from a Portfile, you do worry about that, hence configure.build_arch (which, since it uses the default/options setup, can also be changed). > > > >>Is there an easy way to say "this port doesn't support 64-bit" or do > >>we have to do the "if x86_64 is requested then use i386 else if ppc64 > >>is requested then use ppc" dance? > > > >The problem with this is, what do we do about dependencies? If port B > >depends on A, and A was built 64bit but B says "I only do 32bit", > >then what? > > I don't care about dependencies right now; that's #20728. > > http://trac.macports.org/ticket/20728 > > I guess my request for an easy way to indicate that only 32-bit is > supported is the "archs i386 ppc" syntax proposed here: > > http://trac.macports.org/ticket/20739 > > I'll just do it the long way for now, like the other ports have been > doing it. > > http://trac.macports.org/changeset/56602 It's definitely going to be messy until someone improves the way we handle arch/universal in a more general way... Bryan From keybounce at gmail.com Mon Sep 7 09:05:10 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Mon, 7 Sep 2009 09:05:10 -0700 Subject: -p option seems to be ignored Message-ID: <1bd71ad80909070905x529d5527kc7c937cca6b0db04@mail.gmail.com> Trying to compile a bunch of libraries for gtk2 Note the -p option: Kleiman-ibook:~ michael$ sudo port -p install gtk2 +universal Password: ---> Computing dependencies for gtk2 ---> Configuring ncursesw ---> Configuring ncursesw for architecture ppc ---> Configuring ncursesw for architecture i386 Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_ncursesw/work/ncurses-5.7-i386" && ./configure --prefix=/opt/local --disable-dependency-tracking --disable-dependency-tracking --enable-widec --disable-rpath --with-shared --without-debug --without-ada --enable-safe-sprintf --enable-sigwinch --mandir=/opt/local/share/man --with-manpage-format=normal --disable-dependency-tracking --host=i386-apple-darwin9.8.0 --with-build-cc='/usr/bin/gcc-4.0' --with-build-cpp='/usr/bin/cpp-4.0' --with-build-cppflags=-D_XOPEN_SOURCE_EXTENDED --enable-big-core --with-chtype=long --with-bool='unsigned char' " returned error 1 Command output: checking for nawk... no checking for awk... awk checking for egrep... (cached) grep -E checking for a BSD compatible install... /usr/bin/install -c checking for tdlint... no checking for lint... no checking for alint... no checking whether ln -s works... yes checking for long file names... yes checking if we should assume mixed-case filenames... auto checking if filesystem supports mixed-case filenames... no checking whether make sets ${MAKE}... yes checking for ctags... yes checking for makeflags variable... checking for i386-apple-darwin9.8.0-ranlib... no checking for ranlib... ranlib checking for i386-apple-darwin9.8.0-ld... no checking for ld... ld checking for i386-apple-darwin9.8.0-ar... no checking for ar... ar checking for archiver options (symbol AR_OPTS)... rv checking if you have specified an install-prefix... checking for native build C compiler... /usr/bin/gcc-4.0 checking for native build C preprocessor... /usr/bin/cpp-4.0 checking for native build C flags... checking for native build C preprocessor-flags... -D_XOPEN_SOURCE_EXTENDED checking for native build linker-flags... checking for native build linker-libraries... configure: error: Cross-build requires two compilers. Use --with-build-cc to specify the native compiler. Error: The following dependencies failed to build: atk gettext ncurses ncursesw glib2 perl5 perl5.8 pkgconfig cairo fontconfig freetype zlib libpixman libpng xrender xorg-libX11 autoconf help2man p5-locale-gettext m4 automake libtool xorg-bigreqsproto xorg-inputproto xorg-kbproto xorg-libXau xorg-xproto xorg-libXdmcp xorg-util-macros xorg-xcmiscproto xorg-xextproto xorg-xf86bigfontproto xorg-xtrans xorg-renderproto jasper jpeg pango Xft2 shared-mime-info intltool gnome-common p5-getopt-long p5-pathtools p5-scalar-list-utils p5-xml-parser libxml2 tiff xorg-libXcomposite xorg-compositeproto xorg-libXext xorg-libXfixes xorg-fixesproto xorg-libXcursor xorg-libXdamage xorg-damageproto xorg-libXi xorg-libXinerama xorg-xineramaproto xorg-libXrandr xorg-randrproto Error: Status 1 encountered during processing. From toby at macports.org Mon Sep 7 10:32:10 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 7 Sep 2009 10:32:10 -0700 Subject: -p option seems to be ignored In-Reply-To: <1bd71ad80909070905x529d5527kc7c937cca6b0db04@mail.gmail.com> References: <1bd71ad80909070905x529d5527kc7c937cca6b0db04@mail.gmail.com> Message-ID: <74c219d30909071032x7c635a88kfcb2a011a4763f6f@mail.gmail.com> On Mon, Sep 7, 2009 at 09:05, Michael_google gmail_Gersten wrote: > Trying to compile a bunch of libraries for gtk2 > > Note the -p option: > > Kleiman-ibook:~ michael$ sudo port -p install gtk2 +universal You only specified one port; nothing to continue to. - Toby From keybounce at gmail.com Tue Sep 8 12:17:58 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Tue, 8 Sep 2009 12:17:58 -0700 Subject: -p option seems to be ignored In-Reply-To: <74c219d30909071032x7c635a88kfcb2a011a4763f6f@mail.gmail.com> References: <1bd71ad80909070905x529d5527kc7c937cca6b0db04@mail.gmail.com> <74c219d30909071032x7c635a88kfcb2a011a4763f6f@mail.gmail.com> Message-ID: <1bd71ad80909081217h2e31082al6de09b1ee84293e2@mail.gmail.com> On Mon, Sep 7, 2009 at 10:32 AM, Toby Peterson wrote: > On Mon, Sep 7, 2009 at 09:05, Michael_google > gmail_Gersten wrote: >> Trying to compile a bunch of libraries for gtk2 >> >> Note the -p option: >> >> Kleiman-ibook:~ michael$ sudo port -p install gtk2 +universal > > You only specified one port; nothing to continue to. > > - Toby This package has many dependencies. It stopped when the first dependency failed. I'm expecting behavior like "make -k" -- continue building as much as possible. From blb at macports.org Tue Sep 8 12:45:28 2009 From: blb at macports.org (Bryan Blackburn) Date: Tue, 8 Sep 2009 13:45:28 -0600 Subject: -p option seems to be ignored In-Reply-To: <1bd71ad80909081217h2e31082al6de09b1ee84293e2@mail.gmail.com> References: <1bd71ad80909070905x529d5527kc7c937cca6b0db04@mail.gmail.com> <74c219d30909071032x7c635a88kfcb2a011a4763f6f@mail.gmail.com> <1bd71ad80909081217h2e31082al6de09b1ee84293e2@mail.gmail.com> Message-ID: <20090908194528.GR577@ninagal.withay.com> On Tue, Sep 08, 2009 at 12:17:58PM -0700, Michael_google gmail_Gersten said: > On Mon, Sep 7, 2009 at 10:32 AM, Toby Peterson wrote: > > On Mon, Sep 7, 2009 at 09:05, Michael_google > > gmail_Gersten wrote: > >> Trying to compile a bunch of libraries for gtk2 > >> > >> Note the -p option: > >> > >> Kleiman-ibook:~ michael$ sudo port -p install gtk2 +universal > > > > You only specified one port; nothing to continue to. > > > > - Toby > > This package has many dependencies. > It stopped when the first dependency failed. > > I'm expecting behavior like "make -k" -- continue building as much as possible. What would be the point of continuing? If a dependency needed by gtk2 failed, I'm pretty sure gtk2 is definitely not going to build then... Bryan From keybounce at gmail.com Tue Sep 8 12:50:39 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Tue, 8 Sep 2009 12:50:39 -0700 Subject: -p option seems to be ignored In-Reply-To: <20090908194528.GR577@ninagal.withay.com> References: <1bd71ad80909070905x529d5527kc7c937cca6b0db04@mail.gmail.com> <74c219d30909071032x7c635a88kfcb2a011a4763f6f@mail.gmail.com> <1bd71ad80909081217h2e31082al6de09b1ee84293e2@mail.gmail.com> <20090908194528.GR577@ninagal.withay.com> Message-ID: <1bd71ad80909081250w1fef3102k45480e7d8f277a2b@mail.gmail.com> >> This package has many dependencies. >> It stopped when the first dependency failed. >> >> I'm expecting behavior like "make -k" -- continue building as much as possible. > > What would be the point of continuing? ?If a dependency needed by gtk2 > failed, I'm pretty sure gtk2 is definitely not going to build then... > > Bryan While Gtk2 won't build, another 15 packages that will eventually be needed may be able to. For all I know, other packages will fail, but if I can get them to all fail at once, I can try to get them fixed at once. Instead, I have to solve them serially. From ryandesign at macports.org Tue Sep 8 12:51:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 8 Sep 2009 14:51:29 -0500 Subject: -p option seems to be ignored In-Reply-To: <1bd71ad80909081217h2e31082al6de09b1ee84293e2@mail.gmail.com> References: <1bd71ad80909070905x529d5527kc7c937cca6b0db04@mail.gmail.com> <74c219d30909071032x7c635a88kfcb2a011a4763f6f@mail.gmail.com> <1bd71ad80909081217h2e31082al6de09b1ee84293e2@mail.gmail.com> Message-ID: On Sep 8, 2009, at 14:17, Michael_google gmail_Gersten wrote: > On Mon, Sep 7, 2009 at 10:32 AM, Toby Peterson wrote: > >> On Mon, Sep 7, 2009 at 09:05, Michael_google wrote: >> >>> Trying to compile a bunch of libraries for gtk2 >>> >>> Note the -p option: >>> >>> Kleiman-ibook:~ michael$ sudo port -p install gtk2 +universal >> >> You only specified one port; nothing to continue to. > > This package has many dependencies. > It stopped when the first dependency failed. > > I'm expecting behavior like "make -k" -- continue building as much > as possible. Yeah, and as far as I can tell that's not what port -p does. sudo port -p install A B will proceed to work on B if A fails. That's about it. minivmac-devel currently fails on Snow Leopard for reasons I am still investigating. So for example: $ sudo port extract minivmac-devel minivmac ---> Computing dependencies for minivmac-devel ---> Fetching minivmac-devel ---> Verifying checksum(s) for minivmac-devel ---> Extracting minivmac-devel Error: Target org.macports.extract returned: setting nonzero rsrclength not supported Error: Status 1 encountered during processing. $ See, it stopped after the failure of minivmac-devel and didn't proceed to the other port I requested, minivmac. If I use -p: $ sudo port -p extract minivmac-devel minivmac ---> Computing dependencies for minivmac-devel ---> Fetching minivmac-devel ---> Verifying checksum(s) for minivmac-devel ---> Extracting minivmac-devel Error: Target org.macports.extract returned: setting nonzero rsrclength not supported Error: Status 1 encountered during processing. ---> Computing dependencies for minivmac ---> Fetching minivmac ---> Verifying checksum(s) for minivmac ---> Extracting minivmac $ Now it proceeds past the failure of minivmac-devel and continues on to the other port I requested. From ryandesign at macports.org Tue Sep 8 12:52:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 8 Sep 2009 14:52:03 -0500 Subject: -p option seems to be ignored In-Reply-To: <1bd71ad80909081250w1fef3102k45480e7d8f277a2b@mail.gmail.com> References: <1bd71ad80909070905x529d5527kc7c937cca6b0db04@mail.gmail.com> <74c219d30909071032x7c635a88kfcb2a011a4763f6f@mail.gmail.com> <1bd71ad80909081217h2e31082al6de09b1ee84293e2@mail.gmail.com> <20090908194528.GR577@ninagal.withay.com> <1bd71ad80909081250w1fef3102k45480e7d8f277a2b@mail.gmail.com> Message-ID: <9CBBCD5E-EB67-4F5B-9FD3-54C11240C3DA@macports.org> On Sep 8, 2009, at 14:50, Michael_google gmail_Gersten wrote: > While Gtk2 won't build, another 15 packages that will eventually be > needed may be able to. For all I know, other packages will fail, but > if I can get them to all fail at once, I can try to get them fixed at > once. Instead, I have to solve them serially. Yes, you currently do have to do that manually. From dweber at macports.org Tue Sep 8 12:53:16 2009 From: dweber at macports.org (Darren Weber) Date: Tue, 8 Sep 2009 12:53:16 -0700 Subject: [MacPorts] #20773: Add zope2.10 In-Reply-To: <051.818f2d3754ed051bb460f2d4d6dca658@macports.org> References: <051.818f2d3754ed051bb460f2d4d6dca658@macports.org> Message-ID: I'm curious about using Plone, which is currently at version 3.3. I've downloaded the "unified installer" from http://plone.org/products/plone and I'll take a look at the content of that package to see what the latest dependencies are (most likely they are satisfied by some MacPorts). However, it appears the zope port is outdated. Is anyone else working on the Zope port? Is it a significant dependency of many other ports that are in wide use now? That is, what reason is there for the zope port to be "outdated", if any? Are there functional reasons, politics, superceded software, or what? Thanks, Darren On Sat, Aug 22, 2009 at 3:44 PM, MacPorts wrote: > #20773: Add zope2.10 > > -----------------------------+---------------------------------------------- > Reporter: martin@? | Owner: macports-tickets@? > Type: submission | Status: new > Priority: Normal | Milestone: > Component: ports | Version: 1.7.1 > Keywords: | Port: zope zope2.10 > > -----------------------------+---------------------------------------------- > As stated on the mailing list ( http://lists.macosforge.org/pipermail > /macports-users/2009-February/013697.html ) I think there should be a port > for zope2.10 (and probably zope2.9, zope2.11). As with the different > Python versions it is a dependency for other applications like Plone. > > The attached port file is tested with MacPorts 1.710, Mac OS X 10.5, > Intel. > > -- > Ticket URL: > MacPorts > Ports system for Mac OS > _______________________________________________ > macports-tickets mailing list > macports-tickets at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-tickets > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Tue Sep 8 12:57:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 8 Sep 2009 14:57:13 -0500 Subject: [MacPorts] #20773: Add zope2.10 In-Reply-To: References: <051.818f2d3754ed051bb460f2d4d6dca658@macports.org> Message-ID: <086BB7F8-0B61-4CAF-9C07-9610D34F3BC4@macports.org> On Sep 8, 2009, at 14:53, Darren Weber wrote: > I'm curious about using Plone, which is currently at version 3.3. > I've downloaded the "unified installer" from http://plone.org/products/plone > and I'll take a look at the content of that package to see what the > latest dependencies are (most likely they are satisfied by some > MacPorts). However, it appears the zope port is outdated. > > Is anyone else working on the Zope port? Is it a significant > dependency of many other ports that are in wide use now? That is, > what reason is there for the zope port to be "outdated", if any? > Are there functional reasons, politics, superceded software, or what? As far as I know, the zope ports (there are 43 ports with "zope" in the name) are outdated because nobody maintains them. (Only the three py*-zopeinterface ports are maintained.) It would be great if somebody would maintain the rest of them and update them. From yenwenchieh at gmx.de Tue Sep 8 13:27:33 2009 From: yenwenchieh at gmx.de (Yen, Wenchieh) Date: Tue, 08 Sep 2009 22:27:33 +0200 Subject: making portfile for midnight commander 4.7.0-pre2 Message-ID: <4AA6BE35.6030808@gmx.de> Hi I need some help by file fetching. The tar ball can be downloaded directly in browser or using wget from the link http://www.midnight-commander.org/downloads/12 By assigning the keyword master_site to the link, port fails to fetch as it can't find the file. Any workarounds? cheers, From dweber at macports.org Tue Sep 8 13:29:26 2009 From: dweber at macports.org (Darren Weber) Date: Tue, 8 Sep 2009 13:29:26 -0700 Subject: [MacPorts] #20773: Add zope2.10 In-Reply-To: <086BB7F8-0B61-4CAF-9C07-9610D34F3BC4@macports.org> References: <051.818f2d3754ed051bb460f2d4d6dca658@macports.org> <086BB7F8-0B61-4CAF-9C07-9610D34F3BC4@macports.org> Message-ID: I'm curious about zope/plone, so not the best option to be a maintainer. I can, however, take a shot at the update, although it's not looking like a trivial process to get up to speed on this one! Check out this list of ports in the dports/zope tree: zope-archetypes/ zope-btreefolder2/ zope-cmf/ zope-cmfactionicons/ zope-cmfformcontroller/ zope-cmfmessage/ zope-cmfphoto/ zope-cmfphotoalbum/ zope-cmfplone/ zope-cmfquickinstallertool/ zope-cmfusertracktool/ zope-cvsfile/ zope-emil_email_client/ zope-externaleditor/ zope-externalfile/ zope-extfile/ zope-formulator/ zope-generator/ zope-groupuserfolder/ zope-localfs/ zope-localizer/ zope-mimetypesregistry/ zope-placelesstranslationservice/ zope-ploneerrorreporting/ zope-plonekeywordmanager/ zope-ploneloginhistory/ zope-plonewebmail/ zope-portaltransforms/ zope-revisionmanager/ zope-stripogram/ zope-usersniffer/ zope-usertrack/ zope-validation/ zope-zopetree/ zope-zopezen/ zope-zphotoslides/ zope-zsyncer/ The download link looks simple enough: http://www.zope.org/Products/ Zope appears to be stable at 2.11.4 and 3.4.0, so the dilemma may be which one or how many to port? >From the zope site, we have options to download/install various python CMF too: http://www.zope.org/Products/CMF/ The recent stable versions of the python CMF available are 2.1.1, which is not the same as the python-zopeinterface version (3.3.0). The plot thickens when we get to the level of a Plone dependency tree, i.e.: http://plone.org/documentation/faq/plone-versions >From this FAQ, it appears the plone installation may require it's own "tailor-made" CMF. For my part, I want to focus on Plone. I may work out a way to install plone with the bundled dependencies to avoid conflicts with other ports OR try to massage a Plone port to work with other ports. Note the specific dependency for Plone 3.x on python2.4.4 - it just doesn't get more specific than that ;-) As a general note about MacPorts, the general philosophy to maintain the most up to date packages is good. It's best to avoid multiple installation versions, wherever possible. In this case (Plone 3.x), it appears the very specific dependency requirements may force us to adopt some very version specific ports to satisfy those dependencies (eg, a port for python2.4.4 and zope2.10.x. Take care, Darren On Tue, Sep 8, 2009 at 12:57 PM, Ryan Schmidt wrote: > > On Sep 8, 2009, at 14:53, Darren Weber wrote: > > I'm curious about using Plone, which is currently at version 3.3. I've >> downloaded the "unified installer" from http://plone.org/products/plone and >> I'll take a look at the content of that package to see what the latest >> dependencies are (most likely they are satisfied by some MacPorts). >> However, it appears the zope port is outdated. >> >> Is anyone else working on the Zope port? Is it a significant dependency >> of many other ports that are in wide use now? That is, what reason is there >> for the zope port to be "outdated", if any? Are there functional reasons, >> politics, superceded software, or what? >> > > As far as I know, the zope ports (there are 43 ports with "zope" in the > name) are outdated because nobody maintains them. (Only the three > py*-zopeinterface ports are maintained.) It would be great if somebody would > maintain the rest of them and update them. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at lavergne.gotdns.org Tue Sep 8 13:40:04 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 8 Sep 2009 16:40:04 -0400 Subject: making portfile for midnight commander 4.7.0-pre2 In-Reply-To: <4AA6BE35.6030808@gmx.de> References: <4AA6BE35.6030808@gmx.de> Message-ID: <39F1C202-724C-4DA3-9125-C3DCC4C5B997@lavergne.gotdns.org> Moo. Since when is "12" a useful filename? On Sep 8, 2009, at 4:27 PM, Yen, Wenchieh wrote: > I need some help by file fetching. > > The tar ball can be downloaded directly in browser or using wget > from the link > > http://www.midnight-commander.org/downloads/12 > > By assigning the keyword master_site to the link, port fails to > fetch as it can't find the file. Any workarounds? From jeremy at lavergne.gotdns.org Tue Sep 8 13:40:41 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 8 Sep 2009 16:40:41 -0400 Subject: making portfile for midnight commander 4.7.0-pre2 In-Reply-To: <4AA6BE35.6030808@gmx.de> References: <4AA6BE35.6030808@gmx.de> Message-ID: Check out guide.macports.org It has all the default values you might work with as well as what variables can do what you're expecting ... if that exists. That's a very strange way of hosting a file. On Sep 8, 2009, at 4:27 PM, Yen, Wenchieh wrote: > I need some help by file fetching. > > The tar ball can be downloaded directly in browser or using wget from > the link > > http://www.midnight-commander.org/downloads/12 > > By assigning the keyword master_site to the link, port fails to > fetch as > it can't find the file. Any workarounds? From ryandesign at macports.org Tue Sep 8 13:42:11 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 8 Sep 2009 15:42:11 -0500 Subject: making portfile for midnight commander 4.7.0-pre2 In-Reply-To: <39F1C202-724C-4DA3-9125-C3DCC4C5B997@lavergne.gotdns.org> References: <4AA6BE35.6030808@gmx.de> <39F1C202-724C-4DA3-9125-C3DCC4C5B997@lavergne.gotdns.org> Message-ID: <9E86AC82-A3AA-4E1D-984F-505E2E62A62D@macports.org> On Sep 8, 2009, at 15:40, Jeremy Lavergne wrote: > On Sep 8, 2009, at 4:27 PM, Yen, Wenchieh wrote: > >> I need some help by file fetching. >> >> The tar ball can be downloaded directly in browser or using wget >> from the link >> >> http://www.midnight-commander.org/downloads/12 >> >> By assigning the keyword master_site to the link, port fails to >> fetch as it can't find the file. Any workarounds? > > Moo. > Since when is "12" a useful filename? It isn't, but apparently that is how Trac defines download links. The solution is: master_sites http://www.midnight-commander.org/downloads/12?dummy= We have a port for midnight commander already; it is called "mc". It is a little out of date; it should be updated to 4.6.2. (4.7.0-pre2 is a pre-release version and we don't generally update ports to pre- release versions.) I will file a ticket for the update to 4.6.2 which will also incorporate this change in master_sites. From jeremy at lavergne.gotdns.org Tue Sep 8 13:43:53 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Tue, 8 Sep 2009 16:43:53 -0400 Subject: Fwd: making portfile for midnight commander 4.7.0-pre2 References: <9E86AC82-A3AA-4E1D-984F-505E2E62A62D@macports.org> Message-ID: <1D758A73-E2AD-4972-9F93-4AB6836DC3E6@lavergne.gotdns.org> This tip is from Ryan Schmidt: master_sites http://www.midnight-commander.org/downloads/12?dummy= We have a port for midnight commander already; it is called "mc". It is a little out of date; it should be updated to 4.6.2. (4.7.0-pre2 is a pre-release version and we don't generally update ports to pre- release versions.) I will file a ticket for the update to 4.6.2 which will also incorporate this change in master_sites. Enjoy! :-) From ryandesign at macports.org Tue Sep 8 14:11:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 8 Sep 2009 16:11:08 -0500 Subject: making portfile for midnight commander 4.7.0-pre2 In-Reply-To: <9E86AC82-A3AA-4E1D-984F-505E2E62A62D@macports.org> References: <4AA6BE35.6030808@gmx.de> <39F1C202-724C-4DA3-9125-C3DCC4C5B997@lavergne.gotdns.org> <9E86AC82-A3AA-4E1D-984F-505E2E62A62D@macports.org> Message-ID: <241F3E09-04F1-4D3C-99AA-8ED3BD547EDF@macports.org> On Sep 8, 2009, at 15:42, Ryan Schmidt wrote: > The solution is: > > > master_sites http://www.midnight-commander.org/downloads/12?dummy= > > > We have a port for midnight commander already; it is called "mc". It > is a little out of date; it should be updated to 4.6.2. (4.7.0-pre2 > is a pre-release version and we don't generally update ports to pre- > release versions.) I will file a ticket for the update to 4.6.2 > which will also incorporate this change in master_sites. My patch is here: http://trac.macports.org/ticket/21218 From ryandesign at macports.org Tue Sep 8 16:52:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 8 Sep 2009 18:52:38 -0500 Subject: Write to HFS in Snow Leopard Message-ID: It seems Apple has decided that in Snow Leopard we may now only read HFS volumes but not write to them. I need to write to an HFS disk image. Anybody know of a way to still do this in Snow Leopard? From raimue at macports.org Tue Sep 8 17:43:57 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 09 Sep 2009 02:43:57 +0200 Subject: Write to HFS in Snow Leopard In-Reply-To: References: Message-ID: <4AA6FA4D.7070401@macports.org> On 2009-09-09 01:52 , Ryan Schmidt wrote: > It seems Apple has decided that in Snow Leopard we may now only read > HFS volumes but not write to them. I need to write to an HFS disk > image. Anybody know of a way to still do this in Snow Leopard? Wow, didn't notice and probably would not have ever. Just out of interest, where do you still have to deal with OS versions which do not yet understand HFS+? I guess besides XNU, there are no useful third-party HFS implementations available except the one in the Linux kernel. But I don't think there is enough public interest to port any existing drivers to a Snow Leopard kernel extension... Rainer From ryandesign at macports.org Tue Sep 8 18:19:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 8 Sep 2009 20:19:03 -0500 Subject: Write to HFS in Snow Leopard In-Reply-To: <4AA6FA4D.7070401@macports.org> References: <4AA6FA4D.7070401@macports.org> Message-ID: On Sep 8, 2009, at 19:43, Rainer M?ller wrote: > On 2009-09-09 01:52 , Ryan Schmidt wrote: >> It seems Apple has decided that in Snow Leopard we may now only read >> HFS volumes but not write to them. I need to write to an HFS disk >> image. Anybody know of a way to still do this in Snow Leopard? > > Wow, didn't notice and probably would not have ever. Just out of > interest, where do you still have to deal with OS versions which do > not > yet understand HFS+? > > I guess besides XNU, there are no useful third-party HFS > implementations > available except the one in the Linux kernel. But I don't think > there is > enough public interest to port any existing drivers to a Snow Leopard > kernel extension... Mini vMac, the Mac Plus emulator. Its configuration program can only be run within itself. So I need to write to a disk image to set up this bootstrapping environment. See: http://trac.macports.org/browser/users/ryandesign/minivmac/Portfile?rev=44609 (Because of upstream changes I will have to revert back to that method, except now with Snow Leopard, I can't.) From ryandesign at macports.org Tue Sep 8 21:05:26 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 8 Sep 2009 23:05:26 -0500 Subject: [57304] trunk/dports/news/hellanzb In-Reply-To: <20090909035855.E65B52660298@beta.macosforge.org> References: <20090909035855.E65B52660298@beta.macosforge.org> Message-ID: <8E1BC19E-2168-45E4-A32B-5F13F2C441C6@macports.org> On Sep 8, 2009, at 22:58, jameskyle at macports.org wrote: > Revision: 57304 > http://trac.macports.org/changeset/57304 > Author: jameskyle at macports.org > Date: 2009-09-08 20:58:55 -0700 (Tue, 08 Sep 2009) > Log Message: > ----------- > Patched the hellanzb source to suppress deprecation warnings. Kind > of annoying. It looks like you did more than that, so you should revise the commit message to show all you did. [snip > Added: trunk/dports/news/hellanzb/files/patch-hellanzb.py.diff > =================================================================== > --- trunk/dports/news/hellanzb/files/patch- > hellanzb.py.diff (rev 0) > +++ trunk/dports/news/hellanzb/files/patch-hellanzb.py.diff > 2009-09-09 03:58:55 UTC (rev 57304) > @@ -0,0 +1,18 @@ > +--- hellanzb.py 2007-03-26 21:20:43.000000000 -0700 > ++++ /opt/local/bin/hellanzb.py 2009-09-07 10:39:03.000000000 -0700 > +@@ -1,4 +1,4 @@ > +-#!/usr/bin/env python > ++#!/opt/local/Library/Frameworks/Python.framework/Versions/2.6/ > Resources/Python.app/Contents/MacOS/Python [snip] You can't hardcode /opt/local; you must arrange for ${prefix} to appear here somehow, perhaps through a reinplace. From and.damore at macports.org Wed Sep 9 00:11:44 2009 From: and.damore at macports.org (Andrea D'Amore) Date: Wed, 9 Sep 2009 09:11:44 +0200 Subject: TeX (texlive) port status? In-Reply-To: References: <20090903173221.27B3525AA853@beta.macosforge.org> <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> <20090904023536.GF1400@ambulatoryclam.net> <20090904090415.GB16833@weetamoe.loria.fr> <6C177AD7-647A-4E66-A3FF-F0456893433A@macports.org> Message-ID: On 06/set/09, at 22:28, Ryan Schmidt wrote: > An alternate solution could be to write a tex meta-port that would > do this. Then we would update every single port that depends on > texlive to depend on that metaport instead. Something like: "tex-external Metaport that relies on binary TeX distribution external to mp" Is someone else interested in creating such a port? Bye -- Andrea From ryandesign at macports.org Wed Sep 9 00:14:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 9 Sep 2009 02:14:13 -0500 Subject: TeX (texlive) port status? In-Reply-To: References: <20090903173221.27B3525AA853@beta.macosforge.org> <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> <20090904023536.GF1400@ambulatoryclam.net> <20090904090415.GB16833@weetamoe.loria.fr> <6C177AD7-647A-4E66-A3FF-F0456893433A@macports.org> Message-ID: <6775BE00-5281-4F91-BAA4-83F026CFBFCD@macports.org> On Sep 9, 2009, at 02:11, Andrea D'Amore wrote: > > On 06/set/09, at 22:28, Ryan Schmidt wrote: > >> An alternate solution could be to write a tex meta-port that would >> do this. Then we would update every single port that depends on >> texlive to depend on that metaport instead. > > Something like: > "tex-external Metaport that relies on binary TeX distribution > external to mp" > > Is someone else interested in creating such a port? I meant a meta-port that would ensure either the MacPorts texlive port or an external TeX is installed. From ryandesign at macports.org Wed Sep 9 00:32:17 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 9 Sep 2009 02:32:17 -0500 Subject: Write to HFS in Snow Leopard In-Reply-To: <69DF0239-45CD-437B-887C-2060EC2575FA@gmail.com> References: <69DF0239-45CD-437B-887C-2060EC2575FA@gmail.com> Message-ID: <7687C93D-2143-41D4-918A-4A566103D929@macports.org> On Sep 9, 2009, at 02:21, Andrea D'Amore wrote: > On 09/set/09, at 01:52, Ryan Schmidt wrote: > >> It seems Apple has decided that in Snow Leopard we may now only >> read HFS volumes but not write to them. I need to write to an HFS >> disk image. Anybody know of a way to still do this in Snow Leopard? > > You could try using Basilisk II and its shared folder feature, this > way you could access HFS volumes with a two-steps action: > SnowLeopard --(shared folder)--> System 9.x ----> HFS volume. I am looking for a solution I can use at the command line, and thus can use in a portfile. From roederja at ethz.ch Wed Sep 9 08:25:29 2009 From: roederja at ethz.ch (=?UTF-8?B?SmFubiBSw7bCmmRlcg==?=) Date: Wed, 09 Sep 2009 17:25:29 +0200 Subject: Find out if x86_64 is supported Message-ID: Hi, for the eiffelstudio port I need a way to find out if the processor supports the 64bit extension. AFAIK the first intel iMacs don't have a 64bit CPU. What's the best way to do this in a portfile ? Thanks, Jann From roederja at ethz.ch Wed Sep 9 08:30:06 2009 From: roederja at ethz.ch (=?UTF-8?B?SmFubiBSw7bCmmRlcg==?=) Date: Wed, 09 Sep 2009 17:30:06 +0200 Subject: Find out if x86_64 is supported In-Reply-To: References: Message-ID: I know about the platform x86_64 but it does not seem to be selected on my new MacBook. On the macports command line I get: Platform: darwin 10 i386 It should be Platform: darwin 10 x86_64 though. Jann R??der schrieb: > Hi, > for the eiffelstudio port I need a way to find out if the processor > supports the 64bit extension. AFAIK the first intel iMacs don't have a > 64bit CPU. > > What's the best way to do this in a portfile ? > > Thanks, > Jann > From keybounce at gmail.com Wed Sep 9 09:54:35 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Wed, 9 Sep 2009 09:54:35 -0700 Subject: NCursesW is failing to compile +universal In-Reply-To: <1bd71ad80909070907x4905ec0dr1e81c51de3535e5f@mail.gmail.com> References: <1bd71ad80909070907x4905ec0dr1e81c51de3535e5f@mail.gmail.com> Message-ID: <1bd71ad80909090954m1391aee3p15cfeb94f317fc92@mail.gmail.com> On Mon, Sep 7, 2009 at 9:07 AM, Michael_google gmail_Gersten wrote: > I have no clue what to do next here. You are listed as the maintainer > for this port. > > Kleiman-ibook:~ michael$ sudo port -p install gtk2 +universal > Password: > ---> ?Computing dependencies for gtk2 > ---> ?Configuring ncursesw > ---> ?Configuring ncursesw for architecture ppc > ---> ?Configuring ncursesw for architecture i386 > Error: Target org.macports.configure returned: configure failure: > shell command " cd > "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_ncursesw/work/ncurses-5.7-i386" > && ./configure --prefix=/opt/local --disable-dependency-tracking > --disable-dependency-tracking --enable-widec --disable-rpath > --with-shared --without-debug --without-ada --enable-safe-sprintf > --enable-sigwinch --mandir=/opt/local/share/man > --with-manpage-format=normal --disable-dependency-tracking > --host=i386-apple-darwin9.8.0 --with-build-cc='/usr/bin/gcc-4.0' > --with-build-cpp='/usr/bin/cpp-4.0' > --with-build-cppflags=-D_XOPEN_SOURCE_EXTENDED --enable-big-core > --with-chtype=long --with-bool='unsigned char' " returned error 1 > Command output: checking for nawk... no > checking for awk... awk > checking for egrep... (cached) grep -E > checking for a BSD compatible install... /usr/bin/install -c > checking for tdlint... no > checking for lint... no > checking for alint... no > checking whether ln -s works... yes > checking for long file names... yes > checking if we should assume mixed-case filenames... auto > checking if filesystem supports mixed-case filenames... no > checking whether make sets ${MAKE}... yes > checking for ctags... yes > checking for makeflags variable... > checking for i386-apple-darwin9.8.0-ranlib... no > checking for ranlib... ranlib > checking for i386-apple-darwin9.8.0-ld... no > checking for ld... ld > checking for i386-apple-darwin9.8.0-ar... no > checking for ar... ar > checking for archiver options (symbol AR_OPTS)... rv > checking if you have specified an install-prefix... > checking for native build C compiler... /usr/bin/gcc-4.0 > checking for native build C preprocessor... /usr/bin/cpp-4.0 > checking for native build C flags... > checking for native build C preprocessor-flags... -D_XOPEN_SOURCE_EXTENDED > checking for native build linker-flags... > checking for native build linker-libraries... > configure: error: Cross-build requires two compilers. > Use --with-build-cc to specify the native compiler. > > Error: The following dependencies failed to build: atk gettext ncurses > ncursesw glib2 perl5 perl5.8 pkgconfig cairo fontconfig freetype zlib > libpixman libpng xrender xorg-libX11 autoconf help2man > p5-locale-gettext m4 automake libtool xorg-bigreqsproto > xorg-inputproto xorg-kbproto xorg-libXau xorg-xproto xorg-libXdmcp > xorg-util-macros xorg-xcmiscproto xorg-xextproto xorg-xf86bigfontproto > xorg-xtrans xorg-renderproto jasper jpeg pango Xft2 shared-mime-info > intltool gnome-common p5-getopt-long p5-pathtools p5-scalar-list-utils > p5-xml-parser libxml2 tiff xorg-libXcomposite xorg-compositeproto > xorg-libXext xorg-libXfixes xorg-fixesproto xorg-libXcursor > xorg-libXdamage xorg-damageproto xorg-libXi xorg-libXinerama > xorg-xineramaproto xorg-libXrandr xorg-randrproto > Error: Status 1 encountered during processing. Alright, I found this change seems to work: Kleiman-ibook:ncurses-5.7-i386 michael$ sudo ./configure --prefix=/opt/local --disable-dependency-tracking --disable-dependency-tracking --enable-widec --disable-rpath --with-shared --without-debug --without-ada --enable-safe-sprintf --enable-sigwinch --mandir=/opt/local/share/man --with-manpage-format=normal --disable-dependency-tracking --host=i386-apple-darwin9.8.0 --with-build-cc='/usr/bin/gcc-4.0' --with-build-cpp='/usr/bin/cpp-4.0' --with-build-cppflags=-D_XOPEN_SOURCE_EXTENDED --enable-big-core --with-chtype=long --with-bool='unsigned char' CFLAGS='-arch i386' With the "CFLAGS='arch i386'", it will now build i386 programs, and can tell that it is cross compiling, and configure works. However, I am concerned -- this is specifying gcc 4.0 for local builds, not the default (which is 4.2). I'm at the point where if this does not work, I'm just going to give up and use the partially-working, out of date native gtk library instead of the macports gtk library. (And why does gtk need ncurses if it's an X program? I know, it's used by something deep in the dependency tree. :-) Nope, turns out it needs CFLAGS='-arch i386' CXXFLAGS='-arch i386' To clarify: The old build was specifying the cross compiler flags correctly, but was NOT specifying the build arch. Hence, the cross compiler test did not come out correct, and the program does not build. From keybounce at gmail.com Wed Sep 9 09:59:02 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Wed, 9 Sep 2009 09:59:02 -0700 Subject: How do I tell macports that a step is finished? Message-ID: <1bd71ad80909090959q1c59732ew4df2147fb510c0a6@mail.gmail.com> I managed to get a problem port to configure and compile. ... /usr/bin/g++ -I../c++ -I../include -I. -DHAVE_CONFIG_H -I. -I../include -U_XOPEN_SOURCE -D_XOPEN_SOURCE=500 -DSIGWINCH=28 -D_XOPEN_SOURCE_EXTENDED -DNDEBUG -I/opt/local/include/ncursesw -arch i386 -dynamic -c ../c++/demo.cc -o ../obj_s/demo.o /usr/bin/g++ -o demo ../obj_s/demo.o -L../lib -lncurses++w -L../lib -lformw -lmenuw -lpanelw -lncursesw -Wl,-search_paths_first -I../c++ -I../include -I. -DHAVE_CONFIG_H -I. -I../include -U_XOPEN_SOURCE -D_XOPEN_SOURCE=500 -DSIGWINCH=28 -D_XOPEN_SOURCE_EXTENDED -DNDEBUG -I/opt/local/include/ncursesw -arch i386 -dynamic Kleiman-ibook:ncurses-5.7-i386 michael$ cd # All done! Yea! Now to install it, right? Kleiman-ibook:~ michael$ sudo port install ncurses +universal Password: ---> Computing dependencies for ncurses ---> Configuring ncursesw ---> Configuring ncursesw for architecture ppc Error: Target org.macports.configure returned: error copying "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_ncursesw/work/ncurses-5.7" to "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_ncursesw/work/ncurses-5.7-ppc/ncurses-5.7": file already exists Error: The following dependencies failed to build: ncursesw Error: Status 1 encountered during processing. Kleiman-ibook:~ michael$ It's already done the dependencies, the fetch, the configuration (which failed before, and now is manually done, as well as the i386 half of the compile.) How do I say "Step X is done, go to the next step"? From ryandesign at macports.org Wed Sep 9 12:06:58 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 9 Sep 2009 14:06:58 -0500 Subject: Find out if x86_64 is supported In-Reply-To: References: Message-ID: <6AABA4BC-5FA3-4A6B-89D7-7383EB0F2F37@macports.org> On Sep 9, 2009, at 10:30, Jann R??der wrote: > Jann R??der schrieb: >> > >> for the eiffelstudio port I need a way to find out if the processor >> supports the 64bit extension. AFAIK the first intel iMacs don't >> have a >> 64bit CPU. >> >> What's the best way to do this in a portfile ? You could use the same method MacPorts itself uses and call "sysctl hw.cpu64bit_capable": http://trac.macports.org/browser/trunk/base/src/macports1.0/macports.tcl?rev=56889#L667 But really, I think you want to use the build_arch variable, which can be set by the user in macports.conf and defaults to x86_64 on 64-bit- capable hardware in Snow Leopard, or i386 on 32-bit hardware in Snow Leopard or i386 or ppc as appropriate on Leopard or earlier. > I know about the platform x86_64 but it does not seem to be selected > on > my new MacBook. > > On the macports command line I get: > Platform: darwin 10 i386 > > It should be > Platform: darwin 10 x86_64 > > though. There is no such thing as "platform x86_64" in MacPorts. The only processor platforms in MacPorts are "i386" for any Intel machine (be it i386 or x86_64) and "powerpc" for any PowerPC machine (be it ppc or ppc64). From mail at uwe-arzt.de Wed Sep 9 14:04:47 2009 From: mail at uwe-arzt.de (Uwe Arzt) Date: Wed, 9 Sep 2009 23:04:47 +0200 Subject: [MacPorts] #21237: mcpp doesn't build under Snow Leopard In-Reply-To: <061.1ae560c56233cbdbbb80882c6f11668d@macports.org> References: <052.6a824cba5ac98cb7b0300ab7137ef567@macports.org> <061.1ae560c56233cbdbbb80882c6f11668d@macports.org> Message-ID: Hi Toby, thanks for this very fast fix. Just an additional question: What is the preferred proceeding for fixing bugs like that? I haven' t tested it under leopard and also not under other os like linux. So my patch was -at that moment- meant as a hint to the port maintainer (and in this case also the software developer). Should patches always be tested under Leopard and Tiger also? If yes, is there a machine available at the internet (because at the moment i have only one Mac, running under Snow Leopard)? Works for me now :) Thanks... :q! Uwe Am 09.09.2009 um 21:34 schrieb MacPorts: > #21237: mcpp doesn't build under Snow Leopard > ------------------------------- > +-------------------------------------------- > Reporter: mail@? | Owner: kmatsui@? > Type: defect | Status: closed > Priority: Normal | Milestone: > Component: ports | Version: 1.8.0 > Resolution: fixed | Keywords: snowleopard > Port: mcpp | > ------------------------------- > +-------------------------------------------- > Changes (by toby@?): > > * status: new => closed > * resolution: => fixed > > > Comment: > > r57328 > > -- > Ticket URL: > MacPorts > Ports system for Mac OS From ryandesign at macports.org Wed Sep 9 14:29:44 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 9 Sep 2009 16:29:44 -0500 Subject: [MacPorts] #21237: mcpp doesn't build under Snow Leopard In-Reply-To: References: <052.6a824cba5ac98cb7b0300ab7137ef567@macports.org> <061.1ae560c56233cbdbbb80882c6f11668d@macports.org> Message-ID: On Sep 9, 2009, at 16:04, Uwe Arzt wrote: > What is the preferred proceeding for fixing bugs like that? I > haven' t tested it under leopard and also not under other os like > linux. So my patch was -at that moment- meant as a hint to the port > maintainer (and in this case also the software developer). The problem should probably be reported to the software developer. > Should patches always be tested under Leopard and Tiger also? If > yes, is there a machine available at the internet (because at the > moment i have only one Mac, running under Snow Leopard)? Ideally one would test everything under all available OSes but I would be surprised if anybody actually does -- even those few who actually have access. I just tested and it still builds fine under Leopard and Tiger. Although we state that MacPorts can be used on operating systems other than Mac OS X / Darwin, I would be surprised if more than a handful of people are actually doing so, so changes that break on those other operating systems aren't the end of the world. But if you already know that a change you're proposing is Mac-specific, then it should go in a "platform darwin" section. From ryandesign at macports.org Wed Sep 9 14:31:01 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 9 Sep 2009 16:31:01 -0500 Subject: How do I tell macports that a step is finished? In-Reply-To: <1bd71ad80909090959q1c59732ew4df2147fb510c0a6@mail.gmail.com> References: <1bd71ad80909090959q1c59732ew4df2147fb510c0a6@mail.gmail.com> Message-ID: On Sep 9, 2009, at 11:59, Michael_google gmail_Gersten wrote: > I managed to get a problem port to configure and compile. > > ... > /usr/bin/g++ -I../c++ -I../include -I. -DHAVE_CONFIG_H -I. > -I../include -U_XOPEN_SOURCE -D_XOPEN_SOURCE=500 -DSIGWINCH=28 > -D_XOPEN_SOURCE_EXTENDED -DNDEBUG -I/opt/local/include/ncursesw -arch > i386 -dynamic -c ../c++/demo.cc -o ../obj_s/demo.o > /usr/bin/g++ -o demo ../obj_s/demo.o -L../lib -lncurses++w -L../lib > -lformw -lmenuw -lpanelw -lncursesw -Wl,-search_paths_first > -I../c++ -I../include -I. -DHAVE_CONFIG_H -I. -I../include > -U_XOPEN_SOURCE -D_XOPEN_SOURCE=500 -DSIGWINCH=28 > -D_XOPEN_SOURCE_EXTENDED -DNDEBUG -I/opt/local/include/ncursesw -arch > i386 -dynamic > Kleiman-ibook:ncurses-5.7-i386 michael$ cd > # All done! Yea! Now to install it, right? > Kleiman-ibook:~ michael$ sudo port install ncurses +universal > Password: > ---> Computing dependencies for ncurses > ---> Configuring ncursesw > ---> Configuring ncursesw for architecture ppc > Error: Target org.macports.configure returned: error copying > "/opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_ncursesw > /work/ncurses-5.7" > to "/opt/local/var/macports/build/ > _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_ncursesw > /work/ncurses-5.7-ppc/ncurses-5.7": > file already exists > Error: The following dependencies failed to build: ncursesw > Error: Status 1 encountered during processing. > Kleiman-ibook:~ michael$ > > It's already done the dependencies, the fetch, the configuration > (which failed before, and now is manually done, as well as the i386 > half of the compile.) > > How do I say "Step X is done, go to the next step"? That information is recorded in the state file, which is stored in the file named .macports.${name}.state in the port's work directory. It includes a line for every completed phase. From ryandesign at macports.org Wed Sep 9 14:37:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 9 Sep 2009 16:37:24 -0500 Subject: NCursesW is failing to compile +universal In-Reply-To: <1bd71ad80909090954m1391aee3p15cfeb94f317fc92@mail.gmail.com> References: <1bd71ad80909070907x4905ec0dr1e81c51de3535e5f@mail.gmail.com> <1bd71ad80909090954m1391aee3p15cfeb94f317fc92@mail.gmail.com> Message-ID: <7A135B7E-972D-4A95-8517-5238034E4939@macports.org> On Sep 9, 2009, at 11:54, Michael_google gmail_Gersten wrote: >> Kleiman-ibook:~ michael$ sudo port -p install gtk2 +universal > Note that I don't believe anything that uses glib2 (such as gtk2) will work properly on a PowerPC Mac at this point, given this ticket: http://trac.macports.org/ticket/20372 glib2 will build and install, but it will contain incorrect information in its header files which will either prevent other ports (like gtk2) from building, or at least prevent them from working right. From dluke at geeklair.net Wed Sep 9 14:39:15 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed, 9 Sep 2009 17:39:15 -0400 Subject: How do I tell macports that a step is finished? In-Reply-To: References: <1bd71ad80909090959q1c59732ew4df2147fb510c0a6@mail.gmail.com> Message-ID: <46D155EA-12D3-4AED-88AA-41C200C94725@geeklair.net> On Sep 9, 2009, at 5:31 PM, Ryan Schmidt wrote: >> It's already done the dependencies, the fetch, the configuration >> (which failed before, and now is manually done, as well as the i386 >> half of the compile.) >> >> How do I say "Step X is done, go to the next step"? > > That information is recorded in the state file, which is stored in > the file named .macports.${name}.state in the port's work directory. > It includes a line for every completed phase. ... but manually editing it is almost never what you actually want to do (hint - whatever you did to 'manually' run configure could be added to the portfile so that when port runs configure it works). -- 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 keybounce at gmail.com Wed Sep 9 14:51:37 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Wed, 9 Sep 2009 14:51:37 -0700 Subject: How do I tell macports that a step is finished? In-Reply-To: <46D155EA-12D3-4AED-88AA-41C200C94725@geeklair.net> References: <1bd71ad80909090959q1c59732ew4df2147fb510c0a6@mail.gmail.com> <46D155EA-12D3-4AED-88AA-41C200C94725@geeklair.net> Message-ID: <1bd71ad80909091451k43a3805bn49037f4bf425745e@mail.gmail.com> >>> It's already done the dependencies, the fetch, the configuration >>> (which failed before, and now is manually done, as well as the i386 >>> half of the compile.) >>> >>> How do I say "Step X is done, go to the next step"? >> >> That information is recorded in the state file, which is stored in the >> file named .macports.${name}.state in the port's work directory. It includes >> a line for every completed phase. > > > ... but manually editing it is almost never what you actually want to do > (hint - whatever you did to 'manually' run configure could be added to the > portfile so that when port runs configure it works). Ok, how do I modify the portfile? What do I need to do to add CFLAGS='-arch xxxx' CXXFLAGS='-arch xxxx' From keybounce at gmail.com Wed Sep 9 14:55:07 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Wed, 9 Sep 2009 14:55:07 -0700 Subject: NCursesW is failing to compile +universal In-Reply-To: <7A135B7E-972D-4A95-8517-5238034E4939@macports.org> References: <1bd71ad80909070907x4905ec0dr1e81c51de3535e5f@mail.gmail.com> <1bd71ad80909090954m1391aee3p15cfeb94f317fc92@mail.gmail.com> <7A135B7E-972D-4A95-8517-5238034E4939@macports.org> Message-ID: <1bd71ad80909091455w7cfb8dd4ye6f37ff6822f654d@mail.gmail.com> > Note that I don't believe anything that uses glib2 (such as gtk2) will work > properly on a PowerPC Mac at this point, given this ticket: > > http://trac.macports.org/ticket/20372 > > glib2 will build and install, but it will contain incorrect information in > its header files which will either prevent other ports (like gtk2) from > building, or at least prevent them from working right. Oh for bleepity bleep. I'm just going to download and use the not-quite-ready quartz version of gtk then. Sigh. And all this is just for the map editor which, up until now, wasn't a "required" build and wasn't even PPC ready (didn't generate compatible maps because of floating point issues). From keybounce at gmail.com Wed Sep 9 15:01:51 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Wed, 9 Sep 2009 15:01:51 -0700 Subject: How do I tell macports that a step is finished? In-Reply-To: <1bd71ad80909091451k43a3805bn49037f4bf425745e@mail.gmail.com> References: <1bd71ad80909090959q1c59732ew4df2147fb510c0a6@mail.gmail.com> <46D155EA-12D3-4AED-88AA-41C200C94725@geeklair.net> <1bd71ad80909091451k43a3805bn49037f4bf425745e@mail.gmail.com> Message-ID: <1bd71ad80909091501g172fa5cdg7c5b291c70080e8b@mail.gmail.com> > Ok, how do I modify the portfile? What do I need to do to add > CFLAGS='-arch xxxx' CXXFLAGS='-arch xxxx' Actually, that might not be enough for NCursesW. Part of what it does differs if you are cross compiling. The test for cross compiling is, "Am I unable to run the executable just produced by the compiler?". I know that i386 Macs will run PPC applications. Will they run PPC unix executables? If so, then the cross compilation test will fail. From blb at macports.org Wed Sep 9 21:20:15 2009 From: blb at macports.org (Bryan Blackburn) Date: Wed, 9 Sep 2009 22:20:15 -0600 Subject: [57344] trunk/dports/security/ccrypt/Portfile In-Reply-To: <20090910035053.4B78F267CC3D@beta.macosforge.org> References: <20090910035053.4B78F267CC3D@beta.macosforge.org> Message-ID: <20090910042015.GN577@ninagal.withay.com> On Wed, Sep 09, 2009 at 08:50:52PM -0700, ryandesign at macports.org said: > Revision: 57344 > http://trac.macports.org/changeset/57344 > Author: ryandesign at macports.org > Date: 2009-09-09 20:50:48 -0700 (Wed, 09 Sep 2009) > Log Message: > ----------- > ccrypt: reenable parallel build; see > https://sourceforge.net/tracker/?func=detail&atid=429289&aid=2846805&group_id=40913 > > Modified Paths: > -------------- > trunk/dports/security/ccrypt/Portfile > > Modified: trunk/dports/security/ccrypt/Portfile > =================================================================== > --- trunk/dports/security/ccrypt/Portfile 2009-09-10 02:16:20 UTC (rev 57343) > +++ trunk/dports/security/ccrypt/Portfile 2009-09-10 03:50:48 UTC (rev 57344) > @@ -34,9 +34,9 @@ > sha1 5ad1889c71be905c3004c80dc011948c9c35c814 \ > rmd160 2e7ec037dcfab82ad6963b8644a52017ac6c003e > > -use_parallel_build no > +use_parallel_build yes Note that, as of MacPorts 1.8, parallel is enabled by default so simply removing use_parallel_build also works... Bryan [...] From ryandesign at macports.org Wed Sep 9 21:28:15 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 9 Sep 2009 23:28:15 -0500 Subject: [57344] trunk/dports/security/ccrypt/Portfile In-Reply-To: <20090910042015.GN577@ninagal.withay.com> References: <20090910035053.4B78F267CC3D@beta.macosforge.org> <20090910042015.GN577@ninagal.withay.com> Message-ID: On Sep 9, 2009, at 23:20, Bryan Blackburn wrote: > On Wed, Sep 09, 2009 at 08:50:52PM -0700, ryandesign at macports.org > said: >> >> >> -use_parallel_build no >> +use_parallel_build yes > > Note that, as of MacPorts 1.8, parallel is enabled by default so > simply > removing use_parallel_build also works... Yes, but I like putting "use_parallel_build yes" in ports to indicate that yes, parallel building has been tested and found to work. If nothing is there, you do not know. From yenwenchieh at gmx.de Thu Sep 10 09:30:56 2009 From: yenwenchieh at gmx.de (Yen, Wenchieh) Date: Thu, 10 Sep 2009 18:30:56 +0200 Subject: "niced" processes on leopard Message-ID: <4AA929C0.9090704@gmx.de> hi, while some have already embraced snow leopard, I just moved on to leopard. to my surprise that the old school nice/renice don't seem to work any more, though ps -l still says that the processes are niced. the 'buildnicevalue' in macports.conf has thus no effect at all. Perhaps someone can give me a lesson or two about the most "advanced" OS? cheers, From toby at macports.org Thu Sep 10 10:48:56 2009 From: toby at macports.org (Toby Peterson) Date: Thu, 10 Sep 2009 10:48:56 -0700 Subject: "niced" processes on leopard In-Reply-To: <4AA929C0.9090704@gmx.de> References: <4AA929C0.9090704@gmx.de> Message-ID: <74c219d30909101048kcb4c73avdd7657120b185c77@mail.gmail.com> On Thu, Sep 10, 2009 at 09:30, Yen, Wenchieh wrote: > while some have already embraced snow leopard, I just moved on to leopard. > > to my surprise that the old school nice/renice don't seem to work any > more, though ps -l still says that the processes are niced. the > 'buildnicevalue' in macports.conf has thus no effect at all. > > Perhaps someone can give me a lesson or two about the most "advanced" OS? I don't understand what you're asking. Could you explain what behavior you're seeing and how this differs from your expectations? - Toby From ryandesign at macports.org Thu Sep 10 19:06:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 10 Sep 2009 21:06:24 -0500 Subject: [57417] trunk/dports/sysutils/bacula/Portfile In-Reply-To: <20090911014554.076B126ADD03@beta.macosforge.org> References: <20090911014554.076B126ADD03@beta.macosforge.org> Message-ID: On Sep 10, 2009, at 20:45, macsforever2000 at macports.org wrote: > + if {${os.major} == 10} { > + post-destroot { > + file copy ${workpath}/${worksrcdir}/src/filed/bacula-fd.conf $ > {destroot}${prefix}/etc/bacula/bacula-fd.conf.example > + file copy ${workpath}/${worksrcdir}/src/console/bconsole.conf > ${destroot}${prefix}/etc/bacula/bconsole.conf.example > + file rename ${destroot}${prefix}/etc/bacula/mtx-changer.conf $ > {destroot}${prefix}/etc/bacula/mtx-changer.conf.example > + } > + } > > "${workpath}/${worksrcdir}" is "${worksrcpath}" isn't it? From derek at chocolate-fish.com Thu Sep 10 19:59:11 2009 From: derek at chocolate-fish.com (Derek Harland) Date: Fri, 11 Sep 2009 14:59:11 +1200 Subject: Macports 1.8.0 deletes /opt symlink Message-ID: <250ABE47-59D7-4501-87C2-7D435B895F45@chocolate-fish.com> * I have /opt as a symlink pointing to another disk. * Having just upgrade to Macports 1.8.0 I've discovered that "port" is very keen on destroying this /opt symlink whenever it upgrades ports. * This ticket has more details: http://trac.macports.org/ticket/21297. Any clues? derek. From derek at chocolate-fish.com Thu Sep 10 20:03:43 2009 From: derek at chocolate-fish.com (Derek Harland) Date: Fri, 11 Sep 2009 15:03:43 +1200 Subject: Macports 1.8.0 deletes /opt symlink In-Reply-To: <250ABE47-59D7-4501-87C2-7D435B895F45@chocolate-fish.com> References: <250ABE47-59D7-4501-87C2-7D435B895F45@chocolate-fish.com> Message-ID: And replying to myself I see this is already noted in ticket: https://trac.macports.org/ticket/21082 so ignore my question ... On 11/09/2009, at 2:59 PM, Derek Harland wrote: > * I have /opt as a symlink pointing to another disk. > * Having just upgrade to Macports 1.8.0 I've discovered that "port" > is very keen on destroying this /opt symlink whenever it upgrades > ports. > * This ticket has more details: http://trac.macports.org/ticket/ > 21297. > > Any clues? > derek. > > _______________________________________________ > 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 Sep 11 01:32:45 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 11 Sep 2009 03:32:45 -0500 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: <4A9C6651.7040807@macports.org> References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> <4A9C6651.7040807@macports.org> Message-ID: On Aug 31, 2009, at 19:09, Rainer M?ller wrote: >> Ryan Schmidt wrote: >>> Rather than make everyone update this themselves, which will take >>> forever, I propose I do a batch find and replace in all ports, >>> changing livecheck.check to livecheck.type and svn.tag to >>> svn.revision. This will make these ports incompatible with MacPorts >>> 1.7.1 and earlier. Any objections? Any other batch changes I could >>> be >>> making now that MacPorts 1.8.0 is out? > > I am totally in favor of a batch change, but I would like to give > users > a few days of grace period for updating their MacPorts installations. > Let's say a week is enough? That would be next friday. Batch changes are done: * r57375: change livecheck.check to livecheck.type in ports * r57450: change livecheck.check to livecheck.type in portgroups * r57378: change svn.tag to svn.revision in ports * r57380: remove subversion dependency from ports using "fetch.type svn" * r57382: remove imake dependency from ports using "use_xmkmf" * r57453: remove autoconf, automake and libtool build dependencies from ports using "use_autoconf yes", "use_automake yes" or "use_autoreconf yes" From frstan at bellsouth.net Fri Sep 11 05:06:22 2009 From: frstan at bellsouth.net (William Davis) Date: Fri, 11 Sep 2009 08:06:22 -0400 Subject: "niced" processes on leopard In-Reply-To: <74c219d30909101048kcb4c73avdd7657120b185c77@mail.gmail.com> References: <4AA929C0.9090704@gmx.de> <74c219d30909101048kcb4c73avdd7657120b185c77@mail.gmail.com> Message-ID: <6EDDE6A3-C878-4FE4-9148-902267C22AAE@bellsouth.net> On Sep 10, 2009, at 1:48 PM, Toby Peterson wrote: > On Thu, Sep 10, 2009 at 09:30, Yen, Wenchieh > wrote: >> while some have already embraced snow leopard, I just moved on to >> leopard. >> >> to my surprise that the old school nice/renice don't seem to work any >> more, though ps -l still says that the processes are niced. the >> 'buildnicevalue' in macports.conf has thus no effect at all. >> >> Perhaps someone can give me a lesson or two about the most >> "advanced" OS? > > I don't understand what you're asking. Could you explain what behavior > you're seeing and how this differs from your expectations? > > - Toby I reported this bug to Apple right after Leopard came out. Now we have Snow Leopard. As a solution Apple has removed the "Nice" category from the CPU section of Activity Monitor. :( William Davis frstanATbellsouthDOTnet Mac OS X ver 10.6 Darwin 10.6 XQuartz 2.3.4 (xorg-server 1.4.2-apple45) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From yenwenchieh at gmx.de Fri Sep 11 05:47:59 2009 From: yenwenchieh at gmx.de (Yen, Wenchieh) Date: Fri, 11 Sep 2009 14:47:59 +0200 Subject: "niced" processes on leopard In-Reply-To: <74c219d30909101048kcb4c73avdd7657120b185c77@mail.gmail.com> References: <4AA929C0.9090704@gmx.de> <74c219d30909101048kcb4c73avdd7657120b185c77@mail.gmail.com> Message-ID: <4AAA46FF.3070601@gmx.de> ok Toby, By creating 2 'yes > /dev/null' and one 'nice -n 19 yes > /dev/null' on my core2duo, I would expect to see 2 cpus get near 100% load while one get supressed due to a lower priority. What I got was quite equally distributed cpu cycles to these 3 (though the niced one seemed to have a slightly lower load). I checked it with 'top' or 'Activity Monitor'. In the mean time I checked the niced one with 'ps'. The STAT column showed 'RN+' -- implying it was niced. cheers, Toby Peterson wrote: > On Thu, Sep 10, 2009 at 09:30, Yen, Wenchieh wrote: >> while some have already embraced snow leopard, I just moved on to leopard. >> >> to my surprise that the old school nice/renice don't seem to work any >> more, though ps -l still says that the processes are niced. the >> 'buildnicevalue' in macports.conf has thus no effect at all. >> >> Perhaps someone can give me a lesson or two about the most "advanced" OS? > > I don't understand what you're asking. Could you explain what behavior > you're seeing and how this differs from your expectations? > > - Toby > From dluke at geeklair.net Fri Sep 11 06:25:20 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 11 Sep 2009 09:25:20 -0400 Subject: "niced" processes on leopard In-Reply-To: <4AAA46FF.3070601@gmx.de> References: <4AA929C0.9090704@gmx.de> <74c219d30909101048kcb4c73avdd7657120b185c77@mail.gmail.com> <4AAA46FF.3070601@gmx.de> Message-ID: On Sep 11, 2009, at 8:47 AM, Yen, Wenchieh wrote: > By creating 2 'yes > /dev/null' and one 'nice -n 19 yes > /dev/null' > on > my core2duo, I would expect to see 2 cpus get near 100% load while one > get supressed due to a lower priority. > > What I got was quite equally distributed cpu cycles to these 3 (though > the niced one seemed to have a slightly lower load). I checked it with > 'top' or 'Activity Monitor'. > > In the mean time I checked the niced one with 'ps'. The STAT column > showed 'RN+' -- implying it was niced. You can file a bug with Apple if you want to see something like a 'scavenge class' for nice (or some way to mark a process so it only gets 'idle' or otherwise unused CPU cycles)... maybe it will eventually be implemented. I don't have 10.6 yet, so I don't know how different it is (or seems to be), but you haven't been able to nice things to work that way on any release of Mac OS X (going back prior to 10.0, even). -- 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 toby at macports.org Fri Sep 11 11:27:25 2009 From: toby at macports.org (Toby Peterson) Date: Fri, 11 Sep 2009 11:27:25 -0700 Subject: "niced" processes on leopard In-Reply-To: <4AAA46FF.3070601@gmx.de> References: <4AA929C0.9090704@gmx.de> <74c219d30909101048kcb4c73avdd7657120b185c77@mail.gmail.com> <4AAA46FF.3070601@gmx.de> Message-ID: <74c219d30909111127h74729e03vf14a076b36426dcc@mail.gmail.com> On Fri, Sep 11, 2009 at 05:47, Yen, Wenchieh wrote: > By creating 2 'yes > /dev/null' and one 'nice -n 19 yes > /dev/null' on > my core2duo, I would expect to see 2 cpus get near 100% load while one > get supressed due to a lower priority. > > What I got was quite equally distributed cpu cycles to these 3 (though > the niced one seemed to have a slightly lower load). I checked it with > 'top' or 'Activity Monitor'. > > In the mean time I checked the niced one with 'ps'. The STAT column > showed 'RN+' -- implying it was niced. Sounds like it's working. - Toby From toby at macports.org Fri Sep 11 11:28:29 2009 From: toby at macports.org (Toby Peterson) Date: Fri, 11 Sep 2009 11:28:29 -0700 Subject: "niced" processes on leopard In-Reply-To: <6EDDE6A3-C878-4FE4-9148-902267C22AAE@bellsouth.net> References: <4AA929C0.9090704@gmx.de> <74c219d30909101048kcb4c73avdd7657120b185c77@mail.gmail.com> <6EDDE6A3-C878-4FE4-9148-902267C22AAE@bellsouth.net> Message-ID: <74c219d30909111128t2ebf4dc5y5bafa948f08d64a@mail.gmail.com> On Fri, Sep 11, 2009 at 05:06, William Davis wrote: > > On Sep 10, 2009, at 1:48 PM, Toby Peterson wrote: > >> On Thu, Sep 10, 2009 at 09:30, Yen, Wenchieh wrote: >>> >>> while some have already embraced snow leopard, I just moved on to >>> leopard. >>> >>> to my surprise that the old school nice/renice don't seem to work any >>> more, though ps -l still says that the processes are niced. the >>> 'buildnicevalue' in macports.conf has thus no effect at all. >>> >>> Perhaps someone can give me a lesson or two about the most "advanced" OS? >> >> I don't understand what you're asking. Could you explain what behavior >> you're seeing and how this differs from your expectations? >> >> - Toby > > > I reported this bug to Apple right after Leopard came out. Now we have Snow > Leopard. ?As a solution Apple has removed the "Nice" category from the CPU > section of Activity Monitor. ?:( For technical reasons, top & Activity Monitor cannot accurately report the "niceness" of processes. This does not mean that the functionality is not working. - Toby From toby at macports.org Fri Sep 11 11:29:23 2009 From: toby at macports.org (Toby Peterson) Date: Fri, 11 Sep 2009 11:29:23 -0700 Subject: "niced" processes on leopard In-Reply-To: References: <4AA929C0.9090704@gmx.de> <74c219d30909101048kcb4c73avdd7657120b185c77@mail.gmail.com> <4AAA46FF.3070601@gmx.de> Message-ID: <74c219d30909111129p6035866aheeb224b0f6403020@mail.gmail.com> On Fri, Sep 11, 2009 at 06:25, Daniel J. Luke wrote: > On Sep 11, 2009, at 8:47 AM, Yen, Wenchieh wrote: >> >> By creating 2 'yes > /dev/null' and one 'nice -n 19 yes > /dev/null' on >> my core2duo, I would expect to see 2 cpus get near 100% load while one >> get supressed due to a lower priority. >> >> What I got was quite equally distributed cpu cycles to these 3 (though >> the niced one seemed to have a slightly lower load). I checked it with >> 'top' or 'Activity Monitor'. >> >> In the mean time I checked the niced one with 'ps'. The STAT column >> showed 'RN+' -- implying it was niced. > > > You can file a bug with Apple if you want to see something like a 'scavenge > class' for nice (or some way to mark a process so it only gets 'idle' or > otherwise unused CPU cycles)... maybe it will eventually be implemented. > > I don't have 10.6 yet, so I don't know how different it is (or seems to be), > but you haven't been able to nice things to work that way on any release of > Mac OS X (going back prior to 10.0, even). How many OSes even support this? Nice'ing a process just lowers its scheduling priority... obviously, it will still get scheduled. - Toby From ryandesign at macports.org Fri Sep 11 11:40:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 11 Sep 2009 13:40:05 -0500 Subject: [57497] trunk/dports/mail/ssmtp/Portfile In-Reply-To: <20090911183820.50AC526BE6F6@beta.macosforge.org> References: <20090911183820.50AC526BE6F6@beta.macosforge.org> Message-ID: <0DD224AB-67BF-4AB1-BEEC-A76DC4345EA0@macports.org> On Sep 11, 2009, at 13:38, raimue at macports.org wrote: > Revision: 57497 > http://trac.macports.org/changeset/57497 > Author: raimue at macports.org > Date: 2009-09-11 11:38:15 -0700 (Fri, 11 Sep 2009) > Log Message: > ----------- > mail/ssmtp: > This port is abandoned for a long time, moving to nomaintainer, #14983 If Olaf is gone, we should nomaintainer all his ports: cleanscore darkstat libidn slang slrn ssmtp From dluke at geeklair.net Fri Sep 11 11:46:32 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 11 Sep 2009 14:46:32 -0400 Subject: "niced" processes on leopard In-Reply-To: <74c219d30909111129p6035866aheeb224b0f6403020@mail.gmail.com> References: <4AA929C0.9090704@gmx.de> <74c219d30909101048kcb4c73avdd7657120b185c77@mail.gmail.com> <4AAA46FF.3070601@gmx.de> <74c219d30909111129p6035866aheeb224b0f6403020@mail.gmail.com> Message-ID: <951849BD-42DF-4F48-8687-D8EF64F6CAE4@geeklair.net> On Sep 11, 2009, at 2:29 PM, Toby Peterson wrote: >> You can file a bug with Apple if you want to see something like a >> 'scavenge >> class' for nice (or some way to mark a process so it only gets >> 'idle' or >> otherwise unused CPU cycles)... maybe it will eventually be >> implemented. >> >> I don't have 10.6 yet, so I don't know how different it is (or >> seems to be), >> but you haven't been able to nice things to work that way on any >> release of >> Mac OS X (going back prior to 10.0, even). > > How many OSes even support this? Nice'ing a process just lowers its > scheduling priority... obviously, it will still get scheduled. linux has a 'batch' process class, and freebsd has an idle priority class (that sits below real-time and time-share-scheduled). This would be useful for running something like the distributed.net client on a server. If you do it on an OS that supports it, it doesn't add much latency to 'real work', but on Mac OS X it always has. I don't know of another situation where it would be useful (and for the vast majority of Mac OS X users, it probably makes more sense to let the computer do power saving instead of running something like that). -- 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 yenwenchieh at gmx.de Fri Sep 11 13:32:17 2009 From: yenwenchieh at gmx.de (Yen, Wenchieh) Date: Fri, 11 Sep 2009 22:32:17 +0200 Subject: "niced" processes on leopard In-Reply-To: <74c219d30909111129p6035866aheeb224b0f6403020@mail.gmail.com> References: <4AA929C0.9090704@gmx.de> <74c219d30909101048kcb4c73avdd7657120b185c77@mail.gmail.com> <4AAA46FF.3070601@gmx.de> <74c219d30909111129p6035866aheeb224b0f6403020@mail.gmail.com> Message-ID: <4AAAB3D1.9080709@gmx.de> Hi, I was not questioning if this niceness thing was 'actually' functioning or broken. I was asking if you mac gurus were aware of this behavior in Leopard and if there were other commands that could give back what I used to have in Tiger -- now I just learned not to install ports at the same time, let it be niced or not, if I need the horse power also for something much urgent. cheers, From mnick at macports.org Fri Sep 11 16:05:12 2009 From: mnick at macports.org (Maximilian Nickel) Date: Sat, 12 Sep 2009 01:05:12 +0200 Subject: [RFC] fortran PortGroup Message-ID: <7bad5d350909111605j7d882a28o88b54a8c73b765c4@mail.gmail.com> Hi, since all the ports that depend on fortran either drown in gcc variants or don't create variants for all gcc/g95 versions i've decided to create a litte PortGroup for ports that need fortran. The file for the PortGroup is attached and it would be great to have some comments/thoughts on it. It looks a bit messy as i've decided to go down the metaprogramming path and not explicitly write down every variant. I'm by no means a Tcl expert so maybe all this can be achieved a lot easier, but that's the version i've come up with that works. Usage of the group would be something like PortGroup fortran 1.0 fortran.setup fortran versions that should be explicitly disabled can be stated as arguments to fortran.setup (what might be a bit unintuitive). Error handling and other reasonableness is missing. Cheers /Max -------------- next part -------------- A non-text attachment was scrubbed... Name: fortran-1.0.tcl Type: application/x-tcl Size: 3331 bytes Desc: not available URL: From talklists at newgeo.com Fri Sep 11 16:29:56 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 11 Sep 2009 16:29:56 -0700 Subject: p5-Astro-satpass Port Submission Message-ID: At the request of this thread: http://www.nabble.com/Macports-and-CPAN-td25386477.html I went ahead and made this port. I have not heard back from the OP, so I am the only test case. The port has been submitted here: http://trac.macports.org/ticket/21318 My basic tests show it works. -- Scott * If you contact me off list replace talklists@ with scott@ * From howarth at bromo.med.uc.edu Fri Sep 11 18:19:22 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 11 Sep 2009 21:19:22 -0400 Subject: portfile and install scripts Message-ID: <20090912011922.GA4434@bromo.med.uc.edu> Hi, I am switching all of my packaging efforts over from fink to MacPorts and had a question which I haven't quite found the answer to in the MacPorts documentation. My initial attempt was going to be a port of the molmol molecular modelling program. The fink packaging script uses an InstallScript of the form... InstallScript: << #!/bin/zsh -efv /bin/rm -f **/*.o **/*.c mkdir -p %i/share/molmol cp -R * %i/share/molmol/. mkdir -p %i/bin ln -s %p/share/molmol/molmol %i/bin/molmol mkdir -p %i/share/doc/molmol ln -s %p/share/molmol/COPYING %i/share/doc/molmol/COPYING ln -s %p/share/molmol/man %i/share/doc/molmol/man << What is best practices in MacPorts for trying to achieve this. Would that be achieved with a single phase override like... destroot { /bin/rm -f **/*.o **/*.c mkdir -p ${destroot}${prefix}/share/molmol cp -R * ${destroot}${prefix}/share/molmol/. mkdir -p ${destroot}${prefix}/bin ln -s ${prefix}/share/molmol/molmol ${destroot}${prefix}/bin/molmol mkdir -p ${destroot}${prefix}/share/doc/molmol ln -s ${prefix}/share/molmol/COPYING ${destroot}${prefix}/share/doc/molmol/COPYING ln -s ${prefix}/share/molmol/man ${destroot}${prefix}/share/doc/molmol/man } or am I misreading the manual? Thanks in advance for any advice here. Jack From jeremy at lavergne.gotdns.org Fri Sep 11 18:29:16 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 11 Sep 2009 21:29:16 -0400 Subject: portfile and install scripts In-Reply-To: <20090912011922.GA4434@bromo.med.uc.edu> References: <20090912011922.GA4434@bromo.med.uc.edu> Message-ID: > I am switching all of my packaging efforts over from fink to > MacPorts and had a question which I haven't quite found the answer > to in the MacPorts documentation. My initial attempt was going to be > a port of the molmol molecular modelling program. The fink packaging > script uses an InstallScript of the form... > > InstallScript: << > #!/bin/zsh -efv > /bin/rm -f **/*.o **/*.c > mkdir -p %i/share/molmol > cp -R * %i/share/molmol/. > mkdir -p %i/bin > ln -s %p/share/molmol/molmol %i/bin/molmol > mkdir -p %i/share/doc/molmol > ln -s %p/share/molmol/COPYING %i/share/doc/molmol/COPYING > ln -s %p/share/molmol/man %i/share/doc/molmol/man > << > > What is best practices in MacPorts for trying to achieve this. Would > that be achieved with a single phase override > like... > > destroot { > /bin/rm -f **/*.o **/*.c > mkdir -p ${destroot}${prefix}/share/molmol > cp -R * ${destroot}${prefix}/share/molmol/. > mkdir -p ${destroot}${prefix}/bin > ln -s ${prefix}/share/molmol/molmol ${destroot}${prefix}/bin/molmol > mkdir -p ${destroot}${prefix}/share/doc/molmol > ln -s ${prefix}/share/molmol/COPYING ${destroot}${prefix}/share/doc/ > molmol/COPYING > ln -s ${prefix}/share/molmol/man ${destroot}${prefix}/share/doc/ > molmol/man > } > > or am I misreading the manual? Thanks in advance for any advice here. You probably don't want to override the whole phase; I'd suggest using post-destroot instead. This will make sense since the destroot phase will put the package into a "sandbox" where you can then take out what you want prior to it actually being installed. From ryandesign at macports.org Fri Sep 11 23:43:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 01:43:40 -0500 Subject: [57510] trunk/dports/multimedia/x264/Portfile In-Reply-To: <20090912003516.A230626C4062@beta.macosforge.org> References: <20090912003516.A230626C4062@beta.macosforge.org> Message-ID: <8F45E20F-C188-4C2B-9A56-D2A8F0AD85B5@macports.org> On Sep 11, 2009, at 19:35, devans at macports.org wrote: > +if {"darwin" == ${os.platform} && 10 == ${os.major} && [info exists > build_arch] && "x86_64" == $build_arch} { We don't need to check if build_arch exists. It does exist in MacPorts 1.8.0, and we don't support earlier versions of MacPorts. It would make portfiles easier to read if we removed the checks for the existence of build_arch. From ryandesign at macports.org Fri Sep 11 23:54:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 01:54:38 -0500 Subject: portfile and install scripts In-Reply-To: <20090912011922.GA4434@bromo.med.uc.edu> References: <20090912011922.GA4434@bromo.med.uc.edu> Message-ID: On Sep 11, 2009, at 20:19, Jack Howarth wrote: > I am switching all of my packaging efforts over > from fink to MacPorts Welcome! We're glad to have you on board. > and had a question which I > haven't quite found the answer to in the MacPorts > documentation. My initial attempt was going to be > a port of the molmol molecular modelling program. > The fink packaging script uses an InstallScript > of the form... > > InstallScript: << > #!/bin/zsh -efv > /bin/rm -f **/*.o **/*.c > mkdir -p %i/share/molmol > cp -R * %i/share/molmol/. > mkdir -p %i/bin > ln -s %p/share/molmol/molmol %i/bin/molmol > mkdir -p %i/share/doc/molmol > ln -s %p/share/molmol/COPYING %i/share/doc/molmol/COPYING > ln -s %p/share/molmol/man %i/share/doc/molmol/man > << Ok, looks like a shell script with some variable substitution. MacPorts portfiles have (more verbosely-named) variables for the same kinds of things, but portfiles are Tcl scripts, not shell scripts. We have some extensions to Tcl in MacPorts that let you write some commands that look like shell commands. For example, we have "ln -s" in MacPorts and you can use it as if you were in a shell script. But it's really just an alias for the Tcl procedure "file link -symbolic". We also have "xinstall" which behaves a lot like the shell command "install" and is what is usually used in portfiles to install files and directories. Consult the guide at http://guide.macports.org/ and any Tcl reference to see what other syntax is available. > What is best practices in MacPorts for trying to achieve > this. Would that be achieved with a single phase override > like... If the software in question has no "make install", or the "make install" is too broken to make it worthwhile to fix, then yes, you can override the destroot phase. If "make install" exists and works, or can be patched without too much effort to work, then that's preferred. If you need to do additional work beyond what "make install" does, you can do so in a post-destroot phase. > destroot { > /bin/rm -f **/*.o **/*.c Not valid in Tcl. Look into the "file delete" and "glob" functions. > mkdir -p ${destroot}${prefix}/share/molmol Use "file mkdir" or "xinstall -d" when you want to make a directory. My own stylistic preference is to use "xinstall" in the destroot phase and "file" in other phases. But in this case, skip the creation of this directory, because you can more easily just copy the whole worksrcpath: > cp -R * ${destroot}${prefix}/share/molmol/. file copy ${worksrcpath} ${destroot}${prefix}/share/molmol/ > mkdir -p ${destroot}${prefix}/bin Not necessary; MacPorts makes this directory for you. > ln -s ${prefix}/share/molmol/molmol ${destroot}${prefix}/bin/molmol > mkdir -p ${destroot}${prefix}/share/doc/molmol xinstall -d > ln -s ${prefix}/share/molmol/COPYING ${destroot}${prefix}/share/doc/ > molmol/COPYING > ln -s ${prefix}/share/molmol/man ${destroot}${prefix}/share/doc/ > molmol/man > } I'm not sure it makes sense to symlink the manpages into the doc directory. Manpages should be in the share/man directory so that the man command can find them. Speaking of which, would the man command find manpages in ${prefix}/share/molmol/man? I wouldn't think so, so I would suggest moving the manpages from wherever they get installed to $ {prefix}/share/man/manX where X is the correct category number. Or if the configure script (if there is one) has a --mandir parameter or other way you can influence where manpages go, use that instead of moving it later. From howarth at bromo.med.uc.edu Sat Sep 12 03:45:34 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 06:45:34 -0400 Subject: portfile and install scripts In-Reply-To: References: <20090912011922.GA4434@bromo.med.uc.edu> Message-ID: <20090912104534.GA7883@bromo.med.uc.edu> On Sat, Sep 12, 2009 at 01:54:38AM -0500, Ryan Schmidt wrote: > > I'm not sure it makes sense to symlink the manpages into the doc > directory. Manpages should be in the share/man directory so that the man > command can find them. Speaking of which, would the man command find > manpages in ${prefix}/share/molmol/man? I wouldn't think so, so I would > suggest moving the manpages from wherever they get installed to $ > {prefix}/share/man/manX where X is the correct category number. Or if > the configure script (if there is one) has a --mandir parameter or other > way you can influence where manpages go, use that instead of moving it > later. Ryan, The molmol package doesn't have a proper 'make install' so we have always just pruned the source tree and set up the symlinks for the compiled binary to run. In this case, because it carries along a number of non-code support files, in fink it was placed in %p/share/molmol rather than %p/lib/molmol. I will likely cleanup the installation approach some more compared to what we used in fink but first need to get my sea legs on this new packaging system. FYI, one reason I moved over from fink (where I used to maintain the gcc4X, openmotf3/4, lesstif, openmmpi, lammpi, gromacs(-mpi), sparky-py, molmol, pymol-py, relax-py, ccpnmr-py packges among others) is to make sure I can still test against X11 Xquartz. My goal over the few months is to at least get molmol, sparky and pymol into MacPorts. I assume that there isn't the same -py type of variant in fink (although it is less important at the moment since most code really can't survive the transition to python 3.1.x and it seems s unlikely upstream will move beyond a python 2.6.x release in the python 2.x series). Jack ps I'll also make sure than any changes I can find from our fink x86_64 transition are ticketed here. In particular, I found a bug in lesstif 0.95.2 which caused nedit to bus error (due to an incorrect merge upstream of debian's submitted 64-bit patches). http://sourceforge.net/tracker/index.php?func=detail&aid=2846234&group_id=8596&atid=308596 > > From howarth at bromo.med.uc.edu Sat Sep 12 03:52:27 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 06:52:27 -0400 Subject: portfile and install scripts In-Reply-To: References: <20090912011922.GA4434@bromo.med.uc.edu> Message-ID: <20090912105227.GB7883@bromo.med.uc.edu> On Sat, Sep 12, 2009 at 01:54:38AM -0500, Ryan Schmidt wrote: > > Ok, looks like a shell script with some variable substitution. MacPorts > portfiles have (more verbosely-named) variables for the same kinds of > things, but portfiles are Tcl scripts, not shell scripts. > > Ryan, One question on that. If push came to shove and you absolutely needed a shell script, wouldn't it be possible to just add patches to the package the could create an shell script that could be executed 'sh build_script.sh' from within the appropriate phase? Not that I would resort to that but it seemed like a possible last resort option if necessary. Jack > From howarth at bromo.med.uc.edu Sat Sep 12 06:14:34 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 09:14:34 -0400 Subject: checksums for multiple distfiles? Message-ID: <20090912131434.GA8601@bromo.med.uc.edu> I am having problems with the correct syntax for adding checksums for multiple distfiles in a Portfile. My first attempt so far at a new port looks like... # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 # $Id$ PortSystem 1.0 name molmol version 2k.2.0 categories science maintainers howarth at bromo.med.uc.edu description Molecular graphics display program long_description MOLMOL is a molecular graphics program for displaying, analyzing, \ and manipulating the three-dimensional structure of biological \ macromolecules, with special emphasis on the study of protein \ or DNA structures determined by NMR. The program runs on UNIX \ and Windows NT/95/98/2000 and is freely available. It does not work \ properly with RNA. homepage http://www.mol.biol.ethz.ch/wuthrich/software/molmol/ platforms darwin master_sites ftp://ftp.mol.biol.ethz.ch/software/MOLMOL/unix-gzip distfiles molmol-2k.2.0-src.tar.gz \ molmol-2k.2.0-doc.tar.gz checksums md5 e1f4416d8041a67fa08cadb03ed91c7c \ sha1 09482a1dea601563ca64e773dc0ec47019e22c63 \ rmd160 b1de89953631dd9b11928751d7853cb511bf45f0 \ md5 517545b60b0179ab691a679ed29903a7 \ sha1 b47551283fa19f57f4d5edcbd52f725055d80b7f \ rmd160 08b3e21ab6eb7c9044e59373334181ff91ca8a53 depends_lib port:openmotif \ port:glut \ port:tiff \ port:jpeg \ port:libpng patchfiles molmol-build.diff destroot { # Install example files not installed by the Makefile file mkdir ${destroot}${prefix}/share/${name} file copy ${worksrcpath} \ ${destroot}${prefix}/share/${name} file mkdir ${destroot}${prefix}/bin ln -s ${prefix}/share/${name}/${name} ${destroot}${prefix}/bin/${name} file mkdir ${destroot}${prefix}/share/doc/${name} ln -s ${prefix}/share/${name}/COPYING ${destroot}${prefix}/share/doc/${name}/COPYING ln -s ${prefix}/share/${name}/man ${destroot}${prefix}/share/doc/${name}/man } which produces... ---> Computing dependencies for molmol ---> Fetching molmol ---> Attempting to fetch molmol-2k.2.0-src.tar.gz from http://distfiles.macports.org/molmol ---> Attempting to fetch molmol-2k.2.0-src.tar.gz from http://arn.se.distfiles.macports.org/molmol ---> Attempting to fetch molmol-2k.2.0-src.tar.gz from http://aarnet.au.distfiles.macports.org/pub/macports/mpdistfiles/molmol ---> Attempting to fetch molmol-2k.2.0-src.tar.gz from ftp://ftp.mol.biol.ethz.ch/software/MOLMOL/unix-gzip ---> Attempting to fetch molmol-2k.2.0-doc.tar.gz from http://distfiles.macports.org/molmol ---> Attempting to fetch molmol-2k.2.0-doc.tar.gz from http://arn.se.distfiles.macports.org/molmol ---> Attempting to fetch molmol-2k.2.0-doc.tar.gz from http://aarnet.au.distfiles.macports.org/pub/macports/mpdistfiles/molmol ---> Attempting to fetch molmol-2k.2.0-doc.tar.gz from ftp://ftp.mol.biol.ethz.ch/software/MOLMOL/unix-gzip ---> Verifying checksum(s) for molmol Error: No checksum set for molmol-2k.2.0-src.tar.gz Error: No checksum set for molmol-2k.2.0-doc.tar.gz Error: Target org.macports.checksum returned: Unable to verify file checksums Error: Status 1 encountered during processing. I am having trouble finding an existing Portfile which uses multiple distfiles to discover the correct syntax in this case. Thanks in advance for any advice. Jack From howarth at bromo.med.uc.edu Sat Sep 12 06:46:50 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 09:46:50 -0400 Subject: checksums for multiple distfiles? In-Reply-To: <20090912131434.GA8601@bromo.med.uc.edu> References: <20090912131434.GA8601@bromo.med.uc.edu> Message-ID: <20090912134650.GA8777@bromo.med.uc.edu> On Sat, Sep 12, 2009 at 09:14:34AM -0400, Jack Howarth wrote: > I am having problems with the correct syntax for > adding checksums for multiple distfiles in a Portfile. > My first attempt so far at a new port looks like... > > # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 > # $Id$ > PortSystem 1.0 > name molmol > version 2k.2.0 > categories science > maintainers howarth at bromo.med.uc.edu > description Molecular graphics display program > long_description MOLMOL is a molecular graphics program for displaying, analyzing, \ > and manipulating the three-dimensional structure of biological \ > macromolecules, with special emphasis on the study of protein \ > or DNA structures determined by NMR. The program runs on UNIX \ > and Windows NT/95/98/2000 and is freely available. It does not work \ > properly with RNA. > homepage http://www.mol.biol.ethz.ch/wuthrich/software/molmol/ > platforms darwin > master_sites ftp://ftp.mol.biol.ethz.ch/software/MOLMOL/unix-gzip > distfiles molmol-2k.2.0-src.tar.gz \ > molmol-2k.2.0-doc.tar.gz > checksums md5 e1f4416d8041a67fa08cadb03ed91c7c \ > sha1 09482a1dea601563ca64e773dc0ec47019e22c63 \ > rmd160 b1de89953631dd9b11928751d7853cb511bf45f0 \ > md5 517545b60b0179ab691a679ed29903a7 \ > sha1 b47551283fa19f57f4d5edcbd52f725055d80b7f \ > rmd160 08b3e21ab6eb7c9044e59373334181ff91ca8a53 > depends_lib port:openmotif \ > port:glut \ > port:tiff \ > port:jpeg \ > port:libpng > patchfiles molmol-build.diff > destroot { > # Install example files not installed by the Makefile > file mkdir ${destroot}${prefix}/share/${name} > file copy ${worksrcpath} \ > ${destroot}${prefix}/share/${name} > file mkdir ${destroot}${prefix}/bin > ln -s ${prefix}/share/${name}/${name} ${destroot}${prefix}/bin/${name} > file mkdir ${destroot}${prefix}/share/doc/${name} > ln -s ${prefix}/share/${name}/COPYING ${destroot}${prefix}/share/doc/${name}/COPYING > ln -s ${prefix}/share/${name}/man ${destroot}${prefix}/share/doc/${name}/man > } > > which produces... > > ---> Computing dependencies for molmol > ---> Fetching molmol > ---> Attempting to fetch molmol-2k.2.0-src.tar.gz from http://distfiles.macports.org/molmol > ---> Attempting to fetch molmol-2k.2.0-src.tar.gz from http://arn.se.distfiles.macports.org/molmol > ---> Attempting to fetch molmol-2k.2.0-src.tar.gz from http://aarnet.au.distfiles.macports.org/pub/macports/mpdistfiles/molmol > ---> Attempting to fetch molmol-2k.2.0-src.tar.gz from ftp://ftp.mol.biol.ethz.ch/software/MOLMOL/unix-gzip > ---> Attempting to fetch molmol-2k.2.0-doc.tar.gz from http://distfiles.macports.org/molmol > ---> Attempting to fetch molmol-2k.2.0-doc.tar.gz from http://arn.se.distfiles.macports.org/molmol > ---> Attempting to fetch molmol-2k.2.0-doc.tar.gz from http://aarnet.au.distfiles.macports.org/pub/macports/mpdistfiles/molmol > ---> Attempting to fetch molmol-2k.2.0-doc.tar.gz from ftp://ftp.mol.biol.ethz.ch/software/MOLMOL/unix-gzip > ---> Verifying checksum(s) for molmol > Error: No checksum set for molmol-2k.2.0-src.tar.gz > Error: No checksum set for molmol-2k.2.0-doc.tar.gz > Error: Target org.macports.checksum returned: Unable to verify file checksums > Error: Status 1 encountered during processing. > > I am having trouble finding an existing Portfile which uses multiple > distfiles to discover the correct syntax in this case. Thanks in advance > for any advice. > Jack > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev I puzzled out that... checksums molmol-2k.2.0-src.tar.gz md5 e1f4416d8041a67fa08cadb03ed91c7c \ molmol-2k.2.0-src.tar.gz sha1 09482a1dea601563ca64e773dc0ec47019e22c63 \ molmol-2k.2.0-src.tar.gz rmd160 b1de89953631dd9b11928751d7853cb511bf45f0 \ molmol-2k.2.0-doc.tar.gz md5 517545b60b0179ab691a679ed29903a7 \ molmol-2k.2.0-doc.tar.gz sha1 b47551283fa19f57f4d5edcbd52f725055d80b7f \ molmol-2k.2.0-doc.tar.gz rmd160 08b3e21ab6eb7c9044e59373334181ff91ca8a53 works. I've run to another issue though. The molmol-2k.2.0-src.tar.gz and molmol-2k.2.0-doc.tar.gz tarballs extract out their files without creating an enclosing source directory so that... COPYING auxil makedef.aix.mesa makedef.lnx.mesa makedef.sun src HISTORY data makedef.aix.opengl makedef.sgi4 makedep tiff-v3.4 INSTALL help makedef.dec makedef.sgi5 makedep.devel tips Makefile include makedef.dec.mesa makedef.sgi6 man tools README lib makedef.gen makedef.sol molmol README.UNIX macros makedef.hp makedef.sol.mesa setup README.WIN makedef.aix makedef.lnx makedef.sol.opengl sg are directly splattered into /Users/howarth/ports/science/molmol/work. In fink, this didn't matter but MacPorts shares the work subdirectory with the source and destroot subdirectories. What is best practices here for this case. Do we have a Portfile option to modify how the distfiles are extracted? Jack From howarth at bromo.med.uc.edu Sat Sep 12 07:27:37 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 10:27:37 -0400 Subject: modifying patch files Message-ID: <20090912142737.GA9001@bromo.med.uc.edu> I have run into an issue that is unclear on MacPorts. In fink we often would put placekeepers in a patch such as @FINKPREFIX@ and use the command... sed 's|@FINKPREFIX@|%p|g' <%{PatchFile} | patch -p1 to replace the @FINKPREFIX@ with the actual fink installation directory. How do you handle this situation in MacPorts where you want to generalize the MacPorts prefix in a Makefile patch for instance to survive the case of a user installing MacPorts in a non-default location other than /opt/local? Jack From jeremy at lavergne.gotdns.org Sat Sep 12 07:31:10 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 12 Sep 2009 10:31:10 -0400 Subject: modifying patch files In-Reply-To: <20090912142737.GA9001@bromo.med.uc.edu> References: <20090912142737.GA9001@bromo.med.uc.edu> Message-ID: > I have run into an issue that is unclear on MacPorts. In fink > we often would put placekeepers in a patch such as @FINKPREFIX@ > and use the command... > > sed 's|@FINKPREFIX@|%p|g' <%{PatchFile} | patch -p1 > > to replace the @FINKPREFIX@ with the actual fink installation > directory. > How do you handle this situation in MacPorts where you want to > generalize the MacPorts prefix in a Makefile patch for instance > to survive the case of a user installing MacPorts in a non-default > location other than /opt/local? patchfiles patch-patched_file.diff ... reinplace s|@FINKPREFIX@|${prefix}|g patched_file From devans at macports.org Sat Sep 12 07:39:49 2009 From: devans at macports.org (David Evans) Date: Sat, 12 Sep 2009 07:39:49 -0700 Subject: modifying patch files In-Reply-To: References: <20090912142737.GA9001@bromo.med.uc.edu> Message-ID: <4AABB2B5.3030800@macports.org> Jeremy Lavergne wrote: >> I have run into an issue that is unclear on MacPorts. In fink >> we often would put placekeepers in a patch such as @FINKPREFIX@ >> and use the command... >> >> sed 's|@FINKPREFIX@|%p|g' <%{PatchFile} | patch -p1 >> >> to replace the @FINKPREFIX@ with the actual fink installation directory. >> How do you handle this situation in MacPorts where you want to >> generalize the MacPorts prefix in a Makefile patch for instance >> to survive the case of a user installing MacPorts in a non-default >> location other than /opt/local? > > > patchfiles patch-patched_file.diff > > ... > > reinplace s|@FINKPREFIX@|${prefix}|g patched_file > Actually you want to put the reinplace in a post-patch phase like this post-patch { reinplace "s|@FINKPREFIX@|${prefix}|g" ${worksrcpath}/patched_file } This way the file in question will be patched to include the place holder and then the place holder will be replaced with the appropriate substitution after all patches have been completed. From howarth at bromo.med.uc.edu Sat Sep 12 08:39:09 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 11:39:09 -0400 Subject: modifying patch files In-Reply-To: <4AABB254.9070600@orindasoftware.com> References: <20090912142737.GA9001@bromo.med.uc.edu> <4AABB254.9070600@orindasoftware.com> Message-ID: <20090912153909.GA9360@bromo.med.uc.edu> On Sat, Sep 12, 2009 at 07:38:12AM -0700, David Evans wrote: > Jeremy Lavergne wrote: > >> I have run into an issue that is unclear on MacPorts. In fink > >> we often would put placekeepers in a patch such as @FINKPREFIX@ > >> and use the command... > >> > >> sed 's|@FINKPREFIX@|%p|g' <%{PatchFile} | patch -p1 > >> > >> to replace the @FINKPREFIX@ with the actual fink installation directory. > >> How do you handle this situation in MacPorts where you want to > >> generalize the MacPorts prefix in a Makefile patch for instance > >> to survive the case of a user installing MacPorts in a non-default > >> location other than /opt/local? > > > > > > patchfiles patch-patched_file.diff > > > > ... > > > > reinplace s|@FINKPREFIX@|${prefix}|g patched_file > > > Actually you want to put the reinplace in a post-patch phase like this > > post-patch { > reinplace "s|@FINKPREFIX@|${prefix}|g" ${worksrcpath}/patched_file > } > > This way the file in question will be patched to include the place > holder and > then the place holder will be replaced with the appropriate substitution > after > all patches have been completed. > Thanks. So far my first port from fink hasn't turned out that well. The molmol build that works fine under openmotif4 (2.3.2) on fink doesn't properly display its windows under the openmotif and glw packages in MacPorts. I am afraid I am bumping into a bug in one of those packages. After I clean the port up a bit, I'll submit so that the openmotif and glw maintainers can take a look at this issue. Jack From howarth at bromo.med.uc.edu Sat Sep 12 09:17:12 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 12:17:12 -0400 Subject: molmol packaging Message-ID: <20090912161712.GA9625@bromo.med.uc.edu> Attached is my first attempt at a port from fink to MacPorts. The original fink info file is pretty simple... Package: molmol Version: 2k.2.0 Revision: 1042 CustomMirror: << eur-CH: ftp://ftp.mol.biol.ethz.ch/software/MOLMOL/ nam-US:http://freedom7.swmed.edu/pub/software/MOLMOL/ << Source: mirror:custom:unix-gzip/%n-%v-src.tar.gz Source-MD5: e1f4416d8041a67fa08cadb03ed91c7c SourceDirectory: ../%f Source2: mirror:custom:unix-gzip/%n-%v-doc.tar.gz Source2-MD5: 517545b60b0179ab691a679ed29903a7 Depends: x11, freeglut-shlibs, openmotif3-shlibs, libtiff-shlibs, libjpeg-shlibs, libpng3-shlibs, mesa-libglw-openmotif3-shlibs BuildDepends: freeglut, openmotif3, libtiff, libjpeg, libpng3, x11-dev, mesa-libglw-openmotif3, fink (>= 0.24.12) PatchFile: %n.patch PatchFile-MD5: 10bf2d62aa8a6402a05403d3ffa16cd1 PatchScript: << chmod -R +w * sed 's|@PREFIX@|%p|g' <%{PatchFile} | patch -p1 << CompileScript: << #!/bin/sh -ev make << InstallScript: << #!/bin/zsh -efv /bin/rm -f **/*.o **/*.c mkdir -p %i/share/molmol cp -R * %i/share/molmol/. mkdir -p %i/bin ln -s %p/share/molmol/molmol %i/bin/molmol mkdir -p %i/share/doc/molmol ln -s %p/share/molmol/COPYING %i/share/doc/molmol/COPYING ln -s %p/share/molmol/man %i/share/doc/molmol/man << Homepage: http://www.mol.biol.ethz.ch/wuthrich/software/molmol/ Description: Molecular graphics display program DescDetail: << MOLMOL is a molecular graphics program for displaying, analyzing, and manipulating the three-dimensional structure of biological macromolecules, with special emphasis on the study of protein or DNA structures determined by NMR. The program runs on UNIX and Windows NT/95/98/2000 and is freely available. It does not work properly with RNA. . Invoke with command "molmol" . molmol files and documentation located in /sw/share/molmol. << License: Restrictive Maintainer: W. G. Scott Out of that build, the only things I haven't ported yet are the "chmod -R +w *" in their patchscript and the "/bin/rm -f **/*.o **/*.c" cleanup in their installscript. The packaging attached builds and the resulting molmol binary can be executed however none of the windows are populated with the expected widgets. I am building entirely against the MacPorts x11 headers and libs. I'll cc Jeremy in case he has any ideas on debugging this. Jack ps As I mentioned before this same set of patches and sources works fine in fink with openmotif 2.3.2 and freeglut 2.4.0 (which we replaced glut with long ago). Manually executing "chmod -R +w *" in /opt/local/share/molmol after installation has no effect on the bug. Oh, if you look at... http://www.msg.ucsf.edu/local/programs/molmol/manual.html#ui_mainwin you will see what the window should look like if the program was working normally. -------------- next part -------------- A non-text attachment was scrubbed... Name: molmol_macport.tgz Type: application/x-gzip Size: 4456 bytes Desc: not available URL: From howarth at bromo.med.uc.edu Sat Sep 12 10:14:25 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 13:14:25 -0400 Subject: molmol packaging In-Reply-To: <20090912161712.GA9625@bromo.med.uc.edu> References: <20090912161712.GA9625@bromo.med.uc.edu> Message-ID: <20090912171425.GA10050@bromo.med.uc.edu> I've done some more testing and the glw package in MacPorts looks okay. Using the opensolar.c sample code from http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0640&db=bks&srch=&fname=/SGI_Developer/OpenGL_Porting/sgi_html/ape.html I was able to build a working sample program that runs normally on Snow Leopard. I'll try creating updated packaging for openmotif that uses 2.3.2 and also the patches I added for x86_64 cleanup to the openmotif packages I used to maintain in fink. These patches eliminate a bunch of "cast from pointer to integer of different size" warnings in openmotif. Jack From howarth at bromo.med.uc.edu Sat Sep 12 12:04:55 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 15:04:55 -0400 Subject: molmol packaging In-Reply-To: <20090912161712.GA9625@bromo.med.uc.edu> References: <20090912161712.GA9625@bromo.med.uc.edu> Message-ID: <20090912190455.GA10596@bromo.med.uc.edu> Jeremy, I've pretty much convinced myself that the breakage in molmol is in the X support in MacPorts and not the build. I resorted to a basic build of the molmol sources in /usr/local/molmol. In one case I modified the makedefs file to use the MacPorts includes and libraries (but nothing in /usr/X11R6). This molmol executable hangs. If I do a 'make clean' and use the minor changes to makedef to use fink's headers and libraries instead... --- makedef.macports 2009-09-12 14:55:19.000000000 -0400 +++ makedef.fink 2009-09-12 14:44:18.000000000 -0400 @@ -1,8 +1,8 @@ - TIFFDIR = /opt/local/lib + TIFFDIR = /sw/lib MESADIR = - JPEGDIR = /opt/local/lib + JPEGDIR = /sw/lib - PNGDIR = /opt/local/lib + PNGDIR = /sw/lib ZLIBDIR = /usr/lib # If you configured any of the above three image formats, uncomment @@ -25,7 +25,7 @@ CPP = /usr/bin/cpp -MCPPFLAGS = -DMAXINT=INT_MAX -I/opt/local/include -bind_at_load -I$(TOP) +MCPPFLAGS = -DMAXINT=INT_MAX -I/sw/include -I/usr/X11R6/include -bind_at_load -I$(TOP) CC = gcc @@ -52,8 +52,8 @@ MOTIFDEF = -DFUNCPROTO -SYSLIB = -L/usr/lib -L/opt/local/lib \ - -lX11 -lXm -lGLU -lGL /System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib /opt/local/lib/libGLw.dylib \ +SYSLIB = -L/usr/lib -L/usr/X11R6/lib -L/sw/lib \ + -lX11 -lXm -lGLU -lGL /System/Library/Frameworks/OpenGL.framework/Libraries/libGL.dylib /sw/lib/libGLw.dylib \ -lXmu -lXt -lXp -lXpm -lX11 -lXext -lSM -lICE -lm -lc -lmx TOOLSDIR = $(TOP)/tools then the resulting binary runs fine. Interestingly, molmol stores the previous sessions for quick redisplaying the molecule. Under Macports, the previously view molecule is rendered so that part of the program works. What seems to be broken is all of the control widgets and the access to them. If I look at the MacPort build of the molmol's process in Instruments, I see the following nested calls... poll _XtWaitForSomething XtAppProcessEvent processOneEvent PuMotifEventLoop PuEventLoop MolInit main start Thread 0x7d03: Main Thread While it is sampling for events, there are no displayed Motif GLw widgets to interact with. Can you try the molmol Macports package I sent to the list earlier and see if it reproduces on your machine? Jack From ryandesign at macports.org Sat Sep 12 13:42:09 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 15:42:09 -0500 Subject: checksums for multiple distfiles? In-Reply-To: <20090912134650.GA8777@bromo.med.uc.edu> References: <20090912131434.GA8601@bromo.med.uc.edu> <20090912134650.GA8777@bromo.med.uc.edu> Message-ID: <6C9BA955-0078-4B1E-B6DE-DB248F5389F7@macports.org> On Sep 12, 2009, at 08:46, Jack Howarth wrote: > On Sat, Sep 12, 2009 at 09:14:34AM -0400, Jack Howarth wrote: >> I am having problems with the correct syntax for >> adding checksums for multiple distfiles in a Portfile. >> [snip] >> I am having trouble finding an existing Portfile which uses multiple >> distfiles to discover the correct syntax in this case. Thanks in >> advance >> for any advice. You can check out the examples of curl-ca-bundle, freetype, minivmac, mysql5-devel (see the +innodb_plugin variant), among others. I located these examples by grepping the Portfiles for those that define the "distfiles" keyword -- not all of these specify multiple distfiles, but that is I think the primary reason why one would use that keyword. > I puzzled out that... > > checksums molmol-2k.2.0-src.tar.gz md5 > e1f4416d8041a67fa08cadb03ed91c7c \ > molmol-2k.2.0-src.tar.gz sha1 > 09482a1dea601563ca64e773dc0ec47019e22c63 \ > molmol-2k.2.0-src.tar.gz rmd160 > b1de89953631dd9b11928751d7853cb511bf45f0 \ > molmol-2k.2.0-doc.tar.gz md5 > 517545b60b0179ab691a679ed29903a7 \ > molmol-2k.2.0-doc.tar.gz sha1 > b47551283fa19f57f4d5edcbd52f725055d80b7f \ > molmol-2k.2.0-doc.tar.gz rmd160 > 08b3e21ab6eb7c9044e59373334181ff91ca8a53 > > works. It's simpler if you only specify the distfiles' names once each: checksums molmol-2k.2.0-src.tar.gz \ md5 e1f4416d8041a67fa08cadb03ed91c7c \ sha1 09482a1dea601563ca64e773dc0ec47019e22c63 \ rmd160 b1de89953631dd9b11928751d7853cb511bf45f0 \ molmol-2k.2.0-doc.tar.gz \ md5 517545b60b0179ab691a679ed29903a7 \ sha1 b47551283fa19f57f4d5edcbd52f725055d80b7f \ rmd160 08b3e21ab6eb7c9044e59373334181ff91ca8a53 > I've run to another issue though. The molmol-2k.2.0-src.tar.gz and > molmol-2k.2.0-doc.tar.gz > tarballs extract out their files without creating an enclosing > source directory so that... > > COPYING auxil makedef.aix.mesa makedef.lnx.mesa makedef.sun src > HISTORY data makedef.aix.opengl makedef.sgi4 makedep tiff-v3.4 > INSTALL help makedef.dec makedef.sgi5 makedep.devel tips > Makefile include makedef.dec.mesa makedef.sgi6 man tools > README lib makedef.gen makedef.sol molmol > README.UNIX macros makedef.hp makedef.sol.mesa setup > README.WIN makedef.aix makedef.lnx makedef.sol.opengl sg > > are directly splattered into /Users/howarth/ports/science/molmol/ > work. In fink, this didn't matter but MacPorts shares the work > subdirectory with the source and destroot subdirectories. What is > best practices here for this case. Do we have > a Portfile option to modify how the distfiles are extracted? Typically that would be extract.mkdir yes From ryandesign at macports.org Sat Sep 12 13:45:54 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 15:45:54 -0500 Subject: portfile and install scripts In-Reply-To: <20090912105227.GB7883@bromo.med.uc.edu> References: <20090912011922.GA4434@bromo.med.uc.edu> <20090912105227.GB7883@bromo.med.uc.edu> Message-ID: <3334AB17-28E0-4091-965A-D2008C12A6D9@macports.org> On Sep 12, 2009, at 05:52, Jack Howarth wrote: > On Sat, Sep 12, 2009 at 01:54:38AM -0500, Ryan Schmidt wrote: >> > >> Ok, looks like a shell script with some variable substitution. >> MacPorts >> portfiles have (more verbosely-named) variables for the same kinds of >> things, but portfiles are Tcl scripts, not shell scripts. > > One question on that. If push came to shove and you absolutely > needed > a shell script, wouldn't it be possible to just add patches to the > package > the could create an shell script that could be executed 'sh > build_script.sh' > from within the appropriate phase? Not that I would resort to that > but it > seemed like a possible last resort option if necessary. Yes, you can run shell commands or entire shell scripts from Tcl if you need to. But when there's no need to, we would like to see Portfiles do things in Tcl, because that is the language we've chosen for Portfiles, the language other Portfiles are written in, and the language other Portfile authors know. From howarth at bromo.med.uc.edu Sat Sep 12 13:58:33 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 16:58:33 -0400 Subject: portfile and install scripts In-Reply-To: <3334AB17-28E0-4091-965A-D2008C12A6D9@macports.org> References: <20090912011922.GA4434@bromo.med.uc.edu> <20090912105227.GB7883@bromo.med.uc.edu> <3334AB17-28E0-4091-965A-D2008C12A6D9@macports.org> Message-ID: <20090912205833.GA11388@bromo.med.uc.edu> On Sat, Sep 12, 2009 at 03:45:54PM -0500, Ryan Schmidt wrote: > > On Sep 12, 2009, at 05:52, Jack Howarth wrote: > >> On Sat, Sep 12, 2009 at 01:54:38AM -0500, Ryan Schmidt wrote: >>> >> >>> Ok, looks like a shell script with some variable substitution. >>> MacPorts >>> portfiles have (more verbosely-named) variables for the same kinds of >>> things, but portfiles are Tcl scripts, not shell scripts. >> >> One question on that. If push came to shove and you absolutely >> needed >> a shell script, wouldn't it be possible to just add patches to the >> package >> the could create an shell script that could be executed 'sh >> build_script.sh' >> from within the appropriate phase? Not that I would resort to that but >> it >> seemed like a possible last resort option if necessary. > > Yes, you can run shell commands or entire shell scripts from Tcl if you > need to. But when there's no need to, we would like to see Portfiles do > things in Tcl, because that is the language we've chosen for Portfiles, > the language other Portfiles are written in, and the language other > Portfile authors know. Never underestimate how crufty some of the science codes can be. I will likely have to resort to that if I port my current pymol-py packaging from fink (which builds and installs the pynmr pymol plugin). Jack ps I posted my initial molmol packaging for macports to the list but it looks like I am tickling a bug in the macports x11 packages. Perhaps I could be missing a necessary x11 dependency but I can't see what it would be since the package builds and links fine. I also added a ticket for openmotif to update it to 2.3.2 and add the uintptr_t patch I used in fink's openmotif4. From matt.cottrell at me.com Sat Sep 12 14:05:09 2009 From: matt.cottrell at me.com (Matthew Cottrell) Date: Sat, 12 Sep 2009 17:05:09 -0400 Subject: SHELL environment variable Message-ID: Is it possible to return the SHELL environment variable in a Portfile? $env(SHELL) does not appear to do it. -- From ryandesign at macports.org Sat Sep 12 14:10:54 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 16:10:54 -0500 Subject: [57521] trunk/dports/multimedia In-Reply-To: <20090912132524.B9C3926CD341@beta.macosforge.org> References: <20090912132524.B9C3926CD341@beta.macosforge.org> Message-ID: <2F70233A-1F7D-4FCE-B41C-EDC686EE3AE6@macports.org> On Sep 12, 2009, at 08:25, devans at macports.org wrote: > +if {$build_arch != ""} { Is there actually a circumstance when build_arch can be the empty string? I have been going on the assumption that it will always be set to one of the four architecture names. From ryandesign at macports.org Sat Sep 12 14:53:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 16:53:03 -0500 Subject: molmol packaging In-Reply-To: <20090912190455.GA10596@bromo.med.uc.edu> References: <20090912161712.GA9625@bromo.med.uc.edu> <20090912190455.GA10596@bromo.med.uc.edu> Message-ID: <7DA85A97-A4B5-4C1A-AA7F-BDCCFEEDCC7B@macports.org> On Sep 12, 2009, at 14:04, Jack Howarth wrote: > I've pretty much convinced myself that the breakage in molmol > is in the X support in MacPorts and not the build. What I get when I try your molmol port is: [snip] gcc -I/opt/local/lib -I/opt/local/lib -I/opt/local/lib -I/usr/lib - I../../tools/include -I../../sg/include -I../../include - DMAXINT=INT_MAX -I/opt/local/include -bind_at_load -I../.. -DFUNCPROTO -DTIFF_SUPPORT -DJPEG_SUPPORT -DPNG_SUPPORT -O -bind_at_load -Wall -I/ opt/local/lib -I/opt/local/lib -I/opt/local/lib -I/usr/lib -I../../ tools/include -I../../sg/include -I../../include -DMAXINT=INT_MAX -I/ opt/local/include -bind_at_load -I../.. -DFUNCPROTO -DTIFF_SUPPORT - DJPEG_SUPPORT -DPNG_SUPPORT -c -o MotOGL.o MotOGL.c MotOGL.c:34:26: error: GL/GLwMDrawA.h: No such file or directory MotOGL.c: In function 'exposeCB': MotOGL.c:46: error: 'GLwDrawingAreaCallbackStruct' undeclared (first use in this function) MotOGL.c:46: error: (Each undeclared identifier is reported only once MotOGL.c:46: error: for each function it appears in.) MotOGL.c:46: error: 'callP' undeclared (first use in this function) [snip] So GLwMDrawA.h was expected but not found. From ryandesign at macports.org Sat Sep 12 15:08:01 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 17:08:01 -0500 Subject: molmol packaging In-Reply-To: <7DA85A97-A4B5-4C1A-AA7F-BDCCFEEDCC7B@macports.org> References: <20090912161712.GA9625@bromo.med.uc.edu> <20090912190455.GA10596@bromo.med.uc.edu> <7DA85A97-A4B5-4C1A-AA7F-BDCCFEEDCC7B@macports.org> Message-ID: <89076597-243E-47BE-9762-50717730BB26@macports.org> On Sep 12, 2009, at 16:53, Ryan Schmidt wrote: > So GLwMDrawA.h was expected but not found. Ok, that's in the glw port, so add a dependency on port:glw. Now it builds, and when I open it, I see some rather empty windows and a Tip Of The Day window I don't know how to dismiss. Probably what you were seeing too. From ryandesign at macports.org Sat Sep 12 15:08:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 17:08:42 -0500 Subject: SHELL environment variable In-Reply-To: References: Message-ID: <2D0FC302-203B-401E-90DD-F79033272A74@macports.org> On Sep 12, 2009, at 16:05, Matthew Cottrell wrote: > Is it possible to return the SHELL environment variable in a Portfile? > > $env(SHELL) does not appear to do it. Not sure.. why do you want to know? :) From howarth at bromo.med.uc.edu Sat Sep 12 15:14:30 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 18:14:30 -0400 Subject: molmol packaging In-Reply-To: <7DA85A97-A4B5-4C1A-AA7F-BDCCFEEDCC7B@macports.org> References: <20090912161712.GA9625@bromo.med.uc.edu> <20090912190455.GA10596@bromo.med.uc.edu> <7DA85A97-A4B5-4C1A-AA7F-BDCCFEEDCC7B@macports.org> Message-ID: <20090912221430.GA11864@bromo.med.uc.edu> On Sat, Sep 12, 2009 at 04:53:03PM -0500, Ryan Schmidt wrote: > > On Sep 12, 2009, at 14:04, Jack Howarth wrote: > >> I've pretty much convinced myself that the breakage in molmol >> is in the X support in MacPorts and not the build. > > > What I get when I try your molmol port is: > > > [snip] > > > gcc -I/opt/local/lib -I/opt/local/lib -I/opt/local/lib -I/usr/lib - > I../../tools/include -I../../sg/include -I../../include -DMAXINT=INT_MAX > -I/opt/local/include -bind_at_load -I../.. -DFUNCPROTO -DTIFF_SUPPORT > -DJPEG_SUPPORT -DPNG_SUPPORT -O -bind_at_load -Wall -I/opt/local/lib > -I/opt/local/lib -I/opt/local/lib -I/usr/lib -I../../tools/include > -I../../sg/include -I../../include -DMAXINT=INT_MAX -I/opt/local/include > -bind_at_load -I../.. -DFUNCPROTO -DTIFF_SUPPORT -DJPEG_SUPPORT > -DPNG_SUPPORT -c -o MotOGL.o MotOGL.c > MotOGL.c:34:26: error: GL/GLwMDrawA.h: No such file or directory > MotOGL.c: In function 'exposeCB': > MotOGL.c:46: error: 'GLwDrawingAreaCallbackStruct' undeclared (first use > in this function) > MotOGL.c:46: error: (Each undeclared identifier is reported only once > MotOGL.c:46: error: for each function it appears in.) > MotOGL.c:46: error: 'callP' undeclared (first use in this function) > > > [snip] > > > So GLwMDrawA.h was expected but not found. > Doh, I accidentally deleted my line for the depends_lib on port:glw. Add that back and the build should complete. My mistake. You'll show still see the bug though. Jack ps On a more positive note, I just found the proposed pymol 1.1 packaging from last year that never made it into MacPorts, updated to the 1.2r1 release of pymol and cleaned up the missing sections of the installation. Now I have a fully functional pymol running under MacPorts on Snow Leopard. The general OpenGL support in MacPorts is running perfectly there with all the demos displaying properly (the previous Portfile didn't install the files for those to work). I'll work on adding the PyNMR module to that package (although I need to create a meschach support library package first for the matrix math). I must say I have found the first feature in MacPorts that definitely is an advantage over fink. The pymol author kinda regrets making the code open source so he stopped rolling tarballs. Being able to use... master_sites sourceforge fetch.type svn svn.url https://pymol.svn.sourceforge.net/svnroot/pymol/trunk/pymol svn.tag 3827 to pull the release svn revision was really nice. In fink, we always struggled to find hosts for such tarballs. From ryandesign at macports.org Sat Sep 12 15:20:25 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 17:20:25 -0500 Subject: SHELL environment variable In-Reply-To: <7BB2FFF9-7BE9-4996-9663-1E1C82580FA3@me.com> References: <2D0FC302-203B-401E-90DD-F79033272A74@macports.org> <7BB2FFF9-7BE9-4996-9663-1E1C82580FA3@me.com> Message-ID: On Sep 12, 2009, at 17:16, Matthew Cottrell wrote: > On Sep 12, 2009, at 6:08 PM, Ryan Schmidt wrote: > >> On Sep 12, 2009, at 16:05, Matthew Cottrell wrote: >> >>> Is it possible to return the SHELL environment variable in a >>> Portfile? >>> >>> $env(SHELL) does not appear to do it. >> >> Not sure.. why do you want to know? :) > > I'd like to add some post-activate code to a Portfile that would > amend PATH in a .cshrc or .profile, depending on which shell the > user is running. Instead of doing that, just print instructions advising the user what to do. It's not customary for ports to modify files in a user's home directory. From howarth at bromo.med.uc.edu Sat Sep 12 15:22:06 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 18:22:06 -0400 Subject: molmol packaging In-Reply-To: <89076597-243E-47BE-9762-50717730BB26@macports.org> References: <20090912161712.GA9625@bromo.med.uc.edu> <20090912190455.GA10596@bromo.med.uc.edu> <7DA85A97-A4B5-4C1A-AA7F-BDCCFEEDCC7B@macports.org> <89076597-243E-47BE-9762-50717730BB26@macports.org> Message-ID: <20090912222206.GB11864@bromo.med.uc.edu> On Sat, Sep 12, 2009 at 05:08:01PM -0500, Ryan Schmidt wrote: > > On Sep 12, 2009, at 16:53, Ryan Schmidt wrote: > >> So GLwMDrawA.h was expected but not found. > > Ok, that's in the glw port, so add a dependency on port:glw. Now it > builds, and when I open it, I see some rather empty windows and a Tip Of > The Day window I don't know how to dismiss. Probably what you were > seeing too. > Yes, look at... http://www.msg.ucsf.edu/local/programs/molmol/manual.html#ui_mainwin This shows how the controls and menus on the window should render. I am certain this is a bug somewhere else in MacPorts because as I mention in another email, a completely manual build against the /sw.x86_64 directory from fink builds a usable molmol but not a build against /opt/local (without /usr/X11R6). I compiled the old opensolar.c demo code and have proven to myself that glw is working. It's kinda hard to believe it is a openmotif bug since that build is pretty generic compared to my old openmotif4 fink build. I am suspecting the something is missing or broken in the other parts of the modular X11 packages. Jack From howarth at bromo.med.uc.edu Sat Sep 12 15:33:12 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 18:33:12 -0400 Subject: more verbosity Message-ID: <20090912223312.GA12687@bromo.med.uc.edu> Is there a general conf setting I can change so that port output is always verbose during the build (or just a specific phase)? It is nice that port spews out the compilation when a compile time error is hit but while working up packaging I would like to see the actual build in detail. Jack From ryandesign at macports.org Sat Sep 12 15:37:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 17:37:28 -0500 Subject: SHELL environment variable In-Reply-To: <08104612-7734-45D3-9249-14CE5967FD30@me.com> References: <2D0FC302-203B-401E-90DD-F79033272A74@macports.org> <7BB2FFF9-7BE9-4996-9663-1E1C82580FA3@me.com> <08104612-7734-45D3-9249-14CE5967FD30@me.com> Message-ID: <3574A57E-0AEE-425F-AC09-BABA58388841@macports.org> On Sep 12, 2009, at 17:26, Matthew Cottrell wrote: >>> I'd like to add some post-activate code to a Portfile that would >>> amend PATH in a .cshrc or .profile, depending on which shell the >>> user is running. >> >> Instead of doing that, just print instructions advising the user >> what to do. > > The Portfile currently prompts the user as you suggest, but I still > get email from novices who stumble. I figure I'd be doing them and > myself a favor. > >> It's not customary for ports to modify files in a user's home >> directory. > > I actually got the idea from the modification to PATH that appeared > in my .cshrc when I installed MacPorts ;-) Yeah... MacPorts does break its own rule a bit there. Part of the problem is the user might change his shell later, or one user might be installing software on a Mac for use by multiple users. I concede the former is perhaps not very likely. For the latter, the user needs to be aware that software will not "just work" for those other users -- that something needs to be added to e.g. the .profile for it to work. > ui_msg " > 1) > ************************************************************************** > bash-users add the following lines to your ~/.profile or to your > ~/.bashrc > ************************************************************************** > ARBHOME=${prefix}/share/arb;export ARBHOME > PATH=${prefix}/share/arb/bin:\$PATH > export PATH > > enter the following command: > . ~/.profile > 2) > ************************************************** > tcsh users add the following lines to your ~/.cshrc > ************************************************** > setenv ARBHOME ${prefix}/share/arb > setenv PATH ${prefix}/share/arb\:\$PATH > > enter the following command: > source ~/.cshrc > " > } First thought: are these really necessary? Is there some way the software could be installed so that the user need not manually set these? For example, for the wine port, it wouldn't run right unless DYLD_LIBRARY_PATH was set; to avoid requiring the user to set this manually, I wrote a wrapper script so the user never knows. Read the wine port for more info. Second thought: if manual setup is the only way, put the setup into a script the user can source from their .profile and install it along with the port. This condenses your instructions down to a single line change to the .profile to source your file; hopefully users will be able to grasp that. P.S: Don't forget to Reply All so your reply goes to the list too, not just to me. From ryandesign at macports.org Sat Sep 12 15:38:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 17:38:03 -0500 Subject: more verbosity In-Reply-To: <20090912223312.GA12687@bromo.med.uc.edu> References: <20090912223312.GA12687@bromo.med.uc.edu> Message-ID: <6C77B1D9-797B-4C0D-B171-455CB432ACBF@macports.org> On Sep 12, 2009, at 17:33, Jack Howarth wrote: > Is there a general conf setting I can change > so that port output is always verbose during the > build (or just a specific phase)? It is nice that > port spews out the compilation when a compile time > error is hit but while working up packaging I would > like to see the actual build in detail. There's no conf setting; you must use the "-d" switch every time. sudo port -d install something From ryandesign at macports.org Sat Sep 12 15:41:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 17:41:02 -0500 Subject: more verbosity In-Reply-To: <6C77B1D9-797B-4C0D-B171-455CB432ACBF@macports.org> References: <20090912223312.GA12687@bromo.med.uc.edu> <6C77B1D9-797B-4C0D-B171-455CB432ACBF@macports.org> Message-ID: <81BC0AD2-A5FD-4A4A-8192-BEF726B27CDE@macports.org> On Sep 12, 2009, at 17:38, Ryan Schmidt wrote: > On Sep 12, 2009, at 17:33, Jack Howarth wrote: > >> Is there a general conf setting I can change >> so that port output is always verbose during the >> build (or just a specific phase)? It is nice that >> port spews out the compilation when a compile time >> error is hit but while working up packaging I would >> like to see the actual build in detail. > > There's no conf setting; you must use the "-d" switch every time. > > sudo port -d install something Due to the volume of information printed by the -d switch, its use can cause you to overlook important messages ports sometimes print out. For developing your own portfiles using -d is great and helpful, but for general use, I recommend you install and upgrade ports without the -d flag, and if you encounter an error, then clean the affected port and try again with -d to see the full error. From howarth at bromo.med.uc.edu Sat Sep 12 15:55:14 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 18:55:14 -0400 Subject: package validation Message-ID: <20090912225514.GA13368@bromo.med.uc.edu> Is there anyway to prescan a Profile for validity? In fink, there is 'fink validate foobar.info" which will report obvious syntax and policy errors without building. Do we have anything like that in fink for either the Portfile or packages produced? Also, I noticed the proposed pymol packaging creates dylib's for the python modules. I am certain this is a flaw in the configure script of pymol. In my pymol-py package in fink, I always built with the ancient Makefile.delsci files since they created the desired .so python modules. Do we have any policies for shared libraries and modules which would require me to generate those modules as .so files? I could fix configure and send those change back upstream if it is an issue. Jack ps After I clean up the pymol packaging a bit more, I add it back to the current ticket and update it for 1.2r1. From jeremy at lavergne.gotdns.org Sat Sep 12 16:12:49 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 12 Sep 2009 19:12:49 -0400 Subject: more verbosity In-Reply-To: <81BC0AD2-A5FD-4A4A-8192-BEF726B27CDE@macports.org> References: <20090912223312.GA12687@bromo.med.uc.edu> <6C77B1D9-797B-4C0D-B171-455CB432ACBF@macports.org> <81BC0AD2-A5FD-4A4A-8192-BEF726B27CDE@macports.org> Message-ID: <42162FEE-67E7-45AD-9E4B-1485563463A5@lavergne.gotdns.org> >>> Is there a general conf setting I can change >>> so that port output is always verbose during the >>> build (or just a specific phase)? It is nice that >>> port spews out the compilation when a compile time >>> error is hit but while working up packaging I would >>> like to see the actual build in detail. >> >> There's no conf setting; you must use the "-d" switch every time. >> >> sudo port -d install something > > Due to the volume of information printed by the -d switch, its use > can cause you to overlook important messages ports sometimes print > out. For developing your own portfiles using -d is great and > helpful, but for general use, I recommend you install and upgrade > ports without the -d flag, and if you encounter an error, then clean > the affected port and try again with -d to see the full error. You might consider making an alias in your .profile (or .bashrc ... or whatever). alias port='port -d' From jeremy at lavergne.gotdns.org Sat Sep 12 16:13:35 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 12 Sep 2009 19:13:35 -0400 Subject: package validation In-Reply-To: <20090912225514.GA13368@bromo.med.uc.edu> References: <20090912225514.GA13368@bromo.med.uc.edu> Message-ID: <23D9BCDA-1D5A-4BD3-A439-856AF434BA64@lavergne.gotdns.org> port lint [--nitpick] On Sep 12, 2009, at 6:55 PM, Jack Howarth wrote: > Is there anyway to prescan a Profile for validity? From ryandesign at macports.org Sat Sep 12 16:13:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 18:13:41 -0500 Subject: package validation In-Reply-To: <20090912225514.GA13368@bromo.med.uc.edu> References: <20090912225514.GA13368@bromo.med.uc.edu> Message-ID: On Sep 12, 2009, at 17:55, Jack Howarth wrote: > Is there anyway to prescan a Profile for validity? > In fink, there is 'fink validate foobar.info" which > will report obvious syntax and policy errors without > building. Do we have anything like that in fink for > either the Portfile or packages produced? port lint It's useful but not perfect. If you see the need for a new warning, or an existing warning that's off, let us know. From matt.cottrell at me.com Sat Sep 12 16:26:09 2009 From: matt.cottrell at me.com (Matthew Cottrell) Date: Sat, 12 Sep 2009 19:26:09 -0400 Subject: SHELL environment variable In-Reply-To: <3574A57E-0AEE-425F-AC09-BABA58388841@macports.org> References: <2D0FC302-203B-401E-90DD-F79033272A74@macports.org> <7BB2FFF9-7BE9-4996-9663-1E1C82580FA3@me.com> <08104612-7734-45D3-9249-14CE5967FD30@me.com> <3574A57E-0AEE-425F-AC09-BABA58388841@macports.org> Message-ID: Thanks for the wrapper suggestion. I'll check it out. On Sep 12, 2009, at 6:37 PM, Ryan Schmidt wrote: > > On Sep 12, 2009, at 17:26, Matthew Cottrell wrote: > >>>> I'd like to add some post-activate code to a Portfile that would >>>> amend PATH in a .cshrc or .profile, depending on which shell the >>>> user is running. >>> >>> Instead of doing that, just print instructions advising the user >>> what to do. >> >> The Portfile currently prompts the user as you suggest, but I still >> get email from novices who stumble. I figure I'd be doing them and >> myself a favor. >> >>> It's not customary for ports to modify files in a user's home >>> directory. >> >> I actually got the idea from the modification to PATH that appeared >> in my .cshrc when I installed MacPorts ;-) > > Yeah... MacPorts does break its own rule a bit there. > > Part of the problem is the user might change his shell later, or one > user might be installing software on a Mac for use by multiple > users. I concede the former is perhaps not very likely. For the > latter, the user needs to be aware that software will not "just > work" for those other users -- that something needs to be added to > e.g. the .profile for it to work. > > >> ui_msg " >> 1) >> ************************************************************************** >> bash-users add the following lines to your ~/.profile or to your >> ~/.bashrc >> ************************************************************************** >> ARBHOME=${prefix}/share/arb;export ARBHOME >> PATH=${prefix}/share/arb/bin:\$PATH >> export PATH >> >> enter the following command: >> . ~/.profile >> 2) >> ************************************************** >> tcsh users add the following lines to your ~/.cshrc >> ************************************************** >> setenv ARBHOME ${prefix}/share/arb >> setenv PATH ${prefix}/share/arb\:\$PATH >> >> enter the following command: >> source ~/.cshrc >> " >> } > > First thought: are these really necessary? Is there some way the > software could be installed so that the user need not manually set > these? For example, for the wine port, it wouldn't run right unless > DYLD_LIBRARY_PATH was set; to avoid requiring the user to set this > manually, I wrote a wrapper script so the user never knows. Read the > wine port for more info. > > Second thought: if manual setup is the only way, put the setup into > a script the user can source from their .profile and install it > along with the port. This condenses your instructions down to a > single line change to the .profile to source your file; hopefully > users will be able to grasp that. > > > P.S: Don't forget to Reply All so your reply goes to the list too, > not just to me. > > > -- Matthew Cottrell Lewes, DE 19958 http://www.mattcottrell.org From jeremy at lavergne.gotdns.org Sat Sep 12 16:51:13 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 12 Sep 2009 19:51:13 -0400 Subject: startupitems and port load Message-ID: <25B7A451-109D-4550-A0CD-BAB92FE80625@lavergne.gotdns.org> Does `sudo port load ...` do a force load (`launchctl load -F ...`) or does it write it out as runnable (`launchctl load -w ...`)? If it writes it out, is this the preferred way to run ports with startupitems? When creating your own launchd files, how does one correctly install it? I've heard that using daemondo allows us to account for ports that don't expect launchd to handle them. I think that we should go a little beyond this and determine if we should use it or not. I propose that we avoid using daemondo only if the portfile explicitly uses launchd, maintaining backwards compatibility. Any thoughts on this? From jmr at macports.org Sat Sep 12 17:34:38 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 13 Sep 2009 10:34:38 +1000 Subject: [57521] trunk/dports/multimedia In-Reply-To: <2F70233A-1F7D-4FCE-B41C-EDC686EE3AE6@macports.org> References: <20090912132524.B9C3926CD341@beta.macosforge.org> <2F70233A-1F7D-4FCE-B41C-EDC686EE3AE6@macports.org> Message-ID: <4AAC3E1E.1090403@macports.org> On 2009-9-13 07:10, Ryan Schmidt wrote: > > On Sep 12, 2009, at 08:25, devans at macports.org wrote: > >> +if {$build_arch != ""} { > > Is there actually a circumstance when build_arch can be the empty > string? Non-darwin platforms. - Josh From devans at macports.org Sat Sep 12 17:46:38 2009 From: devans at macports.org (David Evans) Date: Sat, 12 Sep 2009 17:46:38 -0700 Subject: [57521] trunk/dports/multimedia In-Reply-To: <4AAC3E1E.1090403@macports.org> References: <20090912132524.B9C3926CD341@beta.macosforge.org> <2F70233A-1F7D-4FCE-B41C-EDC686EE3AE6@macports.org> <4AAC3E1E.1090403@macports.org> Message-ID: <4AAC40EE.9000601@macports.org> Joshua Root wrote: > On 2009-9-13 07:10, Ryan Schmidt wrote: > >> On Sep 12, 2009, at 08:25, devans at macports.org wrote: >> >> >>> +if {$build_arch != ""} { >>> >> Is there actually a circumstance when build_arch can be the empty >> string? >> > > Non-darwin platforms. > > - Josh > > I was going to say that this was put there by Josh and I assumed he had a reason for it. So now we know. As an aside, the man pages that are installed with 1.8.0 don't seem to reflect the changes that are available in that release. The guide isn't up to date either. Is there a source for documentation on using the new features in 1.8.0 (other than the ChangeLog)? Dave From ryandesign at macports.org Sat Sep 12 17:50:22 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 12 Sep 2009 19:50:22 -0500 Subject: [57521] trunk/dports/multimedia In-Reply-To: <4AAC40EE.9000601@macports.org> References: <20090912132524.B9C3926CD341@beta.macosforge.org> <2F70233A-1F7D-4FCE-B41C-EDC686EE3AE6@macports.org> <4AAC3E1E.1090403@macports.org> <4AAC40EE.9000601@macports.org> Message-ID: On Sep 12, 2009, at 19:46, David Evans wrote: > Joshua Root wrote: >> On 2009-9-13 07:10, Ryan Schmidt wrote: >> >>> On Sep 12, 2009, at 08:25, devans at macports.org wrote: >>> >>> >>>> +if {$build_arch != ""} { >>>> >>> Is there actually a circumstance when build_arch can be the empty >>> string? >>> >> >> Non-darwin platforms. Oh dear. > As an aside, the man pages that are installed with 1.8.0 don't seem to > reflect the changes > that are available in that release. The guide isn't up to date > either. > Is there a source > for documentation on using the new features in 1.8.0 (other than the > ChangeLog)? I think I saw some commits come through about the manpages since 1.8.0, but not for the guide. From howarth at bromo.med.uc.edu Sat Sep 12 18:06:26 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 21:06:26 -0400 Subject: patching config.guess or passing triplets Message-ID: <20090913010626.GA16344@bromo.med.uc.edu> I was until a couple days ago the maintainer of the gcc4x packages in fink. Looking at your broken gcc44 package I noticed some major lapses in logic that is fouling the build and the multilib. The current packaging doesn't pass explicit --host,--target and --build triplets to configure yet attempts to force the compiler to generate 64-bit code with -m64 on the flags. This is never going to work even with config.guess is patched because the operative decider of what the native code architecture is should be the code generated by CC alone. Currently config.guess is broken and misreports the architecture as i386-apple-darwin10 even when the code execution and default code generation in gcc-4.2 is x86_64. I have proposed a fixed config.guess to upstream... https://savannah.gnu.org/patch/?6827 which fixes this. This change has been added to the gcc44 ticket as a patch... http://trac.macports.org/ticket/20838 I am attempting to build this locally but am having some issues with this Portfile not finding the build directory when used from my local ports directory. Perhaps some else can test this. You will to add the patch... http://trac.macports.org/attachment/ticket/20838/gcc44-config.guess.diff and disable any attempt at forcing -m32 or -m64 onto the compiler... # the generated compiler doesn't accept -arch # if {[info exists build_arch] && ${os.platform} == "darwin"} { # if {(${os.arch} == "i386" && $build_arch == "i386") || (${os.arch} == "powerpc" && $build_arch == "ppc")} { # configure.env-append CFLAGS_FOR_TARGET="${configure.cflags}" # } elseif {(${os.arch} == "i386" && $build_arch == "x86_64") || (${os.arch} == "powerpc" && $build_arch == "ppc64")} { # configure.env-append CFLAGS_FOR_TARGET="${configure.cflags}" # } else { # pre-fetch { # return -code error "Cannot build $name for $build_arch" # } # } # configure.env-append CFLAGS_FOR_BUILD="${configure.cc_archflags} ${configure.cflags}" # configure.cc_archflags # configure.cxx_archflags # configure.objc_archflags #} Alternatively you could do what I did in fink gcc44 with... darwinvers=`uname -r|cut -f1 -d.` if [ "%m" = "powerpc" ]; then ../gcc-%v/configure %c --build=%m-apple-darwin${darwinvers} --host=%m-apple-darwin${darwinvers} --target=%m-apple-darwin${darwinvers} elif [ "%m" = "i386" ]; then ../gcc-%v/configure %c --with-arch=nocona --with-tune=generic --build=i686-apple-darwin${darwinvers} --host=i686-apple-darwin${darwinvers} --target=i686-apple-darwin${darwinvers} elif [ "%m" = "x86_64" ]; then ../gcc-%v/configure %c --build=x86_64-apple-darwin${darwinvers} --host=x86_64-apple-darwin${darwinvers} --target=x86_64-apple-darwin${darwinvers} fi and explicitly pass the triplets. However this shouldn't be necessary with the patched config.guess. Note that this config.guess always tracks the code generation of CC so that... [Macintosh-2:~/gcc-4.5-20090905] howarth% setenv CC gcc-4.2 [Macintosh-2:~/gcc-4.5-20090905] howarth% ./config.guess.proposed x86_64-apple-darwin10.0.0 [Macintosh-2:~/gcc-4.5-20090905] howarth% setenv CC gcc-4.0 [Macintosh-2:~/gcc-4.5-20090905] howarth% ./config.guess.proposed i386-apple-darwin10.0.0 [Macintosh-2:~/gcc-4.5-20090905] howarth% setenv CC "gcc-4.0 -m64" [Macintosh-2:~/gcc-4.5-20090905] howarth% ./config.guess.proposed x86_64-apple-darwin10.0.0 [Macintosh-2:~/gcc-4.5-20090905] howarth% setenv CC "gcc-4.2 -m32" [Macintosh-2:~/gcc-4.5-20090905] howarth% ./config.guess.proposed i386-apple-darwin10.0.0 Also it is essential to avoid decoupling the detected triplets in configure from the code generation of the compiler. You risk attempting to compile hard coded assembly language with the wrong architecture or simply have that code disabled unexpectedly. That applies to all packages. Jack From howarth at bromo.med.uc.edu Sat Sep 12 18:16:57 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 21:16:57 -0400 Subject: patching config.guess or passing triplets In-Reply-To: <20090913010626.GA16344@bromo.med.uc.edu> References: <20090913010626.GA16344@bromo.med.uc.edu> Message-ID: <20090913011657.GA16446@bromo.med.uc.edu> If anyone is wondering about the form of the patch to config.guess... --- config.guess.orig 2009-09-12 20:13:05.000000000 -0400 +++ config.guess 2009-09-12 20:14:07.000000000 -0400 @@ -1259,6 +1259,24 @@ *:Darwin:*:*) UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown case $UNAME_PROCESSOR in + i386) + eval $set_cc_for_build + if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then + sed 's/^ //' << EOF >$dummy.c + #if defined(__LP64__) + main() + { + } + #endif +EOF + if test `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep -c main` = 1 ; then + UNAME_PROCESSOR=x86_64 + fi + else + if sysctl -a | grep -c hw.cpu64bit_capable>/dev/null 2>&1 ; then + UNAME_PROCESSOR=x86_64 + fi + fi ;; unknown) UNAME_PROCESSOR=powerpc ;; esac echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE} The first test is if 'uname -p' reports i386 (which will always be the case on Intel Darwin). In the absence of Xcode being installed, the default code execution is determined via sysctl. The config.guess maintainer wants to decouple config.guess from depending on gcc being present which is why that is there. If a compiler is found, the compiler set in CC_FOR_BUILD is used to determine if the __LP64__ definition is present. The gcc developers wanted to used a much more concise form of the test with -dM but this is a gcc-centric option that wouldn't work on other compilers. Jack From kthenriksson at gmail.com Sat Sep 12 18:27:56 2009 From: kthenriksson at gmail.com (Kristofer Henriksson) Date: Sat, 12 Sep 2009 21:27:56 -0400 Subject: more verbosity In-Reply-To: <42162FEE-67E7-45AD-9E4B-1485563463A5@lavergne.gotdns.org> References: <20090912223312.GA12687@bromo.med.uc.edu> <6C77B1D9-797B-4C0D-B171-455CB432ACBF@macports.org> <81BC0AD2-A5FD-4A4A-8192-BEF726B27CDE@macports.org> <42162FEE-67E7-45AD-9E4B-1485563463A5@lavergne.gotdns.org> Message-ID: <4809057c0909121827t3db37e7eg1b783f5c53633943@mail.gmail.com> To my knowledge, aliases do not work with sudo, they only match text at the beginning of the command. On Sat, Sep 12, 2009 at 7:12 PM, Jeremy Lavergne wrote: >>>> Is there a general conf setting I can change >>>> so that port output is always verbose during the >>>> build (or just a specific phase)? It is nice that >>>> port spews out the compilation when a compile time >>>> error is hit but while working up packaging I would >>>> like to see the actual build in detail. >>> >>> There's no conf setting; you must use the "-d" switch every time. >>> >>> sudo port -d install something >> >> Due to the volume of information printed by the -d switch, its use can >> cause you to overlook important messages ports sometimes print out. For >> developing your own portfiles using -d is great and helpful, but for general >> use, I recommend you install and upgrade ports without the -d flag, and if >> you encounter an error, then clean the affected port and try again with -d >> to see the full error. > > You might consider making an alias in your .profile (or .bashrc ... or > whatever). > > alias port='port -d' > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From howarth at bromo.med.uc.edu Sat Sep 12 18:34:21 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 21:34:21 -0400 Subject: gcc44 and local ports directory Message-ID: <20090913013421.GA16532@bromo.med.uc.edu> Can someone explain what I am doing wrong here? I find that when I attempt to build... # $Id: Portfile 57375 2009-09-10 08:16:41Z ryandesign at macports.org $ PortSystem 1.0 name gcc44 epoch 2 version 4.4.1 platforms darwin categories lang maintainers mww license GPLv3 description The GNU compiler collection long_description The GNU compiler collection, including front ends for \ C, C++, Objective-C, Objective-C++, Java and Fortran95. homepage http://gcc.gnu.org/ master_sites ftp://ftp.funet.fi/pub/mirrors/sources.redhat.com/pub/gcc/releases/gcc-${version}/ \ ftp://ftp.gwdg.de/pub/linux/gcc/releases/gcc-${version}/ \ ftp://gcc.ftp.nluug.nl/mirror/languages/gcc/releases/gcc-${version}/ \ ftp://gcc.gnu.org/pub/gcc/releases/gcc-${version}/ \ gnu:/gcc/gcc-${version} set dcore gcc-core-${version}.tar.bz2 set dfort gcc-fortran-${version}.tar.bz2 set dcxx gcc-g++-${version}.tar.bz2 set djava gcc-java-${version}.tar.bz2 set dobjc gcc-objc-${version}.tar.bz2 distfiles ${dcore} ${dfort} ${dcxx} ${djava} ${dobjc} checksums ${dcore} sha1 7e18b5f49b77a78e0ccd31c82c6220c5756da754 \ ${dfort} sha1 65f729704eecffbcb115a3258c17919665066214 \ ${dcxx} sha1 921c8c18287cabc4c515b4a52c70e445160bd161 \ ${djava} sha1 65492e8e66569ba1cceec7fbc8a3e83dafa549f1 \ ${dobjc} sha1 f99d03177548c94184a8788c1d6eefecbd4b99bc use_bzip2 yes # gmp and mpfr are not universal universal_variant no depends_lib port:gmp port:mpfr port:libiconv set major 4.4 patchfiles gcc44-config.guess.diff worksrcdir build # the generated compiler doesn't accept -arch # if {[info exists build_arch] && ${os.platform} == "darwin"} { # if {(${os.arch} == "i386" && $build_arch == "i386") || (${os.arch} == "powerpc" && $build_arch == "ppc")} { # configure.env-append CFLAGS_FOR_TARGET="${configure.cflags}" # } elseif {(${os.arch} == "i386" && $build_arch == "x86_64") || (${os.arch} == "powerpc" && $build_arch == "ppc64")} { # configure.env-append CFLAGS_FOR_TARGET="${configure.cflags}" # } else { # pre-fetch { # return -code error "Cannot build $name for $build_arch" # } # } # configure.env-append CFLAGS_FOR_BUILD="${configure.cc_archflags} ${configure.cflags}" # configure.cc_archflags # configure.cxx_archflags # configure.objc_archflags #} pre-configure { file mkdir ${worksrcpath} } configure.cmd ../gcc-${version}/configure configure.args --enable-languages=c,c++,objc,obj-c++,java,fortran \ --libdir=${prefix}/lib/${name} \ --includedir=${prefix}/include/${name} \ --infodir=${prefix}/share/info \ --mandir=${prefix}/share/man \ --with-local-prefix=${prefix} \ --with-system-zlib \ --disable-nls \ --program-suffix=-mp-${major} \ --with-gxx-include-dir=${prefix}/include/${name}/c++/ \ --with-gmp=${prefix} \ --with-mpfr=${prefix} # do NOT use MacPorts binutils -- they do not work configure.env-append AR_FOR_TARGET=/usr/bin/ar \ AS_FOR_TARGET=/usr/bin/as \ LD_FOR_TARGET=/usr/bin/ld \ NM_FOR_TARGET=/usr/bin/nm \ OBJDUMP_FOR_TARGET=/usr/bin/objdump \ RANLIB_FOR_TARGET=/usr/bin/ranlib \ STRIP_FOR_TARGET=/usr/bin/strip build.target bootstrap use_parallel_build yes destroot.target install install-info-host post-destroot { file delete -force ${destroot}${prefix}/share/man/man7 \ ${destroot}${prefix}/share/info # install/copy ffitarget.h only if we have it if {![catch {set ffitarget.h [glob ${destroot}${prefix}/lib/${name}/gcc/*/${version}/include/ffitarget.h]} result]} { file copy ${ffitarget.h} ${destroot}${prefix}/include/${name}/ } # install select file for gcc_select xinstall -m 755 -d ${destroot}${prefix}/etc/select/gcc xinstall -m 444 ${filespath}/mp-gcc44 ${destroot}${prefix}/etc/select/gcc/ } #platform darwin 7 { # configure.cflags-append -force_cpusubtype_ALL # confgiure.env BOOT_CFLAGS="-g -O2 -force_cpusubtype_ALL" # build.args-append XCFLAGS=-force_cpusubtype_ALL #} platform powerpc { configure.args-append --disable-multilib } # odcctools currently do not compile for x64 - move to variant for the time being variant odcctools \ description "Use the odcctools instead of the system provided ones - does not work for x64 currently!" { depends_lib-append port:odcctools patch { reinplace "s|/usr/bin/libtool|${prefix}/bin/odlibtool|g" \ ${workpath}/gcc-${version}/gcc/config/darwin.h } configure.args-append --with-as=${prefix}/bin/odas \ --with-ld=${prefix}/bin/odld \ --with-ar=${prefix}/bin/odar } livecheck.type regex livecheck.url http://gcc.gnu.org/gcc-4.4/ livecheck.regex GCC (4\\.4\\.\[0-9\]) out of my current ports directory, I keep getting.... DEBUG: setting option extract.args to /opt/local/var/macports/distfiles/gcc44/gcc-java-4.4.1.tar.bz2 DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.6' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work" && /usr/bin/bzip2 -dc /opt/local/var/macports/distfiles/gcc44/gcc-java-4.4.1.tar.bz2 | /usr/bin/gnutar --no-same-owner -xf -' ---> Extracting gcc-objc-4.4.1.tar.bz2 DEBUG: setting option extract.args to /opt/local/var/macports/distfiles/gcc44/gcc-objc-4.4.1.tar.bz2 DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.6' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work" && /usr/bin/bzip2 -dc /opt/local/var/macports/distfiles/gcc44/gcc-objc-4.4.1.tar.bz2 | /usr/bin/gnutar --no-same-owner -xf -' DEBUG: Executing org.macports.patch (gcc44) ---> Applying patches to gcc44 Error: Target org.macports.patch returned: couldn't change working directory to "/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build": no such file or directory DEBUG: Backtrace: couldn't change working directory to "/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build": no such file or directory while executing "_cd [option worksrcpath]" (procedure "portpatch::patch_main" line 24) invoked from within "$procedure $targetname" Warning: the following items did not execute (for gcc44): org.macports.activate org.macports.patch org.macports.configure org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. where.... [Macintosh-2:~/ports] howarth% ls /opt/local/var/macports/build/ _Users_howarth_ports_lang_gcc44 _opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_lesstif [Macintosh-2:var/macports/build] howarth% cd _Users_howarth_ports_lang_gcc44 [Macintosh-2:macports/build/_Users_howarth_ports_lang_gcc44] howarth% ls work [Macintosh-2:macports/build/_Users_howarth_ports_lang_gcc44] howarth% cd work [Macintosh-2:build/_Users_howarth_ports_lang_gcc44/work] howarth% ls gcc-4.4.1 From jeremy at lavergne.gotdns.org Sat Sep 12 18:36:44 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 12 Sep 2009 21:36:44 -0400 Subject: gcc44 and local ports directory In-Reply-To: <20090913013421.GA16532@bromo.med.uc.edu> References: <20090913013421.GA16532@bromo.med.uc.edu> Message-ID: <739B9BF2-56C1-4062-8F73-AE52AEA6FEE0@lavergne.gotdns.org> Does running tar jft indicate that this produces the directory "build" ? It would seem the wrong directory is being extracted since you can't cd to it. On Sep 12, 2009, at 9:34 PM, Jack Howarth wrote: > /opt/local/var/macports/distfiles/gcc44/gcc-objc-4.4.1.tar.bz2 From howarth at bromo.med.uc.edu Sat Sep 12 18:48:12 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 21:48:12 -0400 Subject: gcc44 and local ports directory In-Reply-To: <739B9BF2-56C1-4062-8F73-AE52AEA6FEE0@lavergne.gotdns.org> References: <20090913013421.GA16532@bromo.med.uc.edu> <739B9BF2-56C1-4062-8F73-AE52AEA6FEE0@lavergne.gotdns.org> Message-ID: <20090913014812.GA16640@bromo.med.uc.edu> On Sat, Sep 12, 2009 at 09:36:44PM -0400, Jeremy Lavergne wrote: > Does running tar jft indicate that this produces the directory "build" ? > > It would seem the wrong directory is being extracted since you can't cd > to it. > > On Sep 12, 2009, at 9:34 PM, Jack Howarth wrote: > >> /opt/local/var/macports/distfiles/gcc44/gcc-objc-4.4.1.tar.bz2 What I get is... [Macintosh-2:lang/gcc44/files] howarth% ls -l /opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work total 0 drwxrwxrwx 63 root admin 2142 Sep 12 21:44 gcc-4.4.1 with no "/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build". I think the error... DEBUG: Executing org.macports.patch (gcc44) ---> Applying patches to gcc44 Error: Target org.macports.patch returned: couldn't change working directory to "/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build": no such file or directory DEBUG: Backtrace: couldn't change working directory to "/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build": no such file or directory while executing "_cd [option worksrcpath]" (procedure "portpatch::patch_main" line 24) invoked from within "$procedure $targetname" Warning: the following items did not execute (for gcc44): org.macports.build org.macports.patch org.macports.configure Error: Status 1 encountered during processing. means it isn't changing into /opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/gcc-4.4.1 to apply the patch. The current Portfile doesn't have any patchfiles listed in it so I can't crib. I've tried... patchfiles gcc44-config.guess.diff worksrcdir build patch.dir ${worksrcpath} but that doesn't work either. The patch file is configured as -p0. Jack From howarth at bromo.med.uc.edu Sat Sep 12 18:55:28 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 21:55:28 -0400 Subject: gcc44 and local ports directory In-Reply-To: <739B9BF2-56C1-4062-8F73-AE52AEA6FEE0@lavergne.gotdns.org> References: <20090913013421.GA16532@bromo.med.uc.edu> <739B9BF2-56C1-4062-8F73-AE52AEA6FEE0@lavergne.gotdns.org> Message-ID: <20090913015528.GA16686@bromo.med.uc.edu> On Sat, Sep 12, 2009 at 09:36:44PM -0400, Jeremy Lavergne wrote: > Does running tar jft indicate that this produces the directory "build" ? > > It would seem the wrong directory is being extracted since you can't cd > to it. > > On Sep 12, 2009, at 9:34 PM, Jack Howarth wrote: > >> /opt/local/var/macports/distfiles/gcc44/gcc-objc-4.4.1.tar.bz2 Found an old gcc41 with the patch still in it. Needed to be... patchfiles gcc44-config.guess.diff worksrcdir build pre-patch { file mkdir ${worksrcpath} } patch.dir ${workpath}/gcc-${version} Now the patched config.guess gives... DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build" && ../gcc-4.4.1/configure --prefix=/opt/local --enable-languages=c,c++,objc,obj-c++,java,fortran --libdir=/opt/local/lib/gcc44 --includedir=/opt/local/include/gcc44 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.4 --with-gxx-include-dir=/opt/local/include/gcc44/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local' checking build system type... x86_64-apple-darwin10.0.0 checking host system type... x86_64-apple-darwin10.0.0 checking target system type... x86_64-apple-darwin10.0.0 as is correct on a Core 2 Duo running 10.6. From howarth at bromo.med.uc.edu Sat Sep 12 19:06:18 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 22:06:18 -0400 Subject: gcc44 Message-ID: <20090913020618.GA16759@bromo.med.uc.edu> Okay, you do have something else strange going on in the gcc44 package that I never saw in fink... Checking multilib configuration for libgcc... Configuring stage 1 in x86_64-apple-darwin10.0.0/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking build system type... x86_64-apple-darwin10.0.0 checking host system type... x86_64-apple-darwin10.0.0 checking for x86_64-apple-darwin10.0.0-ar... /usr/bin/ar checking for x86_64-apple-darwin10.0.0-lipo... lipo checking for x86_64-apple-darwin10.0.0-nm... /opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build/./gcc/nm checking for x86_64-apple-darwin10.0.0-ranlib... /usr/bin/ranlib -c checking for x86_64-apple-darwin10.0.0-strip... /usr/bin/strip checking whether ln -s works... yes checking for x86_64-apple-darwin10.0.0-gcc... /opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build/./gcc/ -B/opt/local/x86_64-apple-darwin10.0.0/bin/ -B/opt/local/x86_64-apple-darwin10.0.0/lib/ -isystem /opt/local/x86_64-apple-darwin10.0.0/include -isystem /opt/local/x86_64-apple-darwin10.0.0/sys-include checking for suffix of object files... configure: error: in `/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build/x86_64-apple-darwin10.0.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. I'll have to think about this for awhile. From config.log in /opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build/x86_64-apple-darwin10.0.0/libgcc something is passing CFLAGS='-g -O2 -arch x86_64'. You really don't want to be doing that. Anyone know where is being set and how we can disable it? Jack From howarth at bromo.med.uc.edu Sat Sep 12 19:12:19 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 22:12:19 -0400 Subject: gcc44 In-Reply-To: <20090913020618.GA16759@bromo.med.uc.edu> References: <20090913020618.GA16759@bromo.med.uc.edu> Message-ID: <20090913021218.GA16792@bromo.med.uc.edu> On Sat, Sep 12, 2009 at 10:06:18PM -0400, Jack Howarth wrote: > Okay, you do have something else strange going on in the gcc44 > package that I never saw in fink... > > Checking multilib configuration for libgcc... > Configuring stage 1 in x86_64-apple-darwin10.0.0/libgcc > configure: creating cache ./config.cache > checking for --enable-version-specific-runtime-libs... no > checking for a BSD-compatible install... /usr/bin/install -c > checking for gawk... no > checking for mawk... no > checking for nawk... no > checking for awk... awk > checking build system type... x86_64-apple-darwin10.0.0 > checking host system type... x86_64-apple-darwin10.0.0 > checking for x86_64-apple-darwin10.0.0-ar... /usr/bin/ar > checking for x86_64-apple-darwin10.0.0-lipo... lipo > checking for x86_64-apple-darwin10.0.0-nm... /opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build/./gcc/nm > checking for x86_64-apple-darwin10.0.0-ranlib... /usr/bin/ranlib -c > checking for x86_64-apple-darwin10.0.0-strip... /usr/bin/strip > checking whether ln -s works... yes > checking for x86_64-apple-darwin10.0.0-gcc... /opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build/./gcc/ -B/opt/local/x86_64-apple-darwin10.0.0/bin/ -B/opt/local/x86_64-apple-darwin10.0.0/lib/ -isystem /opt/local/x86_64-apple-darwin10.0.0/include -isystem /opt/local/x86_64-apple-darwin10.0.0/sys-include > checking for suffix of object files... configure: error: in `/opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build/x86_64-apple-darwin10.0.0/libgcc': > configure: error: cannot compute suffix of object files: cannot compile > See `config.log' for more details. > > I'll have to think about this for awhile. From config.log in > /opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/build/x86_64-apple-darwin10.0.0/libgcc > something is passing CFLAGS='-g -O2 -arch x86_64'. You really don't want to be doing that. Anyone know > where is being set and how we can disable it? > Jack > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev Thinking on this more, I suspect this is misguided attempt at emulating the compiler wrappers in fink. Again the compilers wrappers in fink pass -m32 or -m64 as shell script symlink for the actual compiler. This means that -m32 or -m64 are passed effectively on CC and *NOT* on any compiler flags like CFLAGS, FFLAGS, or CXXFLAGS. Doing that will never allow the multilib to build in gcc because you are short-circuiting it when it attempts to build -m32. My guess anyway. Jack ps None of these build issues every existed on fink even before the compiler wrappers when you pass the appropriate triplets. From jeremy at lavergne.gotdns.org Sat Sep 12 19:13:28 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 12 Sep 2009 22:13:28 -0400 Subject: gcc44 In-Reply-To: <20090913020618.GA16759@bromo.med.uc.edu> References: <20090913020618.GA16759@bromo.med.uc.edu> Message-ID: <1D5EF0FC-8C89-432C-B73E-8A26AAB3C99C@lavergne.gotdns.org> > I'll have to think about this for awhile. From config.log in > /opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/ > build/x86_64-apple-darwin10.0.0/libgcc > something is passing CFLAGS='-g -O2 -arch x86_64'. You really don't > want to be doing that. Anyone know > where is being set and how we can disable it? configure.cflags is set to configure.optflags by default, and configure.optflags is set to -O2 by default. The -arch might be from configure.universal_ldflags ... no clue where - g comes from. From howarth at bromo.med.uc.edu Sat Sep 12 19:30:46 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 22:30:46 -0400 Subject: gcc44 In-Reply-To: <1D5EF0FC-8C89-432C-B73E-8A26AAB3C99C@lavergne.gotdns.org> References: <20090913020618.GA16759@bromo.med.uc.edu> <1D5EF0FC-8C89-432C-B73E-8A26AAB3C99C@lavergne.gotdns.org> Message-ID: <20090913023046.GA16857@bromo.med.uc.edu> On Sat, Sep 12, 2009 at 10:13:28PM -0400, Jeremy Lavergne wrote: >> I'll have to think about this for awhile. From config.log in >> /opt/local/var/macports/build/_Users_howarth_ports_lang_gcc44/work/ >> build/x86_64-apple-darwin10.0.0/libgcc >> something is passing CFLAGS='-g -O2 -arch x86_64'. You really don't >> want to be doing that. Anyone know >> where is being set and how we can disable it? > > > configure.cflags is set to configure.optflags by default, and > configure.optflags is set to -O2 by default. > > The -arch might be from configure.universal_ldflags ... no clue where -g > comes from. I just checked in a Portfile-config_guess-fix.diff on ticket 20838 which with the gcc44-config.guess.diff eliminates the multilib breakage. My build is still going (out here on my laptop so only two cores). Hopefully the rest of the packaging file is still valid and that is all I had to fix. Jack ps They might want to add back in a test for the i386-apple-darwin* target and passs --with-arch=nocona --with-tune=generic to configure on that target. Mike Stump at Apple always recommended those setting for best performance on Core2 Duo and related Xeons. I did that on fink's gcc4x packages. For x86_64-apple-darwin*, it doesn't appear to make a difference. From jmr at macports.org Sat Sep 12 19:48:42 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 13 Sep 2009 12:48:42 +1000 Subject: gcc44 In-Reply-To: <20090913020618.GA16759@bromo.med.uc.edu> References: <20090913020618.GA16759@bromo.med.uc.edu> Message-ID: <4AAC5D8A.2000502@macports.org> On 2009-9-13 12:06, Jack Howarth wrote: > something is passing CFLAGS='-g -O2 -arch x86_64'. You commented out the clearing of configure.*_archflags... - Josh From howarth at bromo.med.uc.edu Sat Sep 12 20:05:39 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 23:05:39 -0400 Subject: gcc44 In-Reply-To: <4AAC5D8A.2000502@macports.org> References: <20090913020618.GA16759@bromo.med.uc.edu> <4AAC5D8A.2000502@macports.org> Message-ID: <20090913030539.GA17055@bromo.med.uc.edu> On Sun, Sep 13, 2009 at 12:48:42PM +1000, Joshua Root wrote: > On 2009-9-13 12:06, Jack Howarth wrote: > > something is passing CFLAGS='-g -O2 -arch x86_64'. > > You commented out the clearing of configure.*_archflags... > > - Josh Josh, The last posted Portfile change on the ticket fixed the multilib build. You must have never gotten far enough to see PR41180 which I fixed on gcc trunk and gcc 4.4 branch last week. I am testing new packaging that adds that patch and the --disable-libjava-multilib patch which significantly shortens the build. Jack From howarth at bromo.med.uc.edu Sat Sep 12 20:45:47 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 23:45:47 -0400 Subject: gcc44 In-Reply-To: <4AAC5D8A.2000502@macports.org> References: <20090913020618.GA16759@bromo.med.uc.edu> <4AAC5D8A.2000502@macports.org> Message-ID: <20090913034547.GA17194@bromo.med.uc.edu> What options do we have in the Portfile syntax to to extract out the darwin release? On fink we used... darwinvers=`uname -r|cut -f1 -d.` in a bash shell script. I ask because the 32-bit compiler build is unoptimized unless we manage to get... if {[info exists build_arch] && ${os.platform} == "darwin"} { if {(${os.arch} == "i386" && $build_arch == "i386") { configure.post_args --with-arch=nocona --with-tune=generic --host=i686-apple-darwin10 --build=i686-apple-darwin10 --target=i686-apple-darwin10 } } but I need some syntax that will allow me to determine the numerical darwin release there...ie darwin8, darwin9, darwin10, etc. From howarth at bromo.med.uc.edu Sat Sep 12 20:51:12 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 12 Sep 2009 23:51:12 -0400 Subject: gcc44 In-Reply-To: <20090913034547.GA17194@bromo.med.uc.edu> References: <20090913020618.GA16759@bromo.med.uc.edu> <4AAC5D8A.2000502@macports.org> <20090913034547.GA17194@bromo.med.uc.edu> Message-ID: <20090913035112.GA17248@bromo.med.uc.edu> On Sat, Sep 12, 2009 at 11:45:47PM -0400, Jack Howarth wrote: > What options do we have in the Portfile syntax to > to extract out the darwin release? On fink we used... > > darwinvers=`uname -r|cut -f1 -d.` > > in a bash shell script. I ask because the 32-bit > compiler build is unoptimized unless we manage to get... > > if {[info exists build_arch] && ${os.platform} == "darwin"} { > if {(${os.arch} == "i386" && $build_arch == "i386") { > configure.post_args --with-arch=nocona --with-tune=generic --host=i686-apple-darwin10 --build=i686-apple-darwin10 --target=i686-apple-darwin10 > } > } > > > but I need some syntax that will allow me to determine the numerical > darwin release there...ie darwin8, darwin9, darwin10, etc. > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev Doh. Nevermind, guess we can use... if {[info exists build_arch] && ${os.platform} == "darwin"} { if {(${os.arch} == "i386" && $build_arch == "i386") { configure.post_args --with-arch=nocona --with-tune=generic --host=i686-apple-darwin${os.major} --build=i686-apple-darwin{os.major} --target=i686-apple-darwin${os.major} } } From jeremy at lavergne.gotdns.org Sat Sep 12 20:52:40 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 12 Sep 2009 23:52:40 -0400 Subject: gcc44 In-Reply-To: <20090913035112.GA17248@bromo.med.uc.edu> References: <20090913020618.GA16759@bromo.med.uc.edu> <4AAC5D8A.2000502@macports.org> <20090913034547.GA17194@bromo.med.uc.edu> <20090913035112.GA17248@bromo.med.uc.edu> Message-ID: On Sep 12, 2009, at 11:51 PM, Jack Howarth wrote: >> but I need some syntax that will allow me to determine the numerical >> darwin release there...ie darwin8, darwin9, darwin10, etc. You can use "platform darwin X" blocks. From howarth at bromo.med.uc.edu Sat Sep 12 21:52:48 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 13 Sep 2009 00:52:48 -0400 Subject: gcc44 In-Reply-To: References: <20090913020618.GA16759@bromo.med.uc.edu> <4AAC5D8A.2000502@macports.org> <20090913034547.GA17194@bromo.med.uc.edu> <20090913035112.GA17248@bromo.med.uc.edu> Message-ID: <20090913045248.GA17560@bromo.med.uc.edu> On Sat, Sep 12, 2009 at 11:52:40PM -0400, Jeremy Lavergne wrote: > > On Sep 12, 2009, at 11:51 PM, Jack Howarth wrote: > >>> but I need some syntax that will allow me to determine the numerical >>> darwin release there...ie darwin8, darwin9, darwin10, etc. > > You can use "platform darwin X" blocks. Okay, the packaging I added on the ticket... http://trac.macports.org/ticket/20838 builds and installs gcc44 on x86_64-apple-darwin10 using the files... Portfile_final.diff gcc44-config.guess.diff gcc44-PR41180.diff gcc44-disable-libjava.diff where the last three are new patches for the files folder. I am currently testing the file Portfile_optimized.diff which adds a test for i386-apple-darwin* and in that case provides the proper optimization for building the compiler by using... configure.args-append --with-arch=nocona --with-tune=generic --build=i686-apple-darwin${os.major} --host=i686-apple-darwin${os.major} --target=i686-apple-darwin${os.major} in that case. Enjoy. Jack From afb at macports.org Sun Sep 13 00:40:42 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 13 Sep 2009 09:40:42 +0200 Subject: modifying patch files In-Reply-To: <20090912142737.GA9001@bromo.med.uc.edu> References: <20090912142737.GA9001@bromo.med.uc.edu> Message-ID: <2151E19F-B77C-4643-87AB-E7ACADCC129E@macports.org> Jack Howarth wrote: > I have run into an issue that is unclear on MacPorts. In fink > we often would put placekeepers in a patch such as @FINKPREFIX@ > and use the command... > > sed 's|@FINKPREFIX@|%p|g' <%{PatchFile} | patch -p1 > > to replace the @FINKPREFIX@ with the actual fink installation > directory. > How do you handle this situation in MacPorts where you want to > generalize the MacPorts prefix in a Makefile patch for instance > to survive the case of a user installing MacPorts in a non-default > location other than /opt/local? If you don't want to remember all the zillion files that your port may need patching, then you _can_ do override to do something similar in MacPorts as well: patch { foreach patch $patchfiles { system "cd '${workpath}/${distname}' && \ sed -e 's#@@PREFIX@@#${prefix}#g' '${portpath}/$ {filesdir}/${patch}' | patch -p0" } } But that's usually only needed for some really stupid and unportable ports, like for instance "yum" and such. (since it loves to hardcode /usr and #!/usr/bin/python) Someone suggested it should be a "patch" feature, but nobody bothered implementing it (as far as I know)... Like: "patch.replace @@PREFIX@@=${prefix}", or somesuch --anders From ryandesign at macports.org Sun Sep 13 01:10:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 13 Sep 2009 03:10:02 -0500 Subject: [57560] trunk/dports/www In-Reply-To: <20090913073720.97BE326D8E38@beta.macosforge.org> References: <20090913073720.97BE326D8E38@beta.macosforge.org> Message-ID: <0B5F9724-5659-42CB-B476-AF1A6CD188CE@macports.org> On Sep 13, 2009, at 02:37, and.damore at macports.org wrote: > Revision: 57560 > http://trac.macports.org/changeset/57560 > Author: and.damore at macports.org > Date: 2009-09-13 00:37:14 -0700 (Sun, 13 Sep 2009) > Log Message: > ----------- > drupal5 and drupal6 update, added conflicts between postgresql and > mysql variants Did the maintainer of those ports OK these updates? From ryandesign at macports.org Sun Sep 13 01:24:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 13 Sep 2009 03:24:24 -0500 Subject: patching config.guess or passing triplets In-Reply-To: <20090913010626.GA16344@bromo.med.uc.edu> References: <20090913010626.GA16344@bromo.med.uc.edu> Message-ID: <3FCA046F-89E4-48CE-A1C9-6B9B3D51592C@macports.org> Jack, Thank you for your willingness to help us fix things. I think you have a much greater knowledge of compilers than I do, because a lot of your comments are going right over my head. Is there a specific change you're recommending we make in MacPorts base, such as always passing -- host, --build and/or --target to ./configure? Or a specific thing maintainers of all ports should be watching out for? From howarth at bromo.med.uc.edu Sun Sep 13 04:30:24 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 13 Sep 2009 07:30:24 -0400 Subject: patching config.guess or passing triplets In-Reply-To: <3FCA046F-89E4-48CE-A1C9-6B9B3D51592C@macports.org> References: <20090913010626.GA16344@bromo.med.uc.edu> <3FCA046F-89E4-48CE-A1C9-6B9B3D51592C@macports.org> Message-ID: <20090913113024.GA8725@bromo.med.uc.edu> On Sun, Sep 13, 2009 at 03:24:24AM -0500, Ryan Schmidt wrote: > Jack, > > Thank you for your willingness to help us fix things. I think you have a > much greater knowledge of compilers than I do, because a lot of your > comments are going right over my head. Is there a specific change you're > recommending we make in MacPorts base, such as always passing --host, > --build and/or --target to ./configure? Or a specific thing maintainers > of all ports should be watching out for? Ryan, I am going to write an email to this later today explaining my understanding of the approach and compiler wrapper infrastructure being used for i386 fink on 10.6 and x86_64 fink on 10.5 as well as the requirements this imposes on the packaging used. Fink actually came to regret having tried to implement i386 fink on 10.6 but was so far along there was no point to junking it. If you really want to support the option of having MacPorts build i386 packages on 10.6 (when the compiler default is really x86_64 code), the only rational approach is to resort to compiler wrappers that effectively sneak -m32 into the compiler commands. I would strongly suggest it isn't really worth the effort and it would be much smarter to just leverage the proposed config.guess change to eliminate the problem in Snow Leopard where the triplet is incorrectly reported and configure misjudges the default code generation. In fink, I don't think considered this option in part because we started out with the idea of i386 fink on 10.6 where that wouldn't have helped at all. If you patch config.guess to properly report x86_64-apple-darwin10, on EMT64-capable processors there is no need to manually pass the triplet on --host/--build/--target to configure. Config.guess will give configure that answer correctly on its own. You will want to go through the MacPorts packages and, when you patch config.guess, revert any attempts to manually pass -m64 on the compiler flags as those will be unnecessary and may actually confuse the build process (as was the case with the multilib in gcc44...although that is a pretty unique issue). Jack ps I spent several hundred hours testing i386 and x86_64 fink on 10.6 as well as x86_64 fink on 10.5 during the past year and making x86_64 package variants for x86_64 fink on 10.5/10.6. From howarth at bromo.med.uc.edu Sun Sep 13 05:48:25 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 13 Sep 2009 08:48:25 -0400 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts Message-ID: <20090913124825.GA9119@bromo.med.uc.edu> I should explain to everyone here the situation with i386 fink on 10.6 and x86_64 fink on 10.5 so it is clearer what is possible in packaging binaries of a different architecture than the default and the costs involved. Chronologically, i386 fink on 10.6 came first during the Snow Leopard seeding process. At that time, it was unclear how viable it would be to build all of the fink package set as x86_64 code. The approach used in fink for both i386 fink on 10.6 and x86_64 fink on 10.5 involves the use of compiler wrappers. For i386 fink on 10.6, these reside in... /sw.i386/var/lib/fink/path-prefix-10.6 as... lrwxr-xr-x 1 root admin 16 Aug 10 19:47 c++ -> compiler_wrapper lrwxr-xr-x 1 root admin 16 Aug 10 19:47 c++-4.0 -> compiler_wrapper lrwxr-xr-x 1 root admin 16 Aug 10 19:47 c++-4.2 -> compiler_wrapper lrwxr-xr-x 1 root admin 16 Aug 10 19:47 cc -> compiler_wrapper -rwxr-xr-x 1 root admin 49 Aug 10 19:47 compiler_wrapper lrwxr-xr-x 1 root admin 16 Aug 10 19:47 g++ -> compiler_wrapper lrwxr-xr-x 1 root admin 16 Aug 10 19:47 g++-4.0 -> compiler_wrapper lrwxr-xr-x 1 root admin 16 Aug 10 19:47 g++-4.2 -> compiler_wrapper lrwxr-xr-x 1 root admin 16 Aug 10 19:47 gcc -> compiler_wrapper lrwxr-xr-x 1 root admin 16 Aug 10 19:47 gcc-4.0 -> compiler_wrapper lrwxr-xr-x 1 root admin 16 Aug 10 19:47 gcc-4.2 -> compiler_wrapper lrwxr-xr-x 1 root admin 16 Aug 10 19:47 gcc=4.0 -> compiler_wrapper where the compiler_wrapper file, which is repeatedly symlinked, contains... #!/bin/sh exec /usr/bin/${0##*/} -arch i386 "$@" On x86_64 fink for 10.5, this is oddly in the same directory... /sw.x86_64/var/lib/fink/path-prefix-10.6 but the content of the compiler_wrapper is now changed to... #!/bin/sh exec /usr/bin/${0##*/} -arch x86_64 "$@" Note that these compiler wrappers are not invoked automatically. The default fink init scripts DO NOT change the code generation behavior of the system compilers when invoked outside of the fink packaging program. These wrappers are only activated within the fink builds. So what limitations does this place on you as a packager? The primary one is that your package builds must NEVER invoke the compiler with a complete path. This was actually the hardest issue to initially get across to all of the other fink developers who weren't working with i386 fink on 10.6 or x86_64 fink on 10.5 themselves. If you have CC=/usr/bin/gcc in a Makefile it must become CC=gcc. Now on i386 fink on 10.6, because the current config.guess is broken and incorrectly reports the triplet as i386-apple-darwin10, there was no need to ever pass the triplets manually to configure for those builds. In the case of x86_64 fink on 10.5 however, there is because if configure guesses the wrong triplet, you may not compile the proper sections code or set incorrect values for the type of code being generated. This was the origin of the breakage in the MacPorts gcc44 package that I fixed last night. In fink, this process is generalized by passing... --build=%m-apple-darwin`uname -r|cut -f1 -d.` --host=%m-apple-darwin`uname -r|cut -f1 -d.` to configure where %m is set in fink to the architecture determined via the sysctl -n output. Unless the source package is broken, this should work for all permutations (ie i386-apple-darwin*, powerpc-apple-darwin* and x86_64-apple-darwin*) without breakage in the build). A few months into the i386 fink on 10.6 development, we added the option to build x86_64 fink on 10.6 which was then shortly extended via the compiler_wrappers to x86_64 fink on 10.5 (in order to have more developers involved in porting packages to build on x86_64). As the 10.6 release approached, it became clearer that the x86_64 fink support was quite viable with all the major components building save a few odds and ends like SDL. In recent weeks, the biggest problem the fink developers have has is with i386 fink on 10.6. This is because it can be an exhausting process to make sure that none of the packages manually sneak in a pathed call to the compilers which will suddenly throw x86_64 code into a linkage. Some of the fink developers even came to view the i386 fink on 10.6 support as more trouble than it was worth however they were so far along there was no option but to fix all the packages. So what does this all mean for MacPorts? I am a little unclear on what your ambitions are for Snow Leopard, but if you really intend to support an option where the package are all built as i386 code, you will have to resort to a compiler wrapper approach like fink for it to be viable. Also be warned it will consume huge resources here because of the need to patch all of the software to never directly call the compiler with a complete path. In the last few weeks, I have been working with the config.guess maintainer and the FSF gcc developers to construct an acceptable patch to config.guess that will ensure that the reported triplet always appropriately reflects the compilers default code generation as invoked through CC for example. The current version of this patch, which used to fix the MacPorts gcc44 build, is... --- config.guess.orig 2009-09-12 20:13:05.000000000 -0400 +++ config.guess 2009-09-12 20:14:07.000000000 -0400 @@ -1259,6 +1259,24 @@ *:Darwin:*:*) UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown case $UNAME_PROCESSOR in + i386) + eval $set_cc_for_build + if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then + sed 's/^ //' << EOF >$dummy.c + #if defined(__LP64__) + main() + { + } + #endif +EOF + if test `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep -c main` = 1 ; then + UNAME_PROCESSOR=x86_64 + fi + else + if sysctl -a | grep -c hw.cpu64bit_capable>/dev/null 2>&1 ; then + UNAME_PROCESSOR=x86_64 + fi + fi ;; unknown) UNAME_PROCESSOR=powerpc ;; esac echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE} For i386, this patch checks first if a compiler is available. If none is found, the default code execution is determined through sysctl. If there is a c compiler installed, the default code generation is determined via a small test program with a __LP64__ wrapper around main(). This could have been done with a much shorter test using -dM but that is a gcc-centric option not available on all c compilers. This patched config.guess will now always properly track the code generation of what can be viewed as the system compiler set via CC. So consider the cases... [Macintosh-2:~/gcc-4.5-20090905] howarth% setenv CC gcc-4.2 [Macintosh-2:~/gcc-4.5-20090905] howarth% ./config.guess.proposed x86_64-apple-darwin10.0.0 [Macintosh-2:~/gcc-4.5-20090905] howarth% setenv CC gcc-4.0 [Macintosh-2:~/gcc-4.5-20090905] howarth% ./config.guess.proposed i386-apple-darwin10.0.0 [Macintosh-2:~/gcc-4.5-20090905] howarth% setenv CC "gcc-4.2 -m32" [Macintosh-2:~/gcc-4.5-20090905] howarth% ./config.guess.proposed i386-apple-darwin10.0.0 [Macintosh-2:~/gcc-4.5-20090905] howarth% setenv CC "gcc-4.0 -m64" [Macintosh-2:~/gcc-4.5-20090905] howarth% ./config.guess.proposed x86_64-apple-darwin10.0.0 In each case, the correct triplet is now detected that matches the default code generation of the compiler as invoked through CC. We did not have this config.guess fix available to use during the x86_64 fink on 10.5 development (and it is orthogonal to the problems of building i386 fink on 10.6). If MacPorts is willing to junk the idea of building i386 packages as a default on 10.6, the config.guess fix is really the way to go. When patched this way, all programs that use config.guess to determine the triplets for configure will pick the correct value of x86_64-apple-darwin10 and there will be no need to force -m64 onto any compiler flags or to bother to pass --build/--host/--target to configure. From my own experiences on fink, I would strongly urge MacPorts to abandon any attempt to build an i386 MacPorts on 10.6 (except where non-EMT64 Core Duo and Core Solo's will do that without any intervention) and to focus on the x86_64 Macport builds for 10.6 fully utilizing the proposed config.guess patch to avoid the bother of passing the --build/--target/--host triplets to configure in Portfiles. My two cents anyway as a newcomer to MacPorts. Jack From afb at macports.org Sun Sep 13 09:20:23 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 13 Sep 2009 18:20:23 +0200 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <20090913124825.GA9119@bromo.med.uc.edu> References: <20090913124825.GA9119@bromo.med.uc.edu> Message-ID: <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> Jack Howarth wrote: > If MacPorts is willing to junk the idea of building i386 packages > as a default on 10.6, the config.guess fix is really the way to go. > When patched this way, all programs that use config.guess to determine > the triplets for configure will pick the correct value of > x86_64-apple-darwin10 and there will be no need to force -m64 onto any > compiler flags or to bother to pass --build/--host/--target to > configure. From my own experiences on fink, I would strongly urge > MacPorts to abandon any attempt to build an i386 MacPorts on 10.6 > (except where non-EMT64 Core Duo and Core Solo's will do that without > any intervention) and to focus on the x86_64 Macport builds for 10.6 > fully utilizing the proposed config.guess patch to avoid the bother > of passing the --build/--target/--host triplets to configure in > Portfiles. My two cents anyway as a newcomer to MacPorts. You probably want to fix the "${os.arch}" as well, since that will affect e.g. how packages are named: set archive.file "${name}-${version}_${revision}${portvariants}. [option os.arch].${archive.type}" set unarchive.file "${name}-${version}_${revision}${portvariants}. [option os.arch].${unarchive.type}" "x86_64", as per http://trac.macports.org/changeset/54798 is a workaround for http://trac.macports.org/ticket/20506 set os_arch $tcl_platform(machine) if {$os_arch == "Power Macintosh"} { set os_arch "powerpc" } if {$os_arch == "i586" || $os_arch == "i686" || $os_arch == "x86_64"} { set os_arch "i386" } default os.arch {$os_arch} --anders From howarth at bromo.med.uc.edu Sun Sep 13 09:40:10 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 13 Sep 2009 12:40:10 -0400 Subject: version dependencies in MacPorts? Message-ID: <20090913164010.GA10412@bromo.med.uc.edu> After reading through the current MacPorts documentation, I am not seeing any reference to the ability to set a specific version/revision for particular dependencies in a Portfile. I can imagine a number of instances were this could be a problem. For example, in fink the gcc44 package has dependencies on cloog and ppl. The minimum version of cloog required to build gcc45 has increased. How is this issue addressed in MacPorts? If our gcc44 currently depended on a cloog 0.15.4 and gcc45 required a newer cloog 0.15.7 release, how would port able to handle the following case... 1) A user has gcc44 and cloog 0.15.4 installed. 2) A 'sudo port install gcc45' command is executed. What would trigger having cloog upgraded to the newer 0.15.7 release before the gcc45 build is started? While I could understand that MacPorts could have issues with version dependencies that are triggered when installing binary packages, it should at least be able to make sure that all of packages required for building another are at the required version/revision, no? Thanks in advance for any clarifications. Jack ps I can imagine that this might in concept be solved by requiring the user to do a selfupdate instead, however you would still need a mechanism to stage the build order in a manner that required version/revision dependencies are satisfied in the correct order. From raimue at macports.org Sun Sep 13 09:40:04 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Sun, 13 Sep 2009 18:40:04 +0200 Subject: [57581] trunk/dports/python/py26-cairo/Portfile In-Reply-To: <20090913162328.57AAF26E037E@beta.macosforge.org> References: <20090913162328.57AAF26E037E@beta.macosforge.org> Message-ID: <4AAD2064.6090905@macports.org> On 2009-09-13 18:23 , raimue at macports.org wrote: > --- trunk/dports/python/py26-cairo/Portfile 2009-09-13 15:53:37 UTC (rev 57580) > +++ trunk/dports/python/py26-cairo/Portfile 2009-09-13 16:23:23 UTC (rev 57581) > @@ -37,7 +37,7 @@ > > platform darwin 9 { > post-patch { > - reinplace "s| -export-symbols-regex.*||g" ${worksrcpath}/cairo/Makefile.in > + reinplace "s| -export-symbols-regex.*||g" ${worksrcpath}/src/Makefile.in > } > } I am not sure if this replace should also be done on other Mac OS X versions. It builds fine for me on Snow Leopard in the current version. Why is this necessary at all? Or should there be a darwin 10 variant with the same replace? Rainer From howarth at bromo.med.uc.edu Sun Sep 13 10:45:26 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 13 Sep 2009 13:45:26 -0400 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> Message-ID: <20090913174526.GA10752@bromo.med.uc.edu> On Sun, Sep 13, 2009 at 06:20:23PM +0200, Anders F Bj?rklund wrote: > Jack Howarth wrote: > >> If MacPorts is willing to junk the idea of building i386 packages >> as a default on 10.6, the config.guess fix is really the way to go. >> When patched this way, all programs that use config.guess to determine >> the triplets for configure will pick the correct value of >> x86_64-apple-darwin10 and there will be no need to force -m64 onto any >> compiler flags or to bother to pass --build/--host/--target to >> configure. From my own experiences on fink, I would strongly urge >> MacPorts to abandon any attempt to build an i386 MacPorts on 10.6 >> (except where non-EMT64 Core Duo and Core Solo's will do that without >> any intervention) and to focus on the x86_64 Macport builds for 10.6 >> fully utilizing the proposed config.guess patch to avoid the bother >> of passing the --build/--target/--host triplets to configure in >> Portfiles. My two cents anyway as a newcomer to MacPorts. > > You probably want to fix the "${os.arch}" as well, > since that will affect e.g. how packages are named: > > set archive.file "${name}-${version}_${revision}${portvariants}.[option > os.arch].${archive.type}" > set unarchive.file "${name}-${version}_${revision}${portvariants}. > [option os.arch].${unarchive.type}" > > "x86_64", as per http://trac.macports.org/changeset/54798 > is a workaround for http://trac.macports.org/ticket/20506 > > set os_arch $tcl_platform(machine) > if {$os_arch == "Power Macintosh"} { set os_arch "powerpc" } > if {$os_arch == "i586" || $os_arch == "i686" || $os_arch == "x86_64"} { > set os_arch "i386" } > default os.arch {$os_arch} > > --anders Anders, Where exactly are the packages files created by port stored? I don't see anything obvious in /opt/local's subdirectories. Also, are the architecture of the packages present in their filenames or do I need to invoke a command from port to see that information? Jack From afb at macports.org Sun Sep 13 11:14:54 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 13 Sep 2009 20:14:54 +0200 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <20090913174526.GA10752@bromo.med.uc.edu> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> Message-ID: <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> Jack Howarth wrote: > Anders, > Where exactly are the packages files created by port stored? I > don't > see anything obvious in /opt/local's subdirectories. Also, are the > architecture of the packages present in their filenames or do I need > to invoke a command from port to see that information? > Jack I think that /opt/local/var/macports/packages is rather obvious :-) And the architecture is in the filenames, like foo-1.0_0.i386.tgz But it's still confusing, since they had to be split up between "archives" (such as .tgz or .xpkg) and "packages" (like .rpm or .pkg) where the archives are the "internal" binaries that are used by port -b and the packages are "external" binaries *unknown* to port. More details available at http://guide.macports.org/#using.binaries, but you can't mix ports and packages like you can in Fink or FreeBSD. --anders From howarth at bromo.med.uc.edu Sun Sep 13 11:26:40 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 13 Sep 2009 14:26:40 -0400 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> Message-ID: <20090913182640.GA11037@bromo.med.uc.edu> On Sun, Sep 13, 2009 at 08:14:54PM +0200, Anders F Bj?rklund wrote: > Jack Howarth wrote: > >> Anders, >> Where exactly are the packages files created by port stored? I >> don't >> see anything obvious in /opt/local's subdirectories. Also, are the >> architecture of the packages present in their filenames or do I need >> to invoke a command from port to see that information? >> Jack > > I think that /opt/local/var/macports/packages is rather obvious :-) > And the architecture is in the filenames, like foo-1.0_0.i386.tgz > > But it's still confusing, since they had to be split up between > "archives" (such as .tgz or .xpkg) and "packages" (like .rpm or .pkg) > where the archives are the "internal" binaries that are used by > port -b and the packages are "external" binaries *unknown* to port. > > More details available at http://guide.macports.org/#using.binaries, > but you can't mix ports and packages like you can in Fink or FreeBSD. > > --anders Anders, I don't have that subdirectory. In /opt/local/var/macports all I see is... [Macintosh-2:local/var/macports] howarth% ls -a . .tclpackage distfiles receipts sources .. build port-help.tcl software Since this was the first time I ever installed MacPorts, I used the Snow Leopard dmg of MacPorts 1.8.0 and then used the "sudo port -v selfupdate" command. Jack From afb at macports.org Sun Sep 13 11:37:53 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 13 Sep 2009 20:37:53 +0200 Subject: version dependencies in MacPorts? In-Reply-To: <20090913164010.GA10412@bromo.med.uc.edu> References: <20090913164010.GA10412@bromo.med.uc.edu> Message-ID: <1B0C4132-1A1C-4A26-99AA-F04B0CA15131@macports.org> Jack Howarth wrote: > ps I can imagine that this might in concept be solved by > requiring the user to do a selfupdate instead, however you > would still need a mechanism to stage the build order in > a manner that required version/revision dependencies are > satisfied in the correct order. I believe that's the usual workaround, keep everything on the edge and requiring selfupdate and related upgrades. But sometimes it is handled by making different "major" ports like "foo1" and "foo2", and sometimes it can be addressed by versioning on a specific library or file - for instance when soname is bumped or headers are added. But there is no generic versioned dependencies... Yet ? http://trac.macports.org/wiki/SummerOfCode#dependencies --anders From afb at macports.org Sun Sep 13 11:37:55 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 13 Sep 2009 20:37:55 +0200 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <20090913182640.GA11037@bromo.med.uc.edu> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> Message-ID: Jack Howarth wrote: > Anders, > I don't have that subdirectory. In /opt/local/var/macports > all I see is... > > [Macintosh-2:local/var/macports] howarth% ls -a > . .tclpackage distfiles receipts sources > .. build port-help.tcl software > > Since this was the first time I ever installed MacPorts, I used the > Snow Leopard dmg of MacPorts 1.8.0 and then used the "sudo port -v > selfupdate" > command. Sorry, forgot two important macports.conf changes that I do: # Create and use binary archive packages for installation/ reinstallation ease portarchivemode yes # Set whether to automatically execute "clean" after "install" of ports portautoclean no Then you can package anything up by using "port archive"... RPM packages are created under /opt/local/src/{macports,rpm} depending on which RPM version that you install (4.x or 5.x). I believe the other package types are created somewhere in the work directory of the port, i.e. `port work foo`. See the docs ? --anders From afb at macports.org Sun Sep 13 11:47:56 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 13 Sep 2009 20:47:56 +0200 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> Message-ID: > Sorry, forgot two important macports.conf changes that I do: ... > # Set whether to automatically execute "clean" after "install" of > ports > portautoclean no Seems like this workaround isn't needed anymore, since 1.8.0. http://trac.macports.org/ticket/10881 --anders From raimue at macports.org Sun Sep 13 12:12:40 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 13 Sep 2009 21:12:40 +0200 Subject: version dependencies in MacPorts? In-Reply-To: <1B0C4132-1A1C-4A26-99AA-F04B0CA15131@macports.org> References: <20090913164010.GA10412@bromo.med.uc.edu> <1B0C4132-1A1C-4A26-99AA-F04B0CA15131@macports.org> Message-ID: <4AAD4428.4080008@macports.org> On 2009-09-13 20:37 , Anders F Bj?rklund wrote: >> ps I can imagine that this might in concept be solved by >> requiring the user to do a selfupdate instead, however you >> would still need a mechanism to stage the build order in >> a manner that required version/revision dependencies are >> satisfied in the correct order. > > I believe that's the usual workaround, keep everything on > the edge and requiring selfupdate and related upgrades. With 1.8.0 install will try to upgrade dependencies first before the requested port will be build. This can be seen as some sort of workaround, as we can never be sure if the installed version would satisfy the dependency if it is not the latest available version. Rainer From raimue at macports.org Sun Sep 13 12:23:12 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 13 Sep 2009 21:23:12 +0200 Subject: more verbosity In-Reply-To: <81BC0AD2-A5FD-4A4A-8192-BEF726B27CDE@macports.org> References: <20090912223312.GA12687@bromo.med.uc.edu> <6C77B1D9-797B-4C0D-B171-455CB432ACBF@macports.org> <81BC0AD2-A5FD-4A4A-8192-BEF726B27CDE@macports.org> Message-ID: <4AAD46A0.6030101@macports.org> On 2009-09-13 00:41 , Ryan Schmidt wrote: > Due to the volume of information printed by the -d switch, its use can > cause you to overlook important messages ports sometimes print out. > > For developing your own portfiles using -d is great and helpful, but > for general use, I recommend you install and upgrade ports without the > -d flag, and if you encounter an error, then clean the affected port > and try again with -d to see the full error. This will be improved once we merge the Google Summer of Code project from Dmitry which will provide better ways to analyze and filter the log messages even after a failed build. Especially you will not have to do an extra run to see debug output. Rainer From howarth at bromo.med.uc.edu Sun Sep 13 12:30:43 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 13 Sep 2009 15:30:43 -0400 Subject: version dependencies in MacPorts? In-Reply-To: <4AAD4428.4080008@macports.org> References: <20090913164010.GA10412@bromo.med.uc.edu> <1B0C4132-1A1C-4A26-99AA-F04B0CA15131@macports.org> <4AAD4428.4080008@macports.org> Message-ID: <20090913193043.GA11403@bromo.med.uc.edu> On Sun, Sep 13, 2009 at 09:12:40PM +0200, Rainer M?ller wrote: > On 2009-09-13 20:37 , Anders F Bj?rklund wrote: > >> ps I can imagine that this might in concept be solved by > >> requiring the user to do a selfupdate instead, however you > >> would still need a mechanism to stage the build order in > >> a manner that required version/revision dependencies are > >> satisfied in the correct order. > > > > I believe that's the usual workaround, keep everything on > > the edge and requiring selfupdate and related upgrades. > > With 1.8.0 install will try to upgrade dependencies first before the > requested port will be build. This can be seen as some sort of > workaround, as we can never be sure if the installed version would > satisfy the dependency if it is not the latest available version. > > Rainer Rainer, It certainly would be nice to have some sort of basic version/revision tracker for at least the buiild process of MacPort. In fink, the incrementation of package names (foobar, foobar2,foobar3) is reserved for the case where the ABI and major soversion number changes (such as openmotif3 for 2.2.4 and openmotif4 for 2.3.2). Implementing such version tracking in the packaging building side would probably easier to than at the installation side (when only binary packages are present) but still provide the framework for adding that at a later date. Jack From raimue at macports.org Sun Sep 13 12:56:19 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 13 Sep 2009 21:56:19 +0200 Subject: startupitems and port load In-Reply-To: <25B7A451-109D-4550-A0CD-BAB92FE80625@lavergne.gotdns.org> References: <25B7A451-109D-4550-A0CD-BAB92FE80625@lavergne.gotdns.org> Message-ID: <4AAD4E63.7020107@macports.org> On 2009-09-13 01:51 , Jeremy Lavergne wrote: > Does `sudo port load ...` do a force load (`launchctl load -F ...`) or > does it write it out as runnable (`launchctl load -w ...`)? It's an alias for `launchctl load -w`. And note that this feature is broken in 1.8.0, http://trac.macports.org/ticket/21128 > If it writes it out, is this the preferred way to run ports with > startupitems? `port load` has just been created as an easier alias to start and stop daemons installed through MacPorts. If you want other things (like -F) it is quite inflexible. > When creating your own launchd files, how does one correctly install it? I wanted to say to take the dbus port as example. But apparently it installs the plist files to ${prefix}/Library/LaunchDaemons (why not ${frameworks_dir}?) and adds symlinks to /Library/LaunchDaemons. Marcus, why does dbus use this way and is not directly installing to /Library/LaunchDaemons? I can't think of other ports with custom launchd files... > I've heard that using daemondo allows us to account for ports that > don't expect launchd to handle them. I think that we should go a > little beyond this and determine if we should use it or not. > > I propose that we avoid using daemondo only if the portfile explicitly > uses launchd, maintaining backwards compatibility. Any thoughts on > this? You mean flag in the Portfile to indicate if daemondo should be used or not? Rainer From jeremy at lavergne.gotdns.org Sun Sep 13 13:02:14 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sun, 13 Sep 2009 16:02:14 -0400 Subject: startupitems and port load In-Reply-To: <4AAD4E63.7020107@macports.org> References: <25B7A451-109D-4550-A0CD-BAB92FE80625@lavergne.gotdns.org> <4AAD4E63.7020107@macports.org> Message-ID: >> I propose that we avoid using daemondo only if the portfile >> explicitly uses launchd, maintaining backwards compatibility. Any >> thoughts on this? > > You mean flag in the Portfile to indicate if daemondo should be used > or not? Indirectly: I mean to use the existing startupitem.type (launchd, startupitem, etc). If it's type launchd then we already expect launchd's behavior and the added wrapping is wasteful. For this instance (or any others we deem "safe" to change) we should just create launchd scripts without daemondo being involved. From jeremy at lavergne.gotdns.org Sun Sep 13 13:03:29 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sun, 13 Sep 2009 16:03:29 -0400 Subject: startupitems and port load In-Reply-To: <4AAD4E63.7020107@macports.org> References: <25B7A451-109D-4550-A0CD-BAB92FE80625@lavergne.gotdns.org> <4AAD4E63.7020107@macports.org> Message-ID: <6D978752-94E6-42B5-A833-E37DBA82AA4C@lavergne.gotdns.org> >> Does `sudo port load ...` do a force load (`launchctl load -F ...`) >> or >> does it write it out as runnable (`launchctl load -w ...`)? > > It's an alias for `launchctl load -w`. And note that this feature is > broken in 1.8.0, http://trac.macports.org/ticket/21128 > >> If it writes it out, is this the preferred way to run ports with >> startupitems? > > `port load` has just been created as an easier alias to start and stop > daemons installed through MacPorts. If you want other things (like -F) > it is quite inflexible. Since it is an alias for `load -w`, we should go through and clean up the message that says to run "launchctl load -w ..." once that bug is fixed. The user really only needs to run `port load ...` From raimue at macports.org Sun Sep 13 13:41:38 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 13 Sep 2009 22:41:38 +0200 Subject: version dependencies in MacPorts? In-Reply-To: <20090913193043.GA11403@bromo.med.uc.edu> References: <20090913164010.GA10412@bromo.med.uc.edu> <1B0C4132-1A1C-4A26-99AA-F04B0CA15131@macports.org> <4AAD4428.4080008@macports.org> <20090913193043.GA11403@bromo.med.uc.edu> Message-ID: <4AAD5902.7030102@macports.org> On 2009-09-13 21:30 , Jack Howarth wrote: > It certainly would be nice to have some sort of basic > version/revision tracker for at least the buiild process of > MacPort. Of course I do not disagree that dependencies with versions would be useful. :-) My proposal would be to add the version to existing dependencies, like port:foo@>=1.0 with possible operators being <, >, <=, >= and =. If no version is specified, the current rules apply that the latest version is necessary. But before we could do something like this, we would also need a better syntax to handle multiple choices (like for *-devel ports) as this would not be possible with path: or bin: dependencies. > In fink, the incrementation of package names (foobar, > foobar2,foobar3) is reserved for the case where the ABI and > major soversion number changes (such as openmotif3 for 2.2.4 > and openmotif4 for 2.3.2). Implementing such version tracking > in the packaging building side would probably easier to > than at the installation side (when only binary packages are > present) but still provide the framework for adding that at > a later date. I see the problem in keeping these dependencies updated, as it is hard already to maintain basic dependencies with just port names. Finding out which versions are supported can be hard for some ports if it is not noted down in INSTALL or README. We do not have a written down strict policy for port names, but in my opinion foobar should always be the latest available version. Ports like foobarX should only be created if another dependent port cannot work with the new version due to major API changes. Rainer From howarth at bromo.med.uc.edu Sun Sep 13 13:55:51 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 13 Sep 2009 16:55:51 -0400 Subject: version dependencies in MacPorts? In-Reply-To: <4AAD5902.7030102@macports.org> References: <20090913164010.GA10412@bromo.med.uc.edu> <1B0C4132-1A1C-4A26-99AA-F04B0CA15131@macports.org> <4AAD4428.4080008@macports.org> <20090913193043.GA11403@bromo.med.uc.edu> <4AAD5902.7030102@macports.org> Message-ID: <20090913205550.GA12205@bromo.med.uc.edu> On Sun, Sep 13, 2009 at 10:41:38PM +0200, Rainer M?ller wrote: > On 2009-09-13 21:30 , Jack Howarth wrote: > > It certainly would be nice to have some sort of basic > > version/revision tracker for at least the buiild process of > > MacPort. > > Of course I do not disagree that dependencies with versions would be > useful. :-) > > My proposal would be to add the version to existing dependencies, like > port:foo@>=1.0 with possible operators being <, >, <=, >= and =. If no > version is specified, the current rules apply that the latest version is > necessary. > > But before we could do something like this, we would also need a better > syntax to handle multiple choices (like for *-devel ports) as this would > not be possible with path: or bin: dependencies. > > > In fink, the incrementation of package names (foobar, > > foobar2,foobar3) is reserved for the case where the ABI and > > major soversion number changes (such as openmotif3 for 2.2.4 > > and openmotif4 for 2.3.2). Implementing such version tracking > > in the packaging building side would probably easier to > > than at the installation side (when only binary packages are > > present) but still provide the framework for adding that at > > a later date. > > I see the problem in keeping these dependencies updated, as it is hard > already to maintain basic dependencies with just port names. Finding out > which versions are supported can be hard for some ports if it is not > noted down in INSTALL or README. > > We do not have a written down strict policy for port names, but in my > opinion foobar should always be the latest available version. Ports like > foobarX should only be created if another dependent port cannot work > with the new version due to major API changes. > > Rainer Rainer, I am not so much concerned about the installation dependencies but more on the build dependencies. For instance, I would often want to increase the minimum required version of gmp or libmpfr1 for the gcc4x packages. Rather than depending on users having executed selfupdates in a sequence that ended up those packages being updated before gcc4x was built, it is better for the build of gcc4x to be able to demand the newer versions/revisions being installed before the gcc4x package could be built. It definitely reduces the support issues for the distribution when there is some certainty of which versions of support libraries a package is built against. In the case of gcc45, configure will throw an error if the correct version of cloog-ppl isn't installed but relying on that isn't the best solution. Jack From raimue at macports.org Sun Sep 13 14:04:52 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 13 Sep 2009 23:04:52 +0200 Subject: version dependencies in MacPorts? In-Reply-To: <20090913205550.GA12205@bromo.med.uc.edu> References: <20090913164010.GA10412@bromo.med.uc.edu> <1B0C4132-1A1C-4A26-99AA-F04B0CA15131@macports.org> <4AAD4428.4080008@macports.org> <20090913193043.GA11403@bromo.med.uc.edu> <4AAD5902.7030102@macports.org> <20090913205550.GA12205@bromo.med.uc.edu> Message-ID: <4AAD5E74.3020606@macports.org> On 2009-09-13 22:55 , Jack Howarth wrote: > Rather than depending on users having executed selfupdates > in a sequence that ended up those packages being updated before gcc4x > was built, it is better for the build of gcc4x to be able to demand > the newer versions/revisions being installed before the gcc4x package > could be built. That's exactly what will happen with 1.8.0. port commands will upgrade dependencies before building the requested port. If you don't want that behavior (e.g. upgrading something like qt4-mac may take hours) you can use 'port -n'. Version dependencies could reduce the number of unnecessary/unwanted upgrades in cases where you can build against the installed version of a dependency and upgrade later. Rainer From howarth at bromo.med.uc.edu Sun Sep 13 14:47:50 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 13 Sep 2009 17:47:50 -0400 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> Message-ID: <20090913214750.GA12445@bromo.med.uc.edu> On Sun, Sep 13, 2009 at 06:20:23PM +0200, Anders F Bj?rklund wrote: > > You probably want to fix the "${os.arch}" as well, > since that will affect e.g. how packages are named: > > set archive.file "${name}-${version}_${revision}${portvariants}.[option > os.arch].${archive.type}" > set unarchive.file "${name}-${version}_${revision}${portvariants}. > [option os.arch].${unarchive.type}" > > "x86_64", as per http://trac.macports.org/changeset/54798 > is a workaround for http://trac.macports.org/ticket/20506 > > set os_arch $tcl_platform(machine) > if {$os_arch == "Power Macintosh"} { set os_arch "powerpc" } > if {$os_arch == "i586" || $os_arch == "i686" || $os_arch == "x86_64"} { > set os_arch "i386" } > default os.arch {$os_arch} > > --anders Anders, I am unclear what you mean here. Are you suggesting that I add... set archive.file "${name}-${version}_${revision}${portvariants}.[option os.arch].${archive.type}" set unarchive.file "${name}-${version}_${revision}${portvariants}.[option os.arch].${unarchive.type}" to the Portfile, because that doesn't build... Error: Unable to open port: can't read "portvariants": no such variable Or are you speaking about additional changes to portmain.tcl itself? Jack From howarth at bromo.med.uc.edu Sun Sep 13 15:03:36 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 13 Sep 2009 18:03:36 -0400 Subject: x11 virtual packages? Message-ID: <20090913220336.GA12581@bromo.med.uc.edu> Back to one of the first bugs I found in MacPorts 1.8.0 when building test packaging for the molmol molecular modelling program. I have determined that the glw component is working fine but have some concerns about the missing gui widgets in the motif interface of molmol being due to an incomplete installation of x11 in MacPorts. This leads to the question of x11 virtual packages. Do we have some way to install a x11 virtual package that would trigger the installation of a fairly complete x11 installation? My understanding from Jeremy Huddleston was that all MacPorts packages should be built against the x11 packages in MacPorts and not the system or X11 Xquartz x11 installations. It might be useful to be able to effectively achieve a complete x11 installation in MacPorts via a virtual package rather than to require the user to depend on individual packages understanding all of the required x11 components they should depend on. Specifically, I am wondering if something could me missing from my MacPorts x11 installation that doesn't break the molmol build but effects the execution of molmol under these x11 libraries. Jack From ryandesign at macports.org Sun Sep 13 16:33:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 13 Sep 2009 18:33:03 -0500 Subject: [57591] trunk/dports/tex/LaTeXiT/Portfile In-Reply-To: <20090913205606.883B926E3766@beta.macosforge.org> References: <20090913205606.883B926E3766@beta.macosforge.org> Message-ID: <3BA6737F-E42D-4C2E-A90A-B7AB9FF99195@macports.org> On Sep 13, 2009, at 15:56, jochen at macports.org wrote: > Revision: 57591 > http://trac.macports.org/changeset/57591 > Author: jochen at macports.org > Date: 2009-09-13 13:56:05 -0700 (Sun, 13 Sep 2009) > Log Message: > ----------- > make sure gs is available when run If it's only needed at runtime, not build time, then it should be depends_run not depends_lib. > Modified Paths: > -------------- > trunk/dports/tex/LaTeXiT/Portfile > > Modified: trunk/dports/tex/LaTeXiT/Portfile > =================================================================== > --- trunk/dports/tex/LaTeXiT/Portfile 2009-09-13 20:53:46 UTC (rev > 57590) > +++ trunk/dports/tex/LaTeXiT/Portfile 2009-09-13 20:56:05 UTC (rev > 57591) > @@ -26,6 +26,8 @@ > distname LaTeXiT-source-1_16_1 > use_zip yes > > +depends_lib port:ghostscript > + > worksrcdir ${name}-mainline > xcode.target "All compilations" From ryandesign at macports.org Sun Sep 13 16:41:21 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 13 Sep 2009 18:41:21 -0500 Subject: [57573] trunk/dports/devel In-Reply-To: <20090913114516.C18EF26DBF3A@beta.macosforge.org> References: <20090913114516.C18EF26DBF3A@beta.macosforge.org> Message-ID: <018EEE40-A541-4919-AE32-AD0EAB5C52D4@macports.org> On Sep 13, 2009, at 06:45, aecollins1 at macports.org wrote: > Revision: 57573 > http://trac.macports.org/changeset/57573 > Author: aecollins1 at macports.org > Date: 2009-09-13 04:45:11 -0700 (Sun, 13 Sep 2009) > Log Message: > ----------- > New port: bashdb, a GDB-like debugger for BASH scripts (version > 4.0-0.3) > > Added Paths: > ----------- > trunk/dports/devel/bashdb/ > trunk/dports/devel/bashdb/Portfile > > Added: trunk/dports/devel/bashdb/Portfile [snip] > +test.run yes > +test.cmd make check Shouldn't that be "test.target check" instead? From ryandesign at macports.org Sun Sep 13 16:51:20 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 13 Sep 2009 18:51:20 -0500 Subject: startupitems and port load In-Reply-To: References: <25B7A451-109D-4550-A0CD-BAB92FE80625@lavergne.gotdns.org> <4AAD4E63.7020107@macports.org> Message-ID: On Sep 13, 2009, at 15:02, Jeremy Lavergne wrote: >>> I propose that we avoid using daemondo only if the portfile >>> explicitly uses launchd, maintaining backwards compatibility. Any >>> thoughts on this? >> >> You mean flag in the Portfile to indicate if daemondo should be >> used or not? > > Indirectly: I mean to use the existing startupitem.type (launchd, > startupitem, etc). If it's type launchd then we already expect > launchd's behavior and the added wrapping is wasteful. For this > instance (or any others we deem "safe" to change) we should just > create launchd scripts without daemondo being involved. There are only three ports that use "startupitem.type" (murmur and denyhosts) and they both set it to the default "launchd". Based on what Joshua said: On Sep 12, 2009, at 10:06, Joshua Root wrote: > It is impedance matching for daemons that aren't happy being managed > by > launchd directly. That's all. I assume this means there are ports that would not work right when managed directly by launchd. Can anybody think of any examples of this? From ryandesign at macports.org Sun Sep 13 17:05:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 13 Sep 2009 19:05:23 -0500 Subject: x11 virtual packages? In-Reply-To: <20090913220336.GA12581@bromo.med.uc.edu> References: <20090913220336.GA12581@bromo.med.uc.edu> Message-ID: <0C26ABC0-E63A-4B2C-8E82-DCB3FFEA1DAF@macports.org> On Sep 13, 2009, at 17:03, Jack Howarth wrote: > Back to one of the first bugs I found in > MacPorts 1.8.0 when building test packaging for > the molmol molecular modelling program. I have > determined that the glw component is working > fine but have some concerns about the missing > gui widgets in the motif interface of molmol > being due to an incomplete installation of x11 > in MacPorts. > This leads to the question of x11 virtual > packages. Do we have some way to install a > x11 virtual package that would trigger the > installation of a fairly complete x11 installation? > My understanding from Jeremy Huddleston was > that all MacPorts packages should be built against > the x11 packages in MacPorts and not the system > or X11 Xquartz x11 installations. It might be > useful to be able to effectively achieve a > complete x11 installation in MacPorts via a > virtual package rather than to require the user to > depend on individual packages understanding all > of the required x11 components they should > depend on. Specifically, I am wondering if something > could me missing from my MacPorts x11 installation > that doesn't break the molmol build but effects > the execution of molmol under these x11 libraries. We want individual ports to depend on the individual X libraries they need, and not pull in everything just because it's easier for the port maintainer. If you want a complete X on your system, the port to install is the xorg metaport (or virtual package, if you like). This brings in the xorg-server and xorg-quartzwm ports, and the xorg-apps metaport which in turn brings in a whole lot of apps. If you don't want the apps but just want the X server and Apple window manager, just install xorg- server and xorg-quartzwm. From ryandesign at macports.org Sun Sep 13 17:42:36 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 13 Sep 2009 19:42:36 -0500 Subject: x11 virtual packages? In-Reply-To: <0C26ABC0-E63A-4B2C-8E82-DCB3FFEA1DAF@macports.org> References: <20090913220336.GA12581@bromo.med.uc.edu> <0C26ABC0-E63A-4B2C-8E82-DCB3FFEA1DAF@macports.org> Message-ID: <7EB09F7E-C1A4-4635-86D9-0D38429D2C88@macports.org> On Sep 13, 2009, at 19:05, Ryan Schmidt wrote: > If you want a complete X on your system, the port to install is the > xorg metaport (or virtual package, if you like). This brings in the > xorg-server and xorg-quartzwm ports, and the xorg-apps metaport > which in turn brings in a whole lot of apps. If you don't want the > apps but just want the X server and Apple window manager, just > install xorg-server and xorg-quartzwm. Sorry, it isn't called "xorg-quartzwm"; it's called "quartz-wm". From aecollins1 at macports.org Sun Sep 13 18:32:33 2009 From: aecollins1 at macports.org (Anthony Collins) Date: Mon, 14 Sep 2009 11:32:33 +1000 Subject: [57573] trunk/dports/devel In-Reply-To: <018EEE40-A541-4919-AE32-AD0EAB5C52D4@macports.org> References: <20090913114516.C18EF26DBF3A@beta.macosforge.org> <018EEE40-A541-4919-AE32-AD0EAB5C52D4@macports.org> Message-ID: On 14/09/2009, at 9:41 AM, Ryan Schmidt wrote: > >> +test.run yes >> +test.cmd make check > > Shouldn't that be "test.target check" instead? > Indeed it should be - thanks for pointing out that silly mistake. Fixed in r57601. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Sun Sep 13 18:48:47 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 13 Sep 2009 20:48:47 -0500 Subject: [57603] trunk/dports/kde/koffice/Portfile In-Reply-To: <20090914014049.36E6326E6568@beta.macosforge.org> References: <20090914014049.36E6326E6568@beta.macosforge.org> Message-ID: <7A21E202-6837-439C-852D-3BDB345C58E2@macports.org> On Sep 13, 2009, at 20:40, takanori at macports.org wrote: > Revision: 57603 > http://trac.macports.org/changeset/57603 > Author: takanori at macports.org > Date: 2009-09-13 18:40:45 -0700 (Sun, 13 Sep 2009) > Log Message: > ----------- > koffice: Seems that koffice fails to build if port:GraphicsMagick is > installed. I don't have time to fix this problem now.. > You can more simply accomplish this using the new "conflicts" keyword. Just add this line to the port: conflicts GraphicsMagick From jmr at macports.org Sun Sep 13 21:19:40 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 14 Sep 2009 14:19:40 +1000 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> Message-ID: <4AADC45C.50008@macports.org> On 2009-9-14 04:37, Anders F Bj?rklund wrote: > Sorry, forgot two important macports.conf changes that I do: > > # Create and use binary archive packages for installation/reinstallation > ease > portarchivemode yes > > # Set whether to automatically execute "clean" after "install" of ports > portautoclean no > > Then you can package anything up by using "port archive"... You actually don't need autoclean turned off any more in 1.8 for archive mode and the packaging targets to work correctly. (Ticket #10881) - Josh From and.damore at macports.org Sun Sep 13 22:40:05 2009 From: and.damore at macports.org (Andrea D'Amore) Date: Mon, 14 Sep 2009 07:40:05 +0200 Subject: [57560] trunk/dports/www In-Reply-To: <0B5F9724-5659-42CB-B476-AF1A6CD188CE@macports.org> References: <20090913073720.97BE326D8E38@beta.macosforge.org> <0B5F9724-5659-42CB-B476-AF1A6CD188CE@macports.org> Message-ID: On 13/set/09, at 10:10, Ryan Schmidt wrote: > Did the maintainer of those ports OK these updates? No, he didn't. -- Andrea From and.damore at macports.org Sun Sep 13 22:42:20 2009 From: and.damore at macports.org (Andrea D'Amore) Date: Mon, 14 Sep 2009 07:42:20 +0200 Subject: TeX (texlive) port status? In-Reply-To: <6775BE00-5281-4F91-BAA4-83F026CFBFCD@macports.org> References: <20090903173221.27B3525AA853@beta.macosforge.org> <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> <20090904023536.GF1400@ambulatoryclam.net> <20090904090415.GB16833@weetamoe.loria.fr> <6C177AD7-647A-4E66-A3FF-F0456893433A@macports.org> <6775BE00-5281-4F91-BAA4-83F026CFBFCD@macports.org> Message-ID: <38BCDC57-D24E-4879-BE50-E2DFD0FDB583@macports.org> On 09/set/09, at 09:14, Ryan Schmidt wrote: > I meant a meta-port that would ensure either the MacPorts texlive > port or an external TeX is installed. I understood it but I don't really know what binaries does a latex installation rely on, I was asking for someone with a more in-depth knowledge. -- Andrea From afb at macports.org Mon Sep 14 00:01:36 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 14 Sep 2009 09:01:36 +0200 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <20090913214750.GA12445@bromo.med.uc.edu> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913214750.GA12445@bromo.med.uc.edu> Message-ID: Jack Howarth wrote: >> You probably want to fix the "${os.arch}" as well, >> since that will affect e.g. how packages are named: >> >> set archive.file "${name}-${version}_${revision}${portvariants}. >> [option >> os.arch].${archive.type}" >> set unarchive.file "${name}-${version}_${revision}${portvariants}. >> [option os.arch].${unarchive.type}" >> > Anders, > I am unclear what you mean here. Are you suggesting that I add... > > set archive.file "${name}-${version}_${revision}${portvariants}. > [option os.arch].${archive.type}" > set unarchive.file "${name}-${version}_${revision}${portvariants}. > [option os.arch].${unarchive.type}" > > to the Portfile, because that doesn't build... > > Error: Unable to open port: can't read "portvariants": no such > variable > > Or are you speaking about additional changes to portmain.tcl itself? Those would be changes to "base". But not really in portmain.tcl but instead portarchive.tcl and portunarchive.tcl and friends... Just saying that they will still identify as "i386", even if you change the default configuration to build for x86_64 on Snowy. (but the same mislabeling happened if you used -m64 on ppc64, or when building +universal for e.g. both ppc/i386 at once...) Example: RPM macros have five build archs: i386 or ppc (using -m32), x86_64 or ppc64 (using -m64), and "fat" (using -arch i386 -arch ppc) And a sixth arch too, "noarch", which is used for scripts/data/etc. But the MacPorts archives/packages only have two: i386 or powerpc --anders From afb at macports.org Mon Sep 14 00:03:26 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 14 Sep 2009 09:03:26 +0200 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <4AADC45C.50008@macports.org> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> Message-ID: <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> Joshua Root: >> # Set whether to automatically execute "clean" after "install" of >> ports >> portautoclean no > > You actually don't need autoclean turned off any more in 1.8 for > archive > mode and the packaging targets to work correctly. (Ticket #10881) Yeah, I missed this and the auto-upgrade "feature" in the release notes... Also ran into troubles with frameworks_dir=/Library/Frameworks and Python. And of course x11prefix as well, but disallowing /usr/X11R6 was intentional. I guess that's what you get from upgrading on yearly rather than weekly basis. --anders From ryandesign at macports.org Mon Sep 14 00:44:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 14 Sep 2009 02:44:23 -0500 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> Message-ID: <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> On Sep 14, 2009, at 02:03, Anders F Bj?rklund wrote: > I guess that's what you get from upgrading on yearly rather than > weekly basis. Yes, we must must must release new versions more frequently. :-/ From afb at macports.org Mon Sep 14 01:07:53 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 14 Sep 2009 10:07:53 +0200 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> Message-ID: <20E1A306-91DC-4860-932E-EB38E3C72DD5@macports.org> Ryan Schmidt wrote: >> I guess that's what you get from upgrading on yearly rather than >> weekly basis. > > Yes, we must must must release new versions more frequently. :-/ Actually I meant *me* upgrading my packages, and it's just fine :-) The MacPorts release doesn't include any release version of ports anyway, just a archive snapshot of the current tree which might or might not work. So even if "base" isn't seeing new versions often, you are still releasing new "ports" (i.e. tree) on an hourly basis... I would actually prefer a little less often, like a "stable" branch. But I know MacPorts doesn't have the resources nor the interest to do that, so I just upgrade less often instead. Like this old Tigger, which isn't really supported anymore now that Snow Leopard is out ? But I was mostly using MP for GTK+ anyway, can get that elsewhere. --anders From jmr at macports.org Mon Sep 14 01:32:28 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 14 Sep 2009 18:32:28 +1000 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913214750.GA12445@bromo.med.uc.edu> Message-ID: <4AADFF9C.4070602@macports.org> On 2009-9-14 17:01, Anders F Bj?rklund wrote: >>> set archive.file "${name}-${version}_${revision}${portvariants}.[option >>> os.arch].${archive.type}" >>> set unarchive.file "${name}-${version}_${revision}${portvariants}. >>> [option os.arch].${unarchive.type}" > Just saying that they will still identify as "i386", even if you > change the default configuration to build for x86_64 on Snowy. > (but the same mislabeling happened if you used -m64 on ppc64, > or when building +universal for e.g. both ppc/i386 at once...) The archive names should really contain build_arch rather than os.arch, or universal_archs if appropriate, or noarch once we get a way to label ports as such. Just one more task in the binaries/registry2.0 stuff that will get worked on RSN. - Josh From milosh at macports.org Mon Sep 14 01:51:24 2009 From: milosh at macports.org (Emmanuel Hainry) Date: Mon, 14 Sep 2009 10:51:24 +0200 Subject: TeX (texlive) port status? In-Reply-To: <38BCDC57-D24E-4879-BE50-E2DFD0FDB583@macports.org> References: <31903DFC-556D-4A06-B5C0-510C44ADAD62@lavergne.gotdns.org> <20090904023536.GF1400@ambulatoryclam.net> <20090904090415.GB16833@weetamoe.loria.fr> <6C177AD7-647A-4E66-A3FF-F0456893433A@macports.org> <6775BE00-5281-4F91-BAA4-83F026CFBFCD@macports.org> <38BCDC57-D24E-4879-BE50-E2DFD0FDB583@macports.org> Message-ID: <20090914085124.GA4823@weetamoe.loria.fr> Citando Andrea D'Amore : > > > On 09/set/09, at 09:14, Ryan Schmidt wrote: > > >I meant a meta-port that would ensure either the MacPorts texlive > >port or an external TeX is installed. > > > I understood it but I don't really know what binaries does a latex > installation rely on, I was asking for someone with a more in-depth > knowledge. > You can have a look at the texlive port which is already in some sense a meta-port as it only installs symlinks. What it installs plus pdftex, xetex, omega and alpha are all the binary that may be necessary. Emmanuel From ryandesign at macports.org Mon Sep 14 02:00:07 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 14 Sep 2009 04:00:07 -0500 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <20E1A306-91DC-4860-932E-EB38E3C72DD5@macports.org> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> <20E1A306-91DC-4860-932E-EB38E3C72DD5@macports.org> Message-ID: <7C24FDB6-9A3A-41B2-8994-A6FF1F79DD7E@macports.org> On Sep 14, 2009, at 03:07, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >>> I guess that's what you get from upgrading on yearly rather than >>> weekly basis. >> >> Yes, we must must must release new versions more frequently. :-/ > > Actually I meant *me* upgrading my packages, and it's just fine :-) Ah, and I meant releasing new versions of MacPorts base more often than we have been doing. There were a large number of changes in 1.8.0, several of which are causing me and I think others considerable grief. More-frequent smaller releases would help users avoid encountering a barrage of problems all at once. > The MacPorts release doesn't include any release version of ports > anyway, just a archive snapshot of the current tree which might or > might not work. So even if "base" isn't seeing new versions often, > you are still releasing new "ports" (i.e. tree) on an hourly basis... > > I would actually prefer a little less often, like a "stable" branch. > But I know MacPorts doesn't have the resources nor the interest to > do that, so I just upgrade less often instead. Like this old Tigger, > which isn't really supported anymore now that Snow Leopard is out ? According to the Guide and our tradition, we support the current OS (i.e. Snow Leopard) and the one before that (i.e. Leopard). But we still provide a disk image of MacPorts for Tiger, and I would like to continue to allow ports to be used on it as much as possible. I have upgraded my primary system from Tiger to Snow Leopard and I expect the number of maintainers with access to Tiger is dwindling, so you should expect more ports to break on Tiger as ports get updated and not tested on Tiger anymore. But please do file tickets for problems encountered on Tiger. I can still boot to Tiger if needed to test and fix things. From afb at macports.org Mon Sep 14 02:47:25 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 14 Sep 2009 11:47:25 +0200 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <7C24FDB6-9A3A-41B2-8994-A6FF1F79DD7E@macports.org> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> <20E1A306-91DC-4860-932E-EB38E3C72DD5@macports.org> <7C24FDB6-9A3A-41B2-8994-A6FF1F79DD7E@macports.org> Message-ID: Ryan Schmidt wrote: >> I would actually prefer a little less often, like a "stable" branch. >> But I know MacPorts doesn't have the resources nor the interest to >> do that, so I just upgrade less often instead. Like this old Tigger, >> which isn't really supported anymore now that Snow Leopard is out ? > > According to the Guide and our tradition, we support the current OS > (i.e. Snow Leopard) and the one before that (i.e. Leopard). But we > still provide a disk image of MacPorts for Tiger, and I would like > to continue to allow ports to be used on it as much as possible. I > have upgraded my primary system from Tiger to Snow Leopard and I > expect the number of maintainers with access to Tiger is dwindling, > so you should expect more ports to break on Tiger as ports get > updated and not tested on Tiger anymore. But please do file tickets > for problems encountered on Tiger. I can still boot to Tiger if > needed to test and fix things. I have upgraded to Leopard (without the Snow), can boot into Tiger. But normally, I still build Universal Binaries with the 10.4 SDK... When not in MacPorts that is, since it doesn't do cross-compiles and doesn't really build binary packages either. Just "regular Mac OS X". I expect Tiger to be every bit as much deprecated now as Panther was in MacPorts 1.7 (and Jaguar in MacPorts 1.4, or whenever it died...) So wouldn't the +darwin_8 variants be deleted in MacPorts 1.9 anyway ? But sure, as it'll probably be running around here for a bit still... --anders From howarth at bromo.med.uc.edu Mon Sep 14 06:01:22 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 09:01:22 -0400 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> Message-ID: <20090914130122.GA20583@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 02:44:23AM -0500, Ryan Schmidt wrote: > > On Sep 14, 2009, at 02:03, Anders F Bj?rklund wrote: > >> I guess that's what you get from upgrading on yearly rather than >> weekly basis. > > Yes, we must must must release new versions more frequently. :-/ > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev Coming from working with fink for all these years, the first thing that struck me was how painful it is in MacPorts to visually scan through the various Portfiles. In fink, if you are looking for coding examples of packaging, you could go to one of the categories and quickly look through the various .info files for examples of the packaging you might want to implement. In MacPorts, because of the directory structure that nests the Portfile this is much more painful to do. Is there a way on the web site to quickly get to each Portfile without searching through tickets or such? Jack From jeremy at lavergne.gotdns.org Mon Sep 14 06:03:23 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 14 Sep 2009 09:03:23 -0400 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <20090914130122.GA20583@bromo.med.uc.edu> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> <20090914130122.GA20583@bromo.med.uc.edu> Message-ID: <0D9A0B14-820A-4B61-9311-AEF0DC913438@lavergne.gotdns.org> > Is there a way on the web site to > quickly get to each Portfile without searching through tickets > or such? You can view the source: http://trac.macports.org/browser/trunk/dports You can search the basic info which links to the source: http://www.macports.org/ports.php From ryandesign at macports.org Mon Sep 14 06:10:00 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 14 Sep 2009 08:10:00 -0500 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <20090914130122.GA20583@bromo.med.uc.edu> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> <20090914130122.GA20583@bromo.med.uc.edu> Message-ID: <1B5F3356-3383-406B-98E5-9203DC7DDED8@macports.org> On Sep 14, 2009, at 08:01, Jack Howarth wrote: > Coming from working with fink for all these years, the first thing > that struck me was how painful it is in MacPorts to visually > scan through the various Portfiles. In fink, if you are looking > for coding examples of packaging, you could go to one of the > categories and quickly look through the various .info files for > examples of the packaging you might want to implement. In MacPorts, > because of the directory structure that nests the Portfile this > is much more painful to do. Is there a way on the web site to > quickly get to each Portfile without searching through tickets > or such? The only place on the web site to view the portfiles is in the Trac repository browser, so that's much more painful than looking through the files on disk, which I don't mind so much. The directory structure need not be a hindrance. Usually when looking for coding examples, I cd into the dports directory and do a grep on */*/Portfile. From howarth at bromo.med.uc.edu Mon Sep 14 06:10:47 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 09:10:47 -0400 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <20E1A306-91DC-4860-932E-EB38E3C72DD5@macports.org> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> <20E1A306-91DC-4860-932E-EB38E3C72DD5@macports.org> Message-ID: <20090914131047.GB20583@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 10:07:53AM +0200, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >>> I guess that's what you get from upgrading on yearly rather than >>> weekly basis. >> >> Yes, we must must must release new versions more frequently. :-/ > > Actually I meant *me* upgrading my packages, and it's just fine :-) > > The MacPorts release doesn't include any release version of ports > anyway, just a archive snapshot of the current tree which might or > might not work. So even if "base" isn't seeing new versions often, > you are still releasing new "ports" (i.e. tree) on an hourly basis... > > I would actually prefer a little less often, like a "stable" branch. > But I know MacPorts doesn't have the resources nor the interest to > do that, so I just upgrade less often instead. Like this old Tigger, > which isn't really supported anymore now that Snow Leopard is out ? > > But I was mostly using MP for GTK+ anyway, can get that elsewhere. > > --anders > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev How active is the development branch? I ask the svn didn't seem to be that different from the current 1.8.0 release (which I assume is very recent). Also I am rather confused by the priority assignments on tickets here. Why are tickets like 20838 marked as normal priority instead of high? In fink, not having at least one of our gcc4x packages build on the latest MacOS X release would be considered a higher priority bug than normal. What level of breakage is required for the higher levels? Jack ps I added a new ticket (21341) for proposed fixed gcc44 packaging since 20838 was getting a bit cluttered. From afb at macports.org Mon Sep 14 06:31:34 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 14 Sep 2009 15:31:34 +0200 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <20090914131047.GB20583@bromo.med.uc.edu> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> <20E1A306-91DC-4860-932E-EB38E3C72DD5@macports.org> <20090914131047.GB20583@bromo.med.uc.edu> Message-ID: Jack Howarth wrote: >> I would actually prefer a little less often, like a "stable" branch. >> But I know MacPorts doesn't have the resources nor the interest to >> do that, so I just upgrade less often instead. Like this old Tigger, >> which isn't really supported anymore now that Snow Leopard is out ? > > How active is the development branch? I ask the svn didn't seem to > be that different from the current 1.8.0 release (which I assume > is very recent). There is no particular "development" branch, just trunk... Sometimes "base" is split off into releases like 1.8.0, and at the same time "dports" is archived with those: http://trac.macports.org/browser/trunk/base/ http://trac.macports.org/browser/trunk/dports/ But they all live in the same branch in the svn repository. So when you do "port selfupdate" you get the latest release of base (not trunk), and the latest sync of the ports (trunk). This is unlike Fink, which has a "stable" and an "unstable" source distribution and sometimes even a binary distribution. --anders From milosh at macports.org Mon Sep 14 06:44:01 2009 From: milosh at macports.org (Emmanuel Hainry) Date: Mon, 14 Sep 2009 15:44:01 +0200 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <1B5F3356-3383-406B-98E5-9203DC7DDED8@macports.org> References: <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> <20090914130122.GA20583@bromo.med.uc.edu> <1B5F3356-3383-406B-98E5-9203DC7DDED8@macports.org> Message-ID: <20090914134401.GA10069@weetamoe.loria.fr> Citando Ryan Schmidt : > > On Sep 14, 2009, at 08:01, Jack Howarth wrote: > > >Coming from working with fink for all these years, the first thing > >that struck me was how painful it is in MacPorts to visually > >scan through the various Portfiles. In fink, if you are looking > >for coding examples of packaging, you could go to one of the > >categories and quickly look through the various .info files for > >examples of the packaging you might want to implement. In MacPorts, > >because of the directory structure that nests the Portfile this > >is much more painful to do. Is there a way on the web site to > >quickly get to each Portfile without searching through tickets > >or such? > > The only place on the web site to view the portfiles is in the Trac > repository browser, so that's much more painful than looking through > the files on disk, which I don't mind so much. The directory > structure need not be a hindrance. Usually when looking for coding > examples, I cd into the dports directory and do a grep on > */*/Portfile. > There is also the "Available ports" page that gives links to all the portfiles: http://www.macports.org/ports.php?by=all Emmanuel From etiffany at alum.mit.edu Mon Sep 14 07:11:39 2009 From: etiffany at alum.mit.edu (Eric Tiffany) Date: Mon, 14 Sep 2009 10:11:39 -0400 Subject: Interesting survey on Snow Leopard package managers Message-ID: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> This Ars Techica thread has a survey about package managers on Snow Leopard, and an accompanying thread regarding some of these 64bit issues. http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/494000521041/showpollresults/Y -------------- next part -------------- An HTML attachment was scrubbed... URL: From howarth at bromo.med.uc.edu Mon Sep 14 07:22:57 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 10:22:57 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> Message-ID: <20090914142257.GA21285@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 10:11:39AM -0400, Eric Tiffany wrote: > This Ars Techica thread has a survey about package managers on Snow Leopard, > and an accompanying thread regarding some of these 64bit issues. > > http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/494000521041/showpollresults/Y > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev Eric, As I said in a couple threads this weekend, the smartest thing for MacPorts to do is adopt the usage of the config.guess patch (that is being evaluated by the config.guess maintainers) which I used to fix the gcc44 package here (tickets 20838 and 21341). Assuming you don't want to bother supporting i386 builds on Snow Leopard machines that are defaulting to x86_64 code, this is the most transparent solution. The only alternative is to resort to what fink does in their packaging, test the default architecture with sysctl and then manually pass the --build/--host/--target triplets to configure. I told there are a number of other packages broken on Snow Leopard in MacPorts because of the same issue. Does anyone have a list? I'll try them locally with the config.guess patch and add or open tickets for that fix. Jack From howarth at bromo.med.uc.edu Mon Sep 14 07:37:39 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 10:37:39 -0400 Subject: co-existing pythons? Message-ID: <20090914143739.GA21376@bromo.med.uc.edu> Can someone explain the details of how the various python packages in MacPorts co-exist? Most of the scientific packages I maintained in fink (and will be porting to MacPorts) use python/tcltk. I assume MacPorts doesn't really have the same type of full python variants as fink where a package can be built against any existing compatible python. While full python variants are useful, there are limitations to the concept. For example, variants really never helped get fink transitioned to the tcl 8.5 release. Co-existing tcltk packages would have introduced a bewildering number of package variations. pymol-py25-tcltk84 pymol-py26-tcltk84 pymol-py25-tcltk85 pymol-py26-tcltk25 It even worst in the past before they pruned the pythons to be supported in each -py variant. Hopefully the pythons in MacPorts aren't exclusive and one doesn't have to be deactived to install the other. In fink, the approach is to have multiple python2x packages but only one optional python package for python26 which provides the %p/bin/python symlink to the python26 executable. That actually is useful to have because I ran into at least one package, pdb2pqr which simply can't be properly built without it seeing a %p/bin/python. Not without heavily reworking its configuration scripts. Jack ps In fink, we finally upgraded tcl to 8.5, but only for the x86_64 architecture. That also raises the question, does MacPort have any way to support package variants that are architecture specific? For example having a tcl 8.4 for powerpc and i386, but tcl 8.5 for x86_64? Or would that have to be achieved through a single Portfile? From howarth at bromo.med.uc.edu Mon Sep 14 07:48:07 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 10:48:07 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <20090914142257.GA21285@bromo.med.uc.edu> References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> Message-ID: <20090914144807.GA21490@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 10:22:57AM -0400, Jack Howarth wrote: > On Mon, Sep 14, 2009 at 10:11:39AM -0400, Eric Tiffany wrote: > > This Ars Techica thread has a survey about package managers on Snow Leopard, > > and an accompanying thread regarding some of these 64bit issues. > > > > http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/494000521041/showpollresults/Y > > > _______________________________________________ > > macports-dev mailing list > > macports-dev at lists.macosforge.org > > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > Eric, > As I said in a couple threads this weekend, the smartest thing for > MacPorts to do is adopt the usage of the config.guess patch (that is being > evaluated by the config.guess maintainers) which I used to fix the gcc44 > package here (tickets 20838 and 21341). Assuming you don't want to bother > supporting i386 builds on Snow Leopard machines that are defaulting to > x86_64 code, this is the most transparent solution. The only alternative > is to resort to what fink does in their packaging, test the default > architecture with sysctl and then manually pass the --build/--host/--target > triplets to configure. > I told there are a number of other packages broken on Snow Leopard > in MacPorts because of the same issue. Does anyone have a list? I'll try > them locally with the config.guess patch and add or open tickets for that > fix. > Jack > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev You can pretty much write off gcc40, gcc42 and gcc43 for Snow Leopard. I was the one who submitted the patches to gcc trunk to make certain that gcc44 and gcc45 will build and pass its testsuite reasonably on Snow Leopard. While I could have backported the patches to gcc43, the earlier gcc releases are depreciated upstream. The general code quality has improved between gcc43 and gcc44 for it didn't seem to be worth the effort. FYI, the quality of current gcc 4.4.1 is shown here... http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg01866.html Ignore the objc errors as those are due to changes in 10.5/10.6 in the Apple runtime which haven't been addressed yet. If you use the gnu runtime they go away. Jack From ryandesign at macports.org Mon Sep 14 07:49:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 14 Sep 2009 09:49:03 -0500 Subject: co-existing pythons? In-Reply-To: <20090914143739.GA21376@bromo.med.uc.edu> References: <20090914143739.GA21376@bromo.med.uc.edu> Message-ID: <011718CF-0B75-4F93-9A77-DD8590723F9D@macports.org> On Sep 14, 2009, at 09:37, Jack Howarth wrote: > Can someone explain the details of how the various > python packages in MacPorts co-exist? Most of the scientific > packages I maintained in fink (and will be porting to MacPorts) > use python/tcltk. I assume MacPorts doesn't really have the > same type of full python variants as fink where a package can > be built against any existing compatible python. While full > python variants are useful, there are limitations to the > concept. For example, variants really never helped get fink > transitioned to the tcl 8.5 release. Co-existing tcltk packages > would have introduced a bewildering number of package variations. > > pymol-py25-tcltk84 > pymol-py26-tcltk84 > pymol-py25-tcltk85 > pymol-py26-tcltk25 > > It even worst in the past before they pruned the pythons to > be supported in each -py variant. > Hopefully the pythons in MacPorts aren't exclusive and > one doesn't have to be deactived to install the other. The various python ports and the various python module ports do not conflict with one another; they can coexist, and in many cases have to, as different ports declare dependencies on different python versions. > In > fink, the approach is to have multiple python2x packages > but only one optional python package for python26 which > provides the %p/bin/python symlink to the python26 executable. > That actually is useful to have because I ran into at least > one package, pdb2pqr which simply can't be properly built > without it seeing a %p/bin/python. Not without heavily > reworking its configuration scripts. > Jack We have the python_select script. Ideally ports would not require the user to have selected a particular python, and would work with $ {prefix}/bin/python24 or whatever directly. > ps In fink, we finally upgraded tcl to 8.5, but only for > the x86_64 architecture. That also raises the question, > does MacPort have any way to support package variants > that are architecture specific? For example having a > tcl 8.4 for powerpc and i386, but tcl 8.5 for x86_64? > Or would that have to be achieved through a single > Portfile? No, we don't do that kind of thing. Well, the one exception I can think of is oracle-instantclient, for which version 10.1.x is the only version available for PowerPC and 10.2.x is the only version available for Intel. But Oracle clearly doesn't know how to make software so I wouldn't use this port as an example for best practices. From ryandesign at macports.org Mon Sep 14 07:50:53 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 14 Sep 2009 09:50:53 -0500 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> Message-ID: <2E322D8A-B890-4617-9A19-DF51135AF15D@macports.org> On Sep 14, 2009, at 09:11, Eric Tiffany wrote: > This Ars Techica thread has a survey about package managers on Snow > Leopard, and an accompanying thread regarding some of these 64bit > issues. > > http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/494000521041/showpollresults/Y We're #1! :) From raimue at macports.org Mon Sep 14 07:55:22 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 14 Sep 2009 16:55:22 +0200 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <20090914130122.GA20583@bromo.med.uc.edu> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> <20090914130122.GA20583@bromo.med.uc.edu> Message-ID: <4AAE595A.80601@macports.org> On 2009-09-14 15:01 , Jack Howarth wrote: > Coming from working with fink for all these years, the first thing > that struck me was how painful it is in MacPorts to visually > scan through the various Portfiles. In fink, if you are looking > for coding examples of packaging, you could go to one of the > categories and quickly look through the various .info files for > examples of the packaging you might want to implement. In MacPorts, > because of the directory structure that nests the Portfile this > is much more painful to do. Is there a way on the web site to > quickly get to each Portfile without searching through tickets > or such? Note that you can easily view Portfiles by name with `port edit` or `port cat`. Also `port file` and `port dir` can be used to find Portfile paths. I don't think that nesting is particularly bad. Rainer From dluke at geeklair.net Mon Sep 14 08:01:33 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon, 14 Sep 2009 11:01:33 -0400 Subject: startupitems and port load In-Reply-To: References: <25B7A451-109D-4550-A0CD-BAB92FE80625@lavergne.gotdns.org> <4AAD4E63.7020107@macports.org> Message-ID: On Sep 13, 2009, at 7:51 PM, Ryan Schmidt wrote: > I assume this means there are ports that would not work right when > managed directly by launchd. Can anybody think of any examples of > this? Anything that calls daemon() or fork()s to run in the background and also doesn't have an option to not do this. ... also anything that uses daemondo's system state transition handling (like bind9 uses --restart-netchange) -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From howarth at bromo.med.uc.edu Mon Sep 14 08:26:31 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 11:26:31 -0400 Subject: co-existing pythons? In-Reply-To: <011718CF-0B75-4F93-9A77-DD8590723F9D@macports.org> References: <20090914143739.GA21376@bromo.med.uc.edu> <011718CF-0B75-4F93-9A77-DD8590723F9D@macports.org> Message-ID: <20090914152631.GA21690@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 09:49:03AM -0500, Ryan Schmidt wrote: > > We have the python_select script. Ideally ports would not require the > user to have selected a particular python, and would work with $ > {prefix}/bin/python24 or whatever directly. > > I believe the original idea was to avoid forcing users to install multiple versions of python in fink. They could decide which version of python they thought was best and install all of the packages as -py23, -py24, -p25 or -p26 variants. At the moment the recommended set of python variants is reduced down to -py25 and -py26. Jack From howarth at bromo.med.uc.edu Mon Sep 14 08:30:35 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 11:30:35 -0400 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <4AAE595A.80601@macports.org> References: <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> <20090914130122.GA20583@bromo.med.uc.edu> <4AAE595A.80601@macports.org> Message-ID: <20090914153035.GB21690@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 04:55:22PM +0200, Rainer M?ller wrote: > On 2009-09-14 15:01 , Jack Howarth wrote: > > Coming from working with fink for all these years, the first thing > > that struck me was how painful it is in MacPorts to visually > > scan through the various Portfiles. In fink, if you are looking > > for coding examples of packaging, you could go to one of the > > categories and quickly look through the various .info files for > > examples of the packaging you might want to implement. In MacPorts, > > because of the directory structure that nests the Portfile this > > is much more painful to do. Is there a way on the web site to > > quickly get to each Portfile without searching through tickets > > or such? > > Note that you can easily view Portfiles by name with `port edit` or > `port cat`. Also `port file` and `port dir` can be used to find Portfile > paths. I don't think that nesting is particularly bad. > > Rainer Rainer, No. That doesn't sound bad. It's just the learning curve coming from fink is a bit steep. I am still sorting out details like what are the corresponding options to -k (which leaves behind the build directories) and -K (which leaves behind the binary packaging installation directories) in port. So far it seems, I have have to do a 'sudo port build' and stop there to keep the build directories. Jack From howarth at bromo.med.uc.edu Mon Sep 14 08:50:14 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 11:50:14 -0400 Subject: co-existing pythons? In-Reply-To: <011718CF-0B75-4F93-9A77-DD8590723F9D@macports.org> References: <20090914143739.GA21376@bromo.med.uc.edu> <011718CF-0B75-4F93-9A77-DD8590723F9D@macports.org> Message-ID: <20090914155014.GA22670@bromo.med.uc.edu> Actually one reason I asked the question was that while trying to debug the problems I am seeing with my test packaging of the molmol molecular modelling program, I tried to build molmol against lesstif instead of openmotif. In that case, the lesstif package wanted me to deactive the openmotif package. What exactly does this deactivation do? Will binaries built against lesstif and openmotif run at the same time? In fink we have lesstif-bin, openmotif3-bin and openmotif4-bin packages that conflict with each other. However this doesn't really impact running binaries from packages built against the different motifs at the same time. The 'deactivation' prompt was a little scary since it doesn't clearly indicate that this process won't make the deactivated motif non-functional. Jack From ryandesign at macports.org Mon Sep 14 09:00:15 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 14 Sep 2009 11:00:15 -0500 Subject: co-existing pythons? In-Reply-To: <20090914155014.GA22670@bromo.med.uc.edu> References: <20090914143739.GA21376@bromo.med.uc.edu> <011718CF-0B75-4F93-9A77-DD8590723F9D@macports.org> <20090914155014.GA22670@bromo.med.uc.edu> Message-ID: <5E3E69E0-4447-4BCA-8D01-662B0C71FC3E@macports.org> On Sep 14, 2009, at 10:50, Jack Howarth wrote: > Actually one reason I asked the question was that > while trying to debug the problems I am seeing with > my test packaging of the molmol molecular modelling > program, I tried to build molmol against lesstif instead > of openmotif. In that case, the lesstif package wanted > me to deactive the openmotif package. How did the lesstif package tell you this? I thought maybe the lesstif and openmotif ports were marked as conflicting with one another, but that does not appear to be the case. But it has only been possible to mark ports as conflicting since MacPorts 1.8.0 which has only been out since August 27, 2009, so it could still be that the ports do conflict and that conflicts key still needs to be added to these ports. > What exactly > does this deactivation do? Deactivating a port removes its files from ${prefix} thus making them unavailable. > Will binaries built against > lesstif and openmotif run at the same time? If they conflict and install the same files, then you can only have one or the other. > In fink > we have lesstif-bin, openmotif3-bin and openmotif4-bin > packages that conflict with each other. However > this doesn't really impact running binaries from > packages built against the different motifs at the > same time. The 'deactivation' prompt was a little > scary since it doesn't clearly indicate that this > process won't make the deactivated motif non-functional. Deactivating a port will almost certainly make software that depends on it nonfunctional. From ryandesign at macports.org Mon Sep 14 09:02:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 14 Sep 2009 11:02:08 -0500 Subject: co-existing pythons? In-Reply-To: <5E3E69E0-4447-4BCA-8D01-662B0C71FC3E@macports.org> References: <20090914143739.GA21376@bromo.med.uc.edu> <011718CF-0B75-4F93-9A77-DD8590723F9D@macports.org> <20090914155014.GA22670@bromo.med.uc.edu> <5E3E69E0-4447-4BCA-8D01-662B0C71FC3E@macports.org> Message-ID: <3FA56831-A362-4BC8-B24D-048FC592F93E@macports.org> On Sep 14, 2009, at 11:00, Ryan Schmidt wrote: > On Sep 14, 2009, at 10:50, Jack Howarth wrote: > >> Actually one reason I asked the question was that >> while trying to debug the problems I am seeing with >> my test packaging of the molmol molecular modelling >> program, I tried to build molmol against lesstif instead >> of openmotif. In that case, the lesstif package wanted >> me to deactive the openmotif package. > > How did the lesstif package tell you this? Having tried it myself now, I see: ---> Installing lesstif @0.95.2_1+universal ---> Activating lesstif @0.95.2_1+universal Error: Target org.macports.activate returned: Image error: /opt/local/ bin/mwm is being used by the active openmotif port. Please deactivate this port first, or use 'port -f activate lesstif' to force the activation. Error: Status 1 encountered during processing. So yes, both ports install the same file, so the ports should be marked as conflicting with one another, and you can only have one or the other. From howarth at bromo.med.uc.edu Mon Sep 14 09:21:12 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 12:21:12 -0400 Subject: co-existing pythons? In-Reply-To: <3FA56831-A362-4BC8-B24D-048FC592F93E@macports.org> References: <20090914143739.GA21376@bromo.med.uc.edu> <011718CF-0B75-4F93-9A77-DD8590723F9D@macports.org> <20090914155014.GA22670@bromo.med.uc.edu> <5E3E69E0-4447-4BCA-8D01-662B0C71FC3E@macports.org> <3FA56831-A362-4BC8-B24D-048FC592F93E@macports.org> Message-ID: <20090914162112.GA24361@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 11:02:08AM -0500, Ryan Schmidt wrote: > > On Sep 14, 2009, at 11:00, Ryan Schmidt wrote: > >> On Sep 14, 2009, at 10:50, Jack Howarth wrote: >> >>> Actually one reason I asked the question was that >>> while trying to debug the problems I am seeing with >>> my test packaging of the molmol molecular modelling >>> program, I tried to build molmol against lesstif instead >>> of openmotif. In that case, the lesstif package wanted >>> me to deactive the openmotif package. >> >> How did the lesstif package tell you this? > > Having tried it myself now, I see: > > ---> Installing lesstif @0.95.2_1+universal > ---> Activating lesstif @0.95.2_1+universal > Error: Target org.macports.activate returned: Image error: /opt/local/ > bin/mwm is being used by the active openmotif port. Please deactivate > this port first, or use 'port -f activate lesstif' to force the > activation. > Error: Status 1 encountered during processing. > > So yes, both ports install the same file, so the ports should be marked > as conflicting with one another, and you can only have one or the other. > Yes, this is one thing I definitely miss from fink. Most packages providing development libraries are either present as... foobar headers foobar-bin binaries foobar-shlibs shared libraries or foobar-dev headers foobar binaries foobar-shlibs shared libraries So for lesstif.info, openmotif3.info and openmotif4.info, the lesstif-shlibs, openmotif3-shlibs and openmotif4-shlibs debs can co-exist. The lesstif, openmotif3 and openmotif4 debs with the headers, static libs and symlinks for the shared libs as libXm.dylib, libMrm.dylib conflict. Lastly the debs for lesstif-bin, openmotif3-bin and openmotif4-bin conflict. That packaging approach worked very well for me when I maintained those packages in fink. Jack From toby at macports.org Mon Sep 14 09:27:18 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 14 Sep 2009 09:27:18 -0700 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <20090914142257.GA21285@bromo.med.uc.edu> References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> Message-ID: <74c219d30909140927h56118971h9a59628b6e55edd6@mail.gmail.com> On Mon, Sep 14, 2009 at 07:22, Jack Howarth wrote: > On Mon, Sep 14, 2009 at 10:11:39AM -0400, Eric Tiffany wrote: >> This Ars Techica thread has a survey about package managers on Snow Leopard, >> and an accompanying thread regarding some of these 64bit issues. >> >> http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/494000521041/showpollresults/Y > >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > Eric, > ? As I said in a couple threads this weekend, the smartest thing for > MacPorts to do is adopt the usage of the config.guess patch (that is being > evaluated by the config.guess maintainers) which I used to fix the gcc44 > package here (tickets 20838 and 21341). Assuming you don't want to bother > supporting i386 builds on Snow Leopard machines that are defaulting to > x86_64 code, this is the most transparent solution. The only alternative > is to resort to what fink does in their packaging, test the default > architecture with sysctl and then manually pass the --build/--host/--target > triplets to configure. > ? I told there are a number of other packages broken on Snow Leopard > in MacPorts because of the same issue. Does anyone have a list? I'll try > them locally with the config.guess patch and add or open tickets for that > fix. Our current approach (passing -arch) seems to be working fine - I think both of your suggestions are bit heavy-handed considering *most* ports work just fine with -arch flags. - Toby From howarth at bromo.med.uc.edu Mon Sep 14 10:18:26 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 13:18:26 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> Message-ID: <20090914171826.GA26184@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 09:25:38AM -0700, Toby Peterson wrote: > On Mon, Sep 14, 2009 at 07:22, Jack Howarth wrote: > > On Mon, Sep 14, 2009 at 10:11:39AM -0400, Eric Tiffany wrote: > >> This Ars Techica thread has a survey about package managers on Snow Leopard, > >> and an accompanying thread regarding some of these 64bit issues. > >> > >> http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/494000521041/showpollresults/Y > > > >> _______________________________________________ > >> macports-dev mailing list > >> macports-dev at lists.macosforge.org > >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > > ? As I said in a couple threads this weekend, the smartest thing for > > MacPorts to do is adopt the usage of the config.guess patch (that is being > > evaluated by the config.guess maintainers) which I used to fix the gcc44 > > package here (tickets 20838 and 21341). Assuming you don't want to bother > > supporting i386 builds on Snow Leopard machines that are defaulting to > > x86_64 code, this is the most transparent solution. The only alternative > > is to resort to what fink does in their packaging, test the default > > architecture with sysctl and then manually pass the --build/--host/--target > > triplets to configure. > > ? I told there are a number of other packages broken on Snow Leopard > > in MacPorts because of the same issue. Does anyone have a list? I'll try > > them locally with the config.guess patch and add or open tickets for that > > fix. > > Our current approach (passing -arch) seems to be working fine - I > think both of your suggestions are bit heavy-handed considering *most* > ports work just fine with -arch flags. > > - Toby Toby, That is a pretty extreme statement. I would argue the exact opposite. It is very heavy handed to let configure deduce an entirely different architecture and then change that behind its back by passing -arch to CFLAGS. If you think I'm wrong, go ahead and try to fix gcc44 with your approach. Good luck. Unless you are absolutely certain of the results, you don't want to be decoupling the triplet used by configure from the code generation used. Sure you might get away for awhile in general, but it could be misbuilding packages in subtle ways that are difficult to detect. If you insist on passing -m64, you absolutely should be passing... --host=x86_64-apple-darwin10 --build=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 to configure. I would also consider passing -m64 on CC instead of CFLAGS in that case as well. Also I don't even understand this fixation on passing -march. Unless you have added compiler wrappers to change the default behavior of gcc-4.2 or are using the depreciated gcc-4.0 compiler, the default code generation should always be x86_64 on EMT64-capable hardware. Passing -march does nothing for helping configure understand the correct architecture is it building on. Only explicitly passing the triplets or fixing config.guess does that. Jack From blair at orcaware.com Mon Sep 14 10:43:03 2009 From: blair at orcaware.com (Blair Zajac) Date: Mon, 14 Sep 2009 10:43:03 -0700 Subject: x86_64 10.5/i386 fink 10.6 and the options for MacPorts In-Reply-To: <0D9A0B14-820A-4B61-9311-AEF0DC913438@lavergne.gotdns.org> References: <20090913124825.GA9119@bromo.med.uc.edu> <27A1F162-F5F2-4635-8C9B-ECF696E4CE92@macports.org> <20090913174526.GA10752@bromo.med.uc.edu> <5D5C083F-A22B-45FD-B484-C12ADA20B379@macports.org> <20090913182640.GA11037@bromo.med.uc.edu> <4AADC45C.50008@macports.org> <2E72F21D-62E9-4D5A-9C21-3938FABAA4AE@macports.org> <04D1171E-FD7C-4C3C-8F0E-35A617D3E155@macports.org> <20090914130122.GA20583@bromo.med.uc.edu> <0D9A0B14-820A-4B61-9311-AEF0DC913438@lavergne.gotdns.org> Message-ID: <4AAE80A7.1090504@orcaware.com> Jeremy Lavergne wrote: >> Is there a way on the web site to >> quickly get to each Portfile without searching through tickets >> or such? > > You can view the source: > http://trac.macports.org/browser/trunk/dports Or directly to the Subversion repository, which is faster than going through Trac: http://svn.macports.org/repository/macports/trunk/dports/ Regards, Blair From toby at macports.org Mon Sep 14 11:08:46 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 14 Sep 2009 11:08:46 -0700 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <20090914171826.GA26184@bromo.med.uc.edu> References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> <20090914171826.GA26184@bromo.med.uc.edu> Message-ID: <74c219d30909141108l20f9d72cpe3eeaf6487d1933e@mail.gmail.com> On Mon, Sep 14, 2009 at 10:18, Jack Howarth wrote: > On Mon, Sep 14, 2009 at 09:25:38AM -0700, Toby Peterson wrote: >> On Mon, Sep 14, 2009 at 07:22, Jack Howarth wrote: >> > On Mon, Sep 14, 2009 at 10:11:39AM -0400, Eric Tiffany wrote: >> >> This Ars Techica thread has a survey about package managers on Snow Leopard, >> >> and an accompanying thread regarding some of these 64bit issues. >> >> >> >> http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/494000521041/showpollresults/Y >> > >> >> _______________________________________________ >> >> macports-dev mailing list >> >> macports-dev at lists.macosforge.org >> >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> > >> > ? As I said in a couple threads this weekend, the smartest thing for >> > MacPorts to do is adopt the usage of the config.guess patch (that is being >> > evaluated by the config.guess maintainers) which I used to fix the gcc44 >> > package here (tickets 20838 and 21341). Assuming you don't want to bother >> > supporting i386 builds on Snow Leopard machines that are defaulting to >> > x86_64 code, this is the most transparent solution. The only alternative >> > is to resort to what fink does in their packaging, test the default >> > architecture with sysctl and then manually pass the --build/--host/--target >> > triplets to configure. >> > ? I told there are a number of other packages broken on Snow Leopard >> > in MacPorts because of the same issue. Does anyone have a list? I'll try >> > them locally with the config.guess patch and add or open tickets for that >> > fix. >> >> Our current approach (passing -arch) seems to be working fine - I >> think both of your suggestions are bit heavy-handed considering *most* >> ports work just fine with -arch flags. >> >> - Toby > > ? That is a pretty extreme statement. I would argue the exact opposite. > It is very heavy handed to let configure deduce an entirely different > architecture and then change that behind its back by passing -arch to > CFLAGS. If you think I'm wrong, go ahead and try to fix gcc44 with > your approach. Good luck. Unless you are absolutely certain of the > results, you don't want to be decoupling the triplet used by > configure from the code generation used. Sure you might get away > for awhile in general, but it could be misbuilding packages in > subtle ways that are difficult to detect. If you insist on passing > -m64, you absolutely should be passing... > > --host=x86_64-apple-darwin10 --build=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 > > to configure. I would also consider passing -m64 on CC instead of CFLAGS > in that case as well. Also I don't even understand this fixation on > passing -march. Unless you have added compiler wrappers to change the > default behavior of gcc-4.2 or are using the depreciated gcc-4.0 > compiler, the default code generation should always be x86_64 on > EMT64-capable hardware. Passing -march does nothing for helping > configure understand the correct architecture is it building on. > Only explicitly passing the triplets or fixing config.guess does > that. Do what you want with gcc, I'm just not in favor of making a global change to the way we run configure. Also note that passing identical --host and --target values has no effect. Passing --build at least makes some sense, but since we're not cross-compiling there's really no reason to use the other flags. - Toby From howarth at bromo.med.uc.edu Mon Sep 14 11:19:36 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 14:19:36 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> Message-ID: <20090914181936.GA27831@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 09:25:38AM -0700, Toby Peterson wrote: > > Our current approach (passing -arch) seems to be working fine - I > think both of your suggestions are bit heavy-handed considering *most* > ports work just fine with -arch flags. > > - Toby Toby, I would also suggest reading... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180#c28 Unfortunately, the discussion in that bug report may be hard to follow. Basically Mike Stump was asking the FSF gcc developers to adopt an approach that would be more forgiving to naive users allowing gcc to be built against the wrong tripets. The tail end of comment 28 is the FSF developer response. It is basically that if the user doesn't pass the correct triplets to configure that they desire the breakage they get. Again this was EXACTLY the case with the current gcc44 Portfile on Snow Leopard. The Portfile makes no attempt to correct the guessed triplets by passing them explicitly to configure yet assumes it can force -m64 onto the compiler. What happens is configure sets up to build a 32-bit compiler for i386-apple-darwin10 and gcc proceeds to generate 64-bit code behind its back. When the build hits the multilib section the logic used in the multilib is totally broken. Granted gcc is an extreme case but it is VERY unwise to assume that configure will never set anything that architecture dependent when the wrong triplet are passed. For example, if there is any hard coded assembly language routines in the code, the wrong assembly code will be selected by configure. Not passing the correct triplet to configure or correcting config.guess is simply bad technique. Jack From toby at macports.org Mon Sep 14 11:30:41 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 14 Sep 2009 11:30:41 -0700 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <20090914181936.GA27831@bromo.med.uc.edu> References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> <20090914181936.GA27831@bromo.med.uc.edu> Message-ID: <74c219d30909141130p7e4679c0p298513b5467d33e@mail.gmail.com> On Mon, Sep 14, 2009 at 11:19, Jack Howarth wrote: > On Mon, Sep 14, 2009 at 09:25:38AM -0700, Toby Peterson wrote: >> >> Our current approach (passing -arch) seems to be working fine - I >> think both of your suggestions are bit heavy-handed considering *most* >> ports work just fine with -arch flags. >> >> - Toby > > ? Granted gcc is an extreme case but it is VERY unwise to > assume that configure will never set anything that architecture > dependent when the wrong triplet are passed. For example, if > there is any hard coded assembly language routines in the code, > the wrong assembly code will be selected by configure. Not passing the > correct triplet to configure or correcting config.guess is > simply bad technique. Indeed, and for the (very few) ports that require tweaking, we can make the necessary changes. I've already committed dozens of fixes to correct these types of issues. - Toby From howarth at bromo.med.uc.edu Mon Sep 14 11:58:30 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 14:58:30 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <74c219d30909141130p7e4679c0p298513b5467d33e@mail.gmail.com> References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> <20090914181936.GA27831@bromo.med.uc.edu> <74c219d30909141130p7e4679c0p298513b5467d33e@mail.gmail.com> Message-ID: <20090914185830.GA28519@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 11:30:41AM -0700, Toby Peterson wrote: > On Mon, Sep 14, 2009 at 11:19, Jack Howarth wrote: > > On Mon, Sep 14, 2009 at 09:25:38AM -0700, Toby Peterson wrote: > >> > >> Our current approach (passing -arch) seems to be working fine - I > >> think both of your suggestions are bit heavy-handed considering *most* > >> ports work just fine with -arch flags. > >> > >> - Toby > > > > ? Granted gcc is an extreme case but it is VERY unwise to > > assume that configure will never set anything that architecture > > dependent when the wrong triplet are passed. For example, if > > there is any hard coded assembly language routines in the code, > > the wrong assembly code will be selected by configure. Not passing the > > correct triplet to configure or correcting config.guess is > > simply bad technique. > > Indeed, and for the (very few) ports that require tweaking, we can > make the necessary changes. I've already committed dozens of fixes to > correct these types of issues. > > - Toby Toby, True perhaps, but simple logic dictates that it is bad form for configure to think it is compiling code for a 32-bit architecture and then gcc to start generating 64-bit code behind its back. Remember that Apple has done something no one has ever done before...create an operating system that runs a 32-bit kernel but 64-bit executables. I tried unsuccessfully during Snow Leopard's development to get a more accurate reporting of the default executables from either uname or arch. I have several radar bugs open on that issue. If you consider that the arch manpage says... The arch command with no arguments, displays the machine's architecture type. The other use of the arch command it to run a selected architecture of a universal binary. A universal binary contains code that can run on different architectures. By default, the operating system will select the archi- tecture that most closely matches the processor type. This means that an intel architecture is selected on intel processors and a powerpc architecture is selected on powerpc processors. A 64-bit architecuture is pre- ferred over a 32-bit architecture on a 64-bit processor, while only 32-bit architectures can run on a 32-bit processor. ...even on Leopard, it is obvious that arch without arguments should report the preferred architecture (which is the one run) that is x86_64 on EMT64 compatible hardware. No one has ever decoupled the triplet detected from 'uname -p' or 'arch' from the actual architecture of binary being run. It is no wonder this causes build issues. Only if you are running the 64-bit kernel in Snow Leopard does the correct triplet get passed by the current config.guess. This is the purpose of the config.guess patch...to adapt to the fact that Apple refuses to properly report the actual default architecture through uname or arch. Jack From mta at umich.edu Mon Sep 14 12:54:21 2009 From: mta at umich.edu (Mike Alexander) Date: Mon, 14 Sep 2009 15:54:21 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <20090914185830.GA28519@bromo.med.uc.edu> References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> <20090914181936.GA27831@bromo.med.uc.edu> <74c219d30909141130p7e4679c0p298513b5467d33e@mail.gmail.com> <20090914185830.GA28519@bromo.med.uc.edu> Message-ID: <987673B4202719002D27B14D@fitzrovia.msalexander.com> --On September 14, 2009 2:58:30 PM -0400 Jack Howarth wrote: > True perhaps, but simple logic dictates that it is bad form for > configure to think it is compiling code for a 32-bit architecture > and then gcc to start generating 64-bit code behind its back. Remember > that Apple has done something no one has ever done before...create > an operating system that runs a 32-bit kernel but 64-bit executables. I have to agree with Jack on this issue. Having worked on and with various compilers and operating systems for over 40 years I've seen far too many problems caused by people trying to second guess what the compiler or system thinks it should be doing. I've also had a few problems with MacPorts caused by it's use of -arch and -m64 flags. Mike Alexander From toby at macports.org Mon Sep 14 12:55:28 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 14 Sep 2009 12:55:28 -0700 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <20090914185830.GA28519@bromo.med.uc.edu> References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> <20090914181936.GA27831@bromo.med.uc.edu> <74c219d30909141130p7e4679c0p298513b5467d33e@mail.gmail.com> <20090914185830.GA28519@bromo.med.uc.edu> Message-ID: <74c219d30909141255n5e37915dv3618ab46503d7ff7@mail.gmail.com> On Mon, Sep 14, 2009 at 11:58, Jack Howarth wrote: > On Mon, Sep 14, 2009 at 11:30:41AM -0700, Toby Peterson wrote: >> On Mon, Sep 14, 2009 at 11:19, Jack Howarth wrote: >> > On Mon, Sep 14, 2009 at 09:25:38AM -0700, Toby Peterson wrote: >> >> >> >> Our current approach (passing -arch) seems to be working fine - I >> >> think both of your suggestions are bit heavy-handed considering *most* >> >> ports work just fine with -arch flags. >> >> >> >> - Toby >> > >> > ? Granted gcc is an extreme case but it is VERY unwise to >> > assume that configure will never set anything that architecture >> > dependent when the wrong triplet are passed. For example, if >> > there is any hard coded assembly language routines in the code, >> > the wrong assembly code will be selected by configure. Not passing the >> > correct triplet to configure or correcting config.guess is >> > simply bad technique. >> >> Indeed, and for the (very few) ports that require tweaking, we can >> make the necessary changes. I've already committed dozens of fixes to >> correct these types of issues. >> >> - Toby > > ? True perhaps, but simple logic dictates that it is bad form for > configure to think it is compiling code for a 32-bit architecture > and then gcc to start generating 64-bit code behind its back. Remember > that Apple has done something no one has ever done before...create > an operating system that runs a 32-bit kernel but 64-bit executables. > I tried unsuccessfully during Snow Leopard's development to get a > more accurate reporting of the default executables from either > uname or arch. I have several radar bugs open on that issue. If you > consider that the arch manpage says... > > ? ? The arch command with no arguments, displays the machine's architecture type. > > ? ? The other use of the arch command it to run a selected architecture of a universal binary. ?A universal binary > ? ? contains code that can run on different architectures. ?By default, the operating system will select the archi- > ? ? tecture that most closely matches the processor type. ?This means that an intel architecture is selected on > ? ? intel processors and a powerpc architecture is selected on powerpc processors. ?A 64-bit architecuture is pre- > ? ? ferred over a 32-bit architecture on a 64-bit processor, while only 32-bit architectures can run on a 32-bit > ? ? processor. > > ...even on Leopard, it is obvious that arch without arguments should report > the preferred architecture (which is the one run) that is x86_64 on EMT64 > compatible hardware. No one has ever decoupled the triplet detected from > 'uname -p' or 'arch' from the actual architecture of binary being run. It > is no wonder this causes build issues. Only if you are running the 64-bit > kernel in Snow Leopard does the correct triplet get passed by the current > config.guess. This is the purpose of the config.guess patch...to adapt to > the fact that Apple refuses to properly report the actual default architecture > through uname or arch. It may be bad form, but I'd bet most ports would build just fine for lol-apple-darwin, because they simply don't care. I'd rather patch the few ports that do matter rather than making sweeping changes that are sure to break ports that currently build correctly. K64 makes no difference - config.guess uses uname -p, which is i386 on K32 and K64. The fact is that arch/uname aren't the correct tools for determing the answer to this particular question. - Toby From toby at macports.org Mon Sep 14 12:55:59 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 14 Sep 2009 12:55:59 -0700 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <987673B4202719002D27B14D@fitzrovia.msalexander.com> References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> <20090914181936.GA27831@bromo.med.uc.edu> <74c219d30909141130p7e4679c0p298513b5467d33e@mail.gmail.com> <20090914185830.GA28519@bromo.med.uc.edu> <987673B4202719002D27B14D@fitzrovia.msalexander.com> Message-ID: <74c219d30909141255u4fad6fb0pad1ac6596034dc17@mail.gmail.com> On Mon, Sep 14, 2009 at 12:54, Mike Alexander wrote: > --On September 14, 2009 2:58:30 PM -0400 Jack Howarth > wrote: > >> ? True perhaps, but simple logic dictates that it is bad form for >> configure to think it is compiling code for a 32-bit architecture >> and then gcc to start generating 64-bit code behind its back. Remember >> that Apple has done something no one has ever done before...create >> an operating system that runs a 32-bit kernel but 64-bit executables. > > I have to agree with Jack on this issue. ?Having worked on and with various > compilers and operating systems for over 40 years I've seen far too many > problems caused by people trying to second guess what the compiler or system > thinks it should be doing. ?I've also had a few problems with MacPorts > caused by it's use of -arch and -m64 flags. The ports that need to be fixed should get fixed. Making changes to MacPorts base is not the way to accomplish this. - Toby From raimue at macports.org Mon Sep 14 13:05:13 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 14 Sep 2009 22:05:13 +0200 Subject: co-existing pythons? In-Reply-To: <20090914162112.GA24361@bromo.med.uc.edu> References: <20090914143739.GA21376@bromo.med.uc.edu> <011718CF-0B75-4F93-9A77-DD8590723F9D@macports.org> <20090914155014.GA22670@bromo.med.uc.edu> <5E3E69E0-4447-4BCA-8D01-662B0C71FC3E@macports.org> <3FA56831-A362-4BC8-B24D-048FC592F93E@macports.org> <20090914162112.GA24361@bromo.med.uc.edu> Message-ID: <4AAEA1F9.3010305@macports.org> On 2009-09-14 18:21 , Jack Howarth wrote: > Yes, this is one thing I definitely miss from fink. Most packages providing > development libraries are either present as... > > foobar headers > foobar-bin binaries > foobar-shlibs shared libraries > > or > > foobar-dev headers > foobar binaries > foobar-shlibs shared libraries The reason for this split would be that fink is also a binary distribution and therefore not everyone needs the headers. But such splits do not make sense with source distributions in my opinion, as you will always need headers to build dependents. Rainer From vince at macports.org Mon Sep 14 13:08:22 2009 From: vince at macports.org (vincent habchi) Date: Mon, 14 Sep 2009 22:08:22 +0200 Subject: Fwd: Interesting survey on Snow Leopard package managers References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> Message-ID: > K64 makes no difference - config.guess uses uname -p, which is i386 on > K32 and K64. The fact is that arch/uname aren't the correct tools for > determing the answer to this particular question. Granted that point, is it possible to build, or provide, a modified version of uname, to be put in the tools or whatever suitable directory, and that would override /usr/bin/uname with more sensible data? Does it make sense? V. From dluke at geeklair.net Mon Sep 14 13:15:50 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon, 14 Sep 2009 16:15:50 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> Message-ID: On Sep 14, 2009, at 4:08 PM, vincent habchi wrote: >> K64 makes no difference - config.guess uses uname -p, which is i386 >> on >> K32 and K64. The fact is that arch/uname aren't the correct tools for >> determing the answer to this particular question. > > Granted that point, is it possible to build, or provide, a modified > version of uname, to be put in the tools or whatever suitable > directory, and that would override /usr/bin/uname with more sensible > data? Does it make sense? No, but it's probably possible to get configure to correctly build a triple by using other tools (like it has to do on solaris, for example). It sounds like that's what Jack has done with his updated configure.guess... I would tend to agree with Toby, though, that this probably isn't something that needs to be addressed by base/ -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From vince at macports.org Mon Sep 14 13:21:42 2009 From: vince at macports.org (vincent habchi) Date: Mon, 14 Sep 2009 22:21:42 +0200 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> Message-ID: Le 14 sept. 2009 ? 22:15, Daniel J. Luke a ?crit : > On Sep 14, 2009, at 4:08 PM, vincent habchi wrote: >>> K64 makes no difference - config.guess uses uname -p, which is >>> i386 on >>> K32 and K64. The fact is that arch/uname aren't the correct tools >>> for >>> determing the answer to this particular question. >> >> Granted that point, is it possible to build, or provide, a modified >> version of uname, to be put in the tools or whatever suitable >> directory, and that would override /usr/bin/uname with more >> sensible data? Does it make sense? > > No, but it's probably possible to get configure to correctly build a > triple by using other tools (like it has to do on solaris, for > example). > > It sounds like that's what Jack has done with his updated > configure.guess... > > I would tend to agree with Toby, though, that this probably isn't > something that needs to be addressed by base/ Could it also be reported as a bug to Apple, to be modified in a future SL patch? After all, if I read the manpage correctly, uname -p is supposed to reflect the processor architecture, which is not the architecture the kernel was build for. V. From jmr at macports.org Mon Sep 14 13:22:17 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 15 Sep 2009 06:22:17 +1000 Subject: Fwd: Interesting survey on Snow Leopard package managers In-Reply-To: References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> Message-ID: <4AAEA5F9.2040008@macports.org> On 2009-9-15 06:08, vincent habchi wrote: > >> K64 makes no difference - config.guess uses uname -p, which is i386 on >> K32 and K64. The fact is that arch/uname aren't the correct tools for >> determing the answer to this particular question. > > Granted that point, is it possible to build, or provide, a modified > version of uname, to be put in the tools or whatever suitable directory, > and that would override /usr/bin/uname with more sensible data? Does it > make sense? On a universal i386/x86_64 system, i386 is *a* correct answer for uname -p to be giving... - Josh From howarth at bromo.med.uc.edu Mon Sep 14 13:53:48 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 16:53:48 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> Message-ID: <20090914205348.GA29134@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 10:21:42PM +0200, vincent habchi wrote: > Le 14 sept. 2009 ? 22:15, Daniel J. Luke a ?crit : > >> On Sep 14, 2009, at 4:08 PM, vincent habchi wrote: >>>> K64 makes no difference - config.guess uses uname -p, which is >>>> i386 on >>>> K32 and K64. The fact is that arch/uname aren't the correct tools >>>> for >>>> determing the answer to this particular question. >>> >>> Granted that point, is it possible to build, or provide, a modified >>> version of uname, to be put in the tools or whatever suitable >>> directory, and that would override /usr/bin/uname with more sensible >>> data? Does it make sense? >> >> No, but it's probably possible to get configure to correctly build a >> triple by using other tools (like it has to do on solaris, for >> example). >> >> It sounds like that's what Jack has done with his updated >> configure.guess... >> >> I would tend to agree with Toby, though, that this probably isn't >> something that needs to be addressed by base/ > > Could it also be reported as a bug to Apple, to be modified in a future > SL patch? After all, if I read the manpage correctly, uname -p is > supposed to reflect the processor architecture, which is not the > architecture the kernel was build for. > > V. > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev These have been reported to Apple as radar 6707283, "arch command reports incorrect architecture without arguments", and radar 6407447 ,"uname -p, uname -m and uname -a give inaccurate results in Snow Leopard". Apple is not going to change this from their side as they view as misuse of uname by config.guess (hence the patch). Take a look at http://savannah.gnu.org/patch/?6827 where this issue was first reported. Also note that this problem disappears when you are running Snow Leopard under the 64-bit kernel. Apple wants to tether uname -p and uname -m to the code execution of the kernel and not the executables (for whatever reason) and that won't change. Jack 6707283 From howarth at bromo.med.uc.edu Mon Sep 14 14:03:40 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 17:03:40 -0400 Subject: Fwd: Interesting survey on Snow Leopard package managers In-Reply-To: <4AAEA5F9.2040008@macports.org> References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> <4AAEA5F9.2040008@macports.org> Message-ID: <20090914210340.GB29134@bromo.med.uc.edu> On Tue, Sep 15, 2009 at 06:22:17AM +1000, Joshua Root wrote: > On 2009-9-15 06:08, vincent habchi wrote: > > > >> K64 makes no difference - config.guess uses uname -p, which is i386 on > >> K32 and K64. The fact is that arch/uname aren't the correct tools for > >> determing the answer to this particular question. > > > > Granted that point, is it possible to build, or provide, a modified > > version of uname, to be put in the tools or whatever suitable directory, > > and that would override /usr/bin/uname with more sensible data? Does it > > make sense? > > On a universal i386/x86_64 system, i386 is *a* correct answer for uname > -p to be giving... > > - Josh > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev Actually it is the wrong answer because i386 is NOT the default code execution (unless you are on Core Solo or Core Duo). This whole issue is rather unfortunate in that Apple is the first vendor to ever deliver a hybrid OS that runs a 32-bit kernel but 64-bit executables. Apple decided to tether uname -m and uname -p to the kernel code execution (hence this problem goes away when running the 64-bit kernel). The whole point of the config.guess patch make sure that the reported architecture accurately reflects the native code execution and generation of the system compiler in Snow Leopard which is always x86_64 on EMT64 capable hardware. Again you really only have two valid solutions. Patching config.guess or explicitly correcting the triplets to x86_64 on the configure arguments. Jack From toby at macports.org Mon Sep 14 14:07:51 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 14 Sep 2009 14:07:51 -0700 Subject: Fwd: Interesting survey on Snow Leopard package managers In-Reply-To: <20090914210340.GB29134@bromo.med.uc.edu> References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> <4AAEA5F9.2040008@macports.org> <20090914210340.GB29134@bromo.med.uc.edu> Message-ID: <74c219d30909141407v240d50f1tdec509f50aee00f7@mail.gmail.com> On Mon, Sep 14, 2009 at 14:03, Jack Howarth wrote: > On Tue, Sep 15, 2009 at 06:22:17AM +1000, Joshua Root wrote: >> On 2009-9-15 06:08, vincent habchi wrote: >> > >> >> K64 makes no difference - config.guess uses uname -p, which is i386 on >> >> K32 and K64. The fact is that arch/uname aren't the correct tools for >> >> determing the answer to this particular question. >> > >> > Granted that point, is it possible to build, or provide, a modified >> > version of uname, to be put in the tools or whatever suitable directory, >> > and that would override /usr/bin/uname with more sensible data? Does it >> > make sense? >> >> On a universal i386/x86_64 system, i386 is *a* correct answer for uname >> -p to be giving... >> >> - Josh >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > Actually it is the wrong answer because i386 is NOT the default code > execution (unless you are on Core Solo or Core Duo). This whole issue > is rather unfortunate in that Apple is the first vendor to ever > deliver a hybrid OS that runs a 32-bit kernel but 64-bit executables. > Apple decided to tether uname -m and uname -p to the kernel code > execution (hence this problem goes away when running the 64-bit kernel). > The whole point of the config.guess patch make sure that the reported architecture > accurately reflects the native code execution and generation of the system compiler > in Snow Leopard which is always x86_64 on EMT64 capable hardware. Again > you really only have two valid solutions. Patching config.guess or > explicitly correcting the triplets to x86_64 on the configure arguments. It's not the wrong answer. Where is uname documented as returning the default compiler output or exec behavior? That's a poor assumption that config.guess has relied on. It works fine in the archaic world of machines that can only run code compiled for a single architecture. Furthermore, most of these fixes do not require patching config.guess or passing --build, there are a number of different ways to solve the issue. - Toby From toby at macports.org Mon Sep 14 14:08:41 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 14 Sep 2009 14:08:41 -0700 Subject: Fwd: Interesting survey on Snow Leopard package managers In-Reply-To: <20090914210340.GB29134@bromo.med.uc.edu> References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> <4AAEA5F9.2040008@macports.org> <20090914210340.GB29134@bromo.med.uc.edu> Message-ID: <74c219d30909141408j3322c471v99ffe24a6f12850c@mail.gmail.com> On Mon, Sep 14, 2009 at 14:03, Jack Howarth wrote: > Apple decided to tether uname -m and uname -p to the kernel code > execution (hence this problem goes away when running the 64-bit kernel). Also, as I noted in a previous email, this is not the case. 'uname -m' matches the kernel architecture, 'uname -p' is always i386. - Toby From howarth at bromo.med.uc.edu Mon Sep 14 14:16:43 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 17:16:43 -0400 Subject: Fwd: Interesting survey on Snow Leopard package managers In-Reply-To: <74c219d30909141407v240d50f1tdec509f50aee00f7@mail.gmail.com> References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> <4AAEA5F9.2040008@macports.org> <20090914210340.GB29134@bromo.med.uc.edu> <74c219d30909141407v240d50f1tdec509f50aee00f7@mail.gmail.com> Message-ID: <20090914211643.GA29433@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 02:07:51PM -0700, Toby Peterson wrote: > On Mon, Sep 14, 2009 at 14:03, Jack Howarth wrote: > > On Tue, Sep 15, 2009 at 06:22:17AM +1000, Joshua Root wrote: > >> On 2009-9-15 06:08, vincent habchi wrote: > >> > > >> >> K64 makes no difference - config.guess uses uname -p, which is i386 on > >> >> K32 and K64. The fact is that arch/uname aren't the correct tools for > >> >> determing the answer to this particular question. > >> > > >> > Granted that point, is it possible to build, or provide, a modified > >> > version of uname, to be put in the tools or whatever suitable directory, > >> > and that would override /usr/bin/uname with more sensible data? Does it > >> > make sense? > >> > >> On a universal i386/x86_64 system, i386 is *a* correct answer for uname > >> -p to be giving... > >> > >> - Josh > >> _______________________________________________ > >> macports-dev mailing list > >> macports-dev at lists.macosforge.org > >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > > Actually it is the wrong answer because i386 is NOT the default code > > execution (unless you are on Core Solo or Core Duo). This whole issue > > is rather unfortunate in that Apple is the first vendor to ever > > deliver a hybrid OS that runs a 32-bit kernel but 64-bit executables. > > Apple decided to tether uname -m and uname -p to the kernel code > > execution (hence this problem goes away when running the 64-bit kernel). > > The whole point of the config.guess patch make sure that the reported architecture > > accurately reflects the native code execution and generation of the system compiler > > in Snow Leopard which is always x86_64 on EMT64 capable hardware. Again > > you really only have two valid solutions. Patching config.guess or > > explicitly correcting the triplets to x86_64 on the configure arguments. > > It's not the wrong answer. Where is uname documented as returning the > default compiler output or exec behavior? That's a poor assumption > that config.guess has relied on. It works fine in the archaic world of > machines that can only run code compiled for a single architecture. > > Furthermore, most of these fixes do not require patching config.guess > or passing --build, there are a number of different ways to solve the > issue. > > - Toby Toby, You do realize that upstream will eventually fix this and an updated config.guess will be pulled down from upstream to all of the projects anyway. I don't see how you can say with a straight face that it is okay for config.guess to report i386 when the default code generation and execution of the default system compiler is in fact x86_64. As far as configure goes...garbage in...garbage out. It has to be feed accurate data from config.guess to make the appropriate decisions. Jack From howarth at bromo.med.uc.edu Mon Sep 14 14:23:24 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 17:23:24 -0400 Subject: Fwd: Interesting survey on Snow Leopard package managers In-Reply-To: <74c219d30909141408j3322c471v99ffe24a6f12850c@mail.gmail.com> References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> <4AAEA5F9.2040008@macports.org> <20090914210340.GB29134@bromo.med.uc.edu> <74c219d30909141408j3322c471v99ffe24a6f12850c@mail.gmail.com> Message-ID: <20090914212324.GB29433@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 02:08:41PM -0700, Toby Peterson wrote: > On Mon, Sep 14, 2009 at 14:03, Jack Howarth wrote: > > Apple decided to tether uname -m and uname -p to the kernel code > > execution (hence this problem goes away when running the 64-bit kernel). > > Also, as I noted in a previous email, this is not the case. 'uname -m' > matches the kernel architecture, 'uname -p' is always i386. > > - Toby Regardless that still doesn't get you anywhere with using uname in configure because if you are on the 32-bit kernel, which is the default in Snow Leopard workstation, uname -m or uname -p will always tell config.guess i386. I don't see the complexity here. The output of config.guess should reflect the default code generation and execution on the platform. Ben Elliston who is the maintainer of config.guess agrees with me on this (we are only working out the exact form of the patch). If you object to this, post to... http://savannah.gnu.org/patch/?6827 Jack From brad at pixilla.com Mon Sep 14 14:24:17 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 14 Sep 2009 17:24:17 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <987673B4202719002D27B14D@fitzrovia.msalexander.com> References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> <20090914181936.GA27831@bromo.med.uc.edu> <74c219d30909141130p7e4679c0p298513b5467d33e@mail.gmail.com> <20090914185830.GA28519@bromo.med.uc.edu> <987673B4202719002D27B14D@fitzrovia.msalexander.com> Message-ID: On Sep 14, 2009, at 3:54 PM, Mike Alexander wrote: > --On September 14, 2009 2:58:30 PM -0400 Jack Howarth > wrote: > >> True perhaps, but simple logic dictates that it is bad form for >> configure to think it is compiling code for a 32-bit architecture >> and then gcc to start generating 64-bit code behind its back. >> Remember >> that Apple has done something no one has ever done before...create >> an operating system that runs a 32-bit kernel but 64-bit executables. > > I have to agree with Jack on this issue. Having worked on and with > various compilers and operating systems for over 40 years I've seen > far too many problems caused by people trying to second guess what > the compiler or system thinks it should be doing. I've also had a > few problems with MacPorts caused by it's use of -arch and -m64 flags. I don't know a heck of a lot about compiling but is it possible that a build would succeed but not function properly relating to this subject? If so we don't know how many bugs there are in macports. I have been having problems with either postfix or openssl and these types of questions leave me very uneasy with production use of MacPorts. Unless the answer to my question is false :) // Brad From toby at macports.org Mon Sep 14 14:25:34 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 14 Sep 2009 14:25:34 -0700 Subject: Fwd: Interesting survey on Snow Leopard package managers In-Reply-To: <20090914211643.GA29433@bromo.med.uc.edu> References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> <4AAEA5F9.2040008@macports.org> <20090914210340.GB29134@bromo.med.uc.edu> <74c219d30909141407v240d50f1tdec509f50aee00f7@mail.gmail.com> <20090914211643.GA29433@bromo.med.uc.edu> Message-ID: <74c219d30909141425u3b85c1dcm50a1a4b25a4ab716@mail.gmail.com> On Mon, Sep 14, 2009 at 14:16, Jack Howarth wrote: > On Mon, Sep 14, 2009 at 02:07:51PM -0700, Toby Peterson wrote: >> On Mon, Sep 14, 2009 at 14:03, Jack Howarth wrote: >> > On Tue, Sep 15, 2009 at 06:22:17AM +1000, Joshua Root wrote: >> >> On 2009-9-15 06:08, vincent habchi wrote: >> >> > >> >> >> K64 makes no difference - config.guess uses uname -p, which is i386 on >> >> >> K32 and K64. The fact is that arch/uname aren't the correct tools for >> >> >> determing the answer to this particular question. >> >> > >> >> > Granted that point, is it possible to build, or provide, a modified >> >> > version of uname, to be put in the tools or whatever suitable directory, >> >> > and that would override /usr/bin/uname with more sensible data? Does it >> >> > make sense? >> >> >> >> On a universal i386/x86_64 system, i386 is *a* correct answer for uname >> >> -p to be giving... >> >> >> >> - Josh >> >> _______________________________________________ >> >> macports-dev mailing list >> >> macports-dev at lists.macosforge.org >> >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> > >> > Actually it is the wrong answer because i386 is NOT the default code >> > execution (unless you are on Core Solo or Core Duo). This whole issue >> > is rather unfortunate in that Apple is the first vendor to ever >> > deliver a hybrid OS that runs a 32-bit kernel but 64-bit executables. >> > Apple decided to tether uname -m and uname -p to the kernel code >> > execution (hence this problem goes away when running the 64-bit kernel). >> > The whole point of the config.guess patch make sure that the reported architecture >> > accurately reflects the native code execution and generation of the system compiler >> > in Snow Leopard which is always x86_64 on EMT64 capable hardware. Again >> > you really only have two valid solutions. Patching config.guess or >> > explicitly correcting the triplets to x86_64 on the configure arguments. >> >> It's not the wrong answer. Where is uname documented as returning the >> default compiler output or exec behavior? That's a poor assumption >> that config.guess has relied on. It works fine in the archaic world of >> machines that can only run code compiled for a single architecture. >> >> Furthermore, most of these fixes do not require patching config.guess >> or passing --build, there are a number of different ways to solve the >> issue. >> >> - Toby > > Toby, > ? You do realize that upstream will eventually fix this and an updated > config.guess will be pulled down from upstream to all of the projects > anyway. I don't see how you can say with a straight face that it is okay > for config.guess to report i386 when the default code generation and > execution of the default system compiler is in fact x86_64. As far as > configure goes...garbage in...garbage out. It has to be feed accurate > data from config.guess to make the appropriate decisions. I don't think you're understanding me at all. If a project updates its config.guess and things work fine with the new output, that's fine. However, changing MacPorts base would have many unexpected effects that we'd be better off avoiding. Furthermore, I can say with a straight face that's it's ok for config.guess to return whatever it wants, because it usually makes no difference. It does for some ports, but not for most. - Toby From jeremy at lavergne.gotdns.org Mon Sep 14 14:25:34 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 14 Sep 2009 17:25:34 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> <20090914181936.GA27831@bromo.med.uc.edu> <74c219d30909141130p7e4679c0p298513b5467d33e@mail.gmail.com> <20090914185830.GA28519@bromo.med.uc.edu> <987673B4202719002D27B14D@fitzrovia.msalexander.com> Message-ID: > I have been having problems with either postfix or openssl and these > types of questions leave me very uneasy with production use of > MacPorts. > Unless the answer to my question is false :) You're worried about production use of 10.6 already? From jeremy at lavergne.gotdns.org Mon Sep 14 14:28:32 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 14 Sep 2009 17:28:32 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <74c219d30909141425u3b85c1dcm50a1a4b25a4ab716@mail.gmail.com> References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> <4AAEA5F9.2040008@macports.org> <20090914210340.GB29134@bromo.med.uc.edu> <74c219d30909141407v240d50f1tdec509f50aee00f7@mail.gmail.com> <20090914211643.GA29433@bromo.med.uc.edu> <74c219d30909141425u3b85c1dcm50a1a4b25a4ab716@mail.gmail.com> Message-ID: <4F11FFB9-BB5A-44F6-A7DB-E5EE570B412D@lavergne.gotdns.org> > I don't think you're understanding me at all. If a project updates its > config.guess and things work fine with the new output, that's fine. > However, changing MacPorts base would have many unexpected effects > that we'd be better off avoiding. > > Furthermore, I can say with a straight face that's it's ok for > config.guess to return whatever it wants, because it usually makes no > difference. It does for some ports, but not for most. It sounds like the change does nothing more than allow for 64bit to be built correctly on the 32bit kernel of SL. Is that a good summary for what's going on? Also, Jack, do you have time to meet sometime? I'm over at CCHMC usually and would like to get a better understanding if I'm not reflecting it in the above summary :-) From toby at macports.org Mon Sep 14 14:30:49 2009 From: toby at macports.org (Toby Peterson) Date: Mon, 14 Sep 2009 14:30:49 -0700 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <4F11FFB9-BB5A-44F6-A7DB-E5EE570B412D@lavergne.gotdns.org> References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> <4AAEA5F9.2040008@macports.org> <20090914210340.GB29134@bromo.med.uc.edu> <74c219d30909141407v240d50f1tdec509f50aee00f7@mail.gmail.com> <20090914211643.GA29433@bromo.med.uc.edu> <74c219d30909141425u3b85c1dcm50a1a4b25a4ab716@mail.gmail.com> <4F11FFB9-BB5A-44F6-A7DB-E5EE570B412D@lavergne.gotdns.org> Message-ID: <74c219d30909141430p7638c34cqbcccf02fd5b87e33@mail.gmail.com> On Mon, Sep 14, 2009 at 14:28, Jeremy Lavergne wrote: >> I don't think you're understanding me at all. If a project updates its >> config.guess and things work fine with the new output, that's fine. >> However, changing MacPorts base would have many unexpected effects >> that we'd be better off avoiding. >> >> Furthermore, I can say with a straight face that's it's ok for >> config.guess to return whatever it wants, because it usually makes no >> difference. It does for some ports, but not for most. > > It sounds like the change does nothing more than allow for 64bit to be built > correctly on the 32bit kernel of SL. > > Is that a good summary for what's going on? For the third time, the kernel architecture has absolutely nothing to do with this, as 'uname -p' returns i386 for both K32 and K64. - Toby From howarth at bromo.med.uc.edu Mon Sep 14 14:33:14 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 17:33:14 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <74c219d30909141430p7638c34cqbcccf02fd5b87e33@mail.gmail.com> References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> <4AAEA5F9.2040008@macports.org> <20090914210340.GB29134@bromo.med.uc.edu> <74c219d30909141407v240d50f1tdec509f50aee00f7@mail.gmail.com> <20090914211643.GA29433@bromo.med.uc.edu> <74c219d30909141425u3b85c1dcm50a1a4b25a4ab716@mail.gmail.com> <4F11FFB9-BB5A-44F6-A7DB-E5EE570B412D@lavergne.gotdns.org> <74c219d30909141430p7638c34cqbcccf02fd5b87e33@mail.gmail.com> Message-ID: <20090914213314.GA29593@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 02:30:49PM -0700, Toby Peterson wrote: > On Mon, Sep 14, 2009 at 14:28, Jeremy Lavergne > wrote: > >> I don't think you're understanding me at all. If a project updates its > >> config.guess and things work fine with the new output, that's fine. > >> However, changing MacPorts base would have many unexpected effects > >> that we'd be better off avoiding. > >> > >> Furthermore, I can say with a straight face that's it's ok for > >> config.guess to return whatever it wants, because it usually makes no > >> difference. It does for some ports, but not for most. > > > > It sounds like the change does nothing more than allow for 64bit to be built > > correctly on the 32bit kernel of SL. > > > > Is that a good summary for what's going on? > > For the third time, the kernel architecture has absolutely nothing to > do with this, as 'uname -p' returns i386 for both K32 and K64. > > - Toby Exactly and the point of the config.guess patch is to decouple the guessed architecture from uname and to rely instead on the default code generation of the system compiler or on the default code execution if a system compiler isn't installed. Ben wants to make config.guess less dependent on a compiler being installed. Jack From brad at pixilla.com Mon Sep 14 14:41:32 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Mon, 14 Sep 2009 17:41:32 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> <20090914181936.GA27831@bromo.med.uc.edu> <74c219d30909141130p7e4679c0p298513b5467d33e@mail.gmail.com> <20090914185830.GA28519@bromo.med.uc.edu> <987673B4202719002D27B14D@fitzrovia.msalexander.com> Message-ID: On Sep 14, 2009, at 5:25 PM, Jeremy Lavergne wrote: >> I have been having problems with either postfix or openssl and >> these types of questions leave me very uneasy with production use >> of MacPorts. >> Unless the answer to my question is false :) > > You're worried about production use of 10.6 already? No, I'm worried that packages built on any os would be passed compile flags what were not appropriate and that the compile would complete but the executable would be flawed due to the compile. As I stated I have seen poor or sporadic performance from some ports and I would like to think that it's something in my configuration and not a bad executable. Like I said, I don't have expertise here but I have read this thread and it makes me thing there is something wrong with the MacPorts build process. Just answer me this. Regarding the arch flags and such of what this thread has become, will the build process complete? If so, then part of using MacPorts will be the ability to discover improperly compiled code and report it to maintainers. I don't know how to do this. I won't be on 10.6 until MP 1.8 (or whatever the new version is) plays well with 10.6 and even then I have a number of G5's so there. // Brad From jeremy at lavergne.gotdns.org Mon Sep 14 14:45:10 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 14 Sep 2009 17:45:10 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: References: <303c45610909140711ubad4627kb3ab60efcc3a6de2@mail.gmail.com> <20090914142257.GA21285@bromo.med.uc.edu> <74c219d30909140925n4219154j212e8d4e00e7d64@mail.gmail.com> <20090914181936.GA27831@bromo.med.uc.edu> <74c219d30909141130p7e4679c0p298513b5467d33e@mail.gmail.com> <20090914185830.GA28519@bromo.med.uc.edu> <987673B4202719002D27B14D@fitzrovia.msalexander.com> Message-ID: <65F97F19-80B7-44EE-8687-E31FCE789762@lavergne.gotdns.org> > I won't be on 10.6 until MP 1.8 (or whatever the new version is) > plays well with 10.6 and even then I have a number of G5's so there. Well everyone on the thread so far has agreed that running the 64-bit kernel results in the correct binaries being built. It seems that on 32-bit things get murky, that it's a matter of how you go about building them: one way is to use the flags that MacPorts is throwing in based on the configuration and not relying on uname, or you can rely entirely on the configure scripts that do use uname (which is technically incorrect but still provides functional though seemingly less optimized binaries). That being said, MacPorts 1.8.0 is a lot better than sitting on 1.7.1, even in 10.5 :-) From howarth at bromo.med.uc.edu Mon Sep 14 15:33:20 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 14 Sep 2009 18:33:20 -0400 Subject: Interesting survey on Snow Leopard package managers In-Reply-To: <4F11FFB9-BB5A-44F6-A7DB-E5EE570B412D@lavergne.gotdns.org> References: <18F620B8-2997-4959-9057-8B5144588EB2@macports.org> <4AAEA5F9.2040008@macports.org> <20090914210340.GB29134@bromo.med.uc.edu> <74c219d30909141407v240d50f1tdec509f50aee00f7@mail.gmail.com> <20090914211643.GA29433@bromo.med.uc.edu> <74c219d30909141425u3b85c1dcm50a1a4b25a4ab716@mail.gmail.com> <4F11FFB9-BB5A-44F6-A7DB-E5EE570B412D@lavergne.gotdns.org> Message-ID: <20090914223320.GA29942@bromo.med.uc.edu> On Mon, Sep 14, 2009 at 05:28:32PM -0400, Jeremy Lavergne wrote: >> I don't think you're understanding me at all. If a project updates its >> config.guess and things work fine with the new output, that's fine. >> However, changing MacPorts base would have many unexpected effects >> that we'd be better off avoiding. >> >> Furthermore, I can say with a straight face that's it's ok for >> config.guess to return whatever it wants, because it usually makes no >> difference. It does for some ports, but not for most. > > It sounds like the change does nothing more than allow for 64bit to be > built correctly on the 32bit kernel of SL. > > Is that a good summary for what's going on? > > Also, Jack, do you have time to meet sometime? I'm over at CCHMC > usually and would like to get a better understanding if I'm not > reflecting it in the above summary :-) Jeremy, What the config.guess patch does is decouple its output from the architecture of running kernel and depend instead on the code generation of the system compiler. My own theory on why Apple didn't make any changes to the output of uname or arch was that they were afraid some third party installers or scripts might be depending on the i386 and that would cause more breakage on Snow Leopard. In conversations with Mike Stump in Apple compiler group, he did come around to my view that a careful reading of the "arch" manpage shows that command should really reflect the default code execution on Snow Leopard. However none of this will change, so config.guess will have to adapt to a hybrid 32-bit kernel/64-bit userland which it never was faced with before. The problem with leaving the architecture reported as i386 on Snow Leopard is that configure while make changes to the generated Makefiles using the assumption at it dealing with 32-bit code generation. In a perfect world, this wouldn't be a problem and everyone would be coding with __LP64__ wrappers instead of using configure to make decisions like that but thats not always the case. Jack From howarth at bromo.med.uc.edu Tue Sep 15 06:10:55 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 09:10:55 -0400 Subject: pymol-1.2r1-1 packaging Message-ID: <20090915131055.GA5285@bromo.med.uc.edu> In case any of the other MacPorts developers are interested, I have uploaded proposed packaging for pymol-1.2r1-1 on ticket #21376. Unlike the previously proposed package on ticket #17419 which tried to use the broken configure in pymol (that creates dylibs instead of .so python modules), this packaging leverages the setup/Rules.osx-fink file and uses the .delsci makefiles throughout the pymol sources to build proper .so modules. The current packaging is fully functional although I see need to double check that the build never accesses the system X11R6 directories. I also have some additional pymol plugins that are present in my old fink pymol-py packaging that haven't been added. The pynmr plugin in particular will require the addition of a meschach matrix math package to MacPorts to build. I'll work on that later this week. Jack ps Pondering on the issue of not building against the system X11, I think it would be a really good idea if port scanned the build output for the text "/usr/X11R6" and if it is seen throws a warning in all cases (even if -d isn't used). This would probably be sufficient to alert all packagers if their Portfile and patches were pulling in the system X11 instead of the MacPorts X11. From james.applemac at gmail.com Tue Sep 15 08:40:10 2009 From: james.applemac at gmail.com (Chang James) Date: Tue, 15 Sep 2009 23:40:10 +0800 Subject: [MacPorts] #21241: net-snmp 5.4.2.1_1 Build Failed Under Mac OS X 10.6 In-Reply-To: <069.c9299b9d1963dd2b99e1983b544a66ae@macports.org> References: <060.98bd0bfaf197afb212f55b2a975c7a6c@macports.org> <069.c9299b9d1963dd2b99e1983b544a66ae@macports.org> Message-ID: Hi, I have uninstalled every package build under OS X 10.5.8 and rebuild under OS X 10.6 with xCode 3.2. It show me the following message when I run `lipo -info /opt/local/lib/libssl.dylib` Non-fat file: /opt/local/lib/libssl.dylib is architecture: x86_64 Following are the error messages: {{{ port install net-snmp +bzip2 +ksm +server Port command started with PID 423 Portfile changed since last build; discarding previous state. ---> Computing dependencies for net-snmp ---> Fetching net-snmp ---> Verifying checksum(s) for net-snmp ---> Extracting net-snmp ---> Applying patches to net-snmp ---> Configuring net-snmp ---> Building net-snmp Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_net_net-snmp/work/net-snmp-5.4.2.1" && /usr/bin/make all " returned error 2 Command output: snmpUDPDomain.c: In function 'netsnmp_sock_buffer_set': snmpUDPDomain.c:500: warning: passing argument 5 of 'getsockopt' from incompatible pointer type snmpUDPDomain.c:535: warning: passing argument 5 of 'getsockopt' from incompatible pointer type /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c snmpUDPDomain.c -o snmpUDPDomain.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c -o snmpTCPDomain.lo snmpTCPDomain.c /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c snmpTCPDomain.c -fno-common -DPIC -o .libs/snmpTCPDomain.o /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c snmpTCPDomain.c -o snmpTCPDomain.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c -o snmpUnixDomain.lo snmpUnixDomain.c /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c snmpUnixDomain.c -fno-common -DPIC -o .libs/snmpUnixDomain.o /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c snmpUnixDomain.c -o snmpUnixDomain.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c -o snmpCallbackDomain.lo snmpCallbackDomain.c /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c snmpCallbackDomain.c -fno-common -DPIC -o .libs/snmpCallbackDomain.o /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c snmpCallbackDomain.c -o snmpCallbackDomain.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c -o snmp_secmod.lo snmp_secmod.c /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c snmp_secmod.c -fno-common -DPIC -o .libs/snmp_secmod.o /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c snmp_secmod.c -o snmp_secmod.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c -o snmpusm.lo snmpusm.c /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c snmpusm.c -fno-common -DPIC -o .libs/snmpusm.o /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c snmpusm.c -o snmpusm.o >/dev/null 2>&1 /bin/sh ../libtool --mode=compile /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c -o snmpksm.lo snmpksm.c /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE -c snmpksm.c -fno-common -DPIC -o .libs/snmpksm.o snmpksm.c: In function 'ksm_rgenerate_out_msg': snmpksm.c:493: error: 'params' undeclared (first use in this function) snmpksm.c:493: error: (Each undeclared identifier is reported only once snmpksm.c:493: error: for each function it appears in.) snmpksm.c:693: error: 'krb5_enctype_array' undeclared (first use in this function) snmpksm.c: In function 'ksm_process_in_msg': snmpksm.c:1684: error: 'krb5_enctype_array' undeclared (first use in this function) make[1]: *** [snmpksm.lo] Error 1 make: *** [subdirs] Error 1 Error: Status 1 encountered during processing. ---> Executing: /opt/local/bin/port install net-snmp +bzip2 +ksm +server }}} Best Regards! James Chang 2009/9/10 MacPorts > #21241: net-snmp 5.4.2.1_1 Build Failed Under Mac OS X 10.6 > > --------------------------------------+------------------------------------- > Reporter: james.applemac@? | Owner: opendarwin.org@? > Type: defect | Status: new > Priority: Normal | Milestone: > Component: ports | Version: 1.8.0 > Keywords: | Port: net-snmp > > --------------------------------------+------------------------------------- > Changes (by toby@?): > > * priority: High => Normal > > > Comment: > > What is the output of `lipo -info /opt/local/lib/libssl.dylib` ? > > -- > Ticket URL: > MacPorts > Ports system for Mac OS > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremyhu at macports.org Tue Sep 15 11:00:50 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Tue, 15 Sep 2009 11:00:50 -0700 Subject: X11 and MacPorts In-Reply-To: <20090915141142.GA5818@bromo.med.uc.edu> References: <20090915141142.GA5818@bromo.med.uc.edu> Message-ID: <0FB01F23-E7FD-4FF8-9028-39F471938725@macports.org> On Sep 15, 2009, at 07:11, Jack Howarth wrote: > Jeremy, > FYI, I've resigned all of my fink packages and > have moved over to add those (where missing) to > MacPorts. Did you get my emails to the macports-dev > mailing list and get a chance to build the proposed > molmol packaging to reproduce the missing widgets? I've had a crazy last few weeks, so I am a bit behind on macports mail... but I'll take a look when I get a chance later. > The glw package in MacPorts is behaving normally > as tested with the old opensolar.c sample code, > however the widgets in molmol never appear either > when built as a MacPorts package or directly > against the MacPorts packages manually. Is glw linking against the correct GL (/opt/local/lib/libGL.dylib rather than OpenGL.framework)? > I am still wondering if the problem could be > some missing component of X11 which doesn't prevent > the build but effects the runtime? Have you considered > adding a virtual package to Macports that would > effect a more complete X11 installation to avoid > such problems or don't you think they could exist? It's been there since I addded the modular packages as a way for other ports to transition to the new dependencies. Some ports still have the 'port:xorg-libs' dependency and have not been updated to list the exact dependencies (feel free to fix those where you see them... I believe they were mostly "dead" ports at this point). You can also install 'xorg' which will pull in xorg-libs, xorg-apps, mesa, and xorg-server > Also what version of X11 is the MacPorts x11 packages > based on (2.3.3.2 or 2.4.0)? They're the latest versions available of the individual modules... so at this point post 2.4.0. I pulled in more "beta/rc" packages into what will be 2.4.1-alpha1 since I am less concerned about stability with the alpha packages than with what is in MacPorts. --Jeremy From howarth at bromo.med.uc.edu Tue Sep 15 14:23:00 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 17:23:00 -0400 Subject: configure.build_arch Message-ID: <20090915212300.GA12997@bromo.med.uc.edu> Reading through the commits on the configure.build_arch feature in port, I am rather surprised that invoking that doesn't also set the triplets for configure as well as passing the -m32 or -m64 compiler flags. Wouldn't you at least want to set --target= to the appropriate value so that configure understood what architecture it was going to build for? I suppose such a change might be an option to patching config.guess for those Portfiles that use configure.build_arch. This would make sure that configure was given --target=x86_64-apple-darwin9/10 when -m64 (or -arch x86_64?) was passed through the invoking configure.build_arch. Jack From toby at macports.org Tue Sep 15 14:43:29 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 15 Sep 2009 14:43:29 -0700 Subject: configure.build_arch In-Reply-To: <20090915212300.GA12997@bromo.med.uc.edu> References: <20090915212300.GA12997@bromo.med.uc.edu> Message-ID: <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> On Tue, Sep 15, 2009 at 14:23, Jack Howarth wrote: > ? Reading through the commits on the configure.build_arch feature > in port, I am rather surprised that invoking that doesn't also > set the triplets for configure as well as passing the -m32 or > -m64 compiler flags. It does pass -m32/-m64 if the configure.compiler setting refers to a compiler that doesn't support -arch flags. > Wouldn't you at least want to set > --target= to the appropriate value so that configure understood > what architecture it was going to build for? Passing --target doesn't make any sense, as we are not cross-compiling. - Toby From howarth at bromo.med.uc.edu Tue Sep 15 15:43:58 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 18:43:58 -0400 Subject: configure.build_arch In-Reply-To: <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> References: <20090915212300.GA12997@bromo.med.uc.edu> <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> Message-ID: <20090915224358.GA13401@bromo.med.uc.edu> On Tue, Sep 15, 2009 at 02:43:29PM -0700, Toby Peterson wrote: > On Tue, Sep 15, 2009 at 14:23, Jack Howarth wrote: > > ? Reading through the commits on the configure.build_arch feature > > in port, I am rather surprised that invoking that doesn't also > > set the triplets for configure as well as passing the -m32 or > > -m64 compiler flags. > > It does pass -m32/-m64 if the configure.compiler setting refers to a > compiler that doesn't support -arch flags. > > > Wouldn't you at least want to set > > --target= to the appropriate value so that configure understood > > what architecture it was going to build for? > > Passing --target doesn't make any sense, as we are not cross-compiling. > > - Toby The last statement would be true if the current config.guess weren't reporting the wrong architecture on EMT64-capable processors on 10.6. I assume invoking... configure.build_arch x86_64 sets the CFLAGS to -m64, right. So here we have the same issue all over again. The configure execution reports back i386-apple-darwin10 (even though the compiler is now generating code with -m64). Configure makes decisions based on its understanding that the target architecture is actually 32-bit while the compiler actually is generating 64-bit code behind its back. This isn't rocket science. You can't go around changing the code generation behind configure's back like this. Consider the text at... http://www.gnu.org/prep/standards/html_node/Configuration.html which states... The target type normally defaults to the host type. Programs for which cross-operation is not meaningful need not accept the ?--target? option, because configuring an entire operating system for cross-operation is not a meaningful operation. Now what you say would normally be true but as 10.6 is a hybrid OS so the first clause is NOT true. The target type for -m64 code (x86_64-apple-darwin10) is not the same as the *reported* host type (i386-apple-darwin10). You have to consider that configure is free to make decisions about setting up the Makefiles based on its understanding (without additional options like --target=) that the host type (i386-apple-darwin10) is the operative target (which it isn't when the compiler is generating x86_64 code). I guess I can go upstream and try to find one of the maintainers of autoconf to provide an authorative clarification from upstream for the group here. Jack From toby at macports.org Tue Sep 15 16:01:43 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 15 Sep 2009 16:01:43 -0700 Subject: configure.build_arch In-Reply-To: <20090915224358.GA13401@bromo.med.uc.edu> References: <20090915212300.GA12997@bromo.med.uc.edu> <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> <20090915224358.GA13401@bromo.med.uc.edu> Message-ID: <74c219d30909151601y6e7f351dxbed5cf6af2ca4a9e@mail.gmail.com> On Tue, Sep 15, 2009 at 15:43, Jack Howarth wrote: > On Tue, Sep 15, 2009 at 02:43:29PM -0700, Toby Peterson wrote: >> On Tue, Sep 15, 2009 at 14:23, Jack Howarth wrote: >> > ? Reading through the commits on the configure.build_arch feature >> > in port, I am rather surprised that invoking that doesn't also >> > set the triplets for configure as well as passing the -m32 or >> > -m64 compiler flags. >> >> It does pass -m32/-m64 if the configure.compiler setting refers to a >> compiler that doesn't support -arch flags. >> >> > Wouldn't you at least want to set >> > --target= to the appropriate value so that configure understood >> > what architecture it was going to build for? >> >> Passing --target doesn't make any sense, as we are not cross-compiling. >> >> - Toby > > The last statement would be true if the current config.guess weren't > reporting the wrong architecture on EMT64-capable processors on 10.6. > I assume invoking... > > configure.build_arch x86_64 > > sets the CFLAGS to -m64, right. So here we have the same issue all over > again. The configure execution reports back i386-apple-darwin10 (even > though the compiler is now generating code with -m64). Configure makes > decisions based on its understanding that the target architecture is > actually 32-bit while the compiler actually is generating 64-bit code behind > its back. This isn't rocket science. You can't go around changing the > code generation behind configure's back like this. Consider the text > at... > > http://www.gnu.org/prep/standards/html_node/Configuration.html > > which states... > > The target type normally defaults to the host type. Programs for which cross-operation is not meaningful need not accept the ?--target? option, because configuring an entire operating system for cross-operation is not a meaningful operation. > > Now what you say would normally be true but as 10.6 is a hybrid OS so > the first clause is NOT true. The target type for -m64 code (x86_64-apple-darwin10) > is not the same as the *reported* host type (i386-apple-darwin10). You > have to consider that configure is free to make decisions about setting up the > Makefiles based on its understanding (without additional options like > --target=) that the host type (i386-apple-darwin10) is the operative > target (which it isn't when the compiler is generating x86_64 code). > ?I guess I can go upstream and try to find one of the maintainers of autoconf > to provide an authorative clarification from upstream for the group here. For the few ports that actually care, only --build makes any sense. We don't support cross-compiling, and very few configure scripts get it right anyway. Anyway, the current approach is mostly designed around keeping things working in the future. Universal building currently configures with multiple -arch flags set, and this is not going to change. The main consequences of this are that configure's detected architecture is fairly irrelevant, and that we have to work around configure results anyway. Not much we can do about this, configure just isn't well-suited to deal with the modern problems of multiple architectures, SDKs, etc. In other words, feel free to hack the ports as needed - just keep in mind that "fixing" config.guess is hardly a perfect solution (especially for universal building), and that MacPorts base is not going to be passing these flags to configure. - Toby From howarth at bromo.med.uc.edu Tue Sep 15 16:20:20 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 19:20:20 -0400 Subject: request for configure clarifications on darwin10 Message-ID: <20090915232020.GA13527@bromo.med.uc.edu> Could we please get an expert opinion on the proper approach for handling the darwin10 targets with configure. As darwin10 is a hybrid OS which runs a 32-bit kernel but executes 64-bit binaries on EMT64 capable hardware, the reported architecture returned by the current config.guess can be in error (reporting i386-apple-darwin10 while the system compiler, gcc-4.2, is executing and generating x86_64 code). Ben Elliston is currently evaluating a proposed patch I sent to solve this issue... --- config.guess.orig 2009-09-12 20:13:05.000000000 -0400 +++ config.guess 2009-09-12 20:14:07.000000000 -0400 @@ -1259,6 +1259,24 @@ *:Darwin:*:*) UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown case $UNAME_PROCESSOR in + i386) + eval $set_cc_for_build + if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then + sed 's/^ //' << EOF >$dummy.c + #if defined(__LP64__) + main() + { + } + #endif +EOF + if test `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep -c main` = 1 ; then + UNAME_PROCESSOR=x86_64 + fi + else + if sysctl -a | grep -c hw.cpu64bit_capable>/dev/null 2>&1 ; then + UNAME_PROCESSOR=x86_64 + fi + fi ;; unknown) UNAME_PROCESSOR=powerpc ;; esac echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE} ...which tests the compiler code generation if one is present and otherwise checks the default code execution with sysctl. In the meanwhile, projects like MacPorts are currently trying to deal with these issues. There seems to be some major confusion about what is acceptable to do with configure in this case. Specifically the MacPorts developers seem to believe that the cross-compilation rules don't apply in this situation and that they are free to leave configure using the default triplets for --host/--build/--target as i386-apple-darwin10 while setting the CFLAGS to -m64 behind configure's back. My reading of the line... The target type normally defaults to the host type. Programs for which cross-operation is not meaningful need not accept the ?--target? option, because configuring an entire operating system for cross-operation is not a meaningful operation. at http://www.gnu.org/prep/standards/html_node/Configuration.html seems to differ from their's. I would argue that since darwin10 is a hybrid OS where the reported architecture from uname -p and uname -m is always i386 (when the 32-bit kernel is used) that this rule doesn't apply since the compiler is in fact executing and generating x86_64 code and thus the actual host and target aren't identcal (at least with the current config.guess). Am I correct to say that it is wrong to change the architecture of code generated with CFLAGS to x86_64 when configure is not being given --target=x86_64-apple-darwin10? I would have thought not passing --target would be a bad thing since configure will believe it operating with --host/--build/--target defaulted to the i386-apple-darwin10 as reported by config.guess while the compiler is in fact generating x86_64. Am I correct in saying that in such a case, --target=x86_64-apple-darwin10 must be passed (unless a patched config.guess is used to base the reported architecture on the default compiler code execution/generation and not the kernel architecture)? Thanks in advance for any clarifications on this issue which is causing much confusion for darwin10 developers. Jack ps Isn't darwin10 the very first hybrid OS which the configure machinary has been faced with? I am unaware of any other operating systems that ever differed the architecture of the kernel and the default code execution/generation of the default system compiler. Unfortunately both uname and arch will report i386 on darwin10 on EMT64 capable hardware. Only booting the 64-bit kernel returns coherency to the situation with uname and arch reporting x86_64. From toby at macports.org Tue Sep 15 16:26:36 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 15 Sep 2009 16:26:36 -0700 Subject: request for configure clarifications on darwin10 In-Reply-To: <20090915232020.GA13527@bromo.med.uc.edu> References: <20090915232020.GA13527@bromo.med.uc.edu> Message-ID: <74c219d30909151626h427c54e4paceb4c178379fc73@mail.gmail.com> On Tue, Sep 15, 2009 at 16:20, Jack Howarth wrote: > Only booting the 64-bit kernel returns > coherency to the situation with uname and arch reporting x86_64. This is not true. Jack, I've corrected you on this several times now. The only thing that changes on K64 is "uname -m", which config.guess does not use. The output of "arch" and "uname -p" is i386 regardless. - Toby From toby at macports.org Tue Sep 15 16:33:02 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 15 Sep 2009 16:33:02 -0700 Subject: request for configure clarifications on darwin10 In-Reply-To: <20090915232020.GA13527@bromo.med.uc.edu> References: <20090915232020.GA13527@bromo.med.uc.edu> Message-ID: <74c219d30909151633n5d5a955ep9f60701c78c92a30@mail.gmail.com> Removing autoconf from cc for this reply... On Tue, Sep 15, 2009 at 16:20, Jack Howarth wrote: > ? ?Could we please get an expert opinion on the proper > approach for handling the darwin10 targets with configure. > As darwin10 is a hybrid OS which runs a 32-bit kernel but > executes 64-bit binaries on EMT64 capable hardware, the reported > architecture returned by the current config.guess can > be in error (reporting i386-apple-darwin10 while the > system compiler, gcc-4.2, is executing and generating > x86_64 code). Ben Elliston is currently evaluating a > proposed patch I sent to solve this issue... > > --- config.guess.orig ? 2009-09-12 20:13:05.000000000 -0400 > +++ config.guess ? ? ? ?2009-09-12 20:14:07.000000000 -0400 > @@ -1259,6 +1259,24 @@ > ? ? *:Darwin:*:*) > ? ? ? ?UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown > ? ? ? ?case $UNAME_PROCESSOR in > + ? ? ? ? ? i386) > + ? ? ? ? ? ? ? eval $set_cc_for_build > + ? ? ? ? ? ? ? if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then > + ? ? ? ? ? ? ? ? sed 's/^ ? ? ? ? ? ? ? ?//' << EOF >$dummy.c > + ? ? ? ? ? ? ? ? #if defined(__LP64__) > + ? ? ? ? ? ? ? ? main() > + ? ? ? ? ? ? ? ? { > + ? ? ? ? ? ? ? ? } > + ? ? ? ? ? ? ? ? #endif > +EOF > + ? ? ? ? ? ? ? ? if test `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep -c main` = 1 ; then > + ? ? ? ? ? ? ? ? ? ? UNAME_PROCESSOR=x86_64 > + ? ? ? ? ? ? ? ? fi > + ? ? ? ? ? ? ? else > + ? ? ? ? ? ? ? ? if sysctl -a | grep -c hw.cpu64bit_capable>/dev/null 2>&1 ; then > + ? ? ? ? ? ? ? ? ? UNAME_PROCESSOR=x86_64 > + ? ? ? ? ? ? ? ? fi > + ? ? ? ? ? ? ? fi ;; > ? ? ? ? ? ?unknown) UNAME_PROCESSOR=powerpc ;; > ? ? ? ?esac > ? ? ? ?echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE} > > ...which tests the compiler code generation if one is present and > otherwise checks the default code execution with sysctl. Patch feedback: (1) Wouldn't it be easier to grep the output of "$CC -E -dM -xc /dev/null" ? (2) sysctl check is wrong, as that sysctl is exported regardless. I suggest checking the output of "sysctl -n hw.cpu64bit_capable", it'll be 0 or 1. > ? In the meanwhile, projects like MacPorts are currently trying to > deal with these issues. There seems to be some major confusion about > what is acceptable to do with configure in this case. Specifically > the MacPorts developers seem to believe that the cross-compilation > rules don't apply in this situation and that they are free to leave > configure using the default triplets for --host/--build/--target > as i386-apple-darwin10 while setting the CFLAGS to -m64 behind configure's > back. My reading of the line... Cross-compilation "rules" don't apply because we aren't cross-compiling. And, as I mentioned in my previous email, multiple arch flags render the detected architecture irrelevant - we have to work around the fact that configure scripts haven't adapted to modern systems. This is why "fixing" config.guess really doesn't help anything. > Only booting the 64-bit kernel returns > coherency to the situation with uname and arch reporting x86_64. And I'll reiterate in case you still haven't figured it out... this is *not* true. - Toby From howarth at bromo.med.uc.edu Tue Sep 15 16:34:17 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 19:34:17 -0400 Subject: request for configure clarifications on darwin10 In-Reply-To: <74c219d30909151626h427c54e4paceb4c178379fc73@mail.gmail.com> References: <20090915232020.GA13527@bromo.med.uc.edu> <74c219d30909151626h427c54e4paceb4c178379fc73@mail.gmail.com> Message-ID: <20090915233417.GA13705@bromo.med.uc.edu> On Tue, Sep 15, 2009 at 04:26:36PM -0700, Toby Peterson wrote: > On Tue, Sep 15, 2009 at 16:20, Jack Howarth wrote: > > Only booting the 64-bit kernel returns > > coherency to the situation with uname and arch reporting x86_64. > > This is not true. Jack, I've corrected you on this several times now. > The only thing that changes on K64 is "uname -m", which config.guess > does not use. The output of "arch" and "uname -p" is i386 regardless. > > - Toby Toby, However you are assuming that configure can be passed -m64 or -arch x86_64 on the CFLAGS while config.guess is reporting i386-apple-darwin10 back to configure and still not be required to pass --target=x86_64-apple-darwin10 to configure, correct? In my reading of the configure documentation, the normal cross compilation rules would not apply here since the default triplet detected (i386-apple-darwin10) differs from the code generation being invoked (x86_64). Configure is free to make decisions based on the triplet reported by config.guess that could impact the code being compiled (selecting files with hard coded amd64 assembly, etc). In any case, we should be a clear answer from upstream shortly. Jack From toby at macports.org Tue Sep 15 16:39:29 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 15 Sep 2009 16:39:29 -0700 Subject: request for configure clarifications on darwin10 In-Reply-To: <20090915233417.GA13705@bromo.med.uc.edu> References: <20090915232020.GA13527@bromo.med.uc.edu> <74c219d30909151626h427c54e4paceb4c178379fc73@mail.gmail.com> <20090915233417.GA13705@bromo.med.uc.edu> Message-ID: <74c219d30909151639k2f520d15m5541505e9f041a29@mail.gmail.com> On Tue, Sep 15, 2009 at 16:34, Jack Howarth wrote: > On Tue, Sep 15, 2009 at 04:26:36PM -0700, Toby Peterson wrote: >> On Tue, Sep 15, 2009 at 16:20, Jack Howarth wrote: >> > Only booting the 64-bit kernel returns >> > coherency to the situation with uname and arch reporting x86_64. >> >> This is not true. Jack, I've corrected you on this several times now. >> The only thing that changes on K64 is "uname -m", which config.guess >> does not use. The output of "arch" and "uname -p" is i386 regardless. >> >> - Toby > > ? However you are assuming that configure can be passed -m64 or > -arch x86_64 on the CFLAGS while config.guess is reporting > i386-apple-darwin10 back to configure and still not be required > to pass --target=x86_64-apple-darwin10 to configure, correct? > In my reading of the configure documentation, the normal cross > compilation rules would not apply here since the default triplet > detected (i386-apple-darwin10) differs from the code generation > being invoked (x86_64). Configure is free to make decisions based > on the triplet reported by config.guess that could impact the > code being compiled (selecting files with hard coded amd64 > assembly, etc). In any case, we should be a clear answer from > upstream shortly. [removing autoconf from cc, don't see how it's relevant to that list] We've been dealing with configure's "incorrect" architecture detection for years (universal building, multiple arch flags). I don't see how this is any different. - Toby From howarth at bromo.med.uc.edu Tue Sep 15 16:42:14 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 19:42:14 -0400 Subject: request for configure clarifications on darwin10 In-Reply-To: <74c219d30909151626h427c54e4paceb4c178379fc73@mail.gmail.com> References: <20090915232020.GA13527@bromo.med.uc.edu> <74c219d30909151626h427c54e4paceb4c178379fc73@mail.gmail.com> Message-ID: <20090915234214.GA13639@bromo.med.uc.edu> On Tue, Sep 15, 2009 at 04:26:36PM -0700, Toby Peterson wrote: > On Tue, Sep 15, 2009 at 16:20, Jack Howarth wrote: > > Only booting the 64-bit kernel returns > > coherency to the situation with uname and arch reporting x86_64. > > This is not true. Jack, I've corrected you on this several times now. > The only thing that changes on K64 is "uname -m", which config.guess > does not use. The output of "arch" and "uname -p" is i386 regardless. > > - Toby Toby, Okay. I mispoke on that issue but it is orthogonal to the solution. On Darwin10, under the 32-bit kernel (which is the default), both uname -p and uname -m reports i386 so a patch is necessary to return coherency between the detected host and the actual target code generated by the system compiler. Jack From howarth at bromo.med.uc.edu Tue Sep 15 16:51:26 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 19:51:26 -0400 Subject: request for configure clarifications on darwin10 In-Reply-To: <74c219d30909151633n5d5a955ep9f60701c78c92a30@mail.gmail.com> References: <20090915232020.GA13527@bromo.med.uc.edu> <74c219d30909151633n5d5a955ep9f60701c78c92a30@mail.gmail.com> Message-ID: <20090915235126.GA13810@bromo.med.uc.edu> On Tue, Sep 15, 2009 at 04:33:02PM -0700, Toby Peterson wrote: > > Patch feedback: > > (1) Wouldn't it be easier to grep the output of "$CC -E -dM -xc /dev/null" ? Yes, that is what the gcc compiler developers wanted but Ben Elliston objects since the -dM option is a gcc extension and wouldn't function on all c compilers. > (2) sysctl check is wrong, as that sysctl is exported regardless. I > suggest checking the output of "sysctl -n hw.cpu64bit_capable", it'll > be 0 or 1. > Sorry about that one, I grabbed the wrong copy of the patch for that section. Jack From howarth at bromo.med.uc.edu Tue Sep 15 17:01:28 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 20:01:28 -0400 Subject: request for configure clarifications on darwin10 In-Reply-To: <74c219d30909151633n5d5a955ep9f60701c78c92a30@mail.gmail.com> References: <20090915232020.GA13527@bromo.med.uc.edu> <74c219d30909151633n5d5a955ep9f60701c78c92a30@mail.gmail.com> Message-ID: <20090916000128.GA13899@bromo.med.uc.edu> On Tue, Sep 15, 2009 at 04:33:02PM -0700, Toby Peterson wrote: > > (1) Wouldn't it be easier to grep the output of "$CC -E -dM -xc /dev/null" ? > (2) sysctl check is wrong, as that sysctl is exported regardless. I > suggest checking the output of "sysctl -n hw.cpu64bit_capable", it'll > be 0 or 1. > Toby, As I said, my mistake. This was the original copy... http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00331.html before I started working with Ben to merge it into the current cvs config.guess file. I initially didn't add back in the systcl test until I remembered that Ben was the person who asked for it in the first place. I munged that when I added it back (thanks for catching that). Jack From mta at umich.edu Tue Sep 15 17:05:27 2009 From: mta at umich.edu (Mike Alexander) Date: Tue, 15 Sep 2009 20:05:27 -0400 Subject: configure.build_arch In-Reply-To: <74c219d30909151601y6e7f351dxbed5cf6af2ca4a9e@mail.gmail.com> References: <20090915212300.GA12997@bromo.med.uc.edu> <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> <20090915224358.GA13401@bromo.med.uc.edu> <74c219d30909151601y6e7f351dxbed5cf6af2ca4a9e@mail.gmail.com> Message-ID: --On September 15, 2009 4:01:43 PM -0700 Toby Peterson wrote: > For the few ports that actually care, only --build makes any sense. We > don't support cross-compiling, and very few configure scripts get it > right anyway. I think Jack's point is that in 10.6 on a 32 bit kernel you effectively are cross-compiling whether you want to or not. You're building 64 bit binaries on a system that claims to be a 32 bit system. That seems like cross-compiling to me. Am I misunderstanding something? Mike From howarth at bromo.med.uc.edu Tue Sep 15 17:10:32 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 20:10:32 -0400 Subject: request for configure clarifications on darwin10 In-Reply-To: <20090915232020.GA13527@bromo.med.uc.edu> References: <20090915232020.GA13527@bromo.med.uc.edu> Message-ID: <20090916001032.GB13899@bromo.med.uc.edu> On Tue, Sep 15, 2009 at 07:20:20PM -0400, Jack Howarth wrote: > + else > + if sysctl -a | grep -c hw.cpu64bit_capable>/dev/null 2>&1 ; then > + UNAME_PROCESSOR=x86_64 Please execuse the error in the previously posted patch...I grabbed an older copy. The correct line there is... if test `sysctl -n hw.cpu64bit_capable | grep -c 1` = 1 ; then My apologies. Jack From toby at macports.org Tue Sep 15 17:18:32 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 15 Sep 2009 17:18:32 -0700 Subject: configure.build_arch In-Reply-To: References: <20090915212300.GA12997@bromo.med.uc.edu> <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> <20090915224358.GA13401@bromo.med.uc.edu> <74c219d30909151601y6e7f351dxbed5cf6af2ca4a9e@mail.gmail.com> Message-ID: <74c219d30909151718s4947d973x7b846c04b9c89dd4@mail.gmail.com> On Tue, Sep 15, 2009 at 17:05, Mike Alexander wrote: > --On September 15, 2009 4:01:43 PM -0700 Toby Peterson > wrote: > >> For the few ports that actually care, only --build makes any sense. We >> don't support cross-compiling, and very few configure scripts get it >> right anyway. > > I think Jack's point is that in 10.6 on a 32 bit kernel you effectively are > cross-compiling whether you want to or not. ?You're building 64 bit binaries > on a system that claims to be a 32 bit system. ?That seems like > cross-compiling to me. ?Am I misunderstanding something? As I've noted numerous times now, config.guess still reports i386 on K64, so this perceived problem exists regardless of the kernel architecture. - Toby From mta at umich.edu Tue Sep 15 17:21:20 2009 From: mta at umich.edu (Mike Alexander) Date: Tue, 15 Sep 2009 20:21:20 -0400 Subject: configure.build_arch In-Reply-To: <74c219d30909151718s4947d973x7b846c04b9c89dd4@mail.gmail.com> References: <20090915212300.GA12997@bromo.med.uc.edu> <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> <20090915224358.GA13401@bromo.med.uc.edu> <74c219d30909151601y6e7f351dxbed5cf6af2ca4a9e@mail.gmail.com> <74c219d30909151718s4947d973x7b846c04b9c89dd4@mail.gmail.com> Message-ID: <258A909D3301210200DED148@mistral.private> --On September 15, 2009 5:18:32 PM -0700 Toby Peterson wrote: > On Tue, Sep 15, 2009 at 17:05, Mike Alexander wrote: >> --On September 15, 2009 4:01:43 PM -0700 Toby Peterson >> wrote: >> >>> For the few ports that actually care, only --build makes any sense. >>> We don't support cross-compiling, and very few configure scripts >>> get it right anyway. >> >> I think Jack's point is that in 10.6 on a 32 bit kernel you >> effectively are cross-compiling whether you want to or not. ?You're >> building 64 bit binaries on a system that claims to be a 32 bit >> system. ?That seems like cross-compiling to me. ?Am I >> misunderstanding something? > > As I've noted numerous times now, config.guess still reports i386 on > K64, so this perceived problem exists regardless of the kernel > architecture. Ok, that just seems to make the problem worse. Even after switching to the 64 bit kernel you're still cross-compiling, right? Mike From howarth at bromo.med.uc.edu Tue Sep 15 17:25:26 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 20:25:26 -0400 Subject: configure.build_arch In-Reply-To: <74c219d30909151718s4947d973x7b846c04b9c89dd4@mail.gmail.com> References: <20090915212300.GA12997@bromo.med.uc.edu> <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> <20090915224358.GA13401@bromo.med.uc.edu> <74c219d30909151601y6e7f351dxbed5cf6af2ca4a9e@mail.gmail.com> <74c219d30909151718s4947d973x7b846c04b9c89dd4@mail.gmail.com> Message-ID: <20090916002526.GA14043@bromo.med.uc.edu> On Tue, Sep 15, 2009 at 05:18:32PM -0700, Toby Peterson wrote: > On Tue, Sep 15, 2009 at 17:05, Mike Alexander wrote: > > --On September 15, 2009 4:01:43 PM -0700 Toby Peterson > > wrote: > > > >> For the few ports that actually care, only --build makes any sense. We > >> don't support cross-compiling, and very few configure scripts get it > >> right anyway. > > > > I think Jack's point is that in 10.6 on a 32 bit kernel you effectively are > > cross-compiling whether you want to or not. ?You're building 64 bit binaries > > on a system that claims to be a 32 bit system. ?That seems like > > cross-compiling to me. ?Am I misunderstanding something? > > As I've noted numerous times now, config.guess still reports i386 on > K64, so this perceived problem exists regardless of the kernel > architecture. > > - Toby Toby, As I already admitted, I was in error about uname -p reporting x86_64 on the 64-bit kernel. However that is completely orthogonal to the issue of "configure.build_arch x86_64" passing -m64 on the CFLAGS while neglecting to clue in configure that "uname -p" is wrong by passing "--target=x86_64-apple-darwin10" to it. You still have the situation of configure believing the host is behaving as a 32-bit system while actually the compiler is generating 64-bit code. You are missing the forest for the trees here. Jack From toby at macports.org Tue Sep 15 17:25:56 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 15 Sep 2009 17:25:56 -0700 Subject: configure.build_arch In-Reply-To: <258A909D3301210200DED148@mistral.private> References: <20090915212300.GA12997@bromo.med.uc.edu> <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> <20090915224358.GA13401@bromo.med.uc.edu> <74c219d30909151601y6e7f351dxbed5cf6af2ca4a9e@mail.gmail.com> <74c219d30909151718s4947d973x7b846c04b9c89dd4@mail.gmail.com> <258A909D3301210200DED148@mistral.private> Message-ID: <74c219d30909151725v61f9c271s267e8ccd60aae9af@mail.gmail.com> On Tue, Sep 15, 2009 at 17:21, Mike Alexander wrote: > --On September 15, 2009 5:18:32 PM -0700 Toby Peterson > wrote: > >> On Tue, Sep 15, 2009 at 17:05, Mike Alexander wrote: >>> >>> --On September 15, 2009 4:01:43 PM -0700 Toby Peterson >>> wrote: >>> >>>> For the few ports that actually care, only --build makes any sense. >>>> We don't support cross-compiling, and very few configure scripts >>>> get it right anyway. >>> >>> I think Jack's point is that in 10.6 on a 32 bit kernel you >>> effectively are cross-compiling whether you want to or not. ?You're >>> building 64 bit binaries on a system that claims to be a 32 bit >>> system. ?That seems like cross-compiling to me. ?Am I >>> misunderstanding something? >> >> As I've noted numerous times now, config.guess still reports i386 on >> K64, so this perceived problem exists regardless of the kernel >> architecture. > > Ok, that just seems to make the problem worse. ?Even after switching to the > 64 bit kernel you're still cross-compiling, right? No. From configure's perspective, cross-compiling means building for an architecture that your build system can't run. A 64-bit Snow Leopard machine can run x86_64, i386, and ppc (with Rosetta). Of course, if you actually are cross-compiling then the vast majority of configure scripts don't work, so you'll need to hack things anyway. This is why I'm saying that "fixing" the output of config.guess doesn't really have any practical benefit (for most ports). - Toby From toby at macports.org Tue Sep 15 17:28:45 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 15 Sep 2009 17:28:45 -0700 Subject: configure.build_arch In-Reply-To: <20090916002526.GA14043@bromo.med.uc.edu> References: <20090915212300.GA12997@bromo.med.uc.edu> <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> <20090915224358.GA13401@bromo.med.uc.edu> <74c219d30909151601y6e7f351dxbed5cf6af2ca4a9e@mail.gmail.com> <74c219d30909151718s4947d973x7b846c04b9c89dd4@mail.gmail.com> <20090916002526.GA14043@bromo.med.uc.edu> Message-ID: <74c219d30909151728n462ef019ic6f8f0a28f4f015b@mail.gmail.com> On Tue, Sep 15, 2009 at 17:25, Jack Howarth wrote: > On Tue, Sep 15, 2009 at 05:18:32PM -0700, Toby Peterson wrote: >> On Tue, Sep 15, 2009 at 17:05, Mike Alexander wrote: >> > --On September 15, 2009 4:01:43 PM -0700 Toby Peterson >> > wrote: >> > >> >> For the few ports that actually care, only --build makes any sense. We >> >> don't support cross-compiling, and very few configure scripts get it >> >> right anyway. >> > >> > I think Jack's point is that in 10.6 on a 32 bit kernel you effectively are >> > cross-compiling whether you want to or not. ?You're building 64 bit binaries >> > on a system that claims to be a 32 bit system. ?That seems like >> > cross-compiling to me. ?Am I misunderstanding something? >> >> As I've noted numerous times now, config.guess still reports i386 on >> K64, so this perceived problem exists regardless of the kernel >> architecture. >> >> - Toby > > ? As I already admitted, I was in error about uname -p reporting x86_64 > on the 64-bit kernel. However that is completely orthogonal to the issue > of "configure.build_arch x86_64" passing -m64 on the CFLAGS while neglecting > to clue in configure that "uname -p" is wrong by passing "--target=x86_64-apple-darwin10" > to it. You still have the situation of configure believing the host is behaving > as a 32-bit system while actually the compiler is generating 64-bit code. > You are missing the forest for the trees here. To continue the somewhat appropriate metaphor, you're missing the trees for the forest. The vast forest of ports couldn't care less what config.guess says, because we're either building with multiple arch flags (where we have to work around the inadequacies of autotools), or simply because the detected architecture has no actual effect on the build. Fix the lonely trees where the detected architecture affects things, but stop trying to burn down the entire forest just to keep a few sickly trees alive. - Toby From howarth at bromo.med.uc.edu Tue Sep 15 17:35:47 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 20:35:47 -0400 Subject: configure.build_arch In-Reply-To: <258A909D3301210200DED148@mistral.private> References: <20090915212300.GA12997@bromo.med.uc.edu> <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> <20090915224358.GA13401@bromo.med.uc.edu> <74c219d30909151601y6e7f351dxbed5cf6af2ca4a9e@mail.gmail.com> <74c219d30909151718s4947d973x7b846c04b9c89dd4@mail.gmail.com> <258A909D3301210200DED148@mistral.private> Message-ID: <20090916003546.GB14043@bromo.med.uc.edu> On Tue, Sep 15, 2009 at 08:21:20PM -0400, Mike Alexander wrote: > --On September 15, 2009 5:18:32 PM -0700 Toby Peterson > wrote: > >> On Tue, Sep 15, 2009 at 17:05, Mike Alexander wrote: >>> --On September 15, 2009 4:01:43 PM -0700 Toby Peterson >>> wrote: >>> >>>> For the few ports that actually care, only --build makes any sense. >>>> We don't support cross-compiling, and very few configure scripts >>>> get it right anyway. >>> >>> I think Jack's point is that in 10.6 on a 32 bit kernel you >>> effectively are cross-compiling whether you want to or not. ?You're >>> building 64 bit binaries on a system that claims to be a 32 bit >>> system. ?That seems like cross-compiling to me. ?Am I >>> misunderstanding something? >> >> As I've noted numerous times now, config.guess still reports i386 on >> K64, so this perceived problem exists regardless of the kernel >> architecture. > > Ok, that just seems to make the problem worse. Even after switching to > the 64 bit kernel you're still cross-compiling, right? > > Mike Mike, Yes. I reported this issue on radar several times during the Snow Leopard development but it was never addressed. The solution (which Ben Elliston who is the config.guess maintainer agrees with) is to decouple the config.guess result on i386 darwin from the kernel and to use the code generation of the compiler or the code execution in the absence of a compiler. However even when config.guess is fixed it will take a long time for all projects to update to a fixed config.guess. In the meanwhile we have to be very careful to make sure that configure is clued into the correct architecture. In the case of the configure.build-arch, the fix is obvious and trivial if 'configure.build-arch x86_64' is used "--target=x86_64-apple-darwin${os.major}" needs to be added to the configure arguments by configure.build-arch as well. Jack From howarth at bromo.med.uc.edu Tue Sep 15 17:40:39 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 20:40:39 -0400 Subject: configure.build_arch In-Reply-To: <74c219d30909151725v61f9c271s267e8ccd60aae9af@mail.gmail.com> References: <20090915212300.GA12997@bromo.med.uc.edu> <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> <20090915224358.GA13401@bromo.med.uc.edu> <74c219d30909151601y6e7f351dxbed5cf6af2ca4a9e@mail.gmail.com> <74c219d30909151718s4947d973x7b846c04b9c89dd4@mail.gmail.com> <258A909D3301210200DED148@mistral.private> <74c219d30909151725v61f9c271s267e8ccd60aae9af@mail.gmail.com> Message-ID: <20090916004039.GC14043@bromo.med.uc.edu> On Tue, Sep 15, 2009 at 05:25:56PM -0700, Toby Peterson wrote: > > No. From configure's perspective, cross-compiling means building for > an architecture that your build system can't run. A 64-bit Snow > Leopard machine can run x86_64, i386, and ppc (with Rosetta). > Normally...but name me another operating system in history where the architecture detected by config.guess differed so radically from that of the actual code generation of the system compiler. Any way, let's leave this discussion sit until we get a response from the autoconf developers on how they view the situation with darwin10. Jack From raimue at macports.org Tue Sep 15 17:44:48 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 16 Sep 2009 02:44:48 +0200 Subject: request for configure clarifications on darwin10 In-Reply-To: <20090916001032.GB13899@bromo.med.uc.edu> References: <20090915232020.GA13527@bromo.med.uc.edu> <20090916001032.GB13899@bromo.med.uc.edu> Message-ID: <4AB03500.4040306@macports.org> On 2009-09-16 02:10 , Jack Howarth wrote: > On Tue, Sep 15, 2009 at 07:20:20PM -0400, Jack Howarth wrote: >> + else >> + if sysctl -a | grep -c hw.cpu64bit_capable>/dev/null 2>&1 ; then >> + UNAME_PROCESSOR=x86_64 > > Please execuse the error in the previously posted patch...I grabbed an older copy. The > correct line there is... > > if test `sysctl -n hw.cpu64bit_capable | grep -c 1` = 1 ; then Note that this would be wrong on Leopard (Darwin 9) or earlier as the CPU might be 64-bit capable, but the default arch is i386. Rainer From mta at umich.edu Tue Sep 15 17:47:06 2009 From: mta at umich.edu (Mike Alexander) Date: Tue, 15 Sep 2009 20:47:06 -0400 Subject: Removing a port and dependencies? In-Reply-To: <1bd71ad80909151719p108ba8d2y678cd91f7d47a5ac@mail.gmail.com> References: <1bd71ad80909142105o6c13f6a8t191be1f7ca8701a9@mail.gmail.com> <8B272679-8F04-4ECC-872B-9EF522365C22@macports.org> <1bd71ad80909151719p108ba8d2y678cd91f7d47a5ac@mail.gmail.com> Message-ID: --On September 15, 2009 5:19:17 PM -0700 Michael_google gmail_Gersten wrote: >> There are two versions of port_cutleaves available. ?The port called >> port_cutleaves installs version >> >> # $Id: port_cutleaves 45949 2009-01-26 01:59:07Z perry at macports.org $ >> >> There is also a version in the contrib directory in the svn >> repository. This version is newer: >> >> # $Id: port_cutleaves 55639 2009-08-15 08:35:14Z jmr at macports.org $ >> >> The newer version contains some bug fixes and a new option, -b, to >> consider build dependencies (although the help info for it seems >> backwards to me). ?Perhaps this version should be cleaned up and >> the port upgraded. > > Can someone explain how to get the contrib svn version? Yes, it's just > svn co
localdir, but what is the address? > > Please remember to reply to the group. The URL is . Mike From ryandesign at macports.org Tue Sep 15 17:48:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 15 Sep 2009 19:48:13 -0500 Subject: X11 and MacPorts In-Reply-To: <0FB01F23-E7FD-4FF8-9028-39F471938725@macports.org> References: <20090915141142.GA5818@bromo.med.uc.edu> <0FB01F23-E7FD-4FF8-9028-39F471938725@macports.org> Message-ID: <0B821540-31E3-49BB-8DCF-50B9A4FD8700@macports.org> On Sep 15, 2009, at 13:00, Jeremy Huddleston wrote: >> The glw package in MacPorts is behaving normally >> as tested with the old opensolar.c sample code, >> however the widgets in molmol never appear either >> when built as a MacPorts package or directly >> against the MacPorts packages manually. > > Is glw linking against the correct GL (/opt/local/lib/libGL.dylib > rather than OpenGL.framework)? On my Snow Leopard system, where I also see the problem Jack mentioned, yes, glw is linking with MacPorts versions: $ otool -L /opt/local/lib/libGLw.1.0.dylib /opt/local/lib/libGLw.1.0.dylib: /opt/local/lib/libGLw.1.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libGL.1.dylib (compatibility version 1.2.0, current version 1.2.0) /opt/local/lib/libXm.4.dylib (compatibility version 5.0.0, current version 5.2.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.1.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 124.1.1) From toby at macports.org Tue Sep 15 17:42:03 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 15 Sep 2009 17:42:03 -0700 Subject: configure.build_arch In-Reply-To: <20090916004039.GC14043@bromo.med.uc.edu> References: <20090915212300.GA12997@bromo.med.uc.edu> <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> <20090915224358.GA13401@bromo.med.uc.edu> <74c219d30909151601y6e7f351dxbed5cf6af2ca4a9e@mail.gmail.com> <74c219d30909151718s4947d973x7b846c04b9c89dd4@mail.gmail.com> <258A909D3301210200DED148@mistral.private> <74c219d30909151725v61f9c271s267e8ccd60aae9af@mail.gmail.com> <20090916004039.GC14043@bromo.med.uc.edu> Message-ID: <74c219d30909151742y44b4c439s210c1d6cedad8461@mail.gmail.com> On Tue, Sep 15, 2009 at 17:40, Jack Howarth wrote: > On Tue, Sep 15, 2009 at 05:25:56PM -0700, Toby Peterson wrote: >> >> No. From configure's perspective, cross-compiling means building for >> an architecture that your build system can't run. A 64-bit Snow >> Leopard machine can run x86_64, i386, and ppc (with Rosetta). >> > > Normally...but name me another operating system in history where > the architecture detected by config.guess differed so radically > from that of the actual code generation of the system compiler. Any > way, let's leave this discussion sit until we get a response from > the autoconf developers on how they view the situation with > darwin10. Unless they're planning on redesigning the autotools infrastructure to actually handle building for multiple architectures, I don't think their opinion is particularly relevant. Any change to config.guess etc is just another hack to keep things limping along. - Toby From ryandesign at macports.org Tue Sep 15 17:52:33 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 15 Sep 2009 19:52:33 -0500 Subject: [MacPorts] #21241: net-snmp 5.4.2.1_1 Build Failed Under Mac OS X 10.6 In-Reply-To: References: <060.98bd0bfaf197afb212f55b2a975c7a6c@macports.org> <069.c9299b9d1963dd2b99e1983b544a66ae@macports.org> Message-ID: You should add this comment to the ticket via the web interface. http://trac.macports.org/ticket/21241 On Sep 15, 2009, at 10:40, Chang James wrote: > Hi, > I have uninstalled every package build under OS X 10.5.8 and > rebuild under OS X 10.6 with xCode 3.2. > It show me the following message when I run `lipo -info /opt/local/ > lib/libssl.dylib` > > Non-fat file: /opt/local/lib/libssl.dylib is architecture: x86_64 > > Following are the error messages: > > {{{ > port install net-snmp +bzip2 +ksm +server > Port command started with PID 423 > Portfile changed since last build; discarding previous state. > ---> Computing dependencies for net-snmp > ---> Fetching net-snmp > ---> Verifying checksum(s) for net-snmp > ---> Extracting net-snmp > ---> Applying patches to net-snmp > ---> Configuring net-snmp > ---> Building net-snmp > Error: Target org.macports.build returned: shell command " cd "/opt/ > local/var/macports/build/ > _opt_local_var_macports_sources_rsync.macports.org_release_ports_net_net > -snmp/work/net-snmp-5.4.2.1" && /usr/bin/make all " returned error 2 > Command output: snmpUDPDomain.c: In function > 'netsnmp_sock_buffer_set': > snmpUDPDomain.c:500: warning: passing argument 5 of 'getsockopt' > from incompatible pointer type > snmpUDPDomain.c:535: warning: passing argument 5 of 'getsockopt' > from incompatible pointer type > /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include > -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 - > Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/ > include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/ > include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/ > darwin-2level/CORE -c snmpUDPDomain.c -o snmpUDPDomain.o >/dev/null > 2>&1 > /bin/sh ../libtool --mode=compile /usr/bin/gcc-4.2 -I../include -I. > -I../snmplib -I/opt/local/include -I/opt/local/include - > DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 - > Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include - > no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/ > opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE > -c -o snmpTCPDomain.lo snmpTCPDomain.c > /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include > -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 - > Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/ > include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/ > include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/ > darwin-2level/CORE -c snmpTCPDomain.c -fno-common -DPIC -o .libs/ > snmpTCPDomain.o > /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include > -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 - > Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/ > include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/ > include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/ > darwin-2level/CORE -c snmpTCPDomain.c -o snmpTCPDomain.o >/dev/null > 2>&1 > /bin/sh ../libtool --mode=compile /usr/bin/gcc-4.2 -I../include -I. > -I../snmplib -I/opt/local/include -I/opt/local/include - > DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 - > Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include - > no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/ > opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE > -c -o snmpUnixDomain.lo snmpUnixDomain.c > /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include > -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 - > Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/ > include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/ > include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/ > darwin-2level/CORE -c snmpUnixDomain.c -fno-common -DPIC -o .libs/ > snmpUnixDomain.o > /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include > -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 - > Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/ > include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/ > include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/ > darwin-2level/CORE -c snmpUnixDomain.c -o snmpUnixDomain.o >/dev/ > null 2>&1 > /bin/sh ../libtool --mode=compile /usr/bin/gcc-4.2 -I../include -I. > -I../snmplib -I/opt/local/include -I/opt/local/include - > DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 - > Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include - > no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/ > opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE > -c -o snmpCallbackDomain.lo snmpCallbackDomain.c > /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include > -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 - > Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/ > include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/ > include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/ > darwin-2level/CORE > -c snmpCallbackDomain.c -fno-common -DPIC -o .libs/ > snmpCallbackDomain.o > /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include > -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 - > Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/ > include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/ > include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/ > darwin-2level/CORE -c snmpCallbackDomain.c -o snmpCallbackDomain.o >/ > dev/null 2>&1 > /bin/sh ../libtool --mode=compile /usr/bin/gcc-4.2 -I../include -I. > -I../snmplib -I/opt/local/include -I/opt/local/include - > DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 - > Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include - > no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/ > opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE > -c -o snmp_secmod.lo snmp_secmod.c > /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include > -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 - > Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/ > include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/ > include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/ > darwin-2level/CORE -c snmp_secmod.c -fno-common -DPIC -o .libs/ > snmp_secmod.o > /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include > -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 - > Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/ > include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/ > include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/ > darwin-2level/CORE -c snmp_secmod.c -o snmp_secmod.o >/dev/null 2>&1 > /bin/sh ../libtool --mode=compile /usr/bin/gcc-4.2 -I../include -I. > -I../snmplib -I/opt/local/include -I/opt/local/include - > DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 - > Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include - > no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/ > opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE > -c -o snmpusm.lo snmpusm.c > /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include > -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 - > Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/ > include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/ > include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/ > darwin-2level/CORE -c snmpusm.c -fno-common -DPIC -o .libs/snmpusm.o > /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include > -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 - > Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/ > include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/ > include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/ > darwin-2level/CORE -c snmpusm.c -o snmpusm.o >/dev/null 2>&1 > /bin/sh ../libtool --mode=compile /usr/bin/gcc-4.2 -I../include -I. > -I../snmplib -I/opt/local/include -I/opt/local/include - > DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 -Udarwin10 - > Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/include - > no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/include -I/ > opt/local/include -I/opt/local/lib/perl5/5.8.9/darwin-2level/CORE > -c -o snmpksm.lo snmpksm.c > /usr/bin/gcc-4.2 -I../include -I. -I../snmplib -I/opt/local/include > -I/opt/local/include -DNETSNMP_ENABLE_IPV6 -O2 -arch x86_64 - > Udarwin10 -Ddarwin10=darwin10 -fno-common -DPERL_DARWIN -I/opt/local/ > include -no-cpp-precomp -fno-strict-aliasing -pipe -I/usr/local/ > include -I/opt/local/include -I/opt/local/lib/perl5/5.8.9/ > darwin-2level/CORE -c snmpksm.c -fno-common -DPIC -o .libs/snmpksm.o > snmpksm.c: In function 'ksm_rgenerate_out_msg': > snmpksm.c:493: error: 'params' undeclared (first use in this function) > snmpksm.c:493: error: (Each undeclared identifier is reported only > once > snmpksm.c:493: error: for each function it appears in.) > snmpksm.c:693: error: 'krb5_enctype_array' undeclared (first use in > this function) > snmpksm.c: In function 'ksm_process_in_msg': > snmpksm.c:1684: error: 'krb5_enctype_array' undeclared (first use in > this function) > make[1]: *** [snmpksm.lo] Error 1 > make: *** [subdirs] Error 1 > Error: Status 1 encountered during processing. > ---> Executing: /opt/local/bin/port install net-snmp +bzip2 +ksm > +server > > }}} > > Best Regards! > > James > Chang > > 2009/9/10 MacPorts > #21241: net-snmp 5.4.2.1_1 Build Failed Under Mac OS X 10.6 > -------------------------------------- > +------------------------------------- > Reporter: james.applemac@? | Owner: opendarwin.org@? > Type: defect | Status: new > Priority: Normal | Milestone: > Component: ports | Version: 1.8.0 > Keywords: | Port: net-snmp > -------------------------------------- > +------------------------------------- > Changes (by toby@?): > > * priority: High => Normal > > > Comment: > > What is the output of `lipo -info /opt/local/lib/libssl.dylib` ? > > -- > Ticket URL: > MacPorts > Ports system for Mac OS From toby at macports.org Tue Sep 15 17:38:52 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 15 Sep 2009 17:38:52 -0700 Subject: configure.build_arch In-Reply-To: <20090916003546.GB14043@bromo.med.uc.edu> References: <20090915212300.GA12997@bromo.med.uc.edu> <74c219d30909151443r2ca6f97fufadbb725f7b99055@mail.gmail.com> <20090915224358.GA13401@bromo.med.uc.edu> <74c219d30909151601y6e7f351dxbed5cf6af2ca4a9e@mail.gmail.com> <74c219d30909151718s4947d973x7b846c04b9c89dd4@mail.gmail.com> <258A909D3301210200DED148@mistral.private> <20090916003546.GB14043@bromo.med.uc.edu> Message-ID: <74c219d30909151738m70bcd07aj18efd47fc59bb0df@mail.gmail.com> On Tue, Sep 15, 2009 at 17:35, Jack Howarth wrote: > On Tue, Sep 15, 2009 at 08:21:20PM -0400, Mike Alexander wrote: >> --On September 15, 2009 5:18:32 PM -0700 Toby Peterson >> wrote: >> >>> On Tue, Sep 15, 2009 at 17:05, Mike Alexander wrote: >>>> --On September 15, 2009 4:01:43 PM -0700 Toby Peterson >>>> wrote: >>>> >>>>> For the few ports that actually care, only --build makes any sense. >>>>> We don't support cross-compiling, and very few configure scripts >>>>> get it right anyway. >>>> >>>> I think Jack's point is that in 10.6 on a 32 bit kernel you >>>> effectively are cross-compiling whether you want to or not. ?You're >>>> building 64 bit binaries on a system that claims to be a 32 bit >>>> system. ?That seems like cross-compiling to me. ?Am I >>>> misunderstanding something? >>> >>> As I've noted numerous times now, config.guess still reports i386 on >>> K64, so this perceived problem exists regardless of the kernel >>> architecture. >> >> Ok, that just seems to make the problem worse. ?Even after switching to >> the 64 bit kernel you're still cross-compiling, right? >> >> ? ? ? ? ?Mike > > ? ?Yes. I reported this issue on radar several times during the > Snow Leopard development but it was never addressed. The solution > (which Ben Elliston who is the config.guess maintainer agrees with) > is to decouple the config.guess result on i386 darwin from the kernel and to > use the code generation of the compiler or the code execution in > the absence of a compiler. However even when config.guess is fixed > it will take a long time for all projects to update to a fixed > config.guess. In the meanwhile we have to be very careful to > make sure that configure is clued into the correct architecture. > In the case of the configure.build-arch, the fix is obvious and trivial > if 'configure.build-arch x86_64' is used "--target=x86_64-apple-darwin${os.major}" > needs to be added to the configure arguments by configure.build-arch > as well. Why --target? We're not cross-compiling. If anything, --build makes more sense, and that should most certainly be done on only for ports that need it. - Toby P.S. If the fix is trivial, why do you care so much? ;) From opendarwin.org at darkart.com Tue Sep 15 18:30:52 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Wed, 16 Sep 2009 01:30:52 +0000 Subject: [57743] trunk/dports/graphics/ImageMagick/Portfile In-Reply-To: <20090916012015.A34402736CA9@beta.macosforge.org> References: <20090916012015.A34402736CA9@beta.macosforge.org> Message-ID: <20090916013052.GL1215@darkart.com> On Tue, Sep 15, 2009 at 06:20:13PM -0700, ryandesign at macports.org wrote: > Revision: 57743 > http://trac.macports.org/changeset/57743 > Author: ryandesign at macports.org > Date: 2009-09-15 18:20:06 -0700 (Tue, 15 Sep 2009) > Log Message: > ----------- > ImageMagick: update to 6.5.6-1 to fix #21397 and switch to 7z distfile because it's smaller Is using 7z for downloads really worth the extra compile, etc. time for the decompressor required, and the (presumably) longer decompression time? -eric From howarth at bromo.med.uc.edu Tue Sep 15 18:36:35 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 21:36:35 -0400 Subject: request for configure clarifications on darwin10 In-Reply-To: <4AB03500.4040306@macports.org> References: <20090915232020.GA13527@bromo.med.uc.edu> <20090916001032.GB13899@bromo.med.uc.edu> <4AB03500.4040306@macports.org> Message-ID: <20090916013635.GA14540@bromo.med.uc.edu> On Wed, Sep 16, 2009 at 02:44:48AM +0200, Rainer M?ller wrote: > On 2009-09-16 02:10 , Jack Howarth wrote: > > On Tue, Sep 15, 2009 at 07:20:20PM -0400, Jack Howarth wrote: > >> + else > >> + if sysctl -a | grep -c hw.cpu64bit_capable>/dev/null 2>&1 ; then > >> + UNAME_PROCESSOR=x86_64 > > > > Please execuse the error in the previously posted patch...I grabbed an older copy. The > > correct line there is... > > > > if test `sysctl -n hw.cpu64bit_capable | grep -c 1` = 1 ; then > > Note that this would be wrong on Leopard (Darwin 9) or earlier as the > CPU might be 64-bit capable, but the default arch is i386. > > Rainer Rainer, Well taken. It really wasn't my idea to add that test. Ben wants to decouple from having a c compiler. I'll mention this issue. Still I think SL it will be a vast improvement if config.guess properly reflects the actual code generation and execution of the compiler. Jack From ryandesign at macports.org Tue Sep 15 19:14:36 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 15 Sep 2009 21:14:36 -0500 Subject: Is use_7z worth it? (was: Re: [57743] trunk/dports/graphics/ImageMagick/Portfile) In-Reply-To: <20090916013052.GL1215@darkart.com> References: <20090916012015.A34402736CA9@beta.macosforge.org> <20090916013052.GL1215@darkart.com> Message-ID: <93A9FD64-8B1B-4A68-B34E-33A2DECDD4C5@macports.org> On Sep 15, 2009, at 20:30, Eric Hall wrote: > On Tue, Sep 15, 2009 at 06:20:13PM -0700, ryandesign at macports.org > wrote: > >> Revision: 57743 >> http://trac.macports.org/changeset/57743 >> Author: ryandesign at macports.org >> Date: 2009-09-15 18:20:06 -0700 (Tue, 15 Sep 2009) >> Log Message: >> ----------- >> ImageMagick: update to 6.5.6-1 to fix #21397 and switch to 7z >> distfile because it's smaller > > Is using 7z for downloads really worth the extra compile, etc. > time for the decompressor required, and the (presumably) longer > decompression time? IMHO, definitely, which is why the use_7z option was added to MacPorts base. Processors in today's computers are extremely fast, so the decompression time is practically nothing. All ports should switch to 7z or similar highly-compressed alternatives to gz and bz2 if available. lzma and xz are good choices too, though MacPorts doesn't yet have a use_xz option. The lzma, xz and 7z formats can all use the lzma compression algorithm. Meanwhile, networks can be slow. While in the U.S. we may be used to fast broadband connections with unlimited downloads for a fixed monthly price, in other parts of the world, slower access over ISDN or dialup is still normal, which is probably billed by the minute or by the megabyte. Even if you're on broadband, conditions on your network or between you and the server may make the download slow, so decreasing the download size is good. I did some tests on my 2.2-GHz Intel Core 2 Duo MacBook Pro running Snow Leopard from an external 5400-RPM 2.5" SATA drive connected via FireWire 800. Decompressing either the .7z or the .tar.bz2 version of the ImageMagick distfile took just over 3 seconds; there was practically no difference in time. Using .7z: $ sudo port clean && sudo port checksum ---> Cleaning ImageMagick ---> Computing dependencies for ImageMagick ---> Fetching ImageMagick ---> Verifying checksum(s) for ImageMagick $ time sudo port extract ---> Computing dependencies for ImageMagick ---> Extracting ImageMagick real 0m3.142s user 0m1.239s sys 0m0.815s Using .tar.bz2: $ sudo port clean && sudo port checksum ---> Cleaning ImageMagick ---> Computing dependencies for ImageMagick ---> Fetching ImageMagick ---> Verifying checksum(s) for ImageMagick rschmidt at 808 ImageMagick $ time sudo port extract ---> Computing dependencies for ImageMagick ---> Extracting ImageMagick real 0m3.127s user 0m2.435s sys 0m0.605s And compiling p7zip is a one-time operation which takes less than a minute. $ time sudo port install p7zip ---> Computing dependencies for p7zip ---> Fetching p7zip ---> Verifying checksum(s) for p7zip ---> Extracting p7zip ---> Applying patches to p7zip ---> Configuring p7zip ---> Building p7zip ---> Staging p7zip into destroot ---> Installing p7zip @9.04_0 ---> Activating p7zip @9.04_0 ---> Cleaning p7zip real 0m47.720s user 1m17.400s sys 0m10.072s The p7zip 9.04 bz2 distfile is 3.6 MB. This plus the size of the ImageMagick 6.5.6-1 7z distfile (5.7 MB) is only slightly larger than the size of the ImageMagick 6.5.6-1 bz2 distfile (8.6 MB). So if the user did not already have p7zip, then it will take a little longer this one time, but for every subsequent update, it's a win. From howarth at bromo.med.uc.edu Tue Sep 15 20:30:23 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 15 Sep 2009 23:30:23 -0400 Subject: apbs packaging for MacPorts Message-ID: <20090916033023.GA15062@bromo.med.uc.edu> I just finished porting the current apbs-1.1.0 packaging from fink to MacPorts. It works fine to generate the electrostatic surfaces on molecules in the pymol-1.2r1 packaging that I posted last night. I haven't bothered yet to enable the python support in abps yet. If anyone here has a preference on that let me know. I've never used it myself and when I work up the associated apbs-mpi package (built against openmpi this weekend), I have to disable the python support in that one anyway since you can't build both the mpi and python support at the same time. Actually this brings up a question. Do we have any packages that use mpi support at the moment? What is the preference in MacPorts? Should I use the system openmpi or a MacPorts openmpi package? In fink, I maintained both the lammpi/openmpi packages and would create variants (gromacs-mpi, apbs-mpi,etc) that would build against either (since the fink lammpi/openmpi packages can co-exist with each other). Jack From afb at macports.org Tue Sep 15 23:53:57 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 16 Sep 2009 08:53:57 +0200 Subject: Is use_7z worth it? (was: Re: [57743] trunk/dports/graphics/ImageMagick/Portfile) In-Reply-To: <93A9FD64-8B1B-4A68-B34E-33A2DECDD4C5@macports.org> References: <20090916012015.A34402736CA9@beta.macosforge.org> <20090916013052.GL1215@darkart.com> <93A9FD64-8B1B-4A68-B34E-33A2DECDD4C5@macports.org> Message-ID: <7ACC2045-5EA4-4655-9400-CF4B2494B3C9@macports.org> Ryan Schmidt wrote: >> Is using 7z for downloads really worth the extra compile, etc. >> time for the decompressor required, and the (presumably) longer >> decompression time? > > IMHO, definitely, which is why the use_7z option was added to > MacPorts base. Processors in today's computers are extremely fast, > so the decompression time is practically nothing. All ports should > switch to 7z or similar highly-compressed alternatives to gz and > bz2 if available. lzma and xz are good choices too, though MacPorts > doesn't yet have a use_xz option. The lzma, xz and 7z formats can > all use the lzma compression algorithm. Using .7z isn't a good option in the same way that using .zip isn't optimal. If you want the LZMA compression, it would be better to use .tar.lzma instead ? Even better is to use LZMA2 in form of .tar.xz, when that has been added/released*. * XZ Utils is still in beta (thus port "xz-devel"), see http:// tukaani.org/xz/ > The p7zip 9.04 bz2 distfile is 3.6 MB. This plus the size of the > ImageMagick 6.5.6-1 7z distfile (5.7 MB) is only slightly larger > than the size of the ImageMagick 6.5.6-1 bz2 distfile (8.6 MB). So > if the user did not already have p7zip, then it will take a little > longer this one time, but for every subsequent update, it's a win. Using xz instead of bz2 is a good alternative, since it makes smaller files and is faster to decompress (it takes longer to compress, but that's server-side/once). It does *not* replace gz however, as there are lots of cases where gzip is "good enough" (and faster). But I don't think you should use the .7z format, use compressed .tar instead. --anders From afb at macports.org Wed Sep 16 00:00:46 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 16 Sep 2009 09:00:46 +0200 Subject: configure.build_arch In-Reply-To: <20090915212300.GA12997@bromo.med.uc.edu> References: <20090915212300.GA12997@bromo.med.uc.edu> Message-ID: <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> Jack Howarth wrote: > Reading through the commits on the configure.build_arch feature > in port, I am rather surprised that invoking that doesn't also > set the triplets for configure as well as passing the -m32 or > -m64 compiler flags. Wouldn't you at least want to set > --target= to the appropriate value so that configure understood > what architecture it was going to build for? I suppose such a > change might be an option to patching config.guess for those > Portfiles that use configure.build_arch. This would make sure > that configure was given --target=x86_64-apple-darwin9/10 > when -m64 (or -arch x86_64?) was passed through the invoking > configure.build_arch. We set the triplets back when we were (ab)using +universal to do cross-compilation, with the three universal_ flags: http://lists.macosforge.org/pipermail/macports-dev/2008-February/ 004358.html It never worked very well, so in MacPorts 1.8.0 it was all ripped out in favor of the much simpler build_arch solution... --anders From ryandesign at macports.org Wed Sep 16 00:36:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 16 Sep 2009 02:36:40 -0500 Subject: Is use_7z worth it? (was: Re: [57743] trunk/dports/graphics/ImageMagick/Portfile) In-Reply-To: <7ACC2045-5EA4-4655-9400-CF4B2494B3C9@macports.org> References: <20090916012015.A34402736CA9@beta.macosforge.org> <20090916013052.GL1215@darkart.com> <93A9FD64-8B1B-4A68-B34E-33A2DECDD4C5@macports.org> <7ACC2045-5EA4-4655-9400-CF4B2494B3C9@macports.org> Message-ID: <9A490EDA-6827-43FA-B210-6087AE50FA74@macports.org> On Sep 16, 2009, at 01:53, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >>> Is using 7z for downloads really worth the extra compile, etc. >>> time for the decompressor required, and the (presumably) longer >>> decompression time? >> >> IMHO, definitely, which is why the use_7z option was added to >> MacPorts base. Processors in today's computers are extremely fast, >> so the decompression time is practically nothing. All ports should >> switch to 7z or similar highly-compressed alternatives to gz and >> bz2 if available. lzma and xz are good choices too, though MacPorts >> doesn't yet have a use_xz option. The lzma, xz and 7z formats can >> all use the lzma compression algorithm. > > Using .7z isn't a good option in the same way that using .zip isn't > optimal. In what way is .zip not optimal? It is the built-in compression method offered by the Mac OS X Finder, so at least somebody at Apple thought it was a good choice for something. And software distributed as .zip archives works perfectly fine in MacPorts. It's not optimal in that the compression isn't very good, but in that way it would be completely unlike .7z, which can use lzma compression which is very good. > If you want the LZMA compression, it would be better to > use .tar.lzma instead ? Even better is to use LZMA2 in form > of .tar.xz, when that has been added/released*. > > * XZ Utils is still in beta (thus port "xz-devel"), see http://tukaani.org/xz/ > >> The p7zip 9.04 bz2 distfile is 3.6 MB. This plus the size of the >> ImageMagick 6.5.6-1 7z distfile (5.7 MB) is only slightly larger >> than the size of the ImageMagick 6.5.6-1 bz2 distfile (8.6 MB). So >> if the user did not already have p7zip, then it will take a little >> longer this one time, but for every subsequent update, it's a win. > > Using xz instead of bz2 is a good alternative, since it makes > smaller files and is faster to decompress (it takes longer to > compress, but that's server-side/once). It does *not* replace gz > however, as there are lots of cases where gzip is "good enough" (and > faster). > > But I don't think you should use the .7z format, use compressed .tar > instead. If you have a disagreement with the fundamental nature of the 7z format then that's something you should take up with its developers. The ImageMagick developers have chosen to distribute their software in many different formats. In decreasing order of size, they are: .zip, .tar.gz, .tar.bz2, .tar.xz, and .7z. I chose .7z because it is the smallest. I don't see a problem with this. From afb at macports.org Wed Sep 16 01:01:39 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 16 Sep 2009 10:01:39 +0200 Subject: Is use_7z worth it? (was: Re: [57743] trunk/dports/graphics/ImageMagick/Portfile) In-Reply-To: <9A490EDA-6827-43FA-B210-6087AE50FA74@macports.org> References: <20090916012015.A34402736CA9@beta.macosforge.org> <20090916013052.GL1215@darkart.com> <93A9FD64-8B1B-4A68-B34E-33A2DECDD4C5@macports.org> <7ACC2045-5EA4-4655-9400-CF4B2494B3C9@macports.org> <9A490EDA-6827-43FA-B210-6087AE50FA74@macports.org> Message-ID: Ryan Schmidt wrote: >> Using .7z isn't a good option in the same way that using .zip >> isn't optimal. > > In what way is .zip not optimal? It is the built-in compression > method offered by the Mac OS X Finder, so at least somebody at > Apple thought it was a good choice for something. And software > distributed as .zip archives works perfectly fine in MacPorts. It's > not optimal in that the compression isn't very good, but in that > way it would be completely unlike .7z, which can use lzma > compression which is very good. You are mixing archive formats with compression formats... The .tar format is better suited to distributing UNIX files, whereas zip or 7z might be better for Windows or something*. But .zip and .gz use the same compression, and .7z and .lzma use the same compression, so it's only about the archiving. > The ImageMagick developers have chosen to distribute their software > in many different formats. In decreasing order of size, they > are: .zip, .tar.gz, .tar.bz2, .tar.xz, and .7z. I chose .7z because > it is the smallest. I don't see a problem with this. I don't have a major problem with it either (if I appeared to), just like you could use the .zip file instead of the .tar.gz. Just saying that generally it would be preferred to use .tar.xz, so you probably want to be adding that "use_xz" flag to MacPorts. For instance, 7z doesn't store UNIX owner/group permissions... --anders * PS. Actually one of the best features with .zip is that you can have compression set off and on the file level, something that is also available in the .xar format. But for general file distribution, this usually leads to worse compression ratios. Just that when doing something like a game, you can choose to compress the .exe program but not the .mp3 and .jpg and such. From ryandesign at macports.org Wed Sep 16 01:15:19 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 16 Sep 2009 03:15:19 -0500 Subject: Is use_7z worth it? (was: Re: [57743] trunk/dports/graphics/ImageMagick/Portfile) In-Reply-To: References: <20090916012015.A34402736CA9@beta.macosforge.org> <20090916013052.GL1215@darkart.com> <93A9FD64-8B1B-4A68-B34E-33A2DECDD4C5@macports.org> <7ACC2045-5EA4-4655-9400-CF4B2494B3C9@macports.org> <9A490EDA-6827-43FA-B210-6087AE50FA74@macports.org> Message-ID: <687BCCBA-B002-44B4-A72D-5AB82443D851@macports.org> On Sep 16, 2009, at 03:01, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >>> Using .7z isn't a good option in the same way that using .zip >>> isn't optimal. >> >> In what way is .zip not optimal? It is the built-in compression >> method offered by the Mac OS X Finder, so at least somebody at >> Apple thought it was a good choice for something. And software >> distributed as .zip archives works perfectly fine in MacPorts. It's >> not optimal in that the compression isn't very good, but in that >> way it would be completely unlike .7z, which can use lzma >> compression which is very good. > > You are mixing archive formats with compression formats... It's hard not to, since they're so related. :) > The .tar format is better suited to distributing UNIX files, > whereas zip or 7z might be better for Windows or something*. > But .zip and .gz use the same compression, and .7z and .lzma > use the same compression, so it's only about the archiving. > >> The ImageMagick developers have chosen to distribute their software >> in many different formats. In decreasing order of size, they >> are: .zip, .tar.gz, .tar.bz2, .tar.xz, and .7z. I chose .7z because >> it is the smallest. I don't see a problem with this. > > I don't have a major problem with it either (if I appeared to), > just like you could use the .zip file instead of the .tar.gz. > Just saying that generally it would be preferred to use .tar.xz, > so you probably want to be adding that "use_xz" flag to MacPorts. Yes, I think we should add it too, but I am uncomfortable doing so until a stable version of xz exists. It does not seem right for a core MacPorts functionality to depend on an unstable version of a software package. > For instance, 7z doesn't store UNIX owner/group permissions... I read that claim on the Wikipedia page, but am unable to substantiate it. The 7z archive of ImageMagick does have the execute bit of the configure script set, for example. From afb at macports.org Wed Sep 16 01:33:02 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 16 Sep 2009 10:33:02 +0200 Subject: Is use_7z worth it? (was: Re: [57743] trunk/dports/graphics/ImageMagick/Portfile) In-Reply-To: <687BCCBA-B002-44B4-A72D-5AB82443D851@macports.org> References: <20090916012015.A34402736CA9@beta.macosforge.org> <20090916013052.GL1215@darkart.com> <93A9FD64-8B1B-4A68-B34E-33A2DECDD4C5@macports.org> <7ACC2045-5EA4-4655-9400-CF4B2494B3C9@macports.org> <9A490EDA-6827-43FA-B210-6087AE50FA74@macports.org> <687BCCBA-B002-44B4-A72D-5AB82443D851@macports.org> Message-ID: Ryan Schmidt wrote: >> You are mixing archive formats with compression formats... > > It's hard not to, since they're so related. :) Indeed! It's also a problem for things like MacPorts that calculates checksums/digests on the *compressed* tarball. This means that changing compression changes the digest, which isn't really "perfect" either. There are other ways of calculating the digest, so that it would be the same no matter which compression is being used... Like doing it on the uncompressed .tar, or making a "manifest" of the included files. >> I don't have a major problem with it either (if I appeared to), >> just like you could use the .zip file instead of the .tar.gz. >> Just saying that generally it would be preferred to use .tar.xz, >> so you probably want to be adding that "use_xz" flag to MacPorts. > > Yes, I think we should add it too, but I am uncomfortable doing so > until a stable version of xz exists. It does not seem right for a > core MacPorts functionality to depend on an unstable version of a > software package. Presumably the format itself is stable, but the software isn't yet. It's still possible to use .lzma meanwhile, since that's released. And I don't think that the actual implementation of "use_xz" would change much though, between the current XZ beta and the XZ release ? >> For instance, 7z doesn't store UNIX owner/group permissions... > > I read that claim on the Wikipedia page, but am unable to > substantiate it. The 7z archive of ImageMagick does have the > execute bit of the configure script set, for example. Maybe it's gotten better since, the p7zip (portable version) used to be a bit behind. I don't think it had the LZMA2 before either... But it still has "weird" command-line options etc (just like unzip), whereas xz/lzma (or gzip) has the usual options and tar integration ? --anders From howarth at bromo.med.uc.edu Wed Sep 16 06:01:45 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 16 Sep 2009 09:01:45 -0400 Subject: request for configure clarifications on darwin10 In-Reply-To: References: <20090915232020.GA13527@bromo.med.uc.edu> Message-ID: <20090916130145.GA18976@bromo.med.uc.edu> On Tue, Sep 15, 2009 at 11:52:35PM -0500, Bob Friesenhahn wrote: > On Tue, 15 Sep 2009, Jack Howarth wrote: >> ps Isn't darwin10 the very first hybrid OS which the configure machinary has been >> faced with? I am unaware of any other operating systems that ever differed the >> architecture of the kernel and the default code execution/generation of the >> default system compiler. Unfortunately both uname and arch will report i386 on >> darwin10 on EMT64 capable hardware. Only booting the 64-bit kernel returns >> coherency to the situation with uname and arch reporting x86_64. > > The notion of a "system compiler" seems immaterial to me since we are > not constrained to use it. If the compiler produces default code which > does not run under the OS, that seems like a bug to me. > > Sun's Solaris supports both 32 and 64 bit kernels. Under the 64 bit > kernel (and the 32-bit kernel), config.guess reports > "i386-pc-solaris2.10". It is true that the freely downloadable compiler > from Sun does produce i386 type code by default. > > There is only so much you can expect from config.guess. Except for > extraordinary cases, I would expect that config.guess output would be > based on output from 'uname'. > > Bob > -- > Bob Friesenhahn > bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Bob, The question I have is, in such a case where the detected triplet from config.guess reports a radically different architecture (i386-apple-darwin10) than the actual default code execution and compiler code generation (x86_64-apple-darwin10), might that not be considered a form of cross-compilation requiring the user pass at least the --target triplet to configure? Currently, many developers on darwin10 seem to be under the impression that it is okay to leave configure believing the target is i386-apple-darwin10 while the actual code generation is x86_64-apple-darwin10. My view is that this is a misuse of configure since it is basically working on incorrect assumptions about the architecture. Jack ps I do believe config.guess should be patched. It seems bad form to leave config.guess misreporting the architecture in this manner. The best approach would seem to be decoupling the architecture from the kernel type and instead relying on the actual code generation. I believe this is in fact done currently for solaris in config.guess... i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*) eval $set_cc_for_build SUN_ARCH="i386" # If there is a compiler, see if it is configured for 64-bit objects. # Note that the Sun cc does not turn __LP64__ into 1 like gcc does. # This test works for both compilers. if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then if (echo '#ifdef __amd64'; echo IS_64BIT_ARCH; echo '#endif') | \ (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \ grep IS_64BIT_ARCH >/dev/null then SUN_ARCH="x86_64" fi fi echo ${SUN_ARCH}-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'` exit ;; From howarth at bromo.med.uc.edu Wed Sep 16 06:30:09 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 16 Sep 2009 09:30:09 -0400 Subject: request for configure clarifications on darwin10 In-Reply-To: References: <20090915232020.GA13527@bromo.med.uc.edu> <20090916001032.GB13899@bromo.med.uc.edu> <4AB03500.4040306@macports.org> <20090916013635.GA14540@bromo.med.uc.edu> Message-ID: <20090916133009.GB18976@bromo.med.uc.edu> On Wed, Sep 16, 2009 at 12:06:24AM -0500, Bob Friesenhahn wrote: > On Tue, 15 Sep 2009, Jack Howarth wrote: >> >> Rainer, >> Well taken. It really wasn't my idea to add that test. Ben wants to >> decouple from having a c compiler. I'll mention this issue. Still I >> think SL it will be a vast improvement if config.guess properly >> reflects the actual code generation and execution of the compiler. > > If the user configures using the 64-bit kernel but then decides to > reboot using the 32-bit kernel to run a video game, what happens in that > event? > > It seems to me that altering config.guess output based on whatever > kernel the system is using at that instant in time is fraught with peril > since it may be inconsistent over a period of time, possibly spanning > only minutes. Either the user should be provided with a way to specify > the type of code they want, or effort should be made to produce the > lowest common demominator by default. > > Bob > -- > Bob Friesenhahn > bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Bob, I am not proposing basing the config.guess results on what the kernel is but rather decoupling it from that. I misspoke earlier in that only 'uname -m' reports x86_64 on the x86_64 kernel under darwin10 (but that is orthogonal the problem since config.guess currently uses uname -p which is always i386 on both the 32-bit and 64-bit kernels. I am in fact suggesting the the config,guess result on darwin10 should be based on current code generation of the compiler as set on CC. Perhaps, I should clarify the situation on darwin10. It has the following behaviors... processor type non-EMT64 EMT64 -------------------------- kernel type 32-bit only 32-bit(default) 64-bit code execution 32-bit only 64-bit(default)/32-bit on both kernels code generation 32-bit 64-bit(default)/32-bit on both kernels command outputs uname -m i386 x86_64 uname -p i386 i386 arch i386 i386 Also note that gcc-4.2 is the default system compiler which executes/generates x86_64 code on EMT64 capable processors. The depreciated gcc-4.0 compiler still executes/generates i386 code on EMT64 capables processor (ie only the default system compiler, gcc-4.2, is built as native x86_64 code). I did file a radar report 6707283, arch command reports incorrect incorrect architecture without arguments). The darwin arch man page says... The arch command with no arguments, displays the machine's architecture type. The other use of the arch command it to run a selected architecture of a universal binary. A universal binary contains code that can run on different architectures. By default, the operating system will select the archi- tecture that most closely matches the processor type. This means that an intel architecture is selected on intel processors and a powerpc architecture is selected on powerpc processors. A 64-bit architecuture is pre- ferred over a 32-bit architecture on a 64-bit processor, while only 32-bit architectures can run on a 32-bit processor. which logically would suggest that arch without arguments should report the preferred architecture that will be used on that machine. My proposed patch is intended to test the code generation of CC and detect if __LP64__ is defined on the c compiler. So from the above, if you execute the following with the current config.guess, you will get (on EMT64 machines)... setenv CC gcc-4.2 ./config.guess i386-apple-darwin10 (even though the compiler is creating x86_64 code by default) The patched config.guess eliminates this error by testing if the generated code for CC as set is defining __LP64__. Thus you get... setenv CC gcc-4.2 ./config.guess x86_64-apple-darwin10 setenv CC "gcc-4.2 -m32" ./config.guess i386-apple-darwin10 setenv CC gcc-4.0 ./config.guess i386-apple-darwin10 setenv CC "gcc-4.2 -m64" ./config.guess x86_64-apple-darwin10 Ben Elliston also asked me to handle the case when the c compiler was unavailable. That part of that patch still needs work as we need to only perform that test on darwin >= 10 (since darwin9 could run x86_64 code but it is not the default architecture for code execution). Hopefully I was reasonably clear (it is a confusing situation). Jack From howarth at bromo.med.uc.edu Wed Sep 16 06:41:26 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 16 Sep 2009 09:41:26 -0400 Subject: configure.build_arch In-Reply-To: <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> Message-ID: <20090916134126.GC18976@bromo.med.uc.edu> On Wed, Sep 16, 2009 at 09:00:46AM +0200, Anders F Bj?rklund wrote: > Jack Howarth wrote: > >> Reading through the commits on the configure.build_arch feature >> in port, I am rather surprised that invoking that doesn't also >> set the triplets for configure as well as passing the -m32 or >> -m64 compiler flags. Wouldn't you at least want to set >> --target= to the appropriate value so that configure understood >> what architecture it was going to build for? I suppose such a >> change might be an option to patching config.guess for those >> Portfiles that use configure.build_arch. This would make sure >> that configure was given --target=x86_64-apple-darwin9/10 >> when -m64 (or -arch x86_64?) was passed through the invoking >> configure.build_arch. > > We set the triplets back when we were (ab)using +universal > to do cross-compilation, with the three universal_ flags: > > http://lists.macosforge.org/pipermail/macports-dev/2008-February/ > 004358.html > > It never worked very well, so in MacPorts 1.8.0 it was all > ripped out in favor of the much simpler build_arch solution... > > --anders Anders, My main concern is that the autoconf folks fully understand all of the details of darwin10 so that whatever change created upstream is as well thought out as possible. I still think that anytime port (on at least darwin10) is passing -m64 or -arch x86_64 to configure, via build_arch, that we should at least pass --target=x86_64. Currently to configure, darwin10 acts effectively like a cross-compiler in that the detected triplet for --host is i386-apple-darwin10 but the actual code generation is x86_64-apple-darwin10. Simply making sure that the --target is set by build_arch, so that configure properly understands that actual code generation being used, should help a lot. Jack ps We are starting to get reponses on autoconf mailing list so hopefully they cant arrive at a consensus on whether we should pass --target on darwin10 with the existing config.guess. I would note that Ben Elliston, the config.guess maintainer, is already on board with the concept of decoupling the output of config.guess from the kernel and instead on the code generation of the c compiler as defined by CC. From dluke at geeklair.net Wed Sep 16 06:46:18 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed, 16 Sep 2009 09:46:18 -0400 Subject: request for configure clarifications on darwin10 In-Reply-To: <20090916130145.GA18976@bromo.med.uc.edu> References: <20090915232020.GA13527@bromo.med.uc.edu> <20090916130145.GA18976@bromo.med.uc.edu> Message-ID: <772C94DA-C88A-40AE-A56B-8FA98D159668@geeklair.net> On Sep 16, 2009, at 9:01 AM, Jack Howarth wrote: > ps I do believe config.guess should be patched. sure, but that's an upstream issue. > It seems bad form to leave > config.guess misreporting the architecture in this manner. Do you have an example of a port (or class of ports) where this actually causes a real problem? configure does lots of other stuff that's broken (testing for function availability with link tests instead of using feature test macros, inability to deal with multiple architecture builds in a sane way) - but that doesn't mean MacPorts should be fixing (or attempting to fix that). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From howarth at bromo.med.uc.edu Wed Sep 16 06:52:23 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 16 Sep 2009 09:52:23 -0400 Subject: emulating post install scripts in MacPorts? Message-ID: <20090916135223.GA19348@bromo.med.uc.edu> Am I correct to assume that, unlike fink, MacPorts doesn't have the ability to execute post-installation scripts from a binary archive? I ask because the authors of the apbs software have asked that the following notice be given on installing the software... echo "+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++" echo "Please issue \"open http://agave.wustl.edu/apbs/download/\"," echo "to register your use of this software to help the author" echo "maintain funding for apbs. apbs is released under the GPL and this is" echo "not required, but would be very helpful." echo "+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++" The only approach I currently see in MacPorts is to use a post-destroot phase to print that, however this won't address binary archives. The only approach for those I see is to have a empty text file installed by apbs which a startup script would check for content. If empty, it would be filled with some text and the license message printed. I'd rather not have to resort to that though. Thanks in advance for any hints on this issue. Jack From howarth at bromo.med.uc.edu Wed Sep 16 07:05:47 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 16 Sep 2009 10:05:47 -0400 Subject: request for configure clarifications on darwin10 In-Reply-To: <772C94DA-C88A-40AE-A56B-8FA98D159668@geeklair.net> References: <20090915232020.GA13527@bromo.med.uc.edu> <20090916130145.GA18976@bromo.med.uc.edu> <772C94DA-C88A-40AE-A56B-8FA98D159668@geeklair.net> Message-ID: <20090916140547.GA19413@bromo.med.uc.edu> On Wed, Sep 16, 2009 at 09:46:18AM -0400, Daniel J. Luke wrote: > On Sep 16, 2009, at 9:01 AM, Jack Howarth wrote: >> ps I do believe config.guess should be patched. > > sure, but that's an upstream issue. > >> It seems bad form to leave >> config.guess misreporting the architecture in this manner. > > Do you have an example of a port (or class of ports) where this actually > causes a real problem? > > configure does lots of other stuff that's broken (testing for function > availability with link tests instead of using feature test macros, > inability to deal with multiple architecture builds in a sane way) - but > that doesn't mean MacPorts should be fixing (or attempting to fix that). > > -- > 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. | > +========================================================+ > > Daniel, Well it may be an extreme case but the current Portfile for gcc44 suffers from this problem since it passes -m64 on the CFLAGS but doesn't correct the triplets that configure is using... http://trac.macports.org/ticket/20838 I fixed this easily by removing the passage of -m64 to the CFLAGS and using the proposed config.guess patch to return coherency to inputs configure is working with. http://trac.macports.org/ticket/21341 Basically the breakage in the current packaging is that FSF creates a 32-bit multilib on x86_64-apple-darwin10. By not correcting the triplets and passing -m64 on the CFLAGS, configure believes it is building a 32-bit native compiler instead on i386-apple-darwin10 with a 64-bit multilib. This totally blows up the logic used in the FSF gcc build for the multilib of course. The most common case that I could imagine otherwise would be software that uses configure to make either settings to the Makefile for compiler flags or options based on the detected target in use or more likely cases when configure selects files of code with hard coded assembly language that are architecture dependent. We ran into a few of those in fink when codecs, etc would have architecture specific assembly files selected based on configure's understanding of the exact architecture being built. Jack From ryandesign at macports.org Wed Sep 16 07:11:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 16 Sep 2009 09:11:49 -0500 Subject: emulating post install scripts in MacPorts? In-Reply-To: <20090916135223.GA19348@bromo.med.uc.edu> References: <20090916135223.GA19348@bromo.med.uc.edu> Message-ID: On Sep 16, 2009, at 08:52, Jack Howarth wrote: > Am I correct to assume that, unlike fink, MacPorts doesn't > have the ability to execute post-installation scripts from > a binary archive? I ask because the authors of the apbs software > have asked that the following notice be given on installing > the software... > > echo "+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++++++" > echo "Please issue \"open http://agave.wustl.edu/apbs/download/\"," > echo "to register your use of this software to help the author" > echo "maintain funding for apbs. apbs is released under the GPL and > this is" > echo "not required, but would be very helpful." > echo "+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++++++" > > The only approach I currently see in MacPorts is to use a post- > destroot > phase to print that, however this won't address binary archives. The > only > approach for those I see is to have a empty text file installed by > apbs > which a startup script would check for content. If empty, it would > be filled > with some text and the license message printed. I'd rather not have to > resort to that though. Thanks in advance for any hints on this issue. Most ports that need to print such messages do so in the post-activate phase. I believe you are correct that this will not be shown when installing from binary archives, but since we have no means to centrally build and distribute such archives at this time, and everybody builds from source, this is not a problem. From dluke at geeklair.net Wed Sep 16 07:16:48 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed, 16 Sep 2009 10:16:48 -0400 Subject: request for configure clarifications on darwin10 In-Reply-To: <20090916140547.GA19413@bromo.med.uc.edu> References: <20090915232020.GA13527@bromo.med.uc.edu> <20090916130145.GA18976@bromo.med.uc.edu> <772C94DA-C88A-40AE-A56B-8FA98D159668@geeklair.net> <20090916140547.GA19413@bromo.med.uc.edu> Message-ID: On Sep 16, 2009, at 10:05 AM, Jack Howarth wrote: > Well it may be an extreme case but the current Portfile > for gcc44 suffers from this problem ok > The most common case that I could imagine otherwise > would be software that uses configure to make either > settings to the Makefile for compiler flags or options > based on the detected target in use or more likely > cases when configure selects files of code with > hard coded assembly language that are architecture > dependent. We ran into a few of those in fink when > codecs, etc would have architecture specific assembly > files selected based on configure's understanding > of the exact architecture being built. ... so relatively few ports, then? It seems then, that no change to base is required, but it's something to keep in mind for ports which have assembly files. Fortunately, you've got a solution pushed upstream to configure, so eventually most projects will have picked up those changes and even these special case ports won't need additional attention (just like how some ports needed attention for libtool vs glibtool when darwin was fairly new, but don't anymore). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From afb at macports.org Wed Sep 16 07:45:09 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 16 Sep 2009 16:45:09 +0200 Subject: configure.build_arch In-Reply-To: <20090916134126.GC18976@bromo.med.uc.edu> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <20090916134126.GC18976@bromo.med.uc.edu> Message-ID: <8DA3980D-3ADA-4F7F-90C1-7FCF96AADAE6@macports.org> Jack Howarth wrote: > Anders, ... > I still think that anytime port (on at least darwin10) is > passing -m64 or -arch x86_64 to configure, via build_arch, that > we should at least pass --target=x86_64. Currently to configure, > darwin10 acts effectively like a cross-compiler in that the > detected triplet > for --host is i386-apple-darwin10 but the actual code generation > is x86_64-apple-darwin10. Simply making sure that the --target > is set by build_arch, so that configure properly understands that > actual > code generation being used, should help a lot. ... Passing a --target to configure is reasonable, and different from patching "config.guess" to return something not from uname(1)... (Maybe it changed in Snow Leopard, but it used to detect something like "i386-apple-darwin10.0.1" with a lot of decimals like that ?) RPM* is using CFLAGS="${CFLAGS:--O2 -m64}" (and ditto for CXXFLAGS) along with a --target=x86_64-apple-darwin as it doesn't bother with the release number at the moment. If OS release becomes important, then it could probably be changed to include that in %{_target_os} * http://rpm5.org/ as in the RPM5-20090707.dmg (RPM 5.2.0) rpmbuild sets the target with "--target=i686" or x86_64 Not sure what MacPorts should do though, not using Snow Leopard. I'm not sure too many "configure" even look at the ${target_cpu} ? I believe that when you are trying a GNU-style cross-compile by setting --target and friends, you also need to set up the matching compiler symlinks for this newly invented "platform". Normally the system gcc would expect you to use -arch instead ? I've used it myself earlier to build Universal Binaries for Tiger, by building for "i686-apple-darwin8" and "powerpc-apple-darwin8" with configure, and then merging the results together with lipo(1). But it's a LOT easier when you can just do "-arch i386 -arch ppc" ? --anders From howarth at bromo.med.uc.edu Wed Sep 16 07:53:49 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 16 Sep 2009 10:53:49 -0400 Subject: request for configure clarifications on darwin10 In-Reply-To: References: <20090915232020.GA13527@bromo.med.uc.edu> <20090916130145.GA18976@bromo.med.uc.edu> <772C94DA-C88A-40AE-A56B-8FA98D159668@geeklair.net> <20090916140547.GA19413@bromo.med.uc.edu> Message-ID: <20090916145349.GA19732@bromo.med.uc.edu> On Wed, Sep 16, 2009 at 10:16:48AM -0400, Daniel J. Luke wrote: > > ... so relatively few ports, then? > The proposed change to config.guess only effects the case where the architecture detected by 'uname -p' is i386. In that case, the compiler code generation is tested for __LP64__ being defined and the architecture changed to x86_64 if this is true. This is essentially the same think being done for i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:* currently in config.guess. i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*) eval $set_cc_for_build SUN_ARCH="i386" # If there is a compiler, see if it is configured for 64-bit objects. # Note that the Sun cc does not turn __LP64__ into 1 like gcc does. # This test works for both compilers. if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then if (echo '#ifdef __amd64'; echo IS_64BIT_ARCH; echo '#endif') | \ (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \ grep IS_64BIT_ARCH >/dev/null then SUN_ARCH="x86_64" fi fi echo ${SUN_ARCH}-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'` exit ;; Jack From dluke at geeklair.net Wed Sep 16 07:58:09 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed, 16 Sep 2009 10:58:09 -0400 Subject: request for configure clarifications on darwin10 In-Reply-To: <20090916145349.GA19732@bromo.med.uc.edu> References: <20090915232020.GA13527@bromo.med.uc.edu> <20090916130145.GA18976@bromo.med.uc.edu> <772C94DA-C88A-40AE-A56B-8FA98D159668@geeklair.net> <20090916140547.GA19413@bromo.med.uc.edu> <20090916145349.GA19732@bromo.med.uc.edu> Message-ID: <430E9BBD-7BF1-450A-BE60-F0B6522455AB@geeklair.net> On Sep 16, 2009, at 10:53 AM, Jack Howarth wrote: On Wed, Sep 16, 2009 at 10:16:48AM -0400, Daniel J. Luke wrote: >> ... so relatively few ports, then? > > The proposed change to config.guess only effects the > case where the architecture detected by 'uname -p' is > i386. sure, but MacPorts base doesn't need to force this on every port... (It sounds like a good change to config.guess, but it also sound like MacPorts doesn't really need to do anything generally wrt that change). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From howarth at bromo.med.uc.edu Wed Sep 16 08:14:23 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 16 Sep 2009 11:14:23 -0400 Subject: configure.build_arch In-Reply-To: <8DA3980D-3ADA-4F7F-90C1-7FCF96AADAE6@macports.org> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <20090916134126.GC18976@bromo.med.uc.edu> <8DA3980D-3ADA-4F7F-90C1-7FCF96AADAE6@macports.org> Message-ID: <20090916151423.GB19732@bromo.med.uc.edu> On Wed, Sep 16, 2009 at 04:45:09PM +0200, Anders F Bj?rklund wrote: > > Passing a --target to configure is reasonable, and different from > patching "config.guess" to return something not from uname(1)... > (Maybe it changed in Snow Leopard, but it used to detect something > like "i386-apple-darwin10.0.1" with a lot of decimals like that ?) Anders, However config.guess upstream still needs to adapt to the new situation where the default architecture detected in darwin10 via uname -p, for EMT64 capable hardware, diverges from that of the architecture of the code genererated by the default system compiler. > > I believe that when you are trying a GNU-style cross-compile > by setting --target and friends, you also need to set up the > matching compiler symlinks for this newly invented "platform". > Normally the system gcc would expect you to use -arch instead ? > My argument is that the current situation is already effectively a cross-compilation when the current config.guess is used on EMT64 capable hardware under darwin10. The architecture reported by config.guess is i386 so that configure believes it is working with and generating code for a 32-bit architecture whereas the compiler is silently generating 64-bit code behind configure's back. Not good in concept. Jack ps From my reading of... http://www.gnu.org/prep/standards/html_node/Configuration.html we actually should be passing --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 to configure... > To compile a program to run on a host type that differs from the build type, > use the configure option --host=hosttype, where hosttype uses the same syntax as buildtype. > The host type normally defaults to the build type. > > To configure a cross-compiler, cross-assembler, or what have you, you should specify a > target different from the host, using the configure option ?--target=targettype?. The > syntax for targettype is the same as for the host type. So the command would look like this: > > ./configure --host=hosttype --target=targettype > > The target type normally defaults to the host type. Programs for which cross-operation is > not meaningful need not accept the ?--target? option, because configuring an entire operating > system for cross-operation is not a meaningful operation. If you look at fink 10.4 unstable, you will find that combination is commonly used as... ./configure %c --build=%m-apple-darwin`uname -r|cut -f1 -d.` --host =%m-apple-darwin`uname -r|cut -f1 -d.` to deal with this schizophrenia between the reported and true architecture for EMT64 on darwin10. From toby at macports.org Wed Sep 16 08:36:29 2009 From: toby at macports.org (Toby Peterson) Date: Wed, 16 Sep 2009 08:36:29 -0700 Subject: configure.build_arch In-Reply-To: <20090916134126.GC18976@bromo.med.uc.edu> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <20090916134126.GC18976@bromo.med.uc.edu> Message-ID: <74c219d30909160836n5ef31eaau80ffd8a8d16fc526@mail.gmail.com> On Wed, Sep 16, 2009 at 06:41, Jack Howarth wrote: > On Wed, Sep 16, 2009 at 09:00:46AM +0200, Anders F Bj?rklund wrote: >> Jack Howarth wrote: >> >>> ? ?Reading through the commits on the configure.build_arch feature >>> in port, I am rather surprised that invoking that doesn't also >>> set the triplets for configure as well as passing the -m32 or >>> -m64 compiler flags. Wouldn't you at least want to set >>> --target= to the appropriate value so that configure understood >>> what architecture it was going to build for? I suppose such a >>> change might be an option to patching config.guess for those >>> Portfiles that use configure.build_arch. This would make sure >>> that configure was given --target=x86_64-apple-darwin9/10 >>> when -m64 (or -arch x86_64?) was passed through the invoking >>> configure.build_arch. >> >> We set the triplets back when we were (ab)using +universal >> to do cross-compilation, with the three universal_ flags: >> >> http://lists.macosforge.org/pipermail/macports-dev/2008-February/ >> 004358.html >> >> It never worked very well, so in MacPorts 1.8.0 it was all >> ripped out in favor of the much simpler build_arch solution... >> >> --anders > > Anders, > ? My main concern is that the autoconf folks fully understand > all of the details of darwin10 so that whatever change created > upstream is as well thought out as possible. > ? I still think that anytime port (on at least darwin10) is > passing -m64 or -arch x86_64 to configure, via build_arch, that > we should at least pass --target=x86_64. Currently to configure, > darwin10 acts effectively like a cross-compiler in that the detected triplet > for --host is i386-apple-darwin10 but the actual code generation > is x86_64-apple-darwin10. Simply making sure that the --target > is set by build_arch, so that configure properly understands that actual > code generation being used, should help a lot. > ? ? ? ? ? Jack > ps We are starting to get reponses on autoconf mailing list so hopefully > they cant arrive at a consensus on whether we should pass --target on > darwin10 with the existing config.guess. I would note that Ben > Elliston, the config.guess maintainer, is already on board with > the concept of decoupling the output of config.guess from the > kernel and instead on the code generation of the c compiler > as defined by CC. We will not be passing --target (or --build, for that matter), because we're not cross compiling. When we do begin supporting cross compiling, which is not in the foreseeable future, we can re-evaluate this. Even then, I don't see any reason to, because we've already spent years working around configure results. Unless they completely rearchitect, this isn't going to change. - Toby From toby at macports.org Wed Sep 16 08:38:50 2009 From: toby at macports.org (Toby Peterson) Date: Wed, 16 Sep 2009 08:38:50 -0700 Subject: configure.build_arch In-Reply-To: <20090916151423.GB19732@bromo.med.uc.edu> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <20090916134126.GC18976@bromo.med.uc.edu> <8DA3980D-3ADA-4F7F-90C1-7FCF96AADAE6@macports.org> <20090916151423.GB19732@bromo.med.uc.edu> Message-ID: <74c219d30909160838x1a942660j1be88433ff5ac63b@mail.gmail.com> On Wed, Sep 16, 2009 at 08:14, Jack Howarth wrote: > On Wed, Sep 16, 2009 at 04:45:09PM +0200, Anders F Bj?rklund wrote: >> >> Passing a --target to configure is reasonable, and different from >> patching "config.guess" to return something not from uname(1)... >> (Maybe it changed in Snow Leopard, but it used to detect something >> like "i386-apple-darwin10.0.1" with a lot of decimals like that ?) > > Anders, > ? ?However config.guess upstream still needs to adapt to the new > situation where the default architecture detected in darwin10 via uname -p, > for EMT64 capable hardware, diverges from that of the architecture of > the code genererated by the default system compiler. > >> >> I believe that when you are trying a GNU-style cross-compile >> by setting --target and friends, you also need to set up the >> matching compiler symlinks for this newly invented "platform". >> Normally the system gcc would expect you to use -arch instead ? >> > > My argument is that the current situation is already effectively > a cross-compilation when the current config.guess is used on > EMT64 capable hardware under darwin10. The architecture reported > by config.guess is i386 so that configure believes it is working > with and generating code for a 32-bit architecture whereas the > compiler is silently generating 64-bit code behind configure's > back. Not good in concept. > ? ? ? ? ? ? Jack > ps From my reading of... > > http://www.gnu.org/prep/standards/html_node/Configuration.html > > we actually should be passing --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 > to configure... > >> To compile a program to run on a host type that differs from the build type, >> use the configure option --host=hosttype, where hosttype uses the same syntax as buildtype. >> The host type normally defaults to the build type. >> >> To configure a cross-compiler, cross-assembler, or what have you, you should specify a >> target different from the host, using the configure option ?--target=targettype?. The >> syntax for targettype is the same as for the host type. So the command would look like this: >> >> ? ? ./configure --host=hosttype --target=targettype >> >> The target type normally defaults to the host type. Programs for which cross-operation is >> not meaningful need not accept the ?--target? option, because configuring an entire operating >> system for cross-operation is not a meaningful operation. This goes against everything you've been saying. You're trying to "fix" the output of config.guess (i.e. --build). Why not just pass the "correct" --build flag? You'd only need to use --host and --target if you were cross-compiling, which is not something MacPorts does. > If you look at fink 10.4 unstable, you will find that combination is commonly used as... > > ./configure %c --build=%m-apple-darwin`uname -r|cut -f1 -d.` --host =%m-apple-darwin`uname -r|cut -f1 -d.` > > to deal with this schizophrenia between the reported and true architecture > for EMT64 on darwin10. If you prefer how fink does things, go use fink. - Toby From raimue at macports.org Wed Sep 16 08:42:38 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 16 Sep 2009 17:42:38 +0200 Subject: emulating post install scripts in MacPorts? In-Reply-To: References: <20090916135223.GA19348@bromo.med.uc.edu> Message-ID: <4AB1076E.8060606@macports.org> Ryan Schmidt wrote: > Most ports that need to print such messages do so in the post-activate > phase. I believe you are correct that this will not be shown when > installing from binary archives, but since we have no means to centrally > build and distribute such archives at this time, and everybody builds > from source, this is not a problem. Note that 1.8.0 now also has a 'notes' keyword. Use it like this: notes { You will see this message after installation! } Rainer From howarth at bromo.med.uc.edu Wed Sep 16 09:10:03 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 16 Sep 2009 12:10:03 -0400 Subject: configure.build_arch In-Reply-To: <74c219d30909160838x1a942660j1be88433ff5ac63b@mail.gmail.com> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <20090916134126.GC18976@bromo.med.uc.edu> <8DA3980D-3ADA-4F7F-90C1-7FCF96AADAE6@macports.org> <20090916151423.GB19732@bromo.med.uc.edu> <74c219d30909160838x1a942660j1be88433ff5ac63b@mail.gmail.com> Message-ID: <20090916161003.GA20300@bromo.med.uc.edu> On Wed, Sep 16, 2009 at 08:38:50AM -0700, Toby Peterson wrote: > > If you prefer how fink does things, go use fink. > I am just trying to involve the folks here in the eventual changes implemented upstream so they everyone has some feedback into this. It can only be helpful if the autoconf folks fully understand all of the details of darwin10's behavior as they consider what changes to make. I would note that Bob Friesenhahn mentioned that Solaris supports 32-bit and 64-bit kernels. The config.guess section for that does almost exactly what I am proposing for handling darwin10... i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*) eval $set_cc_for_build SUN_ARCH="i386" # If there is a compiler, see if it is configured for 64-bit objects. # Note that the Sun cc does not turn __LP64__ into 1 like gcc does. # This test works for both compilers. if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then if (echo '#ifdef __amd64'; echo IS_64BIT_ARCH; echo '#endif') | \ (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \ grep IS_64BIT_ARCH >/dev/null then SUN_ARCH="x86_64" fi fi echo ${SUN_ARCH}-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'` exit ;; So it's not likely am coming out of left field with this change to config.guess. The config.guess maintainer thought it a completely rational approach. Jack From toby at macports.org Wed Sep 16 09:12:28 2009 From: toby at macports.org (Toby Peterson) Date: Wed, 16 Sep 2009 09:12:28 -0700 Subject: configure.build_arch In-Reply-To: <20090916161003.GA20300@bromo.med.uc.edu> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <20090916134126.GC18976@bromo.med.uc.edu> <8DA3980D-3ADA-4F7F-90C1-7FCF96AADAE6@macports.org> <20090916151423.GB19732@bromo.med.uc.edu> <74c219d30909160838x1a942660j1be88433ff5ac63b@mail.gmail.com> <20090916161003.GA20300@bromo.med.uc.edu> Message-ID: <74c219d30909160912v7ad79f37l4b35b012a12f634f@mail.gmail.com> On Wed, Sep 16, 2009 at 09:10, Jack Howarth wrote: > On Wed, Sep 16, 2009 at 08:38:50AM -0700, Toby Peterson wrote: >> >> If you prefer how fink does things, go use fink. >> > > I am just trying to involve the folks here in the > eventual changes implemented upstream so they everyone > has some feedback into this. It can only be helpful > if the autoconf folks fully understand all of the > details of darwin10's behavior as they consider what > changes to make. I would note that Bob Friesenhahn > mentioned that Solaris supports 32-bit and 64-bit > kernels. The config.guess section for that does > almost exactly what I am proposing for handling > darwin10... > > ? ?i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*) > ? ? ? ?eval $set_cc_for_build > ? ? ? ?SUN_ARCH="i386" > ? ? ? ?# If there is a compiler, see if it is configured for 64-bit objects. > ? ? ? ?# Note that the Sun cc does not turn __LP64__ into 1 like gcc does. > ? ? ? ?# This test works for both compilers. > ? ? ? ?if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then > ? ? ? ? ? ?if (echo '#ifdef __amd64'; echo IS_64BIT_ARCH; echo '#endif') | \ > ? ? ? ? ? ? ? ?(CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \ > ? ? ? ? ? ? ? ?grep IS_64BIT_ARCH >/dev/null > ? ? ? ? ? ?then > ? ? ? ? ? ? ? ?SUN_ARCH="x86_64" > ? ? ? ? ? ?fi > ? ? ? ?fi > ? ? ? ?echo ${SUN_ARCH}-pc-solaris2`echo ${UNAME_RELEASE}|sed -e 's/[^.]*//'` > ? ? ? ?exit ;; > > So it's not likely am coming out of left field with this > change to config.guess. The config.guess maintainer thought > it a completely rational approach. As I've said multiple times, it really doesn't matter what config.guess says, because we'll have to work around it... same thing we've been doing for years. If you can convince the autoconf folks to change config.guess, that's great - but it doesn't really affect MacPorts. - Toby From afb at macports.org Wed Sep 16 12:47:39 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 16 Sep 2009 21:47:39 +0200 Subject: configure.build_arch In-Reply-To: <20090916151423.GB19732@bromo.med.uc.edu> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <20090916134126.GC18976@bromo.med.uc.edu> <8DA3980D-3ADA-4F7F-90C1-7FCF96AADAE6@macports.org> <20090916151423.GB19732@bromo.med.uc.edu> Message-ID: <1E2C2014-7FE7-4763-B691-75729E87323B@macports.org> Jack Howarth wrote: > However config.guess upstream still needs to adapt to the new > situation where the default architecture detected in darwin10 via > uname -p, > for EMT64 capable hardware, diverges from that of the architecture of > the code genererated by the default system compiler. It just seems that the value of `uname -p` isn't useful for determining the true architecture of the Mac operating system, whether it's on "ppc-apple-darwin8" (that might run ppc64 too) or "i686-apple-darwin10" (that might run x86_64 code as well) And in fact, both Mac platforms are likely to be building more than one arch whether it's ppc+i386 for Tiger or i386+x86_64 for Leopard. So determining just one of them at ./configure time seems to be rather limited - probably better off if done in the code instead ? > My argument is that the current situation is already effectively > a cross-compilation when the current config.guess is used on > EMT64 capable hardware under darwin10. The architecture reported > by config.guess is i386 so that configure believes it is working > with and generating code for a 32-bit architecture whereas the > compiler is silently generating 64-bit code behind configure's > back. Not good in concept. > Jack I just don't think that you can use the detected $build_cpu for anything "useful" on the Mac OS X operating system... Even if CVOG is "ppc-apple-darwin8" or "i686-apple-darwin10", it might still be generating code for something else too ? * CVOG = %{cpu}-%{vendor}-%{os}%{?gnu}, a.k.a. %{platform} Sometimes it is useful to "pretend" to be cross-compiling to another system, by passing --target and setting symlinks, but for the general configure it's close enough with uname(1). Sometimes it breaks, like for FSF GCC, but that's rare enough ? > ps From my reading of... > > http://www.gnu.org/prep/standards/html_node/Configuration.html > > we actually should be passing --host=x86_64-apple-darwin10 -- > target=x86_64-apple-darwin10 > to configure... For this to work in the same GNU-style, you would also need a "x86_64-apple-darwin10-gcc" cross-compiler set up so that you wouldn't have to pass the -m64 (or even -arch x86_64) to get it to generate the proper code for the new --target. I think you mentioned that you had done so with "wrappers" in Fink, but it's not something that comes with the system ? So I don't think that MacPorts will be changing either the installed config.guess or the default --target parameters... --anders From howarth at bromo.med.uc.edu Wed Sep 16 13:02:32 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 16 Sep 2009 16:02:32 -0400 Subject: configure.build_arch In-Reply-To: <1E2C2014-7FE7-4763-B691-75729E87323B@macports.org> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <20090916134126.GC18976@bromo.med.uc.edu> <8DA3980D-3ADA-4F7F-90C1-7FCF96AADAE6@macports.org> <20090916151423.GB19732@bromo.med.uc.edu> <1E2C2014-7FE7-4763-B691-75729E87323B@macports.org> Message-ID: <20090916200232.GA22527@bromo.med.uc.edu> On Wed, Sep 16, 2009 at 09:47:39PM +0200, Anders F Bj?rklund wrote: > > It just seems that the value of `uname -p` isn't useful for > determining the true architecture of the Mac operating system, > whether it's on "ppc-apple-darwin8" (that might run ppc64 too) > or "i686-apple-darwin10" (that might run x86_64 code as well) > Mike Stump (who is the one of the remaining darwin maintainers for FSF gcc) agreed that arch was probably the only thing that should be changed. My radar report for that isn't closed but is marked as a duplicate. If you read over the arch manpage, it really makes sense that arch without arguments should return the 'preferred' architecture and not the 'base' one. If Apple fixed that in Snow Leopard, it would provide quick access to determining the native code type on a Mac. > I just don't think that you can use the detected $build_cpu > for anything "useful" on the Mac OS X operating system... > Even if CVOG is "ppc-apple-darwin8" or "i686-apple-darwin10", > it might still be generating code for something else too ? > > * CVOG = %{cpu}-%{vendor}-%{os}%{?gnu}, a.k.a. %{platform} > > Sometimes it is useful to "pretend" to be cross-compiling > to another system, by passing --target and setting symlinks, > but for the general configure it's close enough with uname(1). > Sometimes it breaks, like for FSF GCC, but that's rare enough ? > Actually I misspoke about what fink does most commonly. They don't pass --target= but rather... --build=%m-apple-darwin`uname -r|cut -f1 -d.` --h ost=%m-apple-darwin`uname -r|cut -f1 -d.` does that make more sense? Jack >> ps From my reading of... >> >> http://www.gnu.org/prep/standards/html_node/Configuration.html >> >> we actually should be passing --host=x86_64-apple-darwin10 -- >> target=x86_64-apple-darwin10 >> to configure... > > > For this to work in the same GNU-style, you would also need > a "x86_64-apple-darwin10-gcc" cross-compiler set up so that > you wouldn't have to pass the -m64 (or even -arch x86_64) > to get it to generate the proper code for the new --target. > > I think you mentioned that you had done so with "wrappers" > in Fink, but it's not something that comes with the system ? > So I don't think that MacPorts will be changing either the > installed config.guess or the default --target parameters... > > --anders From afb at macports.org Wed Sep 16 13:17:49 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Wed, 16 Sep 2009 22:17:49 +0200 Subject: configure.build_arch In-Reply-To: <20090916200232.GA22527@bromo.med.uc.edu> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <20090916134126.GC18976@bromo.med.uc.edu> <8DA3980D-3ADA-4F7F-90C1-7FCF96AADAE6@macports.org> <20090916151423.GB19732@bromo.med.uc.edu> <1E2C2014-7FE7-4763-B691-75729E87323B@macports.org> <20090916200232.GA22527@bromo.med.uc.edu> Message-ID: Jack Howarth wrote: > does that make more sense? Not really (don't think I'd change --build but --target), but then again Fink (or RPM) can do stuff their way... It is my understanding that neither Apple nor MacPorts is going to change the way they do arch/uname/config. And I think cross-compilation is neat when compiling to MinGW (Windows) or to Linux, but probably overkill just for building some 64-bit binaries for regular Mac OS X - whether they are thin/1 or fat/2 or obese/4 binaries ? --anders From howarth at bromo.med.uc.edu Wed Sep 16 13:50:21 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 16 Sep 2009 16:50:21 -0400 Subject: configure.build_arch In-Reply-To: References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <20090916134126.GC18976@bromo.med.uc.edu> <8DA3980D-3ADA-4F7F-90C1-7FCF96AADAE6@macports.org> <20090916151423.GB19732@bromo.med.uc.edu> <1E2C2014-7FE7-4763-B691-75729E87323B@macports.org> <20090916200232.GA22527@bromo.med.uc.edu> Message-ID: <20090916205021.GA22876@bromo.med.uc.edu> On Wed, Sep 16, 2009 at 10:17:49PM +0200, Anders F Bj?rklund wrote: > Jack Howarth wrote: >> does that make more sense? > > Not really (don't think I'd change --build but --target), > but then again Fink (or RPM) can do stuff their way... > It is my understanding that neither Apple nor MacPorts > is going to change the way they do arch/uname/config. > > And I think cross-compilation is neat when compiling to > MinGW (Windows) or to Linux, but probably overkill just > for building some 64-bit binaries for regular Mac OS X - > whether they are thin/1 or fat/2 or obese/4 binaries ? > > --anders Anders, My goal is just to try to keep the logic of the configure machinary as sane as possible for Snow Leopard so that we can co-exist better with the upstream projects. All too often we get dismissed as 'weird' darwin because of linker oddities, etc. like the bug in Snow Leopard's linker where symbols from static libraries, created with 'ranlib -c' to contain common symbol tables, aren't properly ignored when linking against other code which has the same symbols (as a unix linker should). Removing the duplicate code was one of the patches to my proposed fixed gcc44 package (and has already been checked into gcc trunk and gcc 4.4 branch for 4.4.2). Jack From howarth at bromo.med.uc.edu Wed Sep 16 15:59:51 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 16 Sep 2009 18:59:51 -0400 Subject: configure.build_arch In-Reply-To: <20090916205021.GA22876@bromo.med.uc.edu> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <20090916134126.GC18976@bromo.med.uc.edu> <8DA3980D-3ADA-4F7F-90C1-7FCF96AADAE6@macports.org> <20090916151423.GB19732@bromo.med.uc.edu> <1E2C2014-7FE7-4763-B691-75729E87323B@macports.org> <20090916200232.GA22527@bromo.med.uc.edu> <20090916205021.GA22876@bromo.med.uc.edu> Message-ID: <20090916225951.GB23607@bromo.med.uc.edu> The attached patch for config.guess should cover all of the bases for darwin10 and I've sent this to Ben Elliston for review. If a system compiler exists, the default triplet for on Intel darwin is set to the default code generation. In the absence of a compiler, if the system is on darwin10 or later, the sysctl call is used to detect if the processor is EMT64 capable. FYI. Jack -------------- next part -------------- --- config.guess 2009-09-16 18:42:33.000000000 -0400 +++ config.guess.proposed2 2009-09-16 18:45:19.000000000 -0400 @@ -4,7 +4,7 @@ # 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 # Free Software Foundation, Inc. -timestamp='2009-08-19' +timestamp='2009-09-03' # This file is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by @@ -1247,6 +1247,31 @@ *:Darwin:*:*) UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown case $UNAME_PROCESSOR in + i386) + eval $set_cc_for_build + if [ "$CC_FOR_BUILD" != 'no_compiler_found' ]; then + # if system compiler available test by code generation + sed 's/^ //' << EOF >$dummy.c + #if defined(__LP64__) + main() + { + } + #endif +EOF + if test `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep -c main` = 1 ; then + UNAME_PROCESSOR=x86_64 + fi + else + # architecture test in absence of compiler + case `uname -r` in + [1-9].*) ;; + *) + # if darwin10 or later test if EMT64 capable + if test `sysctl -n hw.cpu64bit_capable | grep -c 1` = 1 ; then + UNAME_PROCESSOR=x86_64 + fi ;; + esac + fi ;; unknown) UNAME_PROCESSOR=powerpc ;; esac echo ${UNAME_PROCESSOR}-apple-darwin${UNAME_RELEASE} From ryandesign at macports.org Wed Sep 16 16:49:39 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 16 Sep 2009 18:49:39 -0500 Subject: [57800] trunk/dports/devel/lua-numlua In-Reply-To: <20090916202537.CFCC1276DAD7@beta.macosforge.org> References: <20090916202537.CFCC1276DAD7@beta.macosforge.org> Message-ID: <3D25702E-1F54-41B2-B33D-FEFE5A842981@macports.org> On Sep 16, 2009, at 15:25, and.damore at macports.org wrote: > Revision: 57800 > http://trac.macports.org/changeset/57800 > Author: and.damore at macports.org > Date: 2009-09-16 13:25:37 -0700 (Wed, 16 Sep 2009) > Log Message: > ----------- > update lua-numlua to 0.2.1, closing #16041 > Modified: trunk/dports/devel/lua-numlua/Portfile > post-patch { > - reinplace "s|@PREFIX@|${prefix}|g" ${worksrcpath}/Makefile > - reinplace "s|@PREFIX@|${prefix}|g" ${worksrcpath}/lib/config > - reinplace "s|@PREFIX@|${prefix}|g" ${worksrcpath}/src/Makefile > + reinplace "s|@PREFIX@|${prefix}|g" ${worksrcpath}/Makefile > + reinplace "s|@PREFIX@|${prefix}|g" ${worksrcpath}/lib/config > + reinplace "s|@PREFIX@|${prefix}|g" ${worksrcpath}/src/Makefile > } > Modified: trunk/dports/devel/lua-numlua/files/patch-Makefile > -+INSTALL_ROOT = @PREFIX@ > ++INSTALL_ROOT = /opt/local It looks like this line should not have been changed. From howarth at bromo.med.uc.edu Wed Sep 16 17:00:28 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 16 Sep 2009 20:00:28 -0400 Subject: oddity building ports with archiving Message-ID: <20090917000028.GA24028@bromo.med.uc.edu> I've noticed an oddity while building local ports under MacPorts 1.8.0 with the archiving feature enabled. It appears that if one is modifying the Portfile without constantly bumping the revision number that the 'clean' command is insufficient to purge the previous tgz archive of the package. This means that while 'sudo port build' works as expected when 'sudo port install' is executed the tgz is not recreated. Shouldn't 'sudo port clean' remove the archives associated with the Portfile? Otherwise when archive is enabled it seems one has to constantly delete the archive manually between builds. Or am I missing something here? Jack From keybounce at gmail.com Wed Sep 16 17:03:32 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Wed, 16 Sep 2009 17:03:32 -0700 Subject: configure.build_arch In-Reply-To: <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> Message-ID: <1bd71ad80909161703x195ff94fs630f3cd01f86bf7d@mail.gmail.com> > We set the triplets back when we were (ab)using +universal > to do cross-compilation, with the three universal_ flags: > > http://lists.macosforge.org/pipermail/macports-dev/2008-February/004358.html > > It never worked very well, so in MacPorts 1.8.0 it was all > ripped out in favor of the much simpler build_arch solution... Is this why NCursesW fails? At all related to Glib? From kthenriksson at gmail.com Wed Sep 16 17:10:43 2009 From: kthenriksson at gmail.com (Kristofer Henriksson) Date: Wed, 16 Sep 2009 20:10:43 -0400 Subject: oddity building ports with archiving In-Reply-To: <20090917000028.GA24028@bromo.med.uc.edu> References: <20090917000028.GA24028@bromo.med.uc.edu> Message-ID: <4809057c0909161710l7b213ea8l4c0ee2db28e57c5b@mail.gmail.com> Try port clean --all. Normally port clean only removes the work directory for a port. On Wed, Sep 16, 2009 at 8:00 PM, Jack Howarth wrote: > ? I've noticed an oddity while building local ports > under MacPorts 1.8.0 with the archiving feature enabled. > It appears that if one is modifying the Portfile without > constantly bumping the revision number that the 'clean' > command is insufficient to purge the previous tgz archive > of the package. This means that while 'sudo port build' > works as expected when 'sudo port install' is executed > the tgz is not recreated. Shouldn't 'sudo port clean' > remove the archives associated with the Portfile? Otherwise > when archive is enabled it seems one has to constantly > delete the archive manually between builds. Or am I missing > something here? > ? ? ? ? Jack > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From toby at macports.org Wed Sep 16 17:27:03 2009 From: toby at macports.org (Toby Peterson) Date: Wed, 16 Sep 2009 17:27:03 -0700 Subject: configure.build_arch In-Reply-To: <1bd71ad80909161703x195ff94fs630f3cd01f86bf7d@mail.gmail.com> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <1bd71ad80909161703x195ff94fs630f3cd01f86bf7d@mail.gmail.com> Message-ID: <74c219d30909161727n5cb0a15dt20195e19209f6bb5@mail.gmail.com> On Wed, Sep 16, 2009 at 17:03, Michael_google gmail_Gersten wrote: >> We set the triplets back when we were (ab)using +universal >> to do cross-compilation, with the three universal_ flags: >> >> http://lists.macosforge.org/pipermail/macports-dev/2008-February/004358.html >> >> It never worked very well, so in MacPorts 1.8.0 it was all >> ripped out in favor of the much simpler build_arch solution... > > Is this why NCursesW fails? At all related to Glib? Please file tickets about ports that fail to build. I know ncursesw builds fine. Not sure about glib2 - but given that we don't have (reproducible) build failures reported for glib2, I believe it's working in general. - Toby From keybounce at gmail.com Wed Sep 16 17:48:58 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Wed, 16 Sep 2009 17:48:58 -0700 Subject: configure.build_arch In-Reply-To: <74c219d30909161727n5cb0a15dt20195e19209f6bb5@mail.gmail.com> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <1bd71ad80909161703x195ff94fs630f3cd01f86bf7d@mail.gmail.com> <74c219d30909161727n5cb0a15dt20195e19209f6bb5@mail.gmail.com> Message-ID: <1bd71ad80909161748k2b7eab97o143affbee5beb3cb@mail.gmail.com> >> Is this why NCursesW fails? At all related to Glib? > > Please file tickets about ports that fail to build. I know ncursesw > builds fine. Not sure about glib2 - but given that we don't have > (reproducible) build failures reported for glib2, I believe it's > working in general. > > - Toby NCursesW does NOT build universal on ppc. Glib2's currently open ticket is # #20372 I reported ncursesw here -- 10 days ago to the maintainer, 8 days ago with a solution to the list. It thinks it is doing cross compilation, but the cross compilation fails because it doesn't trigger the cross compilation test. If you are on PPC, building universal for i386, then: [quote] Nope, turns out it needs CFLAGS='-arch i386' CXXFLAGS='-arch i386' To clarify: The old build was specifying the cross compiler flags correctly, but was NOT specifying the build arch. Hence, the cross compiler test did not come out correct, and the program does not build. [/quote] I have just opened ncursesw Ticket #21434 (new defect) Ncursesw thinks that if you can execute code produced by the compiler, then you specified the local compiler, not the cross compiler. Not sure how or if this will prevent x86 from compiling universal (does Rosetta activate on unix executables, or just applications?) From toby at macports.org Wed Sep 16 17:52:14 2009 From: toby at macports.org (Toby Peterson) Date: Wed, 16 Sep 2009 17:52:14 -0700 Subject: configure.build_arch In-Reply-To: <1bd71ad80909161748k2b7eab97o143affbee5beb3cb@mail.gmail.com> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <1bd71ad80909161703x195ff94fs630f3cd01f86bf7d@mail.gmail.com> <74c219d30909161727n5cb0a15dt20195e19209f6bb5@mail.gmail.com> <1bd71ad80909161748k2b7eab97o143affbee5beb3cb@mail.gmail.com> Message-ID: <74c219d30909161752s60633ea5t27aa8af5837a0096@mail.gmail.com> On Wed, Sep 16, 2009 at 17:48, Michael_google gmail_Gersten wrote: >>> Is this why NCursesW fails? At all related to Glib? >> >> Please file tickets about ports that fail to build. I know ncursesw >> builds fine. Not sure about glib2 - but given that we don't have >> (reproducible) build failures reported for glib2, I believe it's >> working in general. >> >> - Toby > > NCursesW does NOT build universal on ppc. > Glib2's currently open ticket is # #20372 Ok, your situation is special because you're trying to build universal *and* you're on ppc. That's a pretty doomed combination. Building i386/ppc universal on ppc is quite unlikely to work for many ports. Also, this is entirely irrelevant to this thread. - Toby From ryandesign at macports.org Wed Sep 16 18:24:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 16 Sep 2009 20:24:35 -0500 Subject: configure.build_arch In-Reply-To: <1bd71ad80909161748k2b7eab97o143affbee5beb3cb@mail.gmail.com> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <1bd71ad80909161703x195ff94fs630f3cd01f86bf7d@mail.gmail.com> <74c219d30909161727n5cb0a15dt20195e19209f6bb5@mail.gmail.com> <1bd71ad80909161748k2b7eab97o143affbee5beb3cb@mail.gmail.com> Message-ID: On Sep 16, 2009, at 19:48, Michael_google gmail_Gersten wrote: > (does Rosetta activate on unix executables, or just applications?) Yes, Rosetta can translate unix executables too. From ryandesign at macports.org Wed Sep 16 18:26:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 16 Sep 2009 20:26:38 -0500 Subject: oddity building ports with archiving In-Reply-To: <4809057c0909161710l7b213ea8l4c0ee2db28e57c5b@mail.gmail.com> References: <20090917000028.GA24028@bromo.med.uc.edu> <4809057c0909161710l7b213ea8l4c0ee2db28e57c5b@mail.gmail.com> Message-ID: <9EB87EDB-1BF6-461C-80F7-667E5ACC2B38@macports.org> On Sep 16, 2009, at 19:10, Kristofer Henriksson wrote: > On Wed, Sep 16, 2009 at 8:00 PM, Jack Howarth wrote: > >> I've noticed an oddity while building local ports >> under MacPorts 1.8.0 with the archiving feature enabled. >> It appears that if one is modifying the Portfile without >> constantly bumping the revision number that the 'clean' >> command is insufficient to purge the previous tgz archive >> of the package. This means that while 'sudo port build' >> works as expected when 'sudo port install' is executed >> the tgz is not recreated. Shouldn't 'sudo port clean' >> remove the archives associated with the Portfile? Otherwise >> when archive is enabled it seems one has to constantly >> delete the archive manually between builds. Or am I missing >> something here? > > Try port clean --all. Normally port clean only removes the work > directory for a port. "clean" by itself means "clean --work". You don't need "clean -- all" (it will delete your distfiles too which you'll then have to redownload); "clean --archive" is sufficient. From keybounce at gmail.com Wed Sep 16 18:54:08 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Wed, 16 Sep 2009 18:54:08 -0700 Subject: PPC / i386 universal building Message-ID: <1bd71ad80909161854i30a4eba5y80143171da5e59b3@mail.gmail.com> On Wed, Sep 16, 2009 at 5:52 PM, Toby Peterson wrote: > Ok, your situation is special because you're trying to build universal > *and* you're on ppc. That's a pretty doomed combination. Building > i386/ppc universal on ppc is quite unlikely to work for many ports. Prior to snow leopard, universal included ppc/i386 building. Those of us still on 10.5 will still need this. If 1.8 is unable to reliably build universal on ppc, then is there a way to go back to the earlier version (1.7.xx), or is the port tree and port program tied together such that 1.7 won't work anymore? More to the point, is there any way to build ppc/i386 universal apps? 10.6 won't produce these at all, as I understand it; will 10.5 on x86 hardware produce ppc/i386 universals with the current macports? From toby at macports.org Wed Sep 16 19:01:33 2009 From: toby at macports.org (Toby Peterson) Date: Wed, 16 Sep 2009 19:01:33 -0700 Subject: PPC / i386 universal building In-Reply-To: <1bd71ad80909161854i30a4eba5y80143171da5e59b3@mail.gmail.com> References: <1bd71ad80909161854i30a4eba5y80143171da5e59b3@mail.gmail.com> Message-ID: <74c219d30909161901i61022585l6c0bf68eacdf7650@mail.gmail.com> On Wed, Sep 16, 2009 at 18:54, Michael_google gmail_Gersten wrote: > On Wed, Sep 16, 2009 at 5:52 PM, Toby Peterson wrote: >> Ok, your situation is special because you're trying to build universal >> *and* you're on ppc. That's a pretty doomed combination. Building >> i386/ppc universal on ppc is quite unlikely to work for many ports. > > Prior to snow leopard, universal included ppc/i386 building. Those of > us still on 10.5 will still need this. > > If 1.8 is unable to reliably build universal on ppc, then is there a > way to go back to the earlier version (1.7.xx), or is the port tree > and port program tied together such that 1.7 won't work anymore? > > More to the point, is there any way to build ppc/i386 universal apps? > 10.6 won't produce these at all, as I understand it; will 10.5 on x86 > hardware produce ppc/i386 universals with the current macports? The problem isn't related to the version of Mac OS X or MacPorts - it's actually because of the number of ports using the "muniversal" group. This causes ports to try building each section independently, thus making it rather difficult to correctly build for architectures your machine cannot execute. - Toby From jmr at macports.org Wed Sep 16 19:02:10 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 17 Sep 2009 12:02:10 +1000 Subject: PPC / i386 universal building In-Reply-To: <1bd71ad80909161854i30a4eba5y80143171da5e59b3@mail.gmail.com> References: <1bd71ad80909161854i30a4eba5y80143171da5e59b3@mail.gmail.com> Message-ID: <4AB198A2.5060008@macports.org> On 2009-9-17 11:54, Michael_google gmail_Gersten wrote: > On Wed, Sep 16, 2009 at 5:52 PM, Toby Peterson wrote: >> Ok, your situation is special because you're trying to build universal >> *and* you're on ppc. That's a pretty doomed combination. Building >> i386/ppc universal on ppc is quite unlikely to work for many ports. > > Prior to snow leopard, universal included ppc/i386 building. Those of > us still on 10.5 will still need this. Can't imagine why, but I'll take your word for it. > If 1.8 is unable to reliably build universal on ppc, then is there a > way to go back to the earlier version (1.7.xx), or is the port tree > and port program tied together such that 1.7 won't work anymore? Building universal on ppc still works as well as it ever did. > More to the point, is there any way to build ppc/i386 universal apps? > 10.6 won't produce these at all, as I understand it; will 10.5 on x86 > hardware produce ppc/i386 universals with the current macports? Xcode 3.2, and by extension MacPorts, is capable of building for all the archs that Xcode 3.1 could. The one caveat is that you can't target an older OS version with MacPorts. - Josh From howarth at bromo.med.uc.edu Wed Sep 16 20:41:05 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 16 Sep 2009 23:41:05 -0400 Subject: how many tcl/tk's in 1.8.0? Message-ID: <20090917034105.GA25267@bromo.med.uc.edu> I ported the sparky 3.115 NMR assignment program using the same build approach from fink (where I maintained the package). I am unclear on whether I need to code the Portfile to support more than just builds against tcl/tk 8.5 (which is what MacPorts 1.8.0 installed on my Snow Leopard box). Looking at the MacPorts database, it appears that only a single tcl/tk is available (8.5). Is that correct? If so I'll move the tcl/tk version changes into the build patch. Jack From ryandesign at macports.org Wed Sep 16 20:52:33 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 16 Sep 2009 22:52:33 -0500 Subject: how many tcl/tk's in 1.8.0? In-Reply-To: <20090917034105.GA25267@bromo.med.uc.edu> References: <20090917034105.GA25267@bromo.med.uc.edu> Message-ID: On Sep 16, 2009, at 22:41, Jack Howarth wrote: > I ported the sparky 3.115 NMR assignment program > using the same build approach from fink (where I > maintained the package). I am unclear on whether I > need to code the Portfile to support more than just > builds against tcl/tk 8.5 (which is what MacPorts > 1.8.0 installed on my Snow Leopard box). Looking > at the MacPorts database, it appears that only a > single tcl/tk is available (8.5). Is that correct? Yes. When 8.5 first came out there was some software that needed 8.4 and we thought about making tcl84 and tk84 ports but the software in question ended up being upgraded to be 8.5-compatible so we dispensed with it and kept just the 8.5 version. From raimue at macports.org Wed Sep 16 23:22:33 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Thu, 17 Sep 2009 08:22:33 +0200 Subject: [57801] trunk/base/src/port1.0/portinstall.tcl In-Reply-To: <20090916204607.8A035276ED4C@beta.macosforge.org> References: <20090916204607.8A035276ED4C@beta.macosforge.org> Message-ID: <4AB1D5A9.8000708@macports.org> On 2009-09-16 22:46 , jmr at macports.org wrote: > Revision: 57801 > http://trac.macports.org/changeset/57801 > Author: jmr at macports.org > Date: 2009-09-16 13:46:03 -0700 (Wed, 16 Sep 2009) > Log Message: > ----------- > don't record install in the statefile This is a bad change as setting target_state to no also removes the variants checks against the statefile. That means you can now run port destroot +foo and then port install +bar, which effectively installs +foo but recording +bar in the registry. Instead, we want to set target_runtype to always which prevents recording in the statefile, but still does the variants checks. Done in r57820. Rainer From afb at macports.org Thu Sep 17 00:06:30 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 17 Sep 2009 09:06:30 +0200 Subject: oddity building ports with archiving In-Reply-To: <20090917000028.GA24028@bromo.med.uc.edu> References: <20090917000028.GA24028@bromo.med.uc.edu> Message-ID: <0E7B64CF-5BBE-45B1-AB12-C4F63EEFDC87@macports.org> Jack Howarth wrote: > I've noticed an oddity while building local ports > under MacPorts 1.8.0 with the archiving feature enabled. > [...] Otherwise > when archive is enabled it seems one has to constantly > delete the archive manually between builds. Or am I missing > something here? This is a change introduced with MacPorts 1.8.0, as previously it would overwrite the old archive: - When archive mode is enabled, ports will no longer be rebuilt if an archive is available. (#10785, jmr in r50416) http://trac.macports.org/ticket/10785 http://trac.macports.org/changeset/50416 So yeah, you will have to clean it manually - there is no "force" or "rearchive" option yet. --anders From afb at macports.org Thu Sep 17 00:33:56 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 17 Sep 2009 09:33:56 +0200 Subject: configure.build_arch In-Reply-To: <1bd71ad80909161703x195ff94fs630f3cd01f86bf7d@mail.gmail.com> References: <20090915212300.GA12997@bromo.med.uc.edu> <5CB362A9-6BFC-4822-86CE-D39BD0323397@macports.org> <1bd71ad80909161703x195ff94fs630f3cd01f86bf7d@mail.gmail.com> Message-ID: <6B4D5B36-73E2-421E-A46D-E38D36A89C3D@macports.org> Michael_google gmail_Gersten wrote: >> We set the triplets back when we were (ab)using +universal >> to do cross-compilation, with the three universal_ flags: >> >> http://lists.macosforge.org/pipermail/macports-dev/2008-February/ >> 004358.html >> >> It never worked very well, so in MacPorts 1.8.0 it was all >> ripped out in favor of the much simpler build_arch solution... > > Is this why NCursesW fails? At all related to Glib? Not really, you should still be able to do +universal builds (i386/ppc) on Tiger and Leopard without doing cross-compilation. If "possible" that is, some software requires that host tools are run during the build and thus require Rosetta to do so... It was the "real" cross-compilation, like building for Tiger (10.4u SDK) on Leopard, or for Panther (ppc) on Tiger (i386) ? Using +universal to build "fat" binaries for either ppc+i386 or i386+x86_64 works bad enough without crossing OS boundaries. Sometimes the cure is indeed a lot worse than the disease... "Doctor, it hurts when I am using MacPorts to build Universal." --anders From howarth at bromo.med.uc.edu Thu Sep 17 06:05:21 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Thu, 17 Sep 2009 09:05:21 -0400 Subject: how many tcl/tk's in 1.8.0? In-Reply-To: References: <20090917034105.GA25267@bromo.med.uc.edu> Message-ID: <20090917130521.GA28849@bromo.med.uc.edu> On Wed, Sep 16, 2009 at 10:52:33PM -0500, Ryan Schmidt wrote: > > On Sep 16, 2009, at 22:41, Jack Howarth wrote: > >> I ported the sparky 3.115 NMR assignment program >> using the same build approach from fink (where I >> maintained the package). I am unclear on whether I >> need to code the Portfile to support more than just >> builds against tcl/tk 8.5 (which is what MacPorts >> 1.8.0 installed on my Snow Leopard box). Looking >> at the MacPorts database, it appears that only a >> single tcl/tk is available (8.5). Is that correct? > > Yes. When 8.5 first came out there was some software that needed 8.4 and > we thought about making tcl84 and tk84 ports but the software in > question ended up being upgraded to be 8.5-compatible so we dispensed > with it and kept just the 8.5 version. > > Fine by me. On fink, the transition from tcl 8.4 to 8.5 has never happened for i386 or powerpc fink but only on x86_64. FYI, I was helping them debug an issue with the fink blt package on tcltk 8.5 yesterday. It looks like the same issue as http://trac.macports.org/ticket/15095. The proper fix backported from Fedora 12 is added to the ticket... http://trac.macports.org/attachment/ticket/15095/blt2.4z-noexactversion.patch For 64-bit compatibility, the blt package also needs to use the Fedora 12 patch added here... http://trac.macports.org/attachment/ticket/15095/blt2.4z-patch-64 I added the last to tbe blt package I maintained in fink and found the first one yesterday in current Fedora rawhide. FYI. Jack From jeremy at lavergne.gotdns.org Thu Sep 17 07:34:02 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 17 Sep 2009 10:34:02 -0400 Subject: oddity building ports with archiving In-Reply-To: <0E7B64CF-5BBE-45B1-AB12-C4F63EEFDC87@macports.org> References: <20090917000028.GA24028@bromo.med.uc.edu> <0E7B64CF-5BBE-45B1-AB12-C4F63EEFDC87@macports.org> Message-ID: >> I've noticed an oddity while building local ports under MacPorts >> 1.8.0 with the archiving feature enabled. > >> [...] Otherwise >> when archive is enabled it seems one has to constantly delete the >> archive manually between builds. Or am I missing something here? > > This is a change introduced with MacPorts 1.8.0, as previously it > would overwrite the old archive: > ... > So yeah, you will have to clean it manually - there is no "force" or > "rearchive" option yet. To do so: sudo port clean --archive PORTNAME From afb at macports.org Thu Sep 17 07:43:06 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 17 Sep 2009 16:43:06 +0200 Subject: oddity building ports with archiving In-Reply-To: References: <20090917000028.GA24028@bromo.med.uc.edu> <0E7B64CF-5BBE-45B1-AB12-C4F63EEFDC87@macports.org> Message-ID: <83FB6BC0-E0B6-4822-A118-00DD72708AFE@macports.org> Jeremy Lavergne wrote: >> So yeah, you will have to clean it manually - there is no "force" >> or "rearchive" option yet. > > To do so: > sudo port clean --archive PORTNAME That was the inferred "manual" part. But no option to the archive command ? --anders From raimue at macports.org Thu Sep 17 07:54:31 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 17 Sep 2009 16:54:31 +0200 Subject: oddity building ports with archiving In-Reply-To: <83FB6BC0-E0B6-4822-A118-00DD72708AFE@macports.org> References: <20090917000028.GA24028@bromo.med.uc.edu> <0E7B64CF-5BBE-45B1-AB12-C4F63EEFDC87@macports.org> <83FB6BC0-E0B6-4822-A118-00DD72708AFE@macports.org> Message-ID: <4AB24DA7.4020905@macports.org> On 2009-09-17 16:43 , Anders F Bj?rklund wrote: > Jeremy Lavergne wrote: > >>> So yeah, you will have to clean it manually - there is no "force" >>> or "rearchive" option yet. >> >> To do so: >> sudo port clean --archive PORTNAME > > That was the inferred "manual" part. > > But no option to the archive command ? Are you thinking of something like archive --overwrite PORTNAME? That does not exist yet, but I think that would be a good idea. Rainer From ryandesign at macports.org Thu Sep 17 08:03:00 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 17 Sep 2009 10:03:00 -0500 Subject: [57851] trunk/dports/math/atlas/Portfile In-Reply-To: <20090917145401.B67B2278F020@beta.macosforge.org> References: <20090917145401.B67B2278F020@beta.macosforge.org> Message-ID: <35C87392-777F-48F2-ABA6-41BF75A40BB6@macports.org> On Sep 17, 2009, at 09:54, jameskyle at macports.org wrote: > Modified: trunk/dports/math/atlas/Portfile > +if {${build_arch} == "x86_64" || ${build_arch} == "ppc64" } { > + set my_arch 64 > +} else { > + set my_arch 32 > +} I would suggest using a variable name here that doesn't use the word "arch" since that's understood to mean the machine architecture, i.e. ppc, i386, ppc64 or x86_64. It's also confusing to have two variables, my_arch and myarch, which are different things. > if {[string equal "${os.arch}" "powerpc"]} { > - set myarch "ppc" > - } { > - set myarch "i386" > + if {${my_arch} == "64" } { > + set myarch "ppc64" > + } else { > + set myarch "ppc" > } > + } else { > + if {${my_arch} == "64" } { > + set myarch "x86_64" > + } else { > + set myarch "i386" > + } > + } So isn't ${myarch} now the same thing as ${build_arch}, and couldn't you just use ${build_arch}? From afb at macports.org Thu Sep 17 08:09:06 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 17 Sep 2009 17:09:06 +0200 Subject: oddity building ports with archiving In-Reply-To: <4AB24DA7.4020905@macports.org> References: <20090917000028.GA24028@bromo.med.uc.edu> <0E7B64CF-5BBE-45B1-AB12-C4F63EEFDC87@macports.org> <83FB6BC0-E0B6-4822-A118-00DD72708AFE@macports.org> <4AB24DA7.4020905@macports.org> Message-ID: <4BC212BD-6F7D-4ECB-8BF3-5C2F481C2237@macports.org> >> >> But no option to the archive command ? > > Are you thinking of something like archive --overwrite PORTNAME? That > does not exist yet, but I think that would be a good idea. I'm thinking "timestamps", but yeah it would be nice to be able to get the old functionality back when testing packages. Either "archive --force" (or --overwrite) or something like fink rebuild. I'm not sure why following state wasn't enough ? Now, even if you clear the port and start the build over it will still ignore the archiving just because it has been done before. Of course this is all assuming that the archiving also has some packaging qualities and not just a side-effect of installing... --anders From ryandesign at macports.org Thu Sep 17 08:44:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 17 Sep 2009 10:44:29 -0500 Subject: [57854] trunk/dports/www/phpmyadmin/Portfile In-Reply-To: <20090917153616.4A8BA278F917@beta.macosforge.org> References: <20090917153616.4A8BA278F917@beta.macosforge.org> Message-ID: <6A0A6DC2-95E0-4336-91E5-8EC11E4D5D56@macports.org> On Sep 17, 2009, at 10:36, alakazam at macports.org wrote: > Revision: 57854 > http://trac.macports.org/changeset/57854 > Author: alakazam at macports.org > Date: 2009-09-17 08:36:12 -0700 (Thu, 17 Sep 2009) > Log Message: > ----------- > Upgrade phpMyAdmin to 3.2.2 and correctly create a configuration > file in ${prefix}/etc/ so that upgrading won't destroy previous > configuration files. Closes tickets #21437 and #20769. > Modified: trunk/dports/www/phpmyadmin/Portfile > destroot { > - xinstall -d -m 0755 ${docpath}/phpmyadmin > - eval copy [glob ${worksrcpath}/*] ${docpath}/phpmyadmin > + xinstall -d -m 0755 ${docroot} > + eval copy [glob ${worksrcpath}/*] ${docroot} > + > + ln -s ${configfile} ${docroot}/config.inc.php > + > + if {![file exists ${configfile}]} { > + xinstall -m 644 ${worksrcpath}/config.sample.inc.php $ > {configfile} > + > + ui_msg "A new configuration file has been created at $ > {configfile}." > + ui_msg "Please refer to the ${my_name} documentation when > editing this file," > + ui_msg "an online version of which can be found at $ > {homepage}documentation/Documentation.html#config" > + ui_msg "" > + } > } If you need to create files (like config files) outside of the destroot, you should do so in the post-activate phase, not in the destroot phase. From howarth at bromo.med.uc.edu Thu Sep 17 08:55:22 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Thu, 17 Sep 2009 11:55:22 -0400 Subject: why Mesa glut? Message-ID: <20090917155522.GA30060@bromo.med.uc.edu> I am starting to wonder if the breakage I am seeing with my proposed molmol package isn't in fact due to the usage of Mesa glut in MacPorts. Why exactly are we using Mesa glut instead of freeglut (which I thought almost all linux distros had standardized on)? I will try creating a freeglut package for MacPorts and build molmol against that to see if the missing interface widgets suddenly appear. Jack From ryandesign at macports.org Thu Sep 17 09:51:44 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 17 Sep 2009 11:51:44 -0500 Subject: [MacPorts] #21437: The MAMP howto doesn't match the sample phpMyAdmin config file In-Reply-To: <389B9371-B6FE-498C-B420-036B889E80EE@mac.com> References: <052.822b01b093ac429a1a186ce38b4d504f@macports.org> <061.5e1ddb1776a10cdc39df43b60f5ba0db@macports.org> <389B9371-B6FE-498C-B420-036B889E80EE@mac.com> Message-ID: On Sep 17, 2009, at 11:48, Steve Meether wrote: > Hello, > > So how do I set the password for access to phpMyAdmin? Do I simply > add the following lines? Years ago when I used phpMyAdmin, those lines were in the config file and you would modify them to suit. If those lines are no longer in the config file of today's phpMyAdmin then they have changed things. Consult the phpMyAdmin documentation, and when you find the answer, let us know, or edit the wiki page yourself to fix it. > This will create a file config.inc.php in the phpMyAdmin folder. > Edit that file, and locate the lines: > > $cfg['Servers'][$i]['auth_type'] = 'config'; // > Authentication method (config, http or cookie based)? > $cfg['Servers'][$i]['user'] = 'root'; // MySQL user > $cfg['Servers'][$i]['password'] = ''; // MySQL > password (only needed > // with 'config' > auth_type) > > Where ' ' is an empty password; fill it with your MySQL root > password. You can either change the 'auth_type' from 'config' to > 'cookie' or 'httpd', or alternatively provide the password you > selected for the root user in the 'password' option. > > > > Please advise, > > -Steve > > > > On Sep 17, 2009, at 9:47 AM, MacPorts wrote: > >> #21437: The MAMP howto doesn't match the sample phpMyAdmin config >> file >> ------------------------------ >> +--------------------------------------------- >> Reporter: steve404@? | Owner: alakazam@? >> Type: defect | Status: assigned >> Priority: Normal | Milestone: >> Component: wiki | Version: 1.8.0 >> Keywords: | Port: phpmyadmin >> ------------------------------ >> +--------------------------------------------- >> >> Comment(by ryandesign@?): >> >> I've worked on the ports that comprise the MAMP stack, but the MAMP >> guide >> in the wiki was created by someone else. I read through it recently >> and >> made a lot of adjustments for clarity and changes that had occurred >> in the >> MAMP ports, but that's about it. I haven't used phpMyAdmin in years >> so I >> don't know how it's changed lately. >> >> One thought I had was that the MAMP guide tells the user to create >> the >> file httpd-phpmyadmin.conf with a certain contents. I would suggest >> that >> it should instead be the phpMyAdmin port's responsibility to do that. >> >> -- >> Ticket URL: >> MacPorts >> Ports system for Mac OS > From and.damore at macports.org Thu Sep 17 09:52:11 2009 From: and.damore at macports.org (Andrea D'Amore) Date: Thu, 17 Sep 2009 18:52:11 +0200 Subject: [57800] trunk/dports/devel/lua-numlua In-Reply-To: <3D25702E-1F54-41B2-B33D-FEFE5A842981@macports.org> References: <20090916202537.CFCC1276DAD7@beta.macosforge.org> <3D25702E-1F54-41B2-B33D-FEFE5A842981@macports.org> Message-ID: <48F78A36-D540-4CB0-B14A-D32CDC0BB3E8@macports.org> On 17/set/09, at 01:49, Ryan Schmidt wrote: >> -+INSTALL_ROOT = @PREFIX@ >> ++INSTALL_ROOT = /opt/local > > It looks like this line should not have been changed. Indeed, probably I diffed a post-patch tree against the original file. Fixed in r57859. -- A. From wsiegrist at apple.com Thu Sep 17 10:50:18 2009 From: wsiegrist at apple.com (William Siegrist) Date: Thu, 17 Sep 2009 10:50:18 -0700 Subject: Guide Regen Failure on Thursday 2009-09-17 at 01:58:13 In-Reply-To: <20090917085813.A136A3662774@gamma.macosforge.org> References: <20090917085813.A136A3662774@gamma.macosforge.org> Message-ID: FYI... the 2 guide regen failures were due to 3 commits to doc-new happening faster than the first one could finish. Rainer's commit later on fixed it up and I just regenerated again to be sure. Thanks -Bill On Sep 17, 2009, at 1:58 AM, superwww wrote: > Guide Regen lockfile found, is another regen job running? From keybounce at gmail.com Thu Sep 17 10:55:25 2009 From: keybounce at gmail.com (Michael_google gmail_Gersten) Date: Thu, 17 Sep 2009 10:55:25 -0700 Subject: Why does gettext require curses? Message-ID: <1bd71ad80909171055v23aca627y809d40af0c88961f@mail.gmail.com> Why does gettext -- a library dealing with looking up translation strings in a database -- need ncurses -- a library for displaying text on terminal screens? Can this dependency be removed? It seems very, very odd. From ryandesign at macports.org Thu Sep 17 10:59:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 17 Sep 2009 12:59:28 -0500 Subject: Why does gettext require curses? In-Reply-To: <1bd71ad80909171055v23aca627y809d40af0c88961f@mail.gmail.com> References: <1bd71ad80909171055v23aca627y809d40af0c88961f@mail.gmail.com> Message-ID: <00F80FC1-978F-4221-AE6E-D3100AF554DA@macports.org> On Sep 17, 2009, at 12:55, Michael_google gmail_Gersten wrote: > Why does gettext -- a library dealing with looking up translation > strings in a database -- need ncurses -- a library for displaying text > on terminal screens? > > Can this dependency be removed? It seems very, very odd. The ncurses dependency was added to gettext in r32719. The DEPENDENCIES file says: * GNU ncurses (preferred) or libtermcap (discouraged) or a curses library (legacy). + Highly recommended. Needed for the --color option of the 'msgcat' program. + Homepage: http://www.gnu.org/software/ncurses/ + Download: http://ftp.gnu.org/gnu/ncurses/ ftp://ftp.gnu.org/gnu/ncurses/ + If it is installed in a nonstandard directory, pass the option --with-ncurses-prefix=DIR or --with-libtermcap-prefix to 'configure'. From landonf at macports.org Thu Sep 17 11:43:04 2009 From: landonf at macports.org (Landon Fuller) Date: Thu, 17 Sep 2009 11:43:04 -0700 Subject: [57854] trunk/dports/www/phpmyadmin/Portfile In-Reply-To: <6A0A6DC2-95E0-4336-91E5-8EC11E4D5D56@macports.org> References: <20090917153616.4A8BA278F917@beta.macosforge.org> <6A0A6DC2-95E0-4336-91E5-8EC11E4D5D56@macports.org> Message-ID: On Sep 17, 2009, at 8:44 AM, Ryan Schmidt wrote: > On Sep 17, 2009, at 10:36, alakazam at macports.org wrote: > > > If you need to create files (like config files) outside of the > destroot, you should do so in the post-activate phase, not in the > destroot phase. I believe the (documented? defacto?) standard is that example configuration files should be installed in destroot phase with a .sample extension. -landonf -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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 ryandesign at macports.org Thu Sep 17 12:08:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 17 Sep 2009 14:08:08 -0500 Subject: [57854] trunk/dports/www/phpmyadmin/Portfile In-Reply-To: References: <20090917153616.4A8BA278F917@beta.macosforge.org> <6A0A6DC2-95E0-4336-91E5-8EC11E4D5D56@macports.org> Message-ID: On Sep 17, 2009, at 13:43, Landon Fuller wrote: > > On Sep 17, 2009, at 8:44 AM, Ryan Schmidt wrote: > >> On Sep 17, 2009, at 10:36, alakazam at macports.org wrote: >> >> >> If you need to create files (like config files) outside of the >> destroot, you should do so in the post-activate phase, not in the >> destroot phase. > > I believe the (documented? defacto?) standard is that example > configuration files should be installed in destroot phase with > a .sample extension. Uh, yes. Well the sample config file should be installed with a name ending in e.g. ".sample" and this should be done in the destroot phase and this file should be part of the destroot. But if you then want to copy that sample config file to a real config file for the user to modify, that should be done outside the destroot and outside the destroot phase, after the port has been activated. From landonf at macports.org Thu Sep 17 12:42:50 2009 From: landonf at macports.org (Landon Fuller) Date: Thu, 17 Sep 2009 12:42:50 -0700 Subject: [57854] trunk/dports/www/phpmyadmin/Portfile In-Reply-To: References: <20090917153616.4A8BA278F917@beta.macosforge.org> <6A0A6DC2-95E0-4336-91E5-8EC11E4D5D56@macports.org> Message-ID: <46BA9D78-783F-46DD-878B-2ADF4F3FD0EC@macports.org> On Sep 17, 2009, at 12:08 PM, Ryan Schmidt wrote: > > On Sep 17, 2009, at 13:43, Landon Fuller wrote: > >> >> On Sep 17, 2009, at 8:44 AM, Ryan Schmidt wrote: >> >>> On Sep 17, 2009, at 10:36, alakazam at macports.org wrote: >>> >>> >>> If you need to create files (like config files) outside of the >>> destroot, you should do so in the post-activate phase, not in the >>> destroot phase. >> >> I believe the (documented? defacto?) standard is that example >> configuration files should be installed in destroot phase with >> a .sample extension. > > Uh, yes. Well the sample config file should be installed with a name > ending in e.g. ".sample" and this should be done in the destroot > phase and this file should be part of the destroot. But if you then > want to copy that sample config file to a real config file for the > user to modify, that should be done outside the destroot and outside > the destroot phase, after the port has been activated. My only point was that the historically standard behavior was to install .sample files and not try to add configuration management logic to either the base system or every port that uses a configuration file. If the new standard is to write custom per-port post-activate handlers to manually trigger ui_msg and install default configuration files, then perhaps it's worth revisiting the years-old decision to not add base system feature for handling configuration files. *shrug*. -landonf -------------- 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 blb at macports.org Thu Sep 17 12:53:09 2009 From: blb at macports.org (Bryan Blackburn) Date: Thu, 17 Sep 2009 13:53:09 -0600 Subject: [57854] trunk/dports/www/phpmyadmin/Portfile In-Reply-To: <46BA9D78-783F-46DD-878B-2ADF4F3FD0EC@macports.org> References: <20090917153616.4A8BA278F917@beta.macosforge.org> <6A0A6DC2-95E0-4336-91E5-8EC11E4D5D56@macports.org> <46BA9D78-783F-46DD-878B-2ADF4F3FD0EC@macports.org> Message-ID: <20090917195309.GM94063@ninagal.withay.com> On Thu, Sep 17, 2009 at 12:42:50PM -0700, Landon Fuller said: [...] > My only point was that the historically standard behavior was to > install .sample files and not try to add configuration management > logic to either the base system or every port that uses a > configuration file. > > If the new standard is to write custom per-port post-activate > handlers to manually trigger ui_msg and install default configuration > files, then perhaps it's worth revisiting the years-old decision to > not add base system feature for handling configuration files. > > *shrug*. Ticket #2365: and until that's implemented: Bryan > > -landonf From ryandesign at macports.org Thu Sep 17 14:26:32 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 17 Sep 2009 16:26:32 -0500 Subject: [57854] trunk/dports/www/phpmyadmin/Portfile In-Reply-To: <46BA9D78-783F-46DD-878B-2ADF4F3FD0EC@macports.org> References: <20090917153616.4A8BA278F917@beta.macosforge.org> <6A0A6DC2-95E0-4336-91E5-8EC11E4D5D56@macports.org> <46BA9D78-783F-46DD-878B-2ADF4F3FD0EC@macports.org> Message-ID: On Sep 17, 2009, at 14:42, Landon Fuller wrote: > On Sep 17, 2009, at 12:08 PM, Ryan Schmidt wrote: > >> On Sep 17, 2009, at 13:43, Landon Fuller wrote: >> >>> On Sep 17, 2009, at 8:44 AM, Ryan Schmidt wrote: >>> >>>> If you need to create files (like config files) outside of the >>>> destroot, you should do so in the post-activate phase, not in the >>>> destroot phase. >>> >>> I believe the (documented? defacto?) standard is that example >>> configuration files should be installed in destroot phase with >>> a .sample extension. >> >> Uh, yes. Well the sample config file should be installed with a >> name ending in e.g. ".sample" and this should be done in the >> destroot phase and this file should be part of the destroot. But if >> you then want to copy that sample config file to a real config file >> for the user to modify, that should be done outside the destroot >> and outside the destroot phase, after the port has been activated. > > My only point was that the historically standard behavior was to > install .sample files and not try to add configuration management > logic to either the base system or every port that uses a > configuration file. > > If the new standard is to write custom per-port post-activate > handlers to manually trigger ui_msg and install default > configuration files, then perhaps it's worth revisiting the years- > old decision to not add base system feature for handling > configuration files. Personally, I prefer to tell the user where the sample files are so they can make copies if and when they want. Other port authors have taken recently to copying the sample files for the user. I didn't realize there had been a specific decision not to do anything about configuration files in MacPorts base; I figured it was just something nobody had gotten to yet. There is an open ticket: http://trac.macports.org/ticket/2365 From raimue at macports.org Thu Sep 17 17:17:10 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 18 Sep 2009 02:17:10 +0200 Subject: [57854] trunk/dports/www/phpmyadmin/Portfile In-Reply-To: References: <20090917153616.4A8BA278F917@beta.macosforge.org> <6A0A6DC2-95E0-4336-91E5-8EC11E4D5D56@macports.org> <46BA9D78-783F-46DD-878B-2ADF4F3FD0EC@macports.org> Message-ID: <4AB2D186.3050405@macports.org> On 2009-09-17 23:26 , Ryan Schmidt wrote: > Personally, I prefer to tell the user where the sample files are so > they can make copies if and when they want. Other port authors have > taken recently to copying the sample files for the user. If the software requires the config file to run at all, it makes sense to copy it in a post-activate phase. Otherwise, there is no need to do this. > I didn't realize there had been a specific decision not to do anything > about configuration files in MacPorts base; I figured it was just > something nobody had gotten to yet. There is an open ticket: > > http://trac.macports.org/ticket/2365 This has just been ignored as it is on lower priority in my opinion. We also offered this as a Google Summer of Code task the last years as it would be relatively easy and even had students interested in the topic. Rainer From mark at mirell.org Thu Sep 17 17:59:24 2009 From: mark at mirell.org (Mark A. Miller) Date: Thu, 17 Sep 2009 19:59:24 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries Message-ID: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> Since there hasn't been much discussion on this for a while, I'm bringing this up again. The relevant enhancement bug is https://trac.macports.org/ticket/20748 One of the thoughts was to use ${prefix}/libexec/gnubin for the unprefixed binaries. Although commonly applications that put files in here, intend these binaries to only be run by other binaries (A good example is HAL on Linux, it installs many HAL wrapper scripts in /libexec). But I think that there's no real reason to prevent putting gnubin (or whatever it ends up being called) under libexec. It seems a good enough place, and people who use this option to put unprefixed binaries here probably wouldn't have any issue with its location. Another thing that was brought up in the ticket is the idea that the scripts should be modified if you want unprefixed binaries. This doesn't particularly work well when you're dealing with large projects with giant recursive makefiles. You want to spend time trying to find the real issues with porting the software to MacOSX, rather than spend hours fighting standard BSD/GNU differences like sed/et cetera. At least that's my experience. Thoughts? -- Mark A. Miller mark at mirell.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From talklists at newgeo.com Thu Sep 17 18:44:26 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 17 Sep 2009 18:44:26 -0700 Subject: dscl Message-ID: <3C42F4AE-0965-45ED-BBD1-547CC6F2EC16@newgeo.com> Hello, I am working on trying to make a change to a port that does not have user and group adding abilities, but it probably should. At this point, I need to confirm this by adding a user and group by hand, using dscl in Mac OS X 10.5 I took this from some old docs on dovecot: sudo dscl . -create /Groups/_ftpg sudo dscl . -create /Groups/_ftpg UniqueID 490 sudo dscl . -create /Users/_ftpu sudo dscl . -create /Users/_ftpu UserShell /usr/bin/false sudo dscl . -create /Users/_ftpu RealName "PureFTPd FTP Server" sudo dscl . -create /Users/_ftpu UniqueID 490 sudo dscl . -create /Users/_ftpu PrimaryGroupID 490 sudo dscl . -create /Users/_ftpu NFSHomeDirectory /var/empty This sort of works. In this case, the ftpd has a flag to "auto create home dirs", which I have enabled. I have told the ftpd to use user and group 490. On first ftp login, it will create the directory I tell it to: drwxr-x--- 2 _ftpu 490 68 Sep 17 18:42 someplace As you can see, there is something wrong with the group. $sudo chgrp _ftpg someplace/ drwxr-x--- 2 _ftpu nobody 68 Sep 17 18:42 someplace I think what I would really like to do is also create a user and group more like www and mysql, where they have both the _foo and foo version, but I can not figure this out. $dscl . -read /Users/_mysqlAppleMetaNodeLocation: /Local/ DefaultNFSHomeDirectory: /var/emptyPassword: *PrimaryGroupID: 74 RealName: MySQL Server RecordName: _mysql mysql RecordType: dsRecTypeStandard:Users UniqueID: 74 UserShell: /usr/bin/false Thanks for any suggestions -- Scott * If you contact me off list replace talklists@ with scott@ * From blair at orcaware.com Thu Sep 17 22:54:17 2009 From: blair at orcaware.com (Blair Zajac) Date: Thu, 17 Sep 2009 22:54:17 -0700 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> Message-ID: <430C5215-F514-408A-B82B-25DF0E294337@orcaware.com> On Sep 17, 2009, at 5:59 PM, Mark A. Miller wrote: > Since there hasn't been much discussion on this for a while, I'm > bringing this up again. > > The relevant enhancement bug is https://trac.macports.org/ticket/20748 > > One of the thoughts was to use ${prefix}/libexec/gnubin for the > unprefixed binaries. Although commonly applications that put files > in here, intend these binaries to only be run by other binaries (A > good example is HAL on Linux, it installs many HAL wrapper scripts > in /libexec). But I think that there's no real reason to prevent > putting gnubin (or whatever it ends up being called) under libexec. > It seems a good enough place, and people who use this option to put > unprefixed binaries here probably wouldn't have any issue with its > location. > > Another thing that was brought up in the ticket is the idea that the > scripts should be modified if you want unprefixed binaries. This > doesn't particularly work well when you're dealing with large > projects with giant recursive makefiles. You want to spend time > trying to find the real issues with porting the software to MacOSX, > rather than spend hours fighting standard BSD/GNU differences like > sed/et cetera. At least that's my experience. > > Thoughts? > I actaully was thinking the opposite, that if you want the port installed, it should install the binaries into the default location for everything to pick up, so as in effect make +with_default_names the default and add a +no_default_names otion. After all, if you're installing the port, then just use it normally. This is similar to the way that we now replace Apple's xorg with our own. Are there any reasons not to do this? Regards, Blair From jeremy at lavergne.gotdns.org Thu Sep 17 22:56:29 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 18 Sep 2009 01:56:29 -0400 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <430C5215-F514-408A-B82B-25DF0E294337@orcaware.com> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <430C5215-F514-408A-B82B-25DF0E294337@orcaware.com> Message-ID: GNU utilities versus BSD utilities ... they don't do the same thing in the same way. This results in some stuff breaking. On Sep 18, 2009, at 1:54 AM, Blair Zajac wrote: > Are there any reasons not to do this? From mark at mirell.org Thu Sep 17 23:02:43 2009 From: mark at mirell.org (Mark A. Miller) Date: Fri, 18 Sep 2009 01:02:43 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <430C5215-F514-408A-B82B-25DF0E294337@orcaware.com> Message-ID: <31014a580909172302v5c0a645awf6b58f654349c818@mail.gmail.com> Exactly, some packages that are set up to build nicely on MacOSX expect BSD tools, not GNU. Good example that has bitten me many times, is GNU's "sed -r" versus BSD's "sed -E". Et cetera. On Fri, Sep 18, 2009 at 12:56 AM, Jeremy Lavergne < jeremy at lavergne.gotdns.org> wrote: > GNU utilities versus BSD utilities ... they don't do the same thing in the > same way. > > This results in some stuff breaking. > > > On Sep 18, 2009, at 1:54 AM, Blair Zajac wrote: > > Are there any reasons not to do this? >> > > -- Mark A. Miller mark at mirell.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From blair at orcaware.com Thu Sep 17 23:04:34 2009 From: blair at orcaware.com (Blair Zajac) Date: Thu, 17 Sep 2009 23:04:34 -0700 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <31014a580909172302v5c0a645awf6b58f654349c818@mail.gmail.com> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <430C5215-F514-408A-B82B-25DF0E294337@orcaware.com> <31014a580909172302v5c0a645awf6b58f654349c818@mail.gmail.com> Message-ID: But if I want the port, I want the port. What's the point of installing it if you don't want it as the default. As for building ports, then we set the port to use /usr/bin/sed and not $prefix/bin/sed for the few cases that are different. Blair On Sep 17, 2009, at 11:02 PM, Mark A. Miller wrote: > Exactly, some packages that are set up to build nicely on MacOSX > expect BSD tools, not GNU. Good example that has bitten me many > times, is GNU's "sed -r" versus BSD's "sed -E". Et cetera. > > On Fri, Sep 18, 2009 at 12:56 AM, Jeremy Lavergne > wrote: > GNU utilities versus BSD utilities ... they don't do the same thing > in the same way. > > This results in some stuff breaking. > > > On Sep 18, 2009, at 1:54 AM, Blair Zajac wrote: > > Are there any reasons not to do this? > > > > > -- > Mark A. Miller > mark at mirell.org From toby at macports.org Thu Sep 17 23:08:42 2009 From: toby at macports.org (Toby Peterson) Date: Thu, 17 Sep 2009 23:08:42 -0700 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <430C5215-F514-408A-B82B-25DF0E294337@orcaware.com> <31014a580909172302v5c0a645awf6b58f654349c818@mail.gmail.com> Message-ID: <74c219d30909172308w222d03b4q7a2c254dc9e3bf4@mail.gmail.com> On Thu, Sep 17, 2009 at 23:04, Blair Zajac wrote: > But if I want the port, I want the port. ?What's the point of installing it > if you don't want it as the default. This is one of those cases where we simply have to ignore the user's wishes, because the user is wrong (whether they know it or not). - Toby From mark at mirell.org Thu Sep 17 23:09:23 2009 From: mark at mirell.org (Mark A. Miller) Date: Fri, 18 Sep 2009 01:09:23 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <430C5215-F514-408A-B82B-25DF0E294337@orcaware.com> <31014a580909172302v5c0a645awf6b58f654349c818@mail.gmail.com> Message-ID: <31014a580909172309s17236bd3y388a6e6cbe5b9252@mail.gmail.com> On Fri, Sep 18, 2009 at 1:04 AM, Blair Zajac wrote: > But if I want the port, I want the port. What's the point of installing it > if you don't want it as the default. > That doesn't particularly make any sense. I can install python26 and python31, but I still want python26 to be the default, but be able to use python31 if I want to. As for building ports, then we set the port to use /usr/bin/sed and not > $prefix/bin/sed for the few cases that are different. > Right, and for the thousands and thousands of lines of Makefiles for the many packages that either ignore documented ./configure variables, use them in some places but not in others, fetches the needed utility out of your $PATH of the executing shell, or are hardcoded, not to mention the large amount of portfiles and patches that would need to be modified...no, that idea makes no sense whatsoever. I understand what you're trying to say, but I don't think you realize the vast ramifications of it. > Blair > > > On Sep 17, 2009, at 11:02 PM, Mark A. Miller wrote: > > Exactly, some packages that are set up to build nicely on MacOSX expect >> BSD tools, not GNU. Good example that has bitten me many times, is GNU's >> "sed -r" versus BSD's "sed -E". Et cetera. >> >> On Fri, Sep 18, 2009 at 12:56 AM, Jeremy Lavergne < >> jeremy at lavergne.gotdns.org> wrote: >> GNU utilities versus BSD utilities ... they don't do the same thing in the >> same way. >> >> This results in some stuff breaking. >> >> >> On Sep 18, 2009, at 1:54 AM, Blair Zajac wrote: >> >> Are there any reasons not to do this? >> >> >> >> >> -- >> Mark A. Miller >> mark at mirell.org >> > > -- Mark A. Miller mark at mirell.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From blair at orcaware.com Thu Sep 17 23:19:34 2009 From: blair at orcaware.com (Blair Zajac) Date: Thu, 17 Sep 2009 23:19:34 -0700 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <31014a580909172309s17236bd3y388a6e6cbe5b9252@mail.gmail.com> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <430C5215-F514-408A-B82B-25DF0E294337@orcaware.com> <31014a580909172302v5c0a645awf6b58f654349c818@mail.gmail.com> <31014a580909172309s17236bd3y388a6e6cbe5b9252@mail.gmail.com> Message-ID: On Sep 17, 2009, at 11:09 PM, Mark A. Miller wrote: > > > On Fri, Sep 18, 2009 at 1:04 AM, Blair Zajac > wrote: > But if I want the port, I want the port. What's the point of > installing it if you don't want it as the default. > > That doesn't particularly make any sense. I can install python26 and > python31, but I still want python26 to be the default, but be able > to use python31 if I want to. Installing these as the default doesn't stop you from using /usr/bin tools when you want to, just as installing python26 as the default doesn't stop you from using python31 if you want to. > > As for building ports, then we set the port to use /usr/bin/sed and > not $prefix/bin/sed for the few cases that are different. > > Right, and for the thousands and thousands of lines of Makefiles for > the many packages that either ignore documented ./configure > variables, use them in some places but not in others, fetches the > needed utility out of your $PATH of the executing shell, or are > hardcoded, not to mention the large amount of portfiles and patches > that would need to be modified...no, that idea makes no sense > whatsoever. > I understand what you're trying to say, but I don't think you > realize the vast ramifications of it. I think you're mistaken there. I've installed many ports with coreutils, findutils and other ones installed and the only issue I've ever run into was with an issue of the python* ports installing using xargs. I'm not suggesting doing this for all ports, just where there's breakage. Blair From mark at mirell.org Thu Sep 17 23:30:43 2009 From: mark at mirell.org (Mark A. Miller) Date: Fri, 18 Sep 2009 01:30:43 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <430C5215-F514-408A-B82B-25DF0E294337@orcaware.com> <31014a580909172302v5c0a645awf6b58f654349c818@mail.gmail.com> <31014a580909172309s17236bd3y388a6e6cbe5b9252@mail.gmail.com> Message-ID: <31014a580909172330y255b5727sd518ebf3f7a225b@mail.gmail.com> On Fri, Sep 18, 2009 at 1:19 AM, Blair Zajac wrote: > > On Sep 17, 2009, at 11:09 PM, Mark A. Miller wrote: > > On Fri, Sep 18, 2009 at 1:04 AM, Blair Zajac wrote: >> But if I want the port, I want the port. What's the point of installing >> it if you don't want it as the default. >> >> That doesn't particularly make any sense. I can install python26 and >> python31, but I still want python26 to be the default, but be able to use >> python31 if I want to. >> > > Installing these as the default doesn't stop you from using /usr/bin tools > when you want to, just as installing python26 as the default doesn't stop > you from using python31 if you want to. > Okay? I was answering your question of why I'd want to install something if I didn't want it as the default. Another example, and pointedly related, I want GNU sed for certain purposes, but I don't want it to be the default, because I want BSD sed for other purposes. > As for building ports, then we set the port to use /usr/bin/sed and not >> $prefix/bin/sed for the few cases that are different. >> >> Right, and for the thousands and thousands of lines of Makefiles for the >> many packages that either ignore documented ./configure variables, use them >> in some places but not in others, fetches the needed utility out of your >> $PATH of the executing shell, or are hardcoded, not to mention the large >> amount of portfiles and patches that would need to be modified...no, that >> idea makes no sense whatsoever. >> > > I understand what you're trying to say, but I don't think you realize the >> vast ramifications of it. >> > > I think you're mistaken there. Not particularly. I've done a lot of cross-compiling and porting, and dealing with Makefile idiocy. > I've installed many ports with coreutils, findutils and other ones > installed and the only issue I've ever run into was with an issue of the > python* ports installing using xargs. > > I'm not suggesting doing this for all ports, just where there's breakage. It's still more work than just allowing the GNU utilities to live in something like ${prefix}/libexec/gnubin. And probably most of the tools you had installed, most of the commands are specified in SuSV4/5, so BSD/GNU had the same functionality. I noticed you didn't mention sed, though. Basically what you're suggesting would cause MacPorts to maintain patches that would distinctly not be merged upstream. I just don't understand why you want more work and breakage. Also, a critical thing to note, is that utilities and such outside of MacPorts would potentially break if they reference something such as sed from the $PATH, so your solution would break things which we have no control over. Whereas by default installing things with a "g" prefix, and having a variant to put them in ${prefix}/libexec/gnubin, and the user must manually add that to their $PATH. So it doesn't break for the general user if they install these things, and lets the "People who know what they're doing" nicely add the GNU utilities as their standard name to their $PATH for certain things. > Blair -- Mark A. Miller mark at mirell.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From blb at macports.org Thu Sep 17 23:44:10 2009 From: blb at macports.org (Bryan Blackburn) Date: Fri, 18 Sep 2009 00:44:10 -0600 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <430C5215-F514-408A-B82B-25DF0E294337@orcaware.com> <31014a580909172302v5c0a645awf6b58f654349c818@mail.gmail.com> <31014a580909172309s17236bd3y388a6e6cbe5b9252@mail.gmail.com> Message-ID: <20090918064409.GA2844@ninagal.withay.com> On Thu, Sep 17, 2009 at 11:19:34PM -0700, Blair Zajac said: > On Sep 17, 2009, at 11:09 PM, Mark A. Miller wrote: > >On Fri, Sep 18, 2009 at 1:04 AM, Blair Zajac > >wrote: > >But if I want the port, I want the port. What's the point of > >installing it if you don't want it as the default. [...] > > I think you're mistaken there. I've installed many ports with > coreutils, findutils and other ones installed and the only issue I've > ever run into was with an issue of the python* ports installing using > xargs. > > I'm not suggesting doing this for all ports, just where there's > breakage. Are you willing to build all 6100+ ports to verify all of them are okay with +with_default_names? Also, note that some of these ports are dependencies for other ports, so it may not simply be a case of "you wanted it, so you must want it as the default". For example, I have m4 and gsed installed solely as dependencies, and I believe that's how I've ended up with coreutils before. Bryan > > Blair From ryandesign at macports.org Fri Sep 18 03:55:17 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 18 Sep 2009 05:55:17 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <20090918064409.GA2844@ninagal.withay.com> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <430C5215-F514-408A-B82B-25DF0E294337@orcaware.com> <31014a580909172302v5c0a645awf6b58f654349c818@mail.gmail.com> <31014a580909172309s17236bd3y388a6e6cbe5b9252@mail.gmail.com> <20090918064409.GA2844@ninagal.withay.com> Message-ID: On Sep 18, 2009, at 01:44, Bryan Blackburn wrote: > Are you willing to build all 6100+ ports to verify all of them are > okay with > +with_default_names? > > Also, note that some of these ports are dependencies for other > ports, so it > may not simply be a case of "you wanted it, so you must want it as the > default". For example, I have m4 and gsed installed solely as > dependencies, > and I believe that's how I've ended up with coreutils before. Exactly. I don't have gsed because I want gsed; I have it because php5 requires it. That is, php5 doesn't require it; it would work fine with bsd sed. But if gsed is present, php5 encodes the name "gsed" into one of its scripts; if I were to uninstall gsed later, a part of php5 would break. Once I realized that, I had to either add the dependency or patch php5. The former was easier and more future-proof than the latter. Mark brought the with_default_names issue up with me a few weeks ago and I convinced him that putting the unprefixed binaries into $ {prefix}/libexec/something would be an ok solution. I, too, would like to get rid of the with_default_names variants, but having the software install with default names always is not acceptable for the reasons mentioned. It would break tons of stuff. I presume that is the reason why e.g. gsed was changed to not install that way by default over four years ago in r13825. We don't want to re-break what that fixed. I'm not sure what "something" in ${prefix}/libexec/something should be. I suggested ${name} because that's what other ports use. Mark suggested "gnubin". "gnubin" would be convenient in that you would only have to add one path to your PATH to pick up all installed GNU utilities. On the other hand, might there be a reason when you would want only specific GNU utilities and not others? Might you want to only have the GNU sed and keep the BSD awk, say? If so, then putting each port's binaries in its own directory would give you that freedom. Heck, we could have it both ways: each port could create two symlinks to each program, one in ${prefix}/libexec/gnubin and one in ${prefix}/ libexec/${name}. Then the user can use whichever path they like. From mww at macports.org Fri Sep 18 04:20:47 2009 From: mww at macports.org (Markus Weissmann) Date: Fri, 18 Sep 2009 13:20:47 +0200 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <430C5215-F514-408A-B82B-25DF0E294337@orcaware.com> <31014a580909172302v5c0a645awf6b58f654349c818@mail.gmail.com> <31014a580909172309s17236bd3y388a6e6cbe5b9252@mail.gmail.com> <20090918064409.GA2844@ninagal.withay.com> Message-ID: On Fri, September 18, 2009 12:55, Ryan Schmidt wrote: > > On Sep 18, 2009, at 01:44, Bryan Blackburn wrote: > > ... > > I'm not sure what "something" in ${prefix}/libexec/something should > be. I suggested ${name} because that's what other ports use. Mark > suggested "gnubin". "gnubin" would be convenient in that you would > only have to add one path to your PATH to pick up all installed GNU > utilities. On the other hand, might there be a reason when you would > want only specific GNU utilities and not others? Might you want to > only have the GNU sed and keep the BSD awk, say? If so, then putting > each port's binaries in its own directory would give you that freedom. > Heck, we could have it both ways: each port could create two symlinks > to each program, one in ${prefix}/libexec/gnubin and one in ${prefix}/ > libexec/${name}. Then the user can use whichever path they like. > The logical extension to this would be, to have a separate libexec/${name} directory for each port -- which imho is a bit excessive. I assume that most people who select "with_default_names" variants are those who prefer GNU tools to BSD tools (Mac OS X respectively). In this case, ONE separate libexec/gnubin or libexec/gnu directory with un-prefixed executables would do. I you want the power to select the name for each and every executable, then for gods sake, make your own directory with symlinks: Its the same amount of work then. Regards, -Markus --- http://www.mweissmann.de/ http://www.macports.org/ From howarth at bromo.med.uc.edu Fri Sep 18 04:33:30 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 18 Sep 2009 07:33:30 -0400 Subject: config.guess changed committed upstream Message-ID: <20090918113330.GA7763@bromo.med.uc.edu> FYI, the config.guess change has been comitted to the up From howarth at bromo.med.uc.edu Fri Sep 18 04:34:29 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 18 Sep 2009 07:34:29 -0400 Subject: config.guess changed committed upstream Message-ID: <20090918113429.GA7760@bromo.med.uc.edu> FYI, the config.guess change for darwin10 is now committed to git HEAD... http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD anyone who is having build issues in their projects should alert their upstream to the availability of the new config.guess and have them update to it. Cheers. Jack >Hi Jack, > >> The attached diff against config.guess HEAD is about as small as >> I can possibly make the patch (using the SunOS5 section as a >> template. This works as before but this version requires a compiler >> of course. Does this one look acceptable? > >This is fine. I have committed it to the master git repository: > >commit ccf975556a0f6797fe80395cd6f314682a770f15 >Author: Ben Elliston >Date: Fri Sep 18 11:04:25 2009 +1000 > > 2009-09-18 Jack Howarth > > * config.guess (*:Darwin:*:*): Handle 64-bit compilers on i386. > >Thanks for your persistence! > >Ben From ryandesign at macports.org Fri Sep 18 04:40:34 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 18 Sep 2009 06:40:34 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <430C5215-F514-408A-B82B-25DF0E294337@orcaware.com> <31014a580909172302v5c0a645awf6b58f654349c818@mail.gmail.com> <31014a580909172309s17236bd3y388a6e6cbe5b9252@mail.gmail.com> <20090918064409.GA2844@ninagal.withay.com> Message-ID: On Sep 18, 2009, at 06:20, Markus Weissmann wrote: > On Fri, September 18, 2009 12:55, Ryan Schmidt wrote: >> > >> I'm not sure what "something" in ${prefix}/libexec/something should >> be. I suggested ${name} because that's what other ports use. Mark >> suggested "gnubin". "gnubin" would be convenient in that you would >> only have to add one path to your PATH to pick up all installed GNU >> utilities. On the other hand, might there be a reason when you would >> want only specific GNU utilities and not others? Might you want to >> only have the GNU sed and keep the BSD awk, say? If so, then putting >> each port's binaries in its own directory would give you that >> freedom. >> Heck, we could have it both ways: each port could create two symlinks >> to each program, one in ${prefix}/libexec/gnubin and one in $ >> {prefix}/ >> libexec/${name}. Then the user can use whichever path they like. > > The logical extension to this would be, to have a separate libexec/$ > {name} > directory for each port -- which imho is a bit excessive. Yes, I did mean one libexec/${name} directory for each port that we're talking about here. I see this variant in coreutils, diffutils, findutils, gsed, gnetcat, gnutar, gwhich, and m4. gawk doesn't have this variant but whatever solution we come up with for the others could be applied to gawk as well. Whether having a separate directory for each of those is excessive depends on the purpose of having the directory in the first place. Since I am not a person who wants these utilities with their default names, I wasn't sure what those who do want that are wanting exactly, that's why I was asking. > I assume that most people who select "with_default_names" variants are > those who prefer GNU tools to BSD tools (Mac OS X respectively). > In this case, ONE separate libexec/gnubin or libexec/gnu directory > with > un-prefixed executables would do. I you want the power to select the > name > for each and every executable, then for gods sake, make your own > directory > with symlinks: Its the same amount of work then. Ah, true, nothing is preventing anyone from making their own symlinks somewhere. In which case, there isn't even a problem with just removing the with_default_names variants entirely and not creating a replacement. But it would be nice to at least symlink them into one directory. From ryandesign at macports.org Fri Sep 18 05:47:51 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 18 Sep 2009 07:47:51 -0500 Subject: Do Explorative Programming in tclsh with Readline Support Message-ID: <76B8B081-9F25-454A-A88A-430BF63B6245@macports.org> I'm trying to follow these instructions for the first time and am not having any luck, so I don't know if I'm doing something wrong or if the instructions need to be changed e.g. for MacPorts 1.8.0 or if there is a bug in MacPorts 1.8.0. http://trac.macports.org/wiki/CommittersTipsAndTricks#DoExplorativeProgrammingintclshwithReadlineSupport I have created the file macports_testing.tcl with the specified contents (except that on the first line I use "/opt/local/Library/Tcl" etc. because that is where my macports1.0 lives). Leaving rlwrap out of it for the moment, I can run "tclsh" (or "tclsh8.4" or "tclsh8.5"). But as soon as I try to "source ~/path/to/ macports_testing.tcl" I don't see the successful "1.0" message but instead: can't read "workpath": can't read "portbuildpath": no such variable Can anybody help? From dluke at geeklair.net Fri Sep 18 06:48:39 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 18 Sep 2009 09:48:39 -0400 Subject: [57854] trunk/dports/www/phpmyadmin/Portfile In-Reply-To: References: <20090917153616.4A8BA278F917@beta.macosforge.org> <6A0A6DC2-95E0-4336-91E5-8EC11E4D5D56@macports.org> <46BA9D78-783F-46DD-878B-2ADF4F3FD0EC@macports.org> Message-ID: <006204BF-5FA0-4879-B269-53E06CE5632C@geeklair.net> On Sep 17, 2009, at 5:26 PM, Ryan Schmidt wrote: > I didn't realize there had been a specific decision not to do > anything about configuration files in MacPorts base; I figured it > was just something nobody had gotten to yet. There is an open ticket: IIRC, the discussion in the past (which resulted in the decision to not do anything specific for conf files) included what to do if/when conf file formats change, or the sample files include new configuration options, etc. While you can try to be 'really clever', it's easy to end up in a situation where you strangely mangle a user's conf file and they have to go in and fix things manually. -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From dluke at geeklair.net Fri Sep 18 06:53:45 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 18 Sep 2009 09:53:45 -0400 Subject: dscl In-Reply-To: <3C42F4AE-0965-45ED-BBD1-547CC6F2EC16@newgeo.com> References: <3C42F4AE-0965-45ED-BBD1-547CC6F2EC16@newgeo.com> Message-ID: <8E1919C8-E26F-43E0-8294-BF72314BA554@geeklair.net> On Sep 17, 2009, at 9:44 PM, Scott Haneda wrote: > Hello, I am working on trying to make a change to a port that does > not have user and group adding abilities, but it probably should. > At this point, I need to confirm this by adding a user and group by > hand, using dscl in Mac OS X 10.5 The port should use the adduser/addgroup commands (see 'man portfile') > I took this from some old docs on dovecot: > sudo dscl . -create /Groups/_ftpg > sudo dscl . -create /Groups/_ftpg UniqueID 490 > sudo dscl . -create /Users/_ftpu > sudo dscl . -create /Users/_ftpu UserShell /usr/bin/false > sudo dscl . -create /Users/_ftpu RealName "PureFTPd FTP Server" > sudo dscl . -create /Users/_ftpu UniqueID 490 > sudo dscl . -create /Users/_ftpu PrimaryGroupID 490 > sudo dscl . -create /Users/_ftpu NFSHomeDirectory /var/empty > > This sort of works. In this case, the ftpd has a flag to "auto > create home dirs", which I have enabled. I have told the ftpd to > use user and group 490. On first ftp login, it will create the > directory I tell it to: > > drwxr-x--- 2 _ftpu 490 68 Sep 17 18:42 someplace > > As you can see, there is something wrong with the group. You didn't set PrimaryGroupID > $sudo chgrp _ftpg someplace/ > drwxr-x--- 2 _ftpu nobody 68 Sep 17 18:42 someplace > > I think what I would really like to do is also create a user and > group more like www and mysql, where they have both the _foo and foo > version, but I can not figure this out. why? I don't think you want/need to have the user be 'special' in this way. -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From kw at codebykevin.com Fri Sep 18 07:02:49 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Fri, 18 Sep 2009 10:02:49 -0400 Subject: Do Explorative Programming in tclsh with Readline Support In-Reply-To: <76B8B081-9F25-454A-A88A-430BF63B6245@macports.org> References: <76B8B081-9F25-454A-A88A-430BF63B6245@macports.org> Message-ID: <4AB39309.3000304@codebykevin.com> On 9/18/09 8:47 AM, Ryan Schmidt wrote: > I'm trying to follow these instructions for the first time and am not > having any luck, so I don't know if I'm doing something wrong or if the > instructions need to be changed e.g. for MacPorts 1.8.0 or if there is a > bug in MacPorts 1.8.0. > > http://trac.macports.org/wiki/CommittersTipsAndTricks#DoExplorativeProgrammingintclshwithReadlineSupport > > > I have created the file macports_testing.tcl with the specified contents > (except that on the first line I use "/opt/local/Library/Tcl" etc. > because that is where my macports1.0 lives). > > Leaving rlwrap out of it for the moment, I can run "tclsh" (or > "tclsh8.4" or "tclsh8.5"). But as soon as I try to "source > ~/path/to/macports_testing.tcl" I don't see the successful "1.0" message > but instead: > > can't read "workpath": can't read "portbuildpath": no such variable > > Can anybody help? The problem might be that your installation of the MacPorts libraries isn't on the standard Tcl search path. /Library/Tcl is a standard search path for Tcl on the Mac, but /opt/local/Library is not. Try running this command in your tclsh session: lappend auto_path /opt/local/Library/Tcl or whatever the specific location is, then try sourcing the relevant file. Here's a good site with resources for learning more about Tcl: http://www.tcl.tk/doc/ There's a tutorial there, among other things. HTH, Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com From ryandesign at macports.org Fri Sep 18 07:12:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 18 Sep 2009 09:12:23 -0500 Subject: Do Explorative Programming in tclsh with Readline Support In-Reply-To: <4AB39309.3000304@codebykevin.com> References: <76B8B081-9F25-454A-A88A-430BF63B6245@macports.org> <4AB39309.3000304@codebykevin.com> Message-ID: <863BE927-52B7-4339-8A5C-54E5A1656593@macports.org> On Sep 18, 2009, at 09:02, Kevin Walzer wrote: > The problem might be that your installation of the MacPorts > libraries isn't on the standard Tcl search path. /Library/Tcl is a > standard search path for Tcl on the Mac, but /opt/local/Library is > not. Try running this command in your tclsh session: > > lappend auto_path /opt/local/Library/Tcl > > or whatever the specific location is, then try sourcing the relevant > file. Appears to have no effect. From mark at mirell.org Fri Sep 18 07:58:51 2009 From: mark at mirell.org (Mark A. Miller) Date: Fri, 18 Sep 2009 09:58:51 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <31014a580909172302v5c0a645awf6b58f654349c818@mail.gmail.com> <31014a580909172309s17236bd3y388a6e6cbe5b9252@mail.gmail.com> <20090918064409.GA2844@ninagal.withay.com> Message-ID: <31014a580909180758kc4b068brb6d2e61c7283732d@mail.gmail.com> On Fri, Sep 18, 2009 at 6:40 AM, Ryan Schmidt wrote: > On Sep 18, 2009, at 06:20, Markus Weissmann wrote: > > On Fri, September 18, 2009 12:55, Ryan Schmidt wrote: >> >>> >>> >> I'm not sure what "something" in ${prefix}/libexec/something should >>> be. I suggested ${name} because that's what other ports use. Mark >>> suggested "gnubin". "gnubin" would be convenient in that you would >>> only have to add one path to your PATH to pick up all installed GNU >>> utilities. On the other hand, might there be a reason when you would >>> want only specific GNU utilities and not others? Might you want to >>> only have the GNU sed and keep the BSD awk, say? If so, then putting >>> each port's binaries in its own directory would give you that freedom. >>> Heck, we could have it both ways: each port could create two symlinks >>> to each program, one in ${prefix}/libexec/gnubin and one in ${prefix}/ >>> libexec/${name}. Then the user can use whichever path they like. >>> >> >> The logical extension to this would be, to have a separate libexec/${name} >> directory for each port -- which imho is a bit excessive. >> > > Yes, I did mean one libexec/${name} directory for each port that we're > talking about here. I see this variant in coreutils, diffutils, findutils, > gsed, gnetcat, gnutar, gwhich, and m4. gawk doesn't have this variant but > whatever solution we come up with for the others could be applied to gawk as > well. Whether having a separate directory for each of those is excessive > depends on the purpose of having the directory in the first place. Since I > am not a person who wants these utilities with their default names, I wasn't > sure what those who do want that are wanting exactly, that's why I was > asking. Just based on my experience, I want it so I could add a particular directory to my path, and try building various packages without having to worry about "Dreaded Sed", "Ghastly Gawk", ...okay, I could only come up with two rhymes, but you get my point. Doing a separate path for each separate utility would be...insane, I think. And doesn't really give me what at least I would want to use it for. I either want all GNU or all BSD, no mixing flavors. > I assume that most people who select "with_default_names" variants are >> those who prefer GNU tools to BSD tools (Mac OS X respectively). >> In this case, ONE separate libexec/gnubin or libexec/gnu directory with >> un-prefixed executables would do. I you want the power to select the name >> for each and every executable, then for gods sake, make your own directory >> with symlinks: Its the same amount of work then. >> > > Ah, true, nothing is preventing anyone from making their own symlinks > somewhere. In which case, there isn't even a problem with just removing the > with_default_names variants entirely and not creating a replacement. But it > would be nice to at least symlink them into one directory. Symlinking doesn't always work. There are some packages (yes, scary enough) that *despite* the fact you have a perfectly fine symlink in a directory for it, try to do something like "stat -L" on the symlink for the utilities path. It's rare, but I've seen it occur. (It's also sick and broken, but what can you do...) -- Mark A. Miller mark at mirell.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Fri Sep 18 08:06:32 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 18 Sep 2009 10:06:32 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <31014a580909180758kc4b068brb6d2e61c7283732d@mail.gmail.com> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <31014a580909172302v5c0a645awf6b58f654349c818@mail.gmail.com> <31014a580909172309s17236bd3y388a6e6cbe5b9252@mail.gmail.com> <20090918064409.GA2844@ninagal.withay.com> <31014a580909180758kc4b068brb6d2e61c7283732d@mail.gmail.com> Message-ID: <17D3ADD6-F154-4ED4-9417-0DFBA3A15A2C@macports.org> On Sep 18, 2009, at 09:58, Mark A. Miller wrote: > On Fri, Sep 18, 2009 at 6:40 AM, Ryan Schmidt wrote: > >> Yes, I did mean one libexec/${name} directory for each port that >> we're talking about here. I see this variant in coreutils, >> diffutils, findutils, gsed, gnetcat, gnutar, gwhich, and m4. gawk >> doesn't have this variant but whatever solution we come up with for >> the others could be applied to gawk as well. Whether having a >> separate directory for each of those is excessive depends on the >> purpose of having the directory in the first place. Since I am not >> a person who wants these utilities with their default names, I >> wasn't sure what those who do want that are wanting exactly, that's >> why I was asking. > > Doing a separate path for each separate utility would be...insane, I > think. And doesn't really give me what at least I would want to use > it for. I either want all GNU or all BSD, no mixing flavors. Ok. Then let's just do a single "gnubin" directory as you said. >> Ah, true, nothing is preventing anyone from making their own >> symlinks somewhere. In which case, there isn't even a problem with >> just removing the with_default_names variants entirely and not >> creating a replacement. But it would be nice to at least symlink >> them into one directory. > > Symlinking doesn't always work. There are some packages (yes, scary > enough) that *despite* the fact you have a perfectly fine symlink in > a directory for it, try to do something like "stat -L" on the > symlink for the utilities path. It's rare, but I've seen it occur. > (It's also sick and broken, but what can you do...) Well, all we're proposing is that the ports should automatically create default-named symlinks in ${prefix}/libexec/gnubin to the programs that are being installed. So if that doesn't work for what you need, then the proposed changes won't help... But I don't see why a program would do a "stat -L" on awk or sed or grep... The current with_default_names variants also all just create default- named symlinks, though in ${prefix}/bin. And you haven't mentioned that not working... From raimue at macports.org Fri Sep 18 08:06:38 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 18 Sep 2009 17:06:38 +0200 Subject: Do Explorative Programming in tclsh with Readline Support In-Reply-To: <76B8B081-9F25-454A-A88A-430BF63B6245@macports.org> References: <76B8B081-9F25-454A-A88A-430BF63B6245@macports.org> Message-ID: <4AB3A1FE.7010804@macports.org> On 2009-09-18 14:47 , Ryan Schmidt wrote: > Leaving rlwrap out of it for the moment, I can run "tclsh" (or > "tclsh8.4" or "tclsh8.5"). But as soon as I try to "source ~/path/to/ > macports_testing.tcl" I don't see the successful "1.0" message but > instead: > > can't read "workpath": can't read "portbuildpath": no such variable > > Can anybody help? I can reproduce the problem here. This error comes from the line 'package require port 1.0'. You can see a backtrace in tclsh using 'set errorInfo'. Unfortunately the interface of the port 1.0 package is not as clean as it should be. Usually port 1.0 is required from macports::worker_init where several variables are already in the global namespace, such as portarchivemode (which is already set in the instructions on the wiki) and portbuildpath. I do not have a list what else might be used, as it would only be recognized once you run the specific command in this way from tclsh. portbuildpath is used in lazy evaluation for the workpath variable, which means it is required as soon as the first access to workpath happens. The gsoc08-privileges added a read operation on workpath causing the evaluation to happen and this lets the loading fail now. I don't know what you want to do, as a quick workaround just do not require port 1.0 for now. Rainer From ryandesign at macports.org Fri Sep 18 08:13:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 18 Sep 2009 10:13:38 -0500 Subject: Do Explorative Programming in tclsh with Readline Support In-Reply-To: <4AB3A1FE.7010804@macports.org> References: <76B8B081-9F25-454A-A88A-430BF63B6245@macports.org> <4AB3A1FE.7010804@macports.org> Message-ID: <1E08F5A9-4110-4946-9F5B-12B84255D2DC@macports.org> On Sep 18, 2009, at 10:06, Rainer M?ller wrote: > This error comes from the line 'package require port 1.0'. You can > see a > backtrace in tclsh using 'set errorInfo'. > > Unfortunately the interface of the port 1.0 package is not as clean as > it should be. Usually port 1.0 is required from macports::worker_init > where several variables are already in the global namespace, such as > portarchivemode (which is already set in the instructions on the wiki) > and portbuildpath. I do not have a list what else might be used, as it > would only be recognized once you run the specific command in this way > from tclsh. > > portbuildpath is used in lazy evaluation for the workpath variable, > which means it is required as soon as the first access to workpath > happens. The gsoc08-privileges added a read operation on workpath > causing the evaluation to happen and this lets the loading fail now. > > I don't know what you want to do, as a quick workaround just do not > require port 1.0 for now. Thanks. I wanted to play with strsed, which works fine without port 1.0. From alakazam at macports.org Fri Sep 18 09:13:12 2009 From: alakazam at macports.org (Olivier Le Floch) Date: Fri, 18 Sep 2009 18:13:12 +0200 Subject: [57854] trunk/dports/www/phpmyadmin/Portfile In-Reply-To: <4AB2D186.3050405@macports.org> References: <20090917153616.4A8BA278F917@beta.macosforge.org> <6A0A6DC2-95E0-4336-91E5-8EC11E4D5D56@macports.org> <46BA9D78-783F-46DD-878B-2ADF4F3FD0EC@macports.org> <4AB2D186.3050405@macports.org> Message-ID: Hi, Thanks for the input and advice on this issue ! On 18 sept. 09, at 02:17, Rainer M?ller wrote: > On 2009-09-17 23:26 , Ryan Schmidt wrote: >> Personally, I prefer to tell the user where the sample files are so >> they can make copies if and when they want. Other port authors have >> taken recently to copying the sample files for the user. > > If the software requires the config file to run at all, it makes sense > to copy it in a post-activate phase. Otherwise, there is no need to > do this. I agree. In the case of the phpMyAdmin port, the configuration file is not required, but since phpMyAdmin expects its configuration file to be in it's root directory (i.e. in /opt/local/www/phpmyadmin/ for macports), uninstalling/upgrading phpmyadmin would destroy/conflict with the user's configuration file. Because of this, I had to add a symlink from the default configuration file location to somewhere in $ {prefix}/etc/. Unfortunately, phpMyAdmin calls it's configuration file {{{config.inc.php}}}, which meant I had to rename it (and differ from phpMyAdmin's documentation) in ${prefix}/etc/, and the easiest way I think to document this name change was to directly install the sample config file. phpMyAdmin seems to work with the symlink and no configuration file, but that would still leave it to the user to understand in what custom location the config file was to be put, so I'm under the impression that this would be the best solution for the user while still complying with macports guidelines. Best regards, -- Olivier From talklists at newgeo.com Fri Sep 18 12:57:36 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 18 Sep 2009 12:57:36 -0700 Subject: dscl In-Reply-To: <8E1919C8-E26F-43E0-8294-BF72314BA554@geeklair.net> References: <3C42F4AE-0965-45ED-BBD1-547CC6F2EC16@newgeo.com> <8E1919C8-E26F-43E0-8294-BF72314BA554@geeklair.net> Message-ID: On Sep 18, 2009, at 6:53 AM, Daniel J. Luke wrote: > On Sep 17, 2009, at 9:44 PM, Scott Haneda wrote: >> Hello, I am working on trying to make a change to a port that does >> not have user and group adding abilities, but it probably should. >> At this point, I need to confirm this by adding a user and group by >> hand, using dscl in Mac OS X 10.5 > > The port should use the adduser/addgroup commands (see 'man portfile') Yes, thanks, eventually I will use those commands, though for the time being, I need to test that it works in this way, to be sure I am even on the right track. >> I took this from some old docs on dovecot: >> sudo dscl . -create /Groups/_ftpg >> sudo dscl . -create /Groups/_ftpg UniqueID 490 >> sudo dscl . -create /Users/_ftpu >> sudo dscl . -create /Users/_ftpu UserShell /usr/bin/false >> sudo dscl . -create /Users/_ftpu RealName "PureFTPd FTP Server" >> sudo dscl . -create /Users/_ftpu UniqueID 490 >> sudo dscl . -create /Users/_ftpu PrimaryGroupID 490 >> sudo dscl . -create /Users/_ftpu NFSHomeDirectory /var/empty >> >> This sort of works. In this case, the ftpd has a flag to "auto >> create home dirs", which I have enabled. I have told the ftpd to >> use user and group 490. On first ftp login, it will create the >> directory I tell it to: >> >> drwxr-x--- 2 _ftpu 490 68 Sep 17 18:42 someplace >> >> As you can see, there is something wrong with the group. > > You didn't set PrimaryGroupID Thank you, that did the trick. >> $sudo chgrp _ftpg someplace/ >> drwxr-x--- 2 _ftpu nobody 68 Sep 17 18:42 someplace >> >> I think what I would really like to do is also create a user and >> group more like www and mysql, where they have both the _foo and >> foo version, but I can not figure this out. > > why? I don't think you want/need to have the user be 'special' in > this way. Any idea what the significance of the _user and _group is? -- Scott * If you contact me off list replace talklists@ with scott@ * From dluke at geeklair.net Fri Sep 18 13:06:13 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 18 Sep 2009 16:06:13 -0400 Subject: dscl In-Reply-To: References: <3C42F4AE-0965-45ED-BBD1-547CC6F2EC16@newgeo.com> <8E1919C8-E26F-43E0-8294-BF72314BA554@geeklair.net> Message-ID: On Sep 18, 2009, at 3:57 PM, Scott Haneda wrote: >> On Sep 17, 2009, at 9:44 PM, Scott Haneda wrote: >>> Hello, I am working on trying to make a change to a port that does >>> not have user and group adding abilities, but it probably should. >>> At this point, I need to confirm this by adding a user and group >>> by hand, using dscl in Mac OS X 10.5 >> >> The port should use the adduser/addgroup commands (see 'man >> portfile') > > Yes, thanks, eventually I will use those commands, though for the > time being, I need to test that it works in this way, to be sure I > am even on the right track. I don't see how that's the case. Either you need a user/group added (in which case you should use adduser/addgroup) or you don't. If you're just checking to see if you need a user/group added, then it seems like it would be easier to just use adduser/addgroup and then test. >>> I think what I would really like to do is also create a user and >>> group more like www and mysql, where they have both the _foo and >>> foo version, but I can not figure this out. >> >> why? I don't think you want/need to have the user be 'special' in >> this way. > > Any idea what the significance of the _user and _group is? I would guess that it's just to mark that they're system-provided non- login users. Also, you don't want to use low number uid/gids (which adduser/ addgroup will not use) since they're reserved by Apple. -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From talklists at newgeo.com Fri Sep 18 13:14:37 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 18 Sep 2009 13:14:37 -0700 Subject: dscl In-Reply-To: References: <3C42F4AE-0965-45ED-BBD1-547CC6F2EC16@newgeo.com> <8E1919C8-E26F-43E0-8294-BF72314BA554@geeklair.net> Message-ID: <9D769BDF-3497-47DC-8886-AB937EED923F@newgeo.com> On Sep 18, 2009, at 1:06 PM, Daniel J. Luke wrote: > On Sep 18, 2009, at 3:57 PM, Scott Haneda wrote: >>> On Sep 17, 2009, at 9:44 PM, Scott Haneda wrote: >>>> Hello, I am working on trying to make a change to a port that >>>> does not have user and group adding abilities, but it probably >>>> should. At this point, I need to confirm this by adding a user >>>> and group by hand, using dscl in Mac OS X 10.5 >>> >>> The port should use the adduser/addgroup commands (see 'man >>> portfile') >> >> Yes, thanks, eventually I will use those commands, though for the >> time being, I need to test that it works in this way, to be sure I >> am even on the right track. > > I don't see how that's the case. Either you need a user/group added > (in which case you should use adduser/addgroup) or you don't. Because there is some strange interaction with the ftpd and users and groups that I am trying to pin down. How the user and group is displayed on the file system, versus how it is shown in an ftp client. If I alter the portfile, I have to to rebuild the source every time to test my work, and as far as I know, MacPorts also does not remove users and groups. It seems simpler and faster to me to just test this one issue this way, then close up with the port file changes. > If you're just checking to see if you need a user/group added, then > it seems like it would be easier to just use adduser/addgroup and > then test. > >>>> I think what I would really like to do is also create a user and >>>> group more like www and mysql, where they have both the _foo and >>>> foo version, but I can not figure this out. >>> >>> why? I don't think you want/need to have the user be 'special' in >>> this way. >> >> Any idea what the significance of the _user and _group is? > > I would guess that it's just to mark that they're system-provided > non-login users. > > Also, you don't want to use low number uid/gids (which adduser/ > addgroup will not use) since they're reserved by Apple. Ok, understood. Though I thought anything over 499 would show up in the login window, which is what I was trying to avoid. This user and group I am creating is indeed a non login user. How does MacPorts determine which uid/guid to use? Is there a higher range that it starts with that also does not show up in the login window? Thanks -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Fri Sep 18 13:30:32 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 18 Sep 2009 15:30:32 -0500 Subject: dscl In-Reply-To: <9D769BDF-3497-47DC-8886-AB937EED923F@newgeo.com> References: <3C42F4AE-0965-45ED-BBD1-547CC6F2EC16@newgeo.com> <8E1919C8-E26F-43E0-8294-BF72314BA554@geeklair.net> <9D769BDF-3497-47DC-8886-AB937EED923F@newgeo.com> Message-ID: On Sep 18, 2009, at 15:14, Scott Haneda wrote: > Ok, understood. Though I thought anything over 499 would show up in > the login window, which is what I was trying to avoid. This user > and group I am creating is indeed a non login user. How does > MacPorts determine which uid/guid to use? Is there a higher range > that it starts with that also does not show up in the login window? On my old Tiger install, before doing a clean install with Snow Leopard, I did have a lot of users showing up in System Preferences from ports I'd tested once and then uninstalled. A little annoying. Not sure if there's a way ports are meant to avoid having their users show up there. From dluke at geeklair.net Fri Sep 18 13:42:22 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 18 Sep 2009 16:42:22 -0400 Subject: dscl In-Reply-To: References: <3C42F4AE-0965-45ED-BBD1-547CC6F2EC16@newgeo.com> <8E1919C8-E26F-43E0-8294-BF72314BA554@geeklair.net> <9D769BDF-3497-47DC-8886-AB937EED923F@newgeo.com> Message-ID: <67A69F2C-C8E6-42E4-8459-6FFAEB6C8B4E@geeklair.net> On Sep 18, 2009, at 4:30 PM, Ryan Schmidt wrote: >> Ok, understood. Though I thought anything over 499 would show up >> in the login window, which is what I was trying to avoid. This >> user and group I am creating is indeed a non login user. How does >> MacPorts determine which uid/guid to use? Is there a higher range >> that it starts with that also does not show up in the login window? > > On my old Tiger install, before doing a clean install with Snow > Leopard, I did have a lot of users showing up in System Preferences > from ports I'd tested once and then uninstalled. A little annoying. > Not sure if there's a way ports are meant to avoid having their > users show up there. I don't know if it works, but the internets seem to say you can do something like: sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array-add user1 user2 user3 user4 might be something nice to add to base/ (as an option to adduser perhaps) -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From talklists at newgeo.com Fri Sep 18 13:46:17 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 18 Sep 2009 13:46:17 -0700 Subject: dscl In-Reply-To: References: <3C42F4AE-0965-45ED-BBD1-547CC6F2EC16@newgeo.com> <8E1919C8-E26F-43E0-8294-BF72314BA554@geeklair.net> Message-ID: Where does adduser/addgroup get the uid and gid to start with so it does not have collisions? -- Scott * If you contact me off list replace talklists@ with scott@ * On Sep 18, 2009, at 1:06 PM, Daniel J. Luke wrote: > Also, you don't want to use low number uid/gids (which adduser/ > addgroup will not use) since they're reserved by Apple. From dluke at geeklair.net Fri Sep 18 14:01:57 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 18 Sep 2009 17:01:57 -0400 Subject: dscl In-Reply-To: References: <3C42F4AE-0965-45ED-BBD1-547CC6F2EC16@newgeo.com> <8E1919C8-E26F-43E0-8294-BF72314BA554@geeklair.net> Message-ID: On Sep 18, 2009, at 4:46 PM, Scott Haneda wrote: > Where does adduser/addgroup get the uid and gid to start with so it > does not have collisions? The best way to answer a question like this, is to look at the source: http://trac.macports.org/browser/trunk/base/src/port1.0/portutil.tcl proc adduser sets the uid by calling nextuid nextuid is from Pextlib.c: http://trac.macports.org/browser/trunk/base/src/pextlib1.0/Pextlib.c There you can see that nextuid is implemented by NextuidCmd, which starts at MIN_USABLE_UID (which is set to 500) and increments until it finds an unused uid. (It uses the same algorithm to find an unused gid). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From howarth at bromo.med.uc.edu Fri Sep 18 14:17:11 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 18 Sep 2009 17:17:11 -0400 Subject: darwin may lose primary target status on FSF gcc Message-ID: <20090918211711.GA12018@bromo.med.uc.edu> Just a heads up for the gcc4x package maintainers here that due to the P1 regressions in exception handling on darwin10 for current gcc trunk (4.5), darwin may lose its primary target status... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260#c31 I have also discovered some things about libgcc in Snow Leopard which I was previously unaware of... http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025900.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025906.html It appears that symbols exposed in libgcc-10.5 have now been moved into libSystem for 10.6 and those symbols from *any* libgcc_s aren't used (only from libSystem). What this means is that the standard build of FSF gcc (which always links against the libgcc it builds) is no longer really using its own libgcc. So any forking between the unwinder in Apple's libgcc_s (now really in libSystem) and FSF's unwinder (in it's libgcc_s) is now exposed (hence all the exception handling regressions in gcc trunk). The solution that I believe Apple's compiler developers are recommending is to build FSF gcc against the systen libgcc (using --with-slib=) and having FSF gcc upstream move all of the new symbols (not present in libgcc-10.5) into a libgcc-ext library. This method has already been proposed to provide the missing emults symbols (that were added post-libgcc-10.5). http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888 I'll be doing some test builds this weekend with --with-slib on gcc trunk to see how well it survives that. It has been ages since anyone has tried to build with the system libgcc. Jack ps I guess we shouldn't really be surprised since clang would have an odd relationship to libgcc (so they would want to move those symbols into libSystem). From talklists at newgeo.com Fri Sep 18 16:12:56 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 18 Sep 2009 16:12:56 -0700 Subject: starting pureftpd port Message-ID: http://trac.macports.org/browser/trunk/dports/net/pureftpd/Portfile I wonder if someone can lend me a hand in figuring out the correct way to start this ftpd on Leopard: From the current port file: # Notify the user how to launch the ftpd post-install { ui_msg "\nYou can now start PureFTPd in 3 ways," ui_msg "either via xinetd, in standalone mode, or" ui_msg "if you're using Mac OS X 10.4 / Darwin 8.x" ui_msg "via launchd(8).\n" ui_msg "If you're under Mac OS X 10.3 or Mac OS X 10.4," ui_msg "you have to copy ${prefix}/share/doc/${name}/pure-ftpd" ui_msg "to /etc/pam.d and use the '-lpam' flag when" ui_msg "launching pure-ftpd to have PAM working.\n" } I can start pureftpd and it works from the command line now. Apple has /System/Library/LaunchDaemons/ftp.plist which seems to get the disabled key toggled around depending on how your system preferences are set. If I want to maintain that feature, enable and disable by System preferences, I take it I would need to alter /System/Library/ LaunchDaemons/ftp.plist? I am thinking in this case, there are so many ways to start this, the portfile needs to just install a plist and ui_msg where it is and how to enabled it. I do not know the correct location to put it, and how to configure it so that it is on demand. I believe the Apple ftp dies and only comes alive when a request comes in, which is nice, as you do not have a ftpd running 24/7, only when you need it. Thanks -- Scott * If you contact me off list replace talklists@ with scott@ * From howarth at bromo.med.uc.edu Fri Sep 18 16:38:15 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 18 Sep 2009 19:38:15 -0400 Subject: darwin may lose primary target status on FSF gcc Message-ID: <20090918233815.GA12896@bromo.med.uc.edu> There is hope! We have an analysis of the exact breakage in eh under 10.6 for gcc trunk... http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html The breakage in gcc trunk is due to the additional epilog unwind information which darwin's unwinder (which is always used under 10.6 since symbols in libgcc-10.5 always come from libSystem) doesn't understand. The possible fixes are either to 1) not add the additional epilog unwind information on darwin or 2) have the gcc driver on darwin implicitly pass -no_compact_unwind to the link line. Cheers. Jack From opendarwin.org at darkart.com Fri Sep 18 16:46:57 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Fri, 18 Sep 2009 23:46:57 +0000 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090918233815.GA12896@bromo.med.uc.edu> References: <20090918233815.GA12896@bromo.med.uc.edu> Message-ID: <20090918234657.GP1215@darkart.com> On Fri, Sep 18, 2009 at 07:38:15PM -0400, Jack Howarth wrote: > There is hope! We have an analysis of the exact > breakage in eh under 10.6 for gcc trunk... > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html > > The breakage in gcc trunk is due to the additional epilog unwind > information which darwin's unwinder (which is always used under > 10.6 since symbols in libgcc-10.5 always come from libSystem) > doesn't understand. The possible fixes are either to 1) not add > the additional epilog unwind information on darwin or 2) have > the gcc driver on darwin implicitly pass -no_compact_unwind to > the link line. Cheers. > Jack Did someone care somewhere in here? From howarth at bromo.med.uc.edu Fri Sep 18 16:57:53 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 18 Sep 2009 19:57:53 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090918234657.GP1215@darkart.com> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> Message-ID: <20090918235753.GA13004@bromo.med.uc.edu> On Fri, Sep 18, 2009 at 11:46:57PM +0000, Eric Hall wrote: > On Fri, Sep 18, 2009 at 07:38:15PM -0400, Jack Howarth wrote: > > There is hope! We have an analysis of the exact > > breakage in eh under 10.6 for gcc trunk... > > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html > > > > The breakage in gcc trunk is due to the additional epilog unwind > > information which darwin's unwinder (which is always used under > > 10.6 since symbols in libgcc-10.5 always come from libSystem) > > doesn't understand. The possible fixes are either to 1) not add > > the additional epilog unwind information on darwin or 2) have > > the gcc driver on darwin implicitly pass -no_compact_unwind to > > the link line. Cheers. > > Jack > > > Did someone care somewhere in here? > > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev If anyone here cares whether gcc 4.5.0 exists in a usable form on darwin10, I should hope so. These were courtesy emails for the gcc44 maintainers here to let the know that someone is working the issue. If darwin support for gcc isn't tended to you'll eventually stuck running g95 (oh..wait...g95 doesn't build on darwin10...never mind). Actually some of this is quite interesting. The system libgcc isn't really what it seems under 10.6 and has actually been folded into libSystem (which makes sense as clang having a dependence on libgcc would be odd). The upshot is that while the gcc44 maintainers may think they are build FSF gcc to use its own libgcc that isn't the case. In darwin10, the libgcc symbols in libSystem are always used (which explains why darwin10 shows the exception handling regressions in gcc trunk and darwin9 doesn't since it is still really using the FSF libgcc which is built). Jack From opendarwin.org at darkart.com Fri Sep 18 17:19:38 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Sat, 19 Sep 2009 00:19:38 +0000 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090918235753.GA13004@bromo.med.uc.edu> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> Message-ID: <20090919001938.GQ1215@darkart.com> On Fri, Sep 18, 2009 at 07:57:53PM -0400, Jack Howarth wrote: > On Fri, Sep 18, 2009 at 11:46:57PM +0000, Eric Hall wrote: > > On Fri, Sep 18, 2009 at 07:38:15PM -0400, Jack Howarth wrote: > > > There is hope! We have an analysis of the exact > > > breakage in eh under 10.6 for gcc trunk... > > > > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html > > > > > > The breakage in gcc trunk is due to the additional epilog unwind > > > information which darwin's unwinder (which is always used under > > > 10.6 since symbols in libgcc-10.5 always come from libSystem) > > > doesn't understand. The possible fixes are either to 1) not add > > > the additional epilog unwind information on darwin or 2) have > > > the gcc driver on darwin implicitly pass -no_compact_unwind to > > > the link line. Cheers. > > > Jack > > > > > > Did someone care somewhere in here? > > > > > > > > _______________________________________________ > > macports-dev mailing list > > macports-dev at lists.macosforge.org > > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > If anyone here cares whether gcc 4.5.0 exists in a usable form > on darwin10, I should hope so. These were courtesy emails for > the gcc44 maintainers here to let the know that someone is > working the issue. If darwin support for gcc isn't tended to > you'll eventually stuck running g95 (oh..wait...g95 doesn't > build on darwin10...never mind). Huh, funny, this 'Xcode' thingy installs a compiler, seems like it works too. I'm thinking that sort of thing is going to continue in the future. Is there a reason there's ongoing discussion of gcc 4.x on a macports related list instead of on a gcc list? From howarth at bromo.med.uc.edu Fri Sep 18 17:26:16 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 18 Sep 2009 20:26:16 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090919001938.GQ1215@darkart.com> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> Message-ID: <20090919002616.GA13203@bromo.med.uc.edu> On Sat, Sep 19, 2009 at 12:19:38AM +0000, Eric Hall wrote: > On Fri, Sep 18, 2009 at 07:57:53PM -0400, Jack Howarth wrote: > > On Fri, Sep 18, 2009 at 11:46:57PM +0000, Eric Hall wrote: > > > On Fri, Sep 18, 2009 at 07:38:15PM -0400, Jack Howarth wrote: > > > > There is hope! We have an analysis of the exact > > > > breakage in eh under 10.6 for gcc trunk... > > > > > > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html > > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html > > > > > > > > The breakage in gcc trunk is due to the additional epilog unwind > > > > information which darwin's unwinder (which is always used under > > > > 10.6 since symbols in libgcc-10.5 always come from libSystem) > > > > doesn't understand. The possible fixes are either to 1) not add > > > > the additional epilog unwind information on darwin or 2) have > > > > the gcc driver on darwin implicitly pass -no_compact_unwind to > > > > the link line. Cheers. > > > > Jack > > > > > > > > > Did someone care somewhere in here? > > > > > > > > > > > > _______________________________________________ > > > macports-dev mailing list > > > macports-dev at lists.macosforge.org > > > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > > If anyone here cares whether gcc 4.5.0 exists in a usable form > > on darwin10, I should hope so. These were courtesy emails for > > the gcc44 maintainers here to let the know that someone is > > working the issue. If darwin support for gcc isn't tended to > > you'll eventually stuck running g95 (oh..wait...g95 doesn't > > build on darwin10...never mind). > > > Huh, funny, this 'Xcode' thingy installs a compiler, > seems like it works too. I'm thinking that sort of thing > is going to continue in the future. > Is there a reason there's ongoing discussion of > gcc 4.x on a macports related list instead of on a gcc > list? > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev Gee, I must be missing something from my SL Xcode installation....where is the fortran *thingy*? Jack ps No one is forcing you to read the posts. From toby at macports.org Fri Sep 18 17:31:40 2009 From: toby at macports.org (Toby Peterson) Date: Fri, 18 Sep 2009 17:31:40 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090919002616.GA13203@bromo.med.uc.edu> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> Message-ID: <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> On Fri, Sep 18, 2009 at 17:26, Jack Howarth wrote: > On Sat, Sep 19, 2009 at 12:19:38AM +0000, Eric Hall wrote: >> On Fri, Sep 18, 2009 at 07:57:53PM -0400, Jack Howarth wrote: >> > On Fri, Sep 18, 2009 at 11:46:57PM +0000, Eric Hall wrote: >> > > On Fri, Sep 18, 2009 at 07:38:15PM -0400, Jack Howarth wrote: >> > > > ? There is hope! We have an analysis of the exact >> > > > breakage in eh under 10.6 for gcc trunk... >> > > > >> > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html >> > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html >> > > > >> > > > The breakage in gcc trunk is due to the additional epilog unwind >> > > > information which darwin's unwinder (which is always used under >> > > > 10.6 since symbols in libgcc-10.5 always come from libSystem) >> > > > doesn't understand. The possible fixes are either to 1) not add >> > > > the additional epilog unwind information on darwin or 2) have >> > > > the gcc driver on darwin implicitly pass -no_compact_unwind to >> > > > the link line. Cheers. >> > > > ? ? ? ? ? ?Jack >> > > >> > > >> > > ? Did someone care somewhere in here? >> > > >> > > >> > > >> > > _______________________________________________ >> > > macports-dev mailing list >> > > macports-dev at lists.macosforge.org >> > > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> > >> > If anyone here cares whether gcc 4.5.0 exists in a usable form >> > on darwin10, I should hope so. These were courtesy emails for >> > the gcc44 maintainers here to let the know that someone is >> > working the issue. If darwin support for gcc isn't tended to >> > you'll eventually stuck running g95 (oh..wait...g95 doesn't >> > build on darwin10...never mind). >> >> >> ? ? ? Huh, funny, this 'Xcode' thingy installs a compiler, >> seems like it works too. ?I'm thinking that sort of thing >> is going to continue in the future. >> ? ? ? Is there a reason there's ongoing discussion of >> gcc 4.x on a macports related list instead of on a gcc >> list? >> >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > Gee, I must be missing something from my SL Xcode > installation....where is the fortran *thingy*? > ? ? ? ? ? ? ?Jack > ps No one is forcing you to read the posts. Given current reality, you're probably better off contributing to llvm-gfortran... or better yet, a native fortran front-end for llvm. FSF gcc is barely relevant on our platform these days. - Toby From howarth at bromo.med.uc.edu Fri Sep 18 17:43:48 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 18 Sep 2009 20:43:48 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> Message-ID: <20090919004348.GA13265@bromo.med.uc.edu> On Fri, Sep 18, 2009 at 05:31:40PM -0700, Toby Peterson wrote: > > Given current reality, you're probably better off contributing to > llvm-gfortran... or better yet, a native fortran front-end for llvm. > FSF gcc is barely relevant on our platform these days. > > - Toby Toby, I created the fink llvm/llvm-gcc42 packages to provide them with a llvm-gfortran. However the gfortran in llvm-gcc42 is just that (locked at the gcc 4.2.1 release because it was the last GPLv2 release that Apple will accept). It has much worse performance than the current gfortran in gcc 4.4.0, has fewer features and significant portions of the newer features aren't working properly. The chances of llvm-gcc being updated to a newer release are basically zero and there is no clang related fortran compiler at all. You work with the hand your dealt...and for us that is trying to keep the wheels on FSF gcc for darwin as long as possible. Actually gcc 4.4.1 has excellent testsuite results on darwin10. Also look at... http://www.mail-archive.com/fink-devel at lists.sourceforge.net/msg18166.html http://archive.netbsd.se/?ml=fink-devel&a=2009-03&m=10250229 where I benchmarked the various gcc compilers on Intel darwin. Lastly, if you check the table at... http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ you will see how really bad it would be to have to rely on g95 even if it built on darwin10 (almost 3 times slower than current gfortran). Jack From alakazam at macports.org Fri Sep 18 18:03:58 2009 From: alakazam at macports.org (Olivier Le Floch) Date: Sat, 19 Sep 2009 03:03:58 +0200 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090919001938.GQ1215@darkart.com> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> Message-ID: <19FF6DEE-BA24-44ED-AA56-23F33A39EB2E@macports.org> > Is there a reason there's ongoing discussion of > gcc 4.x on a macports related list instead of on a gcc > list? Seing as there are numerous math-related ports that depend on gcc- related ports, I'd think raising this issue on this mailing list is *particularly* adequate ? raising it in 3 successive separate mails might not be optimal, though ;) FWIW, as the octave maintainer, it would seem to me that understanding the options that we'll have in the future for fortran code compilation is quite important, and the discussion between Toby and Jack seems interesting to me. From howarth at bromo.med.uc.edu Fri Sep 18 18:05:18 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 18 Sep 2009 21:05:18 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> Message-ID: <20090919010518.GA13505@bromo.med.uc.edu> Toby, If you are interested, here are the results for Polyhedron 2005 benchmarks (the reference set used for testing fortran compilers) for the x86_64 code generated by gcc 4.2.4 and llvm-gcc 4.2.1's gfortran compilers respectively on darwin9... http://www.nabble.com/x86_64-apple-darwin-Polyhedron-2005-benchmarks-td25108861.html The results aren't bad when compared to gcc 4.2.4 but that is an ancient release by gfortran standards (basically when it just started to be usable). In the intervening releases, there have been many changes to wire it up better to the gcc middle end so that it optimizes much better (and a huge number of bug fixes and extensions for newer fortran standards). Jack From howarth at bromo.med.uc.edu Fri Sep 18 18:08:44 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 18 Sep 2009 21:08:44 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <19FF6DEE-BA24-44ED-AA56-23F33A39EB2E@macports.org> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <19FF6DEE-BA24-44ED-AA56-23F33A39EB2E@macports.org> Message-ID: <20090919010844.GB13505@bromo.med.uc.edu> On Sat, Sep 19, 2009 at 03:03:58AM +0200, Olivier Le Floch wrote: >> Is there a reason there's ongoing discussion of >> gcc 4.x on a macports related list instead of on a gcc >> list? > > Seing as there are numerous math-related ports that depend on gcc- > related ports, I'd think raising this issue on this mailing list is > *particularly* adequate ? raising it in 3 successive separate mails > might not be optimal, though ;) > > FWIW, as the octave maintainer, it would seem to me that understanding > the options that we'll have in the future for fortran code compilation > is quite important, and the discussion between Toby and Jack seems > interesting to me. > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev I was most interested in getting across the change of libgcc being subsumed into libSystem on darwin10, I haven't seen that mentioned anywhere before. Knowing this now, I am actually quite surprised that gcc 4.4.1 works as well as it does under darwin10. Jack From mark at mirell.org Fri Sep 18 20:20:00 2009 From: mark at mirell.org (Mark A. Miller) Date: Fri, 18 Sep 2009 22:20:00 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <17D3ADD6-F154-4ED4-9417-0DFBA3A15A2C@macports.org> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <31014a580909172309s17236bd3y388a6e6cbe5b9252@mail.gmail.com> <20090918064409.GA2844@ninagal.withay.com> <31014a580909180758kc4b068brb6d2e61c7283732d@mail.gmail.com> <17D3ADD6-F154-4ED4-9417-0DFBA3A15A2C@macports.org> Message-ID: <31014a580909182020g656aa49xa1aeff6cf3bb83c5@mail.gmail.com> On Fri, Sep 18, 2009 at 10:06 AM, Ryan Schmidt wrote: > > On Sep 18, 2009, at 09:58, Mark A. Miller wrote: > > On Fri, Sep 18, 2009 at 6:40 AM, Ryan Schmidt wrote: >> > > Ah, true, nothing is preventing anyone from making their own symlinks >>> somewhere. In which case, there isn't even a problem with just removing the >>> with_default_names variants entirely and not creating a replacement. But it >>> would be nice to at least symlink them into one directory. >>> >> >> Symlinking doesn't always work. There are some packages (yes, scary >> enough) that *despite* the fact you have a perfectly fine symlink in a >> directory for it, try to do something like "stat -L" on the symlink for the >> utilities path. It's rare, but I've seen it occur. (It's also sick and >> broken, but what can you do...) >> > > Well, all we're proposing is that the ports should automatically create > default-named symlinks in ${prefix}/libexec/gnubin to the programs that are > being installed. So if that doesn't work for what you need, then the > proposed changes won't help... But I don't see why a program would do a > "stat -L" on awk or sed or grep... > It's rare. But I'll concede on that, it's a very strange corner case. (But it's always those we remember the best...) The current with_default_names variants also all just create default-named > symlinks, though in ${prefix}/bin. And you haven't mentioned that not > working... > I haven't done that because it breaks other things, I just copied the executables into a separate directory and stripped off their names for my own purposes. So, ${prefix}/libexec/gnubin seems to work, and put symlinks there for the GNU binaries by default, and get rid of this variant? -- Mark A. Miller mark at mirell.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From vince at macports.org Sat Sep 19 00:01:42 2009 From: vince at macports.org (vincent habchi) Date: Sat, 19 Sep 2009 09:01:42 +0200 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090919010518.GA13505@bromo.med.uc.edu> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> <20090919010518.GA13505@bromo.med.uc.edu> Message-ID: Jack, > http://www.nabble.com/x86_64-apple-darwin-Polyhedron-2005-benchmarks-td25108861.html These figures are very interesting, but I don't understand why they lack the gcc 4.2.4 -m64 performance; was that unavailable at that time? I would be also curious to see the relative performance of the two compilers on C-based scientific benchmarks (like BLAS or gsl or whatever). I know that because of aliasing, C compilers cannot optimize as much as Fortran ones do, but that may be at least partly solved by using the new C99 syntax. It also raises other questions: 1. Could we compare those figures with the ones obtained with a "professional" compiler like, e.g. the Intel C/Fortran compilers for Mac? 2. What are the relative possibilities of progression of GCC and LLVM? I mean, maybe LLVM is lagging these days, but if the intermediate code representation it uses is potentially more powerful that the one chosen for GCC (as it is publicized), it might be just a matter of months before the results get close to a draw. 3. What is the place of Fortran in modern scientific computing compared to C-based languages? More specifically, in the scientific packages available in MacPorts like, e.g. SparseSuite, what part of the Fortran code is actively under development and what part is only legacy code? 4. What is the place of Open-CL? Of course, Open-CL is brand new, but with its capacities to unleashed massive parallel computing power, it could represent an awesome tool for matrix operations. Yet, I understand that due to the overhead of moving data to and fro the video RAM, Open-CL is inefficient for small matrix sizes; but that's also simply where optimization of CPU code is not really significant either. Vincent From toby at macports.org Sat Sep 19 01:03:26 2009 From: toby at macports.org (Toby Peterson) Date: Sat, 19 Sep 2009 01:03:26 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090919004348.GA13265@bromo.med.uc.edu> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> <20090919004348.GA13265@bromo.med.uc.edu> Message-ID: <74c219d30909190103n41af3607y4dc88e9b532ff9d2@mail.gmail.com> On Fri, Sep 18, 2009 at 17:43, Jack Howarth wrote: > On Fri, Sep 18, 2009 at 05:31:40PM -0700, Toby Peterson wrote: >> >> Given current reality, you're probably better off contributing to >> llvm-gfortran... or better yet, a native fortran front-end for llvm. >> FSF gcc is barely relevant on our platform these days. >> >> - Toby > > Toby, > ? I created the fink llvm/llvm-gcc42 packages to provide > them with a llvm-gfortran. However the gfortran in llvm-gcc42 > is just that (locked at the gcc 4.2.1 release because it > was the last GPLv2 release that Apple will accept). It has > much worse performance than the current gfortran in gcc 4.4.0, > has fewer features and significant portions of the newer > features aren't working properly. The chances of llvm-gcc > being updated to a newer release are basically zero and > there is no clang related fortran compiler at all. You > work with the hand your dealt...and for us that is trying > to keep the wheels on FSF gcc for darwin as long as possible. > Actually gcc 4.4.1 has excellent testsuite results on darwin10. > Also look at... > > http://www.mail-archive.com/fink-devel at lists.sourceforge.net/msg18166.html > http://archive.netbsd.se/?ml=fink-devel&a=2009-03&m=10250229 > > where I benchmarked the various gcc compilers on Intel darwin. > Lastly, if you check the table at... > > http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ > > you will see how really bad it would be to have to rely on > g95 even if it built on darwin10 (almost 3 times slower > than current gfortran). That's why I suggested *contributing* to llvm-gfortran or a native front-end. If it lags behind, make it better. FSF gcc just doesn't have much of a future on our platform... - Toby From jeremy at lavergne.gotdns.org Sat Sep 19 08:51:20 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 19 Sep 2009 11:51:20 -0400 Subject: Lprof port on Macports In-Reply-To: <3783.31254.qm@web27208.mail.ukl.yahoo.com> References: <3783.31254.qm@web27208.mail.ukl.yahoo.com> Message-ID: I'll check into it. Presently I'm without regular internet access so things are going to be a bit rough for a week or so. On Sep 19, 2009, at 8:44 AM, Jannes Bolten wrote: > hi, > > i would like to build Lprof on my machine using macports. the > current version of Lprof on Macports is an old one (20090113). would > it be able to update the port for Lprof with the latest source code > from CVS? > > thanks for looking at this! > > regards, > jannes bolten > > From howarth at bromo.med.uc.edu Sat Sep 19 10:05:05 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 19 Sep 2009 13:05:05 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> <20090919010518.GA13505@bromo.med.uc.edu> Message-ID: <20090919170505.GA18798@bromo.med.uc.edu> On Sat, Sep 19, 2009 at 09:01:42AM +0200, vincent habchi wrote: > Jack, > >> http://www.nabble.com/x86_64-apple-darwin-Polyhedron-2005-benchmarks-td25108861.html > > These figures are very interesting, but I don't understand why they lack > the gcc 4.2.4 -m64 performance; was that unavailable at that time? I > would be also curious to see the relative performance of the two > compilers on C-based scientific benchmarks (like BLAS or gsl or > whatever). I know that because of aliasing, C compilers cannot optimize > as much as Fortran ones do, but that may be at least partly solved by > using the new C99 syntax. > Aren't those showing up for you? At the bottom of that url link is another message with more complete benchmarks for... benchmark gcc-4.2.4 gcc-4.2.4 llvm-gcc-svn llvm-gcc-2.6 llvm-gcc-2.6 gcc-4.4.1 gcc-4.4.1 at -m32 at -m64 20081031 -m32 at -m32 at -m64 at -m32 at -m64 ..that I ran later. > It also raises other questions: > > 1. Could we compare those figures with the ones obtained with a > "professional" compiler like, e.g. the Intel C/Fortran compilers for > Mac? I don't have any of the professional compilers myself on the Mac (hence my obession with keeping gfortran healthy). However I would argue that the results from http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ give a pretty accurate idea of how gfortran rates compared to the other commercial compilers. The only caveat is that those are for AMD chipsets. > > 2. What are the relative possibilities of progression of GCC and LLVM? I > mean, maybe LLVM is lagging these days, but if the intermediate code > representation it uses is potentially more powerful that the one chosen > for GCC (as it is publicized), it might be just a matter of months before > the results get close to a draw. > The focus in llvm is really on clang these days. There also are Link Time Optimizations available at -O4 for both llvm-gcc-4.2 and clang but you have to link with the cctools in /Developer/usr/bin and not those in /usr/bin (at least for Leopard) to obtain that. Last I looked the optimizations centered around dead-code elimination but the LTO is being expanded. Do keep in mind that clang really doesn't have a usable c++ compiler yet so as you can imagine that is where their focus is for development (not fortran). > 3. What is the place of Fortran in modern scientific computing compared > to C-based languages? More specifically, in the scientific packages > available in MacPorts like, e.g. SparseSuite, what part of the Fortran > code is actively under development and what part is only legacy code? > Well, in NMR we still have a number of packages (like xplor-nih) which require a fortran compiler. Legacy code isn't going to disappear. That said, gfortran is constantly adapting to the latest standards... http://gcc.gnu.org/wiki/GFortran#news Also I would argue that the availablity of a free high quality compiler that supports the latest standards alone can be a big driver of what how things get written. FYI, this link shows how much for the fortran 2003 support is implemented... http://gcc.gnu.org/wiki/Fortran2003 > 4. What is the place of Open-CL? Of course, Open-CL is brand new, but > with its capacities to unleashed massive parallel computing power, it > could represent an awesome tool for matrix operations. Yet, I understand > that due to the overhead of moving data to and fro the video RAM, Open-CL > is inefficient for small matrix sizes; but that's also simply where > optimization of CPU code is not really significant either. I haven't had a chance to look into OpenCL yet. Frankly, I am mainly concerned that our current tool suite remains functional so folks don't feel the need to resort to linux for scientific computing. If we do lost access to a solid gfortran at any point that could become a issue. It is easy to say just port it all to c/c++ but who has the resources and the time for that? Jack ps As I see, the biggest challenges facing FSF gcc on darwin is 1) adapting to the fact that darwin 10 and later have subsumed libgcc 4.2.1 into libSystem and 2) surviving the LTO merge intact. We won't ever use the LTO in gcc because Apple is taking an entirely different approach.. http://llvm.org/docs/LinkTimeOptimization.html http://www.mail-archive.com/gcc at gcc.gnu.org/msg12816.html Needless to say, FSF gcc decided to go with an approach different from llvm's, I think in part because their own LTO project had already progressed significantly. > > Vincent From howarth at bromo.med.uc.edu Sat Sep 19 10:15:16 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 19 Sep 2009 13:15:16 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909190103n41af3607y4dc88e9b532ff9d2@mail.gmail.com> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> <20090919004348.GA13265@bromo.med.uc.edu> <74c219d30909190103n41af3607y4dc88e9b532ff9d2@mail.gmail.com> Message-ID: <20090919171516.GB18798@bromo.med.uc.edu> On Sat, Sep 19, 2009 at 01:03:26AM -0700, Toby Peterson wrote: > On Fri, Sep 18, 2009 at 17:43, Jack Howarth wrote: > > On Fri, Sep 18, 2009 at 05:31:40PM -0700, Toby Peterson wrote: > >> > >> Given current reality, you're probably better off contributing to > >> llvm-gfortran... or better yet, a native fortran front-end for llvm. > >> FSF gcc is barely relevant on our platform these days. > >> > >> - Toby > > > > Toby, > > ? I created the fink llvm/llvm-gcc42 packages to provide > > them with a llvm-gfortran. However the gfortran in llvm-gcc42 > > is just that (locked at the gcc 4.2.1 release because it > > was the last GPLv2 release that Apple will accept). It has > > much worse performance than the current gfortran in gcc 4.4.0, > > has fewer features and significant portions of the newer > > features aren't working properly. The chances of llvm-gcc > > being updated to a newer release are basically zero and > > there is no clang related fortran compiler at all. You > > work with the hand your dealt...and for us that is trying > > to keep the wheels on FSF gcc for darwin as long as possible. > > Actually gcc 4.4.1 has excellent testsuite results on darwin10. > > Also look at... > > > > http://www.mail-archive.com/fink-devel at lists.sourceforge.net/msg18166.html > > http://archive.netbsd.se/?ml=fink-devel&a=2009-03&m=10250229 > > > > where I benchmarked the various gcc compilers on Intel darwin. > > Lastly, if you check the table at... > > > > http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ > > > > you will see how really bad it would be to have to rely on > > g95 even if it built on darwin10 (almost 3 times slower > > than current gfortran). > > That's why I suggested *contributing* to llvm-gfortran or a native > front-end. If it lags behind, make it better. FSF gcc just doesn't > have much of a future on our platform... > > - Toby Toby, The llvm-gfortran project will be a lost cause in the long run mainly because it is trapped on a most inconvenient source base. The GPLv3 license came into effect just as gfortran development was beginning to show massive progress. The FSF gcc used for llvm-gcc will likely never be updated because of the GPLv3 issue so its gfortran is trapped in a time warp. The most promising approach would be a native fortran compiler for clang but no such project exists yet. I can only work with the possible. Jack ps You do realize that we are using gcc 4.2.1 (and not 4.2.4 or a later gcc release) only because of the GPLv3 license. Few people are aware but Apple's programmers (who are the FSF darwin maintainers) are not allowed to read the gcc mailing lists or the gcc source code since GPLv3 came into effect. They can only review and approve patches submitted for the FSF gcc that impact the darwin port. Fortunately that has allow me to keep the wheels on FSF gcc on darwin so far (knock on wood). From ryandesign at macports.org Sat Sep 19 11:03:20 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 19 Sep 2009 13:03:20 -0500 Subject: starting pureftpd port In-Reply-To: References: Message-ID: <37E3340E-24B9-408A-897F-BE7C358A75F0@macports.org> On Sep 18, 2009, at 18:12, Scott Haneda wrote: > http://trac.macports.org/browser/trunk/dports/net/pureftpd/Portfile > > I wonder if someone can lend me a hand in figuring out the correct > way to start this ftpd on Leopard: > > From the current port file: > # Notify the user how to launch the ftpd > post-install { > ui_msg "\nYou can now start PureFTPd in 3 ways," > ui_msg "either via xinetd, in standalone mode, or" > ui_msg "if you're using Mac OS X 10.4 / Darwin 8.x" > ui_msg "via launchd(8).\n" > ui_msg "If you're under Mac OS X 10.3 or Mac OS X 10.4," > ui_msg "you have to copy ${prefix}/share/doc/${name}/pure-ftpd" > ui_msg "to /etc/pam.d and use the '-lpam' flag when" > ui_msg "launching pure-ftpd to have PAM working.\n" > } Sounds like the instructions can be simplified now that we no longer support 10.3 and can guarantee the presence of launchd. > I can start pureftpd and it works from the command line now. Apple > has /System/Library/LaunchDaemons/ftp.plist which seems to get the > disabled key toggled around depending on how your system preferences > are set. > > If I want to maintain that feature, enable and disable by System > preferences, I take it I would need to alter /System/Library/ > LaunchDaemons/ftp.plist? I would discourage you from modifying files installed by Apple. Instead, this port should install its own launchd plist and you can manage that plist on the command line or using gui tools like lingon. > I am thinking in this case, there are so many ways to start this, > the portfile needs to just install a plist and ui_msg where it is > and how to enabled it. I would say the port should use the startupitem keywords like other ports do. > I do not know the correct location to put it, and how to configure > it so that it is on demand. I believe the Apple ftp dies and only > comes alive when a request comes in, which is nice, as you do not > have a ftpd running 24/7, only when you need it. That would be launch-on-demand. The MacPorts startupitem keywords don't provide a way to do that AFAIK though it might be a nice feature to add somehow. I have already received one request for that in regard to the mysql5-server port. From ryandesign at macports.org Sat Sep 19 11:07:53 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 19 Sep 2009 13:07:53 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <31014a580909182020g656aa49xa1aeff6cf3bb83c5@mail.gmail.com> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <31014a580909172309s17236bd3y388a6e6cbe5b9252@mail.gmail.com> <20090918064409.GA2844@ninagal.withay.com> <31014a580909180758kc4b068brb6d2e61c7283732d@mail.gmail.com> <17D3ADD6-F154-4ED4-9417-0DFBA3A15A2C@macports.org> <31014a580909182020g656aa49xa1aeff6cf3bb83c5@mail.gmail.com> Message-ID: <6D6BA45C-221A-4D95-89D1-27F90058AB6E@macports.org> On Sep 18, 2009, at 22:20, Mark A. Miller wrote: > So, ${prefix}/libexec/gnubin seems to work, and put symlinks there > for the GNU binaries by default, and get rid of this variant? I would say so... I see Marcus already committed an update to do this to gnutar. But now I see the with_default_names variant did more than just install unprefixed binaries. It also installed unprefixed manpages and whatever was in share. For gnutar, there appears to be nothing in libexec and only info pages in share but maybe other ports that have this variant have things in libexec, and also manpages. Do we need "gnushare" and "gnulibexec" dirs too? Or do we need to put bin, share and libexec directories into ${prefix}/libexec/gnu maybe? Presumably if you have your PATH set up so that, say, GNU sed is first, then it would be confusing to say "man sed" and get the system's BSD sed manual... From howarth at bromo.med.uc.edu Sat Sep 19 11:27:14 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 19 Sep 2009 14:27:14 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> Message-ID: <20090919182714.GA19399@bromo.med.uc.edu> On Fri, Sep 18, 2009 at 05:31:40PM -0700, Toby Peterson wrote: > > Given current reality, you're probably better off contributing to > llvm-gfortran... or better yet, a native fortran front-end for llvm. > FSF gcc is barely relevant on our platform these days. > > - Toby Toby, I should have added that you are far more likely to eventually see a fortran compiler on llvm via FSF gcc with a llvm compiler plugin. The recently added GPLv3 exemption for compiler plugins allows FSF's gcc's front and middle ends to use llvm without tainting either's licenses. There is some discusson of this but I wouldn't expect anything before gcc 4.6 or later. Starting from scratch to implement a fortran compiler will take many years (as it did for the g95 code base to mature into a fully integrated gfortran compiler). Jack From talklists at newgeo.com Sat Sep 19 11:54:04 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sat, 19 Sep 2009 11:54:04 -0700 Subject: starting pureftpd port In-Reply-To: <37E3340E-24B9-408A-897F-BE7C358A75F0@macports.org> References: <37E3340E-24B9-408A-897F-BE7C358A75F0@macports.org> Message-ID: <886ACF9B-23FD-460F-84A2-D9CCAED1A396@newgeo.com> On Sep 19, 2009, at 11:03 AM, Ryan Schmidt wrote: > On Sep 18, 2009, at 18:12, Scott Haneda wrote: > >> http://trac.macports.org/browser/trunk/dports/net/pureftpd/Portfile >> >> I wonder if someone can lend me a hand in figuring out the correct >> way to start this ftpd on Leopard: >> >> From the current port file: >> # Notify the user how to launch the ftpd >> post-install { >> ui_msg "\nYou can now start PureFTPd in 3 ways," >> ui_msg "either via xinetd, in standalone mode, or" >> ui_msg "if you're using Mac OS X 10.4 / Darwin 8.x" >> ui_msg "via launchd(8).\n" >> ui_msg "If you're under Mac OS X 10.3 or Mac OS X 10.4," >> ui_msg "you have to copy ${prefix}/share/doc/${name}/pure-ftpd" >> ui_msg "to /etc/pam.d and use the '-lpam' flag when" >> ui_msg "launching pure-ftpd to have PAM working.\n" >> } > > Sounds like the instructions can be simplified now that we no longer > support 10.3 and can guarantee the presence of launchd Ok. Sounds easy enough. Reading over the changelog I see they have added in a new language. I will add that in as a language variant as well. > >> I can start pureftpd and it works from the command line now. Apple >> has /System/Library/LaunchDaemons/ftp.plist which seems to get the >> disabled key toggled around depending on how your system >> preferences are set. >> >> If I want to maintain that feature, enable and disable by System >> preferences, I take it I would need to alter /System/Library/ >> LaunchDaemons/ftp.plist? > > I would discourage you from modifying files installed by Apple. > Instead, this port should install its own launchd plist and you can > manage that plist on the command line or using gui tools like lingon. Ok. Agreed. This has the problem of clicking on the FTP server in Apples System Prefs Sharing pane will cause trouble. Is it worth a UI messgae to warn users, or are there any more automatic or graceful ways to deal with this? I assume this is identical to the Apache ports, and just leave things alone? > >> I am thinking in this case, there are so many ways to start this, >> the portfile needs to just install a plist and ui_msg where it is >> and how to enabled it. > > I would say the port should use the startupitem keywords like other > ports do. The plist is the entire config file. So if you want port ranges, umask, throttle, mysql, about 50 various configurations, there is no config file. It all operates via string items to an array in launchd. What do you suggest based on that? I was going to include plain.plist, ISP.plist, and a few others, with instructions on how to copy and load. There are too many options, one plist can never work for everyone, so I'm not sure it can be ports managed for the creation. > >> I do not know the correct location to put it, and how to configure >> it so that it is on demand. I believe the Apple ftp dies and only >> comes alive when a request comes in, which is nice, as you do not >> have a ftpd running 24/7, only when you need it. > > That would be launch-on-demand. The MacPorts startupitem keywords > don't provide a way to do that AFAIK though it might be a nice > feature to add somehow. I have already received one request for that > in regard to the mysql5-server port. > I have the server starting on demand. Works wonderfully. With a little guidance I think I can add a plist base set that would really ease the starting up of the server. One thing that is easy is the xferlog, which should go to {prefix}/var/ log/ftp/pureftpd-xferlog.log That also is defined in the launchd item. Open to any suggestions, as this is a case of more than just starting something, starting it sets the starting options. There appears to be a bug in the ftpd, it will show user and group colums in ls listings in terminal as an FTP client or desktop client based. The group will show as the group name you defined, the user shows as the uid, not the username. Apples FTP server does not have this problem using the same user and group in testing. Does anyone have the knowhow to pin that down and supply a patch? -- Scott Iphone says hello. From toby at macports.org Sat Sep 19 12:08:45 2009 From: toby at macports.org (Toby Peterson) Date: Sat, 19 Sep 2009 12:08:45 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090919171516.GB18798@bromo.med.uc.edu> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> <20090919004348.GA13265@bromo.med.uc.edu> <74c219d30909190103n41af3607y4dc88e9b532ff9d2@mail.gmail.com> <20090919171516.GB18798@bromo.med.uc.edu> Message-ID: <74c219d30909191208k444469ek4eecd5a2e31a077b@mail.gmail.com> On Sat, Sep 19, 2009 at 10:15, Jack Howarth wrote: > On Sat, Sep 19, 2009 at 01:03:26AM -0700, Toby Peterson wrote: >> On Fri, Sep 18, 2009 at 17:43, Jack Howarth wrote: >> > On Fri, Sep 18, 2009 at 05:31:40PM -0700, Toby Peterson wrote: >> >> >> >> Given current reality, you're probably better off contributing to >> >> llvm-gfortran... or better yet, a native fortran front-end for llvm. >> >> FSF gcc is barely relevant on our platform these days. >> >> >> >> - Toby >> > >> > Toby, >> > ? I created the fink llvm/llvm-gcc42 packages to provide >> > them with a llvm-gfortran. However the gfortran in llvm-gcc42 >> > is just that (locked at the gcc 4.2.1 release because it >> > was the last GPLv2 release that Apple will accept). It has >> > much worse performance than the current gfortran in gcc 4.4.0, >> > has fewer features and significant portions of the newer >> > features aren't working properly. The chances of llvm-gcc >> > being updated to a newer release are basically zero and >> > there is no clang related fortran compiler at all. You >> > work with the hand your dealt...and for us that is trying >> > to keep the wheels on FSF gcc for darwin as long as possible. >> > Actually gcc 4.4.1 has excellent testsuite results on darwin10. >> > Also look at... >> > >> > http://www.mail-archive.com/fink-devel at lists.sourceforge.net/msg18166.html >> > http://archive.netbsd.se/?ml=fink-devel&a=2009-03&m=10250229 >> > >> > where I benchmarked the various gcc compilers on Intel darwin. >> > Lastly, if you check the table at... >> > >> > http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ >> > >> > you will see how really bad it would be to have to rely on >> > g95 even if it built on darwin10 (almost 3 times slower >> > than current gfortran). >> >> That's why I suggested *contributing* to llvm-gfortran or a native >> front-end. If it lags behind, make it better. FSF gcc just doesn't >> have much of a future on our platform... >> >> - Toby > > Toby, > ? ?The llvm-gfortran project will be a lost cause in the long run > mainly because it is trapped on a most inconvenient source base. ?The > GPLv3 license came into effect just as gfortran development was beginning > to show massive progress. The FSF gcc used for llvm-gcc will likely > never be updated because of the GPLv3 issue so its gfortran is trapped > in a time warp. The most promising approach would be a native fortran > compiler for clang but no such project exists yet. I can only work with > the possible. I'm not sure how what I'm suggesting is impossible. Hard, maybe, but impossible? > ps You do realize that we are using gcc 4.2.1 (and not 4.2.4 or a later > gcc release) only because of the GPLv3 license. Few people are aware > but Apple's programmers (who are the FSF darwin maintainers) are not > allowed to read the gcc mailing lists or the gcc source code since > GPLv3 came into effect. They can only review and approve patches submitted > for the FSF gcc that impact the darwin port. Fortunately that has > allow me to keep the wheels on FSF gcc on darwin so far (knock on wood). I'm fully aware of the evils of GPL. - Toby From toby at macports.org Sat Sep 19 12:10:14 2009 From: toby at macports.org (Toby Peterson) Date: Sat, 19 Sep 2009 12:10:14 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090919182714.GA19399@bromo.med.uc.edu> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> <20090919182714.GA19399@bromo.med.uc.edu> Message-ID: <74c219d30909191210o3017627fl9343153f2572dee8@mail.gmail.com> On Sat, Sep 19, 2009 at 11:27, Jack Howarth wrote: > On Fri, Sep 18, 2009 at 05:31:40PM -0700, Toby Peterson wrote: >> >> Given current reality, you're probably better off contributing to >> llvm-gfortran... or better yet, a native fortran front-end for llvm. >> FSF gcc is barely relevant on our platform these days. >> >> - Toby > > Toby, > ? I should have added that you are far more likely to eventually > see a fortran compiler on llvm via FSF gcc with a llvm compiler plugin. > The recently added GPLv3 exemption for compiler plugins allows > FSF's gcc's front and middle ends to use llvm without tainting > either's licenses. There is some discusson of this but I wouldn't > expect anything before gcc 4.6 or later. Starting from scratch to > implement a fortran compiler will take many years (as it did for the > g95 code base to mature into a fully integrated gfortran compiler). I don't care... although your claim that it'd take "many years" is a little silly. - Toby From vince at macports.org Sat Sep 19 12:32:21 2009 From: vince at macports.org (vincent habchi) Date: Sat, 19 Sep 2009 21:32:21 +0200 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090919171516.GB18798@bromo.med.uc.edu> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> <20090919004348.GA13265@bromo.med.uc.edu> <74c219d30909190103n41af3607y4dc88e9b532ff9d2@mail.gmail.com> <20090919171516.GB18798@bromo.med.uc.edu> Message-ID: <200F50C5-4CDF-491C-B989-BA56240FD9F9@macports.org> Le 19 sept. 2009 ? 19:15, Jack Howarth a ?crit : > ps You do realize that we are using gcc 4.2.1 (and not 4.2.4 or a > later > gcc release) only because of the GPLv3 license. Few people are aware > but Apple's programmers (who are the FSF darwin maintainers) are not > allowed to read the gcc mailing lists or the gcc source code since > GPLv3 came into effect. They can only review and approve patches > submitted > for the FSF gcc that impact the darwin port. Fortunately that has > allow me to keep the wheels on FSF gcc on darwin so far (knock on > wood). I wonder if NetBSD has moved to 4.3. If I remember correctly, before I switched to Mac OS, they wanted to turn to LLVM because they refused to accept GPLv3. Vincent From mark at mirell.org Sat Sep 19 13:06:09 2009 From: mark at mirell.org (Mark A. Miller) Date: Sat, 19 Sep 2009 15:06:09 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <6D6BA45C-221A-4D95-89D1-27F90058AB6E@macports.org> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <20090918064409.GA2844@ninagal.withay.com> <31014a580909180758kc4b068brb6d2e61c7283732d@mail.gmail.com> <17D3ADD6-F154-4ED4-9417-0DFBA3A15A2C@macports.org> <31014a580909182020g656aa49xa1aeff6cf3bb83c5@mail.gmail.com> <6D6BA45C-221A-4D95-89D1-27F90058AB6E@macports.org> Message-ID: <31014a580909191306g46899b0dx2f5469fce2dfba11@mail.gmail.com> On Sat, Sep 19, 2009 at 1:07 PM, Ryan Schmidt wrote: > > On Sep 18, 2009, at 22:20, Mark A. Miller wrote: > > So, ${prefix}/libexec/gnubin seems to work, and put symlinks there for the >> GNU binaries by default, and get rid of this variant? >> > > I would say so... I see Marcus already committed an update to do this to > gnutar. But now I see the with_default_names variant did more than just > install unprefixed binaries. It also installed unprefixed manpages and > whatever was in share. For gnutar, there appears to be nothing in libexec > and only info pages in share but maybe other ports that have this variant > have things in libexec, and also manpages. Do we need "gnushare" and > "gnulibexec" dirs too? Or do we need to put bin, share and libexec > directories into ${prefix}/libexec/gnu maybe? Presumably if you have your > PATH set up so that, say, GNU sed is first, then it would be confusing to > say "man sed" and get the system's BSD sed manual... > ${prefix}/libexec/gnu sounds like a good idea, although that would involve adding an additional path to $MANPATH. On the other hand, I don't think it's *that* terrible of an issue, generally I see having these commands in ${prefix}/libexec/gnubin to be almost completely used for scripts and other things that need GNU utilities for some things. But you do have a point, and if adding an additional $MANPATH search path is not a big issue, then I agree. -- Mark A. Miller mark at mirell.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From howarth at bromo.med.uc.edu Sat Sep 19 13:08:14 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 19 Sep 2009 16:08:14 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909191210o3017627fl9343153f2572dee8@mail.gmail.com> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> <20090919182714.GA19399@bromo.med.uc.edu> <74c219d30909191210o3017627fl9343153f2572dee8@mail.gmail.com> Message-ID: <20090919200814.GA19928@bromo.med.uc.edu> On Sat, Sep 19, 2009 at 12:10:14PM -0700, Toby Peterson wrote: > > I don't care... although your claim that it'd take "many years" is a > little silly. > > - Toby Ahem. Have you have participated in any of these projects? Look at the timeline for gfortran (which had the advantages of starting from the g95 source code base which as in turn derived from the g77 source code). >From wikipedia http://gcc.gnu.org/wiki/TheOtherGCCBasedFortranCompiler... In early 2000 Andrew Vaught started g95, a project to create a free software Fortran 95 compiler using the GCC backend. This was a collaborative project for two years, but in late 2002 Andrew decided to become sole developer of g95. The gfortran project was created in January 2003 as a fork from the GPL-licensed g95 source code at that time, in order to allow for cooperative development and integration with the GCC codebase. Since that time, Andrew has continued development of g95 independently, and the codebases of g95 and gfortran have significantly diverged. Thus, the gfortran team is unable to provide support or advice regarding g95. Considering that gcc 4.2 was the first really usable gfortran release, this means that the development time from its original origins to the first stable release (http://gcc.gnu.org/releases.html) was seven years. Also keep in mind any fortran project in llvm can't start with sources imported from later than gcc 4.2.1 without changing the license to GPLv3. We would also be competing for the limited pool of developers interested in fortran development against an existing project. Lastly most hard core open source compiler development is actually done by programmers employed to do so by a company and not folks in their basements. Since Apple's management has no interest in fortran development, another major entity would have to switch from FSF gcc to llvm clang to provide the necessary resources for any new fortran compiler in llvm clang to be viable. We need to be realistic about what is possible at the moment. Jack From howarth at bromo.med.uc.edu Sat Sep 19 13:14:09 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 19 Sep 2009 16:14:09 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909191210o3017627fl9343153f2572dee8@mail.gmail.com> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> <20090919182714.GA19399@bromo.med.uc.edu> <74c219d30909191210o3017627fl9343153f2572dee8@mail.gmail.com> Message-ID: <20090919201408.GB19928@bromo.med.uc.edu> Oh, I should clarify how I measure the first stable release. Until about gcc 4.2, gfortran was in an unstable development mode that exempted it from the normal commit rules (ie when the gcc release was branched only commits for regression fixes and bugs were allowed). It was in such a primordial state up to gcc 4.2.0 that those rules were waived and the gfortran developers were free to commit to the gfortran section of the compiler at any time. After it was deemed stable in 2007, the gfortran compiler fell under the normal rules for developing in gcc. Jack From toby at macports.org Sat Sep 19 13:26:37 2009 From: toby at macports.org (Toby Peterson) Date: Sat, 19 Sep 2009 13:26:37 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090919200814.GA19928@bromo.med.uc.edu> References: <20090918233815.GA12896@bromo.med.uc.edu> <20090918234657.GP1215@darkart.com> <20090918235753.GA13004@bromo.med.uc.edu> <20090919001938.GQ1215@darkart.com> <20090919002616.GA13203@bromo.med.uc.edu> <74c219d30909181731o6c0f027bhd857f53f4f585c38@mail.gmail.com> <20090919182714.GA19399@bromo.med.uc.edu> <74c219d30909191210o3017627fl9343153f2572dee8@mail.gmail.com> <20090919200814.GA19928@bromo.med.uc.edu> Message-ID: <74c219d30909191326l3ba77a91t15ef49dd64c8bece@mail.gmail.com> On Sat, Sep 19, 2009 at 13:08, Jack Howarth wrote: > On Sat, Sep 19, 2009 at 12:10:14PM -0700, Toby Peterson wrote: >> >> I don't care... although your claim that it'd take "many years" is a >> little silly. >> >> - Toby > > Ahem. Have you have participated in any of these projects? Look at the > timeline for gfortran (which had the advantages of starting from the > g95 source code base which as in turn derived from the g77 source code). > From wikipedia http://gcc.gnu.org/wiki/TheOtherGCCBasedFortranCompiler... > > In early 2000 Andrew Vaught started g95, a project to create a free software Fortran 95 compiler using the GCC backend. This was a collaborative project for two years, but in late 2002 Andrew decided to become sole developer of g95. The gfortran project was created in January 2003 as a fork from the GPL-licensed g95 source code at that time, in order to allow for cooperative development and integration with the GCC codebase. > > Since that time, Andrew has continued development of g95 independently, and the codebases of g95 and gfortran have significantly diverged. Thus, the gfortran team is unable to provide support or advice regarding g95. > > Considering that gcc 4.2 was the first really usable gfortran release, > this means that the development time from its original origins to the > first stable release (http://gcc.gnu.org/releases.html) was seven years. > Also keep in mind any fortran project in llvm can't start with sources > imported from later than gcc 4.2.1 without changing the license to > GPLv3. We would also be competing for the limited pool of developers > interested in fortran development against an existing project. Lastly > most hard core open source compiler development is actually done by > programmers employed to do so by a company and not folks in their > basements. Since Apple's management has no interest in fortran development, > another major entity would have to switch from FSF gcc to llvm clang > to provide the necessary resources for any new fortran compiler in > llvm clang to be viable. We need to be realistic about what is possible > at the moment. You really don't need to reply to every email with a wall of text. Anyway, you're right that a new fortran frontend would take "many years" if there are only a couple of volunteer developers. However, since llvm is under a good license it's much more likely for real development to take place. - Toby From ryandesign at macports.org Sat Sep 19 15:20:14 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 19 Sep 2009 17:20:14 -0500 Subject: starting pureftpd port In-Reply-To: <886ACF9B-23FD-460F-84A2-D9CCAED1A396@newgeo.com> References: <37E3340E-24B9-408A-897F-BE7C358A75F0@macports.org> <886ACF9B-23FD-460F-84A2-D9CCAED1A396@newgeo.com> Message-ID: <251FACA0-533F-45EB-998B-DC47BBE5673F@macports.org> On Sep 19, 2009, at 13:54, Scott Haneda wrote: >>> I can start pureftpd and it works from the command line now. >>> Apple has /System/Library/LaunchDaemons/ftp.plist which seems to >>> get the disabled key toggled around depending on how your system >>> preferences are set. >>> >>> If I want to maintain that feature, enable and disable by System >>> preferences, I take it I would need to alter /System/Library/ >>> LaunchDaemons/ftp.plist? >> >> I would discourage you from modifying files installed by Apple. >> Instead, this port should install its own launchd plist and you can >> manage that plist on the command line or using gui tools like lingon. > > Ok. Agreed. This has the problem of clicking on the FTP server in > Apples System Prefs Sharing pane will cause trouble. > > Is it worth a UI messgae to warn users, or are there any more > automatic or graceful ways to deal with this? > > I assume this is identical to the Apache ports, and just leave > things alone? Yes, for the Apache ports and lighttpd and other web servers, users are expected to turn off Apple's Web Sharing -- or run the MacPorts web server on a different port. The same would apply to FTP servers or any other servers Apple might offer. Though I don't see an FTP server in my Sharing preferences -- maybe you're on Mac OS X Server? >>> I am thinking in this case, there are so many ways to start this, >>> the portfile needs to just install a plist and ui_msg where it is >>> and how to enabled it. >> >> I would say the port should use the startupitem keywords like other >> ports do. > > The plist is the entire config file. So if you want port ranges, > umask, throttle, mysql, about 50 various configurations, there is no > config file. > > It all operates via string items to an array in launchd. > > What do you suggest based on that? I was going to include > plain.plist, ISP.plist, and a few others, with instructions on how > to copy and load. > > There are too many options, one plist can never work for everyone, > so I'm not sure it can be ports managed for the creation. Oh, ok. Then I guess it should be up to the user to write and install the plist. The port could install a sample plist and tell the user about it. From ryandesign at macports.org Sat Sep 19 15:28:19 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 19 Sep 2009 17:28:19 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <31014a580909191306g46899b0dx2f5469fce2dfba11@mail.gmail.com> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <20090918064409.GA2844@ninagal.withay.com> <31014a580909180758kc4b068brb6d2e61c7283732d@mail.gmail.com> <17D3ADD6-F154-4ED4-9417-0DFBA3A15A2C@macports.org> <31014a580909182020g656aa49xa1aeff6cf3bb83c5@mail.gmail.com> <6D6BA45C-221A-4D95-89D1-27F90058AB6E@macports.org> <31014a580909191306g46899b0dx2f5469fce2dfba11@mail.gmail.com> Message-ID: <4E9F2734-9363-4192-AB3A-45DC49E2AE55@macports.org> On Sep 19, 2009, at 15:06, Mark A. Miller wrote: > On Sat, Sep 19, 2009 at 1:07 PM, Ryan Schmidt wrote: > >> On Sep 18, 2009, at 22:20, Mark A. Miller wrote: >> >>> So, ${prefix}/libexec/gnubin seems to work, and put symlinks there >>> for the GNU binaries by default, and get rid of this variant? >> >> >> I would say so... I see Marcus already committed an update to do >> this to gnutar. But now I see the with_default_names variant did >> more than just install unprefixed binaries. It also installed >> unprefixed manpages and whatever was in share. For gnutar, there >> appears to be nothing in libexec and only info pages in share but >> maybe other ports that have this variant have things in libexec, >> and also manpages. Do we need "gnushare" and "gnulibexec" dirs too? >> Or do we need to put bin, share and libexec directories into $ >> {prefix}/libexec/gnu maybe? Presumably if you have your PATH set up >> so that, say, GNU sed is first, then it would be confusing to say >> "man sed" and get the system's BSD sed manual... > > ${prefix}/libexec/gnu sounds like a good idea, although that would > involve adding an additional path to $MANPATH. If your MANPATH is empty (as I believe we recommend), then man will automatically search for things in all the locations specified in PATH (that is, for every path in PATH, man will look in ../share/man for manpages). Though it's sounding strange for libexec/gnu to be its own prefix. apach2, for example, uses ${prefix}/apache2 as its prefix. Granted that violates the mtree, which I originally objected to in this thread. :/ Guess I don't really know where it should go. From toby at macports.org Sat Sep 19 15:32:57 2009 From: toby at macports.org (Toby Peterson) Date: Sat, 19 Sep 2009 15:32:57 -0700 Subject: starting pureftpd port In-Reply-To: <251FACA0-533F-45EB-998B-DC47BBE5673F@macports.org> References: <37E3340E-24B9-408A-897F-BE7C358A75F0@macports.org> <886ACF9B-23FD-460F-84A2-D9CCAED1A396@newgeo.com> <251FACA0-533F-45EB-998B-DC47BBE5673F@macports.org> Message-ID: <74c219d30909191532p178d4b00v310d5aa55fe5926a@mail.gmail.com> On Sat, Sep 19, 2009 at 15:20, Ryan Schmidt wrote: > On Sep 19, 2009, at 13:54, Scott Haneda wrote: > >>>> I can start pureftpd and it works from the command line now. ?Apple has >>>> /System/Library/LaunchDaemons/ftp.plist which seems to get the disabled key >>>> toggled around depending on how your system preferences are set. >>>> >>>> If I want to maintain that feature, enable and disable by System >>>> preferences, I take it I would need to alter >>>> /System/Library/LaunchDaemons/ftp.plist? >>> >>> I would discourage you from modifying files installed by Apple. Instead, >>> this port should install its own launchd plist and you can manage that plist >>> on the command line or using gui tools like lingon. >> >> Ok. Agreed. This has the problem of clicking on the FTP server in Apples >> System Prefs Sharing pane will cause trouble. >> >> Is it worth a UI messgae to warn users, or are there any more automatic or >> graceful ways to deal with this? >> >> I assume this is identical to the Apache ports, and just leave things >> alone? > > Yes, for the Apache ports and lighttpd and other web servers, users are > expected to turn off Apple's Web Sharing -- or run the MacPorts web server > on a different port. The same would apply to FTP servers or any other > servers Apple might offer. Though I don't see an FTP server in my Sharing > preferences -- maybe you're on Mac OS X Server? It's under "File Sharing" ... - Toby From ryandesign at macports.org Sat Sep 19 15:37:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 19 Sep 2009 17:37:13 -0500 Subject: [57854] trunk/dports/www/phpmyadmin/Portfile In-Reply-To: References: <20090917153616.4A8BA278F917@beta.macosforge.org> <6A0A6DC2-95E0-4336-91E5-8EC11E4D5D56@macports.org> <46BA9D78-783F-46DD-878B-2ADF4F3FD0EC@macports.org> <4AB2D186.3050405@macports.org> Message-ID: <77349002-F35A-403D-9074-5A166EDC097E@macports.org> On Sep 18, 2009, at 11:13, Olivier Le Floch wrote: > On 18 sept. 09, at 02:17, Rainer M?ller wrote: > >> On 2009-09-17 23:26 , Ryan Schmidt wrote: >> >>> Personally, I prefer to tell the user where the sample files are so >>> they can make copies if and when they want. Other port authors have >>> taken recently to copying the sample files for the user. >> >> If the software requires the config file to run at all, it makes >> sense >> to copy it in a post-activate phase. Otherwise, there is no need to >> do this. The point of phpMyAdmin is to administer MySQL servers, so I don't see any point in trying to run phpMyAdmin without first having configured it to know where your MySQL servers are... > I agree. In the case of the phpMyAdmin port, the configuration file > is not required, but since phpMyAdmin expects its configuration file > to be in it's root directory (i.e. in /opt/local/www/phpmyadmin/ for > macports), uninstalling/upgrading phpmyadmin would destroy/conflict > with the user's configuration file. Because of this, I had to add a > symlink from the default configuration file location to somewhere in > ${prefix}/etc/. Unfortunately, phpMyAdmin calls it's configuration > file {{{config.inc.php}}}, which meant I had to rename it (and > differ from phpMyAdmin's documentation) in ${prefix}/etc/, and the > easiest way I think to document this name change was to directly > install the sample config file. I didn't quite understand: why did you have to rename config.inc.php and differ from phpMyAdmin's documentation? Sure it might be nice to have the config file in ${prefix}/etc along with other programs' config files, but I don't see what forced you to do that. It would have been fine to keep the config file where it was, no? Also I think it's pretty usual for web apps to have their config files within their own directories, and not within ${prefix}/etc. I haven't sampled many web apps, but I would assume they're written to be used on web hosts where users don't usually have access to system-wide directories like / etc. > phpMyAdmin seems to work with the symlink and no configuration file, > but that would still leave it to the user to understand in what > custom location the config file was to be put, so I'm under the > impression that this would be the best solution for the user while > still complying with macports guidelines. From alakazam at macports.org Sat Sep 19 19:01:00 2009 From: alakazam at macports.org (Olivier Le Floch) Date: Sun, 20 Sep 2009 04:01:00 +0200 Subject: [57854] trunk/dports/www/phpmyadmin/Portfile In-Reply-To: <77349002-F35A-403D-9074-5A166EDC097E@macports.org> References: <20090917153616.4A8BA278F917@beta.macosforge.org> <6A0A6DC2-95E0-4336-91E5-8EC11E4D5D56@macports.org> <46BA9D78-783F-46DD-878B-2ADF4F3FD0EC@macports.org> <4AB2D186.3050405@macports.org> <77349002-F35A-403D-9074-5A166EDC097E@macports.org> Message-ID: > I didn't quite understand: why did you have to rename config.inc.php > and differ from phpMyAdmin's documentation? Sure it might be nice to > have the config file in ${prefix}/etc along with other programs' > config files, but I don't see what forced you to do that. It would > have been fine to keep the config file where it was, no? Also I > think it's pretty usual for web apps to have their config files > within their own directories, and not within ${prefix}/etc. I > haven't sampled many web apps, but I would assume they're written to > be used on web hosts where users don't usually have access to system- > wide directories like /etc. There are actually two parts to this question : - Why did I choose to have the configuration file live in ${prefix}/ etc/ instead of the application's own directory ? Because if I'm not mistaken, future upgrade of phpmyadmin, and uninstalls, etc., would not handle this user edited file very well. If this is not the case (i.e. upgrading the phpmyadmin port won't risk erasing this file), then I fully agree that this whole "copy the file and add a symlink" stuff is not useful at all (and I should remove it to avoid confusing users with a non standard phpMyAdmin config). - Why did I choose to rename the configuration file from config.inc.php to phpmyadmin.inc.php ? Since I was putting the file in a directory common to many ports, I most definitely did not want it to have a name that might conflict with other ports. From howarth at bromo.med.uc.edu Sat Sep 19 19:25:03 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 19 Sep 2009 22:25:03 -0400 Subject: macport's oddity Message-ID: <20090920022503.GA21868@bromo.med.uc.edu> I am running into an issue with MacPort's that seems rather odd. My system shell is set to tcsh and and I have the normal entries in my .cshrc of... ## # Your previous /Users/howarth/.cshrc file was backed up as /Users/howarth/.cshrc.macports-saved_2009-09-11_at_18:03:54 ## # MacPorts Installer addition on 2009-09-11_at_18:03:54: adding an appropriate PATH variable for use with MacPorts. setenv PATH /opt/local/bin:/opt/local/sbin:$PATH # Finished adapting your PATH environment variable for use with MacPorts. If I build and install a new package in one Terminal window, normally under fink the installed files were immediately available in the other terminal windows (or worse case I had to issue a rehash command). I am finding that in the other terminal windows, rehash doesn't allow the file to execute and I have to open a new terminal window for the newly installed files in /opt/local/bin to be found when I type their unpathed filename. Is this normal for MacPorts? Jack From mark at mirell.org Sat Sep 19 20:50:55 2009 From: mark at mirell.org (Mark A. Miller) Date: Sat, 19 Sep 2009 22:50:55 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <4E9F2734-9363-4192-AB3A-45DC49E2AE55@macports.org> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <31014a580909180758kc4b068brb6d2e61c7283732d@mail.gmail.com> <17D3ADD6-F154-4ED4-9417-0DFBA3A15A2C@macports.org> <31014a580909182020g656aa49xa1aeff6cf3bb83c5@mail.gmail.com> <6D6BA45C-221A-4D95-89D1-27F90058AB6E@macports.org> <31014a580909191306g46899b0dx2f5469fce2dfba11@mail.gmail.com> <4E9F2734-9363-4192-AB3A-45DC49E2AE55@macports.org> Message-ID: <31014a580909192050j5345d1cfm8ccf6f1097515c53@mail.gmail.com> On Sat, Sep 19, 2009 at 5:28 PM, Ryan Schmidt wrote: > > On Sep 19, 2009, at 15:06, Mark A. Miller wrote: > > On Sat, Sep 19, 2009 at 1:07 PM, Ryan Schmidt wrote: >> >> On Sep 18, 2009, at 22:20, Mark A. Miller wrote: >>> >>> So, ${prefix}/libexec/gnubin seems to work, and put symlinks there for >>>> the GNU binaries by default, and get rid of this variant? >>>> >>> >>> >>> I would say so... I see Marcus already committed an update to do this to >>> gnutar. But now I see the with_default_names variant did more than just >>> install unprefixed binaries. It also installed unprefixed manpages and >>> whatever was in share. For gnutar, there appears to be nothing in libexec >>> and only info pages in share but maybe other ports that have this variant >>> have things in libexec, and also manpages. Do we need "gnushare" and >>> "gnulibexec" dirs too? Or do we need to put bin, share and libexec >>> directories into ${prefix}/libexec/gnu maybe? Presumably if you have your >>> PATH set up so that, say, GNU sed is first, then it would be confusing to >>> say "man sed" and get the system's BSD sed manual... >>> >> >> ${prefix}/libexec/gnu sounds like a good idea, although that would involve >> adding an additional path to $MANPATH. >> > > If your MANPATH is empty (as I believe we recommend), then man will > automatically search for things in all the locations specified in PATH (that > is, for every path in PATH, man will look in ../share/man for manpages). > It's not empty, as seen by my .profile modified by MacPorts install: # MacPorts Installer addition on 2009-06-11_at_17:44:56: adding an appropriate MANPATH variable for use with MacPorts. export MANPATH=/opt/local/share/man:$MANPATH # Finished adapting your MANPATH environment variable for use with MacPorts. But making it empty still results it the behavior you describe, so...redundancy yay! > Though it's sounding strange for libexec/gnu to be its own prefix. apach2, > for example, uses ${prefix}/apache2 as its prefix. Granted that violates the > mtree, which I originally objected to in this thread. :/ Guess I don't > really know where it should go. > Is there really anything bad other than "strange"? Sure it's perhaps strange, but for the people who don't need this, it doesn't ever bother them, and the people who do, it is a nice, cool little addition. ${prefix}/var/gnu? ${prefix}/share/gnu? -- Mark A. Miller mark at mirell.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Sat Sep 19 21:47:21 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 19 Sep 2009 23:47:21 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <31014a580909192050j5345d1cfm8ccf6f1097515c53@mail.gmail.com> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <31014a580909180758kc4b068brb6d2e61c7283732d@mail.gmail.com> <17D3ADD6-F154-4ED4-9417-0DFBA3A15A2C@macports.org> <31014a580909182020g656aa49xa1aeff6cf3bb83c5@mail.gmail.com> <6D6BA45C-221A-4D95-89D1-27F90058AB6E@macports.org> <31014a580909191306g46899b0dx2f5469fce2dfba11@mail.gmail.com> <4E9F2734-9363-4192-AB3A-45DC49E2AE55@macports.org> <31014a580909192050j5345d1cfm8ccf6f1097515c53@mail.gmail.com> Message-ID: <70023E16-BBDE-4911-B39C-B6C50B91432A@macports.org> On Sep 19, 2009, at 22:50, Mark A. Miller wrote: > On Sat, Sep 19, 2009 at 5:28 PM, Ryan Schmidt wrote: > >> If your MANPATH is empty (as I believe we recommend), then man will >> automatically search for things in all the locations specified in >> PATH (that is, for every path in PATH, man will look in ../share/ >> man for manpages). >> > > It's not empty, as seen by my .profile modified by MacPorts install: > > # MacPorts Installer addition on 2009-06-11_at_17:44:56: adding an > appropriate MANPATH variable for use with MacPorts. > export MANPATH=/opt/local/share/man:$MANPATH > # Finished adapting your MANPATH environment variable for use with > MacPorts. > > But making it empty still results it the behavior you describe, > so...redundancy yay! Yeah, I believe Apple started shipping a nonempty MANPATH in Leopard. Not sure why. >> Though it's sounding strange for libexec/gnu to be its own prefix. >> apach2, for example, uses ${prefix}/apache2 as its prefix. Granted >> that violates the mtree, which I originally objected to in this >> thread. :/ Guess I don't really know where it should go. > > Is there really anything bad other than "strange"? Sure it's perhaps > strange, but for the people who don't need this, it doesn't ever > bother them, and the people who do, it is a nice, cool little > addition. > > ${prefix}/var/gnu? ${prefix}/share/gnu? The disadvantage of that would be that it doesn't get the automatic MANPATHness described above. From ryandesign at macports.org Sat Sep 19 22:11:50 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 20 Sep 2009 00:11:50 -0500 Subject: [57854] trunk/dports/www/phpmyadmin/Portfile In-Reply-To: References: <20090917153616.4A8BA278F917@beta.macosforge.org> <6A0A6DC2-95E0-4336-91E5-8EC11E4D5D56@macports.org> <46BA9D78-783F-46DD-878B-2ADF4F3FD0EC@macports.org> <4AB2D186.3050405@macports.org> <77349002-F35A-403D-9074-5A166EDC097E@macports.org> Message-ID: On Sep 19, 2009, at 21:01, Olivier Le Floch wrote: >> I didn't quite understand: why did you have to rename >> config.inc.php and differ from phpMyAdmin's documentation? Sure it >> might be nice to have the config file in ${prefix}/etc along with >> other programs' config files, but I don't see what forced you to do >> that. It would have been fine to keep the config file where it was, >> no? Also I think it's pretty usual for web apps to have their >> config files within their own directories, and not within ${prefix}/ >> etc. I haven't sampled many web apps, but I would assume they're >> written to be used on web hosts where users don't usually have >> access to system-wide directories like /etc. > > There are actually two parts to this question : > > - Why did I choose to have the configuration file live in ${prefix}/ > etc/ instead of the application's own directory ? > > Because if I'm not mistaken, future upgrade of phpmyadmin, and > uninstalls, etc., would not handle this user edited file very well. > If this is not the case (i.e. upgrading the phpmyadmin port won't > risk erasing this file), then I fully agree that this whole "copy > the file and add a symlink" stuff is not useful at all (and I should > remove it to avoid confusing users with a non standard phpMyAdmin > config). Upgrades will delete any file registered to the port, regardless where the file is, and will not touch files not registered to the port. So all you have to do is make sure ${prefix}/www/phpmyadmin/ config.inc.php is not registered to the port. Looking into the distfile, it does not contain a file config.inc.php; it contains a file config.sample.inc.php. So there is no problem. You can install the files contained in the distfile without modification, and explain to the user in a post-activate ui_msg that they should copy config.sample.inc.php to config.inc.php and then make changes. MacPorts will not touch config.inc.php on upgrade or uninstall, because it is not any of the files installed by the port. In the php5 port I check whether the php.ini exists, and vary the message I print: if the file does not exist, I tell the user to copy the sample php.ini; if the file exists, I advise the user they should compare their php.ini with the new sample php.ini because they may need to merge in changes. > - Why did I choose to rename the configuration file from > config.inc.php to phpmyadmin.inc.php ? > > Since I was putting the file in a directory common to many ports, I > most definitely did not want it to have a name that might conflict > with other ports. True. Another option, if you want to continue to have the file within $ {prefix}/etc, would be to not rename it but put it in ${prefix}/etc/$ {name}. From opendarwin.org at darkart.com Sat Sep 19 22:12:57 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Sun, 20 Sep 2009 05:12:57 +0000 Subject: macport's oddity In-Reply-To: <20090920022503.GA21868@bromo.med.uc.edu> References: <20090920022503.GA21868@bromo.med.uc.edu> Message-ID: <20090920051257.GS1215@darkart.com> On Sat, Sep 19, 2009 at 10:25:03PM -0400, Jack Howarth wrote: > I am running into an issue with MacPort's that > seems rather odd. My system shell is set to tcsh > and and I have the normal entries in my .cshrc of... > > ## > # Your previous /Users/howarth/.cshrc file was backed up as /Users/howarth/.cshrc.macports-saved_2009-09-11_at_18:03:54 > ## > > # MacPorts Installer addition on 2009-09-11_at_18:03:54: adding an appropriate PATH variable for use with MacPorts. > setenv PATH /opt/local/bin:/opt/local/sbin:$PATH > # Finished adapting your PATH environment variable for use with MacPorts. > > If I build and install a new package in one > Terminal window, normally under fink the installed > files were immediately available in the other > terminal windows (or worse case I had to issue a > rehash command). I am finding that in the other > terminal windows, rehash doesn't allow the file > to execute and I have to open a new terminal window > for the newly installed files in /opt/local/bin > to be found when I type their unpathed filename. > Is this normal for MacPorts? Did you bother to check your PATH in those terminal windows where things didn't work? If you did, did it have /opt/local/bin:/opt/local/sbin in it? If so, then that's a bit odd, but at a shell and/or system level, not something that MacPorts is doing. If not, then it sounds perfectly normal for a shell. -eric From ryandesign at macports.org Sat Sep 19 22:32:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 20 Sep 2009 00:32:41 -0500 Subject: macport's oddity In-Reply-To: <20090920022503.GA21868@bromo.med.uc.edu> References: <20090920022503.GA21868@bromo.med.uc.edu> Message-ID: On Sep 19, 2009, at 21:25, Jack Howarth wrote: > If I build and install a new package in one > Terminal window, normally under fink the installed > files were immediately available in the other > terminal windows (or worse case I had to issue a > rehash command). I am finding that in the other > terminal windows, rehash doesn't allow the file > to execute and I have to open a new terminal window > for the newly installed files in /opt/local/bin > to be found when I type their unpathed filename. > Is this normal for MacPorts? I do not experience that with bash. I haven't used tcsh in years. From and.damore at macports.org Sun Sep 20 00:16:32 2009 From: and.damore at macports.org (Andrea D'Amore) Date: Sun, 20 Sep 2009 09:16:32 +0200 Subject: starting pureftpd port In-Reply-To: <251FACA0-533F-45EB-998B-DC47BBE5673F@macports.org> References: <37E3340E-24B9-408A-897F-BE7C358A75F0@macports.org> <886ACF9B-23FD-460F-84A2-D9CCAED1A396@newgeo.com> <251FACA0-533F-45EB-998B-DC47BBE5673F@macports.org> Message-ID: <5675FD0D-974C-4606-8EC2-894603147679@macports.org> On 20/set/09, at 00:20, Ryan Schmidt wrote: > Though I don't see an FTP server in my Sharing preferences -- System Preferences -> Sharing -> File Sharing offers AFP, FTP and samba. -- Andrea From afb at macports.org Sun Sep 20 01:22:42 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 20 Sep 2009 10:22:42 +0200 Subject: MacPorts on Other Platforms Message-ID: I dusted off the FreeBSD package for MacPorts 1.8.0, and it now runs OK on FreeBSD 7.2 (and probably 8.0) All Linux packages were retired, since the new MP code is using BSD commands and also since threaded Tcl is not available on all distributions. The old package source was left as 1.6.0, accidently causing some svn issues... The FreeBSD builds came about as a test on Open Source OS, when the Darwin OS (+puredarwin) stopped being released. So it went something like darwin7 -> darwin8 -> freebsd7, and eventually -> freebsd8 which is currently in RC state. You might still be able to get MP to work on puredarwin.org and darwin9 and darwin10 but it's much "easier" on FreeBSD since the rest of the operating system is already working ? (currently much of PureDarwin requires building on Mac OS X) There are not many mac ports working with "platform freebsd", but that's not the goal either (although some might be fixed) The test is more for "base", to test whether it remains working without the proprietary parts... And thus far, it still does. All the source code (and packaging) have been committed to trunk. Packages are at: http://trac.macports.org/browser/users/afb/GA/ --anders From afb at macports.org Sun Sep 20 01:26:10 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 20 Sep 2009 10:26:10 +0200 Subject: Compression and Checksums Message-ID: The "use_xz" directive was added on trunk, just like the previous "use_lzma" and "use_bzip2" already in. It will use a distfile with .xar.xz instead of tar.gz, and needs the XZ Utils installed to decompress that. Since before, you can also use both xz and lzma to make package archives. This is done by changing the portarchivetype from the default "tgz" to use "txz", or you can use more than one (to compare the sizes) portarchivemode yes portarchivetype tgz,txz The "sha256" digest was also added to Pextlib, as a future alternative to the SHA-1/RMD-160 combo. It's longer than those (32 instead of 20), but smaller than needing to have both of them (=40). It's not yet available for the portfiles, until a policy decision has been made on which checksums to use for distfiles. Additionally "size" might be useful to have, instead of distcheck.check=filesize ? # The list of the types of checksums we know. set checksum_types "md5 sha1 rmd160" --anders From afb at macports.org Sun Sep 20 01:28:54 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 20 Sep 2009 10:28:54 +0200 Subject: Compression and Checksums In-Reply-To: References: Message-ID: > It will use a distfile with .xar.xz instead of tar.gz, Funny typo there. I meant to write ".tar.xz" actually... Now, MacPorts can use .xar too but that's another story. --anders From raimue at macports.org Sun Sep 20 04:57:51 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 20 Sep 2009 13:57:51 +0200 Subject: MacPorts on Other Platforms In-Reply-To: References: Message-ID: <4AB618BF.1090205@macports.org> On 2009-09-20 10:22 , Anders F Bj?rklund wrote: > There are not many mac ports working with "platform freebsd", > but that's not the goal either (although some might be fixed) > The test is more for "base", to test whether it remains working > without the proprietary parts... And thus far, it still does. Although platforms is a mandatory keyword, it is not checked against the current platform. So even if ports do not have freebsd in the platforms, they will still work very likely on freebsd, too. Rainer From raimue at macports.org Sun Sep 20 05:11:58 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 20 Sep 2009 14:11:58 +0200 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <4E9F2734-9363-4192-AB3A-45DC49E2AE55@macports.org> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <20090918064409.GA2844@ninagal.withay.com> <31014a580909180758kc4b068brb6d2e61c7283732d@mail.gmail.com> <17D3ADD6-F154-4ED4-9417-0DFBA3A15A2C@macports.org> <31014a580909182020g656aa49xa1aeff6cf3bb83c5@mail.gmail.com> <6D6BA45C-221A-4D95-89D1-27F90058AB6E@macports.org> <31014a580909191306g46899b0dx2f5469fce2dfba11@mail.gmail.com> <4E9F2734-9363-4192-AB3A-45DC49E2AE55@macports.org> Message-ID: <4AB61C0E.4010603@macports.org> On 2009-09-20 00:28 , Ryan Schmidt wrote: > If your MANPATH is empty (as I believe we recommend), then man will > automatically search for things in all the locations specified in PATH > (that is, for every path in PATH, man will look in ../share/man for > manpages). The installer still sets up a non-empty MANPATH. Using an empty MANPATH is only recommend on ProblemHotlist as it is the most easy fix, but adds additional time to search from bin for man or share/man. > Though it's sounding strange for libexec/gnu to be its own prefix. > apach2, for example, uses ${prefix}/apache2 as its prefix. Granted > that violates the mtree, which I originally objected to in this > thread. :/ Guess I don't really know where it should go. We often talked about apache2 as a bad example of mtree violation and we agreed that it is bad and should be changed. But if I remember correctly this is the default layout the build system produces. We could even provide a small "gnuify" script in ${prefix}/bin which would set up the appropriate PATH and MANPATH. For users it wouldn't matter if the GNU binaries with original names are in ${prefix}/gnu or ${prefix}/libexec/gnu or whatever, they just call gnuify once (or add it to their profile). Rainer From afb at macports.org Sun Sep 20 05:13:12 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 20 Sep 2009 14:13:12 +0200 Subject: MacPorts on Other Platforms In-Reply-To: <4AB618BF.1090205@macports.org> References: <4AB618BF.1090205@macports.org> Message-ID: <2F1177B6-EA74-42BF-BAB9-FC399DBDFA19@macports.org> Rainer M?ller wrote: >> There are not many mac ports working with "platform freebsd", >> but that's not the goal either (although some might be fixed) >> The test is more for "base", to test whether it remains working >> without the proprietary parts... And thus far, it still does. > > Although platforms is a mandatory keyword, it is not checked > against the > current platform. So even if ports do not have freebsd in the > platforms, > they will still work very likely on freebsd, too. What I meant was that even many of those ports that *do* have freebsd in the platforms field currently fail due to bitrot... Theoretically one could encase the platform-specific parts in "platform darwin" and "platform macosx" as appropriate, but there's not enough reason to do so without portability ? So most of the current ports (naturally) just assume Mac OS X. It's not at all impossible to update the ports to work, just a question of whether doing so would be worth the time and effort. Kinda like MP supporting Jaguar and Panther, after a while those extra platform passages are just in the way - and so get deleted ? But if there's any interest, I could post the failures somewhere. Mostly it's just about hardcoding .dylib or missing a "platform{}" --anders PS. What _is_ the "platforms" keyword really good for, anyway ? If it's not being checked, and doesn't allow version/arch ? From ryandesign at macports.org Sun Sep 20 06:07:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 20 Sep 2009 08:07:42 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <4AB61C0E.4010603@macports.org> References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <20090918064409.GA2844@ninagal.withay.com> <31014a580909180758kc4b068brb6d2e61c7283732d@mail.gmail.com> <17D3ADD6-F154-4ED4-9417-0DFBA3A15A2C@macports.org> <31014a580909182020g656aa49xa1aeff6cf3bb83c5@mail.gmail.com> <6D6BA45C-221A-4D95-89D1-27F90058AB6E@macports.org> <31014a580909191306g46899b0dx2f5469fce2dfba11@mail.gmail.com> <4E9F2734-9363-4192-AB3A-45DC49E2AE55@macports.org> <4AB61C0E.4010603@macports.org> Message-ID: On Sep 20, 2009, at 07:11, Rainer M?ller wrote: > On 2009-09-20 00:28 , Ryan Schmidt wrote: >> If your MANPATH is empty (as I believe we recommend), then man will >> automatically search for things in all the locations specified in >> PATH >> (that is, for every path in PATH, man will look in ../share/man for >> manpages). > > The installer still sets up a non-empty MANPATH. Using an empty > MANPATH > is only recommend on ProblemHotlist as it is the most easy fix, but > adds > additional time to search from bin for man or share/man. The MacPorts installer package postflight script only modifies the MANPATH if it is not empty. If it is empty, no modification is needed; the manpages are found automatically by searching ../share/man relative to each entry of PATH. Surely the amount of time the computer needs to translate the strings in PATH isn't large? When Leopard was released we discovered it now put things in MANPATH by default, to enable path_helper to work. This was a bit annoying because it disabled the automatic manpage finding, and it appears that Apple learned in Snow Leopard, and MANPATH is no longer modified for path_helper if it is empty (according to the manpage for path_helper). >> Though it's sounding strange for libexec/gnu to be its own prefix. >> apach2, for example, uses ${prefix}/apache2 as its prefix. Granted >> that violates the mtree, which I originally objected to in this >> thread. :/ Guess I don't really know where it should go. > > We often talked about apache2 as a bad example of mtree violation > and we > agreed that it is bad and should be changed. Yes, hence my hesitation. > But if I remember correctly > this is the default layout the build system produces. It's what happens when you use --prefix=${prefix}/${name} anyway, which is what the port does. Who knows what would happen if we left it at the default --prefix=${prefix}. > We could even provide a small "gnuify" script in ${prefix}/bin which > would set up the appropriate PATH and MANPATH. For users it wouldn't > matter if the GNU binaries with original names are in ${prefix}/gnu or > ${prefix}/libexec/gnu or whatever, they just call gnuify once (or > add it > to their profile). We could provide such a script, but if we set MANPATH in it, it would have the disadvantage of making MANPATH nonempty again and thus disabling the automatic manpage finding feature which the user may have been relying on for other manpages. The discussion was between having a directory under ${prefix} which would behave like a prefix for GNU software -- would contain bin and share directories -- or making GNU subdirectories within both the ${prefix}/bin and ${prefix}/ share directories; the automatic manpage finding feature wouldn't be able to find the manpages given that layout. From ryandesign at macports.org Sun Sep 20 06:11:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 20 Sep 2009 08:11:49 -0500 Subject: MacPorts on Other Platforms In-Reply-To: <2F1177B6-EA74-42BF-BAB9-FC399DBDFA19@macports.org> References: <4AB618BF.1090205@macports.org> <2F1177B6-EA74-42BF-BAB9-FC399DBDFA19@macports.org> Message-ID: <7DCD5B02-F861-4BAB-B2E8-121169A6E81E@macports.org> On Sep 20, 2009, at 07:13, Anders F Bj?rklund wrote: > But if there's any interest, I could post the failures somewhere. > Mostly it's just about hardcoding .dylib or missing a "platform{}" I try to put obviously Mac OS X-specific things in a "platform darwin" section. I've certainly seen ports that don't bother. I'm sure if anyone were actually trying to use MacPorts on another OS and encountered problems, they would file tickets. > PS. What _is_ the "platforms" keyword really good for, anyway ? > If it's not being checked, and doesn't allow version/arch ? The purpose is probably to give somebody looking at the portfile or "port info" output an indication of the platforms the maintainer intends the port to work with. It's kinda like the license keyword we have now. Nothing in base uses that either; it's just informative to the user. We could write code in base to check the platform -- for example to check that if "platforms" is "macosx" that we are really running on Mac OS X and not PureDarwin. But since I doubt anybody is using MacPorts on anything other than Mac OS X, our effort might be better spent elsewhere. From raimue at macports.org Sun Sep 20 07:13:10 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 20 Sep 2009 16:13:10 +0200 Subject: MacPorts on Other Platforms In-Reply-To: <7DCD5B02-F861-4BAB-B2E8-121169A6E81E@macports.org> References: <4AB618BF.1090205@macports.org> <2F1177B6-EA74-42BF-BAB9-FC399DBDFA19@macports.org> <7DCD5B02-F861-4BAB-B2E8-121169A6E81E@macports.org> Message-ID: <4AB63876.2040600@macports.org> On 2009-09-20 15:11 , Ryan Schmidt wrote: > We could write code in base to check the platform -- for example to > check that if "platforms" is "macosx" that we are really running on > Mac OS X and not PureDarwin. But since I doubt anybody is using > MacPorts on anything other than Mac OS X, our effort might be better > spent elsewhere. See also my proposal to extend platforms: But you are right, it is just not that important. Rainer From afb at macports.org Sun Sep 20 08:02:46 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 20 Sep 2009 17:02:46 +0200 Subject: MacPorts on Other Platforms In-Reply-To: <7DCD5B02-F861-4BAB-B2E8-121169A6E81E@macports.org> References: <4AB618BF.1090205@macports.org> <2F1177B6-EA74-42BF-BAB9-FC399DBDFA19@macports.org> <7DCD5B02-F861-4BAB-B2E8-121169A6E81E@macports.org> Message-ID: Ryan Schmidt wrote: >> But if there's any interest, I could post the failures somewhere. >> Mostly it's just about hardcoding .dylib or missing a "platform{}" > > I try to put obviously Mac OS X-specific things in a "platform > darwin" section. I've certainly seen ports that don't bother. > > I'm sure if anyone were actually trying to use MacPorts on another > OS and encountered problems, they would file tickets. Obviously nobody is... :-) Some of the errors are a bit trickier, like for instance expecting /usr/bin/patch to be GNU patch or assuming that "make -j1" works. Or not stating -DPIC -fPIC (since that's the default on Mac OS X), or writing #!/bin/sh shell scripts for bash only. Things like that. That ports intended only for Mac OS X, like for instance Xquartz, doesn't work on other platforms except macosx is understandable. But I suppose one could file tickets for the instances where it's actually "base" itself that gets in the way for portability... ? Or just fix them instead. --anders From howarth at bromo.med.uc.edu Sun Sep 20 10:41:18 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 20 Sep 2009 13:41:18 -0400 Subject: macport's oddity In-Reply-To: <20090920051257.GS1215@darkart.com> References: <20090920022503.GA21868@bromo.med.uc.edu> <20090920051257.GS1215@darkart.com> Message-ID: <20090920174118.GA18686@bromo.med.uc.edu> On Sun, Sep 20, 2009 at 05:12:57AM +0000, Eric Hall wrote: > > Did you bother to check your PATH in those > terminal windows where things didn't work? If you > did, did it have /opt/local/bin:/opt/local/sbin > in it? If so, then that's a bit odd, but at a shell > and/or system level, not something that MacPorts > is doing. If not, then it sounds perfectly normal > for a shell. > > > -eric > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev The PATH is showing... [Macintosh-2:~] howarth% printenv PATH /opt/local/bin:/opt/local/sbin:.:/usr/local/NMRPipe/nmrbin.mac:/usr/local/NMRPipe/com:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin It seems obvious that it had to be set otherwise opening a new Terminal window wouldn't solve the issue. I'll try bash to verify that problem disappears under that shell. It is a really odd glitch as I've never seen tcsh not 'find' new files after a rehash but require a new Terminal window. FYI, this is under Snow Leopard. Jack From kw at codebykevin.com Sun Sep 20 10:50:06 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Sun, 20 Sep 2009 13:50:06 -0400 Subject: macport's oddity In-Reply-To: <20090920174118.GA18686@bromo.med.uc.edu> References: <20090920022503.GA21868@bromo.med.uc.edu> <20090920051257.GS1215@darkart.com> <20090920174118.GA18686@bromo.med.uc.edu> Message-ID: <4AB66B4E.8040805@codebykevin.com> On 9/20/09 1:41 PM, Jack Howarth wrote: > On Sun, Sep 20, 2009 at 05:12:57AM +0000, Eric Hall wrote: >> >> Did you bother to check your PATH in those >> terminal windows where things didn't work? If you >> did, did it have /opt/local/bin:/opt/local/sbin >> in it? If so, then that's a bit odd, but at a shell >> and/or system level, not something that MacPorts >> is doing. If not, then it sounds perfectly normal >> for a shell. >> >> >> -eric >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > The PATH is showing... > > [Macintosh-2:~] howarth% printenv PATH > /opt/local/bin:/opt/local/sbin:.:/usr/local/NMRPipe/nmrbin.mac:/usr/local/NMRPipe/com:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin > > It seems obvious that it had to be set otherwise opening a > new Terminal window wouldn't solve the issue. I'll > try bash to verify that problem disappears under that > shell. It is a really odd glitch as I've never seen > tcsh not 'find' new files after a rehash but require > a new Terminal window. FYI, this is under Snow Leopard. Doesn't Fink source an "init.sh" file that modifies your path on the fly? #test -r /sw/bin/init.sh && . /sw/bin/init.sh MacPorts doesn't do this, it simply adds /opt/local/bin to the $PATH defined in your ~/.profile, which won't show up until a new Terminal session is open. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com From jeremy at lavergne.gotdns.org Sun Sep 20 10:53:22 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sun, 20 Sep 2009 13:53:22 -0400 Subject: macport's oddity In-Reply-To: <4AB66B4E.8040805@codebykevin.com> References: <20090920022503.GA21868@bromo.med.uc.edu> <20090920051257.GS1215@darkart.com> <20090920174118.GA18686@bromo.med.uc.edu> <4AB66B4E.8040805@codebykevin.com> Message-ID: <95536878-0CD2-456F-873E-E20602669FA8@lavergne.gotdns.org> MacPorts was already installed, so the path was already available. The problem is that after a rehash of the path, the new binaries weren't available. On Sep 20, 2009, at 1:50 PM, Kevin Walzer wrote: > Doesn't Fink source an "init.sh" file that modifies your path on the > fly? > > #test -r /sw/bin/init.sh && . /sw/bin/init.sh > > MacPorts doesn't do this, it simply adds /opt/local/bin to the $PATH > defined in your ~/.profile, which won't show up until a new Terminal > session is open. From howarth at bromo.med.uc.edu Sun Sep 20 12:09:30 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 20 Sep 2009 15:09:30 -0400 Subject: macport's oddity In-Reply-To: <95536878-0CD2-456F-873E-E20602669FA8@lavergne.gotdns.org> References: <20090920022503.GA21868@bromo.med.uc.edu> <20090920051257.GS1215@darkart.com> <20090920174118.GA18686@bromo.med.uc.edu> <4AB66B4E.8040805@codebykevin.com> <95536878-0CD2-456F-873E-E20602669FA8@lavergne.gotdns.org> Message-ID: <20090920190930.GA19245@bromo.med.uc.edu> On Sun, Sep 20, 2009 at 01:53:22PM -0400, Jeremy Lavergne wrote: > MacPorts was already installed, so the path was already available. > > The problem is that after a rehash of the path, the new binaries weren't > available. > I have a question posted on fink-devel to try to find out if the fink installer is doing anything secretly to make such files seen. Jack From ryandesign at macports.org Sun Sep 20 17:10:59 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 20 Sep 2009 19:10:59 -0500 Subject: MacPorts on Other Platforms In-Reply-To: References: <4AB618BF.1090205@macports.org> <2F1177B6-EA74-42BF-BAB9-FC399DBDFA19@macports.org> <7DCD5B02-F861-4BAB-B2E8-121169A6E81E@macports.org> Message-ID: <37467630-BBF8-4879-A27F-A6978E690BB5@macports.org> On Sep 20, 2009, at 10:02, Anders F Bj?rklund wrote: > Some of the errors are a bit trickier, like for instance expecting > /usr/bin/patch to be GNU patch or assuming that "make -j1" works. "make -j1" doesn't work on other platforms? From afb at macports.org Sun Sep 20 23:10:17 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 21 Sep 2009 08:10:17 +0200 Subject: MacPorts on Other Platforms In-Reply-To: <37467630-BBF8-4879-A27F-A6978E690BB5@macports.org> References: <4AB618BF.1090205@macports.org> <2F1177B6-EA74-42BF-BAB9-FC399DBDFA19@macports.org> <7DCD5B02-F861-4BAB-B2E8-121169A6E81E@macports.org> <37467630-BBF8-4879-A27F-A6978E690BB5@macports.org> Message-ID: <0B7D82B9-658B-45C0-8F41-2D0C452009BF@macports.org> Ryan Schmidt wrote: >> Some of the errors are a bit trickier, like for instance expecting >> /usr/bin/patch to be GNU patch or assuming that "make -j1" works. > > "make -j1" doesn't work on other platforms? Not always, since -j1 is also a parallel build mode so it fails on some makes much the same way as -j2 does. "make" is safer... It's not so much about other OS platforms as it is about different /usr/bin/make, as you can test on Mac OS X by pointing the symlink at bsdmake instead of the default gnumake. Patch has same problems, with /usr/bin/patch versus gpatch (either system or through port). MacPorts unfortunately has a lot of unspecified dependencies like that, whether it is on /usr/bin/make or /usr/bin/patch or if it is /usr/bin/javac or /usr/sbin/mtree - all of them beyond MP's control. We've documented a few of them, but there are many more implicit. This makes it less portable, if it requires "Mac OS X" and "Xcode" instead of explicit dependencies like Tcl or GCC... That's all. --anders From ryandesign at macports.org Sun Sep 20 23:29:52 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 21 Sep 2009 01:29:52 -0500 Subject: MacPorts on Other Platforms In-Reply-To: <0B7D82B9-658B-45C0-8F41-2D0C452009BF@macports.org> References: <4AB618BF.1090205@macports.org> <2F1177B6-EA74-42BF-BAB9-FC399DBDFA19@macports.org> <7DCD5B02-F861-4BAB-B2E8-121169A6E81E@macports.org> <37467630-BBF8-4879-A27F-A6978E690BB5@macports.org> <0B7D82B9-658B-45C0-8F41-2D0C452009BF@macports.org> Message-ID: <8C07100F-A198-42D9-8B4C-0F20FF0A75AE@macports.org> On Sep 21, 2009, at 01:10, Anders F Bj?rklund wrote: > Ryan Schmidt wrote: > >> "make -j1" doesn't work on other platforms? > > Not always, since -j1 is also a parallel build mode so it fails > on some makes much the same way as -j2 does. "make" is safer... We can easily change that of course. I obviously didn't realize there was any difference at all between "make" and "make -j1". I don't see how "make -j1" could be thought to be a parallel build mode, since it will run only 1 job at a time, hence no jobs in parallel... > It's not so much about other OS platforms as it is about different > /usr/bin/make, as you can test on Mac OS X by pointing the symlink > at bsdmake instead of the default gnumake. But MacPorts is documented as using GNU make by default. That's build.type. MacPorts should be using GNU make by default on all platforms unless the port sets build.type to bsd. Is this not the case? > Patch has same problems, > with /usr/bin/patch versus gpatch (either system or through port). I imagine so; I see you made gpatch available in base; thanks. > MacPorts unfortunately has a lot of unspecified dependencies like > that, whether it is on /usr/bin/make or /usr/bin/patch or if it is > /usr/bin/javac or /usr/sbin/mtree - all of them beyond MP's control. > We've documented a few of them, but there are many more implicit. > > This makes it less portable, if it requires "Mac OS X" and "Xcode" > instead of explicit dependencies like Tcl or GCC... That's all. Yeah. I guess all we can do is fix things when problems are reported. From afb at macports.org Sun Sep 20 23:54:12 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 21 Sep 2009 08:54:12 +0200 Subject: MacPorts on Other Platforms In-Reply-To: <8C07100F-A198-42D9-8B4C-0F20FF0A75AE@macports.org> References: <4AB618BF.1090205@macports.org> <2F1177B6-EA74-42BF-BAB9-FC399DBDFA19@macports.org> <7DCD5B02-F861-4BAB-B2E8-121169A6E81E@macports.org> <37467630-BBF8-4879-A27F-A6978E690BB5@macports.org> <0B7D82B9-658B-45C0-8F41-2D0C452009BF@macports.org> <8C07100F-A198-42D9-8B4C-0F20FF0A75AE@macports.org> Message-ID: Ryan Schmidt wrote: >>> "make -j1" doesn't work on other platforms? >> >> Not always, since -j1 is also a parallel build mode so it fails >> on some makes much the same way as -j2 does. "make" is safer... > > We can easily change that of course. I obviously didn't realize > there was any difference at all between "make" and "make -j1". I > don't see how "make -j1" could be thought to be a parallel build > mode, since it will run only 1 job at a time, hence no jobs in > parallel... I think it only runs one at a time anyway, just that the deps fail. Or something like that, it's not like I actually digged into it... Just noticed that "make" works and "make -j1" does not. Besides, that "-j1" argument seemed rather silly to me in the first place ? >> It's not so much about other OS platforms as it is about different >> /usr/bin/make, as you can test on Mac OS X by pointing the symlink >> at bsdmake instead of the default gnumake. > > But MacPorts is documented as using GNU make by default. That's > build.type. MacPorts should be using GNU make by default on all > platforms unless the port sets build.type to bsd. Is this not the > case? If nothing is set for build.type, it uses system make: if {![exists build.type]} { return [findBinary make $portutil::autoconf::make_path] } So it was using -j1 for bsdmake as well ? Or actually it was using "fail" (2) for -j until the default value was changed from 0 to 1. So "whatever the system provides" is the default value, then it can be explicitly set to GNU for the 0.01% of the ports that care. >> This makes it less portable, if it requires "Mac OS X" and "Xcode" >> instead of explicit dependencies like Tcl or GCC... That's all. > > Yeah. I guess all we can do is fix things when problems are reported. No, what you *could* do instead is saying "So what ? We don't care !" and just have MacPorts require Mac OS X (10.5+ ?) and be done with it. I don't think that MacPorts could ever be a portable build system, I was just making sure that it runs on Darwin OS and now FreeBSD... Partly because I think Open Source is important, and partly because I don't have a new Mac to join in on the Snow Leopard crash fest... --anders From ryandesign at macports.org Mon Sep 21 00:24:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 21 Sep 2009 02:24:24 -0500 Subject: MacPorts on Other Platforms In-Reply-To: References: <4AB618BF.1090205@macports.org> <2F1177B6-EA74-42BF-BAB9-FC399DBDFA19@macports.org> <7DCD5B02-F861-4BAB-B2E8-121169A6E81E@macports.org> <37467630-BBF8-4879-A27F-A6978E690BB5@macports.org> <0B7D82B9-658B-45C0-8F41-2D0C452009BF@macports.org> <8C07100F-A198-42D9-8B4C-0F20FF0A75AE@macports.org> Message-ID: <407CE574-6666-471E-B178-59952B1DC1B0@macports.org> On Sep 21, 2009, at 01:54, Anders F Bj?rklund wrote: > I think it only runs one at a time anyway, just that the deps fail. > Or something like that, it's not like I actually digged into it... > > Just noticed that "make" works and "make -j1" does not. On base? On a particular port? > Besides, > that "-j1" argument seemed rather silly to me in the first place ? Sure. There's just no special case code in there to handle when jobs=1. But like I said it could be easily added. How about this patch? Index: portbuild.tcl =================================================================== --- portbuild.tcl (revision 57981) +++ portbuild.tcl (working copy) @@ -142,7 +142,7 @@ return "" } - if {![exists build.jobs] || !([string match "*make*" [option build.cmd]] || [string match "*scons*" [option build.cmd]])} { + if {![exists build.jobs] || 1 == [option build.jobs] || !([string match "*make*" [option build.cmd]] || [string match "*scons*" [option build.cmd]])} { return "" } return " -j[option build.jobs]" >> But MacPorts is documented as using GNU make by default. That's >> build.type. MacPorts should be using GNU make by default on all >> platforms unless the port sets build.type to bsd. Is this not the >> case? > > If nothing is set for build.type, it uses system make: > if {![exists build.type]} { > return [findBinary make $portutil::autoconf::make_path] > } Ok. That's not what our documentation says happens. :) http://guide.macports.org/#reference.phases.build I think we should change the code to match the documentation, which means "build.type gnu" should be the default. > So it was using -j1 for bsdmake as well ? Or actually it was using > "fail" (2) for -j until the default value was changed from 0 to 1. > > So "whatever the system provides" is the default value, then it > can be explicitly set to GNU for the 0.01% of the ports that care. I'd rather change base to match the documentation in this case, since what's documented sounds like more predictable behavior. >>> This makes it less portable, if it requires "Mac OS X" and "Xcode" >>> instead of explicit dependencies like Tcl or GCC... That's all. >> >> Yeah. I guess all we can do is fix things when problems are reported. > > No, what you *could* do instead is saying "So what ? We don't care !" We could do that as well. > and just have MacPorts require Mac OS X (10.5+ ?) and be done with it. We currently work on Mac OS X 10.4 and up and should not unnecessarily exclude 10.4 at this point. > I don't think that MacPorts could ever be a portable build system, I don't know if it could be. But it seems to me we have enough on our hands trying to make a good Mac build system without also trying to accommodate other OSes. > I was just making sure that it runs on Darwin OS and now FreeBSD... > Partly because I think Open Source is important, and partly because > I don't have a new Mac to join in on the Snow Leopard crash fest... Thanks! I certainly appreciate your efforts. They might well uncover other issues which are relevant on Mac OS X as well. From ryandesign at macports.org Mon Sep 21 00:33:27 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 21 Sep 2009 02:33:27 -0500 Subject: MacPorts on Other Platforms In-Reply-To: <407CE574-6666-471E-B178-59952B1DC1B0@macports.org> References: <4AB618BF.1090205@macports.org> <2F1177B6-EA74-42BF-BAB9-FC399DBDFA19@macports.org> <7DCD5B02-F861-4BAB-B2E8-121169A6E81E@macports.org> <37467630-BBF8-4879-A27F-A6978E690BB5@macports.org> <0B7D82B9-658B-45C0-8F41-2D0C452009BF@macports.org> <8C07100F-A198-42D9-8B4C-0F20FF0A75AE@macports.org> <407CE574-6666-471E-B178-59952B1DC1B0@macports.org> Message-ID: <79E6106E-ABCB-48E2-9715-533CD0A639C1@macports.org> On Sep 21, 2009, at 02:24, Ryan Schmidt wrote: >> Besides, >> that "-j1" argument seemed rather silly to me in the first place ? > > Sure. There's just no special case code in there to handle when > jobs=1. But like I said it could be easily added. How about this > patch? > > > Index: portbuild.tcl > =================================================================== > --- portbuild.tcl (revision 57981) > +++ portbuild.tcl (working copy) > @@ -142,7 +142,7 @@ > return "" > } > > - if {![exists build.jobs] || !([string match "*make*" [option > build.cmd]] || [string match "*scons*" [option build.cmd]])} { > + if {![exists build.jobs] || 1 == [option build.jobs] || ! > ([string match "*make*" [option build.cmd]] || [string match > "*scons*" [option build.cmd]])} { > return "" > } > return " -j[option build.jobs]" Oh, I see now you committed a different fix in r57998. Wouldn't mine be simpler? From afb at macports.org Mon Sep 21 02:46:27 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 21 Sep 2009 11:46:27 +0200 Subject: MacPorts on Other Platforms In-Reply-To: <407CE574-6666-471E-B178-59952B1DC1B0@macports.org> References: <4AB618BF.1090205@macports.org> <2F1177B6-EA74-42BF-BAB9-FC399DBDFA19@macports.org> <7DCD5B02-F861-4BAB-B2E8-121169A6E81E@macports.org> <37467630-BBF8-4879-A27F-A6978E690BB5@macports.org> <0B7D82B9-658B-45C0-8F41-2D0C452009BF@macports.org> <8C07100F-A198-42D9-8B4C-0F20FF0A75AE@macports.org> <407CE574-6666-471E-B178-59952B1DC1B0@macports.org> Message-ID: Ryan Schmidt wrote: >> I think it only runs one at a time anyway, just that the deps fail. >> Or something like that, it's not like I actually digged into it... >> >> Just noticed that "make" works and "make -j1" does not. > > On base? On a particular port? Sadly I forgot which, will need to check the FreeBSD logs for details. But it's "not always". >> If nothing is set for build.type, it uses system make: >> if {![exists build.type]} { >> return [findBinary make $portutil::autoconf::make_path] >> } > > Ok. That's not what our documentation says happens. :) > > http://guide.macports.org/#reference.phases.build > > I think we should change the code to match the documentation, which > means "build.type gnu" should be the default. Or you could change the documentation to say that "make" is default. It doesn't really matter on Mac OS X, since make -> gnumake anyway ? >> and just have MacPorts require Mac OS X (10.5+ ?) and be done with >> it. > > We currently work on Mac OS X 10.4 and up and should not > unnecessarily exclude 10.4 at this point. I was just extrapolating, since Tiger is now a legacy platform and these changes would probably be for next release / year... ? Moving away from +system_x11 seems to have "destroyed" my Tiger installation anyway, so I would need to reinstall MacPorts there. > I don't know if it could be. But it seems to me we have enough on > our hands trying to make a good Mac build system without also > trying to accommodate other OSes. Yup, that's what everyone says :-) "Can't get along now, we're busy" >> I was just making sure that it runs on Darwin OS and now FreeBSD... >> Partly because I think Open Source is important, and partly because >> I don't have a new Mac to join in on the Snow Leopard crash fest... > > Thanks! I certainly appreciate your efforts. They might well > uncover other issues which are relevant on Mac OS X as well. We found a lot of base bugs during the initial BSD and GNU porting. --anders From afb at macports.org Mon Sep 21 02:47:14 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 21 Sep 2009 11:47:14 +0200 Subject: MacPorts on Other Platforms In-Reply-To: <79E6106E-ABCB-48E2-9715-533CD0A639C1@macports.org> References: <4AB618BF.1090205@macports.org> <2F1177B6-EA74-42BF-BAB9-FC399DBDFA19@macports.org> <7DCD5B02-F861-4BAB-B2E8-121169A6E81E@macports.org> <37467630-BBF8-4879-A27F-A6978E690BB5@macports.org> <0B7D82B9-658B-45C0-8F41-2D0C452009BF@macports.org> <8C07100F-A198-42D9-8B4C-0F20FF0A75AE@macports.org> <407CE574-6666-471E-B178-59952B1DC1B0@macports.org> <79E6106E-ABCB-48E2-9715-533CD0A639C1@macports.org> Message-ID: <7CAF3BCB-4D78-4B60-A093-3E302059B2BD@macports.org> >> Sure. There's just no special case code in there to handle when >> jobs=1. But like I said it could be easily added. How about this >> patch? >> - if {![exists build.jobs] || !([string match "*make*" [option >> build.cmd]] || [string match "*scons*" [option build.cmd]])} { >> + if {![exists build.jobs] || 1 == [option build.jobs] || ! >> ([string match "*make*" [option build.cmd]] || [string match >> "*scons*" [option build.cmd]])} { > Oh, I see now you committed a different fix in r57998. Wouldn't > mine be simpler? I just restored my original code, which was "simple" to me :-) Seems like it got lost in the split-and-rewrite of r52390 ? Feel free to revise it, although I do think you should keep the integer check on any build.jobs=foo parameters passed... --anders From ryandesign at macports.org Tue Sep 22 01:02:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 22 Sep 2009 03:02:03 -0500 Subject: [MacPorts] #21437: The MAMP howto doesn't match the sample phpMyAdmin config file In-Reply-To: <966588EB-1831-4CCB-8194-CDFF93C71B4D@mac.com> References: <052.822b01b093ac429a1a186ce38b4d504f@macports.org> <061.5e1ddb1776a10cdc39df43b60f5ba0db@macports.org> <389B9371-B6FE-498C-B420-036B889E80EE@mac.com> <966588EB-1831-4CCB-8194-CDFF93C71B4D@mac.com> Message-ID: On Sep 21, 2009, at 15:01, Steve Meether wrote: > I finally got PhpMyAdmin to work. > > I tried several things and, to be honest, I'm not sure if it was one > of those things are all of them together solved the issue. > > 1) in the config.inc.php I changed the following line: > > from: > $cfg['Servers'][$i]['host'] = 'localhost'; > > to > $cfg['Servers'][$i]['host'] = '127.0.0.1'; > > > I believe this is what allowed PhpMyAdmin to start working Changing the connection from localhost to 127.0.0.1 will cause the mysql client in php to try to connect via TCP instead of via the socket file. So if this fixed the issue for you, that suggests the socket file was not at the place that PHP expected. Have you configured the socket location properly in your php.ini? There are three places to do it (one each for mysql, mysqli and pdo_mysql). From talklists at newgeo.com Tue Sep 22 13:08:03 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 22 Sep 2009 13:08:03 -0700 Subject: [MacPorts] #21437: The MAMP howto doesn't match the sample phpMyAdmin config file In-Reply-To: References: <052.822b01b093ac429a1a186ce38b4d504f@macports.org> <061.5e1ddb1776a10cdc39df43b60f5ba0db@macports.org> <389B9371-B6FE-498C-B420-036B889E80EE@mac.com> <966588EB-1831-4CCB-8194-CDFF93C71B4D@mac.com> Message-ID: <8FB55AF2-D2AF-46FA-800A-A865566B6470@newgeo.com> On Sep 22, 2009, at 1:02 AM, Ryan Schmidt wrote: > > On Sep 21, 2009, at 15:01, Steve Meether wrote: > >> I finally got PhpMyAdmin to work. >> >> I tried several things and, to be honest, I'm not sure if it was >> one of those things are all of them together solved the issue. >> >> 1) in the config.inc.php I changed the following line: >> >> from: >> $cfg['Servers'][$i]['host'] = 'localhost'; >> >> to >> $cfg['Servers'][$i]['host'] = '127.0.0.1'; >> >> >> I believe this is what allowed PhpMyAdmin to start working > > Changing the connection from localhost to 127.0.0.1 will cause the > mysql client in php to try to connect via TCP instead of via the > socket file. So if this fixed the issue for you, that suggests the > socket file was not at the place that PHP expected. Have you > configured the socket location properly in your php.ini? There are > three places to do it (one each for mysql, mysqli and pdo_mysql). I have been following a little the phpMyAdmin thread on the list, I am not up to date on it, but wanted to chime in on this one, and seek clarification. I have had to install apache2, mysql5, and php5 on a few machines, and reinstall lately. It is no longer as smooth a process as it once was. In general, you followed the instructions in the output of macports, and had a working phpInfo() page in short order. Now, all of a sudden, the socket has changed to MySql. Why? There are now three places you need to edit in php.ini to get this all working. In the past, there were zero. Personally, I do not see why the socket can not be in the default location that php is going to look for it. Was this change a result of wanting to keep the socket in {prefix} instead of the default, which I believe is outside of prefix? If that is the case, then why not set the socket path at build time of php so that it is now the default, and no editing of php.ini need be done? Or reinplace php.ini's conf files, though that does not solve it when there is no php.ini and we fall back on defaults. I have done this 10 times over, and I still get hung up on it. As to the phpMyAdmin, you do not want to change the localhost to an IP address, as it is not going to use socket, and as Ryan said, use tcp. Not sure the downside of that, but it is not needed. I have sort of wondered about the phpMyAdmin port. This is one of those ports that it may be a disadvantage to have as a port. I would like to hear some comments on my reasoning... Here is how I install phpMyAdmin 1) Download and uppack 2) change directory name to db-admin or similar 3) Upload those files to somewhere served by apache maybe example.com/db-admin 4) Edit the config samples one line of $cfg['blowfish_secret'] = 'random garbage here'; 5) Rename the config file to config.inc.php In this case, MacPorts affords you step 1, the rest of the steps, you either have to do on your own, or chose not to do in order for port update to work. phpMyAdmin is a drag and drop install, managing it with ports may make your life harder, and impose limits on your install by forcing it to be in a location you may not like. If you chose to want to access it at example.com/clients/db then you will have to learn mod_rewrite to make that happen. I suppose there is value in those who are ok with it being installed where it is by default, and just want a simple way to manage and update things. Can we discuss why this socket was changed? I maintain and manage apache, mysql, and php daily, and am constantly boogered by this socket path change, which was something I never had to think about in the past. Can php be changed to have a new internal socket path ref that is ${prefix}/var/run/${mysql}/mysqld.sock Or would it be better to change the MySql port to use the socket path that php defaults to? Or is there some way to port install mysql5 +socket=/where/php/is/ looking I poked into trac to see if I could see when this change happened in mysql5, or if there was discussion on it. I just do not know how to search in trac well enough to find the tickets as amazingly as you guys always do. :) * Not complaining, love you guys, this one just struck me as an odd change in behavior, and one that was a non issue for me in the past. Everyone will get hung up on this, this opens the door to emails to the list that never were here before. -- Scott * If you contact me off list replace talklists@ with scott@ * From bcbarnes at gmail.com Tue Sep 22 14:43:14 2009 From: bcbarnes at gmail.com (Brian Barnes) Date: Tue, 22 Sep 2009 16:43:14 -0500 Subject: darwin may lose primary target status on FSF gcc Message-ID: Regarding the discussion about gcc 4.5.0 problems on darwin and the back-and-forth between Toby and Jack: I have just now caught up on this thread, and I want to echo my support of pretty much everything Jack Howarth has said. I'm a long time user of gcc/gfortran for high performance scientific computing. The HPC world essentially revolves around two compiler suites: gcc and intel (although a few other commercial compilers still have notable followings). Both perform well on linux and OS X. Only one of them is free. If gcc (and hence, gfortran) support on OS X and macports is allowed to stagnate and die, there will be no viable free option for modern Fortran compilation on OS X. g95 is simply too slow and based on too old of a gcc codebase to warrant consideration. Fortran is not a 'dead' language or standard. There are many features of Fortran 2003 which are still being implemented in gfotran, and essentially all of the Fortran 2008 standard (co-arrays!) still needs to be implemented. The llvm/clang community appears to have nobody / very few people interested in implementing a Fortran front-end, and the gfortran maintainers are not going to branch out and start contributing to clang. Fortran is still used every day in scientific computing and the availability of a modern gcc/gfortran on OS X is a major reason I use macports, and, in fact, and am able to use my Mac for work at all (without shelling out for the Intel compilers). It is very important to the HPC community that macports/Apple keeps the latest gcc up-to-date and available! Brian p.s. ... I have patched the latest openmpi Portfile on my local machine, making the obvious changes to allow it to use gcc44 instead of gcc43 (the port seems stagnant). Compile + install went fine. From toby at macports.org Tue Sep 22 15:02:00 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 22 Sep 2009 15:02:00 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: References: Message-ID: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> On Tue, Sep 22, 2009 at 14:43, Brian Barnes wrote: > The llvm/clang community appears to have nobody / very few people interested > in implementing a Fortran front-end Only one way to change that... - Toby From howarth at bromo.med.uc.edu Tue Sep 22 15:04:25 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 22 Sep 2009 18:04:25 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: References: Message-ID: <20090922220425.GA18583@bromo.med.uc.edu> On Tue, Sep 22, 2009 at 04:43:14PM -0500, Brian Barnes wrote: > Regarding the discussion about gcc 4.5.0 problems on darwin and the > back-and-forth between Toby and Jack: > > I have just now caught up on this thread, and I want to echo my support > of pretty much everything Jack Howarth has said. I'm a long time user of > gcc/gfortran for high performance scientific computing. The HPC world > essentially revolves around two compiler suites: gcc and intel (although > a few other commercial compilers still have notable followings). Both > perform well on linux and OS X. Only one of them is free. If gcc (and > hence, gfortran) support on OS X and macports is allowed to stagnate and > die, there will be no viable free option for modern Fortran compilation > on OS X. g95 is simply too slow and based on too old of a gcc codebase > to warrant consideration. > > Fortran is not a 'dead' language or standard. There are many features of > Fortran 2003 which are still being implemented in gfotran, and > essentially all of the Fortran 2008 standard (co-arrays!) still needs to > be implemented. The llvm/clang community appears to have nobody / very > few people interested in implementing a Fortran front-end, and the > gfortran maintainers are not going to branch out and start contributing > to clang. Fortran is still used every day in scientific computing and the > availability of a modern gcc/gfortran on OS X is a major reason I use > macports, and, in fact, and am able to use my Mac for work at all > (without shelling out for the Intel compilers). It is very important to > the HPC community that macports/Apple keeps the latest gcc up-to-date and > available! > > Brian > > p.s. ... I have patched the latest openmpi Portfile on my local machine, > making the obvious changes to allow it to use gcc44 instead of gcc43 (the > port seems stagnant). Compile + install went fine. > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev Heh, it's kinda late now. We just got depreciated as a primary target today... http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01523.html and they are already queuing up to commit patches which will break the darwin builds... http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01545.html It will be interesting to see how helpful the other non-darwin maintainers are without the requirement to support darwin as a primary target. Jack From howarth at bromo.med.uc.edu Tue Sep 22 15:08:24 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 22 Sep 2009 18:08:24 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> Message-ID: <20090922220824.GB18583@bromo.med.uc.edu> On Tue, Sep 22, 2009 at 03:02:00PM -0700, Toby Peterson wrote: > On Tue, Sep 22, 2009 at 14:43, Brian Barnes wrote: > > The llvm/clang community appears to have nobody / very few people interested > > in implementing a Fortran front-end > > Only one way to change that... Toby, I suspect a careful review of the gfortran progress will show that it only gained traction when programmers contracted to improve it came on board. Expecting a 'grass-roots' fortran project to viable is a bit unrealistic. Only if FSF gcc became unbuildable on darwin might a company feel the need to expend funds on such a project. Jack > > - Toby > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From toby at macports.org Tue Sep 22 15:21:31 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 22 Sep 2009 15:21:31 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090922220824.GB18583@bromo.med.uc.edu> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> Message-ID: <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> On Tue, Sep 22, 2009 at 15:08, Jack Howarth wrote: > On Tue, Sep 22, 2009 at 03:02:00PM -0700, Toby Peterson wrote: >> On Tue, Sep 22, 2009 at 14:43, Brian Barnes wrote: >> > The llvm/clang community appears to have nobody / very few people interested >> > in implementing a Fortran front-end >> >> Only one way to change that... > > ? I suspect a careful review of the gfortran progress will show > that it only gained traction when programmers contracted to improve > it came on board. Expecting a 'grass-roots' fortran project to > viable is a bit unrealistic. Only if FSF gcc became unbuildable > on darwin might a company feel the need to expend funds on such > a project. In that case let's hope it becomes unbuildable sooner rather than later. - Toby From bcbarnes at gmail.com Tue Sep 22 15:34:24 2009 From: bcbarnes at gmail.com (Brian Barnes) Date: Tue, 22 Sep 2009 17:34:24 -0500 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090922220425.GA18583@bromo.med.uc.edu> References: <20090922220425.GA18583@bromo.med.uc.edu> Message-ID: <84D228AF-802F-4E1A-B6CD-D200F43F16B5@gmail.com> On Sep 22, 2009, at 5:04 PM, Jack Howarth wrote: > On Tue, Sep 22, 2009 at 04:43:14PM -0500, Brian Barnes wrote: >> Regarding the discussion about gcc 4.5.0 problems on darwin and the >> back-and-forth between Toby and Jack: >> >> I have just now caught up on this thread, and I want to echo my >> support >> of pretty much everything Jack Howarth has said. I'm a long time >> user of >> gcc/gfortran for high performance scientific computing. The HPC world >> essentially revolves around two compiler suites: gcc and intel >> (although >> a few other commercial compilers still have notable followings). Both >> perform well on linux and OS X. Only one of them is free. If gcc (and >> hence, gfortran) support on OS X and macports is allowed to >> stagnate and >> die, there will be no viable free option for modern Fortran >> compilation >> on OS X. g95 is simply too slow and based on too old of a gcc >> codebase >> to warrant consideration. >> >> Fortran is not a 'dead' language or standard. There are many >> features of >> Fortran 2003 which are still being implemented in gfotran, and >> essentially all of the Fortran 2008 standard (co-arrays!) still >> needs to >> be implemented. The llvm/clang community appears to have nobody / >> very >> few people interested in implementing a Fortran front-end, and the >> gfortran maintainers are not going to branch out and start >> contributing >> to clang. Fortran is still used every day in scientific computing >> and the >> availability of a modern gcc/gfortran on OS X is a major reason I use >> macports, and, in fact, and am able to use my Mac for work at all >> (without shelling out for the Intel compilers). It is very >> important to >> the HPC community that macports/Apple keeps the latest gcc up-to- >> date and >> available! >> >> Brian >> >> p.s. ... I have patched the latest openmpi Portfile on my local >> machine, >> making the obvious changes to allow it to use gcc44 instead of >> gcc43 (the >> port seems stagnant). Compile + install went fine. >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > Heh, it's kinda late now. We just got depreciated as a primary target > today... > > http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01523.html > > and they are already queuing up to commit patches which will > break the darwin builds... > > http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01545.html > > It will be interesting to see how helpful the other non-darwin > maintainers are without the requirement to support darwin as > a primary target. > Jack Well, this has the potential to be an absolute disaster for the future of gcc and Fortran on OS X. I am surprised that the GNU SC would abandon an active part of its userbase like this. I do not like how GNU licensing changes compared to the 4.2 days are turning out for OS X users. Of course, in my perfect world Apple would put some money into hiring people for Fortran work on clang/llvm, but really, why should they care? Fortran will never make an impact on their quarterly statements unless they plan on challenging linux in the HPC world. It's not going to happen. Terribly disappointing -- if this proceeds along the path of the worst- case scenario, my next laptop may not be a Mac. Brian From bcbarnes at gmail.com Tue Sep 22 15:44:59 2009 From: bcbarnes at gmail.com (Brian Barnes) Date: Tue, 22 Sep 2009 17:44:59 -0500 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> Message-ID: <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> On Sep 22, 2009, at 5:21 PM, Toby Peterson wrote: > On Tue, Sep 22, 2009 at 15:08, Jack Howarth > wrote: >> On Tue, Sep 22, 2009 at 03:02:00PM -0700, Toby Peterson wrote: >>> On Tue, Sep 22, 2009 at 14:43, Brian Barnes >>> wrote: >>>> The llvm/clang community appears to have nobody / very few people >>>> interested >>>> in implementing a Fortran front-end >>> >>> Only one way to change that... >> >> I suspect a careful review of the gfortran progress will show >> that it only gained traction when programmers contracted to improve >> it came on board. Expecting a 'grass-roots' fortran project to >> viable is a bit unrealistic. Only if FSF gcc became unbuildable >> on darwin might a company feel the need to expend funds on such >> a project. > > In that case let's hope it becomes unbuildable sooner rather than > later. Or, perhaps let's hope that people exist with motive, means and opportunity to contribute to gcc and keep it working on OS X, and are able to do so. I would rather not lose future updates to the only fast, free Fortran compiler on OS X. I cannot comprehend why you wish for some of us to lose our tools with no fast, free replacement even vaguely in sight. Brian From howarth at bromo.med.uc.edu Tue Sep 22 15:53:38 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 22 Sep 2009 18:53:38 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> Message-ID: <20090922225338.GA18991@bromo.med.uc.edu> On Tue, Sep 22, 2009 at 05:44:59PM -0500, Brian Barnes wrote: > > Or, perhaps let's hope that people exist with motive, means and > opportunity to contribute to gcc and keep it working on OS X, and are > able to do so. I would rather not lose future updates to the only fast, > free Fortran compiler on OS X. I cannot comprehend why you wish for some > of us to lose our tools with no fast, free replacement even vaguely in > sight. > > Brian > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev Brian, That answer is easy. Toby doesn't need them. Jack From toby at macports.org Tue Sep 22 16:00:31 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 22 Sep 2009 16:00:31 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090922225338.GA18991@bromo.med.uc.edu> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <20090922225338.GA18991@bromo.med.uc.edu> Message-ID: <74c219d30909221600i10115cd0l8d77375d3aed2b17@mail.gmail.com> On Tue, Sep 22, 2009 at 15:53, Jack Howarth wrote: > On Tue, Sep 22, 2009 at 05:44:59PM -0500, Brian Barnes wrote: >> >> Or, perhaps let's hope that people exist with motive, means and >> opportunity to contribute to gcc and keep it working on OS X, and are >> able to do so. ?I would rather not lose future updates to the only fast, >> free Fortran compiler on OS X. ?I cannot comprehend why you wish for some >> of us to lose our tools with no fast, free replacement even vaguely in >> sight. >> >> Brian >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > ? That answer is easy. Toby doesn't need them. While that is true, the main thing is that this discussion belongs elsewhere. This is macports-dev - Toby From toby at macports.org Tue Sep 22 16:01:11 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 22 Sep 2009 16:01:11 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> Message-ID: <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> On Tue, Sep 22, 2009 at 15:44, Brian Barnes wrote: > On Sep 22, 2009, at 5:21 PM, Toby Peterson wrote: > >> On Tue, Sep 22, 2009 at 15:08, Jack Howarth >> wrote: >>> >>> On Tue, Sep 22, 2009 at 03:02:00PM -0700, Toby Peterson wrote: >>>> >>>> On Tue, Sep 22, 2009 at 14:43, Brian Barnes wrote: >>>>> >>>>> The llvm/clang community appears to have nobody / very few people >>>>> interested >>>>> in implementing a Fortran front-end >>>> >>>> Only one way to change that... >>> >>> ?I suspect a careful review of the gfortran progress will show >>> that it only gained traction when programmers contracted to improve >>> it came on board. Expecting a 'grass-roots' fortran project to >>> viable is a bit unrealistic. Only if FSF gcc became unbuildable >>> on darwin might a company feel the need to expend funds on such >>> a project. >> >> In that case let's hope it becomes unbuildable sooner rather than later. > > Or, perhaps let's hope that people exist with motive, means and opportunity > to contribute to gcc and keep it working on OS X, and are able to do so. ?I > would rather not lose future updates to the only fast, free Fortran compiler > on OS X. ?I cannot comprehend why you wish for some of us to lose our tools > with no fast, free replacement even vaguely in sight. gcc 4.4 will continue to work, and in the meantime development on a viable llvm-based replacement can proceed. Seems quite straightforward to me. - Toby From howarth at bromo.med.uc.edu Tue Sep 22 16:04:20 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 22 Sep 2009 19:04:20 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909221600i10115cd0l8d77375d3aed2b17@mail.gmail.com> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <20090922225338.GA18991@bromo.med.uc.edu> <74c219d30909221600i10115cd0l8d77375d3aed2b17@mail.gmail.com> Message-ID: <20090922230420.GA19006@bromo.med.uc.edu> On Tue, Sep 22, 2009 at 04:00:31PM -0700, Toby Peterson wrote: > On Tue, Sep 22, 2009 at 15:53, Jack Howarth wrote: > > On Tue, Sep 22, 2009 at 05:44:59PM -0500, Brian Barnes wrote: > >> > >> Or, perhaps let's hope that people exist with motive, means and > >> opportunity to contribute to gcc and keep it working on OS X, and are > >> able to do so. ?I would rather not lose future updates to the only fast, > >> free Fortran compiler on OS X. ?I cannot comprehend why you wish for some > >> of us to lose our tools with no fast, free replacement even vaguely in > >> sight. > >> > >> Brian > >> _______________________________________________ > >> macports-dev mailing list > >> macports-dev at lists.macosforge.org > >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > > ? That answer is easy. Toby doesn't need them. > > While that is true, the main thing is that this discussion belongs elsewhere. > > This is macports-dev > > - Toby Toby, Well it directly impacts one of your ports (regardless of how much you detest that particular package) and all other ports like octave that depend on it. Jack From toby at macports.org Tue Sep 22 16:05:50 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 22 Sep 2009 16:05:50 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090922230420.GA19006@bromo.med.uc.edu> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <20090922225338.GA18991@bromo.med.uc.edu> <74c219d30909221600i10115cd0l8d77375d3aed2b17@mail.gmail.com> <20090922230420.GA19006@bromo.med.uc.edu> Message-ID: <74c219d30909221605u44c8fa15x74e4b777f6b57308@mail.gmail.com> On Tue, Sep 22, 2009 at 16:04, Jack Howarth wrote: > On Tue, Sep 22, 2009 at 04:00:31PM -0700, Toby Peterson wrote: >> On Tue, Sep 22, 2009 at 15:53, Jack Howarth wrote: >> > On Tue, Sep 22, 2009 at 05:44:59PM -0500, Brian Barnes wrote: >> >> >> >> Or, perhaps let's hope that people exist with motive, means and >> >> opportunity to contribute to gcc and keep it working on OS X, and are >> >> able to do so. ?I would rather not lose future updates to the only fast, >> >> free Fortran compiler on OS X. ?I cannot comprehend why you wish for some >> >> of us to lose our tools with no fast, free replacement even vaguely in >> >> sight. >> >> >> >> Brian >> >> _______________________________________________ >> >> macports-dev mailing list >> >> macports-dev at lists.macosforge.org >> >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> > >> > ? That answer is easy. Toby doesn't need them. >> >> While that is true, the main thing is that this discussion belongs elsewhere. >> >> This is macports-dev >> >> - Toby > > ? Well it directly impacts one of your ports (regardless of how much you > detest that particular package) and all other ports like octave that depend > on it. To which port are you referring? - Toby From bcbarnes at gmail.com Tue Sep 22 16:41:04 2009 From: bcbarnes at gmail.com (Brian Barnes) Date: Tue, 22 Sep 2009 18:41:04 -0500 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> Message-ID: <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> On Sep 22, 2009, at 6:01 PM, Toby Peterson wrote: > On Tue, Sep 22, 2009 at 15:44, Brian Barnes > wrote: >> On Sep 22, 2009, at 5:21 PM, Toby Peterson wrote: >> >>> On Tue, Sep 22, 2009 at 15:08, Jack Howarth >> > >>> wrote: >>>> >>>> On Tue, Sep 22, 2009 at 03:02:00PM -0700, Toby Peterson wrote: >>>>> >>>>> On Tue, Sep 22, 2009 at 14:43, Brian Barnes >>>>> wrote: >>>>>> >>>>>> The llvm/clang community appears to have nobody / very few people >>>>>> interested >>>>>> in implementing a Fortran front-end >>>>> >>>>> Only one way to change that... >>>> >>>> I suspect a careful review of the gfortran progress will show >>>> that it only gained traction when programmers contracted to improve >>>> it came on board. Expecting a 'grass-roots' fortran project to >>>> viable is a bit unrealistic. Only if FSF gcc became unbuildable >>>> on darwin might a company feel the need to expend funds on such >>>> a project. >>> >>> In that case let's hope it becomes unbuildable sooner rather than >>> later. >> >> Or, perhaps let's hope that people exist with motive, means and >> opportunity >> to contribute to gcc and keep it working on OS X, and are able to >> do so. I >> would rather not lose future updates to the only fast, free Fortran >> compiler >> on OS X. I cannot comprehend why you wish for some of us to lose >> our tools >> with no fast, free replacement even vaguely in sight. > > gcc 4.4 will continue to work, and in the meantime development on a > viable llvm-based replacement can proceed. Seems quite straightforward > to me. Well, except for the fact that development of a llvm-based replacement is not proceeding, no plans exist for it to proceed, would have to be started from scratch, may not be free, and would take years... but you're still missing the point: Jack and I are pessimistic about a free, feature-complete llvm-based replacement _ever_ existing for Fortran. Besides, if gcc/gfortran 4.5 doesn't work on OS X, I lose an update to my normal toolchain, and I'm trying to get work done here! I'd also prefer to be able to use the same free compiler (gcc/ gfortran) for development on both OS X and linux (since most HPC codes will eventually be run on linux machines for data collection). The alternative, buying the Intel compiler to get work done, is just more fodder for the people that want to talk about the "Apple Tax". Brian From toby at macports.org Tue Sep 22 17:13:22 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 22 Sep 2009 17:13:22 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> Message-ID: <74c219d30909221713l279bb5e3qeb76f598c811bc97@mail.gmail.com> On Tue, Sep 22, 2009 at 16:41, Brian Barnes wrote: > On Sep 22, 2009, at 6:01 PM, Toby Peterson wrote: > >> On Tue, Sep 22, 2009 at 15:44, Brian Barnes wrote: >>> >>> On Sep 22, 2009, at 5:21 PM, Toby Peterson wrote: >>> >>>> On Tue, Sep 22, 2009 at 15:08, Jack Howarth >>>> wrote: >>>>> >>>>> On Tue, Sep 22, 2009 at 03:02:00PM -0700, Toby Peterson wrote: >>>>>> >>>>>> On Tue, Sep 22, 2009 at 14:43, Brian Barnes >>>>>> wrote: >>>>>>> >>>>>>> The llvm/clang community appears to have nobody / very few people >>>>>>> interested >>>>>>> in implementing a Fortran front-end >>>>>> >>>>>> Only one way to change that... >>>>> >>>>> ?I suspect a careful review of the gfortran progress will show >>>>> that it only gained traction when programmers contracted to improve >>>>> it came on board. Expecting a 'grass-roots' fortran project to >>>>> viable is a bit unrealistic. Only if FSF gcc became unbuildable >>>>> on darwin might a company feel the need to expend funds on such >>>>> a project. >>>> >>>> In that case let's hope it becomes unbuildable sooner rather than later. >>> >>> Or, perhaps let's hope that people exist with motive, means and >>> opportunity >>> to contribute to gcc and keep it working on OS X, and are able to do so. >>> ?I >>> would rather not lose future updates to the only fast, free Fortran >>> compiler >>> on OS X. ?I cannot comprehend why you wish for some of us to lose our >>> tools >>> with no fast, free replacement even vaguely in sight. >> >> gcc 4.4 will continue to work, and in the meantime development on a >> viable llvm-based replacement can proceed. Seems quite straightforward >> to me. > > Well, except for the fact that development of a llvm-based replacement is > not proceeding, no plans exist for it to proceed, would have to be started > from scratch, may not be free, and would take years... but you're still > missing the point: Jack and I are pessimistic about a free, feature-complete > llvm-based replacement _ever_ existing for Fortran. ?Besides, if > gcc/gfortran 4.5 doesn't work on OS X, I lose an update to my normal > toolchain, and I'm trying to get work done here! > > I'd also prefer to be able to use the same free compiler (gcc/gfortran) for > development on both OS X and linux (since most HPC codes will eventually be > run on linux machines for data collection). ?The alternative, buying the > Intel compiler to get work done, is just more fodder for the people that > want to talk about the "Apple Tax". Still failing to see relevance here. I'm sorry that the gcc devs are causing you this inconvenience, but the fact remains that gcc is not a viable option moving forward. More importantly, it's not relevant to this mailing list. - Toby From howarth at bromo.med.uc.edu Tue Sep 22 17:18:06 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 22 Sep 2009 20:18:06 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> Message-ID: <20090923001806.GA19570@bromo.med.uc.edu> On Tue, Sep 22, 2009 at 06:41:04PM -0500, Brian Barnes wrote: > > Well, except for the fact that development of a llvm-based replacement > is not proceeding, no plans exist for it to proceed, would have to be > started from scratch, may not be free, and would take years... but > you're still missing the point: Jack and I are pessimistic about a free, > feature-complete llvm-based replacement _ever_ existing for Fortran. > Besides, if gcc/gfortran 4.5 doesn't work on OS X, I lose an update to my > normal toolchain, and I'm trying to get work done here! > > I'd also prefer to be able to use the same free compiler (gcc/gfortran) > for development on both OS X and linux (since most HPC codes will > eventually be run on linux machines for data collection). The > alternative, buying the Intel compiler to get work done, is just more > fodder for the people that want to talk about the "Apple Tax". > > Brian > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev Brian, What some folks here miss is that a major chunk of the MacPorts and Fink user base are scientific or engineering users. You might find a few into the geek trick of running Gnome or KDE under MacOS X but in terms of actual productive work, those packages are marginal to what many folks are using these packaging systems for. I would also point out that Fink has seen many users migrate over due to the paucity of scientific packages in MacPorts. This might account for the blase attitude here. Jack From toby at macports.org Tue Sep 22 17:20:46 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 22 Sep 2009 17:20:46 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090923001806.GA19570@bromo.med.uc.edu> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> <20090923001806.GA19570@bromo.med.uc.edu> Message-ID: <74c219d30909221720h2b7689c5x152d327c44a255c7@mail.gmail.com> On Tue, Sep 22, 2009 at 17:18, Jack Howarth wrote: > On Tue, Sep 22, 2009 at 06:41:04PM -0500, Brian Barnes wrote: >> >> Well, except for the fact that development of a llvm-based replacement >> is not proceeding, no plans exist for it to proceed, would have to be >> started from scratch, may not be free, and would take years... but >> you're still missing the point: Jack and I are pessimistic about a free, >> feature-complete llvm-based replacement _ever_ existing for Fortran. >> Besides, if gcc/gfortran 4.5 doesn't work on OS X, I lose an update to my >> normal toolchain, and I'm trying to get work done here! >> >> I'd also prefer to be able to use the same free compiler (gcc/gfortran) >> for development on both OS X and linux (since most HPC codes will >> eventually be run on linux machines for data collection). ?The >> alternative, buying the Intel compiler to get work done, is just more >> fodder for the people that want to talk about the "Apple Tax". >> >> Brian >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > ? What some folks here miss is that a major chunk of the MacPorts > and Fink user base are scientific or engineering users. You might > find a few into the geek trick of running Gnome or KDE under MacOS X > but in terms of actual productive work, those packages are marginal > to what many folks are using these packaging systems for. I would > also point out that Fink has seen many users migrate over due to > the paucity of scientific packages in MacPorts. This might account > for the blase attitude here. I still don't see how this is relevant to this list. MacPorts can't do anything about what platforms gcc does or does not support. Anyway, please go use Fink if you find MacPorts insufficient for your needs. - Toby From howarth at bromo.med.uc.edu Tue Sep 22 17:21:42 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 22 Sep 2009 20:21:42 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909221713l279bb5e3qeb76f598c811bc97@mail.gmail.com> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> <74c219d30909221713l279bb5e3qeb76f598c811bc97@mail.gmail.com> Message-ID: <20090923002142.GA19620@bromo.med.uc.edu> On Tue, Sep 22, 2009 at 05:13:22PM -0700, Toby Peterson wrote: > > Still failing to see relevance here. I'm sorry that the gcc devs are > causing you this inconvenience, but the fact remains that gcc is not a > viable option moving forward. More importantly, it's not relevant to > this mailing list. > > - Toby > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev Toby, Perhaps it is more a reflection of the dearth of scientific packages in MacPorts. On fink, it will be felt... grep gcc44 *info | grep BuildDepends apbs-mpi.info:BuildDepends: gcc44, (%type_pkg[handler] = lammpi) lammpi-dev (>= 7.1.2-1000), (%type_pkg[handler] = openmpi) openmpi-dev (>= 1.2.5-1000), fink (>= 0.24.12) apbs.info:BuildDepends: gcc44, python26, fink (>= 0.24.12) arpack.info:BuildDepends: fink (>=0.24.12), gcc44 atlas.info:BuildDepends: gcc44 avl.info:BuildDepends: fink (>= 0.24.12), gcc44, x11-dev ccp4.info:BuildDepends: gcc44, f2c, fort77, tcltk-dev, x11-dev, xmkmf (>= 1.0.2-3), fink (>= 0.24.12) eden.info:BuildDepends: fink (>= 0.24.12), x11-dev, gsl, fftw | fftw-mpi, gsl, gcc44 fftw.info:BuildDepends: gcc44, (%type_raw[-mpi] = -mpi) openmpi-dev, fink (>= 0.27.2) fftw3.info:BuildDepends: fink (>= 0.24.12-1), gcc44, ocaml freefem++.info:BuildDepends: fink (>= 0.24.12), gcc44, x11-dev, tetex3-base, imagemagick freehelix.info:BuildDepends: gcc44, fink (>= 0.24.12-1) gopenmol.info:BuildDepends: tcltk-dev (>= 8.4.13-1), tclxml-dev, tclexpat-dev, freeglut, libjpeg, python26, gcc44, x11-dev, fink (>= 0.28-1) gpp4.info:BuildDepends: mmdb-dev (>= 1.19-12), ssm-dev (>= 0.1-12), gcc44 (>= 4.4.1-1000) harminv.info:BuildDepends: gcc44 hdf5-18-gfortran.info:BuildDepends: szip (>= 2.0-2), gcc44, fink(>= 0.24.12) hdf5-18.info:BuildDepends: szip (>= 2.0-2), gcc44, fink(>= 0.24.12) hdf5.info:BuildDepends: szip (>= 2.0-2), gcc44, fink ( >= 0.24.12) libarprec.info:BuildDepends: libqd, gcc44 | gcc43 | g95 libqd.info:BuildDepends: gcc44 | gcc43 | g95 meep.info:BuildDepends: gcc44, hdf5-18, libtool14, libiconv-dev, gmp, szip, gsl, fftw3, guile18, guile18-dev, (%type_raw[-mpi] = -mpi) openmpi-dev mmdb.info:BuildDepends: libtool14, gcc44 (>= 4.4.1-1000) modulef.info:BuildDepends: fink (>= 0.24.12), gcc44, x11-dev mosflm.info:BuildDepends: gcc44 (>= 4.4.1-1000), ccp4-dev (>= 6.1.2-1), x11, libjpeg, libgettext3-shlibs ncarg-10.6.info:BuildDepends: gcc44, x11-dev, fink (>= 0.24.12) netcdf-g.info:BuildDepends: (%type_raw[fort] = fortran)gcc44, (%type_raw[fort] = 95)g95 patchy4.info:BuildDepends: gcc44 pdb2pqr.info:BuildDepends: python, python26, gcc44 pgplot.info:BuildDepends: gcc44, libpng3, x11-dev, aquaterm-dev (>= 1.0.0-1002), fink (>= 0.24.12) qepcad.info:BuildDepends: freeglut, readline5, saclib%type_pkg[-gcc4.4], sed, flex-devel, (%type_pkg[-gcc4.4]) gcc44 qprop.info:BuildDepends: fink (>= 0.24.12), gcc44 root-pythia.info:BuildDepends: gcc44, cernlib-mclibs saclib.info:BuildDepends: fink (>= 0.24.12), (%type_pkg[-gcc4.4]) gcc44 scipy-py.info:BuildDepends: fink (>= 0.24.12), fftw3, gcc44, djbfft (>= 0.76-3), x11-dev, swig slatec.info:BuildDepends: gcc44 ssm.info:BuildDepends: mmdb-dev (>= 1.19-12), gcc44 (>= 4.4.1-1000) tinker.info:BuildDepends: gcc44 whatcheck.info:BuildDepends: fink (>= 0.24.12), gcc44 xfoil.info:BuildDepends: fink (>= 0.24.12), gcc44, x11-dev and those are only the packages in the sci subdirectory. From toby at macports.org Tue Sep 22 17:22:47 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 22 Sep 2009 17:22:47 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090923002142.GA19620@bromo.med.uc.edu> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> <74c219d30909221713l279bb5e3qeb76f598c811bc97@mail.gmail.com> <20090923002142.GA19620@bromo.med.uc.edu> Message-ID: <74c219d30909221722x2c844880ud537839edcbbeb46@mail.gmail.com> On Tue, Sep 22, 2009 at 17:21, Jack Howarth wrote: > On Tue, Sep 22, 2009 at 05:13:22PM -0700, Toby Peterson wrote: >> >> Still failing to see relevance here. I'm sorry that the gcc devs are >> causing you this inconvenience, but the fact remains that gcc is not a >> viable option moving forward. More importantly, it's not relevant to >> this mailing list. >> >> - Toby >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > Toby, > ? Perhaps it is more a reflection of the dearth of scientific > packages in MacPorts. On fink, it will be felt... > > grep gcc44 *info | grep BuildDepends > apbs-mpi.info:BuildDepends: gcc44, (%type_pkg[handler] = lammpi) lammpi-dev (>= 7.1.2-1000), (%type_pkg[handler] = openmpi) openmpi-dev (>= 1.2.5-1000), fink (>= 0.24.12) > apbs.info:BuildDepends: gcc44, python26, fink (>= 0.24.12) > arpack.info:BuildDepends: fink (>=0.24.12), gcc44 > atlas.info:BuildDepends: gcc44 > avl.info:BuildDepends: fink (>= 0.24.12), gcc44, x11-dev > ccp4.info:BuildDepends: gcc44, f2c, fort77, tcltk-dev, x11-dev, xmkmf (>= 1.0.2-3), fink (>= 0.24.12) > eden.info:BuildDepends: fink (>= 0.24.12), x11-dev, gsl, fftw | fftw-mpi, gsl, ?gcc44 > fftw.info:BuildDepends: gcc44, (%type_raw[-mpi] = -mpi) openmpi-dev, fink (>= 0.27.2) > fftw3.info:BuildDepends: ?fink (>= 0.24.12-1), gcc44, ocaml > freefem++.info:BuildDepends: fink (>= 0.24.12), gcc44, x11-dev, tetex3-base, imagemagick > freehelix.info:BuildDepends: gcc44, fink (>= 0.24.12-1) > gopenmol.info:BuildDepends: tcltk-dev (>= 8.4.13-1), tclxml-dev, tclexpat-dev, freeglut, libjpeg, python26, gcc44, x11-dev, fink (>= 0.28-1) > gpp4.info:BuildDepends: mmdb-dev (>= 1.19-12), ssm-dev (>= 0.1-12), gcc44 (>= 4.4.1-1000) > harminv.info:BuildDepends: gcc44 > hdf5-18-gfortran.info:BuildDepends: szip (>= 2.0-2), gcc44, fink(>= 0.24.12) > hdf5-18.info:BuildDepends: szip (>= 2.0-2), gcc44, fink(>= 0.24.12) > hdf5.info:BuildDepends: szip (>= 2.0-2), gcc44, fink ( >= 0.24.12) > libarprec.info:BuildDepends: libqd, gcc44 | gcc43 | g95 > libqd.info:BuildDepends: gcc44 | gcc43 | g95 > meep.info:BuildDepends: gcc44, hdf5-18, libtool14, libiconv-dev, gmp, szip, gsl, fftw3, guile18, guile18-dev, (%type_raw[-mpi] = -mpi) openmpi-dev > mmdb.info:BuildDepends: libtool14, gcc44 (>= 4.4.1-1000) > modulef.info:BuildDepends: fink (>= 0.24.12), gcc44, x11-dev > mosflm.info:BuildDepends: gcc44 (>= 4.4.1-1000), ccp4-dev (>= 6.1.2-1), x11, libjpeg, libgettext3-shlibs > ncarg-10.6.info:BuildDepends: gcc44, x11-dev, fink (>= 0.24.12) > netcdf-g.info:BuildDepends: (%type_raw[fort] = fortran)gcc44, (%type_raw[fort] = 95)g95 > patchy4.info:BuildDepends: gcc44 > pdb2pqr.info:BuildDepends: python, python26, gcc44 > pgplot.info:BuildDepends: gcc44, libpng3, x11-dev, aquaterm-dev (>= 1.0.0-1002), fink (>= 0.24.12) > qepcad.info:BuildDepends: freeglut, readline5, saclib%type_pkg[-gcc4.4], sed, flex-devel, (%type_pkg[-gcc4.4]) gcc44 > qprop.info:BuildDepends: fink (>= 0.24.12), gcc44 > root-pythia.info:BuildDepends: gcc44, cernlib-mclibs > saclib.info:BuildDepends: fink (>= 0.24.12), (%type_pkg[-gcc4.4]) gcc44 > scipy-py.info:BuildDepends: fink (>= 0.24.12), fftw3, gcc44, djbfft (>= 0.76-3), x11-dev, swig > slatec.info:BuildDepends: gcc44 > ssm.info:BuildDepends: mmdb-dev (>= 1.19-12), gcc44 (>= 4.4.1-1000) > tinker.info:BuildDepends: gcc44 > whatcheck.info:BuildDepends: fink (>= 0.24.12), gcc44 > xfoil.info:BuildDepends: fink (>= 0.24.12), gcc44, x11-dev > > and those are only the packages in the sci subdirectory. Nothing is stopping you from using Fink. - Toby From howarth at bromo.med.uc.edu Tue Sep 22 17:24:06 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 22 Sep 2009 20:24:06 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909221720h2b7689c5x152d327c44a255c7@mail.gmail.com> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> <20090923001806.GA19570@bromo.med.uc.edu> <74c219d30909221720h2b7689c5x152d327c44a255c7@mail.gmail.com> Message-ID: <20090923002406.GB19620@bromo.med.uc.edu> On Tue, Sep 22, 2009 at 05:20:46PM -0700, Toby Peterson wrote: > > Anyway, please go use Fink if you find MacPorts insufficient for your needs. > > - Toby Toby, Do you realize how idiotic that response sounds. A rational answer would a request for more scientific ports. No, you treat this like your own private little packaging club...new members and ports need not apply. Jack From toby at macports.org Tue Sep 22 17:27:52 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 22 Sep 2009 17:27:52 -0700 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090923002406.GB19620@bromo.med.uc.edu> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> <20090923001806.GA19570@bromo.med.uc.edu> <74c219d30909221720h2b7689c5x152d327c44a255c7@mail.gmail.com> <20090923002406.GB19620@bromo.med.uc.edu> Message-ID: <74c219d30909221727p6a728a44w9d2b54d4d27d4ae6@mail.gmail.com> On Tue, Sep 22, 2009 at 17:24, Jack Howarth wrote: > On Tue, Sep 22, 2009 at 05:20:46PM -0700, Toby Peterson wrote: >> >> Anyway, please go use Fink if you find MacPorts insufficient for your needs. > > ?Do you realize how idiotic that response sounds. A rational answer would a request > for more scientific ports. No, you treat this like your own private little > packaging club...new members and ports need not apply. I'm sorry, did I miss something? You've been whining about gcc support for Mac OS X, not submitting new ports. New port submissions are always welcome (in trac). - Toby From etiffany at alum.mit.edu Tue Sep 22 17:32:01 2009 From: etiffany at alum.mit.edu (Eric Tiffany) Date: Tue, 22 Sep 2009 20:32:01 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <20090923002406.GB19620@bromo.med.uc.edu> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> <20090923001806.GA19570@bromo.med.uc.edu> <74c219d30909221720h2b7689c5x152d327c44a255c7@mail.gmail.com> <20090923002406.GB19620@bromo.med.uc.edu> Message-ID: <303c45610909221732o58d9985bs84d6aea3225ee09c@mail.gmail.com> At the risk of jumping into the middle of a dog fight... I only have a peripheral interest in these issues, but I'd just like to ask: Jack: what do you want the people on this list to do? I (for one) am convinced that this is an important issue and your evidence is overwhelming, but I'm not clear on what course of action you advocate. ET On Tue, Sep 22, 2009 at 8:24 PM, Jack Howarth wrote: > On Tue, Sep 22, 2009 at 05:20:46PM -0700, Toby Peterson wrote: > > > > Anyway, please go use Fink if you find MacPorts insufficient for your > needs. > > > > - Toby > > Toby, > Do you realize how idiotic that response sounds. A rational answer would a > request > for more scientific ports. No, you treat this like your own private little > packaging club...new members and ports need not apply. > Jack > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at mirell.org Tue Sep 22 17:33:35 2009 From: mark at mirell.org (Mark A. Miller) Date: Tue, 22 Sep 2009 19:33:35 -0500 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909221727p6a728a44w9d2b54d4d27d4ae6@mail.gmail.com> References: <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> <20090923001806.GA19570@bromo.med.uc.edu> <74c219d30909221720h2b7689c5x152d327c44a255c7@mail.gmail.com> <20090923002406.GB19620@bromo.med.uc.edu> <74c219d30909221727p6a728a44w9d2b54d4d27d4ae6@mail.gmail.com> Message-ID: <31014a580909221733k69688c2fx2233be97939315dc@mail.gmail.com> On Tue, Sep 22, 2009 at 7:27 PM, Toby Peterson wrote: > On Tue, Sep 22, 2009 at 17:24, Jack Howarth > wrote: > > On Tue, Sep 22, 2009 at 05:20:46PM -0700, Toby Peterson wrote: > >> > >> Anyway, please go use Fink if you find MacPorts insufficient for your > needs. > > > > Do you realize how idiotic that response sounds. A rational answer would > a request > > for more scientific ports. No, you treat this like your own private > little > > packaging club...new members and ports need not apply. > > I'm sorry, did I miss something? You've been whining about gcc support > for Mac OS X, not submitting new ports. New port submissions are > always welcome (in trac). > > - Toby Actually, while I see the merits of both sides, while loss of new Fortran support is apparently an issue in the scientific community, it's also a GCC issue rather than MacPorts-specific, and probably doesn't belong on this particular mailing list. However, what's far more annoying is the flame bait war that this has devolved to. Initially this thread was intelligent, if perhaps irrelevant discussion. Please stop. Thanks. -- Mark A. Miller mark at mirell.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From howarth at bromo.med.uc.edu Tue Sep 22 17:35:32 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 22 Sep 2009 20:35:32 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <74c219d30909221727p6a728a44w9d2b54d4d27d4ae6@mail.gmail.com> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> <20090923001806.GA19570@bromo.med.uc.edu> <74c219d30909221720h2b7689c5x152d327c44a255c7@mail.gmail.com> <20090923002406.GB19620@bromo.med.uc.edu> <74c219d30909221727p6a728a44w9d2b54d4d27d4ae6@mail.gmail.com> Message-ID: <20090923003532.GA19761@bromo.med.uc.edu> On Tue, Sep 22, 2009 at 05:27:52PM -0700, Toby Peterson wrote: > On Tue, Sep 22, 2009 at 17:24, Jack Howarth wrote: > > On Tue, Sep 22, 2009 at 05:20:46PM -0700, Toby Peterson wrote: > >> > >> Anyway, please go use Fink if you find MacPorts insufficient for your needs. > > > > ?Do you realize how idiotic that response sounds. A rational answer would a request > > for more scientific ports. No, you treat this like your own private little > > packaging club...new members and ports need not apply. > > I'm sorry, did I miss something? You've been whining about gcc support > for Mac OS X, not submitting new ports. New port submissions are > always welcome (in trac). > > - Toby Toby, I have a slew of new tickets. The point is that scientific codes often require a fortran compiler. In any case, everyone is overreacting. The wheels aren't likely to come off of gcc 4.5 before release. I actually fixed a P1 blocker last night. It won't be easy but we will likely manage as there still enough other FSF gcc developers who have MacBooks that won't want to lose the ability to work on them with FSF gcc. Jack From howarth at bromo.med.uc.edu Tue Sep 22 17:43:32 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Tue, 22 Sep 2009 20:43:32 -0400 Subject: darwin may lose primary target status on FSF gcc In-Reply-To: <303c45610909221732o58d9985bs84d6aea3225ee09c@mail.gmail.com> References: <74c219d30909221502u669d7815xf347959fe0a44164@mail.gmail.com> <20090922220824.GB18583@bromo.med.uc.edu> <74c219d30909221521p35f4fd33wf7c786e00a81f608@mail.gmail.com> <68062F5F-9726-447A-B11F-9BF3375A5D94@gmail.com> <74c219d30909221601y4aeeb77fm7a9887470cb51a9e@mail.gmail.com> <1A052193-82F2-43EA-B123-2136ED7B0439@gmail.com> <20090923001806.GA19570@bromo.med.uc.edu> <74c219d30909221720h2b7689c5x152d327c44a255c7@mail.gmail.com> <20090923002406.GB19620@bromo.med.uc.edu> <303c45610909221732o58d9985bs84d6aea3225ee09c@mail.gmail.com> Message-ID: <20090923004332.GB19761@bromo.med.uc.edu> On Tue, Sep 22, 2009 at 08:32:01PM -0400, Eric Tiffany wrote: > At the risk of jumping into the middle of a dog fight... I only have a > peripheral interest in these issues, but I'd just like to ask: > > Jack: what do you want the people on this list to do? I (for one) am > convinced that this is an important issue and your evidence is overwhelming, > but I'm not clear on what course of action you advocate. > > > ET > If anyone feels up to it that can try to help with the FSF gcc development. You can commit patches of up to 20 lines without paperwork which often is plenty to fix bugs with. I just fixed the P1 block on *-*-darwin* last night... http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01463.html The biggest issue left to be addressed is how FSF gcc and darwin handle libgcc. Apple wanted to standardize it so we ended up with libgcc-10.4 and libgcc-10.5 which define which symbols out of libgcc_s are visibie. This is causing us problems since over time new symbols have been added to libgcc_s and they aren't visible. We are working with the Darwin maintainers from Apple to try to find the best solution around that. If we fix that, I actually think we are in pretty good shape for awhile. Our testsuite results compare very well with any other FSF gcc target. Jack From vince at macports.org Wed Sep 23 04:04:00 2009 From: vince at macports.org (vincent habchi) Date: Wed, 23 Sep 2009 13:04:00 +0200 Subject: wxPython-devel fork? Message-ID: <09CA7862-FEB5-4DC2-ACAB-1B42921AB7A4@macports.org> Hi, I have ported the Grass (v. 6.4) GIS app to MacPorts in my private tree. However, Grass relies on Wxpython. In order to get a universal build, I had to use the svn version of Wxpython, the only one compatible with the newest wxWidgets 2.9.0, which features the osx_cocoa 32/64-build. The standard wxWidgets-devel Portfile, while up to date, lacks the universal/cocoa option. I have a private version of the port called wxWidgets29, that serves as a foundation for both my private "py26- wxpython-devel" port and Grass. In order to commit Grass and py26-wxpython-devel, is it reasonable to fork wxwindows-devel in wxwindows29 or shall I modify the wxwindows- devel portfile? I proposed the patched version to the owners, but got no response. I feel wxwindows-devel should follow wxWindows development (even into 3.0) while wxwindows29 could be used only for the 2.9 unstable branch. Opinion? Vincent From ryandesign at macports.org Wed Sep 23 11:12:39 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 23 Sep 2009 13:12:39 -0500 Subject: [58127] trunk/dports/databases/couchdb-devel/Portfile In-Reply-To: <20090922184450.7D5F7280421A@beta.macosforge.org> References: <20090922184450.7D5F7280421A@beta.macosforge.org> Message-ID: <24B125B3-B003-4970-ACC3-ED503A1CB6FA@macports.org> On Sep 22, 2009, at 13:44, jwa at macports.org wrote: > Revision: 58127 > http://trac.macports.org/changeset/58127 > Author: jwa at macports.org > Date: 2009-09-22 11:44:45 -0700 (Tue, 22 Sep 2009) > Log Message: > ----------- > version bump to r817403, changing svn spec to 1.8.0 This also undid r57378. I redid it in r58177. > Modified: trunk/dports/databases/couchdb-devel/Portfile > =================================================================== > --- trunk/dports/databases/couchdb-devel/Portfile 2009-09-22 > 17:29:57 UTC (rev 58126) > +++ trunk/dports/databases/couchdb-devel/Portfile 2009-09-22 > 18:44:45 UTC (rev 58127) > @@ -3,8 +3,8 @@ > PortSystem 1.0 > > name couchdb-devel > -svn.revision 799093 > -version 0.10.0r${svn.revision} > +svn.tag 817403 > +version 0.10.0r${svn.tag} > > categories databases > platforms darwin > @@ -71,5 +71,5 @@ > > livecheck.type regex > livecheck.url http://svn.apache.org/viewvc/couchdb/trunk/src/couchdb/ > -livecheck.version ${svn.revision} > +livecheck.version ${svn.tag} > livecheck.regex (\[0-9\]+) From ryandesign at macports.org Wed Sep 23 15:41:51 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 23 Sep 2009 17:41:51 -0500 Subject: [MacPorts] #21544: libsdl 1.2.14 checksum failed In-Reply-To: <057.c08196d2257804b6d586a1380cfa4108@macports.org> References: <048.7fd61d18a0d9448651412fed336e5288@macports.org> <057.c08196d2257804b6d586a1380cfa4108@macports.org> Message-ID: On Sep 23, 2009, at 13:29, MacPorts wrote: > #21544: libsdl 1.2.14 checksum failed > --------------------------- > +------------------------------------------------ > Reporter: senz@? | Owner: ryandesign@? > Type: defect | Status: closed > Priority: Normal | Milestone: > Component: ports | Version: 1.8.0 > Resolution: fixed | Keywords: SDL 1.2.14 checksum > Port: libsdl | > --------------------------- > +------------------------------------------------ > > Comment(by toby@?): > > Reverted r58178 in r58179. A completely broken libsdl does not do > any good > - upgrading daily is an inconvenience, but working is better than not > working. My concern is that we are now advertising in the libsdl port that we provide version 1.2.14, when no such version appears to have been released yet. The libsdl homepage shows 1.2.13 is the current version, and the fact that you had to download the 1.2.14 distfile from a directory called "tmp" instead of the usual "release" directory, and the fact that the distfile has already changed twice in two days, points to the fact that this is not a released version and should therefore not be provided by the libsdl port, which is supposed to be for the latest released version. From toby at macports.org Wed Sep 23 16:13:28 2009 From: toby at macports.org (Toby Peterson) Date: Wed, 23 Sep 2009 16:13:28 -0700 Subject: [MacPorts] #21544: libsdl 1.2.14 checksum failed In-Reply-To: References: <048.7fd61d18a0d9448651412fed336e5288@macports.org> <057.c08196d2257804b6d586a1380cfa4108@macports.org> Message-ID: <74c219d30909231613m615411bcr4b2985bee603c8a3@mail.gmail.com> On Wed, Sep 23, 2009 at 15:41, Ryan Schmidt wrote: > > On Sep 23, 2009, at 13:29, MacPorts wrote: > >> #21544: libsdl 1.2.14 checksum failed >> >> ---------------------------+------------------------------------------------ >> ?Reporter: ?senz@? ? ? ? ?| ? ? ? Owner: ?ryandesign@? >> ? ? Type: ?defect ? ? ? ?| ? ? ?Status: ?closed >> ?Priority: ?Normal ? ? ? ?| ? Milestone: >> Component: ?ports ? ? ? ? | ? ? Version: ?1.8.0 >> Resolution: ?fixed ? ? ? ? | ? ?Keywords: ?SDL 1.2.14 checksum >> ? ? Port: ?libsdl ? ? ? ?| >> >> ---------------------------+------------------------------------------------ >> >> Comment(by toby@?): >> >> Reverted r58178 in r58179. A completely broken libsdl does not do any good >> - upgrading daily is an inconvenience, but working is better than not >> working. > > My concern is that we are now advertising in the libsdl port that we provide > version 1.2.14, when no such version appears to have been released yet. The > libsdl homepage shows 1.2.13 is the current version, and the fact that you > had to download the 1.2.14 distfile from a directory called "tmp" instead of > the usual "release" directory, and the fact that the distfile has already > changed twice in two days, points to the fact that this is not a released > version and should therefore not be provided by the libsdl port, which is > supposed to be for the latest released version. We also advertise it as working... I think that's the more important part. :-) It's this or keep a ticket open that has 70+ people CC'd on it... - Toby From smparkes at smparkes.net Wed Sep 23 17:13:37 2009 From: smparkes at smparkes.net (Steven Parkes) Date: Wed, 23 Sep 2009 17:13:37 -0700 Subject: libxslt 1.1.25 issue (causes kdelibs3 install to fail) Message-ID: <3B5C5745-85D4-4EE7-9C74-1F298144048E@smparkes.net> libxslt-1.1.25 has a deadlocking issue that causes an install of kdelibs3 to fail. There's a deadlock in the code that causes the meinproc binary to hang. The issue was fixed in their git repo on Sunday the 20th. Haven't heard when they're going to do a release, yet. 1.1.24 doesn't have this issue. Causes kdelibs3 install to hang when trying to generate docs. Other apps that use libxslt in the same way would have the same issue (if they exist). From ryandesign at macports.org Wed Sep 23 21:22:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 23 Sep 2009 23:22:42 -0500 Subject: [MacPorts] #21437: The MAMP howto doesn't match the sample phpMyAdmin config file In-Reply-To: References: <052.822b01b093ac429a1a186ce38b4d504f@macports.org> <061.5e1ddb1776a10cdc39df43b60f5ba0db@macports.org> <389B9371-B6FE-498C-B420-036B889E80EE@mac.com> <966588EB-1831-4CCB-8194-CDFF93C71B4D@mac.com> Message-ID: <040E93A1-CE3A-419C-A859-D6B19756587D@macports.org> On Sep 23, 2009, at 23:09, Steve Meether wrote: > I made no changes to the php.ini file, so no I did not configure the > socket. Ok, then that was the problem. See also: http://trac.macports.org/ticket/21250 > Also, the default value for "connect_type" in the config.inc.php > file is "tcp". So it sounds like 127.0.0.1 should have been set for > "host" anyway...? I understand that the default connect_type in phpMyAdmin's config file is "tcp", but when you request a TCP connection to the hostname "localhost", MySQL will connect on a socket. This is described in the MySQL documentation here: http://dev.mysql.com/doc/refman/5.1/en/connecting.html "On Unix, MySQL programs treat the host name localhost specially, in a way that is likely different from what you expect compared to other network-based programs. For connections to localhost, MySQL programs attempt to connect to the local server by using a Unix socket file. [...] To ensure that the client makes a TCP/IP connection to the local server, use --host or -h to specify a host name value of 127.0.0.1, or the IP address or name of the local server." From ryandesign at macports.org Thu Sep 24 09:24:52 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 24 Sep 2009 11:24:52 -0500 Subject: [58218] trunk/dports/lang/coq In-Reply-To: <20090924104059.5C5E0282724C@beta.macosforge.org> References: <20090924104059.5C5E0282724C@beta.macosforge.org> Message-ID: On Sep 24, 2009, at 05:40, jann at macports.org wrote: > Revision: 58218 > http://trac.macports.org/changeset/58218 > Author: jann at macports.org > Date: 2009-09-24 03:40:54 -0700 (Thu, 24 Sep 2009) > Log Message: > ----------- > Version update from ticket #21415 > > Modified Paths: > -------------- > trunk/dports/lang/coq/Portfile > depends_lib bin:ocamlc:ocaml port:camlp5 > +variant doc description {Build documentation} { > + depends_build port:texlive > + depends_build port:hevea > + depends_build port:netpbm These depends_build's overwrite each other, leaving you with just netpbm as a build dependency, which is probably not what you wanted. > +variant coqide description {Install CoqIDE} { > + depends_lib port:lablgtk2 This overwrites the port's global depends_lib, deleting the dependencies on ocaml and camlp5, which is probably not what you wanted. I fixed both problems in r58228. From vince at macports.org Thu Sep 24 09:51:17 2009 From: vince at macports.org (vincent habchi) Date: Thu, 24 Sep 2009 18:51:17 +0200 Subject: Portfile redaction question Message-ID: <012237E4-3F89-4215-93E8-3DA246F37C87@macports.org> Hi there, for an upcoming port (qgis), I need to tweak the build process. The building process unfolds this way: extract, create a build directory at the base of the extract tree, cd into it and call "cmake ..". So I wrote this: post-extract { system "cd ${worksrcpath} && mkdir build" worksrcdir ${worksrcdir}/build } It works like a charm for a standard monolithic install (port install). But if I do it in two phases (e.g. port configure then port build), it fails, because the post-extract block is not executed twice, so ${worksrcdir} value is wrong during port build. Is there any elegant way to solve this? Thanks, Vincent From ryandesign at macports.org Thu Sep 24 10:30:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 24 Sep 2009 12:30:24 -0500 Subject: [58213] trunk/dports/devel In-Reply-To: <20090924071203.550EE2824413@beta.macosforge.org> References: <20090924071203.550EE2824413@beta.macosforge.org> Message-ID: <449E51C2-3ED0-43D1-966E-69CBAF016501@macports.org> On Sep 24, 2009, at 02:12, afb at macports.org wrote: > Revision: 58213 > http://trac.macports.org/changeset/58213 > Author: afb at macports.org > Date: 2009-09-24 00:11:55 -0700 (Thu, 24 Sep 2009) > Log Message: > ----------- > new port: xapian-bindings (#17233) > - updated to match xapian-core > - fixed language bindings (-tcl) > > Added Paths: > ----------- > trunk/dports/devel/xapian-bindings/ > trunk/dports/devel/xapian-bindings/Portfile > > Added: trunk/dports/devel/xapian-bindings/Portfile > =================================================================== > --- trunk/dports/devel/xapian-bindings/ > Portfile (rev 0) > +++ trunk/dports/devel/xapian-bindings/Portfile 2009-09-24 07:11:55 > UTC (rev 58213) > @@ -0,0 +1,45 @@ > +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: > nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 > +# $Id$ > +PortSystem 1.0 > +name xapian-bindings > +version 1.0.15 > +categories devel > +maintainers m at loonsoft.com > +description Xapian bindings > +long_description Xapian is a highly adaptable toolkit which > allows developers to easily add advanced indexing and search > facilities to their own applications. It supports the Probabilistic > Information Retrieval model and also supports a rich set of boolean > query operators. > + > +homepage http://people.xapian.org > +platforms darwin > +master_sites http://oligarchy.co.uk/xapian/${version} > + > +checksums md5 d365969f5ba7fa99d369ef479862c4fe \ > + sha1 34ed2c71df43df39c3a8c56beb1c6bdd2cf39a17 \ > + rmd160 6e8214e2a629662c3dcfc3b469c5159c90ecfddc > +depends_lib port:xapian-core > + > +configure.args-append --without-python --without-csharp --without- > java --without-tcl --without-php --without-ruby > +variant ruby description {builds ruby bindings} { > + configure.args-delete --without-ruby > + configure.args-append --with-ruby > + depends_lib-append port:ruby > + } > +variant php description {builds php bindings} { > + configure.args-delete --without-php > + configure.args-append --with-php > + depends_lib-append port:php5 > + } > +variant python description {builds python bindings} { > + configure.args-delete --without-python > + configure.args-append --with-python > + configure.env-append PYTHON=${prefix}/bin/ > python2.5 > + depends_lib-append port:python25 > + } > +variant java description {builds java bindings} { > + configure.args-delete --without-java > + configure.args-append --with-java > + } > +default_variants +ruby > + > +post-destroot { > + delete "${destroot}${prefix}/share/doc/xapian-bindings/ruby/ > rdocs" > +} If I try to install the port without the ruby variant it fails: $ sudo port install xapian-bindings -ruby ---> Computing dependencies for xapian-bindings ---> Fetching xapian-bindings ---> Attempting to fetch xapian-bindings-1.0.15.tar.gz from http://oligarchy.co.uk/xapian/1.0.15 ---> Verifying checksum(s) for xapian-bindings ---> Extracting xapian-bindings ---> Configuring xapian-bindings ---> Building xapian-bindings ---> Staging xapian-bindings into destroot Error: Target org.macports.destroot returned: no such file or directory Error: Status 1 encountered during processing. $ I imagine you want that post-destroot phase to be inside the ruby variant. If I fix that, the port then fails to install any files at all: $ sudo port install xapian-bindings -ruby ---> Computing dependencies for xapian-bindings ---> Fetching xapian-bindings ---> Verifying checksum(s) for xapian-bindings ---> Extracting xapian-bindings ---> Configuring xapian-bindings ---> Building xapian-bindings ---> Staging xapian-bindings into destroot ---> Installing xapian-bindings @1.0.15_0+universal couldn't change working directory to "/opt/local/var/macports/build/ _Users_rschmidt_macports_dports_devel_xapian-bindings/work/destroot": no such file or directory ---> Activating xapian-bindings @1.0.15_0+universal Error: Target org.macports.activate returned: Image error: Source file /opt/local/var/macports/software/xapian-bindings/ 1.0.15_0+universal does not appear to exist (cannot lstat it). Unable to activate port xapian-bindings. Error: Status 1 encountered during processing. I guess you intend for the user to always select at least one variant? If so, please write that into the portfile so that it is not possible to attempt to install it with no variants selected. Why is the ruby variant a default variant? This makes it difficult for a user to deselect. Does ruby have some special significance for xapian? You may want to employ a strategy like the one in the pdftk port, where it auto-selects a variant for you if you have not already selected another variant. Or you may want to split this into one port per language binding. That would allow other ports that need these bindings to actually declare dependencies on them. (You cannot declare dependencies on variants; see ticket #126.) In the python variant, shouldn't we be using at least 2.6? I've seen several commits lately moving ports off 2.5 and onto 2.6 so it seems wrong to commit a new port using 2.5 now. In the php variant, I already corrected it to allow php5-devel or php52 to satisfy the php dependency. You may want to obfuscate your email address in the maintainer line so you don't get as much spam. From toby at macports.org Thu Sep 24 10:34:15 2009 From: toby at macports.org (Toby Peterson) Date: Thu, 24 Sep 2009 10:34:15 -0700 Subject: Portfile redaction question In-Reply-To: <012237E4-3F89-4215-93E8-3DA246F37C87@macports.org> References: <012237E4-3F89-4215-93E8-3DA246F37C87@macports.org> Message-ID: <74c219d30909241034p634ecd81gea0cf3df7a7cef5d@mail.gmail.com> On Thu, Sep 24, 2009 at 09:51, vincent habchi wrote: > Hi there, > > for an upcoming port (qgis), I need to tweak the build process. The building > process unfolds this way: extract, create a build directory at the base of > the extract tree, cd into it and call "cmake ..". > > So I wrote this: > > post-extract ? ?{ > ? ? ? ?system ? ? ? ? ?"cd ${worksrcpath} && mkdir build" > ? ? ? ?worksrcdir ? ? ?${worksrcdir}/build > } > > It works like a charm for a standard monolithic install (port install). But > if I do it in two phases (e.g. port configure then port build), it fails, > because the post-extract block is not executed twice, so ${worksrcdir} value > is wrong during port build. > > Is there any elegant way to solve this? Probably want to do something like: configure.dir ${worksrcpath}/build instead of setting worksrcdir - Toby From vince at macports.org Thu Sep 24 10:55:52 2009 From: vince at macports.org (vincent habchi) Date: Thu, 24 Sep 2009 19:55:52 +0200 Subject: Portfile redaction question In-Reply-To: <74c219d30909241034p634ecd81gea0cf3df7a7cef5d@mail.gmail.com> References: <012237E4-3F89-4215-93E8-3DA246F37C87@macports.org> <74c219d30909241034p634ecd81gea0cf3df7a7cef5d@mail.gmail.com> Message-ID: Le 24 sept. 2009 ? 19:34, Toby Peterson a ?crit : > Probably want to do something like: > configure.dir ${worksrcpath}/build Nice guess, but I need also the process to go into ${worksrcpath}/ build to build and install the app. build.dir and destroot.dir work? Vincent From afb at macports.org Thu Sep 24 10:56:42 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 24 Sep 2009 19:56:42 +0200 Subject: [58213] trunk/dports/devel In-Reply-To: <449E51C2-3ED0-43D1-966E-69CBAF016501@macports.org> References: <20090924071203.550EE2824413@beta.macosforge.org> <449E51C2-3ED0-43D1-966E-69CBAF016501@macports.org> Message-ID: Ryan Schmidt wrote: > I imagine you want that post-destroot phase to be inside the ruby > variant. Or something, now fixed in r58233. > In the python variant, shouldn't we be using at least 2.6? I've > seen several commits lately moving ports off 2.5 and onto 2.6 so it > seems wrong to commit a new port using 2.5 now. I'll leave the rest of the comments to the port maintainer, but I guess it was using the other python25 primarly from having the port submission stuck in the queue for so long ? The Tcl variant wasn't finding TCLINC, so I just removed it... --anders From toby at macports.org Thu Sep 24 11:04:30 2009 From: toby at macports.org (Toby Peterson) Date: Thu, 24 Sep 2009 11:04:30 -0700 Subject: Portfile redaction question In-Reply-To: References: <012237E4-3F89-4215-93E8-3DA246F37C87@macports.org> <74c219d30909241034p634ecd81gea0cf3df7a7cef5d@mail.gmail.com> Message-ID: <74c219d30909241104l54eb9ebdiaf32e72b78d993ff@mail.gmail.com> On Thu, Sep 24, 2009 at 10:55, vincent habchi wrote: > Le 24 sept. 2009 ? 19:34, Toby Peterson a ?crit : > >> Probably want to do something like: >> configure.dir ${worksrcpath}/build > > Nice guess, but I need also the process to go into ${worksrcpath}/build to > build and install the app. build.dir and destroot.dir work? Yes From ryandesign at macports.org Thu Sep 24 13:36:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 24 Sep 2009 15:36:41 -0500 Subject: Portfile redaction question In-Reply-To: <74c219d30909241104l54eb9ebdiaf32e72b78d993ff@mail.gmail.com> References: <012237E4-3F89-4215-93E8-3DA246F37C87@macports.org> <74c219d30909241034p634ecd81gea0cf3df7a7cef5d@mail.gmail.com> <74c219d30909241104l54eb9ebdiaf32e72b78d993ff@mail.gmail.com> Message-ID: <77DAA52C-81EF-438C-A404-F19BB6A1B174@macports.org> On Sep 24, 2009, at 13:04, Toby Peterson wrote: > On Thu, Sep 24, 2009 at 10:55, vincent habchi > wrote: >> Le 24 sept. 2009 ? 19:34, Toby Peterson a ?crit : >> >>> Probably want to do something like: >>> configure.dir ${worksrcpath}/build >> >> Nice guess, but I need also the process to go into ${worksrcpath}/ >> build to >> build and install the app. build.dir and destroot.dir work? > > Yes You only need to set configure.dir and build.dir. The default for destroot.dir is the value of build.dir so you don't need to set that. From smparkes at smparkes.net Fri Sep 25 08:19:24 2009 From: smparkes at smparkes.net (Steven Parkes) Date: Fri, 25 Sep 2009 08:19:24 -0700 Subject: libxslt 1.1.25 issue (causes kdelibs3 install to fail) In-Reply-To: <3B5C5745-85D4-4EE7-9C74-1F298144048E@smparkes.net> References: <3B5C5745-85D4-4EE7-9C74-1F298144048E@smparkes.net> Message-ID: <108950D3-E134-43E6-AC86-BB6557960EAB@smparkes.net> On Sep 23, 2009, at Sep 23,5:13 PM , Steven Parkes wrote: > libxslt-1.1.25 has a deadlocking issue that causes an install of > kdelibs3 to fail. There's a deadlock in the code that causes the > meinproc binary to hang. The issue was fixed in their git repo on > Sunday the 20th. Haven't heard when they're going to do a release, > yet. 1.1.24 doesn't have this issue. > > Causes kdelibs3 install to hang when trying to generate docs. Other > apps that use libxslt in the same way would have the same issue (if > they exist). Upstream has released 1.1.26, so if whoever handles the libxslt port can get it in, it should resolve the kdelibs3 issue. From ryandesign at macports.org Fri Sep 25 09:56:06 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 25 Sep 2009 11:56:06 -0500 Subject: libxslt 1.1.25 issue (causes kdelibs3 install to fail) In-Reply-To: <108950D3-E134-43E6-AC86-BB6557960EAB@smparkes.net> References: <3B5C5745-85D4-4EE7-9C74-1F298144048E@smparkes.net> <108950D3-E134-43E6-AC86-BB6557960EAB@smparkes.net> Message-ID: On Sep 25, 2009, at 10:19, Steven Parkes wrote: > On Sep 23, 2009, at Sep 23,5:13 PM , Steven Parkes wrote: > >> libxslt-1.1.25 has a deadlocking issue that causes an install of >> kdelibs3 to fail. There's a deadlock in the code that causes the >> meinproc binary to hang. The issue was fixed in their git repo on >> Sunday the 20th. Haven't heard when they're going to do a release, >> yet. 1.1.24 doesn't have this issue. >> >> Causes kdelibs3 install to hang when trying to generate docs. Other >> apps that use libxslt in the same way would have the same issue (if >> they exist). > > Upstream has released 1.1.26, so if whoever handles the libxslt port > can get it in, it should resolve the kdelibs3 issue. It was openmaintainer so I updated it just now (in r58304). Please wait 60 minutes from the time of this message, then "sudo port sync", and it should show up in "port outdated". From davis at guydavis.ca Fri Sep 25 15:03:08 2009 From: davis at guydavis.ca (Guy Davis) Date: Fri, 25 Sep 2009 16:03:08 -0600 Subject: Help on startupitem.executable for Jetty server? Message-ID: <2b7747b70909251503g473274e6ne2dd5ba0f9cc59ca@mail.gmail.com> Hi, I'm trying to update the Jetty portfile to the latest release and am trying to use the 'startupitem.executable' directive to have it start automatically on boot. I've read through the MacPorts guide, but am not having much luck so far. I have Jetty 6.1.21 installing into /opt/local/share/java/jetty. It can be started manually with a 'java -jar start.jar' in that directory. However, my attempt at startupitem seems wrong: startupitem.create yes startupitem.logfile ${prefix}/share/java/jetty/logs/daemon.log" startupitem.logevents yes startupitem.executable java -jar ${prefix}/share/java/jetty/start.jar When I install this dev port and run: sudo launchctl load -w /Library/LaunchDaemons/org.macports.jetty.plist then: sudo launchctl start jetty I get: launchctl start error: No such proces Anyhow, I'd really appreciate some tips on how to properly configure Jetty to launch automatically. Thanks in advance, Guy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 1560 bytes Desc: not available URL: From mark.duling at gmail.com Fri Sep 25 17:40:28 2009 From: mark.duling at gmail.com (Mark Duling) Date: Fri, 25 Sep 2009 17:40:28 -0700 Subject: Help on startupitem.executable for Jetty server? In-Reply-To: <2b7747b70909251503g473274e6ne2dd5ba0f9cc59ca@mail.gmail.com> References: <2b7747b70909251503g473274e6ne2dd5ba0f9cc59ca@mail.gmail.com> Message-ID: <99f24e390909251740h5668fdcdsfa2de9acbb9c320c@mail.gmail.com> Hello Guy, There may be a path problem. Always check the system.log for this type of thing. 'tail /var/log/system.log'. I pasted your startupitem information into the current jetty portfile and I saw this in the system.log after running launchctl: Unable to access jarfile /opt/local/share/java/jetty/start.jar Unless you are updating the path in your updated portfile, I see the path as /opt/local/share/java/jetty-xxx/start.jar. Mark On Fri, Sep 25, 2009 at 3:03 PM, Guy Davis wrote: > Hi, > > I'm trying to update the Jetty portfile to the latest release and am trying > to use the 'startupitem.executable' directive to have it start automatically > on boot. I've read through the MacPorts guide, but am not having much luck > so far. I have Jetty 6.1.21 installing into /opt/local/share/java/jetty. > It can be started manually with a 'java -jar start.jar' in that directory. > > However, my attempt at startupitem seems wrong: > > startupitem.create yes > startupitem.logfile ${prefix}/share/java/jetty/logs/daemon.log" > startupitem.logevents yes > startupitem.executable java -jar ${prefix}/share/java/jetty/start.jar > > When I install this dev port and run: > sudo launchctl load -w /Library/LaunchDaemons/org.macports.jetty.plist > then: > sudo launchctl start jetty > I get: launchctl start error: No such proces > > Anyhow, I'd really appreciate some tips on how to properly configure Jetty > to launch automatically. > > Thanks in advance, > Guy > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davis at guydavis.ca Fri Sep 25 20:58:30 2009 From: davis at guydavis.ca (Guy Davis) Date: Fri, 25 Sep 2009 21:58:30 -0600 Subject: Help on startupitem.executable for Jetty server? In-Reply-To: <99f24e390909251740h5668fdcdsfa2de9acbb9c320c@mail.gmail.com> References: <2b7747b70909251503g473274e6ne2dd5ba0f9cc59ca@mail.gmail.com> <99f24e390909251740h5668fdcdsfa2de9acbb9c320c@mail.gmail.com> Message-ID: <2b7747b70909252058rc2c039fw63864fb690bf119@mail.gmail.com> Hi Mark, I've attached my latest attempt as a full Portfile. I've changed the install location to /opt/local/share/java/jetty without the version on the end. (I may have to put this back to handle upgrades that don't overwrite local config?). I've switched to trying the 'Script' instead of the 'Excecutable' StartupItem approach, however I'm having trouble generating the PID that launchctl seems to need. Thanks, Guy On Fri, Sep 25, 2009 at 6:40 PM, Mark Duling wrote: > Hello Guy, > There may be a path problem. Always check the system.log for this type of > thing. 'tail /var/log/system.log'. I pasted your startupitem information > into the current jetty portfile and I saw this in the system.log after > running launchctl: > > Unable to access jarfile /opt/local/share/java/jetty/start.jar > > Unless you are updating the path in your updated portfile, I see the path > as /opt/local/share/java/jetty-xxx/start.jar. > > Mark > > > On Fri, Sep 25, 2009 at 3:03 PM, Guy Davis wrote: > >> Hi, >> >> I'm trying to update the Jetty portfile to the latest release and am >> trying to use the 'startupitem.executable' directive to have it start >> automatically on boot. I've read through the MacPorts guide, but am not >> having much luck so far. I have Jetty 6.1.21 installing into >> /opt/local/share/java/jetty. It can be started manually with a 'java -jar >> start.jar' in that directory. >> >> However, my attempt at startupitem seems wrong: >> >> startupitem.create yes >> startupitem.logfile ${prefix}/share/java/jetty/logs/daemon.log" >> startupitem.logevents yes >> startupitem.executable java -jar ${prefix}/share/java/jetty/start.jar >> >> When I install this dev port and run: >> sudo launchctl load -w /Library/LaunchDaemons/org.macports.jetty.plist >> then: >> sudo launchctl start jetty >> I get: launchctl start error: No such proces >> >> Anyhow, I'd really appreciate some tips on how to properly configure Jetty >> to launch automatically. >> >> Thanks in advance, >> Guy >> >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 1802 bytes Desc: not available URL: From akitada at macports.org Sat Sep 26 02:53:50 2009 From: akitada at macports.org (Akira Kitada) Date: Sat, 26 Sep 2009 18:53:50 +0900 Subject: MySQL port name confusion Message-ID: <90bb445a0909260253w6a6c300dka248483efc4ab8c9@mail.gmail.com> Hi, I realized mysql5 and mysql5-server ports are still pointing to 5.0.x, ex-GA release of MySQL and need to install mysql5-devel and mysql5-server-devel for 5.1.x, the current GA release. If I understand correctly, -devel suffix denotes that the port is a development version but this case, it actually provides GA release version. So I think I would say they aren't so good port names. I think simply naming them as mysqlXX(-server) is more intuitive. Coincidentally, this seems the naming convention adopted in FreeBSD ports. What do you think of this? Do you think this is feasible? Thanks From ryandesign at macports.org Sat Sep 26 09:45:27 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 26 Sep 2009 11:45:27 -0500 Subject: MySQL port name confusion In-Reply-To: <90bb445a0909260253w6a6c300dka248483efc4ab8c9@mail.gmail.com> References: <90bb445a0909260253w6a6c300dka248483efc4ab8c9@mail.gmail.com> Message-ID: On Sep 26, 2009, at 04:53, Akira Kitada wrote: > I realized mysql5 and mysql5-server ports are still pointing to 5.0.x, > ex-GA release of MySQL > and need to install mysql5-devel and mysql5-server-devel for 5.1.x, > the current GA release. > > If I understand correctly, -devel suffix denotes that the port is a > development version > but this case, it actually provides GA release version. > > So I think I would say they aren't so good port names. > I think simply naming them as mysqlXX(-server) is more intuitive. > Coincidentally, this seems the naming convention adopted in FreeBSD > ports. > > What do you think of this? Do you think this is feasible? I was not planning on changing the names. I was planning on upgrading mysql5 to 5.1.x and mysql5-devel to 5.4.x. http://trac.macports.org/ticket/19414 http://trac.macports.org/ticket/19415 I was just about to finally get around to doing that a few days ago, but it seems mysql 5.1.x cannot be installed as a universal binary whereas this was no problem for 5.0.x so I filed a but with the mysql developers. Unfortunately I have not received a response on it yet. http://bugs.mysql.com/bug.php?id=47360 From talklists at newgeo.com Sat Sep 26 12:24:49 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sat, 26 Sep 2009 12:24:49 -0700 Subject: MySQL port name confusion In-Reply-To: References: <90bb445a0909260253w6a6c300dka248483efc4ab8c9@mail.gmail.com> Message-ID: Question of curiosity. Why does MacPorts needs to be able to build a UB? MacPorts builds on the machine it is intended to use. I am not aware of many desiring to copy a binary from one machine to the other, and that would be a lot of work with all the man pages and other parts that may come along with the binary. If the arch specific base will build, while probably not ideal with regard to a UB, is that not more or less the most desirable case? The UB would be bloated, and many may run lipo on it to get rid of the parts they can not, or do not want to have. Other than MacPorts ability to make a dmg or installer, what is the reason behind the UB builds, aside from being really cool to be able to do, and certainly a target moving forward, but in this case, would the MySql port not suffice to be able to stand as is? I have never added +universal to a port, and in all the port files I have looked at, a very small percentage even have that variant. -- Scott * If you contact me off list replace talklists@ with scott@ * On Sep 26, 2009, at 9:45 AM, Ryan Schmidt wrote: > I was just about to finally get around to doing that a few days ago, > but it seems mysql 5.1.x cannot be installed as a universal binary > whereas this was no problem for 5.0.x so I filed a but with the > mysql developers. Unfortunately I have not received a response on it > yet. > > http://bugs.mysql.com/bug.php?id=47360 From jmr at macports.org Sat Sep 26 12:41:45 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 27 Sep 2009 05:41:45 +1000 Subject: MySQL port name confusion In-Reply-To: References: <90bb445a0909260253w6a6c300dka248483efc4ab8c9@mail.gmail.com> Message-ID: <4ABE6E79.2050803@macports.org> On 2009-9-27 05:24, Scott Haneda wrote: > Question of curiosity. Why does MacPorts needs to be able to build a > UB? MacPorts builds on the machine it is intended to use. I am not > aware of many desiring to copy a binary from one machine to the other, > and that would be a lot of work with all the man pages and other parts > that may come along with the binary. I guess people share archives between machines? You're right, it's usually unnecessary. But then you get something like wine which will only build for i386, so you install all the dependencies universal i386/x86_64 so you can have x86_64 for everything else. I can also see it being useful for people building libs to ship in a .app bundle (or, say, the MacPorts base pkgs), though we don't really cater to that case what with the install_name mangling that is needed. - Josh From ryandesign at macports.org Sat Sep 26 13:01:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 26 Sep 2009 15:01:35 -0500 Subject: MySQL port name confusion In-Reply-To: References: <90bb445a0909260253w6a6c300dka248483efc4ab8c9@mail.gmail.com> Message-ID: <50795478-1F5A-4F88-AD40-FAA8353C81FF@macports.org> On Sep 26, 2009, at 14:24, Scott Haneda wrote: > Question of curiosity. Why does MacPorts needs to be able to build > a UB? MacPorts builds on the machine it is intended to use. I am > not aware of many desiring to copy a binary from one machine to the > other, and that would be a lot of work with all the man pages and > other parts that may come along with the binary. I agree with you, when universal_archs is ppc i386. This was the default for Mac OS X 10.5.x and earlier. But starting with Snow Leopard the default universal_archs is x86_64 i386 and it is very useful. The default build_arch is also x86_64 on Snow Leopard now. This means we build 64-bit by default, which is good because it's faster and lets you use more memory (for example you can use more than 4GB of memory for your MySQL database server, which is something people might want to do). However, not all ports can build x86_64; some need to be built i386 due to various bugs. But if that software requires MySQL, and you've built mysql5 for x86_64 only, then you can't use MySQL from an i386 program. So you would need to build mysql5 universal for both x86_64 and i386. Users on Leopard can modify their build_arch and universal_archs in macports.conf if they want 64-bit builds. Users on Tiger can try to do so as well, but it probably won't work for many ports and so is probably not a good idea. > If the arch specific base will build, while probably not ideal with > regard to a UB, is that not more or less the most desirable case? > The UB would be bloated, and many may run lipo on it to get rid of > the parts they can not, or do not want to have. It would be silly for a user to request the +universal variant and then use lipo to strip out the nonnative architectures. If the user doesn't want a universal build, the user should not request the +universal variant. > Other than MacPorts ability to make a dmg or installer, what is the > reason behind the UB builds, aside from being really cool to be able > to do, and certainly a target moving forward, but in this case, > would the MySql port not suffice to be able to stand as is? I will probably update the mysql5 port anyway and just disable its universal variant. Any user complaints about this can then be directed at the MySQL developers with whom the blame lies. > I have never added +universal to a port, and in all the port files I > have looked at, a very small percentage even have that variant. MacPorts base includes a default universal variant which all ports inherit, unless they specifically request not to by using "universal_variant no", by using "use_configure no", by using the muniversal portgroup, or by defining their own universal variant. Some portgroups like xcode and cmake define their own universal variants. From sbwoodside at gmail.com Sat Sep 26 15:11:24 2009 From: sbwoodside at gmail.com (sbwoodside) Date: Sat, 26 Sep 2009 15:11:24 -0700 (PDT) Subject: Multi-link PPP Message-ID: <25629268.post@talk.nabble.com> Hi there, I'm maybe tilting at a windmill here but I'd like to port some kind of multilink PPP extension to Mac, for example MPD (http://mpd.sourceforge.net/) from FreeBSD. A quick look shows that it depends on netgraph, which is a fairly low level kernel library in FreeBSD that also seems to have been ported to linux kernel 2.4. So, is this even possible without modifying the kernel? It would seem that OS X does support network link bonding which is similar to multilink -- is that enough? I basically don't know quite enough about kernel/drivers to see what the path forward is. Any advice is appreciated. -- View this message in context: http://www.nabble.com/Multi-link-PPP-tp25629268p25629268.html Sent from the MacPorts - Developer mailing list archive at Nabble.com. From mark at dxradio.demon.co.uk Sat Sep 26 15:16:16 2009 From: mark at dxradio.demon.co.uk (Mark Hattam) Date: Sat, 26 Sep 2009 23:16:16 +0100 Subject: MySQL port name confusion In-Reply-To: References: <90bb445a0909260253w6a6c300dka248483efc4ab8c9@mail.gmail.com> Message-ID: <46F1CE3C-3916-4FF0-A3FC-B07C5371FF32@dxradio.demon.co.uk> On 26 Sep 2009, at 17:45, Ryan Schmidt wrote: > On Sep 26, 2009, at 04:53, Akira Kitada wrote: > >> I realized mysql5 and mysql5-server ports are still pointing to >> 5.0.x, >> ex-GA release of MySQL >> and need to install mysql5-devel and mysql5-server-devel for 5.1.x, >> the current GA release. >> >> If I understand correctly, -devel suffix denotes that the port is a >> development version >> but this case, it actually provides GA release version. >> >> So I think I would say they aren't so good port names. >> I think simply naming them as mysqlXX(-server) is more intuitive. >> Coincidentally, this seems the naming convention adopted in FreeBSD >> ports. >> >> What do you think of this? Do you think this is feasible? > > I was not planning on changing the names. I was planning on > upgrading mysql5 to 5.1.x and mysql5-devel to 5.4.x. > > http://trac.macports.org/ticket/19414 > > http://trac.macports.org/ticket/19415 > > I was just about to finally get around to doing that a few days ago, > but it seems mysql 5.1.x cannot be installed as a universal binary > whereas this was no problem for 5.0.x so I filed a but with the > mysql developers. Unfortunately I have not received a response on it > yet. > > http://bugs.mysql.com/bug.php?id=47360 MySQL continues to refer to both 5.0.x and 5.1.x as both being GA releases http://dev.mysql.com/downloads/mysql/5.0.html and http://dev.mysql.com/downloads/mysql/5.1.html And there appears to be no end-of-life statement about 5.0 apart from them not producing pre-built binaries for four named OS's after 31 Dec 2009. In fact they state they are continuing to provide source code and support for everything 4.1 and higher. So maybe there is a need for a MySQL41 MySQL50 MySQL51 MySQL54 separate ports, so that users know what they are actually getting when they install/upgrade. Though whether anyone still requires 4.1.x is a good question. But it is allegedly still supported in the source repository for security fixes. Mark From ryandesign at macports.org Sat Sep 26 15:27:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 26 Sep 2009 17:27:13 -0500 Subject: MySQL port name confusion In-Reply-To: <46F1CE3C-3916-4FF0-A3FC-B07C5371FF32@dxradio.demon.co.uk> References: <90bb445a0909260253w6a6c300dka248483efc4ab8c9@mail.gmail.com> <46F1CE3C-3916-4FF0-A3FC-B07C5371FF32@dxradio.demon.co.uk> Message-ID: On Sep 26, 2009, at 17:16, Mark Hattam wrote: > MySQL continues to refer to both 5.0.x and 5.1.x as both being GA > releases > > http://dev.mysql.com/downloads/mysql/5.0.html > and > http://dev.mysql.com/downloads/mysql/5.1.html > > And there appears to be no end-of-life statement about 5.0 apart > from them not producing pre-built binaries for four named OS's after > 31 Dec 2009. In fact they state they are continuing to provide > source code and support for everything 4.1 and higher. > > So maybe there is a need for a > MySQL41 > MySQL50 > MySQL51 > MySQL54 > separate ports, so that users know what they are actually getting > when they install/upgrade. > > Though whether anyone still requires 4.1.x is a good question. But > it is allegedly still supported in the source repository for > security fixes. Why would anybody want MySQL 5.0.x now that 5.1.x is available? We already have a mysql4 port which provides 4.1.x, though I expect to remove it next year after 4.1.x has been end-of-life'd. I am in the process of removing the mysql3 port. See #20700. From ryandesign at macports.org Sat Sep 26 15:28:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 26 Sep 2009 17:28:40 -0500 Subject: Multi-link PPP In-Reply-To: <25629268.post@talk.nabble.com> References: <25629268.post@talk.nabble.com> Message-ID: On Sep 26, 2009, at 17:11, sbwoodside wrote: > Hi there, I'm maybe tilting at a windmill here but I'd like to port > some kind > of multilink PPP extension to Mac, for example MPD > (http://mpd.sourceforge.net/) from FreeBSD. A quick look shows that it > depends on netgraph, which is a fairly low level kernel library in > FreeBSD > that also seems to have been ported to linux kernel 2.4. > > So, is this even possible without modifying the kernel? It would > seem that > OS X does support network link bonding which is similar to multilink > -- is > that enough? I basically don't know quite enough about kernel/ > drivers to see > what the path forward is. Any advice is appreciated. This is probably not the right list to ask that question. This list is for the development of MacPorts itself, and the development of portfiles for software that already runs on Mac OS X. Though if someone has an answer to the question, feel free to offer it. From akitada at macports.org Sat Sep 26 19:59:43 2009 From: akitada at macports.org (Akira Kitada) Date: Sun, 27 Sep 2009 11:59:43 +0900 Subject: MySQL port name confusion In-Reply-To: References: <90bb445a0909260253w6a6c300dka248483efc4ab8c9@mail.gmail.com> <46F1CE3C-3916-4FF0-A3FC-B07C5371FF32@dxradio.demon.co.uk> Message-ID: <90bb445a0909261959h6