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

Re: [31399] trunk/dports/shells/zsh-devel/Portfile
by Ryan Schmidt 24 Nov '07

24 Nov '07

On Nov 22, 2007, at 07:24, nox(a)macports.org wrote: > Revision: 31399 > http://trac.macosforge.org/projects/macports/changeset/31399 > Author: nox(a)macports.org > Date: 2007-11-22 05:24:42 -0800 (Thu, 22 Nov 2007) > > Log Message: > ----------- > zsh-devel: > * Now uses the ncurses.h header (closes #13359). > * Fixed universal support. > > Modified Paths: > -------------- > trunk/dports/shells/zsh-devel/Portfile > > Modified: trunk/dports/shells/zsh-devel/Portfile > =================================================================== > --- trunk/dports/shells/zsh-devel/Portfile 2007-11-22 10:43:34 UTC > (rev 31398) > +++ trunk/dports/shells/zsh-devel/Portfile 2007-11-22 13:24:42 UTC > (rev 31399) > @@ -56,6 +56,15 @@ > depends_lib port:libiconv \ > port:ncurses > > +post-patch { > + # Fixes #13359. May need to be removed on upstream update. > + reinplace "s/curses\\.h/ncurses.h/" \ > + ${worksrcpath}/Src/Modules/termcap.c \ > + ${worksrcpath}/Src/Modules/terminfo.c > +} Maybe fixing #12605 would make the above unnecessary. Don't know yet. I'm looking into that ticket. http://trac.macports.org/projects/macports/ticket/12605 > +configure.universal_ldflags-append -isysroot ${sysroot} The ${sysroot} variable was added in r30032, after MacPorts 1.5.2 was released. You should hardcode the sysroot value until 1.6.0 is released... Or we could accept that this port is broken for 1.5.2 users since the 1.6.0 release is supposed to be within a week.

1 1

Port version 1.520: py-gnome is inconsistent.
by Douglas Philips 24 Nov '07

24 Nov '07

First thing I did was port -d selfupdate. port --version says: MacPorts 1.520 and goes into interactive mode. I started out trying to install meld. That apparently is an infinite task. After waiting over 5 minutes for port to stop what seemed to be an infinite loop of scanning dependencies, I went after it by hand and started installing the pieces. Until I found an inconsistency. I went after port deps on all the parts looking for where the problem was. Had I known it would have taken me 3 hours, I wouldn't have bothered. But since I spent the time looking (and I started bottom up :(, so I didn't find this very quickly) I wanted to raise this issue: (Eliding the branches of dependencies which aren't relevant to this conflict...) meld depends on py-gnome and py-gtk2 py-gnome depends on libzvt and py-gtk2 libzvt depends on gnome_session depends on control-center depends on nautilus depends on eel depends gnome_menus depends on py25_gtk2 (!) depends on py25_cairo py_gtk2 depends on py_cairo py25_cairo and py_cairo cannot be installed at the same time: # port install py25-cairo ---> Activating py25-cairo 1.4.0_1 Error: Target org.macports.activate returned: Image error: /opt/local/ include/pycairo/pycairo.h is being used by the active py-cairo port. Please deactivate this port first, or use the -f flag to force the activation. Error: Status 1 encountered during processing. HELP! --Doug P.S. Sometime during those three hours I think I ran into another py-... py25-... conflict which in my focus on this one, I didn't record :(, trying to get meld installed, but I don't know if it was also a py-gnome problem or not...

1 0

setting variants on the fly
by Randall Wood 23 Nov '07

23 Nov '07

Is it possible? What I would like to do is be able to test either that a dependency was installed with a certain variant or that a file exists and then set a variant on the port being installed based on that information. Background: I am reworking the gtk2 port so that it can be installed without X11. What I want to be able to do is have "sudo port install gtk2" work correctly, installing gtk2 with the correct variants for the machine its being installed on without user intervention or complaint. Randall Wood rhwood(a)mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

4 5

macports email address question
by Randall Wood 22 Nov '07

22 Nov '07

How do I change the email address for redirecting email addressed to my macports account from the existing redirection address to a new address? Randall Wood rhwood(a)mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

2 2

Re: Gimp without X11
by Yves de Champlain 22 Nov '07

22 Nov '07

Le 07-11-22 à 06:36, Rémi Thébault a écrit : > Le 22 nov. 07 à 00:07, Yves de Champlain a écrit : > >> >> Le 07-11-21 à 17:52, Randall Wood a écrit : >> >>> Its possible to install the Gimp without using X11! I think it >>> mostly works, but am not a heavy user of it, so I don't know of >>> use cases that may break. >>> >>> http://shyramblings.blogspot.com/2007/11/gimp-on-mac-os-x-without- >>> x11-from.html >> >> I've used MacPorts gimp on quartz and while it has some glitches, >> it runs very smoothly. >> >> Gimp developers use gtk-quartz so it's bound to be as good as gtk- >> quartz is. >> >> yves >> >> _______________________________________________ >> macports-users mailing list >> macports-users(a)lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo/macports-users > > > Hi > > I had an issue with "port install gimp2 no_python" : > the dependency gail failed to build with : "gdk/gdkx.h : no such > file or directory". > So I "port clean gail" and then "port install gail > +quartz" and now it's ok :-) > > By the way, why must we remove python support to build it without > x11 ? I'm sure there are a lot of useful python plugins for Gimp. No connection. You can have it with and without python. with is better, of course ! yves

1 0

Re: [31397] trunk/dports/python/py25-numeric/Portfile
by Ryan Schmidt 22 Nov '07

22 Nov '07

On Nov 22, 2007, at 04:04, takanori(a)macports.org wrote: > Revision: 31397 > http://trac.macosforge.org/projects/macports/changeset/31397 > Author: takanori(a)macports.org > Date: 2007-11-22 02:04:31 -0800 (Thu, 22 Nov 2007) > > Log Message: > ----------- > py25-numeric: fix build issue - seems that there are needs to > declare to use gcc Curious. What else would it use otherwise?

1 0

Guide should warn about default_variants
by Ryan Schmidt 22 Nov '07

22 Nov '07

The guide says this about default_variants: > If variants are defined, then the default_variants value lists > which variants are enabled by default. This allows for Portfile > modularity and also allows users to suppress default variants if > they wish. > > * Default: none > * Example: default_variants +ssl +tcpd > > Default variants may be suppressed by preceding a variant name > with a "-" as shown in this example. > > %% port install foo -ssl A MacPorts bug makes default_variants inadvisable to use for variants that you might conceivably want to disable. (If, as in the example above, you "port install foo -ssl", foo -ssl is installed. But when you later need to upgrade foo, default_variants +ssl will take precedence and you'll be left with just "foo" (no "-ssl") installed.) Therefore, this section should add a note like this: "The use of default_variants is discouraged. Instead, it's recommend that a port be built such that the most commonly requested functionality is on, and if needed, can be disabled with a "+no_something" variant. To extend the above example, build the port so that ssl and tcpd functionality is on, without needing to select any variant. Provide "no_ssl" and "no_tcpd" variants if there's a good reason someone might want to disable those features."

1 0

Hypothetical "port load", "port unload" commands (and "turn" script)
by Ryan Schmidt 21 Nov '07

21 Nov '07

I've written many replies on this list explaining to people how to use launchctl to start and stop various services installed by MacPorts. Every time I do, I have to refer back to my notes to remember the exact launchctl command and the exact path to the plist. Admit it: sudo launchctl load -w /Library/LaunchDaemons/org.macports.foo.plist is not easy to remember, and it's a lot to type. On my system, I wrote a script "turn" to simplify things for me. I can say things like: turn foo on or turn off bar and it knows where to look for the plist and how to execute the appropriate launchctl command. It's short and easy to remember. It also prints helpful messages if you try to turn something on when it's already on, or off when it's already off. It would be nice to have easier-to-remember commands included with MacPorts, but a script called "turn" hardly seems to fit in with the rest of the project. But what about: sudo port load foo and sudo port unload bar ? That's pretty easy to remember in my opinion. What do you think? This proposed syntax limits us to one launchctl plist per port. However, we already have that limit, so I don't consider it a big problem at this time. P.S: I'm including my "turn" script for others to examine and try out and even use, if they like. But I'm not suggesting that this script be incorporated as-is into MacPorts. I would fully intend for the hypothetical "port load" and "port unload" commands to be properly implemented in Tcl.

3 3

Re: [31193] branches/release_1_6/base/src
by Ryan Schmidt 21 Nov '07

21 Nov '07

On Nov 17, 2007, at 23:09, jmpp(a)macports.org wrote: > Revision: 31193 > http://trac.macosforge.org/projects/macports/changeset/31193 > Author: jmpp(a)macports.org > Date: 2007-11-17 21:09:01 -0800 (Sat, 17 Nov 2007) > > Log Message: > ----------- > > Temporarily revert Landon's hiding of the Tcl cd command until > remaining Portfiles are cleaned up. > Currently there are still almost 300 ports that use the command and > breaking them all in one fell > swoop is not something we want to do! Thanks. That's a relief. I'm working on a new script to give us a better indicator of how many ports are affected (and to show where). My complicated grep was inaccurate, markd pointed out, in that it gave false positives for (several) portfiles which used "cd" inside of ui_msg blocks, as instructions to the user, which should not be flagged as a problem. > One thing we should do is find a way to issue a suitable warning > when Tcl's cd is called from a Portfile > but not from port1.0, as that would be useless information. An excellent idea. Much like we currently get notices about mtree violations.

5 15

Re: [31362] trunk/dports/x11/gtk2/Portfile
by Juan Manuel Palacios 21 Nov '07

21 Nov '07

On Nov 21, 2007, at 7:16 AM, rhwood(a)macports.org wrote: Log Message > * Add variants with[out]_quartz and with[out]_x11 > * Move x11-specific dependencies and configure/build settings to > variant with_x11 > * Make +with_x11 +without_quartz the default variants > * Include variants quartz and no_x11 as calls to with_quartz and > without_x11 until such a time as they are no longer required > > +variant quartz requires with_quartz {} > +variant no_x11 requires without_x11 {} > + > Why didn't you simply use the more standard "x11", "no_x11" and by extension "quartz", "no_quartz" variant naming scheme rather than this complex set of conflicting and required variants that you used? Something we gtk2 outsiders aren't seeing that makes it necessary? -jmpp

2 1