summaryrefslogtreecommitdiff
path: root/doc/todo/depend_on_concurrent-output.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo/depend_on_concurrent-output.mdwn')
-rw-r--r--doc/todo/depend_on_concurrent-output.mdwn23
1 files changed, 23 insertions, 0 deletions
diff --git a/doc/todo/depend_on_concurrent-output.mdwn b/doc/todo/depend_on_concurrent-output.mdwn
index c3641385..48dd829e 100644
--- a/doc/todo/depend_on_concurrent-output.mdwn
+++ b/doc/todo/depend_on_concurrent-output.mdwn
@@ -27,3 +27,26 @@ Waiting on concurrent-output reaching Debian stable.
> from debian. That is a somewhat old version and perhaps it was buggy?
> However, I have not had any luck reproducing the problem there running
> readProcess in ghci. --[[Joey]]
+>
+> > Tried again in 2020, same bugs still happened. On a system running
+> > debian unstable with concurrent-output 1.10.9, and a system running stable that
+> > had cabal installed concurrent-output 1.10.11.
+> >
+> > The former system (kite) had the strange output problem.
+> >
+> > The latter system (keysafe) seemed ok but crashed at the end with
+> > a STM transaction deadlock. Seemed to only happen when spinning the
+> > host remotely, or not always; I tried to reproduce it running propellor
+> > manually to bisect concurrent-output but without success.
+> >
+> > This is really looking like a reversion, or several, in newer
+> > versions of concurrent-output. The code bundled with propellor is
+> > the same as concurrent-output 1.7.4.
+
+> > > I think I've fixed it, concurrent-output (>= 1.10.12 || <= 1.7.4)
+> > > will be needed to avoid the bug. Will be several years until that's
+> > > in debian stable..
+> > >
+> > > I've updated the embedded concurrent-output copy, and it should
+> > > be kept up-to-date as concurrent-output changes, to avoid more
+> > > such reversions. --[[Joey]]