Re: ghc as an upgrade-stopper
On Nov 3, 2009, at 14:39, Alexy Khrabrov wrote: So I wanted to effect a cheap Snow Leopard upgrade with time sudo port upgrade --enforce-variants installed The only supported solution after upgrading to Snow Leopard is to uninstall all ports and then reinstall them. See the Migration page: http://trac.macports.org/wiki/Migration However, I used to have a ghc, and now it stops the process with: ... Error: Target org.macports.fetch returned: ghc is not yet supported on Mac OS X 10.6.x (SnowLeopard) Now I did port uninstall clean ghc... Do I need further obliteration efforts to make upgrade go past it? ghc is not available in MacPorts for Snow Leopard yet. This is the ticket for the request to get that done: http://trac.macports.org/ticket/20132 You can Cc yourself if you'd like to be informed when ghc is available for Snow Leopard. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: HDF5 dilemma
On Nov 6, 2009, at 17:34, Darren Weber wrote: $ sudo port activate hdf5-18 @1.8.3_1 --- Activating hdf5-18 @1.8.3_1 Error: port activate failed: Image error: /opt/local/bin/gif2h5 is being used by the active hdf5 port. Please deactivate this port first, or use 'port -f activate hdf5-18' to force the activation. The hdf5 and hdf5-18 ports are behaving like separate ports, up to the point of activation conflicts. There are two maintainers for these ports (in the CC list of this email); can we get together on this and work out the activation conflict? They are separate ports, but appear to conflict. If the conflict is intentional, both ports should use the new conflicts keyword available as of MacPorts 1.8.0. If the conflict is not intentional, and it should be possible to install both ports simultaneously, then the conflict should be resolved by these two maintainers so that the two ports do not attempt to both install the same file(s). ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Localized GTK Apps? How to do it?
On Nov 5, 2009, at 02:08, Nico Nachtigall wrote: I'd like to have gtk apps localized. At the moment e.g wireshark is english only on my system and pan2 got translated only in 1/3 or so. / locale LANG=de_DE.UTF-8 LC_COLLATE=de_DE.UTF-8 LC_CTYPE=de_DE.UTF-8 LC_MESSAGES=de_DE.UTF-8 LC_MONETARY=de_DE.UTF-8 LC_NUMERIC=de_DE.UTF-8 LC_TIME=de_DE.UTF-8 LC_ALL= Am I missing some packages or there are just no translations in macports? Most ports should be installing all available localizations by default. For each port you find that doesn't have localizations working properly, you should feel free to file tickets in the issue tracker to have that resolved, if possible. P.S: To start a new thread, please use the New Message feature in your email program; don't Reply to unrelated messages as this messes up the threading. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: A few pointers about launchd and daemondo
On Nov 4, 2009, at 17:54, Scott Haneda wrote: I have moved to making my own normal .plist files and putting them in files/tld.app.binary.plist, so org.pure-ftpd.ftpd.plist or similar. Since pure-ftpd's web site is pureftpd.org (not pure-ftpd.org which appears to be owned by a domain squatter), the name of the plist should be org.pureftpd.whatever (not org.pure-ftpd.whatever). ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: HDF5 dilemma
Hi,
while I am still marked as maintainer of hdf-16, I am actually using
hdf-18 exclusively...
On 09.11.2009, at 00:14, Mark Moll wrote:
HDF5 1.6.10 and HDF5 1.8.4 are currently in prerelease. HDF5 1.6.10
is the last release of the 1.6.x series. HDF5 1.8.x can also be
compiled in 1.6.x compatibility mode, but this shouldn’t be done by
default. I think it’s hard make a case for the hdf5_select approach
you suggest. First, there’s only 2 or 3 ports that need hdf5 1.6 (I
think). Second, with gcc and python there really are many versions
simultaneously in use. The cost of switching versions is significant
with gcc and python and it makes sense to support multiple versions.
I think the easiest solution would be to mark the two ports
conflicting in the Portfile (as pointed out by Ryan).
If there is considerable interest in having both ports around and
active at the same time, then we should provide a hdf5_select…
I believe there is still considerable amounts of software around that
relies on hdf5-1.6, isn't it? Most of it expects the headers directly
in C_INCLUDE_PTH (or alike).
Since I am the maintainer of the hdf5-18 port I might be somewhat
biased, but the least bad solution might be to have the hdf5 port
install its files in ${prefix}/lib/hdf5-16/.
And the equivalent for hdf5-18, and then a hdf5_select that symlinks
one of the two to $prefix/include and such…
Versioned libraries could always go to ${prefix}/lib, so selecting is
compile time, but using is always possible…
Sorry, I don't have time right now to do any of this (besides the
possible conflict statement), but feel free to change the Portfile
appropriately or take over maintainership altogether.
On Nov 6, 2009, at 5:34 PM, Darren Weber wrote:
I've got a hdf5 dilemma ;-)
$ port installed hdf5*
The following ports are currently installed:
hdf5 @1.6.9_0+threadsafe (active)
hdf5-18 @1.8.3_0
hdf5-18 @1.8.3_1
$ sudo port activate hdf5-18 @1.8.3_1
--- Activating hdf5-18 @1.8.3_1
Error: port activate failed: Image error: /opt/local/bin/gif2h5 is
being used by the active hdf5 port. Please deactivate this port
first, or use 'port -f activate hdf5-18' to force the activation.
The hdf5 and hdf5-18 ports are behaving like separate ports, up to
the point of activation conflicts. There are two maintainers for
these ports (in the CC list of this email); can we get together on
this and work out the activation conflict?
Is it possible to have multiple version specific libs/bins
installed? Is it as simple as providing some version specific file-
name mangles (with symlinks and maybe a hdf5_select utility like
the gcc_select or python_select utility)?
A quick search on the user email list brings up a number of ports
that depend on hdf5 with dependency build issues.
What is the current status of play on hdf5 and what is the
recommended version to have installed?
Greetings,
Jochen
--
Einigkeit und Recht und Freiheithttp://www.Jochen-Kuepper.de
Liberté, Égalité, FraternitéGnuPG key: CC1B0B4D
Sex, drugs and rock-n-roll
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Wine error message
Hello, PowerPC Microprocessor Family: The Programming Environments and MPC7450 RISC Miicroprocessor Family Reference Manual. More wading in the latter because it covers all the MPC-74XX series. . On Nov 8, 2009, at 11:44 PM, Ryan Schmidt wrote: On Nov 6, 2009, at 19:15, Frank J. R. Hanstick wrote: I realize that wine is a Mactel only program; but, the error message: Error: wine can only be used on an Intel Mac or other computer with a little-endian processor. Error: Target org.macports.fetch returned: incompatible processor Error: Status 1 encountered during processing. is misleading with the or other computer with a little-endian processor since a PowerPC could run as both big-endian and little- endian. I had no idea that was the case. Where can I read more about that? I didn't want to just say Intel Mac, since MacPorts theoretically runs on non-Macs as well, many of which will be x86-based and thus should be able to use wine. Frank J. R. Hanstick tro...@comcast.net ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: A few pointers about launchd and daemondo
On Nov 9, 2009, at 12:21 AM, Ryan Schmidt wrote: On Nov 4, 2009, at 17:54, Scott Haneda wrote: I have moved to making my own normal .plist files and putting them in files/tld.app.binary.plist, so org.pure-ftpd.ftpd.plist or similar. Since pure-ftpd's web site is pureftpd.org (not pure-ftpd.org which appears to be owned by a domain squatter), the name of the plist should be org.pureftpd.whatever (not org.pure-ftpd.whatever). I have been meaning to ask about this, as the current port is pureftpd, and mind is pure-ftpd. All binaries are pure-ftpd, the only thing that is not is the webite. The app is Pure-FTPd. When I work out this variant conflicts issue, what is the procedure for the fact there is an old per with the name of pureftpd, and I am going with pure-ftpd? Where does it state the the correct naming conventions for laaunchd plists? I never knew the name was supposed to resolve back to the reverse of the website. What do you do on a hosted site, for example: developersfiles.com/imagetool - com.developersfiles.imagetool ? Seems weird to hold them all under a domain that just hosts the files. SF.net being one of them, but they at least use projectname.sourceforge.net And then, all this is in macports, so maybe I should use org.macports.pure-ftpd.whatever. -- Scott * If you contact me off list replace talklists@ with scott@ * ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: daemondo / launchd just being silly on me
On Mon, Nov 9, 2009 at 1:51 AM, Scott Haneda talkli...@newgeo.com wrote:
I do not know anything about stompserver. How I would debug this...
Can you start the server by hand, on the command line? If so, sounds like
you are doing pretty good. Are you sure that --working_dir=/var is
correct? My understanding is that path is a portfile violation,
* Yes, can start it on the command line no probs.
* Yes, am aware that the path should be /opt/var,
/opt/var/ would be fine for this stompserver ruby gem. That
particular one is easy to configure. However the stompserver is just a
pilot and the simplest case for me to get going with. The chef gem,
and chef-server gems are not so easy. Posix /var paths are hardcoded
everywhere in 3 init scripts. Which are distributed as part of a ruby
gem.
Init scripts:
http://github.com/opscode/chef/tree/master/chef/distro/redhat/etc/init.d/
The idea is not to re-invent the wheel, so we would use:
startupitem.{start, stop, restart} to get launchd to call all these
init scripts.
There would be 4 plist files in total.
Then again, any launchd item installed by MP is going outside of ${prefix},
so there have been provisions to allow it. Though it is just a symblink.
Maybe you need --working_dir=${prefix}/var to keep everything in prefix?
So you would have to symlink the files from /opt/var to /var? I was
unsure how reasonable that is compared to just using /var. But it
probably would look like this:
/opt/var/run/chef/
/opt/var/log/chef/
/opt/var/log/stompserver.log
/opt/var/log/stompserver.pid
/var/log/chef/ - /opt/var/log/chef
/var/run/chef/ - /opt/var/run/chef
And with 3 lockfiles left remaining in /var
It would be inadvisable to move them.
/var/lock/subsys/chef-client
/var/lock/subsys/chef-indexer
/var/lock/subsys/chef-server
If you can run via command line, great, you can then point the finger at
debugging around the launchd item. At that point, I wold make a basic
launchd item by hand. Look at something like com.apple.ReportCrash.plist
for a basic shell template to use.
Okay, do you mean still calling daemondo or avoiding daemondo?
Its my impression that this error is an execvp() fail in daemondo/main.c.
Shouldn't i just recompile daemondo to printf() the execvup() arguments?
I have seen manually written plist examles to call other ruby programs
(as a daemon/server). But it seems like an backward step when
startupitem... in a portfile should do it for you. Also can the alias
command port load stomperver port unload stompserver still work
with a manual plist ? How to put a manual plist in a portfile rather
than using a startupitem declaration?
For example, I have a backup script, called at 12:15 AM daily, it calls a
shell script, which yours could do, or if it is simple, it can just call the
one command you need to run.
Are you suggesting to wrap the ruby script in a bash script?
Have not tried that yet.
...
...
...
Launchd is picky about paths, spaced, arguments with leading double dashes,
and a number of things. Aside from the most basic one liner scripts. I
shove my core code logic in a executable file, and then let launchd cal
that.
Hmm, if this were true, then it would be some plist creation error in
startupitem.
Since I do not know about stompserver, all I can add is, get it running, and
see if you can get it running with a standard launchd item. Watch your
system.log wen you load and unload. ( tail -f /var/log/system.log )
Watch the system log when you start via daemondo, it can be telling in a
number of ways. If you get it working via your own launchd, you can decide
to just bundle the plist in files, xinstall it into place, or just ui
message the user on what to do.
I guess this answers 2 earlier question, as i have been reading this.
Thank you, that makes a lot of sense now.
Another thing seems to be that in my case I am simply writing a Port
to distribute launchd scripts. (the actual software can all be
installed with rubygems package management system). So for the case of
having as many as 4+ plist files, they could be all packaged into 1
Port if they were manually added to /files subdir ? This is quite a
benefit because startupitem.executable seems to limit to 1 plist
file per Portfile.
I wonder if the port load tagname, port unload tagname alias will
work for such a manual plist. It is a new convenience that was
recently added to macports.
I do something like this: ( as a ui message )
To install the launchd item, issue the following commands:
cd ${prefix}/share/doc/${name}/
sudo cp org.pure-ftpd.ftpd.plist.server.sample
/Library/LaunchDaemons/org.pure-ftpd.ftpd.plist
- or -
sudo cp org.pure-ftpd.ftpd.plist.basic.sample
/Library/LaunchDaemons/org.pure-ftpd.ftpd.plist
- and then load the launchd item -
sudo launchctl load -w
/Library/LaunchDaemons/org.pure-ftpd.ftpd.plist
You can now test the server with:
Re: Gimp.app crashing
A problem may be that gimp won't compile on Snow Leopard, at least for me. Ryan Schmidt wrote: On Nov 8, 2009, at 10:09, Jeff Pitman wrote: Yes, I was running the no_x11/quartz version. However, I mixed everything up and upgraded to Snow Leopard over the weekend. Did you afterwards uninstall and reinstall all ports? If not, please do: http://trac.macports.org/wiki/Migration ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Gimp.app crashing
On Mon, Nov 9, 2009 at 3:57 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Nov 8, 2009, at 10:09, Jeff Pitman wrote: Yes, I was running the no_x11/quartz version. However, I mixed everything up and upgraded to Snow Leopard over the weekend. Did you afterwards uninstall and reinstall all ports? If not, please do: http://trac.macports.org/wiki/Migration Yes, I cleared out all of the packages first. If gimp-app didn't pull in python25 python26, I might be able to get this up without installing Tk. python26 has an option to shut off tkinter, but python25 has no such option. $ sudo port install python26 +no_tkinter # with +no_python, gimp prolly won't need this $ sudo port install pango +no_x11 +quartz $ sudo port install cairo +no_x11 +quartz $ sudo port install gtk2 +no_x11 +quartz $ sudo port install gimp2 +no_x11 +quartz +no_python $ sudo port install gimp-app +quartz gimp-app also pulls in a ton of dependencies like gcc43 and other random stuff. It'd be nice to go through this and clean up. I'm still churning through the deps right now, I'll reply back to the list with the full instructions. Gotta re-piece the deps and get the variant incantations correct.. take care, jeff ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Gimp.app crashing
On Mon, Nov 9, 2009 at 10:27 PM, Jeff Pitman jeff.pit...@gmail.com wrote: If gimp-app didn't pull in python25 python26, I might be able to get this up without installing Tk. python26 has an option to shut off tkinter, but python25 has no such option. $ sudo port install python26 +no_tkinter # with +no_python, gimp prolly won't need this $ sudo port install pango +no_x11 +quartz $ sudo port install cairo +no_x11 +quartz $ sudo port install gtk2 +no_x11 +quartz $ sudo port install gimp2 +no_x11 +quartz +no_python Before building gimp2, go through the patch incantations documented near the bottom of this bug: http://trac.macports.org/ticket/21011 $ sudo port install gimp-app +quartz Before building gimp-app, go through the following steps in this bug to compile 32-bit version: http://trac.macports.org/ticket/21718 Hmm, doesn't seem to work since Pango just generates blocks for the fonts. Perhaps it's due to 32-bit app invoking 64-bit libs. Ah well, all the appropriate bugs are filed. So, just need to be patient while folks work out the issues. take care, jeff ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: PostGIS / libproj Issues
Hi, I was wondering if there was any progress here. I updated the ticket with the debug output and did a MacPort migration to OS X 10.6 by the directions. Thanks. -Abe On Sun, Oct 11, 2009 at 6:07 AM, Ryan Schmidt ryandes...@macports.org wrote: On Oct 11, 2009, at 02:14, Abram Gillespie wrote: On Fri, Oct 9, 2009 at 6:31 PM, Ryan Schmidt wrote: On Oct 9, 2009, at 14:10, Abram Gillespie wrote: I'm getting an error when installing PostGIS. [snip] Please file a ticket in the issue tracker and provide more information including the full debug output of your attempted installation. Sure will. But how do I get the full debug output? sudo port clean postgis sudo port -d install postgis build.jobs=1 21 | tee ~/Desktop/postgis.txt The debug output will be displayed onscreen and saved in the file postgis.txt on your desktop, from which you can attach it to your Trac ticket if it fails again. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: qt3-mac
The PATH is correctly set but 'which qt3-mac' returns nothing...
'port contents qt-mac' shows me (from a long file list) :
/opt/local/share/qt3/mkspecs/macx-g++/
/opt/local/bin/moc/
/opt/local/bin/qmake/
but nowhere i can find something that looks like /opt/local/bin/qt3-
mac...
I think I miss something but what?
Will
Le 9 nov. 09 à 04:14, Scott Haneda a écrit :
Looking at the Portfile, it looks like things go into ${prefix}/
share/qt3, so probably /opt/local/share/qt3
You can try `which qt3-mac` which may show you the path, but you
should already have your path set to locate it.
See this section http://guide.macports.org/#installing.shell.postflight
about $PATH if when you run `echo $PATH` in the terminal, you do
not see the location of qt3-mac in that path.
Also, try `port contents qt3-mac` which will show you every single
piece of software that was installed for that port.
--
Scott * If you contact me off list replace talklists@ with scott@ *
On Nov 8, 2009, at 1:21 PM, wilfried rabaud wrote:
Hello,
I have installed the qt3-mac port (all goes fine) to compile qcad
from the source . To do so, I have to set the env. variable QTDIR
and QMAKESPECS, but infortunately I am not able to find the
executable files for Qt3. Does anyone knows where is located this
executables?
MacPort 1.8
10.5.8 Leopard
-
Wilfried Rabaud
ew...@free.fr
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Error during p5-xml-parser installation
Thanks, it worked - at least for p5-xml-parser. It fails at opencv now: --- Computing dependencies for opencv --- Building opencv Error: Target org.macports.build returned: shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_opencv/work/opencv-1.0.0 /usr/bin/make -j2 all returned error 2 Command output: /usr/bin/make all-recursive Making all in cxcore Making all in src if /bin/sh ../../libtool --tag=CXX --mode=compile /usr/bin/g++-4.2 -DHAVE_CONFIG_H -I. -I. -I../.. -I. -I../../cxcore/include -I../.. -DNDEBUG -I/opt/local/include -Wall -fno-rtti -pipe -O3 -g -march=prescott -ffast-math -fomit-frame-pointer -O2 -I/opt/local/include -L/opt/local/lib -arch x86_64 -MT dummy.lo -MD -MP -MF .deps/dummy.Tpo -c -o dummy.lo dummy.cpp; \ then mv -f .deps/dummy.Tpo .deps/dummy.Plo; else rm -f .deps/dummy.Tpo; exit 1; fi if /bin/sh ../../libtool --tag=CXX --mode=compile /usr/bin/g++-4.2 -DHAVE_CONFIG_H -I. -I. -I../.. -I. -I../../cxcore/include -I../.. -DNDEBUG -I/opt/local/include -Wall -fno-rtti -pipe -O3 -g -march=prescott -ffast-math -fomit-frame-pointer -O2 -I/opt/local/include -L/opt/local/lib -arch x86_64 -MT cxalloc.lo -MD -MP -MF .deps/cxalloc.Tpo -c -o cxalloc.lo cxalloc.cpp; \ then mv -f .deps/cxalloc.Tpo .deps/cxalloc.Plo; else rm -f .deps/cxalloc.Tpo; exit 1; fi /usr/bin/g++-4.2 -DHAVE_CONFIG_H -I. -I. -I../.. -I. -I../../cxcore/include -I../.. -DNDEBUG -I/opt/local/include -Wall -fno-rtti -pipe -O3 -g -march=prescott -ffast-math -fomit-frame-pointer -O2 -I/opt/local/include -L/opt/local/lib -arch x86_64 -MT dummy.lo -MD -MP -MF .deps/dummy.Tpo -c dummy.cpp -fno-common -DPIC -o .libs/dummy.o /usr/bin/g++-4.2 -DHAVE_CONFIG_H -I. -I. -I../.. -I. -I../../cxcore/include -I../.. -DNDEBUG -I/opt/local/include -Wall -fno-rtti -pipe -O3 -g -march=prescott -ffast-math -fomit-frame-pointer -O2 -I/opt/local/include -L/opt/local/lib -arch x86_64 -MT cxalloc.lo -MD -MP -MF .deps/cxalloc.Tpo -c cxalloc.cpp -fno-common -DPIC -o .libs/cxalloc.o dummy.cpp:1: error: CPU you selected does not support x86-64 instruction set dummy.cpp:1: error: CPU you selected does not support x86-64 instruction set cxalloc.cpp:1: error: CPU you selected does not support x86-64 instruction set cxalloc.cpp:1: error: CPU you selected does not support x86-64 instruction set make[3]: *** [cxalloc.lo] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: *** [dummy.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Error: Status 1 encountered during processing. Any suggestion? Thanks. 2009/11/9 Ryan Schmidt ryandes...@macports.org On Nov 8, 2009, at 15:53, Jakob Vidmar wrote: I've just tried installing p5-xml-parser and this happened: --- Computing dependencies for p5-xml-parser --- Configuring p5-xml-parser 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_perl_p5-xml-parser/work/XML-Parser-2.36 /opt/local/bin/perl Makefile.PL INSTALLDIRS=vendor returned error 139 Command output: sh: line 1: 886 Segmentation fault /opt/local/bin/perl Makefile.PL INSTALLDIRS=vendor Error: Status 1 encountered during processing. Anyone mind shedding some light? Thanks. PS) I'm using macports on Snow Leopard. Did you recently upgrade to Snow Leopard from a prior OS? If so, did you uninstall and then reinstall all ports? You need to; see the Migration page for details: http://trac.macports.org/wiki/Migration ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Installation/port-upgrade problems
Dear Sir, On 09 Νοε 2009, at 5:10 μ.μ., Darren Temple wrote: Hello macports-users, I've been trying to install and start using macports recently, for the intention of installing KDE for use of the Kate and Kile programs, but keep running into problems. I had OS X 10.5.8 installed initially, with the most recent release of X11 but not the most recent XCode tools, which requires Snow Leopard. I managed to install macports with this setup, but found a problem when I came to use it which issued a message about XCode tools needing updating. Seeing as I was expecting to upgrade to Snow Leopard soon, I thought I'd do this first before trying macports again. My system is now as follows :- - Snow Leopard (updated to version 10.6.1) - XCode tools 3.2.1 - X11 2.3.4 I have installed Macports using the easy disk-image/package method, which seemed to be successful. I next ran the command sudo port selfupdate which seemed to work fine, but then running port upgrade outdated I get the following :- * Macintosh:~ Ren$ port upgrade outdated MacPorts running without privileges. You may be unable to complete certain actions (eg install). --- Computing dependencies for openssl MacPorts running without privileges. You may be unable to complete certain actions (eg install). MacPorts running without privileges. You may be unable to complete certain actions (eg install). MacPorts running without privileges. You may be unable to complete certain actions (eg install). MacPorts running without privileges. You may be unable to complete certain actions (eg install). MacPorts running without privileges. You may be unable to complete certain actions (eg install). MacPorts running without privileges. You may be unable to complete certain actions (eg install). --- Building openssl Error: Target org.macports.build returned: shell command cd / Users/Ren/.macports/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_openssl /work/openssl-0.9.8l /usr/bin/make all returned error 2 Command output: ld: warning: in /opt/local/lib/libz.dylib, file is not of required architecture Undefined symbols: _inflateEnd, referenced from: _bio_zlib_free in libcrypto.a(c_zlib.o) _zlib_stateful_free_ex_data in libcrypto.a(c_zlib.o) _deflate, referenced from: _bio_zlib_ctrl in libcrypto.a(c_zlib.o) _bio_zlib_write in libcrypto.a(c_zlib.o) _zlib_stateful_compress_block in libcrypto.a(c_zlib.o) _deflateEnd, referenced from: _bio_zlib_free in libcrypto.a(c_zlib.o) _zlib_stateful_free_ex_data in libcrypto.a(c_zlib.o) _inflateInit_, referenced from: _bio_zlib_read in libcrypto.a(c_zlib.o) _zlib_stateful_init in libcrypto.a(c_zlib.o) _zError, referenced from: _bio_zlib_ctrl in libcrypto.a(c_zlib.o) _bio_zlib_read in libcrypto.a(c_zlib.o) _bio_zlib_write in libcrypto.a(c_zlib.o) _deflateInit_, referenced from: _bio_zlib_write in libcrypto.a(c_zlib.o) _zlib_stateful_init in libcrypto.a(c_zlib.o) _inflate, referenced from: _bio_zlib_read in libcrypto.a(c_zlib.o) _zlib_stateful_expand_block in libcrypto.a(c_zlib.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [link_a.darwin] Error 1 make[1]: *** [do_darwin-shared] Error 2 make: *** [libcrypto.0.9.8.dylib] Error 2 Error: Unable to upgrade port: 1 * Following this, I tried installing the kdebase4 port, just to see if macports would work regardless of this last message. Here is the result of this action :- * Macintosh:~ Ren$ sudo port install kdebase4 Password: Warning: Skipping upgrade since ncursesw 5.7_0 = ncursesw 5.7_0, even though installed variants do not match +darwin_10. Use 'upgrade --enforce-variants' to switch to the requested variants. Warning: Skipping upgrade since ncurses 5.7_0 = ncurses 5.7_0, even though installed variants do not match +darwin_10. Use 'upgrade --enforce-variants' to switch to the requested variants. --- Computing dependencies for openssl --- Building openssl Error: Target org.macports.build returned: shell command cd /opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_openssl /work/openssl-0.9.8l /usr/bin/make all returned error 2 Command output: ld: warning: in /opt/local/lib/libz.dylib, file is not of required architecture Undefined symbols: _inflateEnd, referenced from: _bio_zlib_free in libcrypto.a(c_zlib.o) _zlib_stateful_free_ex_data in libcrypto.a(c_zlib.o) _deflate, referenced from: _bio_zlib_ctrl in libcrypto.a(c_zlib.o) _bio_zlib_write in libcrypto.a(c_zlib.o) _zlib_stateful_compress_block in libcrypto.a(c_zlib.o) _deflateEnd, referenced from: _bio_zlib_free in libcrypto.a(c_zlib.o) _zlib_stateful_free_ex_data in libcrypto.a(c_zlib.o) _inflateInit_, referenced from: _bio_zlib_read in libcrypto.a(c_zlib.o) _zlib_stateful_init in libcrypto.a(c_zlib.o)
Re: A few pointers about launchd and daemondo
On Nov 9, 2009, at 04:50, Scott Haneda wrote: On Nov 9, 2009, at 12:21 AM, Ryan Schmidt wrote: On Nov 4, 2009, at 17:54, Scott Haneda wrote: I have moved to making my own normal .plist files and putting them in files/tld.app.binary.plist, so org.pure-ftpd.ftpd.plist or similar. Since pure-ftpd's web site is pureftpd.org (not pure-ftpd.org which appears to be owned by a domain squatter), the name of the plist should be org.pureftpd.whatever (not org.pure-ftpd.whatever). I have been meaning to ask about this, as the current port is pureftpd, and mind is pure-ftpd. All binaries are pure-ftpd, the only thing that is not is the webite. The app is Pure-FTPd. When I work out this variant conflicts issue, what is the procedure for the fact there is an old per with the name of pureftpd, and I am going with pure-ftpd? Prior to MacPorts 1.8.0, the advice was: never rename a port, because we have no facility for supporting that. Now we do: the replaced_by keyword. So if you want to change the port name, you would leave a stub port called pureftpd which says it has been replaced_by pure- ftpd. This way, anybody who already has the port pureftpd installed will be properly advised to upgrade to pure-ftpd via port outdated. Note the port name doesn't have to match the binary name (though I can see how it might be clearer). For example, the port pkgconfig installs the binary pkg-config. Where does it state the the correct naming conventions for laaunchd plists? http://developer.apple.com/macosx/launchd.html Apple suggests the use of the reverse-DNS naming convention; for instance, com.apple.syslogd.plist. This is an excellent convention, and you should follow it when defining your own services. I never knew the name was supposed to resolve back to the reverse of the website. What do you do on a hosted site, for example: developersfiles.com/imagetool - com.developersfiles.imagetool ? Could be. Seems weird to hold them all under a domain that just hosts the files. SF.net being one of them, but they at least use projectname.sourceforge.net The files do not need to live on the domain; the purpose of the naming convention is to avoid filename clashes on the user's computer. To achieve this, the files are named using the reverse of a domain name that you or the project owns. And then, all this is in macports, so maybe I should use org.macports.pure-ftpd.whatever. The launchd plists MacPorts automatically creates for you with the startupitem keywords do use the org.macports prefix, so that would be appropriate. Before I used MacPorts, when I compiled software by hand and created my own plists for things, I used com.ryandesign as the prefix, because they were plists I had created. Even if the plist was for, say, the lighttpd web server, I didn't want to name the plist with the net.lighttpd prefix, because that seemed to imply to me that the developers of lighttpd had created the plist and were responsible for its content, which was not correct; I was. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Error during p5-xml-parser installation
On Nov 9, 2009, at 12:20, Jakob Vidmar wrote: Thanks, it worked - at least for p5-xml-parser. It fails at opencv now: This is the bug report for that: http://trac.macports.org/ticket/21014 I haven't read through all the comments yet. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: qt3-mac
On Nov 9, 2009, at 12:46 , wilfried rabaud wrote: The PATH is correctly set but 'which qt3-mac' returns nothing... 'port contents qt-mac' shows me (from a long file list) : /opt/local/share/qt3/mkspecs/macx-g++/ /opt/local/bin/moc/ /opt/local/bin/qmake/ but nowhere i can find something that looks like /opt/local/bin/qt3- mac... I think I miss something but what? That qt3 is a library, not a program? I would expect QTDIR to be something like /opt/local/lib/qt3. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: daemondo / launchd just being silly on me
You are a bit more advanced in your knowledge of C and other related
code, sorry I was not more help, comments interspersed below...
On Nov 9, 2009, at 4:09 AM, dreamcat four wrote:
On Mon, Nov 9, 2009 at 1:51 AM, Scott Haneda talkli...@newgeo.com
wrote:
I do not know anything about stompserver. How I would debug this...
Can you start the server by hand, on the command line? If so,
sounds like
you are doing pretty good. Are you sure that --working_dir=/var is
correct? My understanding is that path is a portfile violation,
* Yes, can start it on the command line no probs.
Well, then that pretty much points the finger to daemondo as far as I
can tell then.
The idea is not to re-invent the wheel, so we would use:
startupitem.{start, stop, restart} to get launchd to call all these
init scripts.
Yes, I see where you are coming from. I have never used those
commands. I only recently learned they were tied in like that, and
run just a few servers that needs restarting. When restarting
something like Apache just feels better to use ./apachectl graceful, I
tend to go with what the rest of the world is doing.
I already have enough explaining to do on other lists as to what
launchd even is :)
But I also have my own more general purpose way to restart services as
well. Probably did reinvent a wheel on that one, though my wheel is
pretty wobbly.
There would be 4 plist files in total.
Then again, any launchd item installed by MP is going outside of $
{prefix},
so there have been provisions to allow it. Though it is just a
symblink.
Maybe you need --working_dir=${prefix}/var to keep everything in
prefix?
So you would have to symlink the files from /opt/var to /var? I was
unsure how reasonable that is compared to just using /var. But it
probably would look like this:
/opt/var/run/chef/
/opt/var/log/chef/
/opt/var/log/stompserver.log
/opt/var/log/stompserver.pid
/var/log/chef/ - /opt/var/log/chef
/var/run/chef/ - /opt/var/run/chef
And with 3 lockfiles left remaining in /var
It would be inadvisable to move them.
/var/lock/subsys/chef-client
/var/lock/subsys/chef-indexer
/var/lock/subsys/chef-server
I am way out of my league here, but why symblink? Isn't the idea of
MacPorts to get everything into ${prefix}? If there is some path in
your software that is calling out to /var, then I think you need to
reinplace the source, or use a patchfile, to change the path. Or
perhaps talk to the developer to make it a build time argument that
changes the paths for you.
If you can run via command line, great, you can then point the
finger at
debugging around the launchd item. At that point, I wold make a
basic
launchd item by hand. Look at something like
com.apple.ReportCrash.plist
for a basic shell template to use.
Okay, do you mean still calling daemondo or avoiding daemondo?
I personally avoid it. I have just ran into issues with it, where it
was harder for me to understand. I am sure this is just my fault.
Looking at the files it makes, I find them difficult to understand
what is going on. Whereas a plist for launchd, could not be easier to
understand what is going on.
Its my impression that this error is an execvp() fail in daemondo/
main.c.
Shouldn't i just recompile daemondo to printf() the execvup()
arguments?
I think it is worth a try, if that gets this working how it should,
and there are no repercussions to other daemondo users, then seems a
bug worth fixing.
I have seen manually written plist examles to call other ruby programs
(as a daemon/server). But it seems like an backward step when
startupitem... in a portfile should do it for you. Also can the alias
command port load stomperver port unload stompserver still worky
with a manual plist ? How to put a manual plist in a portfile rather
than using a startupitem declaration?
I do not think that it would work so easily. *I think* `port load`
must call the Portfile in one of its phases, so you may have to alter
that phase to do what you want with your launchd item. I have never
tried this personally.
What I can gather, is at the end of the day, the Portfile is just a
tcl script, so you can do anything you want. MacPorts has built a
nice language helper on top of it, for making things easier, but it is
not to say you can not have your way with that Portfile in any way you
desire.
For example, I have a backup script, called at 12:15 AM daily, it
calls a
shell script, which yours could do, or if it is simple, it can just
call the
one command you need to run.
Are you suggesting to wrap the ruby script in a bash script?
Have not tried that yet.
That just depends on how the app gets started. A launchd item that
calls
/Users/me/bin/myapp is pretty sure to work.
However, a one liner along the lines of
while true; do bunch of stuff here, with and redirection; done;
never worked for me. I have to put that in a interim script,
Re: errors building atlas
I think you are right in that is the patch you need. I use the docs here to remember how to apply a patch: http://guide.macports.org/#development.patches -- Scott * If you contact me off list replace talklists@ with scott@ * On Nov 9, 2009, at 9:07 AM, Arden wrote: I have updated macports and then I ran upgrade outdated, fails with atlas. I see there is a bug filed #22379http://trac.macports.org/ticket/22379 and a possible patch? Not sure how to apply that one. Any help is appreciated. Arden Mac G4 PPC 10.4.1.1 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: A few pointers about launchd and daemondo
The app is Pure-FTPd. When I work out this variant conflicts issue, what is the procedure for the fact there is an old per with the name of pureftpd, and I am going with pure-ftpd? Prior to MacPorts 1.8.0, the advice was: never rename a port, because we have no facility for supporting that. Now we do: the replaced_by keyword. So if you want to change the port name, you would leave a stub port called pureftpd which says it has been replaced_by pure-ftpd. This way, anybody who already has the port pureftpd installed will be properly advised to upgrade to pure-ftpd via port outdated. Note the port name doesn't have to match the binary name (though I can see how it might be clearer). For example, the port pkgconfig installs the binary pkg-config. Seriously, every port I touch has some aspect to it that makes it more than just a straight port :) I used to hate p5's. I love p5's now. P5's are totally my friends, all other ports, I am making a list, when I go on my killing spree, alphabetical, keeping ASSP rightly at the top of that list Thanks for your other explanations, they were helpful, especially to see you had the same thoughts as I did wit using your name in a plist. -- Scott * If you contact me off list replace talklists@ with scott@ * ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: qt3-mac
Le 10 nov. 09 à 01:44, Brandon Allbery a écrit : On Nov 9, 2009, at 12:46 , wilfried rabaud wrote: The PATH is correctly set but 'which qt3-mac' returns nothing... 'port contents qt-mac' shows me (from a long file list) : /opt/local/share/qt3/mkspecs/macx-g++/ /opt/local/bin/moc/ /opt/local/bin/qmake/ but nowhere i can find something that looks like /opt/local/bin/qt3- mac... I think I miss something but what? That qt3 is a library, not a program? I would expect QTDIR to be something like /opt/local/lib/qt3. This is what have been installed in the lib/ : /opt/local/lib/libqt-mt.3.3.8.dylib /opt/local/lib/libqt-mt.3.3.dylib /opt/local/lib/libqt-mt.3.dylib /opt/local/lib/libqt-mt.dylib /opt/local/lib/libqt-mt.la /opt/local/lib/libqt-mt.prl /opt/local/lib/libqt.3.3.dylib /opt/local/lib/libqt.3.dylib /opt/local/lib/libqt.dylib which one is the good one ? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH - Wilfried Rabaud ew...@free.fr ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
