Re: [Nix-dev] golden-cheetah compiling, but not linking against Qt correctly

[Oliver Charles]

Peter Hoeg <pe...@hoeg.com> writes:

> Hi Oliver,
>
> On 17-04-10 at 16:31, Oliver Charles wrote:
>>   Does anyone know what's going on here? Is golden-cheetah doing something
>>   funky with its build scripts?
>
> I think it has to do with the qt dependencies all being added to
> nativeBuildInputs instead of the proper buildInputs.

We got it fixed in the end - here's the solution:

https://github.com/NixOS/nixpkgs/commit/c7dd8a707be6c5192593cd249d8018ac9f87b9cb
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] golden-cheetah compiling, but not linking against Qt correctly

[Oliver Charles]

Hi all,

I've been stuck on this for a while. In nixpkgs, we have a golden-cheetah
expression. In all-packages.nix:

  golden-cheetah = libsForQt5.callPackage
../applications/misc/golden-cheetah {};

It builds just fine, but when I try and actually run it:

→ ./result/bin/GoldenCheetah
./result/bin/GoldenCheetah: error while loading shared libraries:
libQt5Svg.so.5: cannot open shared object file: No such file or directory

If we prod the binary with ldd:

→ ldd ./result/bin/.GoldenCheetah-wrapped
   linux-vdso.so.1 (0x7ffc597aa000)
   libssl.so.1.0.0 =>
/nix/store/9x03gg4ia71qv6ffj12q4frcm39rq65k-openssl-1.0.2k/lib/libssl.so.1.0.0
(0x7fae8bbb4000)
   libcrypto.so.1.0.0 =>
/nix/store/9x03gg4ia71qv6ffj12q4frcm39rq65k-openssl-1.0.2k/lib/libcrypto.so.1.0.0
(0x7fae8b778000)
   libQt5Svg.so.5 => not found
   libQt5MultimediaWidgets.so.5 => not found
   libQt5WebKitWidgets.so.5 => not found
   libQt5Charts.so.5 => not found
   libQt5Widgets.so.5 => not found
   libQt5Multimedia.so.5 => not found
   libQt5WebKit.so.5 => not found
   libQt5Gui.so.5 => not found
   libQt5Xml.so.5 => not found
   libQt5Sql.so.5 => not found
   libQt5Network.so.5 => not found
   libQt5Concurrent.so.5 => not found
   libQt5SerialPort.so.5 => not found
   libQt5Bluetooth.so.5 => not found
   libQt5Core.so.5 => not found
   libGL.so.1 => /run/opengl-driver/lib/libGL.so.1 (0x7fae8b57b000)
   libpthread.so.0 =>
/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/lib/libpthread.so.0
(0x7fae8b35d000)
   libpulse-mainloop-glib.so.0 =>
/nix/store/6avy04i2aiiiwb1vni4amf6dhl5cr50r-libpulseaudio-10.0/lib/libpulse-mainloop-glib.so.0
(0x7fae8b158000)
   libpulse.so.0 =>
/nix/store/6avy04i2aiiiwb1vni4amf6dhl5cr50r-libpulseaudio-10.0/lib/libpulse.so.0
(0x7fae8af06000)
   libglib-2.0.so.0 =>
/nix/store/hsqi48x55vxl9xxf3q3am7cv7jzm45q9-glib-2.50.3/lib/libglib-2.0.so.0
(0x7fae8abf2000)
   libstdc++.so.6 =>
/nix/store/mpi06h1i531wdjrmp6dnq4hwyrm52hcy-gcc-5.4.0-lib/lib/libstdc++.so.6
(0x7fae8a87a000)
   libm.so.6 =>
/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/lib/libm.so.6
(0x7fae8a567000)
   libgcc_s.so.1 =>
/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/lib/libgcc_s.so.1
(0x7fae8a351000)
   libc.so.6 =>
/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/lib/libc.so.6
(0x7fae89fb2000)
   libz.so.1 => not found
   libdl.so.2 =>
/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/lib/libdl.so.2
(0x7fae89dae000)
   libXext.so.6 => /run/opengl-driver/lib/libXext.so.6
(0x7fae89b9c000)
   
/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/lib/ld-linux-x86-64.so.2
(0x7fae8be22000)
   libpulsecommon-10.0.so =>
/nix/store/6avy04i2aiiiwb1vni4amf6dhl5cr50r-libpulseaudio-10.0/lib/pulseaudio/
libpulsecommon-10.0.so (0x7fae89919000)
   libsndfile.so.1 =>
/nix/store/sg8zh61a68nmvc7wkqzhdznbr2pv8w2n-libsndfile-1.0.27/lib/libsndfile.so.1
(0x7fae896a)
   libFLAC.so.8 =>
/nix/store/wham49h9mpb0cz61y9qpg573cbc2xil1-flac-1.3.2/lib/libFLAC.so.8
(0x7fae89447000)
   libvorbisenc.so.2 =>
/nix/store/sl3llmcfwizk5rvm7hxqlm3bwiw1igw3-libvorbis-1.3.5/lib/libvorbisenc.so.2
(0x7fae8919d000)
   libvorbis.so.0 =>
/nix/store/sl3llmcfwizk5rvm7hxqlm3bwiw1igw3-libvorbis-1.3.5/lib/libvorbis.so.0
(0x7fae88f71000)
   libogg.so.0 =>
/nix/store/lp127pirk7scs83pfdrjki9igpap9584-libogg-1.3.2/lib/libogg.so.0
(0x7fae88d6a000)
   libdbus-1.so.3 =>
/nix/store/21akz9yprm9blkjkgb2lrzx6hh13kfzp-dbus-1.10.16-lib/lib/libdbus-1.so.3
(0x7fae88b1a000)
   libsystemd.so.0 =>
/nix/store/8qm6wqd3ya2n3d8kijq666y6573sqx02-systemd-232-lib/lib/libsystemd.so.0
(0x7fae8bfac000)
   libpcre.so.1 =>
/nix/store/70y018kangkrrxr6iv8mmh3ar9kq5jj8-pcre-8.40/lib/libpcre.so.1
(0x7fae888a7000)
   libcap.so.2 =>
/nix/store/k59ifmyjdhbw7fr2g96b0rnsqnp27h3a-libcap-2.25-lib/lib/libcap.so.2
(0x7fae886a2000)
   librt.so.1 =>
/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/lib/librt.so.1
(0x7fae8849a000)
   libX11.so.6 => /run/opengl-driver/lib/libX11.so.6
(0x7fae8815a000)
   libxcb.so.1 =>
/nix/store/6yr132cr98716pc7rpzsafzcbxqa3670-libxcb-1.12/lib/libxcb.so.1
(0x7fae87f32000)
   libXau.so.6 =>
/nix/store/rjckhm7wf7n9m709c1zi41yzgdcm8lrz-libXau-1.0.8/lib/libXau.so.6
(0x7fae87d2e000)
   libXdmcp.so.6 =>
/nix/store/7sl3vk0fmzw7390j4v4kxvg0jkrn46kn-libXdmcp-1.1.2/lib/libXdmcp.so.6
(0x7fae87b28000)
   libresolv.so.2 =>
/nix/store/izxnyg94352qxa4a4783dzgnpy5cwazj-glibc-2.25/lib/libresolv.so.2
(0x7fae87912000)
   liblzma.so.5 =>
/nix/store/cgp591zh14lhh1mnp6rm3kw0qlkr55ip-xz-5.2.2/lib/liblzma.so.5
(0x7fae876ec000)
   liblz4.so.1 =>
/nix/store/0fxa061fb7p08p27gii4riyxr25v8yz1-lz4-131/lib/liblz4.so.1
(0x7fae874da000)
   libgcrypt.so.20 =>

Re: [Nix-dev] Banning people from the mailinglist?

[Oliver Charles]

Matthias Beyer  writes:

> We had the systemd conversation endless times now.
>
> We all know that some people don't like systemd and other ones like 
> it.
>
> Can we just ban the (non-constructive) "fuck systemd" people? I 
> mean... nobody benefits from this kind of behaviour and it creates 
> frustration all over the place. Nobody gets happy with these kind of 
> messages.
>
> How to deal with this? I propose one "Please leave us alone with your 
> hate, we know about the concerns and blah, but please let it be" and 
> after that banning the user.

I hate to be that guy, but I think this is really pointing towards a
need for some form of Code of Conduct - if you want to go down the route
of someone making such decisions. I say that, because my immediate
reaction to your comment is: when do we ban? Is it literally for saying
"fuck systemd"? I assume it's not. So it requires a decision process.

Whether or not there is a need for a Code of Conduct, I would like at
least a transparent process into bans.

> Is there a technical possibility for this?

In the meantime, your mail client should have the ability to bin any

mail from particular people, which might be enough to let you carry on
without the noise.

-- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nix-store --repair doesn't seem to be repairing

[Oliver Charles]

Unfortunately I am still stuck in the same situation - verify is unhappy,
but repair does nothing.

Does anyone else have any ideas?

On Tue, Mar 14, 2017 at 5:41 PM obadz <obadz-...@obadz.com> wrote:

> Ollie, you may want to try this procedure if indeed sqlite is corrupted:
> https://github.com/NixOS/nix/issues/995#issue-167190248
>
> On Mar 14, 2017 10:26 AM, "Christian Kauhaus" <k...@flyingcircus.io> wrote:
>
> Am 14.03.2017 um 00:18 schrieb Oliver Charles:
> > Hmm, how did you reach that conclusion?
>
> Re-downloading from a trusted source (cache.nixos.org) gives the same
> "incorrect" checksum again. Of course it could be possible that the file is
> corrupted on cache.nixos.org, but following the "select isn't broken"
> rule[1] I would start to search elsewhere. This is just a suspicion not a
> hard proof. Perhaps you get the checksum errors due to something completely
> different.
>
> BR
>
> Christian
>
> [1] https://pragprog.com/the-pragmatic-programmer/extracts/tips
>
> --
> Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0
> Flying Circus Internet Operations GmbH · http://flyingcircus.io
> Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
> HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick
>
>
> ___
> 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] Google Summer of Code 2017

[Oliver Charles]

On Wed, Mar 15, 2017 at 12:47 PM Domen Kožar  wrote:

> We aren't participating in GSOC 2017, because I missed the submission
> deadline.
>
>
> That being said, I know people will be disappointed by this. I'm sorry,
> I have no excuses really. I was overworked at that time and totally forgot
> to watch the dates.
>
> I already applied us two times, I hope I'll gather the energy to try again
> next year.
> But since I screwed up this year, someone else can take over if wanted,
> I understand not to be trusted :)
>

As Thomas said, no hard feelings - this is not your fault! There's always
next year :)

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS 17.03 Beta, 16.09 Security Support Timeline

[Oliver Charles]

Linus Heckemann <a...@sphalerite.org> writes:

> On 09/03/17 10:26, Oliver Charles wrote:
>> sudo: /run/current-system/sw/bin/sudo must be owned by uid 0 and have
>> the setuid bit set
>
> Are you just adding sudo to systemPackages rather than using the option
> security.sudo.enable?

Nope, I'm using security.sudo.enable = true;

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nix-store --repair doesn't seem to be repairing

[Oliver Charles]

Hmm, how did you reach that conclusion?

On Mon, Mar 13, 2017 at 8:48 AM Christian Kauhaus <k...@flyingcircus.io>
wrote:

> Am 12.03.2017 um 20:07 schrieb Oliver Charles:
> > Any idea what's going on here?
>
> Looks like the corruption is rather in the sqlite than in the tree. No
> idea how to fix this, though.
>
> Regards
>
> Christian
>
> --
> Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0
> Flying Circus Internet Operations GmbH · http://flyingcircus.io
> Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
> HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Nix-store --repair doesn't seem to be repairing

[Oliver Charles]

Any idea what's going on here?

➜  ~ sudo nix-store --verify-path
/nix/store/2s0mb3dfp8bjmdckmzfp1vr3w3kr8s4v-gdbm-1.12

~
path ‘/nix/store/2s0mb3dfp8bjmdckmzfp1vr3w3kr8s4v-gdbm-1.12’ was modified!
expected hash
‘84e441a23c8487315633fcd4a609cb4cb6044c0e82e0c98851fe155a1ae79568’, got
‘1b2101d3abb7
ea991b5c72e9746163551560f3c6a173161a4dae61eb811f77e3’

➜  ~ sudo nix-store --repair-path
/nix/store/2s0mb3dfp8bjmdckmzfp1vr3w3kr8s4v-gdbm-1.12

~
fetching path ‘/nix/store/2s0mb3dfp8bjmdckmzfp1vr3w3kr8s4v-gdbm-1.12’...

*** Downloading ‘
http://cache.nixos.org/nar/1b9hwwq4vmzhyc4mb9pml8nwy2zb8zcj9bzm5f5s2bl8nyarinkv.nar.xz’
to ‘/nix/store/2s0mb3dfp8bjmdckmzfp1vr3w3kr8s4v-gdbm-1.12’...
 % Total% Received % Xferd  Average Speed   TimeTime Time
 Current
Dload  Upload   Total   SpentLeft
 Speed
100  132k  100  132k0 0   464k  0 --:--:-- --:--:-- --:--:--
 465k

➜  ~ sudo nix-store --verify-path
/nix/store/2s0mb3dfp8bjmdckmzfp1vr3w3kr8s4v-gdbm-1.12

~
path ‘/nix/store/2s0mb3dfp8bjmdckmzfp1vr3w3kr8s4v-gdbm-1.12’ was modified!
expected hash
‘84e441a23c8487315633fcd4a609cb4cb6044c0e82e0c98851fe155a1ae79568’, got
‘1b2101d3abb7
ea991b5c72e9746163551560f3c6a173161a4dae61eb811f77e3’
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nixpkgs > 100k commits

[Oliver Charles]

Bas van Dijk  writes:

> Dear all,
>
> FYI the nixpkgs repository[1] just went over 100.000 commits!

But Git doesn't scale to large repositories! :screaming face emoji:
repeated for emphasis. Oh wait, we seem to be doing just fine.

Congrats everyone, this is a great milestone!

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Shutting down prs.nix.gsc.io

[Oliver Charles]

If you would like any help covering this bill, I'd be happy to contribute.
You're doing amazing work and there's no reason you should be out of money
for this. In an alternative reality people get paid to write code, you
know! ;)

On Wed, 1 Feb 2017, 8:23 am zimbatm,  wrote:

> Ouch. How much is "very very"? Try to talk to the Amazon support, they
> might help you with the bill. Happy to chip in as well.
>
> As for the reason, it's probably because the machines are hosted outside
> of AWS and constantly pulling from S3. Amazon has outrageous egress
> pricing. You will probably be better off setting up a S3-compatible storage
> like ceph.
>
> On Tue, 31 Jan 2017, 20:11 Graham Christensen,  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Well, it has been a good run. Having the space to experiment and try a
> few things was very good. As of a few minutes ago, I have removed all
> the nodes from the hydra master.
>
> WHY? I got my Amazon S3 bill, and it was very, very expensive, even for
> half a month.
>
> WHAT IS NEXT? I'm working with Eelco to move the GitHub pull request
> triggering and the amazingly capable build machines in to
> hydra.nixos.org.
>
> Sorry for the short notice! I hope we have the PR building system
> transfered over very soon.
>
> Thank you,
> Graham Christensen
>
>
>
> -BEGIN PGP SIGNATURE-
>
> iQIcBAEBCAAGBQJYkO9bAAoJEAYSHTZv6UNcPQwP/2zCZFP46jNtYMIVlynnrprj
> gp1u3Z7YZ7HzyEqwHx2qhTVz6WV2ZRC/UWYYjz114dLnfDjhtSmjFfuV28uCiqhz
> f/Cu8iSEdOdL6i0CTfFpN2QM/DD2jAIpbCdnGB7aiz6FPEEViHAhn+KZ66SMoOMu
> BVOhii1/oRl1jB/zClRnSYdbsLVgA2bRSjIFApWWwPGueQ0UNji7tkWx5ruRoRU7
> TripLT74Rn5EVYnUVG/s4N9EsaEvf6ObXM2f0XaIJNE0eMk3REM/ZHrdK+izlHlR
> uJk3IUZpKkcrhMmNO42OjTStpKYUXzJ8JbgtRfgViwTi+HjZCNhGugrR+t5USUNX
> 4c2rW8g2JrN61r3yP4T/8fcVOCEBUl1YYFGHd9kc1lbdveBeotk0iHQI8633WsuP
> pZX+kRIr1mOU7pl0m2esD9J34rlFam+SZAcgeOKgTYDc+1yBTw9GYoZaeux4uvN0
> 3PidY4iStx/qgK5LZDbUz8Bdxq6vqPXouwYuwNDWAA6FaPjn5BI3YkYj0LmsMPcL
> DZS5X6pzt8YDzVeuRcLI48cfBtv6YS7um5zbj0ePSq2K5Tbi6C/2dZQI90CkJlC0
> NocZM8rwURtusLsYZhM6YN/Y+vbh8xhfJ85U12ygajg2FPddkJCDQjM35GUo7rws
> ZfL5Phb6rNyagRZwtc2i
> =yaEh
> -END PGP SIGNATURE-
> ___
> 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-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] List of companies using NixOS (Sander van der Burg)

[Oliver Charles]

We use Nix at https://circuithub.com/ for builds using Hydra, and deploying
the build binaries to our Heroku servers.

- Ollie

On Wed, Dec 7, 2016 at 9:15 PM Thomas Bereknyei  wrote:

> I'm investigating using NixOS/NixOps/Disnix for quick prototypes as part
> of Department of Defense. (www.dds.mil) I'd like to learn more about
> others using Disnix/Hydra.
>
> -Tom
>
> Date: Wed, 7 Dec 2016 16:28:45 +0100
> From: Sander van der Burg 
> To: Vladim?r ?un?t 
> Cc: nix-dev 
> Subject: Re: [Nix-dev] List of companies using NixOS
> Message-ID:
>  j20xatrksuslcmbech7ja2xdtpyvlzua64l...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> At conference compass (http://conference-compass.com), we're using Hydra
> (e.g. for mobile app builds and internal projects) as well as NixOps +
> Disnix for backend deployment.
>
> On Wed, Dec 7, 2016 at 4:10 PM, Vladim?r ?un?t  wrote:
>
> > There were some companies presenting at NixCon - from the top of my
> > head: Intel, some hedge fund (@copumpkin) and surely some I don't
> > recall ATM.
> >
> > --Vladimir
> > ___
> > 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-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] 16.09 beta released

[Oliver Charles]

I'm not having any luck here. Mine freezes during init with both unfree ATI
drivers and the open source drivers :/ haven't had a chance to look further
yet though I'm afraid, but it's unusable for me.

Ollie

On Mon, 12 Sep 2016, 9:30 a.m. Tomasz Czyż,  wrote:

> Domen,
>
> so far, everything is working for me.
>
> Would be nice to add news on nixos.org page (last news is about nixops
> 1.4 release, and previous about nixos 16.03)
>
> 2016-09-12 9:28 GMT+01:00 Domen Kožar :
>
>> This release is pretty quiet so far.
>>
>> I wonder if that means most of things work or do we need a more broader
>> call of more testing?
>>
>> Please report back your findings - thanks!
>>
>> On Tue, Sep 6, 2016 at 10:51 PM, zimbatm  wrote:
>>
>>> Thanks for coordinating the release Domen!
>>>
>>> On Tue, 6 Sep 2016, 21:17 Tomasz Czyż,  wrote:
>>>
 Cheers!

 2016-09-06 21:02 GMT+01:00 Domen Kožar :

> Hi all,
>
> I'd like to announce NixOS 16.09 beta in the name of community.
>
> This release will bring two major changes:
>
> - multiple outputs, reducing runtime closure size (sometimes even by
> half)
> - security hardening flags
>
> Please upgrade channels as usual and test:
>
> $ nix-channel --add https://nixos.org/channels/nixos-16.09 nixos
> $ nixos-rebuild switch --upgrade
>
> I'd like to point out two serious bugs that you might hit:
>
> - dbus will fail to reload, see
> https://github.com/NixOS/nixpkgs/issues/18358
> - make sure /var/empty doesn't have write permissions set otherwise
> sshd won't start, see https://github.com/NixOS/nixpkgs/pull/18365
>
> If you'd like to help out, test and check the github bug tracker under
> 16.09 milestone.
>
> As usual, we're working on getting build failures down:
> https://github.com/NixOS/nixpkgs/issues/18209
>
> Final is set to be release on 29th September.
>
> I've also finally put together a PR that documents the release
> process, any feeback is welcome (it's still far from perfect):
> https://github.com/NixOS/nixpkgs/pull/18062
>
> PS: 16.09-small channel will be also created once container tests are
> fixed
>
> Domen
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>


 --
 Tomasz Czyż
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

>>>
>>
>
>
> --
> Tomasz Czyż
> ___
> 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] Too many open issues

[Oliver Charles]

Agreed.

But if the problem is you think old issues are skewing the results/making
it hard to find the signal, then can't you just use more intelligent search
filters? E.g., things created in the past 3 months.

On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra 
wrote:

> Hi,
>
> On 07/22/2016 09:06 AM, Wout Mertens wrote:
>
> > We have 1238 open issues and 286 open PRs.
> >
> > That is just too much to reason about.
> >
> > How about using something like https://github.com/twbs/no-carrier which
> > auto-closes after 14 days of inactivity, and reopens on a new comment?
>
> There is something to be said for auto-closing issues after a long time
> (e.g.
> Fedora auto-closes inactive issues from CURRENT-2 releases ago), but 14
> days is
> wy to short. Bugs don't disappear after 14 days...
>
> --
> 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
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Oliver Charles]

What does the number 0 bring us if there are in reality still hundreds of
issues?

On Fri, 22 Jul 2016, 8:06 a.m. Wout Mertens,  wrote:

> We have 1238 open issues and 286 open PRs.
>
> That is just too much to reason about.
>
> How about using something like https://github.com/twbs/no-carrier which
> auto-closes after 14 days of inactivity, and reopens on a new comment?
>
> I'm sure that if we have close to 0 open issues/PRs, there will be a
> greater incentive to bring that number to 0…
> ___
> 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] 5da05e: bluejeans: 2.160.49.8 -> 2.160.63.8

[Oliver Charles]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 5da05eef62999580664339c5461971c97ae23a39
  
https://github.com/NixOS/nixpkgs/commit/5da05eef62999580664339c5461971c97ae23a39
  Author: Kranium Gikos Mendoza <kran...@gikos.net>
  Date:   2016-07-10 (Sun, 10 Jul 2016)

  Changed paths:
M 
pkgs/applications/networking/browsers/mozilla-plugins/bluejeans/default.nix

  Log Message:
  ---
  bluejeans: 2.160.49.8 -> 2.160.63.8


  Commit: 65ac26e28a9191cb95410832e2272a1fe1d910e9
  
https://github.com/NixOS/nixpkgs/commit/65ac26e28a9191cb95410832e2272a1fe1d910e9
  Author: Oliver Charles <ol...@ocharles.org.uk>
  Date:   2016-07-11 (Mon, 11 Jul 2016)

  Changed paths:
M 
pkgs/applications/networking/browsers/mozilla-plugins/bluejeans/default.nix

  Log Message:
  ---
  Merge pull request #16841 from womfoo/bump/bluejeans-2.160.63.8

bluejeans: 2.160.49.8 -> 2.160.63.8


Compare: https://github.com/NixOS/nixpkgs/compare/05bdc0c89f86...65ac26e28a91___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 5ee480: fish: 2.3.0 -> 2.3.1

[Oliver Charles]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 5ee480bce5bed9a4597f6d0f90d8b6de352a22bd
  
https://github.com/NixOS/nixpkgs/commit/5ee480bce5bed9a4597f6d0f90d8b6de352a22bd
  Author: Louis Taylor <lo...@kragniz.eu>
  Date:   2016-07-11 (Mon, 11 Jul 2016)

  Changed paths:
M pkgs/shells/fish/default.nix

  Log Message:
  ---
  fish: 2.3.0 -> 2.3.1


  Commit: e75332dd7e96f8ad33d9e7130b2f977071763c29
  
https://github.com/NixOS/nixpkgs/commit/e75332dd7e96f8ad33d9e7130b2f977071763c29
  Author: Oliver Charles <ol...@ocharles.org.uk>
  Date:   2016-07-11 (Mon, 11 Jul 2016)

  Changed paths:
M pkgs/shells/fish/default.nix

  Log Message:
  ---
  Merge pull request #16855 from kragniz/fish-2.3.1

fish: 2.3.0 -> 2.3.1


Compare: https://github.com/NixOS/nixpkgs/compare/0f96c6902615...e75332dd7e96___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Stackage Support Will Be Discontinued

[Oliver Charles]

I pin my Haskell packages by using fetchFromGitHub with a specific nixpkgs
revisions, and then import the result. The only downside is the Haskell
packages linking against things like OpenSSL as you say wouldn't get
patched.

On Wed, 8 Jun 2016, 8:58 p.m. Teo Klestrup Röijezon, 
wrote:

> So there will no longer be a way to pin Haskell dependencies? That's a bit
> annoying. I can understand the desire to keep security-critical packages
> like OpenSSL and user-facing tools like git-annex up to date, but at the
> same time there are many non-critical dependencies that I wouldn't want to
> go back and patch my one-off deployments for updates of.
>
> The old way is/was certainly not perfect, but at least it provided a
> mostly-stable target that I could pretty much forget about after deployment.
>
> On 8 June 2016 at 13:34, Peter Simons  wrote:
>
>> Fellow Haskell Hackers,
>>
>> once the LTS 7.x package set comes out, I intend to make the following
>> changes in "master":
>>
>>  - All haskell.packages.lts.* package sets will disappear.
>>
>>  - haskellPackages will loosely follow the most recent LTS release,
>>
>> where "loosely" means that we'll honor the mandated version bounds for
>> libraries but tend to ignore them for executables.
>>
>> Nixpkgs has shipped every single LTS Haskell version ever released as
>> well as an up-to-date copy of the Stackage Nightly package set for the
>> last 9 months or so, and during that time we've gained insights that
>> suggest this practice is an ineffective use of our resources [1].
>>
>> 1. It's pointless to distribute LTS Haskell version x after the release
>> of version x+1.
>>
>> Stackage does not "maintain" any of its LTS releases. Rather, the
>> Stackage volunteers compile a list of package versions, test and verify
>> them to the best of their abilities, release that list, and then they
>> never touch it again. For example, there won't be any update to LTS
>> Haskell 5.4. That update comes in the form of a new package set called
>> LTS 5.5. So if LTS 5.4 happens to recommend a package that has a serious
>> problem, then that problem will remain there forever. So what is the
>> point of distributing LTS 5.4 after the release of 5.5? Apparently,
>> Stackage intends LTS 5.5 to *replace* the previous version, so isn't
>> that what we should do, too?
>>
>> Furthermore, a major release like LTS Haskell 5.x receives no updates
>> either after LTS 6.x has comes out, so by the same logic there is no
>> point in distributing LTS 5.x after LTS 6.x has become available.
>> Contrary to what the name suggests, LTS versions have no guaranteed
>> lifetime or support cycle. Stackage does not offer any "long-term
>> support" in the sense distributions use the word. "Releases" are merely
>> names for tested snapshots of a project that essentially follows a
>> rolling release model.
>>
>> 2. Following LTS strictly may deprive us of important security updates.
>>
>> Whether a package update goes into a minor LTS release or not depends on
>> whether that update increments the first or second segment of its
>> version number. 6.1.1 -> 6.1.2 will make it, but 6.1.1 -> 6.2 won't.
>> That is a pretty good rule based on the assumption that all LTS
>> contributors follow it, which -- as you will have guessed -- is not the
>> case. The tool git-annex, for example, uses version numbers that have
>> only two levels: .. Due to that scheme, git-annex updates
>> aren't considered for minor LTS releases, which means that security
>> relevant fixes don't reach LTS users until the next major LTS release
>> [2].
>>
>> 3. Stackage Nightly is not a stable package set.
>>
>> Our main package set, haskellPackages, corresponds to Stackage Nightly.
>> We made that choice assuming that it would guarantee us a good mixture
>> of a stable user experience on one hand and an up-to-date packages on
>> the other. Recent experience has shown, however, that Stackage Nightly
>> *will* break some of its packages knowingly on the occasion: the Nightly
>> package set recently moved to GHC 8.0.1, but a handful of libraries and
>> applications blocked that (desirable) update. At that point one would
>> expect people to postpone the compiler update, but what happened instead
>> is that the troublemakers were simply removed from Stackage [3].
>>
>> Now, that is a perfectly legitimate decision to make, it just had the
>> unfortunate side effect of breaking all those builds for users of
>> Nixpkgs in the process, so arguably following Stackage Nightly with our
>> main package set might be a bad idea.
>>
>> 4. Stackage does not provide a stable users experience for Nixpkgs.
>>
>> Stackage releases come out only after a complete test build of all
>> packages has succeeded. Unfortunately, those tests don't always catch
>> all issues we might run into, because we compile packages in a different
>> environment. Stackage builds on Travis-CI using 64-bit Ubuntu Linux with
>> static linking. 

[Nix-commits] [NixOS/nixpkgs] b3acd8: ghc801.MonadCatchIO-transformers: jailbreak

[Oliver Charles]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b3acd8ca3956f888643de91282181656ff48c3fc
  
https://github.com/NixOS/nixpkgs/commit/b3acd8ca3956f888643de91282181656ff48c3fc
  Author: Oliver Charles <ol...@ocharles.org.uk>
  Date:   2016-05-23 (Mon, 23 May 2016)

  Changed paths:
M pkgs/development/haskell-modules/configuration-ghc-8.0.x.nix

  Log Message:
  ---
  ghc801.MonadCatchIO-transformers: jailbreak


___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] NixOps - secret/credentials management

[Oliver Charles]

You're right! I didn't entirely think that one through, shouldn't reply to
emails before my morning cup of coffee ;)

Ollie

On Thu, May 12, 2016 at 9:48 AM Peter Simons  wrote:

> Hi Oliver,
>
>  > One option is to introduce these credentials as parameters to your
> network
>  > evaluation:
>  >
>  > { secretCertificate }:
>  > {
>  >   web = { ... } : ...
>  > }
>  >
>  > Then you will need to set this parameter when you do deployments in
> order to
>  > evaluate the network expression and perform deployments.
>
> I am sorry if I'm missing something terribly obvious, but I wonder how
> that helps getting the secret onto the deployed machines without having
> it added to the Nix store? You cannot say something to the effect of
> "store that information in /etc/my-secret" without going through a Nix
> derivation somewhere, can you?
>
> Best regards,
> Peter
>
> ___
> 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] NixOps - secret/credentials management

[Oliver Charles]

Hi Tomasz,

One option is to introduce these credentials as parameters to your network
evaluation:

{ secretCertificate }:
{
  web = { ... } : ...
}

Then you will need to set this parameter when you do deployments in order
to evaluate the network expression and perform deployments. You could
easily script this and interactively prompt the user, or maybe use GPG to
decrypt an encrypted file for the values at deployment time.

Hopefully that gives you some ideas,
Ollie

On Thu, May 12, 2016 at 12:57 AM Tomasz Czyż  wrote:

> Hi all NixOps users and devs.
>
> I wanted to deploy some secrets/certificates to machines and I'm not sure
> how to do that. I would like to avoid storing those in nix store. Is there
> any way to deploy secrets to machines and not use nix store?
>
> I know there is solution to deploy disk encryption keys which is stored in
> state file, but what about other secrets? Is there any general way to
> handle that?
>
> I thought that I could do that using "nixops ssh" feature, but I would
> like to describe those credentials in network.nix file, is that possible?
> ___
> 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] a36f72: bluejeans: 2.125.24.5 -> 2.155.17.5

[Oliver Charles]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: a36f721630479fddeed3fd1e28966a2beda4d3d0
  
https://github.com/NixOS/nixpkgs/commit/a36f721630479fddeed3fd1e28966a2beda4d3d0
  Author: Kranium Gikos Mendoza <kran...@gikos.net>
  Date:   2016-05-11 (Wed, 11 May 2016)

  Changed paths:
M 
pkgs/applications/networking/browsers/mozilla-plugins/bluejeans/default.nix

  Log Message:
  ---
  bluejeans: 2.125.24.5 -> 2.155.17.5


  Commit: e8b3184895aba2ade83aa7f91d86fed5e3fde7f3
  
https://github.com/NixOS/nixpkgs/commit/e8b3184895aba2ade83aa7f91d86fed5e3fde7f3
  Author: Oliver Charles <ol...@ocharles.org.uk>
  Date:   2016-05-11 (Wed, 11 May 2016)

  Changed paths:
M 
pkgs/applications/networking/browsers/mozilla-plugins/bluejeans/default.nix

  Log Message:
  ---
  Merge pull request #15387 from womfoo/bluejeans

bluejeans: 2.125.24.5 -> 2.155.17.5


Compare: https://github.com/NixOS/nixpkgs/compare/e7ab828da14b...e8b3184895ab___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Source URL breakage – please can we improve the determinism

[Oliver Charles]

On Sun, 8 May 2016, 1:19 a.m. J. R. Haigh,  wrote:

> Dear Nix project leaders,
> I don't find NixOS to be very deterministic at all, and it's
> nearly always for the same reason: source files on random servers scattered
> across the Internet going walkabouts.
>

While I agree this is a problem, this is not a problem with determinism. If
the source code can't be found as it is expected, then the build fails -
that *is* deterministic.

Please can we have all source files hosted by the Nix project and
> all source URLs in nixpkgs and nixpkgs-channels replaced or accompanied by
> the Nix-hosted copies. Ideally there should be a way to specify multiple
> URLs for each source file, so both the original and the Nix-hosted
> locations can be specified, as well as any other mirrors if there are any.
>

We do have the mirror:// scheme which knows to look in many locations, but
I imagine the source you're referring to is not mirrored?

Ollie
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] break purity

[Oliver Charles]

I'm afraid I don't really know what I'm looking at. Can you provide a
smaller self-contained example that I can look at?

On Sat, Apr 23, 2016 at 8:48 PM stewart mackenzie 
wrote:

> Okay, I'm having a few problems implementing this, if you wouldn't
> mind taking a look at this please:
>
> This is the package level default.nix which calls
> `buildFractalideComponent`: http://nixpaste.lbr.uno/ZTwRzV0-?nix
> Typically found here:
>
> https://github.com/fractalide/fractalide/blob/master/components/drop/ip/default.nix
>
> Here is the implementation of `buildFractalideComponent.nix`:
> http://nixpaste.lbr.uno/GmbsNjmk?nix
> Found here:
> https://github.com/fractalide/fractalide/blob/master/build-support/buildFractalideComponent.nix
>
> Here's my error message:
>
> [stewart@rivergod:~/dev/fractalide/fractalide]$ nix-build --argstr
> debug true -A components.drop_ip
> error: value is a function while a set was expected, at
>
> /home/stewart/dev/fractalide/fractalide/components/drop/ip/default.nix:15:21
> (use ‘--show-trace’ to show detailed location information)
>
> The error arises on the last line of default.nix
>
> /sjm
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] break purity

[Oliver Charles]

It's certainly possible, because I just did it with Haskell ;)

https://gist.github.com/ocharles/cbd5d7ce63bb570abb86e655f36435ab

On Fri, Apr 22, 2016 at 7:16 PM stewart mackenzie 
wrote:

> Yeah, I'm not so sure it's possible because one cannot copy from a
> precompiled derivation output to a new derivation output, ie copy
> cross derivation.
>
> As these multiple outputs (outputs = [x y z]) are seen as different
> derivations, this cannot happen right?
>
> Have you actually managed to make progress beyond the copying part of
> your example (preConfigure = "cp ${artefacts}/* .'';) in your
> experimentation?
>
> (I'm still thought experimenting)
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] break purity

[Oliver Charles]

Well you don't tie the knot in the expression itself. It's more that the
pre-existing artefacts are a function input, and a function output:

{ stdenv, gcc, etc, artefacts ? null }:
{
  preConfigure = "cp ${artefacts}/* .'';
  outputs = [ "out" "artefacts" ];
}

Then you would nix-build to produce binaries and an artefacts directory.
Subsequent nix-builds would then use nix-build --arg 'artefacts'
'./results-artefacts'.

Handwaving, but hopefully that helps clarify.
ocharles

On Fri, Apr 22, 2016 at 5:35 PM stewart mackenzie 
wrote:

> Interesting Oliver, though this sounds like it'll throw a recursive
> error. I'll investigate! cheers!
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] break purity

[Oliver Charles]

Something I'm experimenting with here is to actually have these
intermediate artefacts be explicitly captured. I would use multiple outputs
to have both the normal complete binaries, and another output for .o files
and the like. Then you can feed this back in to future builds.

Does that help? Might give you some food for thought...
ocharles

On Thu, 21 Apr 2016, 4:42 p.m. stewart mackenzie, 
wrote:

> Hi,
>
> I've got a bunch of artifacts being built in the
> /tmp/nix-build-component_name.drv-0
>
> now I want to point the build manager, in this case cargo using the
> CARGO_TARGET_DIR env var to put the artifacts into a directory I make
> directly in the /tmp/target_${name}
>
> This way any further compilations will reuse the artifacts and they
> won't need to be rebuilt.
>
> obviously nix doesn't allow me to do this.
>
> Is there a dirty hack to allow creating and writing artifacts directly
> to /tmp/target_${name}?
>
> Why? We're using nix as a replacement for make, one major drawback is:
> every time we change a line of code the entire component + trans deps
> needs to be rebuilt. This takes a long time when transitive deps go
> deep.
>
> /sjm
> ___
> 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] Hydra jobs from private git repositories

[Oliver Charles]

I've had luck just doing `sudo -u hydra -i` on the Hydra machine and
setting up id_rsa and friends in ~/.ssh. I think the full path is
/var/lib/hydra/.ssh.

On Fri, Mar 25, 2016 at 3:19 PM Teo Klestrup Röijezon 
wrote:

> Hi,
>
> Is there any support for setting up Hydra jobs with private git
> repositories as build inputs? I generated a SSH keypair each for hydra and
> hydra-queue-runner, and added them both as deploy keys on Bitbucket, but
> the authentication still seems to fail.
> This was using Hydra 32fa3921463cd7688b6b61602cfc707f406b46ae and Nixpkgs
> 90330c27cd62bd009f0973b92c13af6cfddbca19.
>
> Thanks,
> Teo
> ___
> 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] How to use binaries from other hosts?

[Oliver Charles]

On Mon, Mar 14, 2016 at 9:08 AM Matthias Beyer 
wrote:

> Hi,
>
> I'm on nixos unstable. As racket does not build and my thinkpad takes
> hours to
> build it, I got myself a debian VM in my university cloud and compiled
> racket
> there.
>
> How can I retrieve the closure from there?
>
> I tried _everything_. I cannot nix-copy-closure, as this one does not
> allow me
> to set the SSH port (which isn't 22 but something above 1).
>

Can you change the port by adding an entry to .ssh/config? That should
allow you to set the port, and I believe nix-copy-closure just calls SSH.
You might need to use /etc/sshd/config, as I'm not sure what user it's
actually making the ssh connection as.

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] OpenGL and Nix

[Oliver Charles]

The only way I've had luck with NixOS and OpenGL in the past is by building
anything that needs OpenGL against the same set of nixpkgs that the system
is currently *running* as. Maybe that will help?

On Tue, Mar 1, 2016 at 5:01 PM stewart mackenzie  wrote:

> Hi Herwig,
>
> Okay, Herwg, this is what's driving me insane:
>
> https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/mesa/default.nix#L27
>
> Yes, I do not want to link to the stock nix libGL because it has
> STATIC_TLS enabled without which would result in a 10% performance
> hit. So if you're playing hardcore games you want STATIC_TLS.
>
> I on the other hand do not want STATIC_TLS because if I have it
> enabled it throws this error ""SDL error: Failed loading libGL.so.1:
> dlopen: cannot load any more object with static TLS"', hence I need to
> recompile it ensuring no initial-exec (which == STATIC_TLS) is
> enabled.
>
> As I'm running a simple 2D windowing system (conrod) it's more than
> adequate for my needs.
>
> Excellent, much appreciated Herwig.
> ___
> 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] nix out of memory

[Oliver Charles]

What about hidden directories like .git? You can filter these out. And
also, what is du -hsc for the given src directories?

On Mon, Feb 29, 2016 at 1:17 PM stewart mackenzie 
wrote:

> I have 50 instances of `src = ./.` each time the ./. points to the
> root of a rust project with which consists of 4 files one of which is
> in a folder called src.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nix out of memory

[Oliver Charles]

To expand on that, my understanding is that whenever you refer to a local
path, that entire path is loaded and held in memory.

On Mon, Feb 29, 2016 at 12:12 PM Vladimír Čunát  wrote:

> On 02/29/2016 12:47 PM, stewart mackenzie wrote:
> > What is the reason for dumping a very large path (> 256MiB)?
>
> You probably have
>   src = ./some/local/path;
> so if you have some (unneeded) large files under that path...
>
> --Vladimir
>
>
> ___
> 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] Signed git

[Oliver Charles]

You can only point to something if you can sign that pointer. Just telling
me a narinfo without any more information (that is, signing that) puts us
back to square one.

On Fri, Feb 26, 2016 at 10:06 AM Vladimír Čunát <vcu...@gmail.com> wrote:

> On 02/26/2016 09:55 AM, Oliver Charles wrote:
> > Signed SHAs and the like give us a way to say "I am releasing this
> > version, and you have a way to check that 'I' really said it".
>
> We could point to the corresponding narinfo file. For any package
> there's a signature of the build farm.
>
> That is, assuming the ISOs are copied to the binary cache. I briefly
> looked for the latest 15.09 ones, and they seem not to be there:
>  - latest channel revision: 922f03
>  - the build: http://hydra.nixos.org/build/32068791#tabs-summary
>  - http://cache.nixos.org/95c41wi9dqc1si96d4vhigf0p258s1mr.narinfo
>
> --Vladimir
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Signed git

[Oliver Charles]

I don't think S3 is looking for accountability but reproducibility. With
nothing signed it's unclear what you should really be expecting for the
release ISOs. Signed SHAs and the like give us a way to say "I am releasing
this version, and you have a way to check that 'I' really said it".

On Fri, Feb 26, 2016 at 8:51 AM Vladimír Čunát  wrote:

> On 02/26/2016 08:19 AM, S3 wrote:
> > So, as far as I can tell, nothing is signed.
>
> The binary caches are signed by the build farm, i.e. the mapping from
> expressions to binaries is "safe". That's probably the only signing ATM.
> For transporting nix expressions we offer https.
>
> Disclaimer: I'm no security expert. And I dislike giving a false feeling
> of security.
>
> Note that we have >70 people with push access to nixpkgs. Those are
> random people who contributed larger parts of useful stuff. Even if we
> did sign by a single key that you presumably trust, that person really
> wouldn't be able to guarantee that the contents hasn't been tampered with.
>
> Getting everyone sign their commits would give us accountability in case
> some of us did something malicious (or github). Would that be a
> significant improvement? I'm not certain, but we might do it as the next
> step.
>
> --Vladimir
>
>
> ___
> 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] How to set up your own Hydra server (video tutorial)

[Oliver Charles]

On Wed, Feb 17, 2016 at 10:25 AM zimbatm  wrote:

> One question that was raised, does anyone know why the hydra modules
> aren't part of nixpkgs ? Any organisation who wants to adopt nixos is going
> to need it's own hydra, the easiest the setup the wider the adoption.
>

I believe there is a plan to have the modules in nixpkgs proper, but it
Hydra doesn't have a release coordinator yet, which is a necessary
pre-requisite. 

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Including binary-only derivation in nixops deploy.

[Oliver Charles]

If you're saying you want to install something knowing only the Nix store
path, you can do:

{ type = "derivation";
  name = "whatever";
  outputName = "out";
  outPath = builtins.storePath "/nix/store/deadbeefdeadbeef"; }

This will attempt to lookup the given store path in binary substitution
servers, and will fail if it can't be found (as Nix has no other way to
provide that output).

Does that help?


On Fri, Feb 12, 2016 at 3:03 AM Kevin Cox  wrote:

> Hello all. I have a possibly strange question but I was hoping that you
> could help me out. I am currently using nixops to manage a couple of
> servers and have a couple custom derivations for personal packages. While
> managing the derivation in my nixops config isn't terrible I wanted to
> manage the derivations in each project so that I can use nix to build the
> project in CI and use nix-shell for development. Another benefit of using a
> binary is that I know that dependencies won't change, and that the package
> has been tested with the exact dependencies it will be shipping to
> production.
>
> So long story short I have uploaded the derivation to a binary cache and I
> was hoping to use it in a nixops deploy. However I can't figure out how to
> get it to work (if it is possible). `nix-store
> -r /nix/store/01kymbkb0a1sc99y72wzn5b4gcjdlbnm-dontsayit-nginx` works fine,
> the package and all of its dependencies are installed to the local store.
> However I can't figure out how to use it in a nixops config.
>
> The naive approach of just including the path in a file (in my case an
> nginx config) doesn't work as it isn't being scanned for that path and the
> dependency doesn't get picked up. Interpolating it as a path also doesn't
> work as the file gets copied from the store and put into the store under a
> different hash, losing all dependency information.
>
> I tried playing around with .drv descriptions but couldn't figure out how
> to get it to work either.
>
> I would appreciate any help or recommendations for alternative solutions.
> ___
> 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] Notes and ideas about the Nix-UI proposal

[Oliver Charles]

On Mon, Jan 25, 2016 at 3:46 PM Thomas Hunger  wrote:

> The most common mistake I make is:
>
> nix-env -iA pythonPackages.ipython
> error: attribute ‘pythonPackages’ in selection path
> ‘pythonPackages.ipython’ not found
> (should be nix-env -iA nixpkgs.pythonPackages.ipython)
>

I don't think `nixpkgs` should be made implicit to these commands, and your
problem can be fixed by changing your NIX_PATH. Your NIX_PATH at the moment
presumably just stops at `/channels`. If you change that to
`/channels/nixpkgs`, then I believe nix-env -iA pythonPackages.ipython will
just work.

ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Notes and ideas about the Nix-UI proposal

[Oliver Charles]

`nix do`? :)

On Sat, Jan 23, 2016 at 4:59 PM Matthias Beyer 
wrote:

> Hi,
>
> On 23-01-2016 17:39:09, Christian Theune wrote:
> >
> > I like the direction where this is going a lot. A big +1 from my side.
>
> Same here.
>
> >
> > As a suggestion to the transactional behaviour, I’d like to avoid
> unnecessary shell quoting. How about “+” instead of “;"? I could imagine
> another non-colliding operator from the nix language, but “;” as a
> statement separator is going to be confusing because bash already uses it
> for almost the same thing.
> >
>
> I want to second this! Especially because "\" is kinda hard to type on
> german
> keyboards (two strokes and a weird location of both keys, ergonomically).
> "+"
> sounds much better.
>
> What would be nice is a "repl"-like thing where you can do this:
>
> nix transaction
> > install firefox
> > uninstall chromium
> > commit  ## or maybe ctrl-D
> [nix] transaction about to be committed... doing things now
>
> (ofc, the `nix install firefox $sep uninstall chromium` variant should be
> available as well)
>
> --
> Mit freundlichen Grüßen,
> Kind regards,
> Matthias Beyer
>
> Proudly sent with mutt.
> Happily signed with gnupg.
> ___
> 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] Flattening pkgs tree in nixpkgs/pkgs

[Oliver Charles]

On Fri, Jan 8, 2016 at 3:53 PM Domen Kožar <do...@dev.si> wrote:

> Going for attribute set names is hard, since we have many aliases.
>
> We had a discussion about this at NixCon (I think Oliver Charles has the
> notes).
>

Yep, I lead that sesison but unfortunately haven't had the bandwidth to
start the discussion (as evidinced by the amount of conversation this
thread has already seen!). I'll try and dig my notes out though soon.
<http://lists.science.uu.nl/mailman/listinfo/nix-dev>

- Ollie
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Which is the best way to reload all network configurations? (dhcpclient etc)

[Oliver Charles]

Does systemctl restart network.target work?

On Thu, Dec 10, 2015 at 10:21 AM Marco Maggesi 
wrote:

> Hi,
>
> I'm not confident with the systemd infrastructure.
>
> Which is the best way to shutdown/restart/reload the whole network
> infrastructure?
> (interfaces, dhcpclient, etc)?
>
> Thanks,
> Marco
> ___
> 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] Publish All of Hackage

[Oliver Charles]

On Fri, Nov 20, 2015 at 1:58 PM Shea Levy  wrote:

> The problem with doing this with import-from-derivation is we still
> need the hashes of every tarball ahead of time (though that's much
> smaller than all of hackage, and we really just need the hash of the
> file that contains all the hashes in nixpkgs itself). If we have that,
> then we don't need to generate all of hackage every time, just the bits
> needed to build the specific requested package.
>

What I would expect is that the "generate Nix expressions" Nix expression -
i.e., the thing that generates what is now hackage-packages.nix - would
have to be given known inputs. As far as I understand, hackage2nix simply
requires a checkouts of
https://github.com/commercialhaskell/all-cabal-hashes and
https://github.com/commercialhaskell/all-cabal-hashes. I would expect that
those could be provided by fetchgit, so updating the set of Haskell
packages simply requires Peter or other commiters to change the pinned Git
revisions.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Publish All of Hackage

[Oliver Charles]

On Fri, Nov 20, 2015 at 1:51 PM Daniel Peebles  wrote:

> The downside of this approach is that generating the entire Haskell
>> package set is actually kind of expensive, and we probably wouldn't want
>> to impose those costs onto random users who just wants to have XMonad
>> for their window manager
>>
>
> Couldn't the derivation we're importing from be cached like any other
> "binary" cache value? I've never checked, but intuitively it seems like it
> would make sense.
>

Yes, this is what I was getting at in my original post:

when I as a user choose to evaluate the set of Haskell packages, I will be
> forced to generate all the Nix expressions - or, this being Nix, ask a
> binary substitution server for that.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Publish All of Hackage

[Oliver Charles]

On Thu, Nov 19, 2015 at 11:14 AM Peter Simons  wrote:


> One issue is that checking that ~50MB file into Nixpkgs might be a bad
> idea, because it sets a dangerous precedent. Arguably, if we check all
> of Hackage into Nixpkgs, then we cannot reasonably say *no* to someone
> who wants to check all of CPAN into Nixpkgs too, and before we know it
> our Git repository triples in size. So it might be wise to put the full
> Hackage variant of hackage-packages.nix into a separate repository that
> we fetch via "builtins.fetchurl" if the corresponding option is enabled.
>

It seems a bit of a shame to me that the current state of the world is that
we are forced to essentially check in a build result into the nixpkgs
repository. The code that you really want to commit is the scripts that
*generate* the 50mb file as some sort of Nix expression. Then, when I as a
user choose to evaluate the set of Haskell packages, I will be forced to
generate all the Nix expressions - or, this being Nix, ask a binary
substitution server for that.

I believe this requires some sort of "hierarchical Nix" or "Nix-in-Nix"
that we don't have, but realistically the approach of checking in huge Nix
expressions does have scaling problems. Not to mention I'm always nervous
of checking in files that should not be edited by humans.

Ollie
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Oliver Charles Talk

[Oliver Charles]

Hi Stewart,

Glad you liked the talk! I will be tidying things up - probably tomorrow -
and publishing a blog post on this, and I should be able to have an
accompanying Github repository of relevant code. Keep an eye on
https://ocharles.org.uk/blog (there are RSS feeds if you use a feed
reader). I'll also get my blog added to the Planet before posting the
article.

Thanks for mentioning boot-nix - while I'm not writing ClojureScript any
more, this will certainly come in handy if I ever come back to it :)

Regards,
Ollie

On Tue, Nov 17, 2015 at 3:56 PM stewart mackenzie 
wrote:

> Hi Oliver,
>
> I'd greatly appreciate it if you could share your cleaned up
> deployment nix scripts for fynder.
>
> You're doing some really cool stuff there which is currently what I'm
> building out here:
>
> github.com/fractalide/nixos-infrastructure
>
> btw I've got a boot-nix which is a boot-clj.com task which enumerates
> clojure/script dependencies then downloads them, hopefully others
> might be interested in that.
>
> https://github.com/fractalide/boot-nix
>
> Thanks for giving that talk!
>
> /sjm
> ___
> 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] Logo improvement ideas

[Oliver Charles]

On Thu, Sep 10, 2015 at 1:35 PM Tim Cuthbertson  wrote:

> If nobody authoritative wants to set up a poll, I can certainly do one :)
> I'm a little bit busy at the moment, but as long as we're not in a hurry...
>
> To prevent overwhelming people with options, and after letting these
> stew for a little while, I'd be happy to limit choices to:
>
> * shapes: just circle and hex. I think circle is strictly better than
> "straight", and I think "slant" is too disorganised / unclean to be a
> winner.
>
> * colours: "feature" and "half". The plain versions are probably too
> boring to bother with.
>
> So that only leaves 4 proposals, across those two axis. I can include
> more if people think it's worth it, but I don't want to overwhelm.
>
> I've made a start here:
>
>
> https://docs.google.com/forms/d/1oMKuPCIz5bmUokrN6mllYpIDH7cmVQTzuZAcUdGH1HM/viewform


Looks like a step in the right direction! I can't think of anything else
I'd add.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Meetup in London ?

[Oliver Charles]

Hi z,

We did have a meetup in London once - I gave a talk which is on YouTube
here: https://www.youtube.com/watch?v=pxRSgjPyvqQ

As NixOS is still fairly niche, we felt it made sense to have the meetup
maybe twice a year. I'm not sure about plans for the next one, but there is
certainly interest!

- Ollie

On Sat, Jul 18, 2015 at 8:32 PM stewart mackenzie setor...@gmail.com
wrote:

 You can take a look at Susan Potter's nix-cookbook
 https://github.com/mbbx6spp/nix-cookbook/tree/add-README

 You could add to that maybe?
 ___
 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] Automount for usb thumb drives / other external drives

[Oliver Charles]

I've packaged udevil and devmon now. When it reaches the channels, you
should be able to just add `services.devmon.enable = true;`, though I
haven't been able to test it as my system config doesn't build against HEAD
as bumblebee-project.org is down...

I can confirm that udevil and devmon at least build though, and can be ran
from the command line.

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nixos service using privileged ports as a non-root user

[Oliver Charles]

I believe the User option in systemd unit configuration should do this. See
the systemd.service man page - all options can be used in NixOS
On 4 Jun 2015 10:05 pm, Ganesh Sittampalam gan...@earth.li wrote:

 Hi,

 I'm adding a service - darcsden - to NixOS that is designed to run as a
 non-root user, but should optionally be able to bind to a privileged
 port. It's not designed to start as root and then fork/drop privileges,
 so I'd like to handle this at the OS level somehow.

 I'm aware of various solutions:


 http://unix.stackexchange.com/questions/10735/linux-allowing-an-user-to-listen-to-a-port-below-1024


 http://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-processes-to-bind-to-privileged-ports-1024-on-l

 Is there any standard/preferred way to do this in NixOS?

 Cheers,

 Ganesh
 ___
 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] Nix loves Haskell: the video

[Oliver Charles]

Great work peti - this will be really useful as another resource to give to
people who want to get started with Haskell and Nix :)

- Ollie

On Sat, May 23, 2015 at 1:07 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk
wrote:

 On 05/22/2015 10:38 PM, Peter Simons wrote:
  Hi folks,
 
  Rok Garbas kindly organized a NixOS meetup in Berlin the other day [1],
  and I used the occasion to talk about Haskell NG. The presentation was
  advertised as:
 
We'll look at how Nix can replace cabal-install in your development
workflow to bring you the power of Hackage without the headaches this
normally implies. The talk is aimed at beginners and assumes little
prior knowledge of Nix or Haskell.
 
  Rok recorded the talk and made the video available here:
 
https://www.youtube.com/watch?v=BsBhi_r-OeE
 
  You'll find the slides at [2] and all sample code snippets are available
  at [3].
 
  I hope you'll find this useful!
 
  Best regards,
  Peter
 
 
  [1] http://www.meetup.com/Berlin-NixOS-Meetup/events/222109058/
  [2] http://cryp.to/nixos-meetup-3-slides.pdf
  [3]
 https://github.com/NixOS/cabal2nix/blob/master/doc/nixos-meetup-3-slides.md
 
  ___
  nix-dev mailing list
  nix-dev@lists.science.uu.nl
  http://lists.science.uu.nl/mailman/listinfo/nix-dev
 

 Interesting. Shame the recording cut off at the questions. I didn't know
 you could nix-env -qaP haskellPackages to display the ng package set: we
 just had a person ask about that in #nixos yesterday!

 I think it would be worthwhile to cross-post this to haskell-café.

 --
 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] Use Haskell for Shell Scripting

[Oliver Charles]

Not sure if you're serious, but the last time we considered even rewriting
the scripts in C, people were mostly against that. However, I guess with
this the major opposition (can't read the source code easily) goes away,
because you can still cat the scripts. However, I'd imagine that the
startup overhead is now higher than bash, and the size of closures goes up
a lot (you have to pull in the many hundreds of MB that GHC needs).

So while it's a nice idea, I don't think it's practical to be done system
wide - though I'm all for doing it locally!

-- ocharles

On Fri, Jan 30, 2015 at 4:02 PM, Joe Hillenbrand joehil...@gmail.com
wrote:

 http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html

 Time to replace all shell scripts in Nix with Haskell?

 ___
 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] A Journey into the Haskell NG infrastructure: Part I

[Oliver Charles]

This looks really good! Nice work :)

-- ocharles
On 10 Jan 2015 15:19, Peter Simons sim...@cryp.to wrote:

 Hi,

   It would be nice to have an example of how to use shell.nix and
   default.nix together.

 starting with Nixpkgs version 11ac18a, you can do the following.

  1) To create an interactive build environment that can compile a local
 Haskell
 project, run:

   $ cabal2nix --shell . shell.nix  nix-shell

 The new shell will be set up with an appropriate ghcWithPackages
 wrapper
 that about knows all dependencies for this package, and required system
 libraries will also be configured to be found without extra parameters
 to
 cabal configure.

  2) For recent Hackage packages, you can do that without using cabal2nix,
 even,
 by running:

   $ nix-shell 'nixpkgs' -A haskellngPackages.hspec.env

 This will give you the same kind of environment as (1), but this time
 the
 environment is setup based on the information we have in Nixpkgs, so
 you
 don't have to generate a cabal file at all.

 To illustrate these points, here is an example session. Note that my user
 has
 no 'ghc':

  | $ ghc
  | The program ‘ghc’ is currently not installed. You can install it by
 typing:
  |   nix-env -i ghc

 Anyway, let's build 'hspec'. First, we get the source code:

  | $ curl
 http://hackage.haskell.org/package/hspec-2.1.2/hspec-2.1.2.tar.gz | tar xz
  |   % Total% Received % Xferd  Average Speed   TimeTime Time
 Current
  |  Dload  Upload   Total   SpentLeft
 Speed
  | 100  5200  100  52000 0  75337  0 --:--:-- --:--:--
 --:--:-- 76470
  |
  | $ cd hspec-2.1.2

 Now enter the build environment based on the package data from Nixpkgs:

  | $ nix-shell 'nixpkgs' -A haskellngPackages.hspec.env

 And compile:

  | [nix-shell:/tmp/hspec-2.1.2]$ ghc --make Setup
  | [1 of 1] Compiling Main ( Setup.lhs, Setup.o )
  | Linking Setup ...
  |
  | [nix-shell:/tmp/hspec-2.1.2]$ ./Setup configure
  | Configuring hspec-2.1.2...
  |
  | [nix-shell:/tmp/hspec-2.1.2]$ ./Setup build
  | Building hspec-2.1.2...
  | Preprocessing library hspec-2.1.2...
  | [1 of 7] Compiling Test.Hspec.HUnit ( src/Test/Hspec/HUnit.hs,
 dist/build/Test/Hspec/HUnit.o )
  | [2 of 7] Compiling Test.Hspec.Formatters (
 src/Test/Hspec/Formatters.hs, dist/build/Test/Hspec/Formatters.o )
  | [3 of 7] Compiling Test.Hspec.Discover ( src/Test/Hspec/Discover.hs,
 dist/build/Test/Hspec/Discover.o )
  | [4 of 7] Compiling Test.Hspec.Runner ( src/Test/Hspec/Runner.hs,
 dist/build/Test/Hspec/Runner.o )
  | [5 of 7] Compiling Test.Hspec.Core  ( src/Test/Hspec/Core.hs,
 dist/build/Test/Hspec/Core.o )
  | [6 of 7] Compiling Test.Hspec   ( src/Test/Hspec.hs,
 dist/build/Test/Hspec.o )
  | [7 of 7] Compiling Test.Hspec.QuickCheck (
 src/Test/Hspec/QuickCheck.hs, dist/build/Test/Hspec/QuickCheck.o )
  | In-place registering hspec-2.1.2...
  |
  | [nix-shell:/tmp/hspec-2.1.2]$ exit
  | exit

 Of course, you can use cabal-install if you happen to have that in your
 user
 profile. I just wanted to show the simplest possible use case that works
 without it.

 I hope this helps,
 Peter

 ___
 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] Announcing support for GHCJS

[Oliver Charles]

Ertugrul Söylemez ert...@gmx.de writes:

 Hi everybody,

 I was going to try it out and found the compiler itself, but couldn't
 figure out how to make a derivation for a JS package.  Is there any
 documentation on that?  If not, in which files should I look?  Something
 like ghcjsWithPackages and cabal.mkJsDerivation would be great.

 Nevermind, I think I got it.

Could you update this thread with your solution, for posterity?

-- ocharles


signature.asc
Description: PGP signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Breaking changes log

[Oliver Charles]

One thing I really like is Gentoo's news feature - which seems to be
discussed in detail at http://wiki.gentoo.org/wiki/GLEP:42. Maybe something
like that is what you're envisioning?

-- ocharles

On Wed, Dec 17, 2014 at 1:27 PM, Wout Mertens wout.mert...@gmail.com
wrote:

 Would it be nice if we kept a file with breaking changes?

 That way, nixos-rebuild should be able to list the breaking changes
 between the current version of the channel and the last time the system was
 built.

 We'd also have the full list of breakage for release notes.

 Thoughts? What would such a log look like?

 Cheers,

 Wout.

 ___
 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] What does `self` mean in the function `ghcWithPackages`?

[Oliver Charles]

On Tue, Dec 16, 2014 at 11:01 AM, Vladimír Čunát wrote:

 On 12/16/2014 03:30 AM, Carlo Nucera wrote:

 In the line `packages = pkgs self;` what does `self` refer to?


 Obviously, ``self`` is the parameter of the whole haskell-packages.nix
 top-level function (line 58 in recent master version).


If it was obvious, I don't think Carlo would be asking this question ;)

-- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] force nix-build without binary caches?

[Oliver Charles]

 On Mon, Dec 1, 2014 at 11:21 AM, Domen Kožar do...@dev.si wrote:

 nix-build --option binary-caches 

Rob Vermaas rob.verm...@gmail.com writes:

 Or use (taken from 'man nix.conf'):

build-use-substitutes
If set to true (default), Nix will use binary substitutes if
 available. This option can be disabled to force
building from source.

 E.g. nix-build --option build-use-substitutes false

Another option is to use `nix-biuld --option use-binary-caches false`
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] About 14.11 release

[Oliver Charles]

On Wed, Oct 22, 2014 at 4:42 PM, Eelco Dolstra eelco.dols...@logicblox.com
wrote:

  #739 - meta.license and meta.licenses standardisation - Same here, I
 think
  unless there's any work being done already, it can be delayed.
 
  In my opinion, some other issues / pull requests are release critical:
  #4563 - Xfce mixer applet does not work - This seems like a regression
 from the
  previous stable release
  #4546 - NetworkManager fails to start due to dbus permission issue -
 Definitely
  a regression, not sure what the guy did there though

 NetworkManager has never been a release-critical package IMHO. (Maybe it
 should
 be, but then it will need automated tests at least.)


Do we have a NixOS-official-supported network stack?

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Will there be a systemd replacement at any time in the future?

[Oliver Charles]

I believe at one point the 'jobs' attribute was intended to abstract over
the idea of running a service, but I believe this was mostly dropped as no
one is interested in building our own buggy/limited version of systemd.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nix users going to Haskell Hackathon in Berlin?

[Oliver Charles]

That's fairly easy for me to get to, and I wouldn't mind going to Berlin
again. Hopefully I can make this!

- ocharles
On 14 Jul 2014 18:34, Peter Simons sim...@cryp.to wrote:

 Hi guys,

 does anyone else intend to visit the Berlin Haskell Hackathon?

  | Dear Haskellers,
  |
  | another Haskell Hackathon is waiting for you!
  |
  | Where: Berlin, Germany
  | When:  Fri 26 - Sun 28 September 2014
  |
  | Meet in Berlin, discuss, hack together and improve the Haskell
  | infrastructure. We welcome all programmers interested in Haskell,
  | beginners and experts!
  |
  | For all details, visit our wiki page
  | (http://www.haskell.org/haskellwiki/HacBerlin2014) and make sure to
  | register early.

 I consider going there to do some hacking on cabal2nix or other related
 subjects.

 Best regards,
 Peter

 ___
 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] @nixpkg

[Oliver Charles]

On 30/06/14 00:38, Steven Shaw wrote:
 :). I didn't want to promote the nixpkgs but Nix the package
 (management) system.

Are you aware of https://twitter.com/nixos_org and
https://twitter.com/nixostips ? Is there a need for a third account?

I'm all for more publicity, but there is a risk of fragmenting the
audience, which can be detrimental.

- ocharles




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Writing a Nix evaluator in Haskell

[Oliver Charles]

On 29/06/14 01:03, John Wiegley wrote:
 Since the Nix language is such a nice and simple pure functional language, I
 thought it would be nice to have tooling support for it in Haskell, to aid
 writing lint utilities, etc.

 As such, I've started a project call hnix which will implement a parser and
 evaluator for Nix in Haskell.  I have the parser working for simple
 expressions already (using either Parsec or Trifecta, it works with both).
Weird, I started exactly this project yesterday! I was using
uu-parsinglib, but yours is much further ahead than mine, so I'll ditch
it and try and switch over to yours.

 My first goal is a syntax verification and linting tool; after that to see I
 want to see if I can get an evaluator working for Nix programs.

My goal is not really parsing though, but building Nix files by working
with an AST rather than gluing a bunch of Strings together.

Keep up the good work!
- ocharles



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Using Hydra for all or nothing channels

[Oliver Charles]

Hello,

We've just started trialing Hydra at work and are very impressed with the
results - it's a lovely bit of kit! I feel we'd be able to use it even
better if there was a way to have what I'm calling all or nothing
channels.

We have a jobset that consists of the following jobs:

* frontend - builds the website, minifies scripts, etc
* metronome - compiles a Haskell web server
* fynder - compiles a Haskell library used by the web server
* acceptance-tests - runs end-to-end acceptance tests for the frontend
against metronome.

I'd like to create a channel that contains the `frontend`, `metronome` and
`fynder` packages. The jobset channel gives me exactly this, but
unfortunately the channel is updated too frequently. The jobset channel
updates when *any* job successful builds, irrespective of the other jobs.

I've had a look into `releaseTools.aggregate`, which certainly seems to be
going in the right direction. Now we have a `fynder-stack` job that has the
above 4 jobs as constituents. I was hoping that I could use this as a
channel, but unfortunately this doesn't have anything as build contents.

I suppose what I'm trying to do is a small scale version of the nixos
channels themselves. If I understand correctly, these only get updated if
the `tested` job (which is an aggregate job) passes. Would it be possible
to do this entirely in Hydra without scripting? If it requires scripting,
could anyone show me what listens for success of the `tested` job on
Hydra, so I can try and copy the approach?

Thanks to everyone working on Hydra, looking forward to making it a key
part of our infrastructure!
- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Move to GHC 7.8.2

[Oliver Charles]

I should point out that I've since got everything with working with GHC
7.8, and we've in fact now switched work's compiler to be 7.8.


On Tue, May 27, 2014 at 8:20 PM, John Wiegley jo...@newartisans.com wrote:

  Oliver Charles ollie writes:

  At work, we still can't build with GHC 7.8.2 because various dependencies
  are still broken. However, that's not really the end of the world - I can
  just change our expressions to use haskellPackages_ghc763 rather than
  haskellPackages.

 Just wanted to note that I've been building the Haskell packages I use with
 the following compilers daily (they often all rebuild after nixpkgs
 updates,
 since I use -u --leq):

 GHC 7.4.2
 GHC 7.6.3
 GHC 7.6.3-profiling
 GHC 7.8.2
 GHC 7.8.2-profiling

 So far I've the following not work with 7.8.2 (though things could have
 changed):

 Agda
 cabal2nix
 hasktags
 lambdabot
 threadscope

 The way I work around this is to simply build those specific tools using
 7.6.3, until they are updated to support 7.8.2.

 John
 ___
 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] Move to GHC 7.8.2

[Oliver Charles]

On Wed, May 7, 2014 at 11:54 AM, Peter Simons sim...@cryp.to wrote:

 Hi Oliver,

   At work, we still can't build with GHC 7.8.2 because various
   dependencies are still broken.

 do you have a list of packages that are still causing trouble?


No concrete list because one breakage tends to bring everything down. A
recent one was HsSyck, but I got maintainer rights and have fixed that. We
still have troubles with authenticate-oauth, but that's not 7.8 specific.
But as I said, we'd be happy to depend on an older version in the meantime.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] cannot install java

[Oliver Charles]

This may have been related to nixos.org being down. Maybe try again now and
see if things are better?

- ocharles


On Wed, Apr 16, 2014 at 1:37 PM, Kirill Elagin kirela...@gmail.com wrote:

 Well, it says that hashes didn't match. You can download the file yourself
 and find out what's going on.
 On Apr 16, 2014 12:21 PM, Roelof Wobben r.wob...@home.nl wrote:

  Hello,

 When I want to install opnjdk or icedtea I see this message:

 output path
 `/nix/store/g05g9zypk5km4qc3k980ppjsqy8knphb-icedtea-2.4.5.tar.xz' should
 have sha256 hash `0nrhbn2q7cm21hpq1f5ds0v0rnsznmdyiifi8w4l1ykyqw9n9yfk',
 instead has `14agc12izsyxmp4919g8lx1z03iq6npqyig9g3p40q2cn04rnww8'
 cannot build derivation
 `/nix/store/mf9092kacjj7wajy2gk5iyqrqmxs1w08-icedtea7-2.4.5.drv': 1
 dependencies couldn't be built
 error: build of
 `/nix/store/mf9092kacjj7wajy2gk5iyqrqmxs1w08-icedtea7-2.4.5.drv' failed

 Roelof

 ___
 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-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] lens 4 transition plan?

[Oliver Charles]

Gergely Risko gerg...@risko.hu writes:

 Hi,

 Peter: I saw that you started to upgrade stuff to lens 4, e.g. linear
 1.6 requires it and in nixpkgs lens is now correctly overridden to
 version 4 for that package.

 However I wanted to ask for your transition plan/timeframe regarding
 this change?  Do you plan to switch over to lens4 as default sometime
 and provide overrides for the not forward compatible packages?

 Should we provide patches in nixpkgs where needed to upgrade everything
 to lens4 until they're fixed upstream?

 Asking this, because having both lens3 and lens4 can cause some
 instances to be provided multiple times and that causes some pain.  I
 just ignored linear for now in my system, but I really would like to
 minimize the timespan of the situation where half my packages depend on
 lens3 and the other half on lens4. :)

At work, we override `haskellPackages` to have lens 4 and aeson 0.7. We
have dev.nix files in each project, as such:



with import nixpkgs {};
let haskellPackages = pkgs.haskellPackages_ghc763_profiling.override {
  extraPrefs = self: {
aeson = self.aeson_0_7_0_1;
lens = self.lens_4_0_3;
fynder = self.callPackage ../fynder {};
snapletSocketIO = self.callPackage ../../snaplet-socketio {};
snapCors = self.callPackage ../../snap-cors {};
tempo = self.callPackage ../tempo {};
metronome = self.callPackage ./. {};
fb = lib.overrideDerivation self.fb (attrs: {
  patches = [ 
/home/ollie/nixpkgs/pkgs/development/libraries/haskell/fb/21.diff ];
});
  };
};
in lib.overrideDerivation haskellPackages.metronome (attrs: {
 buildInputs = [ haskellPackages.cabalInstall_1_18_0_2 ] ++ 
attrs.buildInputs;
   })



As you can see, this project (metronome) requires aeson 0.7, lens 4, and
a few other things that aren't on Hackage yet. The project has a
default.nix like this:



{ cabal
, aeson, errors, extensibleEffects, IntervalMap, digestiveFunctorsAeson, time
, postgresqlSimple, pipesParse, iCalendar, lens, fynder, snap, snapletSocketIO
, snapCors, webRoutesBoomerang, jsonAssertions, HTTP, indexed
, quickcheckInstances, tasty, tastyRerun, tastyAntXml, tastyHunit
, tastyQuickcheck, tastySmallcheck, httpClient, pipes, pipesConcurrency, hlint
}:
cabal.mkDerivation (self: {
  pname = metronome;
  version = 0.1.0;
  src = ./.;
  buildDepends = [
aeson errors extensibleEffects IntervalMap digestiveFunctorsAeson
time postgresqlSimple pipesParse iCalendar lens
fynder
snap
snapletSocketIO snapCors
webRoutesBoomerang
  ];
  testDepends = [
jsonAssertions
lens HTTP
indexed quickcheckInstances tasty tastyAntXml
tastyHunit tastyQuickcheck tastySmallcheck httpClient
pipes pipesConcurrency tastyRerun hlint
  ];
})



This has ensured we get consistent aeson and lens instances until the
defaults get switched over. That said, I'd still be interested to know
when we plan to do that, so I can keep close to nixpkgs.

Hope this helps,
- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Fixing module arguments (PROPOSAL MAY BREAK EXISTING NIXOS CONFIGS, PLEASE READ)

[Oliver Charles]

Shea Levy s...@shealevy.com writes:
Hi Shea,

 The Easy Solution
 -

In my opinion the whole project is young enough that we are not yet at a
stage where we have to live with things being difficult to work with. I
think most people who are using NixOS in real deployments are aware of
the fact that they still have to interact with the Nix community, and be
willing to change their deployments as configuration changes.

I may be putting words in other's mouths, but that is certainly how I
feel.

 The Conservative Solution
 -
 [..]

 The Moderate Solution
 -

Following on from my earlier feeling - if we're going to make massive
changes, I'd prefer to keep that window as small as possible. If that
means making a huge change in one pass, then that is what I would
prefer. This means I only have to understand one type of change, and I
only have to fiddle with my deployment configurations once. 

The more times I have to change things, the more likely I am to be
confused as to what exactly is going on, and increases the chance that
I'll screw something up. So...

 The Radical Solution
 

*If* you're convinced that there is a problem in the module system and
that this is the best solution, then I would not be against this type of
change. The argument about having to do a partial evaluation with a
dummy pkgs strongly suggests the model we have now is not the correct
one, and I'd be willing to pay the cost (be that changing my
configurations or helping out with changes in nixpkgs itself) to correct
that.

That said, a few concrete examples would really help clarify the
situtation for me, as I don't think I've entirely understood even the
problem itself.

Is it possible for you to share some of the nixops work you've been
doing, with how it looks now and what the pain points are? Ideally,
seeing how these pain points are solved by some of these solutions would
also be extremely useful - especially as the solutions tend towards the
more radical changes.

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Google Summer of Code 2014

[Oliver Charles]

Domen Kožar do...@dev.si writes:

 Hi all,

 Google Summer of Code is a program organized by Google giving organizations
 in open source opportunity to pay students to work on open source projects.

 Many successful students become contributors after the projects ends. Also,
 participating in GSOC is a healthy sign of an open source project.

 Below is a wiki entry of ideas that a student would accomplish in 3 months.
 The deadline to apply as an organization is tomorrow, I'm willing to do
 that step, but we have to produce a list of ideas with potential mentors by
 tomorrow afternoon (18:00 UTC).

 https://nixos.org/wiki/GSOC_2014_ideas_list

 Maybe to get a better idea, take a peek at Google's list
 https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2013/Ideas

 Disclaimer: I've participated in GSOC for 4 years as a student and I feel
 like it's time to step at the other side :-)

I've also participated in SoC - it's a fantastic project. I've been a
student twice and a mentor twice. I would be happy to help mentor a
student with NixOS this year.

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Fosdem: room reservation for community discussion

[Oliver Charles]

Domen Kožar do...@dev.si writes:

 Hey all,

 I've reserved a room for us at H.3.227 at 13h today. Everyone is welcome to
 join and discuss nix stack.

Great, thanks Domen! I'm going to be at the MirageOS talk at 13h, but
I'll stop by after that (assuming the talk isn't full, anyway).

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Maintainership

[Oliver Charles]

Shea Levy s...@shealevy.com writes:

 * If a package is unmaintained, it can be removed with minimal notice.
   This will require some time under the new idea of maintainership
   before it can be fairly put into place, but Eelco had the suggestion
   that no maintainers could be treated equivalently to meta.broken =
   true.

In Debian, I would imagine they can make use of the popularity contest
or whatever it is to see if people are even using this. Is it worth that
we consider having the ability to gather metrics like that? Removing
things from our package database should be more conscious than is this
supported and should really be considering do people need this?.

 * Maintainers should respond to emails, issues, and pull requests about
   their package in a timely fashion (even if just with WONTFIX)
 * Maintainers should at a minimum keep track of security updates for
   their packages
 * If a change elsewhere breaks a maintained package in a non-obvious
   way, the maintainers should make a reasonable effort to fix the
   breakage in a timely fashion
 * Ideally maintainers would test their maintained packages on the
   release branch(es) and master with regular frequency (most ideally by
   using them as a user)
 * In most cases, maintainers should keep track of all new releases and
   update when available. In the case where a particular maintainer only
   wants to care about a specific version and that version is currently
   the latest, it would be appreciated if they could let the community
   know when a newer version is available so that someone else can step
   up
 * We should devise a way of denoting maintainers for NixOS modules and
   adopt similar policies there. Absent that, it would be nice if
   maintainers for a package also took care of the modules for that
   package where applicable

 Thoughts? If we did decide this was a good idea, we should set aside
 some time period by which people should unmaintain packages they don't
 want this responsibility for and adopt packages they do.

These all sound reasonable - and I think I manage to do most of these
myself. Most of the packages I'm a maintainer for are packages I
actively use and am interested in the development of, so I am OK with
having to keep things up to date. So yes, I agree with all of these
points.

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] FOSDEM: any plans for Saturday evening?

[Oliver Charles]

Cillian de Róiste cillian.deroi...@gmail.com writes:

 It looks like we have 4-6 people interested. That's great! I guess we don't
 really need to make a reservation, just go to a part of town with a lot of
 restaurants, but if anyone has a suggestion for a restaurant or bar all the
 better.

 The talks should be finished by 19:00 so why don't we meet up at the main
 infodesk shortly afterwards and take it from there?:
 https://fosdem.org/2014/practical/transportation/

That sounds sensible. The NixOS talk is on Saturday at 17:00, so I
imagine a few of us will be going (I'll certainly be there).

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] FOSDEM: any plans for Saturday evening?

[Oliver Charles]

Cillian de Róiste cillian.deroi...@gmail.com writes:

 Hi,

 Since there will be quite a few NixOS and Guix folks at FOSDEM it would be
 great to meet up. Is there some interest in arranging dinner / drinks on
 Saturday evening?

I'd love this! Just out of interest, which of us will be going?

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nixops on headless server

[Oliver Charles]

On 23/12/13 20:06, Marco Maggesi wrote:
 I started from scratch.  This is the interaction.
 Thanks a lot,
 M.

 [maggesi@o0dom0:~/Devel/nixconfs/minicloud]$ nixops create
 ./logical.nix ./physical-vbox.nix --name minicloud
 created deployment 'aa84379e-6c0c-11e3-8dd5-bfd6a9bb84eb'
 aa84379e-6c0c-11e3-8dd5-bfd6a9bb84eb

 [maggesi@o0dom0:~/Devel/nixconfs/minicloud]$ nixops deploy -d minicloud
 webserver creating VirtualBox VM...
 webserver Virtual machine
 'nixops-aa84379e-6c0c-11e3-8dd5-bfd6a9bb84eb-webserver' is created and
 registered.
 webserver UUID: eda5fa7f-8141-40df-a9cf-9e13265d7e1f
 webserver Settings file: '/home/maggesi/VirtualBox
 VMs/nixops-aa84379e-6c0c-11e3-8dd5-bfd6a9bb84eb-webserver/nixops-aa84379e-6c0c-11e3-8dd5-bfd6a9bb84eb-webserver.vbox'
 webserver creating disk 'disk1'...
 webserver 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
 webserver Clone hard disk created in format 'VDI'. UUID:
 d9b38107-e2fe-440c-86e4-335711704dbf
 webserver attaching disk 'disk1'...
 webserver VBoxManage: error: The virtual machine
 'nixops-aa84379e-6c0c-11e3-8dd5-bfd6a9bb84eb-webserver' has terminated
 unexpectedly during startup with exit code 1
 webserver VBoxManage: error: Details: code NS_ERROR_FAILURE
 (0x80004005), component Machine, interface IMachine
 webserver Waiting for VM
 nixops-aa84379e-6c0c-11e3-8dd5-bfd6a9bb84eb-webserver to power on...
 webserver waiting for IP
 address.^Cerror:
 interrupted

 [maggesi@o0dom0:~/Devel/nixconfs/minicloud]$ VBoxManage startvm
 nixops-aa84379e-6c0c-11e3-8dd5-bfd6a9bb84eb-webserver --type headless
 Waiting for VM nixops-aa84379e-6c0c-11e3-8dd5-bfd6a9bb84eb-webserver
 to power on...
 VBoxManage: error: The virtual machine
 'nixops-aa84379e-6c0c-11e3-8dd5-bfd6a9bb84eb-webserver' has terminated
 unexpectedly during startup with exit code 1
 VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005),
 component Machine, interface IMachine

 [maggesi@o0dom0:~/Devel/nixconfs/minicloud]$ VBoxManage startvm
 nixops-aa84379e-6c0c-11e3-8dd5-bfd6a9bb84eb-webserver
 Waiting for VM nixops-aa84379e-6c0c-11e3-8dd5-bfd6a9bb84eb-webserver
 to power on...
 VBoxManage: error: The virtual machine
 'nixops-aa84379e-6c0c-11e3-8dd5-bfd6a9bb84eb-webserver' has terminated
 unexpectedly during startup with exit code 1
 VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005),
 component Machine, interface IMachine




I think I had similar behaviour with VirtualBox, and it turned out the
internal DHCP server for VirtualBox wasn't running. I forget the
specific details, but if you Google around you should be able to find
the instructions. Could be a red herring - but worth looking into!

- ocharles


signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Say hello to GHC 7.7.20131202

[Oliver Charles]

On 12/04/2013 12:01 AM, Peter Simons wrote:
 Yo Haskell programmers,
 
 I've just updated ghcHEAD to a reasonably up-to-date Git snapshot, and it 
 works
 quite well. In the interest of doubling compile times for everyone trying to
 use it, haskellPackages_ghcHEAD now has full shared-library support enabled by
 default, so Haskell binaries come at a whopping 300KB:
 
  | $ nix-build -o /tmp/cabal2nix ~/.nix-defexpr -A 
 haskellPackages_ghcHEAD.cabal2nix
  | /nix/store/7lrm31hf7lns8qbac7ciqq351gs603rr-cabal2nix-1.56
  |
  | $ ls -lh /tmp/cabal2nix/bin/cabal2nix
  | -r-xr-xr-x 1 root nixbld 360K Jan  1  1970 /tmp/cabal2nix/bin/cabal2nix
 
 'ldd' will tell a different story, though. :-)
 
 So, if you'd like to test your code against the upcoming 7.8 release, you can
 now use Nix to do it.

Great news! I'm very interested in shared libraries (I opened the
request for this, after all!) - but what is the reason for making this
the default for ghcHEAD? Will haskellPackages_ghc78whatever also have
shared libraries, or are you using this as a testing ground?

Thanks for working on this though, I'll be upgrading as soon as I find
the time :)

- ocharles



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nixpkgs-monitor. New milestone: patches

[Oliver Charles]

On 11/28/2013 12:57 PM, phree...@yandex.ru wrote:
 On Thursday, November 28, 2013 10:44:21 AM Vladimír Čunát wrote:
 On 11/28/2013 10:42 AM, Sergey Mironov wrote:
 2013/11/28 Vladimír Čunát vcu...@gmail.com:
 https://vdmvtkitqc3grub6.onion.to/
 How can you not remember it :-D

 Awesome! But.

 Tor2web Error: Generic Socks Error

 A typo, maybe? ;)

 No, correct (in my bookmarks), only the service doesn't always work (for
 me as well). No idea why.
 
 last time I took it down for maintenance and fell asleep :(
 and before it was hosted on my laptop which is always with me...

Would you like some hardware to host this more reliably? I'm happy to
donate a Linode server I have kicking around - this looks really handy.

- ocharles



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] who has a idea how to solve this

[Oliver Charles]

On 11/26/2013 06:21 PM, Roelof Wobben wrote:
 See bug report : https://github.com/NixOS/nixpkgs/issues/1279
  
 Roelof

I may be a minority, but I think a lot of us are subscribed to the
Github repository directly, and already get notifications when issues
are reported. I don't think it's necessary to email nix-dev too.

- ocharles



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Packaging Foreman

[Oliver Charles]

On 11/19/2013 09:03 AM, Alex Berg wrote:
 
 As part of the Heroku Toolbelt, I need to make a Nix package for
 Foreman. I am following the instructions to Install from Source [1]. The
 instructions say that it has many package requirements:
 
 gcc-c++ git libvirt-devel mysql-devel pg-devel openssl-devel \
 libxml2-devel sqlite-devel libxslt-devel zlib-devel readline-devel \
 postgresql-devel
 
 Am I right when I say - If I want to package Foreman, I must first
 package all these dependent packages. ?

I don't know Foreman, but yes - you will need all of those dependencies.
Note however that these dependencies seem to be specified as Ubuntu
package names. We don't strip out include files from our packages, so we
don't have 'devel' versions. Thus a lot of these dependencies we
probably already have:

gcc-c++ - gcc
mysql-devel - mysql
pg-devel - postgresql9*
sqlite-devel - sqlite

etc.

I tend to grep in nixpkgs/pkgs/top-level/all-packages.nix for the
start of the expression, find something that looks relevant, add it to
the expression of whatever I'm packaging, and attempt to nix-build. I
repeat that process until all dependencies are satisfied

 Related question: Does anyone know how to use the auto-generated Gem
 packages? I can't find any docs. -
 https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/ruby/generated.nix

This really needs better documentation. Most people will tell you to
read nixpkgs/pkgs/development/interpreters/ruby/rubygems.nix, but imo
that is not good enough.

- ocharles



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS 13.10

[Oliver Charles]

On 10/31/2013 11:07 PM, Mathijs Kwik wrote: Congratulations on another
great milestone :)
 It will be interesting to see how this stable experiment goes.
 But together with the new nixos-rebuild profiles, I think this will be
 very smooth.

What are the new nixos-rebuild profiles? Where could I read about these?

- ocharles




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Dashes in haskell-packages

[Oliver Charles]

On 10/08/2013 10:37 AM, Pascal Wittmann wrote: On 10/08/2013 11:24 AM,
Daniel Hlynskyi wrote:
 Hello. There is a convention to convert haskell packages names to
camelCase
 when they contain dashes. But Nix now can dashes.
 So what convention should I use when submitting new haskell packages to
 `nixpkgs`?

 The nixpkgs manual says:

 Dashes in the package name should be changed to underscores in variable
 names, rather than to camel case — e.g., module_init_tools instead of
 moduleInitTools.
   http://nixos.org/nixpkgs/manual/#idp365984

That might be the case for nixpkgs in general, but it's not the case for
Haskell packaging.

Daniel, I would suggest carrying on with camelCase for Haskell packages
for consistency. If we want to use dash naming and be equivalent to
Hackage, then I think this should be done in a single commit.

- ocharles



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Deploying Steam in NixOS

[Oliver Charles]

Very cool! Is this the approach you're suggesting we take with steam, and
abandon hope of doing it outside chroot?
On 13 Sep 2013 23:36, Sander van der Burg - EWI s.vanderb...@tudelft.nl
wrote:

  Hello Nixers seeking some entertainment!

 I also did an attempt to make Steam working in NixOS. I have used a chroot
 approach and for me it seems to work fine. I was capable of deploying and
 running Half-Life, Half Life 2, Portal and Counter Strike and they all seem
 to work fine on both on my desktop machine (with NVIDIA GPU) and notebook
 (with Intel GPU).

 More details:


 http://sandervanderburg.blogspot.com/2013/09/composing-fhs-compatible-chroot.html

 (Just search for tl;dr if you're too impatient :P)

 We may need to tweak the environment a bit to get other Steam games
 working that I don't know of, but the ones that I bought all seem to work.

 Best,

 Sander


 ___
 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] Deploying Steam in NixOS

[Oliver Charles]

On 09/14/2013 12:35 AM, Marc Weber wrote:
 Excerpts from Oliver Charles's message of Sat Sep 14 01:29:44 +0200 2013:
 Very cool! Is this the approach you're suggesting we take with steam, and
 abandon hope of doing it outside chroot?
 What's wrong about a chroot?
 Everything else could be a lot more work to maintain.
 Additional use cases are andoird dev environment and a lot like that.

Nothing is wrong with a chroot, I was just wondering if this was an
active area of exploration, or a more determined idea.

- ocharles



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] What monitoring tools do you currently prefer?

[Oliver Charles]

At work we're happily using statsd and graphite, along with logster.
On 31 Aug 2013 09:35, Mathijs Kwik math...@bluescreen303.nl wrote:

 Thanks for the tips.
 I will look into datadog probably, although I was hoping to uncloud
 myself a bit by moving more stuff to my own infrastructure ;)

 On Wed, Aug 28, 2013 at 11:54 AM, Domen Kožar do...@dev.si wrote:
  It is worth mentioning datadog (as aggregation server) builds upon very
  strong concepts of https://github.com/etsy/statsd/ (as client-side
  statistics collecting tool).
 
  For application developers it's nice because you can collection system
 and
  application data under same api.
 
  Jaka also added Graphite (OSS web tool for drawing graphs from statsd)
  support to NixOS, but it's far from datadog capabilities.
 
 
  On Wed, Aug 28, 2013 at 11:47 AM, Rob Vermaas rob.verm...@gmail.com
 wrote:
 
  Hi Matthijs,
 
   Tools like sysstat/sar come to mind, but as these have been around for
   eons, there might be more modern alternatives that I don't know about
   yet.
 
  If you have a small amount of servers, you could try using DataDog
  (http://www.datadoghq.com/), up to 5 machines are for free. It is very
  easy to use, there is a NixOS module for it. I have used DataDog for
  EC2 machines for which they have an integration available to allow
  getting performance information that EC2 offers. Perhaps they have
  something similar for your cloud provider as well.
 
  If you have more machines, it might be worth to switching to a system
  like Zabbix. Zabbix should also be relatively easy to set up in NixOS,
  there is an example in the nixos-org-configuration repository of the
  NixOS organization on github.
 
  Cheers,
  Rob
  ___
  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-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nixos-install building FLAC and failing

[Oliver Charles]

I also got this error while installing a new Linode. I fixed it by
reverting to the previous version of FLAC.
On 13 Jun 2013 23:23, Malcolm Matalka mmata...@gmail.com wrote:

 I'm trying to install NixOS on another Linode host, and I'm running into
 something odd during 'nixos-install'.

 Despite my configuration, AFAIK, a bunch of sound stuff is being
 installed, and FLAC is failing on tests, most likely because I'm running
 as root.  I just don't understand why FLAC is being installed at all.
 Here is part of the output from nixos-install showing the deps it still
 needs to build.

 building the system configuration...
 these derivations will be built:
   /nix/store/0kpj3rl5w9ycgfqs2wb5bikdmyf1sgir-unit.drv
   /nix/store/4v3x9b21gk0yf80aahy3l6m23l1g66kk-udev-rules.drv
   /nix/store/85zn8vkpwprb1i7zacd150gjmxmxh3vz-dbus-conf.drv
   /nix/store/9xaz4r1ivpf4pk5cq4yqzw5bfhk3hz9m-libsndfile-1.0.23.drv
   /nix/store/iq8rdzk2ybzvpq8m1pvwwb6lsrz6gvpg-flac-1.3.0.drv
   /nix/store/ja8a6k37a2vp60gpd74gd3y01iqgh7z9-units.drv
   /nix/store/jc3935zzvkyzc2xq61lflmnqb5420b61-alsa-utils-1.0.26.drv
   /nix/store/kdr9hr1gdkn1q81sigijry48shgf8r9l-system-path.drv
   /nix/store/npkljyz5ilgg9b8r45yi384bgqibr4cf-etc.drv
   /nix/store/p6cr6phxzavm78wk4srgkr8cknw53kyf-nixos-0.2pre-git.drv
   /nix/store/szj3ha2qac6xkr4wzvgp0p5z1gg6ahk8-system-crontab.drv
   /nix/store/wy5m4svdmj1gkgyzmijy7z09jfwfgqcb-libsamplerate-0.1.7.drv

 Here is the error:

 ERROR: iterator claims file is writable when tester thinks it should not
 be; are you running as root?

 ERROR during test_libFLAC
 make[1]: *** [check] Error 1
 make[1]: Leaving directory
 `/tmp/nix-build-flac-1.3.0.drv-0/flac-1.3.0/test'
 ESC[qESC[qmake: *** [check-recursive] Error 1
 ESC[qESC[qESC[qbuilder for
 `/nix/store/iq8rdzk2ybzvpq8m1pvwwb6lsrz6gvpg-flac-1.3.0.drv' failed with
 exit code 2
 cannot build derivation
 `/nix/store/9xaz4r1ivpf4pk5cq4yqzw5bfhk3hz9m-libsndfile-1.0.23.drv': 1
 dependencies couldn't be built
 cannot build derivation
 `/nix/store/wy5m4svdmj1gkgyzmijy7z09jfwfgqcb-libsamplerate-0.1.7.drv': 1
 dependencies couldn't be built
 cannot build derivation
 `/nix/store/jc3935zzvkyzc2xq61lflmnqb5420b61-alsa-utils-1.0.26.drv': 1
 dependencies couldn't be built
 cannot build derivation
 `/nix/store/kdr9hr1gdkn1q81sigijry48shgf8r9l-system-path.drv': 1
 dependencies couldn't be built
 cannot build derivation
 `/nix/store/p6cr6phxzavm78wk4srgkr8cknw53kyf-nixos-0.2pre-git.drv': 1
 dependencies couldn't be built
 error: build of
 `/nix/store/p6cr6phxzavm78wk4srgkr8cknw53kyf-nixos-0.2pre-git.drv' failed

 Also, I don't seem able to build a dependency graph to see why sound is
 begin pulled in because nothing is actually installed yet.

 Any suggestions how to debug this?
 ___
 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] 'unit' derivations

[Oliver Charles]

On 03/29/2013 09:55 AM, Sergey Mironov wrote:
 Hi, I've noticed lots of derivations called 'unit' during last update. 
 Please explain what do they mean?

 Thanks in advance,
 Sergey
I believe these are all units for systemd. Each unit (e.g., 
display-manager.unit) has its own derivation.

- ocharles
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev