[Nix-commits] [NixOS/nixpkgs] 5f34b5: goaccess: 0.9.4 -> 1.0
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 5f34b5476b8132b5eee7873f2cc4777843bc4f85 https://github.com/NixOS/nixpkgs/commit/5f34b5476b8132b5eee7873f2cc4777843bc4f85 Author: Rok Garbas Date: 2016-06-10 (Fri, 10 Jun 2016) Changed paths: M pkgs/tools/misc/goaccess/default.nix Log Message: --- goaccess: 0.9.4 -> 1.0 also there is no need for local variables ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 4c9686: firefox-bin: 47.0b9 -> 48.0b1, 48.0a2 -> 49.0a2
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 4c96860b5380e0ccb4df2b280286946416505c22 https://github.com/NixOS/nixpkgs/commit/4c96860b5380e0ccb4df2b280286946416505c22 Author: Rok Garbas Date: 2016-06-10 (Fri, 10 Jun 2016) Changed paths: M pkgs/applications/networking/browsers/firefox-bin/beta_sources.nix M pkgs/applications/networking/browsers/firefox-bin/default.nix Log Message: --- firefox-bin: 47.0b9 -> 48.0b1, 48.0a2 -> 49.0a2 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 511565: kibana: 4.4.1 -> 4.5.1
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 511565e996ff4eac7dc114eb39d6f81dba0e50bb https://github.com/NixOS/nixpkgs/commit/511565e996ff4eac7dc114eb39d6f81dba0e50bb Author: Rickard Nilsson Date: 2016-06-10 (Fri, 10 Jun 2016) Changed paths: M pkgs/development/tools/misc/kibana/default.nix Log Message: --- kibana: 4.4.1 -> 4.5.1 Commit: 9657844db241d915f60cd0aa64d6d1c17111a7d0 https://github.com/NixOS/nixpkgs/commit/9657844db241d915f60cd0aa64d6d1c17111a7d0 Author: Rickard Nilsson Date: 2016-06-10 (Fri, 10 Jun 2016) Changed paths: M pkgs/tools/misc/fluentd/Gemfile.lock M pkgs/tools/misc/fluentd/default.nix M pkgs/tools/misc/fluentd/gemset.nix Log Message: --- fluentd: 0.12.6 -> 0.14.0 Compare: https://github.com/NixOS/nixpkgs/compare/c1cb5ca57e4b...9657844db241___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-dev] Where to start when nixos-rebuild switch --upgrade goes wrong
Hi Everyone,
I performed a nixos-rebuild switch --upgrade and after rebooting, was
not able to see my usual KDE session. There was no X session. I
selected a previous generation in gummiboot and was able to have my
KDE session back. What can I do about the upgraded components which
did not work? I could issue a nixos-rebuild switch --rollback, but
would the development community benefit from finding out what went
wrong? This is a very rudimentary and unsophisticated NixOS
installation. Aside from the failed upgrade, nothing out of the
ordinairy has been done to it.
configuration.nix:
{ config, pkgs, ... }:
{
imports =
[ # Include the results of the hardware scan.
./hardware-configuration.nix
];
# Use the gummiboot efi boot loader.
boot.loader.gummiboot.enable = true;
boot.loader.efi.canTouchEfiVariables = true;
networking.hostName = "ejr-e465"; # Define your hostname.
networking.wireless.enable = true; # Enables wireless support via
wpa_supplicant.
# Select internationalisation properties.
i18n = {
consoleFont = "Lat2-Terminus16";
consoleKeyMap = "us";
defaultLocale = "en_US.UTF-8";
};
# Set your time zone.
time.timeZone = "America/New_York";
# List packages installed in system profile. To search by name, run:
# $ nix-env -qaP | grep wget
environment.systemPackages = with pkgs; [
wget
vim
pkgs.kde4.kdemultimedia
pkgs.kde4.kdegraphics
pkgs.kde4.kdeutils
pkgs.kde4.applications
pkgs.kde4.kdebindings
pkgs.kde4.kdeaccessibility
pkgs.kde4.kde_baseapps
pkgs.kde4.kactivities
pkgs.kde4.kdeadmin
pkgs.kde4.kdeartwork
pkgs.kde4.kde_base_artwork
pkgs.kde4.kdenetwork
pkgs.kde4.kdepim
pkgs.kde4.kdepimlibs
pkgs.kde4.kdeplasma_addons
pkgs.kde4.kdesdk
pkgs.kde4.kdetoys
pkgs.kde4.kdewebdev
pkgs.kde4.oxygen_icons
pkgs.kde4.kdebase_workspace
pkgs.kde4.kdelibs
pkgs.kde4.kdevelop
pkgs.kde4.kdevplatform
];
# List services that you want to enable:
# Enable the OpenSSH daemon.
# services.openssh.enable = true;
# Enable CUPS to print documents.
# services.printing.enable = true;
# Enable the X11 windowing system.
services.xserver.enable = true;
services.xserver.layout = "us";
#services.xserver.xkbOptions = "eurosign:e";
# Enable the KDE Desktop Environment.
services.xserver.displayManager.kdm.enable = true;
services.xserver.desktopManager.kde4.enable = true;
fonts = {
enableFontDir = true;
enableGhostscriptFonts = true;
fonts = with pkgs; [
corefonts # Micrsoft free fonts
inconsolata # monospaced
];
};
users.extraUsers.ejr = {
name = "ejr";
group = "users";
uid = 1001;
createHome = true;
home = "/home/ejr";
useDefaultShell = true;
description = "Evan Johannes Rowley";
password = "password";
extraGroups = [
"wheel"
"libvirtd"
"audio"
"kvm"
"cdrom"
"docker"
];
};
# release to be compatible with for stateful data such as databases.
system.stateVersion = "16.03";
system.autoUpgrade.enable = true;
system.autoUpgrade.channel = https://nixos.org/channels/nixos-16.03;
}
--
- EJR
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] wordpress
Naa time critical nature, just decided to spin up an ubuntu virtualbox. Ah I recognize the email address from the code you wrote :-) It would seem it's very centered around deploying stock releases not amenable for developing on wordpress. But I didn't get that far. Is there a faster route? On 10 Jun 2016 02:06, "Joachim Schiele" wrote: > got it working? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to install RubyOnRails on nixos?
On 06.06.2016 10:51, Nicolas Petton wrote: > hi, > > I'm trying to properly install rails on nixos. I'm not interested in > packaging an existing rails app, but rather to do rails development. > > I guess using rubygems is not the nixos way (and installing the rails > gem globally won't work anyway). > > Any pointers? have a look at the gitlab service in nixpkgs. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] wordpress
On 09.06.2016 12:06, stewart mackenzie wrote: > Ah I see this: https://nixos.org/wiki/Wordpress > > I'll need to override the src of wordpress with my own version of wordpress. > got it working? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] c1cb5c: oauth2_proxy module: fix manual build
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: c1cb5ca57e4b067afaa13fd93ed1392ec84c9da2 https://github.com/NixOS/nixpkgs/commit/c1cb5ca57e4b067afaa13fd93ed1392ec84c9da2 Author: Joachim Fasting Date: 2016-06-10 (Fri, 10 Jun 2016) Changed paths: M nixos/modules/services/security/oauth2_proxy.nix Log Message: --- oauth2_proxy module: fix manual build ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] f8a0f1: klavaro: 3.01 -> 3.02
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: f8a0f1ce686674fc53830e2a1c61c40f53df4571 https://github.com/NixOS/nixpkgs/commit/f8a0f1ce686674fc53830e2a1c61c40f53df4571 Author: mimadrid Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/games/klavaro/default.nix Log Message: --- klavaro: 3.01 -> 3.02 Commit: 830c748ea43c470586052c8f67f948900926753a https://github.com/NixOS/nixpkgs/commit/830c748ea43c470586052c8f67f948900926753a Author: mimadrid Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M lib/maintainers.nix M pkgs/games/klavaro/default.nix Log Message: --- Add myself as maintainer Commit: 589082646a8b12c6dd6138f2fa49ccbe02107595 https://github.com/NixOS/nixpkgs/commit/589082646a8b12c6dd6138f2fa49ccbe02107595 Author: Joachim Fasting Date: 2016-06-10 (Fri, 10 Jun 2016) Changed paths: M lib/maintainers.nix M pkgs/games/klavaro/default.nix Log Message: --- Merge pull request #16097 from mimadrid/update/klavaro-3.02 klavaro: 3.01 -> 3.02 Compare: https://github.com/NixOS/nixpkgs/compare/902b6d569188...589082646a8b___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 0e262f: go: v1.5.3 -> v1.5.4
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 0e262f52f30143e9f6fdc171fee69075934604e3 https://github.com/NixOS/nixpkgs/commit/0e262f52f30143e9f6fdc171fee69075934604e3 Author: rushmorem Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/compilers/go/1.5.nix Log Message: --- go: v1.5.3 -> v1.5.4 Commit: 2a258d13ade7533aa37bffcdd2ce0cea67309483 https://github.com/NixOS/nixpkgs/commit/2a258d13ade7533aa37bffcdd2ce0cea67309483 Author: rushmorem Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/top-level/all-packages.nix Log Message: --- go: make 1.6 default Commit: 6e709b180e83c275f49ba0520e598509c2827abe https://github.com/NixOS/nixpkgs/commit/6e709b180e83c275f49ba0520e598509c2827abe Author: rushmorem Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/tools/system/storebrowse/default.nix Log Message: --- storebrowse: mark broken `storebrowse` depends on https://code.google.com/archive/p/gosqlite/ which leads to gosqlite.googlecode.com/hg/sqlite which now 404s. Commit: 902b6d5691888b1eb4b74ef42c6c284a35f91772 https://github.com/NixOS/nixpkgs/commit/902b6d5691888b1eb4b74ef42c6c284a35f91772 Author: Rushmore Mushambi Date: 2016-06-10 (Fri, 10 Jun 2016) Changed paths: M pkgs/development/compilers/go/1.5.nix M pkgs/tools/system/storebrowse/default.nix M pkgs/top-level/all-packages.nix Log Message: --- Merge pull request #16093 from rushmorem/update-go go: v1.5.3 -> v1.5.4 Compare: https://github.com/NixOS/nixpkgs/compare/7bd515979c59...902b6d569188___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-dev] help with Travis builds
n00b here
Trying to sort out PR: https://github.com/NixOS/nixpkgs/pull/15986
while "it works on my machine", travis barks out at me with:
https://travis-ci.org/NixOS/nixpkgs/builds/135414974
so I looked into the travis builds to find out what they were doing, and
come up with this to replicate them locally.
This Vagrantfile fails with the same error as Travis
```
vbox_version = `VBoxManage --version`
Vagrant.configure(2) do |config|
config.vm.box = "ubuntu/trusty64"
config.vm.network "private_network", ip: "192.168.33.96", nic_type:
"virtio"
config.vm.provider "virtualbox" do |vb|
vb.memory = "3072"
vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
vb.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
vb.customize [ "guestproperty", "set", :id,
"/VirtualBox/GuestAdd/VBoxService/--timesync-set-threshold", 1 ]
vb.customize ["modifyvm", :id, "--nictype1", "virtio"]
vb.customize ["modifyvm", :id, "--paravirtprovider", "kvm"] if
vbox_version.to_f >= 5.0
vb.customize ["storagectl", :id, "--name", "SATAController",
"--hostiocache", "on"]
vb.customize ["modifyvm", :id, "--ioapic", "on"]
vb.customize ["modifyvm", :id, "--cpus",
`#{RbConfig::CONFIG['host_os'] =~ /darwin/ ? 'sysctl -n hw.ncpu' :
'nproc'}`.chomp]
vb.linked_clone = true if Vagrant::VERSION =~ /^1.8/
end
config.vm.provision "shell", inline: <<-SHELL
groupadd nixbld
usermod -G nixbld vagrant
apt-get update
apt-get install -y build-essential git
test -e /swapfile || ( dd if=/dev/zero of=/swapfile bs=1M count=2048 &&
mkswap /swapfile )
swapon /swapfile
SHELL
config.vm.provision "shell", privileged: false, inline: <<-SHELL
git clone https://github.com/NixOS/nixpkgs.git
cd nixpkgs
export TRAVIS_PULL_REQUEST=15986
./maintainers/scripts/travis-nox-review-pr.sh nix
./maintainers/scripts/travis-nox-review-pr.sh nox
./maintainers/scripts/travis-nox-review-pr.sh build
SHELL
end
```
But this Vagrantfile builds my PR correctly
```
vbox_version = `VBoxManage --version`
Vagrant.configure(2) do |config|
config.vm.box = "ubuntu/trusty64"
config.vm.network "private_network", ip: "192.168.33.96", nic_type:
"virtio"
config.vm.provider "virtualbox" do |vb|
vb.memory = "3072"
vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
vb.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
vb.customize [ "guestproperty", "set", :id,
"/VirtualBox/GuestAdd/VBoxService/--timesync-set-threshold", 1 ]
vb.customize ["modifyvm", :id, "--nictype1", "virtio"]
vb.customize ["modifyvm", :id, "--paravirtprovider", "kvm"] if
vbox_version.to_f >= 5.0
vb.customize ["storagectl", :id, "--name", "SATAController",
"--hostiocache", "on"]
vb.customize ["modifyvm", :id, "--ioapic", "on"]
vb.customize ["modifyvm", :id, "--cpus",
`#{RbConfig::CONFIG['host_os'] =~ /darwin/ ? 'sysctl -n hw.ncpu' :
'nproc'}`.chomp]
vb.linked_clone = true if Vagrant::VERSION =~ /^1.8/
end
config.vm.provision "shell", inline: <<-SHELL
groupadd nixbld
usermod -G nixbld vagrant
apt-get update
apt-get install -y build-essential git
test -e /swapfile || ( dd if=/dev/zero of=/swapfile bs=1M count=2048 &&
mkswap /swapfile )
swapon /swapfile || echo
SHELL
config.vm.provision "shell", privileged: false, inline: <<-SHELL
git clone https://github.com/NixOS/nixpkgs.git
cd nixpkgs
git config --global user.email "m...@example.com"
git config --global user.name "Your Name"
git remote add Azulinho https://github.com/Azulinho/nixpkgs.git
git fetch Azulinho
git merge Azulinho/update_libgit2_to_v24
export NIXPKGS=$PWD
export TRAVIS_PULL_REQUEST=15986
./maintainers/scripts/travis-nox-review-pr.sh nix
./maintainers/scripts/travis-nox-review-pr.sh nox
. $HOME/.nix-profile/etc/profile.d/nix.sh
nix-build nixos/release.nix -A options --show-trace
nix-build pkgs/top-level/release.nix -A tarball --show-trace
nix-build $PWD -A python27Packages.pygit2
nix-build $PWD -A python35Packages.pygit2
SHELL
end
```
Before I dig into reading about nox and getting into the grittier details,
does anyone has a hint for what could possibly be happening here?
happy to pay back with a merged PR
- azul
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Stackage Support Will Be Discontinued
Peter Simons writes: > Hi Anthony, > > >> [What is] a concrete use case that works for you today but that > >> won't work after LTS-4 has been dropped? > > > > Someone who has a project that works with package versions in LTS-4, > > but hasn't yet been upgraded to LTS-5 or 6. They can simply refer to > > LTS-4 in their shell.nix for haskell packages. > > Oh, but you can absolutely do that! You can extend the set of available > packages to your heart's content and you can compose package sets that > provide any combination of versions as you please. The Haskell > infrastructure in Nix gives you that ability. > > > >>> You are removing that opportunity because it hasn't been used yet. > >> > >> I don't intend to remove any "opportunities" here. All I want to remove > >> is some 850,000 lines of untested, unmaintained code from the Nixpkgs > >> repository. [...] > > > > If it's 850,000 lines of code, then that really seems like a Nix > > issue. If the point here is to declare bankruptcy and tell people to > > use stack which is able to refer to multiple versions of packages, > > then let's call it that. > > I have a hard time assigning meaning to vague terms like "removing > opportunities" and "declaring bankruptcy" in a technical conversation. I > am sorry, I just don't see how to these kind of things make a compelling > argument for distributing old LTS releases in Nixpkgs. I truly don't understand why this is hard for you to understand, so we are of a mind on this misunderstanding! There must be a language barrier or different understanding of what breaking version changes are between us. > > [A team using Nix today] can refer to LTS-5 in nixpkgs, and not need > > to make any changes to adopt LTS-6 until they are ready. I know that > > should a problem emerge with LTS-5, a project using stack has a good > > chance of benefiting from a new Stackage release. I know that after > > the changes you are making, the team using LTS-5 in nixpkgs will not > > have a working environment until they address any of the 5->6 > > breaking changes. > > This is true only if we assume that the team depending on LTS-5 updates > their copy of Nixpkgs to a version that breaks their code. But they > don't have to. They can use a version of Nixpkgs that works for them > until they're comfortable addressing the issues caused by an update. > Also, these changes I'll be making show up only in the branch we dub > "unstable". The release-16.03 branch, for example, has LTS-5 and will > continue to have it until all eternity. > > You realize that Nix allows you to override the contents of the Nixpkgs > version you're using without actually editing that version, right? You > can stick to any given version of Nixpkgs, but if an update of, say > libuuid, comes out that you'd like to have, then you can override only > that particular package in configuration.nix or ~/.nixpkgs/config.nix > without ever touching Nixpkgs itself. This gives you a stable package > plus selected, hand-picked updates. IMHO that is an awesome mechanism > for stable deployments. I think that telling users to stick to a single version of nixpkgs and take responsibility for cherry-picking individual security and bug fix commits to all Haskell and system libraries they depend on is the worst job a package management system can do while still calling itself a package manager. I do appreciate that you find such a setup appealing, so I'll say no more as this is solely your call. Anthony ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] 7bd515: tinycc: fix paxmark call
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 7bd515979c59fa2b5786fba2fddbca9d56c04cb1 https://github.com/NixOS/nixpkgs/commit/7bd515979c59fa2b5786fba2fddbca9d56c04cb1 Author: Joachim Fasting Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/compilers/tinycc/default.nix Log Message: --- tinycc: fix paxmark call I missed this due to testing on a checkout that didn't contain the paxmark fix ... ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Stackage Support Will Be Discontinued
Hi Anthony, >> [What is] a concrete use case that works for you today but that >> won't work after LTS-4 has been dropped? > > Someone who has a project that works with package versions in LTS-4, > but hasn't yet been upgraded to LTS-5 or 6. They can simply refer to > LTS-4 in their shell.nix for haskell packages. Oh, but you can absolutely do that! You can extend the set of available packages to your heart's content and you can compose package sets that provide any combination of versions as you please. The Haskell infrastructure in Nix gives you that ability. >>> You are removing that opportunity because it hasn't been used yet. >> >> I don't intend to remove any "opportunities" here. All I want to remove >> is some 850,000 lines of untested, unmaintained code from the Nixpkgs >> repository. [...] > > If it's 850,000 lines of code, then that really seems like a Nix > issue. If the point here is to declare bankruptcy and tell people to > use stack which is able to refer to multiple versions of packages, > then let's call it that. I have a hard time assigning meaning to vague terms like "removing opportunities" and "declaring bankruptcy" in a technical conversation. I am sorry, I just don't see how to these kind of things make a compelling argument for distributing old LTS releases in Nixpkgs. > [A team using Nix today] can refer to LTS-5 in nixpkgs, and not need > to make any changes to adopt LTS-6 until they are ready. I know that > should a problem emerge with LTS-5, a project using stack has a good > chance of benefiting from a new Stackage release. I know that after > the changes you are making, the team using LTS-5 in nixpkgs will not > have a working environment until they address any of the 5->6 > breaking changes. This is true only if we assume that the team depending on LTS-5 updates their copy of Nixpkgs to a version that breaks their code. But they don't have to. They can use a version of Nixpkgs that works for them until they're comfortable addressing the issues caused by an update. Also, these changes I'll be making show up only in the branch we dub "unstable". The release-16.03 branch, for example, has LTS-5 and will continue to have it until all eternity. You realize that Nix allows you to override the contents of the Nixpkgs version you're using without actually editing that version, right? You can stick to any given version of Nixpkgs, but if an update of, say libuuid, comes out that you'd like to have, then you can override only that particular package in configuration.nix or ~/.nixpkgs/config.nix without ever touching Nixpkgs itself. This gives you a stable package plus selected, hand-picked updates. IMHO that is an awesome mechanism for stable deployments. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] 585997: Add module for oauth2_proxy
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 58599744ee9673d309d5e4d8415077c242545e8d https://github.com/NixOS/nixpkgs/commit/58599744ee9673d309d5e4d8415077c242545e8d Author: Jonathan Lange Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M nixos/modules/module-list.nix A nixos/modules/services/security/oauth2_proxy.nix Log Message: --- Add module for oauth2_proxy Commit: e2e2840aa732048600bbdddc998191abf9a69fa8 https://github.com/NixOS/nixpkgs/commit/e2e2840aa732048600bbdddc998191abf9a69fa8 Author: Joachim Fasting Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M nixos/modules/module-list.nix A nixos/modules/services/security/oauth2_proxy.nix Log Message: --- Merge pull request #15283 from jml/oauth2proxy-moduleu oauth2_proxy: create new module for service Compare: https://github.com/NixOS/nixpkgs/compare/3a4ff5fc7e91...e2e2840aa732___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] d77e65: firefox-bin: 45.0.2 -> 46.0.1
Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: d77e65360ea0e5d5c3bdebf5f0c7f24204303053 https://github.com/NixOS/nixpkgs/commit/d77e65360ea0e5d5c3bdebf5f0c7f24204303053 Author: taku0 Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/applications/networking/browsers/firefox-bin/default.nix M pkgs/applications/networking/browsers/firefox-bin/generate_sources.rb M pkgs/applications/networking/browsers/firefox-bin/sources.nix M pkgs/top-level/all-packages.nix Log Message: --- firefox-bin: 45.0.2 -> 46.0.1 (cherry picked from commit 90f5be3133ed32aa1564d9bfc7fb89e95beccf79) Commit: cde6bb63c09ebce2da8656168a5b0ef3bd2d325b https://github.com/NixOS/nixpkgs/commit/cde6bb63c09ebce2da8656168a5b0ef3bd2d325b Author: taku0 Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/applications/networking/browsers/firefox-bin/default.nix Log Message: --- firefox-bin: fixed missing icon (cherry picked from commit 07a83f226ea6608c9ff614b8bb41d898b21410c0) Commit: 6daa706c06d6a60ff07efde6520ff0e89d7effed https://github.com/NixOS/nixpkgs/commit/6daa706c06d6a60ff07efde6520ff0e89d7effed Author: taku0 Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/applications/networking/browsers/firefox-bin/sources.nix Log Message: --- firefox-bin: 46.0.1 -> 47.0 (cherry picked from commit 697437c8e7c49beec77dc853d051f06656d3439b) Compare: https://github.com/NixOS/nixpkgs/compare/4959bd75db62...6daa706c06d6___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] cf042a: hackage-packages.nix: update Haskell package set
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: cf042ae750a9fe911addd6ffddea2c8c6fa45548 https://github.com/NixOS/nixpkgs/commit/cf042ae750a9fe911addd6ffddea2c8c6fa45548 Author: Peter Simons Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/haskell-modules/configuration-lts-0.0.nix M pkgs/development/haskell-modules/configuration-lts-0.1.nix M pkgs/development/haskell-modules/configuration-lts-0.2.nix M pkgs/development/haskell-modules/configuration-lts-0.3.nix M pkgs/development/haskell-modules/configuration-lts-0.4.nix M pkgs/development/haskell-modules/configuration-lts-0.5.nix M pkgs/development/haskell-modules/configuration-lts-0.6.nix M pkgs/development/haskell-modules/configuration-lts-0.7.nix M pkgs/development/haskell-modules/configuration-lts-1.0.nix M pkgs/development/haskell-modules/configuration-lts-1.1.nix M pkgs/development/haskell-modules/configuration-lts-1.10.nix M pkgs/development/haskell-modules/configuration-lts-1.11.nix M pkgs/development/haskell-modules/configuration-lts-1.12.nix M pkgs/development/haskell-modules/configuration-lts-1.13.nix M pkgs/development/haskell-modules/configuration-lts-1.14.nix M pkgs/development/haskell-modules/configuration-lts-1.15.nix M pkgs/development/haskell-modules/configuration-lts-1.2.nix M pkgs/development/haskell-modules/configuration-lts-1.4.nix M pkgs/development/haskell-modules/configuration-lts-1.5.nix M pkgs/development/haskell-modules/configuration-lts-1.7.nix M pkgs/development/haskell-modules/configuration-lts-1.8.nix M pkgs/development/haskell-modules/configuration-lts-1.9.nix M pkgs/development/haskell-modules/configuration-lts-2.0.nix M pkgs/development/haskell-modules/configuration-lts-2.1.nix M pkgs/development/haskell-modules/configuration-lts-2.10.nix M pkgs/development/haskell-modules/configuration-lts-2.11.nix M pkgs/development/haskell-modules/configuration-lts-2.12.nix M pkgs/development/haskell-modules/configuration-lts-2.13.nix M pkgs/development/haskell-modules/configuration-lts-2.14.nix M pkgs/development/haskell-modules/configuration-lts-2.15.nix M pkgs/development/haskell-modules/configuration-lts-2.16.nix M pkgs/development/haskell-modules/configuration-lts-2.17.nix M pkgs/development/haskell-modules/configuration-lts-2.18.nix M pkgs/development/haskell-modules/configuration-lts-2.19.nix M pkgs/development/haskell-modules/configuration-lts-2.2.nix M pkgs/development/haskell-modules/configuration-lts-2.20.nix M pkgs/development/haskell-modules/configuration-lts-2.21.nix M pkgs/development/haskell-modules/configuration-lts-2.22.nix M pkgs/development/haskell-modules/configuration-lts-2.3.nix M pkgs/development/haskell-modules/configuration-lts-2.4.nix M pkgs/development/haskell-modules/configuration-lts-2.5.nix M pkgs/development/haskell-modules/configuration-lts-2.6.nix M pkgs/development/haskell-modules/configuration-lts-2.7.nix M pkgs/development/haskell-modules/configuration-lts-2.8.nix M pkgs/development/haskell-modules/configuration-lts-2.9.nix M pkgs/development/haskell-modules/configuration-lts-3.0.nix M pkgs/development/haskell-modules/configuration-lts-3.1.nix M pkgs/development/haskell-modules/configuration-lts-3.10.nix M pkgs/development/haskell-modules/configuration-lts-3.11.nix M pkgs/development/haskell-modules/configuration-lts-3.12.nix M pkgs/development/haskell-modules/configuration-lts-3.13.nix M pkgs/development/haskell-modules/configuration-lts-3.14.nix M pkgs/development/haskell-modules/configuration-lts-3.15.nix M pkgs/development/haskell-modules/configuration-lts-3.16.nix M pkgs/development/haskell-modules/configuration-lts-3.17.nix M pkgs/development/haskell-modules/configuration-lts-3.18.nix M pkgs/development/haskell-modules/configuration-lts-3.19.nix M pkgs/development/haskell-modules/configuration-lts-3.2.nix M pkgs/development/haskell-modules/configuration-lts-3.20.nix M pkgs/development/haskell-modules/configuration-lts-3.21.nix M pkgs/development/haskell-modules/configuration-lts-3.22.nix M pkgs/development/haskell-modules/configuration-lts-3.3.nix M pkgs/development/haskell-modules/configuration-lts-3.4.nix M pkgs/development/haskell-modules/configuration-lts-3.5.nix M pkgs/development/haskell-modules/configuration-lts-3.6.nix M pkgs/development/haskell-modules/configuration-lts-3.7.nix M pkgs/development/haskell-modules/configuration-lts-3.8.nix M pkgs/development/haskell-modules/configuration-lts-3.9.nix M pkgs/development/haskell-modules/configuration-lts-4.0.nix M pkgs/development/haskell-modules/configuration-lts-4.1.nix M pkgs/development/haskell-modules/configuration-lts-4.2.nix M pkgs/development/haskell-modules/configuration-lts-5.0
Re: [Nix-dev] Stackage Support Will Be Discontinued
Peter Simons writes: > Hi Anthony, > > > I draw a distinction between newer minor versions obsoleting old ones > > for purposes of bug fixes vs. for purposes of freezing packages. > > I am sorry, but I don't understand that distinction. In your original > response you suggested that dropping old LTS major releases like LTS-4 > from Nixpkgs would reduce your ability to use Nix, i.e. it would make > Nixpkgs less useful to you than it is today. I have a hard time seeing > how what might be the case, so I wonder whether you'd mind explaining to > me a concrete use case that works for you today but that won't work > after LTS-4 has been dropped? Someone who has a project that works with package versions in LTS-4, but hasn't yet been upgraded to LTS-5 or 6. They can simply refer to LTS-4 in their shell.nix for haskell packages. > > The Stackage design is such that they *can* release bug fixes for > > older versions to help their users. > > Yes, I totally agree. Once Stackage starts releasing updates for older > LTS versions, it's a completely different situation and then carrying > around older LTS major releases would actually make sense. > > > > You are removing that opportunity because it hasn't been used yet. > > I don't intend to remove any "opportunities" here. All I want to remove > is some 850,000 lines of untested, unmaintained code from the Nixpkgs > repository. If there is a compelling use case for that code, then let's > talk about it! At the moment, however, the cost / benefit ratio of > keeping all those package sets around strikes me as bad, really, and I > don't think we should keep distributing that code unless there's a real > benefit to the effort. If it's 850,000 lines of code, then that really seems like a Nix issue. If the point here is to declare bankruptcy and tell people to use stack which is able to refer to multiple versions of packages, then let's call it that. > > As companies adopt Stackage package sets, they will have applications > > in production that they, A) really want bug fixes for; and B) do not > > want to keep on the hackage treadmill by following new releases. If a > > bug is found in an LTS-5 package within the next few months, a stink > > will be raised. > > I think everyone agrees that we *want* LTS-5 updates to come out even > after the release of LTS-6. Whether that is actually going to happen or > not, however, is speculation and neither you nor me can possibly know. I know that today a team using Nix can refer to LTS-5 in nixpkgs, and not need to make any changes to adopt LTS-6 until they are ready. I know that should a problem emerge with LTS-5, a project using stack has a good chance of benefiting from a new Stackage release. I know that after the changes you are making, the team using LTS-5 in nixpkgs will not have a working environment until they address any of the 5->6 breaking changes. > >> In Nix, we [freeze dependencies] by tagging a specific version of > >> Nixpkgs and sticking to that. Not only will that freeze the Haskell > >> dependencies, but it will also freeze all other dependencies, too. > > > > This is a big step backwards. You object that Stackage has not yet > > used their existing mechanism for releasing bug fixes for older > > Haskell libraries, and respond by promoting a mechanism that admits > > no bug fixes for any software at all. > > I have no idea what you are talking about. Nix offers a myriad of > different ways to cherry pick updates into a stable version of the > package set. Here's a quote that perhaps states it more clearly, "In Nix, we can solve these things by tagging a specific version of Nixpkgs and sticking to that. Not only will that freeze the Haskell dependencies, but it will also freeze all other dependencies, too." I saw on IRC that you use stack for some Haskell development and nixpkgs for other things, so I don't think there's much point in continuing this as it clarifies your intentions for the nixpkgs design. I have been using nix, and more recently nixpkgs, in place of stack, but if you are not then we simply have different goals and the issues I raise are not relevant. Anthony ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] 32ff5b: krita: init at 3.0
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 32ff5bbc3088ca9afff585898947ecf173ffb9a1 https://github.com/NixOS/nixpkgs/commit/32ff5bbc3088ca9afff585898947ecf173ffb9a1 Author: Nikolay Amiantov Date: 2016-06-01 (Wed, 01 Jun 2016) Changed paths: A pkgs/applications/graphics/krita/default.nix M pkgs/top-level/all-packages.nix Log Message: --- krita: init at 3.0 Commit: 69e97f8a4524eb57633faf1c71ea1fc5da6c05ed https://github.com/NixOS/nixpkgs/commit/69e97f8a4524eb57633faf1c71ea1fc5da6c05ed Author: Nikolay Amiantov Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: A pkgs/applications/graphics/krita/default.nix M pkgs/top-level/all-packages.nix Log Message: --- Merge pull request #15891 from abbradar/krita krita: init at 3.0 Compare: https://github.com/NixOS/nixpkgs/compare/e6fdc9f7f04c...69e97f8a4524___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 97d791: qt56: 5.6.0 -> 5.6.1
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 97d791978cca24515409b53c9cc0cef28f972ea8 https://github.com/NixOS/nixpkgs/commit/97d791978cca24515409b53c9cc0cef28f972ea8 Author: Nikolay Amiantov Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/libraries/qt-5/5.6/fetchsrcs.sh M pkgs/development/libraries/qt-5/5.6/qtbase/cmake-paths.patch M pkgs/development/libraries/qt-5/5.6/qtbase/compose-search-path.patch M pkgs/development/libraries/qt-5/5.6/qtbase/decrypt-ssl-traffic.patch M pkgs/development/libraries/qt-5/5.6/qtbase/default.nix M pkgs/development/libraries/qt-5/5.6/qtbase/dlopen-dbus.patch M pkgs/development/libraries/qt-5/5.6/qtbase/dlopen-gl.patch M pkgs/development/libraries/qt-5/5.6/qtbase/dlopen-gtkstyle.patch M pkgs/development/libraries/qt-5/5.6/qtbase/dlopen-libXcursor.patch M pkgs/development/libraries/qt-5/5.6/qtbase/dlopen-openssl.patch M pkgs/development/libraries/qt-5/5.6/qtbase/dlopen-resolv.patch M pkgs/development/libraries/qt-5/5.6/qtbase/libressl.patch M pkgs/development/libraries/qt-5/5.6/qtbase/mkspecs-libgl.patch M pkgs/development/libraries/qt-5/5.6/qtbase/nix-profiles-library-paths.patch M pkgs/development/libraries/qt-5/5.6/qtbase/tzdir.patch M pkgs/development/libraries/qt-5/5.6/qtbase/xdg-config-dirs.patch M pkgs/development/libraries/qt-5/5.6/srcs.nix Log Message: --- qt56: 5.6.0 -> 5.6.1 Commit: 7b84294bd94b66111c4360fa9036d6bf410a1207 https://github.com/NixOS/nixpkgs/commit/7b84294bd94b66111c4360fa9036d6bf410a1207 Author: Nikolay Amiantov Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/applications/networking/instant-messengers/telegram/tdesktop/default.nix Log Message: --- tdesktop: fix with new Qt Commit: e6fdc9f7f04cb1eead940117e72da94fb5e0e125 https://github.com/NixOS/nixpkgs/commit/e6fdc9f7f04cb1eead940117e72da94fb5e0e125 Author: Thomas Tuegel Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/applications/networking/instant-messengers/telegram/tdesktop/default.nix M pkgs/development/libraries/qt-5/5.6/fetchsrcs.sh M pkgs/development/libraries/qt-5/5.6/qtbase/cmake-paths.patch M pkgs/development/libraries/qt-5/5.6/qtbase/compose-search-path.patch M pkgs/development/libraries/qt-5/5.6/qtbase/decrypt-ssl-traffic.patch M pkgs/development/libraries/qt-5/5.6/qtbase/default.nix M pkgs/development/libraries/qt-5/5.6/qtbase/dlopen-dbus.patch M pkgs/development/libraries/qt-5/5.6/qtbase/dlopen-gl.patch M pkgs/development/libraries/qt-5/5.6/qtbase/dlopen-gtkstyle.patch M pkgs/development/libraries/qt-5/5.6/qtbase/dlopen-libXcursor.patch M pkgs/development/libraries/qt-5/5.6/qtbase/dlopen-openssl.patch M pkgs/development/libraries/qt-5/5.6/qtbase/dlopen-resolv.patch M pkgs/development/libraries/qt-5/5.6/qtbase/libressl.patch M pkgs/development/libraries/qt-5/5.6/qtbase/mkspecs-libgl.patch M pkgs/development/libraries/qt-5/5.6/qtbase/nix-profiles-library-paths.patch M pkgs/development/libraries/qt-5/5.6/qtbase/tzdir.patch M pkgs/development/libraries/qt-5/5.6/qtbase/xdg-config-dirs.patch M pkgs/development/libraries/qt-5/5.6/srcs.nix Log Message: --- Merge pull request #16092 from abbradar/qt561 Qt: 5.6.0 -> 5.6.1 Compare: https://github.com/NixOS/nixpkgs/compare/04ad2ebfb287...e6fdc9f7f04c___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Stackage Support Will Be Discontinued
Hi Anthony, > I draw a distinction between newer minor versions obsoleting old ones > for purposes of bug fixes vs. for purposes of freezing packages. I am sorry, but I don't understand that distinction. In your original response you suggested that dropping old LTS major releases like LTS-4 from Nixpkgs would reduce your ability to use Nix, i.e. it would make Nixpkgs less useful to you than it is today. I have a hard time seeing how what might be the case, so I wonder whether you'd mind explaining to me a concrete use case that works for you today but that won't work after LTS-4 has been dropped? > The Stackage design is such that they *can* release bug fixes for > older versions to help their users. Yes, I totally agree. Once Stackage starts releasing updates for older LTS versions, it's a completely different situation and then carrying around older LTS major releases would actually make sense. > You are removing that opportunity because it hasn't been used yet. I don't intend to remove any "opportunities" here. All I want to remove is some 850,000 lines of untested, unmaintained code from the Nixpkgs repository. If there is a compelling use case for that code, then let's talk about it! At the moment, however, the cost / benefit ratio of keeping all those package sets around strikes me as bad, really, and I don't think we should keep distributing that code unless there's a real benefit to the effort. > As companies adopt Stackage package sets, they will have applications > in production that they, A) really want bug fixes for; and B) do not > want to keep on the hackage treadmill by following new releases. If a > bug is found in an LTS-5 package within the next few months, a stink > will be raised. I think everyone agrees that we *want* LTS-5 updates to come out even after the release of LTS-6. Whether that is actually going to happen or not, however, is speculation and neither you nor me can possibly know. >> In Nix, we [freeze dependencies] by tagging a specific version of >> Nixpkgs and sticking to that. Not only will that freeze the Haskell >> dependencies, but it will also freeze all other dependencies, too. > > This is a big step backwards. You object that Stackage has not yet > used their existing mechanism for releasing bug fixes for older > Haskell libraries, and respond by promoting a mechanism that admits > no bug fixes for any software at all. I have no idea what you are talking about. Nix offers a myriad of different ways to cherry pick updates into a stable version of the package set. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] 4959bd: io: fix evaluation by adding maintainers.vrthra
Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: 4959bd75db62589691112f871b070b81382092a8 https://github.com/NixOS/nixpkgs/commit/4959bd75db62589691112f871b070b81382092a8 Author: Vladimír Čunát Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M lib/maintainers.nix Log Message: --- io: fix evaluation by adding maintainers.vrthra ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] NixOps - merge config files
Erik,
https://nixos.org/nixops/manual/#opt-deployment.keys
Deployment keys won't end up in nix store, I think they are deployed using
ssh just to /run/keys. They also will be removed after reboot as /run will
disappear, untill you set some other option.
Also there was a thread on this list few weeks ago when somebody posted
solution to preserve keys between reboots usint systemd jobs.
2016-06-09 17:57 GMT+01:00 4levels <4lev...@gmail.com>:
> Hi Kevin,
>
> Thanks for the extra info!
> I was wondering though, if the generated config files do end up in
> /nix/store anyway, does it even make a difference if I use the
> deployment.keys method? Or is there another way to have eg. a php script
> read from these keys without actually writing them out?
>
> Symfony uses yml files, WordPress uses php files, and so on.. Each project
> is defined as a service and I generate these files in my various let
> statements..
>
> Personally I don't mind these files sitting in /nix/store as I'm the only
> one with ssh access to these machines..
>
> Kind regards,
>
>
> Erik
>
> On Thu, Jun 9, 2016, 17:16 Kevin Cox wrote:
>
>> On 09/06/16 11:03, 4levels wrote:
>> > Hi Kevin,
>> >
>> > I'm very curious how you setup sensitive information using
>> deployment.keys
>> > This still seems like the best option to do this, but I failed to get
>> > it working..
>> >
>> > Could you be so kind to post a small example, showing how you define
>> > the keys and use them in functions that generate eg. a config file?
>>
>> Here are two examples where I read the key out of a secret directory
>> (encrypted with git-crypt). Note that I don't generate any of my config
>> files, but that is theoretically possible.
>>
>> deployment.keys.mesos.text = "root ${builtins.readFile
>> ../secret/mesos-secret}";
>> deployment.keys.sumologic.text = builtins.readFile ../secret/sumologic;
>>
>> And this example is importing a nix expression. Note that I'm not using
>> deployment.keys so this is accessible to anyone (on the server) as it
>> lands in the Nix store IIUC.
>>
>> networking.defaultMailServer = import ../secret/smtp.nix;
>>
>>
>>
>>
--
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] de8427: qt56.qtbase: propagate build inputs correctly
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: de842765bec692a5b1bf00063bc98406599d07b2 https://github.com/NixOS/nixpkgs/commit/de842765bec692a5b1bf00063bc98406599d07b2 Author: Thomas Tuegel Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/libraries/qt-5/5.6/qtbase/setup-hook.sh Log Message: --- qt56.qtbase: propagate build inputs correctly Commit: 98bb89b9d0265eeaa71538dba1783a383c24d97e https://github.com/NixOS/nixpkgs/commit/98bb89b9d0265eeaa71538dba1783a383c24d97e Author: Thomas Tuegel Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/desktops/kde-5/frameworks-5.22/extra-cmake-modules/setup-hook.sh Log Message: --- kde5.extra-cmake-modules: propagate build inputs correctly Commit: aea0ff96deacacb256ee20f35866883af739aa78 https://github.com/NixOS/nixpkgs/commit/aea0ff96deacacb256ee20f35866883af739aa78 Author: Thomas Tuegel Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/applications/display-managers/sddm/default.nix Log Message: --- sddm: run phase hooks Commit: c608230a614b74eb6cf50b36269c28ddebc99d98 https://github.com/NixOS/nixpkgs/commit/c608230a614b74eb6cf50b36269c28ddebc99d98 Author: Thomas Tuegel Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M nixos/modules/services/x11/desktop-managers/kde5.nix Log Message: --- nixos/kde5: include setup hook and icons with sddm theme Fixes #16094. Commit: 04ad2ebfb28756c823b3070499740bd3e9cb147f https://github.com/NixOS/nixpkgs/commit/04ad2ebfb28756c823b3070499740bd3e9cb147f Author: Thomas Tuegel Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M nixos/modules/services/x11/desktop-managers/kde5.nix M pkgs/applications/display-managers/sddm/default.nix M pkgs/desktops/kde-5/frameworks-5.22/extra-cmake-modules/setup-hook.sh M pkgs/development/libraries/qt-5/5.6/qtbase/setup-hook.sh Log Message: --- Merge branch 'kde-propagate' Compare: https://github.com/NixOS/nixpkgs/compare/09d63127de6e...04ad2ebfb287___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-dev] Broken nix database/store.
Hi, Due to a wrong manipulation when activating dir_index on my root partition, I have now plenty of live orphaned paths in my store (about 5G) like this one: |$ nix-store -q --referrers-closure /nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2 /nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2 $ nix-store --delete /nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2 finding garbage collector roots... error: cannot delete path ‘/nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2’ since it is still alive 0 store paths deleted, 0.00 MiB freed $ nix-store --delete --ignore-liveness /nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2 error: you are not allowed to ignore liveness 0 store paths deleted, 0.00 MiB freed $ sudo nix-store --delete /nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2 finding garbage collector roots... error: cannot delete path ‘/nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2’ since it is still alive 0 store paths deleted, 0.00 MiB freed $ sudo nix-store --delete --ignore-liveness /nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2 finding garbage collector roots... deleting ‘/nix/store/4zhkw0g564g3ljdpnn8j5krrsvcxildn-libXcomposite-0.4.4.tar.bz2’ deleting ‘/nix/store/trash’ deleting unused links... note: currently hard linking saves 1754.97 MiB 1 store paths deleted, 0.27 MiB freed | Is there some repair command to update liveness of paths ? nix-store --verify --check-contents --repair finds nothing useful. Regards, -- Layus. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOps - merge config files
Hi Kevin,
Thanks for the extra info!
I was wondering though, if the generated config files do end up in
/nix/store anyway, does it even make a difference if I use the
deployment.keys method? Or is there another way to have eg. a php script
read from these keys without actually writing them out?
Symfony uses yml files, WordPress uses php files, and so on.. Each project
is defined as a service and I generate these files in my various let
statements..
Personally I don't mind these files sitting in /nix/store as I'm the only
one with ssh access to these machines..
Kind regards,
Erik
On Thu, Jun 9, 2016, 17:16 Kevin Cox wrote:
> On 09/06/16 11:03, 4levels wrote:
> > Hi Kevin,
> >
> > I'm very curious how you setup sensitive information using
> deployment.keys
> > This still seems like the best option to do this, but I failed to get
> > it working..
> >
> > Could you be so kind to post a small example, showing how you define
> > the keys and use them in functions that generate eg. a config file?
>
> Here are two examples where I read the key out of a secret directory
> (encrypted with git-crypt). Note that I don't generate any of my config
> files, but that is theoretically possible.
>
> deployment.keys.mesos.text = "root ${builtins.readFile
> ../secret/mesos-secret}";
> deployment.keys.sumologic.text = builtins.readFile ../secret/sumologic;
>
> And this example is importing a nix expression. Note that I'm not using
> deployment.keys so this is accessible to anyone (on the server) as it
> lands in the Nix store IIUC.
>
> networking.defaultMailServer = import ../secret/smtp.nix;
>
>
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] 09d631: Revert "qt56: 5.6.0 -> 5.6.1"
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 09d63127de6ed74be5947322f8af3b0c8b393374 https://github.com/NixOS/nixpkgs/commit/09d63127de6ed74be5947322f8af3b0c8b393374 Author: Thomas Tuegel Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/libraries/qt-5/5.6/fetchsrcs.sh M pkgs/development/libraries/qt-5/5.6/srcs.nix Log Message: --- Revert "qt56: 5.6.0 -> 5.6.1" This reverts commit 4d2cf4baaccf093a63b7e76793bffdc339f2379d. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] Success: Hydra job nixpkgs:trunk:tarball on x86_64-linux
Hi, The status of Hydra job ‘nixpkgs:trunk:tarball’ (on x86_64-linux) has changed from "Failed" to "Success". For details, see https://hydra.nixos.org/build/36745433 This may be due to 3 commits by Franz Pletz or Thomas Tuegel . Yay! Regards, The Hydra build daemon. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 45d4d6: luaPackages.luaexpat: fix case of LUA_LDIR make fl...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 45d4d6212274acd80cf2c6a8bcbca2ba1107d313 https://github.com/NixOS/nixpkgs/commit/45d4d6212274acd80cf2c6a8bcbca2ba1107d313 Author: Franz Pletz Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/top-level/lua-packages.nix Log Message: --- luaPackages.luaexpat: fix case of LUA_LDIR make flag Commit: a0996c2c60faa1644a0f35b002a35d5f52ba7a37 https://github.com/NixOS/nixpkgs/commit/a0996c2c60faa1644a0f35b002a35d5f52ba7a37 Author: Franz Pletz Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/libraries/libressl/2.3.nix Log Message: --- libressl: 2.3.4 -> 2.3.5 Compare: https://github.com/NixOS/nixpkgs/compare/83c40ada7e23...a0996c2c60fa___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Stackage Support Will Be Discontinued
Peter Simons writes: > Hi Anthony, > > > I know you didn't ask for feedback [...]. > > I'm always happy to get feedback! > > > If the top priority is receiving bug fixes, then keeping an LTS-4, > > LTS-5, LTS-6, etc. that tracks the most recent minor version makes > > sense. > > You seem to be saying that keeping an old major release like LTS-4 > around would somehow help us receive more bug fixes, but I can't see how > that would be true. According to git://github.com/fpco/lts-haskell.git, > the last time any LTS-4 update occurred was on 2016-01-18 -- almost half > a year ago. Surely, there have been point updates that fix bugs between > then and now, but LTS-4 does not seem to receive them, no? That is > because no-one maintains LTS-4. Stackage has moved on to LTS-5, or > rather: LTS-6 by now. > > So how exactly do we receive more bug fixes by distributing LTS-4? I meant that just tracking the latest minor version gets you everything possible regarding bug fixes. This was by way of agreement with your point that newer minor releases obsolete older ones. I go on to draw a distinction between newer minor versions obsoleting old ones for purposes of bug fixes vs. for purposes of freezing packages. > > > You say, "Stackage does not "maintain" any of its LTS releases," but > > the minor releases are precisely the offered maintenance. > > The thing is just that minor releases occur only for the latest major > release. LTS-6 has minor release at the moment, but LTS-5, LTS-4, etc. > do not! I agree that it would make sense to continue to distribute LTS-4 > if there were further minor releases to come out for that package set. > But there won't be any. As far as Stackage is concerned, LTS-4 is dead. The Stackage design is such that they *can* release bug fixes for older versions to help their users. You are removing that opportunity because it hasn't been used yet. Stackage is, relative to Haskell, very new. I think LTS-5 is far more widely used than previous major releases, and therefore stands a much greater chance of seeing a bugfix release even now, after the advent of LTS-6. The use of this safety feature is correlated to adoption: as companies adopt Stackage package sets, they will have applications in production that they, A) really want bug fixes for; and B) do not want to keep on the hackage treadmill by following new releases. If a bug is found in an LTS-5 package within the next few months, a stink will be raised. > > Furthermore, there is no reason a new LTS-5 release can not be issued > > after the first release of LTS-6. > > Sure, this *could* happen and it would be great! Then we'd have a real > long-term supported package set that would be worth-while to distribute. > > > > The cultural prominence of Stackage means that the need for security > > fixes to older versions can actually be promulgated because Stackage > > has users. > > I am sorry, but I have no idea what that sentence means. It means that problems get publicity. When there are notable changes to package versions in Stackage (e.g. with aeson), there is a reddit discussion, posts on twitter, and chatter on IRC. This is the kind of herd immunity that Stackage provides: if one person finds a problem with a version of a library included in a Stackage package set, they can raise an alarm that is easy for everyone to interpret and address. Pre-Stackage, this rarely if ever happened because every application in production was running against a unique collection of versions that the cabal solver picked on an arbitrary day. > > > For a modest application, specifying a particular Stackage release is > > a concise way of freezing Haskell dependencies. > > In Nix, we can solve these things by tagging a specific version of > Nixpkgs and sticking to that. Not only will that freeze the Haskell > dependencies, but it will also freeze all other dependencies, too. This is a big step backwards. You object that Stackage has not yet used their existing mechanism for releasing bug fixes for older Haskell libraries, and respond by promoting a mechanism that admits no bug fixes for any software at all. > > > A typical Stackage definition is about 70KB. > > Huh? That's not what I am seeing in git://github.com/fpco/lts-haskell.git: > >$ ls -lh lts-6.2.yaml >-rw-r--r-- 1 simons users 4.7M Jun 6 11:58 lts-6.2.yaml Your data here is quite disingenuous: that file contains lists of github users, six hashes per package, a kind of reverse dependency information (users), and I do not know what else to aid with Stackage maintenance. If you are a Haskell programmer and wish to use Stackage versions, you do this, $ curl https://www.stackage.org/lts-6.2/cabal.config > cabal.config $ ls -lh cabal.config -rw-r--r-- 1 acowley staff69K Jun 8 20:22 cabal.config Those are the versions of packages on hackage that constitute a Stackage release. nixpkgs will need additional data to address your point about offi
Re: [Nix-dev] NixOps - merge config files
On 09/06/16 11:03, 4levels wrote:
> Hi Kevin,
>
> I'm very curious how you setup sensitive information using deployment.keys
> This still seems like the best option to do this, but I failed to get
> it working..
>
> Could you be so kind to post a small example, showing how you define
> the keys and use them in functions that generate eg. a config file?
Here are two examples where I read the key out of a secret directory
(encrypted with git-crypt). Note that I don't generate any of my config
files, but that is theoretically possible.
deployment.keys.mesos.text = "root ${builtins.readFile
../secret/mesos-secret}";
deployment.keys.sumologic.text = builtins.readFile ../secret/sumologic;
And this example is importing a nix expression. Note that I'm not using
deployment.keys so this is accessible to anyone (on the server) as it
lands in the Nix store IIUC.
networking.defaultMailServer = import ../secret/smtp.nix;
signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] bfa328: First programs extracted from go-packages: deis an...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: bfa32800c3df6dd3a8e23bd239ec102173407249 https://github.com/NixOS/nixpkgs/commit/bfa32800c3df6dd3a8e23bd239ec102173407249 Author: Kamil Chmielewski Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: A pkgs/development/go-modules/libs.json A pkgs/development/tools/deis/default.nix A pkgs/tools/misc/gawp/default.nix M pkgs/top-level/all-packages.nix M pkgs/top-level/go-packages.nix Log Message: --- First programs extracted from go-packages: deis and gawp Commit: 5c2628a7049841b152b304443e7a364f60e1768b https://github.com/NixOS/nixpkgs/commit/5c2628a7049841b152b304443e7a364f60e1768b Author: Kamil Chmielewski Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/tools/misc/gawp/default.nix A pkgs/tools/misc/gawp/deps.json Log Message: --- When using common deps include only specified packages, not all set Commit: 81f3092e1168ef3f149031fca5acd78009acd2e5 https://github.com/NixOS/nixpkgs/commit/81f3092e1168ef3f149031fca5acd78009acd2e5 Author: Kamil Chmielewski Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/go-modules/generic/default.nix M pkgs/development/go-modules/libs.json M pkgs/development/tools/deis/default.nix A pkgs/development/tools/deis/deps.json M pkgs/tools/misc/gawp/default.nix Log Message: --- Reusing go libs in deis build Commit: dfe1064b4e49fcda317021e183e85e419b33b473 https://github.com/NixOS/nixpkgs/commit/dfe1064b4e49fcda317021e183e85e419b33b473 Author: Kamil Chmielewski Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: A pkgs/tools/misc/asciinema/default.nix M pkgs/top-level/all-packages.nix M pkgs/top-level/go-packages.nix Log Message: --- asciinema: top level pkgs extracted from goPackages Commit: dbf48cd10baf816d1ce48829f169a531165a8f2d https://github.com/NixOS/nixpkgs/commit/dbf48cd10baf816d1ce48829f169a531165a8f2d Author: Kamil Chmielewski Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: A pkgs/tools/misc/fzf/default.nix A pkgs/tools/misc/fzf/deps.json M pkgs/top-level/all-packages.nix M pkgs/top-level/go-packages.nix Log Message: --- fzf: application extracted from goPackages Commit: 89a256e463403dab84d89b1bc4563c6b95951383 https://github.com/NixOS/nixpkgs/commit/89a256e463403dab84d89b1bc4563c6b95951383 Author: Kamil Chmielewski Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/go-modules/libs.json A pkgs/servers/interlock/default.nix A pkgs/servers/interlock/deps.json M pkgs/top-level/all-packages.nix M pkgs/top-level/go-packages.nix Log Message: --- interlock: extracted from goPackages Commit: 387246080b2cd9675d7fcdab3ad528a4048842b5 https://github.com/NixOS/nixpkgs/commit/387246080b2cd9675d7fcdab3ad528a4048842b5 Author: Kamil Chmielewski Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/go-modules/libs.json A pkgs/tools/misc/mongodb-tools/default.nix A pkgs/tools/misc/mongodb-tools/deps.json M pkgs/top-level/all-packages.nix M pkgs/top-level/go-packages.nix Log Message: --- mongodb-tools: extracted from goPackages Commit: e5b9d23de7c4687fc0356c14cf5105d1cc809178 https://github.com/NixOS/nixpkgs/commit/e5b9d23de7c4687fc0356c14cf5105d1cc809178 Author: Kamil Chmielewski Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: A pkgs/tools/networking/flannel/default.nix M pkgs/top-level/all-packages.nix M pkgs/top-level/go-packages.nix Log Message: --- flannel: extracted from goPackages Commit: ece0626593674e4962a432ee685df54917adaa0b https://github.com/NixOS/nixpkgs/commit/ece0626593674e4962a432ee685df54917adaa0b Author: Kamil Chmielewski Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: A pkgs/applications/version-management/git-lfs/default.nix M pkgs/top-level/all-packages.nix M pkgs/top-level/go-packages.nix Log Message: --- git-lfs: extracted from goPackages Commit: ce81a8a65dcc7209159fcd35bf1fc703e2ec56aa https://github.com/NixOS/nixpkgs/commit/ce81a8a65dcc7209159fcd35bf1fc703e2ec56aa Author: Kamil Chmielewski Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/go-modules/libs.json A pkgs/tools/filesystems/go-mtpfs/default.nix A pkgs/tools/filesystems/go-mtpfs/deps.json M pkgs/top-level/all-packages.nix M pkgs/top-level/go-packages.nix Log Message: --- go-mtpfs: extracted from goPackages Commit: 977f23ca37d4381d3cdc97b437f9fb7b0e03740d https://github.com/NixOS/nixpkgs/commit/977f23ca37d4381d3cdc97b437f9fb7b0e03740d Author: Kamil Chmielewski Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths:
Re: [Nix-dev] NixOps - merge config files
Hi Kevin, I'm very curious how you setup sensitive information using deployment.keys This still seems like the best option to do this, but I failed to get it working.. Could you be so kind to post a small example, showing how you define the keys and use them in functions that generate eg. a config file? Kind regards, Erik On Thu, Jun 9, 2016 at 4:30 PM Kevin Cox wrote: > On 09/06/16 10:21, 4levels wrote: > > Hi Nix Devs, > > > > I've tried using the deployment.keys but that seems to be only there for > > user accounts and not for custom configurations. As I need multiple > > keys for each platform (eg. symfony, wordpress - cipher, key, database > > password, admin user password etc etc) it seems that deployment.keys > > will not work for this purpose. > > > > I don't know what you mean by "only there for user accounts". I use > deployment.keys for most of the things you describe and it works fine. > > > I'm now resorting to using builtins.readFile and creating separate files > > for the passwords in a folder I can then encrypt with git-crypt. > > This way I'm also able to use conflicting nix characters in the > > passwords as well. > > This seems like a different issue. Are you talking about keeping the > keys private in the configuration or on the server (or both)? > > Although for keeping the keys private in the config I use git-crypt as > well. I have a directory called "secrets" that I store the files in. > Some I keep as text files and read using `builtins.readFile` and some I > leave as nix expressions and simply import them. > > > > > As a last question here I was wondering if there's a way to strip > > trailing newlines when reading files with builtins.readFile as my IDE > > keeps adding a newline at the end of each file when saving. I'll post a > > new message here for this request as this is not relevant in this topic > > > > Text files have newlines at the end 😉 > > You can use lib.removeSuffix to drop that newline if it's a problem. > > Hope that helps, Kevin > > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] Failed: Hydra job nixpkgs:trunk:tarball on x86_64-linux
Hi, The status of Hydra job ‘nixpkgs:trunk:tarball’ (on x86_64-linux) has changed from "Success" to "Failed". For details, see https://hydra.nixos.org/build/36745160 This may be due to 5 commits by Joachim Fasting , Nikolay Amiantov , Ryan Mulligan or Thomas Tuegel . Go forth and fix it. Regards, The Hydra build daemon. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 4d2cf4: qt56: 5.6.0 -> 5.6.1
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 4d2cf4baaccf093a63b7e76793bffdc339f2379d https://github.com/NixOS/nixpkgs/commit/4d2cf4baaccf093a63b7e76793bffdc339f2379d Author: Thomas Tuegel Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/libraries/qt-5/5.6/fetchsrcs.sh M pkgs/development/libraries/qt-5/5.6/srcs.nix Log Message: --- qt56: 5.6.0 -> 5.6.1 Commit: c9ffb7e5f9dcd63773498eebc4db2dc2bba6a9a7 https://github.com/NixOS/nixpkgs/commit/c9ffb7e5f9dcd63773498eebc4db2dc2bba6a9a7 Author: Thomas Tuegel Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/libraries/qt-5/5.6/fetchsrcs.sh M pkgs/development/libraries/qt-5/5.6/srcs.nix Log Message: --- Merge branch 'qt-5.6' Compare: https://github.com/NixOS/nixpkgs/compare/edc36a0091c6...c9ffb7e5f9dc___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] use builtins.readFile and strip trailing newline
Hi Vladimir, I was just reading strings.nix, removeSuffix seems indeed the best candidate, thanks for confirming this! Kind regards, Erik aka 4levels On Thu, Jun 9, 2016 at 4:32 PM Vladimír Čunát wrote: > On 06/09/2016 04:24 PM, 4levels wrote: > > 'd like to know if there's an easy way to strip off the trailing newline > > from a file read with builtins.readFile. > > lib.removeSuffix "\n" > > --Vladimir > > > ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] use builtins.readFile and strip trailing newline
On 06/09/2016 04:24 PM, 4levels wrote: > 'd like to know if there's an easy way to strip off the trailing newline > from a file read with builtins.readFile. lib.removeSuffix "\n" --Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOps - merge config files
On 09/06/16 10:21, 4levels wrote: > Hi Nix Devs, > > I've tried using the deployment.keys but that seems to be only there for > user accounts and not for custom configurations. As I need multiple > keys for each platform (eg. symfony, wordpress - cipher, key, database > password, admin user password etc etc) it seems that deployment.keys > will not work for this purpose. > I don't know what you mean by "only there for user accounts". I use deployment.keys for most of the things you describe and it works fine. > I'm now resorting to using builtins.readFile and creating separate files > for the passwords in a folder I can then encrypt with git-crypt. > This way I'm also able to use conflicting nix characters in the > passwords as well. This seems like a different issue. Are you talking about keeping the keys private in the configuration or on the server (or both)? Although for keeping the keys private in the config I use git-crypt as well. I have a directory called "secrets" that I store the files in. Some I keep as text files and read using `builtins.readFile` and some I leave as nix expressions and simply import them. > > As a last question here I was wondering if there's a way to strip > trailing newlines when reading files with builtins.readFile as my IDE > keeps adding a newline at the end of each file when saving. I'll post a > new message here for this request as this is not relevant in this topic > Text files have newlines at the end 😉 You can use lib.removeSuffix to drop that newline if it's a problem. Hope that helps, Kevin signature.asc Description: OpenPGP digital signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] use builtins.readFile and strip trailing newline
Hi Nix Devs, In a related question to have my sensitive info separated from the normal NixOps configuration files, I am reading the passwords, keys, ciphers, ... from separate files (which are encrypted with git-crypt). My IDE (webstorm) keeps adding a trailing newline when saving these files. I know I can disable this behaviour in the IDE, but just to be sure I'd like to know if there's an easy way to strip off the trailing newline from a file read with builtins.readFile. Kind regards, Erik aka 4levels ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOps - merge config files
Hi Nix Devs,
I've tried using the deployment.keys but that seems to be only there for
user accounts and not for custom configurations. As I need multiple keys
for each platform (eg. symfony, wordpress - cipher, key, database password,
admin user password etc etc) it seems that deployment.keys will not work
for this purpose.
I'm now resorting to using builtins.readFile and creating separate files
for the passwords in a folder I can then encrypt with git-crypt.
This way I'm also able to use conflicting nix characters in the passwords
as well.
As a last question here I was wondering if there's a way to strip trailing
newlines when reading files with builtins.readFile as my IDE keeps adding a
newline at the end of each file when saving. I'll post a new message here
for this request as this is not relevant in this topic
Kind regards and thank you again for your support!
Erik aka 4levels
On Thu, Jun 9, 2016 at 12:29 PM 4levels <4lev...@gmail.com> wrote:
> Hi all,
>
> thank you for your replies!
> The thing is, I seem not to be able to merge at the level I need, at the
> hostname level that is.
> I mean, I need to have a file with the combined sets to be used by NixOps.
>
> There is an mapAttrsRecursive function in attrsets.nix that sounds like it
> does what I need.
>
> Currently I'm more inclined to go the deployment.keys way as pointed out
> by Tomasz
>
> I'll keep you posted here..
>
>
> Kind regards, your support and engagements are fantastic!
>
> Erik
>
> On Thu, Jun 9, 2016 at 12:23 PM Tomasz Czyż wrote:
>
>> Probably some function from
>> https://github.com/NixOS/nixpkgs/blob/master/lib/attrsets.nix could be
>> useful to merge them.
>>
>> 2016-06-09 11:19 GMT+01:00 zimbatm :
>>
>>> @dario: that doesn’t work recursively. { a = { x = 3; } } // { a = { y
>>> = 4; } produces { a = { y = 4 }; }
>>>
>>>
>>> On Thu, 9 Jun 2016 at 10:44 Dario Bertini wrote:
>>>
{a=1;}// {b=2;}
Yields
{a=1; b=2;}
Is this enough to help you?
On 9 June 2016 10:31:07 BST, 4levels <4lev...@gmail.com> wrote:
>Hi,
>
>thank you for your swift reply!
>I'd like to avoid to literally mention all sensitive config params in
>the
>network.nix config.
>
>What would be the "normal" procedure to recursively merge 2 attribute
>sets?
>
>
>So if I have in one file
>servers.nix: {
> vm01 = {
>services.symfony.platforms = {
> database = {
>username = "www";
> };
>};
> };
>}
>
>and in the other
>keys.nix: {
> vm01 = {
>services.symfony.platforms = {
> database = {
>password = "12345678";
> };
>};
> };
>}
>
>So they become one when building:
>{
> vm01 = {
>services.symfony.platforms = {
> database = {
>username = "www";
>password = "12345678";
> };
>};
> };
>}
>
>Kind regards,
>
>Erik
>
>On Thu, Jun 9, 2016 at 11:23 AM zimbatm wrote:
>
>> Hi,
>>
>> I don’t know where you are getting this error. All I can do is
>suggest a
>> workaround:
>>
>> In keys.nix:
>>
>> {
>> database_password = "12345678";
>> }
>>
>> In network.nix:
>>
>> let
>> secrets = import ./keys.nix {};in;
>> {
>> vm01 = {
>> { config, pkgs, ... }:
>> {
>> services.symfony.platforms.database.password =
>secrets.database_password;
>>
>> ..
>> }
>> }
>> }
>>
>>
>>
>> On Thu, 9 Jun 2016 at 07:54 4levels <4lev...@gmail.com> wrote:
>>
>>> Hi Nix Devs,
>>>
>>> I'm having some difficulties separating sensitive information from a
>nix
>>> expression used by NixOps.
>>>
>>> I keep the server config in a separate file, servers.nix:
>>> {
>>> vm01 =
>>> { config, pkgs, nodes, ... }:
>>> {
>>> deployment = {
>>> targetHost = "192.168.121.50";
>>> };
>>> ...
>>> }
>>> }
>>>
>>> Currently I have all relevant software config for each server in a
>nix
>>> expression platforms.nix as follows (where vm01 is the hostname):
>>> {
>>> vm01 =
>>> { config, pkgs, ... }:
>>> {
>>> services.symfony.platforms = {
>>> database = {
>>> username = "www";
>>> /* password = "1234567" -> moved to keys.nix */
>>> };
>>> ...
>>> }
>>> }
>>>
>>> I want to remove the sensitive info from this file and put it in a
>>> separate nix expression, eg. keys.nix, maintaining the same
>structure so
>>> the files can be merged.
>>>
>>> In keys.nix I currently h
[Nix-commits] [NixOS/nixpkgs] edc36a: grsecurity: 4.5.6-201606051644 -> 4.5.7-2016060808...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: edc36a0091c61cc60d3607d5e73ad22e078f8307 https://github.com/NixOS/nixpkgs/commit/edc36a0091c61cc60d3607d5e73ad22e078f8307 Author: Joachim Fasting Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/os-specific/linux/kernel/linux-grsecurity-4.5.nix M pkgs/os-specific/linux/kernel/patches.nix Log Message: --- grsecurity: 4.5.6-201606051644 -> 4.5.7-201606080852 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] b54fa1: zsnes: add desktop item
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: b54fa1e351074531628178cd4da7dccc7c334824 https://github.com/NixOS/nixpkgs/commit/b54fa1e351074531628178cd4da7dccc7c334824 Author: Ryan Mulligan Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/misc/emulators/zsnes/default.nix Log Message: --- zsnes: add desktop item add desktop item so zsnes can be used without the terminal add icons Commit: 2f1b3557477874c277f5dd99f128807f13393ea3 https://github.com/NixOS/nixpkgs/commit/2f1b3557477874c277f5dd99f128807f13393ea3 Author: Nikolay Amiantov Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/misc/emulators/zsnes/default.nix Log Message: --- Merge pull request #15983 from ryantm/zsnes zsnes: add desktop item Compare: https://github.com/NixOS/nixpkgs/compare/20c2ce4954d4...2f1b35574778___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] f1d757: build-support/grsecurity: simplify the grsecurityO...
Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: f1d7572a5fb8f327ca74307fe9e2722008e774ca https://github.com/NixOS/nixpkgs/commit/f1d7572a5fb8f327ca74307fe9e2722008e774ca Author: Joachim Fasting Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/build-support/grsecurity/default.nix Log Message: --- build-support/grsecurity: simplify the grsecurityOverrider Adding inputs required by gcc plugins to the ambient environment is sufficient. (cherry picked from commit 27035365ec98f839fa92c1807c36be967446e1a1) Fixes the build error: https://hydra.nixos.org/build/36725847/nixlog/1/raw Commit: 0e0bb8a1738ab454bf8d94bc3c3b1c08cd1012c5 https://github.com/NixOS/nixpkgs/commit/0e0bb8a1738ab454bf8d94bc3c3b1c08cd1012c5 Author: Joachim Fasting Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/build-support/grsecurity/default.nix Log Message: --- grsecurity: simplify preConfigure (cherry picked from commit 39db90eaf60999db2ffd13668b4619a2d57f76ad) Compare: https://github.com/NixOS/nixpkgs/compare/d6c4dc1094b1...0e0bb8a1738a___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Stackage Support Will Be Discontinued
Hi Anthony, > I know you didn't ask for feedback [...]. I'm always happy to get feedback! > If the top priority is receiving bug fixes, then keeping an LTS-4, > LTS-5, LTS-6, etc. that tracks the most recent minor version makes > sense. You seem to be saying that keeping an old major release like LTS-4 around would somehow help us receive more bug fixes, but I can't see how that would be true. According to git://github.com/fpco/lts-haskell.git, the last time any LTS-4 update occurred was on 2016-01-18 -- almost half a year ago. Surely, there have been point updates that fix bugs between then and now, but LTS-4 does not seem to receive them, no? That is because no-one maintains LTS-4. Stackage has moved on to LTS-5, or rather: LTS-6 by now. So how exactly do we receive more bug fixes by distributing LTS-4? > You say, "Stackage does not "maintain" any of its LTS releases," but > the minor releases are precisely the offered maintenance. The thing is just that minor releases occur only for the latest major release. LTS-6 has minor release at the moment, but LTS-5, LTS-4, etc. do not! I agree that it would make sense to continue to distribute LTS-4 if there were further minor releases to come out for that package set. But there won't be any. As far as Stackage is concerned, LTS-4 is dead. > Furthermore, there is no reason a new LTS-5 release can not be issued > after the first release of LTS-6. Sure, this *could* happen and it would be great! Then we'd have a real long-term supported package set that would be worth-while to distribute. > The cultural prominence of Stackage means that the need for security > fixes to older versions can actually be promulgated because Stackage > has users. I am sorry, but I have no idea what that sentence means. > For a modest application, specifying a particular Stackage release is > a concise way of freezing Haskell dependencies. In Nix, we can solve these things by tagging a specific version of Nixpkgs and sticking to that. Not only will that freeze the Haskell dependencies, but it will also freeze all other dependencies, too. > A typical Stackage definition is about 70KB. Huh? That's not what I am seeing in git://github.com/fpco/lts-haskell.git: $ ls -lh lts-6.2.yaml -rw-r--r-- 1 simons users 4.7M Jun 6 11:58 lts-6.2.yaml > Nix definitions require nearly 10x that space is unfortunate, but I > had expected a Nix solution to this issue rather than giving up on > versions altogether. Oh, come on. I wrote a very long and detailed explanation of *why* we give up on tracking Hackage, and to boil that whole article down to "it was using too much disk space" is just silly. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] 8eb439: Merge #16043: kernel: 4.4.11 -> 4.4.12
Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: 8eb439701ef881260ab8a29326c4c266445f92a0 https://github.com/NixOS/nixpkgs/commit/8eb439701ef881260ab8a29326c4c266445f92a0 Author: Vladimír Čunát Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/os-specific/linux/kernel/linux-4.4.nix Log Message: --- Merge #16043: kernel: 4.4.11 -> 4.4.12 (cherry picked from commit f9310c2eee39939cdb6a14e0b50c2139cebf4c08) Commit: e61983e6a58505086e963709bee1575a90804f1a https://github.com/NixOS/nixpkgs/commit/e61983e6a58505086e963709bee1575a90804f1a Author: Vladimír Čunát Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/os-specific/linux/kernel/linux-4.1.nix Log Message: --- Merge #16044: kernel: 4.1.20 -> 4.1.25 (cherry picked from commit c0895be3ee664dc558641c6654b8c11625c15364) Commit: d6c4dc1094b1865f5d7ac84618a8599b45ea9d4d https://github.com/NixOS/nixpkgs/commit/d6c4dc1094b1865f5d7ac84618a8599b45ea9d4d Author: Vladimír Čunát Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/os-specific/linux/kernel/linux-4.6.nix Log Message: --- Merge #16045: kernel: 4.6.0 -> 4.6.1 (cherry picked from commit 20c2ce4954d4ef67dc77cd773ee95e6d36784d01) Compare: https://github.com/NixOS/nixpkgs/compare/dd06c4e52bb5...d6c4dc1094b1___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] f3ebf1: kernel: 4.1.20 -> 4.1.25
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: f3ebf1376284629b3da9ed57774a31ae79a7ec53 https://github.com/NixOS/nixpkgs/commit/f3ebf1376284629b3da9ed57774a31ae79a7ec53 Author: Tim Steinbach Date: 2016-06-07 (Tue, 07 Jun 2016) Changed paths: M pkgs/os-specific/linux/kernel/linux-4.1.nix Log Message: --- kernel: 4.1.20 -> 4.1.25 Commit: a57cbf6546ddf226a4ea3201fd72d260c7154d3e https://github.com/NixOS/nixpkgs/commit/a57cbf6546ddf226a4ea3201fd72d260c7154d3e Author: Tim Steinbach Date: 2016-06-07 (Tue, 07 Jun 2016) Changed paths: M pkgs/os-specific/linux/kernel/linux-4.4.nix Log Message: --- kernel: 4.4.11 -> 4.4.12 Commit: 269b7d30a7ab049bd6dd0bb575f6cd9e4a601425 https://github.com/NixOS/nixpkgs/commit/269b7d30a7ab049bd6dd0bb575f6cd9e4a601425 Author: Tim Steinbach Date: 2016-06-07 (Tue, 07 Jun 2016) Changed paths: M pkgs/os-specific/linux/kernel/linux-4.6.nix Log Message: --- kernel: 4.6.0 -> 4.6.1 Commit: f9310c2eee39939cdb6a14e0b50c2139cebf4c08 https://github.com/NixOS/nixpkgs/commit/f9310c2eee39939cdb6a14e0b50c2139cebf4c08 Author: Vladimír Čunát Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/os-specific/linux/kernel/linux-4.4.nix Log Message: --- Merge #16043: kernel: 4.4.11 -> 4.4.12 Commit: c0895be3ee664dc558641c6654b8c11625c15364 https://github.com/NixOS/nixpkgs/commit/c0895be3ee664dc558641c6654b8c11625c15364 Author: Vladimír Čunát Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/os-specific/linux/kernel/linux-4.1.nix Log Message: --- Merge #16044: kernel: 4.1.20 -> 4.1.25 Commit: 20c2ce4954d4ef67dc77cd773ee95e6d36784d01 https://github.com/NixOS/nixpkgs/commit/20c2ce4954d4ef67dc77cd773ee95e6d36784d01 Author: Vladimír Čunát Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/os-specific/linux/kernel/linux-4.6.nix Log Message: --- Merge #16045: kernel: 4.6.0 -> 4.6.1 Compare: https://github.com/NixOS/nixpkgs/compare/e52194f17d15...20c2ce4954d4___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] dd06c4: io: 2013.12.04 -> 2015.11.11
Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: dd06c4e52bb54171237eca8c6f113f1d550c7c13 https://github.com/NixOS/nixpkgs/commit/dd06c4e52bb54171237eca8c6f113f1d550c7c13 Author: Rahul Gopinath Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/interpreters/io/default.nix Log Message: --- io: 2013.12.04 -> 2015.11.11 Updating IO language to latest version (cherry picked from commit c860de987d5eb97a2c8d41e9e1a311c3cf988988) This also fixes the build ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] c860de: io: 2013.12.04 -> 2015.11.11
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: c860de987d5eb97a2c8d41e9e1a311c3cf988988 https://github.com/NixOS/nixpkgs/commit/c860de987d5eb97a2c8d41e9e1a311c3cf988988 Author: Rahul Gopinath Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/interpreters/io/default.nix Log Message: --- io: 2013.12.04 -> 2015.11.11 Updating IO language to latest version Commit: e52194f17d15b484fdfdf625fbe4cba759739920 https://github.com/NixOS/nixpkgs/commit/e52194f17d15b484fdfdf625fbe4cba759739920 Author: Joachim Fasting Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/interpreters/io/default.nix Log Message: --- Merge pull request #16061 from vrthra/io io: 2013.12.04 -> 2015.11.11 Compare: https://github.com/NixOS/nixpkgs/compare/cbca34b1a769...e52194f17d15___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 140e48: ffmpeg: 2.8.5 -> 3.0
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 140e48f3c1986f8bb5820e9a9bef394b3908ac62 https://github.com/NixOS/nixpkgs/commit/140e48f3c1986f8bb5820e9a9bef394b3908ac62 Author: Andrew Kelley Date: 2016-03-16 (Wed, 16 Mar 2016) Changed paths: A pkgs/development/libraries/ffmpeg/3.0.nix M pkgs/top-level/all-packages.nix Log Message: --- ffmpeg: 2.8.5 -> 3.0 Commit: 9876769698037d9eddac3bc136bfcf207a72ec9c https://github.com/NixOS/nixpkgs/commit/9876769698037d9eddac3bc136bfcf207a72ec9c Author: Vladimír Čunát Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/libraries/ffmpeg/3.0.nix Log Message: --- ffmpeg_3: 3.0 -> 3.0.2 Commit: 9bf611414740807312d05d8f782a02a471fe8e1e https://github.com/NixOS/nixpkgs/commit/9bf611414740807312d05d8f782a02a471fe8e1e Author: Vladimír Čunát Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/top-level/all-packages.nix Log Message: --- ffmpeg: use 2 as the default for now Commit: cbca34b1a769004181b1a1c0db56e42b45495d72 https://github.com/NixOS/nixpkgs/commit/cbca34b1a769004181b1a1c0db56e42b45495d72 Author: Vladimír Čunát Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: A pkgs/development/libraries/ffmpeg/3.0.nix M pkgs/top-level/all-packages.nix Log Message: --- Merge #13977: ffmpeg: add 3.0 version I made the default not change for now. Compare: https://github.com/NixOS/nixpkgs/compare/35f177fcc990...cbca34b1a769___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 4bc528: shadowsocks-libev: 2.4.6 -> 2.4.7
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 4bc528ce280d3a2e65ee3937949f4b8793928615 https://github.com/NixOS/nixpkgs/commit/4bc528ce280d3a2e65ee3937949f4b8793928615 Author: Jinjing Wang Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/tools/networking/shadowsocks-libev/default.nix Log Message: --- shadowsocks-libev: 2.4.6 -> 2.4.7 Commit: 35f177fcc990b9b6d6ef5f0cfcdd10c5deeed6fd https://github.com/NixOS/nixpkgs/commit/35f177fcc990b9b6d6ef5f0cfcdd10c5deeed6fd Author: Joachim Fasting Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/tools/networking/shadowsocks-libev/default.nix Log Message: --- Merge pull request #15951 from nfjinjing/shadowsocks-libev shadowsocks-libev: 2.4.6 -> 2.4.7 Compare: https://github.com/NixOS/nixpkgs/compare/376ba5f17f81...35f177fcc990___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 376ba5: dnscrypt-proxy service: update resolver list
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 376ba5f17f81a33be8ee6db6b43bd2b08e5a2491 https://github.com/NixOS/nixpkgs/commit/376ba5f17f81a33be8ee6db6b43bd2b08e5a2491 Author: Joachim Fasting Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M nixos/modules/services/networking/dnscrypt-proxy.nix Log Message: --- dnscrypt-proxy service: update resolver list ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 3b28b5: enlightenment: 0.20.8 -> 0.20.9
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 3b28b5673b67670ee61212f2043ef641c7d70dc6 https://github.com/NixOS/nixpkgs/commit/3b28b5673b67670ee61212f2043ef641c7d70dc6 Author: José Romildo Malaquias Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/desktops/enlightenment/enlightenment.nix Log Message: --- enlightenment: 0.20.8 -> 0.20.9 Commit: 687fff86c11602c8f0478791789559248ef0fd3d https://github.com/NixOS/nixpkgs/commit/687fff86c11602c8f0478791789559248ef0fd3d Author: Joachim Fasting Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/desktops/enlightenment/enlightenment.nix Log Message: --- Merge pull request #16087 from romildo/upd.enlightenment enlightenment: 0.20.8 -> 0.20.9 Compare: https://github.com/NixOS/nixpkgs/compare/7a29c403fd14...687fff86c116___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 8f4755: kernel: 4.5.5 -> 4.5.6
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 8f4755a0ae4d70577a62238f93ddf4849755212c https://github.com/NixOS/nixpkgs/commit/8f4755a0ae4d70577a62238f93ddf4849755212c Author: Tim Steinbach Date: 2016-06-07 (Tue, 07 Jun 2016) Changed paths: M pkgs/os-specific/linux/kernel/linux-4.5.nix Log Message: --- kernel: 4.5.5 -> 4.5.6 Commit: 7a29c403fd14ebfd6c4839bd281ac126abd4d828 https://github.com/NixOS/nixpkgs/commit/7a29c403fd14ebfd6c4839bd281ac126abd4d828 Author: Joachim Fasting Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/os-specific/linux/kernel/linux-4.5.nix Log Message: --- Merge pull request #16046 from NeQuissimus/kernel456 kernel: 4.5.5 -> 4.5.6 Compare: https://github.com/NixOS/nixpkgs/compare/b9428a45768e...7a29c403fd14___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 35c544: factor: disable build on i686-linux
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 35c544e6d4e685af7d3ef5cfc4294c094199e57f https://github.com/NixOS/nixpkgs/commit/35c544e6d4e685af7d3ef5cfc4294c094199e57f Author: Rahul Gopinath Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/compilers/factor-lang/default.nix Log Message: --- factor: disable build on i686-linux The factor language should be built only on x86_64 machines. Commit: b9428a45768e5b03469f36e39ab7a4178a0d37a4 https://github.com/NixOS/nixpkgs/commit/b9428a45768e5b03469f36e39ab7a4178a0d37a4 Author: Joachim Fasting Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/compilers/factor-lang/default.nix Log Message: --- Merge pull request #16089 from vrthra/factor factor: disable build on i686-linux Compare: https://github.com/NixOS/nixpkgs/compare/31f4a9b5590f...b9428a45768e___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 31f4a9: xfce.thunar: patch to avoid error
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 31f4a9b5590fdef5412f13e16888d2fa94f6f5f7 https://github.com/NixOS/nixpkgs/commit/31f4a9b5590fdef5412f13e16888d2fa94f6f5f7 Author: obadz Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/desktops/xfce/core/thunar-build.nix Log Message: --- xfce.thunar: patch to avoid error «the desktop file … is in an insecure location» which pops up when invoking desktop files that are symlinks to the /nix/store this error was added by this commit: https://github.com/xfce-mirror/thunar/commit/1ec8ff89ec5a3314fcd6a57f1475654ddecc9875 «Only allow direct execution of desktop files in an XDG directory and if they are executable.» ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] wordpress
Ah I see this: https://nixos.org/wiki/Wordpress I'll need to override the src of wordpress with my own version of wordpress. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOps - merge config files
Hi all,
thank you for your replies!
The thing is, I seem not to be able to merge at the level I need, at the
hostname level that is.
I mean, I need to have a file with the combined sets to be used by NixOps.
There is an mapAttrsRecursive function in attrsets.nix that sounds like it
does what I need.
Currently I'm more inclined to go the deployment.keys way as pointed out by
Tomasz
I'll keep you posted here..
Kind regards, your support and engagements are fantastic!
Erik
On Thu, Jun 9, 2016 at 12:23 PM Tomasz Czyż wrote:
> Probably some function from
> https://github.com/NixOS/nixpkgs/blob/master/lib/attrsets.nix could be
> useful to merge them.
>
> 2016-06-09 11:19 GMT+01:00 zimbatm :
>
>> @dario: that doesn’t work recursively. { a = { x = 3; } } // { a = { y =
>> 4; } produces { a = { y = 4 }; }
>>
>>
>> On Thu, 9 Jun 2016 at 10:44 Dario Bertini wrote:
>>
>>> {a=1;}// {b=2;}
>>> Yields
>>> {a=1; b=2;}
>>>
>>> Is this enough to help you?
>>>
>>> On 9 June 2016 10:31:07 BST, 4levels <4lev...@gmail.com> wrote:
>>> >Hi,
>>> >
>>> >thank you for your swift reply!
>>> >I'd like to avoid to literally mention all sensitive config params in
>>> >the
>>> >network.nix config.
>>> >
>>> >What would be the "normal" procedure to recursively merge 2 attribute
>>> >sets?
>>> >
>>> >
>>> >So if I have in one file
>>> >servers.nix: {
>>> > vm01 = {
>>> >services.symfony.platforms = {
>>> > database = {
>>> >username = "www";
>>> > };
>>> >};
>>> > };
>>> >}
>>> >
>>> >and in the other
>>> >keys.nix: {
>>> > vm01 = {
>>> >services.symfony.platforms = {
>>> > database = {
>>> >password = "12345678";
>>> > };
>>> >};
>>> > };
>>> >}
>>> >
>>> >So they become one when building:
>>> >{
>>> > vm01 = {
>>> >services.symfony.platforms = {
>>> > database = {
>>> >username = "www";
>>> >password = "12345678";
>>> > };
>>> >};
>>> > };
>>> >}
>>> >
>>> >Kind regards,
>>> >
>>> >Erik
>>> >
>>> >On Thu, Jun 9, 2016 at 11:23 AM zimbatm wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> I don’t know where you are getting this error. All I can do is
>>> >suggest a
>>> >> workaround:
>>> >>
>>> >> In keys.nix:
>>> >>
>>> >> {
>>> >> database_password = "12345678";
>>> >> }
>>> >>
>>> >> In network.nix:
>>> >>
>>> >> let
>>> >> secrets = import ./keys.nix {};in;
>>> >> {
>>> >> vm01 = {
>>> >> { config, pkgs, ... }:
>>> >> {
>>> >> services.symfony.platforms.database.password =
>>> >secrets.database_password;
>>> >>
>>> >> ..
>>> >> }
>>> >> }
>>> >> }
>>> >>
>>> >>
>>> >>
>>> >> On Thu, 9 Jun 2016 at 07:54 4levels <4lev...@gmail.com> wrote:
>>> >>
>>> >>> Hi Nix Devs,
>>> >>>
>>> >>> I'm having some difficulties separating sensitive information from a
>>> >nix
>>> >>> expression used by NixOps.
>>> >>>
>>> >>> I keep the server config in a separate file, servers.nix:
>>> >>> {
>>> >>> vm01 =
>>> >>> { config, pkgs, nodes, ... }:
>>> >>> {
>>> >>> deployment = {
>>> >>> targetHost = "192.168.121.50";
>>> >>> };
>>> >>> ...
>>> >>> }
>>> >>> }
>>> >>>
>>> >>> Currently I have all relevant software config for each server in a
>>> >nix
>>> >>> expression platforms.nix as follows (where vm01 is the hostname):
>>> >>> {
>>> >>> vm01 =
>>> >>> { config, pkgs, ... }:
>>> >>> {
>>> >>> services.symfony.platforms = {
>>> >>> database = {
>>> >>> username = "www";
>>> >>> /* password = "1234567" -> moved to keys.nix */
>>> >>> };
>>> >>> ...
>>> >>> }
>>> >>> }
>>> >>>
>>> >>> I want to remove the sensitive info from this file and put it in a
>>> >>> separate nix expression, eg. keys.nix, maintaining the same
>>> >structure so
>>> >>> the files can be merged.
>>> >>>
>>> >>> In keys.nix I currently have
>>> >>> {
>>> >>> vm01 = {
>>> >>> { config, pkgs, ... }:
>>> >>> {
>>> >>> services.symfony.platforms.database.password = "12345678";
>>> >>> ..
>>> >>> }
>>> >>> }
>>> >>> }
>>> >>>
>>> >>> I've modified my nixops deploy to have keys.nix loaded after the
>>> >>> servers.nix and platforms.nix files, but I keep getting errors like
>>> >"the
>>> >>> attribute password does not exist"
>>> >>>
>>> >>> I must be overlooking something obvious as all the other files I
>>> >define
>>> >>> in my deploy are being merged correctly.
>>> >>>
>>> >>> Can anyone advise me on how to achieve this?
>>> >>>
>>> >>> The underlying reason is that I'm using git-crypt to encrypt the
>>> >>> platforms.nix file, but this makes it impossible to work with
>>> >branches (or
>>> >>> git logs) etc. as the whole file is encrypted and git cannot merge
>>> >binary
>>> >>> files (it simply replaces them).
>>> >>>
>>> >>> Kind regards!
>>> >>>
>>> >>> Erik aka 4levels
>>> >>>
>>> >> ___
>>> >>> nix-dev mailing list
>>> >>> nix-dev@lists.science.uu.nl
>>> >>> http://lists.science.uu.nl/mail
Re: [Nix-dev] NixOps - merge config files
Probably some function from
https://github.com/NixOS/nixpkgs/blob/master/lib/attrsets.nix could be
useful to merge them.
2016-06-09 11:19 GMT+01:00 zimbatm :
> @dario: that doesn’t work recursively. { a = { x = 3; } } // { a = { y =
> 4; } produces { a = { y = 4 }; }
>
>
> On Thu, 9 Jun 2016 at 10:44 Dario Bertini wrote:
>
>> {a=1;}// {b=2;}
>> Yields
>> {a=1; b=2;}
>>
>> Is this enough to help you?
>>
>> On 9 June 2016 10:31:07 BST, 4levels <4lev...@gmail.com> wrote:
>> >Hi,
>> >
>> >thank you for your swift reply!
>> >I'd like to avoid to literally mention all sensitive config params in
>> >the
>> >network.nix config.
>> >
>> >What would be the "normal" procedure to recursively merge 2 attribute
>> >sets?
>> >
>> >
>> >So if I have in one file
>> >servers.nix: {
>> > vm01 = {
>> >services.symfony.platforms = {
>> > database = {
>> >username = "www";
>> > };
>> >};
>> > };
>> >}
>> >
>> >and in the other
>> >keys.nix: {
>> > vm01 = {
>> >services.symfony.platforms = {
>> > database = {
>> >password = "12345678";
>> > };
>> >};
>> > };
>> >}
>> >
>> >So they become one when building:
>> >{
>> > vm01 = {
>> >services.symfony.platforms = {
>> > database = {
>> >username = "www";
>> >password = "12345678";
>> > };
>> >};
>> > };
>> >}
>> >
>> >Kind regards,
>> >
>> >Erik
>> >
>> >On Thu, Jun 9, 2016 at 11:23 AM zimbatm wrote:
>> >
>> >> Hi,
>> >>
>> >> I don’t know where you are getting this error. All I can do is
>> >suggest a
>> >> workaround:
>> >>
>> >> In keys.nix:
>> >>
>> >> {
>> >> database_password = "12345678";
>> >> }
>> >>
>> >> In network.nix:
>> >>
>> >> let
>> >> secrets = import ./keys.nix {};in;
>> >> {
>> >> vm01 = {
>> >> { config, pkgs, ... }:
>> >> {
>> >> services.symfony.platforms.database.password =
>> >secrets.database_password;
>> >>
>> >> ..
>> >> }
>> >> }
>> >> }
>> >>
>> >>
>> >>
>> >> On Thu, 9 Jun 2016 at 07:54 4levels <4lev...@gmail.com> wrote:
>> >>
>> >>> Hi Nix Devs,
>> >>>
>> >>> I'm having some difficulties separating sensitive information from a
>> >nix
>> >>> expression used by NixOps.
>> >>>
>> >>> I keep the server config in a separate file, servers.nix:
>> >>> {
>> >>> vm01 =
>> >>> { config, pkgs, nodes, ... }:
>> >>> {
>> >>> deployment = {
>> >>> targetHost = "192.168.121.50";
>> >>> };
>> >>> ...
>> >>> }
>> >>> }
>> >>>
>> >>> Currently I have all relevant software config for each server in a
>> >nix
>> >>> expression platforms.nix as follows (where vm01 is the hostname):
>> >>> {
>> >>> vm01 =
>> >>> { config, pkgs, ... }:
>> >>> {
>> >>> services.symfony.platforms = {
>> >>> database = {
>> >>> username = "www";
>> >>> /* password = "1234567" -> moved to keys.nix */
>> >>> };
>> >>> ...
>> >>> }
>> >>> }
>> >>>
>> >>> I want to remove the sensitive info from this file and put it in a
>> >>> separate nix expression, eg. keys.nix, maintaining the same
>> >structure so
>> >>> the files can be merged.
>> >>>
>> >>> In keys.nix I currently have
>> >>> {
>> >>> vm01 = {
>> >>> { config, pkgs, ... }:
>> >>> {
>> >>> services.symfony.platforms.database.password = "12345678";
>> >>> ..
>> >>> }
>> >>> }
>> >>> }
>> >>>
>> >>> I've modified my nixops deploy to have keys.nix loaded after the
>> >>> servers.nix and platforms.nix files, but I keep getting errors like
>> >"the
>> >>> attribute password does not exist"
>> >>>
>> >>> I must be overlooking something obvious as all the other files I
>> >define
>> >>> in my deploy are being merged correctly.
>> >>>
>> >>> Can anyone advise me on how to achieve this?
>> >>>
>> >>> The underlying reason is that I'm using git-crypt to encrypt the
>> >>> platforms.nix file, but this makes it impossible to work with
>> >branches (or
>> >>> git logs) etc. as the whole file is encrypted and git cannot merge
>> >binary
>> >>> files (it simply replaces them).
>> >>>
>> >>> Kind regards!
>> >>>
>> >>> Erik aka 4levels
>> >>>
>> >> ___
>> >>> 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
>>
>> --
>> Sent from mobile. Please excuse my brevity.
>> ___
>> 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-commits] [NixOS/nixpkgs] cc174b: pidgin: simplify using the wrapped version
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: cc174b3d556945eff999efe44ab18dd7b3e99f76 https://github.com/NixOS/nixpkgs/commit/cc174b3d556945eff999efe44ab18dd7b3e99f76 Author: Vladimír Čunát Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/applications/networking/instant-messengers/pidgin/default.nix M pkgs/top-level/aliases.nix M pkgs/top-level/all-packages.nix Log Message: --- pidgin: simplify using the wrapped version Now only the `pidgin` attribute is exposed and it's wrapped based on whether the `plugins` parameter is overridden. Discussion: https://github.com/NixOS/nixpkgs/issues/8999#issuecomment-224851642 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] NixOps - merge config files
@dario: that doesn’t work recursively. { a = { x = 3; } } // { a = { y = 4;
} produces { a = { y = 4 }; }
On Thu, 9 Jun 2016 at 10:44 Dario Bertini wrote:
> {a=1;}// {b=2;}
> Yields
> {a=1; b=2;}
>
> Is this enough to help you?
>
> On 9 June 2016 10:31:07 BST, 4levels <4lev...@gmail.com> wrote:
> >Hi,
> >
> >thank you for your swift reply!
> >I'd like to avoid to literally mention all sensitive config params in
> >the
> >network.nix config.
> >
> >What would be the "normal" procedure to recursively merge 2 attribute
> >sets?
> >
> >
> >So if I have in one file
> >servers.nix: {
> > vm01 = {
> >services.symfony.platforms = {
> > database = {
> >username = "www";
> > };
> >};
> > };
> >}
> >
> >and in the other
> >keys.nix: {
> > vm01 = {
> >services.symfony.platforms = {
> > database = {
> >password = "12345678";
> > };
> >};
> > };
> >}
> >
> >So they become one when building:
> >{
> > vm01 = {
> >services.symfony.platforms = {
> > database = {
> >username = "www";
> >password = "12345678";
> > };
> >};
> > };
> >}
> >
> >Kind regards,
> >
> >Erik
> >
> >On Thu, Jun 9, 2016 at 11:23 AM zimbatm wrote:
> >
> >> Hi,
> >>
> >> I don’t know where you are getting this error. All I can do is
> >suggest a
> >> workaround:
> >>
> >> In keys.nix:
> >>
> >> {
> >> database_password = "12345678";
> >> }
> >>
> >> In network.nix:
> >>
> >> let
> >> secrets = import ./keys.nix {};in;
> >> {
> >> vm01 = {
> >> { config, pkgs, ... }:
> >> {
> >> services.symfony.platforms.database.password =
> >secrets.database_password;
> >>
> >> ..
> >> }
> >> }
> >> }
> >>
> >>
> >>
> >> On Thu, 9 Jun 2016 at 07:54 4levels <4lev...@gmail.com> wrote:
> >>
> >>> Hi Nix Devs,
> >>>
> >>> I'm having some difficulties separating sensitive information from a
> >nix
> >>> expression used by NixOps.
> >>>
> >>> I keep the server config in a separate file, servers.nix:
> >>> {
> >>> vm01 =
> >>> { config, pkgs, nodes, ... }:
> >>> {
> >>> deployment = {
> >>> targetHost = "192.168.121.50";
> >>> };
> >>> ...
> >>> }
> >>> }
> >>>
> >>> Currently I have all relevant software config for each server in a
> >nix
> >>> expression platforms.nix as follows (where vm01 is the hostname):
> >>> {
> >>> vm01 =
> >>> { config, pkgs, ... }:
> >>> {
> >>> services.symfony.platforms = {
> >>> database = {
> >>> username = "www";
> >>> /* password = "1234567" -> moved to keys.nix */
> >>> };
> >>> ...
> >>> }
> >>> }
> >>>
> >>> I want to remove the sensitive info from this file and put it in a
> >>> separate nix expression, eg. keys.nix, maintaining the same
> >structure so
> >>> the files can be merged.
> >>>
> >>> In keys.nix I currently have
> >>> {
> >>> vm01 = {
> >>> { config, pkgs, ... }:
> >>> {
> >>> services.symfony.platforms.database.password = "12345678";
> >>> ..
> >>> }
> >>> }
> >>> }
> >>>
> >>> I've modified my nixops deploy to have keys.nix loaded after the
> >>> servers.nix and platforms.nix files, but I keep getting errors like
> >"the
> >>> attribute password does not exist"
> >>>
> >>> I must be overlooking something obvious as all the other files I
> >define
> >>> in my deploy are being merged correctly.
> >>>
> >>> Can anyone advise me on how to achieve this?
> >>>
> >>> The underlying reason is that I'm using git-crypt to encrypt the
> >>> platforms.nix file, but this makes it impossible to work with
> >branches (or
> >>> git logs) etc. as the whole file is encrypted and git cannot merge
> >binary
> >>> files (it simply replaces them).
> >>>
> >>> Kind regards!
> >>>
> >>> Erik aka 4levels
> >>>
> >> ___
> >>> 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
>
> --
> Sent from mobile. Please excuse my brevity.
> ___
> 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] 10c87e: haskellPackages.timezone-series: Add support for t...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 10c87e69b4ab04a499be1a54bca1b8548f657d63 https://github.com/NixOS/nixpkgs/commit/10c87e69b4ab04a499be1a54bca1b8548f657d63 Author: Maciek Starzyk Date: 2016-06-08 (Wed, 08 Jun 2016) Changed paths: M pkgs/development/haskell-modules/configuration-common.nix A pkgs/development/haskell-modules/patches/timezone-series.patch Log Message: --- haskellPackages.timezone-series: Add support for time-1.6 - applied patch https://github.com/ygale/timezone-series/pull/1 Commit: 0158d124bd32346c43e1aab6777b94ca82325db4 https://github.com/NixOS/nixpkgs/commit/0158d124bd32346c43e1aab6777b94ca82325db4 Author: Maciek Starzyk Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/haskell-modules/configuration-common.nix R pkgs/development/haskell-modules/patches/timezone-series.patch Log Message: --- haskellPackages.timezone-series: Download patch instead of checking it into nixpkgs Commit: dc6f1cf4b3b513d9761d725b5acefb270e67f587 https://github.com/NixOS/nixpkgs/commit/dc6f1cf4b3b513d9761d725b5acefb270e67f587 Author: Peter Simons Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/haskell-modules/configuration-common.nix Log Message: --- Merge pull request #16080 from mstarzyk/timezone-series haskellPackages.timezone-series: Add support for time-1.6 - applied p… Compare: https://github.com/NixOS/nixpkgs/compare/109096247a20...dc6f1cf4b3b5___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 109096: php56: update to 5.6.22
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 109096247a20ed1141f1f373cd41c1674027c7f1 https://github.com/NixOS/nixpkgs/commit/109096247a20ed1141f1f373cd41c1674027c7f1 Author: Eelco Dolstra Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/interpreters/php/default.nix Log Message: --- php56: update to 5.6.22 (cherry picked from commit 72b4009367257c2447aac89d5f34f2421bbc88dc) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 72b400: php56: update to 5.6.22
Branch: refs/heads/release-16.03 Home: https://github.com/NixOS/nixpkgs Commit: 72b4009367257c2447aac89d5f34f2421bbc88dc https://github.com/NixOS/nixpkgs/commit/72b4009367257c2447aac89d5f34f2421bbc88dc Author: Eelco Dolstra Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/interpreters/php/default.nix Log Message: --- php56: update to 5.6.22 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-dev] wordpress
Hi, I see there's a wordpress package: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/web-servers/apache-httpd/wordpress.nix There are no available wordpress attributes. How do I install wordpress? Kind regards Stewart ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOps - merge config files
On 9 June 2016 at 08:54, 4levels <4lev...@gmail.com> wrote:
> ...
> I've modified my nixops deploy to have keys.nix loaded after the servers.nix
> and platforms.nix files, but I keep getting errors like "the attribute
> password does not exist"
What's the output of: 'nixops info' for your deployment?
> The underlying reason is that I'm using git-crypt to encrypt the
> platforms.nix file, but this makes it impossible to work with branches (or
> git logs) etc. as the whole file is encrypted and git cannot merge binary
> files (it simply replaces them).
I'm also using git-crypt to secure my secrets. I would suggest not
encrypting the full nix expression but just the actual secret like:
{
services.symfony.platforms.database.password = builtins.readFile
./secrets/database-password;
...
}
then encrypt everything under ./secrets.
Regards,
Bas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOps - merge config files
{a=1;}// {b=2;}
Yields
{a=1; b=2;}
Is this enough to help you?
On 9 June 2016 10:31:07 BST, 4levels <4lev...@gmail.com> wrote:
>Hi,
>
>thank you for your swift reply!
>I'd like to avoid to literally mention all sensitive config params in
>the
>network.nix config.
>
>What would be the "normal" procedure to recursively merge 2 attribute
>sets?
>
>
>So if I have in one file
>servers.nix: {
> vm01 = {
>services.symfony.platforms = {
> database = {
>username = "www";
> };
>};
> };
>}
>
>and in the other
>keys.nix: {
> vm01 = {
>services.symfony.platforms = {
> database = {
>password = "12345678";
> };
>};
> };
>}
>
>So they become one when building:
>{
> vm01 = {
>services.symfony.platforms = {
> database = {
>username = "www";
>password = "12345678";
> };
>};
> };
>}
>
>Kind regards,
>
>Erik
>
>On Thu, Jun 9, 2016 at 11:23 AM zimbatm wrote:
>
>> Hi,
>>
>> I don’t know where you are getting this error. All I can do is
>suggest a
>> workaround:
>>
>> In keys.nix:
>>
>> {
>> database_password = "12345678";
>> }
>>
>> In network.nix:
>>
>> let
>> secrets = import ./keys.nix {};in;
>> {
>> vm01 = {
>> { config, pkgs, ... }:
>> {
>> services.symfony.platforms.database.password =
>secrets.database_password;
>>
>> ..
>> }
>> }
>> }
>>
>>
>>
>> On Thu, 9 Jun 2016 at 07:54 4levels <4lev...@gmail.com> wrote:
>>
>>> Hi Nix Devs,
>>>
>>> I'm having some difficulties separating sensitive information from a
>nix
>>> expression used by NixOps.
>>>
>>> I keep the server config in a separate file, servers.nix:
>>> {
>>> vm01 =
>>> { config, pkgs, nodes, ... }:
>>> {
>>> deployment = {
>>> targetHost = "192.168.121.50";
>>> };
>>> ...
>>> }
>>> }
>>>
>>> Currently I have all relevant software config for each server in a
>nix
>>> expression platforms.nix as follows (where vm01 is the hostname):
>>> {
>>> vm01 =
>>> { config, pkgs, ... }:
>>> {
>>> services.symfony.platforms = {
>>> database = {
>>> username = "www";
>>> /* password = "1234567" -> moved to keys.nix */
>>> };
>>> ...
>>> }
>>> }
>>>
>>> I want to remove the sensitive info from this file and put it in a
>>> separate nix expression, eg. keys.nix, maintaining the same
>structure so
>>> the files can be merged.
>>>
>>> In keys.nix I currently have
>>> {
>>> vm01 = {
>>> { config, pkgs, ... }:
>>> {
>>> services.symfony.platforms.database.password = "12345678";
>>> ..
>>> }
>>> }
>>> }
>>>
>>> I've modified my nixops deploy to have keys.nix loaded after the
>>> servers.nix and platforms.nix files, but I keep getting errors like
>"the
>>> attribute password does not exist"
>>>
>>> I must be overlooking something obvious as all the other files I
>define
>>> in my deploy are being merged correctly.
>>>
>>> Can anyone advise me on how to achieve this?
>>>
>>> The underlying reason is that I'm using git-crypt to encrypt the
>>> platforms.nix file, but this makes it impossible to work with
>branches (or
>>> git logs) etc. as the whole file is encrypted and git cannot merge
>binary
>>> files (it simply replaces them).
>>>
>>> Kind regards!
>>>
>>> Erik aka 4levels
>>>
>> ___
>>> 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
--
Sent from mobile. Please excuse my brevity.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOps - merge config files
Hi Tomasz,
that is indeed the case: all these configuration values are being used to
generate different config files (for eg. a symfony project, or a wordpress
site, etc etc) and they do appear in /nix/store
I was not really aware of the security concerns here, but if
deployment.keys can be an attribute set, I'll definitely try implementing
that instead!
Thank you for the pointer, I'll keep you posted here...
Kind regards,
Erik
On Thu, Jun 9, 2016 at 11:36 AM Tomasz Czyż wrote:
> I'm not 100% sure as I'm pretty new to nixops, but probably if you put
> credentials like that, they can end up in /nix/store.
> As someone explained to me before, probably the only good way at the
> moment to do that is to use deployment.keys.
>
> Can anyone confirm that?
>
> 2016-06-09 10:31 GMT+01:00 4levels <4lev...@gmail.com>:
>
>> Hi,
>>
>> thank you for your swift reply!
>> I'd like to avoid to literally mention all sensitive config params in the
>> network.nix config.
>>
>> What would be the "normal" procedure to recursively merge 2 attribute
>> sets?
>>
>> So if I have in one file
>> servers.nix: {
>> vm01 = {
>> services.symfony.platforms = {
>> database = {
>> username = "www";
>> };
>> };
>> };
>> }
>>
>> and in the other
>> keys.nix: {
>> vm01 = {
>> services.symfony.platforms = {
>> database = {
>> password = "12345678";
>> };
>> };
>> };
>> }
>>
>> So they become one when building:
>> {
>> vm01 = {
>> services.symfony.platforms = {
>> database = {
>> username = "www";
>> password = "12345678";
>> };
>> };
>> };
>> }
>>
>> Kind regards,
>>
>> Erik
>>
>> On Thu, Jun 9, 2016 at 11:23 AM zimbatm wrote:
>>
>>> Hi,
>>>
>>> I don’t know where you are getting this error. All I can do is suggest a
>>> workaround:
>>>
>>> In keys.nix:
>>>
>>> {
>>> database_password = "12345678";
>>> }
>>>
>>> In network.nix:
>>>
>>> let
>>> secrets = import ./keys.nix {};in;
>>> {
>>> vm01 = {
>>> { config, pkgs, ... }:
>>> {
>>> services.symfony.platforms.database.password =
>>> secrets.database_password;
>>>
>>> ..
>>> }
>>> }
>>> }
>>>
>>>
>>>
>>> On Thu, 9 Jun 2016 at 07:54 4levels <4lev...@gmail.com> wrote:
>>>
Hi Nix Devs,
I'm having some difficulties separating sensitive information from a
nix expression used by NixOps.
I keep the server config in a separate file, servers.nix:
{
vm01 =
{ config, pkgs, nodes, ... }:
{
deployment = {
targetHost = "192.168.121.50";
};
...
}
}
Currently I have all relevant software config for each server in a nix
expression platforms.nix as follows (where vm01 is the hostname):
{
vm01 =
{ config, pkgs, ... }:
{
services.symfony.platforms = {
database = {
username = "www";
/* password = "1234567" -> moved to keys.nix */
};
...
}
}
I want to remove the sensitive info from this file and put it in a
separate nix expression, eg. keys.nix, maintaining the same structure so
the files can be merged.
In keys.nix I currently have
{
vm01 = {
{ config, pkgs, ... }:
{
services.symfony.platforms.database.password = "12345678";
..
}
}
}
I've modified my nixops deploy to have keys.nix loaded after the
servers.nix and platforms.nix files, but I keep getting errors like "the
attribute password does not exist"
I must be overlooking something obvious as all the other files I define
in my deploy are being merged correctly.
Can anyone advise me on how to achieve this?
The underlying reason is that I'm using git-crypt to encrypt the
platforms.nix file, but this makes it impossible to work with branches (or
git logs) etc. as the whole file is encrypted and git cannot merge binary
files (it simply replaces them).
Kind regards!
Erik aka 4levels
>>> ___
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] NixOps - merge config files
I'm not 100% sure as I'm pretty new to nixops, but probably if you put
credentials like that, they can end up in /nix/store.
As someone explained to me before, probably the only good way at the moment
to do that is to use deployment.keys.
Can anyone confirm that?
2016-06-09 10:31 GMT+01:00 4levels <4lev...@gmail.com>:
> Hi,
>
> thank you for your swift reply!
> I'd like to avoid to literally mention all sensitive config params in the
> network.nix config.
>
> What would be the "normal" procedure to recursively merge 2 attribute
> sets?
>
> So if I have in one file
> servers.nix: {
> vm01 = {
> services.symfony.platforms = {
> database = {
> username = "www";
> };
> };
> };
> }
>
> and in the other
> keys.nix: {
> vm01 = {
> services.symfony.platforms = {
> database = {
> password = "12345678";
> };
> };
> };
> }
>
> So they become one when building:
> {
> vm01 = {
> services.symfony.platforms = {
> database = {
> username = "www";
> password = "12345678";
> };
> };
> };
> }
>
> Kind regards,
>
> Erik
>
> On Thu, Jun 9, 2016 at 11:23 AM zimbatm wrote:
>
>> Hi,
>>
>> I don’t know where you are getting this error. All I can do is suggest a
>> workaround:
>>
>> In keys.nix:
>>
>> {
>> database_password = "12345678";
>> }
>>
>> In network.nix:
>>
>> let
>> secrets = import ./keys.nix {};in;
>> {
>> vm01 = {
>> { config, pkgs, ... }:
>> {
>> services.symfony.platforms.database.password =
>> secrets.database_password;
>>
>> ..
>> }
>> }
>> }
>>
>>
>>
>> On Thu, 9 Jun 2016 at 07:54 4levels <4lev...@gmail.com> wrote:
>>
>>> Hi Nix Devs,
>>>
>>> I'm having some difficulties separating sensitive information from a nix
>>> expression used by NixOps.
>>>
>>> I keep the server config in a separate file, servers.nix:
>>> {
>>> vm01 =
>>> { config, pkgs, nodes, ... }:
>>> {
>>> deployment = {
>>> targetHost = "192.168.121.50";
>>> };
>>> ...
>>> }
>>> }
>>>
>>> Currently I have all relevant software config for each server in a nix
>>> expression platforms.nix as follows (where vm01 is the hostname):
>>> {
>>> vm01 =
>>> { config, pkgs, ... }:
>>> {
>>> services.symfony.platforms = {
>>> database = {
>>> username = "www";
>>> /* password = "1234567" -> moved to keys.nix */
>>> };
>>> ...
>>> }
>>> }
>>>
>>> I want to remove the sensitive info from this file and put it in a
>>> separate nix expression, eg. keys.nix, maintaining the same structure so
>>> the files can be merged.
>>>
>>> In keys.nix I currently have
>>> {
>>> vm01 = {
>>> { config, pkgs, ... }:
>>> {
>>> services.symfony.platforms.database.password = "12345678";
>>> ..
>>> }
>>> }
>>> }
>>>
>>> I've modified my nixops deploy to have keys.nix loaded after the
>>> servers.nix and platforms.nix files, but I keep getting errors like "the
>>> attribute password does not exist"
>>>
>>> I must be overlooking something obvious as all the other files I define
>>> in my deploy are being merged correctly.
>>>
>>> Can anyone advise me on how to achieve this?
>>>
>>> The underlying reason is that I'm using git-crypt to encrypt the
>>> platforms.nix file, but this makes it impossible to work with branches (or
>>> git logs) etc. as the whole file is encrypted and git cannot merge binary
>>> files (it simply replaces them).
>>>
>>> Kind regards!
>>>
>>> Erik aka 4levels
>>>
>> ___
>>> 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] NixOps - merge config files
Hi,
thank you for your swift reply!
I'd like to avoid to literally mention all sensitive config params in the
network.nix config.
What would be the "normal" procedure to recursively merge 2 attribute sets?
So if I have in one file
servers.nix: {
vm01 = {
services.symfony.platforms = {
database = {
username = "www";
};
};
};
}
and in the other
keys.nix: {
vm01 = {
services.symfony.platforms = {
database = {
password = "12345678";
};
};
};
}
So they become one when building:
{
vm01 = {
services.symfony.platforms = {
database = {
username = "www";
password = "12345678";
};
};
};
}
Kind regards,
Erik
On Thu, Jun 9, 2016 at 11:23 AM zimbatm wrote:
> Hi,
>
> I don’t know where you are getting this error. All I can do is suggest a
> workaround:
>
> In keys.nix:
>
> {
> database_password = "12345678";
> }
>
> In network.nix:
>
> let
> secrets = import ./keys.nix {};in;
> {
> vm01 = {
> { config, pkgs, ... }:
> {
> services.symfony.platforms.database.password =
> secrets.database_password;
>
> ..
> }
> }
> }
>
>
>
> On Thu, 9 Jun 2016 at 07:54 4levels <4lev...@gmail.com> wrote:
>
>> Hi Nix Devs,
>>
>> I'm having some difficulties separating sensitive information from a nix
>> expression used by NixOps.
>>
>> I keep the server config in a separate file, servers.nix:
>> {
>> vm01 =
>> { config, pkgs, nodes, ... }:
>> {
>> deployment = {
>> targetHost = "192.168.121.50";
>> };
>> ...
>> }
>> }
>>
>> Currently I have all relevant software config for each server in a nix
>> expression platforms.nix as follows (where vm01 is the hostname):
>> {
>> vm01 =
>> { config, pkgs, ... }:
>> {
>> services.symfony.platforms = {
>> database = {
>> username = "www";
>> /* password = "1234567" -> moved to keys.nix */
>> };
>> ...
>> }
>> }
>>
>> I want to remove the sensitive info from this file and put it in a
>> separate nix expression, eg. keys.nix, maintaining the same structure so
>> the files can be merged.
>>
>> In keys.nix I currently have
>> {
>> vm01 = {
>> { config, pkgs, ... }:
>> {
>> services.symfony.platforms.database.password = "12345678";
>> ..
>> }
>> }
>> }
>>
>> I've modified my nixops deploy to have keys.nix loaded after the
>> servers.nix and platforms.nix files, but I keep getting errors like "the
>> attribute password does not exist"
>>
>> I must be overlooking something obvious as all the other files I define
>> in my deploy are being merged correctly.
>>
>> Can anyone advise me on how to achieve this?
>>
>> The underlying reason is that I'm using git-crypt to encrypt the
>> platforms.nix file, but this makes it impossible to work with branches (or
>> git logs) etc. as the whole file is encrypted and git cannot merge binary
>> files (it simply replaces them).
>>
>> Kind regards!
>>
>> Erik aka 4levels
>>
> ___
>> 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] 51a726: factor-lang: Init at 0.98
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 51a7260fba63167bd17d58631fa0991029521841 https://github.com/NixOS/nixpkgs/commit/51a7260fba63167bd17d58631fa0991029521841 Author: Rahul Gopinath Date: 2016-06-08 (Wed, 08 Jun 2016) Changed paths: A pkgs/development/compilers/factor-lang/default.nix M pkgs/top-level/all-packages.nix Log Message: --- factor-lang: Init at 0.98 Factor is a concatenative, stack-based programming language. Commit: 3871831b37ec94cbbae89863de7da0b21090f4b6 https://github.com/NixOS/nixpkgs/commit/3871831b37ec94cbbae89863de7da0b21090f4b6 Author: Rushmore Mushambi Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: A pkgs/development/compilers/factor-lang/default.nix M pkgs/top-level/all-packages.nix Log Message: --- Merge pull request #16059 from vrthra/factor factor-lang: Init at 0.97 Compare: https://github.com/NixOS/nixpkgs/compare/fcb0023e8030...3871831b37ec___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] NixOps - merge config files
Hi,
I don’t know where you are getting this error. All I can do is suggest a
workaround:
In keys.nix:
{
database_password = "12345678";
}
In network.nix:
let
secrets = import ./keys.nix {};in;
{
vm01 = {
{ config, pkgs, ... }:
{
services.symfony.platforms.database.password = secrets.database_password;
..
}
}
}
On Thu, 9 Jun 2016 at 07:54 4levels <4lev...@gmail.com> wrote:
> Hi Nix Devs,
>
> I'm having some difficulties separating sensitive information from a nix
> expression used by NixOps.
>
> I keep the server config in a separate file, servers.nix:
> {
> vm01 =
> { config, pkgs, nodes, ... }:
> {
> deployment = {
> targetHost = "192.168.121.50";
> };
> ...
> }
> }
>
> Currently I have all relevant software config for each server in a nix
> expression platforms.nix as follows (where vm01 is the hostname):
> {
> vm01 =
> { config, pkgs, ... }:
> {
> services.symfony.platforms = {
> database = {
> username = "www";
> /* password = "1234567" -> moved to keys.nix */
> };
> ...
> }
> }
>
> I want to remove the sensitive info from this file and put it in a
> separate nix expression, eg. keys.nix, maintaining the same structure so
> the files can be merged.
>
> In keys.nix I currently have
> {
> vm01 = {
> { config, pkgs, ... }:
> {
> services.symfony.platforms.database.password = "12345678";
> ..
> }
> }
> }
>
> I've modified my nixops deploy to have keys.nix loaded after the
> servers.nix and platforms.nix files, but I keep getting errors like "the
> attribute password does not exist"
>
> I must be overlooking something obvious as all the other files I define in
> my deploy are being merged correctly.
>
> Can anyone advise me on how to achieve this?
>
> The underlying reason is that I'm using git-crypt to encrypt the
> platforms.nix file, but this makes it impossible to work with branches (or
> git logs) etc. as the whole file is encrypted and git cannot merge binary
> files (it simply replaces them).
>
> Kind regards!
>
> Erik aka 4levels
> ___
> 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] Stackage Support Will Be Discontinued
It might make sense to create an external repo (nix-hackage?) with the stackage releases and it's own release.nix. That way it can evolve independently from nixpkgs and not clobber the main repo. It can also offer it's own binary cache as a service to haskell developers. You might even be able to join forces with the stackage guys on that front. In the main nixpkgs, add a link to the latest version of the nix-hackage. Then remove all the packages from haskellPackages; remove all the libraries and place the executable programs in the normal pkgs/ hierarchy. If all the programs are pre-compiled users won't have to download nix-hackage. That way it keeps nixpkgs small and executables can evolve independently from the stackage releases (I definitely had times where I wanted the latest version of `stack`). On Thu, 9 Jun 2016 at 09:17 Oliver Charles wrote: > I pin my Haskell packages by using fetchFromGitHub with a specific nixpkgs > revisions, and then import the result. The only downside is the Haskell > packages linking against things like OpenSSL as you say wouldn't get > patched. > > On Wed, 8 Jun 2016, 8:58 p.m. Teo Klestrup Röijezon, > wrote: > >> So there will no longer be a way to pin Haskell dependencies? That's a >> bit annoying. I can understand the desire to keep security-critical >> packages like OpenSSL and user-facing tools like git-annex up to date, but >> at the same time there are many non-critical dependencies that I wouldn't >> want to go back and patch my one-off deployments for updates of. >> >> The old way is/was certainly not perfect, but at least it provided a >> mostly-stable target that I could pretty much forget about after deployment. >> >> On 8 June 2016 at 13:34, Peter Simons wrote: >> >>> Fellow Haskell Hackers, >>> >>> once the LTS 7.x package set comes out, I intend to make the following >>> changes in "master": >>> >>> - All haskell.packages.lts.* package sets will disappear. >>> >>> - haskellPackages will loosely follow the most recent LTS release, >>> >>> where "loosely" means that we'll honor the mandated version bounds for >>> libraries but tend to ignore them for executables. >>> >>> Nixpkgs has shipped every single LTS Haskell version ever released as >>> well as an up-to-date copy of the Stackage Nightly package set for the >>> last 9 months or so, and during that time we've gained insights that >>> suggest this practice is an ineffective use of our resources [1]. >>> >>> 1. It's pointless to distribute LTS Haskell version x after the release >>> of version x+1. >>> >>> Stackage does not "maintain" any of its LTS releases. Rather, the >>> Stackage volunteers compile a list of package versions, test and verify >>> them to the best of their abilities, release that list, and then they >>> never touch it again. For example, there won't be any update to LTS >>> Haskell 5.4. That update comes in the form of a new package set called >>> LTS 5.5. So if LTS 5.4 happens to recommend a package that has a serious >>> problem, then that problem will remain there forever. So what is the >>> point of distributing LTS 5.4 after the release of 5.5? Apparently, >>> Stackage intends LTS 5.5 to *replace* the previous version, so isn't >>> that what we should do, too? >>> >>> Furthermore, a major release like LTS Haskell 5.x receives no updates >>> either after LTS 6.x has comes out, so by the same logic there is no >>> point in distributing LTS 5.x after LTS 6.x has become available. >>> Contrary to what the name suggests, LTS versions have no guaranteed >>> lifetime or support cycle. Stackage does not offer any "long-term >>> support" in the sense distributions use the word. "Releases" are merely >>> names for tested snapshots of a project that essentially follows a >>> rolling release model. >>> >>> 2. Following LTS strictly may deprive us of important security updates. >>> >>> Whether a package update goes into a minor LTS release or not depends on >>> whether that update increments the first or second segment of its >>> version number. 6.1.1 -> 6.1.2 will make it, but 6.1.1 -> 6.2 won't. >>> That is a pretty good rule based on the assumption that all LTS >>> contributors follow it, which -- as you will have guessed -- is not the >>> case. The tool git-annex, for example, uses version numbers that have >>> only two levels: .. Due to that scheme, git-annex updates >>> aren't considered for minor LTS releases, which means that security >>> relevant fixes don't reach LTS users until the next major LTS release >>> [2]. >>> >>> 3. Stackage Nightly is not a stable package set. >>> >>> Our main package set, haskellPackages, corresponds to Stackage Nightly. >>> We made that choice assuming that it would guarantee us a good mixture >>> of a stable user experience on one hand and an up-to-date packages on >>> the other. Recent experience has shown, however, that Stackage Nightly >>> *will* break some of its packages knowingly on the occasion: the Nightly >>> package set recently moved to
Re: [Nix-dev] NIX_ENFORCE_NO_NATIVE
On 06/09/2016 10:17 AM, Andreas Herrmann wrote: >> IIRC its' conditioned on $NIX_ENFORCE_NO_NATIVE exactly in order >> not to be filtered out when run outside a nix builder. IMO that's a >> good default. Hydra isn't the only reason; many devs use remote >> builds or nix-copy-closure. > How would you nix-copy-closure something that was compiled outside of > nix? Maybe, we're talking about different things. What I mean is > using a GCC that was built by Nix directly on the command-line You seem to have missed my main point, so let me be more clear. 1) Outside nix builder $NIX_ENFORCE_NO_NATIVE is *not* active unless you explicitly set it, i.e. -march=native *is* passed to the underlying GCC. I re-tested that now by reading code and using (2). 2) If you set NIX_DEBUG=1 those omission won't be silent: $ env NIX_ENFORCE_NO_NATIVE=1 NIX_DEBUG=1 g++ [...] skipping impure path -march=native [...] (Yes, in this case it's not very friendly to call it a path.) --Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Stackage Support Will Be Discontinued
I pin my Haskell packages by using fetchFromGitHub with a specific nixpkgs revisions, and then import the result. The only downside is the Haskell packages linking against things like OpenSSL as you say wouldn't get patched. On Wed, 8 Jun 2016, 8:58 p.m. Teo Klestrup Röijezon, wrote: > So there will no longer be a way to pin Haskell dependencies? That's a bit > annoying. I can understand the desire to keep security-critical packages > like OpenSSL and user-facing tools like git-annex up to date, but at the > same time there are many non-critical dependencies that I wouldn't want to > go back and patch my one-off deployments for updates of. > > The old way is/was certainly not perfect, but at least it provided a > mostly-stable target that I could pretty much forget about after deployment. > > On 8 June 2016 at 13:34, Peter Simons wrote: > >> Fellow Haskell Hackers, >> >> once the LTS 7.x package set comes out, I intend to make the following >> changes in "master": >> >> - All haskell.packages.lts.* package sets will disappear. >> >> - haskellPackages will loosely follow the most recent LTS release, >> >> where "loosely" means that we'll honor the mandated version bounds for >> libraries but tend to ignore them for executables. >> >> Nixpkgs has shipped every single LTS Haskell version ever released as >> well as an up-to-date copy of the Stackage Nightly package set for the >> last 9 months or so, and during that time we've gained insights that >> suggest this practice is an ineffective use of our resources [1]. >> >> 1. It's pointless to distribute LTS Haskell version x after the release >> of version x+1. >> >> Stackage does not "maintain" any of its LTS releases. Rather, the >> Stackage volunteers compile a list of package versions, test and verify >> them to the best of their abilities, release that list, and then they >> never touch it again. For example, there won't be any update to LTS >> Haskell 5.4. That update comes in the form of a new package set called >> LTS 5.5. So if LTS 5.4 happens to recommend a package that has a serious >> problem, then that problem will remain there forever. So what is the >> point of distributing LTS 5.4 after the release of 5.5? Apparently, >> Stackage intends LTS 5.5 to *replace* the previous version, so isn't >> that what we should do, too? >> >> Furthermore, a major release like LTS Haskell 5.x receives no updates >> either after LTS 6.x has comes out, so by the same logic there is no >> point in distributing LTS 5.x after LTS 6.x has become available. >> Contrary to what the name suggests, LTS versions have no guaranteed >> lifetime or support cycle. Stackage does not offer any "long-term >> support" in the sense distributions use the word. "Releases" are merely >> names for tested snapshots of a project that essentially follows a >> rolling release model. >> >> 2. Following LTS strictly may deprive us of important security updates. >> >> Whether a package update goes into a minor LTS release or not depends on >> whether that update increments the first or second segment of its >> version number. 6.1.1 -> 6.1.2 will make it, but 6.1.1 -> 6.2 won't. >> That is a pretty good rule based on the assumption that all LTS >> contributors follow it, which -- as you will have guessed -- is not the >> case. The tool git-annex, for example, uses version numbers that have >> only two levels: .. Due to that scheme, git-annex updates >> aren't considered for minor LTS releases, which means that security >> relevant fixes don't reach LTS users until the next major LTS release >> [2]. >> >> 3. Stackage Nightly is not a stable package set. >> >> Our main package set, haskellPackages, corresponds to Stackage Nightly. >> We made that choice assuming that it would guarantee us a good mixture >> of a stable user experience on one hand and an up-to-date packages on >> the other. Recent experience has shown, however, that Stackage Nightly >> *will* break some of its packages knowingly on the occasion: the Nightly >> package set recently moved to GHC 8.0.1, but a handful of libraries and >> applications blocked that (desirable) update. At that point one would >> expect people to postpone the compiler update, but what happened instead >> is that the troublemakers were simply removed from Stackage [3]. >> >> Now, that is a perfectly legitimate decision to make, it just had the >> unfortunate side effect of breaking all those builds for users of >> Nixpkgs in the process, so arguably following Stackage Nightly with our >> main package set might be a bad idea. >> >> 4. Stackage does not provide a stable users experience for Nixpkgs. >> >> Stackage releases come out only after a complete test build of all >> packages has succeeded. Unfortunately, those tests don't always catch >> all issues we might run into, because we compile packages in a different >> environment. Stackage builds on Travis-CI using 64-bit Ubuntu Linux with >> static linking. Our builds run on all kinds of Linuxes and
Re: [Nix-dev] NIX_ENFORCE_NO_NATIVE
Thanks for your response. On Wednesday 08 June 2016 22:54:04 Vladimír Čunát wrote: > On 06/08/2016 04:14 PM, Andreas Herrmann wrote: > > Especially, when being run outside of a nix-builder. > > IIRC its' conditioned on $NIX_ENFORCE_NO_NATIVE exactly in order not to > be filtered out when run outside a nix builder. IMO that's a good > default. Hydra isn't the only reason; many devs use remote builds or > nix-copy-closure. How would you nix-copy-closure something that was compiled outside of nix? Maybe, we're talking about different things. What I mean is using a GCC that was built by Nix directly on the command-line $ gcc -O3 -march=native -o thing thing.c Or, through some build-system: $ make > If you do want -march or -mtune in mkDerivation, you may either set > NIX_ENFORCE_NO_NATIVE = false; [...] Sure, and I'm glad that it's an easy fix. What I'm taking issue with is that it was a quiet change, and that I'm not notified in any way that part of my compiler flags are being ignored. I only found out by chance when looking at the disassembly of some executable while profiling and optimizing. I noticed that there were no AVX instructions to be found, even though they where generated before with -march=native. My suggestion would be to add a warning. That would seem to work well for both cases: If you're cross-compiling or remote building then you probably don't want to set -march=native and a notification would help to fix these cases. If you're compiling on the target machine and want automatic architecture specific optimization then -march=native is there specifically for that purpose. It being silently ignored is, IMHO, surprising and unexpected behavior and not really helpful. > [...] or even better, specify it explicitly, > e.g. -march=btver1 Well, I think, whether that's better or not depends on the use case. If you have different targets but can compile directly on the target then why not use the automatic detection? That way it's one thing less to worry about. Again, I agree that removing -march=native is a good thing on Hydra. It makes sense to me as the default behavior when building things with nix. It's certainly better than unexpected breakage after a nix-copy-closure. But, I think in any case the user should be notified. Best, Andreas ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] fcb002: haskellPackages.intero: fix tests (thanks @rvl)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: fcb0023e8030074f140c69013a6b339880cd24de https://github.com/NixOS/nixpkgs/commit/fcb0023e8030074f140c69013a6b339880cd24de Author: obadz Date: 2016-06-09 (Thu, 09 Jun 2016) Changed paths: M pkgs/development/haskell-modules/configuration-common.nix Log Message: --- haskellPackages.intero: fix tests (thanks @rvl) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
