This partially reverts commit 3a4fd0bfc6fb34a496708ee95891acb1648eedde.
Addresses another concern by @edolstra that users might not want to
update *all* channels. We're now reverting to the old behaviour but
after updating the "nixos" channel, we just check whether the channel
ships with a file called ".update-on-nixos-rebuild" and if it exists, we
update that channel as well.
Other channels than these are not touched anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
My original reason to put it at the beginning of NIX_PATH was to allow
shipping a particular version <nixpkgs> with a channel. But in order to
do that, we can still let the channel expression ship with a custom
version of nixpkgs by something like <channel/nixpkgs> and the builder
of the channel could also rewrite self-references.
So the inconvenience is now shifted towards the maintainer of the
channel rather than the user (which isn't nice, but better err on the
side of the developer rather than on the user), because as @edolstra
pointed out: Having the channels of root at the beginning of NIX_PATH
could have unintended side-effects if there a channel called nixpkgs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Should make it even easier to use custom channels, because whenever the
user does a "nixos-rebuild --upgrade", it will also upgrade possibly
used ("used" as in referenced in configuration.nix) channels besides
"nixos". And if you also ship a channel tied to a particular version of
nixpkgs or even remove the "nixos" channels, you won't run into
unexpected situations where the system is not updating your custom
channels.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is very useful if you want to distribute channels (and thus
expressions as well) in a similar fashion to Debians APT sources (or
PPAs or whatnot).
So, for example if you have a channel with some additional functions
or packages, you simply add that channel with:
sudo nix-channel --add https://example.com/my-nifty-channel foo
And you can access that channel using <foo>, for example in your
configuration.nix:
{
imports = [ <foo/modules/shiny-little-module> ];
environment.systemPackages = with import <foo/pkgs> {}; [ bar blah ];
services.udev.extraRules = import <foo/lib/udev/mkrule.nix> {
kernel = "eth*";
attr.address = "00:1D:60:B9:6D:4F";
name = "my_fast_network_card";
};
}
Within nixpkgs, we shouldn't have <nixos> used anywhere anymore, so we
shouldn't get into conflicts.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Needed to be able to run 'make serve' in a pelican directory, else this
happens:
$ make serve
cd /home/bfo/pelican-test/output && python -m pelican.server
/run/current-system/sw/bin/python: No module named markupsafe
make: *** [serve] Error 1
That way sending mail with mutt works on NixOS too, without having to
manually change mutt's config on your system. sendmail will be found in
$PATH at runtime, and thus the setuid wrapper will be used, if
available.
Regression introduced by 56a6f22d7fb4690871669eba38a30e4f5a8cb483.
I'm temporarily pulling in test_mccabe.py, as suggested by someone at
flintwork/mccabe#31, which for now should fix the build (and the tests
of course as well).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Upstream changes since 0.8.2:
* Performance improvements for collection browsing.
* Improved memory footprint.
* Show cloud collections above your friends in the sidebar.
* Keep looking for alternative sources even when we found a perfect match.
* Fixed crash in network code.
* Fixed repeat one/all icons.
* Be more lenient about accepting JSPF and M3U playlists.
* Improved support for compilation albums.
* (Windows) Fixed support for Windows XP.
* (OS X) Fixed settings dialog appearance on Yosemite.
* (OS X) Fixed SSL errors on Yosemite.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
- Adds new LLVM-based instrumentation support via afl-clang-fast.
- Experimental support for cgroup management via afl-cgroup, to
mitigate OOM issues when using afl with address sanitizer.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
