[Nix-commits] [NixOS/nixpkgs] 96dfd0: groonga: 6.1.0 -> 6.1.1

2016-11-28 Thread Frederik Rietdijk
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 96dfd01966cc0af2abc1a4c2246a9659dd9fb133
  
https://github.com/NixOS/nixpkgs/commit/96dfd01966cc0af2abc1a4c2246a9659dd9fb133
  Author: Eric Sagnes 
  Date:   2016-11-29 (Tue, 29 Nov 2016)

  Changed paths:
M pkgs/servers/search/groonga/default.nix

  Log Message:
  ---
  groonga: 6.1.0 -> 6.1.1

release notes: http://groonga.org/en/blog/2016/11/29/groonga-6.1.1.html


  Commit: 09aabb6750a9ca7dfe823b4f4f223773c7d44334
  
https://github.com/NixOS/nixpkgs/commit/09aabb6750a9ca7dfe823b4f4f223773c7d44334
  Author: Frederik Rietdijk 
  Date:   2016-11-29 (Tue, 29 Nov 2016)

  Changed paths:
M pkgs/servers/search/groonga/default.nix

  Log Message:
  ---
  Merge pull request #20785 from ericsagnes/pkg-update/groonga

groonga: 6.1.0 -> 6.1.1


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


[Nix-commits] [NixOS/nixpkgs] 1ac1d9: atom: 1.12.5 -> 1.12.6

2016-11-28 Thread Frederik Rietdijk
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 1ac1d934272bda06f93d30ae3481fe39a269c5d5
  
https://github.com/NixOS/nixpkgs/commit/1ac1d934272bda06f93d30ae3481fe39a269c5d5
  Author: Tim Steinbach 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/applications/editors/atom/default.nix

  Log Message:
  ---
  atom: 1.12.5 -> 1.12.6


  Commit: a344b552adbae5e54753178d5713bb60adefdc86
  
https://github.com/NixOS/nixpkgs/commit/a344b552adbae5e54753178d5713bb60adefdc86
  Author: Frederik Rietdijk 
  Date:   2016-11-29 (Tue, 29 Nov 2016)

  Changed paths:
M pkgs/applications/editors/atom/default.nix

  Log Message:
  ---
  Merge pull request #20778 from NeQuissimus/atom_1_12_6

atom: 1.12.5 -> 1.12.6


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


[Nix-commits] [NixOS/nixpkgs] 66fb5a: puddletag: 1.1.1 -> 1.2.0

2016-11-28 Thread Frederik Rietdijk
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 66fb5ac222767f8650c3ea3e4de1dc81c44bb3fd
  
https://github.com/NixOS/nixpkgs/commit/66fb5ac222767f8650c3ea3e4de1dc81c44bb3fd
  Author: Peter Hoeg 
  Date:   2016-11-29 (Tue, 29 Nov 2016)

  Changed paths:
M pkgs/applications/audio/puddletag/default.nix

  Log Message:
  ---
  puddletag: 1.1.1 -> 1.2.0


  Commit: a1b7c943775c6de40f57aa1494087a00a1f426f7
  
https://github.com/NixOS/nixpkgs/commit/a1b7c943775c6de40f57aa1494087a00a1f426f7
  Author: Frederik Rietdijk 
  Date:   2016-11-29 (Tue, 29 Nov 2016)

  Changed paths:
M pkgs/applications/audio/puddletag/default.nix

  Log Message:
  ---
  Merge pull request #20784 from peterhoeg/u/puddletag

puddletag: 1.1.1 -> 1.2.0


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


Re: [Nix-dev] split current and old profile builds

2016-11-28 Thread James Cook
On 28 November 2016 at 20:13, Stefan Huchler  wrote:
> I was so cracy that I installed nixos on a 16gb chromebook. which makes
> every update now very hard, because of space problems.
>
> So well then I thought I have this 64gb sd(hx?) card lets just move the
> whole /nix/store there. But when I run a hdparm -tT performance test I
> got I think 17mb/s vs 170mb/s read results sdcard vs internal flash.
>
> So I would prefer to not slow my complete system down by putting it
> completly on the sdcard, but I would like to have some history to revert
> back to something.
>
> Is there a way to keep only the packages form the current profile on the
> internal flash and move old stuff to the sdcard?
>
> Or should I use some sort of raid (btrfs maybe) to spread the files over
> both devises.
>
> I also thought about putting all on the sdcard but have a very big swap
> file on the internal flash. But I think the System dont has to swap much
> on my setup. so the first read would be where it counts.
>
> Or maybe just install for the user the packages he needs most under his
> user profile, like the browser which I restart very often.
>
> Is there some nixos-way to do that?
>
> Or any suggestions would be nice.
>
> Thanks

Have you looked into SSD caching? I have not tried it myself, but
something like dm-cache might be what you're looking for.

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


[Nix-dev] split current and old profile builds

2016-11-28 Thread Stefan Huchler
I was so cracy that I installed nixos on a 16gb chromebook. which makes
every update now very hard, because of space problems.

So well then I thought I have this 64gb sd(hx?) card lets just move the
whole /nix/store there. But when I run a hdparm -tT performance test I
got I think 17mb/s vs 170mb/s read results sdcard vs internal flash.

So I would prefer to not slow my complete system down by putting it
completly on the sdcard, but I would like to have some history to revert
back to something.

Is there a way to keep only the packages form the current profile on the
internal flash and move old stuff to the sdcard?

Or should I use some sort of raid (btrfs maybe) to spread the files over
both devises.

I also thought about putting all on the sdcard but have a very big swap
file on the internal flash. But I think the System dont has to swap much
on my setup. so the first read would be where it counts.

Or maybe just install for the user the packages he needs most under his
user profile, like the browser which I restart very often.

Is there some nixos-way to do that?

Or any suggestions would be nice.

Thanks

___
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-11-28 Thread zimbatm
Do we need a way to select the revision or branch maybe? I'm just thinking
of the interface that the script should have. Otherwise I would agree with
Garbas overall. Over time I would expect some sort of convention to
establish itself but we don't need to do it straight away.

On Mon, 28 Nov 2016 at 22:06 Rok Garbas  wrote:

> On Mon, Nov 28, 2016 at 9:42 PM, Profpatsch  wrote:
> > On 16-11-28 03:11pm, Rok Garbas wrote:
> >> On Mon, Nov 28, 2016 at 2:37 PM, Bjørn Forsman 
> wrote:
> >> To start this we _only_ need to agree how we call this passthru
> >> attribute :) ... update, updateSrc, refresh, refreshSrc, nextVersion,
> >> ...
> >
> > Exactly.
> > And of course the interface of what the script at this point should do.
> >
> > I’m not sure how to apply the changes to the source files in a sane way.
> > No, regex replacement is definitely *not* a sane way.
> > To be fair, the lisp guys have an advantage of about half a century
> > with source code modification.
> >
>
> 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.
>
> Now even if update script does some weird regex etc... and fails also
> the build afterwards will fail and we don't merge the updated files.
>
> 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.
>
> here are two examples:
>  - update script stores a json and that json is passed to fetchFromGitHub
>
> https://github.com/mozilla-releng/services/blob/master/nix/tools/default.nix#L66
>  - update script generated nix files (pypi2nix, go2nix, cabal2nix, ...)
>
> https://github.com/mozilla-releng/services/blob/master/nix/tools/default.nix#L18
>
> and this is the main entry script which i use to run multiple update
> commands
> https://github.com/mozilla-releng/services/blob/master/nix/update.nix
>  - to run update on one package ->nix-shell nix/update.nix --argstr
> pkg releng_docs
>  - to run updates on all packages -> nix-shell nix/update.nix
>
> 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
>
>
> --
> Rok Garbas
> ___
> 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] 7fc197: nagios: 4.0.8 -> 4.2.3

2016-11-28 Thread Lancelot SIX
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 7fc197fa9100a5559da5ff949772374ed89a4c1f
  
https://github.com/NixOS/nixpkgs/commit/7fc197fa9100a5559da5ff949772374ed89a4c1f
  Author: Lancelot SIX 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/servers/monitoring/nagios/default.nix

  Log Message:
  ---
  nagios: 4.0.8 -> 4.2.3

This update includes many security related fixes.

Version 4.2.0 fixes:
- CVE-2008-4796
- CVE-2013-4214

Version 4.2.2 fixes:
- CVE-2016-9565

Version 4.2.3 fixes:
- CVE-2016-8641

See https://www.nagios.org/projects/nagios-core/history/4x/ for full
detail changes.

(cherry picked from commit 5b6d52b4fb7378740d3c2e7017326a5d0f68711e)


  Commit: a9523ed9c1b091466929e9651db07ff78cf188b8
  
https://github.com/NixOS/nixpkgs/commit/a9523ed9c1b091466929e9651db07ff78cf188b8
  Author: Lancelot SIX 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/servers/monitoring/nagios/plugins/official-2.x.nix

  Log Message:
  ---
  nagiosPluginsOfficial: 2.0.3 -> 2.1.4

See https://github.com/nagios-plugins/nagios-plugins/blob/master/NEWS
for release history

(cherry picked from commit c77011c6decc989d11eef7dcbd37625c980f0790)


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


[Nix-commits] [NixOS/nixpkgs] 5b6d52: nagios: 4.0.8 -> 4.2.3

2016-11-28 Thread Graham Christensen
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 5b6d52b4fb7378740d3c2e7017326a5d0f68711e
  
https://github.com/NixOS/nixpkgs/commit/5b6d52b4fb7378740d3c2e7017326a5d0f68711e
  Author: Lancelot SIX 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/servers/monitoring/nagios/default.nix

  Log Message:
  ---
  nagios: 4.0.8 -> 4.2.3

This update includes many security related fixes.

Version 4.2.0 fixes:
- CVE-2008-4796
- CVE-2013-4214

Version 4.2.2 fixes:
- CVE-2016-9565

Version 4.2.3 fixes:
- CVE-2016-8641

See https://www.nagios.org/projects/nagios-core/history/4x/ for full
detail changes.


  Commit: c77011c6decc989d11eef7dcbd37625c980f0790
  
https://github.com/NixOS/nixpkgs/commit/c77011c6decc989d11eef7dcbd37625c980f0790
  Author: Lancelot SIX 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/servers/monitoring/nagios/plugins/official-2.x.nix

  Log Message:
  ---
  nagiosPluginsOfficial: 2.0.3 -> 2.1.4

See https://github.com/nagios-plugins/nagios-plugins/blob/master/NEWS
for release history


  Commit: 59695de3b17aecaea076b20030ee686929a737df
  
https://github.com/NixOS/nixpkgs/commit/59695de3b17aecaea076b20030ee686929a737df
  Author: Graham Christensen 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/servers/monitoring/nagios/default.nix
M pkgs/servers/monitoring/nagios/plugins/official-2.x.nix

  Log Message:
  ---
  Merge pull request #20763 from lsix/update_nagios

nagios: 4.0.8 -> 4.2.3 (for CVE)


Compare: https://github.com/NixOS/nixpkgs/compare/105255e6f5c6...59695de3b17a___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


[Nix-commits] [NixOS/nixpkgs] f390d6: yarp: 2.3.66.1 -> 2.3.68

2016-11-28 Thread Graham Christensen
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f390d68b7532eecea4856a9e0814697489a0ca2b
  
https://github.com/NixOS/nixpkgs/commit/f390d68b7532eecea4856a9e0814697489a0ca2b
  Author: Nicolò Balzarotti 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/applications/science/robotics/yarp/default.nix

  Log Message:
  ---
  yarp: 2.3.66.1 -> 2.3.68


  Commit: 105255e6f5c6854ee9629ff1274f19711806399a
  
https://github.com/NixOS/nixpkgs/commit/105255e6f5c6854ee9629ff1274f19711806399a
  Author: Graham Christensen 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/applications/science/robotics/yarp/default.nix

  Log Message:
  ---
  Merge pull request #20772 from nico202/yarp

yarp: 2.3.66.1 -> 2.3.68


Compare: https://github.com/NixOS/nixpkgs/compare/076e3ae32cb4...105255e6f5c6___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


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

2016-11-28 Thread Rok Garbas
On Mon, Nov 28, 2016 at 9:42 PM, Profpatsch  wrote:
> On 16-11-28 03:11pm, Rok Garbas wrote:
>> On Mon, Nov 28, 2016 at 2:37 PM, Bjørn Forsman  
>> wrote:
>> To start this we _only_ need to agree how we call this passthru
>> attribute :) ... update, updateSrc, refresh, refreshSrc, nextVersion,
>> ...
>
> Exactly.
> And of course the interface of what the script at this point should do.
>
> I’m not sure how to apply the changes to the source files in a sane way.
> No, regex replacement is definitely *not* a sane way.
> To be fair, the lisp guys have an advantage of about half a century
> with source code modification.
>

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.

Now even if update script does some weird regex etc... and fails also
the build afterwards will fail and we don't merge the updated files.

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.

here are two examples:
 - update script stores a json and that json is passed to fetchFromGitHub
   
https://github.com/mozilla-releng/services/blob/master/nix/tools/default.nix#L66
 - update script generated nix files (pypi2nix, go2nix, cabal2nix, ...)
   
https://github.com/mozilla-releng/services/blob/master/nix/tools/default.nix#L18

and this is the main entry script which i use to run multiple update commands
https://github.com/mozilla-releng/services/blob/master/nix/update.nix
 - to run update on one package ->nix-shell nix/update.nix --argstr
pkg releng_docs
 - to run updates on all packages -> nix-shell nix/update.nix

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


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


[Nix-commits] [NixOS/nixpkgs] 37cad0: e2fsprogs: 1.42.13 -> 1.43.3

2016-11-28 Thread obadz
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 37cad0b90efccf2996bbf514d1a8688f91108987
  
https://github.com/NixOS/nixpkgs/commit/37cad0b90efccf2996bbf514d1a8688f91108987
  Author: obadz 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/tools/filesystems/e2fsprogs/default.nix

  Log Message:
  ---
  e2fsprogs: 1.42.13 -> 1.43.3

(cherry picked from commit 83fe4fa0bfed7d402732a6c31817daefaaed8e64)


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


[Nix-commits] [NixOS/nixpkgs] b833b1: haskellPackages.ReadArgs: jailbreak to fix build

2016-11-28 Thread Pascal Wittmann
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b833b10f81bee30c634802afbe06d9d0630c2709
  
https://github.com/NixOS/nixpkgs/commit/b833b10f81bee30c634802afbe06d9d0630c2709
  Author: Pascal Wittmann 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/haskell-modules/configuration-common.nix

  Log Message:
  ---
  haskellPackages.ReadArgs: jailbreak to fix build

fixes #20515

(cherry picked from commit 7c29887e57adde305166df4a3d569af07fd49b50)


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


[Nix-commits] [NixOS/nixpkgs] 258761: mesa: maintenance 13.0.1 -> 13.0.2

2016-11-28 Thread Vladimír Čunát
  Branch: refs/heads/staging
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 2587611ed5916e8fad810a4a2038e12ed85337c0
  
https://github.com/NixOS/nixpkgs/commit/2587611ed5916e8fad810a4a2038e12ed85337c0
  Author: Vladimír Čunát 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/libraries/mesa/default.nix

  Log Message:
  ---
  mesa: maintenance 13.0.1 -> 13.0.2


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


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

2016-11-28 Thread Profpatsch
On 16-11-28 03:11pm, Rok Garbas wrote:
> On Mon, Nov 28, 2016 at 2:37 PM, Bjørn Forsman  
> wrote:
> To start this we _only_ need to agree how we call this passthru
> attribute :) ... update, updateSrc, refresh, refreshSrc, nextVersion,
> ...

Exactly.
And of course the interface of what the script at this point should do.

I’m not sure how to apply the changes to the source files in a sane way.
No, regex replacement is definitely *not* a sane way.
To be fair, the lisp guys have an advantage of about half a century
with source code modification.

> Anyway I'm currently managing many projects like this which would be
> impossible to do if i wouldn't automate this.

Exactly.

-- 
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


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

2016-11-28 Thread Profpatsch
On 16-11-28 05:04pm, phree...@yandex.ru wrote:
> On Monday, November 28, 2016 13:32:16 Tomasz Czyż wrote:
> > 2016-11-28 13:18 GMT+00:00 Profpatsch :
> > debian has such a strategy:
> > - https://wiki.debian.org/debian/watch
> 
> That happens to not work all that well:
> https://github.com/Phreedom/nixpkgs-monitor/blob/master/debian-watchfiles/watchfiles.md
> 
> It turns out that debian watchfiles were much less reliable at getting 
> updates 
> from SourceForge, than a generic SourceForge updater. This is because naming 
> schemes change, devs forget to update the updater script and lots of other 
> tiny but important reasons.

Since we have a unified packageset written in a turing-complete language
we can do a lot better. e.g. lib.updaters.updateSourceForge

-- 
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


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

2016-11-28 Thread Profpatsch
On 16-11-28 01:32pm, Tomasz Czyż wrote:
> debian has such a strategy:
> - https://wiki.debian.org/debian/watch
> -
> https://github.com/FedericoCeratto/debian-package-init/blob/master/deb_create_watch.py
> 
> I think better place to execute this would be in CI pipeline, when you can
> decide if after upgrading the package you are still able to build the
> project.

Yes, of course it would have to be integrated in the CI pipeline.

> Also, I'm not sure if automatic upgrades would be that great without manual
> verification. There are cases when packages have no signatures and somebody
> switched the code on the website (this happens from time to time).

Depends. In combination with working acceptance/integration tests
this could be completely automated, save for the maintainer clicking
merge. I have a working testing infrastructure in the pipeline,
once I push it the basic building blocks will be in place.

> Also I had an idea that would be nice to integrate this update command into
> "meta" of derivation. What do you think?

The point is defining an interface that CI can then use to provide
automation. That is mainly defining an attribute and what success
and failure mean.

Basic idea:
meta.update (or maybe just passthru.update, not sure yet) is a
shell script that returns 0 on success and prints an attributeset
to stdout that can be merged with the source somehow. On failure
various exit codes are defined, like 1=no_change 2=not_found e.g.

Next problem: Automatic application would require basic nix expr
source introspection (as long as it’s not tried with regex)

-- 
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-commits] [NixOS/nixpkgs] f27c78: Add us-east-2 region to AMI creation script

2016-11-28 Thread Rob Vermaas
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f27c78f75ef04bde2260137c48f5983717e61d8c
  
https://github.com/NixOS/nixpkgs/commit/f27c78f75ef04bde2260137c48f5983717e61d8c
  Author: Rob Vermaas 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M nixos/maintainers/scripts/ec2/create-amis.sh

  Log Message:
  ---
  Add us-east-2 region to AMI creation script


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


[Nix-commits] [NixOS/nixpkgs] 076e3a: gitRepo: 1.22 -> 1.23

2016-11-28 Thread Graham Christensen
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 076e3ae32cb40b590a50bffdcf1ee5da85bfabe9
  
https://github.com/NixOS/nixpkgs/commit/076e3ae32cb40b590a50bffdcf1ee5da85bfabe9
  Author: Graham Christensen 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/applications/version-management/git-repo/default.nix

  Log Message:
  ---
  gitRepo: 1.22 -> 1.23


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


[Nix-commits] [NixOS/nixpkgs] f0bdca: linuxPackages.ati_drivers_x11: patch for kernel 4....

2016-11-28 Thread Matt McHenry
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f0bdca82c0ce446c827f9f4b10381e558f0a9c31
  
https://github.com/NixOS/nixpkgs/commit/f0bdca82c0ce446c827f9f4b10381e558f0a9c31
  Author: Matt McHenry 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/os-specific/linux/ati-drivers/default.nix
A pkgs/os-specific/linux/ati-drivers/patches/4.7-arch-cpu_has_pge-v2.patch

  Log Message:
  ---
  linuxPackages.ati_drivers_x11: patch for kernel 4.7+ (#19810)


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


[Nix-commits] [NixOS/nixpkgs] 539356: llvmPackages*.lldb: fixup input by disabling libed...

2016-11-28 Thread Vladimír Čunát
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 539356f319a22e485f4b6602546e70b46d5ea640
  
https://github.com/NixOS/nixpkgs/commit/539356f319a22e485f4b6602546e70b46d5ea640
  Author: Vladimír Čunát 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/compilers/llvm/3.4/lldb.nix
M pkgs/development/compilers/llvm/3.5/lldb.nix
M pkgs/development/compilers/llvm/3.6/lldb.nix
M pkgs/development/compilers/llvm/3.7/lldb.nix
M pkgs/development/compilers/llvm/3.8/lldb.nix
M pkgs/development/compilers/llvm/3.9/lldb.nix

  Log Message:
  ---
  llvmPackages*.lldb: fixup input by disabling libedit

Fixes #20773.  https://llvm.org/bugs/show_bug.cgi?id=28898
Of course, feel free to find a better solution.

I love this copy&paste :-/

(cherry picked from commit b67ae8b33c38b442a7d0f4bed0e68a8cd85e22bb)


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


[Nix-commits] [NixOS/nixpkgs] 5f7953: lxc: 2.0.4 -> 2.0.6

2016-11-28 Thread Franz Pletz
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 5f79536ebe6b9d2754626774564a76f4dfe5c928
  
https://github.com/NixOS/nixpkgs/commit/5f79536ebe6b9d2754626774564a76f4dfe5c928
  Author: Franz Pletz 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/os-specific/linux/lxc/default.nix

  Log Message:
  ---
  lxc: 2.0.4 -> 2.0.6

Fixes CVE-2016-8649.

See 
https://lists.linuxcontainers.org/pipermail/lxc-users/2016-November/012597.html.

(cherry picked from commit 5d804566dfecaa3928893244399b86453edcacb3)


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


[Nix-commits] [NixOS/nixpkgs] 5d8045: lxc: 2.0.4 -> 2.0.6

2016-11-28 Thread Franz Pletz
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 5d804566dfecaa3928893244399b86453edcacb3
  
https://github.com/NixOS/nixpkgs/commit/5d804566dfecaa3928893244399b86453edcacb3
  Author: Franz Pletz 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/os-specific/linux/lxc/default.nix

  Log Message:
  ---
  lxc: 2.0.4 -> 2.0.6

Fixes CVE-2016-8649.

See 
https://lists.linuxcontainers.org/pipermail/lxc-users/2016-November/012597.html.


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


[Nix-commits] [NixOS/nixpkgs] b67ae8: llvmPackages*.lldb: fixup input by disabling libed...

2016-11-28 Thread Vladimír Čunát
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b67ae8b33c38b442a7d0f4bed0e68a8cd85e22bb
  
https://github.com/NixOS/nixpkgs/commit/b67ae8b33c38b442a7d0f4bed0e68a8cd85e22bb
  Author: Vladimír Čunát 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/compilers/llvm/3.4/lldb.nix
M pkgs/development/compilers/llvm/3.5/lldb.nix
M pkgs/development/compilers/llvm/3.6/lldb.nix
M pkgs/development/compilers/llvm/3.7/lldb.nix
M pkgs/development/compilers/llvm/3.8/lldb.nix
M pkgs/development/compilers/llvm/3.9/lldb.nix

  Log Message:
  ---
  llvmPackages*.lldb: fixup input by disabling libedit

Fixes #20773.  https://llvm.org/bugs/show_bug.cgi?id=28898
Of course, feel free to find a better solution.

I love this copy&paste :-/


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


[Nix-commits] [NixOS/nixpkgs] 462685: matplotlib: fix tk backend on python3

2016-11-28 Thread Frederik Rietdijk
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 4626857229f241b06742d3707c913c321a60973d
  
https://github.com/NixOS/nixpkgs/commit/4626857229f241b06742d3707c913c321a60973d
  Author: Frederik Rietdijk 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

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

  Log Message:
  ---
  matplotlib: fix tk backend on python3


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


Re: [Nix-dev] hotswappable self managing services in nix

2016-11-28 Thread Игорь Пашев
2016-11-27 4:53 GMT+03:00 stewart mackenzie :
> Now say my service code is smart enough to do hot swapping of
> components al a Erlang style. Is it possible to tell nix not to
> restart the service but instead give the running executable a long
> string and let the executable be responsible for making changes to
> it's environment in a declarative manner?


Sure, why not. You start a dumb service which is unlikely to change.
This service read/watch some file or directory.

Then you have another service which put the file or directory in place.
This service restarts on each update and "notifies" the first service.

This approach works, for example, with mysql or postgres: updating
users or some dynamic options.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-commits] [NixOS/nixpkgs] 441777: matplotlib: Fix "attribute ‘tkinter’ missing"

2016-11-28 Thread Frederik Rietdijk
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 44177794d253ea189e9aa9cde102085e76034f81
  
https://github.com/NixOS/nixpkgs/commit/44177794d253ea189e9aa9cde102085e76034f81
  Author: Andreas Herrmann 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/python-modules/matplotlib/default.nix

  Log Message:
  ---
  matplotlib: Fix "attribute ‘tkinter’ missing"

`tkinter` is not part of `python`, but of `pythonPackages`.


  Commit: 7e3331af49002b374063ede0983fc03409d3471f
  
https://github.com/NixOS/nixpkgs/commit/7e3331af49002b374063ede0983fc03409d3471f
  Author: Frederik Rietdijk 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/python-modules/matplotlib/default.nix

  Log Message:
  ---
  Merge pull request #20774 from aherrmann/pr_matplotlib_tkagg

matplotlib: Fix "attribute ‘tkinter’ missing"


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


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

2016-11-28 Thread Tomasz Czyż
Nice research, thanks for providing a link.



2016-11-28 15:04 GMT+00:00 :

> On Monday, November 28, 2016 13:32:16 Tomasz Czyż wrote:
> > 2016-11-28 13:18 GMT+00:00 Profpatsch :
> > > On 16-11-12 06:39pm, Rok Garbas wrote:
> > > > On Sat, Nov 12, 2016 at 6:27 PM, Daniel Frank
> > > > I wrote recently[1] how we tackle this problem at RelEng team at
> > > > Mozilla. I'm slowly moving all my nix projects to do the same. I will
> > > > also do the same for the packages I manage in nixpkgs at least that
> is
> > > > what I will write to Santa this year, to give me more time to play
> > > > work on nixpkgs :)
> > > >
> > > >
> > > > [1] https://garbas.si/2016/updating-your-nix-sources.html
> > >
> > > So you had a very similar idea about update scripts.
> > >
> > > We should chat about that; I think there should be a system
> > > in place for derivations to specify how the next version can
> > > be found and if possible how to automatically update the version
> > > tags & hashes.
> >
> > debian has such a strategy:
> > - https://wiki.debian.org/debian/watch
>
> That happens to not work all that well:
> https://github.com/Phreedom/nixpkgs-monitor/blob/master/
> debian-watchfiles/watchfiles.md
>
> It turns out that debian watchfiles were much less reliable at getting
> updates
> from SourceForge, than a generic SourceForge updater. This is because
> naming
> schemes change, devs forget to update the updater script and lots of other
> tiny but important reasons.
>
> In practice, having developers maintain package-specific update scripts is
> just
> as hard if not harder than maintaining the package itself.
>
> This is why the strategy chosen for nixpkgs-monitor was to develop updaters
> that can tackle at least hundreds of packages.
>
> -- Evgeny
> ___
> 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-commits] [NixOS/nixpkgs] b60873: aws-sdk-cpp: 0.10.6 -> 1.0.34

2016-11-28 Thread Eelco Dolstra
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b60873ed99ccdcd4c0fadc452ba025a75176dc16
  
https://github.com/NixOS/nixpkgs/commit/b60873ed99ccdcd4c0fadc452ba025a75176dc16
  Author: Eelco Dolstra 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/libraries/aws-sdk-cpp/default.nix

  Log Message:
  ---
  aws-sdk-cpp: 0.10.6 -> 1.0.34


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


[Nix-commits] [NixOS/nixpkgs] fc3eed: xen service: fix wrong netmask handed out by xen-b...

2016-11-28 Thread Joachim F
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: fc3eed2cb01825d8024a535b8129ec0eeb0b1b84
  
https://github.com/NixOS/nixpkgs/commit/fc3eed2cb01825d8024a535b8129ec0eeb0b1b84
  Author: Michał Pałka 
  Date:   2016-10-26 (Wed, 26 Oct 2016)

  Changed paths:
M nixos/modules/virtualisation/xen-dom0.nix

  Log Message:
  ---
  xen service: fix wrong netmask handed out by xen-bridge.service

The dnsmasq instance run by the xen-bridge.service errorenously
hands out 172.16.0.0 as the netmask over DHCP to the VMs. This
commit removes the option responsible for that from dnsmasq.conf,
so that the proper netmask is inferred by dnsmasq instead.

Addresses https://github.com/NixOS/nixpkgs/issues/19883


  Commit: 8eefcb5c097ee1c70797ade2d5d8a696443610c9
  
https://github.com/NixOS/nixpkgs/commit/8eefcb5c097ee1c70797ade2d5d8a696443610c9
  Author: Joachim F 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M nixos/modules/virtualisation/xen-dom0.nix

  Log Message:
  ---
  Merge pull request #19900 from michalpalka/xen-fix-xen-bridge2

xen service: fix wrong netmask handed out by xen-bridge.service


Compare: https://github.com/NixOS/nixpkgs/compare/944868dd9b98...8eefcb5c097e___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


[Nix-commits] [NixOS/nixpkgs] 955392: xen service: fix iptables race condition in xen-br...

2016-11-28 Thread Joachim F
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 95539284860205e8e7433da079bf634050f03f71
  
https://github.com/NixOS/nixpkgs/commit/95539284860205e8e7433da079bf634050f03f71
  Author: Michał Pałka 
  Date:   2016-10-25 (Tue, 25 Oct 2016)

  Changed paths:
M nixos/modules/virtualisation/xen-dom0.nix

  Log Message:
  ---
  xen service: fix iptables race condition in xen-bridge.service

The calls to iptables in xen-bridge.service were missing the -w switch,
which caused them to fail if another script was calling iptables
at the same time. Fix it by adding the -w switch.

Addresses https://github.com/NixOS/nixpkgs/issues/19849 .


  Commit: 944868dd9b98b50f66bc1aa5f7707c6ff330f3ea
  
https://github.com/NixOS/nixpkgs/commit/944868dd9b98b50f66bc1aa5f7707c6ff330f3ea
  Author: Joachim F 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M nixos/modules/virtualisation/xen-dom0.nix

  Log Message:
  ---
  Merge pull request #19851 from michalpalka/xen-fix-xen-bridge

xen service: fix iptables race condition in xen-bridge.service


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


[Nix-commits] [NixOS/nixpkgs] fc711b: Revert "firefox: 49.0.2 -> 50.0"

2016-11-28 Thread Eelco Dolstra
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: fc711b5430ee9cca22cfe1b57d66747d643af8b2
  
https://github.com/NixOS/nixpkgs/commit/fc711b5430ee9cca22cfe1b57d66747d643af8b2
  Author: Eelco Dolstra 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/applications/networking/browsers/firefox/default.nix

  Log Message:
  ---
  Revert "firefox: 49.0.2 -> 50.0"

This reverts commit 43b963896281e25c88001c2c83f570f1239502d7. It
breaks video playback.


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


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

2016-11-28 Thread phreedom
On Monday, November 28, 2016 13:32:16 Tomasz Czyż wrote:
> 2016-11-28 13:18 GMT+00:00 Profpatsch :
> > On 16-11-12 06:39pm, Rok Garbas wrote:
> > > On Sat, Nov 12, 2016 at 6:27 PM, Daniel Frank
> > > I wrote recently[1] how we tackle this problem at RelEng team at
> > > Mozilla. I'm slowly moving all my nix projects to do the same. I will
> > > also do the same for the packages I manage in nixpkgs at least that is
> > > what I will write to Santa this year, to give me more time to play
> > > work on nixpkgs :)
> > > 
> > > 
> > > [1] https://garbas.si/2016/updating-your-nix-sources.html
> > 
> > So you had a very similar idea about update scripts.
> > 
> > We should chat about that; I think there should be a system
> > in place for derivations to specify how the next version can
> > be found and if possible how to automatically update the version
> > tags & hashes.
> 
> debian has such a strategy:
> - https://wiki.debian.org/debian/watch

That happens to not work all that well:
https://github.com/Phreedom/nixpkgs-monitor/blob/master/debian-watchfiles/watchfiles.md

It turns out that debian watchfiles were much less reliable at getting updates 
from SourceForge, than a generic SourceForge updater. This is because naming 
schemes change, devs forget to update the updater script and lots of other 
tiny but important reasons.

In practice, having developers maintain package-specific update scripts is just 
as hard if not harder than maintaining the package itself.

This is why the strategy chosen for nixpkgs-monitor was to develop updaters 
that can tackle at least hundreds of packages.

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


[Nix-commits] [NixOS/nixpkgs] 37715d: hydra-module: add cfg.package to hydra-evaluator p...

2016-11-28 Thread Domen Kožar
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 37715d1f46653f331d9b5e52e5436fc6afc6d6c2
  
https://github.com/NixOS/nixpkgs/commit/37715d1f46653f331d9b5e52e5436fc6afc6d6c2
  Author: Aycan iRiCAN 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M nixos/modules/services/continuous-integration/hydra/default.nix

  Log Message:
  ---
  hydra-module: add cfg.package to hydra-evaluator path


  Commit: fcc77d0a53770bfeeb03f2a1ec07c1de82a916ae
  
https://github.com/NixOS/nixpkgs/commit/fcc77d0a53770bfeeb03f2a1ec07c1de82a916ae
  Author: Domen Kožar 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M nixos/modules/services/continuous-integration/hydra/default.nix

  Log Message:
  ---
  Merge pull request #20769 from aycanirican/master

hydra-module: add cfg.package to hydra-evaluator path


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


[Nix-commits] [NixOS/nixpkgs] d35e2d: lxc: 2.0.4 -> 2.0.6 (security)

2016-11-28 Thread Alexander V. Nikolaev
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: d35e2de76099a993e0eb606535834bb8ffe441c2
  
https://github.com/NixOS/nixpkgs/commit/d35e2de76099a993e0eb606535834bb8ffe441c2
  Author: Alexander V. Nikolaev 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/os-specific/linux/lxc/default.nix

  Log Message:
  ---
  lxc: 2.0.4 -> 2.0.6 (security)

https://security-tracker.debian.org/tracker/CVE-2016-8649
(cherry picked from commit 514b3763f74330729ce62c39599ecd81db710d57)


  Commit: 3e8dc13478fc0f436a7022f9625b2cf4748bcef6
  
https://github.com/NixOS/nixpkgs/commit/3e8dc13478fc0f436a7022f9625b2cf4748bcef6
  Author: Alexander V. Nikolaev 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/os-specific/linux/lxc/default.nix

  Log Message:
  ---
  lxc: fix sandbox builds

Package attempt to write /etc/bash_completion.d, I directed it to
"${out}/etc/bash_completion.d" as it was suggested.

(cherry picked from commit 36053e4907ccee9cd1845da87ae2846384571c0a)


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


[Nix-commits] [NixOS/nixpkgs] 121da5: lxc: fix sandbox builds

2016-11-28 Thread Peter Simons
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 121da5e93882073963836dcc2bbacc9e40f33d6c
  
https://github.com/NixOS/nixpkgs/commit/121da5e93882073963836dcc2bbacc9e40f33d6c
  Author: Alexander V. Nikolaev 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/os-specific/linux/lxc/default.nix

  Log Message:
  ---
  lxc: fix sandbox builds

Package attempt to write /etc/bash_completion.d, I directed it to
"${out}/etc/bash_completion.d" as it was suggested.


  Commit: a8eeef62e62bec7b09da028a7340b7bf7f2dc011
  
https://github.com/NixOS/nixpkgs/commit/a8eeef62e62bec7b09da028a7340b7bf7f2dc011
  Author: Alexander V. Nikolaev 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/os-specific/linux/lxc/default.nix

  Log Message:
  ---
  lxc: 2.0.4 -> 2.0.6 (security)

https://security-tracker.debian.org/tracker/CVE-2016-8649


  Commit: 21a5532c573a6e364cf03dff182ce73150c9e504
  
https://github.com/NixOS/nixpkgs/commit/21a5532c573a6e364cf03dff182ce73150c9e504
  Author: Peter Simons 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/os-specific/linux/lxc/default.nix

  Log Message:
  ---
  Merge pull request #20766 from avnik/update/lxc

lxc: 2.0.4 -> 2.0.6 (security)


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


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

2016-11-28 Thread Rok Garbas
On Mon, Nov 28, 2016 at 2:37 PM, Bjørn Forsman  wrote:
> On 28 November 2016 at 14:18, Profpatsch  wrote:
>> On 16-11-12 06:39pm, Rok Garbas wrote:
>>> On Sat, Nov 12, 2016 at 6:27 PM, Daniel Frank
>>> I wrote recently[1] how we tackle this problem at RelEng team at
>>> Mozilla. I'm slowly moving all my nix projects to do the same. I will
>>> also do the same for the packages I manage in nixpkgs at least that is
>>> what I will write to Santa this year, to give me more time to play
>>> work on nixpkgs :)
>>>
>>>
>>> [1] https://garbas.si/2016/updating-your-nix-sources.html
>>
>> So you had a very similar idea about update scripts.
>>
>> We should chat about that; I think there should be a system
>> in place for derivations to specify how the next version can
>> be found and if possible how to automatically update the version
>> tags & hashes.
>>
>> Those can obviously not be executed by nix itself, but by other
>> systems like the nixos monitor.
>
> My wish is for Nix to adopt Guix interface for updating package sources:
>
> https://www.gnu.org/software/guix/manual/guix.html#Invoking-guix-refresh
>

All of this ideas are nice and good, but still common thing across all
this ideas is to describe how to refresh/update/move-to-next-version
with the nix expression of the program.

And this is also where the "hard" work is.

I shown in my blog post how to use Travis as the CI which runs the
update scripts for your projects.

How we hook this with hydra is for me irrelevant at this point. There
are many ways how to do this, but not having this hooked with hydra
should not stop us from adding this update script with expressions.
even more we should require every new package to come with an update
script.

To start this we _only_ need to agree how we call this passthru
attribute :) ... update, updateSrc, refresh, refreshSrc, nextVersion,
...

Anyway I'm currently managing many projects like this which would be
impossible to do if i wouldn't automate this.


-- Rok
___
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-11-28 Thread Bjørn Forsman
On 28 November 2016 at 14:18, Profpatsch  wrote:
> On 16-11-12 06:39pm, Rok Garbas wrote:
>> On Sat, Nov 12, 2016 at 6:27 PM, Daniel Frank
>> I wrote recently[1] how we tackle this problem at RelEng team at
>> Mozilla. I'm slowly moving all my nix projects to do the same. I will
>> also do the same for the packages I manage in nixpkgs at least that is
>> what I will write to Santa this year, to give me more time to play
>> work on nixpkgs :)
>>
>>
>> [1] https://garbas.si/2016/updating-your-nix-sources.html
>
> So you had a very similar idea about update scripts.
>
> We should chat about that; I think there should be a system
> in place for derivations to specify how the next version can
> be found and if possible how to automatically update the version
> tags & hashes.
>
> Those can obviously not be executed by nix itself, but by other
> systems like the nixos monitor.

My wish is for Nix to adopt Guix interface for updating package sources:

https://www.gnu.org/software/guix/manual/guix.html#Invoking-guix-refresh

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


[Nix-commits] [NixOS/nixpkgs] 244f04: genymotion: add menu item

2016-11-28 Thread Graham Christensen
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 244f0456f06066a87ba37e610f638b60489e14ef
  
https://github.com/NixOS/nixpkgs/commit/244f0456f06066a87ba37e610f638b60489e14ef
  Author: Alex Ivanov 
  Date:   2016-11-27 (Sun, 27 Nov 2016)

  Changed paths:
M pkgs/development/mobile/genymotion/default.nix

  Log Message:
  ---
  genymotion: add menu item


  Commit: af1dacc2c33ce97fbd36a4856afcc3297c8645e1
  
https://github.com/NixOS/nixpkgs/commit/af1dacc2c33ce97fbd36a4856afcc3297c8645e1
  Author: Alex Ivanov 
  Date:   2016-11-27 (Sun, 27 Nov 2016)

  Changed paths:
M pkgs/development/mobile/genymotion/default.nix

  Log Message:
  ---
  genymotion: 2.7.2 -> 2.8.0


  Commit: ef138dc260df49350054918f048baf472550bec0
  
https://github.com/NixOS/nixpkgs/commit/ef138dc260df49350054918f048baf472550bec0
  Author: Graham Christensen 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/mobile/genymotion/default.nix

  Log Message:
  ---
  Merge pull request #20749 from gnidorah/master3

genymotion: 2.7.2 -> 2.8.0 and add menu item


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


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

2016-11-28 Thread Tomasz Czyż
2016-11-28 13:18 GMT+00:00 Profpatsch :

> On 16-11-12 06:39pm, Rok Garbas wrote:
> > On Sat, Nov 12, 2016 at 6:27 PM, Daniel Frank
> > I wrote recently[1] how we tackle this problem at RelEng team at
> > Mozilla. I'm slowly moving all my nix projects to do the same. I will
> > also do the same for the packages I manage in nixpkgs at least that is
> > what I will write to Santa this year, to give me more time to play
> > work on nixpkgs :)
> >
> >
> > [1] https://garbas.si/2016/updating-your-nix-sources.html
>
> So you had a very similar idea about update scripts.
>
> We should chat about that; I think there should be a system
> in place for derivations to specify how the next version can
> be found and if possible how to automatically update the version
> tags & hashes.
>
debian has such a strategy:
- https://wiki.debian.org/debian/watch
-
https://github.com/FedericoCeratto/debian-package-init/blob/master/deb_create_watch.py

I think better place to execute this would be in CI pipeline, when you can
decide if after upgrading the package you are still able to build the
project.

Also, I'm not sure if automatic upgrades would be that great without manual
verification. There are cases when packages have no signatures and somebody
switched the code on the website (this happens from time to time).

Probably topic worth discussing.

Maybe workflow like that could be a start point:

- monitor - checks if upgrades are possible
- CI/hydra
- checks if upgrades are possible
- if yes, tries to upgrade package and build it
- if package is built correctly, sends email to package maintainers
with a patch (or open pull request) and asks for verification.

Also I had an idea that would be nice to integrate this update command into
"meta" of derivation. What do you think?




>
> Those can obviously not be executed by nix itself, but by other
> systems like the nixos monitor.
>
> --
> 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-commits] [NixOS/nixpkgs] 448d60: opencv3: adding myself as co-maintainer

2016-11-28 Thread viric
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 448d605f89fb0b66640c1a660b8f1e2b8d4a9893
  
https://github.com/NixOS/nixpkgs/commit/448d605f89fb0b66640c1a660b8f1e2b8d4a9893
  Author: Matthew Daiter 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/libraries/opencv/3.x.nix

  Log Message:
  ---
  opencv3: adding myself as co-maintainer


  Commit: 1f7a23c5a141084ac695b415fde6e80a0b477d36
  
https://github.com/NixOS/nixpkgs/commit/1f7a23c5a141084ac695b415fde6e80a0b477d36
  Author: viric 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/libraries/opencv/3.x.nix

  Log Message:
  ---
  Merge pull request #20768 from mdaiter/opencv_maintainer

opencv3: adding myself as co-maintainer


Compare: https://github.com/NixOS/nixpkgs/compare/70c18b55d71e...1f7a23c5a141___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


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

2016-11-28 Thread Profpatsch
On 16-11-12 06:39pm, Rok Garbas wrote:
> On Sat, Nov 12, 2016 at 6:27 PM, Daniel Frank
> I wrote recently[1] how we tackle this problem at RelEng team at
> Mozilla. I'm slowly moving all my nix projects to do the same. I will
> also do the same for the packages I manage in nixpkgs at least that is
> what I will write to Santa this year, to give me more time to play
> work on nixpkgs :)
> 
> 
> [1] https://garbas.si/2016/updating-your-nix-sources.html

So you had a very similar idea about update scripts.

We should chat about that; I think there should be a system
in place for derivations to specify how the next version can
be found and if possible how to automatically update the version
tags & hashes.

Those can obviously not be executed by nix itself, but by other
systems like the nixos monitor.

-- 
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-commits] [NixOS/nixpkgs] 70c18b: rxvt_unicode: create .desktop file

2016-11-28 Thread Tim Nieradzik
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 70c18b55d71e8bd49c7ac0a1d149cdc1c963f2dd
  
https://github.com/NixOS/nixpkgs/commit/70c18b55d71e8bd49c7ac0a1d149cdc1c963f2dd
  Author: Tim Nieradzik 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/applications/misc/rxvt_unicode/default.nix

  Log Message:
  ---
  rxvt_unicode: create .desktop file


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


[Nix-commits] [NixOS/nixpkgs] f13f3e: opencv3: added CUDA 8.0 specific patches

2016-11-28 Thread viric
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f13f3e7f7ab4ac3b848e5f783e5e946593a5ddb2
  
https://github.com/NixOS/nixpkgs/commit/f13f3e7f7ab4ac3b848e5f783e5e946593a5ddb2
  Author: Matthew Daiter 
  Date:   2016-11-23 (Wed, 23 Nov 2016)

  Changed paths:
M pkgs/development/libraries/opencv/3.x.nix

  Log Message:
  ---
  opencv3: added CUDA 8.0 specific patches

opencv3: added informative comments


  Commit: 75d9dc85161e8188a14da7443a7e4a62c952
  
https://github.com/NixOS/nixpkgs/commit/75d9dc85161e8188a14da7443a7e4a62c952
  Author: viric 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/libraries/opencv/3.x.nix

  Log Message:
  ---
  Merge pull request #20631 from mdaiter/opencv_upgrade

opencv3: added CUDA 8.0 specific patches


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


[Nix-commits] [NixOS/nixpkgs] c93ec7: bftpd: init at 4.4

2016-11-28 Thread Michael Raskin
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: c93ec7b6b75ce6c7aebe11a18f25f1831d0620a6
  
https://github.com/NixOS/nixpkgs/commit/c93ec7b6b75ce6c7aebe11a18f25f1831d0620a6
  Author: Michael Raskin <7c6f4...@mail.ru>
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
A pkgs/servers/ftp/bftpd/default.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  bftpd: init at 4.4


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


[Nix-commits] [NixOS/nixpkgs] 0a77d4: flow: 0.34.0 -> 0.36.0

2016-11-28 Thread Graham Christensen
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 0a77d463223316048858ab55a57245a344507053
  
https://github.com/NixOS/nixpkgs/commit/0a77d463223316048858ab55a57245a344507053
  Author: Fatih Altinok 
  Date:   2016-11-24 (Thu, 24 Nov 2016)

  Changed paths:
M pkgs/development/tools/analysis/flow/default.nix

  Log Message:
  ---
  flow: 0.34.0 -> 0.36.0


  Commit: 8088ad7586cfcc1bc8b27d9632f385afaa5942e9
  
https://github.com/NixOS/nixpkgs/commit/8088ad7586cfcc1bc8b27d9632f385afaa5942e9
  Author: Graham Christensen 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/tools/analysis/flow/default.nix

  Log Message:
  ---
  Merge pull request #20689 from frontsideair/flow-34-36

flow: 0.34.0 -> 0.36.0


Compare: https://github.com/NixOS/nixpkgs/compare/04edf297cc55...8088ad7586cf___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


[Nix-commits] [NixOS/nixpkgs] bd57e3: file_cmds: init at 264.1.1

2016-11-28 Thread Graham Christensen
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: bd57e3231206cb967b9f03e0b5baf8f4fc4d4031
  
https://github.com/NixOS/nixpkgs/commit/bd57e3231206cb967b9f03e0b5baf8f4fc4d4031
  Author: Matthew Bauer 
  Date:   2016-11-27 (Sun, 27 Nov 2016)

  Changed paths:
M pkgs/os-specific/darwin/apple-source-releases/default.nix
A pkgs/os-specific/darwin/apple-source-releases/file_cmds/default.nix

  Log Message:
  ---
  file_cmds: init at 264.1.1


  Commit: 04edf297cc55e40e1d1f039ff792bdf71ec794f2
  
https://github.com/NixOS/nixpkgs/commit/04edf297cc55e40e1d1f039ff792bdf71ec794f2
  Author: Graham Christensen 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/os-specific/darwin/apple-source-releases/default.nix
A pkgs/os-specific/darwin/apple-source-releases/file_cmds/default.nix

  Log Message:
  ---
  Merge pull request #20676 from matthewbauer/file_cmds

file_cmds: init at 264.1.1


Compare: https://github.com/NixOS/nixpkgs/compare/41ed3a8dd10b...04edf297cc55___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits


[Nix-commits] [NixOS/nixpkgs] 41ed3a: lnav: fix compilation

2016-11-28 Thread Vincent Demeester
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 41ed3a8dd10b1e4babb045d06c2074042e13c7e0
  
https://github.com/NixOS/nixpkgs/commit/41ed3a8dd10b1e4babb045d06c2074042e13c7e0
  Author: Vincent Demeester 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

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

  Log Message:
  ---
  lnav: fix compilation

nix-env -i lnav currently result of a failure:

command_executor.cc:34:21: fatal error: pcrecpp.h: No such file or
directory

This fixes by using pcre-cpp instead of pcre.

Signed-off-by: Vincent Demeester 


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


[Nix-commits] [NixOS/nixpkgs] 603439: rogue: Add alternative source archive URLs.

2016-11-28 Thread Graham Christensen
  Branch: refs/heads/release-16.09
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 6034390c75e0c332f80a5c14ef5279385078d7f1
  
https://github.com/NixOS/nixpkgs/commit/6034390c75e0c332f80a5c14ef5279385078d7f1
  Author: Sebastian Hagen 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/games/rogue/default.nix

  Log Message:
  ---
  rogue: Add alternative source archive URLs.

As of right now, rogue.rogueforge.net has been down for at least several hours
(likely more).
We add two mirrors here which are likely to be more reliable. We keep the
original download location as a fallback, in case that estimate turns out to be
incorrect.

(cherry picked from commit aad48be62bbea40d29e2a6507af38687990ec7de)


  Commit: 721f2b9fb2febbd4efce34eb6ffa58a16da0888f
  
https://github.com/NixOS/nixpkgs/commit/721f2b9fb2febbd4efce34eb6ffa58a16da0888f
  Author: Graham Christensen 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/games/rogue/default.nix

  Log Message:
  ---
  Merge pull request #20761 from sh01/cp_rogue_mirror

rogue: Add alternative source archive URLs. (16.09)


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


[Nix-commits] [NixOS/nixpkgs] e99228: grsecurity module: force a known good kernel packa...

2016-11-28 Thread Joachim Fasting
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: e99228db3014131255e19b88ba78e47b46a4bff8
  
https://github.com/NixOS/nixpkgs/commit/e99228db3014131255e19b88ba78e47b46a4bff8
  Author: Joachim Fasting 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M nixos/modules/security/grsecurity.nix
M nixos/modules/security/grsecurity.xml

  Log Message:
  ---
  grsecurity module: force a known good kernel package set

Previously, we would only set a default value, on the theory that
`boot.kernelPackages` could be used to sanely configure a custom grsec
kernel.  Regrettably, this is not the case and users who expect e.g.,
`boot.kernelPackages = pkgs.linuxPackages_latest` to work will end up
with a non-grsec kernel (this problem has come up twice on the bug
tracker recently).

With this patch, `security.grsecurity.enable = true` implies
`boot.kernelPackages = linuxPackages_grsec_nixos` and any customization
must be done via package override or by eschewing the module.


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


Re: [Nix-dev] hotswappable self managing services in nix

2016-11-28 Thread Tomasz Czyż
Stewart:
check my comment for configuration reload, if you want this on service
level, https://github.com/NixOS/nixpkgs/issues/1988#issuecomment-247779639
could be helpful for you (at least I'm implementing such things that way).



2016-11-28 10:49 GMT+00:00 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  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 
>> 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
>
>


-- 
Tomasz Czyż
___
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  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  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


[Nix-commits] [NixOS/nixpkgs] 4c7323: Revert "grsecurity: work around for #20490"

2016-11-28 Thread Joachim Fasting
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 4c7323545b21e103f6e864abb0dcec314eed6ae9
  
https://github.com/NixOS/nixpkgs/commit/4c7323545b21e103f6e864abb0dcec314eed6ae9
  Author: Joachim Fasting 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
R pkgs/os-specific/linux/kernel/grsecurity-modinst.patch
M pkgs/os-specific/linux/kernel/patches.nix
M pkgs/top-level/all-packages.nix

  Log Message:
  ---
  Revert "grsecurity: work around for #20490"

This reverts commit e38b74ba89d3d03e01ee751131d2a6dc316ac33a.

I failed to notice f19c961b4e461da045f2e72e73701059e5117be0; better
use that fix instead.


  Commit: 1915f6908ab17bf37b8aa1cf33eef55f9fac69ce
  
https://github.com/NixOS/nixpkgs/commit/1915f6908ab17bf37b8aa1cf33eef55f9fac69ce
  Author: Joachim Fasting 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

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

  Log Message:
  ---
  linux_grsec_nixos: use the "modinst arg list too long" patch

An alternative to e38b74ba89d3d03e01ee751131d2a6dc316ac33a; see
f19c961b4e461da045f2e72e73701059e5117be0 for details


  Commit: b90ed0cc80293e16a219193f4b2495be14fd563b
  
https://github.com/NixOS/nixpkgs/commit/b90ed0cc80293e16a219193f4b2495be14fd563b
  Author: Joachim Fasting 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/os-specific/linux/kernel/linux-grsecurity.nix
M pkgs/os-specific/linux/kernel/patches.nix

  Log Message:
  ---
  grsecurity: 4.8.10-201611232213 -> 4.8.11-201611271225


  Commit: 5da1394a587a9123f07a55d2bf8d9966df907c10
  
https://github.com/NixOS/nixpkgs/commit/5da1394a587a9123f07a55d2bf8d9966df907c10
  Author: Joachim Fasting 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/os-specific/linux/gradm/default.nix
R pkgs/os-specific/linux/gradm/gradm_nix_store.patch

  Log Message:
  ---
  Revert "gradm: fix using gradm while the RBAC system is active"

This reverts commit fdbf7dc8b38cd523804d342d2c153dfeb10cc83d.

Unfortunately, while gradm now works when the RBAC system is enabled,
gradm still fails when full system learning is enabled, so I probably
need to try again later.


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


[Nix-commits] [NixOS/nixpkgs] e36d24: rustc: Don't fail if deleting of breaking tests fa...

2016-11-28 Thread Moritz Ulrich
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: e36d243258889fa98efba3cb1ee3997d0af2c40e
  
https://github.com/NixOS/nixpkgs/commit/e36d243258889fa98efba3cb1ee3997d0af2c40e
  Author: Moritz Ulrich 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/compilers/rust/rustc.nix

  Log Message:
  ---
  rustc: Don't fail if deleting of breaking tests fails.


  Commit: bfc187f23a80a02135b2d76fb1e92adc7d5759ce
  
https://github.com/NixOS/nixpkgs/commit/bfc187f23a80a02135b2d76fb1e92adc7d5759ce
  Author: Moritz Ulrich 
  Date:   2016-11-28 (Mon, 28 Nov 2016)

  Changed paths:
M pkgs/development/compilers/rust/rustc.nix

  Log Message:
  ---
  rustc: Loosen bootstrapping restrictions.

Newer nightlies check a new environment variable that if set will loosen
restrictions on which compiler version can be used for bootstrapping.

Upstream issue is at https://github.com/rust-lang/rust/pull/37265


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


Re: [Nix-dev] hotswappable self managing services in nix

2016-11-28 Thread stewart mackenzie
zimbatm, i appreciate you sharing your insight and experience, my main
exposure to this is the Erlang Way tm. Many good lessons can be drawn
from this level of engineering.

I'm not too fussed about the network level (inter machine) at this
moment. Inter-service we're using a component that wraps nanomsg.

After a bit of thought, we're redesigning the rustfbp scheduler/vm to
be more like the way nix operates.

i.e. as declarative as possible, we cannot have silly imperative state
fiddling at all, i.e. you cannot log into a fractalide node and start
connecting / disconnecting components, this would be like making the
/nix/store/ writable and messing with that.

The new design is this: you load a nix compiled hierarchy of
components into the fractalide virtual machine (fvm) then if you want
to make a mistake, and want to change it you'll issue a $ fvm reload
${new_subnet_hierarchy} and fvm will then kill/start/hotswap all rust
components that aren't/are in your new description of the graph. Just
as nixos-rebuild makes your system reflect your Configuration.nix
file, so fvm will reconfigure the component graph in the process to
reflect what nix compiled.

Once we get this layer, then we can "surf" with nix and just let
nix/nixops manage the rest. We can implement blue/green styles of
deployment in nixops *.nix files. That's another layer of problems
still to come.

Phew...


On Mon, Nov 28, 2016 at 5:33 PM, zimbatm  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  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] hotswappable self managing services in nix

2016-11-28 Thread zimbatm
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  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