[Nix-commits] [NixOS/nixpkgs] 65364c: pypdf2: 1.25.1 -> 1.26.0
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 65364cc83c7ccc0b1e1572208b6d511184b355c0 https://github.com/NixOS/nixpkgs/commit/65364cc83c7ccc0b1e1572208b6d511184b355c0 Author: Rahul Gopinath Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/top-level/python-packages.nix Log Message: --- pypdf2: 1.25.1 -> 1.26.0 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] cb8651: radeontop: 2016-07-03 -> 2016-07-04
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: cb86518fd390f2c13bf36aa8f5c6256df7dd7f6b https://github.com/NixOS/nixpkgs/commit/cb86518fd390f2c13bf36aa8f5c6256df7dd7f6b Author: Tobias Geerinckx-Rice Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/os-specific/linux/radeontop/default.nix Log Message: --- radeontop: 2016-07-03 -> 2016-07-04 Add support for unprivileged use on both the Linux console and X. Commit: 0385abbc707e859dc16e146365dc8e072cf6caa3 https://github.com/NixOS/nixpkgs/commit/0385abbc707e859dc16e146365dc8e072cf6caa3 Author: Tobias Geerinckx-Rice Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/tools/system/di/default.nix Log Message: --- di: 4.37 -> 4.42; trim meta.description Compare: https://github.com/NixOS/nixpkgs/compare/65364cc83c7c...0385abbc707e___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixops] 887eec: nix/libvirtd-image.nix: use 'out' output for 'conf...
Branch: refs/heads/master Home: https://github.com/NixOS/nixops Commit: 887eec9ce4419dca8ba8806e581d03ec5ca01ef8 https://github.com/NixOS/nixops/commit/887eec9ce4419dca8ba8806e581d03ec5ca01ef8 Author: Renzo Carbonara Date: 2016-06-29 (Wed, 29 Jun 2016) Changed paths: M nix/libvirtd-image.nix Log Message: --- nix/libvirtd-image.nix: use 'out' output for 'config.nix.package'. This fixes issue #448, likely introduced by nixpkgs@21a2f2ba3bc8962845f0b45cacac4e47557ebf13 Commit: ecae856fc958d5d7490f9b88bfe244dc4971d626 https://github.com/NixOS/nixops/commit/ecae856fc958d5d7490f9b88bfe244dc4971d626 Author: Domen Kožar Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M nix/libvirtd-image.nix Log Message: --- Merge pull request #462 from k0001/fix-448 nix/libvirtd-image.nix: use 'out' output for 'config.nix.package'. Compare: https://github.com/NixOS/nixops/compare/d3b7da92e09d...ecae856fc958___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 17a777: zim: 0.63 -> 0.65
Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: 17a777c8edefef78e50a5a976c71053ad63ad392 https://github.com/NixOS/nixpkgs/commit/17a777c8edefef78e50a5a976c71053ad63ad392 Author: Vincent Laporte Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/applications/office/zim/default.nix Log Message: --- zim: 0.63 -> 0.65 (cherry picked from commit 13c6b9ba8549c3db91c6f321e0413a538bce9388) [Bjørn: Without this commit, zim fails to start: "ERROR: Failed running: $PWD/zim", where $PWD is the (expanded) current working directory. Fix by making sys.argv[0] an absolute path to zim.] ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Next London NixOs User Group Meetup!
Thanks Simone for organizing the talk! We had quite a small turnout but it was good fun. The video is now available at https://skillsmatter.com/skillscasts/8307-london-nixos-meetup . And the slides at https://zimbatm.github.io/direnv-and-nix-talk/ Cheers, z On Sat, 25 Jun 2016 at 10:20 zimbatm wrote: > Woop! I'm the one giving the talk on direnv and nix by the way. Thanks for > organising Simone! > > On Wed, 22 Jun 2016, 14:34 Simone Trubian, > wrote: > >> For all of you that are interested the London User Group is organising >> the next NixOs meetup on July 4. You can find out the agenda and register >> here https://skillsmatter.com/meetups/8171-london-nixos-meetup >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Rok,
what about people who are already using previous solution? Why break their
workflows?
2016-07-05 7:36 GMT+01:00 Rok Garbas :
> +1 for just keeping the name npm2nix and bumping up the version.
>
> i'm not using it on any active project, but i'm going to in the near
> future.
>
>
>
> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug
> wrote:
> > Hi Sander,
> >
> > sorry for my very late response. I'll make this one brief as I am sadly
> on
> > my phone.
> >
> > I belong to one of those who tried your new npm2nix and in fact am
> already
> > using it regularly. I am very much in favor of having your
> re-engineeering2
> > branch replacing npm2nix as the de-facto node integration tool.
> >
> > I also definitely want to see the current set of auto-generated node
> > packages removed from nix. They are almost exclusively *totally*
> outdated.
> >
> > Thank you a lot for your continued efforts on this. Working with
> npm/node is
> > annoying but we are better off with your contributions.
> >
> > cheers,
> > Tobi
> >
> > On 22 Jun 2016, at 20:24, Sander van der Burg
> wrote:
> >
> > Hello Nix and Node.js users,
> >
> > I have been absent for a while in this discussion, but as far as I know
> the
> > state of the NPM packages in Nixpkgs is still quite bad and despite some
> > discussions on the mailing list we have not really come to any consensus
> > yet.
> >
> > As some of you may know, I have my own re-engineered version of npm2nix
> that
> > lives in a specific branch in my own personal fork
> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few
> months
> > ago, I did some major efforts in getting npm 3.x's behaviour supported,
> > which I have documented in this blog post:
> >
> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html
> >
> > I have been using this reengineering2 branch for all my public and some
> of
> > my private projects since the beginning of this year, and for me it
> seems to
> > work quite well, despite the fact that some of npm 3.x's flat module
> > installation oddities are still not accurately supported yet.
> >
> > I also received a couple of reports from other people claiming that their
> > projects work and even encountered some people saying that it should
> replace
> > the current npm2nix. :)
> >
> > Obviously, I do not want to claim that my implementation is the perfect
> > solution as it (for example) is much slower than the vanilla npm2nix,
> and it
> > composes the entire set of dependencies in one derivation as opposed to
> > generating a Nix store path per NPM dependency. (I do this for a very
> good
> > reason. For more details, please read my blog post).
> >
> > Furthermore, I have also spoken to people that suggested completely
> > different kinds of approaches in getting NPM supported in a Nix
> environment.
> >
> > Something that I have not done yet is investigating whether this
> > reengineered solution could be a potential replacement for the NPM
> packages
> > set in Nixpkgs.
> >
> > Today, I have been working on an integration pattern, and the good news
> is:
> > it seems that I was able to generate Nix expressions for almost all
> packages
> > that are in pkgs/top-level/node-packages.json. The only exceptions were
> the
> > node-xmpp-* and bip-* packages, but some of them seem to have broken
> > dependencies, which is not npm2nix's fault.
> >
> > If we would proceed integrating, we have a number of practical
> implications:
> >
> > - I believe it is desired to have both Node.js 4.x and Node.js 5.x, 6.x
> > supported (I actually need all of them). To support all of these, we need
> > two different sets of generated Nix expressions. The former uses npm 2.x
> > with the classic dependency addressing approach and the latter uses npm
> 3.x
> > with flat module installations.
> > - I think most library packages should be removed from
> node-packages.json:
> > as explained in my blog post: how a package gets composed and to which
> > version a range resolve depends on the state of the includer. When
> somebody
> > wants their own NPM project to be deployed, he should use npm2nix
> directly
> > on package.json, and not refer to any NPM libraries in Nixpkgs.
> > - Some NPM packages must be overridden to provide native dependencies.
> The
> > mechanisms that the reengineering2 branch use are different. It would
> > probably take a bit of effort to get these migrated.
> >
> > For example, this is how I override the webdrvr package to provide
> phantomjs
> > and the Selenium webdriver:
> >
> > {pkgs, system}:
> >
> > let
> > nodePackages = import ./composition-v4.nix {
> > inherit pkgs system;
> > };
> > in
> > nodePackages // {
> > webdrvr = nodePackages.webdrvr.override (oldAttrs: {
> > buildInputs = oldAttrs.buildInputs ++ [ pkgs.phantomjs ];
> >
> > preRebuild = ''
> > mkdir $TMPDIR/webdrvr
> >
> > ln -s ${pkgs.fetchurl {
> > url =
> > "
> https://selenium-release.storage.goog
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Hi > On 04 Jul 2016, at 17:34, Sander van der Burg wrote: > > So far only one response... Sorry, was silent agreement on my end ;) > I'm planning to implement the most pragmatic approach very soon -- due to > lack of a better/cooler name I'll rename my fork of npm2nix to node2nix. > > Moreover, I will add a second attribute set to Nixpkgs allowing people to > deploy packages that have been generated with node2nix. Also, I will take the > original node-packages.json as a basis, but I will remove the library > packages that I believe that should not be in there. > > Because the old package set will still be there, nobody should be disrupted > and meanwhile people can try/test the new approach. > > Any objections? I've looked into you fork already, looks very positive to me. Appreciate your work on it and also the in-depth background explanation in your blog. :) I am using mainly pip2nix and npm2nix in my projects to generate package sets, willing to switch to node2nix soonish. >From my perspective, I would even take a switch under the same name, even if >it would mean a few hazzles for me potentially to get things up and running >again. On the other side, esp. if people use it and get such a change as a >surprise, it can be negative, since they would be forces to switch fast or get >the old npm2nix available still. At least a fallback option to get the old >npm2nix easily would be good to have if we keep the same name for the new >thing. Cheers, Johannes ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
For what it’s worth, I’m using the re-engineeering2 branch standalone for projects with hundreds of npm dependencies. The way I use it right now is like this: https://gist.github.com/manveru/20d22586d9dceae90930be528cbc49ce Having it as a part of nixpkgs would be nice, but won’t really change how I build and use it, and having npm dependencies listed in nixpkgs isn’t very productive, the ecosystem for JS libraries changes so fast, that we’d have to automatically update the index every day and hope nothing breaks, people depending on js libraries listed in nixpkgs will always be frustrated. I prefer having the checksums generated by npm2nix, and giving each app that is packaged in nixpkgs their own list of dependencies generated by npm2nix. So for now, I think adding it under a different name to nixpkgs and gradually changing things to use the new approach might be the best solution. There are two things that I’m still hoping could be done better: one is that the location to the package.json should be more flexible, while you can specify where it is located when running npm2nix, it won’t be found later when it’s in a directory above the one you put the npm2nix-generated files in. I opted for putting npm-generated files into their own subdirectory, and then run `ln -s "$(nix-build ./nix/npm.nix -A package)/lib/node_modules/myapp/node_modules" node_modules` Maybe there’s a better way, but that’s what I figured out on my own. On 5 July 2016 at 11:17:05, Tomasz Czyż (tomasz.c...@gmail.com) wrote: Rok, what about people who are already using previous solution? Why break their workflows? 2016-07-05 7:36 GMT+01:00 Rok Garbas : > +1 for just keeping the name npm2nix and bumping up the version. > > i'm not using it on any active project, but i'm going to in the near > future. > > > > On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug > wrote: > > Hi Sander, > > > > sorry for my very late response. I'll make this one brief as I am sadly > on > > my phone. > > > > I belong to one of those who tried your new npm2nix and in fact am > already > > using it regularly. I am very much in favor of having your > re-engineeering2 > > branch replacing npm2nix as the de-facto node integration tool. > > > > I also definitely want to see the current set of auto-generated node > > packages removed from nix. They are almost exclusively *totally* > outdated. > > > > Thank you a lot for your continued efforts on this. Working with > npm/node is > > annoying but we are better off with your contributions. > > > > cheers, > > Tobi > > > > On 22 Jun 2016, at 20:24, Sander van der Burg > wrote: > > > > Hello Nix and Node.js users, > > > > I have been absent for a while in this discussion, but as far as I know > the > > state of the NPM packages in Nixpkgs is still quite bad and despite some > > discussions on the mailing list we have not really come to any consensus > > yet. > > > > As some of you may know, I have my own re-engineered version of npm2nix > that > > lives in a specific branch in my own personal fork > > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few > months > > ago, I did some major efforts in getting npm 3.x's behaviour supported, > > which I have documented in this blog post: > > > http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html > > > > I have been using this reengineering2 branch for all my public and some > of > > my private projects since the beginning of this year, and for me it > seems to > > work quite well, despite the fact that some of npm 3.x's flat module > > installation oddities are still not accurately supported yet. > > > > I also received a couple of reports from other people claiming that their > > projects work and even encountered some people saying that it should > replace > > the current npm2nix. :) > > > > Obviously, I do not want to claim that my implementation is the perfect > > solution as it (for example) is much slower than the vanilla npm2nix, > and it > > composes the entire set of dependencies in one derivation as opposed to > > generating a Nix store path per NPM dependency. (I do this for a very > good > > reason. For more details, please read my blog post). > > > > Furthermore, I have also spoken to people that suggested completely > > different kinds of approaches in getting NPM supported in a Nix > environment. > > > > Something that I have not done yet is investigating whether this > > reengineered solution could be a potential replacement for the NPM > packages > > set in Nixpkgs. > > > > Today, I have been working on an integration pattern, and the good news > is: > > it seems that I was able to generate Nix expressions for almost all > packages > > that are in pkgs/top-level/node-packages.json. The only exceptions were > the > > node-xmpp-* and bip-* packages, but some of them seem to have broken > > dependencies, which is not npm2nix's fault. > > > > If we would proceed integrating, we have a number of practical >
[Nix-commits] [NixOS/nixpkgs] 1bbcd9: spacefm: sudo and gksu fixes #15758 and license up...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 1bbcd91b2ef0738709f7d955760a6624a9745fc2 https://github.com/NixOS/nixpkgs/commit/1bbcd91b2ef0738709f7d955760a6624a9745fc2 Author: Ram Kromberg Date: 2016-07-03 (Sun, 03 Jul 2016) Changed paths: M nixos/modules/module-list.nix A nixos/modules/programs/spacefm.nix M pkgs/applications/misc/spacefm/default.nix Log Message: --- spacefm: sudo and gksu fixes #15758 and license update Commit: 7926a98a7162d822e658bdaba171773c73a2992f https://github.com/NixOS/nixpkgs/commit/7926a98a7162d822e658bdaba171773c73a2992f Author: Arseniy Seroka Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M nixos/modules/module-list.nix A nixos/modules/programs/spacefm.nix M pkgs/applications/misc/spacefm/default.nix Log Message: --- Merge pull request #16650 from RamKromberg/fix/spacefm-issue-15758 spacefm: sudo and gksu fixes #15758 and license update Compare: https://github.com/NixOS/nixpkgs/compare/0385abbc707e...7926a98a7162___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 94cf81: gpaste: 3.18.4 -> 3.18.5
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 94cf81ce89884237f419c6b72aee1bd2f3db4928 https://github.com/NixOS/nixpkgs/commit/94cf81ce89884237f419c6b72aee1bd2f3db4928 Author: Damien Cassou Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/desktops/gnome-3/3.18/misc/gpaste/default.nix Log Message: --- gpaste: 3.18.4 -> 3.18.5 Commit: 33a9713ee85b2bd5bb2ab6760a237da49c509a9e https://github.com/NixOS/nixpkgs/commit/33a9713ee85b2bd5bb2ab6760a237da49c509a9e Author: Arseniy Seroka Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/desktops/gnome-3/3.18/misc/gpaste/default.nix Log Message: --- Merge pull request #16719 from DamienCassou/gpaste-3.18.5 gpaste: 3.18.4 -> 3.18.5 Compare: https://github.com/NixOS/nixpkgs/compare/7926a98a7162...33a9713ee85b___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 242260: gpaste: 3.20 -> 3.20.4
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 24226031d9f77e7925c0e6ce2b6fd35d8cdb8e7e https://github.com/NixOS/nixpkgs/commit/24226031d9f77e7925c0e6ce2b6fd35d8cdb8e7e Author: Damien Cassou Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/desktops/gnome-3/3.20/misc/gpaste/default.nix Log Message: --- gpaste: 3.20 -> 3.20.4 Commit: 79ea22723dc60ba67fae1ff0c4cd9ef78f8c1b55 https://github.com/NixOS/nixpkgs/commit/79ea22723dc60ba67fae1ff0c4cd9ef78f8c1b55 Author: Arseniy Seroka Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/desktops/gnome-3/3.20/misc/gpaste/default.nix Log Message: --- Merge pull request #16720 from DamienCassou/gpaste-3.20.4 gpaste: 3.20 -> 3.20.4 Compare: https://github.com/NixOS/nixpkgs/compare/33a9713ee85b...79ea22723dc6___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 86e2cd: wxsqlite3: init at 3.3.1
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 86e2cd9066ac69752bb297fc48d116dcc6f53acc https://github.com/NixOS/nixpkgs/commit/86e2cd9066ac69752bb297fc48d116dcc6f53acc Author: Rahul Gopinath Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: A pkgs/development/libraries/wxsqlite3/default.nix M pkgs/top-level/all-packages.nix Log Message: --- wxsqlite3: init at 3.3.1 Commit: bf1013ae726b7cd3dd9953020c5e6854d0ec3b0a https://github.com/NixOS/nixpkgs/commit/bf1013ae726b7cd3dd9953020c5e6854d0ec3b0a Author: Arseniy Seroka Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: A pkgs/development/libraries/wxsqlite3/default.nix M pkgs/top-level/all-packages.nix Log Message: --- Merge pull request #16718 from vrthra/wxsqlite3 wxsqlite3: init at 3.3.1 Compare: https://github.com/NixOS/nixpkgs/compare/79ea22723dc6...bf1013ae726b___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 56cb0f: aspellDicts.en: 7.1-0 -> 2016.06.26-0
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 56cb0f763edb6b4e6db83e57527f75e29ed4e2ca https://github.com/NixOS/nixpkgs/commit/56cb0f763edb6b4e6db83e57527f75e29ed4e2ca Author: Kranium Gikos Mendoza Date: 2016-07-03 (Sun, 03 Jul 2016) Changed paths: M pkgs/development/libraries/aspell/dictionaries.nix Log Message: --- aspellDicts.en: 7.1-0 -> 2016.06.26-0 Commit: aea9c778beb79a10a085cb24d57c999d85131974 https://github.com/NixOS/nixpkgs/commit/aea9c778beb79a10a085cb24d57c999d85131974 Author: Arseniy Seroka Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/development/libraries/aspell/dictionaries.nix Log Message: --- Merge pull request #16678 from womfoo/bump/aspellDicts-en-2016.06.26-0 aspellDicts.en: 7.1-0 -> 2016.06.26-0 Compare: https://github.com/NixOS/nixpkgs/compare/bf1013ae726b...aea9c778beb7___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 057421: nix.requireSignedBinaryCaches: description fix
Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: 057421e8e29856504243e980d00596f0655ab7a2 https://github.com/NixOS/nixpkgs/commit/057421e8e29856504243e980d00596f0655ab7a2 Author: Al Zohali Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M nixos/modules/services/misc/nix-daemon.nix Log Message: --- nix.requireSignedBinaryCaches: description fix (cherry picked from commit a227bd4e3b9c98f61fa98f305ea191cb20dbbabd) [Bjørn: The description says the default is "disabled" (wrong).] ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] f85602: nixos/spacefm: unbreak manual build
Branch: refs/heads/master
Home: https://github.com/NixOS/nixpkgs
Commit: f8560212ca3e18297b23c5fc8a08610f4440355b
https://github.com/NixOS/nixpkgs/commit/f8560212ca3e18297b23c5fc8a08610f4440355b
Author: Bjørn Forsman
Date: 2016-07-05 (Tue, 05 Jul 2016)
Changed paths:
M nixos/modules/programs/spacefm.nix
Log Message:
---
nixos/spacefm: unbreak manual build
Fixup regression introduced in commit 1bbcd91b2ef0738709f7d95
("spacefm: sudo and gksu fixes #15758 and license update").
A missing end tag caused this:
$ nixos-rebuild build
...
options-db.xml:4402: parser error : Opening and ending tag mismatch: filename
line 4401 and para
Type:
booleanDefault:___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 0efd18: sigil: 0.7.4 > 0.9.6
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 0efd18746abd338d670ab82fa0d9e5411fd53329 https://github.com/NixOS/nixpkgs/commit/0efd18746abd338d670ab82fa0d9e5411fd53329 Author: Ram Kromberg Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/applications/editors/sigil/default.nix Log Message: --- sigil: 0.7.4 > 0.9.6 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Thank you for the responses so far To remind you about the set of packages I intend to include: I only want end-user software (such as command-line utilities) and packages that are dependencies of non-NPM projects to appear in Nixpkgs. All the other packages will be removed from node-packages.json. On Tue, Jul 5, 2016 at 9:56 AM, Michael Fellinger wrote: > For what it’s worth, I’m using the re-engineeering2 branch standalone for > projects with hundreds of npm dependencies. The way I use it right now is > like this: > > https://gist.github.com/manveru/20d22586d9dceae90930be528cbc49ce > > Having it as a part of nixpkgs would be nice, but won’t really change how > I build and use it, and having npm dependencies listed in nixpkgs isn’t > very productive, the ecosystem for JS libraries changes so fast, that we’d > have to automatically update the index every day and hope nothing breaks, > people depending on js libraries listed in nixpkgs will always be > frustrated. > > I prefer having the checksums generated by npm2nix, and giving each app > that is packaged in nixpkgs their own list of dependencies generated by > npm2nix. > > So for now, I think adding it under a different name to nixpkgs and > gradually changing things to use the new approach might be the best > solution. > > There are two things that I’m still hoping could be done better: one is > that the location to the package.json should be more flexible, while you > can specify where it is located when running npm2nix, it won’t be found > later when it’s in a directory above the one you put the npm2nix-generated > files in. I opted for putting npm-generated files into their own > subdirectory, and then run > > `ln -s "$(nix-build ./nix/npm.nix -A > package)/lib/node_modules/myapp/node_modules" node_modules` > > Maybe there’s a better way, but that’s what I figured out on my own. > > On 5 July 2016 at 11:17:05, Tomasz Czyż (tomasz.c...@gmail.com) wrote: > > Rok, > > what about people who are already using previous solution? Why break their > workflows? > > 2016-07-05 7:36 GMT+01:00 Rok Garbas : > >> +1 for just keeping the name npm2nix and bumping up the version. >> >> i'm not using it on any active project, but i'm going to in the near >> future. >> >> >> >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug >> wrote: >> > Hi Sander, >> > >> > sorry for my very late response. I'll make this one brief as I am sadly >> on >> > my phone. >> > >> > I belong to one of those who tried your new npm2nix and in fact am >> already >> > using it regularly. I am very much in favor of having your >> re-engineeering2 >> > branch replacing npm2nix as the de-facto node integration tool. >> > >> > I also definitely want to see the current set of auto-generated node >> > packages removed from nix. They are almost exclusively *totally* >> outdated. >> > >> > Thank you a lot for your continued efforts on this. Working with >> npm/node is >> > annoying but we are better off with your contributions. >> > >> > cheers, >> > Tobi >> > >> > On 22 Jun 2016, at 20:24, Sander van der Burg >> wrote: >> > >> > Hello Nix and Node.js users, >> > >> > I have been absent for a while in this discussion, but as far as I know >> the >> > state of the NPM packages in Nixpkgs is still quite bad and despite some >> > discussions on the mailing list we have not really come to any consensus >> > yet. >> > >> > As some of you may know, I have my own re-engineered version of npm2nix >> that >> > lives in a specific branch in my own personal fork >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few >> months >> > ago, I did some major efforts in getting npm 3.x's behaviour supported, >> > which I have documented in this blog post: >> > >> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html >> > >> > I have been using this reengineering2 branch for all my public and some >> of >> > my private projects since the beginning of this year, and for me it >> seems to >> > work quite well, despite the fact that some of npm 3.x's flat module >> > installation oddities are still not accurately supported yet. >> > >> > I also received a couple of reports from other people claiming that >> their >> > projects work and even encountered some people saying that it should >> replace >> > the current npm2nix. :) >> > >> > Obviously, I do not want to claim that my implementation is the perfect >> > solution as it (for example) is much slower than the vanilla npm2nix, >> and it >> > composes the entire set of dependencies in one derivation as opposed to >> > generating a Nix store path per NPM dependency. (I do this for a very >> good >> > reason. For more details, please read my blog post). >> > >> > Furthermore, I have also spoken to people that suggested completely >> > different kinds of approaches in getting NPM supported in a Nix >> environment. >> > >> > Something that I have not done yet is investigating whether this >> > reengineered solution
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
Ok good to hear! The reason why I would take the pragmatic approach is because I know from experience that any kind of fundamental change (regardless of whether is good or bad) will take time for people to accept. Having two versions makes it possible for people to gradually accept and to smoothly make the transition to a new solution. Forcing people to unexpectedly do this will not make them happy. On Tue, Jul 5, 2016 at 9:44 AM, Johannes Bornhold < johannes.bornh...@gmail.com> wrote: > Hi > > > On 04 Jul 2016, at 17:34, Sander van der Burg > wrote: > > > > So far only one response... > Sorry, was silent agreement on my end ;) > > > I'm planning to implement the most pragmatic approach very soon -- due > to lack of a better/cooler name I'll rename my fork of npm2nix to node2nix. > > > > Moreover, I will add a second attribute set to Nixpkgs allowing people > to deploy packages that have been generated with node2nix. Also, I will > take the original node-packages.json as a basis, but I will remove the > library packages that I believe that should not be in there. > > > > Because the old package set will still be there, nobody should be > disrupted and meanwhile people can try/test the new approach. > > > > Any objections? > > I've looked into you fork already, looks very positive to me. Appreciate > your work on it and also the in-depth background explanation in your blog. > :) > > I am using mainly pip2nix and npm2nix in my projects to generate package > sets, willing to switch to node2nix soonish. > > From my perspective, I would even take a switch under the same name, even > if it would mean a few hazzles for me potentially to get things up and > running again. On the other side, esp. if people use it and get such a > change as a surprise, it can be negative, since they would be forces to > switch fast or get the old npm2nix available still. At least a fallback > option to get the old npm2nix easily would be good to have if we keep the > same name for the new thing. > > Cheers, Johannes > > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
we can still keep and old version of npm2nix in nixpkgs for ppl who use it. and also a branch with old code could be created, for people that want pudh bugfixes or develop further (very unlikely). On Tue, Jul 5, 2016 at 11:16 AM, Tomasz Czyż wrote: > Rok, > > what about people who are already using previous solution? Why break their > workflows? > > 2016-07-05 7:36 GMT+01:00 Rok Garbas : >> >> +1 for just keeping the name npm2nix and bumping up the version. >> >> i'm not using it on any active project, but i'm going to in the near >> future. >> >> >> >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug >> wrote: >> > Hi Sander, >> > >> > sorry for my very late response. I'll make this one brief as I am sadly >> > on >> > my phone. >> > >> > I belong to one of those who tried your new npm2nix and in fact am >> > already >> > using it regularly. I am very much in favor of having your >> > re-engineeering2 >> > branch replacing npm2nix as the de-facto node integration tool. >> > >> > I also definitely want to see the current set of auto-generated node >> > packages removed from nix. They are almost exclusively *totally* >> > outdated. >> > >> > Thank you a lot for your continued efforts on this. Working with >> > npm/node is >> > annoying but we are better off with your contributions. >> > >> > cheers, >> > Tobi >> > >> > On 22 Jun 2016, at 20:24, Sander van der Burg >> > wrote: >> > >> > Hello Nix and Node.js users, >> > >> > I have been absent for a while in this discussion, but as far as I know >> > the >> > state of the NPM packages in Nixpkgs is still quite bad and despite some >> > discussions on the mailing list we have not really come to any consensus >> > yet. >> > >> > As some of you may know, I have my own re-engineered version of npm2nix >> > that >> > lives in a specific branch in my own personal fork >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few >> > months >> > ago, I did some major efforts in getting npm 3.x's behaviour supported, >> > which I have documented in this blog post: >> > >> > http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html >> > >> > I have been using this reengineering2 branch for all my public and some >> > of >> > my private projects since the beginning of this year, and for me it >> > seems to >> > work quite well, despite the fact that some of npm 3.x's flat module >> > installation oddities are still not accurately supported yet. >> > >> > I also received a couple of reports from other people claiming that >> > their >> > projects work and even encountered some people saying that it should >> > replace >> > the current npm2nix. :) >> > >> > Obviously, I do not want to claim that my implementation is the perfect >> > solution as it (for example) is much slower than the vanilla npm2nix, >> > and it >> > composes the entire set of dependencies in one derivation as opposed to >> > generating a Nix store path per NPM dependency. (I do this for a very >> > good >> > reason. For more details, please read my blog post). >> > >> > Furthermore, I have also spoken to people that suggested completely >> > different kinds of approaches in getting NPM supported in a Nix >> > environment. >> > >> > Something that I have not done yet is investigating whether this >> > reengineered solution could be a potential replacement for the NPM >> > packages >> > set in Nixpkgs. >> > >> > Today, I have been working on an integration pattern, and the good news >> > is: >> > it seems that I was able to generate Nix expressions for almost all >> > packages >> > that are in pkgs/top-level/node-packages.json. The only exceptions were >> > the >> > node-xmpp-* and bip-* packages, but some of them seem to have broken >> > dependencies, which is not npm2nix's fault. >> > >> > If we would proceed integrating, we have a number of practical >> > implications: >> > >> > - I believe it is desired to have both Node.js 4.x and Node.js 5.x, 6.x >> > supported (I actually need all of them). To support all of these, we >> > need >> > two different sets of generated Nix expressions. The former uses npm 2.x >> > with the classic dependency addressing approach and the latter uses npm >> > 3.x >> > with flat module installations. >> > - I think most library packages should be removed from >> > node-packages.json: >> > as explained in my blog post: how a package gets composed and to which >> > version a range resolve depends on the state of the includer. When >> > somebody >> > wants their own NPM project to be deployed, he should use npm2nix >> > directly >> > on package.json, and not refer to any NPM libraries in Nixpkgs. >> > - Some NPM packages must be overridden to provide native dependencies. >> > The >> > mechanisms that the reengineering2 branch use are different. It would >> > probably take a bit of effort to get these migrated. >> > >> > For example, this is how I override the webdrvr package to provide >> > phantomjs >> > and the Selenium webdriv
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
I've found myself confused by multiple projects using the same lang2nix name, and big changes in format. One consistent complaint I have is the top of the file usually says: // Generated by lang2nix but having more information like a version number and a URL to the project would have saved hours of searching and trying different tools. Something like: // Generated by lang2nix v0.1.0 // See more at https://github.com/myuser/lang2nix would be a really nice usability adjustment. On Tue, Jul 5, 2016 at 7:36 AM Rok Garbas wrote: > we can still keep and old version of npm2nix in nixpkgs for ppl who use it. > and also a branch with old code could be created, for people that want > pudh bugfixes or develop further (very unlikely). > > > On Tue, Jul 5, 2016 at 11:16 AM, Tomasz Czyż > wrote: > > Rok, > > > > what about people who are already using previous solution? Why break > their > > workflows? > > > > 2016-07-05 7:36 GMT+01:00 Rok Garbas : > >> > >> +1 for just keeping the name npm2nix and bumping up the version. > >> > >> i'm not using it on any active project, but i'm going to in the near > >> future. > >> > >> > >> > >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug > >> wrote: > >> > Hi Sander, > >> > > >> > sorry for my very late response. I'll make this one brief as I am > sadly > >> > on > >> > my phone. > >> > > >> > I belong to one of those who tried your new npm2nix and in fact am > >> > already > >> > using it regularly. I am very much in favor of having your > >> > re-engineeering2 > >> > branch replacing npm2nix as the de-facto node integration tool. > >> > > >> > I also definitely want to see the current set of auto-generated node > >> > packages removed from nix. They are almost exclusively *totally* > >> > outdated. > >> > > >> > Thank you a lot for your continued efforts on this. Working with > >> > npm/node is > >> > annoying but we are better off with your contributions. > >> > > >> > cheers, > >> > Tobi > >> > > >> > On 22 Jun 2016, at 20:24, Sander van der Burg > >> > wrote: > >> > > >> > Hello Nix and Node.js users, > >> > > >> > I have been absent for a while in this discussion, but as far as I > know > >> > the > >> > state of the NPM packages in Nixpkgs is still quite bad and despite > some > >> > discussions on the mailing list we have not really come to any > consensus > >> > yet. > >> > > >> > As some of you may know, I have my own re-engineered version of > npm2nix > >> > that > >> > lives in a specific branch in my own personal fork > >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few > >> > months > >> > ago, I did some major efforts in getting npm 3.x's behaviour > supported, > >> > which I have documented in this blog post: > >> > > >> > > http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html > >> > > >> > I have been using this reengineering2 branch for all my public and > some > >> > of > >> > my private projects since the beginning of this year, and for me it > >> > seems to > >> > work quite well, despite the fact that some of npm 3.x's flat module > >> > installation oddities are still not accurately supported yet. > >> > > >> > I also received a couple of reports from other people claiming that > >> > their > >> > projects work and even encountered some people saying that it should > >> > replace > >> > the current npm2nix. :) > >> > > >> > Obviously, I do not want to claim that my implementation is the > perfect > >> > solution as it (for example) is much slower than the vanilla npm2nix, > >> > and it > >> > composes the entire set of dependencies in one derivation as opposed > to > >> > generating a Nix store path per NPM dependency. (I do this for a very > >> > good > >> > reason. For more details, please read my blog post). > >> > > >> > Furthermore, I have also spoken to people that suggested completely > >> > different kinds of approaches in getting NPM supported in a Nix > >> > environment. > >> > > >> > Something that I have not done yet is investigating whether this > >> > reengineered solution could be a potential replacement for the NPM > >> > packages > >> > set in Nixpkgs. > >> > > >> > Today, I have been working on an integration pattern, and the good > news > >> > is: > >> > it seems that I was able to generate Nix expressions for almost all > >> > packages > >> > that are in pkgs/top-level/node-packages.json. The only exceptions > were > >> > the > >> > node-xmpp-* and bip-* packages, but some of them seem to have broken > >> > dependencies, which is not npm2nix's fault. > >> > > >> > If we would proceed integrating, we have a number of practical > >> > implications: > >> > > >> > - I believe it is desired to have both Node.js 4.x and Node.js 5.x, > 6.x > >> > supported (I actually need all of them). To support all of these, we > >> > need > >> > two different sets of generated Nix expressions. The former uses npm > 2.x > >> > with the classic dependency addressing approach and t
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
+1 ... i did just that recently for pypi2nix. but i'll also add a link to the project home. [1] https://github.com/garbas/pypi2nix/commit/339aee3b149909430ebe7e3e27b8cf158addaef1 On Tue, Jul 5, 2016 at 2:47 PM, Graham Christensen wrote: > I've found myself confused by multiple projects using the same lang2nix > name, and big changes in format. One consistent complaint I have is the top > of the file usually says: > > // Generated by lang2nix > > but having more information like a version number and a URL to the project > would have saved hours of searching and trying different tools. Something > like: > > // Generated by lang2nix v0.1.0 > // See more at https://github.com/myuser/lang2nix > > would be a really nice usability adjustment. > > On Tue, Jul 5, 2016 at 7:36 AM Rok Garbas wrote: >> >> we can still keep and old version of npm2nix in nixpkgs for ppl who use >> it. >> and also a branch with old code could be created, for people that want >> pudh bugfixes or develop further (very unlikely). >> >> >> On Tue, Jul 5, 2016 at 11:16 AM, Tomasz Czyż >> wrote: >> > Rok, >> > >> > what about people who are already using previous solution? Why break >> > their >> > workflows? >> > >> > 2016-07-05 7:36 GMT+01:00 Rok Garbas : >> >> >> >> +1 for just keeping the name npm2nix and bumping up the version. >> >> >> >> i'm not using it on any active project, but i'm going to in the near >> >> future. >> >> >> >> >> >> >> >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug >> >> wrote: >> >> > Hi Sander, >> >> > >> >> > sorry for my very late response. I'll make this one brief as I am >> >> > sadly >> >> > on >> >> > my phone. >> >> > >> >> > I belong to one of those who tried your new npm2nix and in fact am >> >> > already >> >> > using it regularly. I am very much in favor of having your >> >> > re-engineeering2 >> >> > branch replacing npm2nix as the de-facto node integration tool. >> >> > >> >> > I also definitely want to see the current set of auto-generated node >> >> > packages removed from nix. They are almost exclusively *totally* >> >> > outdated. >> >> > >> >> > Thank you a lot for your continued efforts on this. Working with >> >> > npm/node is >> >> > annoying but we are better off with your contributions. >> >> > >> >> > cheers, >> >> > Tobi >> >> > >> >> > On 22 Jun 2016, at 20:24, Sander van der Burg >> >> > wrote: >> >> > >> >> > Hello Nix and Node.js users, >> >> > >> >> > I have been absent for a while in this discussion, but as far as I >> >> > know >> >> > the >> >> > state of the NPM packages in Nixpkgs is still quite bad and despite >> >> > some >> >> > discussions on the mailing list we have not really come to any >> >> > consensus >> >> > yet. >> >> > >> >> > As some of you may know, I have my own re-engineered version of >> >> > npm2nix >> >> > that >> >> > lives in a specific branch in my own personal fork >> >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A few >> >> > months >> >> > ago, I did some major efforts in getting npm 3.x's behaviour >> >> > supported, >> >> > which I have documented in this blog post: >> >> > >> >> > >> >> > http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html >> >> > >> >> > I have been using this reengineering2 branch for all my public and >> >> > some >> >> > of >> >> > my private projects since the beginning of this year, and for me it >> >> > seems to >> >> > work quite well, despite the fact that some of npm 3.x's flat module >> >> > installation oddities are still not accurately supported yet. >> >> > >> >> > I also received a couple of reports from other people claiming that >> >> > their >> >> > projects work and even encountered some people saying that it should >> >> > replace >> >> > the current npm2nix. :) >> >> > >> >> > Obviously, I do not want to claim that my implementation is the >> >> > perfect >> >> > solution as it (for example) is much slower than the vanilla npm2nix, >> >> > and it >> >> > composes the entire set of dependencies in one derivation as opposed >> >> > to >> >> > generating a Nix store path per NPM dependency. (I do this for a very >> >> > good >> >> > reason. For more details, please read my blog post). >> >> > >> >> > Furthermore, I have also spoken to people that suggested completely >> >> > different kinds of approaches in getting NPM supported in a Nix >> >> > environment. >> >> > >> >> > Something that I have not done yet is investigating whether this >> >> > reengineered solution could be a potential replacement for the NPM >> >> > packages >> >> > set in Nixpkgs. >> >> > >> >> > Today, I have been working on an integration pattern, and the good >> >> > news >> >> > is: >> >> > it seems that I was able to generate Nix expressions for almost all >> >> > packages >> >> > that are in pkgs/top-level/node-packages.json. The only exceptions >> >> > were >> >> > the >> >> > node-xmpp-* and bip-* packages, but some of them seem to have broken >> >> > depende
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
+1.. I'll do this in go2nix. -- Kamil 2016-07-05 15:10 GMT+02:00 Rok Garbas : > +1 ... i did just that recently for pypi2nix. but i'll also add a link > to the project home. > > [1] > https://github.com/garbas/pypi2nix/commit/339aee3b149909430ebe7e3e27b8cf158addaef1 > > On Tue, Jul 5, 2016 at 2:47 PM, Graham Christensen > wrote: > > I've found myself confused by multiple projects using the same lang2nix > > name, and big changes in format. One consistent complaint I have is the > top > > of the file usually says: > > > > // Generated by lang2nix > > > > but having more information like a version number and a URL to the > project > > would have saved hours of searching and trying different tools. Something > > like: > > > > // Generated by lang2nix v0.1.0 > > // See more at https://github.com/myuser/lang2nix > > > > would be a really nice usability adjustment. > > > > On Tue, Jul 5, 2016 at 7:36 AM Rok Garbas wrote: > >> > >> we can still keep and old version of npm2nix in nixpkgs for ppl who use > >> it. > >> and also a branch with old code could be created, for people that want > >> pudh bugfixes or develop further (very unlikely). > >> > >> > >> On Tue, Jul 5, 2016 at 11:16 AM, Tomasz Czyż > >> wrote: > >> > Rok, > >> > > >> > what about people who are already using previous solution? Why break > >> > their > >> > workflows? > >> > > >> > 2016-07-05 7:36 GMT+01:00 Rok Garbas : > >> >> > >> >> +1 for just keeping the name npm2nix and bumping up the version. > >> >> > >> >> i'm not using it on any active project, but i'm going to in the near > >> >> future. > >> >> > >> >> > >> >> > >> >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug > >> >> wrote: > >> >> > Hi Sander, > >> >> > > >> >> > sorry for my very late response. I'll make this one brief as I am > >> >> > sadly > >> >> > on > >> >> > my phone. > >> >> > > >> >> > I belong to one of those who tried your new npm2nix and in fact am > >> >> > already > >> >> > using it regularly. I am very much in favor of having your > >> >> > re-engineeering2 > >> >> > branch replacing npm2nix as the de-facto node integration tool. > >> >> > > >> >> > I also definitely want to see the current set of auto-generated > node > >> >> > packages removed from nix. They are almost exclusively *totally* > >> >> > outdated. > >> >> > > >> >> > Thank you a lot for your continued efforts on this. Working with > >> >> > npm/node is > >> >> > annoying but we are better off with your contributions. > >> >> > > >> >> > cheers, > >> >> > Tobi > >> >> > > >> >> > On 22 Jun 2016, at 20:24, Sander van der Burg < > svanderb...@gmail.com> > >> >> > wrote: > >> >> > > >> >> > Hello Nix and Node.js users, > >> >> > > >> >> > I have been absent for a while in this discussion, but as far as I > >> >> > know > >> >> > the > >> >> > state of the NPM packages in Nixpkgs is still quite bad and despite > >> >> > some > >> >> > discussions on the mailing list we have not really come to any > >> >> > consensus > >> >> > yet. > >> >> > > >> >> > As some of you may know, I have my own re-engineered version of > >> >> > npm2nix > >> >> > that > >> >> > lives in a specific branch in my own personal fork > >> >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A > few > >> >> > months > >> >> > ago, I did some major efforts in getting npm 3.x's behaviour > >> >> > supported, > >> >> > which I have documented in this blog post: > >> >> > > >> >> > > >> >> > > http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html > >> >> > > >> >> > I have been using this reengineering2 branch for all my public and > >> >> > some > >> >> > of > >> >> > my private projects since the beginning of this year, and for me it > >> >> > seems to > >> >> > work quite well, despite the fact that some of npm 3.x's flat > module > >> >> > installation oddities are still not accurately supported yet. > >> >> > > >> >> > I also received a couple of reports from other people claiming that > >> >> > their > >> >> > projects work and even encountered some people saying that it > should > >> >> > replace > >> >> > the current npm2nix. :) > >> >> > > >> >> > Obviously, I do not want to claim that my implementation is the > >> >> > perfect > >> >> > solution as it (for example) is much slower than the vanilla > npm2nix, > >> >> > and it > >> >> > composes the entire set of dependencies in one derivation as > opposed > >> >> > to > >> >> > generating a Nix store path per NPM dependency. (I do this for a > very > >> >> > good > >> >> > reason. For more details, please read my blog post). > >> >> > > >> >> > Furthermore, I have also spoken to people that suggested completely > >> >> > different kinds of approaches in getting NPM supported in a Nix > >> >> > environment. > >> >> > > >> >> > Something that I have not done yet is investigating whether this > >> >> > reengineered solution could be a potential replacement for the NPM > >> >> > packages > >> >> > set in Nixpkgs. > >
[Nix-commits] [NixOS/nixpkgs] 392448: rawtherapee: 4.0 -> 4.2
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 392448b5d31f34fa8a84cbc28f22869a28f68f3d https://github.com/NixOS/nixpkgs/commit/392448b5d31f34fa8a84cbc28f22869a28f68f3d Author: Matthias Herrmann Date: 2016-06-25 (Sat, 25 Jun 2016) Changed paths: M pkgs/applications/graphics/rawtherapee/default.nix A pkgs/applications/graphics/rawtherapee/sigc++_fix.patch Log Message: --- rawtherapee: 4.0 -> 4.2 Commit: 07139b8c3f2a1f86c8bfb5b55a5e7edf3a9831b7 https://github.com/NixOS/nixpkgs/commit/07139b8c3f2a1f86c8bfb5b55a5e7edf3a9831b7 Author: Vladimír Čunát Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/applications/graphics/rawtherapee/default.nix A pkgs/applications/graphics/rawtherapee/sigc++_fix.patch Log Message: --- Merge #16488: rawtherapee: 4.0 -> 4.2 Compare: https://github.com/NixOS/nixpkgs/compare/0efd18746abd...07139b8c3f2a___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 26c327: seabios: 1.7.5.2 -> 1.9.2
Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: 26c327c35dbe0c2195ba53928c32bdc0ab9c2ad3 https://github.com/NixOS/nixpkgs/commit/26c327c35dbe0c2195ba53928c32bdc0ab9c2ad3 Author: Joachim Fasting Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/applications/virtualization/seabios/default.nix Log Message: --- seabios: 1.7.5.2 -> 1.9.2 Also fixes the build (cherry picked from commit b148be7ff92955786a3d3596b388f4343ca4f333) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] How to fix corrupt .drv files in nix store?
On 07/05/2016 05:18 PM, Bjørn Forsman wrote: > And, as you saw above, "sudo nix-store --verify --repair > --check-contents" didn't fix it. > > Any suggestions? Why not just remove the *.drv files? (GC them) --Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] How to fix corrupt .drv files in nix store?
Hi all, Short version. This doesn't work (what else can I try?): $ sudo nix-store --verify --repair --check-contents reading the Nix store... checking path existence... checking hashes... path ‘/nix/store/1f0rxsgjcsdxj6jl6qaz555wcaxs164c-xsession.drv’ was modified! expected hash ‘2e527f6df7f00f91be1a5f2a60c811a49e434b218f78096f7d020bf37b39fca3’, got ‘77ac62e2629d8e45f624589c0c8bf99e24b3a722349bf1e79bc186008534e246’ error: cannot repair path ‘/nix/store/1f0rxsgjcsdxj6jl6qaz555wcaxs164c-xsession.drv’ ... Long version: I wanted to see how atomic and safe a NixOS update process really is, so I abused one of my systems by pulling the rootfs disk from it a number of times duing "nixos-rebuild switch" (trying to simulate a power cut-off at the worst possible time). After a few rounds of testing, I ended up with empty, zero sized .drv files, unable to do "nixos-rebuild": $ sudo nixos-rebuild -I nixpkgs=. -Q build building Nix... building the system configuration... error: error parsing derivation ‘/nix/store/h05l5cvr1lvk49vnii320kvpvfv6n1mf-nixos-system-nixos-on-usb-16.03.git.057421e.drv’: expected string ‘Derive([’ $ ls -l /nix/store/h05l5cvr1lvk49vnii320kvpvfv6n1mf-nixos-system-nixos-on-usb-16.03.git.057421e.drv -r--r--r-- 1 root root 0 Jan 1 1970 /nix/store/h05l5cvr1lvk49vnii320kvpvfv6n1mf-nixos-system-nixos-on-usb-16.03.git.057421e.drv And, as you saw above, "sudo nix-store --verify --repair --check-contents" didn't fix it. Any suggestions? When I get this system up again, I'll try with ext4 data=journal mount option and see if that makes it more robust. Best regards, Bjørn Forsman ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to fix corrupt .drv files in nix store?
On 5 July 2016 at 17:21, Vladimír Čunát wrote: > On 07/05/2016 05:18 PM, Bjørn Forsman wrote: >> And, as you saw above, "sudo nix-store --verify --repair >> --check-contents" didn't fix it. >> >> Any suggestions? > > Why not just remove the *.drv files? (GC them) I initially tried to, with "nix-store --delete FILE.drv". But Nix complained that they were "live". Now I used more force, "nix-store --delete --ignore-liveness FILE.drv" and it seems to work. But isn't it a bit "lucky" that the files weren't in use? According to the nix-store man page, --ignore-liveness will be ignored if the path is referred to by other paths. - Bjørn ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to fix corrupt .drv files in nix store?
Hi, On 07/05/2016 05:18 PM, Bjørn Forsman wrote: > Short version. > This doesn't work (what else can I try?): > > $ sudo nix-store --verify --repair --check-contents > reading the Nix store... > checking path existence... > checking hashes... > path ‘/nix/store/1f0rxsgjcsdxj6jl6qaz555wcaxs164c-xsession.drv’ was > modified! expected hash > ‘2e527f6df7f00f91be1a5f2a60c811a49e434b218f78096f7d020bf37b39fca3’, > got ‘77ac62e2629d8e45f624589c0c8bf99e24b3a722349bf1e79bc186008534e246’ > error: cannot repair path > ‘/nix/store/1f0rxsgjcsdxj6jl6qaz555wcaxs164c-xsession.drv’ > ... > > Long version: > I wanted to see how atomic and safe a NixOS update process really is, > so I abused one of my systems by pulling the rootfs disk from it a > number of times duing "nixos-rebuild switch" (trying to simulate a > power cut-off at the worst possible time). This is only safe if you set "sync-before-registering = true" in nix.conf. However, that flag is disabled by default because it causes a significant slowdown during evaluation (since every file written to the store needs to be fsynced separately). > $ sudo nixos-rebuild -I nixpkgs=. -Q build Try passing the "--repair" flag to nixos-rebuild. > When I get this system up again, I'll try with ext4 data=journal mount > option and see if that makes it more robust. Yes, that should help. -- Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs
You all are great! Thank you so much! Graham On Tue, Jul 5, 2016 at 8:14 AM Kamil Chmielewski wrote: > +1.. I'll do this in go2nix. > > -- > Kamil > > 2016-07-05 15:10 GMT+02:00 Rok Garbas : > >> +1 ... i did just that recently for pypi2nix. but i'll also add a link >> to the project home. >> >> [1] >> https://github.com/garbas/pypi2nix/commit/339aee3b149909430ebe7e3e27b8cf158addaef1 >> >> On Tue, Jul 5, 2016 at 2:47 PM, Graham Christensen >> wrote: >> > I've found myself confused by multiple projects using the same lang2nix >> > name, and big changes in format. One consistent complaint I have is the >> top >> > of the file usually says: >> > >> > // Generated by lang2nix >> > >> > but having more information like a version number and a URL to the >> project >> > would have saved hours of searching and trying different tools. >> Something >> > like: >> > >> > // Generated by lang2nix v0.1.0 >> > // See more at https://github.com/myuser/lang2nix >> > >> > would be a really nice usability adjustment. >> > >> > On Tue, Jul 5, 2016 at 7:36 AM Rok Garbas wrote: >> >> >> >> we can still keep and old version of npm2nix in nixpkgs for ppl who use >> >> it. >> >> and also a branch with old code could be created, for people that want >> >> pudh bugfixes or develop further (very unlikely). >> >> >> >> >> >> On Tue, Jul 5, 2016 at 11:16 AM, Tomasz Czyż >> >> wrote: >> >> > Rok, >> >> > >> >> > what about people who are already using previous solution? Why break >> >> > their >> >> > workflows? >> >> > >> >> > 2016-07-05 7:36 GMT+01:00 Rok Garbas : >> >> >> >> >> >> +1 for just keeping the name npm2nix and bumping up the version. >> >> >> >> >> >> i'm not using it on any active project, but i'm going to in the near >> >> >> future. >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jul 4, 2016 at 10:11 PM, Tobias Pflug > > >> >> >> wrote: >> >> >> > Hi Sander, >> >> >> > >> >> >> > sorry for my very late response. I'll make this one brief as I am >> >> >> > sadly >> >> >> > on >> >> >> > my phone. >> >> >> > >> >> >> > I belong to one of those who tried your new npm2nix and in fact >> am >> >> >> > already >> >> >> > using it regularly. I am very much in favor of having your >> >> >> > re-engineeering2 >> >> >> > branch replacing npm2nix as the de-facto node integration tool. >> >> >> > >> >> >> > I also definitely want to see the current set of auto-generated >> node >> >> >> > packages removed from nix. They are almost exclusively *totally* >> >> >> > outdated. >> >> >> > >> >> >> > Thank you a lot for your continued efforts on this. Working with >> >> >> > npm/node is >> >> >> > annoying but we are better off with your contributions. >> >> >> > >> >> >> > cheers, >> >> >> > Tobi >> >> >> > >> >> >> > On 22 Jun 2016, at 20:24, Sander van der Burg < >> svanderb...@gmail.com> >> >> >> > wrote: >> >> >> > >> >> >> > Hello Nix and Node.js users, >> >> >> > >> >> >> > I have been absent for a while in this discussion, but as far as I >> >> >> > know >> >> >> > the >> >> >> > state of the NPM packages in Nixpkgs is still quite bad and >> despite >> >> >> > some >> >> >> > discussions on the mailing list we have not really come to any >> >> >> > consensus >> >> >> > yet. >> >> >> > >> >> >> > As some of you may know, I have my own re-engineered version of >> >> >> > npm2nix >> >> >> > that >> >> >> > lives in a specific branch in my own personal fork >> >> >> > (https://github.com/svanderburg/npm2nix/tree/reengineering2). A >> few >> >> >> > months >> >> >> > ago, I did some major efforts in getting npm 3.x's behaviour >> >> >> > supported, >> >> >> > which I have documented in this blog post: >> >> >> > >> >> >> > >> >> >> > >> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html >> >> >> > >> >> >> > I have been using this reengineering2 branch for all my public and >> >> >> > some >> >> >> > of >> >> >> > my private projects since the beginning of this year, and for me >> it >> >> >> > seems to >> >> >> > work quite well, despite the fact that some of npm 3.x's flat >> module >> >> >> > installation oddities are still not accurately supported yet. >> >> >> > >> >> >> > I also received a couple of reports from other people claiming >> that >> >> >> > their >> >> >> > projects work and even encountered some people saying that it >> should >> >> >> > replace >> >> >> > the current npm2nix. :) >> >> >> > >> >> >> > Obviously, I do not want to claim that my implementation is the >> >> >> > perfect >> >> >> > solution as it (for example) is much slower than the vanilla >> npm2nix, >> >> >> > and it >> >> >> > composes the entire set of dependencies in one derivation as >> opposed >> >> >> > to >> >> >> > generating a Nix store path per NPM dependency. (I do this for a >> very >> >> >> > good >> >> >> > reason. For more details, please read my blog post). >> >> >> > >> >> >> > Furthermore, I have also spoken to people that suggested >> completely >> >> >> > different kinds of appr
[Nix-commits] [NixOS/nixpkgs] 84a105: sysstat: 11.0.7 -> 11.2.5
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 84a1057b417ce209304b7d78e84c89c066239670 https://github.com/NixOS/nixpkgs/commit/84a1057b417ce209304b7d78e84c89c066239670 Author: Kranium Gikos Mendoza Date: 2016-06-30 (Thu, 30 Jun 2016) Changed paths: M pkgs/os-specific/linux/sysstat/default.nix Log Message: --- sysstat: 11.0.7 -> 11.2.5 Commit: 2dd009ec97239fd3d5e34d2c1ed600dbebce2f4e https://github.com/NixOS/nixpkgs/commit/2dd009ec97239fd3d5e34d2c1ed600dbebce2f4e Author: Joachim Fasting Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/os-specific/linux/sysstat/default.nix Log Message: --- Merge pull request #16622 from womfoo/bump/sysstat-11.2.5 sysstat: 11.0.7 -> 11.2.5 Compare: https://github.com/NixOS/nixpkgs/compare/07139b8c3f2a...2dd009ec9723___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-dev] Tips on deploying a Scala Play application
Hi Nix-devs, This is a plain request for assistance / best practices for using Nixos with Java / Scala / Play. Akka with EventSourcing are also a topic of interest. I'm currently trying to get a Scala Play app up and running on my nixOps deployed machines. As I'm very unfamiliar with running Java based apps, I'd like to know if someone has experience on the common pitfalls and tips on keeping the servers healthy (I just caused my laptop's 8 cores to go 100% without being able to stop the server started by the activator call). I've seen some related packages in nixpkgs and have many questions like eg. do I need sbt (which seems to provide typesafe - activator) and a jdk on the production servers or are is a jre sufficient? How do I deploy and run a Java app developed locally? And how do I set-up a local nixos vm for Java development? I'm still investigating and learning a lot myself, so nix-related knowledge is my main concern here (as I need to figure out the rest myself anyway ;-) I'll be happy to share my findings and configuration / setup.. Kind regards, Erik ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Tips on deploying a Scala Play application
Hi, A JRE should be enough for running it, but you need sbt and a JDK for building. I've got a derivation for a Play website at https://github.com/BlocklandGlass/ParseTS-Playground/blob/master/parsets-playground.nix, with the NixOS/NixOps setup at https://github.com/BlocklandGlass/ParseTS-Playground/tree/master/deployment. The gist of it is to run "sbt stage" in the build phase, and to then take "target/universal/stage" as your build output. However, you'll also need to wrap the launcher script to add your JRE and to add gawk (which the launcher script requires). Finally, on any modern system (such as NixOS) you'll also want to disable Play's PID file management, since systemd takes care of that anyway. I didn't in that script, but you'll probably also want to add a testing phase as part of the build. The big drawback with this approach is that SBT downloads all dependencies from the internet on demand, which won't work on a Nix setup with proper isolation (ideally, builds should only have network access if they deterministically produce a given hash). I've been toying with the idea of writing a sbt2nix SBT plugin that generates Nix definitions to build a local maven mirror for the dependencies, but I haven't got around to that (yet). // Teo On 5 July 2016 at 21:52, 4levels <4lev...@gmail.com> wrote: > Hi Nix-devs, > > This is a plain request for assistance / best practices for using Nixos > with Java / Scala / Play. Akka with EventSourcing are also a topic of > interest. > > I'm currently trying to get a Scala Play app up and running on my nixOps > deployed machines. As I'm very unfamiliar with running Java based apps, > I'd like to know if someone has experience on the common pitfalls and tips > on keeping the servers healthy (I just caused my laptop's 8 cores to go > 100% without being able to stop the server started by the activator call). > > I've seen some related packages in nixpkgs and have many questions like > eg. do I need sbt (which seems to provide typesafe - activator) and a jdk > on the production servers or are is a jre sufficient? How do I deploy and > run a Java app developed locally? > And how do I set-up a local nixos vm for Java development? > > I'm still investigating and learning a lot myself, so nix-related > knowledge is my main concern here (as I need to figure out the rest myself > anyway ;-) > > I'll be happy to share my findings and configuration / setup.. > > > Kind regards, > > Erik > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Tips on deploying a Scala Play application
Hi Teo, Thank you for your explanation and quick qualitative response! I'll be looking at your code asap and report back with my experiences ;-) Kind regards, Erik On Tue, Jul 5, 2016, 22:08 Teo Klestrup Röijezon wrote: > Hi, > > A JRE should be enough for running it, but you need sbt and a JDK for > building. I've got a derivation for a Play website at > https://github.com/BlocklandGlass/ParseTS-Playground/blob/master/parsets-playground.nix, > with the NixOS/NixOps setup at > https://github.com/BlocklandGlass/ParseTS-Playground/tree/master/deployment > . > > The gist of it is to run "sbt stage" in the build phase, and to then take > "target/universal/stage" as your build output. However, you'll also need to > wrap the launcher script to add your JRE and to add gawk (which the > launcher script requires). Finally, on any modern system (such as NixOS) > you'll also want to disable Play's PID file management, since systemd takes > care of that anyway. I didn't in that script, but you'll probably also want > to add a testing phase as part of the build. > > The big drawback with this approach is that SBT downloads all dependencies > from the internet on demand, which won't work on a Nix setup with proper > isolation (ideally, builds should only have network access if they > deterministically produce a given hash). > > I've been toying with the idea of writing a sbt2nix SBT plugin that > generates Nix definitions to build a local maven mirror for the > dependencies, but I haven't got around to that (yet). > > // Teo > > On 5 July 2016 at 21:52, 4levels <4lev...@gmail.com> wrote: > >> Hi Nix-devs, >> >> This is a plain request for assistance / best practices for using Nixos >> with Java / Scala / Play. Akka with EventSourcing are also a topic of >> interest. >> >> I'm currently trying to get a Scala Play app up and running on my nixOps >> deployed machines. As I'm very unfamiliar with running Java based apps, >> I'd like to know if someone has experience on the common pitfalls and tips >> on keeping the servers healthy (I just caused my laptop's 8 cores to go >> 100% without being able to stop the server started by the activator call). >> >> I've seen some related packages in nixpkgs and have many questions like >> eg. do I need sbt (which seems to provide typesafe - activator) and a jdk >> on the production servers or are is a jre sufficient? How do I deploy and >> run a Java app developed locally? >> And how do I set-up a local nixos vm for Java development? >> >> I'm still investigating and learning a lot myself, so nix-related >> knowledge is my main concern here (as I need to figure out the rest myself >> anyway ;-) >> >> I'll be happy to share my findings and configuration / setup.. >> >> >> Kind regards, >> >> Erik >> >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> >> > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] a828d7: hackage-packages.nix: update Haskell package set
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: a828d79a8a896c1bfbbea18a00ac542218c06e4f https://github.com/NixOS/nixpkgs/commit/a828d79a8a896c1bfbbea18a00ac542218c06e4f Author: Peter Simons Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/development/haskell-modules/configuration-lts-0.0.nix M pkgs/development/haskell-modules/configuration-lts-0.1.nix M pkgs/development/haskell-modules/configuration-lts-0.2.nix M pkgs/development/haskell-modules/configuration-lts-0.3.nix M pkgs/development/haskell-modules/configuration-lts-0.4.nix M pkgs/development/haskell-modules/configuration-lts-0.5.nix M pkgs/development/haskell-modules/configuration-lts-0.6.nix M pkgs/development/haskell-modules/configuration-lts-0.7.nix M pkgs/development/haskell-modules/configuration-lts-1.0.nix M pkgs/development/haskell-modules/configuration-lts-1.1.nix M pkgs/development/haskell-modules/configuration-lts-1.10.nix M pkgs/development/haskell-modules/configuration-lts-1.11.nix M pkgs/development/haskell-modules/configuration-lts-1.12.nix M pkgs/development/haskell-modules/configuration-lts-1.13.nix M pkgs/development/haskell-modules/configuration-lts-1.14.nix M pkgs/development/haskell-modules/configuration-lts-1.15.nix M pkgs/development/haskell-modules/configuration-lts-1.2.nix M pkgs/development/haskell-modules/configuration-lts-1.4.nix M pkgs/development/haskell-modules/configuration-lts-1.5.nix M pkgs/development/haskell-modules/configuration-lts-1.7.nix M pkgs/development/haskell-modules/configuration-lts-1.8.nix M pkgs/development/haskell-modules/configuration-lts-1.9.nix M pkgs/development/haskell-modules/configuration-lts-2.0.nix M pkgs/development/haskell-modules/configuration-lts-2.1.nix M pkgs/development/haskell-modules/configuration-lts-2.10.nix M pkgs/development/haskell-modules/configuration-lts-2.11.nix M pkgs/development/haskell-modules/configuration-lts-2.12.nix M pkgs/development/haskell-modules/configuration-lts-2.13.nix M pkgs/development/haskell-modules/configuration-lts-2.14.nix M pkgs/development/haskell-modules/configuration-lts-2.15.nix M pkgs/development/haskell-modules/configuration-lts-2.16.nix M pkgs/development/haskell-modules/configuration-lts-2.17.nix M pkgs/development/haskell-modules/configuration-lts-2.18.nix M pkgs/development/haskell-modules/configuration-lts-2.19.nix M pkgs/development/haskell-modules/configuration-lts-2.2.nix M pkgs/development/haskell-modules/configuration-lts-2.20.nix M pkgs/development/haskell-modules/configuration-lts-2.21.nix M pkgs/development/haskell-modules/configuration-lts-2.22.nix M pkgs/development/haskell-modules/configuration-lts-2.3.nix M pkgs/development/haskell-modules/configuration-lts-2.4.nix M pkgs/development/haskell-modules/configuration-lts-2.5.nix M pkgs/development/haskell-modules/configuration-lts-2.6.nix M pkgs/development/haskell-modules/configuration-lts-2.7.nix M pkgs/development/haskell-modules/configuration-lts-2.8.nix M pkgs/development/haskell-modules/configuration-lts-2.9.nix M pkgs/development/haskell-modules/configuration-lts-3.0.nix M pkgs/development/haskell-modules/configuration-lts-3.1.nix M pkgs/development/haskell-modules/configuration-lts-3.10.nix M pkgs/development/haskell-modules/configuration-lts-3.11.nix M pkgs/development/haskell-modules/configuration-lts-3.12.nix M pkgs/development/haskell-modules/configuration-lts-3.13.nix M pkgs/development/haskell-modules/configuration-lts-3.14.nix M pkgs/development/haskell-modules/configuration-lts-3.15.nix M pkgs/development/haskell-modules/configuration-lts-3.16.nix M pkgs/development/haskell-modules/configuration-lts-3.17.nix M pkgs/development/haskell-modules/configuration-lts-3.18.nix M pkgs/development/haskell-modules/configuration-lts-3.19.nix M pkgs/development/haskell-modules/configuration-lts-3.2.nix M pkgs/development/haskell-modules/configuration-lts-3.20.nix M pkgs/development/haskell-modules/configuration-lts-3.21.nix M pkgs/development/haskell-modules/configuration-lts-3.22.nix M pkgs/development/haskell-modules/configuration-lts-3.3.nix M pkgs/development/haskell-modules/configuration-lts-3.4.nix M pkgs/development/haskell-modules/configuration-lts-3.5.nix M pkgs/development/haskell-modules/configuration-lts-3.6.nix M pkgs/development/haskell-modules/configuration-lts-3.7.nix M pkgs/development/haskell-modules/configuration-lts-3.8.nix M pkgs/development/haskell-modules/configuration-lts-3.9.nix M pkgs/development/haskell-modules/configuration-lts-4.0.nix M pkgs/development/haskell-modules/configuration-lts-4.1.nix M pkgs/development/haskell-modules/configuration-lts-4.2.nix M pkgs/development/haskell-modules/configuration-lts-5.0
[Nix-commits] [NixOS/nixpkgs] beec2b: diff-so-fancy: 0.9.3 -> 0.10.0
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: beec2ba1276ef2d4db9525131c7ad6f8b4daecdd https://github.com/NixOS/nixpkgs/commit/beec2ba1276ef2d4db9525131c7ad6f8b4daecdd Author: mimadrid Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/applications/version-management/git-and-tools/diff-so-fancy/default.nix Log Message: --- diff-so-fancy: 0.9.3 -> 0.10.0 Commit: 071faa71e7ae4d8a4a7996f1c05d0688a5efddef https://github.com/NixOS/nixpkgs/commit/071faa71e7ae4d8a4a7996f1c05d0688a5efddef Author: Tuomas Tynkkynen Date: 2016-07-06 (Wed, 06 Jul 2016) Changed paths: M pkgs/applications/version-management/git-and-tools/diff-so-fancy/default.nix Log Message: --- Merge pull request #16736 from mimadrid/update/diff-so-fancy-0.10.0 diff-so-fancy: 0.9.3 -> 0.10.0 Compare: https://github.com/NixOS/nixpkgs/compare/6a6b8fa36fa2...071faa71e7ae___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] eaeb69: cherrytree: 0.35.9 -> 0.37.1
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: eaeb69c46e83e6bd6f72e425eccf5a982ad29631 https://github.com/NixOS/nixpkgs/commit/eaeb69c46e83e6bd6f72e425eccf5a982ad29631 Author: mimadrid Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M pkgs/applications/misc/cherrytree/default.nix M pkgs/applications/misc/cherrytree/subprocess.patch Log Message: --- cherrytree: 0.35.9 -> 0.37.1 Commit: 31daa9b0fb3ec93a7a6d90725f0ce425d9ea722e https://github.com/NixOS/nixpkgs/commit/31daa9b0fb3ec93a7a6d90725f0ce425d9ea722e Author: Tuomas Tynkkynen Date: 2016-07-06 (Wed, 06 Jul 2016) Changed paths: M pkgs/applications/misc/cherrytree/default.nix M pkgs/applications/misc/cherrytree/subprocess.patch Log Message: --- Merge pull request #16737 from mimadrid/update/cherrytree-0.37.1 cherrytree: 0.35.9 -> 0.37.1 Compare: https://github.com/NixOS/nixpkgs/compare/071faa71e7ae...31daa9b0fb3e___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 881ba7: wxsqliteplus: init at 0.3.6
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 881ba7309cad8e29839069d48183d12d07ef5e3a https://github.com/NixOS/nixpkgs/commit/881ba7309cad8e29839069d48183d12d07ef5e3a Author: Rahul Gopinath Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: A pkgs/development/libraries/wxsqliteplus/default.nix M pkgs/top-level/all-packages.nix Log Message: --- wxsqliteplus: init at 0.3.6 Commit: 30e08502facb200f4b5442228b6df1217896cc4f https://github.com/NixOS/nixpkgs/commit/30e08502facb200f4b5442228b6df1217896cc4f Author: Tuomas Tynkkynen Date: 2016-07-06 (Wed, 06 Jul 2016) Changed paths: A pkgs/development/libraries/wxsqliteplus/default.nix M pkgs/top-level/all-packages.nix Log Message: --- Merge pull request #16734 from vrthra/wxsqlite3 wxsqliteplus: init at 0.3.6 Compare: https://github.com/NixOS/nixpkgs/compare/31daa9b0fb3e...30e08502facb___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 2bd785: guake: add gconf to propagatedUserEnvPkgs
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 2bd7855c46386776a9f9f5b3c1efea47bf44ee14 https://github.com/NixOS/nixpkgs/commit/2bd7855c46386776a9f9f5b3c1efea47bf44ee14 Author: Alexey Shmalko Date: 2016-07-03 (Sun, 03 Jul 2016) Changed paths: M pkgs/applications/misc/guake/default.nix Log Message: --- guake: add gconf to propagatedUserEnvPkgs This fixes #15978. Commit: 570da9662bb451b91df4d464f560c18f127c5fac https://github.com/NixOS/nixpkgs/commit/570da9662bb451b91df4d464f560c18f127c5fac Author: Nikolay Amiantov Date: 2016-07-06 (Wed, 06 Jul 2016) Changed paths: M pkgs/applications/misc/guake/default.nix Log Message: --- Merge pull request #16670 from rasendubi/guake guake: add gconf to propagatedUserEnvPkgs Compare: https://github.com/NixOS/nixpkgs/compare/30e08502facb...570da9662bb4___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] de1b4e: python-2.7: Don't use ldconfig and speed up uuid l...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: de1b4e71c1c8be30ad4ebc2ec6005928ba6cf280 https://github.com/NixOS/nixpkgs/commit/de1b4e71c1c8be30ad4ebc2ec6005928ba6cf280 Author: Eelco Dolstra Date: 2016-07-01 (Fri, 01 Jul 2016) Changed paths: M pkgs/development/interpreters/python/2.7/default.nix A pkgs/development/interpreters/python/2.7/no-ldconfig.patch Log Message: --- python-2.7: Don't use ldconfig and speed up uuid load Commit: 2cf8cb7f46b08eb0a547243742711b3e88b63d12 https://github.com/NixOS/nixpkgs/commit/2cf8cb7f46b08eb0a547243742711b3e88b63d12 Author: Tuomas Tynkkynen Date: 2016-07-05 (Tue, 05 Jul 2016) Changed paths: M doc/languages-frameworks/python.md M lib/maintainers.nix M nixos/doc/manual/installation/installing.xml M nixos/modules/config/update-users-groups.pl M nixos/modules/installer/cd-dvd/sd-image-armv7l-multiplatform.nix M nixos/modules/installer/cd-dvd/sd-image-raspberrypi.nix M nixos/modules/misc/ids.nix M nixos/modules/module-list.nix M nixos/modules/profiles/installation-device.nix A nixos/modules/programs/spacefm.nix A nixos/modules/services/editors/emacs.nix M nixos/modules/services/hardware/tlp.nix M nixos/modules/services/search/elasticsearch.nix M nixos/modules/services/web-servers/apache-httpd/default.nix M nixos/modules/system/activation/switch-to-configuration.pl M nixos/modules/system/boot/systemd.nix M nixos/modules/virtualisation/libvirtd.nix A nixos/tests/emacs-daemon.nix M pkgs/applications/editors/eclipse/default.nix M pkgs/applications/editors/edbrowse/default.nix A pkgs/applications/editors/edit/default.nix M pkgs/applications/editors/emacs-modes/melpa-generated.nix M pkgs/applications/editors/emacs-modes/melpa-packages.nix M pkgs/applications/editors/emacs-modes/melpa-stable-generated.nix M pkgs/applications/editors/nano/default.nix A pkgs/applications/editors/wily/default.nix A pkgs/applications/graphics/zgv/default.nix A pkgs/applications/graphics/zgv/switch.patch M pkgs/applications/misc/bleachbit/default.nix M pkgs/applications/misc/dbvisualizer/default.nix M pkgs/applications/misc/lyx/default.nix M pkgs/applications/misc/netsurf/browser/default.nix M pkgs/applications/misc/netsurf/libnsfb/default.nix M pkgs/applications/misc/spacefm/default.nix A pkgs/applications/misc/tnef/default.nix A pkgs/applications/misc/tnef/tnef/default.nix A pkgs/applications/misc/vp/default.nix A pkgs/applications/misc/xsw/default.nix A pkgs/applications/misc/xsw/parse.patch M pkgs/applications/misc/xterm/default.nix M pkgs/applications/networking/browsers/firefox-bin/sources.nix M pkgs/applications/networking/cluster/nomad/default.nix A pkgs/applications/networking/errbot/default.nix A pkgs/applications/networking/errbot/fix-dnspython.patch M pkgs/applications/networking/instant-messengers/utox/default.nix M pkgs/applications/networking/mailreaders/neomutt/default.nix M pkgs/applications/networking/mailreaders/thunderbird-bin/sources.nix M pkgs/applications/networking/mailreaders/thunderbird/default.nix M pkgs/applications/networking/p2p/gnunet/default.nix A pkgs/applications/networking/p2p/transgui/default.nix M pkgs/applications/office/wpsoffice/default.nix A pkgs/applications/science/math/LiE/default.nix M pkgs/applications/video/bomi/default.nix M pkgs/applications/window-managers/tabbed/default.nix M pkgs/build-support/fetchgit/nix-prefetch-git M pkgs/data/fonts/iosevka/default.nix A pkgs/data/fonts/norwester/default.nix A pkgs/data/fonts/orbitron/default.nix M pkgs/data/fonts/unifont/default.nix M pkgs/data/fonts/unifont_upper/default.nix M pkgs/data/misc/geolite-legacy/default.nix M pkgs/desktops/enlightenment/enlightenment.nix M pkgs/desktops/gnome-3/3.18/misc/gpaste/default.nix M pkgs/desktops/gnome-3/3.20/misc/gpaste/default.nix M pkgs/desktops/kde-5/applications-16.04/default.nix M pkgs/development/compilers/boo/default.nix M pkgs/development/compilers/fstar/default.nix A pkgs/development/compilers/mono/4.0.nix A pkgs/development/compilers/mono/4.4.nix R pkgs/development/compilers/mono/default.nix A pkgs/development/compilers/mono/generic.nix A pkgs/development/em-modules/generic/default.nix M pkgs/development/haskell-modules/configuration-common.nix M pkgs/development/haskell-modules/configuration-ghc-7.10.x.nix M pkgs/development/haskell-modules/configuration-hackage2nix.yaml M pkgs/development/haskell-modules/configuration-lts-0.0.nix M pkgs/development/haskell-modules/configuration-lts-0.1.nix M pkgs/development/haskell-modules/configuration-lts-0.2.nix M pkgs/development/haskell-modules/configuration-lts-0.3.nix M pkgs/development/haskell-modules/configuration
[Nix-commits] [NixOS/nixpkgs] 0546a4: guake: add gconf to propagatedUserEnvPkgs
Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: 0546a4aa57f657a50e726c2d3bd824be7084878d https://github.com/NixOS/nixpkgs/commit/0546a4aa57f657a50e726c2d3bd824be7084878d Author: Alexey Shmalko Date: 2016-07-06 (Wed, 06 Jul 2016) Changed paths: M pkgs/applications/misc/guake/default.nix Log Message: --- guake: add gconf to propagatedUserEnvPkgs This fixes #15978. (cherry picked from commit 2bd7855c46386776a9f9f5b3c1efea47bf44ee14) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Tips on deploying a Scala Play application
Hi Teo, I've come quite far in setting up things, but I keep running into building errors. It has everything to do with me removing all references to parsets and postgres and renaming things here and there, trying to merge them with the current deploy setup. Do I understand correctly that parsets is a library to store data, using postgres in the background? I'd like to start using Event Sourcing with Scala / Akka so I don't need a datastore like parsets, correct? I'm very unsure about this as I literally started today with learning Scala / Play. I got my toes wet with Java before but that's really it. Something else I found interesting as I'm quite an Nginx fan and have nginx running with proxies already: Nginx has capabilities to deal with Java in different ways, as proxy or tied with eg Clojure for even faster results.. The journey continues ;-) Kind regards, Erik On Tue, Jul 5, 2016 at 10:23 PM 4levels <4lev...@gmail.com> wrote: > Hi Teo, > > Thank you for your explanation and quick qualitative response! > > I'll be looking at your code asap and report back with my experiences ;-) > > Kind regards, > > Erik > > On Tue, Jul 5, 2016, 22:08 Teo Klestrup Röijezon wrote: > >> Hi, >> >> A JRE should be enough for running it, but you need sbt and a JDK for >> building. I've got a derivation for a Play website at >> https://github.com/BlocklandGlass/ParseTS-Playground/blob/master/parsets-playground.nix, >> with the NixOS/NixOps setup at >> https://github.com/BlocklandGlass/ParseTS-Playground/tree/master/deployment >> . >> >> The gist of it is to run "sbt stage" in the build phase, and to then take >> "target/universal/stage" as your build output. However, you'll also need to >> wrap the launcher script to add your JRE and to add gawk (which the >> launcher script requires). Finally, on any modern system (such as NixOS) >> you'll also want to disable Play's PID file management, since systemd takes >> care of that anyway. I didn't in that script, but you'll probably also want >> to add a testing phase as part of the build. >> >> The big drawback with this approach is that SBT downloads all >> dependencies from the internet on demand, which won't work on a Nix setup >> with proper isolation (ideally, builds should only have network access if >> they deterministically produce a given hash). >> >> I've been toying with the idea of writing a sbt2nix SBT plugin that >> generates Nix definitions to build a local maven mirror for the >> dependencies, but I haven't got around to that (yet). >> >> // Teo >> >> On 5 July 2016 at 21:52, 4levels <4lev...@gmail.com> wrote: >> >>> Hi Nix-devs, >>> >>> This is a plain request for assistance / best practices for using Nixos >>> with Java / Scala / Play. Akka with EventSourcing are also a topic of >>> interest. >>> >>> I'm currently trying to get a Scala Play app up and running on my nixOps >>> deployed machines. As I'm very unfamiliar with running Java based apps, >>> I'd like to know if someone has experience on the common pitfalls and tips >>> on keeping the servers healthy (I just caused my laptop's 8 cores to go >>> 100% without being able to stop the server started by the activator call). >>> >>> I've seen some related packages in nixpkgs and have many questions like >>> eg. do I need sbt (which seems to provide typesafe - activator) and a jdk >>> on the production servers or are is a jre sufficient? How do I deploy and >>> run a Java app developed locally? >>> And how do I set-up a local nixos vm for Java development? >>> >>> I'm still investigating and learning a lot myself, so nix-related >>> knowledge is my main concern here (as I need to figure out the rest myself >>> anyway ;-) >>> >>> I'll be happy to share my findings and configuration / setup.. >>> >>> >>> Kind regards, >>> >>> Erik >>> >>> ___ >>> nix-dev mailing list >>> nix-dev@lists.science.uu.nl >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>> >>> >> ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Tips on deploying a Scala Play application
HI Erik, That's pretty much entirely wrong. :P ParseTS is just a linter script for the game scripting language TorqueScript. ParseTS-Playground was a pastebin that would run the submitted code through the linter. For example, see https://parsets-playground.nullable.se/snippets/13. The datastore used was PostgreSQL. Anyway, apart from the ParseTS stuff, at least those scripts should be pretty much straightforward to copy to any Play application, though for the config stuff to work you'll need to add the line 'include "local.conf"' to your conf/application.conf. Any chance you could post your current setup and the errors you get? // Teo On 6 July 2016 at 04:31, 4levels <4lev...@gmail.com> wrote: > Hi Teo, > > I've come quite far in setting up things, but I keep running into building > errors. > It has everything to do with me removing all references to parsets and > postgres and renaming things here and there, trying to merge them with the > current deploy setup. > > Do I understand correctly that parsets is a library to store data, using > postgres in the background? I'd like to start using Event Sourcing with > Scala / Akka so I don't need a datastore like parsets, correct? I'm very > unsure about this as I literally started today with learning Scala / Play. > I got my toes wet with Java before but that's really it. > > Something else I found interesting as I'm quite an Nginx fan and have > nginx running with proxies already: Nginx has capabilities to deal with > Java in different ways, as proxy or tied with eg Clojure for even faster > results.. > > The journey continues ;-) > > > Kind regards, > > Erik > > On Tue, Jul 5, 2016 at 10:23 PM 4levels <4lev...@gmail.com> wrote: > >> Hi Teo, >> >> Thank you for your explanation and quick qualitative response! >> >> I'll be looking at your code asap and report back with my experiences ;-) >> >> Kind regards, >> >> Erik >> >> On Tue, Jul 5, 2016, 22:08 Teo Klestrup Röijezon wrote: >> >>> Hi, >>> >>> A JRE should be enough for running it, but you need sbt and a JDK for >>> building. I've got a derivation for a Play website at >>> https://github.com/BlocklandGlass/ParseTS-Playground/blob/master/parsets-playground.nix, >>> with the NixOS/NixOps setup at >>> https://github.com/BlocklandGlass/ParseTS-Playground/tree/master/deployment >>> . >>> >>> The gist of it is to run "sbt stage" in the build phase, and to then >>> take "target/universal/stage" as your build output. However, you'll also >>> need to wrap the launcher script to add your JRE and to add gawk (which the >>> launcher script requires). Finally, on any modern system (such as NixOS) >>> you'll also want to disable Play's PID file management, since systemd takes >>> care of that anyway. I didn't in that script, but you'll probably also want >>> to add a testing phase as part of the build. >>> >>> The big drawback with this approach is that SBT downloads all >>> dependencies from the internet on demand, which won't work on a Nix setup >>> with proper isolation (ideally, builds should only have network access if >>> they deterministically produce a given hash). >>> >>> I've been toying with the idea of writing a sbt2nix SBT plugin that >>> generates Nix definitions to build a local maven mirror for the >>> dependencies, but I haven't got around to that (yet). >>> >>> // Teo >>> >>> On 5 July 2016 at 21:52, 4levels <4lev...@gmail.com> wrote: >>> Hi Nix-devs, This is a plain request for assistance / best practices for using Nixos with Java / Scala / Play. Akka with EventSourcing are also a topic of interest. I'm currently trying to get a Scala Play app up and running on my nixOps deployed machines. As I'm very unfamiliar with running Java based apps, I'd like to know if someone has experience on the common pitfalls and tips on keeping the servers healthy (I just caused my laptop's 8 cores to go 100% without being able to stop the server started by the activator call). I've seen some related packages in nixpkgs and have many questions like eg. do I need sbt (which seems to provide typesafe - activator) and a jdk on the production servers or are is a jre sufficient? How do I deploy and run a Java app developed locally? And how do I set-up a local nixos vm for Java development? I'm still investigating and learning a lot myself, so nix-related knowledge is my main concern here (as I need to figure out the rest myself anyway ;-) I'll be happy to share my findings and configuration / setup.. Kind regards, Erik ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev >>> ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
