status of `pdftk' package

[j. van den hoff]

installation and upgrading of the pdftk package fails (and does so for  
some time) issuing:


"pdftk currently does not build on OS X 10.11 or greater"

any chance to see pdftk working again any time soon? or is it an upstream  
problem?


thanks

joerg

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: py-hgsubversion install fails

[j. van den hoff]

if it helps, I'll type in everything you want (expect `/bin/rm -r'  I mean  
;-)) to get more info and solve the issue. just let me know (possibly  
off-list as well).


On Wed, 16 Mar 2016 21:31:54 +0100, Sean Farley <s...@macports.org> wrote:



j. van den hoff <veedeeh...@gmail.com> writes:

On Wed, 16 Mar 2016 19:41:39 +0100, Sean Farley <s...@macports.org>  
wrote:






Mercurial Distributed SCM (version 3.7.2)

$ which hg # ==> /opt/local/bin/hg





no, I have not: everything is installed via macports. in fact, the  
problem
appeared during today's `sudo port selfupdate; sudo port upgrade  
outdated'

run. maybe the error is related to some other dependency? only guessing,
of course ...


It must be picking up some python path because that error was introduced
in aa73d6a5d9ea in hg:

https://bitbucket.org/seanfarley/hg/commits/aa73d6a5d9ea

But that commit was after the 3.7.2 release. Certainly strange. I wonder
which path it's picking up.



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: py-hgsubversion install fails

[j. van den hoff]

thanks. will try (if it is feasible for a "non-pythonist").  will keep you  
informed.


On Wed, 16 Mar 2016 21:47:38 +0100, Sean Farley <s...@macports.org> wrote:



j. van den hoff <veedeeh...@gmail.com> writes:

if it helps, I'll type in everything you want (expect `/bin/rm -r'  I  
mean

;-)) to get more info and solve the issue. just let me know (possibly
off-list as well).


My best guess at debugging would be to clean and extract the port:

$ sudo port -v clean py27-hgsubversion
$ sudo port -v extract py27-hgsubversion

Then edit the file that has the stacktrace to print out all the python
paths and modules (I forgot the variable names off the top of my head).

After you've editing that (perhaps printing it to stderr), try to
install again and hopefully it will print what it finds:

$ sudo port -v install py27-hgsubversion

Not sure what else to do besides that.



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: py-hgsubversion install fails

[j. van den hoff]

On Wed, 16 Mar 2016 19:41:39 +0100, Sean Farley <s...@macports.org> wrote:



j. van den hoff <veedeeh...@gmail.com> writes:


on one of two machines (both running 10.10.5 and current `port')
installation of py-hgsubversion fails with (end of logfile):

8<--
...
CC='/usr/bin/clang'
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/.CC_PRINT_OPTIONS'
CFLAGS=''
CPATH='/opt/local/include'
CXX='/usr/bin/clang++'
CXXFLAGS=''
F90FLAGS=''
FCFLAGS=''
FFLAGS=''
LDFLAGS=''
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.10'
OBJC='/usr/bin/clang'
OBJCFLAGS=''
:debug:build Assembled command: 'cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5"
&&
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
setup.py --no-user-cfg build'
:debug:build Executing command line:  cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5"
&&
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
setup.py --no-user-cfg build
:info:build Traceback (most recent call last):
:info:build   File "setup.py", line 106, in 
:info:build from hgsubversion.svnwrap import svn_swig_wrapper
:info:build   File
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5/hgsubversion/__init__.py",
line 198, in 
:info:build commands.optionalrepo += ' svn'
:info:build AttributeError: 'module' object has no attribute  
'optionalrepo'


This seems like a mismatch with Mercurial. Which version do you have


Mercurial Distributed SCM (version 3.7.2)

$ which hg # ==> /opt/local/bin/hg


installed? Do you have Mercurial installed into /usr/local or something
like that?


no, I have not: everything is installed via macports. in fact, the problem  
appeared during today's `sudo port selfupdate; sudo port upgrade outdated'  
run. maybe the error is related to some other dependency? only guessing,  
of course ...


I also just have cloned `hgsubversion' from the bitbucket repo and pointed  
`hgrc' to that one: works w/o problems. so the failed install right now is  
not really pressing for me but of course I wonder what is going wrong (and  
only on this one machine, not the other one with a not-quite-identical  
(but very similar) macports setup). so if I can provide any more  
information please let me know.


thank you

joerg




--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

py-hgsubversion install fails

[j. van den hoff]

on one of two machines (both running 10.10.5 and current `port')  
installation of py-hgsubversion fails with (end of logfile):


8<--
...
CC='/usr/bin/clang'
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/.CC_PRINT_OPTIONS'
CFLAGS=''
CPATH='/opt/local/include'
CXX='/usr/bin/clang++'
CXXFLAGS=''
F90FLAGS=''
FCFLAGS=''
FFLAGS=''
LDFLAGS=''
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.10'
OBJC='/usr/bin/clang'
OBJCFLAGS=''
:debug:build Assembled command: 'cd  
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5"  
&&  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7  
setup.py --no-user-cfg build'
:debug:build Executing command line:  cd  
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5"  
&&  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7  
setup.py --no-user-cfg build

:info:build Traceback (most recent call last):
:info:build   File "setup.py", line 106, in 
:info:build from hgsubversion.svnwrap import svn_swig_wrapper
:info:build   File  
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5/hgsubversion/__init__.py",  
line 198, in 

:info:build commands.optionalrepo += ' svn'
:info:build AttributeError: 'module' object has no attribute 'optionalrepo'
:info:build Command failed:  cd  
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/work/1.8.5"  
&&  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7  
setup.py --no-user-cfg build

:info:build Exit code: 1
:error:build org.macports.build for port py27-hgsubversion returned:  
command execution failed

:debug:build Error code: CHILDSTATUS 58381 1
:debug:build Backtrace: command execution failed
while executing
"system -nice 0 $fullcmdstring"
("eval" body line 1)
invoked from within
"eval system $notty $nice \$fullcmdstring"
invoked from within
"command_exec build"
(procedure "portbuild::build_main" line 8)
invoked from within
"portbuild::build_main org.macports.build"
("eval" body line 1)
invoked from within
"eval $procedure $targetname"
:info:build Warning: targets not executed for py27-hgsubversion:  
org.macports.activate org.macports.build org.macports.destroot  
org.macports.install
:notice:build Please see the log file for port py27-hgsubversion for  
details:


/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-hgsubversion/py27-hgsubversion/main.log
8<--

any ideas? worth a ticket/bug report?

thx, joerg

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

staging sc into destroot failed

[j. van den hoff]

I encountered this today (current `port' and osx 10.10.5), when upgrading  
`sc'. the tail of the log file read:


8<--
:debug:destroot destroot phase started at Thu Jan 28 12:57:17 CET 2016
:notice:destroot --->  Staging sc into destroot
:info:destroot . missing (directory not created: File exists)
:info:destroot ./Applications missing (directory not created: File exists)
:info:destroot ./Developer missing (directory not created: File exists)
:info:destroot ./Library missing (directory not created: File exists)
:debug:destroot Executing org.macports.destroot (sc)
:debug:destroot Environment:
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.10'
:debug:destroot Assembled command: 'cd  
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/sc-7.16"  
&& /usr/bin/make -w install  
DESTDIR=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/destroot  
prefix=/opt/local'
:debug:destroot Executing command line:  cd  
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/sc-7.16"  
&& /usr/bin/make -w install  
DESTDIR=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/destroot  
prefix=/opt/local
:info:destroot make: Entering directory  
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/sc-7.16'
:info:destroot cp sc  
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/destroot/opt/local/bin/
:info:destroot strip  
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/destroot/opt/local/bin/sc
:info:destroot cp scqref  
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/destroot/opt/local/bin/
:info:destroot strip  
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/destroot/opt/local/bin/scqref
:info:destroot cp psc  
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/destroot/opt/local/bin/
:info:destroot strip  
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/destroot/opt/local/bin/psc
:info:destroot mkdir  
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/destroot/opt/local/share/doc/sc
:info:destroot mkdir:  
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/destroot/opt/local/share/doc:  
No such file or directory

:info:destroot make: *** [/opt/local/share/doc/sc] Error 1
:info:destroot make: Leaving directory  
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/sc-7.16'
:info:destroot Command failed:  cd  
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/sc-7.16"  
&& /usr/bin/make -w install  
DESTDIR=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_finance_sc/sc/work/destroot  
prefix=/opt/local

:info:destroot Exit code: 2
:error:destroot org.macports.destroot for port sc returned: command  
execution failed

:debug:destroot Error code: CHILDSTATUS 34839 2
:debug:destroot Backtrace: command execution failed
while executing
"system -nice 0 $fullcmdstring"
("eval" body line 1)
invoked from within
"eval system $notty $nice \$fullcmdstring"
invoked from within
"command_exec destroot"
(procedure "portdestroot::destroot_main" line 2)
invoked from within
"portdestroot::destroot_main org.macports.destroot"
("eval" body line 1)
invoked from within
"eval $procedure $targetname"
:info:destroot Warning: targets not executed for sc: org.macports.activate  
org.macports.destroot org.macports.install

8<--

does not look like a new "ticket" (or does it?), but something wents wrong  
in the final phase. any ideas?


thanks
joerg

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org

Re: New Mac OS Forge administrator

[j. van den hoff]

On Fri, 20 Nov 2015 22:03:23 +0100, Ian Wadham  wrote:


On 21/11/2015, at 7:15 AM, Bradley Giesbrecht wrote:

Bam, confidence restored!


Congratulations, Ryan!  It is great to know that you will be
the person handling this important job.

I hope you will still find some time to answer queries on the list
or that someone else will step into your shoes.  I have learned
and benefited so much from your posts in the last few years and
I am sure others would agree.


+1



All the best, Ian W.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

`man groff_char' misbehaving

[j. van den hoff]

I see the following output from `man groff_char' with version 1.22.3 of
`groff' under macos 10.10.5:

/usr/bin/tbl::294: unrecognised format `O'
/usr/bin/tbl::294: giving up on this table

(many more similar lines following)

and the finally appearing manpage indeed does not contain the tables
listing the glyphs as it should. any ideas?

thank you

joerg
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: `man groff_char' misbehaving

[j. van den hoff]

On Wed, 18 Nov 2015 22:01:32 +0100, Ryan Schmidt <ryandes...@macports.org>
wrote:



On Nov 18, 2015, at 1:43 PM, j. van den hoff wrote:


I see the following output from `man groff_char' with version 1.22.3 of
`groff' under macos 10.10.5:

/usr/bin/tbl::294: unrecognised format `O'
/usr/bin/tbl::294: giving up on this table

(many more similar lines following)

and the finally appearing manpage indeed does not contain the tables
listing the glyphs as it should. any ideas?


I can confirm that behavior under 10.11.1 with the groff port installed.

I guess OS X's man program is not able to read the groff port's manpage.

Installing the man port seems to work around this problem. Is that  
satisfactory?


ah yes, never occured to me tht there might be a man port as well. thank
you for this solution. regarding "satisfactory": for my personal use, yes
it is. generally, I'd say no, since it seems osx's man does something
wrong/non-canonical, no?







--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: `man groff_char' misbehaving

[j. van den hoff]

On Wed, 18 Nov 2015 22:19:58 +0100, Brandon Allbery <allber...@gmail.com>  
wrote:



On Wed, Nov 18, 2015 at 4:17 PM, j. van den hoff <veedeeh...@gmail.com>
wrote:

well, groff_char is a manpage from the groff project itself and I would  
be
surprised if it has changed much (and in a backward incompatible way!)  
in
recent years (but did not check/verify this). actually it seems the  
problem
is with the `tbl' precprocessor (that's the one throwing the errors).  
maybe

I will try to ask at the groff mailing list what's going on here.



tbl is part of / distributed with groff. And last I checked, Apple (and  
the

*BSDs in general) was shipping a *really ancient* groff, probably because
of license concerns.


that's true. it is GNU groff version 1.19.2
Copyright (C) 2004

and (the old) `tbl' is complaining about an unknown directive in the (new)  
groff_char manpage. so that's probably the reason for the trouble.







--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: ghostscript problem

[j. van den hoff]

On Sat, 26 Sep 2015 00:29:54 +0200, Mojca Miklavec <mo...@macports.org>  
wrote:



On Fri, Sep 25, 2015 at 5:52 PM, j. van den hoff wrote:
not sure whether this qualifies for a ticket: after recent (~ 2 days  
ago)
`port upgrade outdated' postscript generation via `ghostscript' fails  
for me

with an error

Error: /invalidfont in /findfont
Operand stack:
   Times-Roman@0   --nostringval--   Times-Roman
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
--nostringval
p   1966   1   3   %oparray_pop   1950   1   3   %oparray_pop   1836
1   3

--nostringval--   --nostringval--   1919   3   4   %oparray_pop
Dictionary stack:
   --dict:1200/1684(ro)(G)--   --dict:0/20(G)--   --dict:79/200(L)--
--dict:5
Current allocation mode is local
Last OS error: Invalid argument
Current file position is 5762
GPL Ghostscript 9.16: Unrecoverable error, exit code 1


apparently when looking for basic fonts such as times roman. so it  
seems to

longer be able to locate any fonts. unfortunately I don't know anything
specific of ghostscript (just using it via `groff' to generate some
postscript/pdf output).

this happens with  ghostscript @9.16_1+x11. if I deactivate this one and
activate `ghostscript @9.10_2+x11' (which I luckily still had available)
everything goes back to normal.

no idea what is going on here. any help appreciated. if I can provide
further information I'll be glad to do this.

seen with macos 10.10.5 and MacPorts 2.3.3




thanks for your reply.


It looks suspiciously similar to
https://trac.macports.org/ticket/42395, even though it could be
different enough to happen for to a different reason. That ticket was
opened while 9.10 was still the latest version.

You could either open a new ticket or add more information to the
existing one, possibly together with some "minimal" (or at least
relatively small) GS file (or description of how you got that file)
that triggers the error, to make it easier for others to reproduce the
problem.


I think I will do that (new ticket) since as mentioned when switching from  
9.16 back to 9.10 behaviour goes back to normal in my case.




(In any case I have no clue where the fonts are.)


just a remark: I looked at https://trac.macports.org/ticket/42395 and  
noted the comments regarding absence of "Times related" fonts in   
/opt/local/share/ghostscript/9.10/Resource/Font/. I believe this is a  
misconception: AFAIK, ghostscript is using the (free) Nimbus font family  
(Mon, RomNo9, San) as drop in replacement for Courier, Times, Helvetica,  
respectively, so I would think the required fonts are actually there ...  
not that this helps to understand what's going on.


joerg



Mojca



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: ghostscript problem

[j. van den hoff]

I investigated a bit further: actually I believe I see now what's going  
wrong. for some reason or other there is an inconsistency in font file  
naming/requesting: ghostscript wants to use the `Nimbus Roman' font as  
drop in replacement for Times (as it used to be for many years). this is  
fine. but actually with 9.16 ghostscript requests/expects that this font  
is named


NimbusRomNo9L-Regu

while in /opt/local/share/ghostscript/9.16/Resource/Font the font actually  
is names


NimbusRom-Reg

similar conflicts occur for the other fonts there. it's still a mystery to  
me _how_ this inconsistency can occur in the first place. any ideas how to  
proceed (apart from opening a ticket, I mean ;-))


joerg


On Sat, 26 Sep 2015 00:29:54 +0200, Mojca Miklavec <mo...@macports.org>  
wrote:



On Fri, Sep 25, 2015 at 5:52 PM, j. van den hoff wrote:
not sure whether this qualifies for a ticket: after recent (~ 2 days  
ago)
`port upgrade outdated' postscript generation via `ghostscript' fails  
for me

with an error

Error: /invalidfont in /findfont
Operand stack:
   Times-Roman@0   --nostringval--   Times-Roman
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
--nostringval
p   1966   1   3   %oparray_pop   1950   1   3   %oparray_pop   1836
1   3

--nostringval--   --nostringval--   1919   3   4   %oparray_pop
Dictionary stack:
   --dict:1200/1684(ro)(G)--   --dict:0/20(G)--   --dict:79/200(L)--
--dict:5
Current allocation mode is local
Last OS error: Invalid argument
Current file position is 5762
GPL Ghostscript 9.16: Unrecoverable error, exit code 1


apparently when looking for basic fonts such as times roman. so it  
seems to

longer be able to locate any fonts. unfortunately I don't know anything
specific of ghostscript (just using it via `groff' to generate some
postscript/pdf output).

this happens with  ghostscript @9.16_1+x11. if I deactivate this one and
activate `ghostscript @9.10_2+x11' (which I luckily still had available)
everything goes back to normal.

no idea what is going on here. any help appreciated. if I can provide
further information I'll be glad to do this.

seen with macos 10.10.5 and MacPorts 2.3.3


It looks suspiciously similar to
https://trac.macports.org/ticket/42395, even though it could be
different enough to happen for to a different reason. That ticket was
opened while 9.10 was still the latest version.

You could either open a new ticket or add more information to the
existing one, possibly together with some "minimal" (or at least
relatively small) GS file (or description of how you got that file)
that triggers the error, to make it easier for others to reproduce the
problem.

(In any case I have no clue where the fonts are.)

Mojca



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

ghostscript problem

[j. van den hoff]

not sure whether this qualifies for a ticket: after recent (~ 2 days ago)  
`port upgrade outdated' postscript generation via `ghostscript' fails for  
me with an error


Error: /invalidfont in /findfont
Operand stack:
   Times-Roman@0   --nostringval--   Times-Roman
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
--nostringval  
p   1966   1   3   %oparray_pop   1950   1   3   %oparray_pop   1836   1
3
--nostringval--   --nostringval--   1919   3   4   %oparray_pop

Dictionary stack:
   --dict:1200/1684(ro)(G)--   --dict:0/20(G)--   --dict:79/200(L)--
--dict:5

Current allocation mode is local
Last OS error: Invalid argument
Current file position is 5762
GPL Ghostscript 9.16: Unrecoverable error, exit code 1


apparently when looking for basic fonts such as times roman. so it seems  
to longer be able to locate any fonts. unfortunately I don't know anything  
specific of ghostscript (just using it via `groff' to generate some  
postscript/pdf output).


this happens with  ghostscript @9.16_1+x11. if I deactivate this one and  
activate `ghostscript @9.10_2+x11' (which I luckily still had available)  
everything goes back to normal.


no idea what is going on here. any help appreciated. if I can provide  
further information I'll be glad to do this.


seen with macos 10.10.5 and MacPorts 2.3.3

best regards,

joerg


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

midori/webkit crashes: illegal instruction

[j. van den hoff]

I see reproducible crashes of midori on a macpro under 10.10.3 with the  
error message illegal instruction. I suspect this error is due to some  
problem with the webkit-gtk @2.4.8_1+video package since I get the same  
error message from a different browser (external to macports) which I  
compiled from source with linking against the macports provided webkit-gtk  
library. can anyone reproduce the problem? any advice how to better  
identify the cause of the problem?


I only see this on the mac pro, while on a macbook pro everything runs  
just fine ...


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

port upgrade octave fails

[j. van den hoff]

I just did a `port selfupdate; port upgrade outdated' run under macos  
10.10.3 on a mac pro. `octave' fails like this during the configure phase  
(final section of main.log):


8--
:info:configure checking whether we are using the GNU Fortran 77  
compiler... no
:info:configure checking whether /opt/local/bin/gfortran-mp-4.8 accepts  
-g... no
:info:configure checking how to get verbose linking output from  
/opt/local/bin/gfortran-mp-4.8... configure: WARNING: compilation failed

:info:configure
:info:configure checking for Fortran 77 libraries of  
/opt/local/bin/gfortran-mp-4.8...
:info:configure checking for dummy main to link with Fortran 77  
libraries... none
:info:configure checking for Fortran 77 name-mangling scheme... configure:  
error: in  
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_octave/octave/work/octave-3.8.2':

:info:configure configure: error: cannot compile a simple Fortran program
:info:configure See `config.log' for more details
:info:configure Command failed:  cd  
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_octave/octave/work/octave-3.8.2  
 ./configure --prefix=/opt/local --disable-dependency-tracking  
--with-umfpack=-lumfpack -lSuiteSparse --enable-docs  
--enable-strict-warning-flags --disable-silent-rules --without-x  
--with-opengl --disable-gui --disable-java --with-cholmod=-lcholmod  
--with-blas=-lcblas -lf77blas -latlas --with-lapack=-llapack

:info:configure Exit code: 1
:error:configure Failed to configure octave, consult  
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_octave/octave/work/octave-3.8.2/config.log
:error:configure org.macports.configure for port octave returned:  
configure failure: command execution failed

:debug:configure Error code: NONE
:debug:configure Backtrace: configure failure: command execution failed
while executing
portconfigure::configure_main org.macports.configure
(eval body line 1)
invoked from within
eval $procedure $targetname
:info:configure Warning: targets not executed for octave:  
org.macports.install org.macports.configure org.macports.build  
org.macports.destroot

8--

it seems the fortran compiler is not found or cannot be used, no? does  
this require a bug report or am I overlooking something obvious?


thx/joerg

ps: the same selfupdate/upgrade does _not_ choke on `octave' on a macbook  
pro also running 10.10.3...


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: transfer /opt/local to another machine

[j. van den hoff]

thanks to both of you for your answers and clarifications.

On Mon, 13 Apr 2015 04:04:14 +0200, Ryan Schmidt ryandes...@macports.org  
wrote:




On Apr 12, 2015, at 5:54 AM, j. van den hoff wrote:

I just have upgraded two x86_64 machines from 10.9. to 10.10.3 and  
upgraded one of them according to the migration guide (i.e.  
uninstalled/reinstalled all ~ 800 macports packages). this took an  
astonishing long time (over night, basically) partly due to a  
multi-hour recompilation of the `atlas' library. and that was on the  
faster machine with an SSD...


This is intentional, because atlas is performance-sensitive, so the port  
is deliberately programmed to not use precompiled binaries from our  
build server, and to instead build on your computer. My understanding is  
that the build process builds atlas many times, with different compiler  
settings, then tries out each one to see which one is actually fastest  
on your particular computer, then installs that one. That's why it takes  
so long.


yes, I understand that. I'm not sure, however, how much of a performance  
hit I will see when using the intel core-i7 optimized binary on an intel  
core 2 duo, so I just would try it out, whether it's OK for my use (that  
would mean via `octave', which I am using only sporadically, so ...).





one marginal observation I made: after `port deactivate installed' when  
executing `port installed active' I receive the message None of the  
specified ports are installed. which probably should read None of the  
specified ports are active. or No ports are active..


The message is correct. You ran the installed command, and as an  
argument you specified the list of ports you wanted installation details  
for, namely, the list of active ports. The list of active ports is  
empty, so it is correct, in a way, for MacPorts to say that none of the


I guessed so much.

zero ports specified are installed. If anything, the message could be  
clarified to read No ports were specified or maybe The list of  
specified ports is empty.


that what be somewhat better, yes. but actually I think it would be  
clearer to handle these pseudo-portnames (possibly on a per case basis, if  
needed) in the messages. I guess that currently the message generating  
code only gets the list of ports to which the pseudo-portname expands? for  
instance, right now I _do_ have 2 inactive ports (which, by the way,  
magically reappeared (were downloaded etc) during the `port installed  
activate' run of the migration procedure (specifically these two: llvm-3.5  
@3.5.1_3 and  SuiteSparse @4.2.1_3+atlas+gcc48) -- no precise idea why  
this happens (in fact they were there inactive in the first place so I  
trashed them in the initial phase of the migration. that they reappear  
seems to indicate that they are required, despite being inactive??).


so, with these 2 inactive ports I get the message for `port installed  
inactive':


The following ports are currently installed:
  llvm-3.5 @3.5.1_3
  SuiteSparse @4.2.1_3+atlas+gcc48

this seems equally misleading to me as the no ports are installed  
message when there are no inactive ports at all. if the report generator  
would keep track of the entered pseudo-portname the message seemingly  
could easily be clarified to


The following ports are currently installed and {port pseudo-portname  
here}.


another question regarding the manpage and `port help' output: `installed'  
and `(in)active' are both listed as pseudo-portnames expanding to the list  
of denoted ports. this sure is true for `port installed' and `port  
outdated', e.g. but not so for most of  the others, such as `port  
(in)active' which interpret these words as (unknown actions).  what is  
wrong: the documentation or my understanding of it?








--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: transfer /opt/local to another machine

[j. van den hoff]

On Mon, 13 Apr 2015 11:34:29 +0200, Chris Jones jon...@hep.phy.cam.ac.uk  
wrote:



On 13/04/15 10:27, j. van den hoff wrote:

thanks to both of you for your answers and clarifications.

On Mon, 13 Apr 2015 04:04:14 +0200, Ryan Schmidt
ryandes...@macports.org wrote:



On Apr 12, 2015, at 5:54 AM, j. van den hoff wrote:


I just have upgraded two x86_64 machines from 10.9. to 10.10.3 and
upgraded one of them according to the migration guide (i.e.
uninstalled/reinstalled all ~ 800 macports packages). this took an
astonishing long time (over night, basically) partly due to a
multi-hour recompilation of the `atlas' library. and that was on the
faster machine with an SSD...


This is intentional, because atlas is performance-sensitive, so the
port is deliberately programmed to not use precompiled binaries from
our build server, and to instead build on your computer. My
understanding is that the build process builds atlas many times, with
different compiler settings, then tries out each one to see which one
is actually fastest on your particular computer, then installs that
one. That's why it takes so long.


yes, I understand that. I'm not sure, however, how much of a performance
hit I will see when using the intel core-i7 optimized binary on an intel
core 2 duo, so I just would try it out, whether it's OK for my use (that
would mean via `octave', which I am using only sporadically, so ...).


If the core-i7 build is using CPU instructions your core 2 due does not  
have, then the performance hit will be 'significant' (i.e. it simply  
will not run...).


OK, _that_ I would note and accordingly would recompile ;-). I'm not  
trying to avoid that at all costs, anyway. being able to transfer an  
existing comprehensive macports installation to further machines seems  
valuable in itself I would say, e.g. if you are on a slow internet  
connection or just want to quickly get some canonical set of software  
running on the other machines. at least if such a procedure is not calling  
for real trouble (except with atlas, probably).







--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: transfer /opt/local to another machine

[j. van den hoff]

On Mon, 13 Apr 2015 12:34:00 +0200, Ryan Schmidt ryandes...@macports.org  
wrote:




On Apr 13, 2015, at 4:27 AM, j. van den hoff wrote:

one marginal observation I made: after `port deactivate installed'  
when executing `port installed active' I receive the message None of  
the specified ports are installed. which probably should read None  
of the specified ports are active. or No ports are active..


The message is correct. You ran the installed command, and as an  
argument you specified the list of ports you wanted installation  
details for, namely, the list of active ports. The list of active  
ports is empty, so it is correct, in a way, for MacPorts to say that  
none of the


I guessed so much.

zero ports specified are installed. If anything, the message could be  
clarified to read No ports were specified or maybe The list of  
specified ports is empty.


that what be somewhat better, yes. but actually I think it would be  
clearer to handle these pseudo-portnames (possibly on a per case basis,  
if needed) in the messages. I guess that currently the message  
generating code only gets the list of ports to which the  
pseudo-portname expands?


That is what I guess as well. And note that we're not just talking about  
pseudoports (like active, inactive, installed, outdated,  
requested, unrequested, leaves, obsolete). We're also talking  
about any arbitrary expression the user might specify, such as name:php  
and category:databases.



for instance, right now I _do_ have 2 inactive ports (which, by the  
way, magically reappeared (were downloaded etc) during the `port  
installed activate' run of the migration procedure (specifically these  
two: llvm-3.5 @3.5.1_3 and  SuiteSparse @4.2.1_3+atlas+gcc48) -- no  
precise idea why this happens (in fact they were there inactive in the  
first place so I trashed them in the initial phase of the migration.  
that they reappear seems to indicate that they are required, despite  
being inactive??).


There is no port installed activate; that command doesn't make sense  
because activate is not a valid pseudoport name.


sorry that was a typo: I meant `port installed active'



I don't have time to analyze this right now but if MacPorts installed a  
port for you then it was required. Or, if you were using the  
restore_ports.tcl script in the Migration instructions, then it was  
reinstalled for you because you had it installed before, as recorded in  
your myports.txt file.


so, with these 2 inactive ports I get the message for `port installed  
inactive':


The following ports are currently installed:
 llvm-3.5 @3.5.1_3
 SuiteSparse @4.2.1_3+atlas+gcc48

this seems equally misleading to me as the no ports are installed  
message when there are no inactive ports at all.


It is accurate, in that you asked for a list of installed ports that are  
inactive, and that's what was printed.


yes, sure,  principally it is since it is the response to the preceding  
query. but it is not self-explanatory as a message (if, e.g., dumped to  
some logfile for later processing).





if the report generator would keep track of the entered pseudo-portname  
the message seemingly could easily be clarified to


The following ports are currently installed and {port pseudo-portname  
here}.


That doesn't read well for arbitrary expressions like name:php and  
category:databases. Better might be:


The following ports matching the port selector inactive are installed:


yes, that would be good I believe: just augment the output in a way that  
it contains sufficient information regarding the query generating it.





another question regarding the manpage and `port help' output:  
`installed' and `(in)active' are both listed as pseudo-portnames  
expanding to the list of denoted ports. this sure is true for `port  
installed' and `port outdated', e.g. but not so for most of  the  
others, such as `port (in)active' which interpret these words as  
(unknown actions).  what is wrong: the documentation or my  
understanding of it?


The confusion is that installed and outdated are both commands (as  
in port installed and port outdated) and pseudoports (as in port  
uninstall installed and port upgrade outdated).


active, inactive, requested, unrequested, leaves, obsolete  
are only pseudoports; they are not commands.


activate, deactivate, install, uninstall are only commands; they  
are not pseudoports.


of course. stupid me...








--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

transfer /opt/local to another machine

[j. van den hoff]

I just have upgraded two x86_64 machines from 10.9. to 10.10.3 and  
upgraded one of them according to the migration guide (i.e.  
uninstalled/reinstalled all ~ 800 macports packages). this took an  
astonishing long time (over night, basically) partly due to a multi-hour  
recompilation of the `atlas' library. and that was on the faster machine  
with an SSD...


so I don't want to do the same on the other one. therefore I would like to  
inquire whether it is acceptable to do the following (there was an old  
mail in the archive by ryan schmidt recommending this sort of procedure, I  
believe). both machines have current Xcode tools installed:


# on first machine do:
# 
# 1. tidy up
sudo port uninstall inactive
sudo port clean --all all

# now generate tarfile
sudo port -vf deactivate installed
sudo tar vcf myports.tar /opt/local
sudo port -v activate installed

# move the tarfile to the second machine and there do:
# 
sudo port -vf deactivate installed   #is this redundant or required to  
cleanup outside /opt/local?

sudo rm -rf /opt/local
sudo tar xf myports.tar
sudo port -v activate installed

my understanding is that the system bsdtar will not run into file size  
problems even beyound 8GB and permissions should be correctly restored by  
the above on the second machine. but I wonder whether I will not miss  
assorted pieces installed by macports outside of /opt/local? any advice  
would be appreciated.


one marginal observation I made: after `port deactivate installed' when  
executing `port installed active' I receive the message None of the  
specified ports are installed. which probably should read None of the  
specified ports are active. or No ports are active..


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: tclreadline install fails under 10.10

[j. van den hoff]

very good -- thanks a lot! and I hope that you are right regarding it  
being easy ...



On Sat, 11 Apr 2015 13:28:27 +0200, Ryan Schmidt ryandes...@macports.org  
wrote:




On Apr 11, 2015, at 5:46 AM, j. van den hoff wrote:


I ran into this problem today after upgrading from 10.9 to 10.10.3. the  
install fails with exactly the same error messages reported 4 months  
ago in the ticket https://trac.macports.org/ticket/46059. seemingly  
nothing could be done about the problem since then. is there any hope  
that this is going to be looked at by someone in the know in the near  
future? any advice how to workaround the problem would be appreciated,  
too, of course.


thanks,
joerg

PS: a bit of googling at least seems to indicate that the problem is  
not tclreadline specific but some principal thing with readline:


https://lists.samba.org/archive/samba-technical/2014-June/100837.html  
(samba)


http://lists.freebsd.org/pipermail/freebsd-python/2014-March/006664.html  
(python)


in the latter link there even is a patch reported for readline.c which  
allegedly fixes the problem. maybe this is of some help...


I'll take a look. Looks like a problem I've seen and fixed in other  
ports, so hopefully it's easy.





___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

tclreadline install fails under 10.10

[j. van den hoff]

hi list,

I ran into this problem today after upgrading from 10.9 to 10.10.3. the  
install fails with exactly the same error messages reported 4 months ago  
in the ticket https://trac.macports.org/ticket/46059. seemingly nothing  
could be done about the problem since then. is there any hope that this is  
going to be looked at by someone in the know in the near future? any  
advice how to workaround the problem would be appreciated, too, of course.


thanks,
joerg

PS: a bit of googling at least seems to indicate that the problem is not  
tclreadline specific but some principal thing with readline:


https://lists.samba.org/archive/samba-technical/2014-June/100837.html  
(samba)


http://lists.freebsd.org/pipermail/freebsd-python/2014-March/006664.html  
(python)


in the latter link there even is a patch reported for readline.c which  
allegedly fixes the problem. maybe this is of some help...


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: tclreadline install fails under 10.10

[j. van den hoff]

On Sat, 11 Apr 2015 13:38:39 +0200, Ryan Schmidt ryandes...@macports.org  
wrote:




On Apr 11, 2015, at 6:36 AM, j. van den hoff wrote:

very good -- thanks a lot! and I hope that you are right regarding it  
being easy ...


Fixed. Wait 30 minutes, run sudo port selfupdate, and then try again.



gee, that was fast... and it works perfectly.

many thanks,

joerg


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

`ports clean all' warning: No value for java JAVA_HOME was automatically discovered

[j. van den hoff]

I found only one (seemingly unanswered post in the archive: does somebody  
now where this warning comes from in the
`ports clean all' process (observed under 10.9.2)? more importantly: are  
they relevant?


e.g., one instance happens here:

...
---  Cleaning jump
Warning: No value for java JAVA_HOME was automatically discovered
---  Cleaning junit
...

I only see a handful of these warnings during the `clean all' run but  
still ...


j.

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

port install ksh93 fails

[j. van den hoff]

I'm currently in the process of setting up macports from scratch after  
upgrade ot 10.9(.2). so far the migration procedure found on the macports  
page mostly has worked (some glitches, of course), but now I see some real  
problems:



sudo port install ksh93

runs just fine (silently), seemingly until the file stage:

8
Staging ksh93 into destroot
. missing (directory not created: File exists)
./Applications missing (directory not created: File exists)
./Developer missing (directory not created: File exists)
./Library missing (directory not created: File exists)
Error: org.macports.destroot for port ksh93 returned: xinstall: Cannot  
stat:  
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_shells_ksh93/ksh93/work/ksh93-2012-08-01/arch/darwin.i386-64/bin/ksh,  
No such file or directory

8

and indeed the compiled binary is not there. should I create a ticket or  
is it something trivial/obvious?


thanks

joerg

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: port install ksh93 fails

[j. van den hoff]

On Wed, 16 Apr 2014 16:07:44 +0200, Jeremy Lavergne  
jer...@lavergne.gotdns.org wrote:


My guess is that the darwin.i386-64” part is incorrect in your  
situation. Was this built +universal?



it first happened when following the migration cookbook on the macports  
page and executing the `restore_ports.tcl' script. when that failed I did  
`sudo port clean ksh93; sudo port install ksh93' and I believe ksh93 has  
no variants?




I’d do a clean build to attach to a ticket:
sudo port clean ksh93
sudo port install ksh93
attach `port logfile ksh93` to the ticket


will do.

thanks,

j.



On Apr 16, 2014, at 9:59, j. van den hoff veedeeh...@googlemail.com  
wrote:



work/ksh93-2012-08-01/arch/darwin.i386-64/bin/ksh





--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

`port selfupdate; port upgrade outdated' fails

[j. van den hoff]

not sure whether this should be reported via the ticket system:

I just tried to `upgrade outdated' after a `selfupdate' and this failed  
with:


sudo port upgrade outdated
---  Fetching archive for apr
---  Attempting to fetch apr-1.4.8_0.darwin_12.x86_64.tbz2 from  
http://lil.fr.packages.macports.org/apr
---  Attempting to fetch apr-1.4.8_0.darwin_12.x86_64.tbz2.rmd160 from  
http://lil.fr.packages.macports.org/apr

---  Installing apr @1.4.8_0
---  Cleaning apr
---  Deactivating apr @1.4.6_1
---  Cleaning apr
---  Activating apr @1.4.8_0
---  Cleaning apr
---  Computing dependencies for apr-util
---  Fetching archive for apr-util
---  Attempting to fetch apr-util-1.5.2_1.darwin_12.x86_64.tbz2 from  
http://lil.fr.packages.macports.org/apr-util
---  Attempting to fetch apr-util-1.5.2_1.darwin_12.x86_64.tbz2.rmd160  
from http://lil.fr.packages.macports.org/apr-util

---  Installing apr-util @1.5.2_1
---  Cleaning apr-util
---  Computing dependencies for apr-util
---  Deactivating apr-util @1.5.1_0
---  Cleaning apr-util
---  Activating apr-util @1.5.2_1
---  Cleaning apr-util
Error: arpack: Variant openmpi conflicts with gcc43
Error: Unable to open port: Error evaluating variants
To report a bug, follow the instructions in the guide:
http://guide.macports.org/#project.tickets


on a second machine essentially the same happens but a conflict with gcc47  
is stated instead of with gcc43. any ideas?


thanks
j.

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: `port selfupdate; port upgrade outdated' fails

[j. van den hoff]

On Wed, 14 Aug 2013 16:07:11 +0200, Brandon Allbery allber...@gmail.com  
wrote:



On Wed, Aug 14, 2013 at 7:13 AM, j. van den hoff
veedeeh...@googlemail.comwrote:


---  Cleaning apr-util
Error: arpack: Variant openmpi conflicts with gcc43
Error: Unable to open port: Error evaluating variants
To report a bug, follow the instructions in the guide:

http://guide.macports.org/#**project.ticketshttp://guide.macports.org/#project.tickets

on a second machine essentially the same happens but a conflict with  
gcc47

is stated instead of with gcc43. any ideas?



The openmpi variant used to incorrectly allow that, but openmpi is  
itself a

(wrapper around a) compiler so you must either consistently use it
everywhere or risk odd build issues due to conflicting C++ runtime  
support

libraries and such. You must determine which compiler to use yourself in
this case; it's not something ports can do for you --- although probably
manually deactivating the non-openmpi compiler via port upgrade arpack
+openmpi -gcc43 or etc. is probably the right choice in many cases.


indeed, that did the trick (it went through with the warning

Warning: Skipping upgrade since openmpi 1.7.2_0 = openmpi 1.7.2_0, even  
though installed variants +gcc43 do not match +gcc47. Use 'upgrade  
--enforce-variants' to switch to the requested variants.


which I hope is innocuous?

after this upgrade of `arpack' `upgrade outdated' no longer chokes (have  
not tried the second machine, yet).

thanks a lot for your help. I really appreciate this.

otherwise, I admit not being able to follow you completely regarding  
what's going on (I don't know anything about the affected packages arpack,  
openmpi. they are are seemingly dependencies of some stuff I have  
installed)).

but in any case everythings fine now.

thanks again.

j.





--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

duplicate listing of ports by `port list installed'

[j. van den hoff]

I have seen this already with 10.6 and currently with 10.8:

`port list installed' frequently reports several of the installed ports  
repeatedly (I see 2-4 times) on consecutive lines (including the  
`@num.num' version designation, i.e. seemingly exact duplicates). which  
ports are affected looks erratic if I compare macports installation on  
different machines. it only seems to be the case that there are more  
duplicates on older macports installations.


I have these questions:

1.
the duplicate listings do not hint at any relevant corruption of my  
macports setup, right?


2.
what is the reason for the occurrence of the duplicate listings?

3.
is there a way to get rid of the duplicates?


thanks in advance
joerg

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

Re: duplicate listing of ports by `port list installed'

[j. van den hoff]

On Wed, 19 Jun 2013 13:09:15 +0200, Brandon Allbery allber...@gmail.com  
wrote:



On Wed, Jun 19, 2013 at 6:33 AM, j. van den hoff
veedeeh...@googlemail.comwrote:


1.
the duplicate listings do not hint at any relevant corruption of my
macports setup, right?



Correct.



2.
what is the reason for the occurrence of the duplicate listings?



There is a difference between installed and active. At most one
installed version of a port will be active; the others are archived. You
might want to activate an older version if there turns out to be a
compatibility issue with the new version of a port, for example.



thank you very much for responding.
I knew of the difference between installed and active but did not
think of it as the reason of the (apparent) problem.



3.

is there a way to get rid of the duplicates?



sudo port uninstall inactive



yes, obvious in retrospect... thanks again.

basically, my error was to use `port list installed' instead
of `port installed'. the confusing thing is that `port list installed'
shows something like this:


...
cmake  @2.8.10.2   devel/cmake
cmake  @2.8.10.2   devel/cmake
...

`list' (after reading the manpage again it's clear...) always reports
the latest version, so in combination with the pseudo-portname installed  
the

above output resulted, while `port installed' yields.

cmake @2.8.10_1
cmake @2.8.10.2_0 (active)

which is the actually relevant information. one modest proposal for
a fix would be that `port list portname(s)' does something like `uniq(1)'
on its input list of portnames before reporting (Tcl sure has something  
like `uniq' included,

I presume).


regards,
joerg

If you're certain that you'll never need to use the old version of a  
port,

you can pass the -u option when upgrading ports to uninstall the old
version instead of inactivating it.






--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users

`uzbl' crashes Apple's X11 (but not current Xquartz)

[j. van den hoff]

has someone experience with the `uzbl' web browser (under macos 10.6.8  
with uzbl @2011.11.28) using Apple's X11?


I installed uzbl yesterday on two machines both running 10.6.8 but one  
using Apple's X11, the other one using Xquartz. on the latter everything  
is fine, on the former I get reproducible X11 crashes (SIGSEV exception)  
when trying to use the `fl' command (intended to enumerate all links on  
the visited webpage): when trying to type in the `fl' command the `l'  
never is echoed in the bottom left CMD window, but instead X11 crashes.


can someone confirm this behaviour?
is this an upstream (uzbl or X11) issue or could it be patched in the  
macports package?


any feedback appreciated,

joerg


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

unison 2.40.63: `unison -doc all' does not show documentation

[j. van den hoff]

after upgrading `unison -doc all' and `unison -doc topics' both show an  
empty string instead of the complete manual or list of topics,  
respectively, as these commands should (and did, at least with version  
2.32).


I'm guessing: the manual is in a different text file (and not linked into  
the executable) and is not found in the expected location: could this be  
the reason? I see that the package has no maintainer, but maybe someone  
knows the answer (or where to look in the /opt/local tree).


thanks
joerg

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

`hg' (mercurial) does not find `hgsubversion' extension in default search path

[j. van den hoff]

hi,

this seems either a problem of the  `hg' or the `hgsubversion' package  
(probably the latter):


after upgrading to hg 2.0, `hg' does no longer find the `hgsubversion'  
extension in its search path, i.e. the entry

`hgsubversion=' (without explicit path) does no longer work in `.hgrc'.

the reason might be that `hg' now seems to use python2.7. at least this is  
my assumption since in the

`hg' executable defines a libpath of

'../lib/python2.7/site-packages'

(don't know relative to what...)

but `hgsubversion' is a python2.6 package and installed in

/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages.


I believe either `hgsubversion' should be made a python2.7 package (if  
this does not cause compatibility issues) or the `hg' searchpath would  
need to include the location of `hgsubversion' (which then probably would  
have to live in a separate directory, rather than in the 2.6 site-packages  
directory).



joerg





--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

ksh93 problem

[j. van den hoff]

hi,

not so much a macports question, but probably a ksh93 bug (or so I do  
believe), which I don't know where to report:


short version:
==
the `read' built-in is supposed to read a single input line (up to a  
linefeed). it does'nt work correctly with very long input lines but rather  
returns a truncated string of length 253952 without any notification  
(e.g., via return status).



long version:
=
try this:

1. generate a file `longline.txt' containing some very long string,  e.g.  
with:


=CUT=
#!/bin/ksh

if (($# == 0)); then
   imax=262144
else
   imax=$1
fi

print just a moment...
for ((i=1;i$imax;i++)); do buf=${buf}.; done
buf=${buf}+

print $buf  longline.txt
=CUT=

which generates a file with a single line of 262143 repeated `.'  
characters plus a single `+' (and a \n).


at this point, `wc longline.txt' yields 262145 chars (due to trailing \n).

now, in `ksh' from the command line, do

read a  longline.txt
echo $?   ### yields `0', i.e. no error
echo ${#a}### yields a string length of 253952
echo $a   ### shows the truncation

253952 thus is the length of the returned truncated string for an actual  
line length = 262144 (plus \n). to make it a bit more confusing,  
shortening the line by a single character to a length of 262143 (plus \n)  
leads to correct reading and


echo ${#a}   ###yields string length 2621413

now, 2621414-253952=8192, so it seems that the input buffer length is 8192  
bytes and if the line length does not exceed the sum of 253952 plus buffer  
length, the reading still works as expected.


I've seen this with Version JM 93t+ 2010-06-21 under MacOS as well as  
ubuntu. I find this behavior nowhere documented and presume it's a bug.


I would appreciate any feedback whether this behaviour is known (did'nt  
find anything on the net), whether it's really a bug (or I am making some  
stupid error), and where to report this (sending mail david korn directly  
or what??) so that it can get fixed.



thanks,

joerg

ps: in `bash' and `zsh' everything just works as expected.




--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

Re: ksh93 problem

[j. van den hoff]

On Tue, 22 Nov 2011 13:53:46 +0100, Ryan Schmidt ryandes...@macports.org  
wrote:



On Nov 22, 2011, at 05:49, j. van den hoff wrote:

not so much a macports question, but probably a ksh93 bug (or so I do  
believe), which I don't know where to report:


I would appreciate any feedback whether this behaviour is known (did'nt  
find anything on the net), whether it's really a bug (or I am making  
some stupid error), and where to report this (sending mail david korn  
directly or what??) so that it can get fixed.




thanks a lot for the quick reply.

The correct place to discuss ast-ksh is probably on the ast-users  
mailing list:


https://mailman.research.att.com/mailman/listinfo/ast-users


ah yes, I see. I'll try that.



I've updated ksh93 to the latest version of ast-ksh; please update and  
see if that resolves the issue.


unfortunately, no: same behavior as before. I'll contact the ast-users  
list. if anything relevant comes up, I'll let you know.



joerg



https://trac.macports.org/ticket/30198





--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

dblatex problem

[j. van den hoff]

hi,

I'm using dblatex as backend to asciidoc for pdf production. I noticed  
massive latency
(e.g. for a one-page document real time 17 sec,  system+user) 3 sec.) when  
doing
this. I don't know anything about docbook/xml stuff but after quite some  
searching found out that
the problem is related to xsltproc (called by dblatex) looking up xml  
catalogs
on the net instead of doing this locally. This occurs when the environment  
variable

SGML_CATALOG_FILES is not pointing to the local xml-catalog directory. but
in the main `dblatex' python script I find this:

===CUT===
cat = os.environ.get(SGML_CATALOG_FILES)
if cat:
cat += :=/opt/local/etc/xml/catalog
else:
cat = =/opt/local/etc/xml/catalog
os.environ[SGML_CATALOG_FILES] = cat
===CUT===

which seemingly _does_ set the environment variable to point to the
correct directory, one should think. this
does not have any effect, however, i.e. xsltproc takes massive time
waiting for the net. on the other hand, if I export the variable myself in  
the shell with


export SGML_CATALOG_FILES=/opt/local/etc/xml/catalog

xsltproc indeed stops assessing the network and pdf production (for small
documents) speeds up by a factor of 5-6 or so.

questions:

* is this a macports problem or not (probably not...)?
* is it a dblatex bug (my guess)?
* is it a xsltproc bug?
* whom to notify?

thanks
joerg





--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users