Re: [Nix-dev] Commit access

Re: automated LibreOffice UI tests: this promises to be complicated. >>I rank reasonableness of notions used in UI as >> monotone > mercurial > SVN > git >> >> I am currently undecided about fossil, although it is definitely in the >> left half of the chain. >> > >I guess, I'll have to take a

Re: [Nix-dev] Commit access

On 03/01/2016 12:35 AM, Herwig Hochleitner wrote: > For me, whenever I have to use github, I'm like "ugh, why can't i use magit You can fetch the PRs as branches; the refspec is refs/pull/*/head. Then, if you merge them into master by hand, the github PR will auto-close. You can't well see the

Re: [Nix-dev] Commit access

> This is kind of where things are at with hydra channels. Hydra currently *polls* master periodically, whereas with this github *pushes* to hydra/travis/etc, and they git push back to master if the PR passes. This distinction is really important if we want to never break master. The catch is

Re: [Nix-dev] Commit access

2016-03-01 1:06 GMT+01:00 Michael Raskin <7c6f4...@mail.ru>: > > Last time I breaked a thing (and it was recently), it was my commit and > I actually used the resulting binary for some time. Didn't notice the > open dialog was broken. So the question is about price-vs-quality, > testing doesn't

Re: [Nix-dev] Commit access

2016-03-01 0:21 GMT+01:00 ben...@gmail.com : > I would love to see a workflow involving a merge queue, where normally > humans should never push directly to master nor click merge on pull > requests, > This is kind of where things are at with hydra channels. > but instead: >

Re: [Nix-dev] Commit access

>> I do read the patch before; and in many cases I do know what the fallout >> will be. >Sorry, I have to call you on that. Everybody programmer thinks that they >can tell what code does (and they often can), but bugs, you know. Last time I breaked a thing (and it was recently), it was my commit

Re: [Nix-dev] Commit access

2016-03-01 0:17 GMT+01:00 Michael Raskin <7c6f4...@mail.ru>: > > I do read the patch before; and in many cases I do know what the fallout > will be. > Sorry, I have to call you on that. Everybody programmer thinks that they can tell what code does (and they often can), but bugs, you know. Yes,

Re: [Nix-dev] Commit access

I would love to see a workflow involving a merge queue, where normally humans should never push directly to master nor click merge on pull requests, but instead: 1. developer opens pull request 2. travis runs tests, posts results as usual 3. someone with approval/commit rights comments: "nixbot:

Re: [Nix-dev] Commit access

>What does concern me slightly, is the number of merge commits, that I see >in master. Those are usually created by just pressing the merge button. >When actually reviewing stuff, people tend to locally rebase/apply, test to >various stages, and then push. In github, this is visible by "commited

Re: [Nix-dev] Commit access

IMO the mention bot already does a great job at getting notified without having to watch the whole repo. The next thing would be to get a more reliable and fast CI for the PRs. Right now there are too many false negatives which trains us to ignore the red. Waiting for hours for something small to

Re: [Nix-dev] NixON initiative

@Eelco: that looks super cool, once it’s in we should implement all the nix-prefetch-* scripts in function of that. One difference is that nix-prefetch-git also resolves the git revision from a tag or branch name which makes it easy to generate an update script. @gfxmonk: heh not yet but

Re: [Nix-dev] Commit access

Before nix made me dust off my curlies and semicolons again, I have been active in the clojure community. This is relevant to the discussion, because in clojure, we have pretty much the exact opposite contribution policy from nix: Every single contributed patch has to go by Rich Hickey, after

Re: [Nix-dev] NixON initiative

2016-02-28 15:35 GMT+01:00 zimbatm : > No, not the dead president :) JavaScript has JSON and Nix has NixON. A > subset of the language that only contains literal values. > Cool Idea! Here is some code to translate NixON into edn (clojure's json,

Re: [Nix-dev] NixON initiative

On Tue, Mar 1, 2016 at 12:40 AM, Eelco Dolstra wrote: > Hi, > > On 28/02/16 15:35, zimbatm wrote: > >> No, not the dead president :) JavaScript has JSON and Nix has NixON. A >> subset of >> the language that only contains literal values. >> >> Thanks to Tim

Re: [Nix-dev] Commit access

On Mon, Feb 29, 2016 at 11:41 AM, Guillaume Maudoux (Layus) wrote: > But on the other hand, I like the ability to submit a pull-request that > adds a package, a NixOS module and documentation while also bumping the > version of some dependencies. It makes it clear that one

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

+1 > On Feb 29, 2016, at 1:59 PM, Arseniy Seroka wrote: > > IRC is awesome thing, why do we need to replace it? > > -- > Sincerely, > Arseniy Seroka >> On 29 February 2016 22:25:49 Wout Mertens wrote: >> >> Check it out:

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

IRC is awesome thing, why do we need to replace it? -- Sincerely, Arseniy Seroka On 29 February 2016 22:25:49 Wout Mertens wrote: Check it out: http://www.mattermost.org/ Any chance of using that instead of/in addition to IRC? Wout. -- Wout. (typed on mobile,

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

Mattermost does support an IRC bridge, I think. One concern is that IRC and services bridged to it sometimes have different ideas of what valid usernames look like. In particular, I have the following problem with Slack: My slack username is based on a Gmail address containing a period The

[Nix-dev] Open source team messaging: mattermost

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

Re: [Nix-dev] Commit access

Another -1 for multiple repos. We've been fairly good at abstraction and refactoring, and this would serious impair our abilities with regard to both. On Mon, Feb 29, 2016 at 10:02 AM, stewart mackenzie wrote: > Clear support for Layus' points. > > I'll mention another point

Re: [Nix-dev] Commit access

Clear support for Layus' points. I'll mention another point more clearly. Eschew hierarchy & consensus Adopt the Advice Process: Before making a decision seek advice from expertise, then seek advice from those you'll affect. Neither group can veto your decision. Maintainers who do not do this

Re: [Nix-dev] Commit access

>But on the other hand, I like the ability to submit a pull-request that >adds a package, a NixOS module and documentation while also bumping the >version of some dependencies. It makes it clear that one bunch of >changes are related. > >Having different repos brings the difficulty to make

Re: [Nix-dev] Commit access

Le 29/02/16 18:28, Thomas Tuegel a écrit : > On Mon, Feb 29, 2016 at 10:29 AM, Eelco Dolstra > wrote: >> Then when you make a PR, you should look up the responsible maintainer and >> assign the PR to them. Having every PR assigned to somebody should also help >>

Re: [Nix-dev] Commit access

On Mon, Feb 29, 2016 at 10:29 AM, Eelco Dolstra wrote: > Then when you make a PR, you should look up the responsible maintainer and > assign the PR to them. Having every PR assigned to somebody should also help > prevent them from falling through the cracks. If we

Re: [Nix-dev] Commit access

>Then when you make a PR, you should look up the responsible maintainer and >assign the PR to them. Having every PR assigned to somebody should also help >prevent them from falling through the cracks. I would say that making sure every part of NixPkgs and NixOS has a maintainer distinct from

Re: [Nix-dev] Commit access

Hi, On 29/02/16 15:15, Matthias Beyer wrote: >> This is a tree-like model like it is used in other distributions and big >> projects like the kernel or git itself. I originally proposed such a model way back when we switched to Git, but it was not well received :-) Having a fairly high number

Re: [Nix-dev] Commit access

On Mon, Feb 29, 2016 at 8:15 AM, Matthias Beyer wrote: > As this discussion seems to happen outside of the mailinglist, I resend this, > so > everyone on the ML knows: > > On 28-02-2016 15:23:48, Matthias Beyer wrote: >> On 24-02-2016 11:43:22, Michael Raskin wrote: >> > I

[Nix-dev] Problem with the SSL CA cert

We can manually curl for the files, we can manually run cargo, but as soon as you run it through nix it fails. --- snip --- Fetching /tmp/nix-build-development_test-fetch.drv-0/fvm to /nix/store/b73ag3bvlrcchz791r1ijfilbyyigv3d-development_test-fetch Fetching

Re: [Nix-dev] nix out of memory

Brilliant! it was the leftover .target folder! ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Commit access

As this discussion seems to happen outside of the mailinglist, I resend this, so everyone on the ML knows: On 28-02-2016 15:23:48, Matthias Beyer wrote: > On 24-02-2016 11:43:22, Michael Raskin wrote: > > I have fixed and ran the vanity counter script. > > > > My impression is: if any of the

[Nix-dev] Fwd: Re: Displaying package parameters

Forwarded Message Subject: Re: [Nix-dev] Displaying package parameters Date: Mon, 29 Feb 2016 04:25:43 + From: Fabian Schmitthenner To: roger@matrix.ai huh? what's the problem? To be clear, when clicking on a package, some parameters will

[Nix-dev] new tool: nixos-typecheck

Hi! There is the new tool "nixos-typecheck" available in NixOS (currently in master only) that is meant help us to keep the options of our nixos module system well defined. In particular, "nixos-typecheck" can check whether a type attribute is defined for the options of the module system, and

Re: [Nix-dev] NixON initiative

Hi, On 28/02/16 15:35, zimbatm wrote: > No, not the dead president :) JavaScript has JSON and Nix has NixON. A subset > of > the language that only contains literal values. > > Thanks to Tim Cuthbertson (@gfxmonk) nix-prefetch-git now outputs valid NixON. > Would it make sense to convert more

Re: [Nix-dev] nix out of memory

What about hidden directories like .git? You can filter these out. And also, what is du -hsc for the given src directories? On Mon, Feb 29, 2016 at 1:17 PM stewart mackenzie wrote: > I have 50 instances of `src = ./.` each time the ./. points to the > root of a rust project

Re: [Nix-dev] nix out of memory

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

Re: [Nix-dev] nix out of memory

On 02/29/2016 01:40 PM, Oliver Charles wrote: > To expand on that, my understanding is that whenever you refer to a > local path, that entire path is loaded and held in memory. Yes, while dumping it. For more details see e.g.: https://github.com/NixOS/nix/issues/358 smime.p7s Description:

Re: [Nix-dev] nix out of memory

To expand on that, my understanding is that whenever you refer to a local path, that entire path is loaded and held in memory. On Mon, Feb 29, 2016 at 12:12 PM Vladimír Čunát wrote: > On 02/29/2016 12:47 PM, stewart mackenzie wrote: > > What is the reason for dumping a very

Re: [Nix-dev] nix out of memory

On 02/29/2016 12:47 PM, stewart mackenzie wrote: > What is the reason for dumping a very large path (> 256MiB)? You probably have src = ./some/local/path; so if you have some (unneeded) large files under that path... --Vladimir smime.p7s Description: S/MIME Cryptographic Signature

[Nix-dev] nix out of memory

Hello, We are starting to get this more often: [1] denis@denis> nix-build --argstr debug true --argstr subnet development_test --show-trace ~/fractalide/fractalide warning: dumping very large path (> 256 MiB); this may run out of memory error: while evaluating the attribute 'configurePhase' of

Re: [Nix-dev] NixON initiative

Hah, well that has to be one of my shortest-lived changes ever. But as long as I can `fetchgit (importSomehow ./src.json)` I'll be happy, and it seems pretty useful to have nix understand JSON quite well anyway, since it's so pervasive. Thanks for publicising this, zimbatm :) Cheers, - Tim. On

Re: [Nix-dev] Fwd: Re: Displaying package parameters

Wow, very nice! Maybe people reporting that it doesn't work weren't patient enough to wait for it to load the entirety of packages ;) Regarding feature wishlist — this is good enough for package exploration, I'm not sure that for developers using this during expression development anything but a

Re: [Nix-dev] new tool: nixos-typecheck

Sounds good. Regarding the name, isn't that more of a nixos-lint or does it do type inference to find type mismatches ? On Mon, 29 Feb 2016 02:17 Thomas Strobel, <4ZKTUB6TEP74PYJOPWIR013S2AV29YUBW5F9ZH2F4D5UMJUJ6S@hash.domains> wrote: > Hi! > > There is the new tool "nixos-typecheck" available