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

Re: [31764] trunk/dports/net/cacti/Portfile
by Ryan Schmidt 06 Dec '07

06 Dec '07

On Dec 6, 2007, at 12:39, markd(a)macports.org wrote: > -patchfiles tree_console_missing_hosts.patch > +# Placeholder for Cacti official patches > +#patchfiles You removed the reference to the patchfile, but didn't delete the patchfile itself from the files directory...?

1 0

No response from ipython's main
by js 06 Dec '07

06 Dec '07

Hi, I filed a tichet and attached patches but no response is returned. http://trac.macosforge.org/projects/macports/ticket/13459 Someone please check my patches into the svn?

2 1

Re: Problem with a Qt application portfile
by markd＠macports.org 06 Dec '07

06 Dec '07

>>>>> I'm trying to port evolvotron: >>>>> >>>>> http://sourceforge.net/projects/evolvotron >>>>> >>>>> It build with qmake. Works in Fink. >>>>> >>>>> So far, I have this: >>>>> >>>>> PortSystem 1.0 >>>>> name evolvotron >>>>> version 0.4.0 >>>>> categories graphics x11 >>>>> platforms darwin >>>>> maintainers nomaintainer(a)macports.org >>>>> homepage http://sourceforge.net/projects/evolvotron >>>>> master_sites http://downloads.sourceforge.net/evolvotron/ >>>>> checksums md5 ab6f3a3247e36ca0024d3837f78bdf6b >>>>> description "Generative art" image evolver, based on Qt >>>>> long_description "Generative art" software to evolve images/ >>>>> textures/patterns through an \ >>>>> iterative process of random mutation and >>>>> user-selection driven evolution. >>>>> depends_lib port:qt3 >>>>> depends_build port:graphviz port:doxygen >>>>> patchfiles patch-common.pro patch-evolvotron.pro >>>>> worksrcdir ${name} >>>>> configure.args --mandir=${prefix}/share/man >>>>> destroot.destdir INSTALL_ROOT=${destroot} >>>>> configure.env QTDIR=${prefix} INSTALLBASE=${prefix} >>>>> INSTALLPATH=${destroot}${prefix} >>>>> build.env QTDIR=${prefix} INSTALLBASE=${prefix} >>>>> INSTALLPATH=${destroot}${prefix} >>>>> destroot.env QTDIR=${prefix} INSTALLBASE=${prefix} >>>>> INSTALLPATH=${destroot}${prefix} >>>>> > >>>>> I get as far as this: >>>>> >>>>> ---> Fetching evolvotron >>>>> ---> Verifying checksum(s) for evolvotron >>>>> ---> Extracting evolvotron >>>>> ---> Applying patches to evolvotron >>>>> ---> Configuring evolvotron >>>>> ---> Building evolvotron with target all >>>>> ---> Staging evolvotron into destroot >>>>> ---> Packaging tgz archive for evolvotron 0.4.0_0 >>>>> >>>>> And then I get this: >>>>> >>>>> Error: Target org.macports.archive returned: error copying "/opt/ >>>>> local/var/macports/build/ >>>>> _opt_local_var_macports_sources_local_graphics_evolvotron/ >>>>> work/.macports.evolvotron.state" to "/opt/local/var/macports/ >>>>> build/_opt_local_var_macports_sources_local_graphics_evolvotron/ >>>>> work/destroot/+STATE": no such file or directory >>>>> Error: Status 1 encountered during processing. Hi Linc, Because MacPorts uses an intermediate install location phase we call destroot, some poorly written Makefiles do not support DESTDIR or the use of it is not tested. There is no single answer on how to fix it. When possible, if the port author knows how to fix the application's Makefile so that it does work the patch should be contributed upstream. But many times this is not feasible. In this case it appears that evolvotron installs few files (http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/graphics/evolvotron/…) so one option is to just override the destroot phase entirely with your own. Looks like the freebsd port does the same thing. http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/graphics/evolvotron/… See the Portfile Development Examples in the guide and let us know if you have questions. Also, take a look at the logrotate port (the destroot phase) for an example of using MacPorts instead a Makefile's "make install" to destroot a port. http://geeklair.net/new_macports_guide/#development.examples Also note that scanning the freebsd ports collection (and gentoo, openbsd, and fink) can be a big help in creating MacPorts. But with the possible exception of openbsd, there is no equivalent to destroot, so destroot problems often can't be solved by getting tips from these other package managers. Freebsd must not use the makefile for installation for some other reason. Mark

1 0

Renaming a port
by Adam Mercer 06 Dec '07

06 Dec '07

Hi I would like to rename the 'bazaar-ng' port to simply 'bzr' to match the name used in most other distributions, the ideal time to do this would be when version 1.0 is released - in a week or two. The new name would also make more sense for ports of various bzr plugins I plan to add. However I don't simply want to rename the port as this will cause problems with people who have the current port installed and may not be aware of the name change. Therefore, in addition to renaming the port, I would like to add a sort of dummy port that alerts the user that the port has been renamed. Is there any infrastructure that I could use, or a recommended approach for this, or would something like the following suffice? PortSystem 1.0 name bazaar-ng version 1.0 categories devel python platforms darwin maintainers ram description The next-generation distributed version control system long_description ${description} pre-fetch { ui_msg "The bazaar-ng port has been renamed to bzr." return -code error "port has been renamed" } Cheers Adam

1 0

Re: [31752] distfiles
by Ryan Schmidt 06 Dec '07

06 Dec '07

On Dec 5, 2007, at 16:47, takanori(a)macports.org wrote: > Revision: 31752 > http://trac.macosforge.org/projects/macports/changeset/31752 > Author: takanori(a)macports.org > Date: 2007-12-05 14:46:57 -0800 (Wed, 05 Dec 2007) > > Log Message: > ----------- > Add distfile for octave. > > Added Paths: > ----------- > distfiles/octave/ > distfiles/octave/octave-2.9.15.tar.bz2 Why? Just to have an http mirror? Because it's still on the octave ftp server, and they've got releases back to 2.9.0, so I don't think they're going to remove it any time soon.

2 4

Re: +x11, and +quartz variants (or a dangerous idea)
by Ryan Schmidt 05 Dec '07

05 Dec '07

On Dec 5, 2007, at 05:55, Wenchieh Yen wrote: > On Dec 1, 2007, at 10:08 AM, Ryan Schmidt wrote: > >> Unless you would like to redefine our default installation goals >> to no longer be "most featureful" but instead be "most featureful >> excluding X11 things". I'm not saying we should or should not >> redefine this, just point out what our current status is, and that >> you seem to be proposing a change to that. >> >> Actually, I guess our current guidelines are to build a port to be >> the most featureful while not including huge libraries as >> dependencies which most users won't want. Thus far, I think we've >> had an unspoken agreement that the X11 features are useful, and >> indeed our installation docs require the user to install X11 and >> the X11SDK. I guess you're proposing a change to that as well. > > The following is a bit off-topic but this "most featureful" > guideline is sometimes annoying for me: Macports is a supporting > package management system and it is source based. It should be > flexible and customizable to indivisual needs (like Gentoo > Portage). Otherwise, we could just have a central build-farm and > provide users with binaries that would just work. We do want to have a central build-farm and provide users with binaries. :) There is a lot of work before we get there, though. We do want to be flexible and customizable too, though, which is why ports have variants. The default should be to have as many features as most users want. Variants are provided for additional features, or to turn off some features that some people don't want. Though usually if you don't want a feature that was built, you just use it. MacPorts philosophy is that disk space is cheap, so the little bit of extra space occupied by the unused features shouldn't really matter.

1 0

Re: [31434] trunk/dports/x11/gtk2/Portfile
by Eric Hall 05 Dec '07

05 Dec '07

On Fri, Nov 23, 2007 at 07:16:49AM -0800, rhwood(a)macports.org wrote: > Revision: 31434 > http://trac.macosforge.org/projects/macports/changeset/31434 > Author: rhwood(a)macports.org > Date: 2007-11-23 07:16:47 -0800 (Fri, 23 Nov 2007) > > Log Message: > ----------- > @#$% default variants! > remove default variant > add pre-fetch hook to error out if no variant is selected > This is breaking installs of wireshark (and I expect other ports that depend on gtk2) where the user doesn't have gtk2 installed already. Unless a mechanism to define the needed variant in the depspec has been added, can we revert this change, or otherwise set it so that x11 is the default? Thanks much, -eric

7 10

Added support in MacPorts base to set PATH and MANPATH automatically in Leopard
by James Berry 04 Dec '07

04 Dec '07

I just checked in some code (r31491:31492) that supplies and installs spec files for the /etc/paths.d and /etc/manpaths.d directories if they are present, as they are on Leopard. The contents of these files are automatically added to the users PATHS and MANPATHS environment variables, and should mean that we don't need to configure the user's profile under Leopard. Note that support for this is though path_helper(8). Hopefully this will make future configuration less painful. Comments welcome. James

11 28

Re: Added support in MacPorts base to set PATH and MANPATH automatically in Leopard
by Juan Manuel Palacios 03 Dec '07

03 Dec '07

Hello Marc! On Dec 3, 2007, at 7:28 AM, Marc André Selig wrote: > Let me start out by saying I find this whole business of modifying > users' files without telling them so quite awkward. Please note that all this path & manpath munging, user specific against system wide files modification is only meant to happen from the pkg installer (off of its postfligth script located in svn's base/ portmgr/dmg) which: *) Does warn users in the welcoming ReadMe.rtf file displayed by the installer that their environment will be modified for MacPorts usage; *) As it is aimed at a group of users who either don't want or don't know how to install from source, it is configured in the most standard fashion possible and, as such, it is only meant to work in that situation. If you're experienced enough to modify your system in meaningful ways, such as placing your profile file in a read-only image, then surely you're savvy enough to install from source and setup your own MacPorts environment (no project at all can afford to construct hand-holding installers of their software and instructions for more than a bare couple of usually similar-among-them scenarios). This is also made clear througout the documentation: ReadMe.rtf, website, guide, etc. If you feel we're still not being clear and forthcoming enough about this scenario and assumptions we're presenting the user with, then please feel most free to suggest improvements anywhere you might find them appropriate. > > > On Dec 3, 2007 6:14 AM, Juan Manuel Palacios <jmpp(a)macports.org> > wrote: >> *sh) >> if $SHELL -lc "/usr/bin/env | grep -q MANPATH" && ! $SHELL - >> lc "/usr/ >> bin/printenv MANPATH" | grep -q /opt/local/share/man; then >> echo "export MANPATH=/opt/local/share/man:\$PATH" >> >> $HOME/.profile >> fi > > This would fail silently on my account, where ~/.profile is symlinked > to a read-only image under normal circumstances. This is a new instruction that would print further content into the profile file, yes. But note that overall behavior is unchanged: if that fails for you, then the entire postflight script fails because prior to that there are also other instructions printed to the profile. Your "bug report" is not applicable, I'm afraid to say, the postflight script is simply not meant to work with your setup. Nevertheless, as I said above, please feel most free to suggest any improvements you might find appropriate, like some welcomed error catching. > If you don't catch > the error, things would go from "it fails unless you do everything in > the documentation" to "it fails if you do the things in the > (shortened) documentation; read the source if you want to get it > working again". What documentation are you referring to? What's the shortened version that's leaving you in a rather lost state? > I clearly prefer the old variant (more things to do, > but if you do them all, things work) to the new one (it works > magically if your installation is pure standard, but fails in > mysterious ways otherwise). There is no old and new way. We've had this postflight script for a long time already and all we're doing now is enhancing it to fill avoid we're encountering on Leopard (an appropriate setting for MacPorts installed man pages). James' enhancements writing to /etc/ [man]paths.d/ were deferred because they are not yet polished enough for production time, so we're aiming for this alternative through the same postflight script that, if it doesn't work for you now because of the setup you describe, it simply couldn't have worked for you earlier either. Also, magically working on a pure standard scenario but failing unexpectedly on different ones is precisely what the pgk installer and its postflight script are meant to do, that's expected behavior. If you're on the latter crowd, then please install from source. We as a team have not discussed putting together binary installers to cover for other scenarios than the pure standard one. I'm not saying we *wont* do it, but rather that we simply haven't; if we do, then I'm sure mixing its settings/considerations/assumptions with the ones of the pure standard scenario would be a very bad approach. In such case we'd be building two or more completely different and separate installers, each with its own private set of resources. > > > Just the point of view of a mere user. :-) And appreciated! Would love to study whatever enhancement you might propose. > > > Regards, > Marc > > PS: I agree that modifying the local user's preferences is preferrable > to modifying /etc. I still think it needs to be pointed out quite > clearly in the installation manual (i.e. you don't get to shorten the > manual if you do this). Otherwise, everybody who has one account for > each user (plus one account for managing the machine) will not know to > add your stub to the .profile of each user who wants to use MacPorts. Those are interesting documentation enhancements, making it clear that the environment we're setting up will only work on a per user basis. > > > PPS: Another story from the point of view of a mere user: I've had > people apparently locked out from their machine because they had > /opt/local/bin first thing in their PATH and some port had pulled in a > version of sudo that did not work. I've been telling people to put > /opt/local/bin at the end ever since. That should definitely be filed as a bug in our Trac. In fact I think it was and I also think it was fixed, but I don't have any reference to that, sorry. Regards,... -jmpp

1 0

NEW port request
by js 03 Dec '07

03 Dec '07

Hi, I submitted two new ports, py25-httplib2 and py25-lxml about a week ago, but I've got no response... Could anyone please review these attachment and commit them to svn? http://trac.macosforge.org/projects/macports/ticket/13411 http://trac.macosforge.org/projects/macports/ticket/13393

1 1