On 05.05.2015 10:09 AM, René J.V. Bertin wrote:
> I'd launched a `port upgrade outdated` on Bradley's VM late yesterday,
> connected over SSH, and pushed the process to the background when I had to
> call it a night. I left the SSH connection open but suspended my own machine.
> Just now I connected from another machine, noticed the upgrade hadn't
> completed and then saw this in `port log kdelibs4`
>
> {{{
> ---> Computing dependencies for kdelibs4:info:install .:debug:install error
> flushing "stdout": I/O error
> Error: Couldn't activate kdelibs4
> 4.14.7.16_150501_0+docs+nativefiledialogs+nostrip+osxkeychain: error flushing
> "stdout": I/O error
> Error: Follow http://guide.macports.org/#project.tickets to report a bug.
> DEBUG: Checking last run information.
> }}}
>
> apart from the weird fact that this apparently is the whole log, I wonder if
> there would be a way to avoid the abort on the flush error. It's not the
> first time I run into something like this, and it's rather annoying (the
> upgrade should have finished by now if it weren't for that otherwise trivial
> flush error).The error isn't weird. The terminal STDOUT/STDERR/STDIN were connected to all of a sudden vanished. What's weird about erroring out in such a case, especially if the kernel is telling your application that it couldn't handle a write operation on some specific FD? If you want to be able to "call it a night", start port like any other process on UNIX-like operating systems -- within tmux or screen, so that the file descriptors do not simply vanish and the user can detach or reattch at will. Mihai
signature.asc
Description: OpenPGP digital signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
