[Nix-dev] nss_ldap crashing
Hello, we've been trying to update an old nixos with upstart (glibc 2.13) to master, and it's our ldap server. Some weird pieces were crashing (nscd, sshd, samba), while all work fine in the old system. I've seen nss_ldap is pretty old (2009 latest, 2008 that of nixpkgs), and redhad has some fixes over the latest even. I tried all that, and I couldn't make it work fine. Am I just going a bad path, trying to use that nss_ldap thing? :) It looks so abandoned... Anyone using ldap? Suggestions? Thank you, Lluís. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Stable NixOS releases
Can we talk about the details - how to actually name branches? I propose having the names: - "next" receiving tested breaking updates (thus is what is master now) - "stable" receiving non breaking updates only - this will be aliased to 2013-Q2 - 2013-Q1 receiving non breaking update only older stable branches (eventually no longer maintained): 2012-Q4 Thus if you subscribe to 2013-Q2 you are stable now, and continue to be stable for another 3 month which is what you asked for? The important bit is to understand that stable and "2013-Q2" refer to the same commits, thus you can follow "stable" or "2013-Q2" While stable will upgrade every 3 month, 2013-QN will never. What about nixos vs nixpkgs? When the branching hell starts, does it make sense to introduce a nixos/nixpkgs repository whose sole purpose is to to have two submodules (nixos and nixpkgs), then you could specify versions when using nixos-rebuild --upgrade or nixos-install this way: nixos-install github.com/nixos/nixos-nixpkgs --branch next # current stable, breaking changes should go to next nixos-install github.com/nixos/nixos-nixpkgs --branch stable # breaking changes should go to next The big advantage is that people like me using their own "haskell-overlays" could simply create their own branch of nixos-nixpkgs which also checks out haskell & ruby overlays. So we should consider such a change, too. I'm in favor of not creating too many rules - we should also adopt to what changes we are exposed to (eg which kde/gtk/.. updates will happen etc) - or specifying which packages / test cases belong to a "release" and must be taken care of. Maybe we can manage to have something like release.nix to specify this - and treat other packages less seriously. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell packages in the binary cache broken?
Looking at the end of your stage-4 log we see that a build failed because containers-0.4.2.1-75f143aa39a3e77a1ce2300025bdd8ce is missing. That is part of ghc, and the nix hash of your ghc-wrapper is vlx3ikjjxlfvqjjlx74cg07p79y43mdq, which agrees with the Hydra trunk: http://hydra.nixos.org/build/4491149 So your ghc and the binary cache one should be the same, thus the missing containers should be there. Would you check with ghc-pkg -v --global list whether or not your local GHC has the same containers as Hydra? From the build log errors I think it must not. The Hydra ghc does have a containers with the right GHC ABI hash: http://hydra.nixos.org/build/4485890/contents/1 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Stable NixOS releases
On 05/16/2013 12:31 PM, Peter Simons wrote: Now, steps (1) and (2) are easy. Step (3) is hard, because it's an on-going effort that someone needs to pay attention to constantly. Also, propagating changes from master into the release branch can be difficult, because the commits in question may depend on previous changes in 'master' that we don't want to propagate. Does that sound right? Yes, and it's essentially the thing I wrote. One can see easily how far the changes from master has been cherry-picked (by authorship date, or we could have in-repo text file describing the ported changes anyway). So if it's forgotten for some time, we can still catch up easily. The only thing is to mark somehow which changes are suitable for updating the stable branch (we probably only want to do it after some time of testing in master). Porting the changes shouldn't be so difficult, because the non-intrusive important bugfixes IMO almost never depend on changing anything else. As for security updates, I suppose some people who maintain NixOS servers watch these (through RSS?)... cherry-picking security updates is usually very easy (one-liner patches). Vlada 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] Stable NixOS releases
Hi Eelco, > It would be good to have stable releases that get bug fixes for a > certain amount of time. For instance, we could make a stable release > every 3 months or so, named (Ubuntu-style) ., e.g. 13.06, > 13.09, and so on. let me try to translate this goal into actions that need to be taken in order to achieve it: 1) At the beginning of every quarter, we create release branches 'nixos-.mm' and 'nixpkgs-.mmm' from the current 'master' branch of the respective repository. 2) We create Hydra jobsets that build the desired artifacts (binary package cache, Install CD, EC2 AMIs, etc.) for those release branches. 3) Whenever a change is committed to 'master' that qualifies as an important but un-intrusive update, we propagate that change to all active release branches. Now, steps (1) and (2) are easy. Step (3) is hard, because it's an on-going effort that someone needs to pay attention to constantly. Also, propagating changes from master into the release branch can be difficult, because the commits in question may depend on previous changes in 'master' that we don't want to propagate. Does that sound right? Take care, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] firefox elf-hack
Hrm, That proves to be harder than I hoped. I got it to build, but it won't start yet (but gives no errors/warnings). So I will have to dig deeper. On Wed, May 15, 2013 at 3:05 PM, Eelco Dolstra wrote: > Hi, > > On 15/05/13 13:55, Mathijs Kwik wrote: > >> Our current expression for firefox [1] contains the "--disable-elf-hack" >> configureFlag. By default this hack is enabled and is supposed to >> improve performance [2]. After a bit of googling, I found that old >> versions of firefox had issues with this hack, so probably this is the >> reason it got disabled. However, these issues are fixed and I've been >> running with firefox20 _with_ the elf hack for over a week now. >> >> Can we remove this configure flag and stick with the default (hacked) >> behavior? > > Sure. Maybe you can update to Firefox 21 while you're at it ;-) > > -- > 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
