[Nix-commits] [NixOS/nixpkgs] 4d5452: lib: introduce imap0, imap1 (#25543)

2017-07-04 Thread zimbatm via nix-commits
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 4d545297d85c8f32f7ab496d0759f40d881bd61d
  
https://github.com/NixOS/nixpkgs/commit/4d545297d85c8f32f7ab496d0759f40d881bd61d
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-07-04 (Tue, 04 Jul 2017)

  Changed paths:
M lib/deprecated.nix
M lib/lists.nix
M lib/modules.nix
M lib/strings.nix
M lib/types.nix
M nixos/modules/misc/meta.nix
M nixos/modules/services/cluster/kubernetes.nix
M nixos/modules/services/networking/libreswan.nix
M nixos/modules/services/networking/networkmanager.nix
M nixos/modules/services/x11/xserver.nix
M pkgs/games/uqm/default.nix

  Log Message:
  ---
  lib: introduce imap0, imap1 (#25543)

* lib: introduce imap0, imap1

For historical reasons, imap starts counting at 1 and it's not
consistent with the rest of the lib.

So for now we split imap into imap0 that starts counting at zero and
imap1 that starts counting at 1. And imap is marked as deprecated.

See 
https://github.com/NixOS/nixpkgs/commit/c71e2d42359f9900ea2c290d141c0d606471da16#commitcomment-21873221

* replace uses of lib.imap

* lib: move imap to deprecated.nix


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


Re: [Nix-dev] nix-daemon and private git repos

2017-07-04 Thread zimbatm
Yes, the source is part of the build input and is uploaded to the worker to
run the build.

On Tue, 4 Jul 2017, 17:46 Tomas Hlavaty, 
wrote:

> On Tue 04 Jul 2017 at 13:49, "Alexander V. Nikolaev" 
> wrote:
> > On Mon, Jul 03, 2017 at 03:19:31PM +0200, Harmen wrote:
> >
> > I have `fetchgitCustom` expression, which can use pre-seeded "deploy"
> > keys (but with some security implications -- because key is
> > world-readable). It works with sandbox builds, and should work with
> > hydra as well.
>
> And does it work if the package is build by remote build slaves?
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev


[Nix-commits] [NixOS/nixpkgs] 51c481: terraform: 0.9.10 -> 0.9.11

2017-07-04 Thread zimbatm via nix-commits
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 51c481bdcc30e581dc9f3221530acd8e299b89c8
  
https://github.com/NixOS/nixpkgs/commit/51c481bdcc30e581dc9f3221530acd8e299b89c8
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-07-04 (Tue, 04 Jul 2017)

  Changed paths:
M pkgs/applications/networking/cluster/terraform/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  terraform: 0.9.10 -> 0.9.11


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


[Nix-commits] [NixOS/nixpkgs] 6f86a1: Terraform 0.9.10 (#27003)

2017-07-01 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 6f86a1bd09116a6ad5a07ba040f6d9ddc5caa21e
  
https://github.com/NixOS/nixpkgs/commit/6f86a1bd09116a6ad5a07ba040f6d9ddc5caa21e
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-07-01 (Sat, 01 Jul 2017)

  Changed paths:
M pkgs/applications/networking/cluster/terraform/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Terraform 0.9.10 (#27003)

* terraform: remove old 0.9.x versions

* terraform: 0.9.9 -> 0.9.10


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


[Nix-commits] [NixOS/nixpkgs]

2017-06-30 Thread zimbatm
  Branch: refs/heads/ipfs-0.4.10
  Home:   https://github.com/NixOS/nixpkgs
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-commits


[Nix-commits] [NixOS/nixpkgs] 3dd29b: ipfs: 0.4.9 -> 0.4.10 (#27001)

2017-06-30 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 3dd29b2453d1065ae468c2637a24d415c6cd0695
  
https://github.com/NixOS/nixpkgs/commit/3dd29b2453d1065ae468c2637a24d415c6cd0695
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-07-01 (Sat, 01 Jul 2017)

  Changed paths:
M pkgs/applications/networking/ipfs/default.nix

  Log Message:
  ---
  ipfs: 0.4.9 -> 0.4.10 (#27001)


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


[Nix-commits] [NixOS/nixpkgs] 8558d1: ipfs: 0.4.9 -> 0.4.10

2017-06-30 Thread zimbatm
  Branch: refs/heads/ipfs-0.4.10
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 8558d1865554187b27f22ee74c0a5be9fc9aa569
  
https://github.com/NixOS/nixpkgs/commit/8558d1865554187b27f22ee74c0a5be9fc9aa569
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-07-01 (Sat, 01 Jul 2017)

  Changed paths:
M pkgs/applications/networking/ipfs/default.nix

  Log Message:
  ---
  ipfs: 0.4.9 -> 0.4.10


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


[Nix-commits] [NixOS/nixpkgs] a6e71f: ipfs: 0.4.9 -> 0.4.10

2017-06-30 Thread zimbatm
  Branch: refs/heads/ipfs-0.4.10
  Home:   https://github.com/NixOS/nixpkgs
  Commit: a6e71fc05386f587279a7cfbbf2362b92e6fd7b0
  
https://github.com/NixOS/nixpkgs/commit/a6e71fc05386f587279a7cfbbf2362b92e6fd7b0
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-07-01 (Sat, 01 Jul 2017)

  Changed paths:
M pkgs/applications/networking/ipfs/default.nix

  Log Message:
  ---
  ipfs: 0.4.9 -> 0.4.10


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


Re: [Nix-dev] Announcing Chill Code - built with Nix

2017-06-02 Thread zimbatm
Hi Jasper,

congrats on the launch! I think that it's a neat idea.

For other people trying, the nix code is tucked away under each software
card, more -> Download Nix definition. At this stage it doesn't seem
editable so I'm not sure what the users will do with it.

@Jasper: in
https://chillcode.io/dashboard/layer/0723de88-9d01-4c75-83ba-59c233f17b95/docker_config
the
ExposedPorts look suspicious, I don't think that they are meant to have
/tcp twice in them:

```

ExposedPorts = {
"8300/tcp/tcp" = {};"8301/tcp/tcp" = {};

};

```



On Thu, 1 Jun 2017 at 19:39 Jasper Westaway 
wrote:

> Hi,
>
> I wanted to let you know about our startup Chill Code because we use Nix +
> NiXOS as critical components. Chill Code makes deployment of software
> infrastructure something social - public designs that can be forked and
> then deployed in a few minutes (the Nix part).
>
> As you all use Nix anyway, you might not be part of our core audience, but
> we love Nix, and we’d love the community to provide feedback on the
> product. You can watch videos on our website (www.chillcode.io), or just
> give it a spin. We’ve just entered early access, so there are likely to be
> bugs of things we’ve got wrong. We’ve also written our first blog post on
> our experiences using Nix.  Please feel free to drop me an email directly
> with any comments. We are happy to talk more about the ways in which we use
> Nix, and give a talk in London or NY.
>
> We’d also be grateful if you could give us a shout on Twitter
> (chillcode_io).
>
> Jasper
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] NixCon 2017 Call for Paper

2017-06-02 Thread zimbatm
I noticed this hasn't been sent to the list yet. From
https://schedule.nixcon2017.org/en/nixcon2017/cfp/session/new :

-

The second NixCon will take place in *Munich, Germany, October 28-31 2017*.

We are looking forward to your submissions for workshops (3 or 6 hours) and
talks (15, 30, 45 or 60 min). In particular we would love to see sessions
about the following topics:

- How you are using Nix in your organization
- New tools around the NixOS ecosystem
- CI/CD pipelines with Nix
- Improving the user experience
- How to scale the NixOS project and its organization

Please submit your proposal *until July 31* (1000-1500 characters). If you
have other ideas to make NixCon awesome or are unsure if your session fits,
just write us an email: orgateam (at) nixcon2017.org

More information about NixCon 2017 can be found on the conference website
nixcon2017.org and on Twitter @nixcon2017 
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Auto-generated expressions for applications

2017-05-31 Thread zimbatm
On Wed, 31 May 2017, 17:23 Benno Fünfstück, 
wrote:

> Profpatsch  schrieb am Mi., 31. Mai 2017 um 16:01 Uhr:
>
>> On 17-05-31 08:25am, Benno Fünfstück wrote:
>> > A package set
>> > is a consistent set of packages of a given language.
>>
>> exactly that is not possible with e.g. npm or golang packages.
>>
>
> Yes, those should be dealth with differently. Is sharing of deps between
> different applications in these languages common? (sorry, i'm not very
> familar with either)
>

With npm, a single application might contain multiple versions of the same
library. There is no forcing function that nudges developers to deal with
API compatibilities.

With golang, each project dependency is usually pinned to a single commit
ID. There is no notion of semver that can help build a constraint solver.

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


Re: [Nix-dev] Background images of desktop managers

2017-05-30 Thread zimbatm
Hi Maximilian,

Welcome to the list :)

Did you try setting `services.xserver.desktopManager.default = "none"`? I
suspect that might do what you wanted. The "none" desktop manager doesn't
do anything but should still apply the wallpaper regardless of the
windowManager that you chose.


On Sun, 28 May 2017, 08:53 Maximilian Bosch,  wrote:

> Hey there,
>
> before I start with the actual topic I'd like to introduce myself as this
> is the first time I submit something to the `nix-dev` mailing list: I'm
> Maximilian Bosch from Munich, I work for the Mayflower GmbH and I started
> using NixOS at the beginning of 2017 and submitted several PRs since then.
>
> Right now I'm working on the following thing:
> https://github.com/NixOS/nixpkgs/pull/26156
>
> As the title says, I'd like to have some background image support for
> window managers as well (XMonad in my case). Right now I solve this with
> some ugly shell in the `sessionCommands` script, but I'd like to have a
> more suitable solution for this.
>
> Right now you can set an internal option in the {desktop,window}Managers,
> but `bgSupport` isn't available for the windowManagers (see
> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/window-managers/default.nix,
>
> https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/desktop-managers/default.nix
> ).
>
> I decided to change this, please refer to the linked PR for more details
> there.
>
> Right now it works quite fine with `i3`, but when I tried to test it with
> desktopManagers like `gnome3` or `xfce` (both of them have `bgSupport`
> enabled ATM), I realized that they set their own background internally and
> override the stuff declared by the `feh --bg-scale` call.
>
> Therefore I'd like to know: is there any specific reason I'm missing why
> desktopManagers have this bgSupport thign? It works fine with some
> windowManagers (not all of them, `awesome` overrides the background as
> well), but it seems to break with the desktopManagers.
>
> And if that's just some legacy thing: can the bgSupport be removed from
> the desktopManagers?
>
> Have a great sunday and thanks in advance,
>
> Maximilian Bosch
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev


[Nix-commits] [NixOS/nixpkgs] 4f6ab2: gitlab-runner: 9.1.0 -> 9.2.0

2017-05-24 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 4f6ab299a0d433e041bde292ddd2996489fb3d21
  
https://github.com/NixOS/nixpkgs/commit/4f6ab299a0d433e041bde292ddd2996489fb3d21
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-05-24 (Wed, 24 May 2017)

  Changed paths:
M pkgs/development/tools/continuous-integration/gitlab-runner/default.nix

  Log Message:
  ---
  gitlab-runner: 9.1.0 -> 9.2.0


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


Re: [Nix-dev] why has each revision / generation not a own configuration.nix

2017-05-16 Thread zimbatm
How do you find back which git revision was used to produce a given NixOS
profile?

Maybe nixos-rebuild should be extended to include that in the revision
name, and if the git repo is dirty.

On Sat, 13 May 2017, 14:34 Profpatsch,  wrote:

> On 17-05-13 12:25pm, Layus wrote:
> > On 13/05/17 12:14, Leo Gaspard wrote:
> > See the previous ML discussion on that topic where we proposed to keep it
> > opt-in, but with an apt-out config line in the default configuration.nix.
> > This may already be implemented.
>
> The ones who don’t keep their sources under version control
> deserve their eventual fate.
>
> Seriously, copying & pasting default templates around
> is not a good idea.
> I haven’t seen a “default” configuration.nix (whatever that is)
> in more than 1.5 years.
>
> We already have the firewall enabled by default,
> even that has been a major discussion,
> because for everything that is implicit
> you have to remember to turn it off.
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] nvidia proprietary / i7 notebook - does not start

2017-05-11 Thread zimbatm
Writing from the phone so I don't have all the references at hand.

There are currently two issues with NixOS that might affect you:
* Nvidia Not creating the device driver properly
* GDM tty allocation issue, this leads in GDM repeatedly crashing and
making the console unusable because of the interruptions.

There is a PR pending that fixes both issues but needs testing.

On Wed, 10 May 2017, 13:34 Marc Weber,  wrote:

> This works (ubuntu installation), slightly different x versions
>   http://mawercer.de/tmp/xorg-ubuntu.conf
>   http://mawercer.de/tmp/ubuntu.log
>
> Taking xorg config from Ubuntu but using paths from nixos:
>   http://mawercer.de/tmp/xserver-ubuntu-plain.conf
>   http://mawercer.de/tmp/xserver-ubuntu-plain.conf.log
>
> # Trynig to set BusID keeping most of nixos's config:
>   http://mawercer.de/tmp/xorg-nixos.conf
>   http://mawercer.de/tmp/xorg-nixos.conf.log
>
> Best I got is being able to connect to blank screen by setting DISPLAY and
> running xrandr:
>   Screen 0: minimum 8 x 8, current 8 x 8, maximum 16384 x 16384
>   but HDMI is missing and sizes are missing
>   manually setting a size -s 800x600 -> no windows appear.
>
> Yes, I tried
>   xrandr --setprovideroutputsource modesetting NVIDIA-0
>   xrandr --auto
>
> Yes I tried blacklisting nouveau (doesn't change anything)
>
> xrandr output (runnig nouveau):
>
>   eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis
> y axis) 344mm x 194mm
>  1920x1080 60.01*+
>  1400x1050 59.98
>  1280x1024 60.02
>  1280x960  60.00
>  1024x768  60.0460.00
>  960x720   60.00
>  928x696   60.05
>  896x672   60.01
>  800x600   60.0060.3256.25
>  700x525   59.98
>  640x512   60.02
>  640x480   60.0059.94
>  512x384   60.00
>  400x300   60.3256.34
>  320x240   60.05
>   HDMI-1 connected (normal left inverted right x axis y axis)
>  1600x1200 60.00 +
>  1280x1024 75.0260.02
>  1280x960  60.00
>  1152x864  75.00
>  1024x768  75.0370.0760.00
>  832x624   74.55
>  800x600   72.1975.0060.3256.25
>  640x480   75.0072.8166.6759.94
>  720x400   70.08
>
> Marc Weber
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] github triggered builds

2017-05-09 Thread zimbatm
Travis CI also has support for nix builds and might be easier to setup.

On Mon, 8 May 2017, 18:17 Tomasz Czyż,  wrote:

> https://nixos.org/hydra/
>
> and
>
> https://github.com/hercules-ci/hercules ( looks like still in heavy
> development but maybe usable :))
>
> 2017-05-08 18:14 GMT+01:00 Harmen :
>
>> Hi,
>>
>> I'm trying to see how I can make my build processes easier with nix. So
>> far
>> it's going pretty good and it's fun, although there was a lot of searching
>> online for scattered documents.
>>
>> Want I want to do (as the first thing to change to nix in production) is
>> to
>> port the building of some docker images I use for testing. The idea is to
>> have docker images build, tagged with their branch they come from, when
>> someone
>> pushes something. The building and pushing an sich work. The .nix files
>> live in
>> the repo, and with a `make docker` the image is build and uploaded. I'm
>> very
>> happy to be able to build docker images without actually having to use
>> docker
>> ;)
>>
>> So, what would be the recommended way to trigger the building process? I'm
>> currently using drone.io, but that works with containers. It works with
>> nix,
>> when I give it the nixos/nix docker image, but building a node project
>> takes
>> about 5 minutes, and drags in way too much from cache.nixos.org. I tried
>> to
>> have it make a local nix binary-cache, but there are some problems there,
>> but
>> drone also just doesn't fit the problem nicely.  Nix solves the problem of
>> versioning so much nicer than containers that I would prefer to use
>> something
>> simpler. Hydra could work, but I'm a bit intimidated by that, and would
>> like to
>> have something simpler for now.
>>
>> The LT;DR: question: is there a simple nix based build system which can be
>> triggered via git{hub,lab} hooks?
>>
>>
>> Thanks!
>> Harmen
>> (If there is a better place to ask this, let me know)
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
>
> --
> Tomasz Czyż
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Need any mirror in Asia?

2017-05-08 Thread zimbatm
How I see the setup, it would be a HTTP reverse proxy with caching enabled.
That way only the accessed files are transferred over, avoiding unnecessary
traffic. One downside is that it requires a bit of tuning and monitoring to
make sure it's running efficiently. First accesses to files are also doing
the full round trip.

https://www.nginx.com/blog/nginx-caching-guide/ is a pretty good example
setup for nging, where upstream would be cache.nixos.org . A few things
need to be turned, for example the cache TTL should be much bigger than the
10min that they set. Ideally all content-addressable files would never
invalidate unless the disk is full, in that case they should LRU.

Let me know if you need more details or if this enough to get going.

On Mon, 8 May 2017, 16:53 Karibu, <kar...@freedif.org> wrote:

> Thanks for sharing Daniel, I see another thread around my same topic
> ("still waiting for https://cache.nixos.org after 5 seconds..."). So
> I'm happy to see such open discussion.
>
> It seems they have some projects in the pipe to improve the delivery.
> But I will be happy to support in a short or long term (secondary cache
> layer,...)
>
> I'm currently having a 100M, but I'm thinking of upgrading to 1G. (Just
> a new offer, more expansive of course but for a reasonable price still.
> IMO)
>
> Kari
>
> On Mon, 2017-05-08 at 08:15 -0400, Daniel Peebles wrote:
> > Copying this from another related thread: https://mailman.science.uu.
> > nl/pipermail/nix-dev/2016-October/022029.html
> >
> >
> > On Sun, May 7, 2017 at 9:33 PM, Karibu <kar...@freedif.org> wrote:
> > > Hi Zimbatm,
> > >
> > > This would be the first time for me.
> > >
> > > Can yoy brief me on the details and tools needed?
> > >
> > > Thanks
> > >
> > > On May 7, 2017 22:48, zimbatm <zimb...@zimbatm.com> wrote:
> > > @Karibu: is it possible to setup the mirror as a secondary layer
> > > cache instead?
> > >
> > > On Thu, 4 May 2017 at 14:18 Volth <vo...@volth.com> wrote:
> > > Actually, there are regions with bad connectity to Amazon's
> > > Cloudfront.
> > > For example Russia, and, yes, Vietnam.
> > >
> > > There are few obstacles:
> > > 1. the distribution model is not rsync-friendly and not well suited
> > > for 3rd-party mirrors.
> > > 2. there is a  team promising to solve the geo-distribution issue
> > > using IPFS. There is no results yet but the expectation from their
> > > works lower priority of alternative solutions.
> > > 3. the majority of developers (and users?) are located in Cenral
> > > Europe (NL,DE,CZ,SI,...) so the geodistrubution issue get very
> > > little
> > > traction.
> > >
> > > On 5/4/17, Karibu <kar...@freedif.org> wrote:
> > > > Thanks for the prompt reply.
> > > > So you don't need any mirror in Asia and no issue from the speed
> > > there
> > > > I suppose.
> > > >
> > > > If one day, you will need one, you can count on me.
> > > >
> > > > Thanks
> > > >
> > > > Kari
> > > >
> > > > On Thu, 2017-05-04 at 14:43 +0200, Domen Kožar wrote:
> > > >> This is not Gentoo. Our infrastructure is hosted by Amazon S3
> > > and
> > > >> globally distributed over cloudflare CDN.
> > > >>
> > > >> On Thu, May 4, 2017 at 2:41 PM, Karibu <kar...@freedif.org>
> > > wrote:
> > > >> > Hi guys,
> > > >> >
> > > >> > Any idea about the RSYNC url I should use to do a mirror?
> > > >> >
> > > >> > Thanks
> > > >> >
> > > >> > On Tue, 2017-05-02 at 21:09 +0700, Karibu wrote:
> > > >> > > Hehe no problem.
> > > >> > >
> > > >> > > Any mirror admin or dev to let me know the RSYNC url.
> > > >> > > Thanks
> > > >> > >
> > > >> > > Kari
> > > >> > >
> > > >> > > On Tue, 2017-05-02 at 00:47 +0800, Wei Tang wrote:
> > > >> > > >
> > > >> > > > Hi Karibu,
> > > >> > > >
> > > >> > > > I live in Hong Kong, and I would definitely appreciate a
> > > mirror
> > > >> > in
> > > >> > > > Asia.
> > > >> > > >
> > > >> > > > -- Wei
> > > >> > > >
&g

Re: [Nix-dev] Need any mirror in Asia?

2017-05-07 Thread zimbatm
@Karibu: is it possible to setup the mirror as a secondary layer cache
instead?

On Thu, 4 May 2017 at 14:18 Volth  wrote:

> Actually, there are regions with bad connectity to Amazon's Cloudfront.
> For example Russia, and, yes, Vietnam.
>
> There are few obstacles:
> 1. the distribution model is not rsync-friendly and not well suited
> for 3rd-party mirrors.
> 2. there is a  team promising to solve the geo-distribution issue
> using IPFS. There is no results yet but the expectation from their
> works lower priority of alternative solutions.
> 3. the majority of developers (and users?) are located in Cenral
> Europe (NL,DE,CZ,SI,...) so the geodistrubution issue get very little
> traction.
>
> On 5/4/17, Karibu  wrote:
> > Thanks for the prompt reply.
> > So you don't need any mirror in Asia and no issue from the speed there
> > I suppose.
> >
> > If one day, you will need one, you can count on me.
> >
> > Thanks
> >
> > Kari
> >
> > On Thu, 2017-05-04 at 14:43 +0200, Domen Kožar wrote:
> >> This is not Gentoo. Our infrastructure is hosted by Amazon S3 and
> >> globally distributed over cloudflare CDN.
> >>
> >> On Thu, May 4, 2017 at 2:41 PM, Karibu  wrote:
> >> > Hi guys,
> >> >
> >> > Any idea about the RSYNC url I should use to do a mirror?
> >> >
> >> > Thanks
> >> >
> >> > On Tue, 2017-05-02 at 21:09 +0700, Karibu wrote:
> >> > > Hehe no problem.
> >> > >
> >> > > Any mirror admin or dev to let me know the RSYNC url.
> >> > > Thanks
> >> > >
> >> > > Kari
> >> > >
> >> > > On Tue, 2017-05-02 at 00:47 +0800, Wei Tang wrote:
> >> > > >
> >> > > > Hi Karibu,
> >> > > >
> >> > > > I live in Hong Kong, and I would definitely appreciate a mirror
> >> > in
> >> > > > Asia.
> >> > > >
> >> > > > -- Wei
> >> > > >
> >> > > > Karibu writes:
> >> > > >
> >> > > > >
> >> > > > >
> >> > > > > Hi guys,
> >> > > > > I am the admin of the Vietnamese mirror (and blog)
> >> > freedif.org
> >> > > > > (mirror.freedif.org)
> >> > > > >
> >> > > > > I have some spare bandwidth and space and would like to
> >> > support
> >> > > > > your
> >> > > > > project.
> >> > > > >
> >> > > > > Do you need a mirror in Vietnam (no problem to support
> >> > > > > neighbourhood
> >> > > > > countries)
> >> > > > >
> >> > > > > Thanks
> >> > > > >
> >> > > > > Kari
> >> > > > > ___
> >> > > > > nix-dev mailing list
> >> > > > > nix-dev@lists.science.uu.nl
> >> > > > > https://mailman.science.uu.nl/mailman/listinfo/nix-dev
> >> > > ___
> >> > > nix-dev mailing list
> >> > > nix-dev@lists.science.uu.nl
> >> > > https://mailman.science.uu.nl/mailman/listinfo/nix-dev
> >> > ___
> >> > nix-dev mailing list
> >> > nix-dev@lists.science.uu.nl
> >> > https://mailman.science.uu.nl/mailman/listinfo/nix-dev
> >> >
> >>
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > https://mailman.science.uu.nl/mailman/listinfo/nix-dev
> >
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] NixOS and nix 1.12

2017-04-25 Thread zimbatm
At some point but there is no timeline yet. We don't even have a list of
regressions to fix before release yet.

On Thu, 13 Apr 2017, 15:12 Volth,  wrote:

> Hi
>
> Is nix-1.12 going to replace traditional nix command line utilities on
> NixOS ?
> If yes, when it is going to happen, approximately?
> With NixOS-17.09, 18.03 or later?
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Announcing Hail — A service for pull-based continuous deployment from Hydra

2017-04-12 Thread zimbatm
Hi Shea,

It's cool that you're reusing the activation script interface for non-nixos
targets.

What are the advantages for having hail run the cron task instead of using
the system cron? Is it to make it more cross-OS compatible?

Cheers,
z

On Tue, 11 Apr 2017, 19:16 Shea Levy,  wrote:

> Hi all,
>
> Takt has open-sourced a tool we're using to deploy our services from
> hydra. Check out the blog post at
> https://code.takt.com/announcing-hail-4da7208df56d !
>
> Thanks,
> Shea
> ___
> 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] [Help] Accidentally removed configuration.nix

2017-04-10 Thread zimbatm
This issue is likely to trip most newcomers. Maybe nixos-install should
create a git repo in /etc/nixos by default. And then "nixos build"
automatically commit on invocation.

On Mon, 10 Apr 2017, 04:41 Ryan Trinkle,  wrote:

> Jeaye,
>
> I totally agree!  One really interesting approach to this that I've seen
> is the 'pass' password manager, which can automatically handle the use of
> git for passwords.  I wonder if it would be feasible to do this for nixos
> as well, so that beginners (who might not be familiar with git) would
> automatically be doing "the right" (or at least "a reasonable") thing
> without needing to learn about it.
>
>
> Ryan
>
> On Sun, Apr 9, 2017 at 11:10 PM, Jeaye  wrote:
>
> On Thu, Apr 06, 2017 at 04:12:03PM +0200, ni...@vince.lol wrote:
> > Hi all,
> >
> > I acidentally removed my /etc/nixos/configuration.nix is there any way I
> can
> > get it back?
> >
> > Sincerely,
> > Vince
>
> I know you've sorted this out now, but I think it's worthwhile to mention
> that one of the benefits of having a text-based, declarative configuration
> for your OS is that you can very easily track it in git. NixOS will handle
> reverts for you, on an OS level, and git can handle them for you on a
> configuration level.
>
> If you don't want to host the configurations publicly, on Github or
> similar, you could do so privately, on Bitbucket or similar.
>
> Best of luck.
>
> ___
> 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] Banning people from the mailinglist?

2017-04-04 Thread zimbatm
I'm proud of how mature the nix community is, it takes some effort to not
respond to hate with more hate. Share the love :D

On Tue, 4 Apr 2017, 17:05 Alexey Shmalko,  wrote:

> I recommend reading You Are What You Write[1] and Difficult People[2]
> chapters of Producing Open Source Software[3] by Karl Fogel. They
> describe how to handle similar situations; banning people is extreme
> measures, and most situations can be resolved without that.
>
> [1]: http://producingoss.com/en/you-are-what-you-write.html
> [2]: http://producingoss.com/en/difficult-people.html
> [3]: http://producingoss.com/
> ___
> 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] Overriding python with python3 in vim_configurable.customize

2017-04-04 Thread zimbatm
Look into pkgs/top-level/all-packages.nix. I would start by copying the
definition of vim_configurable from there and set the python argument.

On Tue, 4 Apr 2017, 14:08 Ben Zhang, <benzhang...@gmail.com> wrote:

> From the source code, it doesn’t seem to accept a python argument (
> https://github.com/nicknovitski/nixpkgs/blob/master/pkgs/misc/vim-plugins/vim-utils.nix#L291-L295).
> Is there another way to override `python` with `python3` (
> https://github.com/NixOS/nixpkgs/pull/8125#issuecomment-169471686)?
>
> Thanks,
>
> Ben
>
> On Apr 4, 2017, 4:02 AM -0400, zimbatm <zimb...@zimbatm.com>, wrote:
>
> The "with" keyword binds the designated attrset pairs into scope. It
> doesn't override other called function variables though.
>
> Do you know if the customise function accepts a python argument as an
> input?
>
> On Tue, 4 Apr 2017, 06:04 Ben Zhang, <benzhang...@gmail.com> wrote:
>
> Hello everyone,
>
> I am following [this](
> https://github.com/kamilchm/.nixpkgs/blob/master/vim-config/default.nix)
> template for configuring my custom vim with Nix. My
> `vim-config/default.nix` is as follows:
>
> { pkgs }:
>
> let
>   my_plugins = import ./plugins.nix { inherit (pkgs) vimUtils
> fetchFromGitHub; };
> in with (pkgs // { python = pkgs.python3; });
> vim_configurable.customize {
>   name = "vim";
>   vimrcConfig = {
> customRC = ''
>   syntax on
>   filetype on
>   " ...
> '';
>
> vam.knownPlugins = vimPlugins // my_plugins;
> vam.pluginDictionaries = [
>   { names = [
> "ctrlp"
> # ...
>   ]; }
> ];
>   };
> }
>
> Although there is a `(pkgs // { python = pkgs.python3; })` override on
> line 5, python3 is still not used (when I run `vim --version` it shows
> `+python -python3`). Am I missing anything?
>
> Thanks,
>
> Ben
>
> ___
> 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-commits] [NixOS/nixpkgs] bc45ee: ruby: 2.4.0 -> 2.4.1

2017-04-04 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: bc45ee50c4f043bea57422e94a92e79fd07eb379
  
https://github.com/NixOS/nixpkgs/commit/bc45ee50c4f043bea57422e94a92e79fd07eb379
  Author: Tim Steinbach <t...@nequissimus.com>
  Date:   2017-04-03 (Mon, 03 Apr 2017)

  Changed paths:
M pkgs/development/interpreters/ruby/default.nix
M pkgs/development/interpreters/ruby/patchsets.nix
M pkgs/development/interpreters/ruby/rvm-patchsets.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  ruby: 2.4.0 -> 2.4.1


  Commit: 482566939edc8130b60fe32a66f47556ffc7bec8
  
https://github.com/NixOS/nixpkgs/commit/482566939edc8130b60fe32a66f47556ffc7bec8
  Author: Tim Steinbach <t...@nequissimus.com>
  Date:   2017-04-03 (Mon, 03 Apr 2017)

  Changed paths:
M pkgs/development/interpreters/ruby/default.nix
M pkgs/development/interpreters/ruby/patchsets.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  ruby: 2.3.3 -> 2.3.4


  Commit: ec2c46923078ceda67f944ae09bcb4d435d45ce5
  
https://github.com/NixOS/nixpkgs/commit/ec2c46923078ceda67f944ae09bcb4d435d45ce5
  Author: Tim Steinbach <t...@nequissimus.com>
  Date:   2017-04-03 (Mon, 03 Apr 2017)

  Changed paths:
M pkgs/development/interpreters/ruby/default.nix
M pkgs/development/interpreters/ruby/patchsets.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  ruby: 2.2.5 -> 2.2.7


  Commit: 3535a6bf3c25bf2893c070a8a0cb60445e02ea0e
  
https://github.com/NixOS/nixpkgs/commit/3535a6bf3c25bf2893c070a8a0cb60445e02ea0e
  Author: Tim Steinbach <t...@nequissimus.com>
  Date:   2017-04-03 (Mon, 03 Apr 2017)

  Changed paths:
M pkgs/development/interpreters/ruby/default.nix

  Log Message:
  ---
  ruby: 2.0.0-p647 -> 2.0.0-p648


  Commit: 7fe25124bc3bb18c690154a491171d8b527d9440
  
https://github.com/NixOS/nixpkgs/commit/7fe25124bc3bb18c690154a491171d8b527d9440
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-04-04 (Tue, 04 Apr 2017)

  Changed paths:
M pkgs/development/interpreters/ruby/default.nix
M pkgs/development/interpreters/ruby/patchsets.nix
M pkgs/development/interpreters/ruby/rvm-patchsets.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Merge pull request #24604 from NeQuissimus/ruby_updates

Ruby updates


Compare: https://github.com/NixOS/nixpkgs/compare/f0ba178a3c13...7fe25124bc3b___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


Re: [Nix-dev] Overriding python with python3 in vim_configurable.customize

2017-04-04 Thread zimbatm
The "with" keyword binds the designated attrset pairs into scope. It
doesn't override other called function variables though.

Do you know if the customise function accepts a python argument as an input?

On Tue, 4 Apr 2017, 06:04 Ben Zhang,  wrote:

> Hello everyone,
>
> I am following [this](
> https://github.com/kamilchm/.nixpkgs/blob/master/vim-config/default.nix)
> template for configuring my custom vim with Nix. My
> `vim-config/default.nix` is as follows:
>
> { pkgs }:
>
> let
>   my_plugins = import ./plugins.nix { inherit (pkgs) vimUtils
> fetchFromGitHub; };
> in with (pkgs // { python = pkgs.python3; });
> vim_configurable.customize {
>   name = "vim";
>   vimrcConfig = {
> customRC = ''
>   syntax on
>   filetype on
>   " ...
> '';
>
> vam.knownPlugins = vimPlugins // my_plugins;
> vam.pluginDictionaries = [
>   { names = [
> "ctrlp"
> # ...
>   ]; }
> ];
>   };
> }
>
> Although there is a `(pkgs // { python = pkgs.python3; })` override on
> line 5, python3 is still not used (when I run `vim --version` it shows
> `+python -python3`). Am I missing anything?
>
> Thanks,
>
> Ben
>
> ___
> 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-commits] [NixOS/nixpkgs] 1bf690: iosevka: 1.11.4 -> 1.12.1 (#24527)

2017-04-03 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 1bf690c1bb7bfc167d6ad78102a625320691e1ac
  
https://github.com/NixOS/nixpkgs/commit/1bf690c1bb7bfc167d6ad78102a625320691e1ac
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-04-03 (Mon, 03 Apr 2017)

  Changed paths:
M pkgs/data/fonts/iosevka/default.nix

  Log Message:
  ---
  iosevka: 1.11.4 -> 1.12.1 (#24527)

iosevka: 1.11.4 -> 1.12.1


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


[Nix-dev] [RFC 004] Add Replace Unicode Quotes draft

2017-03-28 Thread zimbatm
Hi everyone,

RFC 004 is now ready for wider reviews if you care to take a look:

https://github.com/NixOS/rfcs/pull/4

Cheers,
z

PS: notice the NixOS/ prefix to the repo :)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-commits] [NixOS/nixpkgs] f77de6: arcanist: 20160825 -> 20170323

2017-03-25 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f77de6d3dccd21b3a79bc96b4e809ea8c651baa4
  
https://github.com/NixOS/nixpkgs/commit/f77de6d3dccd21b3a79bc96b4e809ea8c651baa4
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-03-25 (Sat, 25 Mar 2017)

  Changed paths:
M pkgs/development/tools/misc/arcanist/default.nix

  Log Message:
  ---
  arcanist: 20160825 -> 20170323


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


Re: [Nix-dev] Should we drop 9P?

2017-03-21 Thread zimbatm
What matters are that the tests are valid, reproducible   and not too slow.
If you want to replace the filesystem and it improves any of these
qualities I don't see any problems :)

On Mon, 20 Mar 2017, 23:37 Ertugrul Söylemez,  wrote:

> > 9P is used by NixOS to share host's nix store with Qemu virtual
> > machines. Such technique is used in the build process, in the
> > test-driver, so to say in the critical places.
> > Recently few bugs in 9P were found (#23957 #23020 #22695) which
> > reveals that 9P code is not very mature and perhaps NixOS is the first
> > team which uses 9P heavily and relies on it in production.
> >
> > Shouldn't we replace 9P with something battle-tested like NFS or
> > Samba?  It may also improve the performance because 9P server works in
> > qemu process, in user mode and there are as many servers as virtual
> > machines running.
>
> In terms of performance getting rid of QEMU where possible is probably
> the better option.  Containers are fairly mature these days, and then
> sharing file-systems is a matter of bind-mounting.
> ___
> 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-commits] [NixOS/nixpkgs] b052a3: lib/trivial: expand function docs

2017-03-20 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b052a3629463f2f064a0a3da50dbebd73b587651
  
https://github.com/NixOS/nixpkgs/commit/b052a3629463f2f064a0a3da50dbebd73b587651
  Author: Profpatsch <m...@profpatsch.de>
  Date:   2017-03-15 (Wed, 15 Mar 2017)

  Changed paths:
M lib/trivial.nix

  Log Message:
  ---
  lib/trivial: expand function docs


  Commit: cb9ff8bfa73fdfa1a38b609e878a52650dfdb682
  
https://github.com/NixOS/nixpkgs/commit/cb9ff8bfa73fdfa1a38b609e878a52650dfdb682
  Author: Profpatsch <m...@profpatsch.de>
  Date:   2017-03-19 (Sun, 19 Mar 2017)

  Changed paths:
M lib/lists.nix

  Log Message:
  ---
  lib/lists: rename fold to foldr & improve fold docs

In order to better distinguish foldr from foldl the default name is changed to
foldr, but fold is still a synonym.

Additionally the docs are improved and examples added.


  Commit: 4f1d977877b5477d84ca1204ec7a3f87d6bbf871
  
https://github.com/NixOS/nixpkgs/commit/4f1d977877b5477d84ca1204ec7a3f87d6bbf871
  Author: Profpatsch <m...@profpatsch.de>
  Date:   2017-03-19 (Sun, 19 Mar 2017)

  Changed paths:
M lib/tests.nix

  Log Message:
  ---
  lib/tests: add more tests for fold functions

Also the invocation of tests is documented.


  Commit: 3bbab1757510de86d8062684f8c92d231265b934
  
https://github.com/NixOS/nixpkgs/commit/3bbab1757510de86d8062684f8c92d231265b934
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-03-20 (Mon, 20 Mar 2017)

  Changed paths:
M lib/lists.nix
M lib/tests.nix
M lib/trivial.nix

  Log Message:
  ---
  Merge pull request #23929 from Profpatsch/lib-lists-doc

Improve lib/trivial and lib/lists docs


Compare: https://github.com/NixOS/nixpkgs/compare/ed59de18b5e9...3bbab1757510___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


Re: [Nix-dev] How do you work on big packages?

2017-03-18 Thread zimbatm
Another option is to add a powerful remote builder on the local network. It
doesn't beat incremental rebuilds but helps with having the laptop taking
off and trying to burn my legs. Old desktop machines from ebay are not too
expensive and still beat the laptop capacity.

On Sat, 18 Mar 2017 at 02:19 Tuomas Tynkkynen 
wrote:

> A while ago I wrote a wrapper around nix-shell that helps with running
> the build steps in correct manner and order (among with other niceties
> like automatically creating a temporary build directory and making
> $out point to a path in /tmp/):
> https://github.com/dezgeg/nix-debug-shell
>
> I mainly wrote it for debugging build steps for existing packages, but
> I guess the same ideas/code could be used for local development as
> well.
>
> It is rigorously undocumented, so here's a short primer: in a nixpkgs
> tree, run /path/to/nix-debug-shell -A hello. That places you under
> /tmp/nds-build-hello/hello-2.10 with the sources unpacked. Run
> 'nd-step' as many times you want to step through the build phases
> (it's named after the 'step' command in GDB). When installPhase is
> done, it installs to /tmp/, e.g. /tmp/nds-install-hello/bin/hello.
>
> Hope anyone finds this useful.
>
> 2017-03-17 21:26 GMT+02:00 Profpatsch :
> > On 17-03-17 06:04pm, Volth wrote:
> >> "nix-shell" would be a super option here if it could handle
> >> "installPhase" (this seems easy to fix) and .nix files less trivial
> >> than "hello.nix" (this seems not easy to fix; for example "nix-shell
> >> '' -A linux_4_4" has no "configurePhase", and there are
> >> similar problems with almost every of the big projects; nix-shell
> >> launches "make" when "nix-build" launches "cmake" or vice-versa, etc)
> >
> > That’s a pretty common stumbling block.
> >
> > If someone defines his own `installPhase` for example,
> > the `installPhase` shell function is just the standard
> > stdenv `installPhase`. What you want to call is rather
> > the contents of `$installPhase` (the variable), since
> > that contains the phase you defined in `mkDerivation`.
> >
> > nix-shell
> > $ unpackPhase
> > unpacking …
> > $ configurePhase
> > configuring …
> > $ buildPhase
> > …
> > $ $installPhase
> > running your installPhase
> >
> >
> > There is not much abstraction. Every nix attribute within
> > `derivation` (and by extension `mkDerivation`) will end up
> > as a bash shell variable in your shell (and your build env).
> >
> > --
> > Proudly written in Mutt with Vim on NixOS.
> > Q: Why is this email five sentences or less?
> > A: http://five.sentenc.es
> > May take up to five days to read your message. If it’s urgent, call me.
> > ___
> > 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] RFC for RFCs

2017-03-18 Thread zimbatm
RFC 0001 has been merged! The repo still needs to be moved to the NixOS org
but we're getting there :)

To keep the ball rolling, let me know if you want to try drafting a RFC.
The whole process is probably still a bit rough and we need to get a couple
of RFCs trough the process to make it better.

Cheers,
z

On Thu, 9 Mar 2017 at 17:44 Rok Garbas <r...@garbas.si> wrote:

> I haven't read the latest changes in the RFC, but I welcome any more
> formal process for major changes.
>
> Thank you @zimbatm for pursuing this.
>
>
> > On 09 March 2017 at 13:09 Tomasz Czyż <tomasz.c...@gmail.com> wrote:
> >
> >
> > Thanks! Great stuff!
> >
> > 2017-03-08 21:21 GMT+00:00 zimbatm <zimb...@zimbatm.com>:
> >
> > > The RFC for RFCs is ready for a final round of review. Unless there are
> > > major objections I would like to move forward with it, with the idea
> that
> > > we can always improve the process with further RFCs.
> > >
> > > https://github.com/zimbatm/rfcs/pull/1
> > >
> > > On Sun, 12 Feb 2017 at 20:17 Maarten Hoogendoorn <maar...@moretea.nl>
> > > wrote:
> > >
> > >> Also see the notes that Arian took during the BoF session at FOSDEM:
> > >>
> > >> We had a very spontaneous NixOS discussion panel at FOSDEM.
> > >>
> > >> I took minutes.  I must say they're a bit rushy at times, so add
> stuff to
> > >> it
> > >> you think isn't clear or is lacking in content.  Thanks!
> > >>
> > >>
> > >> http://piratepad.net/1nHg65LMQj
> > >>
> > >>
> > >> 2017-02-12 19:46 GMT+01:00 Thomas Hunger <tehun...@gmail.com>:
> > >>
> > >> That would be amazing! I actually have an email sitting in my draft
> > >> folder proposing Nix Enhancement Proposals (NEPs).
> > >>
> > >> IMHO one of the things we aren't very good at is getting larger
> changes
> > >> merged or rejected. We attract a lot of smart people because Nix is
> pretty
> > >> awesome. These smart people then do substantial work, submit a PR and
> the
> > >> PR bitrots. This is highly demotivating.
> > >>
> > >> An RFC process would allow us to get to an accept / reject early on,
> with
> > >> the expectation that accepted RFCs will be merged when the technical
> work
> > >> is done.
> > >>
> > >> I'll add more specific comments to your PR.
> > >>
> > >> ~
> > >>
> > >> On 12 February 2017 at 15:12, zimbatm <zimb...@zimbatm.com> wrote:
> > >>
> > >> Hi all,
> > >>
> > >> we discussed of introducing a RFC process during FOSDEM. The goal is
> to
> > >> help discussion for large or controversial changes which typically
> grind to
> > >> a halt.
> > >>
> > >> Here is an initial proposal based on the one from the Rust community:
> > >> https://github.com/zimbatm/rfcs/pull/1 . Please let me know what you
> > >> think.
> > >>
> > >> Cheers,
> > >> z
> > >>
> > >> ___
> > >> 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
> > >
> > >
> >
> >
> > --
> > Tomasz Czyż
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
> -- Rok Garbas, https://garbas.si
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Google Summer of Code 2017

2017-03-16 Thread zimbatm
Added to calendar for next year :)

On Wed, 15 Mar 2017, 22:03 Vladimír Čunát,  wrote:

> On 03/15/2017 04:33 PM, Oliver Charles wrote:
> > On Wed, Mar 15, 2017 at 12:47 PM Domen Kožar  > > wrote:
> > That being said, I know people will be disappointed by this. I'm
> sorry,
> > I have no excuses really. I was overworked at that time and totally
> > forgot to watch the dates.
> >
> > I already applied us two times, I hope I'll gather the energy to try
> > again next year.
> > But since I screwed up this year, someone else can take over if
> wanted,
> > I understand not to be trusted :)
> >
> > As Thomas said, no hard feelings - this is not your fault! There's
> > always next year :)
>
> I certainly second that; there's no use in assigning the blame.  I
> personally knew the deadline must be soon, but - honestly - I've been
> long-term over-busy with things that felt more important to me, even
> around nix(os).
>
> --Vladimir
>
>
> ___
> 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-commits] [NixOS/nixpkgs] b63aab: slack: 2.5.1 -> 2.5.2

2017-03-14 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b63aab243349792b3ae7ff31d93594cf355cc583
  
https://github.com/NixOS/nixpkgs/commit/b63aab243349792b3ae7ff31d93594cf355cc583
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-03-14 (Tue, 14 Mar 2017)

  Changed paths:
M pkgs/applications/networking/instant-messengers/slack/default.nix

  Log Message:
  ---
  slack: 2.5.1 -> 2.5.2


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


Re: [Nix-dev] Move NodeJS to separate overlay repository?

2017-03-11 Thread zimbatm
I've been thinking of the subject in general for a while. It's a bit long
so please bear with me.

First here are various personas with different and potentially conflicting
interests:

1. As a nixpkgs user, when I want to install a package, I don't really care
in what language it's implemented in. I shouldn't have to know that my
package is in nodePackages or pythonPackage, ... or search for the right
overlay. I also don't care about libraries unless they allow me to install
a package because it's a required dependency. And finally, I don't want
nixpkgs to be much larger and slow down my `nix-channel --update` because
it's downloading all the haskell, ruby, python, ... library descriptions.

2. As a nixpkgs maintainer, I don't want to maintain a library set where
all the versions work together. Something like stackage for haskell is a
tremendous amount of effort. And they have a strong type system which
certainly helps. Finding the right combination of library versions is a
combinatorial problem. The search space is N factorial and without proper
tooling it's very time intensive. Especially with Go dependencies where N
is the number of libraries times the number of commits.

3. As a developer, I have my own $lang dependency set. Most languages have
tooling that can find the right combination of dependencies using version
constraints already. In cases where at dependency takes a long time to
compile, I want to be able to benefit from a binary cache. If nix can
provide me with the equivalent of stackage for my language I would also be
happy provided I can override some of the versions and the versions aren't
too old in general.

So as you can see, to satisfy (1) and (2) it would make sense to remove the
$langPackages from nixpkgs. But (3) wants a binary cache and (4) wants the
security updates.

As another data point, I created https://github.com/zimbatm/nix-rubygems which
is a sort of nixpkgs overlay for all the ruby gems, created before the
overlay feature. It contains the sha256 of all the rubygems until I last
updated it (24 Nov 2016). When checking out the repo, `du -sh. ` gives me
3.5GB for 720312 gems, that's ~5KB per gem probably due to all the inodes
and the .git repo. I think it's possible to bring it down to ~50MB using
binary packing but I would guess 99% of these gems are not really useful
and would be a waste of compute and storage resource.

So far I think the best solution to improve the life of $lang developer is
to:
a. Work with the $lang package manager so that they compute, distribute and
embed the sha256 into their lockfiles like yarn does. There should be a
$lang native tool that produces the locked-down dependency set which nix
can read as well. It means the developer doesn't *have* to have nix
installed, unless he wants the binary cache goodies.
b. Make it easy to setup their own binary cache, integrated with their CI,
and developer re-use it. I think that's an important step for any
organisation who wants to adopt Nix.
c. It's not really clear how yet but I believe nix could become useful for
$lang to get automated reports on build failures and non-reproducible
builds. If we can become that foundation we'll see much better adoption in
general.

I'm not saying that overlays are not useful, potentially we can also have
overlays built by hydra just for the binary cache and (c). It's just some
thoughts. Well done for reading until here :)

On Sat, 11 Mar 2017 at 17:29 David Izquierdo <theco...@gmail.com> wrote:

> Couldn't this become a kind of dependency hell? I remember from Gentoo
> that having dependencies across overlays is not a fun problem to solve.
> However, Exherbo mostly solved this by having overlays be analogous to
> packages, they become a kind of dependency that must be explicitly
> user-solved before continuing. In the default ebuild tree they have
> indexes of every package in each registered overlay.
>
>
> I think this should only be done if there's nothing anywhere else
> depending on a derivation from this overlay-to-be.
>
>
> On 11/03/17 09:12, Wout Mertens wrote:
> > Hi all,
> >
> > now that we got these wonderful overlays as a Chrismas gift (
> > http://lists.science.uu.nl/pipermail/nix-dev/2016-December/022386.html),
> I
> > was wondering if we can move some things out of nixpkgs into their own
> > repos.
> >
> > There are a few package groups that I believe are not used in NixOS core
> > (boot, containers, ...) and are not updated as much as they could be.
> Node,
> > Haskell, others?
> >
> > Specifically, nodePackages is always out of date, and it would be nice if
> > there could be a repository or maybe just a local process that updates
> them
> > separately and adds a lot more builds.
> >
> > Furthermore, building node packages from scratch is ok, because that's
> what
> > npm does anyway. So any ca

[Nix-commits] [NixOS/nixpkgs] 187372: luaPackages.mpack: enable darwin platform

2017-03-10 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 1873721fcdcdd3a45294e873cef053878c10c20d
  
https://github.com/NixOS/nixpkgs/commit/1873721fcdcdd3a45294e873cef053878c10c20d
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-03-10 (Fri, 10 Mar 2017)

  Changed paths:
M pkgs/top-level/lua-packages.nix

  Log Message:
  ---
  luaPackages.mpack: enable darwin platform

It was working fine but then regressed by
77f5a50c400d7e312e7491593dcc8ee8cab86c2c


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


Re: [Nix-dev] RFC for RFCs

2017-03-08 Thread zimbatm
The RFC for RFCs is ready for a final round of review. Unless there are
major objections I would like to move forward with it, with the idea that
we can always improve the process with further RFCs.

https://github.com/zimbatm/rfcs/pull/1

On Sun, 12 Feb 2017 at 20:17 Maarten Hoogendoorn <maar...@moretea.nl> wrote:

> Also see the notes that Arian took during the BoF session at FOSDEM:
>
> We had a very spontaneous NixOS discussion panel at FOSDEM.
>
> I took minutes.  I must say they're a bit rushy at times, so add stuff to
> it
> you think isn't clear or is lacking in content.  Thanks!
>
>
> http://piratepad.net/1nHg65LMQj
>
>
> 2017-02-12 19:46 GMT+01:00 Thomas Hunger <tehun...@gmail.com>:
>
> That would be amazing! I actually have an email sitting in my draft folder
> proposing Nix Enhancement Proposals (NEPs).
>
> IMHO one of the things we aren't very good at is getting larger changes
> merged or rejected. We attract a lot of smart people because Nix is pretty
> awesome. These smart people then do substantial work, submit a PR and the
> PR bitrots. This is highly demotivating.
>
> An RFC process would allow us to get to an accept / reject early on, with
> the expectation that accepted RFCs will be merged when the technical work
> is done.
>
> I'll add more specific comments to your PR.
>
> ~
>
> On 12 February 2017 at 15:12, zimbatm <zimb...@zimbatm.com> wrote:
>
> Hi all,
>
> we discussed of introducing a RFC process during FOSDEM. The goal is to
> help discussion for large or controversial changes which typically grind to
> a halt.
>
> Here is an initial proposal based on the one from the Rust community:
> https://github.com/zimbatm/rfcs/pull/1 . Please let me know what you
> think.
>
> Cheers,
> z
>
> ___
> 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] Contributions

2017-03-08 Thread zimbatm
Hi Judson,

I believe it's also true for the NixOS foundation. There is a legal entity
with money in the bank but it's not clear how to get it out. It would be
nice to have clear rules and reporting so that donors know how their money
is spent. As a community member it would also be nice to know if I can get
support for sponsoring events or other community outreach programs.

Luckily Logicblox is providing the computing and bandwidth resources to run
hydra, all the remote builders and the binary cache so we don't have to
worry about that.

On Tue, 7 Mar 2017, 16:50 Judson Lester,  wrote:

> I was at SCaLE over the weekend, and thinking about Graham's recent
> attempt at a scaled out Hydra cluster. One of the tracks was for Open
> Infrastructure, and there was a lot of discussion about how to donate and
> how to solicit donations to open source projects. I've seen the NixOS
> Foundation page, and the sponsor logos at nixos.org, but was wondering
> what the status of outreach to potentially interested corporate partners
> was like. I know most non-profits feel like they never have enough time to
> do that kind of work - is that the case with the NixOS Foundation? Would
> reliable donations of compute resources help, or is that an avenue already
> pursued?
>
> Judson
> ___
> 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-commits] [NixOS/nixpkgs] e50203: yarn: 0.21.3 -> 0.22.0

2017-03-07 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: e50203bfde29065fd7d1f047d9e3797f5c302b76
  
https://github.com/NixOS/nixpkgs/commit/e50203bfde29065fd7d1f047d9e3797f5c302b76
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-03-07 (Tue, 07 Mar 2017)

  Changed paths:
M pkgs/development/tools/yarn/default.nix

  Log Message:
  ---
  yarn: 0.21.3 -> 0.22.0


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


Re: [Nix-dev] 'nixos-stable' channel?

2017-03-06 Thread zimbatm
At the moment we don't provide a strong guarantee that release upgrades
will be 100% backward-compatible. Having a "stable" channel that jumps
between releases would be misleading I think.

On Mon, 6 Mar 2017, 15:07 Linus Heckemann,  wrote:

> On 06/03/17 15:03, Domen Kožar wrote:
> > It's something like 15min of work to parse http://nixos.org/channels/
> > and point to the latest channel if someone needs this.
> >
> > Officially this is a very bad idea, since people will want us to
> > support it.
>
> Isn't the point to just have it refer to the version of NixOS that *is*
> being supported? I don't see how parsing http://nixos.org/channels will
> convey that information — 17.03 has existed for longer than it's been
> supported, no? I.e. stable rather than latest.
> ___
> 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] NixOS London Hackday #2

2017-03-04 Thread zimbatm
Hi all,

I think I forgot to post this. Next Sunday (11th) we're hosting our second
Hackday in London.

Everyone is welcome to join. Thomas and I will be available if you want
help for packaging your own stuff or just help you out in general.

https://www.meetup.com/NixOS-London/events/237738532/

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


[Nix-commits] [NixOS/nixpkgs] 9c1399: packer: 0.12.1 -> 0.12.2

2017-02-21 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 9c1399e476f98a68726bcd1792426300d388592c
  
https://github.com/NixOS/nixpkgs/commit/9c1399e476f98a68726bcd1792426300d388592c
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-02-21 (Tue, 21 Feb 2017)

  Changed paths:
M pkgs/development/tools/packer/default.nix

  Log Message:
  ---
  packer: 0.12.1 -> 0.12.2


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


[Nix-dev] [ANN] docker-nix-builder beta

2017-02-19 Thread zimbatm
Did you ever have to battle with a user that only wants to have Docker
installed on his system? Or a user that is developing on macOS and has
broken nix packages?

docker-nix-builder is a tool to help smooth the transition. Instead of
using nix to build the project, use Docker to run nix to build the project.
At the end the users gets a new Docker container that only (mostly)
contains the build result.

It's not very efficient because it doesn't benefit from the local
`/nix/store` but that's not the goal. If the user wants to benefit from the
full awesomeness of Nix he just has to install Nix.

https://github.com/numtide/docker-nix-builder
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Explicitly selecting sources for "src" in stdenv.mkDerivation?

2017-02-16 Thread zimbatm
I've been using filterSource. It works okay but is a bit too generic. It
would be nice to have a function that understands a gitignore-like syntax.

On Thu, 16 Feb 2017, 12:44 Profpatsch,  wrote:

> On 17-02-16 01:28pm, Freddy Rietdijk wrote:
> > > src = [ ./subproject-A/schema.sql ./subproject-A/lib ];
> >
> > Each of the files you mentioned here will be stored in a separate store
> > path. You could write a simple function that takes a list of derivations
> > and copies the contents of those derivations in a new output.
>
> Also maybe take a look at the `filterSource` builtin.
> There’s also some wrappers for common setups in lib/sources.nix
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
> ___
> 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] buildMaven usage

2017-02-15 Thread zimbatm
Hi laverne,

did you manage to figure it out?

I think the usage would be to run
https://github.com/NixOS/mvn2nix-maven-plugin on your project and then in
your default.nix add something like:
```
{ pkgs ? import  {}
, buildMaven ? pkgs.buildMaven
}:
buildMaven ./infofile
```

Where the `./infofile` is the file generated by mvn2nix (it should be a
JSON file).

As you can see not a lot of people are packaging java apps :)

Cheers,
z

On Fri, 10 Feb 2017 at 05:47 laverne  wrote:

> Hi,
>
> I have a question about the function defined at
> https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/build-maven.nix
>
> I wanted to use it to build Spark Frame (http://sparkjava.com/), however,
> while the function is in all-packages, it isn't doesn't seem to be used
> anywhere else in nixpkgs. Is anyone here using the function in other
> projects that they would be willing to link to so that I could get a feel
> for how to use it?
>
> Thanks,
> Laverne
> ___
> 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] nix-shell (was: Python 3 as default)

2017-02-14 Thread zimbatm
Point 4 is really the biggest problem for me because the user loses
control. Especially when combined with direnv the user might be surprised
with a big update by just changing directory.

I think that this can be solved using a profile. The user  would load the
profile with nix-shell and use nix-build to switch profiles.

On Tue, 14 Feb 2017, 17:45 Peter Simons,  wrote:

> Hi Profpatsch,
>
>  >> I hardly ever use nix-shell and I don't want to, to be honest.
>  >
>  > Why is that?
>
> 1. I don't need it. Adding those Haskell/Python/LaTeX/R modules that I
>need into my global user environment works just fine. I suppose there
>might be occasions where versions conflict in a way that makes it
>impossible to add them into the same environment, but I haven't
>actually encountered that problem yet. Since I don't need more than
>one shell environment, I don't have to bother will shell.nix files,
>and I don't have to remember which open shell window is running which
>environment either.
>
> 2. nix-shells don't nest. And even if they would, many things you'll
>define inside of a nix-shell won't nest. Thus, you cannot easily
>compose shell environments, which makes it hard to define accurate
>environments in a modular and re-usable fashion.
>
> 3. nix-shell interacts poorly with long-running processes. I work on all
>my projects with Emacs, but I don't want to start Emacs inside of a
>nix-shell created for one particular project. My Emacs is up and
>running from the moment I log in and then I don't ever quit it unless
>I absolutely have to. So having a proper build environment in "some
>other window" isn't very useful to me. I want to compile by hitting
>C-c C-c or C-c C-l.
>
> 4. When I update my copy of the Nixpkgs repository, I run "nix-env -u
>--always" and afterwards everything I'll need to work on all of my
>projects is available locally in my /nix store. If I see that Nix
>needs to compile hundreds of packages to do the update, then I may or
>may not decide to postpone the update. When using nix-shell, I won't
>know whether it needs to compile for an hour until I've actually run
>it, i.e. I'll notice that I can't start hacking on some project only
>after I've decided I want to do that. With one global environment, I
>have that information for all my projects at the time I decide
>whether to update or not.
>
> 5. The default nix-shell prompt in bash does not distinguish between
>"root" and normal users. ;-)
>
> Having said all that, I believe that nix-shell is genuinely useful and I
> do use it every now and then. I wouldn't want to get along without it. I
> just wouldn't want to use it as much as some people apparently do.
>
> Best regards,
> Peter
>
> ___
> 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] "Monitoring" NixOS?

2017-02-14 Thread zimbatm
It would be useful to know how far behind a machine is given a specific
channel. Especially if you care about security updates.

A "needs reboot" flag for when the kernel is updated.

GC state or just store size.

And the the common Linux monitoring metrics apply for vmm, CPU, net, io,
entropy pool, ...

On Mon, 13 Feb 2017, 14:29 Daniel Peebles,  wrote:

> Hi all,
>
> I just packaged up the AWS SSM agent [1], which is a cool system for
> automated management of fleets of machines both in AWS and outside of it,
> allowing you to run commands on all of them, check "inventory" across all
> of them automatically, set policies on disparate types of machines, and so
> on.
>
> NixOS seems to work fine with it and I can run commands on it and keep an
> eye on the current NixOS release by injecting a fake lsb_release into its
> path. But one of the features of SSM is the ability to take an inventory of
> "installed" packages on a system. Of course, that notion doesn't directly
> make sense in NixOS, but it got me wondering what sorts of metrics might
> make sense from a "keep an eye on your fleet of NixOS systems" perspective.
>
> Some possibilities:
>
>1. Track runtime dependencies of the system root, and ideally maintain
>an external mapping of all of those hashes to expressions that produce
>them. The first part I know how to do, but the second part seems tricky.
>2. Monitor "GC state" of your NixOS system: count how many
>unreferenced derivations are in the store and how much disk space past
>system generations retain (factoring in hard linking and such)
>3. Dump current systemd unit state (broader than just NixOS, obviously)
>4. Track total time spent building derivations and downloading
>substitutes: could be helpful to understand that some of your machines
>aren't accessing your binary cache properly. Perhaps also a "binary cache
>hit rate" metric.
>
> Does anyone have others? If you manage a large fleet of NixOS machines
> (and possibly other types of OSes too, so NixOps might not be suitable),
> which metrics do you find useful? Even if you do use NixOps to manage the
> state of your machines, ongoing metrics can still be useful for assessing
> the health of your systems. You don't want to be surprised by a machine's
> drive filling up because its store is full of junk :)
>
> Thanks,
> Dan
>
> [1] https://aws.amazon.com/ec2/systems-manager/
> ___
> 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] RFC for RFCs

2017-02-12 Thread zimbatm
Hi all,

we discussed of introducing a RFC process during FOSDEM. The goal is to
help discussion for large or controversial changes which typically grind to
a halt.

Here is an initial proposal based on the one from the Rust community:
https://github.com/zimbatm/rfcs/pull/1 . Please let me know what you think.

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


Re: [Nix-dev] help with patch for screen locking

2017-02-07 Thread zimbatm
Regarding the suid bit, why don't we let the program decide what suid
should be applied to it's programs?
https://github.com/NixOS/nixpkgs/pull/22532

On Tue, 7 Feb 2017 at 19:38  wrote:

> On 2017-02-07 19:50, Tomasz Czyż wrote:
> > David,
> >
> > I assume you are not talking about
> > https://github.com/NixOS/nixpkgs/issues/16485 [2]?
>
> In fact I'm talking about https://github.com/NixOS/nixpkgs/issues/16845
> :-) my mistake
>
> > Usually I'm using this kind of stuff as part of user session/desktop
> > environment.
>
> Exactly, the actual screenlocker would be installed as a system package,
> I thought it was okay because I noticed something like that was already
> present in xfce.nix, but maybe we can adapt xfce4-session to accept a
> new build input and change it so that it calls the screenlocker in the
> nix store instead of calling the system package.
>
> With regards to slock: maybe we can ask the user to explicitly enable
> the suid like we do when a user tries to install a non-free package?
> ___
> 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] help with patch for screen locking

2017-02-07 Thread zimbatm
As a user I would expect slock to be installed and added to the suid list
if I selected it as my screensaver. That way I can also invoke it manually
in cases where I want to lock the screen manually.

On Mon, 6 Feb 2017, 23:51 ,  wrote:

> Hi!
> I am making a patch to fix issue #16485 but I have encountered an issue.
>
> I added an option called screenLock to
> services.xserver.desktopManager.xfce that can take only "xscreensaver"
> "xlockmore" "slock" "gnome-screensaver" as values but:
>
> - gnome-screensaver seems to not exist anymore, at least not on nixos,
> so I removed the choice
> - slock needs suid to lock the screen, as explained in the wiki too, so
> I don't know if with this patch I should install slock and also set it
> suid, or if it's better to leave the choice out, or if the user that
> puts screenLock = "slock" should be presented an error in case slock is
> not set suid by the user themselves.
>
>
> Thanks for your help
> ___
> 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] Fosdem

2017-02-04 Thread zimbatm
We have a telegram group going: +44 7857103063

On Sat, 4 Feb 2017 at 09:56 Adrien Devresse  wrote:

> Ok to meet up :)
>
> name: adev
>
>
> Le 04/02/17 à 01:09, Franz Pletz a écrit :
> > We will probably be hacking somewhere on the venue in between talks.
> Ping me on IRC if you want to meet up.
>
> ___
> 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] nix on ubuntu/debian. replace core packages.

2017-02-03 Thread zimbatm
Even with hibernation it's not really possible to boot into another OS that
quickly. If you want both systems running side by side it's probably easier
to use a VM.

On Fri, 3 Feb 2017 at 15:50 Peter Holm <peter.g.h...@gmail.com> wrote:

> I was accidently posting this directly to zimbatm. I reposting it to the
> list.
>
> 2017-02-03 1:42 GMT+01:00, Peter Holm <peter.g.h...@gmail.com>:
> > I was more thinking about something like this
> > https://github.com/NixOS/nixpkgs/issues/3111
> > But with custom kernel for each dist, some way to save the running
> > process and reload them  within a ureadhead-reboot (fake stay at the
> > same system).
> >
> > The computer should flicker a bit -  kick you out from the current
> > x-session and then be able to restore the state of the sesssion with a
> > login prompt from the  dm.
> >
> > One had to write a custom hibernate-handler for that.
> >
> > Is that impossible, or just "hard" to get done.?
> >
> > 2016-12-30 12:48 GMT+01:00, zimbatm <zimb...@zimbatm.com>:
> >> Hi Peter,
> >>
> >> When nix is installed on another distro what you get is a
> >> `~/.nix-profile/bin` installed in your PATH before the usual
> >> /usr/bin,/bin
> >> and so on.  So if you install userland tools they will "replace" the
> >> system-provided ones just because the path lookup will find them first.
> >> So
> >> in that sense you get a unified userland between distros if you install
> >> the
> >> same nix packages. Does that answer your question? Note that this only
> >> works for userspace program and not system services.
> >>
> >> On Tue, 27 Dec 2016 at 06:15 Peter Holm <peter.g.h...@gmail.com> wrote:
> >>
> >>> My question is regarding  Nix multiuser-install.
> >>> Is it possible to replace the base-system with packages from nix.?
> >>> Or even better - boot to base-system from nix core, and keep desired
> >>> tools from the previous userland.?
> >>>
> >>> My idea is simple - if its can be done. Then probably  one vould
> >>> ectand it to on-the-fly switch userland between distros and keep whats
> >>> installed from nix. Ok, you have to rebind or replace some
> >>> config-files... But , i belive  that should not be impossible to get
> >>> going.?
> >>>
> >>> /Peter
> >>> ___
> >>> 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] Shutting down prs.nix.gsc.io

2017-02-01 Thread zimbatm
Ouch. How much is "very very"? Try to talk to the Amazon support, they
might help you with the bill. Happy to chip in as well.

As for the reason, it's probably because the machines are hosted outside of
AWS and constantly pulling from S3. Amazon has outrageous egress pricing.
You will probably be better off setting up a S3-compatible storage like
ceph.

On Tue, 31 Jan 2017, 20:11 Graham Christensen,  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
> Well, it has been a good run. Having the space to experiment and try a
> few things was very good. As of a few minutes ago, I have removed all
> the nodes from the hydra master.
>
> WHY? I got my Amazon S3 bill, and it was very, very expensive, even for
> half a month.
>
> WHAT IS NEXT? I'm working with Eelco to move the GitHub pull request
> triggering and the amazingly capable build machines in to
> hydra.nixos.org.
>
> Sorry for the short notice! I hope we have the PR building system
> transfered over very soon.
>
> Thank you,
> Graham Christensen
>
>
>
> -BEGIN PGP SIGNATURE-
>
> iQIcBAEBCAAGBQJYkO9bAAoJEAYSHTZv6UNcPQwP/2zCZFP46jNtYMIVlynnrprj
> gp1u3Z7YZ7HzyEqwHx2qhTVz6WV2ZRC/UWYYjz114dLnfDjhtSmjFfuV28uCiqhz
> f/Cu8iSEdOdL6i0CTfFpN2QM/DD2jAIpbCdnGB7aiz6FPEEViHAhn+KZ66SMoOMu
> BVOhii1/oRl1jB/zClRnSYdbsLVgA2bRSjIFApWWwPGueQ0UNji7tkWx5ruRoRU7
> TripLT74Rn5EVYnUVG/s4N9EsaEvf6ObXM2f0XaIJNE0eMk3REM/ZHrdK+izlHlR
> uJk3IUZpKkcrhMmNO42OjTStpKYUXzJ8JbgtRfgViwTi+HjZCNhGugrR+t5USUNX
> 4c2rW8g2JrN61r3yP4T/8fcVOCEBUl1YYFGHd9kc1lbdveBeotk0iHQI8633WsuP
> pZX+kRIr1mOU7pl0m2esD9J34rlFam+SZAcgeOKgTYDc+1yBTw9GYoZaeux4uvN0
> 3PidY4iStx/qgK5LZDbUz8Bdxq6vqPXouwYuwNDWAA6FaPjn5BI3YkYj0LmsMPcL
> DZS5X6pzt8YDzVeuRcLI48cfBtv6YS7um5zbj0ePSq2K5Tbi6C/2dZQI90CkJlC0
> NocZM8rwURtusLsYZhM6YN/Y+vbh8xhfJ85U12ygajg2FPddkJCDQjM35GUo7rws
> ZfL5Phb6rNyagRZwtc2i
> =yaEh
> -END PGP SIGNATURE-
> ___
> 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] Fosdem

2017-01-31 Thread zimbatm
Count me in!

On Mon, 30 Jan 2017, 21:56 Putten, A. van (Arian), 
wrote:

> I will be there!
> --
> *From:* nix-dev-boun...@lists.science.uu.nl [
> nix-dev-boun...@lists.science.uu.nl] on behalf of Nathan Bijnens [
> nat...@nathan.gs]
> *Sent:* Monday, January 30, 2017 9:35 PM
> *To:* Louis Taylor
> *Cc:* nix-dev
> *Subject:* Re: [Nix-dev] Fosdem
>
> I will be there on Saturday, mostly at the Big Data track.
>
> N.
>
> On Mon, Jan 30, 2017, 21:33 Louis Taylor  wrote:
>
> On Mon, Jan 30, 2017 at 8:16 PM, Nathan Bijnens  wrote:
> > Anyone going to Fosdem?
>
> February just isn't right without a trip to Brussels!
>
> ___
> 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-commits] [NixOS/nixpkgs] 36ac70: tetex: fix source urls

2017-01-24 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 36ac7058d2859c8544a2140f245c7c980900c6ac
  
https://github.com/NixOS/nixpkgs/commit/36ac7058d2859c8544a2140f245c7c980900c6ac
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-01-24 (Tue, 24 Jan 2017)

  Changed paths:
M pkgs/tools/typesetting/tex/tetex/default.nix

  Log Message:
  ---
  tetex: fix source urls


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


Re: [Nix-dev] Fwd: [caskroom/homebrew-cask] Added nix 1.11.5 (#28531)

2017-01-16 Thread zimbatm
Nice, thanks

On Sun, 15 Jan 2017, 09:12 Benno Fünfstück, <benno.fuenfstu...@gmail.com>
wrote:

> Cool, that's a really nice feature. With hub, you should be able to do:
>
> $ hub remote add -p $user
>
> To get RW access
>
> zimbatm <zimb...@zimbatm.com> schrieb am So., 15. Jan. 2017, 00:55:
>
> Actually hub remote only add a read-only git:// remote so it’s not super
> useful. The git-extras package also has a git pr
> <https://github.com/tj/git-extras/blob/master/Commands.md#git-pr> command
> that populates a pr/$number branch with the pull-request commits. But it
> doesn’t set the remote properly either.
> ​
>
> On Sat, 14 Jan 2017 at 23:02 zimbatm <zimb...@zimbatm.com> wrote:
>
> As the person submitting the PR, there is a checkbox (that is checked by
> default) that grants reviewers access to the branch.
>
> As a reviewer, the procedure is to git remote add $user g...@github.com:
> $user/nixpkgs.git. Checkout the branch and push the commits that you
> want. Force-push is not allowed for the reviewer on that branch. To make
> things a bit faster, install the hub <https://hub.github.com/> CLI, then
> you can hub remote add $user which translates to the same as above.
> ​
>
> On Sat, 14 Jan 2017 at 09:54 Benno Fünfstück <benno.fuenfstu...@gmail.com>
> wrote:
>
> > Finally during the review, the reviewer was pushing style fixes to the
> PR. It was probably as quick as leaving a comment and made the whole
> process much more inclusive, we were actually working together to get this
> merged.
>
> How does this work? Did you need to give him access to your repo for this,
> or is there some github-integrated way that I don't know of to push changes
> to branches of a PR?
>
> zimbatm <zimb...@zimbatm.com> schrieb am Fr., 6. Jan. 2017 um 21:17 Uhr:
>
> No not that I know of. It would be awkward to maintain because homebrew
> expects to be installed in /usr/local and not in the /nix/store. It works
> the other way around because homebrew casks don't try to maintain anything
> and just unpack and run an install script.
>
> On Fri, 6 Jan 2017 at 19:58 Jörg Thalheim <jo...@higgsboson.tk> wrote:
>
> I actually mean the other way around.
>
>
> On 2017-01-06 20:57, zimbatm wrote:
> > Yes that's the package. It installs nix with the nixpkgs-unstable
> channel. It does basically the same thing as `curl
> https://nixos.org/nix/install | sh` but also provides an uninstall step.
> >
> > On Fri, 6 Jan 2017 at 19:21 Jörg Thalheim <jo...@higgsboson.tk  jo...@higgsboson.tk>> wrote:
> >
> > Will there be a homebrew package for nixpkgs?
> >
> >
> > On 2017-01-06 19:40, zimbatm wrote:
> > > For the lulz I packaged nix for homebrew cask. Now you can `brew
> cask install nix`. Anyways, what I wanted to highlight is that the
> contributiob process was quite nice, there are probably some ideas that we
> could take from them.
> > >
> > > There is a clear path to contribution starting from the README.md
> which links to the right document. Also `brew cask create nix` was all I
> needed to get the new package description opened in my $EDITOR.
> > >
> > > When they rejected the package it was with a link to a clear
> document that lists the inclusion criteria. This also helped me appeal and
> ultimately revert the decision by sharing some missing context.
> > >
> > > Finally during the review, the reviewer was pushing style fixes to
> the PR. It was probably as quick as leaving a comment and made the whole
> process much more inclusive, we were actually working together to get this
> merged.
> > >
> > > These are just some highlights. In general I find that homebrew
> has a good focus on usability.
> > >
> > > -- Forwarded message -
> > > From: Miccal Matthews <notificati...@github.com  notificati...@github.com> <mailto:notificati...@github.com  notificati...@github.com>>>
> > > Date: Thu, 5 Jan 2017, 11:43
> > > Subject: Re: [caskroom/homebrew-cask] Added nix 1.11.5 (#28531)
> > > To: caskroom/homebrew-cask <homebrew-c...@noreply.github.com
> <mailto:homebrew-c...@noreply.github.com>  homebrew-c...@noreply.github.com <mailto:homebrew-c...@noreply.github.com
> >>>
> > > Cc: zimbatm <zimb...@zimbatm.com <mailto:zimb...@zimbatm.com>
> <mailto:zimb...@zimbatm.com <mailto:zimb...@zimbatm.com>>>, Author <
> aut...@noreply.github.com <mailto:aut...@noreply

[Nix-commits] [NixOS/nixpkgs] f9a9ea: Revert "nodePackages.yarn: remove package"

2017-01-15 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f9a9ea920a3bf225a932220e6bce0ba0f947542d
  
https://github.com/NixOS/nixpkgs/commit/f9a9ea920a3bf225a932220e6bce0ba0f947542d
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2017-01-15 (Sun, 15 Jan 2017)

  Changed paths:
M pkgs/development/node-packages/composition-v4.nix
M pkgs/development/node-packages/composition-v6.nix
M pkgs/development/node-packages/node-packages-v4.nix
M pkgs/development/node-packages/node-packages-v6.nix
M pkgs/development/node-packages/node-packages.json

  Log Message:
  ---
  Revert "nodePackages.yarn: remove package"

This reverts commit 986dba716f8244304e5e9afb92924eb543fc5596.

Fixes:

error: anonymous function at 
/home/travis/build/NixOS/nixpkgs/pkgs/development/node-packages/node-env.nix:3:1
 called with unexpected argument ‘python’, at 
/home/travis/build/NixOS/nixpkgs/pkgs/development/node-packages/composition-v6.nix:8:13

This commit is doing a lot more than removing the yarn package, it also
upgrades a ton of other packages.


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


Re: [Nix-dev] Fwd: [caskroom/homebrew-cask] Added nix 1.11.5 (#28531)

2017-01-14 Thread zimbatm
Actually hub remote only add a read-only git:// remote so it’s not super
useful. The git-extras package also has a git pr
<https://github.com/tj/git-extras/blob/master/Commands.md#git-pr> command
that populates a pr/$number branch with the pull-request commits. But it
doesn’t set the remote properly either.
​

On Sat, 14 Jan 2017 at 23:02 zimbatm <zimb...@zimbatm.com> wrote:

> As the person submitting the PR, there is a checkbox (that is checked by
> default) that grants reviewers access to the branch.
>
> As a reviewer, the procedure is to git remote add $user g...@github.com:
> $user/nixpkgs.git. Checkout the branch and push the commits that you
> want. Force-push is not allowed for the reviewer on that branch. To make
> things a bit faster, install the hub <https://hub.github.com/> CLI, then
> you can hub remote add $user which translates to the same as above.
> ​
>
> On Sat, 14 Jan 2017 at 09:54 Benno Fünfstück <benno.fuenfstu...@gmail.com>
> wrote:
>
> > Finally during the review, the reviewer was pushing style fixes to the
> PR. It was probably as quick as leaving a comment and made the whole
> process much more inclusive, we were actually working together to get this
> merged.
>
> How does this work? Did you need to give him access to your repo for this,
> or is there some github-integrated way that I don't know of to push changes
> to branches of a PR?
>
> zimbatm <zimb...@zimbatm.com> schrieb am Fr., 6. Jan. 2017 um 21:17 Uhr:
>
> No not that I know of. It would be awkward to maintain because homebrew
> expects to be installed in /usr/local and not in the /nix/store. It works
> the other way around because homebrew casks don't try to maintain anything
> and just unpack and run an install script.
>
> On Fri, 6 Jan 2017 at 19:58 Jörg Thalheim <jo...@higgsboson.tk> wrote:
>
> I actually mean the other way around.
>
>
> On 2017-01-06 20:57, zimbatm wrote:
> > Yes that's the package. It installs nix with the nixpkgs-unstable
> channel. It does basically the same thing as `curl
> https://nixos.org/nix/install | sh` but also provides an uninstall step.
> >
> > On Fri, 6 Jan 2017 at 19:21 Jörg Thalheim <jo...@higgsboson.tk  jo...@higgsboson.tk>> wrote:
> >
> > Will there be a homebrew package for nixpkgs?
> >
> >
> > On 2017-01-06 19:40, zimbatm wrote:
> > > For the lulz I packaged nix for homebrew cask. Now you can `brew
> cask install nix`. Anyways, what I wanted to highlight is that the
> contributiob process was quite nice, there are probably some ideas that we
> could take from them.
> > >
> > > There is a clear path to contribution starting from the README.md
> which links to the right document. Also `brew cask create nix` was all I
> needed to get the new package description opened in my $EDITOR.
> > >
> > > When they rejected the package it was with a link to a clear
> document that lists the inclusion criteria. This also helped me appeal and
> ultimately revert the decision by sharing some missing context.
> > >
> > > Finally during the review, the reviewer was pushing style fixes to
> the PR. It was probably as quick as leaving a comment and made the whole
> process much more inclusive, we were actually working together to get this
> merged.
> > >
> > > These are just some highlights. In general I find that homebrew
> has a good focus on usability.
> > >
> > > -- Forwarded message -
> > > From: Miccal Matthews <notificati...@github.com  notificati...@github.com> <mailto:notificati...@github.com  notificati...@github.com>>>
> > > Date: Thu, 5 Jan 2017, 11:43
> > > Subject: Re: [caskroom/homebrew-cask] Added nix 1.11.5 (#28531)
> > > To: caskroom/homebrew-cask <homebrew-c...@noreply.github.com
> <mailto:homebrew-c...@noreply.github.com>  homebrew-c...@noreply.github.com <mailto:homebrew-c...@noreply.github.com
> >>>
> > > Cc: zimbatm <zimb...@zimbatm.com <mailto:zimb...@zimbatm.com>
> <mailto:zimb...@zimbatm.com <mailto:zimb...@zimbatm.com>>>, Author <
> aut...@noreply.github.com <mailto:aut...@noreply.github.com>  aut...@noreply.github.com <mailto:aut...@noreply.github.com>>>
> > >
> > >
> > > Merged #28531 <
> https://github.com/caskroom/homebrew-cask/pull/28531>.
> > >
> > > —
> > > You are receiving this because you authored the thread.
> > > Reply to this email directly, view it on GitHub <
> https://github.com/caskroo

Re: [Nix-dev] Fwd: [caskroom/homebrew-cask] Added nix 1.11.5 (#28531)

2017-01-14 Thread zimbatm
As the person submitting the PR, there is a checkbox (that is checked by
default) that grants reviewers access to the branch.

As a reviewer, the procedure is to git remote add $user g...@github.com:
$user/nixpkgs.git. Checkout the branch and push the commits that you want.
Force-push is not allowed for the reviewer on that branch. To make things a
bit faster, install the hub <https://hub.github.com/> CLI, then you can hub
remote add $user which translates to the same as above.
​

On Sat, 14 Jan 2017 at 09:54 Benno Fünfstück <benno.fuenfstu...@gmail.com>
wrote:

> > Finally during the review, the reviewer was pushing style fixes to the
> PR. It was probably as quick as leaving a comment and made the whole
> process much more inclusive, we were actually working together to get this
> merged.
>
> How does this work? Did you need to give him access to your repo for this,
> or is there some github-integrated way that I don't know of to push changes
> to branches of a PR?
>
> zimbatm <zimb...@zimbatm.com> schrieb am Fr., 6. Jan. 2017 um 21:17 Uhr:
>
> No not that I know of. It would be awkward to maintain because homebrew
> expects to be installed in /usr/local and not in the /nix/store. It works
> the other way around because homebrew casks don't try to maintain anything
> and just unpack and run an install script.
>
> On Fri, 6 Jan 2017 at 19:58 Jörg Thalheim <jo...@higgsboson.tk> wrote:
>
> I actually mean the other way around.
>
>
> On 2017-01-06 20:57, zimbatm wrote:
> > Yes that's the package. It installs nix with the nixpkgs-unstable
> channel. It does basically the same thing as `curl
> https://nixos.org/nix/install | sh` but also provides an uninstall step.
> >
> > On Fri, 6 Jan 2017 at 19:21 Jörg Thalheim <jo...@higgsboson.tk  jo...@higgsboson.tk>> wrote:
> >
> > Will there be a homebrew package for nixpkgs?
> >
> >
> > On 2017-01-06 19:40, zimbatm wrote:
> > > For the lulz I packaged nix for homebrew cask. Now you can `brew
> cask install nix`. Anyways, what I wanted to highlight is that the
> contributiob process was quite nice, there are probably some ideas that we
> could take from them.
> > >
> > > There is a clear path to contribution starting from the README.md
> which links to the right document. Also `brew cask create nix` was all I
> needed to get the new package description opened in my $EDITOR.
> > >
> > > When they rejected the package it was with a link to a clear
> document that lists the inclusion criteria. This also helped me appeal and
> ultimately revert the decision by sharing some missing context.
> > >
> > > Finally during the review, the reviewer was pushing style fixes to
> the PR. It was probably as quick as leaving a comment and made the whole
> process much more inclusive, we were actually working together to get this
> merged.
> > >
> > > These are just some highlights. In general I find that homebrew
> has a good focus on usability.
> > >
> > > -- Forwarded message -
> > > From: Miccal Matthews <notificati...@github.com  notificati...@github.com> <mailto:notificati...@github.com  notificati...@github.com>>>
> > > Date: Thu, 5 Jan 2017, 11:43
> > > Subject: Re: [caskroom/homebrew-cask] Added nix 1.11.5 (#28531)
> > > To: caskroom/homebrew-cask <homebrew-c...@noreply.github.com
> <mailto:homebrew-c...@noreply.github.com>  homebrew-c...@noreply.github.com <mailto:homebrew-c...@noreply.github.com
> >>>
> > > Cc: zimbatm <zimb...@zimbatm.com <mailto:zimb...@zimbatm.com>
> <mailto:zimb...@zimbatm.com <mailto:zimb...@zimbatm.com>>>, Author <
> aut...@noreply.github.com <mailto:aut...@noreply.github.com>  aut...@noreply.github.com <mailto:aut...@noreply.github.com>>>
> > >
> > >
> > > Merged #28531 <
> https://github.com/caskroom/homebrew-cask/pull/28531>.
> > >
> > > —
> > > You are receiving this because you authored the thread.
> > > Reply to this email directly, view it on GitHub <
> https://github.com/caskroom/homebrew-cask/pull/28531#event-912529758>, or
> mute the thread <
> https://github.com/notifications/unsubscribe-auth/AAAMsDii1OcfwpqT5gwbNWZLdZ2Ef1Soks5rPNdUgaJpZM4LaLKP
> >.
> > >
> > >
> > >
> > > ___
> > > nix-dev mailing list
> > > nix-dev@lists.science.uu.nl <mailto:nix-dev@lists.science.uu.nl>
> >   

Re: [Nix-dev] Typing nix − funding campaign

2017-01-14 Thread zimbatm
Thanks everyone! I'm impressed by how fast that went.

On Sat, 14 Jan 2017 at 20:27 Domen Kožar  wrote:

> It's funded :) Congratz!
>
> On Fri, Jan 13, 2017 at 10:56 AM, Théophane Hufschmitt <
> rg_ni...@regnat.ovh> wrote:
>
> Thu 12 Jan 17 − 14:13, Théophane Hufschmitt(rg_ni...@regnat.ovh) a écrit:
> > Hi,
> >
> > I am Théophane Hufschmitt, a french master degree CS student, and I
> > wish to start a six month length internship on giving nix a type
> > system.
> >
> > Numtide offered to fund a part of the internship, but we still need
> > some help for me to be able to start it.
> >
> > The goal of the internship is to design (and implement) a type system
> > for nix in order to be able to statically get some guaranties about
> > the well-foundness of the nixpkgs repo (or any nix expression), in
> > complement to hydra or travis tests which may let some inconsistencies
> > pass − especially on nixos module system which is way harder to test.
> >
> > Providing nix with a proper type system is a long running issue (see
> > https://github.com/NixOS/nix/issues/14), and I think a huge
> > opportunity for nix to improve its awesomeness.
> >
> > The crowdfunding campaign (and a slightly more detailled description of
> > the project) is open at https://www.gofundme.com/typing-nix, and you
> > are all invited to donate.
> >
> > Of course, I'll be happy to answer any question, by mail or on
> > irc/matrix (I am regnat[m] on freenode).
> >
> > --
> > Théophane Hufschmitt
>
> Already one half of the required funding has been reached in less than
> one day. A big thanks to all the donators !
>
> For everyone else, there is still at lot of place if you want to be a
> part of this, so don't hesitate ;)
>
> --
> Théophane Hufschmitt
>
> ___
> 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] Call For Maintainers - Fractalide BETA release

2017-01-12 Thread zimbatm
Ironically I didn't get the original message but now have 10 more emails to
read, not all of them super friendly. As far as I know there are no
explicit rules for the mailing list so it's open for interpretation. If we
want to set more rules then we need a document that we can refer people to,
and therefor a process to create the document.

Personally I think it's acceptable to post announcement-type emails from
related projects like fractalide and guix. We are not a super big community
so let's not split ourselves in smaller pieces. Worst case, add a
"-fractalide" filter in the email client.

On Thu, 12 Jan 2017 at 14:33 Moritz Ulrich  wrote:

stewart mackenzie  writes:

> Reusable Functions - They're great, they're just great, you'll love them.

Sneaky remarks like this are totally inappropriate here. Profpatsch
asked nicely for a short pitch of your project, and you throw this
completely useless sentence into his face.

This isn't how you get users for your project. Personally, I'm repelled
by your behavior.
___
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] Fwd: [caskroom/homebrew-cask] Added nix 1.11.5 (#28531)

2017-01-06 Thread zimbatm
No not that I know of. It would be awkward to maintain because homebrew
expects to be installed in /usr/local and not in the /nix/store. It works
the other way around because homebrew casks don't try to maintain anything
and just unpack and run an install script.

On Fri, 6 Jan 2017 at 19:58 Jörg Thalheim <jo...@higgsboson.tk> wrote:

> I actually mean the other way around.
>
>
> On 2017-01-06 20:57, zimbatm wrote:
> > Yes that's the package. It installs nix with the nixpkgs-unstable
> channel. It does basically the same thing as `curl
> https://nixos.org/nix/install | sh` but also provides an uninstall step.
> >
> > On Fri, 6 Jan 2017 at 19:21 Jörg Thalheim <jo...@higgsboson.tk  jo...@higgsboson.tk>> wrote:
> >
> > Will there be a homebrew package for nixpkgs?
> >
> >
> > On 2017-01-06 19:40, zimbatm wrote:
> > > For the lulz I packaged nix for homebrew cask. Now you can `brew
> cask install nix`. Anyways, what I wanted to highlight is that the
> contributiob process was quite nice, there are probably some ideas that we
> could take from them.
> > >
> > > There is a clear path to contribution starting from the README.md
> which links to the right document. Also `brew cask create nix` was all I
> needed to get the new package description opened in my $EDITOR.
> > >
> > > When they rejected the package it was with a link to a clear
> document that lists the inclusion criteria. This also helped me appeal and
> ultimately revert the decision by sharing some missing context.
> > >
> > > Finally during the review, the reviewer was pushing style fixes to
> the PR. It was probably as quick as leaving a comment and made the whole
> process much more inclusive, we were actually working together to get this
> merged.
> > >
> > > These are just some highlights. In general I find that homebrew
> has a good focus on usability.
> > >
> > > -- Forwarded message -
> > > From: Miccal Matthews <notificati...@github.com  notificati...@github.com> <mailto:notificati...@github.com  notificati...@github.com>>>
> > > Date: Thu, 5 Jan 2017, 11:43
> > > Subject: Re: [caskroom/homebrew-cask] Added nix 1.11.5 (#28531)
> > > To: caskroom/homebrew-cask <homebrew-c...@noreply.github.com
> <mailto:homebrew-c...@noreply.github.com>  homebrew-c...@noreply.github.com <mailto:homebrew-c...@noreply.github.com
> >>>
> > > Cc: zimbatm <zimb...@zimbatm.com <mailto:zimb...@zimbatm.com>
> <mailto:zimb...@zimbatm.com <mailto:zimb...@zimbatm.com>>>, Author <
> aut...@noreply.github.com <mailto:aut...@noreply.github.com>  aut...@noreply.github.com <mailto:aut...@noreply.github.com>>>
> > >
> > >
> > > Merged #28531 <
> https://github.com/caskroom/homebrew-cask/pull/28531>.
> > >
> > > —
> > > You are receiving this because you authored the thread.
> > > Reply to this email directly, view it on GitHub <
> https://github.com/caskroom/homebrew-cask/pull/28531#event-912529758>, or
> mute the thread <
> https://github.com/notifications/unsubscribe-auth/AAAMsDii1OcfwpqT5gwbNWZLdZ2Ef1Soks5rPNdUgaJpZM4LaLKP
> >.
> > >
> > >
> > >
> > > ___
> > > nix-dev mailing list
> > > nix-dev@lists.science.uu.nl <mailto: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 <mailto: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] Fwd: [caskroom/homebrew-cask] Added nix 1.11.5 (#28531)

2017-01-06 Thread zimbatm
Yes that's the package. It installs nix with the nixpkgs-unstable channel.
It does basically the same thing as `curl https://nixos.org/nix/install |
sh` but also provides an uninstall step.

On Fri, 6 Jan 2017 at 19:21 Jörg Thalheim <jo...@higgsboson.tk> wrote:

> Will there be a homebrew package for nixpkgs?
>
>
> On 2017-01-06 19:40, zimbatm wrote:
> > For the lulz I packaged nix for homebrew cask. Now you can `brew cask
> install nix`. Anyways, what I wanted to highlight is that the contributiob
> process was quite nice, there are probably some ideas that we could take
> from them.
> >
> > There is a clear path to contribution starting from the README.md which
> links to the right document. Also `brew cask create nix` was all I needed
> to get the new package description opened in my $EDITOR.
> >
> > When they rejected the package it was with a link to a clear document
> that lists the inclusion criteria. This also helped me appeal and
> ultimately revert the decision by sharing some missing context.
> >
> > Finally during the review, the reviewer was pushing style fixes to the
> PR. It was probably as quick as leaving a comment and made the whole
> process much more inclusive, we were actually working together to get this
> merged.
> >
> > These are just some highlights. In general I find that homebrew has a
> good focus on usability.
> >
> > -- Forwarded message -
> > From: Miccal Matthews <notificati...@github.com  notificati...@github.com>>
> > Date: Thu, 5 Jan 2017, 11:43
> > Subject: Re: [caskroom/homebrew-cask] Added nix 1.11.5 (#28531)
> > To: caskroom/homebrew-cask <homebrew-c...@noreply.github.com  homebrew-c...@noreply.github.com>>
> > Cc: zimbatm <zimb...@zimbatm.com <mailto:zimb...@zimbatm.com>>, Author <
> aut...@noreply.github.com <mailto:aut...@noreply.github.com>>
> >
> >
> > Merged #28531 <https://github.com/caskroom/homebrew-cask/pull/28531>.
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub <
> https://github.com/caskroom/homebrew-cask/pull/28531#event-912529758>, or
> mute the thread <
> https://github.com/notifications/unsubscribe-auth/AAAMsDii1OcfwpqT5gwbNWZLdZ2Ef1Soks5rPNdUgaJpZM4LaLKP
> >.
> >
> >
> >
> > ___
> > 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] Announcing: NixOS Security Team, and Request for Comments

2017-01-06 Thread zimbatm
In relation to GPG key signing, I think it's safe to trust online
identities it they are established trough enough channels. That's basically
what keybase.io is doing, they are a point of contact but the proof of
identity is distributed on multiple services. Personal verification is just
another target.

Someone who would want to subvert that process would have to Impersonate
all these services through MITM and also maintain that in place if the user
is moving between connections (and somehow not trigger chrome's certificate
monitoring).
As far as I know only state actors might be able to pull that off. But they
also have access to zeroday to hack and extract the private key directly
which seem more practical to me.

Anyways, it's good that you want to be careful, that's just my thinking.

On Fri, 6 Jan 2017, 02:13 Graham Christensen,  wrote:

>
> (cross-posted to nix-dev for discussion.)
>
> Hello Nixians,
>
> This morning the NixOS Security Team was formalized in a PR to the
> homepage: https://github.com/NixOS/nixos-homepage/pull/123.
>
> This is now public at https://nixos.org/nixos/security.html.
>
> This information is currently listed as follows:
>
>
> Graham Christensen gra...@grahamc.com
> GPG Key: 0xFE918C3A98C1030F
> GPG Fingerprint: BA94 FDF1 1DA4 0521 2864 C121 FE91 8C3A 98C1 030F
>
> Franz Pletz fpl...@fnordicwalking.de
> GPG Key: 0x846FDED7792617B4
> GPG Fingerprint: 8A39 615D CE78 AF08 2E23 F303 846F DED7 7926 17B4
>
> Domen Kožar do...@dev.si
> GPG Key: 0xC2FFBCAFD2C24246
> GPG Fingerprint: E96C 15A0 8D17 CE3B 17B0 C7AB C2FF BCAF D2C2 4246
>
> Rob Vermaas rob.verm...@gmail.com
> GPG Key: 0xE114A5F264A8AE8E
> GPG Fingerprint: 96BF 75A5 3DEE 1F21 5F0C 979C E114 A5F2 64A8 AE8E
>
>
> At this time, none of us have signed each other's keys. There is some
> discussion about this in the pull request (linked above) but basically
> it boils down to this:
>
> We do each trust the work and intentions of each other, but this
> doesn't necessarily translate in to confirmed identity.
>
> Signing keys has a lot of meaning around verifying identity. Until
> each of us are able to be in the same room and check identification, we
> can't very well assert each other's identities.
>
> This is an effort to preserve the intentions of the web of trust... and
> this is where we get to the "request for comments" on how the Nix
> community would like for us to proceed on this front.
>
> If you have any opinions or feedback, please feel free to reply to the
> nix-dev email list, and _not_ the GitHub issue so as to keep further
> conversation on this list.
>
>
> Thank you,
> Graham Christensen
>
> --
> You received this message because you are subscribed to the Google Groups
> "nix-security-announce" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nix-security-announce+unsubscr...@googlegroups.com.
> To post to this group, send email to
> nix-security-annou...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/nix-security-announce/87bmvluead.fsf%40NdNdNx.supersecrets.gsc.io
> .
> For more options, visit https://groups.google.com/d/optout.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] Fwd: [caskroom/homebrew-cask] Added nix 1.11.5 (#28531)

2017-01-06 Thread zimbatm
For the lulz I packaged nix for homebrew cask. Now you can `brew cask
install nix`. Anyways, what I wanted to highlight is that the contributiob
process was quite nice, there are probably some ideas that we could take
from them.

There is a clear path to contribution starting from the README.md which
links to the right document. Also `brew cask create nix` was all I needed
to get the new package description opened in my $EDITOR.

When they rejected the package it was with a link to a clear document that
lists the inclusion criteria. This also helped me appeal and ultimately
revert the decision by sharing some missing context.

Finally during the review, the reviewer was pushing style fixes to the PR.
It was probably as quick as leaving a comment and made the whole process
much more inclusive, we were actually working together to get this merged.

These are just some highlights. In general I find that homebrew has a good
focus on usability.

-- Forwarded message -
From: Miccal Matthews <notificati...@github.com>
Date: Thu, 5 Jan 2017, 11:43
Subject: Re: [caskroom/homebrew-cask] Added nix 1.11.5 (#28531)
To: caskroom/homebrew-cask <homebrew-c...@noreply.github.com>
Cc: zimbatm <zimb...@zimbatm.com>, Author <aut...@noreply.github.com>


Merged #28531 <https://github.com/caskroom/homebrew-cask/pull/28531>.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/caskroom/homebrew-cask/pull/28531#event-912529758>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAMsDii1OcfwpqT5gwbNWZLdZ2Ef1Soks5rPNdUgaJpZM4LaLKP>
.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-commits] [NixOS/nixpkgs] 125328: zerotierone: 1.1.12 -> 1.1.14

2016-12-27 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 12532879b06d816ba88b52ed8ce5fdad53d6edb7
  
https://github.com/NixOS/nixpkgs/commit/12532879b06d816ba88b52ed8ce5fdad53d6edb7
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2016-12-27 (Tue, 27 Dec 2016)

  Changed paths:
M pkgs/tools/networking/zerotierone/default.nix

  Log Message:
  ---
  zerotierone: 1.1.12 -> 1.1.14


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


[Nix-commits] [NixOS/nixpkgs] 02c65b: google-chrome: add channel name suffix

2016-12-27 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 02c65bdac919fcb0cecc1a157744156ed39b9fc6
  
https://github.com/NixOS/nixpkgs/commit/02c65bdac919fcb0cecc1a157744156ed39b9fc6
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2016-12-27 (Tue, 27 Dec 2016)

  Changed paths:
M pkgs/applications/networking/browsers/google-chrome/default.nix

  Log Message:
  ---
  google-chrome: add channel name suffix

Updates would always select the unstable version otherwise. This was
copies from the chromium package.


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


[Nix-commits] [NixOS/nixpkgs] 004282: flashplayer: 11.2.202.644 -> 24.0.0.186 [Critical ...

2016-12-25 Thread zimbatm
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 00428231f8f4a454a832e4d0cedea148951e93c4
  
https://github.com/NixOS/nixpkgs/commit/00428231f8f4a454a832e4d0cedea148951e93c4
  Author: taku0 <ta...@users.noreply.github.com>
  Date:   2016-12-25 (Sun, 25 Dec 2016)

  Changed paths:
A 
pkgs/applications/networking/browsers/mozilla-plugins/flashplayer/default.nix
A 
pkgs/applications/networking/browsers/mozilla-plugins/flashplayer/standalone.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  flashplayer: 11.2.202.644 -> 24.0.0.186 [Critical security fix] (#21337)

* flashplayer: 11.2.202.644 -> 24.0.0.186

* flashplayer: add debug version

* flashplayer-standalone: 11.2.202.644 -> 24.0.0.186

(cherry picked from commit f3287b0aa53e9ff4ec61b3d8d5ed52f193540506)


  Commit: 435b5f8da08665600c1c93723a48527239882209
  
https://github.com/NixOS/nixpkgs/commit/435b5f8da08665600c1c93723a48527239882209
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2016-12-25 (Sun, 25 Dec 2016)

  Changed paths:
R 
pkgs/applications/networking/browsers/mozilla-plugins/flashplayer-11/default.nix

  Log Message:
  ---
  flashplayer: removed obsolete files

(cherry picked from commit a623ada9121c73833ef8dabeeb2e616a585d1b96)


Compare: https://github.com/NixOS/nixpkgs/compare/0ee1399a39b8...435b5f8da086___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


Re: [Nix-dev] Channels, LetsEncrypt, and Security fixes from 2016-12-23 01:26 UTC

2016-12-25 Thread zimbatm
Checking Hydra as well. Exim has been built but both the large and small
channels are stuck.

Unfortunately there are 130 (!!!) failing jobs on
http://hydra.nixos.org/jobset/nixos/release-16.09 . How did we get there?

The small build was blocked by a *new* package that pointed a missing file,
I reverted that change and the channel should advance in the next hour
unless somebody else is being reckless again.

We really need pierron's security framework so the security releases can be
pushed regardless of the branch's state. Or prevent users from pushing to
master unless the builds are passing.

On Sun, 25 Dec 2016 at 13:10 Graham Christensen <gra...@grahamc.com> wrote:

zimbatm <zimb...@zimbatm.com> writes:

> Thanks Graham.
>
> I pushed the Exim updates for CVE-2016-9963 as well.
>
> master: 352e167c224: exim: 4.87 -> 4.88 for CVE-2016-9963
> release-16.09: d6bff30c96ed6: exim: 4.87 -> 4.87.1 for CVE-2016-9963


Thank you so much! I have sent notice to the security list. Checking
Hydra, this channel update should be out very soon.

Graham

--
You received this message because you are subscribed to the Google Groups
"nix-security-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to nix-security-announce+unsubscr...@googlegroups.com.
To post to this group, send email to nix-security-annou...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/nix-security-announce/87zijkyx1v.fsf%40grahamc.com
.
For more options, visit https://groups.google.com/d/optout.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-commits] [NixOS/nixpkgs] a54d84: Revert "pythonPackages.webencodings: init at 0.5"

2016-12-25 Thread zimbatm
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: a54d84e0bb0d01f4c0c751cafd836d24a9f43a8e
  
https://github.com/NixOS/nixpkgs/commit/a54d84e0bb0d01f4c0c751cafd836d24a9f43a8e
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2016-12-25 (Sun, 25 Dec 2016)

  Changed paths:
R pkgs/development/python-modules/webencodings/default.nix
M pkgs/top-level/python-packages.nix

  Log Message:
  ---
  Revert "pythonPackages.webencodings: init at 0.5"

This reverts commit b5fcd04f1f54fbc1499c6f3d9d6c9593aa1880d1.


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


Re: [Nix-dev] ats2 advance version to 0.2.13

2016-12-25 Thread zimbatm
Thanks Karn, applied to master

On Sat, 24 Dec 2016 at 14:49 Karn Kallio 
wrote:

>
> The attached patch advances the version of the ats2 nixpkgs expression
> to the latest released version 0.2.13
> ___
> 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] Channels, LetsEncrypt, and Security fixes from 2016-12-23 01:26 UTC

2016-12-25 Thread zimbatm
Thanks Graham.

I pushed the Exim updates for CVE-2016-9963 as well.

master: 352e167c224: exim: 4.87 -> 4.88 for CVE-2016-9963
release-16.09: d6bff30c96ed6: exim: 4.87 -> 4.87.1 for CVE-2016-9963

The release branch only got the tiny update to avoid breaking
backward-compatibility.


On Fri, 23 Dec 2016 at 01:28 Graham Christensen  wrote:

>
> New format! If you have feedback on formatting, or extra information you
> would like to see here, please either mail the nix-dev mailing list, me
> personally, or open an issue at https://github.com/nixos/security.
>
> Additionally: Channels are now moving forward and 16.09 users with
> LetsEncrypt should be working after updating your channels and
> rebuilding.
>
> This mail was sent to the nix-dev list as well for the previous two
> issues.
>
> Standard email follows:
>
> The following issues have been resolved in NixOS in release-16.09 and
> unstable. They remain potentially vulnerable on older major
> releases.
>
> These patches will be released to the unstable and
> release-16.09 channels when Hydra finishes building the "tested" job
> for each channel:
>
>  - https://hydra.nixos.org/job/nixos/release-16.09/tested
>  - https://hydra.nixos.org/job/nixos/trunk-combined/tested
>
> Please consider helping with the next security roundup by commenting on
> LATEST_ROUNDUP_URL.
>
> The following changes were applied to release-16.09:
>
> af9b4c6  libtorrentRasterbar_1_0: 1.0.9 -> 1.0.10
> > Fixes potential crash on invalid input to the http parser
> > and a division-by-zero bug in the super seeding logic.
>
> 831571c  keepass: 2.33 -> 2.34
> > Recommended update from upstream. Release notes:
> > http://keepass.info/news/n160611_2.34.html
>
> d3e9fc6  linux:3.12.68 -> 3.12.69
> > All kernel patches are considered security-sensitive.
>
> 6cef2f2  linux:3.18.44 -> 3.18.45
> > All kernel patches are considered security-sensitive.
>
> bd9eba2  zlib: patch for CVE-2016-9840, CVE-2016-9841, CVE-9842, CV..
> > CVE-2016-9840
> > CVE-2016-9841
> > CVE-2016-9842
> > CVE-2016-9843
>
> 4e6223c  pythonPackages.bottle: 0.12.9 -> 0.12.11 for CVE-2016-9964
> > CVE-2016-9964
>
> b5de7ef  xen: patch for many XSAs
> > XSA-190
> > XSA-191
> > XSA-192
> > XSA-193
> > XSA-195
> > XSA-196
> > XSA-198
> > XSA-200
> > XSA_202
> > XSA-204
>
> d3934be  openjpeg2: patch for CVE-2016-9580, and CVE-2016-9581
> > CVE-2016-9580
> > CVE-2016-9581
>
> 142b303  libupnp: 1.6.20 -> 1.6.21 for CVE-2016-8863
> > CVE-2016-8863
>
> 490a23e  nagios: 4.2.3 -> 4.2.4 for CVE-2016-9566
> > CVE-2016-9566
>
> 6c97c1c  tomcatUnstable: 9.0.0.M13 -> 9.0.0.M15 for CVE-2016-9774, ..
> > CVE-2016-9774
> > CVE-2016-9775
>
> 2ab18b7  tomcat85: 8.5.8 -> 8.5.9 for CVE-2016-9774, CVE-2016-9775
> > CVE-2016-9774
> > CVE-2016-9775
>
> 78b5267  game-music-emu: 0.6.0 -> 0.6.1 for multiple CVEs
> > CVE-2016-9957
> > CVE-2016-9958
> > CVE-2016-9959
> > CVE-2016-9960
> > CVE-2016-9961
>
> b2e80a5  samba4: 4.3.11 -> 4.3.13
> > CVE-2016-2123
> > CVE-2016-2125
> > CVE-2016-2126
>
> eaf6fc8  tor: 0.2.8.10 -> 0.2.8.12
> > CVE-2016-1254
>
> b5edcfc  squid: 3.5.19 -> 3.5.23
> > CVE-2016-10002
> > CVE-2016-10003
> ==
>
>
>
> The following changes were applied to unstable:
>
> 3ffb5ba  linux:3.18.44 -> 3.18.45
> > All kernel patches are considered security-sensitive.
>
> 53e2152  linux:3.12.68 -> 3.12.69
> > All kernel patches are considered security-sensitive.
>
> ecc7b33  pythonPackages.bottle: 0.12.9 -> 0.12.11 for CVE-2016-9964
> > CVE-2016-9964
>
> 4e6c7fa  xen: patch for many XSAs
> > XSA-190
> > XSA-191
> > XSA-192
> > XSA-193
> > XSA-195
> > XSA-196
> > XSA-198
> > XSA-200
> > XSA_202
> > XSA-204
>
> c7a2073  openjpeg2: patch for CVE-2016-9580, and CVE-2016-9581
> > CVE-2016-9580
> > CVE-2016-9581
>
> 0d3f0f0  libupnp: 1.6.20 -> 1.6.21 for CVE-2016-8863
> > CVE-2016-8863
>
> 2f17c36  nagios: 4.2.3 -> 4.2.4 for CVE-2016-9566
> > CVE-2016-9566
>
> 72faac9  tomcatUnstable: 9.0.0.M13 -> 9.0.0.M15 for CVE-2016-9774, ..
> > CVE-2016-9774
> > CVE-2016-9775
>
> a528c04  tomcat85: 8.5.8 -> 8.5.9 for CVE-2016-9774, CVE-2016-9775
> > CVE-2016-9774
> > CVE-2016-9775
>
> 2c24ce5  game-music-emu: 0.6.0 -> 0.6.1 for multiple CVEs
> > CVE-2016-9957
> > CVE-2016-9958
> > CVE-2016-9959
> > CVE-2016-9960
> > CVE-2016-9961
>
> 3e92b56  tor: 0.2.8.10 -> 0.2.8.12
> > CVE-2016-1254
>
> 4b67968  squid: 3.5.19 -> 3.5.23
> > CVE-2016-10002
> > CVE-2016-10003
>
> Thank you very much,
> Graham Christensen
> NixOS Security Team
> https://github.com/nixos/security
> ___
> 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-commits] [NixOS/nixpkgs] d6bff3: exim: 4.87 -> 4.87.1 for CVE-2016-9963

2016-12-25 Thread zimbatm
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: d6bff30c96ed675124667dcd500a562234159bc9
  
https://github.com/NixOS/nixpkgs/commit/d6bff30c96ed675124667dcd500a562234159bc9
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2016-12-25 (Sun, 25 Dec 2016)

  Changed paths:
M pkgs/servers/mail/exim/default.nix

  Log Message:
  ---
  exim: 4.87 -> 4.87.1 for CVE-2016-9963


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


[Nix-commits] [NixOS/nixpkgs] 352e16: exim: 4.87 -> 4.88 for CVE-2016-9963

2016-12-25 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 352e167c224e5d98076ca9653d2124c351d969d1
  
https://github.com/NixOS/nixpkgs/commit/352e167c224e5d98076ca9653d2124c351d969d1
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2016-12-25 (Sun, 25 Dec 2016)

  Changed paths:
M pkgs/servers/mail/exim/default.nix

  Log Message:
  ---
  exim: 4.87 -> 4.88 for CVE-2016-9963


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


[Nix-commits] [NixOS/nixpkgs] c38b4d: strongswan: 5.5.0 -> 5.5.1

2016-12-24 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: c38b4da9946b32267301ccf352731ed2d80cc2f6
  
https://github.com/NixOS/nixpkgs/commit/c38b4da9946b32267301ccf352731ed2d80cc2f6
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2016-12-24 (Sat, 24 Dec 2016)

  Changed paths:
M pkgs/tools/networking/strongswan/default.nix

  Log Message:
  ---
  strongswan: 5.5.0 -> 5.5.1


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


Re: [Nix-dev] Holiday Security Patch Schedule, Embargoed Exim Patch on 2016-12-25

2016-12-22 Thread zimbatm
Alright, I got this. I will make the tiny bump on 16.04 and minor bump on
master.
On Thu, 22 Dec 2016, 00:55 Graham Christensen, <gra...@grahamc.com> wrote:

zimbatm <zimb...@zimbatm.com> writes:

> What is the URL to check for the security update? I assume it will be on
> the github issue?

The original posting was here:
http://www.openwall.com/lists/oss-security/2016/12/18/3 and here:
http://www.openwall.com/lists/oss-security/2016/12/21/1 they clarify it
will be released as follows:

> To be more precise: On Dec, 25th, at 10.00 UTC we'll push the changes
> to the public Git repository git://git.exim.org/exim.git and upload
> the tar balls into the FTP area ftp://ftp.exim.org/pub/exim/exim4

Here they get the necessary flak for releasing on Christmas:
http://www.openwall.com/lists/oss-security/2016/12/21/10
and here they defend their decision, and it makes a bit of sense:
http://www.openwall.com/lists/oss-security/2016/12/22/1 ;)

I'm think it is safe to assume that you're "it", Zimbatm! I appreciate
your taking this on.

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


Re: [Nix-dev] Testing Nginx public entry points with NixOps/libvirtd

2016-12-21 Thread zimbatm
Hi,

Your VM needs to be reachable from the internet for letsencrypt to work. If
it's only for internal usage the best thing to do is to provision the
machine with certificates that you generate yourself and add a condition
for production. Alternatively keep it plain HTTP and have a tunnel in
production that does TLS termination.

On Wed, 21 Dec 2016, 11:20 Daniel Hlynskyi,  wrote:

> Hello all NixOps users. I'd like to build my production system with
> libvirtd backend, but I'm stopped with a problem. SSL certificates can't be
> obtained in virtualized environment.
>
> {
>services.nginx.virtualHosts."example.domain" = {
>  enableSSL = true;
>  enableACME = true;
>};
> }
>
> As far as I understand, letsencrypt tries to verify "example.domain", but
> it points to production system, not to virtualized.
>
> What are my options to fix this issue? In the end I'd like to add virtual
> server to VPN and test public entry points from developer machine.
> ___
> 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] Usability: Nixpkg > NixOS

2016-12-19 Thread zimbatm
Hmm okay, I will try to redesign the homepage a bit then. SEO would
recommend not changing the domain either.

On Sat, 17 Dec 2016, 19:48 Nathan Bijnens, <nat...@nathan.gs> wrote:

> Although I agree with having multiple entry points, I would keep only One
> domain. SEO is important these days...
>
> N.
>
> On Sat, Dec 17, 2016, 18:44 zimbatm <zimb...@zimbatm.com> wrote:
>
> I'm impressed at the community response on my borderly trollish email :)
>
> It doesn't look like we can agree on an entry point to the ecosystem as
> everyone here has different opinions. On the other hand, presenting all the
> options upfront is also intimidating to the newcomer.
>
> So maybe the solution is to have multiple landing pages, each catering to
> another subset of the users. Either with multiple domains or by re-thinking
> the current NixOS.org page so it forwards people correctly.
>
> On Fri, 16 Dec 2016, 09:18 Profpatsch, <m...@profpatsch.de> wrote:
>
> On 16-12-15 11:48pm, Judson Lester wrote:
> > First, how derivations become software. I *think* nix-env (or nix-shell,
> or
> > nix-repl) takes the derivation, finds the build script, establishes
> > environment variables and runs the script, but I don't know that I've
> ever
> > seen that in print anywhere.
>
> nix-store --realise
>
> > More nuanced, I've never quite been sure where
> > the appropriate dividing line is between derivation and build script
>
> The whole definition is in the nix manual in the derivation section.
> For specific details you would probably need to read the nix source.
>
> > Second, how do builds get linked into the system? I've seen it happen,
> and
> > again I have suspicions that it has to do with the outputs attribute of
> the
> > derivation, but I remain in the spooky darkness about particulars.
>
> System profiles are just a derivation that is basically a link farm.
> In their /bin they have a bash script that performs the actual switch.
> It basically bootstraps itself.
>
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
> ___
> 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] Holiday Security Patch Schedule, Embargoed Exim Patch on 2016-12-25

2016-12-19 Thread zimbatm
Hey Graham,

Thanks again for doing this.
If nobody else is taking it I can have a go at it.

What is the URL to check for the security update? I assume it will be on
the github issue?

Cheers,
z

On Mon, 19 Dec 2016, 15:07 Graham Christensen,  wrote:

>
> IMPORTANT TLDR: On December 25, an embargoed vulnerability for Exim is
> being released. It would be good for someone _NOT ME_ to patch Nixpkgs
> on that day.
>
> ...
>
> Hello everyone,
>
> This week I will be offline from Thursday through to the following
> Tuesday. (This is why I can't do the Exim patch.)
>
> Close followers of the regular vulnerability roundups know that
> while I start them on Wednesday, they frequently take all of Thursday
> and sometimes some of Friday to finish them. For this reason, I will be
> opening a ticket (roundup #14) today, and working on it each day this
> week until I leave. If you are interested in helping out, please keep an
> eye and know it is coming early.
>
> Thank you,
>
> Graham Christensen
> ___
> 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-commits] [NixOS/nixpkgs] 0c7afc: goaccess: 1.0 -> 1.1.1

2016-12-19 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 0c7afce7dd69a4ca02591b9d505527cec38dfe69
  
https://github.com/NixOS/nixpkgs/commit/0c7afce7dd69a4ca02591b9d505527cec38dfe69
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2016-12-19 (Mon, 19 Dec 2016)

  Changed paths:
M pkgs/tools/misc/goaccess/default.nix

  Log Message:
  ---
  goaccess: 1.0 -> 1.1.1


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


Re: [Nix-dev] Usability: Nixpkg > NixOS

2016-12-17 Thread zimbatm
I'm impressed at the community response on my borderly trollish email :)

It doesn't look like we can agree on an entry point to the ecosystem as
everyone here has different opinions. On the other hand, presenting all the
options upfront is also intimidating to the newcomer.

So maybe the solution is to have multiple landing pages, each catering to
another subset of the users. Either with multiple domains or by re-thinking
the current NixOS.org page so it forwards people correctly.

On Fri, 16 Dec 2016, 09:18 Profpatsch,  wrote:

> On 16-12-15 11:48pm, Judson Lester wrote:
> > First, how derivations become software. I *think* nix-env (or nix-shell,
> or
> > nix-repl) takes the derivation, finds the build script, establishes
> > environment variables and runs the script, but I don't know that I've
> ever
> > seen that in print anywhere.
>
> nix-store --realise
>
> > More nuanced, I've never quite been sure where
> > the appropriate dividing line is between derivation and build script
>
> The whole definition is in the nix manual in the derivation section.
> For specific details you would probably need to read the nix source.
>
> > Second, how do builds get linked into the system? I've seen it happen,
> and
> > again I have suspicions that it has to do with the outputs attribute of
> the
> > derivation, but I remain in the spooky darkness about particulars.
>
> System profiles are just a derivation that is basically a link farm.
> In their /bin they have a bash script that performs the actual switch.
> It basically bootstraps itself.
>
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
> ___
> 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] Usability: Nixpkg > NixOS

2016-12-15 Thread zimbatm
Hi community,

I have been thinking on how to communicate to newcomers and I have come to
the conclusion that "nixpkg" is the best term to talk about our ecosystem
as whole.

The nixos.org website for example starts with NixOS and then the user has
to backtrack to the other parts of the ecosystem. I think it's confusing
and a lot of people don't get that it's more than an operating system. They
are missing on all the goodness about the cross-distro packaging system
capabilities that makes nixpkg appealing.

The other issue is with the term "nix" because it's a common search word.
"*NIX" always comes up, which is the abbreviation used to describe all the
flavors of UNIX. I think it's desirable to get away from that term in our
communication.

Does that make sense? I know that it's easy to get into un-ending semantic
battles but I think it's important to use the right term. Selecting the
right words helps a lot with comprehension. In some sense it's a bit like
go vs golang. "Go" is used in verbal communication and "golang" to help
search.

I bought the nixpkg.com domain just in case and am happy to transfer it to
the nix foundation.

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


[Nix-commits] [NixOS/nixpkgs] 2a224c: fzf: 0.15.1 -> 0.15.9

2016-12-14 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 2a224c6795582068a0cb9936bcb8c34dbce340c6
  
https://github.com/NixOS/nixpkgs/commit/2a224c6795582068a0cb9936bcb8c34dbce340c6
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2016-12-14 (Wed, 14 Dec 2016)

  Changed paths:
M pkgs/tools/misc/fzf/default.nix
M pkgs/tools/misc/fzf/deps.nix

  Log Message:
  ---
  fzf: 0.15.1 -> 0.15.9


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


[Nix-commits] [NixOS/nixpkgs] cbdc94: buildGoPackage: remove go version from name (#2111...

2016-12-13 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: cbdc94f2b7798ac4b2c0f1b564607e64a03996d2
  
https://github.com/NixOS/nixpkgs/commit/cbdc94f2b7798ac4b2c0f1b564607e64a03996d2
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2016-12-13 (Tue, 13 Dec 2016)

  Changed paths:
M pkgs/development/go-modules/generic/default.nix

  Log Message:
  ---
  buildGoPackage: remove go version from name (#2)

As a user installing the program it's not interesting what go version it
was compiled against. Not more interesting than any other potential
dependencies. It also makes it harder to install or update the package.


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


[Nix-commits] [NixOS/nixpkgs] f92816: afl: 2.23b -> 2.35b

2016-12-10 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f9281609aef096cac905cd1081aacc9193ad273f
  
https://github.com/NixOS/nixpkgs/commit/f9281609aef096cac905cd1081aacc9193ad273f
  Author: zimbatm <zimb...@users.noreply.github.com>
  Date:   2016-12-11 (Sun, 11 Dec 2016)

  Changed paths:
M pkgs/tools/security/afl/default.nix

  Log Message:
  ---
  afl: 2.23b -> 2.35b


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


[Nix-commits] [NixOS/nixpkgs] ec7cdd: direnv: 2.9.0 -> 2.10.0

2016-12-10 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: ec7cdd95a7f0b323c11ad3ae054f812607e6d784
  
https://github.com/NixOS/nixpkgs/commit/ec7cdd95a7f0b323c11ad3ae054f812607e6d784
  Author: zimbatm <zimb...@users.noreply.github.com>
  Date:   2016-12-10 (Sat, 10 Dec 2016)

  Changed paths:
M pkgs/tools/misc/direnv/default.nix

  Log Message:
  ---
  direnv: 2.9.0 -> 2.10.0


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


Re: [Nix-dev] List of companies using NixOS

2016-12-08 Thread zimbatm
Thanks, added to the list.

@vladimir: do you know what the Intel guys are using nix for? It would be
great to have them on the list.

On Wed, 7 Dec 2016 at 15:28 Sander van der Burg 
wrote:

> At conference compass (http://conference-compass.com), we're using Hydra
> (e.g. for mobile app builds and internal projects) as well as NixOps +
> Disnix for backend deployment.
>
> On Wed, Dec 7, 2016 at 4:10 PM, Vladimír Čunát  wrote:
>
> There were some companies presenting at NixCon - from the top of my
> head: Intel, some hedge fund (@copumpkin) and surely some I don't
> recall ATM.
>
> --Vladimir
>
> ___
> 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] NixOS Security Team

2016-12-07 Thread zimbatm
+1, thanks for organising this

On Wed, 7 Dec 2016, 08:02 Lancelot SIX,  wrote:

> Big +1 for me for all of the no nominees.
>
> BR
> Lancelot
>
> On 07/12/2016 04:40, Jonn Mostovoy wrote:
> > My 2c: nbp certainly should be nominated ;)
> >
> > Regarding the proposal — it has to happen sooner or later anyway, and
> > if someone is willing to start it now, +1!
> > —
> > Kindest regards,
> > ¬Σ
> >
> >
> > On Wed, Dec 7, 2016 at 2:49 AM, Graham Christensen 
> wrote:
> >> Hello again Nix Users,
> >>
> >> I was talking with Domen the other day on IRC about starting the NixOS
> >> Security Team. We agreed we should run it by the mailing list first and
> >> gets some feedback.
> >>
> >> Members of this team would:
> >>
> >>  - send out security announcements to our new mailing list[0]
> >>  - have their GPG fingerprints on the public website so the
> >>announcements can be verified
> >>  - potentially receive private security disclosures about the Nix
> >>ecosystem
> >>  - (hopefully) help with weekly security roundups and bug fixing
> >>
> >> Long term, they are likely to be initial candidates for when we're
> >> seeking membership to the oss-security's "distros" list[1], and perhaps
> >> more direct involvement in security roadmap issues[2].
> >>
> >> I think it is important that the members of this project have a history
> >> of interest in NixOS's security, and a general history of contributions
> >> to the project.
> >>
> >> I nominate the following people:
> >>
> >>  - myself obviously, Graham Christensen (grahamc)
> >>  - Daniel Peebles (copumpkin)
> >>  - Domen Kožar (domenkozar)
> >>  - Franz Pletz (fpletz)
> >>
> >> For Daniel and Domen, they are both fairly ( ;) ) respectable members of
> >> the community, have a long history of involvement, and both directly
> >> expressed interest on the thread about the "distros" mailing list[1].
> >>
> >> For me, well, I think my initiative, consistency, and history speaks for
> >> itself[6,7]. (I also expressed interest in that same "distros"
> >> thread.[3])
> >>
> >> For Franz, he is an incredibly consistent partner in the security
> >> roundups, and whose efforts I based the roundups process on.
> >>
> >> For Eelco and Rob Vermaas (not listed above,) I don't think they need
> >> nominating, and will be on the team if they want. (I'm assuming they'll
> >> want.)
> >>
> >> I haven't asked Daniel, Domen, or Franz if they would like to be
> >> members, so this is obviously pending their acceptance, and the approval
> >> of the community.
> >>
> >> Daniel, Domen, Franz, and Community: what do you think? A simple "+1"
> >> would be helpful, even if you have no further feedback.
> >>
> >> Eelco, Rob: what do _you_ think?
> >>
> >> Thank you,
> >> Graham Christensen
> >>
> >> 0:
> http://lists.science.uu.nl/pipermail/nix-dev/2016-November/022207.html
> >> 1: https://github.com/NixOS/nixpkgs/issues/14819
> >> 2: https://github.com/NixOS/nixpkgs/issues/14819#issuecomment-212337290
> >> 3: Note that I originally did express interest, but deleted my comments
> >> after [4] because peti was right. See: [5]
> >> 4: https://github.com/NixOS/nixpkgs/issues/14819#issuecomment-212550422
> >> 5: https://github.com/NixOS/nixpkgs/issues/14819#issuecomment-213805937
> >> 6:
> https://github.com/NixOS/nixpkgs/search?q=%22Vulnerability+Roundup%22+author%3Agrahamc=Issues=%E2%9C%93
> >> 7: https://github.com/NixOS/security
> >> ___
> >> 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
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] monitor.nixos.org

2016-12-02 Thread zimbatm
Thanks, makes sense. Let's do this!

On Thu, 1 Dec 2016, 23:39 Rok Garbas,  wrote:

> > Are we always updating to the latest version? For example on a release
> > branch we might want to pin to a major.minor if the project follows
> semver,
> > but maybe on master we always want the latest version.
> >
>
> The maintainer who writes nix expression for the package also decides
> which version update script will follow.
>
> > How do we iterate over all the packages? Do we regularly run all the
> update
> > scripts? Are the updates directly pushed to master or are new PR
> > automatically created?
> >
>
> Initially updates will happen as now, done manually by the
> maintainers. The only this that changes is that maintainers will be
> asked/required to write an update script that and to use that update
> script.
>
> Later we can see how we can hook this script in Hydra/CI, but we first
> need to have some update scripts :)
>
>
> > Let's say the convention is that derivations exposes an "updater"
> passthru.
> > Does it mean that all the derivations need to be updated or can we
> magically
> > support all github projects?
> >
>
> I wouldn't magically support all github projects, but rather provide
> update script one by one. As we go along adding an update which follow
> a branch might look like:
>
> https://github.com/mozilla-releng/services/blob/master/nix/tools/default.nix#L10
>
> > I still think that some of this need to be tried out so we might as well
> > adopt garbas' approach for now but it would be nice to have a clearer
> > picture as well.
> >
>
> The PR I created (https://github.com/NixOS/nixpkgs/pull/20844) leaves
> all the door open for improvement, but brings us just a step closer to
> the future where we could easily manage 1000x more packages then we do
> now.
>
>
>
> -- Rok
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] PatchELF in Bundix's postBuild step

2016-12-01 Thread zimbatm
Yes that's it. There is also a pkgs.defaultGemConfig that contains common
overrides, like injecting libxml for the nokogiri gem. You might want to
merge it with your override (or submit yours to nixpkgs).

On Thu, 1 Dec 2016, 20:51 Maarten Hoogendoorn,  wrote:

> OK, I found a solution after taking a longer look at the bundlerEnv
> implementation.
> Each gem is packaged as a separate derivation (which makes complete sense).
> BundlerEnv offers the `gemConfig', in which one can set another
> postInstall step.
>
> In my case, the following snippet works:
>
> with pkgs; (bundlerEnv {
> name ="ruby-protoc-v3";
> inherit ruby;
> gemfile= ./Gemfile;
> lockfile = ./Gemfile.lock;
> gemset = ./gemset.nix;
> gemConfig = {
>   grpc-tools = attr: {
> postInstall= ''
>   for file in $(find
> $out/lib/ruby/gems/2.3.0/gems/grpc-tools-1.0.1/bin/x86_64-linux -type f
> -executable ); do
> patchelf --set-interpreter
> ${stdenv.glibc}/lib/ld-linux-x86-64.so.2 $file
>   done
> '';
>   };
> };
> })
>
> I think that I got confused by the fact that I did not see any symlinks
> during my investigation. I must have missed that somewhere.
>
> - Maarten
>
> 2016-12-01 21:24 GMT+01:00 Maarten Hoogendoorn :
>
> Hi,
>
> I'm trying to build a gem that has vendored a statically compiled program
> (that still depends on /lib64/ld-linux-x86-64.so.2).
>
> I've tried to use patchelf in the postBuild in a bundlerEnv, but it's
> complaining about not having write permissions to $out
>
> I wrote a one-liner to check for .nix files that contained both the words
> bundlerEnv and patchelf, but only the top-level/all-packages.nix matched
> both.
>
> I tried to create another derivation, that pulls all file in from the
> bundlerEnv, and then patches the elf file, but it's resulting in the same
> error message.
>
> A nix-expression that reproduces this error is attached.
>
>
> ___
> 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] monitor.nixos.org

2016-12-01 Thread zimbatm
Yeah but I'm still wondering how that would work in the context of nixpkgs.

Are we always updating to the latest version? For example on a release
branch we might want to pin to a major.minor if the project follows semver,
but maybe on master we always want the latest version.

How do we iterate over all the packages? Do we regularly run all the update
scripts? Are the updates directly pushed to master or are new PR
automatically created?

Let's say the convention is that derivations exposes an "updater" passthru.
Does it mean that all the derivations need to be updated or can we
magically support all github projects?

I still think that some of this need to be tried out so we might as well
adopt garbas' approach for now but it would be nice to have a clearer
picture as well.

On Thu, 1 Dec 2016, 03:13 Tomasz Czyż, <tomasz.c...@gmail.com> wrote:

> zimbatm: I don't think you need that branch selection thing. All the
> custom logic you want for that package you can put in the update script and
> you can even parametrize it from the outside I assume (update script
> generated by nix expression). That should be enough to do whatever custom
> logic you want.
>
> 2016-11-29 15:05 GMT+00:00 Profpatsch <m...@profpatsch.de>:
>
> On 16-11-28 11:05pm, Rok Garbas wrote:
> > On Mon, Nov 28, 2016 at 9:42 PM, Profpatsch <m...@profpatsch.de> wrote:
> > > Exactly.
> > > And of course the interface of what the script at this point should do.
> >
> > We don't need to define what that update script should do, since a
> > maintainer of that package also makes sure that generated files
> > (json/nix/...) that this update script provides will be read by the
> > package expression.
>
> In order for CI to check for updates there needs to be a standard
> way to call these update scripts. And more than that, a standard
> behaviour of these update scripts. I expect CI to completely sandbox
> them.
> Maybe even go so far as to loosen the “fixed input” rule only a tiny
> bit, meaning the update scripts have to specify exactly what state
> they are going to inspect to find new versions.
>
> > I think Nix has the advantage here actually. A maintainer can write an
> > update script in any language that he is most comfortable with. On the
> > end they have to support it etc... BUT everybody can run the update
> > without knowing that this is a ruby script since ``nix-shell``
> > provides all the needed dependencies for us.
>
> As long as updates always behave the same. And don’t rm -rf your $HOME …
> I’ve had enough untrusted source code run for two lifetimes.
>
> > So on the end we really need to just figure out the name ;) and start
> > writing update scripts. Even if they are full of regex :P
>
> If there is no interface, I’d rather not even have a fix name, or people
> will think updates are specified somehow. Maybe even go the other way
> and reserve the name until someone figures out a nice way to do this.
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
>
>
> --
> Tomasz Czyż
> ___
> 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] hotswappable self managing services in nix

2016-11-28 Thread zimbatm
For process-level graceful restarts see
https://github.com/zimbatm/socketmaster and https://github.com/pusher/crank
. Those could be integrated into the activation script.

On Mon, 28 Nov 2016 at 09:33 zimbatm <zimb...@zimbatm.com> wrote:

> Hi Stewart,
>
> In a HA setup availability is generally achieved on a network level
> instead of system level. Typically you would have two hotswappable
> load-balancers that distribute the traffic to multiple instances of your
> service boxes. In that context is doesn't matter how processes are being
> restarted because the load-balancer will automatically detect unresponsive
> machines and route the traffic accordingly. It's also handy because it
> allows to restart the machines in the event where the kernel needs an
> upgrade. In that setup I suppose you can think of each machine as being one
> Erlang OTP "process" and the network the "message-passing".
>
> One responsibility of the service in that setup is to shutdown properly to
> avoid unnecessary disruption of service. Mainly when the process gets the
> SIGTERM signal it should close the listening socket (so the load-balancer
> can route new incoming connections to a different machine) and then drain
> the existing client connection gracefully. It shouldn't stop all at once
> but let the clients disconnect when they are done with their sessions (and
> optionally signal them to go away if the protocol supports it).
>
> A last thing regarding this approach: generally you need a way to control
> the deploys; if all the service boxes are being upgraded at the same time
> then the load-balancer doesn't have anywhere to route the traffic to. It's
> also something desirable to have to do blue/green deployments.
>
> I need to stop there for now but I also have a similar design answer on
> the system level where processes get replaced gracefully.
>
> Cheers,
> z
>
> On Sun, 27 Nov 2016 at 04:33 stewart mackenzie <setor...@gmail.com> wrote:
>
> 9 9s not unheard of in these circles, Google uptimes are a joke not worthy
> of mention.
>
> There are systems that have been running for some 40 odd years in
> production that factor in changes to legal banking regulations, hardware,
> business logic etc. Erlang has a system called the Ericsson AXD301 which
> has achieved this time frame.
>
> Just because Nixos hasn't been around that long doesn't mean it can't have
> the primitives to allow for such feats. Its these primitives I'm enquiring
> about.
>
> So let's use a new, less controversial figure of 5 9s and keep on topic.
>
> The thing is, we're designing this system so that its governed by nix
> don't necessarily have to depend heavily on the runtime - I really don't
> want to go down the imperative route, by introducing imperative language
> concepts into our declarative language which is managed by another
> declarative language (nix). Besides just bringing in a single component
> with an OS Dependency demands we manage this change from nix level.
>
> We currently have a hack in place, that will resolve dependencies and give
> us a path to load a correctly compiled shared object into memory:
> https://github.com/fractalide/fractalide/blob/master/components/nucleus/find/component/src/lib.rs#L43
> nasty and cringe worthy I know.
>
> Thanks for your pointer, I'll take a look at these activation scripts.
>
> Maybe this hack is the answer, and confine the dynamism to an ssh login al
> a Erlang style...
> ___
> 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] List of companies using NixOS

2016-11-27 Thread zimbatm
Thanks, added to the list. At some point I would like to make a survey to
find out where the ecosystem could be improved.

On Sun, 27 Nov 2016 at 12:57 Prime.vc | Danny Wilson <da...@prime.vc> wrote:

> We use and code Nix, Disnix and NixOS at Prime.vc
>
>
> On 20 Nov 2016, at 19:55, zimbatm <zimb...@zimbatm.com> wrote:
>
> Hi all,
>
> I am collecting a list of companies that are using NixOS. The idea is to
> encourage adoption by validation.
>
> The list is over here:
>
> https://www.reddit.com/r/NixOS/comments/5dz8fp/list_of_companies_using_nixos/
>
> If you don't feel like posting on Reddit just post here and I'll add them
> over there.
>
> Cheers,
> z
>
> ___
> 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] cleaning up old configurations

2016-11-21 Thread zimbatm
Yes this one is quite confusing. The grub list is generated on activation
of a new profile. Try re-running `nixos-rebuild switch`. It might work to
just run /run/current-system/activate



On Mon, 21 Nov 2016 at 09:11 Henning Thielemann <
lemm...@henning-thielemann.de> wrote:

>
> Another beginners question ...
>
> I am confused: The NixOS boot menu shows a list of 17 configurations. I
> want to remove some of them in order to free some space on the NixOS
> partition. I try
>
> $ sudo nix-env --list-generations
>12   2015-08-30 11:20:39
>19   2015-12-22 11:50:11
>20   2016-07-15 15:52:44
>21   2016-11-20 13:09:56
>22   2016-11-20 13:10:06   (current)
>
> in order to obtain the numbers for --delete-generations. However, it seems
> that the listed "generations" are something different from the
> "configurations" in the boot menu. How can I list and delete some of those
> configurations from the boot menu?
>
>
> Btw. I think after upgrading NixOS it is a natural desire to get rid of
> some old versions. What about adding a pointer to
>http://nixos.org/nixos/manual/index.html#sec-upgrading
> ?
> ___
> 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] Multiple ssh substituter hosts

2016-11-21 Thread zimbatm
Yes that's it. S3 should be useable as binary cache out of the box unless
authentication is required. In that case a proxy is required to transform
S3 signatures into basic or network based authorisation.

Within AWS, the VPC endpoint feature might be useful. I haven't tried it
yet and don't know if it's possible to avoid the signatures that way.
https://aws.amazon.com/blogs/aws/new-vpc-endpoint-for-amazon-s3/ .

On Mon, 21 Nov 2016, 01:50 Bas van Dijk, <v.dijk@gmail.com> wrote:

> This seems to cover the first part about pushing nars from hydra to s3:
>
>
> https://github.com/NixOS/hydra/pull/118/commits/7c000713370bbb896e127503e8b0276c65eb76ae
>
> Now I just need to configure my private s3 bucket as a binary cache.
> Anyone know how to set that up?
>
> On 21 November 2016 at 02:18, Bas van Dijk <v.dijk@gmail.com> wrote:
>
> That seems like a good idea.
>
> Ideally my hydra service would upload the nars it builds to a private s3
> bucket. Then my machines need to use this private s3 bucket as a binary
> cache.
>
> Is there any documentation on how to do this?
>
> On 20 November 2016 at 22:34, zimbatm <zimb...@zimbatm.com> wrote:
>
> It's probably expensive to open all the ssh connections. Depending on your
> use-case you might be better off uploading all the binaries to a single
> destination like S3.
>
> On Sun, 20 Nov 2016 at 20:16 Bas van Dijk <v.dijk@gmail.com> wrote:
>
> I see. Thanks for pointing me to the source.
>
> I also see that supporting more hosts is listed as a TODO:
>
>
> https://github.com/NixOS/nix/blob/master/src/download-via-ssh/download-via-ssh.cc#L18
>
> Hopefully that gets implemented some day!
>
> Cheers,
>
> Bas
>
> On 20 November 2016 at 20:13, zimbatm <zimb...@zimbatm.com> wrote:
>
> Hi Bas,
>
> It looks like it's only taking the first host from the list[1]. I suppose
> the intention was to provide fallbacks but it didn't get implemented.
>
> [1]:
> https://github.com/NixOS/nix/blob/master/src/download-via-ssh/download-via-ssh.cc#L114
>
>
> On Sun, 20 Nov 2016 at 15:49 Bas van Dijk <v.dijk@gmail.com> wrote:
>
> Dear all,
>
> Is it possible to have multiple ssh-substituter-hosts, as in:
>
>   ssh-substituter-hosts = nix-ssh@host1 nix-ssh@host2
>
> The documentation[1] is not entirely clear on that.
>
> Bas
>
> [1] http://nixos.org/nix/manual/#ssec-ssh-substituter
> ___
> 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] Multiple ssh substituter hosts

2016-11-20 Thread zimbatm
It's probably expensive to open all the ssh connections. Depending on your
use-case you might be better off uploading all the binaries to a single
destination like S3.

On Sun, 20 Nov 2016 at 20:16 Bas van Dijk <v.dijk@gmail.com> wrote:

I see. Thanks for pointing me to the source.

I also see that supporting more hosts is listed as a TODO:


https://github.com/NixOS/nix/blob/master/src/download-via-ssh/download-via-ssh.cc#L18

Hopefully that gets implemented some day!

Cheers,

Bas

On 20 November 2016 at 20:13, zimbatm <zimb...@zimbatm.com> wrote:

Hi Bas,

It looks like it's only taking the first host from the list[1]. I suppose
the intention was to provide fallbacks but it didn't get implemented.

[1]:
https://github.com/NixOS/nix/blob/master/src/download-via-ssh/download-via-ssh.cc#L114


On Sun, 20 Nov 2016 at 15:49 Bas van Dijk <v.dijk@gmail.com> wrote:

Dear all,

Is it possible to have multiple ssh-substituter-hosts, as in:

  ssh-substituter-hosts = nix-ssh@host1 nix-ssh@host2

The documentation[1] is not entirely clear on that.

Bas

[1] http://nixos.org/nix/manual/#ssec-ssh-substituter
___
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] Multiple ssh substituter hosts

2016-11-20 Thread zimbatm
Hi Bas,

It looks like it's only taking the first host from the list[1]. I suppose
the intention was to provide fallbacks but it didn't get implemented.

[1]:
https://github.com/NixOS/nix/blob/master/src/download-via-ssh/download-via-ssh.cc#L114


On Sun, 20 Nov 2016 at 15:49 Bas van Dijk  wrote:

> Dear all,
>
> Is it possible to have multiple ssh-substituter-hosts, as in:
>
>   ssh-substituter-hosts = nix-ssh@host1 nix-ssh@host2
>
> The documentation[1] is not entirely clear on that.
>
> Bas
>
> [1] http://nixos.org/nix/manual/#ssec-ssh-substituter
> ___
> 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] List of companies using NixOS

2016-11-20 Thread zimbatm
Hi all,

I am collecting a list of companies that are using NixOS. The idea is to
encourage adoption by validation.

The list is over here:
https://www.reddit.com/r/NixOS/comments/5dz8fp/list_of_companies_using_nixos/

If you don't feel like posting on Reddit just post here and I'll add them
over there.

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


[Nix-commits] [NixOS/nixpkgs] a60a58: terraform: 0.7.10 -> 0.7.11

2016-11-16 Thread zimbatm
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: a60a584cb6ebcc9da2ae74e672dd537117849f10
  
https://github.com/NixOS/nixpkgs/commit/a60a584cb6ebcc9da2ae74e672dd537117849f10
  Author: zimbatm <zimb...@zimbatm.com>
  Date:   2016-11-16 (Wed, 16 Nov 2016)

  Changed paths:
M pkgs/applications/networking/cluster/terraform/default.nix

  Log Message:
  ---
  terraform: 0.7.10 -> 0.7.11


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


[Nix-dev] Moving zimbatm/nixbox to NixOS/nixbox

2016-11-05 Thread zimbatm
Hi all,

I would like to move https://github.com/zimbatm/nixbox/ to the nixos org. I
am depending on https://atlas.hashicorp.org/ to build and distribute the
vagrant boxes. They are a paying service but willing to make an exception
if I move the project to the NixOS org, probably because it has a higher
visibility.

Alternatively I could also extend nixpkgs to produce vagrant boxes but it
doesn't tie as well with the whole atlas ecosystem and I would have to
learn how vagrant boxes are being built internally.

@eelco @domen: I added you on the repo so you can move it.

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


  1   2   3   4   5   >