summaryrefslogtreecommitdiff
path: root/doc/todo/depend_on_concurrent-output.mdwn
blob: c442c977b9f38cf7937830b46ddcd40a4b5e38d1 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
Currently a module from concurrent-output is inlined into propellor. This
should be converted to a dependency.

Waiting on concurrent-output reaching Debian stable.

> Well, it's in stable now. Not in oldstable yet, and propellor is still
> supporting the current oldstable, I believe.. --[[Joey]]

[[!tag user/joey]]

> This was attempted again in 2018 and had to be reverted
> in [[!commit b6ac64737b59e74d4aa2d889690e8fab3772d2c6]].
> 
> The strange output I was seeing is the first line 
> of "apt-cache policy apache2" (but not subsequent lines)
> and the ssh-keygen command run by `genSSHFP'`

> Propellor also misbehaved in some other ways likely due to not seeing
> the command output it expected. In particular Git.cloned must have
> failed to see an origin url in git config output, because it nuked and
> re-cloned a git repo (losing data).
> 
> So, it seems that readProcess was somehow leaking output to the console
> and also likely not providing it to the caller. 
> 
> The affected system had libghc-concurrent-output-dev 1.10.5-1 installed
> 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]]

> > > > Unforunately, the embedded concurrent-output copy had to be
> > > > downgraded again, because it turns out the new version
> > > > of concurrent-output depends on process-1.6, while propellor
> > > > neeeds to also work with older versions.
> > > >
> > > > So, propellor will embed the old concurrent-output until
> > > > process-1.6 is in debian oldstable, and then revert
> > > > [[!commit ]] and version propellor's dep on process,
> > > > and then, finally, once concurrent-output 1.10.12 is in oldstable
> > > > propellor can stop embedding it. --[[Joey]]