This is a minimal version of systemd that keeps only the libudev files.

These are needed for mesa, since it dlopens udev at runtime.

This is useful if you want something not in the devel target, but you
still want to build it. It will be used for the libudev-only version
of systemd which we don't need in the devel package (its in systemd
already). But we want to pull into the platform.

If this is set then only the listed files will be part of the component.
Everything else will be deleted.

This is needed to create a simple libudev package from the systemd
sources, as it can't (easily) install libudev only.

This is needed as i want to use walkDir to clean up stuff, including
directories.

This allows us to make the platform image much smaller.

The platform component doesn't have python, so starting python
directly from the systemd trigger fails. However, it also doesn't
need systemd, so we wrap it in a shellscript that checks for the
existance of python first.

This is an initial version of marking up which components are
part of the runtime. This is a point to start from, but will
need more polish.

Components marked as tags=["platform"] in the manifest gets installed
in two new target types, "platform" (only runtime tree) and "sdk"
(runtime and devel stuff). Tags with "sdk" will only be in the sdk.
This will be used to create the app runtime and SDK for Gnome
sandboxed apps.

systemd doesn't support complex scripts in ExecStart. Instead we should use
several ExecStart calls

https://bugzilla.gnome.org/show_bug.cgi?id=735456

We don't have networking.

No idea how that snuck in the last commit.

The problem should be fixed now.

the build is fixed now

it fails to build now

This reverts commit 96b0a48f.

To be able to retroactively have the revision => target map for
older builds, add a new builtin that regenerates the index.json
for each day. (It could also regenerate indices on higher levels
if we extend those in the future - right now there is no reason
to rebuild them, so we don't.)

https://bugzilla.gnome.org/show_bug.cgi?id=733838

For perf.gnome.org, we need the ability to map back from revision
to a particular build, so we can use recorded build data to figure
out what changed between measurements.

We know within a few minutes when a build completed and measurement
started, so it's sufficient to be able to do the map at day granularity,
so add a map to each day's index.json that goes from revision to
build serial and target.

https://bugzilla.gnome.org/show_bug.cgi?id=733838

Header file issues between xserver and the drivers seem to be fixed
now.

It links to a scary index page, so it's not for the faint of heart.

Thank you for the beer.

No module depends on it