summaryrefslogtreecommitdiff
path: root/doc/todo
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo')
-rw-r--r--doc/todo/Add_MonadBaseControl_instance_to_Propellor.mdwn3
-rw-r--r--doc/todo/Add_MonadBaseControl_instance_to_Propellor/comment_1_4b0cd7acc6442210a80c547981b5ae45._comment18
-rw-r--r--doc/todo/Add_MonadBaseControl_instance_to_Propellor/comment_2_60d6e06ebada37648df77442733e325f._comment24
-rw-r--r--doc/todo/Add_MonadBaseControl_instance_to_Propellor/comment_3_45413e6e811c34edc38a6ff70ca7c208._comment50
-rw-r--r--doc/todo/Arch_Linux_Port.mdwn16
-rw-r--r--doc/todo/Arch_Linux_Port/comment_1_8e39dc177e21e9e20c1b74b59b9926d2._comment28
-rw-r--r--doc/todo/Arch_Linux_Port/comment_2_cc4623c156a0d12c88461bc5deec07cd._comment18
-rw-r--r--doc/todo/Arch_Linux_Port/comment_3_d917de766dfe7fded7317d7614d1467f._comment25
-rw-r--r--doc/todo/Arch_Linux_Port/comment_4_924c73c0ab6fb39c9b25ae51facf6bb6._comment8
-rw-r--r--doc/todo/Are_--check_and_--build_on_the_way_in_or_on_the_way_out__63__.mdwn3
-rw-r--r--doc/todo/Are_--check_and_--build_on_the_way_in_or_on_the_way_out__63__/comment_1_7c2b2447254ad44ee1316b47eac130df._comment12
-rw-r--r--doc/todo/Are_--check_and_--build_on_the_way_in_or_on_the_way_out__63__/comment_2_b4910f50225a8b763566126861faea11._comment8
-rw-r--r--doc/todo/Info_property_to_select_host__39__s_preferred_Apt_mirror.mdwn5
-rw-r--r--doc/todo/Info_property_to_select_host__39__s_preferred_Apt_mirror/comment_1_ac66a33d71092261a745378c82959e69._comment7
-rw-r--r--doc/todo/Info_property_to_select_host__39__s_preferred_Apt_mirror/comment_2_2c2c4817a4259acbc1a63bac2e3fb2e3._comment8
-rw-r--r--doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal.mdwn7
-rw-r--r--doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_1_74c6576b25f74c6e620eb015af8b0f6a._comment26
-rw-r--r--doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_2_d63d84b56ece233f795d1075aaba887a._comment18
-rw-r--r--doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_3_1405e20c8f5dc6e9cca3732e3e368d03._comment25
-rw-r--r--doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_4_20c6734d67fefeb1a8c07730d537e06b._comment8
-rw-r--r--doc/todo/Merging_from___47__usr__47__src__47__propellor_broken_now_CHANGELOG_not_a_symlink.mdwn36
-rw-r--r--doc/todo/Merging_from___47__usr__47__src__47__propellor_broken_now_CHANGELOG_not_a_symlink/comment_1_62b47d7c0530c2988b7e6e998878b920._comment11
-rw-r--r--doc/todo/Merging_from___47__usr__47__src__47__propellor_broken_now_CHANGELOG_not_a_symlink/comment_2_61463030200038542d293149754d36ed._comment8
-rw-r--r--doc/todo/PROPELLOR_TRACE_propigation.mdwn6
-rw-r--r--doc/todo/Propellor.Property.Versioned_support_asymmetric_RevertableProperty_types.mdwn7
-rw-r--r--doc/todo/bug_in_diskimage_finalization.mdwn13
-rw-r--r--doc/todo/differential_update_via_RevertableProperty.mdwn146
-rw-r--r--doc/todo/hostChroot.mdwn9
-rw-r--r--doc/todo/initial_spin_compile_failure_recovery.mdwn5
-rw-r--r--doc/todo/merge_request:_Timezone.hs.mdwn9
-rw-r--r--doc/todo/merge_request:_Timezone.hs/comment_1_9cfb5e48940e58f2064cbb5edf462c06._comment15
-rw-r--r--doc/todo/modify_Apt.pinnedTo_to_pin_a_package_to_multiple_suites_with_different_priorities.mdwn7
-rw-r--r--doc/todo/new_apt_pinning_properties.mdwn10
-rw-r--r--doc/todo/new_apt_pinning_properties/comment_1_fd9e6775868eaa8d6aee49d06944ef0c._comment38
-rw-r--r--doc/todo/new_apt_pinning_properties/comment_2_c82f7e83f3fcc7648222d9dbf90e5ddd._comment66
-rw-r--r--doc/todo/new_apt_pinning_properties/comment_3_58d323602f293471ce3d2d9b4d271130._comment23
-rw-r--r--doc/todo/new_apt_pinning_properties/comment_4_add83ed58963e944ccd705a50e8b5a47._comment20
-rw-r--r--doc/todo/property_to_install_propellor.mdwn16
-rw-r--r--doc/todo/property_to_install_propellor/comment_1_b05e9a44e5c7130d9cc928223cd82d78._comment16
-rw-r--r--doc/todo/property_to_install_propellor/comment_2_9fea601af57777e1cb49952483f4da63._comment7
-rw-r--r--doc/todo/sbuild_setup_should_use_apt-cacher-ng.mdwn22
-rw-r--r--doc/todo/spin_failure_HEAD.mdwn130
-rw-r--r--doc/todo/unpropelling_a_host.mdwn9
-rw-r--r--doc/todo/usage__47__help_text_improvements.mdwn3
-rw-r--r--doc/todo/usage__47__help_text_improvements/comment_1_66878945cdb57d06849337262d939701._comment13
-rw-r--r--doc/todo/usage__47__help_text_improvements/comment_2_d531a45851cdef87a8f7b8182b3d04ce._comment12
-rw-r--r--doc/todo/use_stack_for_remote_building_propellor.mdwn13
47 files changed, 987 insertions, 0 deletions
diff --git a/doc/todo/Add_MonadBaseControl_instance_to_Propellor.mdwn b/doc/todo/Add_MonadBaseControl_instance_to_Propellor.mdwn
new file mode 100644
index 00000000..e044e4d9
--- /dev/null
+++ b/doc/todo/Add_MonadBaseControl_instance_to_Propellor.mdwn
@@ -0,0 +1,3 @@
+I had a specific use-case that ensures a property while using a Consul session via the [consul-haskell package](https://hackage.haskell.org/package/consul-haskell-0.4/docs/Network-Consul.html#v:withSession); in order to make it type check a MonadBaseControl IO instance is needed, so I added one. Hopefully this is generally useful, so I don't need to maintain a forked version of propellor!
+
+Patch is located in the `MonadBaseControl` branch of my cloned git repo `git clone git@github.com:hellertime/propellor.git`
diff --git a/doc/todo/Add_MonadBaseControl_instance_to_Propellor/comment_1_4b0cd7acc6442210a80c547981b5ae45._comment b/doc/todo/Add_MonadBaseControl_instance_to_Propellor/comment_1_4b0cd7acc6442210a80c547981b5ae45._comment
new file mode 100644
index 00000000..b38a015f
--- /dev/null
+++ b/doc/todo/Add_MonadBaseControl_instance_to_Propellor/comment_1_4b0cd7acc6442210a80c547981b5ae45._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-30T21:07:26Z"
+ content="""
+I'm not entirely opposed to it, but this does add another two
+dependencies that have to be installed on every host managed by propellor.
+
+Also, I don't really understand the instance MonadBaseControl
+implementation. (And have always had that difficulty with
+monad-control, which is one of the reasons I've stopped using it.)
+This and not having anything to test it with makes me fear maintaining it.
+
+It looks like it would be sufficient make Propellor derive MonadBase IO,
+and then the MonadBaseControl instance could be shipped in another
+package (or even implemented in your config.hs). Does that sound like a
+reasonable compromise?
+"""]]
diff --git a/doc/todo/Add_MonadBaseControl_instance_to_Propellor/comment_2_60d6e06ebada37648df77442733e325f._comment b/doc/todo/Add_MonadBaseControl_instance_to_Propellor/comment_2_60d6e06ebada37648df77442733e325f._comment
new file mode 100644
index 00000000..3233340c
--- /dev/null
+++ b/doc/todo/Add_MonadBaseControl_instance_to_Propellor/comment_2_60d6e06ebada37648df77442733e325f._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="chris"
+ subject="""comment 2"""
+ date="2016-12-01T18:14:10Z"
+ content="""
+Agree on all points. I would rather not add the dependencies to propellor
+proper either, but such was the requirement for this change. I'd be happy
+enough with the MonadBase IO derivation and implementing this externally,
+no argument here.
+
+As for what it does :) I cribbed the implementation from the Snap server (
+https://github.com/snapframework/snap/blob/
+bda15d0a0f29b0107fd69fbb8b7e8cc5ce5fa7e4/src/Snap/Snaplet/Internal/Types.hs#
+L277),
+and it seems to work, essentially it is a way to take the outer
+transformer, and wrap it inside the inner Monad, but in such a way that the
+inner Monad now has access to the outer transformer !? Yeah, I'm still not
+fully grokking it myself, but it type checks and functions.
+
+Anyway feel free to implement at your leisure, it does seem that I could
+even derive the MonadBase IO instance manually and not have to change
+Propellor in the least, though the auto-derived instance would seem like a
+simple and harmless addition.
+"""]]
diff --git a/doc/todo/Add_MonadBaseControl_instance_to_Propellor/comment_3_45413e6e811c34edc38a6ff70ca7c208._comment b/doc/todo/Add_MonadBaseControl_instance_to_Propellor/comment_3_45413e6e811c34edc38a6ff70ca7c208._comment
new file mode 100644
index 00000000..74a5c8bb
--- /dev/null
+++ b/doc/todo/Add_MonadBaseControl_instance_to_Propellor/comment_3_45413e6e811c34edc38a6ff70ca7c208._comment
@@ -0,0 +1,50 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-12-01T18:14:28Z"
+ content="""
+Looking at the lifted-async that is what uses the MonadBaseControl instance
+in your use case, I have some concerns.
+
+Its docs say "All the functions restore the monadic effects in the forked
+computation unless specified otherwise." I think that has bearing on the
+following situation:
+
+Suppose that two Propellor monad actions are run concurrently by this:
+
+ foo `concurrently` bar
+
+Propellor's monad includes a Writer component, that accumulates [EndAction].
+Since they are running concurrently, it seems likely that `foo` and `bar`
+are using separate Writers. Propellor doesn't currently use a State monad,
+but suppose that was added to its stack. Then `foo` and `bar` would
+necessarily, I think, be manipulating independent copies of state.
+
+Now, what happens when `concurrently` finishes running them? We have two
+Writers and/or two States, that need to be merged somehow. I don't see
+anything in the library that lets it do an intelligent merge. (For example,
+it could notice that [EndAction] is a monoid and mappend the two values.)
+
+So, I think when it says it's a restoring the monadic effects, it means it's
+*discarding* any changes that might have been made to the Writer or State.
+
+Is this a large problem for Propellor? Maybe not. EndActions rarely need to
+be added, and in fact only one property in all of Propellor currently adds
+an EndAction. But this could change; Propellor could get state in its
+monad. What then?
+
+Now, I actually dealt with this problem in the
+Propellor.Property.Concurrent module. The code there threads the Writer
+v alues through the concurrent actions and merges them at the end. If
+MonadBaseControl provides a more principled way to do that, which lets
+lifted-async also be used safely, then that part of propellor could perhaps
+be changed to use it.
+
+But, I don't know if this is a problem that MonadBaseControl deals with at
+all. It might be that its design is intended to be used for things like
+`bracket`, where there's no concurrency, and so not as much problem with
+getting different monadic states that need to be merged together. (Although
+in `bracket foo bar baz`, if baz throws an exception part way through,
+there's an interesting question about what to do with any monadic state it
+may have accumulated.)
+"""]]
diff --git a/doc/todo/Arch_Linux_Port.mdwn b/doc/todo/Arch_Linux_Port.mdwn
new file mode 100644
index 00000000..ac3ee4dc
--- /dev/null
+++ b/doc/todo/Arch_Linux_Port.mdwn
@@ -0,0 +1,16 @@
+Hi all, I'm an Arch Linux user and I've been learning Haskell and working on an Arch Liux Port in the last several months. Here's my [GitHub fork](https://github.com/wzhd/propellor/tree/archlinux), and the branch is called archlinux.
+
+Currently, I've added types, modified Bootstrap.hs, and added a Property for the package manager Pacman. I've been using it for a while and it seems to be working.
+
+I've made some addtional minor changes to make propellor compile without errors:
+
+- User.nuked now has type Property Linux
+- OS.cleanInstallOnce now has type Property DebianLike, because one of its dependencies, User.shadowConfig only supports DebianLike
+- tightenTargets is added to Reboot.toDistroKernel to get the expeted type
+- pattern for Arch Linux is added to Debootstrap.extractSuite to silence warning "non-exhaustive pattern match"
+- several properties in Parted and Partition are converted to Property Linux
+- Rsync.installed and Docker.installed now supports Pacman as well
+
+Hope you enjoy it!
+
+> [[merged|done]]; it was indeed enjoyable. thank you! --[[Joey]]
diff --git a/doc/todo/Arch_Linux_Port/comment_1_8e39dc177e21e9e20c1b74b59b9926d2._comment b/doc/todo/Arch_Linux_Port/comment_1_8e39dc177e21e9e20c1b74b59b9926d2._comment
new file mode 100644
index 00000000..11869a2a
--- /dev/null
+++ b/doc/todo/Arch_Linux_Port/comment_1_8e39dc177e21e9e20c1b74b59b9926d2._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-03T19:14:41Z"
+ content="""
+Wow, nice work!
+
+Seems that Propellor.Property.Partition.formatted' is still a DebianLike
+property really, since it only supports using apt to install the mkfs
+programs. It will fail at runtime on Arch. So, I think best to keep it
+DebianLike until that's dealt with -- and then the type will be
+`DebianLike + ArchLinux` rather than `LinuxLike`
+
+Same for Propellor.Property.Partition.kpartx.
+
+Several properties that were changed from DebianLike to Linux really
+only support DebianLike and ArchLinux, not all linux distros, so their
+types ought to be `DebianLike + ArchLinux`. This includes Docker.installed,
+Parted.installed, Rsync.installed.
+
+A nicer way to inplement those multi-distro `installed` properties is like
+this:
+
+ installed :: Property (Debian + ArchLinux)
+ installed = Apt.installed ["foo"] `pickOS` Pacman.installed ["foo"]
+
+Make those changes and I will merge it.
+"""]]
diff --git a/doc/todo/Arch_Linux_Port/comment_2_cc4623c156a0d12c88461bc5deec07cd._comment b/doc/todo/Arch_Linux_Port/comment_2_cc4623c156a0d12c88461bc5deec07cd._comment
new file mode 100644
index 00000000..dc6e3eb1
--- /dev/null
+++ b/doc/todo/Arch_Linux_Port/comment_2_cc4623c156a0d12c88461bc5deec07cd._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="wzhd"
+ avatar="http://cdn.libravatar.org/avatar/d5a499b7c476ca9960cc8dccdf455bae"
+ subject="comment 2"
+ date="2017-02-04T01:53:49Z"
+ content="""
+Thanks!
+
+
+I didn't find the right way to do it; `pickOS` is so much easier than `withOS` !
+
+
+`Propellor.Property.Partition` was modified to get rid of some compiling errors in DiskImage and didn't support anything new. So I removed the changes.
+
+
+Instead, I changed some properties in DiskImage from Linux to DebianLike. Is it the correct way to do it?
+
+"""]]
diff --git a/doc/todo/Arch_Linux_Port/comment_3_d917de766dfe7fded7317d7614d1467f._comment b/doc/todo/Arch_Linux_Port/comment_3_d917de766dfe7fded7317d7614d1467f._comment
new file mode 100644
index 00000000..27ef8078
--- /dev/null
+++ b/doc/todo/Arch_Linux_Port/comment_3_d917de766dfe7fded7317d7614d1467f._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-02-04T20:55:02Z"
+ content="""
+> Instead, I changed some properties in DiskImage from Linux to
+> DebianLike. Is it the correct way to do it?
+
+Looking at it, kpartx is DebianLike-specific, so imageBuiltFrom which uses it
+should be too. The only reason it wasn't marked as DebianLike already and
+was type Linux is because Linux used to be the same as DebianLike and so
+the type checker didn't see a difference. No longer, thanks to your patch.
+
+So, it makes complete sense that you have to change this. You're paying
+the price of blazing the trail of the first non-DebianLike Linux distro in
+Propellor..
+
+---
+
+Looks like your [[!commit 25f6871e1dda3de252fbc6c8ac6962eb0cd9311a]]
+dealt with all my review suggestions. And so, I've merged it.
+
+Unless you have anything else that needs to be done, I'll release
+propellor soon with the added Arch Linux support. Thank you very much!
+"""]]
diff --git a/doc/todo/Arch_Linux_Port/comment_4_924c73c0ab6fb39c9b25ae51facf6bb6._comment b/doc/todo/Arch_Linux_Port/comment_4_924c73c0ab6fb39c9b25ae51facf6bb6._comment
new file mode 100644
index 00000000..f69e2c80
--- /dev/null
+++ b/doc/todo/Arch_Linux_Port/comment_4_924c73c0ab6fb39c9b25ae51facf6bb6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="wzhd"
+ avatar="http://cdn.libravatar.org/avatar/d5a499b7c476ca9960cc8dccdf455bae"
+ subject="comment 4"
+ date="2017-02-05T00:59:18Z"
+ content="""
+That's great! Thank you so much!
+"""]]
diff --git a/doc/todo/Are_--check_and_--build_on_the_way_in_or_on_the_way_out__63__.mdwn b/doc/todo/Are_--check_and_--build_on_the_way_in_or_on_the_way_out__63__.mdwn
new file mode 100644
index 00000000..52b3b998
--- /dev/null
+++ b/doc/todo/Are_--check_and_--build_on_the_way_in_or_on_the_way_out__63__.mdwn
@@ -0,0 +1,3 @@
+I've managed to do a few useful things with propellor, but it feels a bit rough around the edges to me. It looked at first like the --check and --build options would be useful for checking that my configs would at least compile, but it turns out that --build doesn't even exist and --check just returns without doing anything. Should they just be removed, or do they need more work to finish them?
+
+[[done]]
diff --git a/doc/todo/Are_--check_and_--build_on_the_way_in_or_on_the_way_out__63__/comment_1_7c2b2447254ad44ee1316b47eac130df._comment b/doc/todo/Are_--check_and_--build_on_the_way_in_or_on_the_way_out__63__/comment_1_7c2b2447254ad44ee1316b47eac130df._comment
new file mode 100644
index 00000000..392f0f1c
--- /dev/null
+++ b/doc/todo/Are_--check_and_--build_on_the_way_in_or_on_the_way_out__63__/comment_1_7c2b2447254ad44ee1316b47eac130df._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-12-26T15:55:36Z"
+ content="""
+--check does just what it's supposed to do. This is used during bootstrap
+to notice if the propellor binary has gotten broken by changes to eg system
+libraries.
+
+--build seems to have been added without being implemented. But it does
+seem useful to have a way to simply build propellor so implemented it now.
+"""]]
diff --git a/doc/todo/Are_--check_and_--build_on_the_way_in_or_on_the_way_out__63__/comment_2_b4910f50225a8b763566126861faea11._comment b/doc/todo/Are_--check_and_--build_on_the_way_in_or_on_the_way_out__63__/comment_2_b4910f50225a8b763566126861faea11._comment
new file mode 100644
index 00000000..0c594483
--- /dev/null
+++ b/doc/todo/Are_--check_and_--build_on_the_way_in_or_on_the_way_out__63__/comment_2_b4910f50225a8b763566126861faea11._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="db48x"
+ avatar="http://cdn.libravatar.org/avatar/ad2688127feb555a92154b16d8eeb5d3"
+ subject="aha"
+ date="2016-12-26T21:23:03Z"
+ content="""
+Thanks!
+"""]]
diff --git a/doc/todo/Info_property_to_select_host__39__s_preferred_Apt_mirror.mdwn b/doc/todo/Info_property_to_select_host__39__s_preferred_Apt_mirror.mdwn
new file mode 100644
index 00000000..4cd76383
--- /dev/null
+++ b/doc/todo/Info_property_to_select_host__39__s_preferred_Apt_mirror.mdwn
@@ -0,0 +1,5 @@
+It would be good to have an info property, say `Apt.mirror`, which sets a host's preferred apt mirror. Then all properties in `Propellor.Property.Apt` would use this mirror when generating sources lists, falling back to the `deb.debian.org` default. The value of `Apt.mirror` could be an apt cache on the LAN, or a mirror that is known to be better than the Debian CDN from where the host is located. --[[spwhitton|user/spwhitton]]
+
+[[!tag user/spwhitton]]
+
+> [[merged|done]] thank you! --[[Joey]]
diff --git a/doc/todo/Info_property_to_select_host__39__s_preferred_Apt_mirror/comment_1_ac66a33d71092261a745378c82959e69._comment b/doc/todo/Info_property_to_select_host__39__s_preferred_Apt_mirror/comment_1_ac66a33d71092261a745378c82959e69._comment
new file mode 100644
index 00000000..3734d987
--- /dev/null
+++ b/doc/todo/Info_property_to_select_host__39__s_preferred_Apt_mirror/comment_1_ac66a33d71092261a745378c82959e69._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-21T03:07:28Z"
+ content="""
+Very good idea. Happy to merge such a patch.
+"""]]
diff --git a/doc/todo/Info_property_to_select_host__39__s_preferred_Apt_mirror/comment_2_2c2c4817a4259acbc1a63bac2e3fb2e3._comment b/doc/todo/Info_property_to_select_host__39__s_preferred_Apt_mirror/comment_2_2c2c4817a4259acbc1a63bac2e3fb2e3._comment
new file mode 100644
index 00000000..b79ba1c1
--- /dev/null
+++ b/doc/todo/Info_property_to_select_host__39__s_preferred_Apt_mirror/comment_2_2c2c4817a4259acbc1a63bac2e3fb2e3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="merge request"
+ date="2017-03-19T18:42:20Z"
+ content="""
+Please see branch `apt-mirror` of repo `https://git.spwhitton.name/propellor` for an implementation of this.
+"""]]
diff --git a/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal.mdwn b/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal.mdwn
new file mode 100644
index 00000000..0910ef5d
--- /dev/null
+++ b/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal.mdwn
@@ -0,0 +1,7 @@
+I have made a new property to handle logical volume with propellor.
+
+I am not confident my haskell code is good looking as this is my first real life haskell code, can you please have a look?
+
+You can pull the lvm branch at http://git.ni.fr.eu.org/nicolas/propellor.git
+
+Thanks!
diff --git a/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_1_74c6576b25f74c6e620eb015af8b0f6a._comment b/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_1_74c6576b25f74c6e620eb015af8b0f6a._comment
new file mode 100644
index 00000000..5982361f
--- /dev/null
+++ b/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_1_74c6576b25f74c6e620eb015af8b0f6a._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-31T22:40:34Z"
+ content="""
+That's a pretty nice job for your first haskell code! And an impressive
+module.
+
+Most of my review comments have to do with improving types.. Which is
+always a nice way to improve already good code. :)
+
+* VolumeGroup and LogicalVolume seem like easy things to mix up.
+ Also, there's never a LogicalVolume without an associated VolumeGroup.
+ So, suggest `newtype VolumeGroup = VolumeGroup String` and
+ `data LogicalVolume = LogicalVolume String VolumeGroup` -- then
+ the user would write something like
+ `LogicalVolume "test" (VolumeGroup "vg0")`
+* Why not make `LvState` contain a `Maybe Partition.Fs` rather than
+ the string value. (This also would move the parsing of filesystem names
+ from `fsMatch` to `lvState` or perhaps to another function it uses.)
+* It seems a bit wrong for `parseSize` to include the rounding
+ to the next extent, which is not really related to parsing.
+ Would be better to split those two things into separate functions.
+
+I feel that this module is fairly close to mergeable.
+"""]]
diff --git a/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_2_d63d84b56ece233f795d1075aaba887a._comment b/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_2_d63d84b56ece233f795d1075aaba887a._comment
new file mode 100644
index 00000000..546fe436
--- /dev/null
+++ b/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_2_d63d84b56ece233f795d1075aaba887a._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="Nicolas.Schodet"
+ avatar="http://cdn.libravatar.org/avatar/0d7ec808ec329d04ee9a93c0da3c0089"
+ subject="comment 2"
+ date="2017-09-01T21:38:16Z"
+ content="""
+Thanks for your comments.
+
+I also have a problem when running vgs/lvs, they complain about leaked file descriptors. Is it something I can fix?
+
+ File descriptor 10 (/usr/local/propellor/.lock) leaked on vgs invocation. Parent PID 31216: ./dist/build/propellor-config/p
+ File descriptor 11 (pipe:[282601]) leaked on vgs invocation. Parent PID 31216: ./dist/build/propellor-config/p
+ File descriptor 12 (pipe:[282601]) leaked on vgs invocation. Parent PID 31216: ./dist/build/propellor-config/p
+ File descriptor 13 (pipe:[282602]) leaked on vgs invocation. Parent PID 31216: ./dist/build/propellor-config/p
+ File descriptor 14 (pipe:[282602]) leaked on vgs invocation. Parent PID 31216: ./dist/build/propellor-config/p
+
+I have pushed a new version with the suggested fixes.
+"""]]
diff --git a/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_3_1405e20c8f5dc6e9cca3732e3e368d03._comment b/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_3_1405e20c8f5dc6e9cca3732e3e368d03._comment
new file mode 100644
index 00000000..76c89ca6
--- /dev/null
+++ b/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_3_1405e20c8f5dc6e9cca3732e3e368d03._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-09-01T22:32:43Z"
+ content="""
+One way would be to use System.Process's `close_fds` when executing
+vgs/lvs. BTW, I've seen such complaints from lvm before, in some
+situations not involving propellor.
+
+I've made a commit that makes the propellor lock FD be close-on-exec,
+which is generally a good idea for lock FDs anyway. (To prevent some
+long-running daemon process that does not close such FDs keeping the lock
+held.)
+
+My guess is that the other 4 FDs, which are apparently pairs of FDs
+at both sides of a pipe, come from
+System.Console.Concurrent.Internal.bgProcess, which sets up just such a
+pipe. Quite possibly when vgs/lvs are run, it's via that function.
+
+Generally leaking non-lock-related FDs to child processes is not a big
+problem, as long as the child process doesn't write to random FDs (which
+would be pretty bad, but what would ever do that?) ... So I don't know if I
+want to try to chase down every FD used all through propellor to set them
+close-on-exec.
+"""]]
diff --git a/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_4_20c6734d67fefeb1a8c07730d537e06b._comment b/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_4_20c6734d67fefeb1a8c07730d537e06b._comment
new file mode 100644
index 00000000..74a8bbe1
--- /dev/null
+++ b/doc/todo/LVM_logical_volume_creation__44___resize__44___format___38___removal/comment_4_20c6734d67fefeb1a8c07730d537e06b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Nicolas.Schodet"
+ avatar="http://cdn.libravatar.org/avatar/0d7ec808ec329d04ee9a93c0da3c0089"
+ subject="comment 4"
+ date="2017-09-03T21:00:36Z"
+ content="""
+I can rebase/squash, do you see something else to improve?
+"""]]
diff --git a/doc/todo/Merging_from___47__usr__47__src__47__propellor_broken_now_CHANGELOG_not_a_symlink.mdwn b/doc/todo/Merging_from___47__usr__47__src__47__propellor_broken_now_CHANGELOG_not_a_symlink.mdwn
new file mode 100644
index 00000000..bfba8548
--- /dev/null
+++ b/doc/todo/Merging_from___47__usr__47__src__47__propellor_broken_now_CHANGELOG_not_a_symlink.mdwn
@@ -0,0 +1,36 @@
+In Joey's master branch, `CHANGELOG` is a real file, whereas previously it was a symlink. This breaks the `/usr/src/propellor` newer version check.
+
+Steps to reproduce:
+
+1. Install propellor 3.2.3 or older with apt on Debian or Ubuntu
+2. `propellor --init` and select option `A`
+3. Prepare a pseudorelease: merge Joey's master branch into [my Debian packaging branch](https://git.spwhitton.name/?p=propellor.git;a=shortlog;h=refs/heads/debian), `dch -v3.2.3+gitYYYYMMDD.fffffff`, `dpkg-buildpackage -uc -b`, `debi -u`
+4. `propellor --spin`
+
+I haven't yet tried reproducing this by building a `.deb` from Joey's master branch, rather than my packaging branch. If the problem does not appear using a `.deb` from Joey's master branch, this is an internal Debian problem, rather than an upstream bug. However, perhaps Joey can immediately see a solution.
+
+Sample output:
+
+ Auto-merging src/wrapper.hs
+ Auto-merging src/Utility/UserInfo.hs
+ Auto-merging src/Utility/SystemDirectory.hs
+ Auto-merging src/Utility/Misc.hs
+ Auto-merging src/Utility/FileSystemEncoding.hs
+ Auto-merging src/Utility/Exception.hs
+ Auto-merging src/Propellor/Types/CmdLine.hs
+ Auto-merging src/Propellor/Shim.hs
+ Auto-merging src/Propellor/Property/Gpg.hs
+ Auto-merging src/Propellor/Property/Debootstrap.hs
+ Auto-merging src/Propellor/Property.hs
+ Auto-merging src/Propellor/PrivData.hs
+ Auto-merging src/Propellor/Gpg.hs
+ Auto-merging src/Propellor/CmdLine.hs
+ Auto-merging debian/changelog
+ Auto-merging CHANGELOG
+ CONFLICT (add/add): Merge conflict in CHANGELOG
+ Automatic merge failed; fix conflicts and then commit the result.
+ propellor: Failed to run git ["merge","c590ddd8e2fa87baa409b6c29501d4473555ecfb","-s","recursive","-Xtheirs","--quiet","-m","merging upstream version","--allow-unrelated-histories"]
+ CallStack (from HasCallStack):
+ error, called at src/Propellor/DotDir.hs:425:17 in main:Propellor.DotDir
+
+--spwhitton
diff --git a/doc/todo/Merging_from___47__usr__47__src__47__propellor_broken_now_CHANGELOG_not_a_symlink/comment_1_62b47d7c0530c2988b7e6e998878b920._comment b/doc/todo/Merging_from___47__usr__47__src__47__propellor_broken_now_CHANGELOG_not_a_symlink/comment_1_62b47d7c0530c2988b7e6e998878b920._comment
new file mode 100644
index 00000000..886c2534
--- /dev/null
+++ b/doc/todo/Merging_from___47__usr__47__src__47__propellor_broken_now_CHANGELOG_not_a_symlink/comment_1_62b47d7c0530c2988b7e6e998878b920._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-01-01T21:29:52Z"
+ content="""
+I have reverted that change for now.
+
+I don't think the /usr/src/propellor/ merge has anything specific to do
+with the changelog, so there is probably a general case where that merge
+fails to work. I guess it involves a file's type changing.
+"""]]
diff --git a/doc/todo/Merging_from___47__usr__47__src__47__propellor_broken_now_CHANGELOG_not_a_symlink/comment_2_61463030200038542d293149754d36ed._comment b/doc/todo/Merging_from___47__usr__47__src__47__propellor_broken_now_CHANGELOG_not_a_symlink/comment_2_61463030200038542d293149754d36ed._comment
new file mode 100644
index 00000000..b1b4a037
--- /dev/null
+++ b/doc/todo/Merging_from___47__usr__47__src__47__propellor_broken_now_CHANGELOG_not_a_symlink/comment_2_61463030200038542d293149754d36ed._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 2"
+ date="2017-01-03T09:07:18Z"
+ content="""
+Thanks for looking at this. Yes, it's probably the type-change. There is surely some way to instruct git to DTRT.
+"""]]
diff --git a/doc/todo/PROPELLOR_TRACE_propigation.mdwn b/doc/todo/PROPELLOR_TRACE_propigation.mdwn
new file mode 100644
index 00000000..8f7d6893
--- /dev/null
+++ b/doc/todo/PROPELLOR_TRACE_propigation.mdwn
@@ -0,0 +1,6 @@
+`PROPELLOR_TRACE` is not propigated when spinning a remote host,
+conducting a host, and probably not when provisioning a docker or machined
+container.
+
+It is propgiated when provisioning a chroot. That's all I needed, so I
+didh't bother implementing propigation. --[[Joey]]
diff --git a/doc/todo/Propellor.Property.Versioned_support_asymmetric_RevertableProperty_types.mdwn b/doc/todo/Propellor.Property.Versioned_support_asymmetric_RevertableProperty_types.mdwn
new file mode 100644
index 00000000..c60cd4d6
--- /dev/null
+++ b/doc/todo/Propellor.Property.Versioned_support_asymmetric_RevertableProperty_types.mdwn
@@ -0,0 +1,7 @@
+Currently, this module requires `RevertableProperty t t`.
+That can be annoying, it would be good to support at least
+`RevertablePropery (HasInfo + t) t` and ideally all
+`RevertableProperty t1 t2`
+
+There should be no reason that can't be done; I was just having
+problems getting the type checker happy on the day I wrote it. --[[Joey]]
diff --git a/doc/todo/bug_in_diskimage_finalization.mdwn b/doc/todo/bug_in_diskimage_finalization.mdwn
new file mode 100644
index 00000000..3dc9c437
--- /dev/null
+++ b/doc/todo/bug_in_diskimage_finalization.mdwn
@@ -0,0 +1,13 @@
+DiskImage.imageBuilt has broken and no longer runs the finalization
+properties that get added to the chroot. This includes installing grub, and
+Chroot.noServices etc.
+
+Seems that the `_chroot` info that gets propigated from imageBuilt is
+for the chroot before those properties are added to it. Then when chaining
+into the chroot, `_chroot` info is examined to find the properties to
+ensure.
+
+I have not yet been able to determine what broke it -- I'm sure it used to
+work. --[[Joey]]
+
+> Figured it out, fixed [[done]] --[[Joey]]
diff --git a/doc/todo/differential_update_via_RevertableProperty.mdwn b/doc/todo/differential_update_via_RevertableProperty.mdwn
new file mode 100644
index 00000000..3eb9bc7a
--- /dev/null
+++ b/doc/todo/differential_update_via_RevertableProperty.mdwn
@@ -0,0 +1,146 @@
+Long ago, nomeata pointed out that RevertableProperty required the user to
+keep track of different versions of a Host, in a way that should be able to
+be automated. When the user decides to revert a RevertableProperty, they
+have to keep the reverted property on the Host until propellor runs there,
+and only then can remove it.
+
+What if instead, there was a way to store the old version of a Host
+somewhere. Let's not worry about where or how, but assume we have
+`(old, new) :: (Host, Host)`
+
+Propellor could compare `old` and `new`, and if it finds a
+RevertableProperty in `old` that is not in `new`, add it in reverted form
+to `new'`.
+
+Also, if propellor finds a Property in `old` that is not in `new`, it can
+tell the user that this Property needs to be reverted, but cannot be, so
+`new` won't fully describe the state of the host. --[[Joey]]
+
+----
+
+There are a lot of ways such a capability could be used, especially if
+there were a way to pull the old version of a Host out of a previous
+version of config.hs or something like that. But leaving aside such magic,
+here are some nice use cases:
+
+* Suppose we want to generate several disk images, which are somewhat
+ similar, but differ in some properties. Rather than building a separate
+ chroot for each, we can build a chroot for the first, update the first
+ disk image, compare that with the second and update the chroot
+ accordingly, and so on.
+* When propellor is used to build a OS installer disk image, that installer
+ could know the properties used to create it, and the properties of the
+ system that is desired to be installed. To install, it can rsync the
+ installer disk contents to `/target` and then run propellor in `/target`,
+ differentially updating it as needed.
+
+----
+
+Here's the catch: It can't be implemented currently! The comparison of
+properties needs an `Eq` instance for Property (and RevertableProperty).
+But, a property contains an action in the IO monad, which can't have an
+`Eq` instance, and so there's no good way to compare properties.
+
+Making propellor use an ESDL could get us `Eq`. But it would make it rather
+clumsy to write properties, something like this.
+
+<pre>
+appendfoo f = WriteFile f (ListAppend "foo" (ReadFile f))
+</pre>
+
+(Perhaps a deeply embedded DSL would be better.)
+
+Could a Free monad get us `Eq`? Well, there can apparently be free monads that
+have an `Eq` instance, but I tried building one for a simple teletype, and
+failed, which does not bode well. Here's the code; this fails to compile
+because of a missing instance `(Eq1 ((->) String))`, and of course comparing
+functions for equality is not generally feasible.
+
+<pre>
+{-# LANGUAGE FlexibleContexts, UndecidableInstances #-}
+
+import Control.Monad.Free
+import Prelude.Extras
+
+data TeletypeF x
+ = PutStrLn String x
+ | GetLine (String -> x)
+
+instance Functor TeletypeF where
+ fmap f (PutStrLn str x) = PutStrLn str (f x)
+ fmap f (GetLine k) = GetLine (f . k)
+
+instance (Eq1 ((->) String)) => Eq1 TeletypeF where
+ PutStrLn a x ==# PutStrLn b y = a == b && x == y
+ GetLine a ==# GetLine b = a ==# b
+
+type Teletype = Free TeletypeF
+
+putStrLn' :: String -> Teletype ()
+putStrLn' str = liftF $ PutStrLn str ()
+
+getLine' :: Teletype String
+getLine' = liftF $ GetLine id
+
+foo :: Teletype ()
+foo = do
+ putStrLn' "name?"
+ name <- getLine'
+ putStrLn' ("hello, " ++ name)
+
+fooisfoo :: Bool
+fooisfoo = foo ==# foo
+</pre>
+
+-----
+
+## the best we can do without Eq
+
+Is, perhaps:
+
+ data Version = A | B | C
+ deriving (Enum, Ord)
+
+ foo :: Versioned Hoso
+ foo = versionedHost "foo" $ do
+ ver A someprop
+ <|> othervers otherprop
+ ver A somerevertableprop
+ ver [B, C] newprop
+
+That's ... pretty ok, would hit as least some of the use cases described
+above. Seems to need a Reader+Writer monad to implement it,
+without passing the Version around explicitly.
+
+Is it allowable for `newprop` to not be revertable?
+Once `foo` gets that property, it is never removed if we're moving only
+forwards. On the other hand, perhaps the user will want to roll back to
+version A. Allowing rollbacks seems good, so `inVersion` should only
+accept `RevertableProperty`.
+
+Another interesting case is this:
+
+ foo = versionedHost "foo" $ do
+ ver A bar
+ always otherprop
+ ver [B, C] bar
+
+Is version A of foo identical to verion B? If so, this should be allowed to
+compile even when `bar` cannot be reverted. On the other hand, perhaps
+ordering of the properties matters, in which case the systems are subtly
+different, and there's no way to get from A to B.
+
+It's certianly possible for ordering to matter in propellor properties,
+although it's generally a bug when it does. So, it seems ok for this
+case to be rejected.
+
+As well as `Versioned Host`, it would be possible to have
+`Versioned (Property metatypes)`.
+Indeed, that would make sense to he used internally in the
+examples above. And that allows composition of properties with versioning:
+
+ someprop :: Versioned (Property DebianLike)
+ someprop = versionedProperty $ do
+ ver A foo <|> ver [B, C] bar
+
+> [[done]] in Propellor.Property.Versioned. --[[Joey]]
diff --git a/doc/todo/hostChroot.mdwn b/doc/todo/hostChroot.mdwn
new file mode 100644
index 00000000..6a4df9c1
--- /dev/null
+++ b/doc/todo/hostChroot.mdwn
@@ -0,0 +1,9 @@
+Would be useful to have a `hostChroot :: Host -> Chroot`.
+
+For a Debian host, this would use debootstrapped and pass all the Host's
+properties to it. --[[Joey]]
+
+Would need to make privdata use the context of the input Host. And would
+need to propigate privdata info, but not other info. --[[Joey]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/initial_spin_compile_failure_recovery.mdwn b/doc/todo/initial_spin_compile_failure_recovery.mdwn
new file mode 100644
index 00000000..423b279c
--- /dev/null
+++ b/doc/todo/initial_spin_compile_failure_recovery.mdwn
@@ -0,0 +1,5 @@
+When initial propellor --spin host fails to compile propellor
+perhaps due to a ghc compatability bug, spinning again doesn't fix the
+problem. IIRC /usr/local/propellor has a git repo set up, but no remote
+set, and so the subsequent spin doesn't update it, since propellor is not
+running there to receive a git push into the repo. --[[Joey]]
diff --git a/doc/todo/merge_request:_Timezone.hs.mdwn b/doc/todo/merge_request:_Timezone.hs.mdwn
new file mode 100644
index 00000000..a8ba3eae
--- /dev/null
+++ b/doc/todo/merge_request:_Timezone.hs.mdwn
@@ -0,0 +1,9 @@
+Please consider merging branch `timezone` of repo `https://git.spwhitton.name/propellor`.
+
+Adds `Timezone.configured`.
+
+I think that this works fine on stretch, but on Jessie there is some oddness. For example, if you set the timezone of a host to `US/Arizona`, the apt reconfiguration will put `America/Phoenix` in /etc/timezone, resulting in the property reporting a change every time that it is run. I think this is harmless.
+
+--spwhitton
+
+> [[merged|done]] --[[Joey]]
diff --git a/doc/todo/merge_request:_Timezone.hs/comment_1_9cfb5e48940e58f2064cbb5edf462c06._comment b/doc/todo/merge_request:_Timezone.hs/comment_1_9cfb5e48940e58f2064cbb5edf462c06._comment
new file mode 100644
index 00000000..026b13de
--- /dev/null
+++ b/doc/todo/merge_request:_Timezone.hs/comment_1_9cfb5e48940e58f2064cbb5edf462c06._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-07-16T15:57:20Z"
+ content="""
+I generally consider properties that do work every time to be a minor bug.
+
+I wonder if it would be better to preseed tzdata rather than writing the
+config file. I observe the same substitution from eg, US/Eastern to
+America/New_York in the file when reconfiguring noninteractively,
+but reconfiguring interactively I can select US/Eastern and that gets
+into the file.
+
+Anyway, merged as this is certianly a good starting point.
+"""]]
diff --git a/doc/todo/modify_Apt.pinnedTo_to_pin_a_package_to_multiple_suites_with_different_priorities.mdwn b/doc/todo/modify_Apt.pinnedTo_to_pin_a_package_to_multiple_suites_with_different_priorities.mdwn
new file mode 100644
index 00000000..02be4ad7
--- /dev/null
+++ b/doc/todo/modify_Apt.pinnedTo_to_pin_a_package_to_multiple_suites_with_different_priorities.mdwn
@@ -0,0 +1,7 @@
+Please consider merging the `pin` branch of `https://git.spwhitton.name/propellor` (again).
+
+I've modified `Apt.pinnedTo` so that it can pin an `AptPrefPackage` to multiple suites with different pin priorities. I've included a sample use-case in the function's haddock.
+
+--spwhitton
+
+> merged, [[done]] --[[Joey]]
diff --git a/doc/todo/new_apt_pinning_properties.mdwn b/doc/todo/new_apt_pinning_properties.mdwn
new file mode 100644
index 00000000..8687b58a
--- /dev/null
+++ b/doc/todo/new_apt_pinning_properties.mdwn
@@ -0,0 +1,10 @@
+My branch `pin` of repo `https://git.spwhitton.name/propellor` adds
+
+- `Apt.suiteAvailablePinned`
+- `Apt.pinnedTo`
+- `File.containsBlock`
+- a haddock for `File.containsLines`
+
+There is one TODO in a comment that relates to propellor's algebraic data types. I'd be grateful for help with that. --spwhitton
+
+> merged, thanks. [[done]] --[[Joey]]
diff --git a/doc/todo/new_apt_pinning_properties/comment_1_fd9e6775868eaa8d6aee49d06944ef0c._comment b/doc/todo/new_apt_pinning_properties/comment_1_fd9e6775868eaa8d6aee49d06944ef0c._comment
new file mode 100644
index 00000000..4800608f
--- /dev/null
+++ b/doc/todo/new_apt_pinning_properties/comment_1_fd9e6775868eaa8d6aee49d06944ef0c._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-01T20:00:47Z"
+ content="""
+I wonder if it would be better to separate `suiteAvailablePinned`
+into `suiteAvailable` and `suitePinned`? The latter could require
+the former.
+
+`pinnedTo` should probably be DebianLike not UnixLike.
+And its `[String]` parameter ought to be `[Package]`.
+
+Is `File.containsBlock` necessary? Seems that if you care about
+ordering of blocks in the file, you generally should use
+`File.hasContent` to specify the full content. Rather than using
+/etc/apt/preferences.d/10propellor.pref for multiple properties,
+you could use a separate file for each `pinnedTo'` with the parameters
+encoded in the filename.
+
+As to the TODO, I tried adding this:
+
+ robustly' :: RevertableProperty DebianLike DebianLike -> RevertableProperty DebianLike DebianLike
+ robustly' p = p `fallback` (update `before` p)
+
+And the compiler tells me it's wrong because `update` is not revertable.
+But of course, there's no need to revert apt-get update, so this compiles:
+
+ robustly' :: RevertableProperty DebianLike DebianLike -> RevertableProperty DebianLike DebianLike
+ robustly' p = p `fallback` ((update <!> (doNothing :: Property DebianLike)) `before` p)
+
+Cleaning it up left an an exersise for the reader. Might be possible
+to combine `robustly` and `robustly'` into a single function, but I'm
+not able to see how immediately.
+
+However.. Seems to me that whatever you wanted to use `robustly` with to
+spur that TODO, you could just apply it to the first Property of the
+RevertableProperty, and not to the second one?
+"""]]
diff --git a/doc/todo/new_apt_pinning_properties/comment_2_c82f7e83f3fcc7648222d9dbf90e5ddd._comment b/doc/todo/new_apt_pinning_properties/comment_2_c82f7e83f3fcc7648222d9dbf90e5ddd._comment
new file mode 100644
index 00000000..4fd7c824
--- /dev/null
+++ b/doc/todo/new_apt_pinning_properties/comment_2_c82f7e83f3fcc7648222d9dbf90e5ddd._comment
@@ -0,0 +1,66 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="reply to review"
+ date="2017-02-02T17:40:11Z"
+ content="""
+Thank you for your feedback, Joey.
+
+> I wonder if it would be better to separate `suiteAvailablePinned`
+> into `suiteAvailable` and `suitePinned`? The latter could require
+> the former.
+
+I see how this could be useful, in particular if you want to make a
+suite like Debian experimental available, which won't cause any packages
+to be automatically upgraded.
+
+However, it makes it less convenient, and perhaps dangerous, to revert a
+pinned suite. For example, suppose on my Debian testing system I have
+`Apt.suitePinned Unstable 100`. If I revert this property, it will
+remove the pin but not remove the source. Then my system might get
+mass-upgraded to sid if I'm not careful.
+
+We couldn't have the revert of `Apt.suitePinned` remove the source
+because then if I have both `& Apt.suiteAvailable Unstable` and `!
+Apt.suitePinned Unstable 100`, the second property would cancel out the
+first, which doesn't make sense.
+
+On balance, I think it's best to keep the current property. A property
+adding sources to apt.sources.d should probably force the user to pick a
+pin value, to avoid any unexpected upgrades.
+
+> `pinnedTo` should probably be DebianLike not UnixLike.
+
+This was my 'TODO'. (Since the property takes a `DebianSuite`, I think
+it should be `Debian` not `DebianLike`.)
+
+I tried applying `tightenTargets` to `pinnedTo`, but that only seems to
+affect one half of the revertable property. Do I need to implement a
+new tightening function?
+
+> And its `[String]` parameter ought to be `[Package]`.
+
+I don't think so. The parameter to `pinnedTo` can be a wildcard
+expression or a regex (per `apt_preferences(5)`). Neither of these are
+accepted by other existing properties that take `[Package]`, such as
+`Apt.installed`. I could add a new type alias, if you prefer.
+
+> Is `File.containsBlock` necessary? Seems that if you care about
+> ordering of blocks in the file, you generally should use
+> `File.hasContent` to specify the full content. Rather than using
+> /etc/apt/preferences.d/10propellor.pref for multiple properties,
+> you could use a separate file for each `pinnedTo'` with the parameters
+> encoded in the filename.
+
+This was what I tried on my first attempt, but it gets very complicated
+if the user passes a wildcard expression or a regex instead of a package
+name. I would need to convert that wildcard expression or regex to a
+cross-platform filename, and the conversion would need to be isomorphic
+to avoid any clashes. The `File.containsBlock` seems more sane than
+that.
+
+> As to the TODO, I tried adding this: [...]
+
+I don't understand how `robustly` is relevant to my TODO -- please see
+above.
+"""]]
diff --git a/doc/todo/new_apt_pinning_properties/comment_3_58d323602f293471ce3d2d9b4d271130._comment b/doc/todo/new_apt_pinning_properties/comment_3_58d323602f293471ce3d2d9b4d271130._comment
new file mode 100644
index 00000000..b0ff271e
--- /dev/null
+++ b/doc/todo/new_apt_pinning_properties/comment_3_58d323602f293471ce3d2d9b4d271130._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-02-02T18:45:01Z"
+ content="""
+That example with reverting one property overriding another property
+is a general problem propellor has with conflicting properties.
+Normally I don't much worry about it, but I agree an accidental mass
+upgrade is a good reason to avoid that problem here.
+
+Yes please add a new type alias for String (or an ADT)
+if Package is not appropriate.
+
+I had misunderstood which function the TODO was for..
+
+Nice surprise that tightenTargets works on RevertableProperty at all.
+Since it does, you should be able to tighten one side, revert, tighten the
+other side, and re-revert. Or, deconstruct the RevertableProperty,
+tighten both sides individually, and reconstruct it.
+
+I've added a Propellor.Property.File.configFileName that
+should be suitable for your purposes, and others..
+"""]]
diff --git a/doc/todo/new_apt_pinning_properties/comment_4_add83ed58963e944ccd705a50e8b5a47._comment b/doc/todo/new_apt_pinning_properties/comment_4_add83ed58963e944ccd705a50e8b5a47._comment
new file mode 100644
index 00000000..9688672b
--- /dev/null
+++ b/doc/todo/new_apt_pinning_properties/comment_4_add83ed58963e944ccd705a50e8b5a47._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 4"
+ date="2017-02-03T04:07:58Z"
+ content="""
+> Yes please add a new type alias for String (or an ADT) if Package is not appropriate.
+
+Propellor won't be parsing any of the regexp or globs, so I've added a new type alias rather than an ADT.
+
+> Nice surprise that tightenTargets works on RevertableProperty at all. Since it does, you should be able to tighten one side, revert, tighten the other side, and re-revert. Or, deconstruct the RevertableProperty, tighten both sides individually, and reconstruct it.
+
+I don't understand what you're getting at with the first of these suggestions.
+
+In any case, now that I'm not using `File.containsBlock`, it's easy to just apply `tightenTargets` to each side.
+
+> I've added a Propellor.Property.File.configFileName that should be suitable for your purposes, and others..
+
+Very nice :) I've updated my branch to use this. I haven't removed `File.containsBlock`, since it might be useful in the future, but you could of course revert the relevant commit.
+"""]]
diff --git a/doc/todo/property_to_install_propellor.mdwn b/doc/todo/property_to_install_propellor.mdwn
new file mode 100644
index 00000000..184977f5
--- /dev/null
+++ b/doc/todo/property_to_install_propellor.mdwn
@@ -0,0 +1,16 @@
+This seems redundant, since propellor must be running to ensure such a
+Property, but a Property to install propellor is useful when eg, creating a
+disk image that itself will need to run propellor. --[[Joey]]
+
+Should support:
+
+* Cloning the git repo propellor is running in. (Using eg `hostChroot`)
+* Cloning some other git repo.
+* Installing the precompiled propellor binary.
+* Installing the propellor haskell library using cabal/stack/apt.
+
+Much of this is already implemented, in non-Property form, in
+Propellor.Bootstrap, but will need adjustments for this new context.
+--[[Joey]]
+
+> [[done]]
diff --git a/doc/todo/property_to_install_propellor/comment_1_b05e9a44e5c7130d9cc928223cd82d78._comment b/doc/todo/property_to_install_propellor/comment_1_b05e9a44e5c7130d9cc928223cd82d78._comment
new file mode 100644
index 00000000..5a826fea
--- /dev/null
+++ b/doc/todo/property_to_install_propellor/comment_1_b05e9a44e5c7130d9cc928223cd82d78._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-04-09T17:42:10Z"
+ content="""
+Making this work when propellor is setting up a chroot is difficult,
+because the localdir is bind mounted into the chroot.
+
+Hmm, `unshare` could be helpful. Run shell commands to clone the localdir
+inside `unshare -m`, prefixed with a `umount localdir`. This way, the bind
+mount is avoided, and it writes "under" it. Limits the commands that can be
+run to set up the localdir to shell commands, but bootstrap already
+operates on terms of shell commands so that seems ok.
+
+`unshare` is linux-specific; comes in util-linux on modern linuxes.
+"""]]
diff --git a/doc/todo/property_to_install_propellor/comment_2_9fea601af57777e1cb49952483f4da63._comment b/doc/todo/property_to_install_propellor/comment_2_9fea601af57777e1cb49952483f4da63._comment
new file mode 100644
index 00000000..f862f79b
--- /dev/null
+++ b/doc/todo/property_to_install_propellor/comment_2_9fea601af57777e1cb49952483f4da63._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-04-09T20:49:04Z"
+ content="""
+Well, seems that `unshare` does not work in a chroot. Hmm.
+"""]]
diff --git a/doc/todo/sbuild_setup_should_use_apt-cacher-ng.mdwn b/doc/todo/sbuild_setup_should_use_apt-cacher-ng.mdwn
new file mode 100644
index 00000000..d37d6806
--- /dev/null
+++ b/doc/todo/sbuild_setup_should_use_apt-cacher-ng.mdwn
@@ -0,0 +1,22 @@
+Please consider merging branch `apt-cacher-ng` of repo `https://git.spwhitton.name/propellor`.
+
+Sample text for changelog/description of changes:
+
+ * Add Apt.proxy property to set a host's apt proxy.
+ * Add Apt.useLocalCacher property to set up apt-cacher-ng.
+ * Rework Sbuild properties to use apt proxies/cachers instead of bind-mounting
+ the host's apt cache. This makes it possible to run more than one build at
+ a time, and lets sbuild run even if apt's cache is locked by the host's apt.
+ - If Apt.proxy is set, it is assumed that the proxy does some sort of
+ caching, and sbuild chroots are set up to use the same proxy.
+ - If Apt.proxy is not set, we install apt-cacher-ng, and point sbuild
+ chroots at the local apt cacher.
+ - Drop Sbuild.piupartsConfFor, Sbuild.piupartsConf, Sbuild.shareAptCache
+ (API change)
+ No longer needed now that we are using apt proxies/cachers.
+ - Update sample config in haddock for Propellor.Property.Sbuild.
+ Please compare both your config.hs and your ~/.sbuildrc against the haddock.
+
+--spwhitton
+
+> merge [[done]] --[[Joey]]
diff --git a/doc/todo/spin_failure_HEAD.mdwn b/doc/todo/spin_failure_HEAD.mdwn
new file mode 100644
index 00000000..1a591b35
--- /dev/null
+++ b/doc/todo/spin_failure_HEAD.mdwn
@@ -0,0 +1,130 @@
+Seen recently on 2 hosts:
+
+ Sending privdata (73139 bytes) to kite.kitenet.net ... done
+ fatal: Couldn't find remote ref HEAD
+ propellor: <stdout>: hPutStr: illegal operation (handle is closed)
+ fatal: The remote end hung up unexpectedly
+ Sending git update to kite.kitenet.net ... failed
+
+Despite the error, HEAD seems to be updated to the commit that is being spun,
+but the rest of the propellor runs doesn't happen. --[[Joey]]
+
+> This was happening spinning kite at my Mom's, but not from home.
+
+> Earlier, it was happening spinning clam from home, when clam had debian
+> oldstable on it (new install).
+>
+> So, transient and/or network-related.. --[[Joey]]
+
+> > Happening again spinning kite over satelite, but not other hosts.
+> > I enabled propellor.debug, and here's what it showed on kite:
+
+ Sending privdata (73139 bytes) to kite.kitenet.net ... done
+ [2017-06-18 16:01:08 EDT] received marked PRIVDATA
+ [2017-06-18 16:01:08 EDT] requested marked GITPUSH
+ [2017-06-18 16:01:11 EDT] received marked GITPUSH
+ [2017-06-18 16:01:11 EDT] command line: GitPush 11 12
+ fatal: Couldn't find remote ref HEAD
+ propellor: <stdout>: hPutStr: illegal operation (handle is closed)
+ fatal: The remote end hung up unexpectedly
+ Sending git update to kite.kitenet.net ... failed
+
+> > Seem that what's failing is "git fetch" when propellor
+> > runs it with --upload-pack used to run propellor --gitpush.
+> >
+> > The "fatal: Couldn't find remote ref HEAD" comes from git fetch,
+> > I think when no HEAD is in the list of remote refs.
+> >
+> > The hPutStr error was a red herring; errorMessage was using
+> > outputConcurrent. After I fixed it to use errorConcurrent,
+> > it displayed the "git fetch from client failed" error message instead.
+> >
+> > Next step is probably to enable `GIT_TRACE_PACKET` debugging
+> > of the git fetch. I did so on kite, but then propellor --spin succeeded.
+> > Here's the debug output I got when it worked, for later comparison
+> > next time it fails. Note the HEAD ref is given first thing.
+
+<pre>
+Sending privdata (73139 bytes) to kite.kitenet.net ... done
+[2017-06-18 16:27:12 EDT] received marked PRIVDATA
+[2017-06-18 16:27:12 EDT] requested marked GITPUSH
+[2017-06-18 16:27:13 EDT] received marked GITPUSH
+[2017-06-18 16:27:13 EDT] command line: GitPush 11 12
+16:27:13.953638 pkt-line.c:80 packet: fetch< 3a3c8a731d169a2768dd243581803dcb7b275049 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow deepen-since deepen-not deepen-relative no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/joeyconfig agent=git/2.11.0
+16:27:13.953781 pkt-line.c:80 packet: fetch< 86b077b7a21efd5484dfaeee3c31fc5f3c151f6c refs/heads/confpairs
+16:27:13.953789 pkt-line.c:80 packet: fetch< e03e4bf0f1e557f87d1fe7e01a6de7866296fce6 refs/heads/d-i
+16:27:13.953795 pkt-line.c:80 packet: fetch< 3a3c8a731d169a2768dd243581803dcb7b275049 refs/heads/joeyconfig
+16:27:13.953801 pkt-line.c:80 packet: fetch< ee56d3793be3a8c0c268d8afdc642ef92b879269 refs/heads/master
+16:27:13.953807 pkt-line.c:80 packet: fetch< 51be061c90ca7539d7f8b804007cd9942f316860 refs/heads/precompiled
+16:27:13.953812 pkt-line.c:80 packet: fetch< 48c0e1107ea4a89a22e71c1cba0bdc238d119a9f refs/heads/resourceconflict
+16:27:13.953818 pkt-line.c:80 packet: fetch< dbfac89a85485f8ca2107792a3ce964c06adefbf refs/heads/typed-os-requirements
+16:27:13.953823 pkt-line.c:80 packet: fetch< 96a4fcf180885788959d7dc136dbef544270fa81 refs/heads/wip-bytestring-privdata
+16:27:13.953829 pkt-line.c:80 packet: fetch< ee35c58303221ddb4c83c33eb12a52c59cd482c2 refs/remotes/abailly/master
+16:27:13.953834 pkt-line.c:80 packet: fetch< baf65fa9fff4b8451ba7f1ee129484723a8deb9b refs/remotes/db48x/fstab-swap
+16:27:13.953839 pkt-line.c:80 packet: fetch< 7d8f9dbf60f8ab345a75c4ee4f8c457d0fde5b43 refs/remotes/db48x/git-in-emtpy-directory
+16:27:13.953844 pkt-line.c:80 packet: fetch< 17abde8439d17d49676f549f357f45eb2adce868 refs/remotes/db48x/master
+16:27:13.953849 pkt-line.c:80 packet: fetch< de50503e4dbdea853e899f01e8828cf4f454dd57 refs/remotes/dgit/dgit/sid
+(omitted 300+ lines of refs)
+16:27:14.352945 pkt-line.c:80 packet: fetch< 0000
+From .
+ * branch HEAD -> FETCH_HEAD
+16:27:14.379922 pkt-line.c:80 packet: fetch> 0000
+Sending git update to kite.kitenet.net ... done
+</pre>
+
+> > Aha! My next spin failed again, with this debug:
+
+<pre>
+Sending privdata (73139 bytes) to kite.kitenet.net ... done
+[2017-06-18 16:31:15 EDT] received marked PRIVDATA
+[2017-06-18 16:31:15 EDT] requested marked GITPUSH
+[2017-06-18 16:31:16 EDT] received marked GITPUSH
+[2017-06-18 16:31:16 EDT] command line: GitPush 11 12
+16:31:16.361717 pkt-line.c:80 packet: fetch< 17abde8439d17d49676f549f357f45eb2adce868 refs/remotes/db48x/master
+<pre>
+
+> > So there's an actual protocol error here; the first 13 lines
+> > of git protocol were not sent.
+> >
+> > Question now is, where is the mangling happening?
+> >
+> > * Fairly sure it's not on the local side's sendGitUpdate,
+> > where "git upload-pack ." is simply run and fed over ssh.
+> > * Could be in gitPushHelper, perhaps it's failing to write
+> > some of the first lines somehow?
+> > * Could be something on the remote side is consuming stdin
+> > that is not supposed to, and eats some of the protocol.
+> >
+> >
+> > I added debug dumping to gitPushHelper, and it seems to be
+> > reading the same truncated data, so it seems the problem is not there.
+> >
+> > Aha! The problem comes from stdin/stdInput confusion here:
+
+ req NeedGitPush gitPushMarker $ \_ -> do
+ hin <- dup stdInput
+ hout <- dup stdOutput
+ hClose stdin
+ hClose stdout
+
+> > A line read from stdin just before the dup gets the first line of the protocol
+> > as expected. But reading from stdInput starts with a later line.
+> > Apparently data is being buffered in the stdin Handle, so gitPushHelper,
+> > which reads from the Fd, does not see it.
+> >
+> > Here's a simple test case. Feeding this 2 lines on stdin will
+> > print the first and then fail with "hGetLine: end of file".
+> > The second line is lost in the buffer. This test case behaves
+> > like that reliably, so I'm surprised propellor only fails sometimes.
+
+ main = do
+ l <- hGetLine stdin
+ print l
+ bob <- fdToHandle stdInput
+ l2 <- hGetLine bob
+ print l2
+
+> > > I thought I'd fixed this by disabling buffering of stdin, but
+> > > it seems not.
+
+> > > > Seems really [[done]] at last! --[[Joey]]
diff --git a/doc/todo/unpropelling_a_host.mdwn b/doc/todo/unpropelling_a_host.mdwn
new file mode 100644
index 00000000..5c31bd90
--- /dev/null
+++ b/doc/todo/unpropelling_a_host.mdwn
@@ -0,0 +1,9 @@
+We discussed at DebConf the need for a property that removes propellor from a host. It would run itself at the end of the spin. It needs to nuke `/usr/local/propellor`. To what extent can it remove propellor's build dependencies? I can see two problems to be resolved before writing any code.
+
+1. There is no standard way to remove cabal and stack packages from `/root` without potentially nuking stuff the user wants to keep. So maybe the property should remove only OS packages? I.e. best used on `OSOnly` hosts/chroots.
+
+2. What if another property on the host installs some or all of those build dependencies? This property would be cancelled out by the unpropellor property. Maybe properties that install packages need to [[set info about the packages that are meant to remain installed|todo/metapackage]]?
+
+The unpropellor property could just nuke `/usr/local/propellor` and leave it at that. But then the sbuild module would need to maintain a list of propellor's build deps to remove from the newly created chroot, which is a third copy of the list..
+
+--spwhitton
diff --git a/doc/todo/usage__47__help_text_improvements.mdwn b/doc/todo/usage__47__help_text_improvements.mdwn
new file mode 100644
index 00000000..80fffb3d
--- /dev/null
+++ b/doc/todo/usage__47__help_text_improvements.mdwn
@@ -0,0 +1,3 @@
+I started out looking at how to make usage.mdwn into a man page, but that's a little more work than I wanted to do tonight. Instead, I added more information to the usage message. Commit is fa0e8d83 on iabak:~db48x/propellor if you want it.
+
+> merged [[done]] tnx --[[Joey]]
diff --git a/doc/todo/usage__47__help_text_improvements/comment_1_66878945cdb57d06849337262d939701._comment b/doc/todo/usage__47__help_text_improvements/comment_1_66878945cdb57d06849337262d939701._comment
new file mode 100644
index 00000000..f30eae46
--- /dev/null
+++ b/doc/todo/usage__47__help_text_improvements/comment_1_66878945cdb57d06849337262d939701._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-12-27T02:46:19Z"
+ content="""
+I don't like the use of tabs in that; it may be that with some terminal
+with an unusual tab stop, the things don't align.
+
+It would probably be simplest to put the description in the line under the
+option.
+
+BTW, the Makefile can build propellor.1 out of usage.mdwn
+"""]]
diff --git a/doc/todo/usage__47__help_text_improvements/comment_2_d531a45851cdef87a8f7b8182b3d04ce._comment b/doc/todo/usage__47__help_text_improvements/comment_2_d531a45851cdef87a8f7b8182b3d04ce._comment
new file mode 100644
index 00000000..62cf1fe4
--- /dev/null
+++ b/doc/todo/usage__47__help_text_improvements/comment_2_d531a45851cdef87a8f7b8182b3d04ce._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="db48x"
+ avatar="http://cdn.libravatar.org/avatar/ad2688127feb555a92154b16d8eeb5d3"
+ subject="comment 2"
+ date="2016-12-27T06:12:52Z"
+ content="""
+/me facepalms; of course it can. I guess I saw the 'git commit' in the install target and disregarded the rest.
+
+I removed the tabs from the usage. It's a lot longer, but I suppose it gets the job done.
+
+
+"""]]
diff --git a/doc/todo/use_stack_for_remote_building_propellor.mdwn b/doc/todo/use_stack_for_remote_building_propellor.mdwn
index 265596df..8c8751e7 100644
--- a/doc/todo/use_stack_for_remote_building_propellor.mdwn
+++ b/doc/todo/use_stack_for_remote_building_propellor.mdwn
@@ -1,3 +1,16 @@
Among other features [stack](https://github.com/commercialhaskell/stack/) provides a clean and deep dependency management system that even takes care of installing toolchain (ghc, alex, happy, cabal...) in a segregated environment. Building remote propellor with stack would remove the limitation that code should be compilable with stock ghc from package manager. I have done some preliminary work on this feature in my [github clone](https://github.com/abailly/propellor) for propellor, currently from 2.17.2 branch (I wanted to reuse existing properties). The code is mostly in [Bootstrap](https://github.com/abailly/propellor/blob/master/src/Propellor/Bootstrap.hs) and is currently limited to linux systems. Adapting to FreeBsd should be straightforward as this is supported by slack and there are native builds available.
If there is interest in such a feature I would be happy to move it to HEAD and provide a patch.
+
+> I've implemented a bootstrapWith property, which can be added to a Host
+> to make it use stack:
+>
+> & bootstrapWith (Robustly Stack)
+>
+> So, for a propellor install that uses stack entirely, use
+> `stack install propellor` to install it to your laptop,
+> use `propellor --init` to set up `~/.propellor/config,hs`,
+> and in the config file, add the above property to all your
+> Hosts (perhaps using `map` ..).
+>
+> I feel that's enough to call this [[done]]. --[[Joey]]