added tldr to all-packages.nix
cleaned up style
added metadata
semicolons
didn't test on mac. removed platform
wrong types
fixed duplication of version
Adding this package to environment.systemPackages stops the
"Add new printer" button in gnome-control-center from being grayed out
and stops it from printing:
(gnome-control-center:16664): printers-cc-panel-WARNING **: Your system does not have the cups-pk-helper's policy "org.opensuse.cupspkhelper.mechanism.all-edit" installed. Please check your installation
But completing the printer setup requires some additional packaging
work. This is what happens when trying to _add_ a printer:
(gnome-control-center:18733): printers-cc-panel-WARNING **: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.fedoraproject.Config.Printing was not provided by any .service files
(gnome-control-center:18733): printers-cc-panel-WARNING **: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.PackageKit was not provided by any .service files
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.
Also fix the hash in goPackages.inflect, the only user of the fetcher ATM.
Closes#12002 (different `inflect` fix), fixes#12012.
Using fetchzip-derived functions is likely more efficient than fetchhg,
and it's lighter on dependencies (hash is the same as with fetchhg in this case).
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
Two reasons for this change:
- most of 5.0 packages don't build yet
- node packages are memory intensive and block Hydra evaluation
(Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS)
PS: Removing node packages from evaluation goes from 7.5G down to
4.6G for whole nixos release job.
See #3594 and #11865
Relevant changes:
- Python version switched to Python 3
- ssdeep library got replaced with tlsh
- the 'magic' Python package got replaced with a different one
- Minor build system improvements == less work for us
"nix-env -iA gnupg" installs the 2.0.x version of GNU Privacy Guard. This patch
ensures that "nix-env -i gnupg" chooses the same version, instead of installing
GnuPG 2.1.x, which is considered a "development version".
Closes https://github.com/NixOS/nixpkgs/issues/11899.
* Patched fish to load /etc/fish/config.fish if it exists (by default,
it only loads config relative to itself)
* Added fish-foreign-env package to parse the system environment
closes#5331
The git version was duplicated from the stable one and the two had
begun to diverge significantly. For example, commit
88d731925d fixed a supposedly real
bug — but only in the stable package.
Factor out the shared code to avoid trouble — or worse, subtle
differences or bugs — in future.
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.
Fixes#10819. emacsWithPackages will know its own package set. This
requires it to be in a package set, rather than at the top level, so it
lives in emacsPackagesNg.
- 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.
In order to increase portability and flexibility, now the build phase
explicitly sets "compiler=c++" as a make parameter.
Further, there is a link "higan" for backwards compatibility; higan was
split in icarus (the game ROMS database manager) and tomoko (the
emulator itself).
The 0.8.4 version of Tomahawk doesn't yet recognize the new taglib
version that has been introduced in b762a20 and fails during
configurePhase.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
`callPackage` should only be used for actual packages. Functions, like
`emacsPackagesNgGen`, should be `import`ed. This also has the effect of
exposing the `override` function provided by `makeScope` so that
`emacsPackagesNg.override` overrides the package set instead of
overriding the arguments to `emacsPackagesNgGen`.
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.
