So, chromium 30 entered the dev release channel, so the overview of the
current versions is:
stable: 28.0.1500.52 -> 28.0.1500.71 (builds fine, tested)
beta: 28.0.1500.52 -> 29.0.1547.22 (builds fine, tested)
dev: 29.0.1547.0 -> 30.0.1566.2 (builds fine, tested)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
As requested by some users, we finally have support for cloud sync,
spelling, geolocation and a lot more of the services that require API
keys from Google. Details about which services are involved can be found
at: http://www.chromium.org/developers/how-tos/api-keys
Thanks to Paweł Hajdan <phajdan@google.com> for giving us permission to
distribute the API keys with our build of Chromium:
> Note that the public Terms of Service do not allow distribution of the
> API keys in any form. To make this work for you, on behalf of Google
> Chrome Team I am providing you with:
> Official permission to include Google API keys in your packages and to
> distribute these packages. The remainder of the Terms of Service for
> each API applies, but at this time you are not bound by the
> requirement to only access the APIs for personal and development use,
> and Additional quota for each API in an effort to adequately support
> your users.
As noted in the source: Those keys are for use in NixOS/nixpkgs ONLY!
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This also fixes the annoying issue that minicom doesn't work out of the
box:
$ minicom
minicom: there is no global configuration file /etc/minirc.dfl
Ask your sysadmin to create one (with minicom -s).
$ sudo minicom -s
minicom: there is no global configuration file /etc/minirc.dfl
Ask your sysadmin to create one (with minicom -s).
minicom 2.4 basically refuses to enter setup unless /etc/minirc.dfl
already exists. sudo touch /etc/minirc.dfl is enough to fix that though,
but with this commit "sudo minicom -s" will work out of the box.
It used to be set to 7 (debug) so you get lots of crap on the console.
The new value of 4 is also what Ubuntu uses. Red Hat uses 3.
A nice side effect is that it's more likely that the LUKS passphrase
prompt doesn't get clobbered by kernel log messages.
Since "src" is a fetchsvn directory, the source is copied with "cp
--no-preserve=timestamps" (see commit
6d928ab684327e0eeb1bf6cd889d57ca7127e8a7). So some source files might
get a slightly different timestamp. Here, if lib/standard.ppmdfont
gets a newer timestamp than the generated file lib/standardppmdfont.c,
Make will try to rebuild the latter. But that fails because the
ppmdcfont program doesn't exist (yet).
Probably stdenv should ensure that every file has the same timestamp.
