Hi,
Our current stable is 3.14, our latest is 3.15, and on kernel.org the
latest longterm is 3.18.13 and stable is 4.0.2.
Is there a reason beyond manpower why we're not going with 3.18 for the
stable release and latest isn't 4.0?
Wout.
___
nix-dev
Our stable is 3.18 (latest longterm):
https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix#L9422
On Thu, May 7, 2015 at 8:32 AM, Wout Mertens wout.mert...@gmail.com wrote:
Hi,
Our current stable is 3.14, our latest is 3.15, and on kernel.org the
latest longterm is
Linux 4.0 would be great. I want to use the lazyatime feature! (among
other things of course)
On 7/05/2015 4:32 PM, Wout Mertens wrote:
Hi,
Our current stable is 3.14, our latest is 3.15, and on kernel.org
http://kernel.org the latest longterm is 3.18.13 and stable is 4.0.2.
Is there a
Hi Tobias,
I would like to use ghc 7.8.4 and cabal-install 1.20.x.
what Nixpkgs branch are you on? The current 'master' branch (a.k.a.
'nixos-unstable' channel) has cabal-install 1.22.x, and it builds fine:
$ nix-build nixpkgs -A haskell-ng.packages.ghc784.cabal-install
Hi,
I've been facing some problems with haskell-ng and cabal-install.
I would like to use ghc 7.8.4 and cabal-install 1.20.x. I try to
install cabal-install as follows:
$ nix-env -f ~/nixpkgs -i -A haskell-ng.packages.ghc784.cabal-install
The build fails because of missing dependencies :
I'm working on getting Nix onto our clusters to augment our standard CentOS 6
stack as a shared NFS mounted store. I've reset the top level /nix directory
to be on one of our shared storage systems (config.nix.storeDir and
config.nix.stateDir).
For the most part this has worked pretty well.
On 07/05/15 14:29, Daniel Peebles wrote:
I thought that at some point there was an effort to autogenerate
(dynamically, so not nix codegen) the list from readDir.
I made an abortive attempt at reducing the size of all-packages.nix a while
back:
Argh I must have been looking at an older commit. Sorry for the noise :)
Roger: 4.0 is linuxPackages_latest
On Thu, May 7, 2015 at 10:04 AM Domen Kožar do...@dev.si wrote:
Our stable is 3.18 (latest longterm):
https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix#L9422
I thought that at some point there was an effort to autogenerate (dynamically,
so not nix codegen) the list from readDir. If not, it seems like the majority
of packages could work that way, along with room to override where necessary.
On May 7, 2015, at 08:10, Wout Mertens
all-packages.nix is gigantic, and because it's so large, github search
doesn't index it.
Would it be a good idea to move the attribute definitions into files per
package section?
So everything would still be in the pkgs attrset, only the definitions
would be split across multiple files.
the problem with readDir is slowness due to reading thousands of files...
nix codegen would fix that :)
On Thu, May 7, 2015 at 2:29 PM Daniel Peebles pumpkin...@gmail.com wrote:
I thought that at some point there was an effort to autogenerate
(dynamically, so not nix codegen) the list from
No need to read all the files, right? You import them lazily based on what
readDir returns.
On May 7, 2015, at 08:35, Wout Mertens wout.mert...@gmail.com wrote:
the problem with readDir is slowness due to reading thousands of files... nix
codegen would fix that :)
On Thu, May 7,
On 07.05.2015 21:22, Peter Simons wrote:
nix-build nixpkgs -A haskell-ng.packages.ghc784.cabal-install
What I need is cabal 1.20.x because I would like to use ghc-mod which
is not compatible with 1.22.x because of a file format change in cabal
leading to ghc-mod being unable to parse.
So how
yes indeed that looks nice, it would eliminate some 3855 lines of 9351
non-empty lines... With more probably a small refactor away.
On Thu, May 7, 2015 at 3:08 PM Daniel Peebles pumpkin...@gmail.com wrote:
What went wrong? I think that's what I was thinking of
On May 7, 2015, at 08:50,
Hi,
On 07/05/15 15:02, Daniel Peebles wrote:
No need to read all the files, right? You import them lazily based on what
readDir returns.
Yes, but you still need to traverse the directory tree, which itself takes a
long time on non-SSD disks.
--
Eelco Dolstra | LogicBlox, Inc. |
well, that traversal could be automated at commit time? It's just an
optimization...
On Thu, May 7, 2015 at 3:24 PM Eelco Dolstra eelco.dols...@logicblox.com
wrote:
Hi,
On 07/05/15 15:02, Daniel Peebles wrote:
No need to read all the files, right? You import them lazily based on
what
What went wrong? I think that's what I was thinking of
On May 7, 2015, at 08:50, Eelco Dolstra eelco.dols...@logicblox.com wrote:
On 07/05/15 14:29, Daniel Peebles wrote:
I thought that at some point there was an effort to autogenerate
(dynamically, so not nix codegen) the list from
17 matches
Mail list logo
