This introduces the following changes:
- New subcommand "show" for hetznerctl which shows additional
information about one or more servers.
- Allow to get subnets of a specific server through the "subnets"
attribute.
- Allow te get IP addresses of a specific server through the "ips"
attribute.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is a simple tool to scan Nixpkgs for violations of the packaging
guidelines, such as multiple packages with the same name, packages
that lack a description or license, and so on.
To use:
$ nix-env -i nixpkgs-lint
$ cd .../nixpkgs
$ nixpkgs-lint
Current statistics:
Number of packages: 8666
Number of missing maintainers: 3711
Number of missing licenses: 6159
Number of missing descriptions: 1337
Number of bad descriptions: 633
Number of name collisions: 277
The sha256 has changed upstream for 30.0.1566.2 and in addition there is
a new version available, so let's switch to the new version.
Unfortunately the user namespaces sandbox patch doesn't apply anymore
because of http://crbug.com/242290, so this adds a rebased version on
top of the current trunk of Chromium.
In order to build version 30, file is now needed as an additional build
input, because it is used by gyp.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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.
Since "src" is a fetchsvn directory, the source is copied with "cp
--no-preserve=timestamps" (see commit
6d928ab684). 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.
For Linux, the phases was run in the wrong order. I've
fixed that, but the package is still a complete mess that
needs to be cleaned up. The linux and darwin builds should
probably be separated into two different Nix expressions
to avoid the current conditional mess.
