Re: [Nix-dev] Sbtix - SBT project builder

[Teo Klestrup Röijezon]

Granularity, performance and compatibility with existing SBT plugins would
probably be the main differences.

I don't have a lot of experience with Sbt2nix, but from what I can tell,
Sbt2nix generates a Nix derivation with the dependencies of each project,
but then builds it by hand by calling javac/scalac itself. This means that,
for example, any custom build steps (such as Proguard, Scala.js, or
sbt-web) are skipped unless you re-implement them by hand. It also seems
like Sbt2nix hardcodes the Maven repositories that are used (see
https://github.com/charleso/sbt2nix/blob/83a95e5cac9267bf462f52fed94a113a5a513075/plugin/src/main/resources/sbt.nix).
All in all, you can probably get Sbt2nix to do the right thing, but unless
your project is either new or has a very vanilla build setup then it looks
like you would basically end up reimplementing your SBT plugins in bash.
However, if you do get it to work, then you should get faster builds,
better caching, and a smaller risk of impurities sneaking in.

Sbtix, on the other hand, has one build for the whole SBT "build", and
(currently) only tries to implement a Nix-managed "offline mode" for SBT,
where Nix takes care of dependencies but lets SBT handle how to actually
build the project. So any SBT plugins you use should still "just work".

Another side effect of how Sbtix works is that you could just take the
environment it builds, serve it on a web server, and use it as your primary
resolver to avoid everyone in your organization needing to hit up Maven
Central to whenever they/their IDE decide to redownload the world, without
requiring that everyone uses Nix for local development builds.



On 27 August 2016 at 17:29, Matan Shenhav <ma...@fluxcraft.net> wrote:

> Yes! Awesome stuff. Our team is currently setting up a development
> environment, and this will come in handy!
>
> How does this project stand in relation to Sbt2nix
> <https://github.com/charleso/sbt2nix>?
>
>
>  * * * * *
>
> Matan Bendix Shenhav
>
> *Chief Science Officer*Fluxcraft
> +358 (0)45 6 135 315
>
>
>  On Fri, 26 Aug 2016 13:13:24 -0700 *Teo Klestrup
> Röijezon<t...@nullable.se <t...@nullable.se>>* wrote 
>
> Hi,
>
> Lately I've been working on a project to help build SBT projects with Nix:
> https://github.com/teozkr/Sbtix.
>
> Currently it provides some basic project boilerplate and downloads your
> project dependencies for you (like Bundix), but it would be nice to have it
> also download, say, your SBT plugins and the pinned SBT version. Those are
> currently not handled, since the current (hacky) way of discovering all SBT
> projects in the build does not find build projects.
>
> It's also pretty invasive at the moment, since it requires you to replace
> SBT's native Ivy dependency resolver with Coursier. In most cases it should
> be a drop-in replacement, but naturally I'm sure there are edge cases I
> haven't thought of.
>
> Do you guys think this is something worth pursuing further?
>
> // 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

[Nix-dev] Sbtix - SBT project builder

[Teo Klestrup Röijezon]

Hi,

Lately I've been working on a project to help build SBT projects with Nix:
https://github.com/teozkr/Sbtix.

Currently it provides some basic project boilerplate and downloads your
project dependencies for you (like Bundix), but it would be nice to have it
also download, say, your SBT plugins and the pinned SBT version. Those are
currently not handled, since the current (hacky) way of discovering all SBT
projects in the build does not find build projects.

It's also pretty invasive at the moment, since it requires you to replace
SBT's native Ivy dependency resolver with Coursier. In most cases it should
be a drop-in replacement, but naturally I'm sure there are edge cases I
haven't thought of.

Do you guys think this is something worth pursuing further?

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

[Nix-commits] [NixOS/nixpkgs] 2fb541: oidentd: Set C dialect to gnu89 (broken by GCC 5)

[Teo Klestrup Röijezon]

  Branch: refs/heads/release-16.03
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 2fb54132c0e9114cedc9b0c0fddd7cdca95605c4
  
https://github.com/NixOS/nixpkgs/commit/2fb54132c0e9114cedc9b0c0fddd7cdca95605c4
  Author: Teo Klestrup Röijezon <t...@nullable.se>
  Date:   2016-07-27 (Wed, 27 Jul 2016)

  Changed paths:
M pkgs/servers/identd/oidentd/default.nix

  Log Message:
  ---
  oidentd: Set C dialect to gnu89 (broken by GCC 5)

(cherry picked from commit 2d4af4b97908f129602390e6ab9c0c7f2be00a62)


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

Re: [Nix-dev] Hydra out of disk space

[Teo Klestrup Röijezon]

How much space does it currently take up?

On 16 July 2016 at 11:50, Mateusz Czaplinski  wrote:

> Sorry if this was already discussed, but I had a thought recently,
> that if the Hydra farm has recurring trouble with capacity, maybe
> there is a chance some third-party company or individual would be
> willing to contribute hardware, e.g. if asked for help on Hacker News,
> twitter, etc.
>
> On Fri, Jul 15, 2016 at 10:13 PM, Bjørn Forsman 
> wrote:
> > Hi all,
> >
> > I don't know if it's needed or not (you are probably aware), but here
> > is a reminder that hydra builds are still failing due to "out of disk
> > space".
> >
> > - Bjørn
> > ___
> > 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] Tips on deploying a Scala Play application

[Teo Klestrup Röijezon]

Hi Erik,

Strictly speaking then parsets-playground.nix is the only one that's
required here. parsets.nix is for the ParseTS binary itself (a
run-of-the-mill Haskell project) and default.nix is only there to get
nix-build and nix-shell working. Didn't realize that the exec part was
there in mine too, sorry about that. Anyway, what was the error message it
gives you?

Perhaps it would be better to take this over IRC instead, to avoid spamming
the mailing list with too much back-and-forth.

// Teo

On 7 July 2016 at 09:44, 4levels <4lev...@gmail.com> wrote:

> Hi Teo,
>
> thank you for the brief introduction into the different contexts, I was
> not aware of this at all and was using trial-and-error to get things
> running.
> I still need to learn a lot here, that's for sure!
>
> Regarding parseTS: do I need to setup something similar to your
> parsets.nix (adjusted for my needs) or can I skip this completely?  In
> other words, in your github repo here
> https://github.com/BlocklandGlass/ParseTS-Playground which files do I
> need to adjust / implement? Do I understand correctly that I'll have to
> look at these 3 files?
> - defaults.nix
> - parsets.nix
> - parsets-playground.nix
>
> The file parsets-plaground-wrapper.nix in your deployment folder is
> sufficient for the nixops part of this story, right?
>
> Too bad you couldn't spot the issue, did you receive both my emails (since
> one was being held for moderation)?
>
> Regarding the exec in the systemd definition: this is what I copied from
> your code here:
> https://github.com/BlocklandGlass/ParseTS-Playground/blob/master/deployment/parsets-playground-wrapper.nix
>
> I'm still trying to get in touch with some other people who might be able
> to shed some light on how to deploy a Play application correctly.  I'm glad
> to see that you pulled it off in your demo on nullable.se ;-)
>
>
> Thanks again for your support!
>
> Erik
>
> On Wed, Jul 6, 2016 at 10:00 PM Teo Klestrup Röijezon <t...@nullable.se>
> wrote:
>
>> Hey Erik,
>>
>> > how does the sequence of the nixops modify files matter?
>>
>> The files listed are merged when building the actual NixOS configurations.
>>
>> > when to use with *import ;* or *{ stdenv, lib, config, pkgs,
>> ... }:* and what are the differences
>>
>> I think there are actually three different contexts to keep in mind here:
>> packages definitions, NixOS modules, and standalone nix definitions. Quick
>> disclaimer: I am by no means an expert either.
>>
>> For regular packages, you should take the dependencies as arguments. That
>> makes it easy to override them with, say, patched versions. Also, the
>> channel might not always be named nixpkgs, and it might not even be in
>> NIX_PATH at all.
>>
>> For NixOS modules (including when part of NixOps network definitions),
>> the same concerns apply, and Nixpkgs as a whole should instead be injected
>> through the `pkgs` argument. I'm not sure, but I don't believe the `config`
>> is accessible at all using `import`.
>>
>> Finally, for standalone nix definitions (mostly useful for the
>> `default.nix` used for development builds), you'll need to use `import`.
>>
>> Regarding the error, there's not really much that stands out to me right
>> now, except for that you shouldn't use `exec` in systemd services. That
>> shouldn't cause a build error, though.
>>
>> // Teo
>>
>> On 6 July 2016 at 17:10, 4levels <4lev...@gmail.com> wrote:
>>
>>> Hi Teo,
>>>
>>> I knew I was getting off course with my conclusions, thanks for
>>> clarifying this!
>>>
>>> I'll try to give you an overview, I don't mind adding you to our private
>>> Bitbucket repo if you'd like to see all files and folders.
>>> I still don't know where I should add the statements to have the play
>>> project deployed.  All I have for now is the project's directory in a
>>> subfolder, src/play.mancloud.eu
>>>
>>> I still have many questions regarding nixo(p)s internals:
>>> - how does the sequence of the nixops modify files matter?
>>> - when to use with *import ;* or *{ stdenv, lib, config, pkgs,
>>> ... }:* and what are the differences
>>> - ..
>>>
>>> I'll try to give you an explanation of how the deploy scripts are
>>> composed below.  There's still a lot of room for improvements and
>>> regrouping of statements as I'm still a nix beginner..
>>>
>>>
>>> *nixops info* output
>>> Nix expressions: vultr.nix defaults-local.nix defaults.nix
>>> servers-loc

Re: [Nix-dev] Tips on deploying a Scala Play application

[Teo Klestrup Röijezon]

me) cfg.platforms);
> requires = [ "keys.target" "network.target" "mysql.target" ] ++
> lib.mapAttrsToList (n: v:
>   "diem-${n}.service"
> ) (lib.filterAttrs (n: v: n < name) cfg.platforms);
> environment = {
>   inherit (config.environment.variables) SSL_CERT_FILE;
> };
> serviceConfig.ExecStart = "${serviceDir}/${name}/nixSetup.sh";
>   };
> };
>   serverActivation = value:
> lib.concatStrings (lib.mapAttrsToList(n: v:
>   if (lib.isAttrs(v) && lib.hasAttr("platform") v) then
> "${packageActivation n v};"
>   else ""
>   ) value
> );
>   packageActivation = name: value:
> {
>   name = "diem-${name}";
>   value =
> ''
>   # create / symlink project dirs
>   mkdir -p ${serviceDir}/${name}
>   mkdir -p
> ${serviceDir}/${name}/{cache/dm,config/dm,data/backup/db,data/backup/uploads,data/restore/db,data/restore/uploads,data/dm/i18n,data/exports,log,web/uploads}
>
>   # letsEncrypt script
>   cp ${pkgs.writeText "letsEncrypt.sh" "${letsEncrypt name value}"
> } ${serviceDir}/${name}/letsEncrypt.sh
>   chmod +x ${serviceDir}/${name}/letsEncrypt.sh
>
>   # nixSetup script
>   cp ${pkgs.writeText "nixSetup.sh" "${nixSetup name value}" }
> ${serviceDir}/${name}/nixSetup.sh
>   chmod +x ${serviceDir}/${name}/nixSetup.sh
>
>   # s3Backup script
>   cp ${pkgs.writeText "s3Backup.sh" "${s3Backup name}" }
> ${serviceDir}/${name}/s3Backup.sh
>   chmod +x ${serviceDir}/${name}/s3Backup.sh
> '';
> };
>   diem = (import ./diem-package.nix);
>   ...
>
> in
> with lib;
> {
>   options = {
> services.diem = {
>   platforms = mkOption {
> default = {};
> example = {
>   test = {
> database = {
>   password = "foopass";
> };
> timezone = "Europe/Brussels";
>   };
> };
>   };
> };
>   };
>
>   config = mkIf (cfg.platforms != {}) {
> system.activationScripts = mapAttrs' packageActivation cfg.platforms;
>     systemd.services = mapAttrs' systemdService cfg.platforms // timers
> cfg.platforms;
>   };
> }
>
> *diem-package.nix* contains the packaging statements, read from a github
> repo
>
> with import  {};
> pkgs.stdenv.mkDerivation rec {
>   name = "diem-1.0.0";
>   src = pkgs.fetchgit {
> url = "https://github.com/diem-project/diem.git;;
> rev = "refs/heads/master";
> sha256 = "11scd9z7h91bd242gvy0grnlx75d25ckx1k0k3qvz74p55f1kww7";
>   };
>
>   buildPhase = "true";
>   installPhase =
> ''
>   mkdir -p $out
>   cp -r * $out
> '';
> }
>
>
>
> *keys-vm01.nix* contains the inclusions of the configuration keys and
> other sensitive data for this host
>
> {
>   vm01 =
> { config, pkgs, lib, ... }:
> let
>   serverKeys = keys:
> lib.genAttrs keys (n:
>   {
> text = lib.removeSuffix "\n" (builtins.readFile (./keys/vm01 + 
> "/${builtins.replaceStrings ["@"] ["-"] n}") );
> group = "keys";
> permissions = "0640";
>   }
> )
>   ;
> in
> {
>   deployment.keys = serverKeys [
> "diem.project.database.password"
> "diem.project.encryption.cipher"
> "diem.project.encryption.key"
> ...
>   ];
> };
> }
>
>
> platform-local.nix contains the project definitions per server
>
> with import ;
> {
>   vm01 =
> { config, pkgs, ... }:
> {
>   services.diem.platforms = {
> project = {
>   domain = "local.project";
>   path = "/data/dev/projects/project";
> };
>   };
>   ...
> };
> }
>
>
> Kind regards and thank you again for your willing and friendly attitude!
>
> Erik
>
>
>
>
>
> On Wed, Jul 6, 2016 at 5:41 AM Teo Klestrup Röijezon <t...@nullable.se>
> wrote:
>
>> HI Erik,
>>
>> That's pretty much entirely wrong. :P ParseTS is just a linter script for
>> the game scripting language TorqueScript. ParseTS-Playground was a pastebin
>> that would run the submitted code through the linter. For example, see
>&g

Re: [Nix-dev] Tips on deploying a Scala Play application

[Teo Klestrup Röijezon]

HI Erik,

That's pretty much entirely wrong. :P ParseTS is just a linter script for
the game scripting language TorqueScript. ParseTS-Playground was a pastebin
that would run the submitted code through the linter. For example, see
https://parsets-playground.nullable.se/snippets/13. The datastore used was
PostgreSQL.

Anyway, apart from the ParseTS stuff, at least those scripts should be
pretty much straightforward to copy to any Play application, though for the
config stuff to work you'll need to add the line 'include "local.conf"' to
your conf/application.conf.

Any chance you could post your current setup and the errors you get?

// Teo

On 6 July 2016 at 04:31, 4levels <4lev...@gmail.com> wrote:

> Hi Teo,
>
> I've come quite far in setting up things, but I keep running into building
> errors.
> It has everything to do with me removing all references to parsets and
> postgres and renaming things here and there, trying to merge them with the
> current deploy setup.
>
> Do I understand correctly that parsets is a library to store data, using
> postgres in the background?  I'd like to start using Event Sourcing with
> Scala / Akka so I don't need a datastore like parsets, correct?  I'm very
> unsure about this as I literally started today with learning Scala / Play.
> I got my toes wet with Java before but that's really it.
>
> Something else I found interesting as I'm quite an Nginx fan and have
> nginx running with proxies already: Nginx has capabilities to deal with
> Java in different ways, as proxy or tied with eg Clojure for even faster
> results..
>
> The journey continues ;-)
>
>
> Kind regards,
>
> Erik
>
> On Tue, Jul 5, 2016 at 10:23 PM 4levels <4lev...@gmail.com> wrote:
>
>> Hi Teo,
>>
>> Thank you for your explanation and quick qualitative response!
>>
>> I'll be looking at your code asap and report back with my experiences ;-)
>>
>> Kind regards,
>>
>> Erik
>>
>> On Tue, Jul 5, 2016, 22:08 Teo Klestrup Röijezon <t...@nullable.se> wrote:
>>
>>> Hi,
>>>
>>> A JRE should be enough for running it, but you need sbt and a JDK for
>>> building. I've got a derivation for a Play website at
>>> https://github.com/BlocklandGlass/ParseTS-Playground/blob/master/parsets-playground.nix,
>>> with the NixOS/NixOps setup at
>>> https://github.com/BlocklandGlass/ParseTS-Playground/tree/master/deployment
>>> .
>>>
>>> The gist of it is to run "sbt stage" in the build phase, and to then
>>> take "target/universal/stage" as your build output. However, you'll also
>>> need to wrap the launcher script to add your JRE and to add gawk (which the
>>> launcher script requires). Finally, on any modern system (such as NixOS)
>>> you'll also want to disable Play's PID file management, since systemd takes
>>> care of that anyway. I didn't in that script, but you'll probably also want
>>> to add a testing phase as part of the build.
>>>
>>> The big drawback with this approach is that SBT downloads all
>>> dependencies from the internet on demand, which won't work on a Nix setup
>>> with proper isolation (ideally, builds should only have network access if
>>> they deterministically produce a given hash).
>>>
>>> I've been toying with the idea of writing a sbt2nix SBT plugin that
>>> generates Nix definitions to build a local maven mirror for the
>>> dependencies, but I haven't got around to that (yet).
>>>
>>> // Teo
>>>
>>> On 5 July 2016 at 21:52, 4levels <4lev...@gmail.com> wrote:
>>>
>>>> Hi Nix-devs,
>>>>
>>>> This is a plain request for assistance / best practices for using Nixos
>>>> with Java / Scala / Play.  Akka with EventSourcing are also a topic of
>>>> interest.
>>>>
>>>> I'm currently trying to get a Scala Play app up and running on my
>>>> nixOps deployed machines.  As I'm very unfamiliar with running Java based
>>>> apps, I'd like to know if someone has experience on the common pitfalls and
>>>> tips on keeping the servers healthy (I just caused my laptop's 8 cores to
>>>> go 100% without being able to stop the server started by the activator
>>>> call).
>>>>
>>>> I've seen some related packages in nixpkgs and have many questions like
>>>> eg. do I need sbt (which seems to provide typesafe - activator) and a jdk
>>>> on the production servers or are is a jre sufficient? How do I deploy and
>>>> run a Java app developed locally?
>>>> And how do I set-up a local nixos vm for Java development?
>>>>
>>>> I'm still investigating and learning a lot myself, so nix-related
>>>> knowledge is my main concern here (as I need to figure out the rest myself
>>>> anyway ;-)
>>>>
>>>> I'll be happy to share my findings and configuration / setup..
>>>>
>>>>
>>>> Kind regards,
>>>>
>>>> Erik
>>>>
>>>> ___
>>>> 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] Tips on deploying a Scala Play application

[Teo Klestrup Röijezon]

Hi,

A JRE should be enough for running it, but you need sbt and a JDK for
building. I've got a derivation for a Play website at
https://github.com/BlocklandGlass/ParseTS-Playground/blob/master/parsets-playground.nix,
with the NixOS/NixOps setup at
https://github.com/BlocklandGlass/ParseTS-Playground/tree/master/deployment.

The gist of it is to run "sbt stage" in the build phase, and to then take
"target/universal/stage" as your build output. However, you'll also need to
wrap the launcher script to add your JRE and to add gawk (which the
launcher script requires). Finally, on any modern system (such as NixOS)
you'll also want to disable Play's PID file management, since systemd takes
care of that anyway. I didn't in that script, but you'll probably also want
to add a testing phase as part of the build.

The big drawback with this approach is that SBT downloads all dependencies
from the internet on demand, which won't work on a Nix setup with proper
isolation (ideally, builds should only have network access if they
deterministically produce a given hash).

I've been toying with the idea of writing a sbt2nix SBT plugin that
generates Nix definitions to build a local maven mirror for the
dependencies, but I haven't got around to that (yet).

// Teo

On 5 July 2016 at 21:52, 4levels <4lev...@gmail.com> wrote:

> Hi Nix-devs,
>
> This is a plain request for assistance / best practices for using Nixos
> with Java / Scala / Play.  Akka with EventSourcing are also a topic of
> interest.
>
> I'm currently trying to get a Scala Play app up and running on my nixOps
> deployed machines.  As I'm very unfamiliar with running Java based apps,
> I'd like to know if someone has experience on the common pitfalls and tips
> on keeping the servers healthy (I just caused my laptop's 8 cores to go
> 100% without being able to stop the server started by the activator call).
>
> I've seen some related packages in nixpkgs and have many questions like
> eg. do I need sbt (which seems to provide typesafe - activator) and a jdk
> on the production servers or are is a jre sufficient? How do I deploy and
> run a Java app developed locally?
> And how do I set-up a local nixos vm for Java development?
>
> I'm still investigating and learning a lot myself, so nix-related
> knowledge is my main concern here (as I need to figure out the rest myself
> anyway ;-)
>
> I'll be happy to share my findings and configuration / setup..
>
>
> Kind regards,
>
> Erik
>
> ___
> 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] Stackage Support Will Be Discontinued

[Teo Klestrup Röijezon]

Fair enough, that seems like a reasonable solution.

On 11 June 2016 at 18:31, Benno Fünfstück <benno.fuenfstu...@gmail.com>
wrote:

> Teo Klestrup Röijezon <t...@nullable.se> schrieb am Mi., 8. Juni 2016 um
> 21:58 Uhr:
>
>> 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.
>>
>
> There should be still a way to do this. I don't think stackage supports
> needs to be removed from `hackage2nix` or `cabal2nix`, so you can still
> simply generate your own `hackage-packages.nix` and include that with your
> project to pin the hackage snapshot.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

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] break purity

[Teo Klestrup Röijezon]

You can set up a build environment resembling what nix-build would use
using the nix-shell command. All dependencies are provided, and each build
phase gets a function.

On 21 April 2016 at 17:42, 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] Did we just get windows support for free?

[Teo Klestrup Röijezon]

Yes, but there's some hidden switch you need to flip in order to allow it.

On 30 March 2016 at 22:46, stewart mackenzie  wrote:

> Does windows support symlinks in non-administrator mode?
>
> ___
> 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

[Teo Klestrup Röijezon]

D'oh! Disabling StrictHostKeyChecking made it work perfectly, thanks!

On 25 March 2016 at 23:28, Domen Kožar <do...@dev.si> wrote:

> See https://github.com/peti/hydra-tutorial/issues/2
>
> On Fri, Mar 25, 2016 at 9:48 PM, Teo Klestrup Röijezon <t...@nullable.se>
> wrote:
>
>> For the record, it says something about host key verification failing. If
>> I try to run `ssh g...@bitbucket.org` sudoed as either user it works and
>> shows that it should have access to the repo.
>>
>> On 25 March 2016 at 22:47, Teo Klestrup Röijezon <t...@nullable.se> wrote:
>>
>>> Did that for both hydra and hydra-queue-runner, no luck. :/
>>>
>>> On 25 March 2016 at 21:29, Oliver Charles <ol...@ocharles.org.uk> wrote:
>>>
>>>> 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 <t...@nullable.se>
>>>> 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
>>
>>
>
___
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

[Teo Klestrup Röijezon]

For the record, it says something about host key verification failing. If I
try to run `ssh g...@bitbucket.org` sudoed as either user it works and shows
that it should have access to the repo.

On 25 March 2016 at 22:47, Teo Klestrup Röijezon <t...@nullable.se> wrote:

> Did that for both hydra and hydra-queue-runner, no luck. :/
>
> On 25 March 2016 at 21:29, Oliver Charles <ol...@ocharles.org.uk> wrote:
>
>> 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 <t...@nullable.se>
>> 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] Hydra jobs from private git repositories

[Teo Klestrup Röijezon]

Did that for both hydra and hydra-queue-runner, no luck. :/

On 25 March 2016 at 21:29, Oliver Charles <ol...@ocharles.org.uk> wrote:

> 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 <t...@nullable.se>
> 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

[Nix-dev] Hydra jobs from private git repositories

[Teo Klestrup Röijezon]

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

Re: [Nix-dev] Open source team messaging: mattermost

[Teo Klestrup Röijezon]

Plain IRC sucks. IRCCloud does indeed make it a bit better, but (as a
paying subscriber) asking newcomers to subscribe to a paid service to get
an acceptable client isn't exactly welcoming.

On 1 March 2016 at 23:31, Moritz Ulrich  wrote:

>
> Please don't make me keep open yet another tab / yet another IM client
> for just another chat room I have to idle in. It won't work, I already
> have enough of those.
>
> And no, some kind of gateway to
> irc/slack/email/twitter/facebook/whatsapp/snapchat/tcp-over-avian-carrier
> won't work.
>
> Wout Mertens  writes:
>
> > Check it out: http://www.mattermost.org/
> >
> > Any chance of using that instead of/in addition to IRC?
> >
> > Wout.
> > --
> >
> > Wout.
> > (typed on mobile, excuse terseness)
> > ___
> > 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] How to use a previous build from hydra-server

[Teo Klestrup Röijezon]

I believe it tries all of them that are on the search path ($NIX_PATH), and
picks the one with the latest version of whatever package you're installing
(highest version number). All dependencies come from the same channel
(though that channel might, in turn, import them from another channel). By
default nix will only put nixpkgs=/path/to/your/downloaded/nixpkgs/channel
in $NIX_PATH, so you'll need to add custom channels to that, too, if you
want to use them.

For the imperative mode (nix-env), you can pick by specifying the -f flag.
So for example, "nix-env -i firefox -f ''" will install Firefox
from the channel named nixpkgs. For a channel that isn't on $NIX_PATH, use
"... -f $HOME/.nix-defexpr/channels/nixpkgs" instead.

For NixOS' declarative mode (nixos-rebuild)'s environment.systemPackages,
instead of adding pkgs.whatever, add myOtherChannel.pkgs.whatever, where
myOtherChannel might be defined earlier as "import  {}".

For NixOS service modules, the module's configuration typically include a
.pkg option, which you can change to a reference to wherever you want.

On 8 December 2015 at 09:29, Roger Qiu <roger@polycademy.com> wrote:

> If there are multiple channels (custom channels included) available, how
> does Nix choose from which to install, and is there a way for us to pick a
> preference?
> On 08/12/2015 5:52 PM, "Teo Klestrup Röijezon" <t...@nullable.se> wrote:
>
>> You can import a package from a specific version of nixpkgs, independent
>> of the rest of your build, though it's a bit of a manual process.
>>
>> First, check on Hydra which Git revision it is that you want to build
>> (you can see this on the Inputs tab,
>> 144d13cf2cc6de28f8abe9e9e8c98f28ccf8fc59 in this case). Then check what
>> Nix's hash of that revision is, (either by running nix-prefetch-git or by
>> looking at the store path in the Inputs tab, in this case
>> phb6bdyhvnsx92mh78jysaavgviwqpbr). Then replace the reference to the
>> package with a reference to the package in that version of nixpkgs. Now,
>> with most NixOS modules you could do this by setting something like
>>
>> services.mesos.pkg = (import (lib.fetchGit {
>>   url = https://github.com/NixOS/nixpkgs.git;
>>   rev = "144d13cf2cc6de28f8abe9e9e8c98f28ccf8fc59";
>>   sha256 = "phb6bdyhvnsx92mh78jysaavgviwqpbr";
>> }) {}).pkgs.mesos;
>>
>> However, from what I can tell, the mesos module (
>> https://github.com/NixOS/nixpkgs/blob/788800e437c4a0a25d95e217540bded68804b25e/nixos/modules/services/misc/mesos-slave.nix)
>> is one of the few modules that don't support replacing the package used.
>> So, uh, that's a problem that should probably be fixed, but won't really
>> help you right now. :/
>>
>> On 8 December 2015 at 05:08, rohit yadav <rohityadav7...@gmail.com>
>> wrote:
>>
>>> Hi Rok,
>>>
>>> Thanks for reply. How should I fetch it? I mean how to tell the system
>>> to use that particular build? Currently, when I say nixos-rebuild {boot |
>>> switch} it assumes that that  (which again I am not sure which one
>>> it refers to when I have to two channels listed) would tell it the right
>>> hash and it would fetch that from the server. I dunno know how to by-pass
>>> that and directly fetch any particular build from hydra. Could you please
>>> elaborate on this or refer to the documentation where it is described in
>>> more detail.
>>>
>>> Thanks,
>>> Rohit
>>>
>>> On Mon, Dec 7, 2015 at 9:45 PM, Rok Garbas <r...@garbas.si> wrote:
>>>
>>>> you can fetch mesos directly from hydra
>>>>
>>>>
>>>> http://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.mesos.x86_64-linux
>>>>
>>>> check latest successful build for instructions.
>>>>
>>>>
>>>>
>>>> Quoting rohit yadav (2015-12-08 03:54:05)
>>>> > One more question. Is it possible to add two channels? Say one
>>>> unstable and one
>>>> > previous stable channel and choose module from one of them?
>>>> >
>>>> > Thanks.
>>>> > Rohit
>>>> >
>>>> > On Mon, Dec 7, 2015 at 8:47 PM, rohit yadav <rohityadav7...@gmail.com>
>>>> wrote:
>>>> >
>>>> > Hi,
>>>> >
>>>> > Currently Mesos package is broken on nixos-unstable channel,
>>>> therefore, I
>>>> > cannot install it on my server. Is there a way to install a
>>>> previous
>>>> > successful build?
>>>> >
>>>> > Thanks,
>>>> > Rohit
>>>> >
>>>> >
>>>>
>>>>
>>>> --
>>>> Rok Garbas - http://www.garbas.si
>>>>
>>>
>>>
>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>>
>>
>> ___
>> nix-dev 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 a previous build from hydra-server

[Teo Klestrup Röijezon]

You can import a package from a specific version of nixpkgs, independent of
the rest of your build, though it's a bit of a manual process.

First, check on Hydra which Git revision it is that you want to build (you
can see this on the Inputs tab, 144d13cf2cc6de28f8abe9e9e8c98f28ccf8fc59 in
this case). Then check what Nix's hash of that revision is, (either by
running nix-prefetch-git or by looking at the store path in the Inputs tab,
in this case phb6bdyhvnsx92mh78jysaavgviwqpbr). Then replace the reference
to the package with a reference to the package in that version of nixpkgs.
Now, with most NixOS modules you could do this by setting something like

services.mesos.pkg = (import (lib.fetchGit {
  url = https://github.com/NixOS/nixpkgs.git;
  rev = "144d13cf2cc6de28f8abe9e9e8c98f28ccf8fc59";
  sha256 = "phb6bdyhvnsx92mh78jysaavgviwqpbr";
}) {}).pkgs.mesos;

However, from what I can tell, the mesos module (
https://github.com/NixOS/nixpkgs/blob/788800e437c4a0a25d95e217540bded68804b25e/nixos/modules/services/misc/mesos-slave.nix)
is one of the few modules that don't support replacing the package used.
So, uh, that's a problem that should probably be fixed, but won't really
help you right now. :/

On 8 December 2015 at 05:08, rohit yadav  wrote:

> Hi Rok,
>
> Thanks for reply. How should I fetch it? I mean how to tell the system to
> use that particular build? Currently, when I say nixos-rebuild {boot |
> switch} it assumes that that  (which again I am not sure which one
> it refers to when I have to two channels listed) would tell it the right
> hash and it would fetch that from the server. I dunno know how to by-pass
> that and directly fetch any particular build from hydra. Could you please
> elaborate on this or refer to the documentation where it is described in
> more detail.
>
> Thanks,
> Rohit
>
> On Mon, Dec 7, 2015 at 9:45 PM, Rok Garbas  wrote:
>
>> you can fetch mesos directly from hydra
>>
>> http://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.mesos.x86_64-linux
>>
>> check latest successful build for instructions.
>>
>>
>>
>> Quoting rohit yadav (2015-12-08 03:54:05)
>> > One more question. Is it possible to add two channels? Say one unstable
>> and one
>> > previous stable channel and choose module from one of them?
>> >
>> > Thanks.
>> > Rohit
>> >
>> > On Mon, Dec 7, 2015 at 8:47 PM, rohit yadav 
>> wrote:
>> >
>> > Hi,
>> >
>> > Currently Mesos package is broken on nixos-unstable channel,
>> therefore, I
>> > cannot install it on my server. Is there a way to install a previous
>> > successful build?
>> >
>> > Thanks,
>> > Rohit
>> >
>> >
>>
>>
>> --
>> Rok Garbas - http://www.garbas.si
>>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Replace module options

[Teo Klestrup Röijezon]

mkForce (https://nixos.org/nixos/manual/index.html#sec-modularity) is
probably what you're looking for then.

On 29 November 2015 at 17:29, Игорь Пашев  wrote:

> 2015-11-29 19:26 GMT+03:00 Joel Moberg :
> > I think every service have a enable attribute, you should be able to set
> > this to false or just override that service with another one (example
> > config.systemd.services.alsa-store.enable=false). nix-repl is useful to
> > inspect what your config looks like, you can invoke it with nix-repl
> > '' and investigate the attribute 'config'.
>
>
> I tried to override the "enable" option a well. And it said
> "The option `services.foo.enable' in  is already declared in
> " ¯\_(ツ)_/¯
> ___
> 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