Re: [Nix-dev] [NixOS/nixpkgs] 5c6512: idris: patch 0.9.14 to workaround a bug
Hi John, > Commit: 0e588f35fc4ab1a94437653f1ad0ad5dc3b961dd > > https://github.com/NixOS/nixpkgs/commit/0e588f35fc4ab1a94437653f1ad0ad5dc3b961dd > Author: John Wiegley > Date: 2014-07-24 (Thu, 24 Jul 2014) > > Changed paths: > M pkgs/development/libraries/haskell/thyme/default.nix > > Log Message: > --- > haskell-thyme: fix for darwin could you please make that change to cabal2nix instead of editing the expression manually? Changes that cabal2nix isn't aware of will be lost during the next update of the package; probably even sooner. I suppose the same applies to commit d7a2884e. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Fwd: Reminder about nixpkgs branches
On Thu, Jul 24, 2014 at 11:03 PM, Eelco Dolstra wrote: > Hi, > > On 24/07/14 21:32, Mathnerd314 wrote: > > Here it's really more appropriate to use nix-env (i.e. the imperative > package > management style), which makes it easy to mix packages from different > Nixpkgs > revisions. > > The declarative style (environment.systemPackages) doesn't work very well > for > this. It's doable if you only want a few packages from one other branch, > but as > you point out, it doesn't scale very well. > > Yes, mixing modules from different NixOS versions doesn't really work. > Here it > > is easier to have a local branch (e.g. based/rebased on release-14.04) onto > which you can cherry-pick the changes you need. > So in this case, I needed to override the packages used by the modules. AFAICT there is no way to do that in nix-env, yet here you are telling me to use nix-env to manage packages. I must have missed that section of the manual... > > > NixOS is inherently a > > state-centric system; it's not "this change broke my system" but > "version V of > > thing X is broken". > > I don't know what this means. > I believe darcs is pretty much the only example of a "change-based" system, so this is more a reply to Vladimír Čunát. Well, nixpkgs-monitor is intended to help package maintainers, not make them > redundant :-) Maintainers should still do testing before they push a patch > from > the monitor. > And that's impossible, since there are always architectures and configurations that maintainers don't have access to. So I say go the other way: if you can't test the dynamic stuff completely, don't test it at all. On the other hand nix-instantiate is (at least theoretically) system-independent so it is reasonable to run it over all packages; it can check syntax, types, etc. - basically everything static. But the dynamic stuff, e.g. Hydra's builds and tests, should only run as often as you want to release, not as often as you want to update a package. > > > The problem is that, currently, Nix expressions are used for two > purposes - > > building packages and specifying systems. Due to integration in the > nixpkgs > > repository, the coupling between these has grown strong. But, as I hope > my > > example has shown, these are orthogonal and independent activities. > Sometimes I > > want to build packages, e.g. when I want to "build the latest version of > Firefox > > from mozilla-central". Other times I want to specify my system, e.g., > "use this > > known-good version of Firefox". If you look closer, you can see the > difference: > > in the first case, I am referring to a dynamic, changing process. In the > second > > case, I just need a store path. However, currently Nix is using the > extensional > > model which intermingles these two. > > I don't see the connection with the extensional model. Since the extensional model only identifies the inputs, it automatically assumes that any two runs of a derivation are the same. > It allows you to specify > a specific version just fine, e.g. > > environment.systemPackages = [ (builtins.storePath > /nix/store/gv67fwcwbyha77kxsmgcs41baqxh2ysi-firefox-31.0) ]; > There's no way to refer to "the result of calling fetchurl http://google.com on July 1st 2013", which can be described with the intensional model (a hash of the contents, as usual). > > (Not the prettiest syntax, but NixOS wasn't really intended for this kind > of > binary-only package management.) > Well, since that's what all my package paths look like, I guess that's the problem in a nutshell. > > The main advantage of the intensional model is that it allows untrusted > users to > fetch binaries from untrusted binary caches. > It also allows derivations to fetch or produce volatile or time-dependent data, which I think is a bigger advantage. > > > On the other side, the release process and picking process becomes > easier. Hydra > > fetches all of the store paths, and it's just a matter of examining the > results > > and picking the builds that seem to work and pass tests. > > This is pretty much the furthest you can get from declarative package > management. Not really, the furthest you could get would be using no package management at all (a.k.a. "life without commodities"). > It makes a release the sum of a bunch of packages from different > Nixpkgs revisions, all built against whatever version of the dependencies > happened to be the most recently built at the time. No, they're built with whatever dependencies happened to be *available* at the time, which is a different story (availability is determined by Hydra; it can use whichever versions it wants, and the versions it uses are sha256'd hashed as usual). > Reproducing such a > configuration is pretty much impossible. No, the only commands you're running are of the form "execute the script on ". The only time they're not reproducible is when they grab external state. If we continue following our packaging process, then commands which grab exte
Re: [Nix-dev] Reminder about nixpkgs branches
Hi, On 24/07/14 21:32, Mathnerd314 wrote: > So let me describe a little of my recent activities. I wanted the firefox from > https://github.com/NixOS/nixpkgs/commit/872860e6de8e460fb11a79c46b8092bdcff35da8, > the > quassel from ~/nixpkgs, and the rest of the system from the latest hydra > channel; I ended up making nixpkgs checkouts for each of those, hard-coding > their paths in import statements, and manually adding each package (and some > of > their dependencies) to packageOverrides. Here it's really more appropriate to use nix-env (i.e. the imperative package management style), which makes it easy to mix packages from different Nixpkgs revisions. The declarative style (environment.systemPackages) doesn't work very well for this. It's doable if you only want a few packages from one other branch, but as you point out, it doesn't scale very well. > Note that, throughout this process, I was *creating* and *picking*, but I > never > needed to revert a commit. I just checked out older versions. I did end up > trying out a single rollback, when I was looking at Quassel's NixOS module; > however, it was completely useless, as the problem was in systemd's unit > dependencies and thus *all* of my versions were broken. Yes, mixing modules from different NixOS versions doesn't really work. Here it is easier to have a local branch (e.g. based/rebased on release-14.04) onto which you can cherry-pick the changes you need. > NixOS is inherently a > state-centric system; it's not "this change broke my system" but "version V of > thing X is broken". I don't know what this means. > However, to set up my system the way I wanted it (i.e., so that all my > programs > worked), I did need 4 different nixpkgs checkouts. And I've only been using > NixOS for a few weeks; as I set up more programs and services I'm probably > going > to need even more than that. Looking at > https://github.com/MarcWeber/nixpkgs/branches/active it seems he has almost 40 > branches. His workflow is slightly different from mine because he uses TopGit > instead of letting Nix do most of the work, but the branch-explosion is > similar. > When we start using nixpkgs-monitor, the problem is going to get even worse: a > steady, near-realtime stream of patches that bump versions, URL's, and hashes, > with no QA or error checking at all. Well, nixpkgs-monitor is intended to help package maintainers, not make them redundant :-) Maintainers should still do testing before they push a patch from the monitor. > The problem is that, currently, Nix expressions are used for two purposes - > building packages and specifying systems. Due to integration in the nixpkgs > repository, the coupling between these has grown strong. But, as I hope my > example has shown, these are orthogonal and independent activities. Sometimes > I > want to build packages, e.g. when I want to "build the latest version of > Firefox > from mozilla-central". Other times I want to specify my system, e.g., "use > this > known-good version of Firefox". If you look closer, you can see the > difference: > in the first case, I am referring to a dynamic, changing process. In the > second > case, I just need a store path. However, currently Nix is using the > extensional > model which intermingles these two. I don't see the connection with the extensional model. It allows you to specify a specific version just fine, e.g. environment.systemPackages = [ (builtins.storePath /nix/store/gv67fwcwbyha77kxsmgcs41baqxh2ysi-firefox-31.0) ]; (Not the prettiest syntax, but NixOS wasn't really intended for this kind of binary-only package management.) The main advantage of the intensional model is that it allows untrusted users to fetch binaries from untrusted binary caches. > On the other side, the release process and picking process becomes easier. > Hydra > fetches all of the store paths, and it's just a matter of examining the > results > and picking the builds that seem to work and pass tests. This is pretty much the furthest you can get from declarative package management. It makes a release the sum of a bunch of packages from different Nixpkgs revisions, all built against whatever version of the dependencies happened to be the most recently built at the time. Reproducing such a configuration is pretty much impossible. (This is in fact the classic Linux package model, where it is typically doubtful whether all binary packages can be reproduced from their specifications.) > After this, my vision is that the nixpkgs repository will only contain very > high-level instructions, for example "to install firefox: got to mozilla ftp > directory; load a folder (branch); download tarball; install to $out }". I assume you mean "fetch the latest version". That's fundamentally incompatible with the idea of purely functional package management. It would mean that running "nix-build -A firefox" on a specific Nixpkgs revision would give a different result at different points in time.
Re: [Nix-dev] Reminder about nixpkgs branches
Hi, On 23/07/14 11:29, Mathijs Kwik wrote: > - staging hasn't been merged for > 2 weeks I don't think there were very urgent things that needed to be merged. Mostly some Mac OS X improvements. There are some build issues with Atlas (which is an inherently broken package anyway) and Clang on Darwin (which I'll look into). But otherwise it can be merged. -- 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
Re: [Nix-dev] Reminder about nixpkgs branches
On Thu, Jul 24, 2014 at 12:52 PM, Vladimír Čunát wrote: > > On 07/23/2014 11:29 AM, Mathijs Kwik wrote: >>> >> If stuff causes regressions, revert it and move it to a feature-branch >> to debug. >> > > Perhaps. I'm not very clear about that. Typically I first try to fix the > regressions within days, if possible. > > Note that this revert+move workflow tends to hit a problem with unclear > semantics of reverts+merges. The catch is that in the case of *temporarily* > undoing some changes, people typically understand revert the other way than > practically all VCS (including git), which leads to surprises. IMO it's > also connected to being state-centric instead of (arguably more natural) > change-centric approach. > > Details: > https://raw.githubusercontent.com/tonyg/revctrl.org/master/output-raw/Rollback > > So let me describe a little of my recent activities. I wanted the firefox from https://github.com/NixOS/nixpkgs/commit/872860e6de8e460fb11a79c46b8092bdcff35da8, the quassel from ~/nixpkgs, and the rest of the system from the latest hydra channel; I ended up making nixpkgs checkouts for each of those, hard-coding their paths in import statements, and manually adding each package (and some of their dependencies) to packageOverrides. But even that wasn't enough, because I also needed to override the NixOS module for quassel; unfortunately it seems the list of imports is hard-coded and there is no moduleOverride function. So, I made yet another nixpkgs checkout, at exactly the revision of the hydra channel, with my module changes on top, and set NIX_PATH to point there. Note that, throughout this process, I was *creating* and *picking*, but I never needed to revert a commit. I just checked out older versions. I did end up trying out a single rollback, when I was looking at Quassel's NixOS module; however, it was completely useless, as the problem was in systemd's unit dependencies and thus *all* of my versions were broken. NixOS is inherently a state-centric system; it's not "this change broke my system" but "version V of thing X is broken". However, to set up my system the way I wanted it (i.e., so that all my programs worked), I did need 4 different nixpkgs checkouts. And I've only been using NixOS for a few weeks; as I set up more programs and services I'm probably going to need even more than that. Looking at https://github.com/MarcWeber/nixpkgs/branches/active it seems he has almost 40 branches. His workflow is slightly different from mine because he uses TopGit instead of letting Nix do most of the work, but the branch-explosion is similar. When we start using nixpkgs-monitor, the problem is going to get even worse: a steady, near-realtime stream of patches that bump versions, URL's, and hashes, with no QA or error checking at all. We already have this, except not automated, with scripts like hackage2nix. What branches should these updates go to? AFAIK there is no good answer. They can't go to master or staging, because they might break Hydra's builds. A new topic branch per patch means we get several thousand branches, i.e. the branch explosion again. There are 126 open pull requests, and probably hundreds more sitting in offline git repositories; as the project grows this will presumably get worse. The branch approach doesn't scale; if I do a lot of version-picking, all of these nixpkgs checkouts will end up in my configuration.nix! The checkouts are a waste of disk space and contain irrelevant information. Not only that, they're fragile; if I change the checkout, then the next time I do a nixos-rebuild the changes get picked up. It's basically a hack, hard-coding all of these checkouts into Nix. The problem is that, currently, Nix expressions are used for two purposes - building packages and specifying systems. Due to integration in the nixpkgs repository, the coupling between these has grown strong. But, as I hope my example has shown, these are orthogonal and independent activities. Sometimes I want to build packages, e.g. when I want to "build the latest version of Firefox from mozilla-central". Other times I want to specify my system, e.g., "use this known-good version of Firefox". If you look closer, you can see the difference: in the first case, I am referring to a dynamic, changing process. In the second case, I just need a store path. However, currently Nix is using the extensional model which intermingles these two. For me this is most obvious in fetchurl; our current fetchurl is basically a hard-coded store path, with a special exception of "fixed-output derivations" hacked into Nix. With an intensional store model, that goes away; a fetchurl is literally "fetchurl.sh " and nothing more. If the URL breaks, then the store path changes and you can just keep using the old store path. If the content moves to a different URL, you can just change the URL and the content hash is still the same, with no fixed-output hack needed. And of course these advantages apply in other cases besides
Re: [Nix-dev] gvim under nixos
Thank you. That helped. Wat is the case with vim*Wrapper? It seting console interface by default in some of .vimrc-s? On 2014-07-24 17:38, Paul Colomiets wrote: > Hi Alexander, > > On Thu, Jul 24, 2014 at 3:41 PM, Alexander Zubkov wrote: >> Hello. >> I have some strange problem. When I run command gvim - then console >> version of editor starts. At the same time gvim or vim with option "-g" >> have no problems opening GUI version of editor. I do not understand why >> this happens. Because I thaught that for gvim incocation GUI mode should >> be default. >> > > You are probably installed `vimWrapper`. It's already not in repo. If > you install any other version of vim (I recommend vim_configurable > a/k/a vimHugeX), gvim will work ok. > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] gvim under nixos
Hello. I have some strange problem. When I run command gvim - then console version of editor starts. At the same time gvim or vim with option "-g" have no problems opening GUI version of editor. I do not understand why this happens. Because I thaught that for gvim incocation GUI mode should be default. -- Alexander Zubkov ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Reminder about nixpkgs branches
On 07/23/2014 11:29 AM, Mathijs Kwik wrote: If stuff causes regressions, revert it and move it to a feature-branch to debug. Perhaps. I'm not very clear about that. Typically I first try to fix the regressions within days, if possible. Note that this revert+move workflow tends to hit a problem with unclear semantics of reverts+merges. The catch is that in the case of *temporarily* undoing some changes, people typically understand revert the other way than practically all VCS (including git), which leads to surprises. IMO it's also connected to being state-centric instead of (arguably more natural) change-centric approach. Details: https://raw.githubusercontent.com/tonyg/revctrl.org/master/output-raw/Rollback A minor llvm upgrade should just go into master or staging. Yes, these shouldn't break anything. BTW, from X stuff only mesa directly depends on it AFAIK, and it is typically among the first to use new major llvm updates. It's other "less hot" packages that often need to lag behind on older llvm versions. Ah, that's quite short indeed :) Please remember, I wasn't pointing fingers. I'm fine with x-updates. Having staging around doesn't change anything in this regard. [...] I was just clarifying the situation. Some of the changes in x-updates would in fact rather belong into staging, as they are often just minor updates. The discussion was about llvm that time. And I believe it happened before with gcc in stdenv-updates. There really is no reason to not get a new LLVM version in master, just because some X stuff uses it. Ah, I see... yes, for really disruptive things like new gcc branch. (Like we do have gcc49 in master, but nothing uses it yet, and even stdenv doesn't build with it.) On 07/24/2014 11:52 AM, Mathijs Kwik wrote:> Vladimír Čunát writes: Extremely short (<1 week) one-topic branches may seem ideal, but currently they're very impractical, for several reasons: [...] 3) Sure I want features stabilized fast, but wishing it isn't enough. [...] I don't see how this would become worse by having smaller feature-branches. [...] No, (3) wouldn't be worse. Maybe just because of (1) being more time-consuming to test/stabilize updates one-by-one. 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] Reminder about nixpkgs branches
Vladimír Čunát writes: > Hi, > it's not at all so bad as it used to be. Last year it happened we had > ~10 months running stdenv-updates that was in the middle getting more > and more breakages with added commits. That wasn't good and all agreed > on that. I'm glad things currently go a lot smoother. I wasn't trying to point any fingers, just to remain aware of the issues that caused that situation. > > Extremely short (<1 week) one-topic branches may seem ideal, but > currently they're very impractical, for several reasons: > > 1) Testing several changes at once is typically much easier than > testing one-by-one, both in build-time and testing-by-using time. > > 2) Most people can't manipulate Hydra jobsets (including me), which > would be needed for each mass-rebuilding update. I can see how this is an issue indeed. > > 3) Sure I want features stabilized fast, but wishing it isn't > enough. Moreover, how much a mass-rebuild change is potentially > destabilizing can be tricky to estimate. For example, with freetype I > tested building my whole system, including KDE, xfce and several gtk3 > apps, and still I didn't discover dozens of build regressions until > Hydra tried building all. Those took me a few whole days of work to > fix. I don't see how this would become worse by having smaller feature-branches. Something like a freetype-upgrade or fonts-handling branch would quickly show which packages break. Of course that's provided hydra wants to build the branch for you indeed. > > > On 07/23/2014 11:29 AM, Mathijs Kwik wrote: >> - staging hasn't been merged for > 2 weeks > That's good, as there are quite a lot of build regressions ATM. Then they should not have been in staging. Eelco's original email about staging clearly stated staging should be mergeable into master at any time and is only meant to get hydra up to speed so the channel won't lag for days on large rebuilds. If stuff causes regressions, revert it and move it to a feature-branch to debug. > >> - big long-running x-updates branch [...] > This iteration of x-updates runs for about 5 weeks now (since June > 16), which isn't so terribly long. Also, note that it started *before* > the staging branch was even announced (~week after that), so I was now > finishing it in a-kind-of old-style workflow. Ah, that's quite short indeed :) Please remember, I wasn't pointing fingers. I'm fine with x-updates. Having staging around doesn't change anything in this regard. The changes in x-updates deserve their own branch. I was just worried about x-updates becoming a bit more than just core X11 stuff (mesa, freetype, xorg). IMHO stuff like qt / gtk should not get into x-updates but straight to staging (minor upgrades) or a separate branch (larger upgrades). > > Note that there are no added stuff in x-updates like > enlightenment. That got merged in from master and needed a fixup after > x-updates changes. I probably didn't look well enough then. Sorry for the noise. > > >> - upgrades that will probably break stuff >> - add the new version to master >> - users and maintainers can try if their packages work with it >> - change the default in a separate branch (ex: gcc-upgrade) >> - or change the default and pin breaking packages to the previous >> version > > I don't remember agreeing on anything like adding updates as new > versions instead of changing the old one (maybe I misunderstood > you). I rather think it would tend to create a high version bloat > (think ffmpeg and worse), as maintainers will rarely be so responsive > to update the dependency to newer. The discussion was about llvm that time. And I believe it happened before with gcc in stdenv-updates. There really is no reason to not get a new LLVM version in master, just because some X stuff uses it. A minor llvm upgrade should just go into master or staging. If this potentially breaks X stuff, just add the new version and stick X to the previous version. x-updates can then takes its time to work out how to build against the latest version. I do see the danger of having way too many versions around, so indeed we should be careful about this. However, for non-x stuff like LLVM, I don't see the logic in having users wait for some X stuff to stabilize. All in all, the current situation is way better than it used to be and I'm just nitpicking to find out how others think about this branching stuff. Thanks for your input, Mathijs > > > Vlada > > > ___ > 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] Enlightenment 18 - error with cpufreq module
On 24/07/2014 11:10, José Romildo Malaquias wrote: > Hello. > > When starting the enlightenment version 18 desktop manager on my > unstable nixos system, I am getting the following error regarding the > cpufreq module: > > Enlightenment Cpufreq Module: > There was an error trying to set the cpu power state setting via the > module's setfreq utility. > > Cpufreq Permissions Error: > The freqset binatry in the cpufreq module is not owned by root or does > not have the setuid bit set. Please ensure this is the case. For > example: > > sudo chmod u+s,a+x > /nix/store/dbwa7pdwc0wzng07kccmmghsasw7jkqf-enlightenment-0.18.8/lib/enlightenment/modules/cpufreq/linux-gnu-x86_64-ver-00/freqset. > > Is this a bug with the e18 derivation? Yes please report an issue to nixpkgs and cc matejc. It seems freqset should be a setuid program in the e18 configuration. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Enlightenment 18 - error with cpufreq module
Hello. When starting the enlightenment version 18 desktop manager on my unstable nixos system, I am getting the following error regarding the cpufreq module: Enlightenment Cpufreq Module: There was an error trying to set the cpu power state setting via the module's setfreq utility. Cpufreq Permissions Error: The freqset binatry in the cpufreq module is not owned by root or does not have the setuid bit set. Please ensure this is the case. For example: sudo chmod u+s,a+x /nix/store/dbwa7pdwc0wzng07kccmmghsasw7jkqf-enlightenment-0.18.8/lib/enlightenment/modules/cpufreq/linux-gnu-x86_64-ver-00/freqset. Is this a bug with the e18 derivation? Any clues? Romildo ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
