This partially reverts commit ab9537ca22.
From the manpage of systemd-nspawn(1):
Note that systemd-nspawn will mount file systems private to the
container to /dev, /run and similar.
Testing this in a shell turns out:
$ sudo systemd-nspawn --bind-ro=/nix/store "$(readlink "$(which ls)")" /proc
Spawning container aszlig on /home/aszlig.
Press ^] three times within 1s to kill container.
/etc/localtime does not point into /usr/share/zoneinfo/, not updating
container timezone.
1 execdomains kpageflags stat
acpi fb loadavg swaps
asound filesystems locks sys
buddyinfo fs meminfo sysrq-trigger
bus interrupts misc sysvipc
cgroups iomem modules thread-self
cmdline ioports mounts timer_list
config.gz irq mtrr timer_stats
consoles kallsyms net tty
cpuinfo kcore pagetypeinfo uptime
crypto key-users partitions version
devices keys scsi vmallocinfo
diskstats kmsg self vmstat
dma kpagecgroup slabinfo zoneinfo
driver kpagecount softirqs
Container aszlig exited successfully.
So the test on whether PID 1 exists in /proc is enough, because if we
use PID namespaces there actually _is_ a PID 1 (as shown above) and the
special file systems are already mounted. A test on the $containers
variable actually mounts them twice.
This unbreaks NixOS containers and I've tested this against the
containers-imperative NixOS test.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @rickynils, @shlevy, @edolstra
This reverts commit 3c0fdefd84.
We have to keep more history because travis build could be
triggered after new commit is made, meaning it won't be able
to checkout the repository.
The loopback-based tests use a storage size of 102400 blocks (one block
is 1024 bytes), which doesn't seem to fit for btrfs volumes in recent
btrfs versions. I'm setting this to 409600 (400 MB) now so that it
should be enough for later versions in case they need even more space
for subvolumes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Follow-up to the following commits:
abdc5961c3cdf9f5893ea1e91ba08ff5089f53a4: Fix starting the firewall
e090701e2d09aec3e8866ab9a8e53c37973ffeb4: Order before sysinit
Solely use sysinit.target here instead of multi-user.target because we
want to make sure that the iptables rules are applied *before* any
socket units are started.
The reason I've dropped the wantedBy on multi-user.target is that
sysinit.target is already a part of the dependency chain of
multi-user.target.
To make sure that this holds true, I've added a small test case to
ensure that during switch of the configuration the firewall.service is
considered as well.
Tested using the firewall NixOS test.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
Probably as a result of 992c514a20, it
was not being started anymore.
My understanding of systemd.special(7) (section "Special passive
system units") is that the firewall should want network-pre.target,
rather than the other way around (not very intuitive...). This in
itself does not cause the firewall to be wanted, which is why the
wanted-by relationship with multi-user.target is necessary.
http://hydra.nixos.org/build/39965589
So far we don't yet need the Qt 5 build for qtkeychain because the two
packages that depend on it are still using Qt 4. However, the next
upstream version of Tomahawk for example already uses Qt 5, so let's
prepare for that.
Tested building against Tomahawk Git master with qt5.qtkeychain.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Upstream changes since version 0.4.0:
* version 0.5.0 (release 2015-05-04):
- Added support for KWallet5 (KDE5/KF)
* version 0.6.0 (release 2016-03-18)
- Added support for the Windows Credential Store
* version 0.6.1 (release 2016-03-31)
- Fix KWallet not working (regressions in 0.6.0)
* version 0.6.2 (release 2016-04-04)
- KWallet: Fixes a crash when storing passwords, seen on Debian/KDE4
* version 0.7.0 (release 2016-05-23)
- Bump SO version due to 0.6 being binary-incompatible to previous
releases
Tomahawk and owncloud-client depend on this library, both are still
building fine after this update.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The following doesn't seem to be quite right and I have missed this when
I was introducing qtkeychain in the first place:
-- Installing: /nix/store/...-qtkeychain-0.4.0/$out/share/qt/translations/qtkeychain_de.qm
-- Installing: /nix/store/...-qtkeychain-0.4.0/$out/share/qt/translations/qtkeychain_ro.qm
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
