February 2008 - macports-dev - lists.macosforge.org

Re: [33981] trunk/dports/net/transmission-x11/Portfile
by Ryan Schmidt 09 Feb '08

09 Feb '08

For future changes, could I ask you to do whitespace changes in a separate commit please? Otherwise it's hard to see what functional changes were made in a revision. Thanks. On Feb 9, 2008, at 13:05, gui_dos(a)macports.org wrote: > Revision: 33981 > http://trac.macosforge.org/projects/macports/changeset/33981 > Author: gui_dos(a)macports.org > Date: 2008-02-09 11:05:12 -0800 (Sat, 09 Feb 2008) > > Log Message: > ----------- > transmission-x11: > * Update to 1.05 > * Stripped the double \n in the long_description wich > introduced a pair of brackets when evaluated, confusing > the activation phase > * Added dependency on OpenSSL > * Avoid building Cocoa and wxWidgets' versions > > Modified Paths: > -------------- > trunk/dports/net/transmission-x11/Portfile > > Modified: trunk/dports/net/transmission-x11/Portfile > =================================================================== > --- trunk/dports/net/transmission-x11/Portfile 2008-02-09 17:52:05 > UTC (rev 33980) > +++ trunk/dports/net/transmission-x11/Portfile 2008-02-09 19:05:12 > UTC (rev 33981) > @@ -1,26 +1,29 @@ > # $Id$ > > -PortSystem 1.0 > +PortSystem 1.0 > > -name transmission-x11 > -version 1.03 > -revision 1 > -categories net gnome x11 > -maintainers nomaintainer > -description Lightweight BitTorrent client > -long_description Transmission is a free, lightweight BitTorrent > client. \ > - It features a simple, intuitive interface on top of an \ > - efficient, cross-platform back-end. Transmission is open \ > - source (MIT license) and runs on Mac OS X (Cocoa interface), \ > - Linux/NetBSD/FreeBSD/OpenBSD (GTK+ interface) and BeOS \ > - (native interface). \n\n\ > - This is the GTK+ version. > -homepage http://www.transmissionbt.com/ > +name transmission-x11 > +version 1.05 > +categories net gnome x11 > +maintainers nomaintainer > +description Lightweight BitTorrent client > +long_description Transmission is a free, lightweight BitTorrent > client. \ > + It features a simple, intuitive interface on top > of an \ > + efficient, cross-platform back-end. Transmission > is open \ > + source (MIT license) and runs on Mac OS X (Cocoa > interface), \ > + Linux/NetBSD/FreeBSD/OpenBSD (GTK+ interface) and > BeOS \ > + (native interface). This is the GTK+ version. > +homepage http://www.transmissionbt.com/ > +distname transmission-${version} > +master_sites http://download.m0k.org/transmission/files/ > +checksums md5 3baf5be0d4fe2a0e0e0e43b7b0fe5dcb > +use_bzip2 yes > +platforms darwin freebsd > +depends_lib port:gettext port:gtk port:openssl > > -master_sites http://download.m0k.org/transmission/files/ > -checksums md5 f9189da1352483aed9f6736498443de3 > -use_bzip2 yes > - > -platforms darwin freebsd > - > -depends_lib port:gettext port:gtk > +configure.args --without-wx > +# Force avoiding the Cocoa build > +post-extract { > + reinplace "s|macosx/Makefile| |g" ${worksrcpath}/configure > + reinplace "s|macosx||g" ${worksrcpath}/Makefile.in > +}

1 0

New port config could make MacPorts' setup much easier
by Rainer Müller 09 Feb '08

09 Feb '08

Hi, I am thinking about a new port config target, which could make setting up MacPorts much easier. Currently, the appropriate variables for PATH, MANPATH and DISPLAY are determined in the postflight script. If we would move that into a port config target (or port setup, the name is open for discussion), the manual setup process would become easier. To get the env vars needed for your system, you would type: port config --envvars which would output: export PATH=/opt/local/bin:/opt/local/sbin:$PATH export MANPATH=/opt/local/share/man:$MANPATH But to support multiple shells, this could be extended to also allow port config --envvars --tcsh which would output: setenv PATH /opt/local/bin:/opt/local/sbin/:$PATH setenv MANPATH /opt/local/share/man:$MANPATH So the default should be auto-guessing which shell to use (current $SHELL). There could be support for a lot of shells people are using. The env vars which would be exported will be depending on the system this runs on, e.g.: Leopard: PATH and MANPATH Tiger/Panther: PATH, MANPATH and DISPLAY Another switch, port config --profile could output the profile file of the current running shell. This would be .tcshrc for tcsh, .bash_profile for bash, .zshrc for zsh and maybe others, too. So after all setting up MacPorts could become just this line: /opt/local/bin/port config --envvars >> \ $(/opt/local/bin/port config --profile) Or a command /opt/local/port config --setup could do it all automatically. The main purpose would be that we are moving this away from the dmg installer and into base itself. So even if the installer postflight script fails in future again, there would be an easy option to setup MacPorts. Additionally this could also be useful for users installing from source. As the postflight script is broken in the 1.6.0 dmg, we have seen a lot of people on IRC and the users mailing list looking for help how to get MacPorts running. Telling them "set up your PATH manually" sounds too complicated for some users and they might quit using MacPorts at all. What do you think about such an option? Rainer

3 4

Re: [33954] trunk/dports/lang/sbcl
by Ryan Schmidt 08 Feb '08

08 Feb '08

On Feb 8, 2008, at 10:22, waqar(a)macports.org wrote: > Revision: 33954 > http://trac.macosforge.org/projects/macports/changeset/33954 > Author: waqar(a)macports.org > Date: 2008-02-08 08:22:20 -0800 (Fri, 08 Feb 2008) > > Log Message: > ----------- > Fixed to appease the lint. [snip] > Modified: trunk/dports/lang/sbcl/Portfile > =================================================================== > --- trunk/dports/lang/sbcl/Portfile 2008-02-08 15:27:53 UTC (rev > 33953) > +++ trunk/dports/lang/sbcl/Portfile 2008-02-08 16:22:20 UTC (rev > 33954) > @@ -1,9 +1,11 @@ > # $Id$ > > PortSystem 1.0 > + > name sbcl > version 1.0.14 > set bootversion 0.9.16 > +revision 1 > categories lang > maintainers gwright(a)macports.org waqar(a)macports.org > platforms darwin Why "revision 1"? I thought you just changed patchfile names and fixed whitespace and such. The installed product should not have changed.

1 0

Re: *-devel ports
by Thomas de Grivel 08 Feb '08

08 Feb '08

2008/2/7, Ryan Schmidt <ryandesign(a)macports.org>: > > On Feb 7, 2008, at 09:10, Vincent Lefevre wrote: > > > On 2008-02-07 15:21:41 +0100, Thomas de Grivel wrote: > > > >> 2008/2/7, Ryan Schmidt: > >> > >>> It was proposed that -devel ports should be updated to the latest > >>> stable version, if the latest stable version is newer than the > >>> latest > >>> development version. If we act on this proposal, then "-latest" is > >>> more intuitive than "-devel". > >> > >> Ok I see the point. In other terms it is a pointer to a stable or > >> -devel version of the same port, like a virtual package depending on > >> the right one ? > > > > Yes, more or less. > > Actually no, I was not intending for there to be any virtual packages. > > Let's do an example. The way it is now, "mysql5" is the latest > released version of MySQL (5.0.51) and "mysql5-devel" is the latest > development version (5.1.22-rc). Let us now assume for the sake of > this example that the next version of MySQL that is released is > 5.1.25 and it is considered a released version. To follow our current > practices, "mysql5" will be updated to 5.1.25 and "mysql5-devel" will > not be updated and will remain at 5.1.22-rc, until a development > version of MySQL 5.2 is released. Or maybe it will switch to version > 6.0 at that point. > > The proposal is that when the hypothetical stable version 5.1.25 is > released, "mysql5" will be updated to 5.1.25, and "mysql5-devel" will > also be updated to 5.1.25. Both ports will then be identical until > the next development release. Put this way indeed it really sounds right. Sorry if I misunderstood the other explanations. -- Thomas de Grivel

1 0

Re: [33938] trunk/base/src/macports1.0/macports.tcl
by Ryan Schmidt 08 Feb '08

08 Feb '08

On Feb 7, 2008, at 21:34, raimue(a)macports.org wrote: > Revision: 33938 > http://trac.macosforge.org/projects/macports/changeset/33938 > Author: raimue(a)macports.org > Date: 2008-02-07 19:34:55 -0800 (Thu, 07 Feb 2008) > > Log Message: > ----------- > macports1.0/macports.tcl: > Add --prepend option to selfupdate, which will check if an update > is necessary. > I had to rearrange some things in order to present nice output. What is being prepended to what? Or did you mean "pretend"?

2 1

Trac and Subversion down?
by Ryan Schmidt 08 Feb '08

08 Feb '08

Trac has been very slow lately, but right now it's not responding at all: The operation timed out when attempting to contact trac.macosforge.org. The requested site did not respond to a connection request and Camino has stopped waiting for a reply. and neither is Subversion: gnucash $ svn log svn: PROPFIND request failed on '/repository/macports/trunk/dports/ gnome/gnucash' svn: PROPFIND of '/repository/macports/trunk/dports/gnome/gnucash': could not connect to server (http://svn.macosforge.org) gnucash $

2 2

Re: *-devel ports
by Thomas de Grivel 07 Feb '08

07 Feb '08

2008/2/7, js <ebgssth(a)gmail.com>: > If the developer call it as stable and the other's development, > Let' follow it. > Anyone who like to use newer can easily choose -devel one. I think we all agree on this (we dont have time to test stability, ffs). 2008/2/7, Ryan Schmidt <ryandesign(a)macports.org>: >It was proposed that -devel ports should be updated to the latest >stable version, if the latest stable version is newer than the latest >development version. If we act on this proposal, then "-latest" is >more intuitive than "-devel". Ok I see the point. In other terms it is a pointer to a stable or -devel version of the same port, like a virtual package depending on the right one ? I also cannot avoid comparing with Gentoo : they use multiple 'ebuild' files (the converse of a portfile) to reflect the different versions of a package. That done they can mark each version as stable/unstable and allow to install different versions when they have different 'slots' (like for gtk-1 and gtk-2 : they consider it is the same "port" but with a different slot so both can be installed). I dont suggest to rip it off them but that is another existing solution to this problem. Well multiple versions is another larger issue I don't mean to bring here. -- Thomas de Grivel

3 2

Fwd: [MacPorts Lint] Portfile Lint Errors for: dpkg
by Landon Fuller 07 Feb '08

07 Feb '08

So I just received the following automated e-mail. While I think automated portlint is great, I'm wondering why we need a new ".diff" Official Policy just to appease certain people's editors. Begin forwarded message: > From: noreply(a)macports.org > Date: February 6, 2008 05:17:47 PST > To: landonf(a)macports.org > Subject: [MacPorts Lint] Portfile Lint Errors for: dpkg > > Portfile: dpkg > > > Errors: Warning: Line 4 should be a newline (after PortSystem) > Warning: Line 33 has trailing whitespace before newline > Warning: Patchfile patch-config.h.in does not follow the source > patch naming policy "patch-*.diff" > Warning: Patchfile patch-configure does not follow the source patch > naming policy "patch-*.diff" > Warning: Patchfile patch-configure.in does not follow the source > patch naming policy "patch-*.diff" > Warning: Patchfile patch-lib_utils.c does not follow the source > patch naming policy "patch-*.diff" > Warning: Patchfile patch-lib_tarfn.c does not follow the source > patch naming policy "patch-*.diff" > Warning: Patchfile patch-main_remove.c does not follow the source > patch naming policy "patch-*.diff" > Warning: Patchfile patch-utils_Makefile.in does not follow the > source patch naming policy "patch-*.diff" > Warning: Patchfile patch-main_archives.c does not follow the source > patch naming policy "patch-*.diff" > Warning: Patchfile patch-archtable does not follow the source patch > naming policy "patch-*.diff" > Warning: Patchfile patch-include_parsedump.h does not follow the > source patch naming policy "patch-*.diff" > Warning: Patchfile patch-utils_start-stop-daemon.c does not follow > the source patch naming policy "patch-*.diff" > Warning: Patchfile bsd/patch-main_help.c does not follow the source > patch naming policy "patch-*.diff" > > >

2 3

Marking default variants (was: [MacPorts] #14178: Feature Request: show default_variants in "port variants foobar")
by Rainer Müller 07 Feb '08

07 Feb '08

MacPorts wrote: > #14178: Feature Request: show default_variants in "port variants foobar" > --------------------------------+------------------------------------------- > Reporter: themolok(a)gmail.com | Owner: macports-tickets(a)lists.macosforge.org > Type: enhancement | Status: new > Priority: Normal | Milestone: > Component: base | Version: 1.6.0 > Keywords: | > --------------------------------+------------------------------------------- > I tried to write a patch for it, but I failed (I never wrote a single line > of tcl, and I'm a pretty lame programmer), anyway, I think it's really > trivial for who knows the port (the tcl script) codebase. > > Now, for example, "port variants git-core" returns (note that doc is in > default_variants): > {{{ > git-core has the variants: > universal > doc: Install HTML and plaintext documentation > svn: Bi-directional subversion repository support > }}} > > I'd like to have something like: > {{{ > git-core has the variants: > universal > doc: Install HTML and plaintext documentation (default) > svn: Bi-directional subversion repository support > }}} I also thought about marking default variants some time ago, but I think this should not only be added to port variants, but also to port info. Where the latter will be more difficult, as default_variants are currently not stored in PortIndex. It would be good to e.g. mark them with a star. git-core 1.5.3.7, devel/git-core (Variants: universal, *doc, svn) And this could also be used for port variants. git-core has the variants: universal *doc: Install HTML and plaintext documentation svn: Bi-directional subversion repository support I don't like that (default) behind the description as it is not clear if it is part of the description or not. The star (or another symbol) could also be behind the variants name, that's open for discussion. That's why I put this up on macports-dev@ instead of adding a comment to the ticket. Rainer

2 3

Re: [33798] trunk/dports/mail
by Ryan Schmidt 06 Feb '08

06 Feb '08

On Feb 5, 2008, at 08:38, simon(a)macports.org wrote: > Revision: 33798 > http://trac.macosforge.org/projects/macports/changeset/33798 > Author: simon(a)macports.org > Date: 2008-02-05 06:38:46 -0800 (Tue, 05 Feb 2008) > > Log Message: > ----------- > mail/uagen: New port. Since it doesn't seem to install any compiled software, I think it needs a "universal_variant no" bit.

5 5