Commit graph

220 commits

Author SHA1 Message Date
Milan Pässler
bd81420cf5 gem-config: add idn-ruby, rpam2, cld3 2019-05-02 02:41:32 +02:00
Michael Fellinger
98e0f54b85 sup: use bundlerApp, cleanup (#60515) 2019-04-30 20:13:17 +02:00
angristan
11282ea623 solargraph: 0.29.1 -> 0.32.1 2019-04-29 23:56:52 +02:00
Alyssa Ross
27a22f0910
bundix: 2.4.1 -> 2.4.2 2019-04-17 17:28:11 +01:00
Alyssa Ross
69ec9bdf0d
Merge pull request #59252 from lilyball/cocoapods-beta
cocoapods-beta: init at 1.7.0.beta.3
2019-04-17 08:50:15 +00:00
Lily Ballard
8e9796cae2 Make gemdir optional for bundlerApp
Like `bundlerEnv`, the `gemdir` parameter to `bundlerApp` can be omitted
if all 3 of `gemfile`, `lockfile`, and `gemset` are provided.
2019-04-10 13:26:31 -07:00
Bas van Dijk
ad41c1f1c0 fluentd: 1.2.3 -> 1.4.2 2019-04-10 12:46:06 +02:00
Ryan Mulligan
488ecd6636
Merge pull request #58940 from erictapen/ruby-gem-src-fix
ruby-modules/gem: fix path to git checkout
2019-04-07 14:53:37 -07:00
Michael Fellinger
af44cf8bc5 gem-config: add opus-ruby (#59084) 2019-04-07 15:09:15 +02:00
Justin Humm
eb9293e4d8
ruby-modules/gem: fix path to git checkout
In case of the gem type 'git', nix-bundle-install.rb was called with
wrong path to the git checkout.

${src} does contain the sources, but not the newly generated .git dir,
which is created in the buildPhase of pkgs/development/ruby-modules/gem/default.nix

In some rare cases, this .git dir is needed at installPhase.
2019-04-03 16:59:53 +02:00
Judson Lester
704d02053b (ruby-modules/gem): (refactor) (#53525)
* Changing leaveDotGit to git chacha on build

* Removing debugging cruft

* Simpler git handling

* Can't clobber index after `add`

* Update pkgs/development/ruby-modules/gem/default.nix

Useful comments

Co-Authored-By: nyarly <nyarly@users.noreply.github.com>

* Update pkgs/development/ruby-modules/gem/default.nix

Comments are useful

Co-Authored-By: nyarly <nyarly@users.noreply.github.com>
2019-03-29 14:36:04 +01:00
Lev Livnev
c08b7460da gem-config: add native taglib dependency to taglib-ruby gem 2019-02-25 12:20:52 +00:00
Michael Fellinger
fa5459a2ce defaultGemConfig.ovirt-engine-sdk: init 2019-02-06 23:51:56 +01:00
Sergei Maximov
58f6729e56 Use "${vips}" instead of "${vips.out}" 2019-01-31 18:42:05 +03:00
Sergei Maximov
5aaf8c0e15 gem-config: add ruby-vips 2019-01-31 10:21:55 +03:00
Alyssa Ross
eaf0b5e595 defaultGemConfig.tzinfo: fix for >=2.0 (#54881) 2019-01-29 20:30:56 +00:00
Alyssa Ross
b162eb92d3
defaultGemConfig.rbczmq: init
Fixes https://github.com/manveru/bundix/issues/42.
2019-01-26 21:13:57 +00:00
Marica Odagaki
0b0958314a
gem-config: add semian
Note: on macOS, it works without this config. Testing on Ubuntu/Debian with the parent sha will produce an error about extconf.rb failing to find openssl/sha.h.
2019-01-25 20:18:33 -08:00
Sergei Maximov
05c8d5c88f gem-config: add digest-sha3
`digest-sha3` is a C-extension gem which fails to build on Nix because
it uses non-literals as format strings which is forbidden by the default
Nix hardening settings. There is a pull request to fix that ([1]), but
the gem seems to be abandoned.

This PR disables the "format" hardening for `digest-sha3`.

[1]: https://github.com/phusion/digest-sha3-ruby/pull/8
2019-01-18 13:48:48 +03:00
Sergei Maximov
a3bff35450 gem-config: support rbnacl v6.0.0
With the v6.0.0 release of the `rbnacl` gem, it does not longer depends
on `rbnacl-libsodium` gem (which is now deprecated ([1])) to package the
`libsodium` library and should use the one provided by the distribution;
it raises an error if `rbnacl-libsodium` is detected ([2]).
Unfortunately, default gem config patches `rbnacl` unconditionally ([3]),
which means that newer versions of `rbnacl` fail at startup.

[1]: https://github.com/crypto-rb/rbnacl-libsodium/issues/29
[2]: c176fc0bd8/lib/rbnacl.rb (L4-L8)
[3]: 9fd099a6ae/pkgs/development/ruby-modules/gem-config/default.nix (L300-L306)
2019-01-18 11:04:54 +03:00
Jörg Thalheim
6bcfd5cfb3
Merge pull request #52569 from alyssais/qyliss-ruby
Make myself a Ruby maintainer
2018-12-20 18:42:31 +01:00
Alyssa Ross
dafdadda3a
Merge pull request #52440 from alyssais/bundler
bundler: 1.17.1 -> 1.17.2
2018-12-20 14:34:02 +00:00
Alyssa Ross
843b40ff6b
bundix: add qyliss (me) to maintainers 2018-12-20 14:31:13 +00:00
Jörg Thalheim
da093022a4
Merge pull request #52413 from mat8913/vagrant-libvirt
vagrant: build and install vagrant-libvirt plugin
2018-12-19 12:18:44 +01:00
WilliButz
9b2e8ddebe oxidized: 0.21.0 -> 0.25.0, drop obsolete patch (#52492)
This removes the patch for support of Dell X-series because
oxidized now includes a model for these switches.
2018-12-19 00:24:51 +01:00
Alyssa Ross
8e98e48a43
bundler: 1.17.1 -> 1.17.2 2018-12-17 14:28:40 +00:00
Matthew Harm Bekkema
97200e970c gem-config: add ruby-libvirt
Based on 1d9798c8591bbbed6e6b9ca5c1811ff507b88b9a and
90a804c50af327077e7a219a425e8536bb097e39
2018-12-17 10:22:34 +11:00
Alyssa Ross
26053cae74
bundlerEnv: always include default gems
"default" isn't really a group, it's more the absence of one. With
Bundler, this means that a gem should be installed unconditionally,
regardless of which groups are specified. It doesn't really make sense
to allow these gems to be omitted from a bundlerEnv.
2018-12-11 21:26:09 +00:00
Alyssa Ross
83a2d993d4
bundlerEnv: include all groups by default
This wasn't really an issue until the latest minor release of Bundix
(2.4), because prior to then Bundix didn't emit group attributes, and so
this functionality of bundlerEnv wasn't really used. However, it is now
apparent that a better default for bundlerEnv would be to include all
gem groups by default, not just the default group. This matches the
behavior of Bundler, and makes more sense, because the default group
alone isn't necessarily useful for anything -- consider a Rails app with
production, development, and test groups. It has the additional benefit
of being backwards compatible with how this would have worked before the
Bundix update.
2018-12-11 21:26:08 +00:00
Alyssa Ross
67b1265fb3
bundlerEnv: ensure dependencies always included
Suppose I have a Gemfile like this:

    source "https://rubygems.org"
    gem "actioncable"
    gem "websocket-driver", group: :test

The gemset.nix generated by Bundix 2.4.1 will set ActionCable's groups
to [ "default" ], and websocket-driver's to [ "test" ]. This means that
the generated bundlerEnv wouldn't include websocket-driver unless the
test group was included, even though it's required by the default group.

This is arguably a bug in Bundix (websocket-driver's groups should
probably be [ "default" "test" ] or just [ "default" ]), but there's no
reason bundlerEnv should omit dependencies even given such an input --
it won't necessarily come from Bundix, and it would be good for
bundlerEnv to do the right thing.

To fix this, filterGemset is now a recursive function, that adds
dependencies of gems in the group to the filtered gemset until it
stabilises on the gems that match the required groups, and all of their
recursive dependencies.
2018-12-11 21:26:07 +00:00
Frederik Rietdijk
e0950ae9ad Merge master into staging-next 2018-12-08 12:40:13 +01:00
zimbatm
4a8d0927e1
bundix: 2.4.0 -> 2.4.1 (#51660)
fixes #51656
2018-12-07 17:49:33 +01:00
Frederik Rietdijk
a510aa2672 Merge master into staging-next 2018-12-03 12:18:43 +01:00
Jan Tojnar
a51a99c690
gobject-introspection: rename package
camelCase package name was a huge inconsistency in GNOME package set.
2018-12-02 12:42:29 +01:00
worldofpeace
8776ceafc3 solargraph: 0.28.2 -> 0.29.1 2018-12-02 02:48:01 -05:00
midchildan
6fa5ea6e6b
gem-config: Add missing dependencies for gio and gtk2 2018-11-30 21:35:25 +01:00
Frederik Rietdijk
9db2421d1f Merge master into staging-next 2018-11-29 08:12:56 +01:00
Nick Novitski
f2c07cd63e xcpretty: init at 0.3.0 (#48494) 2018-11-28 12:21:37 +01:00
zimbatm
798a2a6c97
bundix: 2.3.1 -> 2.4.0 (#51146) 2018-11-27 23:36:30 +01:00
Vladimír Čunát
a5de78b7d7
Merge branch 'master' into staging-next 2018-11-26 10:28:00 +01:00
Judson Lester
2d5bd339da Bugfix: gemsets didn't handle paths correctly (#51002) 2018-11-25 13:38:38 +01:00
Frederik Rietdijk
0d0d7dcd06 Merge staging-next into staging 2018-11-18 10:41:34 +01:00
Alyssa Ross
b4bdaa0f18
bundler: 1.16.4 -> 1.17.1 2018-11-15 17:41:20 +00:00
Frederik Rietdijk
1d3bff25db Merge staging-next into staging 2018-11-11 14:28:08 +01:00
Jörg Thalheim
2f97911566
Merge pull request #49817 from alyssais/rack_cve
rack: 1.6.* -> 1.6.11, 2.0.* -> 2.0.6 (CVE-2018-16470, CVE-2018-16471)
2018-11-09 19:30:43 +00:00
Jörg Thalheim
d45590b839
metasploit-framework: fix build
> /nix/store/r2vsi140pys7jnzyk0qz1fj9aji6sq40-ruby2.5.3-rb-readline-0.5.5/lib/ruby/gems/2.5.0/gems/rb-readline-0.5.5/lib/rbreadline.rb:1097:in `<module:RbReadline>': HOME environment variable (or HOMEDRIVE and HOMEPATH) must be set and point to a directory (RuntimeError)
2018-11-09 18:03:18 +00:00
Marwan Aljubeh
8bfe8c45a7 gem-config: add iconv (#49910) 2018-11-08 17:46:29 +01:00
Patrick Hilhorst
b0e9fc131c
treewide: Fix packages using name where they should use pname 2018-11-06 00:06:17 +01:00
Alyssa Ross
69dcb1a2c0 bundlerApp: take buildInputs (#45435)
It would be reasonable to have a Ruby program that depends on some other
program being in the PATH. In this case, the obvious thing to do would
be something like this:

    bundlerApp {
      # ...
      buildInputs = [ makeWrapper ];
      postBuild = ''
        wrapProgram "$out/bin/foo" \
          --prefix PATH : ${lib.makeBinPath [ dep ]}
      '';
    }

However, this doesn't work, because even though it just forwards most of
its arguments to `runCommand`, `bundlerApp` won't take a `buildInputs`
parameter. It doesn't even specify its own `buildInputs`, which means
that the `scripts` parameter to `bundlerApp` (which depends on
`makeWrapper`) is completely broken, and, as far as I can tell, has been
since its inception. I've added a `makeWrapper` build input if the
scripts parameter is present to fix this.

I've added a `buildInputs` option to `bundlerApp`. It's also passed
through to bundled-common because `postBuild` scripts are run there as
well. This actually means that in this example we'd end up going through
two layers of wrappers (one from `bundlerApp` and one from
bundled-common), but that has always been the case and isn't likely to
break anything. That oddity does suggest that it might be prudent to
not forward `postBuild` to bundled-common (or to at least use a
different option) though...

FWIW, as far as I can tell no package in nixpkgs uses either the
`scripts` or `postBuild` options to `bundlerApp`.
2018-10-29 22:39:51 +01:00
Michael Fellinger
34e1fa4a50 buildRubyGem: Provide manpages for Ruby gems (#49334) 2018-10-29 01:48:05 +01:00