[[!comment format=mdwn
 username="joey"
 subject="""comment 4"""
 date="2020-08-14T17:06:46Z"
 content="""
So the relevant change in that commit, I think, is that
waitForProcessConcurrent used to do its own locking,
and would sometimes not even call waitForProcess, but instead
waitAny. And now it just calls waitForProcess.

That change comes from concurrent-output commit 
1c330fa3814baadf23c1934a8014c91a3251234a
Which removed a workaround for
https://github.com/haskell/process/issues/46 and added
a depend on `process (>= 1.6)` which fixed its bug.

Propellor does not depend on any particular version of process,
so it's exposed to the old bug.

But, David, is your system really using an older version of process to
build propellor?
(Bearing in mind that the system might ship with a newer version but cabal
may have chosen to use an older version for whatever reason.)
Probably the easiest way to check is, edit propellor.cabal,
make it depend on `process (>= 1.6)`, and rebuild and see if you still have
the problem.

Anyway, we can either revert 1c330fa3814baadf23c1934a8014c91a3251234a in
propellor, or revert the whole 162e1d4e82e24f0fe3e2bd3114e4366ddb1062c0
but I'd really rather not do that because it's been stuck on the old
version of concurrent-output forever. 

Or, it propellor could depend on the fixed process. process-1.6
was bundled with ghc-8.2.2. That works back to debian stable, but not
oldstable, which is still a supported target of propellor.

I guess, if we can confirm the old version of process is really the issue,
I'm leaning toward reverting 1c330fa3814baadf23c1934a8014c91a3251234a,
until the far-future time when we emerge blinking from the oldstable stasis
chamber and propellor can finally depend on concurrent-output rather than
bundling it.
"""]]
