worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS 20.03 BETA Announced | | | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm |
ivan has left #nixos-dev [#nixos-dev]
drakonis has quit [Ping timeout: 260 seconds]
ivan has joined #nixos-dev
CRTified has joined #nixos-dev
teto has quit [Ping timeout: 246 seconds]
<worldofpeace> Jan Tojnar: if the wayland session fails to start in gnome, it just starts the xorg session right?
<jtojnar> worldofpeace I think so
<worldofpeace> Jan Tojnar: I probably can get rid of this then, and I also realized that I added the udev rules to gdm that disables the wayland session when using nvidia
<jtojnar> not sure if it aplies to gdm greeter too, though
<{^_^}> firing: RootPartitionLowDiskSpace:
<gchristensen> nixops deploy -d buildfarm --include mac4 --force-reboot...
<samueldr> making an example out of mac4 so the other boxes behave?
<gchristensen> bingo
<gchristensen> "and don't you forget it!"
<{^_^}> resolved: RootPartitionLowDiskSpace:
<julm> :D
jtojnar_ has joined #nixos-dev
jtojnar_ has quit [Remote host closed the connection]
drakonis has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
drakonis has quit [Ping timeout: 246 seconds]
<ashkitten> gchristensen: do you know why hydra is timing out with firefox builds on aarch64?
<ashkitten> is it just taking too long?
lovesegfault has quit [Ping timeout: 256 seconds]
FRidh has joined #nixos-dev
cole-h has quit [Ping timeout: 250 seconds]
<colemickens> I finally have had the resolve to push the Azure stuff in a spot where it's demonstrably better/usable:
<{^_^}> #78827 (by colemickens, 7 weeks ago, open): nixos/azure: improve azure module, add new maintainer scripts/examples/demo
<colemickens> 7 weeks ago, but I mostly rewrote it tonight
ivan has left #nixos-dev [#nixos-dev]
kcalvinalvinn has joined #nixos-dev
kcalvinalvin has quit [Ping timeout: 260 seconds]
kcalvinalvinn has quit [Client Quit]
Jackneill has joined #nixos-dev
Guest30 has joined #nixos-dev
Guest30 is now known as ash-braker
Mic92 has quit [*.net *.split]
b42 has quit [*.net *.split]
greizgh has quit [*.net *.split]
teozkr has quit [*.net *.split]
misuzu has quit [*.net *.split]
{^_^} has quit [*.net *.split]
nh2 has quit [*.net *.split]
teehemkay has quit [*.net *.split]
jared-w has quit [*.net *.split]
cbarrett has quit [*.net *.split]
claudiii has quit [*.net *.split]
johnny101 has quit [*.net *.split]
misuzu has joined #nixos-dev
teehemkay has joined #nixos-dev
jared-w has joined #nixos-dev
teozkr has joined #nixos-dev
claudiii has joined #nixos-dev
cbarrett has joined #nixos-dev
Mic92 has joined #nixos-dev
b42 has joined #nixos-dev
greizgh has joined #nixos-dev
nh2 has joined #nixos-dev
{^_^} has joined #nixos-dev
johnny101 has joined #nixos-dev
ash-braker has quit [Ping timeout: 240 seconds]
__monty__ has joined #nixos-dev
pepesza has quit [Ping timeout: 258 seconds]
FRidh2 has joined #nixos-dev
FRidh has quit [Ping timeout: 250 seconds]
<Profpatsch> infinisil: what’s the problem with attrsets being strict in keys?
<Profpatsch> I was thinking ({ … } // { … }) ? key, but in order to find key there you still have to //
<Profpatsch> Hm, does it mean that if you do pkgs.x it has to collect every key in pkgs first and thus possibly touch a lot of files?
<Profpatsch> cc puck ^
<MichaelRaskin> Hm. To get _keys_ you need tens of files, not thousands, right?
<domenkozar[m]> btw did anyone experiment replacing glibc with musl in stdenv?
<domenkozar[m]> I guess for some things like graphical bits we'd still have to use glib
<domenkozar[m]> c
<FRidh2> domenkozar[m]: pkgsMusl ?
<domenkozar[m]> yes
clkamp___ has quit [Read error: Connection reset by peer]
justanotheruser has quit [Ping timeout: 256 seconds]
phreedom has quit [Remote host closed the connection]
phreedom has joined #nixos-dev
Guest30 has joined #nixos-dev
orivej has joined #nixos-dev
justanotheruser has joined #nixos-dev
teto has joined #nixos-dev
<domenkozar[m]> error: opening lock file '/nix/var/nix/db/big-lock': Permission denied
<domenkozar[m]> hmm, that's a new one
<{^_^}> nix#3451 (by domenkozar, 8 minutes ago, open): error: opening lock file '/nix/var/nix/db/big-lock': Permission denied
Guest30 has quit [Remote host closed the connection]
<LnL> domenkozar[m]: can you reproduce that?
<domenkozar[m]> you mean to provide a docker image that reproduces it?
<LnL> ah no that's not the profile one
<domenkozar[m]> the 755 error?
<domenkozar[m]> this one?
<{^_^}> 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, 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
<gchristensen> puck: are there any?
<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 (could someone pick it up). In that regard, I don't think the release notes are exactly done for 20.03
<{^_^}> #80848 (by worldofpeace, 4 weeks ago, open): rl-2003: mention python driver
<MichaelRaskin> Of course there is tryEval on readFile from store — this should be uncatchable
<gchristensen> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 81
cole-h has joined #nixos-dev
justanotheruser has quit [Ping timeout: 256 seconds]
ryantm has joined #nixos-dev
abathur has joined #nixos-dev
ixxie has joined #nixos-dev
justanotheruser has joined #nixos-dev
drakonis has joined #nixos-dev
<ma27[m]> regarding the mongodb update: can somebody please take a look at this? (it's mongodb's own license)
<drakonis> ah the new license, ie: not affero gpl 3?
<ma27[m]> it's called sspl and it's created by mongodb (
<drakonis> i've heard about it
<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~
<ma27[m]> :)
<drakonis> haw
<srk> +1!
<drakonis> let people opt into using mongo
<gchristensen> I'd really like a couple Python PRs reviewed. trivial: not complicated, but a bit long: anyone able to help with that?
<{^_^}> nixops#1265 (by grahamc, 3 hours ago, open): parallel: handle exceptions more modern-like
<{^_^}> nixops#1263 (by grahamc, 1 day ago, open): script_defs: open state files and deployments with a context manager
<MichaelRaskin> simpson: Vampire-ten-years-ago-style?
<simpson> gchristensen: First reading, nothing looks wrong, and the context-manager change seems desirable.
<gchristensen> thanks, domenkozar[m]!
<gchristensen> thanks, simpson!
<ma27[m]> so we'd need some kind of redistributable flag for licenses which allows hydra to build it?
<ma27[m]> I'll leave the PR open for now, but I doubt that we can establish such a change in our licensing system before 20.03 is out
<domenkozar[m]> I've fixed the PR url without whitespace to be correct
<drakonis> merge for now
<gchristensen> oops, thanks drakonis
<gchristensen> domenkozar[m]:
<drakonis> the redistributable flag exists for nonfree
<drakonis> but hydra does not build packages with it
<ma27[m]> That's true, but Hydra doesn't build it then, right?
<ma27[m]> I'm afraid that if we merge now, everyone will have to compile their own mongodb :/
<drakonis> merge but include a warning for the install
<ma27[m]> gchristensen: or do you know if hydra builds unfree, but redistributable packages?
<drakonis> it does not
<drakonis> nvidia packages have unfreeredistributable set
<drakonis> let me check first
<infinisil> ma27[m]: drakonis:
<{^_^}> #47237 (by bhipple, 1 year ago, closed): WIP: Factoring out unfree non-redistributable vs. unfree redistributale licenses
<ma27[m]> hmm, but actually you're right: mongodb doesn't even evaluate atm because of openssl 1.0.1
<ma27[m]> so the current state is at least an improvement
<drakonis> line up a replacement for the existing package license system within two versions because this might be very necessary soon
<drakonis> this won't be the only time this becomes necessary
<drakonis> unfreeredistributable seems to include packages that are binary only but get patched?
<domenkozar[m]> hmm, is that warning an issue we should fix?
<domenkozar[m]> warning: reached FD_SETSIZE limit
<drakonis> too many files?
<gchristensen> what builder?
<samueldr> ike
<domenkozar[m]> ike
<domenkozar[m]> yeah sounds like select() hitting files limit
<gchristensen> oh ike
<gchristensen> domenkozar[m]: woohoo!
<domenkozar[m]> it seems to have succeeded
<gchristensen> domenkozar[m]: you might like to take a look at too, though don't merge it :)
<{^_^}> 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> { = {}; } <- in-memory state file
<yorick> gchristensen: I had massive performance issues around 200 machines
<yorick> it seems to evaluate a lot of them
<gchristensen> nixops#1264, nixops#1245, nixops#1265, nixops#1263, nixops#1243, nixops#1232
<{^_^}> (by grahamc, 1 day ago, open): Example NixOps State Backends
<{^_^}> (by grahamc, 2 weeks ago, open): Deploy Targets: Policy/Behavior-free Deployment Hooks (auto-rollbacks, drain events, etc.)
<{^_^}> (by grahamc, 4 hours ago, merged): parallel: handle exceptions more modern-like
<{^_^}> (by grahamc, 1 day ago, merged): script_defs: open state files and deployments with a context manager
<{^_^}> (by grahamc, 3 weeks ago, merged): `nixops deploy --test`
<{^_^}> (by grahamc, 3 weeks ago, merged): 2-to-3: Start with types
<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
<{^_^}> (by adisbladis, 2 weeks ago, open): Make it possible to use Nixops without automatic SSH key provisioning
<{^_^}> (by adisbladis, 2 weeks ago, open): WIP: Add deploy without creating a state file
<{^_^}> (by adisbladis, 1 week ago, open): RFC: Use Poetry & Poetry2nix for environment and plugin management
<srk> very nice!
Jackneill has joined #nixos-dev
<gchristensen> I'm thinking about closing all the PRs from before 2->3 and inviting people to reopen if they rebase
<gchristensen> too rude?
<srk> +1
<gchristensen> any other opinions? I don't want to be a jerk
<srk> or maybe give people some time to react/rebase before closing
<gchristensen> they can always reopen
<srk> yeah
<gchristensen> leaving them open would make it harder to see them
<MichaelRaskin> If you want visibility, comment+label sound natural way of warning
<MichaelRaskin> Then close later, I guess
<domenkozar[m]> I think people mostly get annoyed as they use PRs as todo lists
<domenkozar[m]> so suggesting to open an issue helps a bit
<gchristensen> domenkozar[m]: so are you thinking not good to close ?
<gchristensen> for me it'd be easier to close :x
<domenkozar[m]> to close but invite folks to open an issue to track "progress"
<gchristensen> ah
<gchristensen> I'll write a draft comment and share it with you
<domenkozar[m]> k
<domenkozar[m]> aha :D
<domenkozar[m]> I'd bold each important bit in each sentence for those that will skim it
<domenkozar[m]> but that's the cherry on top :)
<gchristensen> good idea
<gchristensen> domenkozar[m]: maybe you could do that for me? :P
<gchristensen> I'm not sure which ones I should bold and which I shouldn't
<domenkozar[m]> sure
<gchristensen> thanks!
<domenkozar[m]> wish gists would have an edit
<gchristensen> yeah
<qyliss> They do, don't they?
<qyliss> That's what the revisions are
<samueldr> you need to fork to edit another user's gist
<samueldr> and then I don't think there is a PR-like workflo
<qyliss> there is not
<qyliss> OTOH they are just git repos
<samueldr> yeah
<qyliss> could mail a patch
<gchristensen> please no lol
<domenkozar[m]> I removed too much apologising :P
<gchristensen> looks great, thank you :D
<gchristensen> I hate it when my PRs get closed without a good reason, so I feel it a bit close to the heart :)
<domenkozar[m]> well I agree, but this time it's a good reason
<gchristensen> :)
<domenkozar[m]> now I want to fix uploading secrets in parallel
<gchristensen> oh yes please
<domenkozar[m]> since I have like 15 and it takes longer than all the rest
<gchristensen> jeeze I'm annoyed at 7
<gchristensen> you know, run_tasks should make it trivial to do that
<domenkozar[m]> yup
<domenkozar[m]> btw I remember you had a bunch of improvements to NixOS tests to boot really fast
<domenkozar[m]> did something come out of that?
<gchristensen> hmmm
<gchristensen> I'll find it. it is when I was trying to make, with firecracker :)
<MichaelRaskin> For NixOS tests, I think even I have a PR that went nowhere
<MichaelRaskin> Or maybe a branch that I did not end up PR-ing
<domenkozar[m]> I'd appreciate any speedup as I run functional tests before deploying
<domenkozar[m]> so most of time is spent uploading keys
<domenkozar[m]> and booting NixOS :D
<MichaelRaskin> — I think this did help at least a bit (but not too much)
<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 = ""; }; 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 $@`
<domenkozar[m]> gchristensen:
<{^_^}> nixops#1266 (by domenkozar, 2 minutes ago, open): send keys in parallel
<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
<domenkozar[m]> holy crap
<{^_^}> nixops#1237 (by erikarvstedt, 3 weeks ago, open): Fix leaking secret keys: Allow defining keyFiles as strings
<gchristensen> yeah ,that is the one I'm actually looking at :)
<domenkozar[m]> I can't find them in my nix store though
<gchristensen> domenkozar[m]: I think it is a misunderstanding
<gchristensen> assuming that since ./secret is dangerous in a Nix build, that it is dangerous in a NixOps deploy
<gchristensen> which is totally fair on their part, and good to go the safe route -- but we're not doing the bad thing now
<gchristensen> ah ha!
<gchristensen> oh cool
<{^_^}> #78640 (by Infinisil, 8 weeks ago, open): Add `types.secretPath`
<samueldr> nixos-unstable is failing due to a lot of tests failing on the following
<samueldr> - Test "Assert readiness of login prompt" failed with error: "unit "nixos-manual" is inactive and there are no pending jobs"
<samueldr> without bisecting, this looks relevant
<{^_^}> #83391 (by primeos, 20 hours ago, merged): nixosTests.installer: Don't wait for the nixos-manual service
<domenkozar[m]> gchristensen: nice
<samueldr> ah, this PR likely fixes it, it didn't eval since
<gchristensen> it is a bit scary actually that a path is acceptable, since it trains people to think it might be okay to use secrets in a nixexpr
<domenkozar[m]> it does make sure that it exists
<samueldr> hydra-eval-jobs returned exit code 1:
<samueldr> warning: SQLite database '/nix/var/nix/db/db.sqlite' is busy
<samueldr> okay, database being busy is probably not relevant
* samueldr checks what's up
ixxie has quit [Ping timeout: 240 seconds]
teto has quit [Ping timeout: 240 seconds]
teto has joined #nixos-dev
<samueldr> weird!
<samueldr> hydra-eval-jo
<samueldr> bs
<samueldr> oops, bad copy
<samueldr> hydra-eval-jobs will not transmit eval errors from nix it looks like
<samueldr> 11443 write(8, "{\"error\":\"syntax error, unexpect"..., 156) = 156 # from strace
<samueldr> (might not be a nix eval error, now that I look more into it)
Jackneill has quit [Ping timeout: 240 seconds]
<samueldr> worldofpeace: any tip to help debug why b3ef282fd5c37d98b550e04c596136db8a9e978b (link would halt eval?
<samueldr> is there a test I can run?
<samueldr> reverting that commit the eval (using hydra-eval-jobs) continues as expected; luckily the issue makes it bail early
<jtojnar> samueldr oops, should have been environment.etc."rygel.conf".source
<samueldr> oh
* samueldr tries
zarel_ has quit [Ping timeout: 240 seconds]
zarel has joined #nixos-dev
tokudan has quit [Remote host closed the connection]
tokudan has joined #nixos-dev
tokudan has quit [Remote host closed the connection]
zarel has quit [Read error: Connection reset by peer]
zarel has joined #nixos-dev
tokudan has joined #nixos-dev
<worldofpeace> samueldr: ohh right, tbh we should have ran the gnome3 test
<worldofpeace> feel free to push if you've already made the change
<samueldr> errors happen, I was looking for input and not for blame :)
<samueldr> waiting on that (hopefully) successful hydra-eval-jobs first
justanotheruser has quit [Ping timeout: 256 seconds]
<samueldr> ugh, I hate pushing to master... and there I go, making a fool of myself with a typo in the commit message :|
<worldofpeace> samueldr: It's weird that the PR passed eval now that I think about it. Wouldn't it be able to catch that?
<samueldr> I don't understand the way it fails
<samueldr> or, let's say, grok it
<gchristensen> btw I read stranger in a strange land (where grok comes from) a few months ago and it was really great
<samueldr> >> error: syntax error, unexpected '=', expecting $end, at /nix/store/67ccp3dq3cbx368j3ljrg4j3salvlhsw-rygel-0.38.3/etc/rygel.conf:7:19
<samueldr> I don't think ofborg is evaluating release-combined in its entirety, only `tested` is instantiated
<samueldr> this is why it passed
justanotheruser has joined #nixos-dev
<gchristensen> after I pop 3 things from my to-do list, we can switchto hydra-eval-jobs and eval all of it
<cole-h> Which 3 todos might those be?
<gchristensen> I wrote so I could do this
<{^_^}> 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
<samueldr> opened ofborg#440
<{^_^}> (by samueldr, 12 seconds ago, open): Evaluate using hydra-eval-jobs
<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
<gchristensen> probably the easiest way to do this is with the HTTP API and curl
zarel has quit [Ping timeout: 250 seconds]
abathur has quit [Ping timeout: 240 seconds]
<gchristensen> you may be able to write it without a NixOS system to test it, actually :)