summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/Linux.mdwn3
-rw-r--r--doc/README.mdwn6
-rw-r--r--doc/download.mdwn5
-rw-r--r--doc/forum/Compatibility_between_different_software_versions.mdwn1
-rw-r--r--doc/forum/Compatibility_between_different_software_versions/comment_1_1bc12b78e09c7060f4b5c434004b4b7f._comment12
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system.mdwn36
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_10_7982113b64a7884ce95ff38a6d876e2e._comment7
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_11_b1ad266b5c34b600d2d724bf5ffc40de._comment8
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_12_4baf7efcc6f9c50e3aebd663b7792279._comment23
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_13_2f8c7bb7f8ffb734a99ac3d7b28e2d62._comment15
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_1_2daa4574bce2179bfd7e9e505de3f7b0._comment8
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_2_98fb34d4e76bab6ef7a981c87533f395._comment14
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_3_047bca6e0676f0d93338d4eff20825bf._comment18
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_4_fc50b46606eacf59e5db227760ce38ab._comment24
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_5_df27f39bfb7104b4440c972b71f586e4._comment17
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_6_1410b386c0f3e1ff41adb068dd611f10._comment12
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_7_a3de897d9d056fcb6821f3b03485ede5._comment13
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_8_ca5d1f161c037c09fe853c56281f88bc._comment18
-rw-r--r--doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_9_eebdf852c9d73c7b11b184b7654aa78c._comment16
-rw-r--r--doc/forum/Docker.hs_will_Break_in_Stretch.mdwn16
-rw-r--r--doc/forum/Docker.hs_will_Break_in_Stretch/comment_1_8a4f16ae6d04b9d4bedb437ef333562b._comment11
-rw-r--r--doc/forum/Error_building_on_remote_host.mdwn31
-rw-r--r--doc/forum/Error_building_on_remote_host/comment_1_f0f6f241e971d048486ae159585a4ab2._comment21
-rw-r--r--doc/forum/Error_building_on_remote_host/comment_2_9029575e378c3ed67ea7b7d9fd0a11b5._comment13
-rw-r--r--doc/forum/Error_building_on_remote_host/comment_3_3090e63b93e00d6eca95ca8fe523f5b8._comment8
-rw-r--r--doc/forum/Error_building_on_remote_host/comment_4_8a3eac770c1bee9295272c46f022a03c._comment8
-rw-r--r--doc/forum/Error_building_on_remote_host/comment_4_c2e07d9bfba84fbdcf408a09965d6cb6._comment10
-rw-r--r--doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap.mdwn3
-rw-r--r--doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_1_8ab6b313c80486f8f87a5e13e830bfa9._comment20
-rw-r--r--doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_2_773fc1441dd06e9dd41508bd800298eb._comment13
-rw-r--r--doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_3_f48a6191c56bed41eda55436f0aa3e9c._comment15
-rw-r--r--doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_4_b1769231a633ad2b978ee4c9fa90591c._comment9
-rw-r--r--doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_5_6dc24952c8efa31a401191a8cf2d0b39._comment14
-rw-r--r--doc/forum/Git.cloned_deletes_harmless_empty_directory.mdwn3
-rw-r--r--doc/forum/Git.cloned_deletes_harmless_empty_directory/comment_1_7cd0521c6d071b25852f8355f4f61f94._comment20
-rw-r--r--doc/forum/Git.cloned_deletes_harmless_empty_directory/comment_2_289f157f129511242d93beae76fd03a3._comment11
-rw-r--r--doc/forum/How_to_create_a_property_with_info.mdwn65
-rw-r--r--doc/forum/How_to_create_a_property_with_info/comment_1_819902ee6b8e571f735dd2c9c93c49a9._comment29
-rw-r--r--doc/forum/How_to_create_a_property_with_info/comment_2_1c2b3cb54f27fb6b6bb5de9d159dd34f._comment15
-rw-r--r--doc/forum/How_to_create_a_property_with_info/comment_3_6cf0360b4922a131bca33d33acf078be._comment11
-rw-r--r--doc/forum/Inherited_Variables....mdwn26
-rw-r--r--doc/forum/Inherited_Variables.../comment_1_082e5d5b8e25335bc90577abcfef1d21._comment15
-rw-r--r--doc/forum/Inherited_Variables.../comment_2_988319ed6de46eff2eac0d5ef36382f9._comment15
-rw-r--r--doc/forum/Inherited_Variables.../comment_3_acf78fa9f732f070bf73c2ab601464ee._comment8
-rw-r--r--doc/forum/Inherited_Variables.../comment_4_5bf7b1f69b48b4d9c516d424e4438208._comment21
-rw-r--r--doc/forum/Inherited_Variables.../comment_5_6fbd29f568ec8b97be47874e2aac57a3._comment20
-rw-r--r--doc/forum/Manage_multiple_different_projects_with_propellor.mdwn7
-rw-r--r--doc/forum/Manage_multiple_different_projects_with_propellor/comment_1_dbad48163b2efd6434ea7c37a72dfd30._comment14
-rw-r--r--doc/forum/Modules_with_Multiple_cmdProperty_causing_build_failures/comment_2_5afe0f200d7139499ef4b01ea6445206._comment11
-rw-r--r--doc/forum/Sbuild_chroot_are_not_compatible_with_schroot.mdwn29
-rw-r--r--doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_1_59ac4661a896a514ce953a0069341869._comment24
-rw-r--r--doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_2_579894632e567a08d83e306be5e355b2._comment84
-rw-r--r--doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_3_6aeee8ba74b363d26a49d6773c5d5014._comment12
-rw-r--r--doc/forum/Supported_OS/comment_3_f2924708a819b962ba7ed690019601ed._comment7
-rw-r--r--doc/forum/Using_propellor_for_continers_only.mdwn5
-rw-r--r--doc/forum/Using_propellor_for_continers_only/comment_1_95e8b7103f248d93570fecb6b8999996._comment20
-rw-r--r--doc/forum/Using_propellor_for_continers_only/comment_2_42b45a126cfdf1dfc370b166c8042690._comment8
-rw-r--r--doc/forum/Using_propellor_for_continers_only/comment_3_cd4b9b9e160469e9f0b105f6c40a4ef8._comment54
-rw-r--r--doc/forum/Using_propellor_for_continers_only/comment_4_9dc985b26c29b9ce21e6c75ec03f6262._comment21
-rw-r--r--doc/forum/Using_propellor_for_continers_only/comment_5_8552ce821f5a3b386cb9e6ad417670ec._comment8
-rw-r--r--doc/forum/Why_downloading_package_list_from_hackage.haskell.org__63__/comment_5_61d7ef8a61ac7b922c810825d794da5f._comment8
-rw-r--r--doc/forum/Why_downloading_package_list_from_hackage.haskell.org__63__/comment_6_ceddc6d118b7ea71ec8f498960a5fe97._comment8
-rw-r--r--doc/forum/Work_on_OS_X.mdwn5
-rw-r--r--doc/forum/Work_on_OS_X/comment_1_6d7d5b89f1de9604718f7973e4b3eeb1._comment20
-rw-r--r--doc/forum/Work_on_OS_X/comment_2_00b20c240fc13bed6dc54e5b985b41e2._comment17
-rw-r--r--doc/forum/Work_on_OS_X/comment_3_294f4783522a8e4887793aac921ee546._comment14
-rw-r--r--doc/forum/Work_on_OS_X/comment_4_74b579d4d590432b6bd236ccb929cc11._comment16
-rw-r--r--doc/forum/creating_Bind9_configuration.mdwn9
-rw-r--r--doc/forum/creating_Bind9_configuration/comment_1_0798f44e1f5a91fbc91c0b472ad92bfa._comment29
-rw-r--r--doc/forum/creating_Bind9_configuration/comment_2_f1bffbdd7c2ebab2dd9518ee024e7a92._comment18
-rw-r--r--doc/forum/creating_Bind9_configuration/comment_3_6b4d73b17d87d00845fda26431ded422._comment10
-rw-r--r--doc/forum/host_to_deal_with_dpkg::options.mdwn41
-rw-r--r--doc/forum/host_to_deal_with_dpkg::options/comment_1_641dcb7be62151bdc97fd5e574f334d0._comment12
-rw-r--r--doc/forum/host_to_deal_with_dpkg::options/comment_2_bac8129b570ce216ef9f6aa6c0e12c1e._comment9
-rw-r--r--doc/forum/host_to_deal_with_dpkg::options/comment_3_62d671fb3c787aafcd4d058975208f75._comment10
-rw-r--r--doc/forum/propellor_4.7.6_does_not_compile_on_jessie.mdwn32
-rw-r--r--doc/forum/propellor_4.7.6_does_not_compile_on_jessie/comment_1_c35f458b4c958f6397fe726f5676b700._comment7
-rw-r--r--doc/forum/propellor_and_gpg2.mdwn14
-rw-r--r--doc/forum/propellor_and_gpg2/comment_1_4b732110f59f78f73fdfb745bdd9c0dd._comment13
-rw-r--r--doc/forum/propellor_failed_to_sign_the_commit.mdwn30
-rw-r--r--doc/forum/propellor_failed_to_sign_the_commit/comment_1_c1dab7554841bd88d2109e9d46b31102._comment30
-rw-r--r--doc/forum/propellor_failed_to_sign_the_commit/comment_2_21ff16e0871e7069749cd6c47a6fc8fe._comment9
-rw-r--r--doc/forum/propellor_failed_to_sign_the_commit/comment_3_f0e087ed1a80f42d11d34fb215183205._comment11
-rw-r--r--doc/haskell_newbie.mdwn6
-rw-r--r--doc/index.mdwn2
-rw-r--r--doc/install.mdwn4
-rw-r--r--doc/news/version_3.1.1.mdwn4
-rw-r--r--doc/news/version_3.1.2.mdwn22
-rw-r--r--doc/news/version_3.2.0.mdwn17
-rw-r--r--doc/news/version_3.2.1.mdwn5
-rw-r--r--doc/news/version_3.2.2.mdwn5
-rw-r--r--doc/news/version_4.7.3.mdwn3
-rw-r--r--doc/news/version_4.7.4.mdwn7
-rw-r--r--doc/news/version_4.7.5.mdwn3
-rw-r--r--doc/news/version_4.7.6.mdwn6
-rw-r--r--doc/news/version_4.7.7.mdwn11
-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
-rw-r--r--doc/usage.mdwn12
-rw-r--r--doc/user/craige.mdwn1
-rw-r--r--doc/user/spwhitton.mdwn1
146 files changed, 2415 insertions, 64 deletions
diff --git a/doc/Linux.mdwn b/doc/Linux.mdwn
index 00276f69..ca0cfd65 100644
--- a/doc/Linux.mdwn
+++ b/doc/Linux.mdwn
@@ -1,5 +1,6 @@
Propellor was written to manage Linux systems.
-It supports Debian and Debian-derived distributions.
+It supports Debian and Debian-derived distributions,
+as well as Arch Linux.
Support for other distributions should not be too hard to add.
Indeed, Propellor has been ported to [[FreeBSD]] now!
diff --git a/doc/README.mdwn b/doc/README.mdwn
index 31d222c1..a4a38c5f 100644
--- a/doc/README.mdwn
+++ b/doc/README.mdwn
@@ -12,8 +12,8 @@ repository to each host it manages, in a
[components](http://propellor.branchable.com/components/)
for details.
-Properties are defined using Haskell. Edit `~/.propellor/config.hs`
-to get started. There is fairly complete
+Properties are defined using Haskell in the file `~/.propellor/config.hs`.
+There is fairly complete
[API documentation](http://hackage.haskell.org/package/propellor/),
which includes many built-in Properties for dealing with
[Apt](http://hackage.haskell.org/package/propellor/docs/Propellor-Property-Apt.html)
@@ -41,6 +41,8 @@ see [configuration for the Haskell newbie](https://propellor.branchable.com/hask
1. Get propellor installed on your development machine (ie, laptop).
`cabal install propellor`
or
+ `stack install propellor`
+ or
`apt-get install propellor`
2. Run `propellor --init` ; this will set up a `~/.propellor/` git
repository for you.
diff --git a/doc/download.mdwn b/doc/download.mdwn
new file mode 100644
index 00000000..6fe1ca33
--- /dev/null
+++ b/doc/download.mdwn
@@ -0,0 +1,5 @@
+Propellor's source code and some example configs are in a git repository:
+
+`git clone git://propellor.branchable.com/propellor`
+
+See the [[README]] for details on installing and configuring propellor.
diff --git a/doc/forum/Compatibility_between_different_software_versions.mdwn b/doc/forum/Compatibility_between_different_software_versions.mdwn
new file mode 100644
index 00000000..b2de3439
--- /dev/null
+++ b/doc/forum/Compatibility_between_different_software_versions.mdwn
@@ -0,0 +1 @@
+I'm just asking myself how (or if) we can guarantee compatibility between different versions of an application. Let's take "prosody" as an example. Even if we use the "DebianLike" property, there might be different versions of "prosody" in Debian Stable and Debian Unstable and therefore different configurations options available. Is there a way to catch those cases? Another example would be a "generic" property (which works for DebianLike and ArchLinux) for a specific software, but inside these distributions are different versions of the application. Even a "Prosody.installed" might be problematic, if the package has been renamed in a newer Debian release.
diff --git a/doc/forum/Compatibility_between_different_software_versions/comment_1_1bc12b78e09c7060f4b5c434004b4b7f._comment b/doc/forum/Compatibility_between_different_software_versions/comment_1_1bc12b78e09c7060f4b5c434004b4b7f._comment
new file mode 100644
index 00000000..97ab02e8
--- /dev/null
+++ b/doc/forum/Compatibility_between_different_software_versions/comment_1_1bc12b78e09c7060f4b5c434004b4b7f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-31T22:26:42Z"
+ content="""
+`withOS` or `getOS` is often used to deal with such differences,
+varying behavior depending on the Host's defined OS. For example,
+Propellor.Property.Borg.installed does one thing on Debian jessie
+and another thing on other versions of Debian. And
+Propellor.Property.Apt.getMirror generates different urls for Debian and
+Ubuntu.
+"""]]
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system.mdwn b/doc/forum/DiskImage_creation_does_not_work_on_my_system.mdwn
new file mode 100644
index 00000000..f7f56889
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system.mdwn
@@ -0,0 +1,36 @@
+Hello, I am trying to create a virtualbox image from my stretch system.
+
+But I hve two problems :)
+
+I took your example from the DiskImage property, but in the end, I got this
+
+/srv/diskimages/soleil.img.chroot no services started ... ok
+/srv/diskimages/soleil.img.chroot has Operating System (Debian Linux Unstable) X86_32 ... ok
+/srv/diskimages/soleil.img.chroot apt installed linux-image-i686 ... ok
+/srv/diskimages/soleil.img.chroot grub package installed ... ok
+/srv/diskimages/soleil.img.chroot root has insecure password ... done
+/srv/diskimages/soleil.img.chroot account for soleil ... ok
+/srv/diskimages/soleil.img.chroot soleil has insecure password ... done
+/srv/diskimages/soleil.img.chroot user soleil in group audio ... ok
+/srv/diskimages/soleil.img.chroot user soleil in group cdrom ... ok
+/srv/diskimages/soleil.img.chroot user soleil in group dip ... ok
+/srv/diskimages/soleil.img.chroot user soleil in group floppy ... ok
+/srv/diskimages/soleil.img.chroot user soleil in group video ... ok
+/srv/diskimages/soleil.img.chroot user soleil in group plugdev ... ok
+/srv/diskimages/soleil.img.chroot user soleil in group netdev ... ok
+/srv/diskimages/soleil.img.chroot user soleil is in standard desktop groups ... ok
+/srv/diskimages/soleil.img.chroot cache cleaned ... ok
+ 0 0% 0.00kB/s 0:00:00 (xfr#0, to-chk=0/3)
+ 930 0% 1.77kB/s 0:00:00 (xfr#3, to-chk=0/11069)
+chroot: impossible d'exécuter la commande « update-initramfs »: No such file or directory
+loop deleted : /dev/loop0
+
+I will try to add the pacakge which contain update-initramfs and report back
+
+
+the second problem is thaht virtualbox is no more part of stretch.
+So it is not possible to create a virtualbox image.
+
+Cheers
+
+Frederic
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_10_7982113b64a7884ce95ff38a6d876e2e._comment b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_10_7982113b64a7884ce95ff38a6d876e2e._comment
new file mode 100644
index 00000000..3ccfc4db
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_10_7982113b64a7884ce95ff38a6d876e2e._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2017-08-24T15:35:22Z"
+ content="""
+I've implemented the DiskImage type class.
+"""]]
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_11_b1ad266b5c34b600d2d724bf5ffc40de._comment b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_11_b1ad266b5c34b600d2d724bf5ffc40de._comment
new file mode 100644
index 00000000..79debc75
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_11_b1ad266b5c34b600d2d724bf5ffc40de._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="picca"
+ avatar="http://cdn.libravatar.org/avatar/7e61c80d28018b10d31f6db7dddb864c"
+ subject="comment 11"
+ date="2017-08-24T18:36:12Z"
+ content="""
+Thanks a lot joey.
+"""]]
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_12_4baf7efcc6f9c50e3aebd663b7792279._comment b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_12_4baf7efcc6f9c50e3aebd663b7792279._comment
new file mode 100644
index 00000000..b6de7d0a
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_12_4baf7efcc6f9c50e3aebd663b7792279._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="picca"
+ avatar="http://cdn.libravatar.org/avatar/7e61c80d28018b10d31f6db7dddb864c"
+ subject="comment 12"
+ date="2017-08-24T19:11:24Z"
+ content="""
+If I understand correctly, the new typeclass need to provide a method which return the
+(RawDiskImage filename). In the process we have at least 2 cache level
+One for the chroot, and one for the RawImage.
+
+I was wondering if these cache (side effect) could not be regrouped
+under /var/cache/propellor instead of putting this randomly everywhere on the disk.
+
+This way It should be possible to \"reset\" propellor by removing the cache in order to force
+a cache rebuild.
+
+I think about this because I am not aware as a user of all these \"side effects\".
+
+propellor --purge-cache ;)
+
+cheers and thanks again
+
+"""]]
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_13_2f8c7bb7f8ffb734a99ac3d7b28e2d62._comment b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_13_2f8c7bb7f8ffb734a99ac3d7b28e2d62._comment
new file mode 100644
index 00000000..74dc528e
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_13_2f8c7bb7f8ffb734a99ac3d7b28e2d62._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2017-08-24T21:11:07Z"
+ content="""
+Yes, there are two levels of caches. This does make updating the images a
+whole lot faster!
+
+Some systems don't have a very large /var partition and so I think it's
+better to let the user pick where they go. The documentation could
+certainly (always) be improved.
+
+Note that reverting any of the properties in DiskImage will clean up
+all the cache files as well as the final disk image.
+"""]]
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_1_2daa4574bce2179bfd7e9e505de3f7b0._comment b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_1_2daa4574bce2179bfd7e9e505de3f7b0._comment
new file mode 100644
index 00000000..90283031
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_1_2daa4574bce2179bfd7e9e505de3f7b0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="picca"
+ avatar="http://cdn.libravatar.org/avatar/7e61c80d28018b10d31f6db7dddb864c"
+ subject="comment 1"
+ date="2017-08-22T07:02:51Z"
+ content="""
+Haaaaaaa the format of the post is ugly. Is it possible to change this ?
+"""]]
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_2_98fb34d4e76bab6ef7a981c87533f395._comment b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_2_98fb34d4e76bab6ef7a981c87533f395._comment
new file mode 100644
index 00000000..e8898a96
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_2_98fb34d4e76bab6ef7a981c87533f395._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="picca"
+ avatar="http://cdn.libravatar.org/avatar/7e61c80d28018b10d31f6db7dddb864c"
+ subject="comment 2"
+ date="2017-08-22T07:12:13Z"
+ content="""
+OK, I tryed to install the wrong kernel so the initramfs was not installed.
+
+So now the only real problem is the virtualbox one ;)
+
+Cheers
+
+Frederic
+"""]]
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_3_047bca6e0676f0d93338d4eff20825bf._comment b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_3_047bca6e0676f0d93338d4eff20825bf._comment
new file mode 100644
index 00000000..aeeaf724
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_3_047bca6e0676f0d93338d4eff20825bf._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="picca"
+ avatar="http://cdn.libravatar.org/avatar/7e61c80d28018b10d31f6db7dddb864c"
+ subject="comment 3"
+ date="2017-08-22T07:36:06Z"
+ content="""
+It seems that we do not need virtualbox in order to generate a vmdk image
+
+I installed *qemu-utils* and then
+
+ # qemu-img convert -O vmdk soleil.img soleil.vmdk
+ # file soleil.vmdk
+ soleil.vmdk: VMware4 disk image
+
+what about using this solution instead of the virtualbox one ?
+
+Cheers
+"""]]
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_4_fc50b46606eacf59e5db227760ce38ab._comment b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_4_fc50b46606eacf59e5db227760ce38ab._comment
new file mode 100644
index 00000000..27b70a57
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_4_fc50b46606eacf59e5db227760ce38ab._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="picca"
+ avatar="http://cdn.libravatar.org/avatar/7e61c80d28018b10d31f6db7dddb864c"
+ subject="comment 4"
+ date="2017-08-22T08:42:35Z"
+ content="""
+ vmdkBuiltFor :: FilePath -> RevertableProperty DebianLike UnixLike
+ vmdkBuiltFor diskimage = (setup <!> cleanup)
+ `describe` (vmdkfile ++ \" built\")
+ where
+ vmdkfile = diskimage ++ \".vmdk\"
+ setup = cmdProperty \"qemu-img\"
+ [ \"convert\"
+ , \"-O\", \"vmdk\"
+ , diskimage, vmdkfile
+ ]
+ `changesFile` vmdkfile
+ `onChange` File.mode vmdkfile (combineModes (ownerWriteMode : readModes))
+ `requires` Apt.installed [\"qemu-utils\"]
+ `requires` File.notPresent vmdkfile
+ cleanup = File.notPresent vmdkfile
+
+seems to work :))
+"""]]
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_5_df27f39bfb7104b4440c972b71f586e4._comment b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_5_df27f39bfb7104b4440c972b71f586e4._comment
new file mode 100644
index 00000000..374de327
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_5_df27f39bfb7104b4440c972b71f586e4._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-08-23T15:49:27Z"
+ content="""
+The `vmdkBuiltFor` property is provided to make a disk image
+usable with virtualbox. If your distribution chooses not to include
+virtualbox and so you don't have virtualbox installed, what good would
+such an image be to you?
+
+To use `vmdkBuiltFor` you must already have a disk image file, which qemu
+etc can already use.
+
+"qemu-img convert" writes a whole disk image file. This is a much more
+expensive operation than what `vmdkBuiltFor` currently does, which creates
+a tiny text file that makes virtualbox use the existing disk image.
+"""]]
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_6_1410b386c0f3e1ff41adb068dd611f10._comment b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_6_1410b386c0f3e1ff41adb068dd611f10._comment
new file mode 100644
index 00000000..5bd1ab6d
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_6_1410b386c0f3e1ff41adb068dd611f10._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="picca"
+ avatar="http://cdn.libravatar.org/avatar/7e61c80d28018b10d31f6db7dddb864c"
+ subject="comment 6"
+ date="2017-08-23T19:42:31Z"
+ content="""
+this is good for me because I prepare a virtualbox image not for me but for our windows / MacOSX users.
+
+This is why I need to build these images.
+
+thanks for your help
+"""]]
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_7_a3de897d9d056fcb6821f3b03485ede5._comment b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_7_a3de897d9d056fcb6821f3b03485ede5._comment
new file mode 100644
index 00000000..7c0995ff
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_7_a3de897d9d056fcb6821f3b03485ede5._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2017-08-23T21:07:41Z"
+ content="""
+The vmdk text file is so small that I did think about just having propellor
+generate it by itself. I don't know how stable/documented it is however.
+
+I suppose that if you're distributing a vmdk image to others, you would not
+want to use the text file format, since that hard-codes the path to the
+.img file. So, perhaps there should be separate properties for vmdk text
+files that point at disk images and self-contained vmdk images.
+"""]]
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_8_ca5d1f161c037c09fe853c56281f88bc._comment b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_8_ca5d1f161c037c09fe853c56281f88bc._comment
new file mode 100644
index 00000000..9891845e
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_8_ca5d1f161c037c09fe853c56281f88bc._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="picca"
+ avatar="http://cdn.libravatar.org/avatar/7e61c80d28018b10d31f6db7dddb864c"
+ subject="comment 8"
+ date="2017-08-24T07:04:07Z"
+ content="""
+It is true that my uszer prefer the embeded virtual image :).
+
+Maybe we could have a DiskImage export property which could take an output format type
+I do not know how many format are out there for these kind of virtual machines.
+Maybe this could be also a way to prepare images for the cloud. (I do not use this mayself but why not).
+What is the difference between Diskimage and containers ?
+
+Cheers
+
+Frederic
+
+"""]]
diff --git a/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_9_eebdf852c9d73c7b11b184b7654aa78c._comment b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_9_eebdf852c9d73c7b11b184b7654aa78c._comment
new file mode 100644
index 00000000..1b1f1e64
--- /dev/null
+++ b/doc/forum/DiskImage_creation_does_not_work_on_my_system/comment_9_eebdf852c9d73c7b11b184b7654aa78c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2017-08-24T14:39:05Z"
+ content="""
+The `DiskImage` data type could be expanded to support different output
+formats.
+
+Or, a type class could be used, so eg:
+
+ imageBuilt :: DiskImage d => d -> (FilePath -> Chroot) -> TableType -> [PartSpec ()] -> RevertableProperty (HasInfo + DebianLike) Linux
+
+The type class would just need a function to convert from the raw disk
+image to the desired file format. Then anyone could add whatever disk image
+formats they want (which can probably shade into containers in some cases).
+"""]]
diff --git a/doc/forum/Docker.hs_will_Break_in_Stretch.mdwn b/doc/forum/Docker.hs_will_Break_in_Stretch.mdwn
new file mode 100644
index 00000000..c89c995c
--- /dev/null
+++ b/doc/forum/Docker.hs_will_Break_in_Stretch.mdwn
@@ -0,0 +1,16 @@
+G'day Joey!
+
+I'm in the process of deploying Docker infrastructure via Propellor on both Jessie and Stretch and I've come to discover that Docker.io did not make it into Stretch:
+
+* [docker.io REMOVED from testing](https://packages.qa.debian.org/d/docker.io/news/20161012T163916Z.html)
+* [docker.io - Linux container runtime](https://tracker.debian.org/pkg/docker.io)
+* [Excuse for docker.io](https://qa.debian.org/excuses.php?package=docker.io)
+
+So the below from Docker.hs will fail beyond Jessie:
+
+ installed :: Property DebianLike
+ installed = Apt.installed ["docker.io"]
+
+Before I embarked on my own path to re-implement the above (probably based on [How to install Docker engine on Debian 9 Stretch Linux](https://linuxconfig.org/how-to-install-docker-engine-on-debian-9-stretch-linux)), I thought I'd see what you thought might be the way to resolve this, so that my work could be contributed upstream (if suitable).
+
+Thanks!
diff --git a/doc/forum/Docker.hs_will_Break_in_Stretch/comment_1_8a4f16ae6d04b9d4bedb437ef333562b._comment b/doc/forum/Docker.hs_will_Break_in_Stretch/comment_1_8a4f16ae6d04b9d4bedb437ef333562b._comment
new file mode 100644
index 00000000..949f8d0c
--- /dev/null
+++ b/doc/forum/Docker.hs_will_Break_in_Stretch/comment_1_8a4f16ae6d04b9d4bedb437ef333562b._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-02-02T17:28:49Z"
+ content="""
+Apparently the Debian way to install docker will be from backports.
+<https://bugs.debian.org/cgi-bin/bugreport.cgi?att=3;bug=781554;msg=9>
+
+Note that I'm no longer using any docker Properties myself, so
+propellor users who are will need to send patches..
+"""]]
diff --git a/doc/forum/Error_building_on_remote_host.mdwn b/doc/forum/Error_building_on_remote_host.mdwn
new file mode 100644
index 00000000..240db464
--- /dev/null
+++ b/doc/forum/Error_building_on_remote_host.mdwn
@@ -0,0 +1,31 @@
+I recently updated to the latest Propellor and now I'm getting an error building on a remote host:
+
+ [86 of 94] Compiling Propellor.Bootstrap ( src/Propellor/Bootstrap.hs, dist/build/propellor-config/propellor-config-tmp/Propellor/Bootstrap.o )
+
+ src/Propellor/Bootstrap.hs:237:22:
+ No instance for (Typeable Bootstrapper)
+ arising from a use of `fromInfo'
+ Possible fix:
+ add an instance declaration for (Typeable Bootstrapper)
+ In the expression: fromInfo (maybe mempty hostInfo mh)
+ In a stmt of a 'do' block:
+ case fromInfo (maybe mempty hostInfo mh) of {
+ NoInfoVal
+ -> do { bs <- getGitConfigValue "propellor.buildsystem";
+ case bs of {
+ Just "stack" -> ...
+ _ -> ... } }
+ InfoVal bs
+ -> case getBuilder bs of {
+ Cabal -> cabalBuild msys
+ Stack -> stackBuild msys } }
+ In the second argument of `($)', namely
+ `do { case fromInfo (maybe mempty hostInfo mh) of {
+ NoInfoVal -> do { ... }
+ InfoVal bs
+ -> case getBuilder bs of {
+ Cabal -> ...
+ Stack -> ... } } }'
+ propellor: cabal build failed
+
+I guess I'm missing something, but not sure what?
diff --git a/doc/forum/Error_building_on_remote_host/comment_1_f0f6f241e971d048486ae159585a4ab2._comment b/doc/forum/Error_building_on_remote_host/comment_1_f0f6f241e971d048486ae159585a4ab2._comment
new file mode 100644
index 00000000..eca6c8c6
--- /dev/null
+++ b/doc/forum/Error_building_on_remote_host/comment_1_f0f6f241e971d048486ae159585a4ab2._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="mithrandi"
+ avatar="http://cdn.libravatar.org/avatar/869963bdf99b541c9f0bbfb04b0320f1"
+ subject="comment 1"
+ date="2017-07-25T22:22:49Z"
+ content="""
+I tried adding:
+
+ & bootstrapWith (Robustly Stack)
+
+But that fails trying to install stack:
+
+ Fetched 413 kB in 7s (54.3 kB/s)
+ Reading package lists...
+ E: Unable to locate package haskell-stack
+ sh: 1: stack: not found
+ sh: 1: stack: not found
+
+That's not really too surprising, of course, since this package isn't in jessie (or stretch, for that matter).
+
+"""]]
diff --git a/doc/forum/Error_building_on_remote_host/comment_2_9029575e378c3ed67ea7b7d9fd0a11b5._comment b/doc/forum/Error_building_on_remote_host/comment_2_9029575e378c3ed67ea7b7d9fd0a11b5._comment
new file mode 100644
index 00000000..34750553
--- /dev/null
+++ b/doc/forum/Error_building_on_remote_host/comment_2_9029575e378c3ed67ea7b7d9fd0a11b5._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="mithrandi"
+ avatar="http://cdn.libravatar.org/avatar/869963bdf99b541c9f0bbfb04b0320f1"
+ subject="comment 2"
+ date="2017-07-25T22:50:42Z"
+ content="""
+Okay, got it to work:
+
+1. Installed haskell-stack by hand from unstable (the package works fine even on jessie).
+2. Removed the \"dist\" directory in the remote /usr/local/propellor.
+
+After that the build was successful; I think that points to the original failure being due to the ancient GHC in jessie, but I'm not 100% sure.
+"""]]
diff --git a/doc/forum/Error_building_on_remote_host/comment_3_3090e63b93e00d6eca95ca8fe523f5b8._comment b/doc/forum/Error_building_on_remote_host/comment_3_3090e63b93e00d6eca95ca8fe523f5b8._comment
new file mode 100644
index 00000000..1790ac78
--- /dev/null
+++ b/doc/forum/Error_building_on_remote_host/comment_3_3090e63b93e00d6eca95ca8fe523f5b8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-07-26T00:49:51Z"
+ content="""
+The haskell-stack package is available in Debian stretch
+<https://packages.debian.org/search?keywords=haskell-stack>
+"""]]
diff --git a/doc/forum/Error_building_on_remote_host/comment_4_8a3eac770c1bee9295272c46f022a03c._comment b/doc/forum/Error_building_on_remote_host/comment_4_8a3eac770c1bee9295272c46f022a03c._comment
new file mode 100644
index 00000000..5129fb5d
--- /dev/null
+++ b/doc/forum/Error_building_on_remote_host/comment_4_8a3eac770c1bee9295272c46f022a03c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mithrandi"
+ avatar="http://cdn.libravatar.org/avatar/869963bdf99b541c9f0bbfb04b0320f1"
+ subject="comment 4"
+ date="2017-07-26T01:03:02Z"
+ content="""
+Oh, so it is! Must have misread something earlier.
+"""]]
diff --git a/doc/forum/Error_building_on_remote_host/comment_4_c2e07d9bfba84fbdcf408a09965d6cb6._comment b/doc/forum/Error_building_on_remote_host/comment_4_c2e07d9bfba84fbdcf408a09965d6cb6._comment
new file mode 100644
index 00000000..7d8f26fe
--- /dev/null
+++ b/doc/forum/Error_building_on_remote_host/comment_4_c2e07d9bfba84fbdcf408a09965d6cb6._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-07-26T00:52:20Z"
+ content="""
+Interesting that it works on newer ghc without an explict
+`Typeable Bootstrapper` instance.
+
+I've added the missing instance.
+"""]]
diff --git a/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap.mdwn b/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap.mdwn
new file mode 100644
index 00000000..61cd10cc
--- /dev/null
+++ b/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap.mdwn
@@ -0,0 +1,3 @@
+The mount command won't work when activating a swap partition/file, so we should call swapon instead.
+
+https://github.com/ArchiveTeam/glowing-computing-machine/tree/fstab-swap
diff --git a/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_1_8ab6b313c80486f8f87a5e13e830bfa9._comment b/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_1_8ab6b313c80486f8f87a5e13e830bfa9._comment
new file mode 100644
index 00000000..4a144df5
--- /dev/null
+++ b/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_1_8ab6b313c80486f8f87a5e13e830bfa9._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-04-05T02:17:00Z"
+ content="""
+This idea kind of makes sense, because swap partitions in /etc/fstab
+get swaponed at boot.
+
+But, the implementation doesn't take the types into account. The `mounted`
+property takes a FilePath for the mountpoint, but for swap that
+needs to be "none", which is not really a file-path. Also, the `fstabbed`
+property has a separate `SwapPartition` type, so making `mount` support
+swap partitions without using that type feels wrong.
+
+It might be simpler all round to treat swap partitions being able to
+be specified in /etc/fstab as a historical accident, which it kind of
+is (increasingly so, since eg systemd has other ways to accomplish
+that), and instead of shoehorning this into the `mounted` property,
+add a new `swaponed` property.
+"""]]
diff --git a/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_2_773fc1441dd06e9dd41508bd800298eb._comment b/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_2_773fc1441dd06e9dd41508bd800298eb._comment
new file mode 100644
index 00000000..62cabc0a
--- /dev/null
+++ b/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_2_773fc1441dd06e9dd41508bd800298eb._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="db48x@80bd751a72d5a80737e2f875342cf845629c7202"
+ nickname="db48x"
+ avatar="http://cdn.libravatar.org/avatar/ad2688127feb555a92154b16d8eeb5d3"
+ subject="comment 2"
+ date="2017-04-05T02:48:08Z"
+ content="""
+Yes, perhaps if it took an Option FilePath (am I saying this correctly in Haskellese?) it would be nicer.
+
+I don't mind much how it's structured; this was just the smallest obvious change, since it was failing to mount it. Perhaps breaking it up into smaller, more primitive, pieces would help. Fstab.mounted could = Fstab.fstabbed `onChange` Fstab.mounted, for instance, and then I could write Fstab.fstabbed `onChange` Swap.swapEnabled (oh, but Fstab.fstabbed already exists; I'm not using it because it replaces the whole file, which seems like an odd thing to do. Maybe call it Fstab.listed instead?).
+
+Also, for maximum irony I was just perusing your most recent dozen commits or so, and saw you enable Apt.serviceInstalledRunning \"swapspace\" on one of your machines. That's amazing; I had no idea it existed! I am re-evaluating all of my life choices now.
+"""]]
diff --git a/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_3_f48a6191c56bed41eda55436f0aa3e9c._comment b/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_3_f48a6191c56bed41eda55436f0aa3e9c._comment
new file mode 100644
index 00000000..95c69551
--- /dev/null
+++ b/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_3_f48a6191c56bed41eda55436f0aa3e9c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-04-05T03:08:30Z"
+ content="""
+I like the idea of composing smaller properties to build the current
+property, and add flexability.
+
+Renaming the existing `fstabbed` would probably be too much bother.
+(Also, I think I picked that name because it kind of hints that the
+existing fstab does not come out alive.)
+
+(The swapspace package is great if you can eat the now tiny overhead of a
+swap file compared to a swap partition.)
+"""]]
diff --git a/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_4_b1769231a633ad2b978ee4c9fa90591c._comment b/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_4_b1769231a633ad2b978ee4c9fa90591c._comment
new file mode 100644
index 00000000..ca04f945
--- /dev/null
+++ b/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_4_b1769231a633ad2b978ee4c9fa90591c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="db48x@80bd751a72d5a80737e2f875342cf845629c7202"
+ nickname="db48x"
+ avatar="http://cdn.libravatar.org/avatar/ad2688127feb555a92154b16d8eeb5d3"
+ subject="comment 4"
+ date="2017-04-05T06:39:49Z"
+ content="""
+I took a stab at implementing this. It compiles, but I've not tested it yet as I need to get some sleep; consider it a work in progress. Looks right to me though.
+"""]]
diff --git a/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_5_6dc24952c8efa31a401191a8cf2d0b39._comment b/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_5_6dc24952c8efa31a401191a8cf2d0b39._comment
new file mode 100644
index 00000000..f87500b2
--- /dev/null
+++ b/doc/forum/Fstab.mounted_could_call_swapon_when_activating_swap/comment_5_6dc24952c8efa31a401191a8cf2d0b39._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-04-06T23:51:08Z"
+ content="""
+Merged. Have not tested it either.
+
+On my Debian system, the swapon command does not support the
+`--no-headings` that you used. It's `--noheadings` here. Is that a typo in
+your patch?
+
+I've simply removed that option for now, since it probably won't
+hurt if it treats the heading like another device that's swapped on.
+"""]]
diff --git a/doc/forum/Git.cloned_deletes_harmless_empty_directory.mdwn b/doc/forum/Git.cloned_deletes_harmless_empty_directory.mdwn
new file mode 100644
index 00000000..ce3c192c
--- /dev/null
+++ b/doc/forum/Git.cloned_deletes_harmless_empty_directory.mdwn
@@ -0,0 +1,3 @@
+In my case I have carefully set up the directory that I'm going to clone into with the correct group ownership and setgid permission, so that the cloned files will also have the correct ownership. This change just checks to see if the directory actually has anything in it before it deletes it.
+
+https://github.com/ArchiveTeam/glowing-computing-machine/tree/git-in-emtpy-directory
diff --git a/doc/forum/Git.cloned_deletes_harmless_empty_directory/comment_1_7cd0521c6d071b25852f8355f4f61f94._comment b/doc/forum/Git.cloned_deletes_harmless_empty_directory/comment_1_7cd0521c6d071b25852f8355f4f61f94._comment
new file mode 100644
index 00000000..91b403b0
--- /dev/null
+++ b/doc/forum/Git.cloned_deletes_harmless_empty_directory/comment_1_7cd0521c6d071b25852f8355f4f61f94._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-04-05T02:22:54Z"
+ content="""
+I am not entirely happy with this patch, because it seems that if
+Git.cloned took care to preserve permissions in this case, it could be
+argued that it should also preserve permissions when the directory already
+exists but has the wrong content. Or equally well argued that it should not
+preserve permissions, which might be a leftover from some past unwanted
+state.
+
+Is that really the best way to do it? You could instead say:
+
+ Git.cloned user repo dir Nothing
+ `onChange` recursiveSetGID user dir
+
+And then you just have to write a recursiveSetGID which would be a
+generally useful property.
+"""]]
diff --git a/doc/forum/Git.cloned_deletes_harmless_empty_directory/comment_2_289f157f129511242d93beae76fd03a3._comment b/doc/forum/Git.cloned_deletes_harmless_empty_directory/comment_2_289f157f129511242d93beae76fd03a3._comment
new file mode 100644
index 00000000..1a8c1447
--- /dev/null
+++ b/doc/forum/Git.cloned_deletes_harmless_empty_directory/comment_2_289f157f129511242d93beae76fd03a3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="db48x@80bd751a72d5a80737e2f875342cf845629c7202"
+ nickname="db48x"
+ avatar="http://cdn.libravatar.org/avatar/ad2688127feb555a92154b16d8eeb5d3"
+ subject="comment 2"
+ date="2017-04-05T02:37:44Z"
+ content="""
+Yea, I guess that's a fair point about the other cases.
+
+It just seems inelegant to go back over all the files and fix up their permissions, when it could just have been set right to begin with.
+"""]]
diff --git a/doc/forum/How_to_create_a_property_with_info.mdwn b/doc/forum/How_to_create_a_property_with_info.mdwn
new file mode 100644
index 00000000..ea8babe5
--- /dev/null
+++ b/doc/forum/How_to_create_a_property_with_info.mdwn
@@ -0,0 +1,65 @@
+Hello Joey,
+
+I try to setup a debomatic service on one of my computer.
+So I created a data which will store on which host it was installed
+
+ data DebOMaticHostMirror = DebOMaticHostMirror Url
+ deriving (Eq, Show, Typeable)
+
+So now I try to create a property which get the hostname and set the info,
+BUT I did not find the right way to do this. Here an attempt
+
+ debomaticHostMirror :: Property (HasInfo + UnixLike)
+ debomaticHostMirror = property' desc $ \w -> do
+ hostname <- asks hostName
+ ensureProperty $ pureInfoProperty desc (InfoVal (DebOMaticHostMirror hostname))
+ where
+ desc = "setup the Deb-O-Matic host name for other properties"
+
+but I get this error message
+
+ src/propellor-config.hs:935:3: error:
+ • Couldn't match expected type ‘Propellor Result’
+ with actual type ‘Property
+ (Propellor.Types.MetaTypes.MetaTypes inner0)
+ -> Propellor Result’
+ • In a stmt of a 'do' block:
+ ensureProperty
+ $ pureInfoProperty desc (InfoVal (DebOMaticHostMirror hostname))
+ In the expression:
+ do { hostname <- asks hostName;
+ ensureProperty
+ $ pureInfoProperty desc (InfoVal (DebOMaticHostMirror hostname)) }
+ In the second argument of ‘($)’, namely
+ ‘\ w
+ -> do { hostname <- asks hostName;
+ ensureProperty
+ $ pureInfoProperty desc (InfoVal (DebOMaticHostMirror hostname)) }’
+
+ src/propellor-config.hs:935:20: error:
+ • Couldn't match expected type ‘OuterMetaTypesWitness outer0’
+ with actual type ‘Property (HasInfo + UnixLike)’
+ • In the second argument of ‘($)’, namely
+ ‘pureInfoProperty desc (InfoVal (DebOMaticHostMirror hostname))’
+ In a stmt of a 'do' block:
+ ensureProperty
+ $ pureInfoProperty desc (InfoVal (DebOMaticHostMirror hostname))
+ In the expression:
+ do { hostname <- asks hostName;
+ ensureProperty
+ $ pureInfoProperty desc (InfoVal (DebOMaticHostMirror hostname)) }
+
+the Idea after is to create a property which will take the DeboMatic Info and generate the
+/etc/apt/sourses.list.d/debomatic.list on a bunch of hosts.
+
+Maybe we could have a
+
+ typeclass Mirror a where
+ toSourceListDLines :: a -> [Line]
+
+ instance Mirror DebOMaticHostMirror where
+ toSourceListDLines (DebOMaticHostMirror hostname) = ...
+
+then the stdSourceListD property should be change to use toSourceListDLines
+
+but this is another story :)
diff --git a/doc/forum/How_to_create_a_property_with_info/comment_1_819902ee6b8e571f735dd2c9c93c49a9._comment b/doc/forum/How_to_create_a_property_with_info/comment_1_819902ee6b8e571f735dd2c9c93c49a9._comment
new file mode 100644
index 00000000..853e6e86
--- /dev/null
+++ b/doc/forum/How_to_create_a_property_with_info/comment_1_819902ee6b8e571f735dd2c9c93c49a9._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-25T23:07:12Z"
+ content="""
+It's not allowed for the content of Info to come from an IO action.
+Info has to be static. This allows one Host to introspect the Info of
+another Host. The Dns properties rely on that.
+
+So, the type checker is right in preventing this. It's also not allowed
+to use ensureProperty with a property that HasInfo, as the info would
+not propigate to the outer property. The type checker is also preventing
+you making that mistake.
+
+(You also forgot to pass the `w` parameter to `ensureProperty`,
+which made the type checker unhappy as well and probably confused the error
+messages.)
+
+To accomplish your goal, you could use:
+
+ data DebOMaticHostMirror = DebOMaticHostMirror
+
+If a Host has this in its Info, you know that Host is the one with
+debomatic installed. You can then get its hostname using the `hostName`
+field accessor on the Host.
+
+The property that does that will need to be passed a `[Host]` which will
+typically be the `hosts` list defined in config.hs.
+"""]]
diff --git a/doc/forum/How_to_create_a_property_with_info/comment_2_1c2b3cb54f27fb6b6bb5de9d159dd34f._comment b/doc/forum/How_to_create_a_property_with_info/comment_2_1c2b3cb54f27fb6b6bb5de9d159dd34f._comment
new file mode 100644
index 00000000..6034e6e5
--- /dev/null
+++ b/doc/forum/How_to_create_a_property_with_info/comment_2_1c2b3cb54f27fb6b6bb5de9d159dd34f._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="picca"
+ avatar="http://cdn.libravatar.org/avatar/7e61c80d28018b10d31f6db7dddb864c"
+ subject="comment 2"
+ date="2017-08-26T06:29:44Z"
+ content="""
+I could have multiple host with debomatic install on it.
+I need to create a property which take a list of hosts (all with the Debomatic info) in order to generate the sources.list files.
+This way it is possible for me to select per host the sources of packages.
+
+what should be done in order to type check this ?
+I would like the compiler to says. Hey you ask for a source list from this host but it dos not contain a Debian mirror.
+
+Cheers
+"""]]
diff --git a/doc/forum/How_to_create_a_property_with_info/comment_3_6cf0360b4922a131bca33d33acf078be._comment b/doc/forum/How_to_create_a_property_with_info/comment_3_6cf0360b4922a131bca33d33acf078be._comment
new file mode 100644
index 00000000..ac4ca94b
--- /dev/null
+++ b/doc/forum/How_to_create_a_property_with_info/comment_3_6cf0360b4922a131bca33d33acf078be._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-08-28T22:38:55Z"
+ content="""
+Finding a way to type check that, I don't know. It would certianly be nice
+to be able to statically check such things. The way that Info is
+implemented as a monoid that contains many different types seems to
+preclude exposing enough information for the type checker to catch such a
+problem. So it would have to be changed somehow, I don't know how.
+"""]]
diff --git a/doc/forum/Inherited_Variables....mdwn b/doc/forum/Inherited_Variables....mdwn
new file mode 100644
index 00000000..1535ec77
--- /dev/null
+++ b/doc/forum/Inherited_Variables....mdwn
@@ -0,0 +1,26 @@
+I've got a server defined in config.hs as follows:
+
+ myserver :: Host
+ myserver = host "myserver.mydomain" $ props
+ & standardSystem (Stable "jessie") X86_64 [ "Welcome to myserver!" ]
+
+I'm writing a module (to deploy Matrix, FWIW) which has a section like this:
+
+ sources :: Property Debian
+ sources = File.hasContent "/etc/apt/sources.list.d/matrix.list"
+ [ "# Deployed by Propellor"
+ , ""
+ , "deb http://matrix.org/packages/debian/ jessie main"
+ ] `onChange` Apt.update
+
+What I would like to be able to do, for example, is pull "jessie" from the standardSystem line into the sources function.
+
+The host name is another I'd like to be able to pull in, so that I can abstract as much as possible and wind up with a line that looks not unlike this:
+
+ & Matrix.server
+
+Instead of
+
+ & Matrix.server hostname jessie
+
+Am I barking up the wrong tree and should I just embrace the latter?
diff --git a/doc/forum/Inherited_Variables.../comment_1_082e5d5b8e25335bc90577abcfef1d21._comment b/doc/forum/Inherited_Variables.../comment_1_082e5d5b8e25335bc90577abcfef1d21._comment
new file mode 100644
index 00000000..e4b32398
--- /dev/null
+++ b/doc/forum/Inherited_Variables.../comment_1_082e5d5b8e25335bc90577abcfef1d21._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-01-26T06:39:35Z"
+ content="""
+This is where propellor's `Info` system comes in. `Propellor.Info.getOS`
+can be run to get the OS info.
+
+It's also possible to add new properties that add new values with custom
+types to `Info`.
+
+The hostname is not currently stored in `Info`, but it probably should be;
+that would be a good simplification. Currently there's a
+separate way to get the hostname: `asks hostName` (run in the Propellor monad)
+"""]]
diff --git a/doc/forum/Inherited_Variables.../comment_2_988319ed6de46eff2eac0d5ef36382f9._comment b/doc/forum/Inherited_Variables.../comment_2_988319ed6de46eff2eac0d5ef36382f9._comment
new file mode 100644
index 00000000..676f41ac
--- /dev/null
+++ b/doc/forum/Inherited_Variables.../comment_2_988319ed6de46eff2eac0d5ef36382f9._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-01-26T06:50:39Z"
+ content="""
+A worked example:
+
+ server :: Property Debian
+ server = property' "some description" $ \w -> do
+ os <- getOS
+ hostname <- asks hostName
+ ensureProperty w $
+ File.hasContent "/etc/apt/sources.list.d/matrix.list"
+ (genSourcesList os hostname)
+"""]]
diff --git a/doc/forum/Inherited_Variables.../comment_3_acf78fa9f732f070bf73c2ab601464ee._comment b/doc/forum/Inherited_Variables.../comment_3_acf78fa9f732f070bf73c2ab601464ee._comment
new file mode 100644
index 00000000..fcdf923b
--- /dev/null
+++ b/doc/forum/Inherited_Variables.../comment_3_acf78fa9f732f070bf73c2ab601464ee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="craige"
+ avatar="http://cdn.libravatar.org/avatar/64ac5816ea3a51347d1f699022d1fdc1"
+ subject="Thanks!"
+ date="2017-01-27T21:54:45Z"
+ content="""
+Thanks Joey. I think that's exactly what I need. Very helpful :-)
+"""]]
diff --git a/doc/forum/Inherited_Variables.../comment_4_5bf7b1f69b48b4d9c516d424e4438208._comment b/doc/forum/Inherited_Variables.../comment_4_5bf7b1f69b48b4d9c516d424e4438208._comment
new file mode 100644
index 00000000..3b691b2a
--- /dev/null
+++ b/doc/forum/Inherited_Variables.../comment_4_5bf7b1f69b48b4d9c516d424e4438208._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="craige@a46118dff5bc0fad85259759970d8b4b9fc377d7"
+ nickname="craige"
+ avatar="http://cdn.libravatar.org/avatar/6d2207226de755da46aa2fdff9af70b2"
+ subject="comment 4"
+ date="2017-02-03T00:04:05Z"
+ content="""
+Ugh, sorry to ask again but I'm specifically stuck trying to extract the Debian suite only from this. Is this stored as a specific value I can draw on? I've been wading through the source and added in a swag of trial and error with no luck.
+
+I can see the suite listed in the output
+
+ Just (System (Debian Linux (Stable \"jessie\"))
+
+but I was wondering if there was a method to pull out just the suite code name (ie: \"jessie\") that did not involve a regex looking for it amongst that output.
+
+The goal is to query Info so that a suite name can be added to a sources list.
+
+If I have to regex, that's OK, I just didn't want to go down that path if there was a smarted way.
+
+Thanks Joey :-)
+"""]]
diff --git a/doc/forum/Inherited_Variables.../comment_5_6fbd29f568ec8b97be47874e2aac57a3._comment b/doc/forum/Inherited_Variables.../comment_5_6fbd29f568ec8b97be47874e2aac57a3._comment
new file mode 100644
index 00000000..16819bd6
--- /dev/null
+++ b/doc/forum/Inherited_Variables.../comment_5_6fbd29f568ec8b97be47874e2aac57a3._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-02-03T19:32:58Z"
+ content="""
+What you're looking for is not a regexp, but Haskell's [pattern
+matching](https://www.haskell.org/tutorial/patterns.html).
+
+For example:
+
+ myproperty :: Property Debian
+ myproperty = withOS "some desc here" $ \w o -> case o of
+ -- Pattern match on the OS, to get the Debian stable release
+ (Just (System (Debian _kernel (Stable release)) _arch)) ->
+ ensureProperty w $ Apt.setSourcesListD (sourcesLines release) "mysources"
+ _ -> unsupportedOS
+
+ sourcesLines :: Release -> [Line]
+ sourcesLines release = undefined
+"""]]
diff --git a/doc/forum/Manage_multiple_different_projects_with_propellor.mdwn b/doc/forum/Manage_multiple_different_projects_with_propellor.mdwn
new file mode 100644
index 00000000..bcba383c
--- /dev/null
+++ b/doc/forum/Manage_multiple_different_projects_with_propellor.mdwn
@@ -0,0 +1,7 @@
+Hi there,
+
+I've been tasked with investigating propellor as an alternative to Ansible. I'm a little bit confused about how one might go about managing a *single* project's hosts with propellor, without infecting the global propellor config. It seems that everything is concerned with the ~/.propellor repository. However, I don't want project A's hosts to know about project B's and vice versa. I'm sure I'm overlooking something obvious!
+
+Thanks very much!
+
+Mitchell
diff --git a/doc/forum/Manage_multiple_different_projects_with_propellor/comment_1_dbad48163b2efd6434ea7c37a72dfd30._comment b/doc/forum/Manage_multiple_different_projects_with_propellor/comment_1_dbad48163b2efd6434ea7c37a72dfd30._comment
new file mode 100644
index 00000000..7513cc09
--- /dev/null
+++ b/doc/forum/Manage_multiple_different_projects_with_propellor/comment_1_dbad48163b2efd6434ea7c37a72dfd30._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-24T18:14:14Z"
+ content="""
+There did not used to be a good way to do that, but since propellor 3.2.3,
+when you run eg "propellor --spin host", it first checks to see if there is
+a `./config.hs` file, and if so, uses it instead of the user-global
+`~/.propellor/config.hs`.
+
+So, just make different git repos for the different projects with propellor
+`config.hs` files in them, and `cd` into the one you want to run before running
+propellor.
+"""]]
diff --git a/doc/forum/Modules_with_Multiple_cmdProperty_causing_build_failures/comment_2_5afe0f200d7139499ef4b01ea6445206._comment b/doc/forum/Modules_with_Multiple_cmdProperty_causing_build_failures/comment_2_5afe0f200d7139499ef4b01ea6445206._comment
new file mode 100644
index 00000000..00f77116
--- /dev/null
+++ b/doc/forum/Modules_with_Multiple_cmdProperty_causing_build_failures/comment_2_5afe0f200d7139499ef4b01ea6445206._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="craige@a46118dff5bc0fad85259759970d8b4b9fc377d7"
+ nickname="craige"
+ avatar="http://cdn.libravatar.org/avatar/6d2207226de755da46aa2fdff9af70b2"
+ subject="Fixed!"
+ date="2017-01-26T05:54:22Z"
+ content="""
+The original suggestions did fix my problems.
+
+Apologies for the late response.
+"""]]
diff --git a/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot.mdwn b/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot.mdwn
new file mode 100644
index 00000000..8887f438
--- /dev/null
+++ b/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot.mdwn
@@ -0,0 +1,29 @@
+Hello, I am preparing a property in order to setup a debomatic machine
+but when I try to upload a package I get this error from debomatic
+
+ DEBUG: Command '['schroot', '-l']' returned non-zero exit status 1
+ Traceback (most recent call last):
+ File "/usr/share/debomatic/Debomatic/process.py", line 197, in _finish
+ raise e
+ File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
+ result = self.fn(*self.args, **self.kwargs)
+ File "/usr/share/debomatic/Debomatic/build.py", line 525, in run
+ self._build()
+ File "/usr/share/debomatic/Debomatic/build.py", line 133, in _build
+ self._setup_chroot()
+ File "/usr/share/debomatic/Debomatic/build.py", line 395, in _setup_chroot
+ chroots = check_output(['schroot', '-l'], stderr=fd)
+ File "/usr/lib/python3.5/subprocess.py", line 316, in check_output
+ **kwargs).stdout
+ File "/usr/lib/python3.5/subprocess.py", line 398, in run
+ output=stdout, stderr=stderr)
+ subprocess.CalledProcessError: Command '['schroot', '-l']' returned non-zero exit status 1
+
+so tried on my own
+
+ :/etc/debomatic# schroot -l
+ E: /etc/schroot/chroot.d/stretch-amd64-sbuild-propellor: [stretch-amd64-sbuild]: Required key ‘directory’ is missing
+
+to my opinion the schroot config file generated by Sbuild property does something wrong.
+
+Cheers
diff --git a/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_1_59ac4661a896a514ce953a0069341869._comment b/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_1_59ac4661a896a514ce953a0069341869._comment
new file mode 100644
index 00000000..b4e411b7
--- /dev/null
+++ b/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_1_59ac4661a896a514ce953a0069341869._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="picca"
+ avatar="http://cdn.libravatar.org/avatar/7e61c80d28018b10d31f6db7dddb864c"
+ subject="comment 1"
+ date="2017-08-23T13:00:13Z"
+ content="""
+this is strange because the stretch-amd64-sbuild file is wrong.
+
+here the content
+
+ [stretch-amd64-sbuild]
+ command-prefix=/var/cache/ccache-sbuild/sbuild-setup,eatmydata
+
+to compare with my previous jessie-amd64-sbuild
+
+ [jessie-amd64-sbuild]
+ type=directory
+ description=Debian jessie/amd64 autobuilder
+ directory=/srv/chroot/jessie-amd64
+ groups=root,sbuild
+ root-groups=root,sbuild
+ profile=sbuild
+ command-prefix=/var/cache/ccache-sbuild/sbuild-setup,eatmydata
+"""]]
diff --git a/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_2_579894632e567a08d83e306be5e355b2._comment b/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_2_579894632e567a08d83e306be5e355b2._comment
new file mode 100644
index 00000000..53595ad2
--- /dev/null
+++ b/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_2_579894632e567a08d83e306be5e355b2._comment
@@ -0,0 +1,84 @@
+[[!comment format=mdwn
+ username="picca"
+ avatar="http://cdn.libravatar.org/avatar/7e61c80d28018b10d31f6db7dddb864c"
+ subject="comment 2"
+ date="2017-08-23T13:26:31Z"
+ content="""
+Hello, so I try to restart from scratch and ask for a stretch Sbuild
+
+everything went fine until the update
+
+
+ I: schroot chroot configuration written to /etc/schroot/chroot.d/stretch-amd64-propellor-VYWULd.
+ +------------------------------------------------------------------------
+ |[stretch-amd64-propellor]
+ |description=Debian stretch/amd64 autobuilder
+ |groups=root,sbuild
+ |root-groups=root,sbuild
+ |profile=sbuild
+ |type=directory
+ |directory=/srv/chroot/stretch-amd64
+ |union-type=overlay
+ +------------------------------------------------------------------------
+ I: Please rename and modify this file as required.
+ W: Not creating symlink /srv/chroot/stretch-amd64 to /etc/sbuild/chroot/stretch-amd64-propellor: file already exists
+ perl: warning: Setting locale failed.
+ perl: warning: Please check that your locale settings:
+ LANGUAGE = (unset),
+ LC_ALL = (unset),
+ LANG = \"en_GB.UTF-8\"
+ are supported and installed on your system.
+ perl: warning: Falling back to the standard locale (\"C\").
+ I: Setting reference package list.
+ I: Updating chroot.
+
+
+On my network, I need a proxy so I setup the host with
+
+ ...
+ & Apt.proxy myproxy
+ & Sbuild.builtFor stretch Sbuild.UseCcache
+
+If I understand correctly the Apt.proxy should propagate the Apt.proxy into the Sbuild
+but when I look inside the chroot, I can not find the
+
+ /etc/apt/apt.conf.d/20proxy
+
+file which is on the host
+
+And Indeed after a certain amount of time, the network gives a timeout
+
+ Err:1 http://deb.debian.org/debian stretch InRelease
+ Cannot initiate the connection to deb.debian.org:80 (2001:41c8:1000:21::21:4). - connect (101: Network is unreachable) [IP: 2001:41c8:1000:21::21:4 80]
+ Reading package lists...
+ W: Failed to fetch http://deb.debian.org/debian/dists/stretch/InRelease Cannot initiate the connection to deb.debian.org:80 (2001:41c8:1000:21::21:4). - connect (101: Network is unreachable) [IP: 2001:41c8:1000:21::21:4 80]
+ W: Some index files failed to download. They have been ignored, or old ones used instead.
+ Reading package lists...
+ Building dependency tree...
+ Calculating upgrade...
+ 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
+ I: Successfully set up stretch chroot.
+ I: Run \"sbuild-adduser\" to add new sbuild users.
+ sixs7.exp.synchrotron-soleil.fr sbuild schroot for System (Debian Linux (Stable \"stretch\")) X86_64 ... done
+
+the good news is that now the schroot file contain the right informations
+
+ [stretch-amd64-sbuild]
+ description=Debian stretch/amd64 autobuilder
+ groups=root,sbuild
+ root-groups=root,sbuild
+ profile=sbuild
+ type=directory
+ directory=/srv/chroot/stretch-amd64
+ union-type=overlay
+ command-prefix=/var/cache/ccache-sbuild/sbuild-setup,eatmydata
+
+
+So to summarize, I think that the Apt.proxy propagation does not work.
+
+This propagation should be optional because sometime we prepare images which are not meant to be used behind a proxy (where they were prepare)
+
+thanks for your attention :)
+
+
+"""]]
diff --git a/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_3_6aeee8ba74b363d26a49d6773c5d5014._comment b/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_3_6aeee8ba74b363d26a49d6773c5d5014._comment
new file mode 100644
index 00000000..12d59028
--- /dev/null
+++ b/doc/forum/Sbuild_chroot_are_not_compatible_with_schroot/comment_3_6aeee8ba74b363d26a49d6773c5d5014._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 3"
+ date="2017-09-02T02:47:01Z"
+ content="""
+Thank you for the detailed report.
+
+I think the problem is the proxy propagation happens after the sbuild-createchroot command has run, but if the sbuild-createchroot command needs the proxy, it will fail in the way you describe.
+
+After speaking to Joey at DebConf I think I can rework the sbuild module to bypass sbuild-createchroot and run debootstrap itself, without thereby polluting the chroot that is created. That should make it much easier to fix this bug, so I'll do that first.
+"""]]
diff --git a/doc/forum/Supported_OS/comment_3_f2924708a819b962ba7ed690019601ed._comment b/doc/forum/Supported_OS/comment_3_f2924708a819b962ba7ed690019601ed._comment
new file mode 100644
index 00000000..c03f6cd9
--- /dev/null
+++ b/doc/forum/Supported_OS/comment_3_f2924708a819b962ba7ed690019601ed._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Arch too!"""
+ date="2017-02-04T21:30:26Z"
+ content="""
+Propellor just got support for Arch Linux!
+"""]]
diff --git a/doc/forum/Using_propellor_for_continers_only.mdwn b/doc/forum/Using_propellor_for_continers_only.mdwn
new file mode 100644
index 00000000..faf07956
--- /dev/null
+++ b/doc/forum/Using_propellor_for_continers_only.mdwn
@@ -0,0 +1,5 @@
+Hi,
+
+I was wondering: Is it possible to use propellor to generate images only without actually managing any hosts per-se? I couldn't find any documentation on that.
+
+Ideally, I'd also be able to use it directly from a sandbox so that I wouldn't have to even "pollute" the GHC/Cabal "global" (user home dir) database on the development machine. I see that there's support for having the config.hs stored in a different directory than ~/.propellor, but I haven't managed to get it working when I use a sandbox in e.g. ~/foo with the config.hs stored in the same directory. Perhaps that's just a bug? If it's supposed to work I can provide detailed error messages, etc. **EDIT:** I'd also like to manage the git repository myself -- is that possible?
diff --git a/doc/forum/Using_propellor_for_continers_only/comment_1_95e8b7103f248d93570fecb6b8999996._comment b/doc/forum/Using_propellor_for_continers_only/comment_1_95e8b7103f248d93570fecb6b8999996._comment
new file mode 100644
index 00000000..dc6cc616
--- /dev/null
+++ b/doc/forum/Using_propellor_for_continers_only/comment_1_95e8b7103f248d93570fecb6b8999996._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-29T19:09:37Z"
+ content="""
+Sounds like you may want to write a program that uses propellor as a
+library. `Propellor.Engine.mainProperties` is a reasonable
+entry point, just pass it a Host that has the properties you want
+to run.
+
+For example:
+
+ import Propellor
+ import Propellor.Engine
+ import Propellor.Property.DiskImage
+
+ main :: IO ()
+ main = mainProperties $ host "whatever" $ props
+ & imageBuilt "/some/disk.img" ...
+"""]]
diff --git a/doc/forum/Using_propellor_for_continers_only/comment_2_42b45a126cfdf1dfc370b166c8042690._comment b/doc/forum/Using_propellor_for_continers_only/comment_2_42b45a126cfdf1dfc370b166c8042690._comment
new file mode 100644
index 00000000..45cd3e0c
--- /dev/null
+++ b/doc/forum/Using_propellor_for_continers_only/comment_2_42b45a126cfdf1dfc370b166c8042690._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="bardur.arantsson"
+ avatar="http://cdn.libravatar.org/avatar/a0be0039b44d33262b7ae650a0803ad5"
+ subject="comment 2"
+ date="2017-04-06T02:14:58Z"
+ content="""
+I'll try that this weekend, thanks!
+"""]]
diff --git a/doc/forum/Using_propellor_for_continers_only/comment_3_cd4b9b9e160469e9f0b105f6c40a4ef8._comment b/doc/forum/Using_propellor_for_continers_only/comment_3_cd4b9b9e160469e9f0b105f6c40a4ef8._comment
new file mode 100644
index 00000000..fceeedcf
--- /dev/null
+++ b/doc/forum/Using_propellor_for_continers_only/comment_3_cd4b9b9e160469e9f0b105f6c40a4ef8._comment
@@ -0,0 +1,54 @@
+[[!comment format=mdwn
+ username="bardur.arantsson"
+ avatar="http://cdn.libravatar.org/avatar/a0be0039b44d33262b7ae650a0803ad5"
+ subject="comment 3"
+ date="2017-05-12T06:50:49Z"
+ content="""
+Ok, so I've tried to use this to build a Chroot (a reasonable starting point for building containers), using the following program:
+
+ module Main
+ ( main
+ ) where
+
+ import Propellor
+ import Propellor.Engine
+ import Propellor.Property.DiskImage
+ import qualified Propellor.Property.Apt as Apt
+ import qualified Propellor.Property.User as User
+ import Propellor.Property.Chroot
+
+ main :: IO ()
+ main = mainProperties $ host \"whatever\" $ props
+ & provisioned (mychroot \"out\")
+ where
+ mychroot d = debootstrapped mempty d $ props
+ & osDebian Unstable X86_64
+ & Apt.installed [\"linux-image-amd64\"]
+ & User.hasPassword (User \"root\")
+ & User.accountFor (User \"demo\")
+ & User.hasPassword (User \"demo\")
+
+It seems that \"debootstrap\" finishes:
+
+ I: Configuring apt-transport-https...
+ I: Configuring tasksel...
+ I: Configuring tasksel-data...
+ I: Configuring libc-bin...
+ I: Configuring systemd...
+ I: Configuring ca-certificates...
+ I: Base system installed successfully.
+
+But fails immediately afterwards:
+
+ ldd: /usr/local/propellor/propellor: No such file or directory
+ ** warning: user error (ldd [\"/usr/local/propellor/propellor\"] exited 1)
+ whatever chroot out exists ... failed
+ whatever overall ... failed
+
+(I should probably have used a different hostname than \"whatever\", but... whatever :).)
+
+So it seems that the chroot support still expects propellor to be installed on the host system?
+
+I should mention that I've done an extremely small patch to Propellor locally, just to the ChrootBootstrapper instance for ArchLinux to allow it to call debootstrap on Arch Linux -- it seems to exist as a package these days, not sure if it did when that Propellor code was written. Anyway...
+
+"""]]
diff --git a/doc/forum/Using_propellor_for_continers_only/comment_4_9dc985b26c29b9ce21e6c75ec03f6262._comment b/doc/forum/Using_propellor_for_continers_only/comment_4_9dc985b26c29b9ce21e6c75ec03f6262._comment
new file mode 100644
index 00000000..72d7ca83
--- /dev/null
+++ b/doc/forum/Using_propellor_for_continers_only/comment_4_9dc985b26c29b9ce21e6c75ec03f6262._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2017-05-13T17:42:41Z"
+ content="""
+The way propellor handles running in a chroot or container is it exports
+its binary and support files into the container. This way the
+haskell code can run in a container, rather than being limited to
+only running shell commands in the container, and without needing ghc in
+the container.
+
+It does use the hardcoded `localdir` for that.
+It would certianly be possible to make it use propellor in a different
+location, perhaps using `getExecutablePath`.
+
+Since the git-annex outside the container passes command-line options to
+the one running inside the container to tell it what to do, using
+`mainProperties` would also not work since that does not look at
+command-line options. It would need to use `defaultMain` or
+`processCmdLine` and dispatch itself, or something..
+"""]]
diff --git a/doc/forum/Using_propellor_for_continers_only/comment_5_8552ce821f5a3b386cb9e6ad417670ec._comment b/doc/forum/Using_propellor_for_continers_only/comment_5_8552ce821f5a3b386cb9e6ad417670ec._comment
new file mode 100644
index 00000000..0d9904c5
--- /dev/null
+++ b/doc/forum/Using_propellor_for_continers_only/comment_5_8552ce821f5a3b386cb9e6ad417670ec._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="bardur.arantsson"
+ avatar="http://cdn.libravatar.org/avatar/a0be0039b44d33262b7ae650a0803ad5"
+ subject="comment 5"
+ date="2017-05-25T06:13:14Z"
+ content="""
+I'm not sure I understand all of that, but it sounds like I'll be fighting an uphill battle :). Maybe I'll try something shake-based instead. Thanks for the help.
+"""]]
diff --git a/doc/forum/Why_downloading_package_list_from_hackage.haskell.org__63__/comment_5_61d7ef8a61ac7b922c810825d794da5f._comment b/doc/forum/Why_downloading_package_list_from_hackage.haskell.org__63__/comment_5_61d7ef8a61ac7b922c810825d794da5f._comment
new file mode 100644
index 00000000..35c894b0
--- /dev/null
+++ b/doc/forum/Why_downloading_package_list_from_hackage.haskell.org__63__/comment_5_61d7ef8a61ac7b922c810825d794da5f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/2982bac2c2cd94ab3860efb189deafc8"
+ subject="comment 5"
+ date="2017-07-14T10:58:33Z"
+ content="""
+The new \"bootstrapWith (Robustly Stack)\" and \"bootstrapWith OSOnly\" properties completely address my concerns. Thanks!
+"""]]
diff --git a/doc/forum/Why_downloading_package_list_from_hackage.haskell.org__63__/comment_6_ceddc6d118b7ea71ec8f498960a5fe97._comment b/doc/forum/Why_downloading_package_list_from_hackage.haskell.org__63__/comment_6_ceddc6d118b7ea71ec8f498960a5fe97._comment
new file mode 100644
index 00000000..32ed86f8
--- /dev/null
+++ b/doc/forum/Why_downloading_package_list_from_hackage.haskell.org__63__/comment_6_ceddc6d118b7ea71ec8f498960a5fe97._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/2982bac2c2cd94ab3860efb189deafc8"
+ subject="comment 6"
+ date="2017-07-14T11:16:10Z"
+ content="""
+(I did not try to build propellor again on this 128Mo host yet, though)
+"""]]
diff --git a/doc/forum/Work_on_OS_X.mdwn b/doc/forum/Work_on_OS_X.mdwn
new file mode 100644
index 00000000..e3c5fd64
--- /dev/null
+++ b/doc/forum/Work_on_OS_X.mdwn
@@ -0,0 +1,5 @@
+I'm interested in using Propellor on OS X. I understand that it is not supported though.
+
+Is there anyone doing this? If it was developed, would support for OS X be merged upstream?
+
+Thanks!
diff --git a/doc/forum/Work_on_OS_X/comment_1_6d7d5b89f1de9604718f7973e4b3eeb1._comment b/doc/forum/Work_on_OS_X/comment_1_6d7d5b89f1de9604718f7973e4b3eeb1._comment
new file mode 100644
index 00000000..4eac2063
--- /dev/null
+++ b/doc/forum/Work_on_OS_X/comment_1_6d7d5b89f1de9604718f7973e4b3eeb1._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-04-13T21:36:20Z"
+ content="""
+I got a patch some years back to make propellor compile on OSX.
+I merged it. You might want to get in touch with its author, as
+he may be doing something with propellor on OSX.
+<https://github.com/tittoassini/propellor>
+
+Anyway, I'd probably merge OSX patches, if they were not super
+intrusive. And I don't see why it would be, as propellor already supports
+FreeBSD.
+
+Since `Property` is parameterized by the operating systems it
+supports, it should be easy to start by only porting the core parts
+of propellor, and then port over individual Properties one by one as
+needed. See the commits for the recent FreeBSD port for a nice walkthough
+of the changes you'll want to make.
+"""]]
diff --git a/doc/forum/Work_on_OS_X/comment_2_00b20c240fc13bed6dc54e5b985b41e2._comment b/doc/forum/Work_on_OS_X/comment_2_00b20c240fc13bed6dc54e5b985b41e2._comment
new file mode 100644
index 00000000..aa33c85b
--- /dev/null
+++ b/doc/forum/Work_on_OS_X/comment_2_00b20c240fc13bed6dc54e5b985b41e2._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joelmccracken"
+ avatar="http://cdn.libravatar.org/avatar/45175015b9eb3dd3f6c740b3fe920fed"
+ subject="comment 2"
+ date="2017-04-17T17:47:30Z"
+ content="""
+Sounds good. I contacted the person you linked to, have not heard back yet.
+
+
+
+The first issue I ran into is that propellor wants to connect to \"root@<hostname>\", and it doesn't look like this is configurable.
+Would you accept a patch to make this configurable?
+
+Additionally, is this the best place to ask questions about what you would/would not accept?
+
+Thank you!!!
+"""]]
diff --git a/doc/forum/Work_on_OS_X/comment_3_294f4783522a8e4887793aac921ee546._comment b/doc/forum/Work_on_OS_X/comment_3_294f4783522a8e4887793aac921ee546._comment
new file mode 100644
index 00000000..ed654d3f
--- /dev/null
+++ b/doc/forum/Work_on_OS_X/comment_3_294f4783522a8e4887793aac921ee546._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-04-18T00:08:13Z"
+ content="""
+Yes, this is the place. Or you can email me directly, but I prefer to keep
+discussions public.
+
+`propellor --spin` needs a way to run commands as root on the remote host.
+If ssh as root on OSX is not allowed, it would need a way to get to a user
+who can get root, and it would be very annoying if a password needed to be
+entered since each `propellor --spin` actually makes several ssh connections to
+the remote host. Anything that works within these constraints would be ok.
+"""]]
diff --git a/doc/forum/Work_on_OS_X/comment_4_74b579d4d590432b6bd236ccb929cc11._comment b/doc/forum/Work_on_OS_X/comment_4_74b579d4d590432b6bd236ccb929cc11._comment
new file mode 100644
index 00000000..d386c1b5
--- /dev/null
+++ b/doc/forum/Work_on_OS_X/comment_4_74b579d4d590432b6bd236ccb929cc11._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joelmccracken"
+ avatar="http://cdn.libravatar.org/avatar/45175015b9eb3dd3f6c740b3fe920fed"
+ subject="comment 4"
+ date="2017-04-20T02:23:06Z"
+ content="""
+So, it turns out that yes, root is a thing on os x... but it is complicated. I'm going to put what I learned here because I think it will be useful, at least for telling folks how to use propellor on os x.
+
+1. Enable the root account. Steps are here: https://support.apple.com/en-us/HT204012
+2. password-authentication as root is disabled -- if you try to `ssh root@localhost`, it wont work. you need a key pair.
+3. use su/sudo to install a public key (probably at `.ssh/id_rsa.pub`) to roots authorized_keys. adapted from: https://discussions.apple.com/thread/4078360?start=0&tstart=0
+4. copy the the pub file to authorized keys: `sudo cp /Users/joel/.ssh/id_rsa.pub /var/root/.ssh/authorized_keys`
+5. you should now be able to `ssh root@localhost` without a password.
+
+I'm not super sure that this is even the best way forward, but lets get this working first, then we'll see.
+"""]]
diff --git a/doc/forum/creating_Bind9_configuration.mdwn b/doc/forum/creating_Bind9_configuration.mdwn
new file mode 100644
index 00000000..5e281394
--- /dev/null
+++ b/doc/forum/creating_Bind9_configuration.mdwn
@@ -0,0 +1,9 @@
+I try to use propellor to deploy a secondary DNS server.
+
+In your configuration, I see nothing to change the `listen-on { 127.0.0.1; };` option, did I miss something?
+
+Also, in `Dns.secondaryFor`, I do not know how to set `confLines` to something else, should I use this function and peel the result until I can change this or shoud I add a `Dns.secondaryFor'` version with an extra argument?
+
+By the way, is it really advisable to use a "minimal config" instead of a full clone?
+
+Thanks!
diff --git a/doc/forum/creating_Bind9_configuration/comment_1_0798f44e1f5a91fbc91c0b472ad92bfa._comment b/doc/forum/creating_Bind9_configuration/comment_1_0798f44e1f5a91fbc91c0b472ad92bfa._comment
new file mode 100644
index 00000000..d1387a22
--- /dev/null
+++ b/doc/forum/creating_Bind9_configuration/comment_1_0798f44e1f5a91fbc91c0b472ad92bfa._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="Nicolas.Schodet"
+ avatar="http://cdn.libravatar.org/avatar/0d7ec808ec329d04ee9a93c0da3c0089"
+ subject="comment 1"
+ date="2017-08-03T20:52:22Z"
+ content="""
+For the moment I use:
+
+```
+namedOptions :: Property DebianLike
+namedOptions =
+ File.hasContent \"/etc/bind/named.conf.options\" namedOptionsStanza
+ `onChange` Service.reloaded \"bind9\"
+ where
+ namedOptionsStanza =
+ [ \"// automatically generated by propellor\"
+ , \"options {\"
+ , \"\tdirectory \\"/var/cache/bind\\";\"
+ , \"\tdnssec-validation auto;\"
+ , \"\tlisten-on-v6 { any; };\"
+ , \"\tlisten-on { any; };\"
+ , \"\tallow-query { any; };\"
+ , \"\tallow-recursion { localhost; };\"
+ , \"\tallow-transfer { none; };\"
+ , \"\tallow-notify { none; };\"
+ , \"};\"
+ ]
+```
+"""]]
diff --git a/doc/forum/creating_Bind9_configuration/comment_2_f1bffbdd7c2ebab2dd9518ee024e7a92._comment b/doc/forum/creating_Bind9_configuration/comment_2_f1bffbdd7c2ebab2dd9518ee024e7a92._comment
new file mode 100644
index 00000000..71c8b5a4
--- /dev/null
+++ b/doc/forum/creating_Bind9_configuration/comment_2_f1bffbdd7c2ebab2dd9518ee024e7a92._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-08-23T16:00:12Z"
+ content="""
+At least on Debian, bind seems to come configured to listen on all
+interfaces by default, so I have not messed with listen-on settings at all.
+
+confLines seems to have been included in NamedConf to allow for specifying
+additional lines, but there does not seem to be an interface to set it.
+Versions of the 3 dns properties with an additional (NamedConf -> NamedConf)
+parameter woulld be one way; I'd take such a patch.
+
+As to a minimal config vs a full clone, it's up to you. With a full clone
+you can easily modify all of propellor's properties to quicklly deal with
+issues like this.. but then you might have to maintain your patches if you
+don't get them accepted into propellor.
+"""]]
diff --git a/doc/forum/creating_Bind9_configuration/comment_3_6b4d73b17d87d00845fda26431ded422._comment b/doc/forum/creating_Bind9_configuration/comment_3_6b4d73b17d87d00845fda26431ded422._comment
new file mode 100644
index 00000000..c61feaab
--- /dev/null
+++ b/doc/forum/creating_Bind9_configuration/comment_3_6b4d73b17d87d00845fda26431ded422._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Nicolas.Schodet"
+ avatar="http://cdn.libravatar.org/avatar/0d7ec808ec329d04ee9a93c0da3c0089"
+ subject="comment 3"
+ date="2017-08-28T14:03:35Z"
+ content="""
+It might be a configuration from my server provider, maybe I should do a clean install :)
+
+If not using a full clone, I also have problem because I cannot use things like Utility.Units.
+"""]]
diff --git a/doc/forum/host_to_deal_with_dpkg::options.mdwn b/doc/forum/host_to_deal_with_dpkg::options.mdwn
new file mode 100644
index 00000000..5faaefe2
--- /dev/null
+++ b/doc/forum/host_to_deal_with_dpkg::options.mdwn
@@ -0,0 +1,41 @@
+[[!meta title "how to deal with dpkg::options"]]
+
+Hello
+
+I try to create a distUpgrade property in order to migrate one of my computer from jessie -> stretch
+
+I started wit this
+
+ distUpgrade :: String -> Property DebianLike
+ distUpgrade p = combineProperties ("apt " ++ p) $ props
+ & Apt.pendingConfigured
+ & Apt.runApt ["-y", "--force-yes", "-o", "Dpkg::Options::=\"--force-confnew\"", p]
+ `assume` MadeChange
+
+But when I try to use this
+
+ ...
+ & distUpgrade dist-upgrade
+
+ I get this error message
+
+ Préconfiguration des paquets...
+ setting xserver-xorg-legacy/xwrapper/allowed_users from configuration file
+ dpkg: erreur: requiert une option d'action
+
+ Utilisez « dpkg --help » pour obtenir de l'aide à propos de l'installation et la désinstallation des paquets [*] ;
+ Utilisez « apt » ou « aptitude » pour gérer les paquets de m1578 mis à jour, 376 nouvellement installés, 72 à enlever et 0 non mis à jour.
+ Il est nécessaire de prendre 0 o/1 458 Mo dans les archives.
+
+I checked that if I run this command on the command line it works
+
+ apt-get -y --force-yes -o Dpkg::Options::="--force-confnew" dist-upgrade
+
+even If I write this it works
+
+ apt-get -y --force-yes -o Dpkg::Options::=\"--force-confnew\" dist-upgrade
+
+So it seems to me that there is a problem with the runApt method or I missed something
+
+thanks
+
diff --git a/doc/forum/host_to_deal_with_dpkg::options/comment_1_641dcb7be62151bdc97fd5e574f334d0._comment b/doc/forum/host_to_deal_with_dpkg::options/comment_1_641dcb7be62151bdc97fd5e574f334d0._comment
new file mode 100644
index 00000000..65756b12
--- /dev/null
+++ b/doc/forum/host_to_deal_with_dpkg::options/comment_1_641dcb7be62151bdc97fd5e574f334d0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="picca"
+ avatar="http://cdn.libravatar.org/avatar/7e61c80d28018b10d31f6db7dddb864c"
+ subject="comment 1"
+ date="2017-07-28T15:09:12Z"
+ content="""
+please change the title, I made a mistake
+
+how to deal with ...
+
+sorry
+"""]]
diff --git a/doc/forum/host_to_deal_with_dpkg::options/comment_2_bac8129b570ce216ef9f6aa6c0e12c1e._comment b/doc/forum/host_to_deal_with_dpkg::options/comment_2_bac8129b570ce216ef9f6aa6c0e12c1e._comment
new file mode 100644
index 00000000..39e0ebc3
--- /dev/null
+++ b/doc/forum/host_to_deal_with_dpkg::options/comment_2_bac8129b570ce216ef9f6aa6c0e12c1e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-07-28T15:45:43Z"
+ content="""
+I doubt that apt's option parser deals with quotes; those are normally
+handled by the shell. runApt does not pass the command through the shell,
+so probably simply removing the quotes from inside the parameter will work.
+"""]]
diff --git a/doc/forum/host_to_deal_with_dpkg::options/comment_3_62d671fb3c787aafcd4d058975208f75._comment b/doc/forum/host_to_deal_with_dpkg::options/comment_3_62d671fb3c787aafcd4d058975208f75._comment
new file mode 100644
index 00000000..4031bd16
--- /dev/null
+++ b/doc/forum/host_to_deal_with_dpkg::options/comment_3_62d671fb3c787aafcd4d058975208f75._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="picca"
+ avatar="http://cdn.libravatar.org/avatar/7e61c80d28018b10d31f6db7dddb864c"
+ subject="comment 3"
+ date="2017-07-28T15:53:03Z"
+ content="""
+Great it works
+
+thanks a lot
+"""]]
diff --git a/doc/forum/propellor_4.7.6_does_not_compile_on_jessie.mdwn b/doc/forum/propellor_4.7.6_does_not_compile_on_jessie.mdwn
new file mode 100644
index 00000000..b3e6f7c7
--- /dev/null
+++ b/doc/forum/propellor_4.7.6_does_not_compile_on_jessie.mdwn
@@ -0,0 +1,32 @@
+Hello here the error message I got while trying to compile on jessie
+
+ [ 91 of 113] Compiling Propellor.Bootstrap ( src/Propellor/Bootstrap.hs, dist/build/propellor-config/propellor-config-tmp/Propellor/Bootstrap.o ) src/Propellor/Bootstrap.hs:239:22:
+ No instance for (Typeable Bootstrapper)
+ arising from a use of `fromInfo'
+ Possible fix:
+ add an instance declaration for (Typeable Bootstrapper)
+ In the expression: fromInfo (maybe mempty hostInfo mh)
+ In a stmt of a 'do' block:
+ case fromInfo (maybe mempty hostInfo mh) of {
+ NoInfoVal
+ -> do { bs <- getGitConfigValue "propellor.buildsystem";
+ case bs of {
+ Just "stack" -> ...
+ _ -> ... } }
+ InfoVal bs
+ -> case getBuilder bs of {
+ Cabal -> cabalBuild msys
+ Stack -> stackBuild msys } }
+ In the second argument of `($)', namely
+ `do { case fromInfo (maybe mempty hostInfo mh) of {
+ NoInfoVal -> do { ... }
+ InfoVal bs
+ -> case getBuilder bs of {
+ Cabal -> ...
+ Stack -> ... } } }'
+ Warning: The package list for 'hackage.haskell.org' does not exist. Run 'cabal
+ update' to download it.
+ Resolving dependencies...
+ Configuring propellor-4.7.6...
+
+Cheers
diff --git a/doc/forum/propellor_4.7.6_does_not_compile_on_jessie/comment_1_c35f458b4c958f6397fe726f5676b700._comment b/doc/forum/propellor_4.7.6_does_not_compile_on_jessie/comment_1_c35f458b4c958f6397fe726f5676b700._comment
new file mode 100644
index 00000000..98b2d00a
--- /dev/null
+++ b/doc/forum/propellor_4.7.6_does_not_compile_on_jessie/comment_1_c35f458b4c958f6397fe726f5676b700._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-08-23T15:41:55Z"
+ content="""
+I've added a typeable instance for Bootstrapper which should fix that.
+"""]]
diff --git a/doc/forum/propellor_and_gpg2.mdwn b/doc/forum/propellor_and_gpg2.mdwn
new file mode 100644
index 00000000..d78de741
--- /dev/null
+++ b/doc/forum/propellor_and_gpg2.mdwn
@@ -0,0 +1,14 @@
+I had a problem similar to [[Key sign problem]]. Maybe in that case the fix was easy, just supplying the secret key.
+
+In my case this was a fresh install into a new Debian/sid system (so gpg2 is the default) and the failure happened during the propellor --init following the directions in the quick start at <https://propellor.branchable.com/>. During the --init I selected to create a gpg key. The message, after finally getting enough entropy and creating the gpg key, was:
+ error:gpg failed to sign the data
+ fatal: failed to write commit object
+
+So it was frustrating that propellor didn't work out of the box and there were no hints what was wrong with signing commits in git (the error above is from git and doing git commit -S was enough to reproduce it).
+
+The issue has to do with prompting for a passphrase in gpg2. If the agent is running and $GPG_TTY is set correctly you get a prompt and things will work. I was able to convince myself that if the agent wasn't running it would cause this error but it seems that gpg2 requires the agent and automatically starts it so I'm not sure how I managed that.
+
+Initially I was trying propellor before I installed a desktop so I don't know what I had for the gpg agent or how it should have been prompting. There doesn't seem to be much help out there on gpg2 + git failures but I'll keep looking.
+
+Dave
+
diff --git a/doc/forum/propellor_and_gpg2/comment_1_4b732110f59f78f73fdfb745bdd9c0dd._comment b/doc/forum/propellor_and_gpg2/comment_1_4b732110f59f78f73fdfb745bdd9c0dd._comment
new file mode 100644
index 00000000..66c4cffa
--- /dev/null
+++ b/doc/forum/propellor_and_gpg2/comment_1_4b732110f59f78f73fdfb745bdd9c0dd._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="anselmi@0a9758305bef5e058dd0263fa20a27b334b482c7"
+ nickname="anselmi"
+ avatar="http://cdn.libravatar.org/avatar/65b723eb35eb4e3b05fffafd3e13e0fd"
+ subject="Cache gpg passphrase."
+ date="2016-12-22T17:23:58Z"
+ content="""
+The bottom line on this is that gpg2 (via the agent and pinentry) doesn't prompt correctly when run from git. It does when run directly.
+
+One fix is to set GPG_TTY before running propellor: `export GPG_TTY=$(tty)` or some such.
+
+Anything else that caches the pass phrase in the agent works too since that removes the need to prompt.
+"""]]
diff --git a/doc/forum/propellor_failed_to_sign_the_commit.mdwn b/doc/forum/propellor_failed_to_sign_the_commit.mdwn
new file mode 100644
index 00000000..83a4fd44
--- /dev/null
+++ b/doc/forum/propellor_failed_to_sign_the_commit.mdwn
@@ -0,0 +1,30 @@
+Hello since sometime on my computer gpgv1 -> gpgv2 transition on Debian
+
+I get this error message. (I need to say that I am using a NitroKey Pro for my gpg keys)
+
+ Propellor build ... done
+ error: gpg n'a pas pu signer les données
+ fatal: échec de l'écriture de l'objet commit
+ Git commit ... failed
+
+reading this bug report
+
+ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568375
+
+Ifound that I need to define
+
+
+ https://www.gnupg.org/documentation/manuals/gnupg/Common-Problems.html
+
+ The gpg-agent man page nowadays includes the following hint:
+
+ It is important to set the GPG_TTY environment variable in your login
+ shell, for example in the ‘~/.bashrc’ init script:
+
+ export GPG_TTY=$(tty)
+
+don't you think that propellor should define GPG_TTY in order to avoid this problem ?
+
+thanks
+
+Frederic
diff --git a/doc/forum/propellor_failed_to_sign_the_commit/comment_1_c1dab7554841bd88d2109e9d46b31102._comment b/doc/forum/propellor_failed_to_sign_the_commit/comment_1_c1dab7554841bd88d2109e9d46b31102._comment
new file mode 100644
index 00000000..2d2315c0
--- /dev/null
+++ b/doc/forum/propellor_failed_to_sign_the_commit/comment_1_c1dab7554841bd88d2109e9d46b31102._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-07-30T14:51:13Z"
+ content="""
+I guess the problem involves running propellor at a unix tty, not in a
+GUI's virtual terminal?
+
+My limited understanding of `GPG_TTY`, refreshed by re-reading this ooold
+thread <https://bugs.debian.org/316388> is that gpg is normally able to
+detect if it's in a GUI or at a tty, and will prompt in the tty if
+necessary. Where that may fall down is when gpg is run with its stdio
+connected to pipes, since then probably isatty fails. Although in at least
+some cases, gpg apparently then
+[falls back to /dev/tty](https://dev.gnupg.org/T1434).
+
+Propellor runs gpg with stdin and stdout piped to it when eg, decrypting
+the privdata file. I tried `propellor --list-fields` at the linux console
+and it fails there.
+
+But, when I tried `propellor --spin host` at the linux console, that worked
+ok, including making the gpg signed git commit. Of course git is running
+gpg in this case, and perhaps my version of git has its own way to avoid
+this problem.
+
+This does seems like something propellor could work around fairly
+inexpensively.
+
+(See also [[propellor_and_gpg2]].)
+"""]]
diff --git a/doc/forum/propellor_failed_to_sign_the_commit/comment_2_21ff16e0871e7069749cd6c47a6fc8fe._comment b/doc/forum/propellor_failed_to_sign_the_commit/comment_2_21ff16e0871e7069749cd6c47a6fc8fe._comment
new file mode 100644
index 00000000..41120706
--- /dev/null
+++ b/doc/forum/propellor_failed_to_sign_the_commit/comment_2_21ff16e0871e7069749cd6c47a6fc8fe._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-07-30T15:15:45Z"
+ content="""
+It seems that setting `GPG_TTY` does not force gpg to prompt at a tty
+when in a GUI. At least in X with gpg 2.1, I still get a GUI prompt from
+gpg. Good.
+"""]]
diff --git a/doc/forum/propellor_failed_to_sign_the_commit/comment_3_f0e087ed1a80f42d11d34fb215183205._comment b/doc/forum/propellor_failed_to_sign_the_commit/comment_3_f0e087ed1a80f42d11d34fb215183205._comment
new file mode 100644
index 00000000..ae750878
--- /dev/null
+++ b/doc/forum/propellor_failed_to_sign_the_commit/comment_3_f0e087ed1a80f42d11d34fb215183205._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-07-30T15:33:02Z"
+ content="""
+I've made propellor set `GPG_TTY` and verified that this lets gpg prompt
+for the password at the linux console.
+
+Since I was not able to reproduce git commit signing not working, I don't
+know for sure that this fixed that, but imagine it probably would.
+"""]]
diff --git a/doc/haskell_newbie.mdwn b/doc/haskell_newbie.mdwn
index d6e339ed..8f3b60cf 100644
--- a/doc/haskell_newbie.mdwn
+++ b/doc/haskell_newbie.mdwn
@@ -47,13 +47,13 @@ Finally, you need to define the configuration for each host in the list:
[[!format haskell """
mylaptop :: Host
-mylaptop = host "mylaptop.example.com"
+mylaptop = host "mylaptop.example.com" $ props
& osDebian Unstable X86_64
& Apt.stdSourcesList
myserver :: Host
-myserver = host "server.example.com"
- & osDebian (Stable "jessie") X86_64
+myserver = host "server.example.com" $ props
+ & osDebian (Stable "stretch") X86_64
& Apt.stdSourcesList
& Apt.installed ["ssh"]
"""]]
diff --git a/doc/index.mdwn b/doc/index.mdwn
index 52c23021..1e3af9dd 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -1,7 +1,7 @@
[[!meta title="propellor: deploying properties to hosts with haskell"]]
[[!sidebar content="""
-[[Install]]
+[[Download]]
[API documentation](http://hackage.haskell.org/package/propellor)
[[Other Documentation|documentation]]
[Sample config file](http://git.joeyh.name/?p=propellor.git;a=blob;f=joeyconfig.hs)
diff --git a/doc/install.mdwn b/doc/install.mdwn
deleted file mode 100644
index ad87cedc..00000000
--- a/doc/install.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-`git clone git://propellor.branchable.com/ propellor`
-Or get it [from github](https://github.com/joeyh/propellor).
-
-Propellor is recently available in Debian.
diff --git a/doc/news/version_3.1.1.mdwn b/doc/news/version_3.1.1.mdwn
deleted file mode 100644
index b6ef29cf..00000000
--- a/doc/news/version_3.1.1.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-propellor 3.1.1 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * Haddock build fix.
- Thanks, Sean Whitton"""]] \ No newline at end of file
diff --git a/doc/news/version_3.1.2.mdwn b/doc/news/version_3.1.2.mdwn
deleted file mode 100644
index b54b396a..00000000
--- a/doc/news/version_3.1.2.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-propellor 3.1.2 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * [ Joey Hess ]
- * Ssh.knownHost: Bug fix: Only fix up the owner of the known\_hosts
- file after it exists.
- * [ Sean Whitton ]
- * Sbuild.keypairInsecurelyGenerated: Improved to be more robust.
- * Pass --allow-unrelated-histories to git merge when run with git 2.9 or
- newer. This fixes the /usr/bin/propellor wrapper with this version of git.
- * Sbuild.built &amp; Sbuild.builtFor no longer require Sbuild.keypairGenerated.
- Transition guide: If you are using sbuild 0.70.0 or newer, you should
- `rm -r /var/lib/sbuild/apt-keys`. Otherwise, you should add either
- Sbuild.keypairGenerated or Sbuild.keypairInsecurelyGenerated to your host.
- * Sbuild haddock improvements:
- - State that we don't support squeeze and Buntish older than trusty.
- This is due to our enhancements, such as eatmydata.
- - State that you need sbuild 0.70.0 or newer to build for stretch.
- This is due to gpg2 hitting Debian stretch.
- - Explain when a keygen is required.
- - Update sample ~/.sbuildrc for sbuild 0.71.0.
- - Add hint for customising chroots with propellor.
- - Update example usage of System type."""]] \ No newline at end of file
diff --git a/doc/news/version_3.2.0.mdwn b/doc/news/version_3.2.0.mdwn
deleted file mode 100644
index bef06b1b..00000000
--- a/doc/news/version_3.2.0.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-propellor 3.2.0 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * [ Sean Whitton ]
- * Using ccache with Sbuild.built &amp; Sbuild.builtFor is now toggleable: these
- properties now take a parameter of type Sbuild.UseCcache. (API Change)
- * Sbuild.piupartsConf: no longer takes an Apt.Url. (API Change)
- * Sbuild.piupartsConf &amp; Sbuild.piupartsConfFor: does nothing if corresponding
- schroot not built.
- Previously, these properties built the schroot if it was missing.
- * Sbuild.built &amp; Sbuild.piupartsConf: add an additional alias to sid chroots.
- This is for compatibility with `dgit sbuild`.
- * Further improvements to Sbuild.hs haddock.
- * [ Joey Hess ]
- * Tor.hiddenService: Converted port parameter from Int to Port. (API change)
- * Tor.hiddenServiceAvailable: The hidden service hostname file may not
- be available immedaitely after configuring tor; avoid ugly error in
- this case."""]] \ No newline at end of file
diff --git a/doc/news/version_3.2.1.mdwn b/doc/news/version_3.2.1.mdwn
deleted file mode 100644
index 214ef427..00000000
--- a/doc/news/version_3.2.1.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-propellor 3.2.1 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * Simplify Debootstrap.sourceInstall since #770217 was fixed.
- * Debootstap.installed: Fix inverted logic that made this never install
- debootstrap. Thanks, mithrandi."""]] \ No newline at end of file
diff --git a/doc/news/version_3.2.2.mdwn b/doc/news/version_3.2.2.mdwn
deleted file mode 100644
index 19acc9f7..00000000
--- a/doc/news/version_3.2.2.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-propellor 3.2.2 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * Added Linode.serialGrub property.
- * Clean up build warnings about redundant constraints when built with ghc 8.0.
- * Added Group.hasUser property. Thanks, Daniel Brooks"""]] \ No newline at end of file
diff --git a/doc/news/version_4.7.3.mdwn b/doc/news/version_4.7.3.mdwn
new file mode 100644
index 00000000..87c58e81
--- /dev/null
+++ b/doc/news/version_4.7.3.mdwn
@@ -0,0 +1,3 @@
+propellor 4.7.3 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * Expand the Trace data type."""]] \ No newline at end of file
diff --git a/doc/news/version_4.7.4.mdwn b/doc/news/version_4.7.4.mdwn
new file mode 100644
index 00000000..982f34b6
--- /dev/null
+++ b/doc/news/version_4.7.4.mdwn
@@ -0,0 +1,7 @@
+propellor 4.7.4 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * Set GPG\_TTY when run at a terminal, so that gpg can do password
+ prompting despite being connected by pipes to propellor (or git).
+ * Rsync: Make rsync display less verbose.
+ * Improve PROPELLOR\_TRACE output so serialized trace values always
+ come on their own line, not mixed with title setting."""]] \ No newline at end of file
diff --git a/doc/news/version_4.7.5.mdwn b/doc/news/version_4.7.5.mdwn
new file mode 100644
index 00000000..f2fbaf84
--- /dev/null
+++ b/doc/news/version_4.7.5.mdwn
@@ -0,0 +1,3 @@
+propellor 4.7.5 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * Avoid crashing when getTerminalName fails due to eg, being in a chroot."""]] \ No newline at end of file
diff --git a/doc/news/version_4.7.6.mdwn b/doc/news/version_4.7.6.mdwn
new file mode 100644
index 00000000..4c8abd97
--- /dev/null
+++ b/doc/news/version_4.7.6.mdwn
@@ -0,0 +1,6 @@
+propellor 4.7.6 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * Sbuild: Add Sbuild.userConfig property.
+ Thanks, Sean Whitton
+ * Locale: Make sure that the locales package is installed when enabling
+ locales."""]] \ No newline at end of file
diff --git a/doc/news/version_4.7.7.mdwn b/doc/news/version_4.7.7.mdwn
new file mode 100644
index 00000000..258f0f23
--- /dev/null
+++ b/doc/news/version_4.7.7.mdwn
@@ -0,0 +1,11 @@
+propellor 4.7.7 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * Locale: Display an error message when /etc/locale.gen does not contain
+ the requested locale.
+ * Attic module is deprecated and will warn when used.
+ Attic is no longer available in Debian and appears to have been
+ mostly supersceded by Borg.
+ * Obnam module is deprecated and will warn when used.
+ Obnam has been retired by its author.
+ * Add Typeable instance to Bootstrapper, fixing build with old versions
+ of ghc. (Previous attempt was incomplete.)"""]] \ No newline at end of file
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]]
diff --git a/doc/usage.mdwn b/doc/usage.mdwn
index fec346ae..3d32538f 100644
--- a/doc/usage.mdwn
+++ b/doc/usage.mdwn
@@ -55,6 +55,14 @@ and configured in haskell.
The hostname given to --spin can be a short name, which is
then looked up in the DNS to find the FQDN.
+* propellor --build
+
+ Causes propellor to build itself, checking that your config.hs, etc are
+ valid.
+
+ You do not need to run this as a separate step; propellor automatically
+ builds itself when using things like --spin.
+
* propellor --add-key keyid
Adds a gpg key, which is used to encrypt the privdata.
@@ -66,6 +74,10 @@ and configured in haskell.
using this key. Propellor requires signed commits when pulling from
a central git repository.
+* propellor --rm-key keyid
+
+ Stops encrypting the privdata to a gpg key.
+
* propellor --list-fields
Lists all privdata fields that are used by your propellor configuration.
diff --git a/doc/user/craige.mdwn b/doc/user/craige.mdwn
new file mode 100644
index 00000000..775e2fb0
--- /dev/null
+++ b/doc/user/craige.mdwn
@@ -0,0 +1 @@
+It's been said I was the fourth user :-)
diff --git a/doc/user/spwhitton.mdwn b/doc/user/spwhitton.mdwn
new file mode 100644
index 00000000..f5f92fac
--- /dev/null
+++ b/doc/user/spwhitton.mdwn
@@ -0,0 +1 @@
+Maintainer of propellor's Debian package, and several modules.