| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
It could result in sometimes quite wrong values, eg "1.1 GB" when the input
value was a few bytes less than 2 GB.
Properties in Ccache and Journald that used it to generate config files
were affected by this bug.
|
| |
|
|
|
|
|
|
|
|
| |
Fixes display of concurrent output from processes when using
Propellor.Property.Conductor. (Reversion introduced in version 5.5.0.)
Utility.Process.Shim's whole point is to let propellor differ from
git-annex here, but I forgot and copied over git-annex's version.
|
|
|
|
| |
Last done in May 2017..
|
|
|
|
|
|
|
|
| |
ghc warned that the guard did not cover all values of h, but they
clearly do, and when rewritten as a case statement the warning goes away
Probably a ghc bug, but I kind of prefer the case statement over the
guards anyway.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MissingH is a heavy dependency, which pulls in parsec and a bunch of stuff.
So eliminating it makes propellor easier to install and less likely to
fail to build.
changesFileContent now uses hashable's hash. This may not be stable across
upgrades, I'm not sure -- but it's surely ok here, as the hash is not
stored.
socketFile also uses hash. I *think* this is ok, even if it's not stable.
If it's not stable, an upgrade might make propellor hash a hostname to a
different number, but with 9 digets of number in use, the chances of a
collision are small. In any case, I've opned a bug report asking for the
stability to be documented, and I think it's intended to be stable, only
the documentation is bad.
NB: I have not checked that the arch linux and freebsd packages for the new
deps, that Propellor.Bootstrap lists, are the right names or even exist.
Since propellor depends on hashable, it could be changed to use
unordered-containers, rather than containers, which would be faster and
perhaps less deps too.
This commit was sponsored by Alexander Thompson on Patreon.
|
|
|
|
| |
encoding-related crashes in eg, Propellor.Property.File.
|
|
|
|
|
|
| |
This new type was added to base a while ago; I don't know what uses it,
but it's intended to be an async exception, so make sure we
don't catch it.
|
|
|
|
| |
lines, or a ByteString.
|
|
|
|
| |
https://propellor.branchable.com/todo/bytes_in_privData__63__/
|
|
|
|
|
|
|
| |
Sadly my bug report about this is not going to get fixed it seems, so
I have to drag around a whole added module file just to deal with it.
https://github.com/haskell/directory/issues/52
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's now exporting a conflicting isSymbolicLink
https://github.com/haskell/directory/issues/52
Only a few places in propellor use isSymbolicLink, but to prevent future
problems, made as much of it as possible import Utility.Directory, which
re-exports System.Directory without the conflicting symbol.
(Utility.Tmp and System.Console.Concurrent.Internal cannot import
Utility.Directory due to cycles, and don't use isSymbolicLink anyway.)
|
| |
|
|
|
|
|
|
|
|
| |
Before, they could run in the background if another process was running,
and so their output wouldn't immediately be visible.
With this change, the concurrent-output layer is not used for these
interactive commands.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
withTmpDir security fix in git-annex merged
Fix potential denial of service attack when creating temp dirs.
withTmpDir now makes directory mode 700. AFAICS, propellor didn't leak any
info with the old permissions, and no uses of withTmpDir in propellor are
broken by the new permissions.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This adds a dependency on Text, but I don't mind propellor depending on it
and am somewhat surprised it doesn't already.
Using Text also lets this use encodeUtf8 instead of the nasty hack it was
using to go from String -> ByteString.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
threads on shutdown
|
| |
|
| |
|
|
|
|
| |
Build it up reversed, and reverse when processing.
|
|
|
|
| |
https://github.com/haskell/process/issues/46
|
|
|
|
|
|
|
|
|
| |
Race between 2 calls to takeOutputLock'. The first call empties the
TMVar, and does some work to check it. Meanwhile, the second call could
sneak in, see it was empty, and call waitlock. Since waitlock used
tryTakeTMVar, that would not block it, and it would think it had the lock,
filling the TMVar. In the meantime, the first call could decide it had to
lock and go on to possibly cause trouble.
|
|
|
|
|
|
|
|
| |
I had 2 MVars both involved in the same lock, and it seemed intractable to
avoid deadlocks with them. STM makes it easy.
At this point, the concurrent process stuff seems to work pretty well, but
I'm not 100% sure it's not got some bugs.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This interface will fix the current deadlock when a process is running
and the thread that ran it wants to output to the console.
The locking and buffering is not implemented yet.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Found a reasonable clean way to make Utility.Process use
execProcessConcurrent, while still allowing copying updates to it from
git-annex.
|
| |
|