nixpkgs-suyu/pkgs/build-support/vm/windows/cygwin-iso/mkclosure.py

79 lines
2.3 KiB
Python
Raw Normal View History

vm: Introduce new Windows VM installer for Cygwin. After quite a lot of fighting against Windows and its various limitations, this new is the base architecture for installing and accessing the Windows VM and thus the Cygwin environment inside it: .------------. .---> | vde_switch | | `-[#]----[#]-' | | | ,' .' `---.___ ,' 192.168.0.1 `. | | 192.168.0.2 ,' _____[#]____ | ,' | | ______[#]______ | | Windows VM | | .--' | | |____________| | | | | | /|\ | .-| | | .---------. | | | | | | .-|-| manager |-' | | | | | | | `---------' | | | | | | | | | | | | | | .-------------. | | Samba | | | | BOOTSTRAP | | | | | | | | |-------------| | | | | .------| | `-| spawn VMs |-+--> | | `---| xchg | <-------. | |-------------| | | .---^------| | | | install |---. | `-| nixstore | <----. | | |-------------| | | `----------| | | |---| suspend VM | | | | | | | `------.------' | | Controller VM | | | | | | |_______________| | | | .--' | /|\ VirtIO | | __|__________:____________ | | | \|/ | | `. | | | | .------------. | | : | | | | | REAL BUILD | | | .-------^--------. | | | | |------------| | `-> | serial console | | | | `-| revive VM | | `----------------' | | | |------------| |------------. | | | | build |-->| /nix/store >>>-----------|-' | |------------| |------------| | | | collect |<--| xchg >>>-----------|----' `-----.------' |------------' | | | | \|/ | | | __ ___ | | | |--| | | (__ -|- | F I N I S H E D | | | |__| ___) | | |__________________________| This might look a bit overwhelming, but let me try to explain: We're starting at the base derivation ("BOOTSTRAP" above), where we actually install the Cygwin envirenment. Over there we basically fire up a vde_switch process and two virtual machines: One is the Windows machine, the other is a NixOS machine, which serves as some kind of proxy between the host and the Windows machine. The reason we're doing this, is because we don't have a lot of options for sharing files between a stock Windows machine and the host. In earlier experiments, I've tried to communicate with the Windows guest by using pipes and OpenSSH, but obviously this wasn't a big speed rush (or to say it bluntly: It was fucking slow). Using TCP/IP directly for accessing the guest would have been another option, but it could lead to possible errors when the port or a range of ports are in use at the Host system. Also, we would need to punch a hole into the sandbox of the Nix builder (as it doesn't allow networking), which in turn will possibly undermine deterministic builds/runs (well, at least as deterministic as it can be, we're running Windows, remember?). So, let's continue: The responsibility of the NixOS (controller) VM is to just wait until an SSH port becomes available on the Windows VM, whereas the Windows VM itself is installed using an unattended installation file provided via a virtual floppy image. With the installation of the basic Windows OS, we directly install Cygwin and start up an OpenSSH service. At this point the bootstrapping is almost finished and as soon as the port is available, the controller VM sets up Samba shares and makes it available as drive letters within Windows and as bind mounts (for example /nix/store) within Cygwin. Finally we're making a snapshot of the memory of the Windows VM in order to revive it within a few seconds when we want to build something. Now, the build process itself is fairly straightforward: Revive VM and build based on existing store derivations and collect the result _and_ the exit code from the xchg share/directory. Conclusion: This architecture may sound a bit complicated, but we're trying to achieve deterministic and reproducable builds and/or test runs. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2014-02-15 03:47:57 +01:00
# Ugliest Python code I've ever written. -- aszlig
import sys
def get_plist(path):
in_pack = False
in_str = False
current_key = None
buf = ""
packages = {}
package_name = None
package_attrs = {}
with open(path, 'r') as setup:
for line in setup:
if in_str and line.rstrip().endswith('"'):
package_attrs[current_key] = buf + line.rstrip()[:-1]
in_str = False
continue
elif in_str:
buf += line
continue
if line.startswith('@'):
in_pack = True
package_name = line[1:].strip()
package_attrs = {}
elif in_pack and ':' in line:
key, value = line.split(':', 1)
if value.lstrip().startswith('"'):
if value.lstrip()[1:].rstrip().endswith('"'):
value = value.strip().strip('"')
else:
in_str = True
current_key = key.strip().lower()
buf = value.lstrip()[1:]
continue
package_attrs[key.strip().lower()] = value.strip()
elif in_pack:
in_pack = False
packages[package_name] = package_attrs
return packages
def main():
packages = get_plist(sys.argv[1])
to_include = set()
def traverse(package):
to_include.add(package)
attrs = packages.get(package, {})
deps = attrs.get('requires', '').split()
for new_dep in set(deps) - to_include:
traverse(new_dep)
map(traverse, sys.argv[2:])
sys.stdout.write('[\n')
for package, attrs in packages.iteritems():
if package not in to_include:
cats = [c.lower() for c in attrs.get('category', '').split()]
if 'base' not in cats:
continue
install_line = attrs.get('install')
if install_line is None:
continue
url, size, hash = install_line.split(' ', 2)
vm: Introduce new Windows VM installer for Cygwin. After quite a lot of fighting against Windows and its various limitations, this new is the base architecture for installing and accessing the Windows VM and thus the Cygwin environment inside it: .------------. .---> | vde_switch | | `-[#]----[#]-' | | | ,' .' `---.___ ,' 192.168.0.1 `. | | 192.168.0.2 ,' _____[#]____ | ,' | | ______[#]______ | | Windows VM | | .--' | | |____________| | | | | | /|\ | .-| | | .---------. | | | | | | .-|-| manager |-' | | | | | | | `---------' | | | | | | | | | | | | | | .-------------. | | Samba | | | | BOOTSTRAP | | | | | | | | |-------------| | | | | .------| | `-| spawn VMs |-+--> | | `---| xchg | <-------. | |-------------| | | .---^------| | | | install |---. | `-| nixstore | <----. | | |-------------| | | `----------| | | |---| suspend VM | | | | | | | `------.------' | | Controller VM | | | | | | |_______________| | | | .--' | /|\ VirtIO | | __|__________:____________ | | | \|/ | | `. | | | | .------------. | | : | | | | | REAL BUILD | | | .-------^--------. | | | | |------------| | `-> | serial console | | | | `-| revive VM | | `----------------' | | | |------------| |------------. | | | | build |-->| /nix/store >>>-----------|-' | |------------| |------------| | | | collect |<--| xchg >>>-----------|----' `-----.------' |------------' | | | | \|/ | | | __ ___ | | | |--| | | (__ -|- | F I N I S H E D | | | |__| ___) | | |__________________________| This might look a bit overwhelming, but let me try to explain: We're starting at the base derivation ("BOOTSTRAP" above), where we actually install the Cygwin envirenment. Over there we basically fire up a vde_switch process and two virtual machines: One is the Windows machine, the other is a NixOS machine, which serves as some kind of proxy between the host and the Windows machine. The reason we're doing this, is because we don't have a lot of options for sharing files between a stock Windows machine and the host. In earlier experiments, I've tried to communicate with the Windows guest by using pipes and OpenSSH, but obviously this wasn't a big speed rush (or to say it bluntly: It was fucking slow). Using TCP/IP directly for accessing the guest would have been another option, but it could lead to possible errors when the port or a range of ports are in use at the Host system. Also, we would need to punch a hole into the sandbox of the Nix builder (as it doesn't allow networking), which in turn will possibly undermine deterministic builds/runs (well, at least as deterministic as it can be, we're running Windows, remember?). So, let's continue: The responsibility of the NixOS (controller) VM is to just wait until an SSH port becomes available on the Windows VM, whereas the Windows VM itself is installed using an unattended installation file provided via a virtual floppy image. With the installation of the basic Windows OS, we directly install Cygwin and start up an OpenSSH service. At this point the bootstrapping is almost finished and as soon as the port is available, the controller VM sets up Samba shares and makes it available as drive letters within Windows and as bind mounts (for example /nix/store) within Cygwin. Finally we're making a snapshot of the memory of the Windows VM in order to revive it within a few seconds when we want to build something. Now, the build process itself is fairly straightforward: Revive VM and build based on existing store derivations and collect the result _and_ the exit code from the xchg share/directory. Conclusion: This architecture may sound a bit complicated, but we're trying to achieve deterministic and reproducable builds and/or test runs. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2014-02-15 03:47:57 +01:00
pack = [
' {',
' url = "{0}";'.format(url),
' hash = "{0}";'.format(hash),
vm: Introduce new Windows VM installer for Cygwin. After quite a lot of fighting against Windows and its various limitations, this new is the base architecture for installing and accessing the Windows VM and thus the Cygwin environment inside it: .------------. .---> | vde_switch | | `-[#]----[#]-' | | | ,' .' `---.___ ,' 192.168.0.1 `. | | 192.168.0.2 ,' _____[#]____ | ,' | | ______[#]______ | | Windows VM | | .--' | | |____________| | | | | | /|\ | .-| | | .---------. | | | | | | .-|-| manager |-' | | | | | | | `---------' | | | | | | | | | | | | | | .-------------. | | Samba | | | | BOOTSTRAP | | | | | | | | |-------------| | | | | .------| | `-| spawn VMs |-+--> | | `---| xchg | <-------. | |-------------| | | .---^------| | | | install |---. | `-| nixstore | <----. | | |-------------| | | `----------| | | |---| suspend VM | | | | | | | `------.------' | | Controller VM | | | | | | |_______________| | | | .--' | /|\ VirtIO | | __|__________:____________ | | | \|/ | | `. | | | | .------------. | | : | | | | | REAL BUILD | | | .-------^--------. | | | | |------------| | `-> | serial console | | | | `-| revive VM | | `----------------' | | | |------------| |------------. | | | | build |-->| /nix/store >>>-----------|-' | |------------| |------------| | | | collect |<--| xchg >>>-----------|----' `-----.------' |------------' | | | | \|/ | | | __ ___ | | | |--| | | (__ -|- | F I N I S H E D | | | |__| ___) | | |__________________________| This might look a bit overwhelming, but let me try to explain: We're starting at the base derivation ("BOOTSTRAP" above), where we actually install the Cygwin envirenment. Over there we basically fire up a vde_switch process and two virtual machines: One is the Windows machine, the other is a NixOS machine, which serves as some kind of proxy between the host and the Windows machine. The reason we're doing this, is because we don't have a lot of options for sharing files between a stock Windows machine and the host. In earlier experiments, I've tried to communicate with the Windows guest by using pipes and OpenSSH, but obviously this wasn't a big speed rush (or to say it bluntly: It was fucking slow). Using TCP/IP directly for accessing the guest would have been another option, but it could lead to possible errors when the port or a range of ports are in use at the Host system. Also, we would need to punch a hole into the sandbox of the Nix builder (as it doesn't allow networking), which in turn will possibly undermine deterministic builds/runs (well, at least as deterministic as it can be, we're running Windows, remember?). So, let's continue: The responsibility of the NixOS (controller) VM is to just wait until an SSH port becomes available on the Windows VM, whereas the Windows VM itself is installed using an unattended installation file provided via a virtual floppy image. With the installation of the basic Windows OS, we directly install Cygwin and start up an OpenSSH service. At this point the bootstrapping is almost finished and as soon as the port is available, the controller VM sets up Samba shares and makes it available as drive letters within Windows and as bind mounts (for example /nix/store) within Cygwin. Finally we're making a snapshot of the memory of the Windows VM in order to revive it within a few seconds when we want to build something. Now, the build process itself is fairly straightforward: Revive VM and build based on existing store derivations and collect the result _and_ the exit code from the xchg share/directory. Conclusion: This architecture may sound a bit complicated, but we're trying to achieve deterministic and reproducable builds and/or test runs. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
2014-02-15 03:47:57 +01:00
' }',
];
sys.stdout.write('\n'.join(pack) + '\n')
sys.stdout.write(']\n')
if __name__ == '__main__':
main()