Minor sync with upstream, adds a use flag we don't enable.
Updated our toolchain just in time, the -fuse-ld= option is now
supported and as of 218 systemd doesn't link with bfd any more so now is
a good time to re-enable the configure test to enable it. For reference
the guilty commit at fault is probably:
5f86c1f4c4
Or specifically:
```c
/* GCC maps this magically to the beginning and end of the BUS_ERROR_MAP section */
extern const sd_bus_error_map __start_BUS_ERROR_MAP[];
extern const sd_bus_error_map __stop_BUS_ERROR_MAP[];
```
... to which I say haha wtf... WELL WHAT ABOUT WHEN IT DOESN'T? :-P
The new dockerd wrapper script does its best to select between the btrfs
and overlay backends based on the filesystem mounted at /var/lib/docker.
The new 1.4 version will remain marked as ~amd64 for testing purposes
until we stabilize its dependencies, including Linux 3.18.x.
This is a temporary workaround to allow people to transistion into 1.3+
smoothly. This sets --insecure-registry=0.0.0.0/0 to maintain backward
compatibility.
Adding the update step appears to break permissions on the distfiles
directory. Ensure the portage user is correct and set the permissions on
directories it needs to write to in advance.
When bootstrapping a SDK we need to update GCC dependencies to ensure
the GCC built for stage1 is linked against the same library versions as
those that are included in the stage1. Without this updating the mpc
library just results in a broken stage1.
The linux-info eclass may trigger a fatal error if it is unable to check
a package's required kernel options. Even when the error isn't fatal the
warnings add a lot of clutter to our build output.
Fixes commit 3f028060 which mistakenly added coreos-sources as both
build and run-time dependencies. This was missed initially because there
are exclude rules that remove /usr/src from production images but it
does needlessly slow down the build and pulls in extraneous kernel build
dependencies like perl.
Prune old releases, no need for them.
Probing all filesystem types on all block devices appears to hang
booting Amazon EC2 HVM instances. The console output is unreliably
buffered so there is no information on what the failure actually is. On
the up side we can work around it easily by only searching the GPT which
appears to be safe.
