This provides a default console_cmd for the slim display-manager.
When the user enters "console" as the user name, slim will run this
command.
Having a default is rather important; the virtual terminals don't work
with some display drivers, so having a broken X session can leave you
locked out of your machine.
The go tests get tripped up due to error messages along the lines of:
ld: warning: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation, ignoring unexpected dylib file
Which is due to us passing that along via $NIX_LDFLAGS in the `clang` wrapper.
To keep `go` from getting confused, I create a small `clang` wrapper that
filters out that warning.
Also, the strip.patch is no longer necessary, and only causes problems when
testing DWARF support:
--- FAIL: TestDwarfAranges (0.59s)
runtime-lldb_test.go:218: Missing aranges section
FAIL
FAIL runtime 17.123s
Also, I disable the misc/cgo/errors test, as I suspect it is also due to similar
problems regarding `ld`:
##### ../misc/cgo/errors
misc/cgo/errors/test.bash: BUG: expected error output to contain "err1.go:11:" but saw:
# command-line-arguments
cannot parse gcc output $WORK/command-line-arguments/_obj//_cgo_.o as ELF, Mach-O, PE object
2016/05/07 02:07:58 Failed: exit status 1
Closes#14208
This fixes the previous attempt (in commit 46d1dd5) to make ctags' ctags
override emacs' ctags. The higher the value of the priority attribute,
the higher the priority (see the definition of `buildEnv`).
GHCJS uses integer-gmp, but cabal2nix generates a dependency list that
includes integer-simple instead. This tweaks the stage2 generator to
replace any instance of integer-simple with integer-gmp.
Things currently still work without this change (assuming
integer-simple is defined as null), as ghcjs includes integer-gmp in
its stage1 packages - so it's always available.
However, this change makes things a bit more explicit, rather than
leaving things to chance. If at any point the stage1 packages are also
split up into separate derivations, the integer-gmp package will need to
be passed along to the packages that depend on it. This change should
prevent some confusion going forward.
Previously, we were compiling Setup.hs with ghcjs (instead of ghc),
and that required that Cabal be available, otherwise the Setup.hs would
fail to compile.
Now that we are compiling Setup.hs with ghc, it's no longer necessary
to add Cabal as a dependency to all ghcjs packages.
CipherScan is a simple way to find out which SSL ciphersuites are
supported by a target.
It can take advantage of the extra features in Peter Mosmans' openssl
fork (which is also included in this commit).
This improves our Bundler integration (i.e. `bundlerEnv`).
Before describing the implementation differences, I'd like to point a
breaking change: buildRubyGem now expects `gemName` and `version` as
arguments, rather than a `name` attribute in the form of
"<gem-name>-<version>".
Now for the differences in implementation.
The previous implementation installed all gems at once in a single
derivation. This was made possible by using a set of monkey-patches to
prevent Bundler from downloading gems impurely, and to help Bundler
find and activate all required gems prior to installation. This had
several downsides:
* The patches were really hard to understand, and required subtle
interaction with the rest of the build environment.
* A single install failure would cause the entire derivation to fail.
The new implementation takes a different approach: we install gems into
separate derivations, and then present Bundler with a symlink forest
thereof. This has a couple benefits over the existing approach:
* Fewer patches are required, with less interplay with the rest of the
build environment.
* Changes to one gem no longer cause a rebuild of the entire dependency
graph.
* Builds take 20% less time (using gitlab as a reference).
It's unfortunate that we still have to muck with Bundler's internals,
though it's unavoidable with the way that Bundler is currently designed.
There are a number improvements that could be made in Bundler that would
simplify our packaging story:
* Bundler requires all installed gems reside within the same prefix
(GEM_HOME), unlike RubyGems which allows for multiple prefixes to
be specified through GEM_PATH. It would be ideal if Bundler allowed
for packages to be installed and sourced from multiple prefixes.
* Bundler installs git sources very differently from how RubyGems
installs gem packages, and, unlike RubyGems, it doesn't provide a
public interface (CLI or programmatic) to guide the installation of a
single gem. We are presented with the options of either
reimplementing a considerable portion Bundler, or patch and use parts
of its internals; I choose the latter. Ideally, there would be a way
to install gems from git sources in a manner similar to how we drive
`gem` to install gem packages.
* When a bundled program is executed (via `bundle exec` or a
binstub that does `require 'bundler/setup'`), the setup process reads
the Gemfile.lock, activates the dependencies, re-serializes the lock
file it read earlier, and then attempts to overwrite the Gemfile.lock
if the contents aren't bit-identical. I think the reasoning is that
by merely running an application with a newer version of Bundler, you'll
automatically keep the Gemfile.lock up-to-date with any changes in the
format. Unfortunately, that doesn't play well with any form of
packaging, because bundler will immediately cause the application to
abort when it attempts to write to the read-only Gemfile.lock in the
store. We work around this by normalizing the Gemfile.lock with the
version of Bundler that we'll use at runtime before we copy it into
the store. This feels fragile, but it's the best we can do without
changes upstream, or resorting to more delicate hacks.
With all of the challenges in using Bundler, one might wonder why we
can't just cut Bundler out of the picture and use RubyGems. After all,
Nix provides most of the isolation that Bundler is used for anyway.
The problem, however, is that almost every Rails application calls
`Bundler::require` at startup (by way of the default project templates).
Because bundler will then, by default, `require` each gem listed in the
Gemfile, Rails applications are almost always written such that none of
the source files explicitly require their dependencies. That leaves us
with two options: support and use Bundler, or maintain massive patches
for every Rails application that we package.
Closes#8612
This makes the firmware available (or would, if someone switched off
enableAllFirmware). Corresponding kernel module should get auto-loaded.
See #9948. Close#9971.
This provides support for Ubuntu Fan Networking [1].
This includes:
* The fanctl package, and a corresponding NixOS service.
* iproute patches.
* kernel patches.
closes#9188
1: https://wiki.ubuntu.com/FanNetworking
In f18efaf26e, the "patches" attribute was erroneously renamed to
"patch". If you follow the original bug report[1], you'll see that this
has long since been fixed upstream (using a different patch).
1: https://bugs.gentoo.org/show_bug.cgi?id=331447
Pipework lets you connect together containers in arbitrarily complex
scenarios. Pipework uses cgroups and namespace and works with "plain"
LXC containers (created with lxc-start), and with the awesome Docker.
In 6f08fdd26, I left in a typo after copying from my `~/.nixpkgs/config`.
I would normally test this out locally, but I'm fixing up my conf locally,
and, in the interest of not forgetting to push this change up, made the edit
through GitHub's UI.
Oops.
This updates macvim to 7.4.648. This also fixes the build, which was broken when I set the default Ruby version to 2.2.2 (one of the symbols was renamed).
Charles Strahan