Re: persisting problems with pdf display in `gv': error /undefined in copy_trailer_attrs
On Thu, 20 May 2010 14:51:18 +0200, Ryan Schmidt ryandes...@macports.org
wrote:
On May 19, 2010, at 13:45, joerg van den hoff wrote:
I reported something similar a few weeks back (no response, though):
after
a further `port selfupdate; port update outdated' the problem persists:
gv any_pdf_file
throws the ghostscript error:
/undefined in copy_trailer_attrs
and that's it. doing
gs any_pdf_file
works as does
gv any_ps_file
this is on 10.6 x86 powerbook with current macports and gv-3.6.9,
gs-8.71
any ideas?
Sorry you didn't get a response before, but it's probably just because
nobody knew how to help you. You may need to ask the developers of gv
for assistance.
ryan,
I followed your advice, contacting the `gv' maintainer, who thankfully
responded quickly and to the point:
this is not a `gv' bug but rather a bug in ghostscript 8.71. the affected
file is at (for macports):
/opt/local/share/ghostscript/8.71/lib/pdf2dsc.ps
and here is the diff to patch it:
==CUT=
--- ghostscript-8.71/lib/pdf2dsc.ps.copy_trailer_attrs 2008-02-25
05:48:45.0 +
+++ ghostscript-8.71/lib/pdf2dsc.ps.copy_trailer_attrs 2010-02-19
21:35:15.0 +
@@ -116,7 +116,7 @@ systemdict /.setsafe known { .setsafe }
DSCfile PDFname write==only
( \(r\) file { DELAYSAFER { .setsafe } if } stopped pop\n) puts
( pdfopen begin\n) puts
- ( copy_trailer_attrs\n) puts
+ ( process_trailer_attrs\n) puts
(%%EndSetup\n) puts
/.hasPageLabels false def % see Page Labels in the PDF Reference
==CUT=
found here:
https://bugzilla.redhat.com/attachment.cgi?id=395186action=edit
after this patch `gv' displays pdf just fine as it used to do.
I think this should of course be patched upstream, but if this does not
work right now, it should be done during the macports install process
(sorry, I don't know
the internals of `ports', otherwise I would do it...)
thanks again and
best regards,
joerg
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: persisting problems with pdf display in `gv': error /undefined in copy_trailer_attrs
On Thu, 20 May 2010 14:51:18 +0200, Ryan Schmidt ryandes...@macports.org wrote: On May 19, 2010, at 13:45, joerg van den hoff wrote: I reported something similar a few weeks back (no response, though): after a further `port selfupdate; port update outdated' the problem persists: gv any_pdf_file throws the ghostscript error: /undefined in copy_trailer_attrs and that's it. doing gs any_pdf_file works as does gv any_ps_file this is on 10.6 x86 powerbook with current macports and gv-3.6.9, gs-8.71 any ideas? Sorry you didn't get a response before, but it's probably just because nobody knew how to help you. You may need to ask the developers of gv for assistance. yes, and I will try this (ask `gv' developers) in the next step, although I believe (not sure) it has something to do with macports: exactly at the same time when the trouble with `gv' started, `xpdf' started to complain (but keeps working) about _lots_ of missing/unaccessible fonts. and that for such esoteric (...) fonts as helvetica, e.g.: : Couldn't create a font for 'Helvetica' might I have something broken regarding the X11 font set up? anyway thanks a lot for bothering (and thanks to all maintainers for keeping macports alive) joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
persisting problems with pdf display in `gv': error /undefined in copy_trailer_attrs
I reported something similar a few weeks back (no response, though): after a further `port selfupdate; port update outdated' the problem persists: gv any_pdf_file throws the ghostscript error: /undefined in copy_trailer_attrs and that's it. doing gs any_pdf_file works as does gv any_ps_file this is on 10.6 x86 powerbook with current macports and gv-3.6.9, gs-8.71 any ideas? thanks joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: rb-ncurses-ruby install failed
On Thu, 29 Apr 2010 01:40:45 +0200, Ryan Schmidt ryandes...@macports.org wrote: On Apr 28, 2010, at 16:24, joerg van den hoff wrote: I tried to insall `sup' today on two machines. the first instance (ppc and 10.5) went through the second (10.6 and x86) failed during install of the dependency `rb-ncurses-ruby'. Yes, we have a ticket for this problem: http://trac.macports.org/ticket/21672 thanks a lot for the pointer (I'll try to look more often into the ticket list before posting...). the proposed workaround seems to fail for me though. mmh. hopefully someone finds time to look into this. regards, joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
gem problem; probably related to Ticket #23875 (pec_fetcher.rb:232: warning: getc is obsolete; use STDIN.getc instead)
hi, I noticed the mentioned ticket (2 month old), so I just want to report I observe the exact same problem under 10.5 (ppc) as well. any chance of a solution (or a workaround) soon? best joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
rb-ncurses-ruby install failed
hello everybody, I tried to insall `sup' today on two machines. the first instance (ppc and 10.5) went through the second (10.6 and x86) failed during install of the dependency `rb-ncurses-ruby'. on the second try I get this messages: CUT= --- Computing dependencies for rb-ncurses-ruby --- Staging rb-ncurses-ruby into destroot Error: Target org.macports.destroot returned: shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_ruby_rb-ncurses-ruby/work/ncurses-ruby-1.2.3 /opt/local/bin/gem install --local --force --install-dir /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_ruby_rb-ncurses-ruby/work/destroot/opt/local/lib/ruby/gems/1.8 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_ruby_rb-ncurses-ruby/work/ncurses-ruby-1.2.3/ncurses-1.2.3.gem returned error 1 Command output: checking for attr_get()... yes checking for the panel library... checking for panel.h... yes checking for panel_hidden() in -lpanel... yes checking for the form library... checking for form.h... yes checking for new_form() in -lform... yes checking for the menu library... checking for menu.h... yes checking for new_menu() in -lmenu... yes creating Makefile make Makefile:134: warning: overriding commands for target `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_ruby_rb-ncurses-ruby/work/destroot/opt/local/lib/ruby/gems/1.8/gems/ncurses-1.2.3/lib' Makefile:132: warning: ignoring old commands for target `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_ruby_rb-ncurses-ruby/work/destroot/opt/local/lib/ruby/gems/1.8/gems/ncurses-1.2.3/lib' /usr/bin/gcc-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin10 -I. -DHAVE_UNISTD_H -DHAVE_LOCALE_H -DHAVE_NCURSES_H -DHAVE_NEWSCR -DHAVE_TABSIZE -DHAVE_ESCDELAY -DHAVE_KEYBOUND -DHAVE_CURSES_VERSION -DHAVE_TIGETSTR -DHAVE_GETWIN -DHAVE_PUTWIN -DHAVE_UNGETMOUSE -DHAVE_MOUSEMASK -DHAVE_WENCLOSE -DHAVE_MOUSEINTERVAL -DHAVE_WMOUSE_TRAFO -DHAVE_MCPRINT -DHAVE_HAS_KEY -DHAVE_DELSCREEN -DHAVE_DEFINE_KEY -DHAVE_KEYOK -DHAVE_RESIZETERM -DHAVE_USE_DEFAULT_COLORS -DHAVE_USE_EXTENDED_NAMES -DHAVE_WRESIZE -DHAVE_ATTR_ON -DHAVE_ATTR_OFF -DHAVE_ATTR_SET -DHAVE_CHGAT -DHAVE_COLOR_SET -DHAVE_FILTER -DHAVE_INTRFLUSH -DHAVE_MVCHGAT -DHAVE_MVHLINE -DHAVE_MVVLINE -DHAVE_MVWCHGAT -DHAVE_MVWHLINE -DHAVE_MVWVLINE -DHAVE_NOQIFLUSH -DHAVE_PUTP -DHAVE_QIFLUSH -DHAVE_SCR_DUMP -DHAVE_SCR_INIT -DHAVE_SCR_RESTORE -DHAVE_SCR_SET -DHAVE_SLK_ATTR -DHAVE_SLK_ATTR_SET -DHAVE_SLK_COLOR -DHAVE_TIGETFLAG -DHAVE_TIGETNUM -DHAVE_USE_ENV -DHAVE_VIDATTR -DHAVE_WATTR_ON -DHAVE_WATTR_OFF -DHAVE_WATTR_SET -DHAVE_WCHGAT -DHAVE_WCOLOR_SET -DHAVE_GETATTRS -DHAVE_ASSUME_DEFAULT_COLORS -DHAVE_ATTR_GET -DHAVE_PANEL_H -DHAVE_FORM_H -DHAVE_MENU_H -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -O2 -arch x86_64 -fno-common -pipe -fno-common -g -arch x86_64 -c form_wrap.c form_wrap.c: In function 'make_arg': form_wrap.c:1130: warning: format '%d' expects type 'int', but argument 6 has type 'long int' /usr/bin/gcc-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin10 -I. -DHAVE_UNISTD_H -DHAVE_LOCALE_H -DHAVE_NCURSES_H -DHAVE_NEWSCR -DHAVE_TABSIZE -DHAVE_ESCDELAY -DHAVE_KEYBOUND -DHAVE_CURSES_VERSION -DHAVE_TIGETSTR -DHAVE_GETWIN -DHAVE_PUTWIN -DHAVE_UNGETMOUSE -DHAVE_MOUSEMASK -DHAVE_WENCLOSE -DHAVE_MOUSEINTERVAL -DHAVE_WMOUSE_TRAFO -DHAVE_MCPRINT -DHAVE_HAS_KEY -DHAVE_DELSCREEN -DHAVE_DEFINE_KEY -DHAVE_KEYOK -DHAVE_RESIZETERM -DHAVE_USE_DEFAULT_COLORS -DHAVE_USE_EXTENDED_NAMES -DHAVE_WRESIZE -DHAVE_ATTR_ON -DHAVE_ATTR_OFF -DHAVE_ATTR_SET -DHAVE_CHGAT -DHAVE_COLOR_SET -DHAVE_FILTER -DHAVE_INTRFLUSH -DHAVE_MVCHGAT -DHAVE_MVHLINE -DHAVE_MVVLINE -DHAVE_MVWCHGAT -DHAVE_MVWHLINE -DHAVE_MVWVLINE -DHAVE_NOQIFLUSH -DHAVE_PUTP -DHAVE_QIFLUSH -DHAVE_SCR_DUMP -DHAVE_SCR_INIT -DHAVE_SCR_RESTORE -DHAVE_SCR_SET -DHAVE_SLK_ATTR -DHAVE_SLK_ATTR_SET -DHAVE_SLK_COLOR -DHAVE_TIGETFLAG -DHAVE_TIGETNUM -DHAVE_USE_ENV -DHAVE_VIDATTR -DHAVE_WATTR_ON -DHAVE_WATTR_OFF -DHAVE_WATTR_SET -DHAVE_WCHGAT -DHAVE_WCOLOR_SET -DHAVE_GETATTRS -DHAVE_ASSUME_DEFAULT_COLORS -DHAVE_ATTR_GET -DHAVE_PANEL_H -DHAVE_FORM_H -DHAVE_MENU_H -I/opt/local/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I/opt/local/include -fno-common -O2 -arch x86_64 -fno-common -pipe -fno-common -g -arch x86_64 -c menu_wrap.c /usr/bin/gcc-4.2 -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin10 -I. -DHAVE_UNISTD_H -DHAVE_LOCALE_H -DHAVE_NCURSES_H -DHAVE_NEWSCR -DHAVE_TABSIZE -DHAVE_ESCDELAY -DHAVE_KEYBOUND -DHAVE_CURSES_VERSION -DHAVE_TIGETSTR -DHAVE_GETWIN -DHAVE_PUTWIN -DHAVE_UNGETMOUSE -DHAVE_MOUSEMASK -DHAVE_WENCLOSE -DHAVE_MOUSEINTERVAL -DHAVE_WMOUSE_TRAFO -DHAVE_MCPRINT -DHAVE_HAS_KEY -DHAVE_DELSCREEN
problems with `xpdf' and `gv' after `port upgrade outdated'
hello, both mentioned viewers do no longer work properly after the `port upgrade outdated' run (xpdf itself was _not_ updated in this run AFAICS but `gv' was). I noted that among other packages, `openmotif' and `ghostscript' underwent update. what I see is e.g. `gv' without arguments starts, but segfaults when immediately quitting with `q' `xpdf' segfaults immediately (except in a single instance where it popped up like `gv' does and segfaults later on). could these be openmotif related problems? `gv some.pdf' pops up the viewer, but does not show anything except the error window: the error message for 10.5 and ppc is: ==CUT Error: /undefinedGPL Ghostscript 8.71: Unrecoverable error, exit code 1 in copy_trailer_attrs Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1878 1 3 %oparray_pop 1877 1 3 %oparray_pop 1861 1 3 %oparray_pop 1755 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary st ==CUT= while the same for 10.6 and x86 causes the message ===CUT== Error: /undefined in copy_trailer_attrs Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1878 1 3 %oparray_pop 1877 1 3 %oparray_pop 1861 1 3 %oparray_pop 1755 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringvaGPL Ghostscript 8.71: Unrecoverable error, exit code 1 l-- Dictionary stack: --dict:1156/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)-- --dict:108/127(ro)(G)-- --dict:288/300(ro)(G)-- --dict:21/25(L)-- Current allocation mode is local ==CUT `gs some.pdf' (i.e. using ghostscript directly) displays the document just fine. `gv some.ps' seems to work OK (just a single test). I would guess, this has to do with ghostscript problems, but I'm not sure, of course. any advice would be appreciated. thanks joerg PS: using port version 1.8.2 with updated package list from yesterday and macos 10.5(ppc) and 10.6(x86) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
install of `sbcl' failed
hi there, sudo port install sbcl failed and rerunning as adviced as sudo port -d install sbcl yielded cut=== DEBUG: Found port in file:///opt/local/var/macports/sources/rsync.macports.org/release/ports/lang/sbcl DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/lang/sbcl DEBUG: OS Platform: darwin DEBUG: OS Version: 10.3.0 DEBUG: Mac OS X Version: 10.6 DEBUG: System Arch: i386 DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf DEBUG: not using configure, so not adding the default universal variant DEBUG: Requested variant darwin is not provided by port sbcl. DEBUG: Requested variant i386 is not provided by port sbcl. DEBUG: Requested variant macosx is not provided by port sbcl. DEBUG: Executing variant darwin_10_i386 provides darwin_10_i386 DEBUG: Executing variant html provides html --- Computing dependencies for sbcl DEBUG: Executing org.macports.main (sbcl) DEBUG: Skipping completed org.macports.fetch (sbcl) DEBUG: Skipping completed org.macports.checksum (sbcl) DEBUG: setting option extract.cmd to /usr/bin/bzip2 DEBUG: Skipping completed org.macports.extract (sbcl) DEBUG: Skipping completed org.macports.patch (sbcl) DEBUG: Skipping completed org.macports.configure (sbcl) --- Building sbcl DEBUG: Executing org.macports.build (sbcl) sh: line 0: cd: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.37: No such file or directory Error: Target org.macports.build returned: shell command unset LD_PREBIND unset LD_PREBIND_ALLOW_OVERLAP cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.37 sh make.sh /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.12-x86-darwin/src/runtime/sbcl --core /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.12-x86-darwin/output/sbcl.core --disable-debugger --sysinit /dev/null --userinit /dev/null returned error 1 DEBUG: Backtrace: shell command unset LD_PREBIND unset LD_PREBIND_ALLOW_OVERLAP cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.37 sh make.sh /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.12-x86-darwin/src/runtime/sbcl --core /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.12-x86-darwin/output/sbcl.core --disable-debugger --sysinit /dev/null --userinit /dev/null returned error 1 while executing $procedure $targetname Warning: the following items did not execute (for sbcl): org.macports.activate org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. To report a bug, see http://guide.macports.org/#project.tickets ===cut=== this happened both with 10.5 on ppc as well as 10.6 on i386 I see there is a 'no such file' problem but how does this come about? any ideas? thanks joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: install of `sbcl' failed
On Mon, 26 Apr 2010 17:06:17 +0200, Rainer Müller rai...@macports.org wrote: On 2010-04-26 16:46 , joerg van den hoff wrote: I see there is a 'no such file' problem but how does this come about? any ideas? thanks for the quick reply! Which version of MacPorts are you using? It is currently failing with current (1.8.2.) trunk as the order changed in which platform blocks are evaluated. sorry for posting (and not checking the tickets) if it is known already. any hope for a solution soon? or is there a workaround (an easy one, that is)? another point: `sbcl' has to be installed as a dependency of the computer algebra system `maxima' which is written in lisp. prior to my todays upgrading of the package descriptions there was a variant sudo port install maxima +clisp which worked (i.e. clisp installed without problem) by using `clisp' instead of the default `sbcl' as the lisp interpreter. now (after updating the package list), this variant is gone. since maxima seems to have no maintainer I might probably ask here as well: does somebody know, why the `clisp' variant is gone (it would help for now to get maxima running again...)? thanks joerg Rainer ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: install of `sbcl' failed
On Mon, 26 Apr 2010 17:39:58 +0200, Rainer Müller rai...@macports.org wrote: On 2010-04-26 17:28 , joerg van den hoff wrote: Which version of MacPorts are you using? It is currently failing with current (1.8.2.) trunk as the order changed in which platform blocks are evaluated. sorry for posting (and not checking the tickets) if it is known already. any hope for a solution soon? or is there a workaround (an easy one, that is)? It is supposed to work with 1.8.2, so this is not what I thought initially. Works fine for me with 1.8.2 on Snow Leopard as I just tested. which is of course good to know but makes me only partially happy ;-) especially my snow leopard installation of macports is overall quite young (a few month) and has had not that much time to become messed up, inconsistent or whatever. anyhow, something seems to be different for my setup. and I see the same problem on 10.5 ppc machine with an independent macports setup... my question: can I do any further testing and/or provide further information which would help to corner the problem? regards, joerg Rainer ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: install of `sbcl' failed
ryan, rainer, really thanks a lot for bothering with this. On Mon, 26 Apr 2010 20:07:31 +0200, Ryan Schmidt ryandes...@macports.org wrote: On Apr 26, 2010, at 09:46, joerg van den hoff wrote: DEBUG: Skipping completed org.macports.fetch (sbcl) DEBUG: Skipping completed org.macports.checksum (sbcl) DEBUG: setting option extract.cmd to /usr/bin/bzip2 DEBUG: Skipping completed org.macports.extract (sbcl) DEBUG: Skipping completed org.macports.patch (sbcl) DEBUG: Skipping completed org.macports.configure (sbcl) --- Building sbcl DEBUG: Executing org.macports.build (sbcl) sh: line 0: cd: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.37: No such file or directory this happened both with 10.5 on ppc as well as 10.6 on i386 I see there is a 'no such file' problem but how does this come about? any ideas? Since it works for Rainer and for me, I can only suggest that you somehow successfully completed sbcl's extract phase, then perhaps interrupted the installation, then deleted the extracted directory. I'd suggest you start on both machines by cleaning the port and trying again. actually, I did not. what I did in the first place was trying to install maxima: sudo port install maxima which led _directly_ (without any intervention on my side) to the reported error (the final one, that the make target could not be executed). sudo port clean sbcl sudo port -d install sbcl If it fails again, send us the complete debug output this will produce. this worked (and it's completely my fault that I did not try this tidy up in the first place before posting). so: problem solved for me, thanks a lot!. I have no idea why it failed in the first place. I can only guess: installing `maxima' has been failing (with unrelated errors) for quite some time (last I tried was a few months ago) but very probably I did _not_ do `port clean maxima' in between. whether or not this could've let to a state of the ports tree which caused the present problem I cannot say. anyway, really thanks a lot to both of you again! joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: unison 2.32
On Sat, 14 Nov 2009 14:12:29 +0100, Jochen Küpper kuepper.joc...@googlemail.com wrote: thanks for the response. On 13.11.2009, at 16:42, joerg van den hoff wrote: my question therefore is: if you've managed to get the commandline version running would it not be possible to provide this for the time being, for instance as a different port 'unison-cli-only'? or is there another way to get hold of it? Well, in a way an unison-devel port would be appropriate, using the 2.32 sources. Maybe cli only, or with cli as a (non-default) variant. yes, such `devel' variants might be a good idea in some instances. the other major case I know of is `mutt' where many other packaging systems provide 1.5.18 (e.g. on ubuntu or (for macos) fink) while macports is stuck for years (literally) with 1.4.x since this is the last officially declared stable release. the current situation seems a little debianesque :-) Why don’t you try to implement this, starting from a copy of the current unison port and come back with specific questions if this doesn’t work out? because: a) there seeminlgy is already a maintainer of this package (erid...@macports.org) which whom I don't want to interfere. b) someone seemingly got the cli version running already (Chris Scharver css...@mac.com) a month or so ago, which would make doing it again redundant. my initial post actually was essentially asking for making this available as 'unison-devel' c) last not least: I would have to start from zero since I have nil experience with this, this would mean substantial time and I can't do that right now (urgent things to do and the migration from 10.4 on ppc to 10.6 on intel burning too much time already...) needless to reiterate that I don't take it for granted that other people put their time energy into macports and that I, at least, appreciate this honestly. regards, joerg Greetings, Jochen -- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
mercurial problem on 10.6 (seemingly identical to ticket #21283)
I've just installed macports 1.8.1 on a new macbook pro running 10.6 and installed some packages, most of them without problems (thanks to everybody involved!). but mercurial fails with exactly the same error message as reported in ticket 21283 (bottom line no module named osutils). that ticket is seemingly closed, and I don't see what I should do now. any advice? thanks joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: mercurial problem on 10.6 (seemingly identical to ticket #21283)
On Wed, 11 Nov 2009, Bryan Blackburn wrote: On Wed, Nov 11, 2009 at 11:43:16AM +0200, joerg van den hoff said: I've just installed macports 1.8.1 on a new macbook pro running 10.6 and installed some packages, most of them without problems (thanks to everybody involved!). but mercurial fails with exactly the same error message as reported in ticket 21283 (bottom line no module named osutils). that ticket is seemingly closed, and I don't see what I should do now. any advice? That ticket was closed as a duplicate of #21389: http://trac.macports.org/ticket/21389 If you look at this one you'll see it's a umask issue. If you use a more open umask when installing a port, it should be okay. You'll need to use that workaround until MacPorts 1.8.2 is released. yep, umask 022 helps :-). thanks a lot! (and apologies for not seeing that in the first place...) joerg Bryan thanks joerg ___ 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
unison 2.32 declared stable
hi there, unison 2.32 has been finally declared stable a few weeks ago. any chance to see this version soon in macports? regards, joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
streamripper install failed
hi there, I ran into the following problem. `port install streamripper' failed with: =CUT --- Fetching streamripper --- Attempting to fetch streamripper-1.64.3.tar.gz from http://mesh.dl.sourceforge.net/streamripper --- Verifying checksum(s) for streamripper --- Extracting streamripper --- Configuring streamripper Error: Target org.macports.configure returned: configure failure: shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_audio_streamripper/work/streamripper-1.64.3 ./configure --prefix=/opt/local --with-ogg=/opt/local --with-vorbis=/opt/local --with-libiconv-prefix=/opt/local --with-included-argv --with-included-libmad --with-included-tre --mandir=/opt/local/share/man returned error 1 Command output: checking whether /usr/bin/gcc-4.0 accepts -g... yes checking for /usr/bin/gcc-4.0 option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of /usr/bin/gcc-4.0... gcc3 checking for a BSD-compatible install... /usr/bin/install -c checking for ranlib... ranlib checking for inline... inline checking for main in -lm... yes checking how to run the C preprocessor... /usr/bin/cpp-4.0 checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for working alloca.h... yes checking for alloca... yes checking for pkg-config... /opt/local/bin/pkg-config checking pkg-config is at least version 0.7... yes checking for GLIB - version = 2.16.0... no *** Could not run GLIB test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means GLIB is incorrectly installed. configure: error: Glib 2.16 or greater required =CUT indeed, I had only glib 2.14 installed, but it seems that the missing newer version should be automatically installed? furthermore, I don't understand the initial 'configure failure' error... this happened with macos 10.4.11 (PB G4) port 1.700 note: after I installed glib 2.20 manually, streamripper installed apparently fine. best regards joerg -- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
streamripper install failed
hi there, I ran into the following problem. `port install streamripper' failed with: =CUT --- Fetching streamripper --- Attempting to fetch streamripper-1.64.3.tar.gz from http://mesh.dl.sourceforge.net/streamripper --- Verifying checksum(s) for streamripper --- Extracting streamripper --- Configuring streamripper Error: Target org.macports.configure returned: configure failure: shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_audio_streamripper/work/streamripper-1.64.3 ./configure --prefix=/opt/local --with-ogg=/opt/local --with-vorbis=/opt/local --with-libiconv-prefix=/opt/local --with-included-argv --with-included-libmad --with-included-tre --mandir=/opt/local/share/man returned error 1 Command output: checking whether /usr/bin/gcc-4.0 accepts -g... yes checking for /usr/bin/gcc-4.0 option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of /usr/bin/gcc-4.0... gcc3 checking for a BSD-compatible install... /usr/bin/install -c checking for ranlib... ranlib checking for inline... inline checking for main in -lm... yes checking how to run the C preprocessor... /usr/bin/cpp-4.0 checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for working alloca.h... yes checking for alloca... yes checking for pkg-config... /opt/local/bin/pkg-config checking pkg-config is at least version 0.7... yes checking for GLIB - version = 2.16.0... no *** Could not run GLIB test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means GLIB is incorrectly installed. configure: error: Glib 2.16 or greater required =CUT indeed, I had only glib 2.14 installed, but it seems that the missing newer version should be automatically installed or this is a misconeption? furthermore, I don't understand the initial 'configure failure' error... this happened with macos 10.4.11 (PB G4) port 1.700 note: after I installed glib 2.20 manually, streamripper installed apparently fine. best regards joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
[OT] groff compile problems on 10.5.7.
apologies for posting this here, since it's not (yet?) a macports problem, but maybe someone can help out here: on the 'groff' mailing list problems are reported compiling the most recent 'groff' under 10.5.7. which seem to be related to mac specific modifications of gcc. does somebody on this list know something about this which could help the groff developer fix the problem? the problem is described in this thread: http://search.gmane.org/?query=10.5.7group=gmane.comp.printing.groff.general thanks in advance joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: mercurial: hg convert cannot find `svn' python bindings
On Mon, Feb 23, 2009 at 09:19:52AM -0500, Daniel J. Luke wrote:
On Feb 22, 2009, at 10:07 AM, Joshua Root wrote:
am I missing something or is it a bug??
Looks like something needs to depend on py25-socket-ssl?
I would think that it would be mercurial that needs it, since you can do
thank's for responding.
'import svn' from python and it works enough for trac and to pass its
test suite without that being installed).
unfortenuately, I'm rather clueless where the problem actually is.
I just want to import some svn-managed stuff to mercurial.
to be sure that I'm not using it incorrectly I tried the same
on an ubuntu box: there, the identical call to `hg convert' succeeded
(pointing it to the local working copy of the svn-repo).
now, _if_ mercurial depends on py25-socket-ssl (as it seems), should this
not be a dependency of mercurial, since the `convert' extension is installed
together with mercurial?
next thing is, although, I _did_ install py25-socket-ssl, my problem did not go
away. so my question is: can someone please confirm the reported behaviour
(i.e. `hg convert -s svn {path_to_some_svn_manganged_stuff}' does give an
Subversion python bindings could not be loaded
error)?
last [not least :-)]: how can I get it running?
many thanks
joerg
--
Daniel J. Luke
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: mercurial: hg convert cannot find `svn' python bindings
On Sun, Feb 22, 2009 at 09:23:08PM -0600, Ryan Schmidt wrote: On Feb 22, 2009, at 11:30, Joshua Root wrote: Joerg van den Hoff wrote: --- Deactivating libiconv @1.12_0 Error: Deactivating libiconv 1.12_0 failed: Active version of libiconv is not 1.12_0 but 1.12_0+darwin_8. (only thing I'm not sure of is, whether the `libiconv' error is irrelevant?) It certainly shouldn't be happening... Looks like: http://trac.macports.org/ticket/17367 thanks. yes, it does. question: could this somehow explain my `hg convert' problem? I guess not, but ... joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
mercurial: hg convert cannot find `svn' python bindings
hi, I'm running `hg' version 1.1.2 under macosX 10.4.11 and port v 1.7. today I've installed `subversion-python25bindings'. next I tried a `hg convert ssh://server/path_to_repo'. (first try: not quite sure if the URL is correct or needs a double `/' after server if it's an absolute path...) now I get the error message: Subversion python bindings could not be loaded although /opt/local/lib/svn-python25 is in place. a ktrace' of the `hg convert' indicates that `hg' is very well aware of svn-python25 location but is trying in vain to locate files like: /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/_socket /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/_socket.so /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/_socketmodule.so /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/_socket.py /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/_socket.pyc /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_ssl /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_ssl.so /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_sslmodule.so /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_ssl.py /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_ssl.pyc /opt/local/lib/svn-python2.5/_ssl /opt/local/lib/svn-python2.5/_ssl.so /opt/local/lib/svn-python2.5/_sslmodule.so /opt/local/lib/svn-python2.5/_ssl.py /opt/local/lib/svn-python2.5/_ssl.pyc am I missing something or is it a bug?? thanks joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: mercurial: hg convert cannot find `svn' python bindings
On Mon, Feb 23, 2009 at 02:07:26AM +1100, Joshua Root wrote: Joerg van den Hoff wrote: hi, I'm running `hg' version 1.1.2 under macosX 10.4.11 and port v 1.7. today I've installed `subversion-python25bindings'. next I tried a `hg convert ssh://server/path_to_repo'. (first try: not quite sure if the URL is correct or needs a double `/' after server if it's an absolute path...) now I get the error message: Subversion python bindings could not be loaded although /opt/local/lib/svn-python25 is in place. a ktrace' of the `hg convert' indicates that `hg' is very well aware of svn-python25 location but is trying in vain to locate files like: /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/_socket /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/_socket.so /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/_socketmodule.so /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/_socket.py /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/_socket.pyc /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_ssl /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_ssl.so /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_sslmodule.so /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_ssl.py /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_ssl.pyc /opt/local/lib/svn-python2.5/_ssl /opt/local/lib/svn-python2.5/_ssl.so /opt/local/lib/svn-python2.5/_sslmodule.so /opt/local/lib/svn-python2.5/_ssl.py /opt/local/lib/svn-python2.5/_ssl.pyc am I missing something or is it a bug?? Looks like something needs to depend on - Josh thanks for responding so quickly. I tried as advised (installed py25-socket-ssl) more or less successful: --- Fetching py25-socket-ssl --- Verifying checksum(s) for py25-socket-ssl --- Extracting py25-socket-ssl --- Configuring py25-socket-ssl --- Building py25-socket-ssl --- Staging py25-socket-ssl into destroot --- Packaging tgz archive for py25-socket-ssl 2.5.4_0 --- Installing py25-socket-ssl @2.5.4_0 --- Activating py25-socket-ssl @2.5.4_0 --- Cleaning py25-socket-ssl --- Fetching libiconv --- Attempting to fetch libiconv-1.12.tar.gz from ftp://ftp.lip6.fr/pub/gnu/libiconv --- Verifying checksum(s) for libiconv --- Extracting libiconv --- Applying patches to libiconv --- Configuring libiconv --- Building libiconv --- Staging libiconv into destroot --- Packaging tgz archive for libiconv 1.12_2 --- Deactivating libiconv @1.12_0 Error: Deactivating libiconv 1.12_0 failed: Active version of libiconv is not 1.12_0 but 1.12_0+darwin_8. --- Fetching gettext --- Attempting to fetch gettext-0.17.tar.gz from http://mirrors.kernel.org/gnu/gettext --- Verifying checksum(s) for gettext --- Extracting gettext --- Applying patches to gettext --- Configuring gettext --- Building gettext --- Staging gettext into destroot --- Packaging tgz archive for gettext 0.17_4 --- Deactivating gettext @0.17_3 --- Installing gettext @0.17_4 --- Activating gettext @0.17_4 --- Cleaning gettext (only thing I'm not sure of is, whether the `libiconv' error is irrelevant?) anyway, I now have a _ssl.so in /opt/local/lib/python2.5/site-packages/_ssl.so but `hg convert ...' (according to ktrace) now seemlingly looks only in 25045 Python NAMI /opt/local/bin/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-darwin/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_ssl.so for the _ssl.so file... (strangely, `hg' no longer looks, e.g., in /opt/local/lib/svn-python2.5/_ssl.so as in my first `ktrace' run!?) so I'm still getting the Subversion python bindings could not be loaded message. any more ideas? am I doing something stupid wrong? e.g., I'm not at all acquainted with phyton, so must/can I define/modify the python library path? greetings, joerg
Re: mercurial: hg convert cannot find `svn' python bindings
On Mon, Feb 23, 2009 at 04:30:08AM +1100, Joshua Root wrote: Joerg van den Hoff wrote: --- Deactivating libiconv @1.12_0 Error: Deactivating libiconv 1.12_0 failed: Active version of libiconv is not 1.12_0 but 1.12_0+darwin_8. (only thing I'm not sure of is, whether the `libiconv' error is irrelevant?) It certainly shouldn't be happening... anyway, I now have a _ssl.so in /opt/local/lib/python2.5/site-packages/_ssl.so but `hg convert ...' (according to ktrace) now seemlingly looks only in 25045 Python NAMI /opt/local/bin/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-darwin/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_ssl.so 25045 Python NAMI /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_ssl.so for the _ssl.so file... (strangely, `hg' no longer looks, e.g., in /opt/local/lib/svn-python2.5/_ssl.so as in my first `ktrace' run!?) There is a symlink involved: % ls -ld /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 lrwxr-xr-x 1 root admin 24 7 Jan 19:35 /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 - /opt/local/lib/python2.5 So probably it stops after /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/_ssl.so this time because it finds that file. sorry, I did'nt check this. you are right, I looked into the ktrace output again: it finds the file under this name. I don't know why the bindings can't be loaded, though. let alone me... maybe somebody else knows what's up. anyway thanks a lot for narrowing it down a bit. joerg - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
bug in asciidoc port?
hi there, I recently installed the `asciidoc` port (MacOS 10.4.11) and I noted that the first line in the python source of `asciidoc` reads: #!/usr/bin/env python which finds the system's python binary in /usr/bin. at least for me this is version 2.3.5 but, `asciidoc' needs the macports provided python2.5. so the first line should read #!/usr/bin/env python2.5 or probably even better specify directly the path to the correct python executable. I presume... regards, joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
maxima installation failed
dear all, my attempt to install `maxima' failed with =CUT= sudo port install maxima --- Building recode --- Staging recode into destroot --- Packaging tgz archive for recode 3.6_3 --- Installing recode @3.6_3 --- Activating recode @3.6_3 --- Cleaning recode --- Fetching sbcl --- Attempting to fetch sbcl-1.0.24-source.tar.bz2 from http://dfn.dl.sourceforge.net/sbcl --- Attempting to fetch sbcl-1.0.22-powerpc-darwin-binary.tar.bz2 from http://dfn.dl.sourceforge.net/sbcl --- Verifying checksum(s) for sbcl --- Extracting sbcl --- Applying patches to sbcl --- Configuring sbcl --- Building sbcl Error: Target org.macports.build returned: shell command unset LD_PREBIND unset LD_PREBIND_ALLOW_OVERLAP sh make.sh /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.22-powerpc-darwin/src/runtime/sbcl --core /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.22-powerpc-darwin/output/sbcl.core --disable-debugger --sysinit /dev/null --userinit /dev/null returned error 1 Command output: //starting build: Mon Jan 19 12:42:39 CET 2009 //SBCL_XC_HOST=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.22-powerpc-darwin/src/runtime/sbcl --core /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.22-powerpc-darwin/output/sbcl.core --disable-debugger --sysinit /dev/null --userinit /dev/null //entering make-config.sh //ensuring the existence of output/ directory //initializing /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.24/local-target-features.lisp-expr //guessing default target CPU architecture from host architecture //setting up CPU-architecture-dependent information sbcl_arch=ppc //setting up symlink src/compiler/target //setting up symlink src/assembly/target //setting up symlink src/compiler/assembly //setting up OS-dependent information //finishing /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_sbcl/work/sbcl-1.0.24/local-target-features.lisp-expr /in canonicalize-whitespace-1 /$*=./customize-target-features.lisp ./local-target-features.lisp-expr ./tests/test-status.lisp-expr ./contrib/sb-bsd-sockets/foo.c ./contrib/sb-posix/foo.c ./src/runtime/runtime.c ./src/runtime/target-arch-os.h ./src/runtime/target-arch.h ./src/runtime/target-lispregs.h ./src/runtime/target-os.h /$scratchfilename=/tmp/canonicalize-whitespace-1.17069.tmp //entering make-host-1.sh //building cross-compiler, and doing first genesis make-host-1.sh: line 31: 17083 Bus error $SBCL_XC_HOST make-host-1.lisp =CUT= i.e. a bus error during `sbcl' install. this is on a PPC G5, MacOSX 10.4.11 and with `port' version 1.700 any help would be appreciated. regards, joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
py-cddb problem
hi there, not a very specific question (apologies), but anyway: until some time ago I used py-cddb without problems driven by a small wrapper script to first collect the CD information for a CD in the drive and then query the database. now, when I try this I get errors: dev = DiscID.open() File /opt/local/lib/python2.4/site-packages/DiscID.py, line 31, in open return cdrom.open() cdrom.error: (13, 'Permission denied') when I try again with `sudo' I get: File /opt/local/lib/python2.4/site-packages/DiscID.py, line 38, in disc_id (first, last) = cdrom.toc_header(device) cdrom.error: (25, 'Inappropriate ioctl for device') these errors are related to the compiled C code included in the package I believe. is this not working anymore??? the only thing I noted otherwise is, that previously the cd was /dev/disk1 and now it is /dev/disk2 (this is with 10.4.11), but that's probably irrelevant. any help? joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: t1lib: unable to infer tagged configuration (was: Re: xpdf install failed)
On Sep 11 2008 (Thu, 17:51), Ryan Schmidt wrote: On Sep 11, 2008, at 09:37, Joerg van den Hoff wrote: an attempt to install `xpdf' under 10.4.11. failed with ==CUT= --- Building t1lib with target without_doc [snip] Ok, so the failing port is t1lib, not xpdf. /opt/local/bin/glibtool --mode=compile \ /usr/bin/gcc-4.0 -c -O2 -DT1LIB_IDENT=\5.1.2\ - DGLOBAL_CONFIG_DIR=\/opt/local/share/t1lib\ -DT1LIB_NO_X11_SUPPORT -DT1_AA_TYPE16=short -DT1_AA_TYPE32=int arith.c glibtool: compile: unable to infer tagged configuration glibtool: compile: specify a tag with `--tag' make[2]: *** [arith.lo] Error 1 make[1]: *** [type1_target] Error 1 make: *** [] Error 1 ==CUT= what's making `port' unhappy? port is not unhappy; glibtool is. what does glibtool: compile: unable to infer tagged configuration mean? That's like these bugs: http://trac.macports.org/ticket/14308 http://trac.macports.org/ticket/13653 http://trac.macports.org/ticket/13648 Are your ports up to date? Do: sudo port selfupdate port outdated Any ports show up as outdated? If so, upgrade them. sudo port upgrade foo In particular, this problem showed up a lot when libtool was built *before* MacPorts started using /usr/bin/gcc-4.0 as CC (instead of just gcc or cc), and you attempted to build certain ports *after* updating MacPorts. However, this change was a long time ago so I'm surprised you're still running into it. Try the above and let us know I try to keep port itself and important packages (or those which are developing rapidly) up to date, but are otherwise content if 'outdated' packages are running just fine. I rely on ports to detect things which must be updated due to dependencies. so I naively would have thought that if, e.g. xpdf depdends on libtool and that one is to old, it should have been updated first automatically? where's my error here? what happens. If rebuilding libtool doesn't fix it, the problem may be specific to t1lib. bingo! it was the libtool problem. otherwise, I was running a current port. running sudo port upgrade libtool sudo port clean --work xpdf sudo port install xpdf was starting where the last attempt aborted and processed t1lib without any problem. xpdf finally installed just fine. your competent help is very much appreciated. all the best, joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
xpdf throws error
hello, not sure, whether its right to ask, but: I just managed to install xpdf (universial variant). It works OK but at each start gives the error Error: No paper information available - using defaults in the terminal window _although_ I have psPaperSize A4 in my .xpdfrc. using `xpdf -paper A4 file.pdf' does the same. my older xpdf (having other problems related to proper zooming) still from `fink' days did'nt do this. while the error does no visible harm (display's OK), it's still irritating to always get errors at program start. how come? joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
subversion upgrade failed
me again: I now get the supposedly solved issue with `libtool' (cf. recent mail regarding xpdf install) with a subversion upgrade: --- Building serf with target all Error: Target org.macports.build returned: shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_serf/work/serf-0.2.0 make all returned error 2 Command output: /opt/local/share/apr-1/build/libtool --silent --mode=compile /usr/bin/gcc-4.0 -O2 -g -I/opt/local/include -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -I. -I/opt/local/include/apr-1 -I/opt/local/include/apr-1 -c -o buckets/aggregate_buckets.lo buckets/aggregate_buckets.c touch buckets/aggregate_buckets.lo libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make: *** [buckets/aggregate_buckets.lo] Error 1 Error: The following dependencies failed to build: serf it seems like the same error message, only now I definitely have a upgraded `libtool'. this is with current `port' and 10.4.11. what am I missing _this_ time? joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: xpdf throws error
On Fri, Sep 12, 2008 at 04:23:34PM +, Eric Hall wrote: On Fri, Sep 12, 2008 at 12:26:16PM +0200, Joerg van den Hoff wrote: hello, not sure, whether its right to ask, but: I just managed to install xpdf (universial variant). It works OK but at each start gives the error Error: No paper information available - using defaults in the terminal window _although_ I have psPaperSize A4 in my .xpdfrc. using `xpdf -paper A4 file.pdf' does the same. my older xpdf (having other problems related to proper zooming) still from `fink' days did'nt do this. while the error does no visible harm (display's OK), it's still irritating to always get errors at program start. I've had success setting the 'PAPERSIZE' environment variable (PAPERSIZE=letter; export PAPERSIZE). -eric thanks. yes that works. but it seems the other ways should, too. especially, the resource file `.xpdfrc' would be my favorite place to set such things. does anybody know why command line and resource file don't work with this xpdf package? joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
xpdf install failed
hi, an attempt to install `xpdf' under 10.4.11. failed with ==CUT= --- Building t1lib with target without_doc for i in lib type1afm examples ; do \ (cd $i; make 'CC=/usr/bin/gcc-4.0' 'CFLAGS=-O2 -DT1LIB_IDENT=\5.1.2\ -DGLOBAL_CONFIG_DIR=\/opt/local/share/t1lib\ -DT1LIB_NO_X11_SUPPORT ' 'OPTIONS=' ) || exit 1; \ done /opt/local/bin/glibtool --mode=compile \ /usr/bin/gcc-4.0 -c -O2 -DT1LIB_IDENT=\5.1.2\ -DGLOBAL_CONFIG_DIR=\/opt/local/share/t1lib\ -DT1LIB_NO_X11_SUPPORT -DT1_AA_TYPE16=short -DT1_AA_TYPE32=int arith.c glibtool: compile: unable to infer tagged configuration glibtool: compile: specify a tag with `--tag' make[2]: *** [arith.lo] Error 1 make[1]: *** [type1_target] Error 1 make: *** [] Error 1 Error: Target org.macports.build returned: shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_t1lib/work/t1lib-5.1.2 make without_doc LIBTOOL=/opt/local/bin/glibtool returned error 2 Command output: for i in lib type1afm examples ; do \ (cd $i; make 'CC=/usr/bin/gcc-4.0' 'CFLAGS=-O2 -DT1LIB_IDENT=\5.1.2\ -DGLOBAL_CONFIG_DIR=\/opt/local/share/t1lib\ -DT1LIB_NO_X11_SUPPORT ' 'OPTIONS=' ) || exit 1; \ done /opt/local/bin/glibtool --mode=compile \ /usr/bin/gcc-4.0 -c -O2 -DT1LIB_IDENT=\5.1.2\ -DGLOBAL_CONFIG_DIR=\/opt/local/share/t1lib\ -DT1LIB_NO_X11_SUPPORT -DT1_AA_TYPE16=short -DT1_AA_TYPE32=int arith.c glibtool: compile: unable to infer tagged configuration glibtool: compile: specify a tag with `--tag' make[2]: *** [arith.lo] Error 1 make[1]: *** [type1_target] Error 1 make: *** [] Error 1 ==CUT= what's making `port' unhappy? what does glibtool: compile: unable to infer tagged configuration mean? thanks in advance, joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
obsolete mutt version
hi, I'd like to ask whether `mutt' will be brought up to date in `macports' any time soon? right now I only see version 1.4.2.3 while on the mutt home page (and in the `fink' project, too) I see 1.5.18 (which is quite new: may 2008). joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: obsolete mutt version
On Fri, Jul 25, 2008 at 02:10:10PM +0200, Erwan David wrote: Le Fri 25/07/2008, Joerg van den Hoff disait hi, I'd like to ask whether `mutt' will be brought up to date in `macports' any time soon? right now I only see version 1.4.2.3 while on the mutt home page (and in the `fink' project, too) I see 1.5.18 (which is quite new: may 2008). use the mutt-devel port if you want 1.5(by the way 1.5 is officially a development version even if completely usable) well, that was stupid, not to do `port search mutt', but only `port info mutt'... sorry for the noise. joerg -- Erwan ___ 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
availability of unison 2.27.72 (2008.05.29, stable)
hi there, I ran into some problems with the unison version currently provided at macports and was advised by unison's main author on the unison help list to try the new version (cf. subject line) which might have fixed that problem. I would like to stay with macports managing everything. so my question: is there a chance that the new version will appear soon on macports (this would be nice) or have I to install it separately? thanks, joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: strange problem with `gv' install under Leopard
On Sun, Jul 20, 2008 at 04:00:50AM -0500, Ryan Schmidt wrote:
On Jul 20, 2008, at 02:34, Ryan Schmidt wrote:
On Jul 18, 2008, at 03:46, Joerg van den Hoff wrote:
thanks for taking this seriously (it sounds stupid, I'm
sure...).
No no, it sounds like a bug, and I like getting bugs fixed, so let's
keep at it until we do!
On Jul 17, 2008, at 11:49, Joerg van den Hoff wrote:
I'm currently in the process of a complete new install of macports
on a power book g4 running leopard 10.5.3. so not much yet to mess
things up...
[snip]
port install gv
[snip]
PROBLEM: the resulting executable `gv' in /opt/local/bin is a
copy of the config file /opt/local/lib/gv/GV
question: my fault or a bug?
/opt/local/lib/gv/GV is not a config file.
It *is* the gv binary.
than the problem is already at _this_ point:
in may case,
/opt/local/lib/gv/GV is the same _text_ file as /opt/local/gv.
The makefile includes a step that deliberately copies this file to
/opt/local/bin/gv.
Upon rereading the Makefile I see I was mistaken earlier when I said
that the it copies ${prefix}/lib/gv/GV to ${prefix}/bin/gv.
Is your filesystem case-sensitive or case-insensitive? I'm guessing
the latter, which is the default on Mac OS X. I was using a case-
insensitive filesystem too in my earlier test.
Testing on a case-sensitive filesystem now, what I've found is that
after the build phase is complete, the src directory contains both
gv and GV. gv is the binary which should go in ${prefix}/bin/
gv, and GV is the configuration file which should go in ${prefix}/
lib/gv/GV. Of course a case-insensitive filesystem can only
accommodate one of these files existing at a time.
So on your computer you have the problem that ${prefix}/bin/gv is a
copy of the config file at ${prefix}/lib/gv/GV and therefore you
don't have a proper gv binary so you can't run gv.
And on my computer I have the problem that ${prefix}/lib/gv/GV is a
copy of the binary at ${prefix}/bin/gv so I don't have a proper GV
config file and I don't know what the implications of that are.
For whatever reason (processor speed, disk speed, compiler version),
it looks like the order in which things get built differs between our
machines.
Clearly the build process needs to be changed so that it does not
have case collisions like this. I filed a bug report with the
developers of gv:
https://savannah.gnu.org/bugs/index.php?23896
The developers of gv were quick in suggesting a workaround, which
I've put into the portfile. I also updated gv from 3.6.3 to 3.6.5. If
you will wait at least 30 minutes from the time of this message, then
run sudo port sync, then you should be able to install gv with
right now, I'm back to my own machine (still running Tiger, which I probably
will do until judgement day if Apple is not finally fixing fullscreen X11
support
again...). but I understand that the problem is the case issue (`GV' vs. `gv')
and not Leopard specific. so I've just installed `gv' (previously still using
the one from `fink') and it just runs fine. perfect fix!
I'll check the Leopard machine next week, but I think it's for sure that the
problem will go away there too.
sudo port install gv. And thanks so much for reporting this
the only danger lurking in the corner was the possibility that I had made
some stupid corner. it sounded just to stupid...
problem! ;-) Please let us know if anything else isn't working.
you bet :-)
and really thanks a lot for solving this issue.
joerg
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: strange problem with `gv' install under Leopard
On Thu, Jul 17, 2008 at 06:35:00PM -0500, Ryan Schmidt wrote: Hi Joerg, hi ryan, thanks for taking this seriously (it sounds stupid, I'm sure...). On Jul 17, 2008, at 11:49, Joerg van den Hoff wrote: I'm currently in the process of a complete new install of macports on a power book g4 running leopard 10.5.3. so not much yet to mess things up... up to now I (admittedly erratically) installed in this order Macports (from the corresponding .dmg) and the packages: ncftp lua gv the first two went just fine. the third (`gv') aborted in the first try due to a failed fetch: --- Attempting to fetch fontconfig-2.6.0.tar.gz from http:// fontconfig.org/release/ --- Attempting to fetch fontconfig-2.6.0.tar.gz from http:// svn.macports.org/repository/macports/distfiles/fontconfig % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total Spent Left Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 --- Attempting to fetch fontconfig-2.6.0.tar.gz from http:// svn.macports.org/repository/macports/distfiles/general/ % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total Spent Left Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 --- Attempting to fetch fontconfig-2.6.0.tar.gz from http:// svn.macports.org/repository/macports/downloads/fontconfig % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total Spent Left Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 Error: Target org.macports.fetch returned: fetch failed when later simply doing a second port install gv (after first doing `port uninstall gv; port clean --all gv') it ran through (fetching the above suceeded now) apparently without problems.. So it looks like there was a temporary problem with the fontconfig web site which resolved itself by the time you tried the second time. FYI: There was no need to attempt to uninstall or clean gv; MacPorts had not yet begun to do anything with gv as it was still concerned with fontconfig. (gv depends on ghostscript which depends on fontconfig). I'm always a bit paranoid something is left behind which comes in the way the next time (e.g. logfiles not in sync with what happened last), but I understand that the uninstall/clean was nonsense. PROBLEM: the resulting executable `gv' in /opt/local/bin is a copy of the config file /opt/local/lib/gv/GV question: my fault or a bug? /opt/local/lib/gv/GV is not a config file. It *is* the gv binary. than the problem is already at _this_ point: in may case, /opt/local/lib/gv/GV is the same _text_ file as /opt/local/gv. The makefile includes a step that deliberately copies this file to / opt/local/bin/gv. thanks, joerg PS: the complete log of the second `port install gv' comes here: I looked at the difference between your log and what I got installing gv on my Power Mac G4 with Leopard. Pretty similar except mine has this line which yours doesn't: creating GV Curious that yours does not have this line; this is the step that copies the file from /opt/local/lib/gv/GV to /opt/local/bin/gv. Are /opt/local/bin/gv and /opt/local/lib/gv/GV text files or binary files? If text, what's in them? If binary, what happens when you try to run gv? both are identical text files containing this: =CUT ! ! gv_user.ad ! User specific application defaults for gv ! Copyright (C) 1995, 1996, 1997 Johannes Plass ! Copyright (C) 2004,2005,2006,2007 José E. Marchesi ! !## gv_user_res.dat !# Application specific Resources GV.pageMedia: automatic GV.orientation: automatic GV.fallbackOrientation: portrait GV.swapLandscape: False GV.autoCenter: True GV.antialias: True GV.respectDSC: True GV.ignoreEOF: True GV.confirmPrint:True GV.reverseScrolling:False GV.scrollingEyeGuide: True GV.autoResize: True GV.maximumWidth:screen-20 GV.maximumHeight: screen-44 GV.minimumWidth:400 GV.minimumHeight: 430 GV.confirmQuit: 1 GV.watchFile: False GV.watchFileFrequency: 1000 GV.showTitle: True GV.miscMenuEntries: redisplay \n\ # update\n\ stop\n\ line\n\ toggle_current \n\ toggle_even \n\ toggle_odd \n\ unmark \n\ line
strange problem with `gv' install under Leopard
hello, I'm currently in the process of a complete new install of macports on a power book g4 running leopard 10.5.3. so not much yet to mess things up... up to now I (admittedly erratically) installed in this order Macports (from the corresponding .dmg) and the packages: ncftp lua gv the first two went just fine. the third (`gv') aborted in the first try due to a failed fetch: --- Attempting to fetch fontconfig-2.6.0.tar.gz from http://fontconfig.org/release/ --- Attempting to fetch fontconfig-2.6.0.tar.gz from http://svn.macports.org/repository/macports/distfiles/fontconfig % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 --- Attempting to fetch fontconfig-2.6.0.tar.gz from http://svn.macports.org/repository/macports/distfiles/general/ % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 --- Attempting to fetch fontconfig-2.6.0.tar.gz from http://svn.macports.org/repository/macports/downloads/fontconfig % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 Error: Target org.macports.fetch returned: fetch failed when later simply doing a second port install gv (after first doing `port uninstall gv; port clean --all gv') it ran through (fetching the above suceeded now) apparently without problems.. PROBLEM: the resulting executable `gv' in /opt/local/bin is a copy of the config file /opt/local/lib/gv/GV question: my fault or a bug? thanks, joerg PS: the complete log of the second `port install gv' comes here: ==CUT== [EMAIL PROTECTED](~/Desktop): sudo port -v install gv --- Fetching gv --- gv-3.6.3.tar.gz doesn't seem to exist in /opt/local/var/macports/distfiles/gv --- Attempting to fetch gv-3.6.3.tar.gz from http://ftp.gnu.org/gnu/gv % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 469k 100 469k0 0 321k 0 0:00:01 0:00:01 --:--:-- 393k --- Verifying checksum(s) for gv --- Checksumming gv-3.6.3.tar.gz --- Extracting gv --- Extracting gv-3.6.3.tar.gz --- Applying patches to gv --- Applying /opt/local/var/macports/sources/rsync.macports.org/release/ports/print/gv/files/patch-setenv.c.diff patching file src/setenv.c --- Configuring gv checking for a BSD-compatible install... /usr/bin/install checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no 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 ISO C89... none needed checking for style of include used by make... GNU checking dependency style of /usr/bin/gcc-4.0... none checking for ranlib... ranlib checking how to run the C preprocessor... /usr/bin/cpp-4.0 checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking for getopt_long_only... yes checking whether optreset is declared... yes checking whether getenv is declared... yes checking whether the preprocessor supports include_next... yes checking for unistd.h... (cached) yes checking for sqrt in -lm... yes checking for yywrap in -lfl... yes checking for X... libraries /usr/X11/lib, headers /usr/X11/include checking whether -R must be followed by a space... no checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for XOpenDisplay in -lX11... yes checking for main in
Re: python2.5 install failed
On Tue, Jun 17, 2008 at 12:11:16PM +0200, Rainer Müller wrote: Ryan Schmidt wrote: On Jun 16, 2008, at 5:18 AM, Joerg van den Hoff wrote: question: could'nt/should'nt `port' check the Xcode version itself and issue a complain if it's too old? Yes, that would be wonderful. I filed a request for that some time ago but it hasn't really been implemented yet: http;//trac.macports.org/ticket/12794 The source install checks the Xcode version on configure and warns if one is using an old version. I don't think the dmg installer does something like this. Checking the version on every run of port is not a good idea, especially not when we allow to choose other compilers through configure.compiler (or a new setting in macports.conf as I proposed recently). Bundling the check with the currently setting of configure.compiler could work. Maybe it would be enough to add this check to 'port selfupdate' (or a new 'port selfcheck'?). But we also have users with old MacPorts versions from time to time... that's true (happened to me, too...). but the adivice first run port selfupdate and look whether problem goes away is seen so often that most people will try this sooner or later anyway. so, I'd say a check at `port selfupdate' time would probably solve95-99%of all cases where the Xcode version problem arises. joerg Rainer ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: python2.5 install failed
On Fri, Jun 13, 2008 at 02:52:25PM -0600, Bryan Blackburn wrote: On Jun 13, 2008, at 5:11 AM, Joerg van den Hoff wrote: hi, under 10.4.11 I did a `port upgrade mercurial'. ... /usr/bin/libtool -o libpython2.5.dylib -dynamic \ -all_load libpython2.5.a -single_module \ -install_name /opt/local/lib/libpython2.5.dylib \ -compatibility_version 2.5 \ -current_version 2.5 -lSystem -lSystemStubs -L/opt/local/lib ld64 failed: in libpython2.5.a(getbuildinfo.o), not a valid ppc64 mach-o file /usr/bin/libtool: internal link edit command failed make: *** [libpython2.5.dylib] Error 1 Check your Xcode version, and see: http://trac.macports.org/ticket/15216 Bryan indeed. had'nt checked Xcode for quite some time. thank's a lot! question: could'nt/should'nt `port' check the Xcode version itself and issue a complain if it's too old? joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
python2.5 install failed
hi, under 10.4.11 I did a `port upgrade mercurial'. which depends on python2.5 and `port' tries to install this (only python2.4 installed up to now). now I see the following: ==CUT --- Fetching python25 --- Attempting to fetch Python-2.5.2.tar.bz2 from http://www.python.org//ftp/python/2.5.2/ --- Verifying checksum(s) for python25 --- Extracting python25 --- Applying patches to python25 --- Configuring python25 --- Building python25 with target all Error: Target org.macports.build returned: shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python25/work/Python-2.5.2 make all returned error 2 ==CUT after this point compile nevertheless seemingly runs fine till the final `ranlib' run: ==CUT ranlib libpython2.5.a /usr/bin/libtool -o libpython2.5.dylib -dynamic \ -all_load libpython2.5.a -single_module \ -install_name /opt/local/lib/libpython2.5.dylib \ -compatibility_version 2.5 \ -current_version 2.5 -lSystem -lSystemStubs -L/opt/local/lib ld64 failed: in libpython2.5.a(getbuildinfo.o), not a valid ppc64 mach-o file /usr/bin/libtool: internal link edit command failed make: *** [libpython2.5.dylib] Error 1 ==CUT then some other stuff (gperf, gettext are fetched/upgraded and finally I see: ==CUT Error: The following dependencies failed to build: python25 --- Fetching bzip2 --- Attempting to fetch bzip2-1.0.5.tar.gz from http://www.bzip.org/1.0.5/ --- Verifying checksum(s) for bzip2 --- Extracting bzip2 --- Applying patches to bzip2 --- Configuring bzip2 --- Building bzip2 with target all --- Staging bzip2 into destroot --- Packaging tgz archive for bzip2 1.0.5_1 --- Deactivating bzip2 1.0.4_1 --- Installing bzip2 1.0.5_1 --- Activating bzip2 1.0.5_1 --- Cleaning bzip2 --- Building python25 with target all Error: Target org.macports.build returned: shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_python25/work/Python-2.5.2 make all returned error 2 Command output: /usr/bin/libtool -o libpython2.5.dylib -dynamic \ -all_load libpython2.5.a -single_module \ -install_name /opt/local/lib/libpython2.5.dylib \ -compatibility_version 2.5 \ -current_version 2.5 -lSystem -lSystemStubs -L/opt/local/lib ld64 failed: in libpython2.5.a(getbuildinfo.o), not a valid ppc64 mach-o file /usr/bin/libtool: internal link edit command failed make: *** [libpython2.5.dylib] Error 1 Error: The following dependencies failed to build: py25-bz2 python25 py25-hashlib py25-zlib Error: Unable to upgrade port: 1 ==CUT `port' is current and up-to-date. where's my fault? and if the python2.5 problem is not easily solved: can I enforce upgrade of `mercurial' (assuming it will run just fine with python2.4)? joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: compilation of `hydra' failed
On Wed, Jun 04, 2008 at 03:08:38PM -0500, Ryan Schmidt wrote: On Jun 4, 2008, at 10:06, Joerg van den Hoff wrote: I'm back to field one: due to your above news, I just did: port clean --all libssh port uninstall hydra #this was the old (working) version without ssh support port clean --all hydra port selfupdate port sync port install hydra which crashed again: CUT== --- Building hydra with target all [snip] /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-ssh2.c -DLIBOPENSSL - DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include hydra-ssh2.c:10:2: warning: #warning If compilation of hydra-ssh2 fails, you are not using v0.11. Download from http://www. 0xbadc0de.be/ hydra-ssh2.c:12:27: error: libssh/libssh.h: No such file or directory [snip] Did the port libssh01 get installed? It would provide libssh/libssh.h in /opt/local/include/libssh01. I checked this: no libssh01 in this location. but then I repeated exactly the sequence of commands (history excerpt...): 2 10:32 sudo port -v clean --all libssh 3 10:32 sudo port uninstall hydra 4 10:32 sudo port clean --all hydra 5 10:32 sudo port -v sync 6 10:34 sudo port -v install hydra and now hydra installed just so!? so, sorry for the noise (though I swear the usual oath that I used exactly the same commands yesterday...) and many thanks again for fixing the ssh issue. joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: compilation of `hydra' failed
On Thu, Jun 05, 2008 at 04:35:19PM +0200, Joerg van den Hoff wrote: On Thu, Jun 05, 2008 at 06:52:57AM -0500, Ryan Schmidt wrote: On Jun 5, 2008, at 03:41, Joerg van den Hoff wrote: On Wed, Jun 04, 2008 at 03:08:38PM -0500, Ryan Schmidt wrote: On Jun 4, 2008, at 10:06, Joerg van den Hoff wrote: I'm back to field one: due to your above news, I just did: port clean --all libssh port uninstall hydra #this was the old (working) version without ssh support port clean --all hydra port selfupdate port sync port install hydra which crashed again: CUT= = --- Building hydra with target all [snip] /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-ssh2.c -DLIBOPENSSL - DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include hydra-ssh2.c:10:2: warning: #warning If compilation of hydra-ssh2 fails, you are not using v0.11. Download from http://www. 0xbadc0de.be/ hydra-ssh2.c:12:27: error: libssh/libssh.h: No such file or directory [snip] Did the port libssh01 get installed? It would provide libssh/libssh.h in /opt/local/include/libssh01. I checked this: no libssh01 in this location. but then I repeated exactly the sequence of commands (history excerpt...): 2 10:32 sudo port -v clean --all libssh 3 10:32 sudo port uninstall hydra 4 10:32 sudo port clean --all hydra 5 10:32 sudo port -v sync 6 10:34 sudo port -v install hydra and now hydra installed just so!? so, sorry for the noise (though I swear the usual oath that I used exactly the same commands yesterday...) and many thanks again for fixing the ssh issue. I take it libssh01 is installed now? right. I think the first time you tried to install must have been before libssh01 got added to the PortIndex (which is only regenerated every 12 hours), so when hydra asked for it as a dependency, MacPorts didn't know where to find it, skipped it, and proceeded to try to install hydra anyway, which failed. Now that libssh01 is in the index it can be installed properly. me again. `hydra' is now installed and running, sort of: when using the `ssh2' protocol hydra apparently runs as it should but terminates (apparently _not_ prematurely, but I'm not sure) with something like: hydra(2814) malloc: *** set a breakpoint in szone_error to debug hydra(2814) malloc: *** error for object 0x401920: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug hydra(2814) malloc: *** set a breakpoint in szone_error to debug hydra(2814) malloc: *** error for object 0x400d70: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug hydra(2814) malloc: *** set a breakpoint in szone_error to debug hydra(2814) malloc: *** error for object 0x400d70: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug hydra(2814) malloc: *** set a breakpoint in szone_error to debug hydra(2814) malloc: *** error for object 0x400d70: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug hydra(2814) malloc: *** set a breakpoint in szone_error to debug hydra(2814) malloc: *** error for object 0x400d70: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug hydra(2814) malloc: *** set a breakpoint in szone_error to debug Hydra (http://www.thc.org) finished at 2008-06-05 18:02:29 has somebody an idea what to make of this? is this specific for the mac port or is this seen otherwise, too? and: does it harm? joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: compilation of `hydra' failed
On Tue, Jun 03, 2008 at 02:53:15PM -0700, Matrix Mole wrote: (sorry forgot to Reply-to-all on the original message to include the mailing list) On Tue, Jun 3, 2008 at 12:24 PM, Joerg van den Hoff [EMAIL PROTECTED] wrote: Also, be sure to run a port sync to get the most recent version of the port files, I believe the old maintainer removed the dependency on libssh for hydra until the issue could be resolved. I did. `variant ssh' is indeed commented out in the portfile. nevertheless I get the same error complaining about libssh version mismatch. thanks again (to ryan, too). got it installed now. You may have to uninstall libssh first, if libssh is installed, it will try to pull the libraries into a hydra build. Once you have libssh removed, then hydra should build without ssh support. I'll wait and observe the status of the ticket. Unfortunately, I don't think much work is going to get done on that ticket since the maintainer of the port has stepped down. I that would be bad. really no hope?? contemplated picking it up myself, but I don't have any time (nor programming experience) to do so. regards, joerg Matrix Mole ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: compilation of `hydra' failed
On Wed, Jun 04, 2008 at 05:14:53AM -0500, Ryan Schmidt wrote: On Jun 4, 2008, at 04:24, Joerg van den Hoff wrote: On Tue, Jun 03, 2008 at 02:53:15PM -0700, Matrix Mole wrote: (sorry forgot to Reply-to-all on the original message to include the mailing list) On Tue, Jun 3, 2008 at 12:24 PM, Joerg van den Hoff [EMAIL PROTECTED] wrote: Also, be sure to run a port sync to get the most recent version of the port files, I believe the old maintainer removed the dependency on libssh for hydra until the issue could be resolved. I did. `variant ssh' is indeed commented out in the portfile. nevertheless I get the same error complaining about libssh version mismatch. thanks again (to ryan, too). got it installed now. You may have to uninstall libssh first, if libssh is installed, it will try to pull the libraries into a hydra build. Once you have libssh removed, then hydra should build without ssh support. I'll wait and observe the status of the ticket. Unfortunately, I don't think much work is going to get done on that ticket since the maintainer of the port has stepped down. I that would be bad. really no hope?? Ticket is resolved. :) hey, great! thanks a lot. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: compilation of `hydra' failed
On Wed, Jun 04, 2008 at 05:14:53AM -0500, Ryan Schmidt wrote: On Jun 4, 2008, at 04:24, Joerg van den Hoff wrote: On Tue, Jun 03, 2008 at 02:53:15PM -0700, Matrix Mole wrote: (sorry forgot to Reply-to-all on the original message to include the mailing list) On Tue, Jun 3, 2008 at 12:24 PM, Joerg van den Hoff [EMAIL PROTECTED] wrote: Also, be sure to run a port sync to get the most recent version of the port files, I believe the old maintainer removed the dependency on libssh for hydra until the issue could be resolved. I did. `variant ssh' is indeed commented out in the portfile. nevertheless I get the same error complaining about libssh version mismatch. thanks again (to ryan, too). got it installed now. You may have to uninstall libssh first, if libssh is installed, it will try to pull the libraries into a hydra build. Once you have libssh removed, then hydra should build without ssh support. I'll wait and observe the status of the ticket. Unfortunately, I don't think much work is going to get done on that ticket since the maintainer of the port has stepped down. I that would be bad. really no hope?? Ticket is resolved. :) ryan, I'm back to field one: due to your above news, I just did: port clean --all libssh port uninstall hydra #this was the old (working) version without ssh support port clean --all hydra port selfupdate port sync port install hydra which crashed again: CUT== --- Building hydra with target all /usr/bin/gcc-4.0 -I. -Wall -O2 -o pw-inspector pw-inspector.c /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-vnc.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-pcnfs.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-rexec.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-nntp.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-socks5.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-telnet.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-cisco.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-http.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-ftp.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-imap.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-pop3.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-smb.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-icq.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-cisco-enable.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-ldap.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-mysql.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-http-proxy.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-smbnt.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-mssql.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-snmp.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-cvs.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-smtpauth.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-sapr3.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-ssh2.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include/libssh01 -I/opt/local/include hydra-ssh2.c:10:2: warning: #warning If compilation of hydra-ssh2 fails, you are not using v0.11. Download from http://www.0xbadc0de.be/; hydra-ssh2.c:12:27: error: libssh/libssh.h: No such file or directory hydra-ssh2.c: In function 'start_ssh2': hydra-ssh2.c:24: error: 'SSH_SESSION' undeclared (first use in this function) hydra-ssh2.c:24: error: (Each undeclared identifier is reported only once hydra-ssh2.c:24: error: for each function
compilation of `hydra' failed
hi, wanted to check strengths of my password(s) against brute force attacks with `hydra' (hope this is the tool to do it?) but sudo port install hydra yielded #CUT --- Fetching libssh --- Attempting to fetch libssh-0.2.tgz from http://www.0xbadc0de.be/libssh --- Verifying checksum(s) for libssh --- Extracting libssh --- Configuring libssh --- Building libssh with target all --- Staging libssh into destroot --- Packaging tgz archive for libssh 0.2_0 --- Installing libssh 0.2_0 --- Activating libssh 0.2_0 --- Cleaning libssh --- Fetching hydra --- Attempting to fetch hydra-5.4-src.tar.gz from http://freeworld.thc.org/releases --- Verifying checksum(s) for hydra --- Extracting hydra --- Configuring hydra --- Building hydra with target all Error: Target org.macports.build returned: shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_security_hydra/work/hydra-5.4-src make all XLIBPATHS=-L/opt/local/lib CC=/usr/bin/gcc-4.0 returned error 2 Command output: /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-pop3.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-smb.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-icq.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-cisco-enable.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-ldap.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-mysql.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-http-proxy.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-smbnt.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-mssql.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-snmp.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-cvs.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-smtpauth.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-sapr3.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include /usr/bin/gcc-4.0 -I. -Wall -O2 -c hydra-ssh2.c -DLIBOPENSSL -DLIBSSH -I/opt/local/include -I/opt/local/include hydra-ssh2.c:10:2: warning: #warning If compilation of hydra-ssh2 fails, you are not using v0.11. Download from http://www.0xbadc0de.be/; hydra-ssh2.c: In function 'start_ssh2': hydra-ssh2.c:34: warning: implicit declaration of function 'options_new' hydra-ssh2.c:34: warning: assignment makes pointer from integer without a cast hydra-ssh2.c:44: warning: implicit declaration of function 'options_set_wanted_method' hydra-ssh2.c:44: error: 'KEX_COMP_C_S' undeclared (first use in this function) hydra-ssh2.c:44: error: (Each undeclared identifier is reported only once hydra-ssh2.c:44: error: for each function it appears in.) hydra-ssh2.c:45: error: 'KEX_COMP_S_C' undeclared (first use in this function) hydra-ssh2.c:46: warning: implicit declaration of function 'options_set_port' hydra-ssh2.c:47: warning: implicit declaration of function 'options_set_host' hydra-ssh2.c:48: warning: implicit declaration of function 'options_set_username' hydra-ssh2.c:50: warning: passing argument 1 of 'ssh_connect' from incompatible pointer type hydra-ssh2.c:50: warning: assignment makes pointer from integer without a cast hydra-ssh2.c:82: warning: implicit declaration of function 'ssh_error_code' make: *** [hydra-ssh2.o] Error 1 #CUT the problem seems that libssh-0.2.tgz is fetched from www.0xbadc0de.be but `hydra' expects v0.11??? this is with 10.4.11 and PPC (and current `macports'). any hope of a fix (no maintainer, apparently...)? regards joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Octave 3.0.1 plotting is very slow
On Tue, Jun 03, 2008 at 11:10:52AM +0200, Alakazam wrote: - What machine are you running octave on ? PPC Powerbook 1.5 GHz 2 GB Which explains why plotting takes ~20s for you, and ~10s for me. - What version of Mac OS X are you running ? 10.5.11 Is that 10.4.11 or 10.5.3 ? Anyway, this obviously does not change anything, since we obtain similar results on the performance tests. Here are some more test results from running this program: The setup is this, run only once per session: x = [1:10]; y = cos(x); The timed part is this: t = time(); plot(x, y); time() - t which reports an answer (call it t1) some time before the plot appears (and at which time the prompt returns)--the latter time I time on my watch call t2. In all cases the plot was run at least once before timing it. This is the same test I was running, so no problem here. Here are some results for t1 and t2 for various versions which are: 2.1.71 downloaded last year from http://hpc.sourceforge.net 3.0.1 downloaded today from http://hpc.sourceforge.net 3.0.1 installed by Macports a few days ago Octave versionOutput device t1t2 == Macports 3.0.1Aquaterm0.64575 22 Macports 3.0.1X11 0.41969 22 HPC 2.1.71 Aquaterm2.70574 HPC 2.1.71 X11 N/A; uses Aquaterm HPC 3.0.1Aquaterm0.62115 22 HPC 3.0.1X11 N/A; defaults to Terminal.app FWIW, Activity Monitor reports high CPU usage from gnuplot while waiting for the plots to appear. So it would seem the problem may not be with the octave compilation options, but indeed with the octave-gnuplot interaction. Do any macports users still have old octave2.9s (or, less likely, octave2.1s) installed (via macports) ? Would you be willing to run the quick aforementioned tests to check precisely when the problem may have appeared ? hi, if it helps: with GNU Octave, version 2.1.71 (powerpc-apple-darwin). and G N U P L O T Version 4.0 patchlevel 0 I get t = 1.7 sec (with a 2 GHz G5 under X11) regards, joerg Reading http://www.gnu.org/software/octave/NEWS-3.html I see that octave 3 (and 2.9) have introduced may changes to the graphics backend, in particular to the way data is output to gnuplot : Octave now sends data over the same pipe that is used to send commands to gnuplot. While this avoids the problem of cluttering / tmp with data files, it is no longer possible to use the mouse to zoom in on plots. This is a limitation of gnuplot, which is unable to zoom when the data it plots is not stored in a file. Some work has been done to fix this problem in newer versions of gnuplot ( 4.2.2). See for example, this thread on the gnuplot development list. I think it would be best to take this issue to the octave team, and see if they can reproduce the problem (on other platforms even ?) or know where it might come from. You may also want to check the different gnuplot versions used by these octave versions ; maybe changes on that end might also influence the plotting performance. Regards, -- Alakazam [EMAIL PROTECTED] ___ macports-users mailing list macports-users@lists.macosforge.org ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: xv and png
On Fri, Apr 04, 2008 at 08:02:43PM -0500, Ryan Schmidt wrote: On Apr 4, 2008, at 19:39, Rainer Müller wrote: Joerg van den Hoff wrote: standard `xv' does not have png support although patches seem to exist. The standard xv release does not support PNG images according to the homepage. Even if there are any patches available somewhere, they are not applied at the moment. There is an official patch on the downloads page, Patch to read/ write PNG files [1]. The statement in the description is, This version has been patched to support the PNG PhotoCD image types. But it seems that it is just using the standard source distribution without additional patches. `port info xv' lists `libpng' as one of the dependencies and PNG is explicitely mentioned under the supported file formats. therefore I installed it hoping for PNG support, but without success: no display of png images. Strange enough, it is really linked against libpng. But it can't display PNG images for me neither. $ otool -L /opt/local/bin/xv /opt/local/bin/xv: [...] /opt/local/lib/libjpeg.62.dylib (compatibility version 63.0.0, current version 63.0.0) /opt/local/lib/libtiff.3.dylib (compatibility version 12.0.0, current version 12.2.0) /usr/X11/lib/libpng.3.dylib (compatibility version 4.0.0, current version 4.0.0) [...] Looks like it's also linked against the system's libpng, not MacPorts' libpng, which is unfortunate and should be fixed. is mr. nomaintainer informed? :-) and it would be really great, if the PNG patch could really be included: missing PNG support is the one big shortcoming of `xv'. as `xv' seems otherwise frozen since the mid nineties applying the patch seems a one time action. and for standard tasks `xv' still seems really superior to `ImageMagick' (standard operations such as edge detection run faster by a signifcant factor (5-10) and yield really much better results). joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
xv and png
dear all, standard `xv' does not have png support although patches seem to exist. `port info xv' lists `libpng' as one of the dependencies and PNG is explicitely mentioned under the supported file formats. therefore I installed it hoping for PNG support, but without success: no display of png images. any ideas? thanks joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: libiconv problems after urxvt upgrade
On Fri, Mar 14, 2008 at 08:53:37PM -0500, Ryan Schmidt wrote: On Mar 14, 2008, at 07:38, Joerg van den Hoff wrote: ryan, thanks a lot for bothering. I really appreciate this. On Fri, Mar 14, 2008 at 06:39:20AM -0500, Ryan Schmidt wrote: On Mar 13, 2008, at 06:11, Joerg van den Hoff wrote: during upgrade from urxvt8.7 to the current version I got the error message ===CUT== == Portfile changed since last build; discarding previous state. --- Fetching libiconv --- Verifying checksum(s) for libiconv --- Extracting libiconv --- Applying patches to libiconv --- Configuring libiconv --- Building libiconv with target all --- Staging libiconv into destroot --- Packaging tgz archive for libiconv 1.12_0+darwin_8 --- Deactivating libiconv 1.11_0 Error: Deactivating libiconv 1.11_0 failed: Active version of libiconv is not 1.11_0 but 1.11_0+darwin_8. ===CUT== == Peculiar... after which install proceded (apparently successful). I don't know why MacPorts proceeds when it encounters an error activating a port. This only leads to further errors down the road, as you've seen: deserves this an official bug report (I was hoping a bit the ml might suffice)? All bugs deserve a bug report in our issue tracker. :) I'm just not sure how to report this. I've seen it before, but I forget how it happened to be exactly. And you don't know how it happened to you either. Without a reproduction recipe, it'll be hard to fix. But it should still be filed. I tried to search just now (summary contains activat, component = base) and didn't find it. trying to start `urxvt' now throws the error: ===CUT== == dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib Referenced from: /opt/local/lib/libXft.2.dylib Reason: Incompatible library version: libXft.2.dylib requires version 7.0.0 or later, but libiconv.2.dylib provides version 5.0.0 Trace/BPT trap ===CUT== == No libiconv is active, because of the earlier error, so ports that require libiconv now explode. trying a `sudo port deactivate [EMAIL PROTECTED]' yielded ===CUT== == Error: port deactivate failed: Registry error: libiconv not registered as installed active. ===CUT== == which seems inconsistent with the error message during urxvt install. Agreed. That seems inconsistent. Not sure how you got into this state. neither am I. I'm definitely _not_ tinkering with the system. rather I try to upgrade by and then relevant packages and go on with my work. after a `sudo port activate [EMAIL PROTECTED]' now everything seems to work, Great! but the above messages seems to hint at some grade of corruption of the internal state of port. is this the case? can I sanitize/check it somehow without purging everything? What does port installed libiconv show now? this: The following ports are currently installed: libiconv @1.10_1+darwin_8 libiconv @1.11_0+darwin_8 libiconv @1.12_0+darwin_8 (active) libiconv @1.9.2_1 Looks ok to me. You can force-uninstall those older inactive versions if you want since nothing is using them. I also notice that many packages appear both with `port list active' _and_ `port list inactive'. how can this be? port list does not do what you think it does. port list does the following: for each port, display the current version (not the installed version). You probably would rather use port installed active and port installed inactive. thanks for this clarification. I read the manpage again: this behaviour is far from obvious from the manpage, since there installed and active are both listed as pseudo-portnames which should imply that 'port list active' should do what I expected. No... because port list does not do what you expected. Read the description of port list in the manpage: list If no argument is given, display a list of the the latest version of all available ports. If portname(s) are given as arguments, display a list of the latest version of each port. (I just noticed the the and fixed it in r35030.) So port list active lists the latest version of each active port, *not* the installed version of each active port. For example, if you deactivate libiconv @1.12_0+darwin_8 and then activate libiconv @1.11_0+darwin_8, port list active (or port list libiconv) will still show libiconv @1.12 textproc/ libiconv because 1.12 is the latest version of that port. also port
Re: libiconv problems after urxvt upgrade
ryan, thanks a lot for bothering. I really appreciate this. On Fri, Mar 14, 2008 at 06:39:20AM -0500, Ryan Schmidt wrote: On Mar 13, 2008, at 06:11, Joerg van den Hoff wrote: during upgrade from urxvt8.7 to the current version I got the error message ===CUT Portfile changed since last build; discarding previous state. --- Fetching libiconv --- Verifying checksum(s) for libiconv --- Extracting libiconv --- Applying patches to libiconv --- Configuring libiconv --- Building libiconv with target all --- Staging libiconv into destroot --- Packaging tgz archive for libiconv 1.12_0+darwin_8 --- Deactivating libiconv 1.11_0 Error: Deactivating libiconv 1.11_0 failed: Active version of libiconv is not 1.11_0 but 1.11_0+darwin_8. ===CUT Peculiar... after which install proceded (apparently successful). I don't know why MacPorts proceeds when it encounters an error activating a port. This only leads to further errors down the road, as you've seen: deserves this an official bug report (I was hoping a bit the ml might suffice)? trying to start `urxvt' now throws the error: ===CUT dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib Referenced from: /opt/local/lib/libXft.2.dylib Reason: Incompatible library version: libXft.2.dylib requires version 7.0.0 or later, but libiconv.2.dylib provides version 5.0.0 Trace/BPT trap ===CUT No libiconv is active, because of the earlier error, so ports that require libiconv now explode. trying a `sudo port deactivate [EMAIL PROTECTED]' yielded ===CUT Error: port deactivate failed: Registry error: libiconv not registered as installed active. ===CUT which seems inconsistent with the error message during urxvt install. Agreed. That seems inconsistent. Not sure how you got into this state. neither am I. I'm definitely _not_ tinkering with the system. rather I try to upgrade by and then relevant packages and go on with my work. after a `sudo port activate [EMAIL PROTECTED]' now everything seems to work, Great! but the above messages seems to hint at some grade of corruption of the internal state of port. is this the case? can I sanitize/check it somehow without purging everything? What does port installed libiconv show now? this: The following ports are currently installed: libiconv @1.10_1+darwin_8 libiconv @1.11_0+darwin_8 libiconv @1.12_0+darwin_8 (active) libiconv @1.9.2_1 I also notice that many packages appear both with `port list active' _and_ `port list inactive'. how can this be? port list does not do what you think it does. port list does the following: for each port, display the current version (not the installed version). You probably would rather use port installed active and port installed inactive. thanks for this clarification. I read the manpage again: this behaviour is far from obvious from the manpage, since there installed and active are both listed as pseudo-portnames which should imply that 'port list active' should do what I expected. also port installed (or port installed active) works while port active does not. should not the manpage be modified to make this point clear? and a last question: the active ports are the only one in use Yes. or are inactive ones (especially libs) secretly used by other ports? No, inactive ports are not used at all. I noted that a tentative `sudo port uninstall [EMAIL PROTECTED]' showed me lots of ports depending on it which would need prior uninstall. The message shown by MacPorts is misleading. The message says Unable to uninstall libiconv 1.11_0+darwin_8, the following ports depend on it but what the message should say is Unable to uninstall libiconv, the following ports depend on it (in other words it should not list the version or variants). Since you already have a newer version of libiconv installed, it's perfectly fine to remove the older version. MacPorts just doesn't know any better. Educate it by using -f when uninstalling ports in such situations: ah. maybe I manage to remember this in the future. sudo port -f uninstall [EMAIL PROTECTED] I understand that different versions of libs are needed at the same time That's not how MacPorts works. Only one version of a library can be used at a time. If multiple versions of a library are needed at the same time, multiple separate ports must be created. See for example apr and apr0, db41 thru db46, and many other examples
urxvt: installing files outside common directory structure
during upgrade of `rxvt-unicode' I've got the warning rxvt-unicode requests to install files outside the common directory structure! simple question: and where might that be?? I need to know in order to get the mirroring of the ports tree from desktop to labtop machine via `rsync' right (much faster than installing everything twice...). I propose to modify the above warning and explicitly state (IN CAPS) what files are installed where outside `/opt/local'. thanks joerg ps: don't laught at the Cc address ... ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
libiconv problems after urxvt upgrade
during upgrade from urxvt8.7 to the current version I got the error message ===CUT Portfile changed since last build; discarding previous state. --- Fetching libiconv --- Verifying checksum(s) for libiconv --- Extracting libiconv --- Applying patches to libiconv --- Configuring libiconv --- Building libiconv with target all --- Staging libiconv into destroot --- Packaging tgz archive for libiconv 1.12_0+darwin_8 --- Deactivating libiconv 1.11_0 Error: Deactivating libiconv 1.11_0 failed: Active version of libiconv is not 1.11_0 but 1.11_0+darwin_8. ===CUT after which install proceded (apparently successful). trying to start `urxvt' now throws the error: ===CUT dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib Referenced from: /opt/local/lib/libXft.2.dylib Reason: Incompatible library version: libXft.2.dylib requires version 7.0.0 or later, but libiconv.2.dylib provides version 5.0.0 Trace/BPT trap ===CUT trying a `sudo port deactivate [EMAIL PROTECTED]' yielded ===CUT Error: port deactivate failed: Registry error: libiconv not registered as installed active. ===CUT which seems inconsistent with the error message during urxvt install. after a `sudo port activate [EMAIL PROTECTED]' now everything seems to work, but the above messages seems to hint at some grade of corruption of the internal state of port. is this the case? can I sanitize/check it somehow without purging everything? I also notice that many packages appear both with `port list active' _and_ `port list inactive'. how can this be? and a last question: the active ports are the only one in use or are inactive ones (especially libs) secretly used by other ports? I noted that a tentative `sudo port uninstall [EMAIL PROTECTED]' showed me lots of ports depending on it which would need prior uninstall. I understand that different versions of libs are needed at the same time but why, then, is one declared active the others inactive? so in short what's the difference between active and inactive, especially for libs? joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: libiconv problems after urxvt upgrade (II)
On Thu, Mar 13, 2008 at 12:11:27PM +0100, Joerg van den Hoff wrote: during upgrade from urxvt8.7 to the current version I got the error message ===CUT Portfile changed since last build; discarding previous state. --- Fetching libiconv --- Verifying checksum(s) for libiconv --- Extracting libiconv --- Applying patches to libiconv --- Configuring libiconv --- Building libiconv with target all --- Staging libiconv into destroot --- Packaging tgz archive for libiconv 1.12_0+darwin_8 --- Deactivating libiconv 1.11_0 Error: Deactivating libiconv 1.11_0 failed: Active version of libiconv is not 1.11_0 but 1.11_0+darwin_8. ===CUT after which install proceded (apparently successful). trying to start `urxvt' now throws the error: ===CUT dyld: Library not loaded: /opt/local/lib/libiconv.2.dylib Referenced from: /opt/local/lib/libXft.2.dylib Reason: Incompatible library version: libXft.2.dylib requires version 7.0.0 or later, but libiconv.2.dylib provides version 5.0.0 Trace/BPT trap ===CUT trying a `sudo port deactivate [EMAIL PROTECTED]' yielded ===CUT Error: port deactivate failed: Registry error: libiconv not registered as installed active. ===CUT which seems inconsistent with the error message during urxvt install. after a `sudo port activate [EMAIL PROTECTED]' now everything seems to work, but the above messages seems to hint at some grade of corruption of the internal state of port. is this the case? can I sanitize/check it somehow without purging everything? I also notice that many packages appear both with `port list active' _and_ `port list inactive'. how can this be? and a last question: the active ports are the only one in use or are inactive ones (especially libs) secretly used by other ports? I noted that a tentative `sudo port uninstall [EMAIL PROTECTED]' showed me lots of ports depending on it which would need prior uninstall. I understand that different versions of libs are needed at the same time but why, then, is one declared active the others inactive? so in short what's the difference between active and inactive, especially for libs? joerg hi again, answering my own mail keeps it in this thread at least: in the meantime I had to realize that `w3m' (which was complaining just as `urxvt' before I manually activated libiconv1.12) contrary to `urxvt' is not happy again. even a `port uninstall w3m; port clean --all w3m; port install w3m' did not help: when starting `w3m' now. cpu time goes to 100% but w3m never pops up. here are the first (and last) few lines from `ktrace': CUT 19806 ktrace RET ktrace 0 19806 ktrace CALL execve(0xbfffecfc,0xb2e8,0xb2f4) 19806 ktrace NAMI /sw/bin/w3m 19806 ktrace RET execve -1 errno 2 No such file or directory 19806 ktrace CALL execve(0xbfffecfc,0xb2e8,0xb2f4) 19806 ktrace NAMI /sw/sbin/w3m 19806 ktrace RET execve -1 errno 2 No such file or directory 19806 ktrace CALL execve(0xbfffecfc,0xb2e8,0xb2f4) 19806 ktrace NAMI /opt/local/bin/w3m 19806 ktrace NAMI /usr/lib/dyld 19806 w3m RET execve 0 19806 w3m CALL issetugid 19806 w3m RET issetugid 0 19806 w3m CALL __sysctl(0xbfffed8c,0x2,0xbfffed94,0xbfffed88,0x8fe45a90,0xa) 19806 w3m RET __sysctl 0 19806 w3m CALL __sysctl(0xbfffed94,0x2,0x8fe599bc,0xbfffee38,0,0) 19806 w3m RET __sysctl 0 19806 w3m CALL __sysctl(0xbfffed8c,0x2,0xbfffed94,0xbfffed88,0x8fe45abc,0xd) 19806 w3m RET __sysctl 0 19806 w3m CALL __sysctl(0xbfffed94,0x2,0x8fe599b8,0xbfffee38,0,0) 19806 w3m RET __sysctl 0 19806 w3m CALL getpid 19806 w3m RET getpid 19806/0x4d5e 19806 w3m CALL __sysctl(0xbfffee40,0x3,0xbfffee38,0xbfffee3c,0,0) 19806 w3m RET __sysctl 0 19806 w3m CALL open(0x1570,0,0) 19806 w3m NAMI /opt/local/lib/libintl.8.dylib 19806 w3m RET open 3 19806 w3m CALL fstat(0x3,0xbfffcd10) 19806 w3m RET fstat 0 19806 w3m CALL pread(0x3,0xbfffd170,0x1000,0) 19806 w3m GIO fd 3 read 4096 bytes ... ... ... 19806 w3m RET pread 4096/0x1000 19806 w3m CALL shared_region_map_file_np(0x3,0x4,0xbfffbe60,0) 19806 w3m RET shared_region_map_file_np 0 19806 w3m CALL close(0x3) 19806 w3m RET close 0 19806 w3m CALL __sysctl(0xb19c,0x2,0xb198,0xb190,0,0) 19806 w3m RET __sysctl 0 19806
Re: urxvt: installing files outside common directory structure
On Thu, Mar 13, 2008 at 10:07:14AM -0400, Daniel J. Luke wrote: On Mar 13, 2008, at 6:44 AM, Joerg van den Hoff wrote: during upgrade of `rxvt-unicode' I've got the warning rxvt-unicode requests to install files outside the common directory structure! simple question: and where might that be?? port contents rxvt-unicode should give you an answer. -- Daniel J. Luke id does. thanks a lot! joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: ocaml fails on Tiger (was: Re: sudo port install mldonkey)
On Fri, Jan 04, 2008 at 12:05:14PM -0600, Ryan Schmidt wrote: On Jan 4, 2008, at 09:41, Charlse Darwin wrote: On Dec 26, 2007, at 8:14 AM, Ryan Schmidt wrote: This bug has already been reported: http://trac.macosforge.org/projects/macports/ticket/13583 # I installed ocaml from precompiled binary # http://caml.inria.fr/pub/distrib/ocaml-3.10/ocaml-3.10.0-ppc.dmg $ sudo port clean --dist --archive --work mldonkey --- Cleaning mldonkey $ sudo port clean --dist --archive --work ocaml Password: --- Cleaning ocaml $ sudo port clean --dist --archive --work mldonkey --- Cleaning mldonkey Mac:~ pm$ sudo port -f install mldonkey --- Fetching ocaml --- Attempting to fetch ocaml-3.10.0.tar.bz2 from http:// caml.inria.fr/pub/distrib/ocaml-3.10/ --- Verifying checksum(s) for ocaml --- Extracting ocaml --- Applying patches to ocaml --- Configuring ocaml Error: Target org.macports.configure returned: configure failure: shell command cd /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ ocaml/work/ocaml-3.10.0 ./configure -prefix /opt/local -no-tk returned error 2 Command output: sed: 1: s/-[^-]*$//: RE error: brackets ([ ]) not balanced ../gnu/config.sub: line 128: [: !=: unary operator expected Invalid configuration `powerpc-apple-darwin8.11.0': machine `' not recognized Please specify the correct host type with the -host option Error: The following dependencies failed to build: lablgtk ocaml Error: Status 1 encountered during processing. $ # How do I get it to skip ocaml? There isn't a built-in way to do that. MacPorts is designed not to make use of any software you install outside of MacPorts. You could possibly modify the portfile to look for ocaml in a different directory. But what we would really like is for someone to figure out why the ocaml port fails to build, and fix it. is there hope (i.e. is the package still actively maintained)? would it be helpful to cross post this issue on one of the ocaml lists asking for opinions/help? if so, where to send potential answers? to [EMAIL PROTECTED] as `port info ocaml' tells me? regards, joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: ion3 window manager no longer available
On Mon, Dec 17, 2007 at 02:01:58PM +0100, Vincent Lefevre wrote: On 2007-12-17 13:35:00 +0100, Joerg van den Hoff wrote: since `ion3' actually is a very fine window manager for a certain type of work, may I ask you to check whether it would'nt be sufficient to modify the package info line accordingly with some wildcard disclaimer of the kind: if this version is older than xxx weeks, please take note that this version is considered obsolete by the original author. upgrade manually to the most recent version found at http://modeemi.cs.tut.fi/~tuomov/ion/ before sending bug reports or questions to the author The name also needs to be changed. what name? the name of the package? why not call it `ion3_x11-wm' or whatever? I think one should be as pragmatic as possible about this: problem is artficial (from macports point of view, anyway), but ion3 is good software, so make the name change, explain reason in package info, provide package and forget about the noise. this possible or not? joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: ion3 window manager no longer available
On Mon, Dec 17, 2007 at 12:22:20PM -0500, William Davis wrote: On Dec 17, 2007, at 10:44 AM, Joerg van den Hoff wrote: On Mon, Dec 17, 2007 at 02:01:58PM +0100, Vincent Lefevre wrote: On 2007-12-17 13:35:00 +0100, Joerg van den Hoff wrote: since `ion3' actually is a very fine window manager for a certain type of work, may I ask you to check whether it would'nt be sufficient to modify the package info line accordingly with some wildcard disclaimer of the kind: if this version is older than xxx weeks, please take note that this version is considered obsolete by the original author. upgrade manually to the most recent version found at http://modeemi.cs.tut.fi/~tuomov/ion/ before sending bug reports or questions to the author The name also needs to be changed. what name? the name of the package? why not call it `ion3_x11-wm' or whatever? I think one should be as pragmatic as possible about this: problem is artficial (from macports point of view, anyway), but ion3 is good software, so make the name change, explain reason in package info, provide package and forget about the noise. this possible or not? joerg ___ Because using the name ion3 in any form would be a license violation. ok, got it. but the debian solution (some other arbitrary name) would work. so why can't you just include this (the renaming of the executable) into the patch procedure. Given the author's propensity for flame wars (not to mention possible law suits) I think IMHO we are better off without him. May I suggest you complain to the author instead. Why doesnt he believe me, I did. but you can only talk so much. incorporate a check for updates in his software and tell the end user there is no support for non-current versions if this bothers him so much? he will tell you that the user's are'nt going to read this, so it's not prominent enough etc etc. nevertheless, `ion3' is a very good tool (the author's attitude does not shine through :-)), so I would really appriciate it, if it's availability could somehow be secured. joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
ion3 problem
dear all, I've been using the `ion3' window manager (currently: 3rc-20070608) for quite some time now but have encountered a new problem with the above mentioned release which was not present before: tagging windows (`MOD1+T') apparently works (the checkbox in the title bar appears), but a subsequent `attach tagged' command is ignored (both, from the menu as well as via `MOD1+K+A'). on the other hand, attaching a window via `MOD1+A' and selecting the name still works OK. before getting bullied on the `ion3' help list my question is: can somebody confirm the above described failure of attaching tagged windows? thanks, joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
ghc does not tolerate rsync between different machines
hi, I ran into the following problem: I routinely do a complete rsync --delete of the `/opt/local' branch from a G5 PPC to a G4 PPC powerbook in order to have available the macports software there, too. this worked perfectly up to now. but when I now installed ghc-6.6.1 on the G5 PPC and rsynced to the G4, `ghci' did not start on the G4 and instead I got the error message: #-- dyld: Library not loaded: /opt/local/lib/libgmp.3.dylib Referenced from: /opt/local/lib/ghc-6.6.1/ghc-6.6.1 Reason: no suitable image found. Did find: /opt/local/lib/libgmp.3.dylib: incompatible cpu-subtype Trace/BPT trap #-- does this mean that due to the incompatible cpu-subtype I need to recompile ghc from scratch for the G4? I would rather not (it took 3 hours on the G5...). no way around this? regards, joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
ion3 upgrade failed
hi, I'd like to let you know that `ion-3rc-20070506.tar.gz' seems no longer available from tuomo's site and is replaced by a more recent version so that `port upgrade ion3' consequently failed. I hope (egoistically) that you'll find the time to look into this soon :-). I encountered another problem before the upgrade definitely failed: ... --- Deactivating libiconv 1.11_0 Error: Deactivating libiconv 1.11_0 failed: Active version of libiconv is not 1.11_0 but 1.11_0+darwin_8. --- Fetching expat ... is this a problem with the upgrade procedure or what need I to do with this one? any help appreciated (as always!) best regards, joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
ocaml
hi, ocaml 3.10 has been recently released. my question: will it occur on macports any time soon? regards, joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
ion3
hello, first, a big thank you for making `ion3' available via macports, which is a really excellent (and still rather unusual) window manager (not finding this package at all in `fink' brought me to `macports' in the first place...). unfortenuately, the `ion3' version available via macports is rather old. I therefore recently tried (unsuccessfully) to compile a newer release of ion3 myself. I gave up after some time due to unclear conflicts which I did not manage to resolve. my question: is their a chance that `ion3' will be updated on macports to a more recent version? this would be great. best regards, joerg ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
gworkspace install failed
hello, I tried installing gworkspace via macports on a G5 (10.4.8.) this ran initially smooth until the line --- Configuring gnutls below is the `port -v' output which follows at that point: cut=== checking build system type... powerpc-apple-darwin8.8.0 checking host system type... powerpc-apple-darwin8.8.0 checking target system type... powerpc-apple-darwin8.8.0 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes configure: autobuild project... gnutls configure: autobuild revision... 1.4.1 configure: autobuild hostname... marco.fz-rossendorf.de configure: autobuild timestamp... 20070206-115657 checking whether in dmalloc mode... no checking whether in electric fence mode... no checking whether in developer mode... no checking whether in profile mode... no *** *** Checking for compilation programs... checking whether NLS is requested... yes checking for msgfmt... /opt/local/bin/msgfmt checking for gmsgfmt... /opt/local/bin/msgfmt checking for xgettext... /opt/local/bin/xgettext checking for msgmerge... /opt/local/bin/msgmerge checking for style of include used by make... GNU 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 ISO C89... none needed checking dependency style of /usr/bin/gcc-4.0... gcc3 checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for shared library run path origin... done checking for CFPreferencesCopyAppValue... yes checking for CFLocaleCopyCurrent... yes checking whether NLS is requested... yes checking for GNU gettext in libc... no checking for iconv... yes checking how to link with libiconv... -liconv checking for GNU gettext in libintl... yes checking whether to use NLS... yes checking where the gettext function comes from... external libintl checking how to link with libintl... -lintl -liconv -lc -Wl,-framework -Wl,CoreFoundation checking for gcc... (cached) /usr/bin/gcc-4.0 checking whether we are using the GNU C compiler... (cached) yes checking whether /usr/bin/gcc-4.0 accepts -g... (cached) yes checking for /usr/bin/gcc-4.0 option to accept ISO C89... (cached) none needed checking dependency style of /usr/bin/gcc-4.0... (cached) gcc3 checking whether ln -s works... yes *** *** Detecting compiler options... checking for ranlib... ranlib checking for an ANSI C-conforming const... yes checking for inline... inline checking whether C99 macros are supported... yes checking if gcc supports -Wno-pointer-sign... yes checking whether we have GNU assembler... no *** *** Detecting C library capabilities... checking how to run the C preprocessor... /usr/bin/cpp-4.0 checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking whether time.h and sys/time.h may both be included... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for unistd.h... (cached) yes checking for strings.h... (cached) yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking alloca.h usability... yes checking alloca.h presence... yes checking for alloca.h... yes checking for sys/stat.h... (cached) yes checking for sys/types.h... (cached) yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking time.h usability... yes checking time.h presence... yes checking for time.h... yes checking math.h usability... yes checking math.h presence... yes checking for math.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking float.h usability... yes checking float.h presence... yes checking for float.h... yes checking stdarg.h usability... yes checking stdarg.h presence... yes checking for stdarg.h... yes checking ctype.h usability... yes checking ctype.h presence... yes checking for ctype.h... yes checking netdb.h usability... yes checking netdb.h presence... yes checking for netdb.h... yes checking for umask...
