This update was generated by hackage2nix v20151217-9-geddefc2 using the following inputs:
- Nixpkgs: a28e076b47
- Hackage: c63083af59
- LTS Haskell: cf055c2754
- Stackage Nightly: 8f10b44c12
See http://nixos.org/nixpkgs/manual/#sec-package-naming
I've added an alias for multipath_tools to make sure that we don't break
existing configurations referencing the old name.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
By default, GPGME tries to search in $PATH for the gpg and gpgconf
binaries. This has the downside, that the library won't work by its own
and needs to have GnuPG in systemPackages or the user environment.
I've stumbled on this while working on one of the dependencies of
nixos-assimilate and nixpart (volume_key), where the testing environment
didn't come with GnuPG in $PATH and thus the tests have failed.
After testing this with a few programs using GPGME, I haven't found any
weird behavior in conjunction with the GnuPG agent.
However one possible implication could be that if the GnuPG used in
$PATH (and the config files in the user's home directory) should be
vastly incompatible, it could lead to failures.
In practice however, the GnuPG1/2 versions pretty much seem to stay
compatible within their major releases so it shouldn't pose a problem.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This update was generated by hackage2nix v20151217-9-geddefc2 using the following inputs:
- Nixpkgs: 4f74881496
- Hackage: b70bc194ef
- LTS Haskell: cf055c2754
- Stackage Nightly: 3184791ff4
This patch is directly taken from easytag. id3lib is not maintained any longer
and the last release is 13 years old.
This patch fixes some unicode issues.
Recent illumos includes a linux-incompatible `inotify.h` header, which configure detects: compilation fails.
Also, a newer `dtrace` on SmartOS fails creating the probes ELF linkable object (with `dtrace -G`). Disable for now.
Remove old configure option `--disable-modular-tests`.
Recent illumos includes a linux-incompatible `inotify.h` header, which configure detects: compilation fails.
Also, a newer `dtrace` on SmartOS fails creating the probes ELF linkable object (with `dtrace -G`). Disable for now.
Remove old configure option `--disable-modular-tests`.
This adds changes to the rebar3 expression that patch rebar3 to force it
to be hermetic. Now, by default, rebar3 literally can't download
anything. A 'rebar3-open' expression was added for those folks whe want
the normal rebar3.
Also split out gmock's source so that it can be copied into protobuf's
source. Hopefull this hack can be removed again once gmock is replaced
by gtest.
This does not include python bindings.
Nix unzips the different components of the Android SDK one by one.
It followed the directory structure of complete packages released for
mainstream OS but the names of the directories in build-tools doesn't
match those.
As a result, some programs assuming the usual directory structure and
naming conventions broke (in my case it is a gradle plugin).
This is a fix. It may introduce a regression if some programs rely on
the current behavior.
To successfully build rebar packages, it needs to be provided with
rebar3 plugins used to build it. This change passes them to env
variable. From there rebar3-nix-bootstrap takes them and symlinks into
_build/default/plugins.
Eelco showed alternative way of building static libraries via
stdenv adapter in a conversation several days ago and expressed
concern about adding new enableStatic flags.
This update was generated by hackage2nix v20151217-9-geddefc2 using the following inputs:
- Nixpkgs: 3a04b0b2d4
- Hackage: e505b113f6
- LTS Haskell: e72964a553
- Stackage Nightly: 14a3a2d00e
Regression introduced by df2b9b48cb.
This breaks the build for ltrace and other programs using libelf,
because the header file relies on features from glibc >= 2.22.
Here is an excerpt from the log output of the configure script from
ltrace:
In file included from ...elfutils-0.165/include/gelf.h:32:0,
from conftest.c:57:
...elfutils-0.165/include/libelf.h:280:8: error: unknown type name 'Elf32_Chdr'
extern Elf32_Chdr *elf32_getchdr (Elf_Scn *__scn);
^
...elfutils-0.165/include/libelf.h:281:8: error: unknown type name 'Elf64_Chdr'
extern Elf64_Chdr *elf64_getchdr (Elf_Scn *__scn);
^
In file included from conftest.c:57:0:
...elfutils-0.165/include/gelf.h:89:9: error: unknown type name 'Elf64_Chdr'
typedef Elf64_Chdr GElf_Chdr;
^
The issue has been reported in the Debian bug tracker at
https://bugs.debian.org/810885 and I'm using the patch from Mark
Wielaard that has been posted there which adds compatibility for older
glibc versions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This update was generated by hackage2nix v20151217-7-g3384c26 using the following inputs:
- Nixpkgs: 65d4f18f9e
- Hackage: 03c5ce2cbc
- LTS Haskell: e72964a553
- Stackage Nightly: 23478137ac
Also, install programs with the "eu-" prefix to prevent collisions
with binutils (as recommended by upstream), enable xz support, and
enable deterministic archives.
Modifies libvirt package to search for configs in /var/lib and changes
libvirtd service to copy the default configs to the new location.
This enables the user to change e.g. the networking configuration with
virsh or virt-manager and keep those settings.
- I chose to keep `browser-unwrapped` attributes so that it's much
easier to override parameters for the browser (through `packageOverrides`).
- Aliases `browserWrapper` are retained for now, as usual.
This commit adds 187 packages from Hex.pm and documents 100 more that
could not be imported for various reasons. The packages where generated
by hex2nix.
Building Hex packages is a superset of building with rebar3. There is no
need to force folks that use rebar3 but not hex to build with hex. This
commit seperates the rebar3 specific bits and the hex specific bits into
seperate functions that can be used independently.
The buildErlang function is broken and and leads Engineers down a wrong
path. For vanilla erlang that doesn't user rebar3, its better to simply
use `stdenv.mkDerivation` along with a set setupHook then the existing
functionality.
This commit moves all the hex based packages to a single namespace. It
also moves all the packages to a single file. This is in preparation
for the move to a system to generate the hex packages from the hex
package store.
This addresses CVE-2015-8618 (a vulnerability in math/big)
This issue can affect RSA computations in crypto/rsa, which is used by
crypto/tls. TLS servers on 32-bit systems could plausibly leak their RSA
private key due to this issue. Other protocol implementations that
create many RSA signatures could also be impacted in the same way.
https://groups.google.com/forum/#!topic/golang-dev/MEATuOi_ei4
The error was due to the fact that with-introduced bindings have lower
priority and we do have `darwin` in scope already.
Fixes#12350. Closes#12351. (A slightly different fix.
I chose this to lower the risk of people re-introducing the mistake.)
- fix in silencing some moveToOutput messages
- allow removing (developer) documentation even without defining outputs
(note: some paths are auto-removed by default, e.g. gtk-doc and man3)
This update was generated by hackage2nix v20151217-7-g3384c26 using the following inputs:
- Nixpkgs: 7cbc1f27d4
- Hackage: dfdbb526ed
- LTS Haskell: e72964a553
- Stackage Nightly: a9df6f5b32
Citing from http://hydra.cryp.to/build/1533084/log/raw:
Configuring ghcjs-0.2.0...
Setup: At least the following dependencies are missing:
aeson >=0.7 && <0.10,
haskell-src-exts ==1.16.*,
optparse-applicative ==0.11.*,
syb >=0.4 && <0.6
This issue has been present for a while now, and it's only gotten worse.
This update was generated by hackage2nix v20151217-6-g3c230ba using the following inputs:
- Nixpkgs: fbf35cf17d
- Hackage: 3e0920b425
- LTS Haskell: e72964a553
- Stackage Nightly: c0de8ca462
ktexteditor-5.18.0 needs its patches updated. An optional dependency on
`libgit2` was also added. `makeQtWrapper` was added to
`nativeBuildInputs` to set `XDG_DATA_DIRS` correctly.
This update was generated by hackage2nix v20151217-6-g3c230ba using the following inputs:
- Nixpkgs: b05b64ed59
- Hackage: ce76547c84
- LTS Haskell: 87e2d54643
- Stackage Nightly: 392791fc31
This is a major closure size reduction on Darwin, and probably a less
significant one on Linux. On darwin, retaining the compiler means adding
clang and its dependency llvm to the perl closure, which gives us ~400MB
of extra stuff. Considering that Nix itself depends on this version of
perl, that makes cutting a new Nix release rather unpleasaont Darwin.
After this patch, I was able to get the `nixUnstable` closure down to
21MB after feeding it into a .tar.xz (123MB before compression). There's
still room for improvement but this should carry us over until we split
outputs.
Add Twisted as build input so that we can continue to have Python
support. (./configure disables Python support unless it finds the
'trial' program, from Twisted.) I don't know whether upstream intended
that, because it seems perfectly fine to run thrift + Python without
Twisted. (Only the TTwisted transport uses Twisted...)
Ah, Thrift use Twisted in its unit tests. Even when we pass
--enable-tests=no to ./configure :-D
This update was generated by hackage2nix v20151217-5-ged07a8e using the following inputs:
- Nixpkgs: f24e81fbd3
- Hackage: 01c9e56f5d
- LTS Haskell: 87e2d54643
- Stackage Nightly: c30758374f
Adding stdenv.cc into the PATH, also setting CC, so that on Darwin
clang will be used by default. Still allowing to use an existing value
of CC if it is set already.
Replacing __inline_isnanl with __inline_isnan on darwin since the former
one was not defined.
This update was generated by hackage2nix v20151217-5-ged07a8e using the following inputs:
- Nixpkgs: 665c16fbe1
- Hackage: d9755ca900
- LTS Haskell: d3e5ae70f9
- Stackage Nightly: 56e1f693d5
Upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1293060
This patch is based on the one attached to that bug report, but
instead of patching the .x files (parsing of which apparently
fails as well) it modifies the pre-generated .c files directly.
This ought to fix#12139.
Built and run locally.
From the Changelog:
```
Version 0.7.81, 2015-12-31
+ Acquisition Metadata: support of all SMPTE RDD18 elements
+ Matroska: cover presence and content of the cover, thanks to Max Pozdeev
+ #F446, Matroska: Handling of cropping values, thanks to Max Pozdeev
+ Improvement of Python binding: Mac Os X support, Python2 and Python3
can use same MediaInfoDLL.py
+ #F484, AVI: OpenDML Interlaced / Progressive scan type detection
+ MP4: support of AtomicParsley imdb tag
x #B959, MPEG-TS: MPEG-1 Video appeared as MPEG-2 Video
x #B914, Matroska: Undefined number of chapters in some M4V with Timed
Text, thanks to Max Pozdeev
x #B962, Matroska: negative timecodes were not correctly handled
x #B964, FLV: was hanging trying to open some FLV files
x JPEG in AVI or MOV: better handling of buggy APP0/AVI1, avoiding some
false positives about interlacement
x DVCPRO HD: some containers consider DVCPRO HD as with width 1920
despite the fact it is 1280 or 1440, using 1280 or 1440 in all cases
```
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
