list element in braces followed by } instead of space
I have a local port repository under my home path where I am testing a new port for libpqxx (see attached). When I try to install this port, I get the following: [ [EMAIL PROTECTED] ~/ports ]$ sudo port install libpqxx Password: Portfile changed since last build; discarding previous state. --- Fetching libpqxx --- Verifying checksum(s) for libpqxx --- Extracting libpqxx --- Configuring libpqxx --- Building libpqxx with target all --- Staging libpqxx into destroot --- Installing libpqxx 2.6.9_0 list element in braces followed by } instead of space Error: Status 1 encountered during processing. Thereafter, I can't do anything with this port, eg: [ [EMAIL PROTECTED] ~/ports ]$ sudo port lint libpqxx list element in braces followed by } instead of space Error: Status 1 encountered during processing. [ [EMAIL PROTECTED] ~/ports ]$ sudo port clean --all libpqxx Portfile changed since last build; discarding previous state. list element in braces followed by } instead of space Error: Status 1 encountered during processing. [ [EMAIL PROTECTED] ~/ports ]$ sudo port install libpqxx list element in braces followed by } instead of space Error: Status 1 encountered during processing. Is this a sign of corruption somewhere in the macport registry or something? For instance: [ [EMAIL PROTECTED] ~/ports ]$ port -v installed Error: port installed failed: list element in braces followed by } instead of space No ports are installed. If so, how do I fix this? Thanks, Darren Portfile Description: Binary data ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: list element in braces followed by } instead of space
I've also run this debug command:
[ [EMAIL PROTECTED] ~/ports ]$ port -d installed
DEBUG: list element in braces followed by } instead of space
while executing
array set receipt_$ref $receipt_contents
(procedure receipt_flat::open_entry line 84)
invoked from within
${macports::registry.format}::open_entry $name $version $revision $variants
(procedure open_entry line 4)
invoked from within
open_entry $iname $iversion $irevision $ivariants
(procedure registry::installed line 13)
invoked from within
registry::installed
Error: port installed failed: list element in braces followed by }
instead of space
No ports are installed.
On Mon, Sep 22, 2008 at 1:06 PM, Darren Weber
[EMAIL PROTECTED] wrote:
I have a local port repository under my home path where I am testing a
new port for libpqxx (see attached). When I try to install this port,
I get the following:
[ [EMAIL PROTECTED] ~/ports ]$ sudo port install libpqxx
Password:
Portfile changed since last build; discarding previous state.
--- Fetching libpqxx
--- Verifying checksum(s) for libpqxx
--- Extracting libpqxx
--- Configuring libpqxx
--- Building libpqxx with target all
--- Staging libpqxx into destroot
--- Installing libpqxx 2.6.9_0
list element in braces followed by } instead of space
Error: Status 1 encountered during processing.
Thereafter, I can't do anything with this port, eg:
[ [EMAIL PROTECTED] ~/ports ]$ sudo port lint libpqxx
list element in braces followed by } instead of space
Error: Status 1 encountered during processing.
[ [EMAIL PROTECTED] ~/ports ]$ sudo port clean --all libpqxx
Portfile changed since last build; discarding previous state.
list element in braces followed by } instead of space
Error: Status 1 encountered during processing.
[ [EMAIL PROTECTED] ~/ports ]$ sudo port install libpqxx
list element in braces followed by } instead of space
Error: Status 1 encountered during processing.
Is this a sign of corruption somewhere in the macport registry or something?
For instance:
[ [EMAIL PROTECTED] ~/ports ]$ port -v installed
Error: port installed failed: list element in braces followed by }
instead of space
No ports are installed.
If so, how do I fix this?
Thanks, Darren
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: list element in braces followed by } instead of space
Yes, Ryan, the receipt contained a syntax problem, related to the long_description. I created a ticket about that problem, where I noted my solution (#16619). I've now created a new ticket to incorporate a port for libpqxx, Ticket #16621. It installs and uninstalls for me. It should be fully tested for functional integrity against the postgresql83 port. I've not had time to configure and run the functional tests. Thanks! On Mon, Sep 22, 2008 at 2:22 PM, Ryan Schmidt [EMAIL PROTECTED] wrote: On Sep 22, 2008, at 3:06 PM, Darren Weber wrote: I have a local port repository under my home path where I am testing a new port for libpqxx (see attached). When I try to install this port, I get the following: [ [EMAIL PROTECTED] ~/ports ]$ sudo port install libpqxx Password: Portfile changed since last build; discarding previous state. --- Fetching libpqxx --- Verifying checksum(s) for libpqxx --- Extracting libpqxx --- Configuring libpqxx --- Building libpqxx with target all --- Staging libpqxx into destroot --- Installing libpqxx 2.6.9_0 list element in braces followed by } instead of space Error: Status 1 encountered during processing. Thereafter, I can't do anything with this port, eg: [ [EMAIL PROTECTED] ~/ports ]$ sudo port lint libpqxx list element in braces followed by } instead of space Error: Status 1 encountered during processing. [ [EMAIL PROTECTED] ~/ports ]$ sudo port clean --all libpqxx Portfile changed since last build; discarding previous state. list element in braces followed by } instead of space Error: Status 1 encountered during processing. [ [EMAIL PROTECTED] ~/ports ]$ sudo port install libpqxx list element in braces followed by } instead of space Error: Status 1 encountered during processing. Is this a sign of corruption somewhere in the macport registry or something? Yes, this sounds like something wrong got written to the registry. Is it even called the registry? I don't know. Check the file /opt/local/var/macports/receipts/libpqxx/receipt.bz2 -- copy it somewhere else, decompress it, look into it, see if it looks like valid Tcl. Or attach it here and I'll look at it. My first guess would be the newlines in your long_description. I'm building it now myself to see what's happening, but it will take awhile to build the postgresql83 dependency and its dependencies. For instance: [ [EMAIL PROTECTED] ~/ports ]$ port -v installed Error: port installed failed: list element in braces followed by } instead of space No ports are installed. If so, how do I fix this? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: ruby - pg
Hi Tom, I'm playing around with the postgresql83 port (it's not my port, but I want to tweak a few things for it, so I have a copy of it in my private port repository). For postgresql 8.3.4, there is no build configure option to enable ruby (as there is for perl, python, tcl), but there is a port called rb-plruby that might provide ruby support within postgres. I'm not familiar with the port for 'ruby' or the port for 'rb-rubygems' and the operation of gems on OSX. I've done a quick google search and found this: http://people.planetpostgresql.org/jdavis/index.php?/archives/5-ruby-pg-is-now-the-official-postgres-ruby-gem.html Indications from the page linked above are that this problem requires a variant for the ruby port or something, as the postgresql connection might be a build option for ruby (not vice-versa - but see rb-plruby). So, I suggest you contact the ruby port maintainers and see if you can get a variant on the ruby port. If that might depend on something in postgresql83, then I might be able to help with that side of things. Best, Darren PS, If you want to see what happens to any port, try: port edit portname PPS, The rb-postgres port uses the ruby portgroup for config, see http://guide.macports.org/chunked/reference.portgroup.html On Mon, Oct 6, 2008 at 4:11 PM, Tom Allison [EMAIL PROTECTED] wrote: Well this is a sticky spot. None of the modules/packages/gems/ work and here's more. And now I will have three different installations of postgres running on a small macbook. I'm not sure this makes sense anymore. How is it that Perl has a DBI that is largely libpq independent and Ruby is largely .. not. Sign of maturity of the language? Bryan Blackburn wrote: On Mon, Oct 06, 2008 at 05:23:19PM -0400, Tom Allison said: I'm struggling here between the different mailing lists and postings. What I would like to get running is the ruby DBI on postgresql 8.3. macports seems to support 8.1 only. rubygems is mostly DOA every time I try to install and run them. They install without error, but cannot be loaded. Is there a path I need to set? Some other method? There's a lot pf pages out there talking about a lot of different packages available. As near as I can tell - ruby-pg is the one I want to install under the DBI library. For Ruby and DBI, it looks like you want to use the rb-dbi port with the dbd_pg variant for PostGreSQL. The dbd_pg variant requires the rb-postgres port which is what brings in postgresql81 unfortantely; there is a ticket about this: http://trac.macports.org/ticket/12703 Bryan One thing that is a must have is prepared statements for performance. I don't think ORM do this very well. ___ 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 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: ruby - pg
I've thrown together a new Portfile for ruby-pg, but I don't have the expertise to test it and debug it. I've put up a ticket for it at http://trac.macports.org/ticket/16814 Can someone with ruby experience get this working? It could be called from rb-dbi as a new variant that works with postgresql83. Best, Darren On Mon, Oct 6, 2008 at 4:11 PM, Tom Allison [EMAIL PROTECTED] wrote: Well this is a sticky spot. None of the modules/packages/gems/ work and here's more. And now I will have three different installations of postgres running on a small macbook. I'm not sure this makes sense anymore. How is it that Perl has a DBI that is largely libpq independent and Ruby is largely .. not. Sign of maturity of the language? Bryan Blackburn wrote: On Mon, Oct 06, 2008 at 05:23:19PM -0400, Tom Allison said: I'm struggling here between the different mailing lists and postings. What I would like to get running is the ruby DBI on postgresql 8.3. macports seems to support 8.1 only. rubygems is mostly DOA every time I try to install and run them. They install without error, but cannot be loaded. Is there a path I need to set? Some other method? There's a lot pf pages out there talking about a lot of different packages available. As near as I can tell - ruby-pg is the one I want to install under the DBI library. For Ruby and DBI, it looks like you want to use the rb-dbi port with the dbd_pg variant for PostGreSQL. The dbd_pg variant requires the rb-postgres port which is what brings in postgresql81 unfortantely; there is a ticket about this: http://trac.macports.org/ticket/12703 Bryan One thing that is a must have is prepared statements for performance. I don't think ORM do this very well. ___ 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 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Port fails to install as image. Problem with cleaning the registry.
I have a sandbox for some ports, including postgresql83-server (see attached) and I've got some issues with my installation. I'm curious about why the 'port clean --all portname' doesn't remove the registry entry? Here's a terminal session where I incur an issue with the registry and my port fails to install as an image: [ [EMAIL PROTECTED] ~/ports ]$ sudo port install postgresql83-server Password: Portfile changed since last build; discarding previous state. --- Fetching postgresql83-server --- Verifying checksum(s) for postgresql83-server --- Extracting postgresql83-server --- Configuring postgresql83-server --- Building postgresql83-server with target all --- Staging postgresql83-server into destroot --- Creating launchd control script ### # A startup item has been generated that will aid in # starting postgresql83-server with launchd. It is disabled # by default. Execute the following command to start it, # and to cause it to launch at startup: # # sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql83-server.plist ### --- Installing postgresql83-server 8.3.4_0 Error: Target org.macports.install returned: Registry error: postgresql83-server @8.3.4_0 already registered as installed. Please uninstall it first. Error: Status 1 encountered during processing. [ [EMAIL PROTECTED] ~/ports ]$ sudo port uninstall postgresql83-server --- Uninstalling postgresql83-server 8.3.4_0 [ [EMAIL PROTECTED] ~/ports ]$ sudo port clean --all postgresql83-server --- Cleaning postgresql83-server [ [EMAIL PROTECTED] ~/ports ]$ sudo port install postgresql83-server --- Fetching postgresql83-server --- Verifying checksum(s) for postgresql83-server --- Extracting postgresql83-server --- Configuring postgresql83-server --- Building postgresql83-server with target all --- Staging postgresql83-server into destroot --- Creating launchd control script ### # A startup item has been generated that will aid in # starting postgresql83-server with launchd. It is disabled # by default. Execute the following command to start it, # and to cause it to launch at startup: # # sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql83-server.plist ### --- Installing postgresql83-server 8.3.4_0 Error: Target org.macports.install returned: Registry error: postgresql83-server @8.3.4_0 already registered as installed. Please uninstall it first. Error: Status 1 encountered during processing. [ [EMAIL PROTECTED] ~/ports ]$ sudo rm /opt/local/var/macports/receipts/postgresql83-server/8.3.4_0/receipt.bz2 [ [EMAIL PROTECTED] ~/ports ]$ sudo port install postgresql83-server --- Installing postgresql83-server 8.3.4_0 To create a database instance, after install do %% sudo mkdir -p /opt/local/var/db/postgresql83/defaultdb %% sudo chown postgres:postgres /opt/local/var/db/postgresql83/defaultdb %% sudo su postgres -c '/opt/local/lib/postgresql83/bin/initdb -D /opt/local/var/db/postgresql83/defaultdb' To tweak your DBMS, consider increasing kern.sysv.shmmax by adding an increased kern.sysv.shmmax .. to /etc/sysctl.conf To load the startup deamon, run: %% sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql83-server.plist To unload the startup deamon, run: %% sudo launchctl unload -w /Library/LaunchDaemons/org.macports.postgresql83-server.plist Run 'port install pgAdmin3' to administer PostgreSQL Run 'port install slony1' to manage replication for PostgreSQL --- Activating postgresql83-server 8.3.4_0 Error: Target org.macports.activate returned: Image error: postgresql83-server @8.3.4_0 not installed as an image. Error: Status 1 encountered during processing. Portfile Description: video/flv ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Is there a print CSS for macports guide?
Does anyone have a CSS for printing the macports guide? I assume the web-page(s) for the guide are displayed with CSS controls. Can we get rid of the navigation (div?) and have the main content (div?) spread over the full-width of the page when printing? It should be easy to copy the screen CSS and modify the media tag for printing. This simple change would allow us to get a nice .pdf version when printing it on OSX too. Maybe a link to such a .pdf version would be really useful in the introduction? It would be useful to have a link in the macports guide introduction to the chunked version too, ie: http://guide.macports.org/chunked/ I only found it by a google search, there's no link to it from the macports site that I've seen yet. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
daemondo with postgresql83-server
I'm playing with a sandbox version of postgresql83-server and it contains
the following startup config:
set libdir ${prefix}/lib/postgresql83
set logdir ${prefix}/var/log/postgresql83
set dbdir ${prefix}/var/db/postgresql83/defaultdb
set dbpid ${dbdir}/postmaster.pid
set dbuser postgres
set dbgrp postgres
startupitem.create yes
startupitem.name${name}
startupitem.logfile ${logdir}/postgres.log
startupitem.logevents yes
startupitem.initPGCTL=${libdir}/bin/pg_ctl
startupitem.start \
su ${dbuser} -c \\${PGCTL} -D \${POSTGRESQL83DATA:=${dbdir}} start -w
-l ${logdir}/postgres.log -o \\\-i -l
startupitem.stop\
su ${dbuser} -c \\${PGCTL} -D \${POSTGRESQL83DATA:=${dbdir}} stop -s
-m fast\
startupitem.restart \
su ${dbuser} -c \\${PGCTL} -D \${POSTGRESQL83DATA:=${dbdir}} restart
-w -s -m fast\
startupitem.pidfile clean ${dbpid}
Is it possible to use startupitem.execute for postgresql83? The script
wrapper simply contains the pg_ctl commands listed above, maybe daemondo
could call pg_ctl directly? Maybe daemondo could be configured to replace
pg_ctl and call the postmaster directly?
The pid file (/opt/local/var/db/postgresql83/defaultdb/postmaster.pid) is
only available to user postgres:
-rw--- 1 500 postgres 67 Oct 13 20:12
/opt/local/var/db/postgresql83/defaultdb/postmaster.pid
It contains (pid in bold):
[ [EMAIL PROTECTED] ~ ]$ sudo cat
/opt/local/var/db/postgresql83/defaultdb/postmaster.pid
88055
/opt/local/var/db/postgresql83/defaultdb
5432001131072
Can daemondo read AND parse this file to get the pid and use it to monitor
the server? This is the relevant entries on the system from `ps aux | grep
post` (while running the server and pgAmin3 with one connection):
500 88060 0.3 0.084776400 ?? Ss Mon08PM 0:15.39
postgres: stats collector process
500 86574 0.0 0.087992 4208 ?? Ss2:05PM 0:00.13
postgres: postgres postgres 127.0.0.1(52101) idle
500 88059 0.0 0.086920584 ?? Ss Mon08PM 0:07.85
postgres: autovacuum launcher process
500 88058 0.0 0.086856436 ?? Ss Mon08PM 0:13.90
postgres: wal writer process
500 88057 0.0 0.086856752 ?? Ss Mon08PM 0:18.96
postgres: writer process
root 88044 0.0 0.075440772 ?? Ss Mon08PM 0:00.01
/opt/local/bin/daemondo --label=postgresql83-server --start-cmd
/opt/local/etc/LaunchDaemons/org.macports.postgresql83-server/postgresql83-server.wrapper
start ; --stop-cmd
/opt/local/etc/LaunchDaemons/org.macports.postgresql83-server/postgresql83-server.wrapper
stop ; --restart-cmd
/opt/local/etc/LaunchDaemons/org.macports.postgresql83-server/postgresql83-server.wrapper
restart ; --verbosity=1 --pid=fileauto --pidfile
/opt/local/var/db/postgresql83/defaultdb/postmaster.pid
daemon 359 0.0 0.077476308 ?? SFri04PM 0:00.00
postgres: stats collector process
daemon 357 0.0 0.078464228 ?? SFri04PM 0:00.00
postgres: stats buffer process
daemon 356 0.0 0.078908960 ?? SFri04PM 0:00.99
/System/Library/CoreServices/RemoteManagement/rmdb.bundle/bin/postmaster -D
/var/db/RemoteManagement/RMDB/rmdb.data
500 86580 0.0 0.087480 3700 ?? Ss2:07PM 0:00.01
postgres: postgres test 127.0.0.1(52109) idle
Note the pid file contains a reference to this process:
500 88055 0.0 0.086856 2384 s000 SMon08PM 0:05.13
/opt/local/lib/postgresql83/bin/postgres -D
/opt/local/var/db/postgresql83/defaultdb
Also note that this process seems to spawn several helpers, incl:
500 88060 0.3 0.084776400 ?? Ss Mon08PM 0:15.39
postgres: stats collector process
500 88059 0.0 0.086920584 ?? Ss Mon08PM 0:07.85
postgres: autovacuum launcher process
500 88058 0.0 0.086856436 ?? Ss Mon08PM 0:13.90
postgres: wal writer process
500 88057 0.0 0.086856752 ?? Ss Mon08PM 0:18.96
postgres: writer process
I could really appreciate some advice about how daemondo parses a pid file
and whether to modify this startupitem section of the port. Also appreciate
updated clarification of daemondo vs. launchd (an old email thread on this
from late 2007 was helpful [daemondo defeats purpose of launchd?], maybe
more so than the guide pages that resulted from that thread).
Thanks, Darren
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: daemondo with postgresql83-server
Thanks, Daniel. I discovered that my startup problems were related to SSL options - I did not create a server certificate. I now have a custom Portfile that is working with SSL enabled (after I created the server certificate). It is using daemondo to control the server. I'm trying to stay within the parameters of macports to get this running, and I can't see a way to create your .plist file directly. Anyhow, daemondo is monitoring the server by using a pid-file and it's working as expected. See my custom Portfile attached. I'll submit this to track for consideration. Best, Darren On Mon, Oct 20, 2008 at 9:04 AM, Daniel J. Luke [EMAIL PROTECTED] wrote: On Oct 17, 2008, at 5:31 PM, Darren Weber wrote: Is it possible to use startupitem.execute for postgresql83? Yes. The script wrapper simply contains the pg_ctl commands listed above, maybe daemondo could call pg_ctl directly? Yes, it could. Maybe daemondo could be configured to replace pg_ctl and call the postmaster directly? Probably, but the postgresql documentation recommends using pg_ctl (especially as you would have difficulty doing clean postgres shutdowns otherwise). Can daemondo read AND parse this file to get the pid and use it to monitor the server? Yes. I have a non-macports install of postgresql that uses daemondo and this works fine [1]. If you're curious, the code for daemondo isn't that large, and you can check it out yourself ( http://trac.macports.org/browser/trunk/base/src/programs/daemondo/main.c) I could really appreciate some advice about how daemondo parses a pid file and whether to modify this startupitem section of the port. If things are working, why do you need to modify it? Also appreciate updated clarification of daemondo vs. launchd (an old email thread on this from late 2007 was helpful [daemondo defeats purpose of launchd?], maybe more so than the guide pages that resulted from that thread). Launchd is the application starter on Mac OS X. It has an API that allows for more flexibility than exists with older methods of launching things. Daemondo helps applications that don't know about launchd fit into the launchd environment better. Apple has documentation on launchd you can read if you're interested in more details. -- Daniel J. Luke ++ | * [EMAIL PROTECTED] * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ 1. Here's the text of my launchd plist: ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN http://www.apple.com/D TDs/PropertyList-1.0.dtd plist version=1.0 dict keyDebug/key false/ keyGroupName/key stringpostgres/string keyLabel/key stringnet.geeklair.postgres/string keyOnDemand/key false/ keyProgramArguments/key array string/opt/local/bin/daemondo/string string--label=postgres/string string--start-cmd/string string/usr/local/pgsql/bin/pg_ctl/string stringstart/string string-o/string string-i/string string-D/string string/usr/local/pgsql/data/string string;/string string--stop-cmd/string string/usr/local/pgsql/bin/pg_ctl/string stringstop/string string-m/string stringfast/string string;/string string--restart-cmd/string string/usr/local/pgsql/bin/pg_ctl/string stringrestart/string string-m/string stringfast/string string-o/string string-i/string string-D/string string/usr/local/pgsql/data/string string;/string string--pid=fileauto/string string--pidfile=/usr/local/pgsql/data/postmaster.pid/string /array keyRunAtLoad/key false/ keyUserName/key stringpostgres/string /dict /plist Portfile Description: Binary data ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
macports stages - how to stop server processes?
RE: http://guide.macports.org/#reference.phases Can we define phases for deactivate and uninstall? For example, postgresql83-server is left running after doing uninstall. There should be an option to take down and remove any config data for a server process during the deactivate and uninstall phases. In the case of postgresql83-server, it is monitored by daemondo (which is watched by launchd), so we need to do a couple of things (not sure of the right order): a) sudo launchctl unload -w /Library/LaunchDaemons/org.macports.postgresql83-server.plist b) stop daemondo watching the server c) stop the server d) remove launch files e) remove config files (or maybe this is part of 'clean --all'). Any suggestions? Thanks, Darren PS, Come to think of it, it might be useful to be able to do these things when upgrading a server installation (ie: first stop and remove the current server). ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
What's up with trac?
Just tried to access http://trac.macports.org/newticket It returns rubbish - what's up? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
libIce conflict between xorg-libice and ice-cpp
Seems to be a conflict between xorg and ice-cpp over libice, eg: [ dwe...@elegans ~ ]$ sudo port install ice-cpp Password: --- Fetching ice-cpp Error: No defined site for tag: mcpp, using master_sites --- Attempting to fetch protobuf-patch-0.1.0.gz from http://distfiles.macports.org/ice-cpp --- Attempting to fetch Ice-3.3.0.tar.gz from http://distfiles.macports.org/ice-cpp Error: No defined site for tag: mcpp, using master_sites --- Attempting to fetch mcpp-2.7.tar.gz from http://voxel.dl.sourceforge.net/mcpp --- Verifying checksum(s) for ice-cpp --- Extracting ice-cpp --- Configuring ice-cpp --- Building ice-cpp --- Staging ice-cpp into destroot --- Installing ice-cpp @3.3.0_3 --- Activating ice-cpp @3.3.0_3 Error: Target org.macports.activate returned: Image error: /opt/local/lib/libIce.dylib is being used by the active xorg-libice port. Please deactivate this port first, or use the -f flag to force the activation. Error: Status 1 encountered during processing. What's the solution for this one? Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
port install efficiency issue
What is up with port? It just ran for about 15 mins to build a package that is already installed. If I were to work on the same damn thing, repeating it all day, day after day, I would get the sack pretty quickly. Just think of the useless load on the network and the servers for all those futile downloads, etc. So tell me, why shouldn't I switch to fink? At least Debian has a decent package management system, geez! $ sudo port install gettext --- Fetching gettext --- Verifying checksum(s) for gettext --- Extracting gettext --- Applying patches to gettext --- Configuring gettext --- Building gettext --- Staging gettext into destroot --- Installing gettext @0.17_4 Error: Target org.macports.install returned: Registry error: gettext @0.17_4 already registered as installed. Please uninstall it first. Error: Status 1 encountered during processing. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: port install efficiency issue
2009/3/22 Frank J. R. Hanstick tro...@comcast.net Hello, Wouldn't it be better and faster to do the check at request time rather than wait until everything has been done and then request if an update is wanted rather than an install? Frank Yes, sounds reasonable. Also, my apologies! Macports is great and so much so that I like to contribute to it whenever I can! http://trac.macports.org/wiki/dweber Yes, fink has some issues too! Nevertheless, I have used Debian (mostly Ubuntu) for a few years and I've lived to appreciate that system (despite some initial headaches with stable, unstable, ouch-bleeding on the testing stuff). For the most part, I think the dependency resolution and the upgrade process is amazing. I am very pleased to see this system available for OSX and I do hope it lives on in all it's wonder. I've made a move over to OSX for a new job and I guessed that macports would be the right way to go, basically because I guessed it would be a BSD system (or darwinports system) and I assumed that would be totally rock solid and efficient because it's been around for decades (even in those days of scheduled compilation). I'm a novice when it comes to BSD and OSX, so this is a great learning opportunity for me (even if I lose it sometimes). On balance, I'm both impressed and disappointed with the complexity of the macports system to date. For example, dependency resolution needs a lot of work during upgrades, binary distributions are a great idea in the making (perhaps forever in the making), and the whole issue of dependency on variants is a massive conference debate. I've certainly come across these issues and tried to submit reasonable trac suggestions for enhancements, etc. on a couple of ports. My main issue seems to be in getting a few ports with a lot of dependencies to cooperate, esp. with regard to variants (eg, Qt, Postgresql, MySQL, VTK, etc.). I do think that package maintainers should think very carefully about their default variants and try to provide as many options as possible - that seems to be the way with Debian packages. It seems to me that Debian uses a different set of packages for every major release, whereas macports tries to accommodate all the OSX flavours into every Portfile. Perhaps one way to reduce the confusion is to create branches in the port tree for each major OSX release and platform (PowerPC, intel, iphone; what's next?). Perhaps some of these things are rightly compiler variants or something, but how much easier it might be if you just choose the right branch for your platform to work on? I guess that raises the problem of where to edit the Portfile and management of multiple files in different branches - ouch. I don't know how that's done in Debian. Nevertheless, I will push on with macports and I'm trying to do my part to both support and encourage open-source systems. That's the bigger picture here and I'm very sorry that my frustration on this thread raised a relatively minor quibble about distribution systems. Unfortnately, my comments were emotional, but that's how it is sometimes and that's when you really feel that there has to be a better way. Patience is a virtue, I just lose it sometimes. Thankyou all for your understanding and, moreover, for the many reasonable suggestions to make macports even better. Take care, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
compile farm?
Is it possible to use the sourceforge compile farm to provide binary distros for macports? Perhaps cdash or something like it could be used? FYI: http://www.cdash.org/ Take care, Darren PS, I assume GNU savanna is not available for anything that depends on OSX (but does it also exclude BSD - darwin?). http://savannah.gnu.org/ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: port install efficiency issue
Is it possible to create a distributed build system that uses Xgrid, to allow all macport users the option of adding their machine to a distributed macports build system? In effect, every time anybody on this grid has to build a package from source, some kind of meta-package monitor can detect whether the build and install was successful and then make an inquiry of a central managment system as to whether or not this build should be added to the mirrors for binary distributions. If this inquiry was made before the build and a binary is available somewhere, the system simply downloads the binary (perhaps a torrent system). If the binary is not available, the build proceeds. If it's successful, the outcome of the build is added to the binary downloads available (ie, uploaded and distributed to mirrors to become an effective part of a torrent download system). Also, perhaps the Xgrid system can be used to create a distributed build system, regardless of what packages a user installs, but make sure that it uses idle systems (a lot like the scheduled builds of older days). For example: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ http://www.apple.com/downloads/dashboard/status/xgridstanford.html On Sun, Mar 22, 2009 at 5:54 PM, Joshua Root j...@macports.org wrote: Scott Haneda wrote: Can we talk more about this? I have the ability to host such a build farm. Now, I could not host one machine, of every architecture, of every OS, I just do not have the room in colocation. I do have quite a bit of room if we go 1U though. So 2 1U machines, a PPC and a Intel, and I would imagine, that PPC machine could go away a lot sooner than we all think. Mac Mini's could take it further, since they are so small, 8 of them can fit on a shelf and occupy no more than a few U's of space. The damn power bricks are more an issue than anything else. There have to be PPC Mini's out there to be had. As long as the various OS versions could be virtualized, so we could have 10.3, 10.4, 10.5, 10.6 and forward virtualized on each machine, it would not at all be hard to come up with a authentication routine to allow builds to happen on whatever virtual interface you want. I have the Ip space to spare, so each virtual machine could have it's own connection space, or we could do some simple dhcp pooling. Static IP's are something I was alloted a /24 of, and do not see giving up 20 or so of them being an issue. Am I looking at this wrong, or would this be helpful? Is this too much reliance on an outside party for core ports features? I have had access to this data center for 9+ years or so, I do not plan on giving up that access at any time soon. The bandwidth requirements are minimal, it would go unnoticed. Thanks for the offer. I think it's safe to say, though, that finding the hardware for a build farm will be a relatively minor issue. The main thing that is needed is the software. Server-side, to build all the ports in some kind of intelligent order and copy the archives to somewhere from which they can be downloaded by the client, with error reporting; and to keep doing this as needed when new versions and new ports are added. Client-side, to check for the presence of an archive with the desired version/variants on the server, and to download and unarchive it instead of building from source when possible. - Josh ___ 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: stable vs. unstable ports?
I like the idea of an opt-in Xgrid system, whereby users could opt-in to install an Xgrid client that provides a macports build system, binary distributions, and meta-ports monitor. Of course, some folks might interpret it as too much big-brother, but really it's just so common now to have integrated network clusters with two-way traffic. The opt-in and security settings on the facility may need integrity checking (code review - so specific commit rights and few maintainers with security access) and community monitoring to ensure security. Just about every major desktop system around has some kind of automated process monitoring and opt-in bug reporting (windows, mac OSX, gnome, etc.). I guess that Xgrid provides a nice platform for a distributed build system. I have no idea where to start with macports base. If I had time to learn it, I would try. Even so, I would hate to screw around with it without knowing what I'm doing. Is there any documentation on how to get started with hacking macports base - any kind of sandbox to play around with? Anyone know how to work with Xgrid? It's something on my todo list, but I've not read anything about it yet. Take care, Darren On Sun, Mar 22, 2009 at 5:18 PM, Joshua Root j...@macports.org wrote: Darren Weber wrote: I've noticed problems during port upgrades. What is the general consensus on having a TAG for each port to indicate it's success status within the system? Is it possible to have a meta-port monitor that automatically tracks the status of each package install and reports that status back to a central repository to continuously flag the status of a port install. A simple dichotomy of stable and unstable might suffice (Debian uses stable, unstable, and testing). Perhaps the monitoring system could provide the data required to justify these port status levels. IIRC, last time something like this was proposed, the consensus was that phoning home is evil and MacPorts shouldn't do it. (The focus then was more on collecting stats on how often each port is used.) Personally I don't see what the problem is as long as it's opt-in. Of course, if we had a build farm producing binaries (see discussion currently ongoing), this information could also be produced by it incidentally to its main function. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: compile farm?
An Xgrid system? On Sun, Mar 22, 2009 at 2:17 PM, Rainer Müller rai...@macports.org wrote: Darren Weber wrote: Is it possible to use the sourceforge compile farm to provide binary distros for macports? The sourceforge compile farm does not exist any more for at least two years now. Rainer ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: compile farm?
On Mon, Mar 23, 2009 at 12:33 AM, Ryan Schmidt ryandes...@macports.orgwrote: On Mar 23, 2009, at 01:11, Darren Weber wrote: On Sun, Mar 22, 2009 at 2:17 PM, Rainer Müller wrote: Darren Weber wrote: Is it possible to use the sourceforge compile farm to provide binary distros for macports? The sourceforge compile farm does not exist any more for at least two years now. An Xgrid system? As stated in Re: port install efficiency issue, finding computers to serve as a build farm should not be a problem. I believe our Apple representatives have even offered such resources already. What we need to discuss is how the build farm would work. Someone (apologies; I forget who) already worked on a script to build a port in a clean environment. I think what still is needed is to then package that up and send it to a download server. Then we need code in the MacPorts base code to check for and if available download those binaries instead of building from source. This suggestion may be too complicated, but it's a thought. Suppose it is possible to create a virtual machine or some kind of encapsulated clean environment (perhaps like a java sdk or something), which can contain any of the environments for OSX (10.x), or at least a standardized subset that is required by default for macports builds. Suppose such an environment could be run from within any OSX system as a virtual machine. Suppose such a virtual environment could be distributed on an Xgrid system, it could provide a distributed build system for macports. OK, back to reality... ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: compile farm?
On Mon, Mar 23, 2009 at 11:18 AM, Anders F Björklund a...@macports.orgwrote: Darren Weber wrote: This suggestion may be too complicated, but it's a thought. Suppose it is possible to create a virtual machine or some kind of encapsulated clean environment (perhaps like a java sdk or something), which can contain any of the environments for OSX (10.x), or at least a standardized subset that is required by default for macports builds. Suppose such an environment could be run from within any OSX system as a virtual machine. Suppose such a virtual environment could be distributed on an Xgrid system, it could provide a distributed build system for macports. This is called a chroot, and is what MPAB uses to build. See http://trac.macports.org/wiki/MPAB for all the details. OK, back to reality... Has been for a long time. --anders Hey, of course it exists! Why recreate the wheel? Yes, we are Standing of the shoulders of giants. I have it running on my system now, to learn more about it. I have an OSX 10.5.6 Server on a mac pro (2x quad core zeons, 24 Gb RAM). First thing I note is that the ReadMe.txt contains instructions for an svn export. Two thoughts about that: (a) it can automated as part of the script, (b) it uses trunk, but that could be any branch of the svn (eg, stable, unstable, testing, etc. and I would equate trunk with testing). I haven't looked into mpab itself, yet. Can it detect the current platform and make reasonable changes to the chroot for 10.x variants? When I run it, should I pipe the output to a log file? Do you think it is possible to adapt this for Xgrid compilation? Is it possible to have (a) the chroot images distributed, and (b) to have each of the port builds farmed out to different nodes on the grid. I assume that dependency issues prevent (b), so parallel builds of individual packages are not possible - is that right? Nevertheless, it should be possible to farm out the entire autobuild to nodes on a grid for idle-time compilations. Take care, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: port install efficiency issue
On Mon, Mar 23, 2009 at 11:58 AM, Joshua Root j...@macports.org wrote: Darren Weber wrote: when I look at a Portfile, I also take a little time to check out darwinports and Debian packages to learn something about how these software are built and distributed. I'm confused - is this a slip of the keyboard? DarwinPorts no longer exists, the name changed to MacPorts a few years ago. - Josh Sorry I should be referring to: http://www.freebsd.org/ports/ For example, http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/boaconstructor/ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: stable vs. unstable ports?
I've been working with macports under the mis-apprehension that it would operate along the lines of freeBSD (and some frustration may arise mostly from that lack of understanding). I decided that it's time for me to do some long-overdue homework. I've been working mostly with linux (and developed a preference for Debian-Ubuntu), so I need to get educated about BSD, as macports seems to follow that model (to some extent). In case it's of interest to others, I found a few interesting links online (I apologize if similar macports docs are available, I must check into that also): http://www.freebsd.org/ http://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/book.html http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.html http://www.freebsd.org/doc/en/books/handbook/using-sysinstall.html http://www.freebsd.org/doc/en/books/handbook/index.html Handbook downloads in multiple formats: ftp://ftp.freebsd.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/handbook/ http://www.lemis.com/grog/Documentation/CFBSD/ BSD jails (chroot) http://en.wikipedia.org/wiki/Chroot http://www.freebsd.org/doc/en/books/handbook/jails.html http://www.freebsd.org/doc/en/books/handbook/virtualization.html *NIX history http://www.freebsd.org/cgi/cvsweb.cgi/src/share/misc/bsd-family-tree?rev=1.115.2.3;content-type=text%2Fplain freebsd vs openbsd (vs netbsd) http://forums.whirlpool.net.au/forum-replies-archive.cfm/488714.html http://www.linuxquestions.org/questions/bsd-17/important-read-this-before-posting-177142/ http://www.serverwatch.com/tutorials/article.php/10825_3393051_1 BSD vs Linux http://www.over-yonder.net/~fullermd/rants/bsd4linux/bsd4linux1.php Bill Joy I find it curious that Bill Joy created chroot to build BSD and then went on to found Sun and probably contributed a lot to java design - perhaps the whole idea of a chroot to build BSD might have been just the right inspiration for the java vm and sdk. http://en.wikipedia.org/wiki/Bill_Joy http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_gift/ On Tue, Mar 24, 2009 at 8:25 PM, Shreevatsa R shreevatsa.pub...@gmail.comwrote: [Changing the topic from build systems and replying just to the original question] 2009/3/22 Darren Weber dwe...@macports.org: I've noticed problems during port upgrades. What is the general consensus on having a TAG for each port to indicate it's success status within the system? There is already a low-tech way of doing this: see if any bugs have been reported against the given port. :) Chances are that if others have had problems with upgrades, they would have (hopefully) filed a ticket against the port. Checking this is very easy to do thanks to Rainer Müller's recently implemented Trac report, e.g. use http://trac.macports.org/report/16?PORT=python25 to see if there are any recent bugs with the python25 port that you care about. Is it possible to have a meta-port monitor that automatically tracks the status of each package install and reports that status back to a central repository to continuously flag the status of a port install. A simple dichotomy of stable and unstable might suffice (Debian uses stable, unstable, and testing). Perhaps the monitoring system could provide the data required to justify these port status levels. Note that what Debian does is something quite a bit more: they have entirely different *sets* of ports marked stable, testing, unstable and users choose to install all their packages from the same set (tree). This is fine for Debian to do because they have enough people, but it would not be a good idea for MacPorts: having to maintain multiple sets of inter-compatible ports leads to too much fragmentation and the situation might end up similar to that with Fink: the stable ports work very well but are too outdated for most purposes, the unstable ports are really unstable and *still* quite a bit older than in MacPorts. Having only one current version of each port, which everyone gets and reports bugs against etc. is one of MacPorts's strengths. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: stable vs. unstable ports?
Recently, I was running something like update-all and there were some issues with the netCDF library. It was upgraded by the maintainer, who manually updated a dependency on HDF5 within their dev environment, who then put out a request to the HDF5 maintainer to update that package, but this could not happen because of other dependencies on HDF5. This situation persisted for quite some time. As a consequence, the netCDF package was broken during the upgrade process. (Please forgive me if any or all of these recollections are just plain wrong, but something like this happened and it's just the main idea that's important). Despite all the reasons why this might or might not be a good process model, I don't like it for daily work. For the purpose of my daily work, I do want a stable environment, I don't need to be on the cutting edge (or is that a bleeding edge). There are times when I want to get closer to the cutting edge - that's when I grab and modify the Portfile in my local repository and tinker with it (and any dependency issues, etc.). I do like the way this is possible in macports. However, for the vast majority of packages, I just want them to work, I want them to be stable and I want them to be nice to each other, to work in harmony. I would love an automated tagging system that can monitor the success or failure of port builds and trace this status through the dependency tree to automatically identify the conjunction of all stable ports. It should provide a report of that information to the maintainers of each package, indicating the status of builds (broken down by variants and including a relevant dependency list for each build-type that fails - not EVERY build, just the category of build that fails). All this currently happens in trac and it requires a lot of effort to monitor and manage it. Perhaps some of that effort could be spent on programming a meta-port monitor and status report system. In effect, macports already has multiplicity of ports for each package, mainly because there are separate ports for each major-minor release of a package (like postgresql-83, etc.) and so do many other port or package management systems. It's not uncommon for a large package management system to deal with the contingencies of multiple versions for a package, including installation of multiple versions at the same time (due to user preferences or due to package dependency). At some point, in some way, it is inevitable that a package management system must have some kind of stable - unstable tag on it's packages (ports), whether it is automatic or manual (ie, developer decisions). At present, it appears this is all manual in macports and there is no way for a user to use a simple category selector in the port program, but perhaps your suggestion for python is a move toward some level of automation. Thanks, Darren On Tue, Mar 24, 2009 at 8:25 PM, Shreevatsa R shreevatsa.pub...@gmail.comwrote: [Changing the topic from build systems and replying just to the original question] 2009/3/22 Darren Weber dwe...@macports.org: I've noticed problems during port upgrades. What is the general consensus on having a TAG for each port to indicate it's success status within the system? There is already a low-tech way of doing this: see if any bugs have been reported against the given port. :) Chances are that if others have had problems with upgrades, they would have (hopefully) filed a ticket against the port. Checking this is very easy to do thanks to Rainer Müller's recently implemented Trac report, e.g. use http://trac.macports.org/report/16?PORT=python25 to see if there are any recent bugs with the python25 port that you care about. Is it possible to have a meta-port monitor that automatically tracks the status of each package install and reports that status back to a central repository to continuously flag the status of a port install. A simple dichotomy of stable and unstable might suffice (Debian uses stable, unstable, and testing). Perhaps the monitoring system could provide the data required to justify these port status levels. Note that what Debian does is something quite a bit more: they have entirely different *sets* of ports marked stable, testing, unstable and users choose to install all their packages from the same set (tree). This is fine for Debian to do because they have enough people, but it would not be a good idea for MacPorts: having to maintain multiple sets of inter-compatible ports leads to too much fragmentation and the situation might end up similar to that with Fink: the stable ports work very well but are too outdated for most purposes, the unstable ports are really unstable and *still* quite a bit older than in MacPorts. Having only one current version of each port, which everyone gets and reports bugs against etc. is one of MacPorts's strengths. ___ macports-users mailing
Re: stable vs. unstable ports?
On Thu, Mar 26, 2009 at 2:09 PM, Dave Howell groups.20...@grandfenwick.netwrote: On Mar 23, 2009, at 0:38 , Ryan Schmidt wrote: Before we can allow arbitrary users to submit their builds to a central server, we would need to ensure that a build that occurs on one user's system is *identical* to the build on any other user's computer. This cannot currently be assured because MacPorts does not build in a chroot, and without this, it is possible for a port to link with libraries that happen to be on the user's system that it ought not link with -- be they libraries from other ports on which the port in question does not declare a dependency, or libraries in /usr/local, to which the compiler always looks. Would two identical builds be byte-identical? If so, then a binary doesn't become available until *two* (or three or whatever) identical binaries are uploaded. And/or, there's some command line library tool (I'm on vacation and my reference books are home) that I can run to get a listing of what libraries are called by a particular binary, isn't there? Wouldn't that help screen wacky-linked binaries? The deliberate uploading of contaminated binaries, however, is a whole different kettle of worms. :/ I've been running mpab for a few days now, ie: http://trac.macports.org/wiki/MPAB This is a chroot approach. Obviously, as it is, anyone could tinker with it to include a rootkit or whatever. Nevertheless, I wonder if it's possible to create a binary app of this, which is authenticated during installation (at least), and we ensure that it must do some handshaking to get hold of the official and secure port tree somehow (probably an encrypted handshake, encrypted file archive for download, etc.) and then it goes about it's business on a user machine and only does an upload (if any) when there is some kind of further authentication that the port build is correct (binary md5 etc. for at least 2-5 builds on the exact same configuration). Even if it does no uploads, it could create useful information about the stability or integrity (you name it) of the entire build process. It would be really neat to have an Xgrid controller (or many) be able to run a job that can parse out port dependencies and have some kind of parallelism in the build. Best, Darren PS, `man otool` can tell you just about anything you need to know about the binary file, eg otool -l /opt/local/bin/gls otool -L /opt/local/bin/gls ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Install from Binary Archives (was Re: port install efficiency issue)
On Thu, Mar 26, 2009 at 3:19 PM, Rainer Müller rai...@macports.org wrote: Dave Howell wrote: What about this: I do a ports install widget, ports looks for a binary, doesn't find one that matches (in this case, the default options and current version), so it goes about building it. When it's done, it says upload compiled binary to binary archives? I say Y, and up it goes. Now it's available for the next user who comes along. Sure, we would just distribute arbitrary binaries to end-users... NOT! Ever thought about security? What if I upload some rootkit instead of the real software and everyone installs it? No, this will not work. Rainer I've been running mpab for a few days now, ie: http://trac.macports.org/wiki/MPAB This is a chroot approach. Obviously, as it is, anyone could tinker with it to include a rootkit or whatever. Nevertheless, I wonder if it's possible to create a binary app of this, which is authenticated during installation (at least), and we ensure that it must do some handshaking to get hold of the official and secure port tree somehow (probably an encrypted handshake, encrypted file archive for download, etc.) and then it goes about it's business on a user machine and only does an upload (if any) when there is some kind of further authentication that the port build is correct (binary md5 etc. for at least 2-5 builds on the exact same configuration). Even if it does no uploads, it could create useful information about the stability or integrity (you name it) of the entire build process. It would be really neat to have an Xgrid controller (or many) be able to run a job that can parse out port dependencies and have some kind of parallelism in the build. Best, Darren PS, `man otool` can tell you just about anything you need to know about the binary file, eg otool -l /opt/local/bin/gls otool -L /opt/local/bin/gls ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: stable vs. unstable ports?
FYI, running mpab (without any mods) on a mac Pro system: Model Name:Mac Pro Model Identifier:MacPro3,1 Processor Name:Quad-Core Intel Xeon Processor Speed:2.8 GHz Number Of Processors:2 Total Number Of Cores:8 L2 Cache (per processor):12 MB Memory:24 GB Bus Speed:1.6 GHz It's been running since 11 am, Monday 23rd March, 2009. It's now: Fri Mar 27 11:22:21 PDT 2009 The auto-build is currently at: Building slib-guile (1645 of 5648)... I don't know how to interrogate the success or failure rates. Best, Darren On Thu, Mar 26, 2009 at 8:23 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Mar 26, 2009, at 17:51, Darren Weber wrote: On Thu, Mar 26, 2009 at 2:09 PM, Dave Howell wrote: On Mar 23, 2009, at 0:38 , Ryan Schmidt wrote: Before we can allow arbitrary users to submit their builds to a central server, we would need to ensure that a build that occurs on one user's system is *identical* to the build on any other user's computer. This cannot currently be assured because MacPorts does not build in a chroot, and without this, it is possible for a port to link with libraries that happen to be on the user's system that it ought not link with -- be they libraries from other ports on which the port in question does not declare a dependency, or libraries in /usr/local, to which the compiler always looks. Would two identical builds be byte-identical? If so, then a binary doesn't become available until *two* (or three or whatever) identical binaries are uploaded. And/or, there's some command line library tool (I'm on vacation and my reference books are home) that I can run to get a listing of what libraries are called by a particular binary, isn't there? Wouldn't that help screen wacky-linked binaries? The deliberate uploading of contaminated binaries, however, is a whole different kettle of worms. :/ I've been running mpab for a few days now, ie: http://trac.macports.org/wiki/MPAB This is a chroot approach. Obviously, as it is, anyone could tinker with it to include a rootkit or whatever. Nevertheless, I wonder if it's possible to create a binary app of this, which is authenticated during installation (at least), and we ensure that it must do some handshaking to get hold of the official and secure port tree somehow (probably an encrypted handshake, encrypted file archive for download, etc.) and then it goes about it's business on a user machine and only does an upload (if any) when there is some kind of further authentication that the port build is correct (binary md5 etc. for at least 2-5 builds on the exact same configuration). Even if it does no uploads, it could create useful information about the stability or integrity (you name it) of the entire build process. It would be really neat to have an Xgrid controller (or many) be able to run a job that can parse out port dependencies and have some kind of parallelism in the build. Libraries and compressed files (which include manpages) tend to differ everytime they're built, even if they're functionally the same. So you can't just run an md5 checksum over everything and expect it to be the same after repeated builds. I hadn't thought of securing a distributed build system from malicious users until Joshua's message, but now I agree that from a security standpoint we cannot allow user-uploaded binaries at all. Dave's proposed safeguard of requiring n users to upload functionally identical files isn't going to help; if a malicious user can upload a bad binary from 1 computer, they can borrow n friends' computers and create n throwaway email addresses and upload the binary how ever many times we've specified. There are botnets out there with thousands of computers that can be commandeered by hackers to do whatever. So let's kill the idea of user-submitted binaries now. We want dedicated build servers under the control of the MacPorts project. So let's flesh out MPAB into something that can be run on such build servers. Then we can look at acquiring the servers. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
dbus and launchd spinning out of control
I've only just noticed my Utilities - Console log and it contains streams of the following messages: 3/28/09 3:11:03 PM org.macports.dbus[20573] Failed to start message bus: The pid file /opt/local/var/run/dbus/pid exists, if the message bus is not running, remove this file 3/28/09 3:11:03 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds 3/28/09 3:11:03 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds 3/28/09 3:11:13 PM org.macports.dbus[20575] Failed to start message bus: The pid file /opt/local/var/run/dbus/pid exists, if the message bus is not running, remove this file 3/28/09 3:11:13 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds 3/28/09 3:11:13 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds 3/28/09 3:11:23 PM org.macports.dbus[20579] Failed to start message bus: The pid file /opt/local/var/run/dbus/pid exists, if the message bus is not running, remove this file 3/28/09 3:11:23 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds 3/28/09 3:11:23 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds 3/28/09 3:11:33 PM org.macports.dbus[20583] Failed to start message bus: The pid file /opt/local/var/run/dbus/pid exists, if the message bus is not running, remove this file 3/28/09 3:11:33 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds So every 10 sec, launchd is trying to get dbus up and running, but it fails because an old pid file is hanging around. Can this be resolved automatically? When I check the file, I get: [ dwe...@ ~ ]$ ls -l /opt/local/var/run/dbus/pid -rw-r--r-- 1 root messagebus 4 2008-09-19 21:05 /opt/local/var/run/dbus/pid Given the date of this pid file (Sep 2008), I can only assume that this entire process has been repeated every 10 seconds for months, whenever my laptop system is running. I've now removed the old pid file and the launchd job has finally come to rest. I'm not a frequent checker of system logs, I just use the system and I guess most people are also unlikely to check the system logs (console). I'm curious about why this situation arose and, moreover, why it was not automatically resolved (it clearly required my intervention to remove the old pid file). Take care, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: dbus and launchd spinning out of control
I'm not sure if there is a specific ticket on this already, but maybe this one comes close: http://trac.macports.org/ticket/18462 On my system, I have the following LaunchDeamon and LaunchAgent: [ dwe...@xxx ~ ]$ cat /Library/LaunchDaemons/org.macports.dbus.plist ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 dict keyDebug/key false/ keyLabel/key stringorg.macports.dbus/string keyOnDemand/key false/ keyProgramArguments/key array string/opt/local/bin/daemondo/string string--label=dbus/string string--start-cmd/string string/opt/local/bin/dbus-daemon/string string--system/string string--nofork/string string;/string string--pid=exec/string /array keyRunAtLoad/key false/ /dict /plist [ dwe...@xxx ~ ]$ cat /Library/LaunchAgents/org.freedesktop.dbus-session.plist ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 dict keyLabel/key stringorg.freedesktop.dbus-session/string keyServiceIPC/key true/ !-- bug in 10.4's launchd - on-demand loading does not work -- keyOnDemand/key false / keyProgramArguments/key array string/opt/local/bin/dbus-daemon/string string--nofork/string string--session/string /array keySockets/key dict keyunix_domain_listener/key dict keySecureSocketWithKey/key stringDBUS_LAUNCHD_SESSION_BUS_SOCKET/string /dict /dict /dict /plist On Sat, Mar 28, 2009 at 3:20 PM, Darren Weber dwe...@macports.org wrote: I've only just noticed my Utilities - Console log and it contains streams of the following messages: 3/28/09 3:11:03 PM org.macports.dbus[20573] Failed to start message bus: The pid file /opt/local/var/run/dbus/pid exists, if the message bus is not running, remove this file 3/28/09 3:11:03 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds 3/28/09 3:11:03 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds 3/28/09 3:11:13 PM org.macports.dbus[20575] Failed to start message bus: The pid file /opt/local/var/run/dbus/pid exists, if the message bus is not running, remove this file 3/28/09 3:11:13 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds 3/28/09 3:11:13 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds 3/28/09 3:11:23 PM org.macports.dbus[20579] Failed to start message bus: The pid file /opt/local/var/run/dbus/pid exists, if the message bus is not running, remove this file 3/28/09 3:11:23 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds 3/28/09 3:11:23 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds 3/28/09 3:11:33 PM org.macports.dbus[20583] Failed to start message bus: The pid file /opt/local/var/run/dbus/pid exists, if the message bus is not running, remove this file 3/28/09 3:11:33 PM com.apple.launchd[1] (org.macports.dbus) Throttling respawn: Will start in 10 seconds So every 10 sec, launchd is trying to get dbus up and running, but it fails because an old pid file is hanging around. Can this be resolved automatically? When I check the file, I get: [ dwe...@ ~ ]$ ls -l /opt/local/var/run/dbus/pid -rw-r--r-- 1 root messagebus 4 2008-09-19 21:05 /opt/local/var/run/dbus/pid Given the date of this pid file (Sep 2008), I can only assume that this entire process has been repeated every 10 seconds for months, whenever my laptop system is running. I've now removed the old pid file and the launchd job has finally come to rest. I'm not a frequent checker of system logs, I just use the system and I guess most people are also unlikely to check the system logs (console). I'm curious about why this situation arose and, moreover, why it was not automatically resolved (it clearly required my intervention to remove the old pid file). Take care, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
new milestone: Port Binaries
How about a new milestone for trac: binary distributions? I guess most of this would focus on mpab and adaptations to port to enable binary installations. Take care, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
sysadmin: is there a manifesto on environment settings for macports?
Is there a general manifesto on how to configure OSX for macports?
I see the following documents online, but they don't answer all my questions
for macports:
http://trac.macports.org/wiki/FAQ
http://trac.macports.org/wiki/InstallingMacPorts
The installation of macports proposes a user-specific environment (using
~/.profile or similar, but I wonder if that resolves path issues when using
sudo or for system deamons, etc.).
An issue that I have is with the dynamic linker unable to resolve some
library paths at run-time. I would like to see a document on macport wisdom
for dyld.
In my explorations today, to resolve some environment settings, I found a
few places where the environment is configured (I'm using bash).
I see the following system path settings available:
/etc/paths
/etc/paths.d/* (used by /usr/libexec/path_helper, called from /etc/profile
[and elsewhere?])
/etc/manpaths
/etc/manpaths.d
/etc/man.conf
For bash, there are a few /etc files around:
/etc/bashrc
/etc/profile (which calls path_helper and it handles at /etc/paths.d/*)
For csh, there are /etc/csh.* files.
In the user domain, there are the usual suspects (~/.bashrc, ~/.profile,
~/.cshrc, ~/.login, etc.). Then there is a sneeky OSX specific environment
file in ~/.MacOSX/environment.plist. The macports installation recommends
using the *nix convention of setting up the environment in the shell login
profiles (.profile, .bashrc, etc.).
What about dynamic library path configuration (for dyld)? What is the best
way to configure this for macports? Should settings apply at the system
level (I would assume so) or at the user level (probably not). I currently
have one env setting for postgresql83 (and I think this one is user
specfic):
DYLD_FALLBACK_LIBRARY_PATH=:/opt/local/lib/postgresql83
When building libraries, is there a general philosophy on using rpath? I'm
confused about this, eg consider:
http://wiki.debian.org/RpathIssue
http://www.mail-archive.com/bug-libt...@gnu.org/msg00700.html
http://lists.apple.com/archives/unix-porting/2008/Mar/msg8.html
http://developer.apple.com/releasenotes/DeveloperTools/RN-dyld/index.html
I've found that rpath can be a problem because macports builds into a
destroot. When I use rpath outside of a destroot, it works fine, but I
don't understand how to use it with a destroot, as in macports. If a port
should use rpath, how should a port set RPATH correctly (maybe a relative
path to ${prefix})? Or, should a port update a DYLD path setting so that
run-time dependencies get resolved (see options for path settings in `man
dyld` and maybe ports should set a system or user equivalent to
~/.MacOSX/environment.plist)?
See also:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/index.html
http://developer.apple.com/documentation/MacOSX/Conceptual/BPSystemStartup/BPSystemStartup.html
http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/BPRuntimeConfig.html
http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html#//apple_ref/doc/uid/20002093
http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/intro/intro.html
Take care, Darren
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: sysadmin: is there a manifesto on environment settings for macports?
Hi Rainer,
I've had some difficulty with the VTK library when I try to get dynamic
libraries working under macports. See
http://trac.macports.org/ticket/19000
I could use some help with understanding how to get rpath working under
macports (if that is THE way to go), given that VTK uses CMAKE settings to
configure the RPATH or the INSTALL_RPATH and the settings that I've tried so
far get corrupted during the macports build process because it uses a
destroot setting. I've thought about a postdestroot hack using
'install_name_tool' but there may be a better way to get it right.
For me, the bigger picture is creating an open-source scientific application
that will depend on VTK, among other libraries, and macports may provide the
foundation for the distribution process on OSX.
Best, Darren
On Thu, Apr 9, 2009 at 5:36 PM, Rainer Müller rai...@macports.org wrote:
Darren Weber wrote:
What about dynamic library path configuration (for dyld)? What is the
best way to configure this for macports? Should settings apply at the
system level (I would assume so) or at the user level (probably not). I
currently have one env setting for postgresql83 (and I think this one is
user specfic):
DYLD_FALLBACK_LIBRARY_PATH=:/opt/local/lib/postgresql83
ports should not require any DYLD_* settings as they are expected to
link against absolute paths in the ${prefix}. If this is really required
for postgresql83 to work, it is a bug in that port.
When building libraries, is there a general philosophy on using rpath?
I'm confused about this, eg consider:
http://wiki.debian.org/RpathIssue
http://www.mail-archive.com/bug-libt...@gnu.org/msg00700.html
http://lists.apple.com/archives/unix-porting/2008/Mar/msg8.html
http://developer.apple.com/releasenotes/DeveloperTools/RN-dyld/index.html
I've found that rpath can be a problem because macports builds into a
destroot. When I use rpath outside of a destroot, it works fine, but I
don't understand how to use it with a destroot, as in macports. If a
port should use rpath, how should a port set RPATH correctly (maybe a
relative path to ${prefix})? Or, should a port update a DYLD path
setting so that run-time dependencies get resolved (see options for path
settings in `man dyld` and maybe ports should set a system or user
equivalent to ~/.MacOSX/environment.plist)?
First, what particular problem are you trying to solve with this? Is
there any port which relies on RPATH? If so, why would it need this?
Rainer
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
VTK port naming conventions
This is a thread to discuss naming conventions for VTK in macports. Macports has the following VTK ports (as of 04/13/2009): VTK @4.4.2 (graphics) 3D visualization toolkit vtk5 @5.2.1 (graphics, devel) 3D visualization toolkit In the Debian distribution, there are quite a few packages, eg: http://packages.debian.org/search?keywords=vtksearchon=namessuite=stablesection=all A similar story with FreeBSD, see: http://www.freebsd.org/cgi/ports.cgi?query=vtkstype=all Note that both Debian and FreeBSD list VTK in several categories, including 'libs', 'libdevel', 'graphics', and 'math'. Many of these separate packages in Debian and FreeBSD probably equate to 'variants' in a macport. Take care, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: VTK port naming conventions
I agree with Ryan, that separate ports provide more clarity for dependency specifications, but I do not understand macports variants very well. For instance, there is a track ticket on VTK with some discussion about this issue, see: http://trac.macports.org/ticket/19000 In that ticket, tgamblin raises the possibility of using the @X.Y.Z syntax to get version specific installs, eg: port install v...@5.2.1 port install v...@5.4.0 Furthermore, it should be possible to do this: port install v...@5.2.1 port build v...@5.4.0 port deactivate v...@5.2.1 port activate v...@5.4.0 ... etc If so, does this automatically resolve @X.Y into the latest Z version available? Also, similarly, does it automatically resolve @X into the latest Y.Z version? In my experience with macports to date, the @ syntax must be very specific to be effective, it doesn't have automatic resolution to the latest version. I know that Debian has some symbolic package names that are resolved to the latest version of a package (an auto-update package name). In any case, there are some issues with simultaneous version installations (please see the trac ticket comments for some details). Given some differences of opinion, it would be great to work out a consensus on how best to move forward. This requires broader discussion that a track ticket, as the resolution is not necessarily specific to any particular port, although this discussion has a focus on VTK for example. Any ports that depend on a specific version of vtk should be able to: (a) specify a dependency on a vtkXY port name that includes at least an XY version (or use the @X.Y.Z syntax?), and (b) restrict the build and link search paths to the version required. To my knowlege, vtk doesn't provide a utility like /opt/local/lib/postgresql83/bin/pg_config, but cmake does have some macros for searching out include and library paths (this may also apply to ports in the K-desktop, as they have adopted cmake as their build tool). In the cmake search paths, there are several variables that control the search, including: CMAKE_FIND_FRAMEWORK CMAKE_FIND_ROOT_PATH ONLY_CMAKE_FIND_ROOT_PATH NO_CMAKE_SYSTEM_PATH NO_CMAKE_ENVIRONMENT_PATH NO_SYSTEM_ENVIRONMENT_PATH CMAKE_FRAMEWORK_PATH CMAKE_APPBUNDLE_PATH CMAKE_INCLUDE_PATH CMAKE_INCLUDE_DIRECTORIES_BEFORE Given there are relatively few ports that depend on VTK, I've been looking for inspiration from more significant libraries, like postgresql and python. A possible solution is to adopt a model something like postgresql8x, where the installation goes almost entirely into /opt/local/lib/postgresql8x, including /opt/local/lib/postgresql83/bin, for instance. Translating that model to vtk might result in something like: /opt/local/include/vtk-X.Y /opt/local/lib/vtkX.Y These paths are already the defaults, given $prefix = /opt/local, but notice how posgresql83 has something like a bin path within the lib path, eg: /opt/local/lib/vtk-X.Y/bin This would separate any vtk binaries that are version specific, rather than have them clash under /opt/local/bin/. Another possible solution is to adopt a pythonX.Y model, where the version specific installs include a version suffix. In addition, there is the utility python_select to define the 'current' version. In this model, a build that depends on a specific version of VTK might temporarily use something like python_select to define the current version for the build. Take care, Darren On Mon, Apr 13, 2009 at 3:06 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Apr 13, 2009, at 16:52, css...@mac.com wrote: On Monday, April 13, 2009, at 04:49PM, Darren Weber wrote: This is a thread to discuss naming conventions for VTK in macports. Macports has the following VTK ports (as of 04/13/2009): VTK @4.4.2 (graphics) 3D visualization toolkit vtk5 @5.2.1 (graphics, devel) 3D visualization toolkit It might be more clear to rename along the lines of: vtk @5.2.1 vtk-devel @5.4 vtk4 @4.4.2 I'm not sure how best we might handle renaming the existing ports to match this scheme, but it would follow the scheme of keeping the port named without a version as the latest, stable release. I also need to fix the case-sensitive handling of the directory versus the port name. Any thoughts? This is difficult since MacPorts does not have a mechanism for renaming ports. It would be great if we had such a mechanism. Many of these separate packages in Debian and FreeBSD probably equate to 'variants' in a macport. That's true. MacPorts provides the extra language bindings in variants rather than separate ports, unless the demand hasn't been made to enable a particular binding either by default or as a variant. IMHO separate ports are better than variants, since they can be installed and uninstalled separately, and depended on (in a dependency statement). The Subversion language bindings are in separate ports, for example
Re: VTK port naming conventions
On Mon, Apr 13, 2009 at 2:52 PM, css...@mac.com wrote: On Monday, April 13, 2009, at 04:49PM, Darren Weber dwe...@macports.org wrote: This is a thread to discuss naming conventions for VTK in macports. Macports has the following VTK ports (as of 04/13/2009): VTK @4.4.2 (graphics) 3D visualization toolkit vtk5 @5.2.1 (graphics, devel) 3D visualization toolkit It might be more clear to rename along the lines of: vtk @5.2.1 vtk-devel @5.4 vtk4 @4.4.2 The -devel suffix (or just -dev) is often used with a debug release, and (or) it specifies that all the include headers are installed, not just the binaries. As VTK is a library (not an application, per se), the -dev suffix is sort-of implied (virtually mandatory). Note that Debian use the names libvtk-* to be explicit that VTK is a library, but this is not the case in FreeBSD. Perhaps there could be a dev or testing variant of vtk for the current CVS checkout? Given that 5.4.0 is the latest stable release, it should not get a -dev suffix. I'm clueless about the @ syntax for version specificity; maybe that will work. Take care, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: VTK port naming conventions
On Tue, Apr 14, 2009 at 2:23 PM, Ryan Schmidt ryandes...@macports.orgwrote: This is really more of a development question and not a usage question so macports-dev may be a better place to continue this. On Apr 14, 2009, at 12:55, Darren Weber wrote: I agree with Ryan, that separate ports provide more clarity for dependency specifications, but I do not understand macports variants very well. For instance, there is a track ticket on VTK with some discussion about this issue, see: http://trac.macports.org/ticket/19000 In that ticket, tgamblin raises the possibility of using the @X.Y.Z syntax to get version specific installs, eg: port install v...@5.2.1 port install v...@5.4.0 Furthermore, it should be possible to do this: port install v...@5.2.1 port build v...@5.4.0 port deactivate v...@5.2.1 port activate v...@5.4.0 ... etc If so, does this automatically resolve @X.Y into the latest Z version available? Also, similarly, does it automatically resolve @X into the latest Y.Z version? In my experience with macports to date, the @ syntax must be very specific to be effective, it doesn't have automatic resolution to the latest version. I know that Debian has some symbolic package names that are resolved to the latest version of a package (an auto-update package name). MacPorts does not offer the facility to install a specific version of a port. It only lets you install the current version of the port. port install v...@5.2.1 will not install version 5.2.1; it will install whatever version is currently offered by the port. Once a port has been updated to a new version, MacPorts no longer has any information about the older version of the port. You can *uninstall*, *deactivate* and *activate* specific versions which have already been installed. For example, if you install zlib, and that gives you version 1.2.1, and later version 1.2.3 becomes available and you port upgrade zlib to get it, you now have two versions of zlib installed: zlib @1.2.1_0 and zlib @1.2.3_0, with the latter being active. If you wish to go back to 1.2.1_0, you can port deactivate zlib (which will deactivate zlib @1.2.3_0; specifying the version is not necessary here because there is only one zlib active) and then port activate zlib @1.2.1_0. Note this is only possible because the old version had already previously been installed. Instructions for installing an older version of a port directly are in the wiki: http://trac.macports.org/wiki/howto/InstallingOlderPort The conclusion to be drawn from this part of our discussion is that any ports that depend on a specific version of VTK can specify that version dependency only if there is a version specific port available (ie, vtkXY). It is not possible for a port to specify a dependency using the @X.Y.Z syntax. The next question is, why would any port require a dependency on a specific version of VTK? Furthermore, if it does, to what extent is that port compatible with future releases of VTK? So, moving on to the next question below. In any case, there are some issues with simultaneous version installations (please see the trac ticket comments for some details). Given some differences of opinion, it would be great to work out a consensus on how best to move forward. This requires broader discussion that a track ticket, as the resolution is not necessarily specific to any particular port, although this discussion has a focus on VTK for example. Any ports that depend on a specific version of vtk should be able to: (a) specify a dependency on a vtkXY port name that includes at least an XY version (or use the @X.Y.Z syntax?), and (b) restrict the build and link search paths to the version required. To my knowlege, vtk doesn't provide a utility like /opt/local/lib/postgresql83/bin/pg_config, but cmake does have some macros for searching out include and library paths (this may also apply to ports in the K-desktop, as they have adopted cmake as their build tool). In the cmake search paths, there are several variables that control the search, including: CMAKE_FIND_FRAMEWORK CMAKE_FIND_ROOT_PATH ONLY_CMAKE_FIND_ROOT_PATH NO_CMAKE_SYSTEM_PATH NO_CMAKE_ENVIRONMENT_PATH NO_SYSTEM_ENVIRONMENT_PATH CMAKE_FRAMEWORK_PATH CMAKE_APPBUNDLE_PATH CMAKE_INCLUDE_PATH CMAKE_INCLUDE_DIRECTORIES_BEFORE Given there are relatively few ports that depend on VTK, I've been looking for inspiration from more significant libraries, like postgresql and python. A possible solution is to adopt a model something like postgresql8x, where the installation goes almost entirely into /opt/local/lib/postgresql8x, including /opt/local/lib/postgresql83/bin, for instance. Translating that model to vtk might result in something like: /opt/local/include/vtk-X.Y /opt/local/lib/vtkX.Y These paths are already the defaults, given $prefix = /opt/local, but notice how posgresql83 has something like a bin path within the lib path, eg
Re: VTK port naming conventions
Proposed summary:
Where possible, do not use portmajorminor (eg: vtk54), rather port
should be the latest STABLE version (eg: the port named 'vtk' should contain
5.2.x at the time of this writing). Any version of a port that is near the
cutting edge must have the -devel suffix on the port name (eg, vtk-devel
should contain 5.4.0 at the time of this writing). An exception to this
rule is where multiple versions of a port (VERSIONS - not variants) must be
installed due to down-stream dependencies on incompatible versions. This
usually occurs for older versions than the current stable version. In this
case, the older versions should adopt the name portmajorminor (or at
least portmajor, depending on the port compatibility policies) and, if
possible, the down-stream ports that depend on it should have revised
dependency specifications (eg, change the dependency from 'vtk' to 'vtkXY')
- unless or until the downstream ports can be updated to be compatible with
the latest releases in their dependency tree. At the point where a library
like vtk is updated to a new incompatible release (eg, a major version
change, such as 4.x to 5.x), the vtk port becomes the latest stable version
and the prior port becomes at least vtkmajor, if not vtkmajorminor.
In the event that older stable releases are updated with bug fixes, the
live-check mechanism might be used to detect and upgrade the port (assuming
the bug fixes don't change compatibility).
[Note. Avoid '.' in the port name, so don't do portmajor.minor in the
port name.]
Conclusion:
vtk becomes vtk4 or vtk44 @4.4.2
vtk5 becomes vtk @5.2.1
vtk54 becomes vtk-devel @5.4.0
[Note. When vtk-5.4.x becomes at least 5.4.1, it will become 'vtk' and then
vtk-devel will disappear - at least until the next time a -devel is
required, when we get say vtk-5.5.0 or some other change that might be
incompatible with vtk-5.4.x.]
The result of these changes should provide something like (at the time of
writing):
[ m...@xxx ~ ]$ port search vtk
vtk44 @4.4.2 (graphics)
3D visualization toolkit (www.vtk.org)
vtk @5.2.1 (graphics)
3D visualization toolkit (www.vtk.org)
vtk-devel @5.4.0 (graphics, devel)
3D visualization toolkit (www.vtk.org)
Note that there has to be some changes in the Portfile to the way the
${name}, etc. variables are handled when there is a change in the version
release. For example,
name vtk44
version 4.4.2
revision 0
set branch[join [lrange [split ${version} .] 0 1] .]
homepage http://www.vtk.org/
master_sites http://www.vtk.org/files/release/${branch}
distname vtk-${branch}
distfiles vtk-${version}.tar.gz \
vtkdata-${version}.tar.gz
post-extract {
system cd ${workpath}; mv VTK ${distname}; mv VTKData ${distname}-data
}
In any case, all the vtk ports should assume that more than one version of
the library can be installed and those installations should be separated
into independent locations (hopefully this can be handled with the right
CMAKE variable settings). For the most part, this already happens in vtk,
although there are some binaries that are not version specific that get
installed into ${prefix}/bin/.
If we have a consensus on this, we might conclude this discussion of the VTK
naming convention.
Take care, Darren
PS, Additional summary notes or issues to be resolved elsewhere:
a) vtk takes a long time to build, so the default variant should provide a
complete installation (wrapping for tcl, python, and java, plus docs,
examples, data, tests, or whatever). The wrappers for tcl, python, java
should be variants, so too with docs, examples, data, etc., which are
included by default, but thereby making it possible to exclude them with
-variant syntax. There should be some documentation in the
long_description about the variants, to explain the variant compatibility
and the defaults.
b) Additional variants, or separate ports, for substantial combination of
vtk with other ports, like Qt, mysql, postgresql, etc. During the build for
vtk, there are distinct options to include classes and links to additional
functionality for GUI and database programming (among others).
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
uninstall works, but receipts are not updated?
What is happening here (there is a local repository in ~/ports, but it's probably not important for this issue): [ m...@xxx ~/ports ]$ port installed | grep vtk vtk @5.2.1_0+darwin_9+examples+tclSys+testing vtk5 @5.2.0_0+darwin_9+examples+shared+tclSys+testing vtk5 @5.2.0_0+darwin_9+examples+tclSys+testing vtk52 @5.2.1_0+darwin_9+examples+tclSys+testing vtk54 @5.4.0_0+darwin_9+examples+tclSys+testing [ m...@xxx ~/ports ]$ sudo port uninstall vtk @5.2.1_0+darwin_9+examples+tclSys+testing Password: --- Uninstalling vtk @5.2.1_0+darwin_9+examples+tclSys+testing [ m...@xxx ~/ports ]$ sudo port uninstall vtk5 @5.2.0_0+darwin_9+examples+shared+tclSys+testing --- Uninstalling vtk5 @5.2.0_0+darwin_9+examples+shared+tclSys+testing [ m...@xxx ~/ports ]$ sudo port uninstall vtk5 @5.2.0_0+darwin_9+examples+tclSys+testing --- Uninstalling vtk5 @5.2.0_0+darwin_9+examples+tclSys+testing [ m...@xxx ~/ports ]$ sudo port uninstall vtk52 @5.2.1_0+darwin_9+examples+tclSys+testing --- Uninstalling vtk52 @5.2.1_0+darwin_9+examples+tclSys+testing [ m...@xxx ~/ports ]$ sudo port uninstall vtk54 @5.4.0_0+darwin_9+examples+tclSys+testing --- Uninstalling vtk54 @5.4.0_0+darwin_9+examples+tclSys+testing [ m...@xxx ~/ports ]$ [ m...@xxx ~/ports ]$ port installed | grep vtk vtk @5.2.1_0+darwin_9+examples+tclSys+testing vtk5 @5.2.0_0+darwin_9+examples+shared+tclSys+testing vtk5 @5.2.0_0+darwin_9+examples+tclSys+testing vtk52 @5.2.1_0+darwin_9+examples+tclSys+testing vtk54 @5.4.0_0+darwin_9+examples+tclSys+testing [ m...@xxx ~/ports ]$ ls /opt/local/var/macports/software/vtk* /opt/local/bin/gls: cannot access /opt/local/var/macports/software/vtk*: No such file or directory [ m...@xxx ~/ports ]$ ls /opt/local/var/macports/receipts/vtk*/* /opt/local/var/macports/receipts/vtk/5.2.1_0+darwin_9+examples+tclSys+testing: receipt.bz2 receipt.bz2.mpsaved /opt/local/var/macports/receipts/vtk5/5.2.0_0+darwin_9+examples+shared+tclSys+testing: receipt.bz2 receipt.bz2.mpsaved /opt/local/var/macports/receipts/vtk5/5.2.0_0+darwin_9+examples+tclSys+testing: receipt.bz2 receipt.bz2.mpsaved /opt/local/var/macports/receipts/vtk52/5.2.1_0+darwin_9+examples+tclSys+testing: receipt.bz2 receipt.bz2.mpsaved /opt/local/var/macports/receipts/vtk54/5.4.0_0+darwin_9+examples+tclSys+testing: receipt.bz2 receipt.bz2.mpsaved Best, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
how-to delete a registry entry?
There is some documentation here on the macports API, including some registry functions: http://guide.macports.org/#internals.apis How is the API called? It is a tcl API, so is it loaded into tclsh? Thanks, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: how-to delete a registry entry?
I made the stupid mistake of removing some registry (ie, receipt) files, so
now I get
[ m...@xxx ~/ports ]$ port installed
Error: port installed failed: list must have an even number of elements
No ports are installed.
I ran a few port uninstall commands and then checked that the ports were not
installed, but
port installed | grep portname
continued to indicate that the ports were installed (see my other list post
on that topic). I should like 'port installed' to indicate that a port is
no longer installed after running 'port uninstall port'. So I started to
read up on how to remove the receipts using the API somehow, but I couldn't
do that and I did just removed the files. Lesson learned, but now it needs
to be fixed - how can I regenerate the registry?
FYI:
[ m...@xxx ~/ports ]$ port -d installed
DEBUG: list must have an even number of elements
while executing
array set receipt_$ref $receipt_contents
(procedure receipt_flat::open_entry line 84)
invoked from within
${macports::registry.format}::open_entry $name $version $revision
$variants
(procedure open_entry line 4)
invoked from within
open_entry $iname $iversion $irevision $ivariants
(procedure registry::installed line 13)
invoked from within
registry::installed
Error: port installed failed: list must have an even number of elements
No ports are installed.
On Thu, Apr 16, 2009 at 7:20 PM, Rainer Müller rai...@macports.org wrote:
Darren Weber wrote:
There is some documentation here on the macports API, including some
registry functions:
http://guide.macports.org/#internals.apis
How is the API called? It is a tcl API, so is it loaded into tclsh?
This is only meant for internal use inside of MacPorts. What are you
trying to do with the registry?
Rainer
PS: This topic may have been better suited for macports-dev.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
reinstalling macports
I've got a corrupted registry (receipts). Will reinstalling macports correct a corrupted registry? Is it possible to re-install macports from the .dmg while keeping all the ports that are installed (and registered)? How can I correct a corrupted registry, without re-installation? Thanks in advance, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: reinstalling macports
Nice command line, Jeremy! I did find my own custom port had some \n chars in long_description that screwed up the registry. It's all working correctly now. Phew! Thanks! On Wed, Apr 22, 2009 at 4:01 PM, Jeremy Huddleston jerem...@macports.orgwrote: This should tell you which one is problematic: for f in /opt/local/var/macports/receipts/*/*/receipt.bz2; do echo -n $f bzcat $f | wc -l; done | grep -v ' 2$' On Apr 22, 2009, at 14:09, Rainer Müller wrote: Darren Weber wrote: I've got a corrupted registry (receipts). Do you know which receipt it is? I assume this the issue with using \n in the description/long_description as you did in your gdb port. In this case, you could fix it by editing the receipt by hand. A valid receipt should have only two lines. The first is the version number, the second one contains all the information about the port. If there was some \n in the description/long_description, these new lines are written into this receipt file as actual new lines. So, to get a working receipt again, remove the new lines by joining these lines to a single one. You will find the receipt at /opt/local/var/macports/receipts/name/composite_version/receipt.bz2 These are compressed, but plain text. Uncompress, edit and compress again (or if you know vim, it will do it automatically for you). If my guess above was wrong, please show the receipt file in question and describe what you did. Rainer ___ 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: VTK port naming conventions
I have not had enough experience with VTK to know how compatible it is across minor version releases. To provide flexibility, I've assumed that vtkXY should be sufficient to provide the major.minor (X.Y) version specificity for any port that depends on VTK (ie, I've not considered vtkXYZ to be necessary). Certainly vtkX at a minimum to provide the major release compatibility. At this point, do we have a consensus that port names should have a version string in the name? (We may not agree on the specificity of that version string - vtkX, vtkXY, vtkXYZ - but it appears the @ syntax is not an option.) A number should only be used in the port name if you need to have multiple ports that install multiple different versions of the software. For most ports, this should not be necessary; just provide a single port with the latest version of the software. To know how this should be handled for vtk, you need to answer the question: why would a user install the old version if a new version is available? Why would a user install vtk 4.4.2 if 5.2.1 is available? Why would a user install vtk 5.2.1 if 5.4 is available? If there is no reason why a user would do this, then multiple ports are not needed. Quick update on this section of our discussion, see http://www.vtk.org/Wiki/VTK_FAQ#Changes_to_the_VTK_API It provides some indication that the API for VTK can change with a lot of flexibility, so we might expect the minor release versions of VTK to break some parts of the API sometimes. In this case, any software that depends on VTK might need either (a) a dependency on an old minor release version (eg, vtkXY) or (b) an update to the source to adjust for API changes. Regards, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
What is the preferred or recommended gcc version?
This one is not in the FAQ, yet, so here we go. Is there a general consensus, for the majority of ports without any specific build dependency, on which version of gcc is preferred or recommended for MacPorts? The following gcc variants are available: [ dwe...@x ~ ]$ gcc_select -l Available versions: gcc40 mp-gcc42 mp-gcc43 mp-gcc44 [ dwe...@x ~ ]$ ls -l /opt/local/bin/gcc* | sed -e 's/.*[0-9] \/opt/\/opt/' /opt/local/bin/gcc - /usr/bin/gcc-4.0* /opt/local/bin/gcc-apple-4.2 - /opt/local/lib/apple-gcc42/bin/gcc-apple-4.2* /opt/local/bin/gcc-mp-4.2* /opt/local/bin/gcc-mp-4.3* /opt/local/bin/gcc-mp-4.4* /opt/local/bin/gcc_select* /opt/local/bin/gccbug-mp-4.2* /opt/local/bin/gccbug-mp-4.3* /opt/local/bin/gccbug-mp-4.4* /opt/local/bin/gccxml* /opt/local/bin/gccxml_cc1plus* [ dwe...@x ~ ]$ ls -l /opt/local/bin/g++* | sed -e 's/.*[0-9] \/opt/\/opt/' /opt/local/bin/g++ - /usr/bin/bin/g++-4.0 /opt/local/bin/g++-mp-4.2* /opt/local/bin/g++-mp-4.3* /opt/local/bin/g++-mp-4.4* Take care, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: GDB 6.8 via Mac Ports?
Hi Kendall, I put this Portfile together in the hope that the build and install would be smooth. It's not. I'm a novice at building gdb, so I have a lot to learn about why this is failing. It may be that the automatic detection of the target architecture is wrong, it currently detects checking build system type... i386-apple-darwin9.7.0 checking host system type... i386-apple-darwin9.7.0 The main concern is this: checking build system type... i386-apple-darwin9.7.0 checking host system type... i386-apple-darwin9.7.0 checking target system type... i386-apple-darwin9.7.0 checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for gcc... /usr/bin/gcc-4.0 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc-4.0 accepts -g... yes checking for /usr/bin/gcc-4.0 option to accept ANSI C... none needed checking whether we are using the GNU C++ compiler... yes checking whether /usr/bin/g++-4.0 accepts -g... yes checking for gnatbind... no checking for gnatmake... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 *** This configuration is not supported in the following subdirectories: bfd opcodes gdb sim (Any other directories should still work fine.) So what is happening is the build and install is working, but only partially. It would be preferable that the build fails at this point, but it does not! I'm very sorry to waste your time, I wish this was working! I think the main thing to get right is the target platform identifier. I looked into it briefly, but it's not resolved yet. I would hope that if the target platform is identified correctly (and fully supported by gdb 6.8), the port will be functional. If you have the motivation and patience to look into it, I can advise you on how to play around with the Porfile. The first thing to do is to run port in debug mode, i.e.: sudo port -d destroot gdb This will provide a lot of information on what port is doing. The destroot target does the configure and build, then runs make install with a custom DESTDIR. MacPorts uses that DESTDIR, called destroot, as a way to parse the files in the port, install the files into /opt/local/var/macports/software/gdb/ and then activate the port with hard links in /opt/local to the files in the software/gdb installation. The destroot path for this port is /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_gdb/work/destroot The pitiful truth is that the only files currently installed there are: .../destroot/ .../destroot//opt .../destroot//opt/local .../destroot//opt/local/lib .../destroot//opt/local/lib/libiberty.a .../destroot//opt/local/share .../destroot//opt/local/share/info .../destroot//opt/local/share/info/configure.info .../destroot//opt/local/share/info/standards.info If you want to build everything custom, without MacPorts, you can copy the distfile into your build path from /opt/local/var/macports/distfiles/gdb/gdb*.tar.gz I hope we can fix this one! I've created a new trac ticket on this issue: http://trac.macports.org/ticket/19871 Take care, Darren On Fri, Jun 5, 2009 at 10:56 AM, Kendall Bennett kenda...@amainhobbies.comwrote: Hi Darren, I am trying to get an updated version of GDB installed to see if it will solve some problems I have found with the one distributed by Apple (seems to have issues with breakpoints in some C++ programs, specifically Qt4 stuff). Anyway, I tested gdb 6.8 on Windows and it seems to not have these issues, so the Mac Ports version of gdb 6.8 seemed like a good option. Anyway, I did the installed and ran into a snag during the activation, saying the following: --- Activating gdb Error: port activate failed: Image error: /opt/local/share/info/ standards.info is being used by the active autoconf port. Please deactivate this port first, or use 'port -f activate gdb' to force the activation. I have both tried deactivating autoconf and activating gdb, and leaving autoconf activated and forcing the activation of gdb, but there does not appear to be any gdb binary located anywhere under the /opt/local tree? I was expecting it to show up on /opt/local/bin, but there is nothing there, and searching the /opt/local directory does not find anything resembling a gdb binary? What am I missing here? Regards, *Kendall Bennett, CEO *A Main Hobbies 424 Otterson Drive, Suite 160 Chico, CA 95928 1-800-705-2215 (Toll-Free) 1-530-894-0797 (Int'l Local) 1-530-894-9049 (Fax) *http://www.amainhobbies.com* ___
Re: GDB 6.8 via Mac Ports?
Hi, I spent a while looking into this, pretty nearly clueless about how to resolve the problem. I've commented on my experience today in the ticket: http://trac.macports.org/ticket/19871 To save others the trouble, I've committed a change to the trunk of this port so that the fetch stage just issues a message about the port failing to build everything, with reference to that ticket. Hopefully that will save some trouble for others trying to use the port. In hindsight, the port should not have been committed in the first place, but it wasn't clear to me at the time that it was failing to build everything. Anyhow, sorry for all the inconvenience! Take care, Darren On Fri, Jun 5, 2009 at 1:40 PM, Kendall Bennett kenda...@amainhobbies.comwrote: Hi Darren, Thanks for the update. I am a total newb when it comes to Mac Ports, and although I have built GDB in the past on Linux, I never really played much with it past just building it (and patching in debugging support for X11 loadable modules). But that was a while ago. If I get time, I will play with this a bit and see if I can work it out. If you do get it figured out, let me know! Regards, *Kendall Bennett, CEO *A Main Hobbies 424 Otterson Drive, Suite 160 Chico, CA 95928 1-800-705-2215 (Toll-Free) 1-530-894-0797 (Int'l Local) 1-530-894-9049 (Fax) *http://www.amainhobbies.com * -- *From: *Darren Weber dwe...@macports.org *Date: *Fri, 5 Jun 2009 11:38:09 -0700 *To: *Kendall Bennett kenda...@amainhobbies.com *Cc: *MacPorts Users macports-users@lists.macosforge.org *Subject: *Re: GDB 6.8 via Mac Ports? Hi Kendall, I put this Portfile together in the hope that the build and install would be smooth. It's not. I'm a novice at building gdb, so I have a lot to learn about why this is failing. It may be that the automatic detection of the target architecture is wrong, it currently detects checking build system type... i386-apple-darwin9.7.0 checking host system type... i386-apple-darwin9.7.0 The main concern is this: checking build system type... i386-apple-darwin9.7.0 checking host system type... i386-apple-darwin9.7.0 checking target system type... i386-apple-darwin9.7.0 checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for gcc... /usr/bin/gcc-4.0 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc-4.0 accepts -g... yes checking for /usr/bin/gcc-4.0 option to accept ANSI C... none needed checking whether we are using the GNU C++ compiler... yes checking whether /usr/bin/g++-4.0 accepts -g... yes checking for gnatbind... no checking for gnatmake... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 *** This configuration is not supported in the following subdirectories: bfd opcodes gdb sim (Any other directories should still work fine.) So what is happening is the build and install is working, but only partially. It would be preferable that the build fails at this point, but it does not! I'm very sorry to waste your time, I wish this was working! I think the main thing to get right is the target platform identifier. I looked into it briefly, but it's not resolved yet. I would hope that if the target platform is identified correctly (and fully supported by gdb 6.8), the port will be functional. If you have the motivation and patience to look into it, I can advise you on how to play around with the Porfile. The first thing to do is to run port in debug mode, i.e.: sudo port -d destroot gdb This will provide a lot of information on what port is doing. The destroot target does the configure and build, then runs make install with a custom DESTDIR. MacPorts uses that DESTDIR, called destroot, as a way to parse the files in the port, install the files into /opt/local/var/macports/software/gdb/ and then activate the port with hard links in /opt/local to the files in the software/gdb installation. The destroot path for this port is /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_gdb/work/destroot The pitiful truth is that the only files currently installed there are: .../destroot/ .../destroot//opt .../destroot//opt/local .../destroot//opt/local/lib .../destroot//opt/local/lib/libiberty.a .../destroot//opt/local/share .../destroot//opt/local/share/info .../destroot//opt/local/share/info/configure.info http://configure.info .../destroot//opt/local/share/info/standards.info http://standards.info If you want to build everything
OSX Upgrades: Snow Leopard
What happens to a MacPorts installation when we install a distribution
upgrade to OSX, say Leopard to Snow Leopard? Do we need to backup the
MacPorts installation, or is the ${prefix} path immune to the upgrade? What
about startup items (launchd or anything that violates the mtree)?
Thanks in advance,
Darren
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: OSX Upgrades: Snow Leopard
What's the recommended series of command lines for that?
Thanks!
Darren
On Tue, Jun 9, 2009 at 8:19 AM, Joshua Root j...@macports.org wrote:
On 2009-6-9 22:15, Tim Visher wrote:
Hi Darren,
On Tue, Jun 9, 2009 at 1:20 AM, Darren Weberdwe...@macports.org wrote:
What happens to a MacPorts installation when we install a distribution
upgrade to OSX, say Leopard to Snow Leopard? Do we need to backup the
MacPorts installation, or is the ${prefix} path immune to the upgrade?
What
about startup items (launchd or anything that violates the mtree)?
I can't be sure technically but I've upgraded OS X for every release
since MacPorts came out (Back when it was called DarwinPorts. Jaguar?)
and I've never had to reinstall it. So, anecdotally I think you're
safe. If you care very deeply you should of course back it up just in
case.
Both MacPorts base and each port are built for a specific major OS
version. Maybe they'll work acceptably on a newer version, maybe they
won't. The only safe option has always been to record your installed
ports, uninstall MacPorts entirely, install the correct base version for
your OS, then install your ports again.
- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: OSX Upgrades: Snow Leopard
On Tue, Jun 9, 2009 at 5:32 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Jun 9, 2009, at 17:07, Jeremy Huddleston wrote: On Jun 9, 2009, at 13:36, Darren Weber wrote: What's the recommended series of command lines for that? Here's what I did: cd /opt/local/var/macports/software /bin/ls -1d * ~/todo.mp cd sudo mv /opt/local /var/tmp/old_macports Moving /opt/local aside is not sufficient to uninstall MacPorts. See proper uninstall instructions here: http://trac.macports.org/wiki/FAQ#HowdoIremoveoruninstallMacPorts cd src/macports/trunk/base ./configure make sudo make install for f in $(cat todo.mp ); do [[ -d /opt/local/var/macports/software/$f ]] || sudo port -v install $f; done I'm sure there's something ports option to do that, but /shrug... MacPorts doesn't include a command to help you rebuild an entire installation like this. This is unfortunate and makes it a rather involved process. But since upgrading to a new major OS version is a task users don't perform often, I don't think any work has gone into making this easier. I think the key to solving this would be to have MacPorts record more information in the registry about each port that was installed, including what version of Mac OS X it was done on, with what version of Xcode, and even record several of the settings from macports.conf that were in effect at the time. Then we can make port outdated recognize that if the current OS is a major version later than the one a port was installed with, the port needs to be rebuilt. Interesting suggestion. Does the receipt include the variants installed? Is this process likely to be available in 1.8? Take care, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: OSX Upgrades: Snow Leopard
On Tue, Jun 9, 2009 at 5:45 AM, vincent habchi vi...@macports.org wrote: Le 9 juin 09 à 14:32, Kurt Hillig a écrit : On the other hand I recently upgraded from 10.4 to 10.5 and my machine was horribly unstable until I blew away the MacPorts install. I'm not sure why this was, and I didn't have the time or gumption to run a lot of diagnostics, so it could well be that something less drastic would have sufficed. When you upgrade, the libraries change, so you may have to recompile some of your bricks. For example, when SL will be out, we'll have, at least, a 64-bit API to QuickTime, so we'll be able to compile WxWindows safely in 64-bit mode. But maybe also the old AGL will vanished, and all ports that are based on it will have to be rebuild, etc. Ah, right. There will be changes to the default compiler in xcode, with an upgrade to a newer version of gcc and some performance improvements with llvm. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: VTK 5.2 and GL2PS export
I've done a bit of work on vtk-devel to make some things in the installation version specific. I have not tested whether vtk-devel can co-exist with vtk5. All the work on vtk-devel was based on the default variants (cocoa shared wrap) plus testing and examples. Nothing has been tested extensively, and very little has been done with x11. If you have time to run the build and install, I suggest the huge variant, or no variants at all will give you a default set of variants. vtk-devel has the variants: darwin_9: Platform variant, do not select manually huge: provide cocoa data doc examples shared testing wrap database mpi boost data: provide example data in: /opt/local/share/vtk-5.4/data doc: provide doxygen documentation in: /opt/local/share/vtk-5.4/doc examples: provide VTK examples in: /opt/local/share/vtk-5.4/examples shared: build shared libraries (default) testing: provide VTK tests in: /opt/local/share/vtk-5.4/testing carbon: build with Carbon cocoa: build with Cocoa (default) x11: build with X11 wrap: provide java, py26, tcl java: java wrapper py25: python 2.5 wrapper py26: python 2.6 wrapper tcl: tcl wrapper (MacPorts tcl/tk) tcl_apple: tcl wrapper (apple tcl/tk framework) database: provide all database variants mysql5: build the MySQL driver for vtkSQLDatabase pgsql83: build the PostgreSQL 8.3 driver for vtkSQLDatabase odbc: build the ODBC database interface mpi: use message passing interface (mpich2) for parallel support boost: use Boost libraries - www.boost.org universal: Build for multiple architectures Regards, Darren On Thu, Jun 18, 2009 at 10:19 AM, Jonathan Stickel jjstic...@vcn.comwrote: I reinstalled vtk5 with the +x11 variant, and now the vtk rendering library is linked to /opt/local/lib/libGL.1.dylib However, I still have the same problem of textActors not exporting. Labels on axes export fine, though. I suppose this could be reported upstream to VTK. Maybe I'll try vtk-devel (vtk-5.4) when I have some more time and see if the problem persists. Jonathan Jeremy Huddleston wrote: Interesting. We were just talking about some vtk oddities in the x11-users and xquartz-dev mailing list. Check out: http://www.ctcms.nist.gov/oof/renderingbug Since you're seeing this purely in carbon, my guess now is that this is an issue with either OpenGL.framework (which would mean it's in both Tiger and Leopard... which I think isn't too likely) or with VTK itself. On Jun 17, 2009, at 11:14, Jonathan Stickel wrote: I'm experiencing a problem using the GL2PS export feature of VTK, where VTK was installed via Macports (vtk5 @5.2.1_2+carbon+darwin_8+python). When I have a textActor in my render window, e.g. some arbitrary title or note, then that text does not show in the exported pdf/eps. I suspect the problem might be related to the OpenGL library that VTK links to, in this case /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL since I am using the Carbon variant. Can someone verify that they see this problem also? Any knowledge about how to resolve this? I am currently on Tiger. Thanks, Jonathan ___ 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 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: [MacPorts] #20773: Add zope2.10
I'm curious about using Plone, which is currently at version 3.3. I've downloaded the unified installer from http://plone.org/products/plone and I'll take a look at the content of that package to see what the latest dependencies are (most likely they are satisfied by some MacPorts). However, it appears the zope port is outdated. Is anyone else working on the Zope port? Is it a significant dependency of many other ports that are in wide use now? That is, what reason is there for the zope port to be outdated, if any? Are there functional reasons, politics, superceded software, or what? Thanks, Darren On Sat, Aug 22, 2009 at 3:44 PM, MacPorts nore...@macports.org wrote: #20773: Add zope2.10 -+-- Reporter: mar...@… | Owner: macports-tick...@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports| Version: 1.7.1 Keywords: |Port: zope zope2.10 -+-- As stated on the mailing list ( http://lists.macosforge.org/pipermail /macports-users/2009-February/013697.html ) I think there should be a port for zope2.10 (and probably zope2.9, zope2.11). As with the different Python versions it is a dependency for other applications like Plone. The attached port file is tested with MacPorts 1.710, Mac OS X 10.5, Intel. -- Ticket URL: http://trac.macports.org/ticket/20773 MacPorts http://www.macports.org/ Ports system for Mac OS ___ macports-tickets mailing list macports-tick...@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-tickets ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: [MacPorts] #20773: Add zope2.10
I'm curious about zope/plone, so not the best option to be a maintainer. I can, however, take a shot at the update, although it's not looking like a trivial process to get up to speed on this one! Check out this list of ports in the dports/zope tree: zope-archetypes/ zope-btreefolder2/ zope-cmf/ zope-cmfactionicons/ zope-cmfformcontroller/ zope-cmfmessage/ zope-cmfphoto/ zope-cmfphotoalbum/ zope-cmfplone/ zope-cmfquickinstallertool/ zope-cmfusertracktool/ zope-cvsfile/ zope-emil_email_client/ zope-externaleditor/ zope-externalfile/ zope-extfile/ zope-formulator/ zope-generator/ zope-groupuserfolder/ zope-localfs/ zope-localizer/ zope-mimetypesregistry/ zope-placelesstranslationservice/ zope-ploneerrorreporting/ zope-plonekeywordmanager/ zope-ploneloginhistory/ zope-plonewebmail/ zope-portaltransforms/ zope-revisionmanager/ zope-stripogram/ zope-usersniffer/ zope-usertrack/ zope-validation/ zope-zopetree/ zope-zopezen/ zope-zphotoslides/ zope-zsyncer/ The download link looks simple enough: http://www.zope.org/Products/ Zope appears to be stable at 2.11.4 and 3.4.0, so the dilemma may be which one or how many to port? From the zope site, we have options to download/install various python CMF too: http://www.zope.org/Products/CMF/ The recent stable versions of the python CMF available are 2.1.1, which is not the same as the python-zopeinterface version (3.3.0). The plot thickens when we get to the level of a Plone dependency tree, i.e.: http://plone.org/documentation/faq/plone-versions From this FAQ, it appears the plone installation may require it's own tailor-made CMF. For my part, I want to focus on Plone. I may work out a way to install plone with the bundled dependencies to avoid conflicts with other ports OR try to massage a Plone port to work with other ports. Note the specific dependency for Plone 3.x on python2.4.4 - it just doesn't get more specific than that ;-) As a general note about MacPorts, the general philosophy to maintain the most up to date packages is good. It's best to avoid multiple installation versions, wherever possible. In this case (Plone 3.x), it appears the very specific dependency requirements may force us to adopt some very version specific ports to satisfy those dependencies (eg, a port for python2.4.4 and zope2.10.x. Take care, Darren On Tue, Sep 8, 2009 at 12:57 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Sep 8, 2009, at 14:53, Darren Weber wrote: I'm curious about using Plone, which is currently at version 3.3. I've downloaded the unified installer from http://plone.org/products/plone and I'll take a look at the content of that package to see what the latest dependencies are (most likely they are satisfied by some MacPorts). However, it appears the zope port is outdated. Is anyone else working on the Zope port? Is it a significant dependency of many other ports that are in wide use now? That is, what reason is there for the zope port to be outdated, if any? Are there functional reasons, politics, superceded software, or what? As far as I know, the zope ports (there are 43 ports with zope in the name) are outdated because nobody maintains them. (Only the three py*-zopeinterface ports are maintained.) It would be great if somebody would maintain the rest of them and update them. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
port upgrade outdated - stops at build failure on doxygen
First, a general question about how the outdated ports are sorted - are they sorted alphabetically or is there a dependency heirarchy (or tree) that is searched to identify the order for upgrade? Now, is it possible to have 'port update outdated' continue after a build failure? Below is an example of a long list of outdated ports and the upgrade procedure fails on a port early in the process (doxygen in this case). So the upgrade stops without updating the rest of the outdated ports. For example: [ m...@xxx ~ ]$ port outdated The following installed ports are outdated: doxygen1.5.9_1 1.6.1_0 editres1.0.3_1 1.0.4_0 ffmpeg 0.5_3 0.5_5 gcc_select 0.1_3 0.1_4 gegl 0.1.0_1 0.1.0_2 git-core 1.6.4.2_0 1.6.4.4_0 glibmm 2.20.1_0 2.20.2_0 gnupg 1.4.9_0 1.4.10_0 gnupg2 2.0.12_1 2.0.13_0 gpg-agent 2.0.11_1 2.0.13_0 GraphicsMagick 1.3.6_0 1.3.7_0 ImageMagick6.5.5-7_0 6.5.6-1_0 iso-codes 3.10.3_0 3.11_0 jasper 1.900.1_4 1.900.1_5 libgeotiff 1.2.5_0 1.2.5_1 libksba1.0.5_0 1.0.7_0 libquicktime 1.1.3_0 1.1.3_1 librsvg2.26.0_0 2.26.0_1 libsdl 1.2.13_6 1.2.14_6 libsdl_gfx 2.0.19_0 2.0.20_0 libsigcxx2 2.2.3_0 2.2.4.2_0 libtheora 1.0_0 1.1.1_0 libusb 1.0.2_0 1.0.3_0 libxmlxx2 2.26.0_0 2.26.1_0 libxslt1.1.24_2 1.1.26_0 llvm 2.5_0 2.5_1 luit 1.0.3_1 1.0.4_0 maxima 5.18.1_0 5.19.2_0 mcpp 2.7.2_1 2.7.2_3 mesa 7.4.3_0 7.6_0 mod_wsgi 1.1_1 2.5_0 mysql5 5.0.85_0 5.0.86_0 mysql5-server 5.0.85_0 5.0.86_0 neon 0.28.4_0 0.28.6_0 netcdf 4.0_0 4.0.1_5 ocaml 3.11.1_0 3.11.1_2 openmotif 2.3.1-1_2 2.3.2_0 orbit2 2.14.17_0 2.14.17_1 p5-archive-tar 1.52_0 1.54_0 p5-compress-raw-bzip2 2.019_0 2.021_0 p5-compress-raw-zlib 2.020_0 2.021_0 p5-datetime0.47_0 0.50_0 p5-datetime-locale 0.42_0 0.44_0 p5-datetime-timezone 0.86_0 0.99_0 p5-digest-sha1 2.11_0 2.12_0 p5-extutils-cbuilder 0.2603_0 0.260301_0 p5-extutils-parsexs2.2002_0 2.200401_0 p5-html-parser 3.60_0 3.62_0 p5-libwww-perl 5.826_0 5.832_0 p5-mime-base64 3.07_0 3.08_0 p5-module-build0.34_0 0.35_0 p5-params-validate 0.91_0 0.92_0 p5-test-manifest 1.22_0 1.23_0 p5-uri 1.38_0 1.40_0 p5-version 0.76_0 0.7702_0 p5-xml-libxml 1.66_0 1.69_0 p5-xml-libxslt 1.66_0 1.68_0 p5-xml-parser-lite-tree0.03_0 0.11_0 p5-xml-xpathengine 0.11_0 0.12_0 php5 5.3.0_2 5.3.0_3 php5-apc 3.1.2_3 3.1.3p1_0 php5-http 1.6.3_3 1.6.5_0 pinentry 0.7.5_0 0.7.6_0 poppler0.11.1_0 0.12.0_0 postgresql83 8.3.7_0 8.3.8_0 postgresql83-server8.3.7_0 8.3.8_0 postgresql84 8.4.0_0 8.4.1_0 py-lint0.16.0_0 0.18.1_0 py-logilab-astng 0.17.4_0 0.19.1_0 py-logilab-common 0.42.0_0 0.45.0_0 py25-logilab-common0.42.0_0 0.45.0_0 py25-scientific2.6.1_0 2.8_0 py26-cairo 1.8.4_0 1.8.8_0 py26-ipython 0.9.1_0 0.10_0 py26-mpmath0.12_0 0.13_0 py26-nose 0.10.4_0 0.11.1_0 py26-pil 1.1.6_0 1.1.6_1 py26-tz2009j_0 2009n_0 python25 2.5.4_6 2.5.4_7 R 2.9.1_0 2.9.2_0 samba3 3.2.13_0 3.2.15_0 schroedinger 1.0.7_0 1.0.7_1 subversion 1.6.3_0 1.6.5_0 taglib 1.5_0 1.6_0 testdisk 6.9_0 6.11_0 tightvnc 1.3.9_0 1.3.9_2 vim7.2.222_0 7.2.245_1 vim-app7.2.222_0 7.2.245_0 VLC1.0.0_1 1.0.2_0 vtk-devel 5.4.0_5 5.4.2_0 wget 1.11.4_3 1.12_0 wxWidgets-devel
vtk-devel updated to 5.4.2
The port for vtk-devel has been updated to ver 5.4.2 (it may take a few hours to propagate this svn update into the rsync distribution). This update builds and installs using 'sudo port install vtk-devel +huge'. (This updated version was only tested on Leopard.) The port now uses PostgreSQL 8.4 instead of 8.3 (the 8.3 variant is still available for those who require that - get back to me with any problems doing an upgrade or new install that requires the pgsql83 variant). Take care, Darren PS, The Portfile can be viewed here: http://trac.macports.org/browser/trunk/dports/graphics/vtk-devel/Portfile ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
location of hdf5 header files
In cursory exploration of /opt/local/include/, it appears that many, if not all, of the hdf5 header files are located at the root of /opt/local/include/. Is that a mistake? Should the hdf5 include files get stored into something like /opt/local/include/hdf5/? Take care, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: location of hdf5 header files
On Thu, Oct 8, 2009 at 12:16 PM, Ryan Schmidt ryandes...@macports.orgwrote:
On Oct 8, 2009, at 13:37, Darren Weber wrote:
In cursory exploration of /opt/local/include/, it appears that many, if
not all, of the hdf5 header files are located at the root of
/opt/local/include/. Is that a mistake? Should the hdf5 include files get
stored into something like /opt/local/include/hdf5/?
Using port contents hdf5 | grep \\.h$ I would agree that all this port's
headers are in ${prefix}/include. Is that a problem? Would it be better to
have them in a subdirectory? The port doesn't seem to do anything to change
the header location at present, so it just installs them where the developer
of that software thought they should go. Is there a problem you're trying to
solve by moving the headers?
Ah, it's not a current problem that prevents or interference with other
ports within MacPorts, ASFAIK.
Firstly, it's a convenience. When using ctags or any IDE system to analyze
a set of header files (for programming autocompletion), it is convenient to
have the headers in a package specific path within the general
${prefix}/include path. This is especially true for large packages, like
wx*, vtk*, InsightToolkit*, etc.
Secondly, it's a safety-net. At the very least, it is significant and
important that any headers located in the generic ${prefix}/include have
some kind of unique naming convention, like a prefix in their file name, to
avoid any conflicts with other software packages. The hdf5 package appears
to have the file prefix of H5 to distinguish it from other packages.
However, a two-char prefix is not exactly a reliable unique identifier,
especially on a file system that is not case sensitive. To avoid potential
conflicts with other software packages, it may be preferable to locate the
headers within ${prefix}/include/hdf5/. An additional layer may be added by
using ${prefix}/include/hdf5-${ver} where ver=1.6 (as of the current
writing, we have hdf5 @ 1.6.9). The version specific path should allow
multiple versions of the library to co-exist in the ports tree (in this
regard, we have seen some issues with versions of the hdf5 port in relation
to the netcdf port).
Take care,
Darren
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: location of hdf5 header files
On Thu, Oct 8, 2009 at 12:53 PM, Jochen Küpper
kuepper.joc...@googlemail.com wrote:
On 08.10.2009, at 21:46, Darren Weber wrote:
On Thu, Oct 8, 2009 at 12:16 PM, Ryan Schmidt ryandes...@macports.org
wrote:
On Oct 8, 2009, at 13:37, Darren Weber wrote:
In cursory exploration of /opt/local/include/, it appears that many, if
not all, of the hdf5 header files are located at the root of
/opt/local/include/. Is that a mistake? Should the hdf5 include files get
stored into something like /opt/local/include/hdf5/?
Using port contents hdf5 | grep \\.h$ I would agree that all this port's
headers are in ${prefix}/include. Is that a problem? Would it be better to
have them in a subdirectory? The port doesn't seem to do anything to change
the header location at present, so it just installs them where the developer
of that software thought they should go. Is there a problem you're trying to
solve by moving the headers?
Ah, it's not a current problem that prevents or interference with other
ports within MacPorts, ASFAIK.
Firstly, it's a convenience. When using ctags or any IDE system to
analyze a set of header files (for programming autocompletion), it is
convenient to have the headers in a package specific path within the general
${prefix}/include path. This is especially true for large packages, like
wx*, vtk*, InsightToolkit*, etc.
Secondly, it's a safety-net. At the very least, it is significant and
important that any headers located in the generic ${prefix}/include have
some kind of unique naming convention, like a prefix in their file name, to
avoid any conflicts with other software packages. The hdf5 package appears
to have the file prefix of H5 to distinguish it from other packages.
However, a two-char prefix is not exactly a reliable unique identifier,
especially on a file system that is not case sensitive. To avoid potential
conflicts with other software packages, it may be preferable to locate the
headers within ${prefix}/include/hdf5/. An additional layer may be added by
using ${prefix}/include/hdf5-${ver} where ver=1.6 (as of the current
writing, we have hdf5 @ 1.6.9). The version specific path should allow
multiple versions of the library to co-exist in the ports tree (in this
regard, we have seen some issues with versions of the hdf5 port in relation
to the netcdf port).
But you then have to teach your compiler where to find the headers
individually for all these packets... Software written for hdf5 generally
assumes that
#include H5...
works and no
#include hdf5-1.x/H5...
is necessary...
I think it's fine as it is, until there is a actual name clash.
Then it should be fixed upstream and all software has to be adopted to the
new naming scheme...
Yes, it's best practice to avoid #includes like this:
#include hdf5-1.x/H5...
Rather, the common and perhaps preferred method to avoid such #include code
styles is to use an include path as an argument to the compiler. This is
the way to provide code that can build on various systems and it's the
purpose of autoconf and similar tools to figure out where to find the
libraries if they are not specified using some form of include path option
(gcc has the -I and -L options).
For example, assume a source file contains:
#include H5ArrayType.h
This file may be compiled on any distribution (where the package maintainers
determine where stuff goes), using the convention of specific include path
options for autoconf-like tools or the compiler suite.
If the hdf5 libs are located in /opt/local/, that is the path to provide,
eg:
gcc -I/opt/local ...
Software developers do suggest the default locations for the include and
lib files in the default settings for autoconf and like tools (perhaps they
provide a install shell script with defaults). The defaults are often
consistent with a general consensus on where things go, like /usr/local and
such. Note that MacPorts already discards the general consensus for using
/usr/* paths, for good reason too. It is just a consensus, not a rule of
law. The beauty of path specifications for autoconf and compilers is that
the source code can be developed independently of the installation location
for the headers/libs and, furthermore, package distribution systems can use
ANY path configuration (e.g., AFAIK fink uses /sw/*).
Getting back to the main point here, in the case of hdf5, there are multiple
ports related to this software package:
[ m...@xxx ~ ]$ port search hdf
h4h5tools @2.0 (science)
HDF4 to HDF5 conversion tools.
hdf4 @4.2r4 (science)
file format for storing scientific data and utilities
hdf5 @1.6.9 (science)
HDF5 general purpose library and file format for storing scientific data
hdf5-18 @1.8.3 (science)
HDF5 general purpose library and file format for storing scientific data
hdfeos @2.15v1.00 (science)
HDF-EOS library built on HDF4
py25-tables @2.1.2 (python, python, science)
Python package for HDF5 file access.
py26
cvs2svn dependencies
With reference to this page: http://cvs2svn.tigris.org/cvs2svn.html There are various run-time dependencies indicated under the title of Requirements. Are any of these included as dependencies in the MacPorts cvs2svn port? (I don't see any.) Also, is it possible to have a symlink or hardlink: /opt/local/bin/cvs2svn - /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/cvs2svn Take care, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: cvs2svn dependencies
On Thu, Oct 8, 2009 at 4:23 PM, Daniel J. Luke dl...@geeklair.net wrote:
On Oct 8, 2009, at 7:11 PM, Darren Weber wrote:
With reference to this page:
http://cvs2svn.tigris.org/cvs2svn.html
There are various run-time dependencies indicated under the title of
Requirements. Are any of these included as dependencies in the MacPorts
cvs2svn port? (I don't see any.)
That page lists
1- python (which is a port dependency)
2- db library and python bindings (python26 port builds with db46 and gdbm
already)
3- gnu sort (comes with mac os x)
optionally can use rcs or cvs if you pass in appropriate options (and you
can pass the path to those binaries). both cvs and rcs are included with Mac
OS X (or you could install a macports version if you wanted and point
cvs2svn to them).
did you notice something broken?
No, I just couldn't find 'cvs2svn' in the default bin path. Then looking
over the web page indicated earlier it appeared that some dependencies were
not specified, but you clarified all that above. I guess it wouldn't hurt
to specify build or lib dependencies on 'gdbm' and 'coreutils' (but
coreutils can install with a 'g' prefix such as /opt/local/bin/gsort and
it's unlikely that cvs2svn will look for that).
Also, is it possible to have a symlink or hardlink:
/opt/local/bin/cvs2svn -
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/cvs2svn
cvs2svn used to install to ${prefix}/bin but the python26 portgroup sets
prefix to ${frameworks_dir}/Python.framework/Versions/2.6
presumably this is so that one could install a cvs2svn against python26 and
one against another version of python...
Linking cvs2bzr, cvs2git, and cvs2svn to ${prefix}/bin would be one
possible solution ...
Oh, I see. (Maybe they should be using $pyPrefix to avoid a clash with the
general MacPorts $prefix?)
I now have a bash alias as a personal work-around:
alias
cvs2svn='/opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/cvs2svn'
Thanks!
Darren
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
X11 flicker (using imagemagick::animate)
Does anyone see a lot of flicker and poor interaction behavior when using the animate tool from ImageMagick? It's almost useless on 10.5.8, with XQuartz 2.4.0. It looks like ImageMagick builds against MacPorts X11 libs, not the XQuartz installation: $ otool -L /opt/local/bin/animate /opt/local/bin/animate: /opt/local/lib/libMagickCore.2.dylib (compatibility version 3.0.0, current version 3.0.0) /opt/local/lib/libMagickWand.2.dylib (compatibility version 3.0.0, current version 3.0.0) /opt/local/lib/libtiff.3.dylib (compatibility version 13.0.0, current version 13.1.0) /opt/local/lib/libjbig.2.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /opt/local/lib/libjpeg.62.dylib (compatibility version 63.0.0, current version 63.0.0) /opt/local/lib/libfftw3.3.dylib (compatibility version 6.0.0, current version 6.4.0) /opt/local/lib/libfontconfig.1.dylib (compatibility version 6.0.0, current version 6.3.0) /opt/local/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 7.2.0) /opt/local/lib/libfreetype.6.dylib (compatibility version 10.0.0, current version 10.20.0) /opt/local/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0) /opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0) /opt/local/lib/libXt.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5) /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /opt/local/lib/libltdl.7.dylib (compatibility version 10.0.0, current version 10.0.0) /opt/local/lib/libSM.6.dylib (compatibility version 7.0.0, current version 7.1.0) /opt/local/lib/libICE.6.dylib (compatibility version 10.0.0, current version 10.0.0) /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0) /opt/local/lib/libXau.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/local/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current version 7.0.0) /opt/local/lib/libgomp.1.dylib (compatibility version 2.0.0, current version 2.0.0) /opt/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: how to remove distfiles etc. (short of disk space on a laptop)
On Fri, Nov 6, 2009 at 11:32 AM, Jochen Küpper kuepper.joc...@googlemail.com wrote: On 06.11.2009, at 19:30, Darren Weber wrote: We have a laptop that is very short on disk space. There is a bunch of stuff lying around in: It would be a start to run port clean –-all all There are some warnings, like: --- Cleaning arm-aout-binutils Warning: Distfiles directory '/opt/local/var/macports/ distfiles/binutils' may contain distfiles needed for other ports, use the -f flag to force removal ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
port inactive - not really inactive?
What's an explanation for this apparent anomaly: $ port echo inactive binutils @2.20_0 g95@0.91_1+darwin_9 gnupg @1.4.10_0 gnutar @1.22_0 hdf5-18@1.8.3_0 hdf5-18@1.8.3_1 snip $ sudo port uninstall inactive --- Uninstalling binutils @2.20_0 --- Uninstalling g95 @0.91_1+darwin_9 --- Unable to uninstall gnupg 1.4.10_0, the following ports depend on it: --- p5-module-signature Error: port uninstall failed: Please uninstall the ports that depend on gnupg first. $ port installed gnupg The following ports are currently installed: gnupg @1.4.10_0 $ port installed gnupg* The following ports are currently installed: gnupg @1.4.10_0 gnupg2 @2.0.13_0+darwin (active) $ port installed p5-module* The following ports are currently installed: p5-module-build @0.35_0 (active) p5-module-signature @0.55_0 (active) $ port deps p5-module-signature Full Name: p5-module-signature @0.55 Library Dependencies: perl5, gnupg, p5-digest-sha How is it possible for p5-module-signature to depend on an inactive port? Is this an indication to fix this with: $ sudo port install gnupg Password: --- Computing dependencies for gnupg --- Activating gnupg @1.4.10_0 --- Cleaning gnupg $ port installed gnupg* The following ports are currently installed: gnupg @1.4.10_0 (active) gnupg2 @2.0.13_0+darwin (active) TIA, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
HDF5 dilemma
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? Take care, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: HDF5 dilemma
On Fri, Nov 6, 2009 at 3:34 PM, Darren Weber dwe...@macports.org 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?
Take care,
Darren
PS,
$ for f in `find macports.svn/dports -name Portfile`; do grep -H hdf5 $f;
done
macports.svn/dports/math/gnudatalanguage/Portfile:
port:hdf5-18 \
macports.svn/dports/math/gnudatalanguage/Portfile: reinplace
s|-L\$with_hdf5/lib/hdf -L\$with_hdf5/lib/hdf5|| \
macports.svn/dports/math/gnudatalanguage/Portfile: reinplace
s|-I\$with_hdf5/include/hdf -I\$with_hdf5/include/hdf5|| \
macports.svn/dports/math/gnudatalanguage/Portfile:
--with-hdf5=${prefix} \
macports.svn/dports/math/octave/Portfile:port:hdf5-18 \
macports.svn/dports/math/octave/Portfile:--with-hdf5 \
macports.svn/dports/math/petsc/Portfile:variant hdf5 description {build with
support for HDF5 file format} {
macports.svn/dports/math/petsc/Portfile:configure.args-append
--with-hdf5=1 --with-hdf5-dir=${prefix} \
macports.svn/dports/math/petsc/Portfile:depends_lib-append
port:hdf5-18
macports.svn/dports/python/py-tables/Portfile:depends_lib-append
port:hdf5 port:py-numpy port:bzip2
macports.svn/dports/python/py-tables/Portfile:
--hdf5=${prefix}
macports.svn/dports/python/py-tables/Portfile:destroot.args
--hdf5=${prefix}
macports.svn/dports/python/py25-h5py/Portfile:configure.args --api=18
--hdf5=${prefix}
macports.svn/dports/python/py25-h5py/Portfile:depends_lib-append
port:py25-numpy port:hdf5-18
macports.svn/dports/python/py25-tables/Portfile:depends_lib-append
port:hdf5-18 \
macports.svn/dports/python/py25-tables/Portfile:
--hdf5=${prefix} \
macports.svn/dports/python/py25-tables/Portfile:destroot.args
--hdf5=${prefix} \
macports.svn/dports/python/py26-h5py/Portfile:configure.args --api=18
--hdf5=${prefix}
macports.svn/dports/python/py26-h5py/Portfile:depends_lib-append
port:py26-numpy port:hdf5-18
macports.svn/dports/python/py26-tables/Portfile:depends_lib-append
port:hdf5-18 \
macports.svn/dports/python/py26-tables/Portfile:
--hdf5=${prefix} \
macports.svn/dports/python/py26-tables/Portfile:destroot.args
--hdf5=${prefix} \
macports.svn/dports/science/cdo/Portfile:depends_lib-append
port:hdf5-18
macports.svn/dports/science/cdo/Portfile:configure.args-append
--with-hdf5=${prefix} \
macports.svn/dports/science/gdal/Portfile:--without-ogdi
--without-fme --without-hdf4 --without-hdf5 \
macports.svn/dports/science/gdal/Portfile:variant hdf5 description {Enable
HDF5 file format} {
macports.svn/dports/science/gdal/Portfile:depends_lib-append
port:hdf5
macports.svn/dports/science/gdal/Portfile:configure.args-delete
--without-hdf5
macports.svn/dports/science/gdal/Portfile:configure.args-append
--with-hdf5=${prefix}
macports.svn/dports/science/h4h5tools/Portfile:depends_lib-append
port:hdf5 \
macports.svn/dports/science/hdf5/Portfile:namehdf5
macports.svn/dports/science/hdf5/Portfile:
ftp://ftp.hdfgroup.org/HDF5/prev-releases/hdf5-${version}/src/
macports.svn/dports/science/hdf5-18/Portfile:set realnamehdf5
macports.svn/dports/science/hdf5-18/Portfile:
ftp://ftp.hdfgroup.org/HDF5/prev-releases/hdf5-${version}/src/
macports.svn/dports/science/nco/Portfile: depends_lib-append
port:hdf5-18 \
macports.svn/dports/science/netcdf/Portfile:variant netcdf4 description
{compile with hdf5} {
macports.svn/dports/science/netcdf/Portfile:configure.env-append
LDFLAGS=-L${prefix}/lib LIBS=-lhdf5 -lhdf5_hl
macports.svn/dports/science/netcdf/Portfile:
--with-hdf5=${prefix} \
macports.svn/dports/science/netcdf/Portfile:
port:hdf5-18
macports.svn/dports/science/vis5d/Portfile:#reinplace s|-lnetcdf
\$V5D_LIBS_AUX|-lnetcdf -lhdf5_hl -lhdf5 -lz -lcurl \$V5D_LIBS_AUX| \
macports.svn/dports/science/wgrib2/Portfile:
-lgrib2c -ljasper -lnetcdf -lhdf5_hl -lhdf5 -lpng -lz\
macports.svn/dports/science/wgrib2
