| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
My first try with a pipe was the right approach, and was almost right,
except I forgot to close the write end of the pipe, and so it was inherited
by the forked process, leading to deadlock.
|
|
With some small changes, and debugging.
|
|
This reverts commit 632137836b39462883483a621f9dd696ce1d73cc.
Still failing :( Seems that disabling buffering is not the solution.
|
|
The "fatal: Couldn't find remote ref HEAD" persists, and is intermittent
so hard to be sure but it seemed that disabling buffering earlier
avoided it. Now done first thing on start.
I was not able to find anything that reads from stdin other than
getMarked, but perhaps there is something..
|
|
* Hosts can be configured to build propellor using stack, by adding
a property:
& bootstrapWith (Robustly Stack)
* Hosts can be configured to build propellor using cabal, but using
only packages installed from the operating system. This
will work on eg Debian:
& bootstrapWith OSOnly
propellor build its config using stack. (This does not affect
how propellor is bootstrapped on a host by "propellor --spin host".)
This has not yet been tested at all! But should probably work fine.
This is based on earlier work by Arnaud Bailly, who made
Propellor.Bootstrap use stack without parameterization.
In Arnaud's patch, stack was installed using wget, but that
only worked on linux-x86_64 and was insecure. I instead chose
to use the distribution packages of stack, like is done for cabal.
Debian stack has haskell-stack now, and it's getting into many
distributions.
This commit was sponsored by Francois Marier on Patreon.
|
|
|
|
|
|
|
|
|
|
This commit was sponsored by Trenton Cronholm on Patreon.
|
|
|
|
Properties that used to need it as a parameter now look at Info about the
bootloader that is installed in the chroot that the disk image is created
from. (API change)
This is a simplication, and avoids the user needing to repeat themselves
in the propellor config, thus avoiding mistakes.
When no boot loader is installed, or multiple different ones are,
disk image creation will fail, which seems reasonable.
This commit was sponsored by Jake Vosloo on Patreon.
|
|
* DiskImage.grubBooted no longer takes a BIOS parameter,
and no longer implicitly adds Grub.installed to the properties of
the disk image. If you used DiskImage.grubBooted, you'll need to update
your propellor configuration, removing the BIOS parameter from
grubBooted and adding a Grub.installed property to the disk image, eg:
& Grub.installed PC
(API change)
* Grub.installed: Avoid running update-grub when used in a chroot, since
it will get confused.
* DiskImage.Finalization: Simplified this type since it does not need to
be used to install packages anymore. (API change)
The advantage of doing this comes when using hostChroot with
imageBuilt, since the Host then has its Grub.installed property
explicitly listed so propellor knows about it when otherwise deploying that
host. Also, it simplifies the quite complex imageBuilt parameters.
This commit was sponsored by Ewen McNeill.
|
|
|
|
This commit was sponsored by Ethan Aubin.
|
|
destination file did not yet exist.
This commit was sponsored by andrea rota.
|
|
|
|
|
|
f' normally means a later version of f
|
|
|
|
|
|
* Propellor.Property.XFCE added with some useful properties for the
desktop environment.
* Added File.applyPath property.
This commit was sponsored by Riku Voipio.
|
|
(minor API change as the type changed)
|
|
When provisioning a container, output was buffered until the whole process
was done; now output will be displayed immediately.
I know this didn't used to be a problem. I belive it was introduced by
accident when propellor started using concurrent-output. I know I've seen
it for a while and never was bothered enough to get to the bottom of it;
apparently "a while" was longer than I thought.
Also refactored code to do with chain provisioning to all be in
Propellor.Engine and avoided some duplication.
This commit was sponsored by Anthony DeRobertis on Patreon.
|
|
This reverts commit c59ce983999ddbfe6cb8b27e4f376b5c37d7f853.
That was wrong because only the *last* line of chain output is a Result.
It could be that a previous line is able to be read as a Result, and
the commit would make processing bail out at that point.
|
|
|
|
Avoid needing to wait for a subsequent line before displaying the
previous line.
|
|
This way, when a disk image is built using this property, and booted up,
running propellor won't try to ensure this property again.
This commit was sponsored by Jeff Goeke-Smith on Patreon.
|
|
from the bootstrapped config the first time.
When the config changes, the bootstrapped propellor needs to get rebuilt.
This commit was sponsored by Fernando Jimenez on Patreon.
|
|
Since some programs (such as VBoxManage convertdd) refuse to operate on
disk images not aligned to a sector size.
This commit was sponsored by Boyd Stephen Smith Jr. on Patreon.
|
|
|
|
I have a cron job updating a file in there..
|
|
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
It turns out that IncludeOptional will error out if it is passed non-wildcard
directories that do not exist.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
So if the insecure password is later changed, the new password won't be
exposed.
|
|
Not sure what the problem was, but it hung. Also though, I noticed that
stdin was still open when git fetch was run, so if git fetch itself
decided to read from stdin, it would mess up the protocol forwarding.
While git fetch should never read from stdin, that was reason enough to
fall back to plan B.
|
|
ref HEAD"
Tricky stdin buffering problem.
An easier fix would have been:
hSetBuffering stdin NoBuffering
But that approach is less robust; even with NoBuffering, anything that
uses hLookAhead causes 1 byte of buffering. And, any reads from stdin
before hSetBuffering would still cause the problem. Instead, I used a
bigger hammer that will always work. It involves a bit more CPU work,
but this is data that is already being fed through ssh; copying it one
more time won't cause a measurable performance impact.
This commit was sponsored by Jack Hill on Patreon.
|
|
This is using ByteString, so the handle IO discipline is irrelevant.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
