Re: [Nix-dev] Unable to handle `.zip` archive in unstable.
On Tue, 06 Sep 2016 21:03:45 +1000, Aloïs Cochard wrote: > I'm currently trying to upgrade my system to the latest unstable, but I keep > running into errors like: > > unpacking source archive > /nix/store/calj3b4gz6vq99d6wxc1760q66w101k3o147jen_linuxufrII_0290.zip > do not know how to unpack source archive > /nix/store/calj3b4gz6vq99d6wxc1760q66w101k3o147jen_linuxufrII_0290.zip > builder for > ‘/nix/store/hdbk6k7b6v6799i6mfknd7cagmi8zazx-canon-cups-ufr2-2.90.drv’ failed > with exit code 1 > > If I remove cups, it then fail on the next package that require a `.zip` > retrieved by `fetchurl`, is there some > sort of regression? > > Cheers > > PS: I was building `e8315cb1caac6343322b5bab822f3cd227ae287b` which is the > latest Hydra build with complete > evaluation at the time I started the upgrade. I just encountered a gzip problem while trying to build chromium-53.0.2785.34, from '6ac7ffd9d7febdd51dc3a13ce3163115ade6696e', as below. Tim --- [2079/19283] ACTION Generating resources from resources/components_resources.grd FAILED: cd ../../components; python ../tools/grit/grit.py -i resources/components_resources.grd build -f ../tools/gritsettings/resource_ids -o ../out/Release/gen/components "--write-only-new=1" -D _chromium -E "CHROMIUM_BUILD=chromium" -D desktop_linux -D toolkit_views -D use_aura -D use_nss_certs -D enable_extensions -D enable_plugins -D enable_printing -D enable_print_preview -D enable_themes -D use_concatenated_impulse_responses -D enable_media_router -D enable_webrtc -D enable_hangout_services_extension -D enable_task_manager -D enable_notifications -D enable_service_discovery -E "about_credits_file=../out/Release/gen/about_credits.bro" Error processing node Traceback (most recent call last): File "../tools/grit/grit.py", line 15, in grit.grit_runner.Main(sys.argv[1:]) File "/tmp/nix-build-chromium-53.0.2785.34.drv-0/chromium-53.0.2785.34/tools/grit/grit/grit_runner.py", line 268, in Main toolobject.Run(options, args[1:]) File "/tmp/nix-build-chromium-53.0.2785.34.drv-0/chromium-53.0.2785.34/tools/grit/grit/tool/build.py", line 230, in Run self.Process() File "/tmp/nix-build-chromium-53.0.2785.34.drv-0/chromium-53.0.2785.34/tools/grit/grit/tool/build.py", line 360, in Process self.ProcessNode(self.res, output, outfile) File "/tmp/nix-build-chromium-53.0.2785.34.drv-0/chromium-53.0.2785.34/tools/grit/grit/tool/build.py", line 297, in ProcessNode formatted = formatter(node, output_node.GetLanguage(), output_dir=base_dir) File "/tmp/nix-build-chromium-53.0.2785.34.drv-0/chromium-53.0.2785.34/tools/grit/grit/format/data_pack.py", line 45, in Format id, value = node.GetDataPackPair(lang, UTF8) File "/tmp/nix-build-chromium-53.0.2785.34.drv-0/chromium-53.0.2785.34/tools/grit/grit/node/include.py", line 104, in GetDataPackPair data = grit.format.gzip_string.GzipStringRsyncable(data) File "/tmp/nix-build-chromium-53.0.2785.34.drv-0/chromium-53.0.2785.34/tools/grit/grit/format/gzip_string.py", line 26, in GzipStringRsyncable stderr) subprocess.CalledProcessError: Command 'gzip' returned non-zero exit status 1 ninja: build stopped: subcommand failed. builder for ‘/nix/store/pfgvqywsgvysm3aa95ymafr4j4rcjan3-chromium-53.0.2785.34.drv’ failed with exit code 1 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Cross development for STM32
On Sat, 27 Aug 2016 03:28:49 +1000, Alexey Shmalko wrote: > > I usually produce raw binary file first: > > $ arm-none-eabi-objcopy -O binary build/ch.elf ch.bin > > and then flash that with openocd: > > $ openocd -f openocd.cfg > poll > reset halt > flash probe 0 > flash write_image erase ch.bin 0x0800 > reset > > Note this unlikely to work for you, as your device is probably different. > > Check out my Makefile (flash target) and openocd scripts: > - https://github.com/rasendubi/bkernel/blob/master/Makefile#L70-L72 > - https://github.com/rasendubi/bkernel/blob/master/openocd.cfg > - https://github.com/rasendubi/bkernel/blob/master/openocd.tcl I think you have put my feet on the right path. Thank you. I got so far as being able to connect openocd and halt the board, when strangely openocd lost communication. Subsequently my stlink device stubbornly fails to enumerate: [Aug28 23:54] usb 9-1: new full-speed USB device number 2 using ohci-pci [ +0.127987] usb 9-1: device descriptor read/64, error -62 [ +0.233991] usb 9-1: device descriptor read/64, error -62 [ +0.228991] usb 9-1: new full-speed USB device number 3 using ohci-pci [ +0.127962] usb 9-1: device descriptor read/64, error -62 [ +0.234022] usb 9-1: device descriptor read/64, error -62 [ +0.228991] usb 9-1: new full-speed USB device number 4 using ohci-pci [ +0.403983] usb 9-1: device not accepting address 4, error -62 [ +0.128992] usb 9-1: new full-speed USB device number 5 using ohci-pci [ +0.403986] usb 9-1: device not accepting address 5, error -62 [ +0.006086] usb usb9-port1: unable to enumerate USB device even though I have reset the USB subsystems, and even plugged it into a different PC. Neither does its LED illuminate, whereas before it did. I presume that it has failed, and am waiting for a replacement unit. Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Cross development for STM32
On Fri, 26 Aug 2016 22:23:46 +1000, Alexey Shmalko wrote: > [...] > Resources you may check out: > - my kernel for STM32F4Discovery which is 100% Rust > (https://github.com/rasendubi/bkernel). Interesting. How large is your kernel ? Would it fit in a small STM32 (128k flash, 20k RAM) ? Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Cross development for STM32
Thank you Philip and Alexey. I have tried gcc-arm-embedded as you suggested, and had no trouble building the ChibiOS UART demo for a Maple Mini board (I did have to change GPIOC_LED to GPIOB_LED; presumably the demo was written for a board with more LEDs). $ file build/ch.elf build/ch.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped $ arm-none-eabi-size build/ch.elf textdata bss dec hex filename 6880 416 20448 277446c60 build/ch.elf I have yet to figure out how to get the code onto the board. Something like connecting to UART1 and starting the boot loader. I also have an stlink device, so openocd should work too, if necessary. Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Cross development for STM32
I have some STM32 boards (e.g. Maple Mini) to play with. I am not trying to port Nixos to them, because they are not really powerful enough to run Linux; instead I plan to run ChibiOS/RT on them. I would appreciate suggestions as to a good way to setup an STM32 cross-development environment on Nixos, so that I can write software that will run on (link with) ChibiOS/RT on the STM32 board. Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Eclipse
What is the recommended way to run Eclipse on Nixos ? When I install a Nixos eclipse package (e.g. eclipse-cpp), I find that it cannot install plugins in the normal way, because the plugin installation process tries to modify the Nix store. I would like to be able to run Eclipse with i.a. the GNU ARM plugin... Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Sidestepping the community builds trust issue?
On Sat, 26 Dec 2015 09:07:38 +, Wout Mertens wrote: > If web-of-trust is the best solution, and the only blocker is build > reproducability, how about trying to classify > build differences? > > Each of the differences will have a reason, and either we can fix the build > to be deterministic (e.g. timestamps, > build paths), or we can classify a class of changes as equivalent (e.g. > optimalizations resulting in equivalent > code, prelinking). > [...] Your suggestion sounds a bit like homotopy, which type theorists are now using to resolve their long-standing difficulties with intensional vs extensional equality; perhaps there is a connection between these difficulties and the fact that Nixos is not yet using the intensional Nix store model. How would one verify that the builds are equivalent, and that the difference is not due to a malicious modification ? Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Sidestepping the community builds trust issue?
I agree there is no conflict between your proposal and my suggestion. The reason I mentioned it is that I do not like the idea of relying on a single trusted party for security (to whic your proposal makes no difference, because the trusted party will control all build machines). If someone (use your imagination) wanted to be able to gain access to any nixos machine, they would be tempted to compromise the centrally controlled builds. Therefore I think we should encourage people to run build systems, whether centrally controlled or not. Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Signing source packages
At Mon, 2 Feb 2015 15:45:31 +, Daniel Shahaf wrote: [ tl;dr: NixOS should sign any code that makes it into users' systems. ] [...] I would therefore suggest that NixOS starts signing any code that gets installed on users' machines, and that Nix should, by default, verify signature against a set of trusted keys and refuse to install packages that fail to verify. By comparison, most distros sign everything, from .iso images onwards. Part of this has been implemented: verification of binary packages has been implemented last year [1], however, it is off by default. (Thanks to Lethalman on IRC for this information.) I'm suggesting that as an interested potential user; I don't run NixOS at the moment. (And not having signed packages makes it harder for me to choose it over alternatives.) I would like to see this too. I do run NixOS. Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use Haskell for Shell Scripting
At Sat, 31 Jan 2015 13:22:09 +0100, Ertugrul Söylemez wrote: [...] I have actually experimented with using Haskell (and a few other FP languages) as a substitute for shells. [...] You might be interested why Curry didn't work. Simple: I couldn't figure out how to write a program. Actually I went through the whole tutorial, did all the exercises (they aren't really difficult to a Haskell programmer) and then skimmed through the whole PAKCS manual. I could write extremely elegant algorithmic code and was quite amazed at the beauty of this language, even compared to Haskell. But in the end I still didn't know how to turn all this beautiful Curry code into an executable file that I can run without invoking PAKCS explicitly. Something with a shebang or ideally something binary. It would probably be possible to write wrapper scripts, but let's just wait until one of the implementations becomes mature enough for systems programming. Curry is indeed a beautiful language, and is essentially a conservative extension of Haskell. I am surprised that more Haskell folk have not adopted it. PAKCS compiles Curry to Prolog (typically SICStus), which drags in the Prolog system. To get a binary executable, a better choice would be MCC (compiles Curry to native code) or KiCS2 (compiles Curry to Haskell, which can go into ghc): http://www-ps.informatik.uni-kiel.de/currywiki/implementations/overview Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] postfix - generating alias tables in store and some additional changes
At Mon, 26 Jan 2015 09:29:21 +, Marc Weber wrote: Is anybody interested in these? https://github.com/MarcWeber/nixpkgs/commit/1bb2f95c9ab792422a89c11e1f629dcff2cbf322 marc-nixos/postfix Yes, please. Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] A few questions about Arm support and NixOS on a Chrome-book
I would also like to be able to run Nixos on ARM. I have three Raspberry Pis (indeed an aging platform), and an MK802IV (much more powerful that the Raspberry Pi, but a similar price). I also would prefer to avoid x86 PC hardware in the future, the problem being the power consumption (100-200W per box). ARM seems much better in this regard. From a very rough estimate, I think an MK802IV has about 10% of the processing power of a PC, for about 2.5% of the power consumption (5W max). I think we will see the day when ARM will out-perform x86, because it will be able to process more instructions per second without melting. AMD is working on 64-bit server-class ARM CPUs, which will fit in PC motherboards. I hope to use such machines in place of x86 PCs (in the future), and to use MK802IV, or similar, for less demanding applications. I have managed to get a Raspberry Pi up to date WRT to Nixos 13.10 (it took about a week to build), but the current small stable channel (nixos-14.04-small) failed on building the kernel (3.6.y in nixos-14.04.527). I am not sure whether Nixos 13.10 is patched for recent security fixes. It would be really helpful if Hydra could do ARM builds, even just for the small channels (e.g. nixos-14.04-small). I would also like to know whether nixops can work cross-platform. Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NILFS2, NixOS, nixpart and Blivet
Wout Mertens writes: FWIW, btrfs and ZFS also do non destructive writes, they're Copy on Write. As a bonus you get unlimited instant snapshots and lots of other wonderful things. I prefer btrfs as it has more of a desktop focus and feature set as well as being in the kernel, but ZFS is more mature. I shall probably go back to using btrfs. One nice property of NILFS is that every write results in a new checkpoint, which makes it very cheap to check whether a filesystem has been modified (other than via low-level disk-editing). Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NILFS2, NixOS, nixpart and Blivet
Wout Mertens writes: On Mon, Oct 6, 2014 at 8:04 AM, Tim Barbour t...@categorical.net wrote: One nice property of NILFS is that every write results in a new checkpoint, which makes it very cheap to check whether a filesystem has been modified (other than via low-level disk-editing). On btrfs you can look at the generation: http://www.tummy.com/blogs/2010/11/01/fun-with-btrfs-what-files-have-changed/ Thank you! That looks like what I need. Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NILFS2, NixOS, nixpart and Blivet
Nicolas Pierron writes: Looking at the details of NILFS2, I saw that it does a linear search within directories. This is far from ideal for the /nix/store as this directory is HUGE. This might have a noticeable cost at the start-up of a computer / programs. Ouch! I missed that bit. I shall probably have to go back to btrfs. Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NILFS2, NixOS, nixpart and Blivet
aszlig writes: On Tue, Sep 30, 2014 at 09:08:41PM +1000, Tim Barbour wrote: The most serious problem is that NILFS2 needs to update /etc/mtab when mounting a filesystem, so that it can store information about the [...] I don't have any experience with NILFS2 yet, but you might want to take a look at how it is handled when using NFS in fileSystems: I think your point is that NFS also needs to keep track of some state when filesystems are mounted and unmounted. https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/filesystems/nfs.nix I had a look at that file, but I could not see where it is handling the state. Nice :-) Have you considered submitting your patch for 0.41 upstream? If it doesn't get upstreamed too soon, I could include it as well while cleaning up the mess^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hupdating blivet/nixpart. That would be great. But as mentioned in the other mail, I'm working on nixpart 1.0 already, which should get rid of the monkey patching with 0.17. I attach a tarball with patches for Blivet (note that the 0.41 patch is untested). Yah, probably would make sense to test against 0.41, because I think we shouldn't aim for old versions, especially in terms of nixpart. Are you able to build a current Blivet to test with ? I just checked, and it looks as if Blivet is up to about 0.65 now: https://apps.fedoraproject.org/packages/python-blivet Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] NILFS2, NixOS, nixpart and Blivet
NILFS2 is a log-structured filesystem which is now in the Linux kernel source tree, and supported by GRUB2. It should appeal to NixOS users because it avoids destructive update (changing a file produces a new version of the file). I have installed NixOS with all filesystems on NILFS2, but encountered some problems along the way. The most serious problem is that NILFS2 needs to update /etc/mtab when mounting a filesystem, so that it can store information about the nilfs_cleanerd process associated with the mounted filesystem. If it cannot write to /etc/mtab, it does not start nilfs_cleanerd, and thus does not do garbage collection. In NixOS, /etc/mtab is just a symlink to /proc/mounts. I have worked around this manually so far, by replacing the symlink with a copy of /proc/mounts, then remounting all the NILFS2 filesystems. I am not sure how to resolve this properly. It is possible to mount using the '-n' option, but then NILFS2 will not start nilfs_cleanerd; it can be started later, but that requires writing to /etc/mtab. Perhaps the right way would be to mount using '-n', then start nilfs_cleanerd separately, but care would be necessary to make sure that nilfs_cleanerd is started exactly once (per filesystem), and shutdown appropriately at unmount. Another problem is that nixpart does not work with NILFS2, because Blivet does not support it. I modified Blivet (0.41) to support NILFS2, but the NixOS Blivet packages use a very old version (0.17-1), so I cannot easily test my change against the latest version of Blivet. I have back-ported it to 0.17-1, and used that to setup partitions and filesystems for the above NixOS installation. I noticed one problem: it did not label any of the volumes, not even swap, even though I specified labels. I suspect this is a deficiency of Blivet 0.17-1, and imagine it is already fixed in Blivet 0.41 . I considered updating the NixOS Blivet package(s), but they do some tricky-looking processing on the source code, and I doubt that I could update that properly for the current source code. If the maintainer could update the Blivet packages, then I would test my patch against the current Blivet, and send it to the upstream maintainers. I attach a tarball with patches for Blivet (note that the 0.41 patch is untested). Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 patches.tar.gz Description: Binary data ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] build server
I would like to set up a nix build server, particularly for use with nixops. Is there a definitive document about how to do this, including cross-platform builds (e.g. ARM) ? Can it be done declaratively, or does one need to set environment variables ? So far I have found the following documents, each with a different way: https://nixos.org/wiki/Raspberry_Pi - distcc approach https://nixos.org/wiki/Distributed_build --- ignore this, look at nix.buildMachines in NixOS Manual http://nixos.org/nix/manual/#chap-distributed-builds http://sandervanderburg.blogspot.com.au/2013/04/setting-up-hydra-build-cluster-for_10.html I would really like to know the current recommended way. Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] build server
Tim Barbour writes: I would like to set up a nix build server, particularly for use with nixops. Is there a definitive document about how to do this, including cross-platform builds (e.g. ARM) ? Well, I got it working (no cross-build yet) using nix.buildMachines as described here: http://sandervanderburg.blogspot.com.au/2013/04/setting-up-hydra-build-cluster-for_10.html together with archive signing as described here: http://functional-orbitz.blogspot.com.au/2013/05/setting-up-nixops-on-mac-os-x-with.html I have yet to setup cross-platform builds. I know that I need to configure the cross-build capability on the build server, and tell the client that the server has it (the easy part). So far I have found these instructions: https://nixos.org/wiki/CrossCompiling Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-1.7 on armv6l-linux
vcu...@gmail.com writes: That's trivial. armv6l-linux was not in the all platform set. I fixed that in master 7323d5e12 and 14.04 5f2f1b05e. Thank you. I am still getting the same error, I think because your change has not reached the 14.04 channel yet - presumably it is still working its way through Hydra. I will try again later, and/or use git. Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-1.7 on armv6l-linux
Tim Barbour writes: vcu...@gmail.com writes: That's trivial. armv6l-linux was not in the all platform set. I fixed that in master 7323d5e12 and 14.04 5f2f1b05e. Thank you. I am still getting the same error, I think because your change has not reached the 14.04 channel yet - presumably it is still working its way through Hydra. I will try again later, and/or use git. Following Eelco's post, I switched the channel to nixos-14.04-small, and it is now building okay. So I think the nixos-14.04-small channel has already got the change. Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] nix-1.7 on armv6l-linux
Starting from the installation image on the Wiki, I managed to get my Raspberry Pi Model B up-to-date WRT nixos-13.10 . I then changed the channel to nixos-14.04, updated the channel, and ran nixos-rebuild build, resulting in the following output: building Nix... error: user-thrown exception: the package ânix-1.7â in «unknown-file» is not supported on âarmv6l-linuxâ (use `--show-trace' to show detailed location information) error: user-thrown exception: the package ânix-1.8pre3718_51485dcâ in «unknown-file» is not supported on âarmv6l-linuxâ (use `--show-trace' to show detailed location information) error: user-thrown exception: the package ânix-1.8pre3718_51485dcâ in «unknown-file» is not supported on âarmv6l-linuxâ (use `--show-trace' to show detailed location information) which seems to be saying that nix no longer runs on armv6l-linux from 1.7 onwards. Has anyone else tried running nixos-14.04 on ARM ? Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ghcWithPackages
This message somehow did not make it to the list, so I am sending it again. ---BeginMessage--- Mateusz Kowalczyk writes: [...] haskellPackages_ghc783.ghcWithPackages should work just fine, I just tried it myself. Considering haskellPackages.ghcWithPackages gives you 7.6.3, it simply makes me think that you have an old set of packages. On nixos-unstable/nixpkgs-unstable, that would default to 7.8.3 and haskellPackages_ghc783.ghcWithPackages would work fine. That's what I use in my configuration.nix myself: I'm using nixos-unstable channel. That fixed it, thank you. Now I am wondering what the wisest choice of channel(s) is. I imagine the latest stable nixos for most things, but nixos-unstable for more experimental things (e.g. yi). Perhaps nixos-unstable for most Haskell packages ? What determines the choice between the nixos channel and the nixpkgs channel ? Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ---End Message--- -- Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ghcWithPackages
This message somehow did not make it to the list, so I am sending it again: Mateusz Kowalczyk writes: [...] haskellPackages_ghc783.ghcWithPackages should work just fine, I just tried it myself. Considering haskellPackages.ghcWithPackages gives you 7.6.3, it simply makes me think that you have an old set of packages. On nixos-unstable/nixpkgs-unstable, that would default to 7.8.3 and haskellPackages_ghc783.ghcWithPackages would work fine. That's what I use in my configuration.nix myself: I'm using nixos-unstable channel. That fixed it, thank you. Now I am wondering what the wisest choice of channel(s) is. I imagine the latest stable nixos for most things, but nixos-unstable for more experimental things (e.g. yi). Perhaps nixos-unstable for most Haskell packages ? What determines the choice between the nixos channel and the nixpkgs channel ? Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] ghcWithPackages
It seems that some versions of haskellPackages define ghcWithPackages, and others do not. I have been following the approach described at https://nixos.org/wiki/Haskell#Using_cabal_in_the_direct_installation_scenario under the heading Local use via Nixpkgs config. If I use haskellPackages.ghcWithPackages with yi in the list of packages, I get installing `haskell-env-ghc-7.6.3' these derivations will be built: /nix/store/3n7dzh6c1idpjbq27wzds0784i200kpi-haskell-env-ghc-7.6.3.drv /nix/store/7kbz46k29gxgx67lxs2fymk3crkd0q1d-haskell-yi-ghc7.6.3-0.8.1.drv ... 60% ( 9 / 15) in 'Yi.Command' haddock: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): mkWWcpr: not a product details unavailable Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug builder for `/nix/store/7kbz46k29gxgx67lxs2fymk3crkd0q1d-haskell-yi-ghc7.6.3-0.8.1.drv' failed with exit code 1 cannot build derivation `/nix/store/3n7dzh6c1idpjbq27wzds0784i200kpi-haskell-env-ghc-7.6.3.drv': 1 dependencies couldn't be built error: build of `/nix/store/3n7dzh6c1idpjbq27wzds0784i200kpi-haskell-env-ghc-7.6.3.drv' failed which looks very similar to this bug: https://ghc.haskell.org/trac/ghc/ticket/9170 Since the bug is supposed to be fixed in ghc = 7.8.2, I would like to use a newer version of haskellPackages. But if I try haskellPackages_ghc783.ghcWithPackages, I get error: attribute `haskellPackages_ghc783.ghcWithPackages' missing OTOH, haskellPackages_ghc742.ghcWithPackages has no such error. It seems that some versions of haskellPackages define ghcWithPackages, and others do not. Why ? What is the right way to specify a particular version of ghc ? Or better still, avoid a given version of ghc ? Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Raspberry Pi image seed
Jeremy Hughes writes: Never mind. Got it now. Bizarre. You might be interested to know that the image in question does not work with RPis that use the Hynix chipset (in some later RPis), as I discovered when trying to use it. I have made a modified image that does work with the Hynix chipset, and will make it available as soon as I can. I suggest checking your RPi CPU - if it has hynix written on it, then you probably need my modified image. Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] nixops data deployment
I understand that one advantage of nixops is being able to deploy a set of services atomically, possibly including data that is needed by the services. What is the recommended way to get nixops to deploy some data for a service at the same time it deploys the service ? I would like to be able to deploy some services (e.g. postfix) via nixops, including required data (e.g. whitelist data). Obviously I could use something else (like rsync) to deploy the data, but that would break the atomic deployment, since the service could start before the data was available. Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bind root hints
Peter Simons writes: personally, I think it's okay to use fetchurl because it guarantees that we notice updates in the cache file. How will we notice ? When bind fails to install ? The named.cache file does contain a version number (i.e. a date stamp), so can reliably detect that a change checksum change was caused by an upstream update. You are right, it does. But I was wishing for a version number in the filename, which would allow us to fetch the file in a referentially transparent way (as with version numbers in the names of source tarballs). According to my understanding, once the named.root file is in the store, fetchurl will get it from there (the store acting as a cache), and will not check the source; thus even when the source file changes, it will not notice. I think the change will only be apparent when trying to install bind where the store does not already contain a *matching* copy of the named.root file. This will happen if the checksum in the source is not updated, or much worse, when someone tries to install from an old version (e.g. stable) version of the source. The latter amounts to gratuitous bitrot, and it is the reason why I think this is the wrong approach. I do not think it can be acceptable for a package that used to install correctly to stop doing so, just because of a change in the named.root file. It would be easy enough to use wget to fetch the file every time preStart runs, but that would put unnecessary load on the internic.net server. Futhermore, it would not guarantee changes would be noticed (consider a stable bind installation that is not restarted for months or years). The DNS HOWTO (http://www.tldp.org/HOWTO/DNS-HOWTO-8.html) recommends using dig to get the root hints. Since dig is included with bind, it should be available by the time preStart runs, so I think we could use dig in preStart to fetch the root hints each time preStart runs. Unfortunately, that approach does not provide the version number information (being in a comment, which dig will not return), but it should still work. The DNS HOWTO also recommends using a monthly cron job to update the root hints. I suppose we could arrange for nixos to install such a cron job automatically whenever bind is installed with rootHints true, but I am not sure of the right way to do this. Yes, the file should probably be used by default. I don't see much a downside. Okay, I will make the option default to true. The only downside I can see is when someone wants a DNS with roots different to the Internet ones. In that (rare) case, they need to explicitly set the option false. Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bind root hints
Tim Barbour writes: The DNS HOWTO (http://www.tldp.org/HOWTO/DNS-HOWTO-8.html) recommends using dig to get the root hints. Since dig is included with bind, it should be available by the time preStart runs, so I think we could use dig in preStart to fetch the root hints each time preStart runs. Unfortunately, that approach does not provide the version number information (being in a comment, which dig will not return), but it should still work. I did that, but now have a further difficulty. I had to add a rootHintsServer option to specify the nameserver to use for getting the root hints. If I specify a DNS name (e.g. k.root-servers.net), preStart is unable to resolve it, and so bind fails to install (if I specify an IP address, it works fine). The problem is that /etc/resolv.conf points to localhost, but bind is not yet working there. nixos must have a way around this kind of bootstrap problem, otherwise it would have difficulty downloading the source code for bind. Is there a nix function I can use to get rootHintsServer resolved to an IP address, before putting it into preStart ? Tim --- ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bind root hints
Tim Barbour writes: The DNS HOWTO (http://www.tldp.org/HOWTO/DNS-HOWTO-8.html) recommends using dig to get the root hints. Since dig is included with bind, it should be available by the time preStart runs, so I think we could use dig in preStart to fetch the root hints each time preStart runs. Unfortunately, that approach does not provide the version number information (being in a comment, which dig will not return), but it should still work. Now I am reading elsewhere http://grokbase.com/t/centos/centos/132e099w4y/bind-built-in-root-hints that modern bind does not need the root hints file, because it is capable of finding the information itself. But it may need root.key for DNSSEC. Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bind root hints
Tim Barbour writes: Now I am reading elsewhere http://grokbase.com/t/centos/centos/132e099w4y/bind-built-in-root-hints that modern bind does not need the root hints file, because it is capable of finding the information itself. But it may need root.key for DNSSEC. Indeed, it works fine without root hints, so there is not much need for my change after all. Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bind root hints
Peter Simons writes: The nixos bind package* does not seem to include any root hints, or any way to configure it to use them. Is it only intended to be used in a forwarding setup? my impression is that generating a fully fledged BIND config within NixOS is overkill, i.e. there are so many possible options one might want to set that it's easier to just write the appropriate config file directly. I see your point, but think that root hints are common enough to support without needing a custom config file. I have modified the bind package to add a rootHints option. This currently uses the pkgs.fetchurl to fetch the root hints file, which is not the right approach, because fetchurl needs a checksum provided, and the root hints file changes occasionally (without any version number). Perhaps wget would be a better choice, but then bind would depend on wget. Would this be acceptable, or is there a better way to fetch the file ? For backwards compatibility, I have the rootHints option defaulting to false, but one could reasonably argue that it should default to true. Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bind root hints
Tim Barbour writes: I have modified the bind package to add a rootHints option. For backwards compatibility, I have the rootHints option defaulting to false, but one could reasonably argue that it should default to true. At least, when there are no forwarders, it should provide root hints by default. Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] bind root hints
The nixos bind package* does not seem to include any root hints, or any way to
configure it to use them. Is it only intended to be used in a forwarding setup?
I would like to configure a stand-alone DNS server to be deployed by nixops...
For root hints, the bind config should include a zone like this:
zone . IN {
type hint;
file named.root;
};
and the file named.root should be fetched from
http://www.internic.net/domain/named.root
and installed, as part of the installation of bind.
*
https://github.com/NixOS/nixos/blob/master/modules/services/networking/bind.nix
Tim
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] disk setup for nixos installation
aszlig writes: So you could use it, but it's not yet ready for being part of the nixos installation procedure. Here is the repository: https://github.com/aszlig/nixpart And it is in nixpkgs as well. Thank you very much. I have had a play, and it looks very helpful. There is one small problem though: I want to use the nilfs2 filesystem, and kickstart does not support it out of the box. Is there any way to pass some option to tell nixpart and kickstart that nilfs2 is a valid filesystem type ? When I specify a filesystem of type nilfs2 in the kickstart file, nixpart just ignores it (it does not even complain about it). If I change the filesystem type (e.g. to ext3), then nixpart will create it. Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] how to install nilfs-utils ?
I am trying to install nilfs-utils. According to the wiki ( http://nixos.org/wiki/Install/remove_software ), I can install a package by 'nix-env -i package for one user, or I can install it for all users by adding it to environment.systemPackages . The second way does not work for me for nilfs-utils. If I put environment.systemPackages = with pkgs; [ wget httpfs2 nilfs-utils ]; in /etc/nixos/configuration.nix, then nix complains: $ nixos-rebuild build building Nix... building the system configuration... error: undefined variable `nilfs-utils' but other packages like wget or httpfs2 are fine. Also 'nix-env -i nilfs-utils' works fine. What is wrong with putting nilfs-utils in environment.systemPackages ? Does it have something to do with the hyphen in the name, or is nilfs-utils a special kind of package ? In the latter case, how can one tell ? How can it be installed for all users ? Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] disk setup for nixos installation
I would like to be able to boot from nixos installation media, then do automated partitioning, LVM setup and filesystem creation, then let nixops do the rest. What is the best way to automate partitioning, LVM setup and filesystem creation ? I wrote a shell script to do this (just for one disk, so far) using parted etc., but it looks ugly, and I wonder if it would be better done using nix. Does nix / nixos provide any existing mechanisms for doing this ? I am an experienced functional programmer (Haskell, not nix), but I don't understand how to do IO in nix. Perhaps I should be modelling the disk setup as the building of some derivations, but such derivations would not produce a result in the nix store. If I made them produce a result in the store, then the disk setup would be a side-effect, and not referentially transparent. I get the feeling that this is outside the scope of nix. Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] disk setup for nixos installation
On further reflection, I think I see how it almost might work using derivations. Assume it is possible to have a derivation that is only considered to be built (hand-waving part here ...) if the required filesystem exists. Then that derivation depends on another that is only considered to be built if the necessary LVM volume exists, etc. . I still cannot see how to make the hand-waving part referentially transparent. I think nixos must have a solution to this problem, otherwise how can it install GRUB ? Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] cannot build nova
Thank you. I tried prefetching it, but it makes no difference. The result of prefetching goes in different store location to the one it is looking for. Perhaps the package has the wrong hash for python-novaclient-2012.1.tar.gz ? What is the process for updating the package ? $ nix-prefetch-url http://pkgs.fedoraproject.org/repo/pkgs/python-novaclient/python-novaclient-2012.1.tar.gz/f654bce125e0fc4010448cc2701cdb42/python-novaclient-2012.1.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 85322 100 853220 0 66526 0 0:00:01 0:00:01 --:--:-- 85407 path is '/nix/store/jqn8p6fybyz22v9lcz1zxbns059gsxnp-python-novaclient-2012.1.tar.gz' 0hrihvl3y6xdj3vj5cdvpwbz8dalxlq10z9flknpipz10slbhv3b nixos-rebuild build Password: building Nix... building the system configuration... these derivations will be built: [...] /nix/store/88dpxha8s11jxw09lfbffkhxsv4939hg-python-novaclient-2012.1.tar.gz.drv /nix/store/8sdvg7xc4a9kzlln1iml3znjn2px1pjw-nova-2011.2.drv [...] building path(s) `/nix/store/65m6wingws3f36i5xdidx4il601axzrw-python-novaclient-2012.1.tar.gz' trying http://pypi.python.org/packages/source/p/python-novaclient/python-novaclient-2012.1.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (22) The requested URL returned error: 404 Not Found error: cannot download python-novaclient-2012.1.tar.gz from any mirror Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] cannot build nova
If I set virtualisation.nova.enableSingleNode = true; in configuration.nix, then nixos-rebuild build fails as follows: building Nix... building the system configuration... these derivations will be built: /nix/store/00yyan1p9zgnw1mj7q8v1ga1pp3hx9lr-nixos-13.07pre4944_6246d75-1f2ecd0.drv /nix/store/16nq8svckrhi6j0k644j0w337pys319d-unit.drv /nix/store/3qmh9lkzzh6za3c4r0z9kr43z4i16gz6-units.drv /nix/store/4ahzixf4csghzlmf7xv7xmz2267zi0ab-unit.drv /nix/store/7qfz9ihaplyf1am329fki95j06whgkp1-dbus-conf.drv /nix/store/88dpxha8s11jxw09lfbffkhxsv4939hg-python-novaclient-2012.1.tar.gz.drv /nix/store/8sdvg7xc4a9kzlln1iml3znjn2px1pjw-nova-2011.2.drv /nix/store/9yb5b3xhm9iil7yqjdyfdyybr2781sxm-unit.drv /nix/store/hdm6isgz0ksqq1nhwkcvfs8790gzxz2x-nova-network-start.drv /nix/store/j685bx51fyga6zjy14rjhymzlhnlk2rm-unit.drv /nix/store/j8pz12y95wv5zhyxvdyjh4mkjripl393-system-path.drv /nix/store/jab89qlpr3j5v5fyir5nsbx8z5p308a4-novaclient-2012.1.drv /nix/store/m8gki6l1srr6c1m3gdrnygv3bjs14caa-system-crontab.drv /nix/store/mibvixljsgb8p4izgh9hi7h557n2fb5b-nova-compute-start.drv /nix/store/r5qv1zicbljljl4528wfr2lvy61hbpvh-nova-api-start.drv /nix/store/w04vbi6sdcvqrzg5slhrvjm5087yzhc3-nova-scheduler-start.drv /nix/store/yxcxqc7afhz4hpc2p9pqi6a4ab32xj93-etc.drv /nix/store/z3py2lwrzxfjfq3zy9h8sn2apv97hgcr-nova-objectstore-start.drv /nix/store/zn6pv5glv4ff27iacgywnv8cg8xxzsq9-unit.drv building path(s) `/nix/store/65m6wingws3f36i5xdidx4il601axzrw-python-novaclient-2012.1.tar.gz' trying http://pypi.python.org/packages/source/p/python-novaclient/python-novaclient-2012.1.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (22) The requested URL returned error: 404 Not Found error: cannot download python-novaclient-2012.1.tar.gz from any mirror note: keeping build directory `/tmp/nix-build-python-novaclient-2012.1.tar.gz.drv-7' builder for `/nix/store/88dpxha8s11jxw09lfbffkhxsv4939hg-python-novaclient-2012.1.tar.gz.drv' failed with exit code 1 cannot build derivation `/nix/store/jab89qlpr3j5v5fyir5nsbx8z5p308a4-novaclient-2012.1.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/8sdvg7xc4a9kzlln1iml3znjn2px1pjw-nova-2011.2.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/j8pz12y95wv5zhyxvdyjh4mkjripl393-system-path.drv': 2 dependencies couldn't be built cannot build derivation `/nix/store/hdm6isgz0ksqq1nhwkcvfs8790gzxz2x-nova-network-start.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/r5qv1zicbljljl4528wfr2lvy61hbpvh-nova-api-start.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/w04vbi6sdcvqrzg5slhrvjm5087yzhc3-nova-scheduler-start.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/z3py2lwrzxfjfq3zy9h8sn2apv97hgcr-nova-objectstore-start.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/mibvixljsgb8p4izgh9hi7h557n2fb5b-nova-compute-start.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/16nq8svckrhi6j0k644j0w337pys319d-unit.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/7qfz9ihaplyf1am329fki95j06whgkp1-dbus-conf.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/zn6pv5glv4ff27iacgywnv8cg8xxzsq9-unit.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/m8gki6l1srr6c1m3gdrnygv3bjs14caa-system-crontab.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/4ahzixf4csghzlmf7xv7xmz2267zi0ab-unit.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/j685bx51fyga6zjy14rjhymzlhnlk2rm-unit.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/9yb5b3xhm9iil7yqjdyfdyybr2781sxm-unit.drv': 1 dependencies couldn't be built cannot build derivation `/nix/store/3qmh9lkzzh6za3c4r0z9kr43z4i16gz6-units.drv': 5 dependencies couldn't be built cannot build derivation `/nix/store/yxcxqc7afhz4hpc2p9pqi6a4ab32xj93-etc.drv': 3 dependencies couldn't be built cannot build derivation `/nix/store/00yyan1p9zgnw1mj7q8v1ga1pp3hx9lr-nixos-13.07pre4944_6246d75-1f2ecd0.drv': 3 dependencies couldn't be built error: build of `/nix/store/00yyan1p9zgnw1mj7q8v1ga1pp3hx9lr-nixos-13.07pre4944_6246d75-1f2ecd0.drv' failed Tim ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
