LnL has quit [(Quit: exit 1)]
LnL has joined joined #nixos-dev
mbrgm has quit [(Ping timeout: 240 seconds)]
mbrgm has joined joined #nixos-dev
adisbladis has quit [(Remote host closed the connection)]
adisbladis has joined joined #nixos-dev
MichaelRaskin has quit [(Quit: MichaelRaskin)]
goibhniu has joined joined #nixos-dev
<zimbatm> any1 wants to co-manage the talks with me at nixcon?
<zimbatm> presenting people and doing the time nazi
<zimbatm> not sure if I sell this properly :p
goibhniu has quit [(Remote host closed the connection)]
goibhniu has joined joined #nixos-dev
<gchristensen> zimbatm: what does it involve? is there like a timer-ipad timer-cards about how much is left?
<zimbatm> yeah some sort of time-tracking system would be helpful
<zimbatm> the role is to keep the conference on track
<zimbatm> so it means intro-ing the people before the talk, let them speak for a while
<zimbatm> 5 minutes before the end, notify them that they need to wrap things up
<zimbatm> then be rude and interrupt people if they're going over time
<zimbatm> then give some time for the questions
<zimbatm> sprinkled with some jokes if you feel like it :)
<zimbatm> we also might have to announce stuff like when is lunch time, if there are any changes of plans, ...
<gchristensen> I think it might be good for me, to wear down some of the stage fright before my talks :P
<zimbatm> cool! we're all quite friendly you'll see :)
<zimbatm> thanks a lot for helping out, I wasn't looking forward to do that for 2 days straight
<goibhniu> on the plus side ... you get to smash the gong :D
<gchristensen> no!
<zimbatm> gchristensen: are you going to be at the workshop too?
<gchristensen> mon/tue?
<goibhniu> could you both also help out with clipping the mic to people?
<goibhniu> ... and getting people hooked up to the projector etc.
<goibhniu> actually, I'll ask on #nixos, it would be good to have extra help there
<gchristensen> yeah
<gchristensen> also ... we're going to have a bunch of nixos users plugging in nixos laptops to present. how well does nixos handle this? :)
<goibhniu> really well IME
<gchristensen> what DE/etc?
<goibhniu> but we'll probably need everything-to-HDMI adapters
<goibhniu> yeah, if they're not using a DE, they'll need to know some xrandr commands
<gchristensen> I might switch to gnome for the day :P
<goibhniu> perhaps there's a generic enough xrandr command we can keep handy, I'm not familiar with that stuff myself
<gchristensen> niksnut: (friendly bump to check your PMs)
<clever> gchristensen: my nixos desktop (amd graphics) will lock xorg up solid if i unplug any hdmi display
<clever> i have to turn it off via the gui before i unplug it
<clever> but it also re-enables itself upon being plugged in
<gchristensen> hilarious ...
<clever> so its very risky to go near those cables
<goibhniu> oh gosh
<clever> any contact bounce when plugging in it, and it might enable itself, come unplugged, and crash
<clever> and i think the open source driver will just crash instantly upon enabling dual-monitor setup
<goibhniu> at the last NixCon there were hardly any issues at all
<clever> but xfce saves the config before applying, so when you relog, it re-crashes
<goibhniu> I think one person had trouble
<clever> goibhniu: i'm also reminded of a defcon talk, where they where talking about pci-e DMA attacks and how thunderbolt does pcie+hdmi
<clever> goibhniu: and at the end of the talk, they show how you can cut up a thunderbolt->hdmi adapter, and put the peices around a normal thunderbolt cable, that leads to an external pcie box
<clever> goibhniu: so the "dumb hdmi adapter" is actualy a full thunderbolt cable, able to do dma
<clever> oh, and they left it at the podeium lastnight, and have ram dumps from the previous presenter :P
<gchristensen> clever: I do have a soft spot for video standards which also come with full arbitrary memory access
<clever> gchristensen: its more that they tried to multi-purpose the port, but you can use a passive adapter to strip out just a dumb hdmi signal
<gchristensen> I know :)
<gchristensen> but use-case-specific cables are a good thing I think
<clever> gchristensen: and its trivial to glue the pieces of an adapter around a cable to fool even defcon presenters
<clever> which reminds me of something ive done before, that could help detect this
<clever> many years ago, i had setup udev rules to run "beep" with different beep counts and freq, based on various events
<clever> certain usb devices coming online
<clever> the wpa coming up/down
<clever> cron, just to give hourly chimes
<gchristensen> til `beep`
<clever> you could just add another, to alert you to pci devices being hot-plugged
<goibhniu> fascinating!
<clever> the 'beep' program will poke at the motherboard speaker
<clever> though modern hardware may not really support it anymore
<clever> but it gives you a lot more control then "tput bel"
<gchristensen> gotta make a kernel driver that creates a hardware speaker and just pipes to also
<gchristensen> gotta make a kernel driver that creates a hardware speaker and just pipes to alsa
<clever> bel doesnt even make a noise on my machines
<clever> gchristensen: there already are some drivers that do that
<clever> gchristensen: i also did something else, to keep the beeps from anoying my dad
<clever> gchristensen: i programmed the system to beep at 20khz, whenever my name was said on irc
<clever> my dad couldnt hear it :P
<gchristensen> >.>
<clever> it was practically a phycic link, lol
<clever> i can hear things nobody else can
<clever> [root@eeepc2:~]# nix-shell -p beep
<clever> these paths will be fetched (32.28 MiB download, 112.95 MiB unpacked):
<clever> /nix/store/8kz8y0s4siqv8hvqy9p6c45wnvy5ql0p-bootstrap-tools
<clever> gchristensen: also, its strange that a normal shell depends on the bootstrap
<gchristensen> it didn't for me
<clever> oh, interesting, the netbook lacks any alsa devices
* clever scratches head, its not in lspci
<gchristensen> beep should be setuid
<clever> yeah
<gchristensen> man beep -> IOCTL WACKINESS is a good read
<clever> oh, wait
clever is now known as clever-afk
__Sander__ has joined joined #nixos-dev
<__Sander__> whoa
<__Sander__> never underestimate the power of "separation of concerns"
<__Sander__> just overhauled the entire internal structure of node2nix
<__Sander__> with the new design it is a lot easier to get a grasp on the generation process
<__Sander__> now a couple packages that always used to fail now succeed
<__Sander__> due to some odd corner cases with bundled dependencies that I previously could not detect
<fadenb> May I print those 6 lines, frame them and hang them in the office of some of our developers? :P
<__Sander__> sure :D
<__Sander__> I guess I should also this here :D
<__Sander__> but convincing my boss to take 3 weeks restructuring one of our company projects is quite hard
<__Sander__> hard
<__Sander__> impossible I would say :D
<copumpkin> niksnut: if I run a nix-instantiate with -vvvvv it tells me stats at the end with "time elapsed: 5.1884" but under the time program, total time is 52s. I'm guessing the rest is writing out .drvs or something? Feels awkwardly slow for something comparatively straightforward but I'm not sure how to track it down
goibhniu has quit [(Remote host closed the connection)]
goibhniu has joined joined #nixos-dev
<gchristensen> there seems to be a steady-state rate of events on nixos/nixpkgs at one event every 10 seconds
jtojnar has quit [(Quit: jtojnar)]
__Sander__ has quit [(Quit: Konversation terminated!)]
zarel has joined joined #nixos-dev
Sonarpulse has joined joined #nixos-dev
Sonarpulse has quit [(Quit: Leaving)]
Sonarpulse has joined joined #nixos-dev
clever-afk is now known as clever
<clever> gchristensen: thats a lot more then i would have expected
<gchristensen> I might be misinterpreting the data
<gchristensen> I'll have better info in ~a while
<clever> copumpkin: there is also the round-trip times when it has to ask nix-daemon over the unix socket, and wait for sqlite db changes
<copumpkin> yeah
<copumpkin> probably not major factors though
<copumpkin> is there a way to ask for build-use-sandbox=true, but with networking exceptions (temporarily while I develop something)?
<clever> copumpkin: there is a relaxed mode
<copumpkin> I thought that only affected how it behaved with individual derivations requesting exceptions
<copumpkin> at least that's how it is on macOS
<clever> copumpkin: yeah, if you set build-use-sandbox = relaxed, then a build can request that the sandbox just be turned off
<copumpkin> yeah, I don't want it off
<copumpkin> I care about local access but not networking 😇
<clever> copumpkin: what kind of access are you doing?
<copumpkin> a build that wants to retrieve some JVM dependencies that I haven't written a wrapper for yet
<clever> ah
<clever> maven? gravel?
<copumpkin> anyway, not a huge deal
<copumpkin> maven/ivy
<copumpkin> I have a fetchIvy and such
<copumpkin> but it's not quite ready yet
<clever> copumpkin: i also have a fake maven cache
<copumpkin> yeah that's what my thing is doing :D
<clever> it uses buildenv to merge together many fetches into a single cache
<copumpkin> although mine is for ivy
<copumpkin> the buildenv works cleanly for the maven cache? I assumed it would need to manipulate some stuff
<copumpkin> but that's cool
<clever> copumpkin: https://github.com/mcpkg/mcpkg-server/blob/master/default.nix#L36 is where i generate each input to the buildenv
<copumpkin> the merging is the thing that's missing from my ivy one, but I think I'll have it soon
<clever> that is the artifactid, version, and sha256 of every single dependency in the closure
<clever> all manualy typed in....
<copumpkin> ouch :) mine is autogenerated
<clever> this function then inspects the deps listed on each entry, and figures out the actual closure
<copumpkin> cool, I'll see if I can steal some of your stuff.
<copumpkin> have you considered putting versions of it upstream?
goibhniu has quit [(Ping timeout: 240 seconds)]
<clever> copumpkin: this was an incomplete mess that could barely build a single minecraft mod
<clever> and its missing the code to inspect the deps of a gradel project and auto-generate the data
<copumpkin> oh I see, you're downloading it yourself over http
<clever> yeah
<clever> and i didnt fully understand how those mirrors worked
<copumpkin> I'm actually invoking ivy in mine to download stuff for me
<clever> so i just brute-force every url i saw gradel grabing
<copumpkin> so I don't have to understand much of the annoying shit
<clever> and i ignore any failures
<copumpkin> hah
<copumpkin> ok :)
<clever> and then the files are in the right directory structure, for gradle to be happy
<clever> there is no index
<clever> $out/repository/$DIR2/${filename}.pom
<clever> $out/repository/$DIR2/${filename}.jar
<clever> $out/repository/$DIR1/maven-metadata.xml
<copumpkin> I see, yeah
<copumpkin> I think ivy can populate that for you btw
<copumpkin> I'll see when I finish getting mine working
<copumpkin> it might simplify things a lot
<clever> copumpkin: there are also a couple custom fetch routines in MC mods, that just try to download things directly and not use maven
<copumpkin> sh
<copumpkin> ah
<clever> copumpkin: but they do cache things locally, and nix can populate those caches to trick it: https://github.com/mcpkg/mcpkg-server/blob/master/root.nix#L42-L45
<clever> so this tricks the build system into thinking a previous build downloaded those files
<copumpkin> I see, yeah
<copumpkin> that's basically exactly what I do with ivy
<copumpkin> it has a cache dir
<copumpkin> and my nix unit of distribution (the $out) is the cache dir
<clever> i was mostly going for generating that cache directory in a pure manner, and only including the required closure
<clever> so multiple things could build seperately
<copumpkin> yup
toogley has left #nixos-dev ["WeeChat 1.9.1"]
<copumpkin> is a single-file nar (at the top level) equivalent to the file itself? or is there a header that always gets applied?
MichaelRaskin has joined joined #nixos-dev
<Dezgeg> how would you prevent confusing a multi-file nar in the nix store then?
<Sonarpulse> niksnut: can you review https://github.com/NixOS/nixpkgs/pull/30549 ?
Jackneilll has joined joined #nixos-dev
Jackneill has quit [(Ping timeout: 255 seconds)]
<niksnut> Sonarpulse: sorry, not much time to review stuff this week
<Sonarpulse> niksnut: fair enough
<clever> copumpkin: a nar containing a single file still has a header, stating that the entry is of type file, and its length
<clever> copumpkin: but there is no name attached to that entry
<Sonarpulse> nixcon and the hackathon is just around the corner, I suppose
<copumpkin> I see, makes sense
<copumpkin> Sonarpulse: I forget, are you coming?
<Sonarpulse> copumpkin: yes!
<copumpkin> yay
<Sonarpulse> niksnut: but if you feel confortable signing off on the idea, all it does is add a stdenv.cc.bintools = binutils, and use that instead of binutils directly in a bunch of places
<Sonarpulse> since on darwin we aren't actually using real binutils
<clever> copumpkin: also, 2017-02-22 22:23:23< clever> $ nix-store --dump a | nix-store --restore b
<clever> copumpkin: this will copy a -> b, recursively (if needed)
<clever> copumpkin: you can also just pipe it into hexdump -C to inspect the format, and store it to a file or pipe thru ssh to implement scp
<clever> echo -n "content" > example.txt ; nix-store --dump example.txt | hexdump -C
<clever> copumpkin: when i run this, i can see a "nix-archive-1" tag, a ( and ) marking the borders of a single entity, type=regular, contents=content
<clever> copumpkin: each string is in the form of a length prefix, followed by the string, and some padding to ensure all fields start on an 8 byte boundary
<clever> and pairs of strings form key=value pairs
<clever> the contents of the file are just a single "string" that follows the contents string
<MichaelRaskin> (while building a package with non-default builds of boost, boehmgc and clang as dependencies) I wonder if it is a good idea to have some kind of boost.static, boehmgc.static and clang.with-rtti on the top level.
<clever> copumpkin: and if your wondering how i can read this hex, ive written a parser for nar from scratch in haskell
<copumpkin> hah :)
<clever> copumpkin: i originally wrote a c++ fuse layer, that would take a directory full of <hash>-<name>.nar and make it look like it had been unpacked to /nix/store/, this version used the nix library to parse the NAR's: https://github.com/cleverca22/fusenar
<clever> copumpkin: but the problem, is that you have to parse the entire entity, including the ) at the very end of the file, to even know if the nar represents a file or directory
<clever> so "ls -l /nix/store" winds up parsing every single byte of every single store path
<clever> i then redid the entire project in haskell with taktoa's help: https://github.com/taktoa/narfuse
<clever> so it can take advantage of lazy evaluation to stop once it has found a type=regular field
<Profpatsch> Do we have a module system geek here?
<Profpatsch> shlevy, can I show you a WIP?
<copumpkin> yeah, not the most pleasant file format to parse incrementally
<clever> Profpatsch: ive gone so deep into the module system, ive made my own distro using the module system
<Profpatsch> The idea is to finally introduce support for tagged unions (aka sum types).
<clever> Profpatsch: line 11 of the 2nd gist lacks a ;
<Profpatsch> Yeah, that hasn’t run yet.
<Profpatsch> Oh, and int.between is in this patch, so I’ll have to rebase on that first https://github.com/NixOS/nixpkgs/pull/27965
<Profpatsch> clever: Oh, sorry, that was an old version of that harddrives module
<Profpatsch> I’ve updated the gist
<Profpatsch> clever: Give me a few minutes, I’ll rebase some stuff first.
<clever> Profpatsch: so the default of low = {}; would just pick some value between 0 and 127 as a default?
<Profpatsch> clever: Right, that’s the problem I have.
<Profpatsch> I want that to not type check.
<Profpatsch> Because the type of low is int
<Profpatsch> or int.between a b
<Profpatsch> But I’m not sure where the recursive type checks are invoked and the internal documentation is horrible.
<Profpatsch> It’s akin to listOf
<clever> ahh
<clever> Profpatsch: and about the merge thing you mention on 295 of the first link
<clever> Profpatsch: i cant remember which option right now, but there is a "boolean" option in nixos, that lacks a proper type setting
<clever> and the default merge when bools are found, is to just or them together
<clever> so setting it to true in one file, and false in another, will silently ignore the false
<Profpatsch> clever: Default bool has mergeEqualOption
<clever> when no type is set at all
<clever> this is the merge operator when you forget to set any type
<Profpatsch> phew
<Profpatsch> ouch
<Profpatsch> The correct way would be to use Semigroups/Monoids for merging, but that kinda works too, I guess?
<Profpatsch> clever: Do you know how listOf/attrsOf invoke type-checking their arguments recursively?
<Profpatsch> because their check methods are just one layer deep.
<Profpatsch> aka isAttrs/isList
<clever> eek!
<Profpatsch> I understand the reasoning, you’d lose the position information otherwise.
<Profpatsch> You want to propagate that for submodules.
<Profpatsch> That’s another thing I’m not sure of, how taggedUnion should play with submodules; submodules are a kind of more powerful tuples.
<clever> Profpatsch: listOf passes the type to mergeDefinitions
<Profpatsch> So when you put a submodule inside a taggedUnion, you get an ADT.
<copumpkin> we have a taggedUnion type?
<clever> and mergeDefinitions doesnt make use of that type field
<clever> wait
<copumpkin> I had a hacked proposal for one ages ago
<copumpkin> but I can't find it now
<clever> line 340, is indented more
<clever> Profpatsch: line 340, i think it will call the sub-type check as it merges the values
<clever> so type.listOf type.int will call type.int.check on each entry in the list
<copumpkin> I'd love types.taggedUnion to take an attrset of "constructors", and types.sigma to take a function ;)(
<Profpatsch> copumpkin: I’m in the process of creating one.
<copumpkin> types.taggedUnion might be expressed in terms of types.sigma :) :)
<Profpatsch> copumpkin: sigma?
<copumpkin> sweet
<copumpkin> I don't know where mine went
<copumpkin> Profpatsch: dependent sum!
<MichaelRaskin> And then at some point module system's type system will reach Turing completeness.
<Profpatsch> YES, EXACTLY. :DD
<gchristensen> please god no
<Profpatsch> MichaelRaskin: Well, it already is turing complete.
* gchristensen cries
<Profpatsch> We basically got dependent types already.
<Profpatsch> In a very crude way, but yes.
<copumpkin> types.sigma would just take an arbitrary function instead of an attrset :)
<Profpatsch> copumpkin: Do you have an example?
<Profpatsch> Maybe we can add it later if it’s needed.
<LnL> gchristensen: :p
<copumpkin> it wouldn't necessarily be enumerable
<copumpkin> the enumerable version is types.taggedUnion
<Profpatsch> But no idea if that can be sensibly integrated in the existing module system.
<Profpatsch> I’m not sure with taggedUnion to be honest.
<Profpatsch> But I know that we need it direly.
<copumpkin> Profpatsch: it's just a trivial generalization of what you have, really. Instead of looking up the "tag" in the attrset, you'd just apply the function to it. This would let you construct as a contrived example, a listOfSize type, for example
<copumpkin> not that it's a particularly enjoyable one :)
<Profpatsch> I suspect that would make error messages abysmal?
<copumpkin> it doesn't have to, but yes it could
<copumpkin> anyway, don't let me distract you from the more useful on e
<copumpkin> just figured it wouldn't be much more work given this
<Profpatsch> hehe
<copumpkin> it seems good to explicitly separate the tag name from the "body" though
<Profpatsch> You can always insert it later and retroactively use it to implement taggedUnion.
<copumpkin> to avoid field overlap confusion
<copumpkin> yeah, I might do that
<copumpkin> "teach Agda via Nix"
* copumpkin runs
<Profpatsch> copumpkin: What do you mean by field overlap?
<Profpatsch> My current idea is to implement values of a taggedUnion as { tag = value; }
<copumpkin> like if my tag is called "foo" and the submodule in question also defines foo
<clever> Profpatsch: oh, do you know how to inspect the options tree of the module system?
<Profpatsch> Hm, then it’d bee foo.foo, right?
<clever> [root@amd-nixos:~]# nix-repl '<nixpkgs/nixos>'
<clever> nix-repl> options.nix.extraOptions.declarations
<clever> [ "/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/services/misc/nix-daemon.nix" ]
<clever> nix-repl> options.nix.extraOptions.definitions
<clever> [ "build-extra-platforms = armv7l-linux secret-key-files = /etc/nix/signing.sec " ]
<Profpatsch> Ah, screw that, you of course have to match first.
<copumpkin> Profpatsch: I dunno, maybe I'm misunderstanding
<Profpatsch> So you have a type Foo = Bla | Baz Int
<copumpkin> Profpatsch: oh I see
<Profpatsch> The type is `foo = taggedUnion { bla = unit; baz = int }`
<Profpatsch> the values can be
<copumpkin> I was thinking of putting the tag next to the value
<Profpatsch> { bla = {}; }
<copumpkin> otherwise you end up with off = ???
<Profpatsch> and { baz = 42; }
<copumpkin> yeah I guess
<copumpkin> probably fine, although it's not quite as flexible as I was hoping
<Profpatsch> I chose to use {} as type of union
<clever> what about allowing strings
<copumpkin> e.g., a lot of existing modules have options that don't make sense if other options are defined
<copumpkin> it would be nice to retrofit some of this into it
<clever> so you can do { baz = 42; } or just "off" by itself
<Profpatsch> In the vain of how dhall does union.
<Profpatsch> copumpkin: Uh, not sure if that can be done.
<copumpkin> why not?
<copumpkin> that's what my lost version was doing
<Profpatsch> e.g. in my example, advancedPower can be off | low int | high int
<Profpatsch> And there will be another option named spinDownTimeout, that depends on advancedPower to be some low value.
<Profpatsch> So I’d just use assertions to implement these invariants.
<Profpatsch> Maybe there’s a better way?
<copumpkin> hmmm, assertions where? It doesn't seem like assertions should be needed
<Profpatsch> s/how dhall does union/how dhall does unit/
<Profpatsch> copumpkin: well, those should be different options.
<Profpatsch> Types are only checked per option.
<copumpkin> anyway, I'm basically just saying allow me to pass field controlling which field is passed in
<Profpatsch> copumpkin: Do you have an example?
<Profpatsch> clever: Hm, that would lose the uniformity.
<Profpatsch> And probably add a lot of special casing and bad error messages?
<copumpkin> { config, ... }: let options = { oink = ...; woof = ...; meow = ...; }; in { options = { foo = types.int; bar = types.enum [ "oink" "woof" "meow" ]; baz = types.submdule options.${config.bar}; }
<copumpkin> not sure if that's clear, sorry :(
<copumpkin> I think that would work today if you didn't force it too hard
<copumpkin> I'm basically just saying to make that more of a first-class thing
<copumpkin> it seems like both approaches are nice in different ways though
* copumpkin shrugs :)
<Profpatsch> copumpkin: Ah, you cannot use config inside options, that will always lead to an infinite recursion atm.
<copumpkin> ah yeah, would need to be deferred a bit
<Profpatsch> And I’m not deep enough into the module system (or dependent types ftm) to say if that could be avoided.
<copumpkin> but that's the shape of thing I'm talking about
<Profpatsch> Probably a nice idea for a small research project. ;)
<Profpatsch> clever: Ugh, yet another wtf moment from types.nix
<Profpatsch> Why does listOf copy half of the implementation of mergeDefinitions, including the error message. Ugh.
<copumpkin> copying and pasting code 4 life
<Profpatsch> The code is just so bad. :(
JosW has joined joined #nixos-dev
<Profpatsch> There is no flow, no reasonable line breaks, no lets, I have no idea what these four lines do.
<Profpatsch> And you have to jump all over the place.
<Profpatsch> The last line is especially jarring.
<Profpatsch> Someone loves lisp it seems. :)
goibhniu has joined joined #nixos-dev
<Profpatsch> Well, if they loved lisp they know how to indent stuff. Hrm
<LnL> heh, maybe that's why I'm so pedantic about indentation
JosW has quit [(Quit: Konversation terminated!)]
zarel has quit [(Quit: Leaving)]
<Profpatsch> listToAttrs (mapAttrsToList
<Profpatsch> (n: def': { name = n;
<Profpatsch> Excuse me? AHAHAHAHAHA
<Profpatsch> That’s inside the attrsOf merge definition.
<Profpatsch> Is it a bad joke? Or a speed optimization of some kind?!
taktoa has joined joined #nixos-dev
<Profpatsch> Then of course there’s that
<Profpatsch> in mapAttrs (n: v: v.value)
<Profpatsch> (filterAttrs (n: v: v ? value)
<Profpatsch> which just seems like a waste. Why don’t all attributes have a value?
<copumpkin> maybe a PR refactoring it would be nice!
<Profpatsch> Yeah, thinking about it.
<Profpatsch> I’ll have to expand that stuff manually and see what leads to shorter code.
<Profpatsch> So much yak shaving.
<Profpatsch> How can a function like mergeDefinitions even exist without documentation in a weakly typed language like nix.
<Profpatsch> Why would it be merged.
<LnL> wasn't there a nix-build --hash in 1.12?
<shlevy> Profpatsch: Sure, what's up?
goibhniu has quit [(Ping timeout: 240 seconds)]
goibhniu has joined joined #nixos-dev