[Nix-commits] [NixOS/nixpkgs] 96dfd0: groonga: 6.1.0 -> 6.1.1
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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....
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...
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
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
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...
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
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-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"
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
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
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...
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...
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"
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
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...
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)
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
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
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
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
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 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
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
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
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
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
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
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
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
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.
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...
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
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
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"
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...
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
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
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
