<{^_^}>
nix#3435 (by amckinlay, 4 days ago, open): error: could not set permissions on '/nix/var/nix/profiles/per-user' to 755: Operation not permitted
<LnL>
yeah thought it was that one
<domenkozar[m]>
to reproduce this one, install nix on darwin, but make sure nix-daemon never starts
<domenkozar[m]>
then nix will fallback to single user mode and try to create directories
<domenkozar[m]>
something along those lines
<domenkozar[m]>
I had this bug in cachix-action, where `nix-build` execute run before nix-daemon would start
<LnL>
I was expecting that to be an issue with db permissions
<domenkozar[m]>
executed*
<LnL>
don't recall exactly how nix falls back to local but I guess it could also be that
<domenkozar[m]>
well there could be different situations under which it happens
<domenkozar[m]>
but doing something like
<domenkozar[m]>
install-nix && nix-build
<domenkozar[m]>
will definitely fail this way
<domenkozar[m]>
I think nix-daemon will create directories on first command
<domenkozar[m]>
so easier to reproduce is
<domenkozar[m]>
1. install nix
<domenkozar[m]>
2. change nix.conf and pkill nix-daemon
<domenkozar[m]>
3. run quickly nix-build
<puck>
Profpatsch: it reads the keys, but not the values, so e.g. this mostly means reading + parsing all-pkgs.nix or whatever it was called
<LnL>
cool, I'll play with that later
<Profpatsch>
puck: but then I wonder what infinisil’s use-case is.
<puck>
Profpatsch: cases where you can't or won't provide all keys in an attrset at the same time
<Profpatsch>
I’m suspecting the merge function of the module system, where you might not be able to build the set of keys without evaluating way too much.
<Profpatsch>
But then the question becomes: why not make nix lazy in the keys.
<gchristensen>
the module system can't really tell you anything without evaluating pretty much everything
<puck>
Profpatsch: because it's pretty hard
<gchristensen>
I suspect one reason it isn't lazy in keys is because iteration is ordered
<puck>
Profpatsch: e.g. builtins.attrNames and builtins.attrValues depend on the order of the keys, which involves evaluating everything
<Profpatsch>
puck: well, if you call those you force of course.
<Profpatsch>
But if you only do foo.bar, then you only have to evaluate until you find bar
<puck>
yes, but that means either defining the order in which keys are ordered, or having huge amounts of evaluator-specific behavior
<Profpatsch>
So if you have ({ a = …; } // { foo = …; } // { x = …; }).foo you wouldn’t need to do the last //
<Profpatsch>
Argh, you would have
<gchristensen>
what if you had { "foo" = 1; } // { x = 1; } // { "foo" = null; }
<Profpatsch>
yeah
<puck>
also yeah evaluation would be the opposite direction anyways
<Profpatsch>
Hm, but then it works, just the other way around
<puck>
the primary issue with this is e.g. let trace = v: builtins.trace v v; { ${trace "foo"} = "foo"; ${trace "bar"} = "bar"; } ? baz
<Profpatsch>
I wonder if it’s a semantics-preserving optimization or if you can write code that works with lazy keys but doesn’t with strict keys
<puck>
does this output "foo", then "bar"? or would it also be allowed to output "bar" then "foo"
<puck>
Profpatsch: the latter is trivial
<gchristensen>
imo either is fine, puck
<Profpatsch>
puck is probably the one person who knows the nix evaluator better than niksnut :P
<puck>
also with lazy keys, does this suddenly become acceptable: let a = { ${trace "b"} = {}; }; a.${trace "b"}.c = 5; in a.b.c
<Profpatsch>
puck: trace is usually not well-defined in lazy languages.
<puck>
Profpatsch: imagine trace is actually a sideeffectful operation here
<Profpatsch>
e.g. you can only guarantee that trace prints if it is reached
<Profpatsch>
puck: but are there any that are intended
<gchristensen>
delete that
<Profpatsch>
derivation is not a side effect
<Profpatsch>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 239
<Profpatsch>
puck++
<{^_^}>
puck's karma got increased to 4
<puck>
i can tell if you call e.g. a then b, vs b then a, which means that evaluation order has a noticable effect
<gchristensen>
puck: what is the nugget in that quantum state thing which lets it work?
<puck>
gchristensen: pathExists and toFile
<puck>
i calculate the hash that a toFile operation would have, without running toFIle
<gchristensen>
this is the worst thing :P
<Profpatsch>
pathExists should not be a builtin tbh
<gchristensen>
puck: is there a way to fix that..?
<puck>
complex
<puck>
there's a hacky way, but it doesn't really fix the full issue
<puck>
also i'm pretty sure this is doable without pathExists and toFile either
<srk>
hm, why doesn't nix garbage collect oldest paths first but uses randomized approach instead?
<gchristensen>
puck: you're amazing
v0|d has quit [Ping timeout: 258 seconds]
ryantm has quit [Ping timeout: 256 seconds]
orivej_ has joined #nixos-dev
orivej has quit [Read error: Connection reset by peer]
callahad8707 has quit [Ping timeout: 240 seconds]
callahad8707 has joined #nixos-dev
dongcarl has quit [Read error: Connection reset by peer]
<MichaelRaskin>
To break this one should forbid pathExists on the store
<gchristensen>
oh great idea
<MichaelRaskin>
(which is not known at compile time, runtime store might be different)
<worldofpeace>
Hey, I need help finishing https://github.com/NixOS/nixpkgs/pull/80848 (could someone pick it up). In that regard, I don't think the release notes are exactly done for 20.03
<ma27[m]>
the problem is: the original author declared it as unfree since it's not OSI-approved (I guess?), but from what I understand it's actually a free license (redistribution, modification etc seems to be possible) and based on gplv3
<puck>
<MichaelRaskin> To break this one should forbid pathExists on the store <- except there's cases this is probably valid in, e.g. filterSource output
<MichaelRaskin>
ma27[m]: isn't its use restriction unfree by most definitions?
<MichaelRaskin>
puck: erm. do we and should we use it like that?
<simpson>
ma27[m]: Not a lawyer, not your lawyer; SSPL is obviously unfree.
<ma27[m]>
could you explain to me why? :)
<drakonis>
this calls for a new license category label
<simpson>
Because it infringes on the Zeroth Freedom, "The freedom to run the program as you wish, for any purpose"
<drakonis>
restricted usage
<drakonis>
or maybe a new system for handling licenses
<drakonis>
we're about to enter a new era of new licenses outside the scope of the fsf and osi
<drakonis>
the license is designed to restrict cloud usage
<drakonis>
cloud restricted licenses
<simpson>
Too bad they can't publish Mongo under a license which forbids *all* usage~
<{^_^}>
nixops#1264 (by grahamc, 1 day ago, open): Example NixOps State Backends
<drakonis>
ma27[m]: i think it would've been best to merge it with a warning to read the license
<ma27[m]>
well, it's marked as unfree now :)
<ma27[m]>
so people will be forced to check on it by default
<drakonis>
fair enough, an compromise for this release
<drakonis>
time to build a replacement for the existing licensing setup
<drakonis>
include attribute sets to indicate licenses a package might have?
<domenkozar[m]>
gchristensen: does it work already?
<drakonis>
and this might tie up to the one thing i wanted to do earlier this year, which was including improved package metadata for filtering
<drakonis>
seems like a good time to begin
<gchristensen>
domenkozar[m]: mostly yes
<gchristensen>
but really don't want to merge yet :)
<domenkozar[m]>
not great, not terrible
<drakonis>
i have a distinct desire to list all available importer packages
<domenkozar[m]>
gchristensen: I really like how backends are so simple
<gchristensen>
:D
<domenkozar[m]>
it feels like cheating, maybe we should use Haskell instead
<gchristensen>
lol
<drakonis>
ma27[m]: i see you pinged me on the issue
<domenkozar[m]>
(sorry folks, Friday is closing by and I read today we'll be stuck home for next 18 months, trying to control snarky comments :D)
<gchristensen>
ack.
<gchristensen>
domenkozar[m]: so, I have actually used this PR quite a bit now and it works really well. I'm deploying it to "prod" for me soon, to stress it more
<gchristensen>
it works great :) but really don't want to merge it yet.
<domenkozar[m]>
I didn't dig into it, does it handle locking?
<gchristensen>
yep
<gchristensen>
look at the S3 one.
<gchristensen>
the "Legacy" one doesn't need locking (the existing statefile stuff locks it automatically) and the memory one also doesn't for obvious reasons
<domenkozar[m]>
I see :)
<domenkozar[m]>
locking in 9 lines
<domenkozar[m]>
you win
<gchristensen>
domenkozar[m]: I was considering the possibility of the state backend being a context manager, but it seemed a bit weird. I'm not sure why though...
<domenkozar[m]>
I'd add storage.locking as context manager, where locking would happen for all storage backends
<domenkozar[m]>
so it's part of the api
<gchristensen>
hmmm yeah
<domenkozar[m]>
but I also don't think this needs to be in scope
<gchristensen>
locking could be its own provider
<gchristensen>
but that is maybe overkill
<domenkozar[m]>
well maybe if you want to use local storage
<domenkozar[m]>
and amazon locking
<domenkozar[m]>
(for some weird reason)
<domenkozar[m]>
but I agree with overkill
<gchristensen>
I started implementing a etcd backend too but got bored trying to find a good etcd client and decided to leave it to someone who actually cares about etcd
<cransom>
i'm still generally amazed/bewildered that the super popular answer to locking behavior in the cloud is dynamodb.
<gchristensen>
yeah, kinda weird
Jackneill has quit [Ping timeout: 240 seconds]
FRidh2 has quit [Quit: Konversation terminated!]
lassulus has quit [Ping timeout: 240 seconds]
lassulus_ has joined #nixos-dev
<domenkozar[m]>
gchristensen++ for reviving nixops
<{^_^}>
gchristensen's karma got increased to 240
lassulus_ is now known as lassulus
<mkaito>
just as I'm trying desperately to stop using nixops lol
<gchristensen>
bashful.gif
<gchristensen>
mkaito: why?
<mkaito>
because I have deadlines and I spend way too much time fighting it
<gchristensen>
which parts do you fight?
<mkaito>
just today, libvirt deploy doesn't work because "cannot resolve username", so I switch to virtualbox, and the base image is too ancient and I have to reboot the vm every time I deploy -_-
<gchristensen>
ah, ouch
<mkaito>
now I'm just spinning up EC2 machines and `nixos-rebuild --target-host` to it instead
<gchristensen>
sometime soon I plan on running CI on PRs with actual backends
<domenkozar[m]>
yeah I was telling my friend how hetzner backend just works and then we hit like 3 bugs just to provision the machine
<domenkozar[m]>
and spent like almost a day
<srk>
there were several PRs for libvirt but they all got rotten due to state of nixops :(
<domenkozar[m]>
I think it really just needs functional tests that anyone can run
<mkaito>
we've talked frequently about donating some worktime to nixops at serokell, but it always slips through the cracks
<gchristensen>
srk: I suppose the Python 2 -> 3 switch likely made them unmergeable until they're updated, but hopefully the addition of types will make them easier to merge
<gchristensen>
mkaito: would serokell be interested in sponsoring the work I've been doing? :P
<mkaito>
maybe, talk to yorick :P
<gchristensen>
yorick: would serokell be interested in sponsoring the work I've been doing? :P
<gchristensen>
but for it to be a healthy project, there needs to be people who care and can/do merge/reniew stuff
<yorick>
gchristensen: what are you been doing?
<srk>
I'll take a look at libvirt backend if the PR can be revived
<gchristensen>
yorick: well I (and others) updated it it from python2 -> 3 and am about done adding state storage backends. I'd like to add automated testing for PRs using real services that cost money (money is no proble,m it is time ..) and add declarative arguments and nix-path support too
<gchristensen>
generally, simplify nixops core and make it easier to understand the code of course, at the same time
<srk>
what I like about morph is that you can run stateless easily
<gchristensen>
yeah
<srk>
I wrote a none backend for nixops which does the same
<mkaito>
we're currently using a combination of terraform + pushing/activating system closures for deployment btw
<gchristensen>
{ network.storage.memory = {}; } <- in-memory state file
<yorick>
gchristensen: I had massive performance issues around 200 machines
<srk>
gchristensen: will it still create SSH key pairs?
<gchristensen>
srk: that is another thing to change, for sure
<gchristensen>
adisbladis has been working with me a lot too on all ofthese PRs, and he submitted nixops#1247, nixops#1248 which I based my memor ybackend on, and I'm lookin forward to nixops#1256 for sure
<MichaelRaskin>
But I saw that the benefit is not large enough and did not polish it
<MichaelRaskin>
domenkozar[m]: have you dropped udev settling from your tests already?
<domenkozar[m]>
I haven't done any tweaks yet
<domenkozar[m]>
how do I do that?
<gchristensen>
make sure you're not doing dhcp, too
<domenkozar[m]>
why can't we add these to nixos tests as a default?
<MichaelRaskin>
I think removing udev-settling from the hot path is just being slowly processed NixOS-wide
<pie_[bnc]>
garbas: any reason you dont want to put vidyo in nixpkgs? I see its in nixpkgs-mozilla
<pie_[bnc]>
garbas: also do you know anything about it hanging...
* pie_[bnc]
retries with unstable
<domenkozar[m]>
AttributeError: 'object' object has no attribute 'name'
<domenkozar[m]>
yeah I didn't miss Python at all
<gchristensen>
more types
<domenkozar[m]>
oh it works
<domenkozar[m]>
I do get: mux_client_request_session: session request failed: Session open refused by peer
<gchristensen>
too many connections? hrm
<adisbladis>
Damn peer... Always refusing & closing my connections. Give him a stern talking.
<domenkozar[m]>
maybe it doesn't like 15 ssh connections :D
<domenkozar[m]>
nixops uses run_tasks per machine
<gchristensen>
maybe could nr_workers to like 3 or 5
<domenkozar[m]>
so it could be that running over the same machine is not safe
<gchristensen>
actually domenkozar[m], try this: 1) make sure you have a control socket open by running a trrivial ssh command like "true", and then do a run_tasks
<domenkozar[m]>
The sshd daemon on the server is limiting the number of sessions per network connection. This is controlled by MaxSessions option in /etc/ssh/sshd_config
<domenkozar[m]>
previous default of 10,
<domenkozar[m]>
This allows increasing the number of allowed sessions above the
<domenkozar[m]>
8 it is
<gchristensen>
:D
<domenkozar[m]>
yay
<pie_[bnc]>
garbas: trying to run Vidyo via `let moz = builtins.fetchGit { url = "https://github.com/glasserc/nixpkgs-mozilla.git"; }; in (import <nixpkgs> { overlays = [ (import "${moz}/vidyo-overlay.nix") ]; }).VidyoDesktop
<pie_[bnc]>
` fails for me with at least `/usr/bin/VidyoDesktop: line 6: 32420 Segmentation fault (core dumped) /nix/store/h7lch18i41g2h932xpmwdy847mz6g7y2-VidyoDesktopDeb-3.6.3/opt/vidyo/VidyoDesktop/$EXEC $option $audioflag $@`
<pie_[bnc]>
just realized im on someones weird branch, time to try the official one
<domenkozar[m]>
not great not terrible but vewy fast
bhipple has joined #nixos-dev
<pie_[bnc]>
yep still borked
<gchristensen>
domenkozar[m]: a future project will be making these mega-functions smaller :P
<domenkozar[m]>
yeah I took the straight line
<gchristensen>
yeah
<gchristensen>
of course
<domenkozar[m]>
I can only handle that much objects per day
<domenkozar[m]>
many*
<gchristensen>
man, all my deployments are moved over to using various sets of unmerged nixops PRs and it makes it hard to test your PR hehe
<infinisil>
Sounds like more pure tests are needed
<domenkozar[m]>
I use
<domenkozar[m]>
nix-build release.nix -A build.x86_64-linux --arg p "p: [ (p.callPackage ../nixops-aws/release.nix {}) ]"
<domenkozar[m]>
but then my deployment is boring :)
<gchristensen>
infinisil: yes absolutely
<gchristensen>
and also
<gchristensen>
this points out numerous tricky bits :)
<gchristensen>
domenkozar[m]: my deployments have mostly moved to s3 state storage :)
<domenkozar[m]>
heh
<domenkozar[m]>
well I tested it
<gchristensen>
I believe you and I don't doubt your PR, but if I have a tricky time validating your PR, think about all the other PRs I closed promising it'd be easier to merge theirs :)
<domenkozar[m]>
i can merge the DONT MERGE THIS PR pr
<domenkozar[m]>
:P
<gchristensen>
lol
<domenkozar[m]>
joking aside, no hurry here really
<{^_^}>
nixops#1264 (by grahamc, 2 days ago, open): Example NixOps State Backends
<gchristensen>
just so you know how deep it goes
<aminechikhaoui>
<3 did I tell you're awesome gchristensen ?
<{^_^}>
did's karma got increased to 1
<cole-h>
lol
<aminechikhaoui>
haha
<gchristensen>
thanks aminechikhaoui :D
<samueldr>
gchristensen: opening an issue with a concern, and the commit that failed here so we can test this better
<cole-h>
gchristensen: Anything a newb like me can help with in regards to those 3 todos :^)?
<gchristensen>
sounds great, samueldr
<worldofpeace>
gchristensen++
<{^_^}>
gchristensen's karma got increased to 241
<gchristensen>
*checks list*
<gchristensen>
okay, so first I had to implement 1264, and then integrate with adisbladis' plugin PR -- this is all sorted. cole-h, sure, do you have a system deployed via nixops? (not required)
<cole-h>
Nope. Not even on NixOS yet ^^;
<cole-h>
(Planning to remedy that next week on my actual spring break)
<gchristensen>
ah, that makes it a bit trickier :x
<cole-h>
gchristensen: Well, if you have any documentation or comments that you want nitpicked, I can do that ;^)
<gchristensen>
cool :)
<gchristensen>
fwiw I was going to ask for you to make a systemd unit which started when vault-key.service started, unlock Vault using that key, and then delete it. plus a timer to delete that key if it exists, which runs every 10 minutes