December 2007 - macports-dev - lists.macosforge.org

Re: List of universal archs in base (was: [31959] trunk/dports/devel/openssl)
by Ryan Schmidt 28 Dec '07

28 Dec '07

On Dec 28, 2007, at 00:21, Boey Maun Suang wrote: > On Fri, December 14, 2007 7:42 pm, Ryan Schmidt wrote: > >> On Dec 12, 2007, at 12:52, mww(a)macports.org wrote: >> >>> + post-patch { >>> +# foreach arch {i386 x86_64 ppc ppc64} >>> + foreach arch {i386 ppc} { >>> + file copy ${worksrcpath} ${workpath}/${arch} >>> + } >>> + } >> >> Perhaps we should define this list of universal architectures in >> MacPorts base itself, so that ports that want to do something for >> each arch will already have the array ready to go rather than have to >> define it themselves -- possibly differently from base, which would >> be inconsistent. >> >> Such a definition (let's call it "universal_archs", maybe) should >> probably go above the definition of configure.universal_args in >> portconfigure.tcl. The contents of this array should be used to build >> up a new variable (how about "universal_arch_flags") which ends up >> looking like "-arch i386 -arch ppc". This string can then be used to >> build up configure.universal_cflags, configure.universal_cxxflags and >> configure.universal_ldflags. >> >> Anyone agree? Disagree? > > That looks like a reasonable suggestion to me. Given the patch > that you > quote, it might be better to extend the idea to handle 32- and 64-bit > platforms as well, as I think that we're starting to see issues > specific > to single-arch 64-bit platform builds, 32-bit universal building, > and so > on. Still don't grok base well enough to work on this myself, > though :( > I'll get there one day... mww already implemented this in base, and made the list include all 4 archs. http://trac.macports.org/projects/macports/changeset/32194 This brings up another issue though. Seems to me that all users who already have ports with the old 2-way +universal variant installed will now start seeing problems. What if, for example, I had zlib +universal installed before (and therefore have a 2-way universal of zlib installed), and now I update MacPorts base to include this 4-way universal variant, and I try to install libpng +universal, which depends on zlib, libpng will probably fail because there aren't any 64-bit versions of zlib for it to link with. We need to implement some kind of fix for this before this change in trunk can be released.

1 0

Re: Error loading stylesheet /svnindex.xsl
by Juan Manuel Palacios 27 Dec '07

27 Dec '07

On Dec 26, 2007, at 8:43 PM, Jeffrey Thompson wrote: > I'm still getting the error (see attached): Error loading > stylesheet: A > network error occured loading an XSLT stylesheet: > http://svn.macports.org/svnindex.xsl Strange, I'm looking at it right now with both Safari (3.0.4) and Firefox (2.0.0.9) and I still don't see the problem, every http://svn.macports.org/repository/macports/* "page" of our svn repository I navigate to displays just fine for me. I'm still guessing the problem is intermittent, I'll investigate. -jmpp

2 2

Re: propchange - r32353 svn:log
by Ryan Schmidt 27 Dec '07

27 Dec '07

jmpp wrote: > BRAINSTORM: After this commit, the ${prefix}/etc/macports/ > mp_version installed file is going to stall and thus might confuse > people, > so should we delete it upon installing a new release? I would say: Probably so!

1 0

Re: [32358] trunk/dports/mail/imapfilter/Portfile
by Ryan Schmidt 27 Dec '07

27 Dec '07

On Dec 27, 2007, at 07:55, mww(a)macports.org wrote: > +variant universal { > + configure.cflags-append "${configure.universal_cflags}" > + configure.cppflags-append "${configure.universal_cppflags}" > + configure.ldflags-append "${configure.universal_ldflags}" > +} Wouldn't the attached be simpler and clearer? The above is a little confusing at first glance because configure.universal_* are already appended to configure.* by default.

1 0

Error loading stylesheet /svnindex.xsl
by Ryan Schmidt 27 Dec '07

27 Dec '07

Attempting to access http://svn.macports.org/repository/macports/ in Camino gives me Error loading stylesheet: A network error occured loading an XSLT stylesheet: http://svn.macports.org/svnindex.xsl Attempting to access http://svn.macports.org/svnindex.xsl gives me Forbidden You don't have permission to access /svnindex.xsl on this server.

3 3

tcl84 and tcl85?
by Takeshi Enomoto 24 Dec '07

24 Dec '07

Hello, I became aware of the official release of Tcl/Tk 8.5 in the other thread. I tried to upgrade but failed as already reported by Stephen. The ports for Tcl/Tk require some work to be stable. <http://trac.macosforge.org/projects/macports/ticket/13682> I wanted to upgrade Tcl/Tk to see if it works with PLplot and Tcl-nap. In the mean time, Ryan found PLplot does not work with Tcl/Tk 8.5 (Thanks!). This upgrade of Tcl/Tk affects other ports significantly. <http://trac.macosforge.org/projects/macports/ticket/13697> It occurred to me if we could separate Tcl/Tk 8.4.x and Tcl/Tk 8.5 ports as done with Python. Then PLplot can depend on port:tcl84 and port:tk84. Any opinions? Takeshi

1 0

RFC: coreutils uses program-prefix=g by default
by js 23 Dec '07

23 Dec '07

Hi list, I've just installed coreutils and found that all files in coreutils have "g" prefix. "port cat corefiles" show that this is because coreutils' portfile set configure.args to "program-prefix=g". The reason why I installed coreutils was to run shell script that uses seq but for the "g" prefix, the shell script had to be modified to have "g" in front of the name. This was very annoying for me. Yes, I can easily avoid this by "port edit corefiles" and drop "program-prefix" but I thought if most of the MacPorts users wouldn't want "g", it might be better to fix this portfile. So let me ask this, "Do you like to have gls, guniq in your /opt/local/bin? Is there any case that removing "g" prefix causes any problems? Any input will be appreciated. Thanks.

3 6

OS X 10.4.11, Ports v 1.6.0, upgrading tk...
by Douglas Philips 23 Dec '07

23 Dec '07

Just a few days ago I did a port -d selfupdate and moved up from 1.5.2 to 1.6.0. A few hours ago I started the port upgrade commands on my outdated ports. Everything went fine excpet for tk... 8.4.16_0 is the currently installed version. tcl is already @8.5.0_0 But, when I try the port upgrade on tk (and yes, I've done a port clean --all tk several tiems now), I get this error: In file included from /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_tk/ work/tk8.5.0/unix/../generic/ttk/ttkBlink.c:19: /opt/local/include/tk.h:23:3: error: #error Tk 8.4 must be compiled with tcl.h from Tcl 8.4 make: *** [ttkBlink.o] Error 1 Error: Unable to upgrade port: 1 And sure enough, when I look in /opt/local/include/tk.h, it is checking for 8.4. Has anyone else seen this? Maybe it is just something about my system? Anyways, wanted to ping before opening a ticket... Thanks, --Doug

2 2

Portfile for Alpine
by Tod Morrison 23 Dec '07

23 Dec '07

With the official release of version 1.00 I've created a Portfile for Alpine. --- Begin Portfile --- # $Id$ PortSystem 1.0 name alpine version 1.00 categories mail maintainers todmorrison(a)gmail.com description alpine - a Program for Internet News and Email homepage http://www.washington.edu/alpine/ platforms darwin long_description Alpine is a tool for reading, sending, and managing \ electronic messages that was designed with novice users in mind. master_sites ftp://ftp.cac.washington.edu/alpine/ \ ftp://ftp.cac.washington.edu/alpine/old/ checksums md5 214e02f93fad5ce79d8e3b37d74387a1 distname ${name}-${version} extract.suffix .tar.gz configure.args --without-tcl \ --with-local-password-cache-method variant passfile { configure.args-delete --with-local-password-cache-method configure.args-append --with-passfile=".pine.pwd" } --- End Portfile ---

2 1

Should /opt/local/bin/perl be deleted too ?
by Anders F Björklund 22 Dec '07

22 Dec '07

http://trac.macports.org/projects/macports/ticket/13641 Perl 5.10.0 has now been released, so there are now two stable port versions available: "perl5.8" and "perl5.10" Should we delete "${prefix}/bin/perl" just like we did with "${prefix}/bin/python", or is there a better option ? --anders

5 9