In #19309 a separate output for tkinter was added.
Several dependencies of Python depend indirectly on Python. We have the
following two paths:
```
‘python-2.7.12’ - ‘tk-8.6.6’ - ‘libXft-2.3.2’ - ‘libXrender-0.9.10’ -
‘libX11-1.6.4’ - ‘libxcb-1.12’ - ‘libxslt-1.1.29’- ‘libxml2-2.9.4’ -
‘python-2.7.12’
‘python-2.7.12’ - ‘tk-8.6.6’ - ‘libXft-2.3.2’ - ‘fontconfig-2.12.1’ -
‘dejavu-fonts-2.37’ - ‘fontforge-20160404’ - ‘python-2.7.12’
```
Because only `tkinter` needs this, I added
```
pythonSmall = python.override {x11Support = false;};
```
to break the infinite recursion. We also still have the output
`tkinter`.
However, we might as well build without x11Support by default. Then we build with x11Support as well so we get the tkinter module and put that in a separate package.
PHP FPM will now notify systemd when it's done initializing and ready to
serve requests.
Additionally ```systemctl status phpfpm``` will now show statistics such
as:
```
Status: "Processes active: 0, idle: 8, Requests: 0, slow: 0, Traffic: 0req/sec"
```
* Manage patches in git
* Fixes the hook invocation to be more safe. Thanks @Mic92
* Install gems as user by default
* Install gem binaries with the /usr/bin/env shebang
* Fixes a bug where the passthru.libPath and passthru.gemPath would
point to the wrong directory
* Overhaul ruby version heuristics
Update the `chibi-scheme` (attribute `chibi`) package from version 0.7
to version 0.7.3.
The homepage listed for this package before this change,
<https://code.google.com/p/chibi-scheme/>, now redirects to
<https://github.com/ashinn/chibi-scheme>; this patch changes this
package to use this GitHub version of the software.
I have tested this change per nixpkgs manual section 10.1 ("Making
patches").
python.buildenv is used to build an env that provides binaries that can
import all modules that were passed in to the env.
Before this change it filtered the propagatedBuildInputs to remove all
non-Python packages, thereby possibly reducing the amount of packages
that were referenced. However, Python packages often don't have non-
Python packages as propagatedBuildInputs. And occasionally, we do want
to be able to add other packages to the env.
It's a long build and generally painful to split into smaller commits,
so I apologize for lumping many changes into one commit but this is far
easier.
There are still several outdated parts of the darwin stdenv but these
changes should bring us closer to the goal.
Fixes#18461
By chance I noticed that php picked up my /etc/odbc.ini file (clearly
wrong!). This fixes it by adding a namespace for php.
WARNING: This is a breaking change for anyone that happen to rely on php
picking up .ini files from /etc.
Compiling python with "-Wl,-stack_size,1000000" causes problems when
compiling for example pygobject3. pygobject3 uses "python3.x-config
--ldflags" during installation and then fails when
"-Wl,-stack_size,1000000" is present. Maybe we should investigate
removing this during the build of pyobject3, but this stack_size flag is
also not used on the popular darwin homebrew-core channel for python3.5,
so it seems safe to remove it.
This one was already merged into release-16.09, so let's not have the
stable branch is ahead of master and confuse things. In addition to
that, currently we have an odd situation that master has less things
actually finished building than in staging.
Conflicts:
pkgs/data/documentation/man-pages/default.nix
The previous commit revealed that Python wasn't actually using
Berkeley DB; it only had it in its closure due to the build-time flag
dump in Makefile and _sysconfigdata.py. When Python detects both GNU
gdbm and Berkeley DB at build time, it will use the former.
This cuts about 3 MiB from the installed size. On Linux, the configure
script is supposed to detect that installing tzdata is unnecessary,
but it looks in locations like /usr/share/zoneinfo.
This reduces Python's closure size from 200 MiB to 129 MiB. Even
better would be to get move tkinter to a separate output or package
(since that would get rid of all X11 stuff), but that's a bit harder.
This reduces tcl's total size from 25.0 MiB to 8.6 MiB. Admittedly
this is also because putting the manpages in the right place causes
all man3 pages to be deleted by the multiple outputs setup hook. Not
sure if that's desirable behaviour...
In the tarball job:
````
checking find-tarballs.nix
error: while evaluating anonymous function at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:6:1, called from undefined position:
while evaluating ‘operator’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:27:16, called from undefined position:
while evaluating ‘immediateDependenciesOf’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:39:29, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:27:44:
while evaluating anonymous function at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/attrsets.nix:224:10, called from undefined position:
while evaluating anonymous function at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:40:37, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/attrsets.nix:224:16:
while evaluating ‘derivationsIn’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:42:19, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:40:40:
while evaluating ‘optional’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/lists.nix:175:20, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:44:33:
while evaluating ‘canEval’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:48:13, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/maintainers/scripts/find-tarballs.nix:44:43:
while evaluating the attribute ‘pkgs’ of the derivation ‘ruby-dev-2.3.1-p0’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/pkgs/build-support/trivial-builders.nix:10:14:
while evaluating ‘override’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/customisation.nix:60:22, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/pkgs/development/interpreters/ruby/dev.nix:10:13:
while evaluating ‘makeOverridable’ at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/customisation.nix:54:24, called from /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/customisation.nix:60:31:
anonymous function at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/pkgs/development/ruby-modules/bundix/default.nix:1:1 called with unexpected argument ‘ruby’, at /tmp/nix-build-nixpkgs-tarball-16.09pre1234.abcdef.drv-0/nixpkgs/lib/customisation.nix:56:12
````
This was one of the ways to build packages, we are trying
hard to minimize different ways so it's easier for newcomers
to learn only one way.
This also:
- removes texLive (old), fixes#14807
- removed upstream-updater, if that code is still used it should be in
separate repo
- changes a few packages like gitit/mit-scheme to use new texlive
io uses SIMD instructions even on i686, causing the build to fail:
> /nix/store/[...]-gcc-5.4.0/lib/gcc/i686-pc-linux-gnu/5.4.0/include/xmmintrin.h:181:1:
error: inlining failed in call to always_inline '_mm_add_ps': target
specific option mismatch
_mm_add_ps (__m128 __A, __m128 __B)
(from https://hydra.nixos.org/build/37879114/log/raw)
The simplest solution is to disable the build on this platform.
This follows on from PR #16965 for qrupdate and PR #16968 for fltk.
WIth these, the added explicit dependencies on arpack (to support
the octave `eigs` function) and `libwebp`, and not pulling X11 things,
octave works properly on darwin.
Minor OTP releases (and their manpages) are not available for dowload at
http://erlang.org/download
But e.g.:
- 18.3.1 contains an important fix for mnesia
- 18.3.1-18.3.4 has a lot of SSL/TLS fixes
So we have to fetch from GitHub and build everything ourselves.
Also replace explicit path patching with upstream patches:
- https://github.com/erlang/otp/pull/1023
- https://github.com/erlang/otp/pull/1103 - with this patch it's now
possible to build erlang in sandboxed mode
Some tests fail and cause kernel spam of this sort:
[ 6607.906159] Alignment trap: not handling instruction f4430a1f at [<0021e500>]
[ 6607.913308] Unhandled fault: alignment exception (0x811) at 0x003a15ec
[ 6607.919864] pgd = e8b88000
[ 6607.922601] [003a15ec] *pgd=fb185835
/cc #16477. /cc @domenKozar (don't know who better),
as I still experience test failures of different kind:
=================================== FAILURES ===================================
_______________________________________ _______________________________________
Traceback (most recent call last):
File "/tmp/nix-build-pypy-5.1.1.drv-0/pypy-pypy-b0a649e90b66/pypy/tool/pytest/run-script/regrverbose.py", line 14, in <module>
indirect_test()
File "/tmp/nix-build-pypy-5.1.1.drv-0/pypy-pypy-b0a649e90b66/lib-python/2.7/test/test_ctypes.py", line 10, in test_main
skipped, testcases = ctypes.test.get_tests(ctypes.test, "test_*.py", verbosity=0)
File "/tmp/nix-build-pypy-5.1.1.drv-0/pypy-pypy-b0a649e90b66/lib-python/2.7/ctypes/test/__init__.py", line 72, in get_tests
mod = __import__(modname, globals(), locals(), ['*'])
File "/tmp/nix-build-pypy-5.1.1.drv-0/pypy-pypy-b0a649e90b66/lib-python/2.7/ctypes/test/test_python_api.py", line 9, in <module>
from _ctypes import PyObj_FromPtr
ImportError: cannot import name 'PyObj_FromPtr'
=========================== short test summary info ============================
FAIL lib-python/2.7/test/test_ctypes.py::unmodified
9 tests deselected by '-knot ( test_ssl or test_urllib2net or test_urllibnet or test_urllib2_localnet or test_socket or test_shutil or test_zipfile64 or test_epoll )'
======= 1 failed, 341 passed, 51 skipped, 9 deselected in 550.97 seconds =======
In line with the Nixpkgs manual.
A mechanical change, done with this command:
find pkgs -name "*.nix" | \
while read f; do \
sed -e 's/description\s*=\s*"\([a-z]\)/description = "\u\1/' -i "$f"; \
done
I manually skipped some:
* Descriptions starting with an abbreviation, a user name or package name
* Frequently generated expressions (haskell-packages.nix)
This allows you to turn on debug infor for all the beam packages in the
system with a single change at the top level. This is required for
debugging and dialyzer work. It also allows you to switch it on on a
package by package basis.
Rebol is a cross-platform data exchange language and a multi-paradigm dynamic
programming language for network communications and distributed computing.
Icon is a very high level general-purpose programming language with
extensive features for processing strings (text) and data structures.
Closes#16036.
This modifies the elixir derivation to allow 'debugInfo' to be set. This
will build the elixir library with debug information and allow dializer
to be used it derivative projects
Fix build by applying a patch from Arch Linux.
See https://hydra.nixos.org/build/33247205/log/raw
Meta fixups
- The license is actually 3-clause BSD license.
- Use HTTPS homepage
- Adopt the package
- Convert src.sha256 to base32
Setting the GEM_PATH after ruby is started is not reliable enough. In
some cases rubygems would have already loaded and ignore these settings.
Fixes#14048
After ruby initializes, rubygems no longer reads the GEM_PATH. Before,
we have the following scenario:
Gem.path # => ["a"]
ENV['GEM_PATH'] = ["b"]
Gem.path # => ["a"] # Still returns the same
Gem.use_paths is the documented way to create isolated environments as
documented in [1].
[1] http://www.rubydoc.info/github/rubygems/rubygems/Gem.use_paths
The idea is to bundle ruby, bundler and bundix together. I was
having issues where bundler was installed with ruby 2.3.0 and I wanted to use
ruby 2.0.0.
With this change all the developer has to do is install `ruby_2_0_0.dev`
either in his environment or in a nix-shell.
Having a separate rubygems package can lead to split-brain scenarios.
Since rubygems is designed to replace himself on a ruby installation,
let's do that.
The $lib output refers to the terminfo database in $out, which is about
10x larger than the ncurses shared library. Splitting these outputs
saves a small amount of space for any derivations that use the terminfo
database but not the ncurses library, but we do not have evidence that
any such exist.
The following parameters are now available:
* hardeningDisable
To disable specific hardening flags
* hardeningEnable
To enable specific hardening flags
Only the cc-wrapper supports this right now, but these may be reused by
other wrappers, builders or setup hooks.
cc-wrapper supports the following flags:
* fortify
* stackprotector
* pie (disabled by default)
* pic
* strictoverflow
* format
* relro
* bindnow
The location of this 'regen' script (whatever is does) depends on the
platform. AFAICT it always exists due to this:
$(srcdir)/Lib/$(PLATDIR):
mkdir $(srcdir)/Lib/$(PLATDIR)
cp $(srcdir)/Lib/plat-generic/regen $(srcdir)/Lib/$(PLATDIR)/regen
This will probably be mandatory soon, and is a step in the right
direction. Removes the deprecated meta.version, and move some meta
sections to the end of the file where I should have put them in
the first place.
This was preventing any ruby gem with a c extension to build.
mkmf would fail with a misleading error:
/nix/store/dmkcai8fnv21qxiasx628nim3mq4r4wg-ruby-2.2.3-p0/lib/ruby/2.2.0/mkmf.rb:456:in `try_do': The compiler failed to generate an executable file. (RuntimeError)
You have to install development tools first.
generate_stub doesn't exist and the output is not used in the code so I just
removed the line.
This was preventing the binstubs from generating properly.
- 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 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.
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
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.
According to @zimbatm, he got the SHA256 hashes via nix-prefetch-git.
However, fetchFromGitHub doesn't use Git to fetch the sources but uses
fetchzip under the hood, so we get plain source directories in the Nix
store, which in turn are hashed.
Tested by:
nix-build --no-out-link -E 'map (x:
(builtins.getAttr x (import ./. {})).src
) [ "ruby_1_9_3" "ruby_2_0_0" "ruby_2_1_0" "ruby_2_1_1" "ruby_2_1_2"
"ruby_2_1_3" "ruby_2_1_6" "ruby_2_1_7" "ruby_2_2_0" "ruby_2_2_2"
"ruby_2_2_3"
]'
Signed-off-by: aszlig <aszlig@redmoonstudios.org>