The default 10.0 is deprecated and removed upstream. Also, instead of
twiddling the hardened flag we should just use the hardened profile.
As part of this the host SDK no longer has multilib enabled, it isn't
actually needed for anything anyway.
When enabling policy kit there appears to be a build race condition in
the generation of updating translations in policy files. There is a nls
configure flag in systemd now, we don't need translations.
The existing ebuild uses a really crazy hack for cross compiling which
may have worked a few versions ago but it doesn't now. The root issue is
that Mozilla mixes up the meaning of "host" and "target" so give in to
their stupid and setup the environment with their meaning.
The configure script claimed in a comment:
In Mozilla, we use the names $target, $host and $build incorrectly,
but are too far gone to back out now. See Bug 475488:
- When we say $target, we mean $host, that is, the system on which
Mozilla will be run.
- When we say $host, we mean $build, that is, the system on which
Mozilla is built.
- $target (in its correct usage) is for compilers who generate
code for a different platform than $host, so it would not be used
by Mozilla.
I'm inclined to smack someone with a stick.
If additional EBS volumes are mapped to a PV instance using a "sd*" name
they will always be ordered by the hypervisor before "xvd*" devices,
again ignoring the root device definition. This applies to all PV
instance types so we cannot get away with just poo-pooing m1.small.
We will need to call attention to this since it requires users who set
the volume size via APIs to use the name "/dev/sda" again.
Lots of things here, wget for example is not strictly related but
updating mit-krb5 required pulling in a multilib version of the openssl
library which in turn impacts how other dependencies work. The new libev
and libverto dependencies are the ones directly required by mit-krb5.
Packages updated:
app-crypt/mit-krb5
dev-libs/libev
dev-libs/libverto
dev-libs/openssl
net-misc/openssh
net-misc/wget
virtual/krb5
For a long time these scripts have always set images as public
regardless of whether the image was a working production image or not.
This may lead users to boot random development images if they happen to
pop up to the top of Amazon's terrible AMI search page.
