It's bad to have the kernel config scattered across two places. (This
should also be done for the other architectures.)
Also, restore Xen and KVM guest support in Linux 3.10.
Having N different copies of the NixOS kernel configuration is bad
because these copies tend to diverge. For instance, our 3.10 config
lacked some modules that were enabled in older configs, probably
because the 3.10 config had been copied off an earlier version of some
older kernel config.
So now there is a single kernel config in common-config.nix. It has a
few conditionals to deal with new/removed kernel options, but
otherwise it's pretty straightforward.
Also, a lot of cut&paste boilerplate between the kernel Nix
expressions is gone (such as preConfigure).
Change PATH=$PATH:deps to PATH=deps:$PATH in the wicd wrappers, because
the latter is more deterministic; it prevents possibly wrong versions of
dependencies to sneak in from the environment.
Do the same for PYTHONPATH.
It doesn't make sense to build tools/applications with three different
python interpreter versions, so move them out of python modules list.
Also reverts 53ffc6e0ef.
We cannot import the packages from all of these three packages sets into
the global namespace, because they are indistinguishable. For example:
$ nix-env -qaP \* | grep pylint
pypyPackages.pylint pylint-0.26.0
python33Packages.pylint pylint-0.26.0
python27Packages.pylint pylint-0.26.0
When someone tries to install pylint by running "nix-env -i pylint",
then it's impossible to tell which one of these three versions was
chosen.
I can think of two ways to remedy this problem with recurseIntoAttrs:
1) Bake the name of the Python interpreter into every package's name,
i.e. offer "python27-pylint", "python33-pylint", and so on.
2) Ensure that all non-default package sets mark all their packages
'lowPrio' to unsure that the choice during installation is
deterministic.
OfflineIMAP is primarily a program/tool, not a python module (although
it installs a python module too, for those who want to poke at its
internals).
Now we can install it with "nix-env -i offlineimap" instead of
"nix-env -i python2.7-offlineimap".
Wheezy has been released on June 15th and on all mirrors the SHA256 hash
of Packages.bz2 has changed to reflect the new release, so let's update.
Here is the release announcement from Debian:
http://www.debian.org/News/2013/20130615
It also seems that the versioning scheme has changed in version 7.x, so
they seem to have switched to a two digit versioning scheme. This means,
that the attribute name "debian70..." should really be something like
"debian7...", but I'm keeping the attribute as-is to not break
references.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We already have mini_httpd, but IMHO it is *too* minimal as in not very
flexible in configuration (for example, I haven't found any runtime
configuration for disabling logging), so that's why I decided to add
thttpd, which serves quite well as an ad-hoc HTTPd.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is needed in order to prevent services from starting while
populating the image with the contents of the .deb files. The procedure
used here is exactly the same as used in debootstrap.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
- The description attribute is very long, so rename it to
longDescription and add a short text in the description attribute.
- Use licenses.gpl2Plus instead of free form text "GPLv2+".
- Add platforms attribute so that hydra will build the package.
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.
