| Age | Commit message (Collapse) | Author |
|---|
|
time, though retrying succeeded.
May have only been a problem on debian stable, the /var/lib/tor/keys/ was
not created by installing the package.
|
|
propellor-config binary and not all the libraries.
This is a super speedup!
|
|
Got lost in recent changes and broke the cron job.
|
|
|
|
The freebsd changes caused a bootstrap of a system with no declared OS to
not work, where before it was assumed to be some debian-like system where
apt can be used. Brought back this assumption.
|
|
|
|
|
|
|
|
|
|
|
|
better than symlinks because this way no conflict can ever occur
and, commit from hook
|
|
|
|
We were using checkResult instead of check, and we weren't parsing the
output of `jail -l -q` properly. Now it handles respins perfectly.
|
|
|
|
|
|
|
|
|
|
where blocks involve lest nesting than let in, and are more idiomatic
in propellor properties
|
|
|
|
Made some code a little faster..
|
|
for some reason I asked the author to put the copyright in there, but
Propellor doesn't do per-file copyrights; it's all BSD. Also, make the
maintainer show up in haddock.
|
|
This is so, when a user adds a new OS, ghc tells them everywhere they
need to look to add it.
Also, avoid throwing error from pure function..
|
|
Rather than having the property fail when the Host has no OS defined,
I made bootstrapPropellorCommand not install deps in this situation.
The cron job will (probably) still work, unless a system upgrade causes
deps to be removed.
|
|
|
|
|
|
|
|
|
|
The freebsd branch made it run ./propellor --check after verifying
that command fails, which is clearly wrong.
|
|
|
|
My policy for config.hs is it shouldn't need to load any modules other than
propellor and the desired property modules.
|
|
|
|
(cherry picked from commit df40046fd65bc07eced41adb73c7e227d2b54cd1)
|
|
(cherry picked from commit 0207c5ab585f41877c1b9f9674a25941cffd2ac7)
|
|
(cherry picked from commit c3a23f89092d1ef8367c37ab8993ea7031124f4b)
|
|
- Propellor bootstrapping
- Basic pkg
- Basic ZFS datasets and properties
- Simple Poudriere configuration (regular and ZFS)
- Poudriere jail creation
FIXME:
- Cron.hs: runPropellor needs the System, but hasn't yet gotten it.
Reorganizing:
- Remove FreeBSD.Process
- Move ZFS up to Property
- Add Info for Pkg.update/Pkg.upgrade
- Move FreeBSD.md to doc so it'll show up automatically.
- Merge the FreeBSD config with the other sample config.
- Use Info to check Pkg updated/upgraded and Poudriere configured.
- Warnings clean-up, move ZFS types to Propellor.Types.
- Maintainer and license statements.
|
|
|
|
|
|
(cherry picked from commit 125135ea5d42d623346a385faf7ed404f8878891)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When spinning a remote host, we do want to rebuild propellor on it,
and this use of --continue that did a rebuild was different from all the
other uses of --continue that avoided a rebuild.
This fixes a build loop involving that special case. When --continue
SimpleRun ran a rebuild, it re-execed propellor with --continue SimpleRun,
and so would rebuild again, and re-exec again if the binary kept changing.
Backwards compatability should be ok; old versions of propellor,
when run with --serialized SimpleRun by the new version, do a buildFirst,
followed by another (redundant) buildFirst, and then run. The one redundant
buildFirst is not a problem in the upgrade scenario.
(Unfortunately, I can't rename SimpleRun to something nicer despite only
spin using it; backwards compatability does prevent that.)
|
|
|
