Portupgrade at openoffice.org gets as far as backing up
the previous version, then hangs, executing what it says
is the installer. soffice.bin is spinning, using
100-epsilon CPU. I kill -QUIT'ed that process, and
portupgrade /ignored/ the error, and proceeded with the
installation. I now have an openoffice installation
that produces the attached popup window. This is
actually a retrograde step from the failure that
happened at that point two weeks ago, because then it
backed the new version out, and restored 1.0.2.
Fix: Don't know how to fix. In fact, given the lack of noise
on the mailing lists about this problem, the fault is
almost certainly something to do with the setup of my
system. Hints about how to detect the fault would be
appreciated. I have both native java-1.3.1p8_1 and
jdk-1.4.1p3_3 installed, if that makes any difference.
How-To-Repeat: Have openoffice.org-1.0.2 installed, and use portupgrade
to install current port version.
Over to maintainers
The problem is that our openoffice install assumes that
no previous version is installed at the same location. If thats
the case, it will just hang.
So please move the old openoffice dir to a backup location,
then try again and report your success.
I've just tried installing openoffice again, and it stalled again
(several times), and it has finally failed in the same way that I
described before. I made certain that all traces of openoffice
had been removed from my system before starting the build process.
The screen image that I attached to my previous report was what
happened when I tried to start openoffice after the installation
process finished. However, the installation process did not get
to "finished" without intervention from me:
In several places during the build, saxparser stalled, and I
killed that process and restarted the make (without first cleaning
everything up) and it continued. saxparser had been busy building
what looked like i18n modules for languages/locales that I don't
care about, so I was not concerned if they were corrupted.
At the end, when the make install process (i.e., top-level BSD
port make) said:
===> Installing for openoffice-1.0.3_2
Initializing installation program..........
*** Error code 255 (ignored)
===> Generating temporary packing list
===> Add wrapper scripts
===> Registering installation for openoffice-1.0.3_2
===> SECURITY REPORT:
That Error code 255 (ignored) was me killing the soffice.bin
executable, because it had been consuming 90+% of the CPU for the
whole night, and that seemed unreasonable.
These problems (and the others that I'm experiencing with sawfish)
seem to me to be consistent with deadlock conditions in
multi-threaded applications that are making unwarrented
assumptions about the thread implementation, or perhaps bugs in
the thread implementation.
I'm thinking of upgrading to 5.x, just to get kernel-based
threads, to be more like Linux and Solaris, where these
applications are presumably more tested. Is that a reasonable
If this is still a problem with the latest (3.23.58) one, please
resubmit the problem. Most likely it was caused by the not running
of ldconfig by the port. If it still occures, please add the output
of "ldconfig -r" to the PR.
euhmm.. I'll redit this PR.
Fix synopsesFix synopsesFix synopses
ports/61760 describes the same issue, no need to keep both PRs.