[Nix-commits] [NixOS/nixpkgs] 487140: typespeed: fix darwin compatibility

[Tuomas Tynkkynen]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 487140e8ef6cb044d3d252f23344f1a9ace668e3
  
https://github.com/NixOS/nixpkgs/commit/487140e8ef6cb044d3d252f23344f1a9ace668e3
  Author: Nick Novitski 
  Date:   2016-06-09 (Thu, 09 Jun 2016)

  Changed paths:
M pkgs/games/typespeed/default.nix

  Log Message:
  ---
  typespeed: fix darwin compatibility


  Commit: a357edc0c69f24f3d82a79f736e55ffe8991bdce
  
https://github.com/NixOS/nixpkgs/commit/a357edc0c69f24f3d82a79f736e55ffe8991bdce
  Author: Tuomas Tynkkynen 
  Date:   2016-06-09 (Thu, 09 Jun 2016)

  Changed paths:
M pkgs/games/typespeed/default.nix

  Log Message:
  ---
  Merge pull request #16013 from nicknovitski/typespeed-darwin

typespeed: fix darwin compatibility


Compare: https://github.com/NixOS/nixpkgs/compare/37ab0f31231d...a357edc0c69f___
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

[Anthony Cowley]

Peter Simons writes:

> 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. Our builds run on all kinds of Linuxes and on Darwin, we
> support 32 bit platforms, and we link everything with shared libraries
> by default. This means that some of our builds fail even though they
> succeed in Stackage [4]. Now, we usually report these issues to Stackage
> and on some occasions they've made an effort to fix the issue, but on
> other occasions their response was, essentially, "works for me". That
> leaves us in an odd place, because we're nominally following Stackage
> (and our users rely on getting exactly those builds that Stackage
> promises), but at the same time we have no choice but to deviate from
> Stackage because the builds they want us to do just don't work.
>
> As such, it's a good idea to use Stackage as a *recommendation* for our
> package set, but we cannot expect to be 100% compliant to Stackage and
> provide a stable user experience at the same time.
>
> Best regards,
> Peter
>
>
> [1] 

[Nix-commits] [NixOS/nixpkgs] a2612d: nomad: add package

[Rushmore Mushambi]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: a2612dc0f13eb995ed3c491b96c119e2de892248
  
https://github.com/NixOS/nixpkgs/commit/a2612dc0f13eb995ed3c491b96c119e2de892248
  Author: rushmorem 
  Date:   2016-06-09 (Thu, 09 Jun 2016)

  Changed paths:
M pkgs/top-level/all-packages.nix
M pkgs/top-level/go-packages.nix

  Log Message:
  ---
  nomad: add package


  Commit: 37ab0f31231d6b4ad598b1a7cfa941f7f49b8c45
  
https://github.com/NixOS/nixpkgs/commit/37ab0f31231d6b4ad598b1a7cfa941f7f49b8c45
  Author: Rushmore Mushambi 
  Date:   2016-06-09 (Thu, 09 Jun 2016)

  Changed paths:
M pkgs/top-level/all-packages.nix
M pkgs/top-level/go-packages.nix

  Log Message:
  ---
  Merge pull request #16073 from rushmorem/package-nomad

nomad: add package


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

Re: [Nix-dev] firefox + Nix + sha512

[Vladimír Čunát]

On 06/08/2016 07:56 PM, Sergey Mironov wrote:
>
> https://nixos.org/wiki/How_to_update_when_Nix_is_too_old_to_evaluate_Nixpkgs
> 
> I tried to add the advice Vladimir gave me, but my user (ierton) have
> no write permissions any more. Who can I ask to re-gain them?

The wiki is read-only on purpose, and the content is being migrated to
official documentation (though very slowly AFAIK). The problem is that
much of it was either rotten or poor quality anyway.
https://github.com/NixOS/nixpkgs/issues?milestone=8

> How should I know the right Nix hash to --realize in future?

I got the path on Hydra... but we *should* fix the nixpkgs evaluation
error to provide helpful information.

--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NIX_ENFORCE_NO_NATIVE

[Vladimír Čunát]

On 06/08/2016 04:14 PM, Andreas Herrmann wrote:
> Especially, when being run outside of a nix-builder.

IIRC its' conditioned on $NIX_ENFORCE_NO_NATIVE exactly in order not to
be filtered out when run outside a nix builder. IMO that's a good
default. Hydra isn't the only reason; many devs use remote builds or
nix-copy-closure.

If you do want -march or -mtune in mkDerivation, you may either set
NIX_ENFORCE_NO_NATIVE = false; or even better, specify it explicitly,
e.g. -march=btver1

--Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] b214c6: kde5.plasma-desktop: add missing ksysguard depende...

[Thomas Tuegel]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b214c6b64fde1ef5fc549cb8e0f99884f3ec03f7
  
https://github.com/NixOS/nixpkgs/commit/b214c6b64fde1ef5fc549cb8e0f99884f3ec03f7
  Author: Thomas Tuegel 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/desktops/kde-5/plasma-5.6/plasma-desktop/default.nix

  Log Message:
  ---
  kde5.plasma-desktop: add missing ksysguard dependency


  Commit: 8dae2eddcfad999a7f8252e43789b0e78d66e6d1
  
https://github.com/NixOS/nixpkgs/commit/8dae2eddcfad999a7f8252e43789b0e78d66e6d1
  Author: Thomas Tuegel 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/desktops/kde-5/plasma-5.6/kdeplasma-addons.nix

  Log Message:
  ---
  kde5.kdeplasma-addons: add missing ksysguard dependency


  Commit: bdb8bafd1fb44b5d07fca8f4f2269ffbdf6df711
  
https://github.com/NixOS/nixpkgs/commit/bdb8bafd1fb44b5d07fca8f4f2269ffbdf6df711
  Author: Thomas Tuegel 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/desktops/kde-5/plasma-5.6/kdeplasma-addons.nix
M pkgs/desktops/kde-5/plasma-5.6/plasma-desktop/default.nix

  Log Message:
  ---
  Merge branch 'plasma-workspace'


Compare: https://github.com/NixOS/nixpkgs/compare/ba096752329e...bdb8bafd1fb4___
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

[Teo Klestrup Röijezon]

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. Our builds run on all kinds of Linuxes and on Darwin, we
> support 32 bit platforms, and we link everything with shared libraries
> by default. This means that some of our builds fail even though they
> succeed in Stackage [4]. Now, we usually report these issues to Stackage
> and on some occasions they've made an effort to fix the issue, but on
> other occasions their response was, essentially, 

Re: [Nix-dev] firefox + Nix + sha512

[Layus]

The wiki is read-only and will remains so for an undefined period 
(forever ?).
The general idea is to update the documentation (via pull requests) and 
kill the outdated wiki pages.


You are most welcom to add up-to-date information to the manual.

-- Layus.

PS: Please, someone correct me if I am mistaken about the wiki state.

On 08/06/16 19:56, Sergey Mironov wrote:

Let me also note, that all Hydra links are 404 on the Wiki page, which
is referenced by the nix command line tools:

https://nixos.org/wiki/How_to_update_when_Nix_is_too_old_to_evaluate_Nixpkgs

I tried to add the advice Vladimir gave me, but my user (ierton) have
no write permissions any more. Who can I ask to re-gain them?

2016-06-08 20:30 GMT+03:00 Sergey Mironov :

Thanks for the '--realize' command, it saved my day!
How should I know the right Nix hash to --realize in future?

Regards,
Sergey

2016-05-22 10:45 GMT+03:00 Vladimír Čunát :

Hi.

On 05/21/2016 04:00 PM, Sergey Mironov wrote:

[...] Unfortunately, all the one-click-install packages are 404.

Could you help me to understand what is happening? Which settings do
people normally use at the moment?

I've got no idea about what people normally use. Perhaps most of them
update more often.

Instead of one-click-install, I'd use the desired path directly
nix-store --realize /nix/store/mf9ha2d0yz599wx3aw5r0wdzyk5f8lf7-nix-1.11.2
(That should be possible since using binary caches.)


I expect it isn't enough to have new nix to evaluate the expressions but
also running as nix-daemon. Therefore, I suggest you first update your
system without firefox, getting rid of the error and then you can
continue normally, adding it, etc.

That should be possible in revisions after util-linux using sha256 again
https://github.com/NixOS/nixpkgs/pull/15048#issuecomment-219149502


--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-commits] [NixOS/nixpkgs] ba0967: zap: update 2.4.3 -> 2.5.0

[Benno Fünfstück]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: ba096752329ef5d8755bdc6f938bba60b76d52b6
  
https://github.com/NixOS/nixpkgs/commit/ba096752329ef5d8755bdc6f938bba60b76d52b6
  Author: Benno Fünfstück 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/tools/networking/zap/default.nix

  Log Message:
  ---
  zap: update 2.4.3 -> 2.5.0


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

[Nix-commits] [NixOS/nixpkgs] d13378: haskellPackages.libmpd: remove upper bound on time

[obadz]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: d13378ffd16561f8fc4d37215ef0e3c6030b4a82
  
https://github.com/NixOS/nixpkgs/commit/d13378ffd16561f8fc4d37215ef0e3c6030b4a82
  Author: obadz 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/development/haskell-modules/configuration-common.nix

  Log Message:
  ---
  haskellPackages.libmpd: remove upper bound on time


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

[Nix-commits] [NixOS/nixpkgs] 1201cc: geolite-legacy: 2016-06-06 -> 2016-06-08

[Tobias Geerinckx-Rice]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 1201cc569cfbce66d39b748af40e94498f97b899
  
https://github.com/NixOS/nixpkgs/commit/1201cc569cfbce66d39b748af40e94498f97b899
  Author: Tobias Geerinckx-Rice 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/data/misc/geolite-legacy/default.nix

  Log Message:
  ---
  geolite-legacy: 2016-06-06 -> 2016-06-08


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

Re: [Nix-dev] firefox + Nix + sha512

[Sergey Mironov]

Let me also note, that all Hydra links are 404 on the Wiki page, which
is referenced by the nix command line tools:

   https://nixos.org/wiki/How_to_update_when_Nix_is_too_old_to_evaluate_Nixpkgs

I tried to add the advice Vladimir gave me, but my user (ierton) have
no write permissions any more. Who can I ask to re-gain them?

2016-06-08 20:30 GMT+03:00 Sergey Mironov :
> Thanks for the '--realize' command, it saved my day!
> How should I know the right Nix hash to --realize in future?
>
> Regards,
> Sergey
>
> 2016-05-22 10:45 GMT+03:00 Vladimír Čunát :
>> Hi.
>>
>> On 05/21/2016 04:00 PM, Sergey Mironov wrote:
>>> [...] Unfortunately, all the one-click-install packages are 404.
>>>
>>> Could you help me to understand what is happening? Which settings do
>>> people normally use at the moment?
>>
>> I've got no idea about what people normally use. Perhaps most of them
>> update more often.
>>
>> Instead of one-click-install, I'd use the desired path directly
>> nix-store --realize /nix/store/mf9ha2d0yz599wx3aw5r0wdzyk5f8lf7-nix-1.11.2
>> (That should be possible since using binary caches.)
>>
>>
>> I expect it isn't enough to have new nix to evaluate the expressions but
>> also running as nix-daemon. Therefore, I suggest you first update your
>> system without firefox, getting rid of the error and then you can
>> continue normally, adding it, etc.
>>
>> That should be possible in revisions after util-linux using sha256 again
>> https://github.com/NixOS/nixpkgs/pull/15048#issuecomment-219149502
>>
>>
>> --Vladimir
>>
>>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 1207ac: geolite-legacy: 2016-06-06 -> 2016-06-08

[Tobias Geerinckx-Rice]

  Branch: refs/heads/release-16.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 1207ac1aafa5d1edb6776a901a73eb3fcaef7b9c
  
https://github.com/NixOS/nixpkgs/commit/1207ac1aafa5d1edb6776a901a73eb3fcaef7b9c
  Author: Tobias Geerinckx-Rice 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/data/misc/geolite-legacy/default.nix

  Log Message:
  ---
  geolite-legacy: 2016-06-06 -> 2016-06-08


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

Re: [Nix-dev] firefox + Nix + sha512

[Sergey Mironov]

Thanks for the '--realize' command, it saved my day!
How should I know the right Nix hash to --realize in future?

Regards,
Sergey

2016-05-22 10:45 GMT+03:00 Vladimír Čunát :
> Hi.
>
> On 05/21/2016 04:00 PM, Sergey Mironov wrote:
>> [...] Unfortunately, all the one-click-install packages are 404.
>>
>> Could you help me to understand what is happening? Which settings do
>> people normally use at the moment?
>
> I've got no idea about what people normally use. Perhaps most of them
> update more often.
>
> Instead of one-click-install, I'd use the desired path directly
> nix-store --realize /nix/store/mf9ha2d0yz599wx3aw5r0wdzyk5f8lf7-nix-1.11.2
> (That should be possible since using binary caches.)
>
>
> I expect it isn't enough to have new nix to evaluate the expressions but
> also running as nix-daemon. Therefore, I suggest you first update your
> system without firefox, getting rid of the error and then you can
> continue normally, adding it, etc.
>
> That should be possible in revisions after util-linux using sha256 again
> https://github.com/NixOS/nixpkgs/pull/15048#issuecomment-219149502
>
>
> --Vladimir
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 213f88: atom: patchelf ctags binary

[Rushmore Mushambi]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 213f882fd38aba19d00e513de744aad8ac358515
  
https://github.com/NixOS/nixpkgs/commit/213f882fd38aba19d00e513de744aad8ac358515
  Author: Leon Isenberg 
  Date:   2016-06-04 (Sat, 04 Jun 2016)

  Changed paths:
M pkgs/applications/editors/atom/default.nix

  Log Message:
  ---
  atom: patchelf ctags binary


  Commit: 5c8a8808ba196bfbd44d4e2c9606f93a57fff29c
  
https://github.com/NixOS/nixpkgs/commit/5c8a8808ba196bfbd44d4e2c9606f93a57fff29c
  Author: Rushmore Mushambi 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/applications/editors/atom/default.nix

  Log Message:
  ---
  Merge pull request #16056 from ljli/fix-atom

atom: patchelf ctags binary


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

[Nix-commits] [NixOS/nixpkgs] f3a753: auctex: enable preview

[obadz]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f3a753829d8e385255db2a85ff67798ea34c86fd
  
https://github.com/NixOS/nixpkgs/commit/f3a753829d8e385255db2a85ff67798ea34c86fd
  Author: Guillaume Maudoux 
  Date:   2016-06-05 (Sun, 05 Jun 2016)

  Changed paths:
M pkgs/tools/typesetting/tex/auctex/default.nix

  Log Message:
  ---
  auctex: enable preview


  Commit: 6035e80137e04d56a8766fbac964009ef919cda9
  
https://github.com/NixOS/nixpkgs/commit/6035e80137e04d56a8766fbac964009ef919cda9
  Author: Guillaume Maudoux 
  Date:   2016-06-05 (Sun, 05 Jun 2016)

  Changed paths:
A pkgs/applications/graphics/ktikz/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  ktikz: init at 0.10


  Commit: ab70ae2edfbd4252ebbe792814c158d97e28cc65
  
https://github.com/NixOS/nixpkgs/commit/ab70ae2edfbd4252ebbe792814c158d97e28cc65
  Author: obadz 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
A pkgs/applications/graphics/ktikz/default.nix
M pkgs/tools/typesetting/tex/auctex/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Merge pull request #15647 from layus/auctex

ktikz: init at 0.10


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

[Nix-commits] [NixOS/nixpkgs] 093c42: yabar: init at 0.4.0

[Christian Lask]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 093c42161fe2f6730c1379c45bbd990de887284f
  
https://github.com/NixOS/nixpkgs/commit/093c42161fe2f6730c1379c45bbd990de887284f
  Author: Christian Lask 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
A pkgs/applications/window-managers/yabar/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  yabar: init at 0.4.0

Closes #15945


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

[Nix-commits] [NixOS/nixpkgs] 2e6b25: rkt: 1.5.1 -> 1.7.0 (#15958)

[Stefan Junker]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 2e6b257edf66dcc7b7a31b59b5215a8e42ba4529
  
https://github.com/NixOS/nixpkgs/commit/2e6b257edf66dcc7b7a31b59b5215a8e42ba4529
  Author: Stefan Junker 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/applications/virtualization/rkt/default.nix

  Log Message:
  ---
  rkt: 1.5.1 -> 1.7.0 (#15958)


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

[Nix-commits] [NixOS/nixpkgs] 0a4e80: ocamlnet: 3.7.7 -> 4.1.1 (#16008)

[vbgl]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 0a4e806f8f6532098284238e15dfb9801309c70c
  
https://github.com/NixOS/nixpkgs/commit/0a4e806f8f6532098284238e15dfb9801309c70c
  Author: vbgl 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/development/ocaml-modules/ocamlnet/default.nix

  Log Message:
  ---
  ocamlnet: 3.7.7 -> 4.1.1 (#16008)


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

[Nix-commits] [NixOS/nixpkgs] d22013: httpie: 0.9.2 -> 0.9.3 (#16067)

[zimbatm]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: d220132f222979db1350dde527408e445af3cf43
  
https://github.com/NixOS/nixpkgs/commit/d220132f222979db1350dde527408e445af3cf43
  Author: zimbatm 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/tools/networking/httpie/default.nix

  Log Message:
  ---
  httpie: 0.9.2 -> 0.9.3 (#16067)


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

[Nix-commits] [NixOS/nixpkgs] bcd6e2: kde5.plasma-workspace: add iso-codes dependency

[Thomas Tuegel]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: bcd6e295d7f61caabd3dad99f63497e1276e52b3
  
https://github.com/NixOS/nixpkgs/commit/bcd6e295d7f61caabd3dad99f63497e1276e52b3
  Author: Thomas Tuegel 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/desktops/kde-5/plasma-5.6/plasma-workspace/default.nix

  Log Message:
  ---
  kde5.plasma-workspace: add iso-codes dependency

Fixes #16040. CMake finds the iso-codes dependency through pkgconfig.


  Commit: 719b8e6d4ca385c1d32116165098023026d93637
  
https://github.com/NixOS/nixpkgs/commit/719b8e6d4ca385c1d32116165098023026d93637
  Author: Thomas Tuegel 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/desktops/kde-5/plasma-5.6/plasma-workspace/default.nix

  Log Message:
  ---
  Merge branch 'plasma-workspace-iso-codes'


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

[Nix-commits] [NixOS/nixpkgs] 697437: firefox-bin: 46.0.1 -> 47.0

[Joachim Fasting]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 697437c8e7c49beec77dc853d051f06656d3439b
  
https://github.com/NixOS/nixpkgs/commit/697437c8e7c49beec77dc853d051f06656d3439b
  Author: taku0 
  Date:   2016-06-07 (Tue, 07 Jun 2016)

  Changed paths:
M pkgs/applications/networking/browsers/firefox-bin/sources.nix

  Log Message:
  ---
  firefox-bin: 46.0.1 -> 47.0


  Commit: ccf7048307f2bc0e7005f338822e00e3a4c8f777
  
https://github.com/NixOS/nixpkgs/commit/ccf7048307f2bc0e7005f338822e00e3a4c8f777
  Author: Joachim Fasting 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/applications/networking/browsers/firefox-bin/sources.nix

  Log Message:
  ---
  Merge pull request #16057 from taku0/firefox-bin-47.0

firefox-bin: 46.0.1 -> 47.0


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

[Nix-commits] [NixOS/nixpkgs] d88aa1: Firefox: 46.0.1 -> 47.0

[Michael Raskin]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: d88aa14c6e4563c3244ec89805abe7360246f623
  
https://github.com/NixOS/nixpkgs/commit/d88aa14c6e4563c3244ec89805abe7360246f623
  Author: Michael Raskin <7c6f4...@mail.ru>
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/applications/networking/browsers/firefox/default.nix

  Log Message:
  ---
  Firefox: 46.0.1 -> 47.0


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

[Nix-commits] [NixOS/nixpkgs] 8fc6ca: torbrowser: 6.0 -> 6.0.1

[Joachim Fasting]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 8fc6ca75a93671b9bb3ccfbb5cd9a68a48754064
  
https://github.com/NixOS/nixpkgs/commit/8fc6ca75a93671b9bb3ccfbb5cd9a68a48754064
  Author: Joachim Fasting 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/tools/security/tor/torbrowser.nix

  Log Message:
  ---
  torbrowser: 6.0 -> 6.0.1


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

[Nix-dev] NIX_ENFORCE_NO_NATIVE

[Andreas Herrmann]

Hi everyone,

I'm using Nix to manage some of my numerics applications. I am compiling the 
programs specifically on and for a certain platform and am using GCC's 
`-march=native` flag so that the compiler can apply all the platform specific 
optimizations it knows. (SSE, AVX, etc.)

I noticed that this doesn't really work as expected, anymore. Many of the 
platform features are not detected automatically. While digging through nixpkgs 
I found that there is an environment variable `NIX_ENFORCE_NO_NATIVE` that 
defaults to `1` which means that the `-march=native` flag is going to be 
ignored. The reasoning is to prevent impurity. This flag was introduced this 
march [1].

Now, I understand that this is important for packages that are compiled on 
Hydra for the binary cache. But, I think it's not a good thing for GCC to 
quietly ignore the `-march=native` flag. Especially, when being run outside of 
a nix-builder.

Maybe a warning would be appropriate in that case, or even in general? After 
all, people usually have a good reason to set `-march=native`. In those cases 
performance tends to be important.

Best, Andreas

[1]: 
https://github.com/NixOS/nixpkgs/commit/0c6db0ca48612f18e5c2b744dfa385ba8eecc950

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

Re: [Nix-dev] Twitter account?

[Rok Garbas]

i use #nixos or #nix hashtag ... which susally does the job of getting
into the twitter list of other nixers.

On Wed, Jun 8, 2016 at 3:23 PM, Maarten Hoogendoorn  wrote:
> Hi there,
>
> I'm about to post a blogpost on Nix. We'd like to tweet about this, and
> include a twitter handle for nix*. Does such an account exist :)?
>
> Best regards,
> Maarten
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>



-- 
Rok Garbas
http://www.garbas.si
r...@garbas.si
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Twitter account?

[Domen Kožar]

https://twitter.com/nixos_org

On Wed, Jun 8, 2016 at 2:23 PM, Maarten Hoogendoorn 
wrote:

> Hi there,
>
> I'm about to post a blogpost on Nix. We'd like to tweet about this, and
> include a twitter handle for nix*. Does such an account exist :)?
>
> Best regards,
> Maarten
>
> ___
> 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] Twitter account?

[Maarten Hoogendoorn]

Hi there,

I'm about to post a blogpost on Nix. We'd like to tweet about this, and
include a twitter handle for nix*. Does such an account exist :)?

Best regards,
Maarten
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] 909f83: piqi: 0.6.12 -> 0.6.13

[zimbatm]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 909f83f9f81456f72339ccf319b8aafeb31cd757
  
https://github.com/NixOS/nixpkgs/commit/909f83f9f81456f72339ccf319b8aafeb31cd757
  Author: Vincent Laporte 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/development/ocaml-modules/piqi/default.nix

  Log Message:
  ---
  piqi: 0.6.12 -> 0.6.13


  Commit: 2bb6cb6d203953d207822ba569186595b09fd62b
  
https://github.com/NixOS/nixpkgs/commit/2bb6cb6d203953d207822ba569186595b09fd62b
  Author: Vincent Laporte 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/development/ocaml-modules/piqi-ocaml/default.nix

  Log Message:
  ---
  piqi-ocaml: 0.7.4 -> 0.7.5


  Commit: 4e30ff7368a9c18658c209c4f5df84f1967456df
  
https://github.com/NixOS/nixpkgs/commit/4e30ff7368a9c18658c209c4f5df84f1967456df
  Author: zimbatm 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/development/ocaml-modules/piqi-ocaml/default.nix
M pkgs/development/ocaml-modules/piqi/default.nix

  Log Message:
  ---
  Merge pull request #16062 from vbgl/piqi-0.7.5

piqi-ocaml: 0.7.4 -> 0.7.5


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

[Nix-dev] Stackage Support Will Be Discontinued

[Peter Simons]

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. Our builds run on all kinds of Linuxes and on Darwin, we
support 32 bit platforms, and we link everything with shared libraries
by default. This means that some of our builds fail even though they
succeed in Stackage [4]. Now, we usually report these issues to Stackage
and on some occasions they've made an effort to fix the issue, but on
other occasions their response was, essentially, "works for me". That
leaves us in an odd place, because we're nominally following Stackage
(and our users rely on getting exactly those builds that Stackage
promises), but at the same time we have no choice but to deviate from
Stackage because the builds they want us to do just don't work.

As such, it's a good idea to use Stackage as a *recommendation* for our
package set, but we cannot expect to be 100% compliant to Stackage and
provide a stable user experience at the same time.

Best regards,
Peter


[1] https://github.com/NixOS/nixpkgs/issues/14897
[2] https://github.com/fpco/stackage/issues/1465
[3] 
https://github.com/fpco/stackage/commit/cb54d78615c0e154913007e9437ff30de6e13661
[4] 

Re: [Nix-dev] Install Nix on OSX, install nixops -> runs python2.7-pytest tests

[Domen Kožar]

Yes it's possible. If it for some reason doesn't work, please provide a
http://sscce.org and open an issue :)

On Tue, Jun 7, 2016 at 4:19 PM, Graham Christensen 
wrote:

> Is it actually possible to run Nixops on OSX? A client of mine wasn't able
> to build EC2 machines on his OS X laptop today during a demo.
>
> Best,
> Graham
>
> On Jun 7, 2016, at 7:59 AM, Freddy Rietdijk 
> wrote:
>
> The nixpkgs-unstable channel, which includes OSX packages, hasn't updated
> in 25 days whereas the nixos-unstable channel was updated 4 days ago.
> http://howoldis.herokuapp.com/
>
> On Tue, Jun 7, 2016 at 2:54 PM, Maarten Hoogendoorn 
> wrote:
>
>> Ah, I see ;) Now it makes sense.
>>
>> 2016-06-07 14:42 GMT+02:00 zimbatm :
>>
>>> It's possible, the nixpkgs-unstable and nixos-unstable both evolve
>>> independently as they have different "success" conditions.
>>>
>>> On Tue, 7 Jun 2016, 13:38 Maarten Hoogendoorn, 
>>> wrote:
>>>
 Ah, that could be very well the cause of this. Is the OS X build
 lagging behind the NixOS one? I thought if some package was present in the
 unstable channel, that hydra would have build it and uploaded it to the
 binary cache?

 2016-06-07 14:30 GMT+02:00 zimbatm :

> In general I found that there are less packages available from the
> cache on OSX. What probably happened is that the packages had to be built.
> If doCheck = true then tests are run after the build and this is the
> default for python packages.
>
> On Tue, 7 Jun 2016, 13:19 Maarten Hoogendoorn, 
> wrote:
>
>> Hi there,
>>
>> I have been a really happy Nix{,pkgs,os,ops} for some time. In fact,
>> I'm writing two intro blog posts about nix during working hours for
>> Container Solutions. Since most of the developers that will read the
>> blogpost will be running OS X, I've borrowed a spare macbook, and 
>> installed
>> nix and nixops.
>>
>> To my surprise, this caused python tests to run. Is this the expected
>> behavior?
>>
>> Thanks,
>> Maarten
>> ___
>> 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
>
>
> ___
> 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] ff8362: pktgen: build with the same CFLAGS as dpdk

[Domen Kožar]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: ff8362aeb48d9ea54a9f21c38f53e641d75e1d5e
  
https://github.com/NixOS/nixpkgs/commit/ff8362aeb48d9ea54a9f21c38f53e641d75e1d5e
  Author: Ruslan Babayev 
  Date:   2016-06-07 (Tue, 07 Jun 2016)

  Changed paths:
M pkgs/os-specific/linux/pktgen/default.nix

  Log Message:
  ---
  pktgen: build with the same CFLAGS as dpdk


  Commit: 964665eb1c75e0bb596e08a92a6c872b5ae06a31
  
https://github.com/NixOS/nixpkgs/commit/964665eb1c75e0bb596e08a92a6c872b5ae06a31
  Author: Domen Kožar 
  Date:   2016-06-08 (Wed, 08 Jun 2016)

  Changed paths:
M pkgs/os-specific/linux/pktgen/default.nix

  Log Message:
  ---
  Merge pull request #15962 from abuibrahim/master

pktgen: build with the same CFLAGS as dpdk


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

[Nix-commits] Success: Hydra job nixpkgs:trunk:tarball on x86_64-linux

[Hydra Build Daemon]

Hi,

The status of Hydra job ‘nixpkgs:trunk:tarball’ (on x86_64-linux) has changed 
from "Failed" to "Success".  For details, see

  https://hydra.nixos.org/build/36742694

This may be due to 33 commits by Andrey Pavlov , Luca 
Bruno , Moritz Ulrich , Nikolay 
Amiantov , Peter Simons , Rahul Gopinath 
, Robert Helgesson , Rushmore 
Mushambi , Tuomas Tynkkynen , 
obadz , rushmorem  or zimbatm 
.

Yay!

Regards,

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