This update was generated by hackage2nix v20151217-3-gd4ae18a using the following inputs:
- Nixpkgs: 579e6bb797
- Hackage: e1530f9f9a
- LTS Haskell: d3e5ae70f9
- Stackage Nightly: db90cf927d
Also sync a tiny difference in docs outputs from gcc-5.
I originally assumed that people will push gcc-5 support to master
long before closure-size gets there, but I overestimated the situation.
We haven't really settled even the issue of ABI switch,
so let's use the same gcc version on closure-size and master.
Some multiple-output changes were previously only in 5.22,
but since master is still using 5.20, let's stick with that version
on closure-size as well.
741bf840da (commitcomment-14784970)
http://hydra.nixos.org/eval/1234895
The mass errors on Hydra seem transient; I verified ghc on i686-linux.
Only darwin jobs are queued ATM. There's a libpng security update
included in this merge, so I don't want to wait too long.
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 update was generated by hackage2nix v20151217-3-gd4ae18a using the following inputs:
- Nixpkgs: 236677809b
- Hackage: 62b6b580fb
- LTS Haskell: d3e5ae70f9
- Stackage Nightly: ef03f60b53
Previously, the native libvirt package was making an assertion that
the dependent Python package had a compatible version. This commit
switches that so that the Python package makes the assertion, since
it makes more sense to me to have a child package making an
assertion about its parent than vice versa.
Previously the gems defaulted to "ruby" as the name and
"${ruby-version}-${gem-name}-${gem-version}" as the version,
which was just insane.
https://github.com/NixOS/nixpkgs/issues/9771#issuecomment-141041414
Noone is reacting so it's high time to take at least some action.
/cc @cstrahan.
This update was generated by hackage2nix v20151217-2-g519e0a9 using the following inputs:
- Nixpkgs: 2ed14d2303
- Hackage: 53c15ee9e3
- LTS Haskell: b668f53a86
- Stackage Nightly: ec9500b675
It is better to specify data-dir in the environmental variable since
then both the language description files and the dictionaries will be
found. Since dict-dir defaults to data-dir only the latter needs to be
set. See for example https://github.com/NixOS/nixpkgs/issues/1000
vcunat did some cosmetic changes, such as joining lines
because we seem to rarely use one-identifier-per-line style,
or fixing hyena description to conform to our rules.
Compatible with llvm+clang 3.7. Changes:
- Added Boost and Qt mappings.
- Better support for using declarations.
- Allow size_t from multiple headers.
- Fixed handling includes with common path prefix.
More: http://include-what-you-use.org/
This adds erlangPackages.${name}.env, which is usable to launch a shell
with the package and it's dependencies like this:
nix-shell -A erlangPackages.lager.env
This required:
1) refactoring buildHex to become a fixed-point function,
2) moves output of a package into $out/${name},
3) introduces erlEnv (buildEnv, which links in package and it's deps
into one directory - a super-simple plagiarization of
haskellPackages.compiler.ghcWithPackages) and
4) shell function producing a un-buildable derivation to be used by
nix-shell
This update was generated by hackage2nix v20151217 using the following inputs:
- Nixpkgs: 1e4c0752db
- Hackage: 42db5021ee
- LTS Haskell: 253d4da342
- Stackage Nightly: 57c8505aea
- The patch fixes building against gst-1.6.
- Having to change three files with almost same contents would drive me mad,
so I unified them into a single expression. /cc @ttuegel
- libxslt seemed unneeded, and it uses libxml2 anyway.
This update was generated by hackage2nix v20150922-47-ga631ea6 using the following inputs:
- Nixpkgs: e616e3fbaa
- Hackage: 1be87a125d
- LTS Haskell: 253d4da342
- Stackage Nightly: 1ee60f7320
The new GHC version contains a patch [1] that passes linker and compiler flags
to GCC via response files rather than directly on the command-line. This is
supposed to be beneficial on Windows and other platforms that have trouble
dealing with long argument lists. On NixOS, however, this feature breaks the
flag handling provided by gcc-wrapper [2] and therefore causes the entire GHC
build to fail.
This issue has been reported upstream at [3]. It's not clear yet how to remedy
this problem, but until we've figured that out we just don't pass compiler flags
in response files on NixOS to fix https://github.com/NixOS/nixpkgs/issues/10752.
[1] 296bc70b5f
[2] https://github.com/NixOS/nixpkgs/issues/11762
[3] https://ghc.haskell.org/trac/ghc/ticket/11147
The three KDE package sets now have circular dependencies between them,
so they can only be built if they are merged into a single package set
during evaluation.
This allows to avoid fetching registry file from S3 at build time,
making the build hermetic and much faster. Automatic tools will be used
to update said external repo content when Hex packages are
imported/update.
There are some packages on Hex which have custom hex-specific names, but
inside there's a base project name.
Remove most packages andadd ibrowse, meck, jiffy
This patch fixes compilation errors when using ccache wrapper:
```
cc1: error: /nix/store/19vvbsjs6l6j0r22albzhysxfvr94imf-ccache-links/lib/gcc/*/*/include-fixed: No such file or directory
```
From the changelog:
```
Version 0.7.80, 2015-11-30
+ Matroska: support of MKVMerge statistics tags (duration frame count,
stream size, bit rate) per track, thanks to ndjamena
+ FLAC: Channel positions, thanks to ndjamena
+ FLAC: difference between detected bit depth and stored bit depth
+ MPEG-TS: if DTVCC transport stream is present and no DTVCC service
descriptor, scan also in the middle of the file in order to detect
more caption services
+ Subtitle frame rate computing if frame count and duration are
available (hidden by default)
+ Subtitles in Matroska: count of elements
+ Matroska, MXF and MP4/MOV: detection of truncated files
+ DTS: difference between ES Matrix and ES Discrete
+ DTS: display ES Matrix or ES Discrete even if HRA or MA is present
+ DTS: difference between DTS-HRA with 96k option and pure DTS-96/24
+ DTS: detection of DTS:X
+ Samples per frame info
+ AC-3: detection of Atmos inside TrueHD
+ Video frame rate: showing precision of 1/1.001 frame rates (e.g.
"23.976 (24000/1001) fps" and "23.976 (23976/1000) fps")
+ MPEG-4/MOV: showing the complete list of compatible brands in the
CodecID field
+ MPEG-4/MOV: Alternate groups
+ MPEG-4/MOV: "Disabled" tag
+ MPEG-4/MOV: "Forced" tag
+ MPEG-4/MOV: showing links between tracks (chapters for, subtitles for,
fallback for)
+ MXF: handling of more acquisition metadata items
+ MXF: Package name
+ AVC: Store method of interlaced content (Interleaved Fields or
Separated Fields)
+ EBUCore: acquisition metadata (Proof of concept, for feedback only)
x Matroska: frame rate detection algorithm revisited, less wrong numbers
are expected
x SDP/Teletext: some pages were sometimes (when present in 2 different
SDP lines) displayed several times
x MPEG-4/MOV: some hint tracks were not displayed
+ Hongkongese language added
+ Option "Full parsing"
```
