summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/forum/Apt.install_return_ok_even_if_asked_something_impossible.mdwn14
-rw-r--r--doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_4_7ee19c190d1acb8106079871dda7f521._comment8
-rw-r--r--doc/todo/integrate_shell-monad/comment_3_155d4af99bbbd8681a9924198aa7da73._comment11
-rw-r--r--doc/todo/integrate_shell-monad/comment_4_4914d37a548e1a19733156fbd77142a6._comment20
-rw-r--r--doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_4466bc58fd3e69938c184c817ddbb3e6._comment23
-rw-r--r--doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_6460a7f85249bd8b9a83f2e145a25d62._comment29
-rw-r--r--doc/todo/merge_request:_changes_to_Reboot.hs/comment_4_b39af83b7f793013a7d63f340ee8de6d._comment29
7 files changed, 134 insertions, 0 deletions
diff --git a/doc/forum/Apt.install_return_ok_even_if_asked_something_impossible.mdwn b/doc/forum/Apt.install_return_ok_even_if_asked_something_impossible.mdwn
new file mode 100644
index 00000000..2858a75a
--- /dev/null
+++ b/doc/forum/Apt.install_return_ok_even_if_asked_something_impossible.mdwn
@@ -0,0 +1,14 @@
+Hello joey
+
+here the result of the Apt.installed [ "dgit", "pypi2dsc" ]
+
+ apt installed dgit pypi2dsc ... ok
+
+
+BUT
+
+pypi2dsc does not exist (it is pypi2deb)
+
+So there is something wrong with the installed property :)
+
+Cheers
diff --git a/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_4_7ee19c190d1acb8106079871dda7f521._comment b/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_4_7ee19c190d1acb8106079871dda7f521._comment
new file mode 100644
index 00000000..83ebf6ec
--- /dev/null
+++ b/doc/forum/cabal:_Unrecognised_flags:_propellor-config/comment_4_7ee19c190d1acb8106079871dda7f521._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="craige@a46118dff5bc0fad85259759970d8b4b9fc377d7"
+ nickname="craige"
+ subject="Resolved"
+ date="2016-06-13T23:35:40Z"
+ content="""
+Cracked enough heads to get the box upgraded and the issue unsurpisingly vanished :-)
+"""]]
diff --git a/doc/todo/integrate_shell-monad/comment_3_155d4af99bbbd8681a9924198aa7da73._comment b/doc/todo/integrate_shell-monad/comment_3_155d4af99bbbd8681a9924198aa7da73._comment
new file mode 100644
index 00000000..48d25d7f
--- /dev/null
+++ b/doc/todo/integrate_shell-monad/comment_3_155d4af99bbbd8681a9924198aa7da73._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="gueux"
+ subject="comment 3"
+ date="2016-06-14T10:56:04Z"
+ content="""
+I've posted a question on https://github.com/Gabriel439/Haskell-Turtle-Library/issues/157
+
+Probably Gabriel will have a good idea for this :-). Maybe another solution would be to generate executables instead of shell scripts?
+
+
+"""]]
diff --git a/doc/todo/integrate_shell-monad/comment_4_4914d37a548e1a19733156fbd77142a6._comment b/doc/todo/integrate_shell-monad/comment_4_4914d37a548e1a19733156fbd77142a6._comment
new file mode 100644
index 00000000..77f30917
--- /dev/null
+++ b/doc/todo/integrate_shell-monad/comment_4_4914d37a548e1a19733156fbd77142a6._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-06-14T17:11:09Z"
+ content="""
+We already have /usr/local/bin/propellor executable, so the cron job or
+whatever could be made to run it with a parameter that runs the turtle IO
+action. (Or generally, any IO action.. Being able to run arbitrary haskell
+IO code as a cron job would be great!)
+
+This would need some way to get a `UniqueId` for an IO action, that is
+stable across runs of propellor, and a way to build up a` Map UniqueId (IO ())` of such
+actions. The Info interface could be used to build up that Map.
+
+----
+
+Some of the places I'd like to use shell-monad though are where propellor
+is bootstrapping itself on a host and all it can easily run at that point
+is shell script.
+"""]]
diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_4466bc58fd3e69938c184c817ddbb3e6._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_4466bc58fd3e69938c184c817ddbb3e6._comment
new file mode 100644
index 00000000..4fa14683
--- /dev/null
+++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_4466bc58fd3e69938c184c817ddbb3e6._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="comment 3"
+ date="2016-06-14T03:16:18Z"
+ content="""
+Thanks for taking a look at my branch, and especially for fixing my inadequately-tested `readVersionMaybe`.
+
+`Sbuild.built` does not *require* a particular version of the kernel. It is just that the file that it generates in `/etc/schroot/chroot.d` can vary depending on the kernel version running at the time that `Sbuild.built` is first ensured. In particular, if the running kernel does not support overlayfs (as jessie's kernel doesn't), the line `union-type=overlay` will be omitted from the file in `/etc/schroot/chroot.d`. This renders `Schroot.overlaysInTmpfs` useless.
+
+I think it should be up to the user to apply a property like
+
+ & Sbuild.built foo `requires` Reboot.toKernelNewerThan bar
+
+to individual hosts, because it depends on whether they actually care about using an overlay chroot. Perhaps on an old machine they don't intend to use overlays. In my config, I do something like this:
+
+ & osDebian Testing \"i386\"
+ & Apt.stdSourcesList `onChange` (Apt.upgraded `before` Apt.cacheCleaned `before` Reboot.toKernelNewerThan \"4\")
+ & Sbuilt.builtFor ...
+
+The idea is that if I reinstall my machine from a jessie installation CD, propellor will upgrade to testing and boot to the new kernel before it builds the chroot, so I get the `union-type=overlay` line in my config.
+
+I could prepare a patch to add this information to the haddock of Sbuild.hs?
+"""]]
diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_6460a7f85249bd8b9a83f2e145a25d62._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_6460a7f85249bd8b9a83f2e145a25d62._comment
new file mode 100644
index 00000000..3d842ac3
--- /dev/null
+++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_3_6460a7f85249bd8b9a83f2e145a25d62._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-06-14T04:04:50Z"
+ content="""
+It might also be worth making the Sbuild properties know
+whether overlays are desired. Then they could make sure to set up the
+config file with the needed lines, even if the wrong kernel is running.
+
+I assume schroot fails to work in that configuration, so the properties
+for it would fail and then the user would notice they need to add a
+property to get a new enough kernel version..
+
+It could be specified with another parameter to the Sbuild properties.
+Or, you could add a pure Info property `useOverlays` and have the
+Sbuild properties check if the Info has that set. This would also
+let Schroot.overlaysInTmpfs require useOverlays and auto-enable them.
+
+Most of the implementation of that:
+
+ useOverlays :: Property (HasInfo + UnixLike)
+ useOverlays = pureInfoProperty "use schroot overlays" (InfoVal UseOverlays)
+
+ data UseOverlays = UseOverlays
+
+ useOverlays :: Propellor Bool
+ useOverlays = isJust . fromInfoVal
+ <$> (askInfo :: Propellor (InfoVal UseOverlays))
+"""]]
diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_4_b39af83b7f793013a7d63f340ee8de6d._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_4_b39af83b7f793013a7d63f340ee8de6d._comment
new file mode 100644
index 00000000..148f8efb
--- /dev/null
+++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_4_b39af83b7f793013a7d63f340ee8de6d._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-06-14T03:41:53Z"
+ content="""
+When `requires` is used as in your first example, Reboot.toKernelNewerThan
+does not need to throw an exception. It could just return FailedChange
+and then Sbuild.builtFor wouldn't get run.
+
+Your second example, as written is actually buggy. If Apt.upgraded
+fails for some reason, then Reboot.toKernelNewerThan never gets run,
+and then Sbuilt.builtFor can still run with the wrong kernel version.
+
+The second example could instead be written thus:
+
+ & osDebian Testing "i386"
+ & combineProperties "sbuild setup"
+ ( props
+ & Apt.stdSourcesList `onChange` (Apt.upgraded `before` Apt.cacheCleaned `before` Reboot.toKernelNewerThan "4")
+ & Sbuilt.builtFor ...
+ )
+
+Then if any part of the upgrade fails the following properties don't run
+thanks to `combineProperties`. And here too Reboot.toKernelNewerThan does
+not need to thow an exception.
+
+So, I'm not seeing any good use cases for it throwing an exception in these
+examples.
+"""]]