[Nix-dev] Nixbot - a little helper for pull requests

Hi all, Due to a certain dissertation being submitted, I've had a bit of free time over the last day or two. I hacked up a quick prototype of a bot to help with maintainers getting pull requests merged for the packages they maintain. There's previously been talk about related topics. I've some

Re: [Nix-dev] On commit naming conventions

On May 5, 2016 11:26 AM, "Arseniy Seroka" wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > I'm working with PR for more than 1,5 years. I saw maybe once that a person completely lost his interest. I just really didn't have time / intention to support what I

Re: [Nix-dev] Packaging software that mutates itself

I suggest you look into the way Steam is packaged, as it also self- updates (and updates other applications under its control). On Fri, May 6, 2016, at 09:13 AM, Tomasz Czyż wrote: > IMHO, this is pretty simple. > You pack "first/original" version into immutable store /nix/store. You > add

Re: [Nix-dev] Packaging software that mutates itself

IMHO, this is pretty simple. You pack "first/original" version into immutable store /nix/store. You add tiny wrapper around it, which checks if /var/lib/ exists, if not, create directory and copy binary there and run it there. If file already exists in /var/lib, execute it directly. Application

Re: [Nix-dev] Packaging software that mutates itself

On Fri, May 06, 2016 at 01:02:15AM +0300, Nikita Karetnikov wrote: > The server is controlled by other people. I'd like to add that I'm assuming that these people are not malicious. In this case, I'm more worried about a misconfigured package that might break my system in some way.

[Nix-dev] Packaging software that mutates itself

I've talked a bit about this on IRC earlier today, but I think the issue deserves an in-depth discussion. It's more of a general policy question, a clash of an imperative world and a pure functional one. I'm trying to package a Java program, a client, which can be (among other things) updated by

Re: [Nix-dev] racket advance version

On Thu, May 5, 2016, at 08:18 PM, Karn Kallio wrote: > > The attached patch advances the racket version from 6.4 to the latest > release 6.5 Applied, thank you ___ nix-dev mailing list nix-dev@lists.science.uu.nl

[Nix-dev] racket advance version

The attached patch advances the racket version from 6.4 to the latest release 6.5 >From 655053d97f7faddfc2a0dcf9c97679fbf80758f3 Mon Sep 17 00:00:00 2001 From: Karn Kallio Date: Thu, 5 May 2016 14:16:01 -0400 Subject: [PATCH] racket: advance version 6.4 to 6.5 ---

Re: [Nix-dev] [***SPAM***] Re: On commit naming conventions

Thanks for reading in between the lines of what I said by the way. Removing the naming convention is an implementation detail and my main concern is to avoid putting contributors off with details that seem too nit-picky. So the consensus is that: if no new data is provided for 3 months,

Re: [Nix-dev] Feedback requested: new `boot.kernelPatches` option

Just got some random thoughts attached to what you said. makeObject looks like a cleaner implementation of lib.makeOverridable which is used to wrap all callPackage derivations. I haven’t thought deeply about that stuff though. Regarding the naming, I think in nix an “object” is a set that has a

Re: [Nix-dev] mix bundlerEnv and python3.buildEnv

Or if the dependency is a runtime dependency then maybe create another pkgs.buildEnv that merges both environments. On Thu, 5 May 2016 at 00:25 Rok Garbas wrote: > Hi Maxim, > > i think you will have to adjust ``bundlerEnv`` to be able to "merge" > it with

Re: [Nix-dev] [***SPAM***] Re: On commit naming conventions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I agree with it. On 5 May 2016 13:02:46 GMT+03:00, "Tomasz Czyż" wrote: >Huh, so oh the other hand, maybe some "cancellation policy" can be >added. > >"If there is no code change in PR for more than 3 months close it." >

Re: [Nix-dev] [***SPAM***] Re: On commit naming conventions

Huh, so oh the other hand, maybe some "cancellation policy" can be added. "If there is no code change in PR for more than 3 months close it." (myself has two similar PRs, one is waiting for review/acceptance for quite a long time, the other one is waiting for me to implement it - maybe this can

[Nix-dev] [***SPAM***] Re: On commit naming conventions

>I'm working with PR for more than 1,5 years. I saw maybe once that a person >completely lost his interest. It depends on the scope of «lost interest» I have seen many open PRs with minor problems to fix; these were from people who later got commit access and never finished some of their early

Re: [Nix-dev] On commit naming conventions

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm working with PR for more than 1,5 years. I saw maybe once that a person completely lost his interest. On 5 May 2016 12:13:45 GMT+03:00, zimbatm wrote: >This paragraph in the article sums the problem pretty much: > >>

Re: [Nix-dev] On commit naming conventions

This paragraph in the article sums the problem pretty much: > What’s even more frustrating is that even though Jane provides feedback quickly, often contributors lose interest and/or forget about taking their Pull Requests the final step after initially contributing them. The apparent triviality

Re: [Nix-dev] cannot find -lgcc

On 05/04/2016 10:58 PM, David Craven wrote: > Am I missing a wrapCC or something like > that? I checked that the libgcc.a has the correct file format. Could it be that you're attempting to link dynamically? (Though the message really seems more likely to only indicate architecture mismatch.)