[Nix-dev] Fwd: Encrypted boot, encrypted root on zfs setup. Problem with root unlocking.
> I have a working configuration with a Luks-encrypted root filesystem
> on two devices (btrfs). I do not use postBootCommands (except to set
> up encrypted swap). I set
>
> boot.initrd.luks.devices = [{ device = "/dev/..."; name = (pick any
> name);} {device = ...; name = ...;}];
> boot.initrd.supportedFilesystems = [ "btrfs" ];
>
> I don't know if there's anything similar if you're not using Luks. Let
> me know if this helps.
>
I'm using luks.
Problem is that I do not want to enter the password for 4 disks. So I keep
key file on other partition and than I have to decrypt partitions with this
key. I didn't find how to do it in configure.nix file. Probably could be
something like
boot.initrd.luks.devices = [{ device="/dev/...", keyfile="XXX" }]
but whatever I do it manually or there is any way in configure.nix, I need
to know where the key actually is.
So I have an Idea, I'll try to mount the boot partition somewhere. but
maybe it's already mounted or there are any better ways to do it ?
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] How to add file to initrd?
Hi, Continuation of this thread: http://thread.gmane.org/gmane.linux.distributions.nixos/17879/focus=17880 I already successfully set up crypted partitions for mdadm and for zfs. The system is mounting them properly with standard nixos configuration using ``boot.initrd.luks`` configs. But for each mount I have to pass password/key. I thought I can put keys for all partitions to initrd as initrd is on encrypted boot partition (boot). The process would be like: * enter password for grub * grub loads initrd * initrd unlocks all other partitions Currently it works for me in very strange way. I am using preLVMCommands option with "echo 'mykey' > /key". I don't like it because I cannot keep my configuration on git somewhere cause it expose my passwords. Is there any way to add key files to initrd? (I found some "extra" options for boot partition but not for initrd, maybe there are some hooks I'm not aware of) -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] hotkey to change between qwerty <-> dvorak
Probably you could use this xorg setup: http://unix.stackexchange.com/questions/106782/keyboard-layout-switch-ctrlshift-in-a-new-xorg There is also few trayicon applications to do that, depends on which environment you use. 2015-09-09 16:42 GMT+01:00 Peter Simons : > Hi Stewart, > > I run "setxkbmap de" and "setxkbmap dvorak" to switch layouts. Not sure > how to bind that to a key, but I'd be interested to find out if someone > else knows? > > Best regards, > Peter > > ___ > 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] How to add file to initrd?
Thank you, I'll try. I couldn't find this in docs, it's kind of undocumented feature or I just was not looking carefully? Tom 2015-09-09 5:59 GMT+01:00 : > On Tuesday, September 08, 2015 20:09:16 Tomasz Czyż wrote: > > > Is there any way to add key files to initrd? (I found some "extra" > options > > > for boot partition but not for initrd, maybe there are some hooks I'm not > > > aware of) > > > > boot.initrd.extraUtilsCommands looks like a good match. > > > > -- Evgeny > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to add file to initrd?
2015-09-09 7:03 GMT+01:00 Bryan Gardiner :
> On Tue, Sep 08, 2015 at 08:09:16PM +0100, Tomasz Czyż wrote:
> > Hi,
> >
> > Continuation of this thread:
> >
> http://thread.gmane.org/gmane.linux.distributions.nixos/17879/focus=17880
> >
> > I already successfully set up crypted partitions for mdadm and for zfs.
> The
> > system is mounting them properly with standard nixos configuration using
> > ``boot.initrd.luks`` configs.
> >
> > But for each mount I have to pass password/key. I thought I can put keys
> > for all partitions to initrd as initrd is on encrypted boot partition
> > (boot). The process would be like:
> > * enter password for grub
> > * grub loads initrd
> > * initrd unlocks all other partitions
> >
> > Currently it works for me in very strange way.
> > I am using preLVMCommands option with "echo 'mykey' > /key".
> > I don't like it because I cannot keep my configuration on git somewhere
> > cause it expose my passwords.
>
> How about doing something like:
>
> preLVMCommands =
> let key = builtins.readFile ./keyfile; in
> "echo '${key}' >/key"
>
> then putting keyfile in gitignore?
>
Thanks Bryan,
looks like good trick :-) I'm new to nix, I didn't even thought about that
stuff, cheers!
Tom
>
> - Bryan
>
> > Is there any way to add key files to initrd? (I found some "extra"
> options
> > for boot partition but not for initrd, maybe there are some hooks I'm not
> > aware of)
>
> ___
> 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] How to add file to initrd?
2015-09-10 16:27 GMT+01:00 Bryan Gardiner : > On Thu, Sep 10, 2015 at 09:18:38AM +0100, Tomasz Czyż wrote: > > Thank you, I'll try. > > I couldn't find this in docs, it's kind of undocumented feature or I just > > was not looking carefully? > > It has internal = true; set on the declaration in > nixpkgs/nixos/modules/system/boot/stage-1.nix, probably why it doesn't > show up in the manual. > Thanks for clarification. Tom > > - Bryan > > ___ > 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] How to add file to initrd?
2015-09-10 9:19 GMT+01:00 Tomasz Czyż :
>
>
> 2015-09-09 7:03 GMT+01:00 Bryan Gardiner :
>
>> On Tue, Sep 08, 2015 at 08:09:16PM +0100, Tomasz Czyż wrote:
>> > Hi,
>> >
>> > Continuation of this thread:
>> >
>> http://thread.gmane.org/gmane.linux.distributions.nixos/17879/focus=17880
>> >
>> > I already successfully set up crypted partitions for mdadm and for zfs.
>> The
>> > system is mounting them properly with standard nixos configuration using
>> > ``boot.initrd.luks`` configs.
>> >
>> > But for each mount I have to pass password/key. I thought I can put keys
>> > for all partitions to initrd as initrd is on encrypted boot partition
>> > (boot). The process would be like:
>> > * enter password for grub
>> > * grub loads initrd
>> > * initrd unlocks all other partitions
>> >
>> > Currently it works for me in very strange way.
>> > I am using preLVMCommands option with "echo 'mykey' > /key".
>> > I don't like it because I cannot keep my configuration on git somewhere
>> > cause it expose my passwords.
>>
>> How about doing something like:
>>
>> preLVMCommands =
>> let key = builtins.readFile ./keyfile; in
>> "echo '${key}' >/key"
>>
>> then putting keyfile in gitignore?
>>
> Thanks Bryan,
>
> looks like good trick :-) I'm new to nix, I didn't even thought about that
> stuff, cheers!
>
> Tom
>
To sum up. This method works pretty well as long as you do "echo -n" so it
won't add new line at the end of your key. But the method is not the best
as if there any problem inside the script, the content of the file is
printed on the screen (during the boot process). Not problem for me as I'm
using boot partition encription, but it's kind of concert. Anyway thanks
for sharing this tip!.
>
>> - Bryan
>>
>> > Is there any way to add key files to initrd? (I found some "extra"
>> options
>> > for boot partition but not for initrd, maybe there are some hooks I'm
>> not
>> > aware of)
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
>
> --
> Tomasz Czyż
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to add file to initrd?
I have a problem with this method as you cannot copy the file outside extras tree. I used: ''cp /my.key $out/key" - the final file is in /nix/store/X/here (hard to access, if hash will change this stuff stop work. "cp /my.key $out/../../key" or "cp /my.key /key" doesn't work, permission error, so I cannot put key in the root of initrd. Tom 2015-09-09 5:59 GMT+01:00 : > On Tuesday, September 08, 2015 20:09:16 Tomasz Czyż wrote: > > > Is there any way to add key files to initrd? (I found some "extra" > options > > > for boot partition but not for initrd, maybe there are some hooks I'm not > > > aware of) > > > > boot.initrd.extraUtilsCommands looks like a good match. > > > > -- Evgeny > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to add file to initrd?
Permission denied – if I try use /key. 2015-09-10 21:58 GMT+01:00 Bryan Gardiner : > On Thu, Sep 10, 2015 at 09:22:13PM +0100, Tomasz Czyż wrote: > > I have a problem with this method as you cannot copy the file outside > > extras tree. > > > > I used: > > > >''cp /my.key $out/key" - the final file is in /nix/store/X/here > > (hard to access, if hash will change this stuff stop work. > > > >"cp /my.key $out/../../key" or "cp /my.key /key" doesn't work, > > permission error, so I cannot put key in the root of initrd. > > I don't have encrypted boot going myself... I'm passing on a reply I > got off-list from Leroy (bcc'ed, thanks, hope you don't mind), whose > config works using boot.initrd.extraUtilsCommands: > > On Wed, Sep 09, 2015 at 07:40:21PM +1200, Leroy Hopson wrote: > > Hi Bryan, > > > > I have a similar setup. I'm using `boot.initrd.extraUtilsCommands` as > > Evygeny suggested. > > > > Here is a link to the relevant section of my configuration: > > > https://github.com/lihop/nixos/blob/7b1b0a7fd4396713573c35368791e32843feb957/devices/desktop.nix#L59-L72 > > > > Regards, > > Leroy > > He's putting the keyfile in the initrd's /bin, then I suspect that > $PATH is only "/bin" in his keyFile = ...; arguments. If that's the > case, then with your first cp command above, your keyfile should > simply be at "/key" in your initrd, no need to know the hash. > > Cheers, > Bryan > > ___ > 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] How to add file to initrd?
2015-09-11 13:01 GMT+01:00 Tuomas Tynkkynen :
> (Argh, replying to the list this time...)
>
> 2015-09-09 9:03 GMT+03:00 Bryan Gardiner :
> > On Tue, Sep 08, 2015 at 08:09:16PM +0100, Tomasz Czyż wrote:
> [...]
> >
> > How about doing something like:
> >
> > preLVMCommands =
> > let key = builtins.readFile ./keyfile; in
> > "echo '${key}' >/key"
> >
>
> Do note that by doing this, the key will get embedded somewhere in
> /nix/store, with world-readable unix permissions.
>
Mhm, that's definitely not cool. I thought it will appear only inside
initrd image :[
Do you think is there any other way to put this key in initrd?
> ___
> 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] How to add file to initrd?
2015-09-11 15:31 GMT+01:00 Bryan Gardiner :
> On Fri, Sep 11, 2015 at 01:05:36PM +0100, Tomasz Czyż wrote:
> > 2015-09-11 13:01 GMT+01:00 Tuomas Tynkkynen :
> >
> > > (Argh, replying to the list this time...)
> > >
> > > 2015-09-09 9:03 GMT+03:00 Bryan Gardiner :
> > > > On Tue, Sep 08, 2015 at 08:09:16PM +0100, Tomasz Czyż wrote:
> > > [...]
> > > >
> > > > How about doing something like:
> > > >
> > > > preLVMCommands =
> > > > let key = builtins.readFile ./keyfile; in
> > > > "echo '${key}' >/key"
> > > >
> > >
> > > Do note that by doing this, the key will get embedded somewhere in
> > > /nix/store, with world-readable unix permissions.
> >
> > Mhm, that's definitely not cool. I thought it will appear only inside
> > initrd image :[
> > Do you think is there any other way to put this key in initrd?
>
> If you don't want it in plain text, you could compress or obfuscate it
> by any means, then reverse that in the initrd... The
> extraUtilsCommands method will certainly result in "not simply plain
> text." Though this is security by obscurity, and I don't know a quick
> way to truly secure it without having to enter your password an extra
> time. Nix doesn't support non-world-readable data in the store.
>
Thanks for explenation.
>
> Can Grub pass its unlock password to the initrd? If so, you could
> decrypt the keyfile with that, and only put an encrypted keyfile in
> the store.
>
Not really, that's why I want to put key inside initrd. Otherwise I could
decrypt partitions with the pass from grub.
>
> Or maybe you could restrict non-root users from accessing the initrds
> in the store via grsec or apparmor.
>
Mhm, I see.
What about putting something into initrd but not adding it to nixstore?
Do you think is there any initrd hook I can use to add stuff?
Tom
>
> Cheers,
> Bryan
>
> ___
> 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] How to add file to initrd?
Thanks for all the tips Bryan.
2015-09-11 16:02 GMT+01:00 Bryan Gardiner :
> On Fri, Sep 11, 2015 at 03:39:34PM +0100, Tomasz Czyż wrote:
> > 2015-09-11 15:31 GMT+01:00 Bryan Gardiner :
> >
> > > On Fri, Sep 11, 2015 at 01:05:36PM +0100, Tomasz Czyż wrote:
> > > > 2015-09-11 13:01 GMT+01:00 Tuomas Tynkkynen >:
> > > >
> > > > > (Argh, replying to the list this time...)
> > > > >
> > > > > 2015-09-09 9:03 GMT+03:00 Bryan Gardiner :
> > > > > > On Tue, Sep 08, 2015 at 08:09:16PM +0100, Tomasz Czyż wrote:
> > > > > [...]
> > > > > >
> > > > > > How about doing something like:
> > > > > >
> > > > > > preLVMCommands =
> > > > > > let key = builtins.readFile ./keyfile; in
> > > > > > "echo '${key}' >/key"
> > > > > >
> > > > >
> > > > > Do note that by doing this, the key will get embedded somewhere in
> > > > > /nix/store, with world-readable unix permissions.
> > > >
> > > > Mhm, that's definitely not cool. I thought it will appear only inside
> > > > initrd image :[
> > > > Do you think is there any other way to put this key in initrd?
> > >
> > > If you don't want it in plain text, you could compress or obfuscate it
> > > by any means, then reverse that in the initrd... The
> > > extraUtilsCommands method will certainly result in "not simply plain
> > > text." Though this is security by obscurity, and I don't know a quick
> > > way to truly secure it without having to enter your password an extra
> > > time. Nix doesn't support non-world-readable data in the store.
> > >
> > Thanks for explenation.
> >
> > >
> > > Can Grub pass its unlock password to the initrd? If so, you could
> > > decrypt the keyfile with that, and only put an encrypted keyfile in
> > > the store.
> > >
> > Not really, that's why I want to put key inside initrd. Otherwise I could
> > decrypt partitions with the pass from grub.
> >
> > >
> > > Or maybe you could restrict non-root users from accessing the initrds
> > > in the store via grsec or apparmor.
> > >
> > Mhm, I see.
> > What about putting something into initrd but not adding it to nixstore?
> > Do you think is there any initrd hook I can use to add stuff?
>
> That could work, if you find how the initrd is copied over. Grub
> manages to make /boot/grub have 700 permissions, so if you extract +
> insert + rebuild the initrd during its installation, and make
> /boot/kernels 700 as well? In my readings of nixpkgs/nixos, I haven't
> gotten to the bottom of the rabbit hole and found out how nixos
> modules *actually* have an effect on the world yet :).
>
> Cheers,
> Bryan
>
> ___
> 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] How to add file to initrd?
2015-09-11 19:03 GMT+01:00 Tuomas Tynkkynen :
> 2015-09-11 15:05 GMT+03:00 Tomasz Czyż :
> >
>
> >
> > Mhm, that's definitely not cool. I thought it will appear only inside
> initrd
> > image :[
>
> A copy of the initrd is always kept in /nix/store, but also the .drv file
> and
> potentially any generated scripts (for building the initrd) might
> contain the key.
>
> > Do you think is there any other way to put this key in initrd?
>
> GRUB supports loading multiple initrd images at once. For example,
> on Arch Linux the generated grub.cfg contains this:
>
> menuentry 'Arch Linux' --class arch --class gnu-linux /* etc. */ {
> # ...
> initrd /boot/intel-ucode.img /boot/initramfs-linux.img
> }
>
> So one approach would be to create a initrd with just the keyfile
> (outside Nix), place it on the /boot partition, and then somehow
> make the grub.cfg generator emit the proper initrd line(s).
>
wow, I was not aware that stuff is even possible. I have to read more about
how to access stuff from the other initrd.
Btw, I search through /nix/store and the key copied with "echp ${key} >
/key" is not there, so probably it's only inside a script, which is still
bad.
Thanks a lot.
Tom
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [RFC] buildPythonPackage refactoring
Nice work, cheers! 2015-11-23 9:56 GMT+00:00 Domen Kožar : > Hi all, > > during NixCon sprints I worked on porting our Python tooling from year > 2000 into 2012. We now use wheel toolchain that fixes a lot of bugs and > allows us to push improvements upstream. The PR has lots of other > improvements, feel free to read changelog overview on > > https://github.com/NixOS/nixpkgs/pull/11086 > > Feel free to test your Python projects, I'm planning to merge the PR on > Wednesday. > > Domen > > ___ > 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] Nix User Profile (NixUP)
Awesome! I'll test. 2015-11-25 12:08 GMT+00:00 Thomas Strobel : > Hi! > > I'm very happy to say that a new version of NixUP is available for > testing. You can find the latest version at [1]. Please read > NIXUP_README.md for help on how to test NixUP. > > > What is Nix User Profile (NixUP)? NixUP is a declarative configuration > for the user environment. It is an equivalent to the NixOS configuration > method that is based around 'nixos-rebuild' and > '/etc/nixos/configuration.nix'. NixUP provides a module system for > configuring the user environment and is intended as a replacement for > the imperative 'nix-env' commands. NixUP allows to, e.g., install > packages, manage user defined services and to manage resources. > > > NixUP consists of a new program, called 'nixup' and a declarative > configuration rooted at '$XDG_CONFIG_HOME/nixup/profile.nix' (e.g. > ~/.config/nixup/profile.nix). Basically, the workflow for managing the > NixUP user profile is the same as how the NixOS system configuration is > being managed. The 'profile.nix' is edited by the user, and then turned > into an active environment through 'nixup'. > > The important commands for using 'nixup' are: > > nixup build >-- Builds a user profile. By default the profile is defined > in $XDG_CONFIG_HOME/nixup/profile.nix. > > nixup login >-- Builds a user profile that will be activated on the next login. > That is similar to nixos-rebuild boot. > > nixup switch >-- Builds a user profile and immediately switches to it. > > nixup edit >-- Opens an editor with the current configuration. > > > NixUP also brings an small program that helps to install and to remove > software packages. If 'config.imperativeNix.enable=true' is set in the > 'profile.nix' configuration, then a program 'nix-package' becomes > available that manages a list of packages to be installed into the user > environment. By default the list is maintained at > '$XDG_CONFIG_HOME/nixup/packages.nix', from where the list is read by a > module of the NixUP system. > > The commands for using 'nix-package' are: > > nix-package install hello > > nix-package remove hello > > Note that the packages are not pinned at a particular version but are > linked to the currently active nixpkgs channel. A way to pin a package > will be provided later. > > > Besides managing software packages, NixUP also provides a way to manage > user controlled services. NixUP allows to define services for 'systemd > --user', similarly to how NixOS allows to define services for 'systemd'. > That means that the feature of managing services within NixUP is bound > very tightly to 'systemd', and will not be available on other platforms > like OSX or Windows. > > > The last interesting feature of NixUP is that is allows to manage > resources. That means, it allows to define files in 'profile.nix' that > are then linked into the $HOME directory of a user, or into any > sub-directory of $HOME. The necessary sub-directories and links are > created as needed, and automatically removed when the 'profile.nix' > changes. Automatically created sub-directories are removed if they are > empty after all links have been removed. So NixUP has a built-in way for > managing, e.g., dot-files. > > > The plan is now to test NixUP and hopefully merge NixUP into NixOS. The > next step then will then be to extend NixOS and NixUP so that the same > configuration can be written into the NixOS user declaration of > 'configuration.nix' and into the user's NixUP 'profile.nix'. After that, > we could generalize the NixOS modules of those services that could also > run as user services and make them available for both NixOS and NixUP. > In the long run, NixUP should be developed into an extensive collection > of user modules that allow to declaratively configure and manage user > applications and user services. > > > Please let me know what you think, and please try to test NixUP! :) > > > Best regards, > Thomas > > > [1] https://github.com/NixOS/nixpkgs/pull/9250 > ___ > 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] Fundraiser?
https://www.bountysource.com/search?query=nixos - maybe this is good enough, no? Just needs a little more advertisement :-) 2015-12-07 16:33 GMT+00:00 Thomas Hunger : > There's the foundation https://nixos.org/nixos/foundation.html which > would be a great structure to collect and direct money. > > Eelco - I'm not sure where to look so I couldn't find anything about the > foundation's activity. Do you keep meeting notes somewhere online? > > best, > Tom > > > > On 7 December 2015 at 15:10, Bjørn Forsman > wrote: > >> Hi all, >> >> I've been a Nix/NixOS user for a few years now. While some parts of >> NixOS are moving forward rather quickly (awesome!), some of the Nix >> tooling is improving painfully slow (IMHO). I was wondering if any >> core devs have considered starting a fundraiser to possibly work >> full-time on some issues? >> >> Some things I'd really like to see happen (and support financially): >> >> * Better UI. I think there are many GitHub issues about this already, >> but I really like what's being pointed out here: >> https://github.com/NixOS/nix/issues/684#issuecomment-154502504. >> >> * Better support for Nix as a 3rd party package solution. Be able to >> build a distro agnostic package on a Nix system and deploy it >> (trivially) to other systems (that may not even have Nix). >> >> Best regards, >> Bjørn Forsman >> ___ >> 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] Fundraiser?
2015-12-07 18:29 GMT+00:00 Matthias Beyer : > On 07-12-2015 16:36:50, Tomasz Czyż wrote: > > https://www.bountysource.com/search?query=nixos - maybe this is good > > enough, no? Just needs a little more advertisement :-) > > This points to the old nixos package repository (github.com/nixos/nixos > <- why > does this still exist???) - I'd consider this site dead if I see this, > really! > I was pointing to the idea not to the perfect solution. Maybe after small reorganization or some improvements this platform can be used without huge effort preparing papers, legal stuff etc. > > -- > Mit freundlichen Grüßen, > Kind regards, > Matthias Beyer > > Proudly sent with mutt. > Happily signed with gnupg. > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Perl -> C++
Why not haskell? It's functional (like nix), can be compiled, in nixos, there is already infrastructure for it. 2015-12-31 10:26 GMT+00:00 Anderson Torres : > The main motivation is to get rid of dependencies. It would greatly > help in porting Nix to other architectures and systems. > > 2015-12-31 4:06 GMT-02:00 stewart mackenzie : > > This is our usage of Rust: https://github.com/fractalide/rustfbp > > The nix scripts to build all the rust components with capnproto > > dependencies in a deterministic fashion: > > https://github.com/fractalide/fractalide > > we use nix basically to replace make, it's still a WIP. > > > > I'm okay which most implementation languages used for nix, including > > Perl. I'm merely sharing my opinion on Rust. > > Though I would _like_ to see Rust used because of the barrage of > > niceties associated with it. > > > > peace > > /sjm > > > > On Thu, Dec 31, 2015 at 3:36 PM, Shea Levy wrote: > >> Nothing's stopping you from starting the conversion. If it's clearly > >> better, it will be a lot easier to convince people once you have actual > >> code to show. > > ___ > > 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] Perl -> C++
Domen, I think this evolved from why perl -> c++ not perl -> X. Not sure this went to nix -> X. But if decision was already made that c++ is the one, probably discussion is over :)? 2015-12-31 11:13 GMT+00:00 Domen Kožar : > I really don't see a correlation between rewriting perl parts in C++ and > why/how we should rewrite Nix in a different language. Could we separate > the threads? > > > Mateusz, did you get an answer to your questions to be able to start > contributing? > > On Thu, Dec 31, 2015 at 12:05 PM, stewart mackenzie > wrote: > >> Language features of the implementation language are generally lost when >> implementing a new language. >> >> So we are left with: "can be compiled and existing infrastructure." >> >> Leveraging LLVM would be astute. >> >> On 31 Dec 2015 21:47, "Tomasz Czyż" wrote: >> > >> > Why not haskell? >> > >> > It's functional (like nix), can be compiled, in nixos, there is already >> infrastructure for it. >> >> ___ >> 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] Configure WiFi networks for NetworkManager in configuration.nix?
So, how /etc/shadow file works? I did a quick look and seems it's generated
by some perl scripts (probably omitting nix store), is that correct? Maybe
the same way could be used here.
2016-01-06 15:03 GMT+00:00 Fabian Schmitthenner :
> I think you can use
>
> environment.etc."NetworkManager/system-connections/some-file" = {
> text = "Text of file";
> mode = "0400";
> }
>
> This will copy the file into /etc with appropriate mode at activation
> time. See also http://nixos.org/nixos/options.html and search for
> environment.etc for further options.
>
> (Of cause other users can still read the original file in the nix store,
> so the contents would still be reachable for all users).
>
> Greetings
>
> Fabian
>
> On 01/06/2016 02:26 PM, Vladimír Čunát wrote:
> > On 01/06/2016 12:52 AM, Mateusz Czaplinski wrote:
> >> NetworkManager expects to have network definitions as chmod 400 files in
> >> /etc/NetworkManager/system-connections/ IIRC.
> >
> > Files in nix store can't be chmod 400.
> >
> > --Vladimir
> >
> >
> >
> >
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Perl -> C++
<:)> Let's make each script a REST API in any language we want! 2016-01-07 3:26 GMT+00:00 Jakob Gillich : > > I think there are few enough people who contribute to the nix repo as it > is now. > > That is actually an argument in favor of a rewrite, C++ is not very > popular in the Linux community. Contributing to Nix will become a lot > more attractive when it's written in a language that people actually > enjoy using. At least that's how I personally feel about it, I'm just > not interested in doing any C++ anymore. > > On Wed, Jan 6, 2016, at 09:26 PM, Vladimír Čunát wrote: > > On 01/06/2016 06:36 PM, stewart mackenzie wrote: > > > Shall we start defining the nix language? > > > > None of the perl stuff deals directly with the nix language, so that > > seems rather a much independent issue. Personally, I think there are few > > enough people who contribute to the nix repo as it is now. Do you think > > starting another implementation would help the quality or something > > else? Even in a horizon of up to several years? > > > > --Vladimir > > > > > > ___ > > nix-dev mailing list > > nix-dev@lists.science.uu.nl > > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > Email had 1 attachment: > > + smime.p7s > > 5k (application/pkcs7-signature) > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Flattening pkgs tree in nixpkgs/pkgs
After playing for a while with a nixpkgs repo I have impression that categories/directories are just waste of time. * Have to be maintained * Harder to find things * Lack of any package manager which tells about it Each time I want to find a package name I do * find -name '*name*' or use github search to locate files in repo. >From maintaining perspective: (for x in `ls`; do n=$(ls $x|wc -l);echo "$n - $x";done)|sort -n 1 - backup 2 - inferno 2 - search 3 - gis 4 - display-managers 10 - altcoins 11 - science 11 - taxes 20 - virtualization 25 - kde-apps-15.12 27 - office 41 - version-management 41 - window-managers 42 - networking 59 - video 60 - editors 85 - graphics 186 - audio 224 - misc Do you see that? It's hard to define all those categories levels, some of directories have subdirectories (like applications) other not (servers). It's hard to follow. Most people know the name of the software, if not, they probably use google to find it, not using categories. Let's make the layout more clear, more accessible and easy to follow. What do you think about moving all packages into flat namespace? Let's say you have pkgs/package1/default.nix pkgs/package2/default.nix or even better: pkgs/my-package.nix pkgs/gcc.nix pkgs/gcc-5.0.nix then, you can autogenerate top-level.pkgs I'm happy to help implementing that. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs
@Luca: Why haproxy is more a tool and sigproxd is more application than tool? ./tools/networking/haproxy ./applications/networking/siproxd Why there is no common networking category? (simple, because most programs match multiple categories) Same for "groups", why gnome-terminal is more gnome and not more terminal? @Jonn Could you give an example? I'm using nix ~0.5year and not familiar with all internals yet. 2016-01-08 0:15 GMT+00:00 Jonn Mostovoy : > Your approach holds for applications, but fails for libraries, or rather, > for packages that are part of different ecosystems. > > There are some packages that just can't be taken out of their respective > "contexts" without introducing indirection. > > I agree, however, that "packages in themselves" *can* be flattened, I'm > not sure they should be though. Giving an option for a user to go over > interesting to him parts of nixpkgs over tea, clicking with mouse and > scrolling, learning about what's packaged and what's not might be not worth > taking away. > On Jan 8, 2016 1:04 AM, "Tomasz Czyż" wrote: > >> After playing for a while with a nixpkgs repo I have impression that >> categories/directories are just waste of time. >> >> * Have to be maintained >> * Harder to find things >> * Lack of any package manager which tells about it >> >> Each time I want to find a package name I do >> * find -name '*name*' >> or use github search to locate files in repo. >> >> From maintaining perspective: >> >> (for x in `ls`; do n=$(ls $x|wc -l);echo "$n - $x";done)|sort -n >> 1 - backup >> 2 - inferno >> 2 - search >> 3 - gis >> 4 - display-managers >> 10 - altcoins >> 11 - science >> 11 - taxes >> 20 - virtualization >> 25 - kde-apps-15.12 >> 27 - office >> 41 - version-management >> 41 - window-managers >> 42 - networking >> 59 - video >> 60 - editors >> 85 - graphics >> 186 - audio >> 224 - misc >> >> Do you see that? It's hard to define all those categories levels, some of >> directories have subdirectories (like applications) other not (servers). >> It's hard to follow. >> Most people know the name of the software, if not, they probably use >> google to find it, not using categories. >> >> Let's make the layout more clear, more accessible and easy to follow. >> >> What do you think about moving all packages into flat namespace? >> >> Let's say you have >> >> pkgs/package1/default.nix >> pkgs/package2/default.nix >> >> or even better: >> >> pkgs/my-package.nix >> pkgs/gcc.nix >> pkgs/gcc-5.0.nix >> >> then, you can autogenerate top-level.pkgs >> >> I'm happy to help implementing that. >> >> ___ >> 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] Flattening pkgs tree in nixpkgs/pkgs
2016-01-08 0:34 GMT+00:00 Jonn Mostovoy : > Tomasz, > > Any group of packages that depend on a runtime or maintained as whole for > different reasons. > > Kde, Gnome, haskellPackages. > Still don't see the value in it. I would just prefix them with haskellPackages-, pythonPackages-. > In fact, go through the directory tree and read some deep expressions, > you'll see the usefulness of it yourself! > Will look thanks. > You are complaining about ambiguity in categories, why not to add more > dimensions to the metadata and utility to query values of those? Some > categories are better than no categories, are better than some things > categorized and some others not categorized. > I completely agree! I think all metadata should be in metadata attribute in nix file :-) > On Jan 8, 2016 1:21 AM, "Tomasz Czyż" wrote: > >> @Luca: >> Why haproxy is more a tool and sigproxd is more application than tool? >> ./tools/networking/haproxy >> ./applications/networking/siproxd >> Why there is no common networking category? (simple, because most >> programs match multiple categories) >> >> Same for "groups", why gnome-terminal is more gnome and not more terminal? >> >> @Jonn >> Could you give an example? I'm using nix ~0.5year and not familiar with >> all internals yet. >> >> 2016-01-08 0:15 GMT+00:00 Jonn Mostovoy : >> >>> Your approach holds for applications, but fails for libraries, or >>> rather, for packages that are part of different ecosystems. >>> >>> There are some packages that just can't be taken out of their respective >>> "contexts" without introducing indirection. >>> >>> I agree, however, that "packages in themselves" *can* be flattened, I'm >>> not sure they should be though. Giving an option for a user to go over >>> interesting to him parts of nixpkgs over tea, clicking with mouse and >>> scrolling, learning about what's packaged and what's not might be not worth >>> taking away. >>> On Jan 8, 2016 1:04 AM, "Tomasz Czyż" wrote: >>> >>>> After playing for a while with a nixpkgs repo I have impression that >>>> categories/directories are just waste of time. >>>> >>>> * Have to be maintained >>>> * Harder to find things >>>> * Lack of any package manager which tells about it >>>> >>>> Each time I want to find a package name I do >>>> * find -name '*name*' >>>> or use github search to locate files in repo. >>>> >>>> From maintaining perspective: >>>> >>>> (for x in `ls`; do n=$(ls $x|wc -l);echo "$n - $x";done)|sort -n >>>> 1 - backup >>>> 2 - inferno >>>> 2 - search >>>> 3 - gis >>>> 4 - display-managers >>>> 10 - altcoins >>>> 11 - science >>>> 11 - taxes >>>> 20 - virtualization >>>> 25 - kde-apps-15.12 >>>> 27 - office >>>> 41 - version-management >>>> 41 - window-managers >>>> 42 - networking >>>> 59 - video >>>> 60 - editors >>>> 85 - graphics >>>> 186 - audio >>>> 224 - misc >>>> >>>> Do you see that? It's hard to define all those categories levels, some >>>> of directories have subdirectories (like applications) other not (servers). >>>> It's hard to follow. >>>> Most people know the name of the software, if not, they probably use >>>> google to find it, not using categories. >>>> >>>> Let's make the layout more clear, more accessible and easy to follow. >>>> >>>> What do you think about moving all packages into flat namespace? >>>> >>>> Let's say you have >>>> >>>> pkgs/package1/default.nix >>>> pkgs/package2/default.nix >>>> >>>> or even better: >>>> >>>> pkgs/my-package.nix >>>> pkgs/gcc.nix >>>> pkgs/gcc-5.0.nix >>>> >>>> then, you can autogenerate top-level.pkgs >>>> >>>> I'm happy to help implementing that. >>>> >>>> ___ >>>> nix-dev mailing list >>>> nix-dev@lists.science.uu.nl >>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>>> >>>> >> >> >> -- >> Tomasz Czyż >> > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs
2016-01-08 0:37 GMT+00:00 Mathnerd314 : > On Thu, Jan 7, 2016 at 5:04 PM, Tomasz Czyż wrote: > >> What do you think about moving all packages into flat namespace? >> > > GitHub limits directories to 1000 files, for example here: > https://github.com/rust-lang/rust/tree/master/src/test/run-pass > We definitely have more than that in nixpkgs, so some form of hierarchy is > needed. > LOL, didn't know about that. > > I would suggest doing it by hosting site / provider: all KDE packages in > one directory, all GNOME in another, GNU in a third, SourceForge in a > fourth, Kernel.org in a fifth, etc., with a final "misc" directory for > one-package sites. > Looks like good way, but not sure about few things. So github.com whould be another provider? Seems like haskellPackages, pythonPackages, *Packages could follow that rule if we treat lang-repos as providers. > > It does mean that packages have to be moved around when their hosting > changes (e.g. VLC's move away from Sourceforge), but on the other hand it > makes it very easy to find all broken packages when a site shuts down (e.g. > Google Code). In general packages change hosting very infrequently, so it > seems reasonable to me. > > The directory structure under that can be flat or chosen by maintainers. > > Search, nix-env, and command-not-found remain the best way of finding > packages, as in https://nixos.org/wiki/Howto_find_a_package_in_NixOS. > Sorry I was not precise. The problem is to locate program nix file, not the name/attribute. > > -- Mathenrd314 > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs
As Mathnerd314 said, filesystem layout != attribute layout. This should still work as right now. 2016-01-08 1:39 GMT+00:00 Jookia <166...@gmail.com>: > On Thu, Jan 07, 2016 at 06:29:35PM -0700, Mathnerd314 wrote: > > On Thu, Jan 7, 2016 at 6:25 PM, Jookia <166...@gmail.com> wrote: > > > > > On Fri, Jan 08, 2016 at 12:38:52AM +, Tomasz Czyż wrote: > > > > 2016-01-08 0:34 GMT+00:00 Jonn Mostovoy : > > > > Still don't see the value in it. I would just prefix them with > > > > haskellPackages-, pythonPackages-. > > > > > > How would we do something like 'buildInputs = with pythonPackages; > > > [pycrypto]; ' > > > with that kind of system? I imagine things would get very verbose very > > > quickly. > > > > > > > We would still have all-packages.nix, so the attribute paths would not > > change. > > > > -- Mathnerd314 > > Would this still work with conflicting namespaces, such as Python3Packages? > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs
2016-01-08 1:28 GMT+00:00 Mathnerd314 : > On Thu, Jan 7, 2016 at 5:44 PM, Tomasz Czyż wrote: > >> 2016-01-08 0:37 GMT+00:00 Mathnerd314 : >> >>> >>> I would suggest doing it by hosting site / provider: all KDE packages in >>> one directory, all GNOME in another, GNU in a third, SourceForge in a >>> fourth, Kernel.org in a fifth, etc., with a final "misc" directory for >>> one-package sites. >>> >> Looks like good way, but not sure about few things. So github.com whould >> be another provider? >> Seems like haskellPackages, pythonPackages, *Packages could follow that >> rule if we treat lang-repos as providers. >> > Yeah, language specific stuff should be their own directories. > GitHub/SF/etc. are catch-alls; in theory there could be 1000's of projects > from them, but in practice it seems that most of the projects on there are > dead, abandoned, or mirrored somewhere else. > > The goal is to have a unique location for each package, so that two people > don't package the same thing twice (which has already happened a few times > with our current structure). > Didn't see that yet, but looks like another good reason to make some changes around that. > Hosting seems like a good index but there might be something else (month > project was founded?). > wow :-) Maybe first letter? > > Search, nix-env, and command-not-found remain the best way of finding >>> packages, as in https://nixos.org/wiki/Howto_find_a_package_in_NixOS. >>> >> Sorry I was not precise. The problem is to locate program nix file, not >> the name/attribute. >> > Well, once you have the attribute it is usually not too hard to find the > file by tracing through the code. > Exactly, instead of going to the file you have to follow/trace the code. > > And some packages are spread across multiple files, e.g. kde4.okular has > the source hash in pkgs/desktops/kde-4.14/kde-package/4.14.3.nix, the > description in pkgs/desktops/kde-4.14/kdegraphics/okular.nix, and the glue > code in pkgs/desktops/kde-4.14/kde-package/default.nix. Keeping all the > relevant files in one directory seems like the most one could ask for. > :-) > > > -- Mathnerd314 > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs
2016-01-08 14:58 GMT+00:00 Vladimír Čunát : > On 01/08/2016 02:53 PM, Daniel Peebles wrote: > > I think the categories/directories could make more sense than they do > > today, and that all-packages.nix should be abolished > > The largest problem I see for categorization is ambiguity (mentioned > already). The "categories" will always overlap nontrivially, so we would > better track such information in a different way than directory > structure, e.g. meta.tags = [ "foo" "bar" "baz" ]; (perhaps even > hierarchical tags). > +1 > > Currently a significant portion of our packages is in > pkgs/development/libraries/ - which is a rather bad category IMO. If I > didn't use tab-completion, I would've pushed this issue hard long time > ago already. > > Personally, I would make it much flatter and also make it (almost) > exactly correspond to our *attribute* hierarchy. > +100 > > We had some discussion around this on NixCon. IMO best time to execute > this will be during release stabilization to minimize cherry-pick > conflicts due to file renames, but first we need a clear consensus. > > > Vladimir > > > > _______ > 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] Flattening pkgs tree in nixpkgs/pkgs
2016-01-08 15:47 GMT+00:00 zimbatm : > The issue with naming is that everyone has their opinion. > > Since other smart people have already played the categorization game can I > suggest to restrict the discussion to which *existing* structure we should > adopt ? > There are a lot of big repositories out there: debian, gentoo portage, > archlinux, pkgsrc, ... One of them is bound to work, mostly. The nice > benefit would also be of not having to talk about categorization ever > again, unless the packaged project doesn't exist in the canonical > repository. > That's quite good observation. > > I don't care what structure we chose as long as it's shallower than what > we have right now. Like OP I'm tired of searching for packages and then > entering long paths in my shell. > > > On Fri, 8 Jan 2016 at 15:03 Bjørn Forsman wrote: > >> On 8 January 2016 at 15:58, Vladimír Čunát wrote: >> > Personally, I would make it much flatter and also make it (almost) >> > exactly correspond to our *attribute* hierarchy. >> >> That's a good idea, I think! >> >> /Bjørn >> ___ >> 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] Flattening pkgs tree in nixpkgs/pkgs
2016-01-08 15:55 GMT+00:00 Arseniy Seroka : > In my opinion we should spend our time and skills to solve more important > issues and problems. > On the other hand I agree with that, on the other I wasted some time figuring that stuff out and I'll waste more. And as it seems not only me... Fixing this shouldn't be that hard I think. If we will go to the point where "top-packages" could be autogenerated or not needed at all (I'm not sure what plans are about that but probably some duplication could be limited there), than fixing file layout will not be very time consuming (imho). > On 8 Jan 2016 18:53, "Domen Kožar" wrote: > >> Going for attribute set names is hard, since we have many aliases. >> >> We had a discussion about this at NixCon (I think Oliver Charles has the >> notes). >> >> In general, the only thing that really matters here is not to waste >> people time. Currently it's suboptimal, I'd really just be happy if we had >> flat structure. That does impose problems since it's hard to find a system >> to categorize software. >> >> It's really worth checking out what other package managers do and see who >> is happy about their structure. >> >> On Fri, Jan 8, 2016 at 4:47 PM, zimbatm wrote: >> >>> The issue with naming is that everyone has their opinion. >>> >>> Since other smart people have already played the categorization game can >>> I suggest to restrict the discussion to which *existing* structure we >>> should adopt ? >>> There are a lot of big repositories out there: debian, gentoo portage, >>> archlinux, pkgsrc, ... One of them is bound to work, mostly. The nice >>> benefit would also be of not having to talk about categorization ever >>> again, unless the packaged project doesn't exist in the canonical >>> repository. >>> >>> I don't care what structure we chose as long as it's shallower than what >>> we have right now. Like OP I'm tired of searching for packages and then >>> entering long paths in my shell. >>> >>> >>> On Fri, 8 Jan 2016 at 15:03 Bjørn Forsman >>> wrote: >>> >>>> On 8 January 2016 at 15:58, Vladimír Čunát wrote: >>>> > Personally, I would make it much flatter and also make it (almost) >>>> > exactly correspond to our *attribute* hierarchy. >>>> >>>> That's a good idea, I think! >>>> >>>> /Bjørn >>>> ___ >>>> nix-dev mailing list >>>> nix-dev@lists.science.uu.nl >>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>>> >>> >>> ___ >>> nix-dev mailing list >>> nix-dev@lists.science.uu.nl >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>> >>> >> >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> >> > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Flattening pkgs tree in nixpkgs/pkgs
2016-01-09 20:41 GMT+00:00 Matthias Beyer : > On 08-01-2016 01:32:34, Profpatsch wrote: > > > > Now the problem is: Who has enough time to refactor everything? :) > > > > +1 on this. I think that flattening the file tree for nixpkgs/pkgs is just > a > waste of time. > > As the OP of this thread says, he has to use `find` all the time. Now > what? Now I try to change it. > We > all have and it works perfectly fine for all of us. I explicitly excluded myself from the "all" group so I assume you cannot use "all" here, and according to that discussion looks like there is few people who have different opinions about current situation. > Why changing (or even > debating) about things which _work_ and where changes do not improve the > experience of the end-user? > Sure, please, help Debian project :-) > > I mean, come one, nixos is not a big community who has time to argue about > infrastructure which does change (note: I don't use the term "improve" > here) > something for the maintainers but doesn't change anything for the end user! > Is anyone here who knows any nix user which do not read nix files and is only "end-user"? For me personally as "end-user" the file structure is part of user experience. Same as nix command line interface. > User experience is what comes first, and this proposal doesn't alter user > experience (neither improve nor worsen) at all. So why focusing on > something > like this? Why debating about internal infrastructure changes while the > end-user > is faced with hydra not building for weeks or while there are packages out > there > which do not run because of unmet dependencies,... I could possibly go on. > I > don't want to start a conversation on the latter two points in here, but I > guess > you see what I mean. > I as wrote, for me it IS user-experience. And I'm not sure what the projejct short/long term goals are but I think most users are developers/admins who write nix files anyway. Please define what for you is real end-user of nixos and please give some examples what are cases worth to waste time for you. btw, why some people argue about others people time? There is bunch of people want to make some positive change and they want to spent some time on that (whatever the change is). I wrote that I would like to help with that (or maybe even implement that if I have enough knowledge), please if you think it's waste of time, propose something else to change and make it happen. > -- > Mit freundlichen Grüßen, > Kind regards, > Matthias Beyer > > Proudly sent with mutt. > Happily signed with gnupg. > > ___ > 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] lightdm remembering last session on boot
I had this issue before, there is even ticket for that https://github.com/NixOS/nixpkgs/issues/10349 For me, on some machines problem disappeared when I installed from scratch, on some still exists and on some disappeared after I upgraded (I'm using unstable). I had not enough time to track the problem down. 2016-03-22 10:56 GMT+00:00 José Romildo Malaquias : > Hello. > > Differently from other linux distributions, on my (unstable) nixos > system the lightdm display manager does not remember the last chosen > session after rebooting. How can this be fixed? > > lightdm is always preselecting the first entry in the sessions menu, and > never consider my last choice. In other operating systems it remembers > which was last chosen. > > Regards, > > José Romildo > ___ > 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] Nixpkgs versioning
Vladimir: true. There is any rule for transforming app name + version to attribute name? underscores and dashes are ok in attribute names but versions mostly use dots (not sure if replacing them with underscore or dash is a good idea as those chars are used in version strings as well). I assume adding/allowing more chars in attribute names will make parsing more difficult, it that the limiting factor? 2016-03-30 13:41 GMT+00:00 Vladimír Čunát : > On 03/30/2016 12:02 PM, Peter Simons wrote: > > Besides, I thought the universally agreed best way forward was to drop > > the notion of installing packages "by name" from the CLI anyway? > > True, we push towards using attribute names instead. There can be > version embedded in attribute names, e.g. we have llvm_37, but `@` makes > little sense in there... > > --Vladimir > > > > ___ > 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] Nixpkgs versioning
2016-03-30 17:31 GMT+00:00 Vladimír Čunát : > On 03/30/2016 04:42 PM, Tomasz Czyż wrote: > > There is any rule for transforming app name + version to attribute name? > > None AFAIK. And there's a related rule to strive to avoid using multiple > versions and avoid specifying the version in attribute name at all. > Yeah, but I assume we are talking about examples like you wrote, llvm_37 > > --Vladimir > > > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nixpkgs versioning
I would say it maybe doesn't matter for main nix repo and nixpkgs. But when you have your development platform with private packages this can be an issue. I have the situation now where I have one repo with private packages but for different projects I use different versions of the same package. I could use totally separated dependencies per project, but for some cases I prefer to use central repo (to avoid repetitions mostly) and in that case I need package versioning (I'm using _ right now which is not that convininet). 2016-03-30 23:18 GMT+00:00 Colin Putney : > > > On Mar 30, 2016, at 1:55 AM, Jakob Gillich wrote: > > > > FYI npm also uses @ for this purpose (e.g. npm install foo@1.0). I don't > > think I ever had to escape it (?). > > I don’t know about Guix, but with NPM, version names are much more > important than they are with nix. NPM uses semver and constraint solving to > resolve dependencies based on the version numbers, so the actual x.y.z > number attached to a given release is critical. With nix, there’s no > central registry of packages, release and their numbers, and we often > specify dependencies with a Git rev and hash. We use fixed-output > derivations to ensure that we always get the right dependency, so the > version number of a given derivation doesn’t matter that much, and often > doesn’t exist. > > Colin > ___ > 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] Nixpkgs versioning
8,
> xf86-video-tdfx-1.4.6,
> > xf86-video-trident-1.3.7, xf86-video-vesa-2.3.4,
> xf86-video-vmware-13.1.0,
> > xgamma-1.0.6, xhost-1.0.7, xinput-1.6.2, xkbevd-1.1.4,
> xkeyboard-config-2.17,
> > xlockmore-5.46, xlsatoms-1.1.2, xmlto-0.0.28, xmodmap-1.0.9,
> > xorg-server-1.18.1, xorriso-1.4.2, xproto-7.0.28, xrandr-1.5.0,
> xterm-322,
> > xvid-1.3.4, xvinfo-1.1.3, xz-5.2.2, yasm-1.3.0, yelp-3.18.1,
> > yelp-tools-3.18.0, yelp-xsl-3.18.1, ykclient-2.15,
> youtube-dl-2016.03.01,
> > zlib-1.2.8, znc-1.6.2, zynaddsubfx-2.5.3
> >
> > ** Programming interfaces
> >
> > *** Build systems always set the ‘SOURCE_DATE_EPOCH’ environment
> variable
> > *** New (guix graph) graph manipulation module, abstracted from ‘guix
> graph’
> > *** New (guix cve) module, to navigate the CVE database
> > *** ‘build-things’ procedure takes a new ‘mode’ parameter
> > *** Mass rename of ‘dmd’ to ‘shepherd’ in the (gnu …) modules
> > *** New ‘gnome-desktop-service’ and ‘xfce-desktop-service’ procedures
> > *** ‘pam-root-service-type’ can be extended with cross-cutting
> transformations
> > *** ‘package-with-python2’ honors the ‘python2-variant’ package
> property
> > (see <http://bugs.gnu.org/22437>)
> >
> > ** Noteworthy bug fixes
> >
> > *** Grafts are applied recursively (<http://bugs.gnu.org/22139>)
> > *** Commands correctly handle numbers in package names
> > (http://bugs.gnu.org/19219)
> > *** ‘guix-daemon’ deduplication code detects corrupt items
> > *** eudev now populates /dev/disk/by-{id,label}
> > *** Selected locale is automatically built (<http://bugs.gnu.org/22572
> >)
> > *** Substitutes can be downloaded over HTTPS (<
> http://bugs.gnu.org/22937>)
> > *** umask explicitly set in /etc/profile (<http://bugs.gnu.org/22650>)
> > *** ‘guix system init’ writes GC root on the target file system
> > (<http://bugs.gnu.org/22802>)
> > *** ‘guix system vm’ now works in the absence of KVM support
> > (<http://bugs.gnu.org/22633>)
> > *** GuixSD includes an Info reader by default (<
> http://bugs.gnu.org/22598>)
> > *** MacBook keyboards are now properly detected (<
> http://bugs.gnu.org/20433>)
> > *** GRUB searches root by label or UUID (<http://bugs.gnu.org/22281>)
> > *** ‘guix package --search-paths’ honors propagated inputs
> > (<http://bugs.gnu.org/22073>)
> > *** GCC uses ‘C_INCLUDE_PATH’ et al. instead of ‘CPATH’
> > (<http://bugs.gnu.org/22186>)
> > *** ‘ld-wrapper’ computes library search path based on all ‘-L’ flags
> > (<http://bugs.gnu.org/21941>)
> > *** ‘guix environment --container’ gracefully handles abnormal exists
> > (<http://bugs.gnu.org/21958>)
> >
> > ** Native language support
> >
> > *** Updated translations: da, de
> > *** New translation: pl (Polish)
> >
> >
> > Please report bugs to bug-g...@gnu.org.
> > Join guix-de...@gnu.org and #guix on Freenode for discussions.
> >
> > Thanks to everyone who contributed to this release:
> >
> > 2Al McElrath
> >137Alex Kost
> > 3Alex Sassmannshausen
> > 3Alex Vong
> > 1Alírio Eyng
> > 2Amirouche Boubekki
> > 63Andreas Enge
> > 79Andy Wingo
> > 63Ben Woodcroft
> > 3Chris Marusich
> > 35Christopher Allan Webber
> > 1Christopher Baines
> > 2Danny Milosavljevic
> > 3David Hashe
> > 56David Thompson
> > 1Dmitry Bogatov
> > 9Eelco Dolstra
> >360Efraim Flashner
> > 42Eric Bavier
> > 2Erik Edrosa
> > 10Fabian Harfert
> > 28Federico Beffa
> > 2Florian Paul Schmidt
> > 1George Clemmer
> > 9Jan Nieuwenhuizen
> > 1Jessica Tallon
> > 3Jochem Raat
> > 1John Darrington
> > 1Jookia
> > 1Justus Winter
> > 2Kyle Meyer
> >198Leo Famulari
> >477Ludovic Courtès
> > 1Lukas Gradl
> > 2Manolis Ragkousis
> > 1Mario Daniel Ruiz Saavedra
> >119Mark H Weaver
> > 26Mathieu Lirzin
> > 1Michael Vetter
> > 8Nils Gillmann
> > 1Petter
> > 8Pjotr Prins
> > 2Raimon Grau
> > 6Rene Saavedra
> >342Ricardo Wurmus
> > 1Rob Syme
> > 1Rodger Fox
> > 10Roel Janssen
> > 89Sou Bunnbu (宋文武)
> > 19Taylan Ulrich Bayırlı/Kammer
> > 8Tobias Geerinckx-Rice
> > 1Tomáš Čech
> >
> > Ludovic, on behalf of the Guix team.
> >
> >
> >
> > --
> > ___
> > 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] Custom Channel with Custom Modules
ng ‘applyIfFunction’ at > /nix/store/21ldmqrpq104n0aq3b8qzdpwamdzza9n-nixos/nixos/nixpkgs/lib/modules.nix:127:29, > called > from > /nix/store/21ldmqrpq104n0aq3b8qzdpwamdzza9n-nixos/nixos/nixpkgs/lib/modules.nix:98:39: > > undefined variable ‘config’ at > /nix/store/k86a1d8cyzhn8kj4gsq1nc12vn301f22-user-environment/bv-nix/pkgs/bv-users/bv-user-daemon.nix:8:8 > > I obviously don't understand what need to be in the channel's default.nix > to set up imports from the nixos channel so this can work. Or perhaps I'm > doing something completely wrong. Either way, I'd appreciate comments. I > plan to write up the results of this particular journey so I can add them > to the nixos wiki. A lot of companies out there will need custom channels, > custom module, and custom packages, that cannot be added into the public > github repository. Therefore I think this a worthwhile endeavor. > > Cheers. > _ > > [image: Bazaarvoice] > > Paul Cooley > Senior Dev Ops Engineer > o: m: 281-435-2328 > e: paul.coo...@bazaarvoice.com > Site <http://www.bazaarvoice.com/> | Blog > <http://www.bazaarvoice.com/blog> | Twitter > <http://twitter.com/Bazaarvoice> > > > > > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Haskell dependencies in a project
Hi,
I'm trying to make a nix/haskell package (with executable) with some
dependencies (from nixpkgs and some locally declared).
I have my-dep directory with haskell package exposing library and src
directory which contains application using my-dep dependency and aeson
package from nixpkgs.
Here is my nix expression:
{ pkgs ? import {} }:
let
my-dep = pkgs.haskellPackages.mkDerivation {
pname = "my-dep";
version = "0.1.0.0";
src = ./my-dep;
isLibrary=true;
isExecutable=false;
license = with pkgs; stdenv.lib.licenses.unfree;
doHaddock=false;
};
dependencies = with pkgs.haskellPackages; [
aeson my-dep
];
ghc = pkgs.haskellPackages.ghcWithPackages(hs:(dependencies));
in
pkgs.haskellPackages.mkDerivation {
pname = "haskell-project";
version = "0.1.0.0";
src = ./src;
isLibrary = false;
isExecutable = true;
buildTools = [ghc];
buildDepends = dependencies;
license = with pkgs; stdenv.lib.licenses.unfree;
}
(library expose 1 function which print text and main project just imports
aeson and my-dep and uses function from library)
When building it, I am getting error:
Building haskell-project-0.1.0.0...
Preprocessing executable 'haskell-project' for haskell-project-0.1.0.0...
Main.hs:2:18:
Could not find module ‘MyDep’
Use -v to see a list of the files searched for.
builder for
‘/nix/store/43lbwp4qfigjwkf97nqp4h21hsrf5yr2-haskell-project-0.1.0.0.drv’
failed with exit code 1
error: build of
‘/nix/store/43lbwp4qfigjwkf97nqp4h21hsrf5yr2-haskell-project-0.1.0.0.drv’
failed
There is no problem with aeson (it's complaining about aeson when I remove
dependency from nix expression), but there is a problem with my-dep
dependency.
Question is, how I should declare dependency for my-dep to make it working,
to make haskell-project to use that dependency correctly?
(if I run nix-shell with this expression I have the same error, but if I
"cd" to my-dep directory and run ghc ../src/Main.hs it's working, it looks
like ghs tries search for MyDep.hs only in current directory instead of
package directory).
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell dependencies in a project
Brian, thank you for your response.
2016-04-03 5:35 GMT+00:00 Brian McKenna :
> You need to call pkgs.haskellPackages.callPackage on my-dep, so it
> will look something like:
>
> dependencies = with pkgs.haskellPackages; [
> aeson (callpackage my-dep { })
> ];
>
> It's also possible to use the 'override' attribute instead, which
> would be useful if you later add a dependency which uses my-dep:
>
>
> https://nixos.org/nixpkgs/manual/#how-to-build-projects-that-depend-on-each-other
Do you know why I need to call callPackage? (I read in the manual from link
you provided that there is some package registration/discovery mechanism,
do you know if there is any explanation how that works?)
I have one problem with callPackage, it looks for a file "default.nix" in
directory "my-dep", but I wanted to declare that dependency locally (in the
same file as shown in example) - is it possible to use that kind of
dependency? (it works for me when I use python project for example).
>
>
> On 3 April 2016 at 12:15, Tomasz Czyż wrote:
> > Hi,
> >
> > I'm trying to make a nix/haskell package (with executable) with some
> > dependencies (from nixpkgs and some locally declared).
> >
> > I have my-dep directory with haskell package exposing library and src
> > directory which contains application using my-dep dependency and aeson
> > package from nixpkgs.
> >
> > Here is my nix expression:
> >
> > { pkgs ? import {} }:
> > let
> > my-dep = pkgs.haskellPackages.mkDerivation {
> > pname = "my-dep";
> > version = "0.1.0.0";
> > src = ./my-dep;
> > isLibrary=true;
> > isExecutable=false;
> > license = with pkgs; stdenv.lib.licenses.unfree;
> > doHaddock=false;
> > };
> > dependencies = with pkgs.haskellPackages; [
> > aeson my-dep
> > ];
> > ghc = pkgs.haskellPackages.ghcWithPackages(hs:(dependencies));
> > in
> > pkgs.haskellPackages.mkDerivation {
> > pname = "haskell-project";
> > version = "0.1.0.0";
> > src = ./src;
> > isLibrary = false;
> > isExecutable = true;
> > buildTools = [ghc];
> > buildDepends = dependencies;
> > license = with pkgs; stdenv.lib.licenses.unfree;
> > }
> >
> > (library expose 1 function which print text and main project just imports
> > aeson and my-dep and uses function from library)
> >
> > When building it, I am getting error:
> >
> >
> > Building haskell-project-0.1.0.0...
> > Preprocessing executable 'haskell-project' for haskell-project-0.1.0.0...
> >
> > Main.hs:2:18:
> > Could not find module ‘MyDep’
> > Use -v to see a list of the files searched for.
> > builder for
> > ‘/nix/store/43lbwp4qfigjwkf97nqp4h21hsrf5yr2-haskell-project-0.1.0.0.drv’
> > failed with exit code 1
> > error: build of
> > ‘/nix/store/43lbwp4qfigjwkf97nqp4h21hsrf5yr2-haskell-project-0.1.0.0.drv’
> > failed
> >
> >
> > There is no problem with aeson (it's complaining about aeson when I
> remove
> > dependency from nix expression), but there is a problem with my-dep
> > dependency.
> >
> > Question is, how I should declare dependency for my-dep to make it
> working,
> > to make haskell-project to use that dependency correctly?
> >
> > (if I run nix-shell with this expression I have the same error, but if I
> > "cd" to my-dep directory and run ghc ../src/Main.hs it's working, it
> looks
> > like ghs tries search for MyDep.hs only in current directory instead of
> > package directory).
> >
> > ___
> > 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] A suggestion of Nixpkgs contributing workflow - help and opinions needed
I would say it depends on what are you planning to do with your packages. If you are planning to push them to upstream, that's the good way IMHO. In the other case I would create custom packages in ~/.nixpkgs/config.nix (and friends) or custom channel so your packages could be developed "independently" from nixpkgs (of course you could still use/depend on nixpkgs) 2016-04-11 19:05 GMT+00:00 Vladimír Čunát : > On 04/10/2016 08:51 PM, Anderson Torres wrote: > > My question is: how can I "update" Current if I update Nixos locally, > > AND propagate the update to the derived branches? > > You might use topgit workflow. It's quite a nice tool to develop > multiple features at once that can *depend* on each other. AFAIK it > assumes you want to export one commit per feature in the end, which > might not be what you want... > > (Underneath it uses merge commits, not rebasing.) > > --Vladimir > > > > ___ > 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] Monitoring by default
That's interesting, however I don't think this should be part of
"monitoring" service.
I'm using prometheus daily and I'm following its development and I don't
think it's stable enough (for example backend/storage changes quite often),
and prometheus is far from 1.0 (stable).
I don't agree that something like "monitoring" should be tied to specific
software. I personally like debian-way better than redhat-way ("apache2"
service instead of "httpd" service which is apache or nginx).
So I think I would like to have prometheus service and I would build my
system using those blocks. On that level I can use nixops to make a
"monitoring" service which consists of many other applications (let's say
prometheus + some dashboard + other modules around or I can use totally
different software instead, but still it will be monitoring service).
2016-04-21 21:41 GMT+01:00 Layus :
> I like the idea too.
>
> It seems to me that distributions really lack metrics collection and
> data analysis.
> For example, it would be nice to have automatic gathering of the battery
> usage (charge/discharge/capacity) and an easy access to compiled
> historical data like the capacity loss over the years.
>
> I know this is far less ambitious than what you describe, but it would
> be a great entry point for new users.
> If they like it, they may want to gather wore statistics.
>
> Anyway, I think it makes total sense to have such a feature in NixOS.
>
> -- Layus.
>
> On 20/04/16 11:49, Rok Garbas wrote:
> > +1 for the initiative. i don't believe personally enabling monitoring
> > by default should be the right way to go (since we all use nixos in
> > different contexts), but having a commented instructions in generated
> > configurations.nix would be the way to go.
> >
> > it would be nice if systemd monitoring stuff could be used as well:
> > https://github.com/garbas/dotfiles/blob/master/nixos/rok.nix#L236
> > above line makes systemd-cgtop showing numbers.
> >
> >
> >
> > On Wed, Apr 20, 2016 at 8:44 AM, Alexei Robyn wrote:
> >> Seems interesting. You mention alerts for "System software too old.",
> but
> >> the only vaguely-universal definition of "too old" I can think of would
> be
> >> "missing security updates", and that's both debatable and an area where
> >> NixOS is currently fairly lacking in infrastructure and tooling.
> >>
> >> Default collection of metrics beyond what is necessary to provide useful
> >> alerts is a bad idea. Alerts have essentially universal usefulness,
> >> statistics less so - they're unnecessary for most desktops and small
> >> servers. At least until you have issues, so of course it'd be nice if
> they
> >> were easy to switch on :p.
> >>
> >> - Alexei
> >>
> >>
> >> On Wed, Apr 20, 2016, at 12:40 AM, Svein Ove Aas wrote:
> >>
> >> Hi all,
> >>
> >> People who are not interested in reliability or monitoring can stop
> reading
> >> now.
> >>
> >> --
> >>
> >> I've written up a "design doc" (statement of intent?) for how we might
> do
> >> monitoring-by-default. Once I think there is a reasonable level of
> consensus
> >> about how we should do this, I'll go ahead and implement what's in the
> >> document, but I'd like to make sure we're all on the same page first;
> >> especially as I want this to be on by default.
> >>
> >> So I'd like your input. Can you take a look?
> >>
> >> --
> >> Svein Ove Aas
> >> ___
> >> nix-dev mailing list
> >> nix-dev@lists.science.uu.nl
> >> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >>
> >>
> >>
> >> ___
> >> nix-dev mailing list
> >> nix-dev@lists.science.uu.nl
> >> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >>
> >
> >
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fix build for some kde-5 components
Karn: why not just PR on github? 2016-04-24 3:14 GMT+01:00 Karn Kallio : > > Several phonon include paths reference the nonexistent include > directory "Phonon" which breaks the kde5 build. The attached patch > fixes these replacing them with the correct "phonon" include directory. > > The phonon expression itself produces a "phonon" include directory, so > I have used that as the definition of correct. > > ___ > 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] haskell structure for all of nixpkgs
Hey Stewart, do you have any description of what you are exactly talking about? Personally I'm not following all the changes in packaging. If you could describe the key differences or just put some github links to show them that would be great. 2016-04-23 20:06 GMT+01:00 stewart mackenzie : > Every time I come into contact with Peter Simon's work on Haskell I > find myself growing green with envy. > > This approach seems to be a much better way of structuring nixpkgs in > general. > > Now closure-size, a monumental job was undertaken successfully, what's > the feasibility of implementing the Haskell approach across the entire > nixpkgs. > > How does one even start thinking about this? > > Is it even worth it? > > /sjm > ___ > 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] Nix in a Cluster Environment Talk Slides
Thanks Kevin, good stuff. 2017-01-19 22:15 GMT+00:00 Kevin Cox : > Hello, > > There was recently a Nix meetup in Dublin and a couple of people > expressed interest in my talk on using Nix in a clustered environment. > Unfortunately I fat-fingered the recording but I have posted my slides > for those who find them useful. > > https://kevincox.ca/2017/01/19/nix-and-mesos-talk/ > > I'll try to make sure that we have the recording figured out for future > meetups so that those who can't make it can get more value 🙂 > > Thanks again to Tomasz and Bariša for organizing and hosting the event, > it's great so see such great attendance. Also if you find yourself in > the Dublin area feel free to join us: https://www.meetup.com/NixOS-Dublin/ > > Cheers, Kevin > > > ___ > 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] Is it possible to limit nix access to sudoers and/or a group?
It's probably against nix design but let's try. Just an idea (haven't tried yet). Install nix as NIXUSER (without the deamon, just nix to run builds). Other users can access paths, build by nix from /nix/store but they won't access nix as it belongs to NIXUSER. But they probably can access nix at any point at this stage (or maybe they need sudo to be added to a group, not sure). 2017-01-20 2:15 GMT+00:00 Mateusz Czaplinski : > I'd like to build a system where regular users cannot access nix > commands, daemon, etc. Ideally, only users belonging to a particular > group could access those. (Probably worse solution, but still > acceptable, if this was limited to sudoers only.) > > Is it possible? If yes, how to do that on NixOS? > > Thanks & Best Regards, > /Mateusz. > ___ > 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] Is it possible to limit nix access to sudoers and/or a group?
So obvious :-) Eelco, is that the case with NixOS only or that works also when you install Nix as regular user, let's say on Ubuntu? 2017-01-20 12:07 GMT+00:00 Eelco Dolstra : > Hi, > > On 01/20/2017 03:15 AM, Mateusz Czaplinski wrote: > > > I'd like to build a system where regular users cannot access nix > > commands, daemon, etc. Ideally, only users belonging to a particular > > group could access those. (Probably worse solution, but still > > acceptable, if this was limited to sudoers only.) > > > > Is it possible? If yes, how to do that on NixOS? > > Yes, by setting allowed-users in nix.conf, or nix.allowedUsers in the NixOS > configuration, e.g. > > nix.allowedUsers = [ "@wheel" ]; > > The default is "*". I've been thinking that it might be good to tighten > this to > something like [ "root" "@users" ], to disallow (say) system daemons. > > -- > Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ > _______ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Grub problem: external pointer tables not supported
Hello, recently my grub said this to me after I restarted computer: Error: external pointer tables not supported Error: you need to load the kernel first. Every option I select with nix (also past generations) shows me this message. I updated the system to 17.03pre99792.c311871 on 2016-12-23 and restarted it before multiple times (and worked). I don't remember if I did other updates, but this is what's grub menu shows me. My disk layout is: EFI boot partition for grub, next partition is encrypted luks volume and ZFS on top of it. This setup worked for me for 1.5 year now without any issue. Anybody is aware of any changes to grub/zfs recently or had same issue? Any suggestions how I can recover from it or what can be wrong? Tom ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Grub problem: external pointer tables not supported
2017-01-23 16:15 GMT+00:00 Roger Qiu : > Hey, > > Changing nixos generations won't affect the grub boot partition, that only > changes which nixos kernel and initramfs image gets booted. > Because all boot options are not working one of my guesses is that in new nix version, wrong config was generated when I did system update which broke all options. > This looks like an error in the Grub partition. Maybe you recently updated > it or changed it, or the partition got corrupted. > It's possible, I tried to boot from USB, do ``nixos-install --no-root-passwd`` to reinstall the system, but I'm not sure how to force grub/uefi partition recreation/reinstalling, any idea? Should I just format it and will be recreated? > This is why other operating systems tend to make their /boot read-only... > > If you can't get into the OS, then you can try booting off a USB, and then > edit the boot partition. Or run the uefi terminal app (but this one never > worked for me). If you had cloned/raided boot partitions you can try > changing the uefi image to boot from in your uefi settings (access it like > BIOS). > I tried that, but I'm not sure what to change. I tried to reinstall grub on EFI partition but I'm not sure how to do that, is regular grub-install stuff way to go (I thought I had some issues with that and I tried nixos-install after that). > Currently I have 2 uefi boot partitions cloned, but one failed so I've > been booting off the other one. > Nice one, I think I'll try to do something like that. Thanks Roger. > Thanks, > Roger > On 23/01/2017 10:48 PM, "Tomasz Czyż" > > masz.c...@gmail.com > wrote: > >> Hello, >> >> recently my grub said this to me after I restarted computer: >> >> Error: external pointer tables not supported >> Error: you need to load the kernel first. >> >> Every option I select with nix (also past generations) shows me this >> message. >> >> I updated the system to 17.03pre99792.c311871 on 2016-12-23 and restarted >> it before multiple times (and worked). I don't remember if I did other >> updates, but this is what's grub menu shows me. >> >> My disk layout is: EFI boot partition for grub, next partition is >> encrypted luks volume and ZFS on top of it. >> >> This setup worked for me for 1.5 year now without any issue. >> >> Anybody is aware of any changes to grub/zfs recently or had same issue? >> Any suggestions how I can recover from it or what can be wrong? >> >> Tom >> >> >> >> ___ >> 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] Grub problem: external pointer tables not supported
It looks like I hit some ZFS feature that it's not supported by grub module. How I found that? In grub, you can list files in zfs volumes by doing ``ls $drive/@/home`` etc. I could list ``ls $drive/@/nix`` or ``ls $drive/@/nix/var`` but not ``ls $drive/@/nix/store`` where I kept the kernels. I found some explanations about lot's of files and lot's of hardlinks (nix store had at that time more than 130G and probably triggered the feature). nix-collect-garbage -d didn't help. I solved the problem by using boot.loader.grub.copyKernels = true; Kernels were copied to the same volume but to /boot where there is smaller number of files and worked perfectly. 2017-01-23 16:44 GMT+00:00 Tomasz Czyż : > > > 2017-01-23 16:15 GMT+00:00 Roger Qiu : > >> Hey, >> >> Changing nixos generations won't affect the grub boot partition, that >> only changes which nixos kernel and initramfs image gets booted. >> > Because all boot options are not working one of my guesses is that in new > nix version, wrong config was generated when I did system update which > broke all options. > >> This looks like an error in the Grub partition. Maybe you recently >> updated it or changed it, or the partition got corrupted. >> > It's possible, I tried to boot from USB, do ``nixos-install > --no-root-passwd`` to reinstall the system, but I'm not sure how to force > grub/uefi partition recreation/reinstalling, any idea? Should I just format > it and will be recreated? > >> This is why other operating systems tend to make their /boot read-only... >> >> If you can't get into the OS, then you can try booting off a USB, and >> then edit the boot partition. Or run the uefi terminal app (but this one >> never worked for me). If you had cloned/raided boot partitions you can try >> changing the uefi image to boot from in your uefi settings (access it like >> BIOS). >> > I tried that, but I'm not sure what to change. I tried to reinstall grub > on EFI partition but I'm not sure how to do that, is regular grub-install > stuff way to go (I thought I had some issues with that and I tried > nixos-install after that). > >> Currently I have 2 uefi boot partitions cloned, but one failed so I've >> been booting off the other one. >> > Nice one, I think I'll try to do something like that. > > Thanks Roger. > >> Thanks, >> Roger >> On 23/01/2017 10:48 PM, "Tomasz Czyż" >> > > >> masz.c...@gmail.com > wrote: >> >>> Hello, >>> >>> recently my grub said this to me after I restarted computer: >>> >>> Error: external pointer tables not supported >>> Error: you need to load the kernel first. >>> >>> Every option I select with nix (also past generations) shows me this >>> message. >>> >>> I updated the system to 17.03pre99792.c311871 on 2016-12-23 and >>> restarted it before multiple times (and worked). I don't remember if I did >>> other updates, but this is what's grub menu shows me. >>> >>> My disk layout is: EFI boot partition for grub, next partition is >>> encrypted luks volume and ZFS on top of it. >>> >>> This setup worked for me for 1.5 year now without any issue. >>> >>> Anybody is aware of any changes to grub/zfs recently or had same issue? >>> Any suggestions how I can recover from it or what can be wrong? >>> >>> Tom >>> >>> >>> >>> ___ >>> nix-dev mailing list >>> nix-dev@lists.science.uu.nl >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>> >>> > > > -- > Tomasz Czyż > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Fwd: Grub problem: external pointer tables not supported
Roger, I got it from my grub.cfg config file. It looks like that's how you access "root" zfs volume. If I have / /volume1 /volume2 in grub I could access it $disk/@/ $disk/volume1/ $disk/volume2/ Looks like just a convention but didn't dive into it. btw, just to clarify my setup, currently I have /boot and /nix/store on the same zfs volume and works, looks like only one directory is affected by hardlinks/too many files issue. Thanks, Tom 2017-01-24 3:43 GMT+00:00 Roger Qiu : > Btw what is the `@` symbol mean in your `ls` examples? I've never seen > that. The grub rescue allows yo use `ls hd (0,1)/...` with no `@`. > On 24/01/2017 12:52 PM, "Tomasz Czyż" wrote: > >> It looks like I hit some ZFS feature that it's not supported by grub >> module. >> >> How I found that? >> In grub, you can list files in zfs volumes by doing ``ls $drive/@/home`` >> etc. >> I could list ``ls $drive/@/nix`` or ``ls $drive/@/nix/var`` but not ``ls >> $drive/@/nix/store`` where I kept the kernels. >> >> I found some explanations about lot's of files and lot's of hardlinks >> (nix store had at that time more than 130G and probably triggered the >> feature). >> >> nix-collect-garbage -d didn't help. >> >> I solved the problem by using boot.loader.grub.copyKernels = true; >> >> Kernels were copied to the same volume but to /boot where there is >> smaller number of files and worked perfectly. >> >> >> 2017-01-23 16:44 GMT+00:00 Tomasz Czyż : >> >>> >>> >>> 2017-01-23 16:15 GMT+00:00 Roger Qiu : >>> >>>> Hey, >>>> >>>> Changing nixos generations won't affect the grub boot partition, that >>>> only changes which nixos kernel and initramfs image gets booted. >>>> >>> Because all boot options are not working one of my guesses is that in >>> new nix version, wrong config was generated when I did system update which >>> broke all options. >>> >>>> This looks like an error in the Grub partition. Maybe you recently >>>> updated it or changed it, or the partition got corrupted. >>>> >>> It's possible, I tried to boot from USB, do ``nixos-install >>> --no-root-passwd`` to reinstall the system, but I'm not sure how to force >>> grub/uefi partition recreation/reinstalling, any idea? Should I just format >>> it and will be recreated? >>> >>>> This is why other operating systems tend to make their /boot >>>> read-only... >>>> >>>> If you can't get into the OS, then you can try booting off a USB, and >>>> then edit the boot partition. Or run the uefi terminal app (but this one >>>> never worked for me). If you had cloned/raided boot partitions you can try >>>> changing the uefi image to boot from in your uefi settings (access it like >>>> BIOS). >>>> >>> I tried that, but I'm not sure what to change. I tried to reinstall grub >>> on EFI partition but I'm not sure how to do that, is regular grub-install >>> stuff way to go (I thought I had some issues with that and I tried >>> nixos-install after that). >>> >>>> Currently I have 2 uefi boot partitions cloned, but one failed so I've >>>> been booting off the other one. >>>> >>> Nice one, I think I'll try to do something like that. >>> >>> Thanks Roger. >>> >>>> Thanks, >>>> Roger >>>> On 23/01/2017 10:48 PM, "Tomasz Czyż" >>>> >>> >>> >>>> masz.c...@gmail.com > wrote: >>>> >>>>> Hello, >>>>> >>>>> recently my grub said this to me after I restarted computer: >>>>> >>>>> Error: external pointer tables not supported >>>>> Error: you need to load the kernel first. >>>>> >>>>> Every option I select with nix (also past generations) shows me this >>>>> message. >>>>> >>>>> I updated the system to 17.03pre99792.c311871 on 2016-12-23 and >>>>> restarted it before multiple times (and worked). I don't remember if I did >>>>> other updates, but this is what's grub menu shows me. >>>>> >>>>> My disk layout is: EFI boot partition for grub, next partition is >>>>> encrypted luks volume and ZFS on top of it. >>>>> >>>>> This setup worked for me for 1.5 year now without any issue. >>>>> >>>>> Anybody is aware of any changes to grub/zfs recently or had same issue? >>>>> Any suggestions how I can recover from it or what can be wrong? >>>>> >>>>> Tom >>>>> >>>>> >>>>> >>>>> ___ >>>>> nix-dev mailing list >>>>> nix-dev@lists.science.uu.nl >>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>>>> >>>>> >>> >>> >>> -- >>> Tomasz Czyż >>> >> >> >> >> -- >> Tomasz Czyż >> >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> >> -- Tomasz Czyż -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] PCI Expresscard not working under NixOS
What about doing quick check and running ubuntu from livecd/usb to confirm if card still is alive? 2017-02-07 2:23 GMT+00:00 Roger Qiu : > It might be a missing driver. Ultimately is the kernel, its drivers and > modules that deal with hardware and IO. You might need to google around and > ask specifically for the given pci expess hardware serial code and model. > On 07/02/2017 9:39 AM, "Christoph-Simon Senjak" < > christoph.sen...@googlemail.com> wrote: > >> Hello. >> >> On 06.02.2017 06:36, Roger Qiu wrote: >> >>> When you plug something in, the kernel log should show something. If it >>> doesn't then the kernel doesn't know about it, nothing in the userspace >>> can help. >>> >> >> How can that be? >> >> Make sure you're running those commands before you plug the usb in. >>> >> > >> >>> Also I used to have faulty usb cables, but even then the kernel showed >>> something. Usually repeating messages because the usb cable kept >>> dropping out and coming back in. >>> >>> What happens if you plug those devices directly? >>> >> >> The kernel does not notice the expresscard itself when I plug it in. My >> usb hard disk works perfectly under the other ports. >> >> Ah, and fun fact: When plugging in the expresscard, I can reproducibly >> scramble my sound output for a second (the music repeats for a second after >> I plug it in). Still, the kernel says nothing. And no device nodes appear. >> >> >> On 06/02/2017 2:55 PM, "Christoph-Simon Senjak" >>> >> <mailto:christoph.sen...@googlemail.com>> wrote: >>> >>> Hi. >>> >>> On 06.02.2017 04:46, Peter Hoeg wrote: >>> >>> Hi, >>> >>> My USB 3.0 Expresscard does not work under NixOS, it used to >>> work >>> under other distros. I already tried to add >>> >>> >>> Can you be a little more specific about "does not work"? >>> >>> >>> Nothing happens. Like, really nothing. No new hub is shown in lsusb >>> (as it was under Ubuntu). Devices I plug in are not shown. Nothing. >>> >>> When you plug it in, what messages are you seeing while running >>> these 2 >>> commands in separate terminals: >>> >>> journalctl -k -f >>> >>> and >>> >>> udevadm monitor >>> >>> >>> Nothing. No output. >>> >>> Regards, CSS >>> ___ >>> nix-dev mailing list >>> nix-dev@lists.science.uu.nl <mailto:nix-dev@lists.science.uu.nl> >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>> <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] nix-bundle: Bundle Nix derivations to run anywhere
Matthew,
very good tool, thank you for sharing.
2017-02-07 10:32 GMT+00:00 Domen Kožar :
> Awesome! I will need this very soon, good timing :)
>
> On Tue, Feb 7, 2017 at 11:30 AM, Moritz Ulrich
> wrote:
>
>>
>> Hey Matthew,
>>
>> This sounds great! I'll give it a try :-)
>>
>> One question: Will it create a persistent /nix directory on the machine
>> the generated binary is running?
>>
>> Cheers
>> Moritz
>>
>> Matthew Bauer writes:
>>
>> > GitHub page: https://github.com/matthewbauer/nix-bundle
>> >
>> > I just wanted to post about a little project I've been working on. I'm
>> > calling it "nix-bundle".
>> >
>> > Basically, what it does is: take a Nix closure, compress it into a
>> > tarball, and turn that tarball into an executable using "Arx". The
>> > final result looks like a plain shell script, but actually has a
>> > tarball closure appended to it. When you run that script, Arx will
>> > execute "nix-user-chroot" (which is included in the closure) which
>> > will setup a /nix/ directory, then execute a target executable. All of
>> > this should work "out of the box" for any Nix derivation folder with a
>> > valid executable.
>> >
>> > For example, to generate a "hello" bundle:
>> >
>> > ./nix-bundle.sh hello /bin/hello
>> >
>> > "hello" specifies pkgs.hello and /bin/hello specifies the file
>> > ${pkgs.helloi}/bin/hello to be executed. The output file will just be
>> > called "hello".
>> >p
>> > The result is a "bundle" that can run without Nix being installed! No
>> > external dependencies are needed because they are all contained within
>> > the Nix closure.
>> >
>> > There are two main drawbacks: slow startup and large file size.
>> > Extracting the tarball takes time and this adds on to startup times.
>> > Also, because everything is included from the Nix closure, complicated
>> > apps tend to be much larger because of the dependency tree.
>> >
>> > I've been experimenting with using AppImage as a format to package
>> > them in, but it is not currently ready yet.
>> > _______
>> > nix-dev mailing list
>> > nix-dev@lists.science.uu.nl
>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>> --
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-bundle: Bundle Nix derivations to run anywhere
I would vote for mirroring this tool in nixos github namespace (or even
trying to make this project official one) as it can have big impact of
propagating/implementing nix ideas into environments where it's not
straight forward to use it.
What do you think people?
2017-02-07 11:31 GMT+00:00 Tomasz Czyż :
> Matthew,
> very good tool, thank you for sharing.
>
> 2017-02-07 10:32 GMT+00:00 Domen Kožar :
>
>> Awesome! I will need this very soon, good timing :)
>>
>> On Tue, Feb 7, 2017 at 11:30 AM, Moritz Ulrich
>> wrote:
>>
>>>
>>> Hey Matthew,
>>>
>>> This sounds great! I'll give it a try :-)
>>>
>>> One question: Will it create a persistent /nix directory on the machine
>>> the generated binary is running?
>>>
>>> Cheers
>>> Moritz
>>>
>>> Matthew Bauer writes:
>>>
>>> > GitHub page: https://github.com/matthewbauer/nix-bundle
>>> >
>>> > I just wanted to post about a little project I've been working on. I'm
>>> > calling it "nix-bundle".
>>> >
>>> > Basically, what it does is: take a Nix closure, compress it into a
>>> > tarball, and turn that tarball into an executable using "Arx". The
>>> > final result looks like a plain shell script, but actually has a
>>> > tarball closure appended to it. When you run that script, Arx will
>>> > execute "nix-user-chroot" (which is included in the closure) which
>>> > will setup a /nix/ directory, then execute a target executable. All of
>>> > this should work "out of the box" for any Nix derivation folder with a
>>> > valid executable.
>>> >
>>> > For example, to generate a "hello" bundle:
>>> >
>>> > ./nix-bundle.sh hello /bin/hello
>>> >
>>> > "hello" specifies pkgs.hello and /bin/hello specifies the file
>>> > ${pkgs.helloi}/bin/hello to be executed. The output file will just be
>>> > called "hello".
>>> >p
>>> > The result is a "bundle" that can run without Nix being installed! No
>>> > external dependencies are needed because they are all contained within
>>> > the Nix closure.
>>> >
>>> > There are two main drawbacks: slow startup and large file size.
>>> > Extracting the tarball takes time and this adds on to startup times.
>>> > Also, because everything is included from the Nix closure, complicated
>>> > apps tend to be much larger because of the dependency tree.
>>> >
>>> > I've been experimenting with using AppImage as a format to package
>>> > them in, but it is not currently ready yet.
>>> > ___
>>> > nix-dev mailing list
>>> > nix-dev@lists.science.uu.nl
>>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>> --
>>>
>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>>
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
>
> --
> Tomasz Czyż
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] help with patch for screen locking
David, I assume you are not talking about https://github.com/NixOS/nixpkgs/issues/16485? Usually I'm using this kind of stuff as part of user session/desktop environment. Which means that xfce-session or gnome-session or whatever is starting all those for user. Do we really need to start is outside of user session? Does it break any existing user sessions? 2017-02-07 18:36 GMT+00:00 zimbatm : > As a user I would expect slock to be installed and added to the suid list > if I selected it as my screensaver. That way I can also invoke it manually > in cases where I want to lock the screen manually. > > On Mon, 6 Feb 2017, 23:51 , wrote: > >> Hi! >> I am making a patch to fix issue #16485 but I have encountered an issue. >> >> I added an option called screenLock to >> services.xserver.desktopManager.xfce that can take only "xscreensaver" >> "xlockmore" "slock" "gnome-screensaver" as values but: >> >> - gnome-screensaver seems to not exist anymore, at least not on nixos, >> so I removed the choice >> - slock needs suid to lock the screen, as explained in the wiki too, so >> I don't know if with this patch I should install slock and also set it >> suid, or if it's better to leave the choice out, or if the user that >> puts screenLock = "slock" should be presented an error in case slock is >> not set suid by the user themselves. >> >> >> Thanks for your help >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Fwd: Why having releases if you break things in it often
I'm not sure if that's a troll or not, but let's try: So any help would be nice. I am a technicaly shurly keen guy, but I cant > reboot daily my machine for months, cause nobody of you experts can > invest 5-15 mins to fix that. > But you know, experts stuff is pretty expensive resource, and maybe people decided will be better if they use it differently than you would expect? > > > I dont want to be a 100% full time nixos developer / sysadmin just to > solve such stupid problem. Except somebody would pay me for that, then I > would think about it. > Ah, so you won't do it for free but you expect the army of experts to rush for help and do it for free for you, do I read that correctly? > > Is that really what I have to expect? > :-) > > Sorry for ranting here, I stopp now, but maybe some of that feedback > helps you to improve something, and maybe somebody could give me some > config lines or nix-env commands that gets flexget running again. > I can improve, but you know... if you would pay me, than I would think about it. Sorry, just kidding :-) And now serious, nix is an effort of huge number of people, they contribute in their free time mostly, and even those who do it for cash, mostly work for some companies and nixos contribution is just side effect of their work. It looks like a lot of people think that nixos is so useful for their work they contribute to it and even help others. You can join to that movement and spend a lot of time learning about this open source project or you can use the company to help you. Few people started nixos consulting (me as well :-) and this is a second option, you pay for product/service. It's like most of the open source software, right? > Graham Christensen writes: > > > I'm very sorry you've had a bad experience with breakage on stable. :( I > > use 16.09 myself. > > > >>> yes I think that html5lib thing would it be. So it was at least a > >>> security fix, so you dont just update stuff to update it, which would > >>> make releases pretty useless concept :) > > > > Roughly, this is why backports happen: > > > > - Security patches which aren't major updates > > - If a security patch is a major upgrade, try and find patches to our > >current version which accomplish the same goal. Apply the major > >update to master, and the patches to stable. > > - Bug fixes to applications which, again, aren't major updates. > >Generally be cautious about these. > > - Any updates when the current stable version is utterly broken. A key > >example of this is Spotify, who regularly breaks their old versions. > > - Extremely security-sensitive software, in particular Chrome, > >Chromium, Firefox, Thunderbird, and of course the kernel. > > > >>> Sorry I formulated that message a bit trollish, but just wanted to > learn > >>> why how releases are done in nixos. > > > > Please know that Freddy, Franz, Robin, Domen, myself, and the rest of > > the people contributing to NixOS work very hard to keep the stable > > version of NixOS working nicely. This is very important to us. > > > > It can be very stressful when preparing to backport changes, but it is > > important to do them anyway. I try to think through impact and run tests > > across a wide range of software to see what will break. We also try not > > to backport any substantial changes, but instead smaller patches to > > prevent breakage. > > > > When you do find breakage, please do promptly open an issue on send a > > report on the mailing list so we can address the problem and perhaps add > > testing to prevent it in the future. We're also quite accessible on the > > #nixos IRC channel on Freenode. > > > > If you would like to take part in the process of identifying and solving > > security problems on master and backporting to stable, we sure would > > love the extra help -- feel free to comment on > > https://github.com/NixOS/nixpkgs/issues/21967 and I'll tag you on > > Wednesday when I open the next roundup. > > > > Best, > > Graham Christensen > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- Tomasz Czyż -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Python 3 as default
I would also vote for not changing "default" python as it will break stuff. I was going to propose what Eelco already wrote here, just to have explicit sets like python27Packages, python35Packages without any "default". But I would leave symlink as it is for compatibility reasons. 2017-02-14 15:54 GMT+00:00 Kevin Cox : > > > On Feb 14, 2017 07:49, "Freddy Rietdijk" wrote: > > It would two mean things: > >1. alias `python3 to `python` >2. add a symlink that points to the `python` program, as discussed >before in this thread. > > For what it is worth I would prefer that we have a python executable in > the path (if it is "installed"), but the nix expressions only have the > version suffixed attributes to increase explicitness and improve > readability. > > Plus then we will be ready for python 4 😛 > > ___ > 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] Which option replaces security.setuidOwners?
Actually, very strange that such a huge change has no documentation changes at all. Good thing is, there were some tests :) 2017-02-14 22:07 GMT+00:00 Bjørn Forsman : > On 14 February 2017 at 23:04, Bjørn Forsman > wrote: > > On 14 February 2017 at 22:51, Domen Kožar wrote: > >> We need to use renames for backwards compatibility then :) > > > > A rename implies same signature under different namespace (AFAICS). > > This is not the case here, because the option types are different. > > > > I've got a local change that is about to be pushed: > > > > +(mkRemovedOptionModule [ "security" "setuidOwners" ] "Use > > security.wrappers instead") > > +(mkRemovedOptionModule [ "security" "setuidPrograms" ] "Use > > security.wrappers instead") > > > > (I also do some other fixups that was wrt. new security.wrapper to > > make my NixOS build.) > > I created PR: https://github.com/NixOS/nixpkgs/pull/22806 > > Best regards, > Bjørn Forsman > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] 0b27c7: pgjwt: init at 0.0.1 (#22644)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 0b27c74eb2517d307b1c1bbd04567157fba7cb63 https://github.com/NixOS/nixpkgs/commit/0b27c74eb2517d307b1c1bbd04567157fba7cb63 Author: Tomasz Czyż Date: 2017-02-26 (Sun, 26 Feb 2017) Changed paths: M nixos/release.nix A nixos/tests/pgjwt.nix A pkgs/servers/sql/postgresql/pgjwt/default.nix M pkgs/top-level/all-packages.nix Log Message: --- pgjwt: init at 0.0.1 (#22644) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Best Practices on Modularizing Configuration.nix?
Hey Mark,
I use almost the same setup and for 1.5y works very well.
I have "modules" and "hosts" directories. Each "host" contains
configuration about hardware/disk setup and includes set of modules from
"modules". On each host there is a symlink to correct
"hosts/.nix" file.
I found this setup pretty robust on dev machines.
On servers I use nixops which pushes configuration so I don't manage
/etc/nixos there.
Tom
2017-02-27 14:15 GMT+00:00 Mark Gardner :
> Now that I am putting NixOS on more and more machines, I would like to
> modularize and share parts of the config to maximize reuse and ensure
> uniformity. My approach is to consider the sub-config files as traits or
> roles and combine them together to create configuration.nix for a specific
> machine, like this:
>
> - cfg/common.nix # common config
> - cfg/desktop.nix # xorg and related
> - cfg/laptop.nix # related to all laptops
> - cfg/work.nix # work location related
> ...
> - cfg/mylaptop.nix # specific laptop related
>
> I import from these to make up configuration.nix. For example, on my
> laptop, configuration.nix contains:
>
> ---
> { config, pkgs, ... }:
>
> {
> imports =
> [
> ./hardware-configuration.nix
> ./cfg/mylaptop.nix
> ./cfg/common.nix
> ./cfg/desktop.nix
> ./cfg/laptop.nix
> ./cfg/work.nix
> ];
> }
> ---
>
> So far, this seems like a good approach. Except that each machine has its
> own configuration.nix that I would like to keep in the git repository too
> but of course I can't have different top level files with the same name. To
> solve this, I could moved the current configuration.nix inside of cfg (as
> cfg/mylaptop.cfg.nix perhaps) or merge with the existing cfg/mylaptop.nix
> then making configuration.nix a symlink to it. That way the only thing to
> do by hand is create the symlink to select a particular configuration. Is
> this reasonable? Is there a better way to do it?
>
> How do you modularize your configuration and put it into a repo such that
> you can easily create a configuration for a new machine (and put it in the
> repo too) without a lot of hand work?
>
> Mark
> --
> Mark Gardner
> --
>
> ___
> 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] Fwd: Python 3 as default
2017-02-27 15:20 GMT+00:00 Eelco Dolstra : > Hi, > > On 02/24/2017 07:54 AM, Freddy Rietdijk wrote: > > >> I'd be happy to help with the process of mass-renaming, if somebody > provided a > > list of packages wanting 2 or 3, however I suspect the real work is in > > determining those package sets. > > So, if a query-replace for `pkgs.python` -> `pkgs.python2` / > `pkgs.python3` > > within nixpkgs would cause so much trouble, how would a rename in > > `all-packages.nix` fare any better? Are we ready to throw the switch yet? > > > > All the packages that explicitly need Python 2 are already pinned to use > Python > > 2. That was a matter of converting, testing, and moving on. About 150 > packages > > were pinned to `python2`. That is why a `python = python3` won't break > anything > > (or nearly nothing) in Nixpkgs anymore. > > It may silently break external users, though. So removing the "python" > attribute > is preferable to aliasing it to "python3". > > BTW, I just noticed that the Python 3 package in 17.03 already defines a > "python > -> python3" symlink (introduced by [1]). IMHO, we should revert that, > since it > can only lead to pointless environment collision errors/warnings. Also, we > probably don't want to promote the use of the "python" executable name > because > it's unversioned (so when Python 4 breaks the language again, we'll have > to go > through this whole process again). > I agree totally. > > [1] https://github.com/NixOS/nixpkgs/commit/708822250e017f0256b0bace5af27a > 7232e6e1fd > > -- > Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ > ___ > 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] Copy a closure to machine with no Nix installed on it
I assume you could do nix-store --export or nix-store --dump to prepare archive or you can query nix store for all dependnecies and with that list you can copy them using method of your choice 2017-03-02 16:38 GMT+00:00 Volth : > Hello > > What is a good way to copy a closure to a Linux machine where Nix is > not installed (and it is tricky to install: 1. there is only root > account and 2. there may be no Internet access) ? > > "nix-copy-closure" expects "nix-store" on the target machine. > > Would "nix-store" be a single executable with no dependencies, it > could be uploaded beforehand, but it has a lot of dependencies so its > uploading is also the task of uploading a closure to a machine without > Nix... > ___ > 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] Copy a closure to machine with no Nix installed on it
Also, somebody mentioned https://github.com/matthewbauer/nix-bundle recently which is nice way to distribute some software to non nix environments. 2017-03-02 16:49 GMT+00:00 Bjørn Forsman : > On 2 March 2017 at 17:38, Volth wrote: > > Hello > > > > What is a good way to copy a closure to a Linux machine where Nix is > > not installed (and it is tricky to install: 1. there is only root > > account and 2. there may be no Internet access) ? > > > > "nix-copy-closure" expects "nix-store" on the target machine. > > > > Would "nix-store" be a single executable with no dependencies, it > > could be uploaded beforehand, but it has a lot of dependencies so its > > uploading is also the task of uploading a closure to a machine without > > Nix... > > Don't know how to do it without Nix, but Nix can be installed offline. > Get the binary tarball for you system: > > http://nixos.org/releases/nix/nix-1.11.7/nix-1.11.7-x86_64-linux.tar.bz2 > > Copy it to your target machine, unpack and run ./install from the > extracted tree. > > That creates a single user install. It requires sudo to create the > /nix directory, everything else is owned and run by your user. (There > are ways to run nix from $HOME or wherever, I think "proot" is a good > search word.) > > Once you have nix you have nix-copy-closure. > > Hope that helps. > > Best regards, > Bjørn Forsman > ___ > 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] RFC for RFCs
Thanks! Great stuff! 2017-03-08 21:21 GMT+00:00 zimbatm : > The RFC for RFCs is ready for a final round of review. Unless there are > major objections I would like to move forward with it, with the idea that > we can always improve the process with further RFCs. > > https://github.com/zimbatm/rfcs/pull/1 > > On Sun, 12 Feb 2017 at 20:17 Maarten Hoogendoorn > wrote: > >> Also see the notes that Arian took during the BoF session at FOSDEM: >> >> We had a very spontaneous NixOS discussion panel at FOSDEM. >> >> I took minutes. I must say they're a bit rushy at times, so add stuff to >> it >> you think isn't clear or is lacking in content. Thanks! >> >> >> http://piratepad.net/1nHg65LMQj >> >> >> 2017-02-12 19:46 GMT+01:00 Thomas Hunger : >> >> That would be amazing! I actually have an email sitting in my draft >> folder proposing Nix Enhancement Proposals (NEPs). >> >> IMHO one of the things we aren't very good at is getting larger changes >> merged or rejected. We attract a lot of smart people because Nix is pretty >> awesome. These smart people then do substantial work, submit a PR and the >> PR bitrots. This is highly demotivating. >> >> An RFC process would allow us to get to an accept / reject early on, with >> the expectation that accepted RFCs will be merged when the technical work >> is done. >> >> I'll add more specific comments to your PR. >> >> ~ >> >> On 12 February 2017 at 15:12, zimbatm wrote: >> >> Hi all, >> >> we discussed of introducing a RFC process during FOSDEM. The goal is to >> help discussion for large or controversial changes which typically grind to >> a halt. >> >> Here is an initial proposal based on the one from the Rust community: >> https://github.com/zimbatm/rfcs/pull/1 . Please let me know what you >> think. >> >> Cheers, >> z >> >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> >> >> >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> >> >> > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Vulnerability Roundup #missing
Graham, thank you, you are doing great job. There is few I'm aware of: - https://oval.cisecurity.org/ (previously I think it was open vulnerability ID) - https://github.com/distributedweaknessfiling - https://github.com/distributedweaknessfiling/DWF-Database 2017-03-09 11:39 GMT+00:00 Jörg Thalheim : > On 2017-03-08 14:36, Graham Christensen wrote: > > Just a heads up that the LWN Vulnerability Database we use hasn't been > > updated in over a week, which means our tooling thinks there have been > > zero problems. This is obviously not true. > > > > LWN's database provides a hugely valuable resource for us. They collect > > mail from many distro's mailing lists and aggregate similar reports in > > to a single entry. Each of those then will have multiple solutions and > > patches that we can use to fix the issue in our distribution. This > > aggregation has been a huge "force multiplier," allowing us to keep up > > to date and patch almost as fast as the bigger distributions, even in > > the earliest weeks of roundups where only a few people were regularly > > contributing. > > > > If you appreciate the work we've done, I recommend subscribing to LWN as > > a thank-you. > > > > > > Remediation: > > > > - I've messaged LWN to ask if the database will be updated again. > > - I've been researching alternative ways to get the job done: > >- Other DBs with similar goals of aggregating issues and reports. > >- Reviewing all the mail from oss-security > >- Subscribing to and reviewing all the mail from all the distro's > > that LWN watched > > - other options? > > > > This is a tough spot to be in, and I am hoping LWN will continue. Either > > way, we should likely expand our tooling to support other sources as > > well. > > > > If anyone has any ideas or suggestions, I'm all ears :) > > > > Best, > > Graham Christensen > > Do you know how LWN aggregates the reports? Is it more of a manual process > or is done automatically? > > > ___ > > 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
[Nix-dev] nixos-container networking
Hey, could anyone using nixos-container (declarative style) share how you setup networking? I'm trying to setup few containers with private network and http proxy at the front. Each container potentially could run application on port 80 and I would like to expose them through proxy. I tried to set this up with privateNetwork=true; hostAddress localAddress and I tried to also run nat on the host with (just to enable outbound traffic) internalInterfaces = ["ve-+"]; externalInterfaces = "eth0"; but no luck. My next try will be creating bridge on the host and add containers to that bridge. Is that how you do stuff or are better ways of doing container networking? Tom ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nixos-container networking
Michael, Ian, thank you for your answers.
Looks like my problem was with the container name. I tried bunch of
different setups which didn't work and I discovered that when I'm using "-"
in container name it doesn't work (I had impression that worked one or two
times when I started machine from scratch, but most of the time didn't).
After I removed "-" from the name, looks like private network is working (I
can access private IP of container) so I don't need NAT actually.
Tom
2017-03-13 23:54 GMT+00:00 Ian-Woo Kim :
> I've recently made nixos-container port forwarding easier (both
> imperative and declarative) and it's now merged into master.
>
> https://github.com/NixOS/nixpkgs/pull/20869
>
> Hope that this helps.
>
> Ian
>
> On Sun, Mar 12, 2017 at 7:52 PM, Michael Walker
> wrote:
> > Tomasz,
> >
> > I have declarative container networking set up and working on a VPS,
> > but I wrote most of the configuration as I was learning things, so it
> > may not be the best way.
> >
> > Here's the configuration.nix for the VPS:
> > https://github.com/barrucadu/nixfiles/blob/master/hosts/innsmouth.nix
> > Each container has a config file here:
> > https://github.com/barrucadu/nixfiles/tree/master/containers
> >
> > Containers have ports forwarded to them via NAT; each container is
> > running a web server on port 80 with the host reverse-proxying via
> > nginx; the host also does https and letsencrypt for all the proxied
> > containers.
> >
> > At the top of the innsmouth.nix file, I have a "containerSpecs" record
> > which has all the details for each container. The relevant bits of the
> > config are:
> >
> > 1. Set up the networking and NAT:
> >
> > networking.nat.enable = true;
> > networking.nat.internalInterfaces = ["ve-+"];
> > networking.nat.externalInterface = "enp0s4";
> >
> > 2. Forward ports to containers:
> >
> > networking.nat.forwardPorts = concatMap
> > ( {num, ports, ...}:
> > map (p: { sourcePort = p; destination =
> > "192.168.255.${toString num}:${toString p}"; }) ports
> > ) containerSpecs';
> >
> > 3. Define all the containers:
> >
> > containers = mapAttrs
> > (_: {num, config, ...}:
> > { autoStart = true
> > ; privateNetwork = true
> > ; hostAddress = "192.168.254.${toString num}"
> > ; localAddress = "192.168.255.${toString num}"
> > ; config = config
> > ; }
> > ) containerSpecs;
> >
> > 4. Reverse-proxy HTTPS to HTTP in each container, manage letsencrypt
> > certificates, and forward HTTP to HTTPS.
> >
> > This is a little complex as I have a fairly custom nginx config (see
> > the services/nginx.nix file in the repository), but the
> > reverse-proxying is fairly straightfoward. Here is the generated
> > nginx.conf: https://misc.barrucadu.co.uk/nginx.txt
> >
> > On 13 March 2017 at 02:12, Tomasz Czyż wrote:
> >> Hey,
> >>
> >> could anyone using nixos-container (declarative style) share how you
> setup
> >> networking?
> >>
> >> I'm trying to setup few containers with private network and http proxy
> at
> >> the front. Each container potentially could run application on port 80
> and I
> >> would like to expose them through proxy.
> >>
> >> I tried to set this up with
> >>
> >> privateNetwork=true;
> >> hostAddress
> >> localAddress
> >>
> >> and I tried to also run nat on the host with (just to enable outbound
> >> traffic)
> >> internalInterfaces = ["ve-+"];
> >> externalInterfaces = "eth0";
> >>
> >> but no luck.
> >> My next try will be creating bridge on the host and add containers to
> that
> >> bridge. Is that how you do stuff or are better ways of doing container
> >> networking?
> >>
> >> Tom
> >>
> >> ___
> >> nix-dev mailing list
> >> nix-dev@lists.science.uu.nl
> >> http://lists.science.uu.nl/mailman/listinfo/nix-dev
> >>
> >
> >
> >
> > --
> > Michael Walker (http://www.barrucadu.co.uk)
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Fwd: nixos-container networking
-- Forwarded message --
From: Tomasz Czyż
Date: 2017-03-14 18:12 GMT+00:00
Subject: Re: [Nix-dev] nixos-container networking
To: Danylo Hlynskyi
Hey Danylo,
yup, I hit 13 char limit and because I was removing - I thought it's that.
I also had the issue with recreating containers, but this happened only
sometimes and didn't happen when I restart the machine so I was not sure
why is that. Thanks for your mail, it's very useful.
Would you share your bridget networking?
I was trying that but I'm wondering if you have one shared bridge or you
have bridge per container and how you access containers from host (or route
traffic to them).
Cheers,
Tom
2017-03-14 6:01 GMT+00:00 Danylo Hlynskyi :
> Strange, I have lot's of containers with "-" and experience no problems.
> But maybe you've exceeded by accident limit 13 symbols per container name?
>
> Also, last time I tried "veth" networking, I was struggling from
> https://github.com/NixOS/nixpkgs/issues/16330. My container experience
> was awful when I tried container renames. That's why I've already switched
> to bridged networking
>
> ---
>
> BTW, I highly recommend patch to switch-to-configuration.pl
> <https://github.com/NixOS/nixpkgs/pull/3021/commits/6e36619b277f78ece1bb81b79b5651897e46a2bf#diff-0a057d6ff3f6f83f68b859178484f4fe>
> from https://github.com/NixOS/nixpkgs/pull/3021/commits/6e36619b2
> 77f78ece1bb81b79b5651897e46a2bf
>
> It isn't clear from commit message, but it does the following: makes
> declarative containers truly reloadable (when you change
> container config, it activates new configuration for container). The
> culprit is *it should be* default behavior, because of
>
> 1. https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/
> virtualisation/containers.nix#L225-L230
> 2. https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/
> virtualisation/containers.nix#L676
>
> I'd like to PR this, but got no time to test properly other parts of Nixos.
>
> 2017-03-14 4:42 GMT+02:00 Tomasz Czyż :
>
>> Michael, Ian, thank you for your answers.
>>
>> Looks like my problem was with the container name. I tried bunch of
>> different setups which didn't work and I discovered that when I'm using "-"
>> in container name it doesn't work (I had impression that worked one or two
>> times when I started machine from scratch, but most of the time didn't).
>>
>> After I removed "-" from the name, looks like private network is working
>> (I can access private IP of container) so I don't need NAT actually.
>>
>> Tom
>>
>> 2017-03-13 23:54 GMT+00:00 Ian-Woo Kim :
>>
>>> I've recently made nixos-container port forwarding easier (both
>>> imperative and declarative) and it's now merged into master.
>>>
>>> https://github.com/NixOS/nixpkgs/pull/20869
>>>
>>> Hope that this helps.
>>>
>>> Ian
>>>
>>> On Sun, Mar 12, 2017 at 7:52 PM, Michael Walker
>>> wrote:
>>> > Tomasz,
>>> >
>>> > I have declarative container networking set up and working on a VPS,
>>> > but I wrote most of the configuration as I was learning things, so it
>>> > may not be the best way.
>>> >
>>> > Here's the configuration.nix for the VPS:
>>> > https://github.com/barrucadu/nixfiles/blob/master/hosts/innsmouth.nix
>>> > Each container has a config file here:
>>> > https://github.com/barrucadu/nixfiles/tree/master/containers
>>> >
>>> > Containers have ports forwarded to them via NAT; each container is
>>> > running a web server on port 80 with the host reverse-proxying via
>>> > nginx; the host also does https and letsencrypt for all the proxied
>>> > containers.
>>> >
>>> > At the top of the innsmouth.nix file, I have a "containerSpecs" record
>>> > which has all the details for each container. The relevant bits of the
>>> > config are:
>>> >
>>> > 1. Set up the networking and NAT:
>>> >
>>> > networking.nat.enable = true;
>>> > networking.nat.internalInterfaces = ["ve-+"];
>>> > networking.nat.externalInterface = "enp0s4";
>>> >
>>> > 2. Forward ports to containers:
>>> >
>>> > networking.nat.forwardPorts = concatMap
>>> > ( {num, ports, ...}:
>>> > map (p: { sourcePort = p; destination =
>>> > "192.168.255.${toString num}:${toStr
Re: [Nix-dev] Fwd: nixos-container networking
Arnold, Danylo, thank you for info, links and examples!
2017-03-15 9:17 GMT+00:00 Danylo Hlynskyi :
> Host side:
>
> networking.bridges.${bridgeName}.interfaces = [];
> networking.interfaces.${bridgeName}.ip4 = [ { address =
> "${subnet}.1"; prefixLength = 24; } ];
>
> # Each container takes at least 4 inotify file handles, so you quickly
> reach limit 128 when spawning many containers
> boot.kernel.sysctl."fs.inotify.max_user_instances" = 2048;
>
> # internet in containers!
> networking.nat.enable = true;
> networking.nat.internalInterfaces = [ "ve-+" "vb-+" bridgeName ]; #
> TODO check if bridgeName is required
> networking.nat.externalInterface = "eth0";
>
> Container side:
>
> privateNetwork = true;
> hostBridge = bridgeName;
> localAddress = container_ip + "/24";
> config = {
> networking.defaultGateway = "${subnet}.1";
> networking.extraHosts = ''
> ${subnet}.1 ${hostConfig.networking.hostName}
> '';
> };
>
> There is also some code to set-up hostname resolving via /etc/hosts,
> because I know little about DHCP
> , mDNS, nss-* and so on (https://github.com/NixOS/nixpkgs/issues/16754).
> It is a wrapper around `containers`
> and monitors IP clashes (which are set manually in my setup)
>
>
> In general, I have 1 bridge with multiple IPs/subnets, so containers in
> one subnet don't see containers in other.
>
> 2017-03-14 20:12 GMT+02:00 Tomasz Czyż :
>
>>
>> -- Forwarded message --
>> From: Tomasz Czyż
>> Date: 2017-03-14 18:12 GMT+00:00
>> Subject: Re: [Nix-dev] nixos-container networking
>> To: Danylo Hlynskyi
>>
>>
>> Hey Danylo,
>>
>> yup, I hit 13 char limit and because I was removing - I thought it's that.
>>
>> I also had the issue with recreating containers, but this happened only
>> sometimes and didn't happen when I restart the machine so I was not sure
>> why is that. Thanks for your mail, it's very useful.
>>
>> Would you share your bridget networking?
>> I was trying that but I'm wondering if you have one shared bridge or you
>> have bridge per container and how you access containers from host (or route
>> traffic to them).
>>
>> Cheers,
>> Tom
>>
>>
>> 2017-03-14 6:01 GMT+00:00 Danylo Hlynskyi :
>>
>>> Strange, I have lot's of containers with "-" and experience no problems.
>>> But maybe you've exceeded by accident limit 13 symbols per container name?
>>>
>>> Also, last time I tried "veth" networking, I was struggling from
>>> https://github.com/NixOS/nixpkgs/issues/16330. My container experience
>>> was awful when I tried container renames. That's why I've already switched
>>> to bridged networking
>>>
>>> ---
>>>
>>> BTW, I highly recommend patch to switch-to-configuration.pl
>>> <https://github.com/NixOS/nixpkgs/pull/3021/commits/6e36619b277f78ece1bb81b79b5651897e46a2bf#diff-0a057d6ff3f6f83f68b859178484f4fe>
>>> from https://github.com/NixOS/nixpkgs/pull/3021/commits/6e36619b2
>>> 77f78ece1bb81b79b5651897e46a2bf
>>>
>>> It isn't clear from commit message, but it does the following: makes
>>> declarative containers truly reloadable (when you change
>>> container config, it activates new configuration for container). The
>>> culprit is *it should be* default behavior, because of
>>>
>>> 1. https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/v
>>> irtualisation/containers.nix#L225-L230
>>> 2. https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/v
>>> irtualisation/containers.nix#L676
>>>
>>> I'd like to PR this, but got no time to test properly other parts of
>>> Nixos.
>>>
>>> 2017-03-14 4:42 GMT+02:00 Tomasz Czyż :
>>>
>>>> Michael, Ian, thank you for your answers.
>>>>
>>>> Looks like my problem was with the container name. I tried bunch of
>>>> different setups which didn't work and I discovered that when I'm using "-"
>>>> in container name it doesn't work (I had impression that worked one or two
>>>> times when I started machine from scratch, but most of the time didn't).
>>>>
>>>> After I removed "-" from the name, looks like private network is
>>>> working (I can access private IP of container) so I don&#x
[Nix-dev] NixOs containers and secrets
Hey nixos-containers users, according to https://github.com/NixOS/nixops/issues/631 how to you deploy secrets to containers? Tom ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Provide options for storing secrets outside the Nix store
Great job Bas. We already started going into that direction with some new pull requests. nlewo implemented that for new openstack modules for example. I think your proposal is very good. Should that go to our new shiny RFC? 2017-03-24 22:52 GMT+00:00 Bas van Dijk : > Dear module authors, maintainers and contributors, > > I would like to bring your attention to: > > https://github.com/NixOS/nixpkgs/issues/24288 > > The idea is to add a `passwordFile` option for every `password` option so > that users have a choice other than storing secrets inside the > world-readable Nix store. > > What do you think about the proposal? > > If you agree and want to contribute, please mention in the issue which > module you want to take on. That way we can coordinate the effort. > > Happy hacking, > > Bas > > ___ > 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 on VServer (update)
You are missing few required parts in your configuration. If you are deploying to the VM installed from CD or somethign like that you should get that in /etc/nixos/hardware-configuration.nix (or you can generate that with some command). There are settings about filesystems and boot options. Copy that to your config (or just put in "import" section). 2017-03-28 0:21 GMT+01:00 : > Here are more details to my previous message: > > I'm getting the following error, when deploying this > (http://lpaste.net/353990) config to a remote nix machine: > > nixops deploy -d network > building all machine configurations... > error: > Failed assertions: > - The ‘fileSystems’ option does not specify your root file system. > - You must set the option ‘boot.loader.grub.devices’ or > 'boot.loader.grub.mirroredBoots' to make the system bootable. > (use ‘--show-trace’ to show detailed location information) > error: unable to build all machine configurations > > Does anybody have an idea how to fix this? > > ___ > 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 on VServer (update)
Usually you have the layout like
disk
disk/partition1
disk/partition2
so you install grub on disk (/dev/sda, /dev/xvda) or something like that
(generally block device with partition table I think).
New grub also requires boot partition I think (but not 100% sure).
There are other methods how you can install grub or other boot loader, for
example gummibot. Now I think it's more general issue, not nixos specific
so maybe you can get infro from other sources.
I, in my setups, use that layout, block device + boot partition + other
partition
2017-03-28 0:55 GMT+01:00 :
> nice, this got me a step further. Now I face this however:
>
> network> closures copied successfully
> webserver> updating GRUB 2 menu...
> webserver> installing the GRUB 2 boot loader on /dev/disk/by-uuid/49dd2ea0-
> e795-4b57-b45a-0649794a804d...
> webserver> Installing for i386-pc platform.
> webserver> /nix/store/wvmch6hwsz5ls592c1qcjk0qcb8w8a
> jh-grub-2.x-2015-11-16/sbin/grub-install: warning: File system `ext2'
> doesn't support embedding.
> webserver> /nix/store/wvmch6hwsz5ls592c1qcjk0qcb8w8a
> jh-grub-2.x-2015-11-16/sbin/grub-install: warning: Embedding is not
> possible. GRUB can only be installed in this setup by using blocklists.
> However, blocklists are UNRELIABLE and their use is discouraged..
> webserver> /nix/store/wvmch6hwsz5ls592c1qcjk0qcb8w8a
> jh-grub-2.x-2015-11-16/sbin/grub-install: error: will not proceed with
> blocklists.
> webserver> /nix/store/ivy5afbs8xrqm71xdqsll7z4kv37llh2-install-grub.pl:
> installation of GRUB on /dev/disk/by-uuid/49dd2ea0-e795-4b57-b45a-0649794a804d
> failed
> webserver> error: unable to activate new configuration
> error: activation of 1 of 1 machines failed (namely on ‘webserver’)
>
>
> I just added the following copied from the remote hardware config to the
> deploy cfg:
>
>
> fileSystems."/" =
> { fsType = "ext4";
> device = "/dev/disk/by-uuid/49dd2ea0-e795-4b57-b45a-0649794a804d";
> };
>
> boot.loader.grub.devices = ["/dev/disk/by-uuid/49dd2ea0-
> e795-4b57-b45a-0649794a804d"];
>
> There's only one partition remote, is this maybe wrong? I mean should I
> either provide a separate boot partition or have the one of another type?
>
> thanks a lot for the hints!
>
>
>
>
>
> On 28.03.2017 01:34, Tomasz Czyż wrote:
>
> You are missing few required parts in your configuration.
>
> If you are deploying to the VM installed from CD or somethign like that
> you should get that in /etc/nixos/hardware-configuration.nix (or you can
> generate that with some command). There are settings about filesystems and
> boot options. Copy that to your config (or just put in "import" section).
>
> 2017-03-28 0:21 GMT+01:00 :
>
>> Here are more details to my previous message:
>>
>> I'm getting the following error, when deploying this
>> (http://lpaste.net/353990) config to a remote nix machine:
>>
>> nixops deploy -d network
>> building all machine configurations...
>> error:
>> Failed assertions:
>> - The ‘fileSystems’ option does not specify your root file system.
>> - You must set the option ‘boot.loader.grub.devices’ or
>> 'boot.loader.grub.mirroredBoots' to make the system bootable.
>> (use ‘--show-trace’ to show detailed location information)
>> error: unable to build all machine configurations
>>
>> Does anybody have an idea how to fix this?
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
>
> --
> Tomasz Czyż
>
>
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [RFC 004] Add Replace Unicode Quotes draft
2017-03-29 12:33 GMT+01:00 Profpatsch : > On 17-03-28 10:03pm, zimbatm wrote: > > Hi everyone, > > > > RFC 004 is now ready for wider reviews if you care to take a look: > > > > https://github.com/NixOS/rfcs/pull/4 > > For posterity, the responses are exactly > the kind of bikeshedding I feared would come out of RFCs. > > But maybe it is for the best? > I don’t know. > I think it's valuable, right now some of the decisions are hidden and some of them must be rediscovered. With RFC, when someone asks about certain thing, you can says, "hey, you have RFC, read it, that's why" - you have track of all discussion in one place rather. Alternative is to have discussions distributed over github issues, mailing list and irc channel, IMHO RFC is very good decision log. > > -- > Proudly written in Mutt with Vim on NixOS. > Q: Why is this email five sentences or less? > A: http://five.sentenc.es > May take up to five days to read your message. If it’s urgent, call me. > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS 17.03 'Gorilla' Released
Robin, thank you for your work on this release! 2017-03-31 15:29 GMT+01:00 Robin Gloster : > Dear community, > > I'm proud to announce the 7th NixOS stable release 17.03 named > "Gorilla". > > With over 12479 (last release: 13283) commits from 625 (last release > 554) contributors the release brings a few highlights: > > * Nixpkgs is now extensible through overlays. See the Nixpkgs manual for > more information. > > * This release is based on Glibc 2.25, GCC 5.4.0 and systemd 232. The > default Linux kernel is 4.9 and Nix is at 1.11.8. > > * The default desktop environment now is KDE's Plasma 5. KDE 4 has been > removed > > * The setuid wrapper functionality now supports setting capabilities. > > * X.org server uses branch 1.19. Due to ABI incompatibilities, > ati_unfree keeps forcing 1.17 and amdgpu-pro starts forcing 1.18. > > * Cross compilation has been rewritten. See the nixpkgs manual for > details. The most obvious breaking change is that in derivations there > is no .nativeDrv nor .crossDrv and are now cross by default, not > native. > > * The overridePackages function has been rewritten to be replaced by > overlays > > * Packages in nixpkgs can be marked as insecure through listed > vulnerabilities. See the Nixpkgs manual for more information. > > There are two open issues currently: > * gdm crashes on some hardware, using slim to start gnome works, see > the github issue for more information: >https://github.com/NixOS/nixpkgs/issues/24172 > * Firefox e10s tabs crash, see the github issue for more information: >https://github.com/NixOS/nixpkgs/issues/24295 > > See release notes for more information about major changes and updates > at http://nixos.org/nixos/manual/release-notes.html#sec-release-17.03 > > ISO and VirtualBox images can be downloaded from: > http://nixos.org/nixos/download.html > (Azure BLOBs and EC2 AMIs will follow) > > The NixOS manual is at http://nixos.org/nixos/manual/ > > A fresh installation can be done by following "Installation chapter" in > the manual: > > http://nixos.org/nixos/manual/index.html#sec-installation > > Upgrading existing NixOS installations: > > $ nix-channel --add https://nixos.org/channels/nixos-17.03 nixos > $ nixos-rebuild switch --upgrade > > Please report issues to our bug tracker: > https://github.com/NixOS/nixpkgs/issues > > The most active contributors for this release were: > 621 commits: Frederik Rietdijk > 498 commits: Franz Pletz > 379 commits: Vladimír Čunát > 377 commits: Thomas Tuegel > 324 commits: Joachim Fasting > > And of course the regular thank you to Eelco Dolstra for his tireless > work on NixOS, Nix and all the projects around that. I'd like to thank > Domen Kožar for his help on getting this release out smoothly and his > regular work on NixOS, the security team for taking a lot of workload > off the release manager by always making sure to keep our systems and > packages secure and also Mayflower for allowing me to work on NixOS a > lot in working hours. > > Also I'd like to start a discussion if we want to start rotating the > release manager for every release or maybe have two release managers > each rotating after two releases, so you always have one who has > managed one release. Any opinions? I'm not opposed to doing it again > but it needs quite some time I could also spend on other work. > > PS: Note that according to our new policy, 16.09 is still supported one > month by our security team until the end of April. > > Cheers, > Robin > ___ > 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] Nix init system
I was almost convinced by that message but I think there was not enough f word (but almost!). I think it would be a + when you attach your scream as mp3 or something (just more interactive!) Actually, I'm little disapointed that only few kind of curses were there, I think you didn't put too much effort into that email. Not enough non-substantive arguments as well; hate is directed to dead things, make it personal! You can blame me if this will help you :-) Use all the power, memes and tweets! Use curses to encourage volontiers to do the work! That's how you do it. PS. Please send me details to your Personal Communication coach, looks like I need that as well. (please) - at the end is really sweet :-) btw, https://youtu.be/CT6Mn8UZqnY?t=3m50s - tomorrow Ulrich has presentation about immutable infrastructures on NixOS Dublin if anyone interested :-) 2017-04-03 16:24 GMT+01:00 Graham Christensen : > NixOS is 14 years old and has used systemd for about five years. > > On Mon, Apr 3, 2017 at 11:22 AM Luescher Claude wrote: > >> On 2017-04-03 16:20, Profpatsch wrote: >> > On 17-04-03 11:14am, Luescher Claude wrote: >> >> Hello, >> > >> > Guess what? >> > >> > NOBODY CARES. >> > >> > Keep your hate. >> > Go back to the hole you came from. >> >> No I won't keep my hate because if everybody does nothing will happen >> towards eliminating the cancer from the linux community what malware(d) >> is. >> >> I hope you all realize that this whole system(d) pottering scheme is >> putting the worse NSA funded malware backdoor into linux. >> >> System(d) taking away the control from users, sysadmins and hackers and >> giving it all to Redhat & associates. >> >> Your project is still just couple of months old so removing systemd >> should happen now at early stages! >> ___ >> 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] Chromium extensions
Works for me. What version of nix/nixos do you use? 2017-04-04 8:42 GMT+01:00 Judson Lester : > I've found that every time I update Chromium, all my extensions get ... > lost? Their icons become puzzle pieces, and their behavior is erratic. Is > there a fix for this, or an easy way to reinstall them all? > > Judson > > ___ > 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] [Help] Accidentally removed configuration.nix
As it's read by nix, I assume it would be somewhere in nix store, but I did quick look and didn't find (but might be there, nexted somewhere) 2017-04-06 15:12 GMT+01:00 : > Hi all, > > I acidentally removed my /etc/nixos/configuration.nix is there any way I > can get it back? > > Sincerely, > Vince > > ___ > 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] github triggered builds
https://nixos.org/hydra/
and
https://github.com/hercules-ci/hercules ( looks like still in heavy
development but maybe usable :))
2017-05-08 18:14 GMT+01:00 Harmen :
> Hi,
>
> I'm trying to see how I can make my build processes easier with nix. So far
> it's going pretty good and it's fun, although there was a lot of searching
> online for scattered documents.
>
> Want I want to do (as the first thing to change to nix in production) is to
> port the building of some docker images I use for testing. The idea is to
> have docker images build, tagged with their branch they come from, when
> someone
> pushes something. The building and pushing an sich work. The .nix files
> live in
> the repo, and with a `make docker` the image is build and uploaded. I'm
> very
> happy to be able to build docker images without actually having to use
> docker
> ;)
>
> So, what would be the recommended way to trigger the building process? I'm
> currently using drone.io, but that works with containers. It works with
> nix,
> when I give it the nixos/nix docker image, but building a node project
> takes
> about 5 minutes, and drags in way too much from cache.nixos.org. I tried
> to
> have it make a local nix binary-cache, but there are some problems there,
> but
> drone also just doesn't fit the problem nicely. Nix solves the problem of
> versioning so much nicer than containers that I would prefer to use
> something
> simpler. Hydra could work, but I'm a bit intimidated by that, and would
> like to
> have something simpler for now.
>
> The LT;DR: question: is there a simple nix based build system which can be
> triggered via git{hub,lab} hooks?
>
>
> Thanks!
> Harmen
> (If there is a better place to ask this, let me know)
> _______
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS and nix 1.12
Actually, wouldn't be great if we transfer that functions over a time rather than doing big bang? I was thinking recently that probably simple bash wrapper aggregating various commands under common executable would be good start. In that case we can then replace functions one by one with new implementation or reogranize it. What do you think? 2017-05-09 10:39 GMT+01:00 Sergey Mironov : > Where can I read more about new features of nix-1.12 ? > > Regards, > Sergey > > 2017-04-25 11:26 GMT+03:00 zimbatm : > > At some point but there is no timeline yet. We don't even have a list of > > regressions to fix before release yet. > > > > > > On Thu, 13 Apr 2017, 15:12 Volth, wrote: > >> > >> Hi > >> > >> Is nix-1.12 going to replace traditional nix command line utilities on > >> NixOS ? > >> If yes, when it is going to happen, approximately? > >> With NixOS-17.09, 18.03 or later? > >> ___ > >> nix-dev mailing list > >> nix-dev@lists.science.uu.nl > >> https://mailman.science.uu.nl/mailman/listinfo/nix-dev > > > > > > ___ > > nix-dev mailing list > > nix-dev@lists.science.uu.nl > > https://mailman.science.uu.nl/mailman/listinfo/nix-dev > > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > https://mailman.science.uu.nl/mailman/listinfo/nix-dev > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] why has each revision / generation not a own configuration.nix
https://nixos.org/nixos/options.html#configuration+copy 2017-05-12 22:57 GMT+01:00 Stefan Huchler : > Hi, > > I find it always strange, that when I revert back or boot a older > version of nixos, the configuration file has no version that reflected > that version. So I have to seperatly have to backup the > configuration.nix file. > > Could there not be at least a backup of the config used in that > generation somewhere (or is there somewhere one) when you build a > generation? > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > https://mailman.science.uu.nl/mailman/listinfo/nix-dev > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to build all of nixpkgs?
check release.nix (release-*.nix)
2017-05-21 16:49 GMT+01:00 Bjørn Forsman :
> Hi all Nix users,
>
> I'd like to build all of nixpkgs. Or as much as possible.
>
> What I've tried:
>
> 8<
> $ nix-build --keep-going
> error: Package ‘Agda-Sheaves-8a06162a8f0f7df308458db91d720cf8f7345d69’
> in ‘/home/bfo/proj/code/forks/nixpkgs/pkgs/development/
> libraries/agda/Agda-Sheaves/default.nix:18’
> is marked as broken, refusing to evaluate.
>
> a) For `nixos-rebuild` you can set
> { nixpkgs.config.allowBroken = true; }
> in configuration.nix to override this.
>
> b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you
> can add
> { allowBroken = true; }
> to ~/.config/nixpkgs/config.nix.
>
> $ NIXPKGS_ALLOW_BROKEN=1 nix-build --keep-going
> error: assertion failed at
> /home/bfo/proj/code/forks/nixpkgs/pkgs/top-level/all-packages.nix:6164:19
> >8
>
> So no success.
>
> Any suggestions?
>
> Best regards,
> Bjørn Forsman
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to build all of nixpkgs?
Look there, that's how all packages are build by CI:
http://hydra.nixos.org/jobset/nixpkgs/trunk#tabs-configuration
It uses pkgs/top-level/release.nix to build all of that.
Also it passes nixpkgs. So maybe you need to do something like
nix-build -I nixpkgs=path-to-your-nixpkgs pkgs/top-level/release.nix (and
eventually pass other options like officialRelease etc)
2017-05-22 16:18 GMT+01:00 Bjørn Forsman :
> On 21 May 2017 at 19:26, Tomasz Czyż wrote:
> > check release.nix (release-*.nix)
>
> I've tried to look at some of those. For instance,
> ./pkgs/top-level/release{,-small}.nix, and
> ./nixos/release-{small,combined}.nix. But I don't seem to get them
> working like I want with 'nix-build'.
>
> Examples:
>
> 1. "nix-build ./pkgs/top-level/release-small.nix" doesn't build any of
> the packages, it only builds channel, manual, isos and a bunch of VM
> tests. It seems to be because the attributes of the 'nixpkgs'
> attribute in that top-level expression does not contain direct
> derivations as sub-attributes but rather the derivations are one level
> further down, in an 'arch' attribute. Like mypkg.x86_64-linux instead
> of just mypkg. I tried adding 'recurseIntoAttrs', but it didn't help.
>
> 2. "nix-build ./pkgs/top-level/release.nix" gives "error: value is a
> set while a Boolean was expected". AFAICT, the expression has sensible
> default arguments. I don't know where it fails and --show-trace
> doesn't show any trace. So I'm stuck there.
>
> 3. "nix-build ./nixos/release-combined.nix" (and the -small variant)
> doesn't build any packages from the 'nixpkgs' set because it doesn't
> contain (direct) derivations. Same problem as (1).
>
> So is Hydra doing some magic with these expressions? Is it possible to
> build "world" with a simple "nix-build"?
>
> Best regards,
> Bjørn Forsman
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ZFS configuration for 17.03
Evan, I found zfs config pretty straight forward. I just added supportedFilesystems = ["zfs"]; and configured particular partitions as ZFS so they are mounted during boot. What exactly you want to know? 2017-05-26 21:11 GMT+01:00 Evan Rowley : > I have seen some guides from 2014 and 2015 but these are pre-17.03. Are > there any recent configurations guides, configuration.nix, or basic > pointers for setting this up for a new system? > > -- > - EJR > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > https://mailman.science.uu.nl/mailman/listinfo/nix-dev > > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] concatAttrs :: [attrSet] -> attrSet ?
https://github.com/NixOS/nixpkgs/blob/master/lib/attrsets.nix#L413 is also
handy
2017-05-29 13:36 GMT+01:00 Domen Kožar :
> mkMerge can be used only with NixOS modules.
>
> I do remember some recursive merge function, but can't find it now.
>
> On Mon, May 29, 2017 at 2:29 PM, Volth wrote:
>
>> there is also lib.mkMerge to handle nested attrs
>>
>> On 5/29/17, Domen Kožar wrote:
>> > Note that this will fail if you'll nest the attributes, one will
>> override
>> > the other.
>> >
>> > nix-repl> :p concatAttrs [ {x={a =3;};} {x={ b= 4;};} ]
>> > { x = { b = 4; }; }
>> >
>> >
>> > On Sun, May 28, 2017 at 5:23 PM, Sergiu Ivanov
>> wrote:
>> >
>> >> Hey Leo,
>> >>
>> >> Thus quoth Leo Gaspard at 13:05 on Sun, May 28 2017:
>> >> > On 05/28/2017 02:58 PM, Sergiu Ivanov wrote:
>> >> >> My use case is quite specific. I do this, approximately:
>> >> >>
>> >> >> let func name = { "${name}" = something name; };
>> >> >> in concatAttrs (map func [ "name1" "name2" ])
>> >> >
>> >> > If this is your use case, you could also be interested in `genAttrs`
>> >> > defined in `lib/attrsets.nix` ;)
>> >>
>> >> Excellent! Worked like a charm, thanks a lot! (After I realised I had
>> >> to use it like pkgs.lib.genAttrs in my context :-) )
>> >>
>> >> --
>> >> Sergiu
>> >>
>> >> ___
>> >> nix-dev mailing list
>> >> nix-dev@lists.science.uu.nl
>> >> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>> >>
>> >>
>> >
>>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Auto-generated expressions for applications
Current approach seems to be doing the job except notifying people when dependency is updated. Previously we had monitor to do some similar stuff, and I think vulnix can check that without much effort so I wouldn't worry about having duplicated packages for apps. I think focusing on improving CI process and security notifications process is the way to go. Probably we could set another process/job in hydra to check all apps for security issues/updates. (I'm not sure if security team doesn't have that already). 2017-05-30 10:17 GMT+01:00 Marc Weber : > Let met try to sum up what I remember: > > - There 3+ solutions to update "sources" documented on the wiki > somewhere - ideas from comparing versions with other distributions up > to adding scrapers getting latest version from web sites if I recall > correctly > > - Putting automatically generated code into nixpkgs doesn't solve all > issues, for corner cases you have to duplicate dependencies using > different version constraints. > > -> overhead > > - Its not always quite clear how stable the user wants to be > (gimp/inskscape) case, master sometimes has new features. > > So which versions to support ? > > - Whatever we do, we don't solve anything for other distros (which > suffer the same problem), unless we switch point of view: > > The solution would be a cross platform cross language dependency > management system allowing to declare dependencies in a file so that > you can even install from gihtub automatically. > > systemPackages = [ (fromGithub "user/package" "HEAD") ] # sort rest out > on your own, thanks > > package A could be working, package B could be working, but [A B] in the > same environment not (because they both depend on executable C) > > After all we want nixpkgs to be at least stable enough to have broken > packages marked as broken and expect everything else to at least > compile/install. > > Which are the best short/middle/long term solutions ? > > Marc Weber > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > https://mailman.science.uu.nl/mailman/listinfo/nix-dev > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Background images of desktop managers
Shouldn't the wallpaper be the user/session setting rather than system
setting?
Looks like kde, gnome, xfce way of doing this seems to be more natural,
user changes the wallpaper in his session.
Personally, I'm using awesome window manager and I use it with xfce session
so I have all other goodies that awesome is not offering. For all other
cases I think this should be implemented on the user space.
2017-05-30 9:25 GMT+01:00 zimbatm :
> Hi Maximilian,
>
> Welcome to the list :)
>
> Did you try setting `services.xserver.desktopManager.default = "none"`? I
> suspect that might do what you wanted. The "none" desktop manager doesn't
> do anything but should still apply the wallpaper regardless of the
> windowManager that you chose.
>
>
> On Sun, 28 May 2017, 08:53 Maximilian Bosch, wrote:
>
>> Hey there,
>>
>> before I start with the actual topic I'd like to introduce myself as this
>> is the first time I submit something to the `nix-dev` mailing list: I'm
>> Maximilian Bosch from Munich, I work for the Mayflower GmbH and I started
>> using NixOS at the beginning of 2017 and submitted several PRs since then.
>>
>> Right now I'm working on the following thing: https://github.com/
>> NixOS/nixpkgs/pull/26156
>>
>> As the title says, I'd like to have some background image support for
>> window managers as well (XMonad in my case). Right now I solve this with
>> some ugly shell in the `sessionCommands` script, but I'd like to have a
>> more suitable solution for this.
>>
>> Right now you can set an internal option in the {desktop,window}Managers,
>> but `bgSupport` isn't available for the windowManagers (see
>> https://github.com/NixOS/nixpkgs/blob/master/nixos/
>> modules/services/x11/window-managers/default.nix,
>> https://github.com/NixOS/nixpkgs/blob/master/nixos/
>> modules/services/x11/desktop-managers/default.nix).
>>
>> I decided to change this, please refer to the linked PR for more details
>> there.
>>
>> Right now it works quite fine with `i3`, but when I tried to test it with
>> desktopManagers like `gnome3` or `xfce` (both of them have `bgSupport`
>> enabled ATM), I realized that they set their own background internally and
>> override the stuff declared by the `feh --bg-scale` call.
>>
>> Therefore I'd like to know: is there any specific reason I'm missing why
>> desktopManagers have this bgSupport thign? It works fine with some
>> windowManagers (not all of them, `awesome` overrides the background as
>> well), but it seems to break with the desktopManagers.
>>
>> And if that's just some legacy thing: can the bgSupport be removed from
>> the desktopManagers?
>>
>> Have a great sunday and thanks in advance,
>>
>> Maximilian Bosch
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] A nix pretty-printer and a trace function you can tell how deep it should go
nice, thank you
2017-06-12 16:33 GMT+01:00 Profpatsch :
> https://github.com/NixOS/nixpkgs/pull/26433
>
> Pretty Printing:
>
> nix-repl> lib.generators.toPretty {} { foo = [ 2 3 netcat-openbsd ]; bar =
> lib.id; x = {args, def ? 42}: args; }
> "{ \"bar\" = <λ>; \"foo\" = [ 2 3 <δ> ]; \"x\" = <λ:{args,(def)}>; }"
>
> nix-repl> lib.generators.toPretty {} (import )
> "<λ:{(config),(crossSystem),(localSystem),(overlays),(
> platform),(system)}>"
>
>
> Trace Folding:
>
> nix-repl> foo = { a = [ 1 [ 2 3 ] ]; b = { c.d.e = "yip yip"; }; }
>
> nix-repl> lib.traceValSeqN 10 foo
> trace: { "a" = [ 1 [ 2 3 ] ]; "b" = { "c" = { "d" = { "e" = "yip yip"; };
> }; }; }
> { a = [ ... ]; b = { ... }; }
>
> nix-repl> lib.traceValSeqN 3 foo
> trace: { "a" = [ 1 [ 2 3 ] ]; "b" = { "c" = { "d" = {…}; }; }; }
> { a = [ ... ]; b = { ... }; }
>
> nix-repl> lib.traceValSeqN 1 foo
> trace: { "a" = […]; "b" = {…}; }
> { a = [ ... ]; b = { ... }; }
>
> nix-repl> lib.traceValSeqN 0 foo
> trace: {…}
> { a = [ ... ]; b = { ... }; }
>
>
> https://twitter.com/Profpatsch/status/874127956884566016
>
> I hope this helps some people.
> Please review the code.
>
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] okteta fix build
For me https://nixos.org/nixpkgs/manual/#chap-submitting-changes implies that github must be used. But on website http://nixos.org/nixos/community.html nix-dev mailing list is mentioned as another way. Would be nice to be more clear and specific how it works and who is responsible for testing changes if they are not comming as PR, is there any travis like pipeline etc. 2017-06-27 16:10 GMT+01:00 Shea Levy : > Mailing list is a perfectly appropriate place to send git patches that > doesn't require membership with a proprietary service; You may not care > about that (I personally don't), but there's no reason we can't > accommodate those who do. > > Joachim Schiele writes: > > > please provide your nice patches via a PR on github.com/nixos/nixpkgs to > > 'master' > > > > if you are unsure about the workflow, please ask and we'll help you! > > thanks for your work! > > > > On 25.06.2017 19:51, Karn Kallio wrote: > >> > >> The attached patch fixes the build of the Nixpkgs KDE application > >> okteta by adding some missing dependencies. > >> > >> > >> > >> ___ > >> nix-dev mailing list > >> nix-dev@lists.science.uu.nl > >> https://mailman.science.uu.nl/mailman/listinfo/nix-dev > >> > > > > > > ___ > > nix-dev mailing list > > nix-dev@lists.science.uu.nl > > https://mailman.science.uu.nl/mailman/listinfo/nix-dev > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > https://mailman.science.uu.nl/mailman/listinfo/nix-dev > > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-daemon and private git repos
You don't need to know the user itself I think, you could share it with
nixbld group (probably).
Also, I think this way recommends to use ssh-agent as far as I remember
looking at that (but could changed).
What I did for one project was:
337 fetchgitPrivate = (args: derivation ((nixpkgs.fetchgit
> args).drvAttrs // {
> 338 # This function is wrapper around nix fetch git function
> to use SSH key.
> 339 # It can be useful when fetching from private
> repositories.
> 340 #
>
> 341 # Original function is in
> https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/fetchgit/default.nix
> 342 #
>
> 343 GIT_SSH = rr.lib.writeShellScript "git-ssh" ''#!
> ${nixpkgs.bash}/bin/bash -eu
> 344 if ! [[ -r '${repositories-ssh-private-key-path}'
> ]];then
> 345 echo "ERROR:" >&2
>
> 346 echo "ERROR:" >&2
>
> 347 echo "ERROR: ssh key
> '${repositories-ssh-private-key-path}' is not readable by build user
> ($(id))" >&2
> 348 echo "ERROR:" >&2
>
> 349 echo "ERROR:" >&2
>
> 350 exit 5
>
> 351 fi
>
> 352 exec ${nixpkgs.openssh}/bin/ssh -o
> StrictHostKeyChecking=no -i '${repositories-ssh-private-key-path}' "$@"
> 353 '';
But probably is way better to go with agent.
2017-07-03 14:19 GMT+01:00 Harmen :
> Hi all,
>
> I'm struggling to get fetchgitPrivate to work on nix-daemon installation
> (no
> NixOS, these are Ubuntu machines with nix).
> I can make it work on my dev machine, with is a non-daemon install, by
> setting
>
> NIX_PATH=ssh-config-file=/my/ssh/config:$NIX_PATH
>
> But that doesn't work in sandboxed daemon mode, because the nixbld* users
> can't
> read that file (both because of access rights, and because of the sandbox).
>
> Nix has this warning in fetchgitPrivate:
> > Note that the config file and any keys it points to must be readable
> > by the build user, which depending on your nix configuration means
> making it
> > readable by the build-users-group, the user of the running nix-daemon,
> or the
> > user calling the nix command which started the build. Similarly, if
> using an
> > ssh agent ssh-auth-sock must point to a socket the build user can access.
> > You may need StrictHostKeyChecking=no in the config file. Since ssh
> > will refuse to use a group-readable private key, if using build-users
> you will
> > likely want to use something like IdentityFile /some/directory/%u/key
> and have
> > a directory for each build user accessible to that user.
> from
> https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/fetchgit/
> private.nix
>
> which sounds reasonable, but it I don't see how to do that since I don't
> know
> exactly which user will run the build. Also because of the sandbox the
> build
> can't read the ssh config file at all.
>
>
> So next option is to generate the configfile in my expression, a-la
> https://www.mpscholten.de/nixos/2016/07/07/private-
> github-repositories-and-nixos.html
> but I don't know how to set nix.path from inside an expression. It would
> also
> require bundling the key with the expression, but if that works...
>
>
> I can't be the first to want to use fetchgitPrivate with a sandboxed
> nix-daemon. Any experiences or tips?
> Thanks!
> Harmen
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bare XMonads environment and KDE5 programs
You could try to set this variable in your ~/.xprofile file and re-login as
a workaround
2016-05-03 5:20 GMT+01:00 Ruben Astudillo :
> Hi all
>
> I am recently changing from KDE4 -> KDE5 on my bare XMonad setup. I
> didn't do it before because I was encountering a error with KIO-slaves
> and icons no showing. I have basically this setup
>
> -- /etc/nixos/configuration.nix
> services.xserver = {
>displayManager.lightdm.enable = true;
>desktopManager.kde5.enable = true;
> };
>
> plus on my user profile I have installed (from nixos.kde5 attr):
> breeze-5.5.5
> dolphin-15.12.3
> gwenview-15.12.3
>
> I've got luck lunching dolphin as
>
> slack@tapioca> XDG_CURRENT_DESKTOP=kde dolphin
>
> yet it can't launch gwenview by clicking. Is there something obvious
> missing from my setup?
>
> --
> -- Ruben Astudillo
> ___
> 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] [***SPAM***] Re: On commit naming conventions
Huh, so oh the other hand, maybe some "cancellation policy" can be added. "If there is no code change in PR for more than 3 months close it." (myself has two similar PRs, one is waiting for review/acceptance for quite a long time, the other one is waiting for me to implement it - maybe this can make things moving faster?) 2016-05-05 10:42 GMT+01:00 Michael Raskin <7c6f4...@mail.ru>: > >I'm working with PR for more than 1,5 years. I saw maybe once that a > person completely lost his interest. > > It depends on the scope of «lost interest» > > I have seen many open PRs with minor problems to fix; these were from > people who later got commit access and never finished some of their > early submissions (I assume they didn't have time right after getting > a suggestion to fix something, forgot or lost interest later and > probably didn't use the code afterwards). Many of these were old enough > to have merge conflicts. > > > > ___ > 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] Packaging software that mutates itself
IMHO, this is pretty simple. You pack "first/original" version into immutable store /nix/store. You add tiny wrapper around it, which checks if /var/lib/ exists, if not, create directory and copy binary there and run it there. If file already exists in /var/lib, execute it directly. Application can update itself there. 2016-05-05 23:07 GMT+01:00 Nikita Karetnikov : > On Fri, May 06, 2016 at 01:02:15AM +0300, Nikita Karetnikov wrote: > > The server is controlled by other people. > > I'd like to add that I'm assuming that these people are not malicious. In > this > case, I'm more worried about a misconfigured package that might break my > system > in some way. > ___ > nix-dev 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] Packaging software that mutates itself
Alexei, looks like steam does exactly that trick, just per user basis rather than on the system level. It keeps itself in ~/.local/share/steam I think, and applications are kept there as well and installed there but this are steam internals (nothing to do with nixos packaging). 2016-05-06 1:14 GMT+01:00 Alexei Robyn : > I suggest you look into the way Steam is packaged, as it also self-updates > (and updates other applications under its control). > > > On Fri, May 6, 2016, at 09:13 AM, Tomasz Czyż wrote: > > IMHO, this is pretty simple. > You pack "first/original" version into immutable store /nix/store. You add > tiny wrapper around it, which checks if /var/lib/ exists, if not, > create directory and copy binary there and run it there. If file already > exists in /var/lib, execute it directly. Application can update itself > there. > > 2016-05-05 23:07 GMT+01:00 Nikita Karetnikov : > > On Fri, May 06, 2016 at 01:02:15AM +0300, Nikita Karetnikov wrote: > > The server is controlled by other people. > > I'd like to add that I'm assuming that these people are not malicious. In > this > case, I'm more worried about a misconfigured package that might break my > system > in some way. > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > > > > -- > Tomasz Czyż > *___* > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > > > _______ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Persistent NixOps keys
I'm not sure I understand this correctly. Do you want to put keys into the
initrd?
2016-05-08 20:54 GMT+01:00 Игорь Пашев :
> Simple way to keep the keys on reboot.
> /run/keys is mounted somewhere in initrd,
> thus just a couple of services
> (I was thinking about on-disk /run/keys)
>
> { config, lib, pkgs, ... }:
> let
>
> inherit (builtins) attrNames;
> inherit (lib) mkIf concatMapStringsSep;
> inherit (config.deployment) keys;
>
> store = "/root/keys";
> runkeys = "/run/keys";
>
> load = pkgs.writeBashScript "nixops-load-keys" ''
> set -euo pipefail
> if [ -e '${store}/done' ] && [ ! -e '${runkeys}/done' ]; then
> cd '${store}'
> cp -pf -- ${concatMapStringsSep " " (k: "'${k}'") (attrNames keys)} \
> '${runkeys}/' || exit 0
> touch -r '${store}/done' '${runkeys}/done'
> fi
> '';
>
> save = pkgs.writeBashScript "nixops-save-keys" ''
> set -euo pipefail
> while true; do
> if [ -e '${runkeys}/done' ]; then
> if [ ! -e '${store}/done' ] || [ '${runkeys}/done' -nt
> '${store}/done' ] ; then
> rm -rf '${store}'
> mkdir -p '${store}'
> chown --reference='${runkeys}' -- '${store}'
> chmod --reference='${runkeys}' -- '${store}'
> cd '${runkeys}'
> cp -pf -- ${concatMapStringsSep " " (k: "'${k}'") (attrNames
> keys)} \
> '${store}/' || continue
> touch -r '${runkeys}/done' '${store}/done'
> touch -r '${runkeys}' '${store}'
> fi
> fi
> sleep 1m
> done
> '';
>
> in {
> config = mkIf (keys != {}) {
> systemd.services.nixops-load-keys = {
> description = "Re-load nixops keys after reboot";
> before = [ "nixops-keys.service" ];
> wantedBy = [ "keys.target" ];
> unitConfig.RequiresMountsFor = [ runkeys store ];
> serviceConfig = {
> ExecStart = load;
> Type = "oneshot";
> RemainAfterExit = false;
> };
> };
>
> systemd.services.nixops-save-keys = {
> description = "Save nixops keys to re-load after reboot";
> after = [ "keys.target" ];
> wantedBy = [ "keys.target" ];
> serviceConfig = {
> ExecStart = save;
> Restart = "always";
> };
> };
> };
> }
>
>
> P. S. writeBashScript:
> { bash, writeScript, haskellPackages, runCommand }:
>
> name: text:
> let
> f = writeScript name ''
> #!${bash}/bin/bash
> ${text}
> '';
> in
> runCommand name { } ''
> ${haskellPackages.ShellCheck}/bin/shellcheck ${f}
> cp -a ${f} $out
> ''
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
--
Tomasz Czyż
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] NixOps - secret/credentials management
Hi all NixOps users and devs. I wanted to deploy some secrets/certificates to machines and I'm not sure how to do that. I would like to avoid storing those in nix store. Is there any way to deploy secrets to machines and not use nix store? I know there is solution to deploy disk encryption keys which is stored in state file, but what about other secrets? Is there any general way to handle that? I thought that I could do that using "nixops ssh" feature, but I would like to describe those credentials in network.nix file, is that possible? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOps - secret/credentials management
Igor posted some solution to have persistant keys few days back: https://www.mail-archive.com/nix-dev@lists.science.uu.nl/msg18995.html Worth to adding to docs? 2016-05-12 15:31 GMT+01:00 Graham Christensen : > > > On Thu, May 12, 2016 at 4:43 AM, Rob Vermaas > wrote: > >> >> Note >> that this is a location on a tmpfs, so if you want to have it on a >> persistent disk, you'll need to copy it to a location of your >> choosing. >> > > This seems like a good candidate note to have in the documentation, as > nixops currently doesn't indicate it is temporary. > > I'm really glad to know of the feature, though. > > Thank you, > Graham Christensen > > -- 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 - secret/credentials management
Rob: thank you! This might be what I'm looking for, I'll try that. 2016-05-12 15:45 GMT+01:00 Tomasz Czyż : > Igor posted some solution to have persistant keys few days back: > https://www.mail-archive.com/nix-dev@lists.science.uu.nl/msg18995.html > > Worth to adding to docs? > > 2016-05-12 15:31 GMT+01:00 Graham Christensen : > >> >> >> On Thu, May 12, 2016 at 4:43 AM, Rob Vermaas >> wrote: >> >>> >>> Note >>> that this is a location on a tmpfs, so if you want to have it on a >>> persistent disk, you'll need to copy it to a location of your >>> choosing. >>> >> >> This seems like a good candidate note to have in the documentation, as >> nixops currently doesn't indicate it is temporary. >> >> I'm really glad to know of the feature, though. >> >> Thank you, >> Graham Christensen >> >> > > > -- > Tomasz Czyż > -- Tomasz Czyż ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Users of 32-bit NixOS channels?
maybe it's better to check download statistics from that channel? 2016-05-16 23:08 GMT+01:00 : > Hi all, > > Periodically I like to check to see how many people are still running > 32-bit NixOS systems from the channel. If it ever happens that no one > responds, we can stop building it in hydra and significantly lighten the > build load. Maybe in 20 years or so ;) > > So, please respond if you're running a NixOS with a 32-bit kernel with > hydra-provided binaries! > > ~Shea > > ___ > 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] python2nix requires old pip?
Recently I've got https://github.com/garbas/pypi2nix working, looks like usefull tool. But I had to make own package, the one from nixpkgs didn't work for me. 2016-06-06 17:59 GMT+01:00 Jeffrey David Johnson : > What's the current state of the py*2nix helpers? I just tried to run > python2nix and got this: > > $ python2nix > Traceback (most recent call last): > File > "/nix/store/mpzwan1fyraps3kmigpda76lzyj9r9qy-python2nix-20140927/bin/.python2nix-wrapped", > line 8, in > from python2nix import main > File > "/nix/store/mpzwan1fyraps3kmigpda76lzyj9r9qy-python2nix-20140927/lib/python2.7/site-packages/python2nix/__init__.py", > line 5, in > from python2nix import pip_deps > File > "/nix/store/mpzwan1fyraps3kmigpda76lzyj9r9qy-python2nix-20140927/lib/python2.7/site-packages/python2nix/pip_deps.py", > line 15, in > from pip.log import logger > ImportError: No module named log > > It worked for me until recently. Is anyone else currently using it? > According to https://github.com/proger/python2nix it requires pip==1.5.6, > so I'm guessing that just needs to be hunted down and added as a dependency. > > Also tried cloning the two pypi2nix repos ( > https://github.com/garbas/pypi2nix and > https://github.com/offlinehacker/pypi2nix) but couldn't get either of > them to work. > Jeff > _______ > 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
