summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJoey Hess2016-06-16 17:04:45 -0400
committerJoey Hess2016-06-16 17:04:45 -0400
commited475d6818263f714aac599f9915080a8beb1b9b (patch)
tree40cd5fa31fa4f8ec06240d7d36beb2c97a605d81
parent1ac943d0143b6d822d12ceb920109690c7ad8095 (diff)
parent8fa80f9cc25edb26651ad1d90c8f84094be728f1 (diff)
Merge branch 'master' of ssh://propellor.branchable.com
-rw-r--r--doc/forum/Bug_with_Sbuild.mdwn68
-rw-r--r--doc/forum/Systemd_container_pre-setup_properties.mdwn3
-rw-r--r--doc/todo/merge_request:_changes_to_Reboot.hs/comment_6_c2b043ecea1524e4d5743196fc0d191c._comment13
3 files changed, 84 insertions, 0 deletions
diff --git a/doc/forum/Bug_with_Sbuild.mdwn b/doc/forum/Bug_with_Sbuild.mdwn
new file mode 100644
index 00000000..3891ba69
--- /dev/null
+++ b/doc/forum/Bug_with_Sbuild.mdwn
@@ -0,0 +1,68 @@
+Hello, I installed a machine with these properties
+
+
+ & sbuild (System (Debian Unstable) "i386") (Just proxy)
+ & Sbuild.piupartsConfFor (System (Debian Unstable) "i386")
+ & Sbuild.updatedFor (System (Debian Unstable) "i386") `period` Weekly (Just 1)
+ & Sbuild.usableBy (User "picca")
+ & Sbuild.shareAptCache
+
+where
+
+
+ type Proxy = Maybe Url
+
+ sbuild :: System -> Proxy -> RevertableProperty (HasInfo + Linux) Linux
+ sbuild system@(System dist arch) proxy = Sbuild.builtFor system `before` setup
+ where
+ setup :: RevertableProperty (HasInfo + Linux) Linux
+ setup = Chroot.provisioned chroot
+ chroot = Chroot.debootstrapped Debootstrap.BuilddD chrootdir $ props
+ & os
+ & case proxy of
+ (Just p) -> "/etc/apt/apt.conf.d/01proxy" `File.hasContent` ["Acquire::http::Proxy \"" ++ p ++ "\";"]
+ Nothing -> doNothing
+ & Apt.installed ["apt-transport-https"]
+ & Apt.stdSourcesList
+ & Apt.update `onChange` Apt.upgrade
+ & Apt.cacheCleaned
+ chrootdir :: FilePath
+ chrootdir = "/srv/chroot" </>
+ case dist of
+ (Debian suite) -> Apt.showSuite suite ++ "-" ++ arch
+ (Buntish suite) -> suite ++ "-" ++ arch
+ os = case dist of
+ (Debian suite) -> osDebian suite arch
+
+
+But when I use it I get this error message
+
+
+ i686-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/«PKGBUILDDIR»/src -I/usr/include/python2.7 -c /«PKGBUILDDIR»/python/cython/_fisx.cpp -o build/temp.linux-i686-2.7/«PKGBUILDDIR»/python/cython/_fisx.o
+ ccache: error: Failed to create directory /var/cache/ccache-sbuild/9/1: Permission denied
+ error: command 'i686-linux-gnu-gcc' failed with exit status 1
+ E: pybuild pybuild:274: build: plugin distutils failed with: exit code=1: /usr/bin/python setup.py build
+
+ picca@ORD03037:~/Debian/python-fisx/python-fisx$ ls -l /var/cache/ccache-sbuild/
+ total 76
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 0
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 1
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 2
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 3
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 4
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 5
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 6
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 7
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 8
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 9
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 a
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 b
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 c
+ -rw-rw-r-- 1 picca instrumentation 16 juin 16 16:32 ccache.conf
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 d
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 e
+ drwxr-xr-x 2 root root 4096 juin 16 15:48 f
+ -r-xr-xr-x 1 root root 172 juin 16 15:48 sbuild-setup
+ drwxrwxr-x 2 picca instrumentation 4096 juin 16 16:32 tmp
+
+
diff --git a/doc/forum/Systemd_container_pre-setup_properties.mdwn b/doc/forum/Systemd_container_pre-setup_properties.mdwn
new file mode 100644
index 00000000..1cb94d66
--- /dev/null
+++ b/doc/forum/Systemd_container_pre-setup_properties.mdwn
@@ -0,0 +1,3 @@
+When creating a systemd container, what would be the best way to execute properties before propellor is run inside the container proper?
+
+I'm trying to setup packages for networking in a systemd container, but I first need the network to get the packages. Ideally, we should be able to run a few properties on the chroot that are used when creating a systemd container (and therefore use the host network). So far, I've solved this by adding the properties in the Systemd.Core.installed property. Not nice, but works if all your systemd containers are the same. I've tried creating a chroot myself, tar it and pass that to Systemd.container, but things got a little complicated. It also requires additional properties on the host that have to be moved if the container moved to another host.
diff --git a/doc/todo/merge_request:_changes_to_Reboot.hs/comment_6_c2b043ecea1524e4d5743196fc0d191c._comment b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_6_c2b043ecea1524e4d5743196fc0d191c._comment
new file mode 100644
index 00000000..05ca43ae
--- /dev/null
+++ b/doc/todo/merge_request:_changes_to_Reboot.hs/comment_6_c2b043ecea1524e4d5743196fc0d191c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="comment 6"
+ date="2016-06-16T06:30:04Z"
+ content="""
+I like the idea of a `useOverlays` info property. It is better, and more in the spirit of propellor, to have the choice explicit, rather than implicitly relying on the behaviour of certain shell commands in certain conditions (relying on sbuild-createchroot(1) to create the config file in /etc/schroot/chroot.d is the thing I like least about Sbuild.hs, though it's necessary for achieving the goal of having a totally standard Debian sbuild setup).
+
+Before I implement this, I have a couple of questions:
+
+1. In the case where `Reboot.toKernelNewerThan` finds a satisfactory kernel to reboot to, what do you think about the choice of rebooting immediately or at the end of the current propellor run? If every property that needs the newer kernel `requires` it, it would mean that other properties that don't need the newer kernel get ensured sooner. Not sure whether this is actually an advantage, but it might encourage using `requires` instead of relying on implicit ordering.
+
+2. You suggest relying on schroot(1) and sbuild-createchroot(1) failing if `union-type=overlay` is present in the config file but the kernel doesn't support overlays. I'd prefer to go further and have the sbuild properties conditionally `requires` `Reboot.toKernelNewerThan` if the info property is set. That way, we can be confident that we'll never get an inconsistent state out of the sbuild properties. Does this sound sensible?
+"""]]