Re: [Nix-dev] haskell: overriding mtl/any builtin
Hi Mateusz, Notably if I specify mtl = mtl_2_2_1; then it complains that it needs transformers == 0.4 but there seems to be no clues in nixpkgs as to how to achieve this. Currently mtl = 2.2.1 for HEAD but I know it should work with 7.8.3 transformers is a core library in GHC 7.8.3. We cannot override that package, because it's shipped with the compiler and other core libraries are linked against that version. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] NixOS on MacBook: how to enable sudden motion sensor?
Hello, could you tell me please how to make sure in NixOS on a MacBook that the sudden motion sensor and the relevant disk protection are enabled? It seems that i need applesmc module for this, but i couldn't find how to install it in NixOS. Thanks, Alexey. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] automatically mount vboxsf
Hi Nicolas,
On Saturday 06 September 2014 20:25:43 Nicolas Pierron wrote:
Have you tried listing it as an entry of the fileSystem of the vm, such as:
fileSystems./host_home = {
fsType = vboxsf;
device = hostHome;
};
Thanks for the hint. I got it working with the following config:
fileSystems./host_home = {
fsType = vboxsf;
device = hostHome;
options = ro; # If you want it read-only
noCheck = true; # fsck would be pointless.
};
Additionally, I had to add the vbox guest additions into the scope:
system.fsPackages = [
config.boot.kernelPackages.virtualboxGuestAdditions
];
Best,
Andreas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] automatically mount vboxsf
Additionally, I had to add the vbox guest additions into the scope: system.fsPackages = [ config.boot.kernelPackages.virtualboxGuestAdditions ]; I suggest you to use services.virtualbox.enable = true. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] DevOps sprint at gocept/FlyingCircus
i think i'll be only able to come for fri/sat maybe i can come for later on thu but not 100%. -- Rok Garbas - http://www.garbas.si ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] PAGER=less -R
topgit has an issue with that:
https://github.com/greenrd/topgit/blob/master/tg.sh#L462
TG_PAGER gets defined some lines above ${FOO-xxx) means but word if FOO
isn't defined (thanks to Lethalman, I failed finding that in the man
page.
Is the best way to fix this by dropping quotes? Does anybody know how
PAGER ist most commonly used?
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] automatically mount vboxsf
Dear Luca, On Monday 08 September 2014 10:57:31 Luca Bruno wrote: system.fsPackages = [ config.boot.kernelPackages.virtualboxGuestAdditions ]; I suggest you to use services.virtualbox.enable = true. Doesn't nixops set this by default when the deployment is virtualbox? At least, I haven't manually set this service to enabled before, but the guest additions were installed anyway. For instance, I was able to manually mount the vboxsf volume once the machine had booted. I had the feeling, that the package just wasn't there, yet when the system tried to automatically mount the vboxsf volume at boot-time. So, adding it to fsPackages should somehow make sure that the package is available at boot-time. Or am I wrong here? Best, Andreas ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Fwd: GHC pointed at the wrong package
Seems I forgot to send this email to the list ... -- Benno -- Forwarded message -- From: Benno Fünfstück benno.fuenfstu...@gmail.com Date: 2014-08-24 20:00 GMT+02:00 Subject: Re: [Nix-dev] GHC pointed at the wrong package To: Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk Yes, GHC bug #4012 [https://ghc.haskell.org/trac/ghc/ticket/4012] is about this issue. You can use `nix-store --repair-path store path` to re-download a specific store path from hydra. -- Benno 2014-08-23 15:15 GMT+02:00 Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk: On 08/23/2014 01:29 PM, Peter Simons wrote: Hi Mateusz, There are problems in package regex-tdfa-1.2.0: dependency parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424 doesn't exist There are problems in package regex-tdfa-rc-1.1.8.3: dependency parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424 doesn't exist the process that generates those IDs in GHC is non-deterministic. Two people can compile the same library with the same version of GHC on the same type of machine yet end up with two distinct IDs. It doesn't happen often, but it does happen. I'd recommend running $ nix-store --delete /nix/store/*-haskell-parsec-ghc7.8.3-3.1.5-shared on all your machines. Then the next build will download these packages from Hydra, and you'll have a consistent build again. Note that you may have to remove packages from your active profiles to make that deletion process succeed. I hope this helps, Peter It's very unfortunate to hear about the package ID stuff. Is there a bug open? I managed to resolve the issue by getting rid of my parsec package as you advised. Unluckily it was depended on all the way from xmonad-extras. In the end I was able to remove -extras from my system as my config only needs -contrib, reboot, garbage collect and it works. I fear if this ever hits something xmonad directly depends on because I'll have to get rid of my WM to fix the issue… Perhaps a --force-overwrite flag should be created in nix-store as long as two hashes match? Thanks for help! -- Mateusz K. ___ 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] GHC pointed at the wrong package
On 09/07/2014 10:10 PM, Rickard Nilsson wrote:
On 08/23/2014 03:15 PM, Mateusz Kowalczyk wrote:
On 08/23/2014 01:29 PM, Peter Simons wrote:
Hi Mateusz,
There are problems in package regex-tdfa-1.2.0:
dependency parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424 doesn't
exist
There are problems in package regex-tdfa-rc-1.1.8.3:
dependency parsec-3.1.5-ca5ed8f175b69e1a085cfeaf3b95f424 doesn't
exist
the process that generates those IDs in GHC is non-deterministic. Two
people can compile the same library with the same version of GHC on the
same type of machine yet end up with two distinct IDs. It doesn't happen
often, but it does happen.
I'd recommend running
$ nix-store --delete /nix/store/*-haskell-parsec-ghc7.8.3-3.1.5-shared
on all your machines. Then the next build will download these packages
from Hydra, and you'll have a consistent build again. Note that you may
have to remove packages from your active profiles to make that deletion
process succeed.
I hope this helps,
Peter
It's very unfortunate to hear about the package ID stuff. Is there a bug
open?
There is https://ghc.haskell.org/trac/ghc/ticket/4012
There has actually been a patch to that bug about a day before I asked
so the situation for the simple case may improve.
Actually, since we started building Haskell packages in parallel
(https://github.com/NixOS/nixpkgs/commit/817c0e41443a5176baf6dd9b422878fdccecd266),
this problem might have got more common (but I have no real evidence for
that).
You can reproduce this by building the haskell http-client package with
--cores 4 (non-parallel makes the problem go away). Each build (with
the exact same dependencies, and hence exact same nix hash) produces a
package with different package-id (in package-conf.d). It is not only
the package-id that differs, but the ABI differs, which could make
linking fail. Look at this:
$ nm -g
pkg-1/lib/ghc-7.8.3/http-client-0.3.8.1/libHShttp-client-0.3.8.1.a hc-1-nm
$ nm -g
pkg-2/lib/ghc-7.8.3/http-client-0.3.8.1/libHShttp-client-0.3.8.1.a hc-2-nm
$ diff hc-1-nm hc-2-nm | tail -n 10
8775,8776c8775,8776
U
httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfy8a_closure
D
httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfy9a1_closure
---
U
httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfxPa_closure
D
httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfxQa1_closure
8780c8780
D
httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfy8a_closure
---
D
httpzmclientzm0zi3zi8zi1_NetworkziHTTPziClientziTypes_zdLrfxPa_closure
As pointed out on the Trac ticket, non-determinism in presence of
parallelism is a known problem, so there's your evidence.
I really don't know how this could be worked around in Nix. Of course,
the problem is not very common, since you would have to build one
package locally, then fetch a package built somewhere else that depends
on your local package, and finally build a third package that depends on
that fetched package. But in a build cluster things like that certainly
do happen.
I think making Haskell packages only build on a single core again would
be a start.
For me that problem is common: my Hydra builds Haskell packages from
nixpkgs HEAD and uses official Hydra and peti's Hydra as binary caches.
Further, my own-use computer uses official Hydra, my Hydra and peti's
Hydra as caches + I often build packages locally when packaging stuff
for nixpkgs master or when I need some patches from there. It's fairly
easy to see that it's easy for the problem to come up here. In fact my
Hydra right now suffers from the same thing and weirdly it's actually,
again, something to do with pandoc/parsec packages.
Right from my Hydra:
package pandoc-1.13.1 is broken due to missing package
pandoc-types-1.12.4.1-917a8ba6e10664f3ab958ef027071e98
My options when this happens is to either:
1. manually drop in and try to remove broken packages
2. garbage collect everything
3. wait for a big rebuild which will cause these to be rebuild/refetched
Today 3. is actually happening so hopefully it comes out without any
bogus errors but ideally this should never happen. If building each
package on single core makes it more likely to produce non-broken
packages then I think it should be the default until it can be patched
upstream.
/ Rickard
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell: overriding mtl/any builtin
On 09/08/2014 07:36 AM, Peter Simons wrote: Hi Mateusz, Notably if I specify mtl = mtl_2_2_1; then it complains that it needs transformers == 0.4 but there seems to be no clues in nixpkgs as to how to achieve this. Currently mtl = 2.2.1 for HEAD but I know it should work with 7.8.3 transformers is a core library in GHC 7.8.3. We cannot override that package, because it's shipped with the compiler and other core libraries are linked against that version. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev Right, yes, it is, yet somehow there are packages around on Hackage which do depend on mtl-2.2.1 and by proxy on transformers-0.4, which do compile with GHC 7.8.3. This must be somehow achieved one way or another and currently with nix(pkgs) we can not accommodate for those packages. Recent release of JuicyPixels is a good example, we had to ask upstream to relax the bound a bit so that we could use it but just relaxing the bound is not always possible. I expect more and more packages to start using the new mtl over time. I found myself yesterday in need of hacking a bit on a project which happened to actually need mtl-2.2.1 and I just could not do it with 7.8.3 whereas that's exactly what the original developer was using. My hack there was to comment out the 2.2.1 imports and manually stick undefined everywhere but that's obviously not acceptable for any actual work. The only other way I could think of would be to use the (outdated) GHC ‘HEAD’ version from nixpkgs which would not help me because it was to try and chase down a bug appearing with 7.8.3. -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] PAGER=less -R
On 09/08/2014 11:56 AM, Marc Weber wrote: topgit has an issue with that: What issue do you mean. Either I don't get you or I can't reproduce it. 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] Developing with older packages
Hello,
I'm using nix-shell to setup a Haskell environment for development. On a
project I ran into a problem recently, and I'm curious if there is a
common/preferred way of solving it.
The problem I ran into is that the project depends on the mongoDB 1.5
package. The API changed drastically in 2.0 and we're not ready to
undertake the upgrade yet. I think I can handle this by creating a nixpkgs
directory in the project, putting a mongoDB/default.nix file in there that
is setup for the version we need, then override it in our shell.nix file
like this:
let
pkgs = import nixpkgs {};
haskellPackages = pkgs.haskellPackages.override {
extension = self: super: {
mongoDB = self.callPackage nixpkgs/mongoDB {};
ourkidsclass = self.callPackage ./. {};
};
};
Is this a reasonable approach? Is there a better way?
Thanks,
Rich
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS on Azure?
I'm not sure if you mean the initial connection for the end user (i.e. someone deploying from your image) or for your preparation of the image. If you mean the end user then the user provides either an SSH key or a password when the deploy the image. This is handled by either the Azure portal or the cross platform CLI we provide. If you mean for the preparation then you use the credentials you set up in preparing the image and then deprovision the image, which removes all keys (amongst other things) and provides the hooks for the Azure portal/CLI to add in a new set of keys. Both processes are documented in http://msopentech.com/blog/2014/05/14/deploy-customize-freebsd-virtual-machine-image-microsoft-azure/ (which is about FreeBSD but the process is the same for Linux). Ross Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation MS Open Tech is hiring! Ask me for details if anyone you know is interested (http://aka.ms/msopentechjobs) -Original Message- From: Shea Levy [mailto:s...@shealevy.com] Sent: Friday, September 5, 2014 8:46 PM To: Ross Gardler (MS OPEN TECH) Cc: nix-dev@lists.science.uu.nl Subject: Re: [Nix-dev] NixOS on Azure? How is the initial connection managed? Does Azure provide a console, or some interface to provide the VM with an SSH public key, or some such? On Fri, Sep 05, 2014 at 11:03:34PM +, Ross Gardler (MS OPEN TECH) wrote: That's correct Azure images are VHD's. I've not tried the route you propose, so can't promise it will work. Certainly worth a try though. Sent from my Windows Phone From: Shea Levymailto:s...@shealevy.com Sent: 9/5/2014 3:58 PM To: Ross Gardler (MS OPEN TECH)mailto:ross.gard...@microsoft.com Cc: nix-dev@lists.science.uu.nlmailto:nix-dev@lists.science.uu.nl Subject: Re: [Nix-dev] NixOS on Azure? Hi Ross, Am I reading [1] correctly that Azure VMs are started from VHDs? If so, we already have a function for creating virutalbox images that converts a raw image containing a base NixOS system to VDI using qemu-img, so it should be straightforward to tweak that to create a VHD instead. [1]: http://azure.microsoft.com/en-us/documentation/articles/virtual-machin es-linux-create-upload-vhd/ ~Shea On Fri, Sep 05, 2014 at 09:32:58PM +, Ross Gardler (MS OPEN TECH) wrote: I see that NixOS has images available for some of the popular clouds, but not for Azure. I'd love to see a NixOS image on VM Depothttp://vmdepot.msopentech.com/. VM Depot is a community managed repository of virtual machines for Azure. We have something like 8 different Linux distros and around 1700 images built on those distros (ranging from developer stacks through to end user applications). The first step to getting folks to publish NixOS based images is to have a base distribution of NixOS available and, preferably, updated every time there is an official release of NixOS. Is anyone here interested in creating and upload an image to VM Depot? I'm happy to help guide the process. Some common questions for the curious: 1) Does it cost anything to store an image on VM Depot? No - all storage costs are paid by Microsoft Open Technologies, Inc (my employer) 2) Does it cost anything to publish an image on VM Depot? Probably not - You will need an Azure subscription to temporarily store the image and there will be bandwidth charges for the initial copy. However, there are mechanisms by which we can ensure open source projects have sufficient Azure credits to do this without receiving a bill. Create a free Windows Azure trial subscriptionhttp://www.windowsazure.com/en-us/pricing/free-trial/?WT.mc_id=AA4C1C935 to get started straight away (one month, $200 credit) 3) Are there an restrictions on what can be uploaded to VM Depot? - Short answer - if its open source then no there are no restrictions. Long answer is in the Terms of Use http://vmdepot.msopentech.com/ToU.htm 4) Why would I want to upload an image to VM Depot? It is easy for people to deploy a VM from VM Depot to Azure. This means it is easy for people to experiment with your project. More people experimenting means more users, more users means more potential contributors to the project and more potential customers for those employing contributors. 5) How do I get started creating a new VM based on an existing distribution? See http://msopentech.com/blog/2014/05/14/deploy-customize-freebsd-virtual-machine-image-microsoft-azure/ for a description of the general process (need not be FreeBSD as the starting image, the process is the same for any of the other images available) 6) How do I get started creating a new base distribution VM? http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-tutorial/ 7) Who can I contact for assistance? Ross Gardler -
Re: [Nix-dev] Developing with older packages
On 09/08/2014 04:56 PM, Richard Wallace wrote:
Hello,
I'm using nix-shell to setup a Haskell environment for development. On a
project I ran into a problem recently, and I'm curious if there is a
common/preferred way of solving it.
The problem I ran into is that the project depends on the mongoDB 1.5
package. The API changed drastically in 2.0 and we're not ready to
undertake the upgrade yet. I think I can handle this by creating a nixpkgs
directory in the project, putting a mongoDB/default.nix file in there that
is setup for the version we need, then override it in our shell.nix file
like this:
let
pkgs = import nixpkgs {};
haskellPackages = pkgs.haskellPackages.override {
extension = self: super: {
mongoDB = self.callPackage nixpkgs/mongoDB {};
ourkidsclass = self.callPackage ./. {};
};
};
Is this a reasonable approach? Is there a better way?
Thanks,
Rich
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
This looks as good of a solution as any other one could come up with. Is
there something you're dissatisfied with that you would like to have in
a ‘better’ solution?
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Developing with older packages
Hi. On 09/08/2014 05:56 PM, Richard Wallace wrote: The API changed drastically in 2.0 and we're not ready to undertake the upgrade yet. That sounds like it makes sense to keep mongoDB_1_5 in nixpkgs, at least for some time. More people may experience the same issue. (It seems simplified by the fact that I see no package that depends on mongoDB.) 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] Default to GNOME 3.12
* GNOME 3.10 life * In the staging branch I've changed gnome3 to be 3.12 by default, including the nixos test. I haven't tested the change locally except for a few packages. GNOME 3.10 is still sticking around as gnome3_10. In case any program fails to build or run, we can fallback to gnome3_10 for that package. Once everything seems ok we can merge into master and update the release notes. We'll drop GNOME 3.10 once all programs are ported to GNOME 3.12. * GNOME 3.14 * GNOME 3.14.0 is scheduled for release[1] in Sep 22-24, while 3.14.1 in Oct 13-15. Hope my connection will grant me to download something in this period, hope to have a better connection in October. In any case I will try packaging all gnome 3.14.0 again. In general there shouldn't be any problem, except for gdm which is tricky and full of patches. For having GNOME 3.14 in nixos stable, it depends on the timing between GNOME 3.14 release and the new nixos stable release. Also depends on how much we're able to test GNOME 3.14 by the time. * Telepathy framework * The telepathy team as usual kindly notify[2] packagers about the best versions to be used with GNOME. If something does not work in this regard, we can try packaging those exact versions in gnome3_14. Also, since in nixos we have an option to remove packages that are installed by default[3] in GNOME, in order to improve the user experience I'm thinking of installing telepathy-gabble (for XMPP protocols) by default when enabling GNOME. Best regards, [1] https://wiki.gnome.org/ThreePointThirteen [2] https://mail.gnome.org/archives/distributor-list/2014-August/msg2.html [3] http://nixos.org/nixos/manual/#opt-environment.gnome3.excludePackages ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] PAGER=less -R
Fed upstream: https://github.com/greenrd/topgit/issues/36 Thanks for tv @ irc for helping. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Developing with older packages
On Mon, Sep 8, 2014 at 9:03 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk
wrote:
On 09/08/2014 04:56 PM, Richard Wallace wrote:
Hello,
I'm using nix-shell to setup a Haskell environment for development. On a
project I ran into a problem recently, and I'm curious if there is a
common/preferred way of solving it.
The problem I ran into is that the project depends on the mongoDB 1.5
package. The API changed drastically in 2.0 and we're not ready to
undertake the upgrade yet. I think I can handle this by creating a
nixpkgs
directory in the project, putting a mongoDB/default.nix file in there
that
is setup for the version we need, then override it in our shell.nix file
like this:
let
pkgs = import nixpkgs {};
haskellPackages = pkgs.haskellPackages.override {
extension = self: super: {
mongoDB = self.callPackage nixpkgs/mongoDB {};
ourkidsclass = self.callPackage ./. {};
};
};
Is this a reasonable approach? Is there a better way?
Thanks,
Rich
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
This looks as good of a solution as any other one could come up with. Is
there something you're dissatisfied with that you would like to have in
a ‘better’ solution?
Well, the mongoDB package isn't the only one that I want to get a specific
version of. We originally built it with a sandbox and used `cabal freeze`
to make sure everyone is using the same versions. So there are a number of
such packages and I was hoping for something a bit more automated. Perhaps
I can script something to make it a bit easier to maintain.
Rich
--
Mateusz K.
___
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] Developing with older packages
On Mon, Sep 8, 2014 at 9:04 AM, Vladimír Čunát vcu...@gmail.com wrote: Hi. On 09/08/2014 05:56 PM, Richard Wallace wrote: The API changed drastically in 2.0 and we're not ready to undertake the upgrade yet. That sounds like it makes sense to keep mongoDB_1_5 in nixpkgs, at least for some time. More people may experience the same issue. (It seems simplified by the fact that I see no package that depends on mongoDB.) One thing that surprised me about nix when I started using it is that there isn't a way to say, I need package X with version Y. Instead, you have to resort to having multiple definitions of the package with different package names for different versions. This seems a bit hacky to me. As mentioned in a separate reply, I expect to have several such packages and being able to specify it that way would make things much easier. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Developing with older packages
On 09/08/2014 08:12 PM, Richard Wallace wrote: One thing that surprised me about nix when I started using it is that there isn't a way to say, I need package X with version Y. Instead, you have to resort to having multiple definitions of the package with different package names for different versions. This seems a bit hacky to me. When you change version, you have to change the download hash, and often also some other things like dependencies or patches. As many things may be different, having a special attribute name is a flexible convention. In nixpkgs we do not maintain old versions unless there is a good reason to do so. For those cases, the language offers many ways of sharing code among multiple versions, although some of those techniques were disputed a lot and disapproved. 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
Re: [Nix-dev] Developing with older packages
On 09/08/2014 08:08 PM, Richard Wallace wrote: Well, the mongoDB package isn't the only one that I want to get a specific version of. We originally built it with a sandbox and used `cabal freeze` to make sure everyone is using the same versions. So there are a number of such packages and I was hoping for something a bit more automated. Perhaps I can script something to make it a bit easier to maintain. (CC @peti, as the thread concerns versioning of haskell packages in nixpkgs.) You can use cabal2nix to generate the .nix file for a specific package version. 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
Re: [Nix-dev] Developing with older packages
What about just copying the old .nix from old nixpkgs commits?
On Mon, Sep 8, 2014 at 8:08 PM, Richard Wallace rwall...@thewallacepack.net
wrote:
On Mon, Sep 8, 2014 at 9:03 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk
wrote:
On 09/08/2014 04:56 PM, Richard Wallace wrote:
Hello,
I'm using nix-shell to setup a Haskell environment for development. On
a
project I ran into a problem recently, and I'm curious if there is a
common/preferred way of solving it.
The problem I ran into is that the project depends on the mongoDB 1.5
package. The API changed drastically in 2.0 and we're not ready to
undertake the upgrade yet. I think I can handle this by creating a
nixpkgs
directory in the project, putting a mongoDB/default.nix file in there
that
is setup for the version we need, then override it in our shell.nix file
like this:
let
pkgs = import nixpkgs {};
haskellPackages = pkgs.haskellPackages.override {
extension = self: super: {
mongoDB = self.callPackage nixpkgs/mongoDB {};
ourkidsclass = self.callPackage ./. {};
};
};
Is this a reasonable approach? Is there a better way?
Thanks,
Rich
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
This looks as good of a solution as any other one could come up with. Is
there something you're dissatisfied with that you would like to have in
a ‘better’ solution?
Well, the mongoDB package isn't the only one that I want to get a specific
version of. We originally built it with a sandbox and used `cabal freeze`
to make sure everyone is using the same versions. So there are a number of
such packages and I was hoping for something a bit more automated. Perhaps
I can script something to make it a bit easier to maintain.
Rich
--
Mateusz K.
___
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
--
www.debian.org - The Universal Operating System
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Developing with older packages
On 09/08/2014 10:27 PM, Luca Bruno wrote: www.debian.org http://www.debian.org - The Universal Operating System You should update your footer ;-) 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
Re: [Nix-dev] Developing with older packages
Haven't found a cool slogan for nixos yet :P On Mon, Sep 8, 2014 at 11:23 PM, Vladimír Čunát vcu...@gmail.com wrote: On 09/08/2014 10:27 PM, Luca Bruno wrote: www.debian.org http://www.debian.org - The Universal Operating System You should update your footer ;-) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- www.debian.org - The Universal Operating System ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Terminus console font
M. P. Ashton d...@imap.cc writes:
On Sun, Sep 7, 2014, at 02:20 PM, Dmitry Malikov wrote:
Good day.
I'm not a huge fan of X server, that why I'm spending my time inside a
tty and virtual terminals. Default fonts that NixOS offers are not
perfectly suite my eyes that why I'm looking for a way to use terminus
font there.
I.e. in Gentoo OS there is a `consoleFont` variable which could be set
to ter-116n value to get terminus in Xless console. I'm trying to do
the same via setting `i18n.consoleFont = ter-116n`([1]) , but it do
nothing.
Also as you see `pkgs.terminus_font` is added to the `fonts.fonts`
statement, that why I'm assuming terminus font is installed in my system.
have you guys achieved it? What am I doing wrong?
What works for me is the line:
i18n.consoleFont = Lat2-Terminus16;
Something like this works for me:
i18n.consoleFont = ${pkg.terminus}/share/consolefonts/ter-i16n.pcf.gz;
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
