gchristensen changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | 18.03 release managers: fpletz and vcunat
Sonarpulse has quit [Ping timeout: 246 seconds]
Synthetica has quit [Quit: Connection closed for inactivity]
Lisanna has joined #nixos-dev
<dtz> shlevy: YAY glibc 2.27 and binutils 2.30 \o/
pxc1 has joined #nixos-dev
pxc1 has quit [Client Quit]
pxc has quit [Quit: WeeChat 2.0]
pxc has joined #nixos-dev
mbrgm has quit [Ping timeout: 240 seconds]
mbrgm has joined #nixos-dev
pxc has quit [Ping timeout: 246 seconds]
<dtz> Sonarpulse: probably of interest, WIP: https://github.com/NixOS/nixpkgs/issues/37522
pxc has joined #nixos-dev
orivej has joined #nixos-dev
<catern> if anyone is interested in radical ideas about the future of nixpkgs, take a look at https://git.io/vxcGi where I sketch out something I think would be neat
<catern> (clear clickbait)
bgamari- has quit [Ping timeout: 276 seconds]
<dtz> ^_^
bgamari has joined #nixos-dev
bgamari has quit [Ping timeout: 268 seconds]
ma27 has joined #nixos-dev
jtojnar_ has joined #nixos-dev
ma27 has quit [Ping timeout: 245 seconds]
jtojnar has quit [Read error: Connection reset by peer]
jtojnar has joined #nixos-dev
jtojnar_ has quit [Ping timeout: 240 seconds]
bgamari has joined #nixos-dev
bgamari has quit [Ping timeout: 264 seconds]
Lisanna has quit [Quit: Lisanna]
bgamari has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
pie_ has quit [Ping timeout: 264 seconds]
pxc has quit [Quit: WeeChat 2.0]
jtojnar_ has joined #nixos-dev
jtojnar has quit [Read error: Connection reset by peer]
jtojnar_ is now known as jtojnar
pie_ has joined #nixos-dev
davidlt_ has joined #nixos-dev
davidlt__ has quit [Ping timeout: 256 seconds]
davidlt_ is now known as davidlt
pie_ has quit [Ping timeout: 240 seconds]
MichaelRaskin has quit [Quit: MichaelRaskin]
pie_ has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
_rvl_ has quit [Quit: ZNC 1.6.5 - http://znc.in]
_rvl has joined #nixos-dev
ma27 has joined #nixos-dev
ashgillman has joined #nixos-dev
ashgillman has quit [Ping timeout: 256 seconds]
ashgillman has joined #nixos-dev
__Sander__ has joined #nixos-dev
pie_ has quit [Ping timeout: 256 seconds]
jtojnar_ has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar_ has quit [Ping timeout: 240 seconds]
goibhniu has quit [Ping timeout: 260 seconds]
pie_ has joined #nixos-dev
jtojnar has joined #nixos-dev
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-dev
jtojnar has quit [Ping timeout: 264 seconds]
julm has quit [Ping timeout: 265 seconds]
julm has joined #nixos-dev
<shlevy> Nooooo
<shlevy> fetchGit :P
<domenkozar> wat? :)
<shlevy> domenkozar: In response to catern's proposal
<shlevy> Which I haven't read yet beyond noting it suggests submodules :P
<niksnut> we should just have a giant monorepo containing the source code of all packages :p
<Mic92> With a fuse for git and memcached for caching.
<domenkozar> I'm sure this was posted before - weekend reading: Build Systems a la Carte https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems-5ab0f42d0f937.pdf
<domenkozar> I think it's a bit unfair not to include Nix, although it was considered :)
<Mic92> is nix a build system?
<domenkozar> basically they said IFD is monadic but we're not there yet
<domenkozar> which is true :)
<shlevy> :D
<shlevy> Nice to be validated by SPJ
<domenkozar> I just skimmed the paper
<domenkozar> but it's good stuff
<domenkozar> they are planing to write another build system incorporaing all current ideas
<domenkozar> combining cloud (what they refer to our binary cache)
<domenkozar> dynamic dependency handling
<domenkozar> etc
Synthetica has joined #nixos-dev
<michaelpj> hmph, I told him to put Nix in, but maybe it was a bit close to the deadline
<michaelpj> quite right that you don't get monadic tasks without IFD
<shlevy> (or recursive nix ;) )
<shlevy> gchristensen: Another SDL hang :( https://hydra.nixos.org/build/71402813
<gchristensen> hmm
<dtz> Sonarpulse: whoa I recognize these commit authors: https://github.com/ghc/ghc/commits/master/configure.ac xD
Profpatsch is now known as fluktusduktus3
fluktusduktus3 is now known as fluktusduktusr3
fluktusduktusr3 is now known as Profpatsch
<domenkozar> lol
<domenkozar> I can still claim ghc depends on perl
<catern> niksnut: that is effectively what my proposal is :) except my proposal actually scales
<gchristensen> it massively scales the "pain because of git submodules' UX" though
<shlevy> :D
<catern> yes, very true ¯\_(ツ)_/¯
<gchristensen> I think a nice thing about nixpkgs as a repo is it doesn't use many of git's features
<niksnut> is it scalable though? if every package uses this, it means having tens of thousands of submodules
<niksnut> not sure how well git will behave with that
<catern> (I definitely agree that having to deal with submodules is worse than having a single repository, but my work heavily uses submodules to scale the volume of code and though I hated it at first, I now find it not *too* bad. (that is ultimately what inspired this proposal))
<shlevy> Do we actually *want* submodules though?
<catern> niksnut: yeah, that scales just fine - we have ~2500 submodules in our monorepo at work
<niksnut> ok
<shlevy> It seems like we just want a) a declarative way to specify what we depend on (fetchGit works fine) and b) an easy way to check them out and make changes
<shlevy> Why not build tooling on top of what we have that doesn't require all the gymnastics submodules have to do to make it look like one tree but not really one tree etc.?
<gchristensen> I do not want submodules
<niksnut> right, I recall guix has an easy way to override sources (something like --with-source /my/sources), Nix should have something like that
<shlevy> +1. They've been a huge pain in every project I've used them on
<shlevy> To be clear, I'm not opposed to solving this problem. I just think we can do better than submodules.
<gchristensen> same
<domenkozar> +1 for not using submodules
<catern> shlevy: yes, I am not saying submodules are a perfect solution or even a good one, although I do think they have an undeniable architectural elegance
<catern> (though their UX sucks)
<catern> architectural elegance for this use case, I mean
<gchristensen> shlevy: ok I tried again to get mac1 to use Nix 2.0 for the daemon via nix-darwin. hydra says it mac1 is down, possibly because it lost too many connections to it during my attempts. let's keep an eye, and if mac1 comes online and starts building I'll scale out to a few more macs.
<shlevy> gchristensen: Is the SDL issue a mac versioning thing?
<catern> (and you don't need any new tooling to use them)
<gchristensen> shlevy: I have no real idea about darwin stuff, other than I have nix-darwin and I know how to use it sorta.
<shlevy> OK
<shlevy> niksnut: Shouldn't hanging builds be killed eventually?
<LnL> shlevy: I don't remember what the actual issue with sdl-config is, in the "fixed" builds we just skipped it IIRC
<niksnut> yes, eventually
<shlevy> How long?
<niksnut> dunno, 2 hours I believe
<shlevy> OK, so 1day 7 hours is definitely over the limit? :D https://hydra.nixos.org/build/71402813
<shlevy> Is that because the Nix there can't catch POLLHUP?
<gchristensen> w00t mac1 is back in rotation.
<niksnut> yeah I had disabled it, sorry about that
<gchristensen> oh ok no worries :)
<gchristensen> I'm glad I didn't break it
<niksnut> shlevy: in principle that shouldn't matter
<niksnut> timeouts are implemented by the local nix, not hydra
<shlevy> Hmm OK
davidlt_ has joined #nixos-dev
<niksnut> sadly, apple's developer hostility makes it hard to debug these issues
<shlevy> :( yeah
davidlt has quit [Ping timeout: 240 seconds]
<niksnut> killing the conftest makes the build continue
<shlevy> amazing
goibhniu has joined #nixos-dev
<niksnut> I need to disable mac1 for a bit again
<gchristensen> ok niksnut, I'm experimenting on mac3
<shlevy> I'm too fundamentally impatient to be a stdenv hacker
<shlevy> llvm building for 45 minutes and only at 15% :'(
<gchristensen> you need faster single-core performance
<gchristensen> like a time-traveling debugger but for compilation
goibhniu has quit [Ping timeout: 240 seconds]
<gchristensen> OK mac3 looks healthy on Nix2, thank you a lot LnL for your help. trying mac4 now!
<niksnut> okay, the timeout issue was caused by "NIX_REMOTE=daemon" in ~/.ssh/authorized_keys
<shlevy> Ah
<shlevy> So it *is* the POLLHUP issue?
<niksnut> no
<LnL> \o/
<shlevy> Or are timeouts not forwarded?
<niksnut> it's that nix-store --serve doesn't propagate timeouts to the daemon
<shlevy> Ah
<gchristensen> niksnut: so that is being added by the nix-darwin deploy tool I have. should I drop that env var? (cc LnL whom I got that from)
<niksnut> since the daemon connection is established before it gets the timeouts from the client
<shlevy> Should we switch to ssh-ng?
<niksnut> gchristensen: yes, it's unnecessary / inefficient to use the daemon
<shlevy> OK
<gchristensen> ok, dropping!
<LnL> gchristensen: niksnut: should it be using nix-daemon --stdio?
<niksnut> that will probably create all sorts of new and exciting problems
<LnL> my setup doesn't use root for the build user so that's why I have it in there
<shlevy> :)
<shlevy> Nothing like dogfooding to expose our bugs
<LnL> shlevy: build-remote now works with ssh-ng?
<shlevy> Yep
<LnL> nice!
<shlevy> LnL: (that's nix-daemon --stdio ;) )
<LnL> I can enable that on my setup for a while and see if I run into issues
<LnL> ah right, I remember needing it for something with 1.12 :)
<gchristensen> niksnut: how does this look: command="NIX_SSL_CERT_FILE=/nix/store/5kkw217xqighkdh0y4bl9wk8j42ixsbq-nss-cacert-3.34.1/etc/ssl/certs/ca-bundle.crt /nix/store/2jlsrxmx8h64iwss2yhjrf0skafgfmc9-nix-2.0/bin/nix-store --serve --write" ssh-rsa...
<niksnut> gchristensen: it's probably not a good idea to put store paths in authorized_keys since it's not a GC root
<niksnut> better to use /nix/var/nix/profiles/default/bin/nix-store
<Profpatsch> There is an RFC on Rough Consenus btw https://tools.ietf.org/html/rfc7282
<Profpatsch> Which could be a template on how Nix RFCs / Pull Requests can/should be handled.
<gchristensen> the contents of the authorized_keys is from /etc/static which is part of a GC root, niksnut
<gchristensen> I could switch over to the default profile, it'll take some work to make nix-darwin handle that nicely
<LnL> I think you could use /run/current-system/sw/etc/... if you add it to systemPackages but that's kind of weird
<gchristensen> I worry about getting out of Eelco's comfort zone here :)
<LnL> but if you don't remove the default profile cacert will be in there, just might be a bit older
<shlevy> Profpatsch: reading now, one thing it seems like we're missing is a chair who makes the call on whether objections are addressed/small enough to move past them
<Profpatsch> shlevy: I don’t think rough consenus requires a chair; or for parts of the infrastructure the “chairs” are the people who built/maintain these parts.
<shlevy> Profpatsch: The problem I've seen is that it is rarely if ever clear who even gets to say when we have or haven't reached consensus, who is driving toward consensus, etc.
<Profpatsch> But an awesome thing about rough consenus is that it’s organic and the results of a decision should be obvious by reading through the discussion and knowing about how rough consenus works.
<gchristensen> niksnut: I think this should work okay, but I think you're right about using the default profile longer term. in the interest of getting Nix2 on all the macs I'm going to go ahead and finish it unless you strongly disagree, then try fixing the default profile problem
<shlevy> In practice though that doesn't happen. WHat specifically do you think we should change to make it happen in the future, if not assign someone tomake the call?
<Profpatsch> shlevy: True; but maybe the solution is that anybody who takes up the initiative can act as chair.
<niksnut> gchristensen: ok, thanks
<Profpatsch> And by taking the initiative is to lead to a rough consenus and then follow up with code.
<gchristensen> thanks!
<shlevy> Sure, that's a reasonable approach (so long as proposers have a decent base of trust)
dtz has quit [Ping timeout: 248 seconds]
olejorgenb[m] has quit [Ping timeout: 248 seconds]
<shlevy> I think I could get behind that model
<Profpatsch> Sure, trust is required, and that requires a community where everybody assumes the other is acting out of good will/intensions.
<Profpatsch> That’s a requirement I think.
<shlevy> Yeah
<shlevy> I guess "commit bit on the RFCs repo" is a decent proxy for trust
<shlevy> And if someone makes a proposal that doesn't have it, they can either request it or request someone who has it to "chair" the decision
<shlevy> (just thinking as a first-pass approach)
olejorgenb[m] has joined #nixos-dev
dtz has joined #nixos-dev
<shlevy> Profpatsch: If you wanted to write up an RFC for adopting rough consensus with explicit chairs I'd probably coauthor
<shlevy> The paragraph starting "Now, a conclusion of having only rough consensus relies heavily on the good judgement of the consensus caller." seems key
<Profpatsch> shlevy: I bet that RFC never gets implemented because we don’t have a structure to decide on such matters. :D
<niksnut> eh
<niksnut> didn't we just create nix-core for this?
<shlevy> niksnut: That only applies to Nix
<shlevy> niksnut: And isn't part of the point to provide a base to determine a working governance model?
<Profpatsch> I think we already use rough consenus in practice.
<Profpatsch> Though that RFC could help give it a name.
<niksnut> shlevy: yes, with the possibility of extending it to nixpkgs/nixos
<niksnut> it seems strange to already start thinking about a *different* governance model for nixpkgs/nixos
<shlevy> Fair
Sonarpulse has joined #nixos-dev
ashgillman has quit [Ping timeout: 252 seconds]
<gchristensen> niksnut: didn't we used to have a mac9?
<niksnut> yes
<niksnut> I don't know why it's disabled
<niksnut> let's try
<Sonarpulse> angerman: do you mind if I push to your PR?
<Sonarpulse> (force push, that is, cause I'll rebase it)
<niksnut> curl: (56) OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 54
<gchristensen> hmm I haven't deployed to it yet, one minute
stqism has quit [Quit: Like 3 fire emojis lit rn 🔥🔥🔥]
<gchristensen> <apparently one minute later> how about now, niksnut?
<gchristensen> w00t not only did we get Nix2 running on all the builders with nix-darwin, we expanded build capacity by another box!
<LnL> :D
<Sonarpulse> :)
<niksnut> gchristensen: this one appears to hang: https://hydra.nixos.org/build/71410176/nixlog/1/tail
<niksnut> I guess that's pre-upgrade?
<gchristensen> I think so
<gchristensen> niksnut, LnL, copumpkin https://github.com/NixOS/nixos-org-configurations/pull/40
<LnL> gchristensen: should I change the profile thing to a warning?
<gchristensen> I commented that part out because it was unhappy that <darwin> didn't exist
<gchristensen> ohhh no, I think that was a good change
<shlevy> gchristensen: niksnut: darwin builds dying with SIGKILL is a result of the maintenance, right?
<shlevy> I can restart them?
<LnL> I think my change was merged into 2.0 so a fresh install shouldn't need that anymore
<gchristensen> shlevy: yeah, please do
<shlevy> Hmm there's no "restart all failed builds"
<shlevy> I think because all the failed builds are new jobs
<gchristensen> awkward
<shlevy> So there's no "failed builds" tab
<shlevy> :D
<gchristensen> hydra doesn't often have no history, so that edge case is rather unexplored .. :)
<shlevy> Yeah, I just turned on darwin for release-small
<shlevy> (for binutils 2.30)
<shlevy> The number of builds is juuuuust at the threshold where I'd consider scripting this :D
<gchristensen> hrm?
<shlevy> I just opened all the failed builds in new tabs and am restarting one by one
<shlevy> I'd probably script it instead if there weren't too manymore
<LnL> gchristensen: you'll also want to set nix.maxJobs / nix.buildCores
<shlevy> (it was llvm that was killed, so most darwin jobs)
<gchristensen> hmm I do maxJobs
<LnL> oh my bad, looked over that :)
<gchristensen> I'll set buildCores
<LnL> not sure what the best balance is for the mac minis
<gchristensen> they're set to 1 historically
<shlevy> Set 0 and trust make :P
<gchristensen> I'm not sure the macs can handle that ...
<shlevy> :D
<shlevy> -j0 is different from -j right?
<Dezgeg> plain -j is same as infinity
<Dezgeg> don't do that
<shlevy> Right
<shlevy> Yeah, I don't know why make even allows it :D
<gchristensen> seems f6ine.. ;)
<gchristensen> LnL: any other suggestions?
<shlevy> Although tbh we may reach the point where running our own process scheduler for build farms makes sense :D
<shlevy> In which case just dumping it all into the kernel might eb the right thing to do
<shlevy> (not on darwin, of course)
<LnL> gchristensen: no, looks great but I should really add support for remote build/activation :)
<gchristensen> cool, just pushed a few minor tweaks
<shlevy> niksnut: is it expected that /tail endpoints in hydra logs don't seem to actually refresh?
<gchristensen> yeah
<gchristensen> it was too heavy
<shlevy> OK
<niksnut> I don't remember if it was too heavy, but in any case it got lost in the move to S3
<niksnut> oh yeah, I remember experimenting by having "tail -f" pipe to HTTP
<niksnut> but that had issues
<Sonarpulse> has it been reported how the nix.conf name changes cause migration woahs on non-nixos?
<shlevy> nix.conf name change?
<shlevy> Oh, you mean settings changes?
goibhniu has joined #nixos-dev
<Sonarpulse> shlevy: yeah
<Sonarpulse> caches -> substitutors etc
<fpletz> configure: error: SHUT 'ER DOWN CLANCY, SHE'S PUMPIN' MUD!
<fpletz> autotools… m(
<fpletz> oh, it's coming from zfs actually
<gchristensen> ttp://fsckin.com/2007/09/24/189-humorous-unix-errors/ ...
<gchristensen> evidently computers have a long history of pumpin' mud
<fpletz> "It is a error message in a 1987 Texas Instruments computer operating system left in by accident"
<gchristensen> that is definitely a mistake I would make ;)
Lisanna has joined #nixos-dev
<Mic92> this should not give me any results: nix why-depends nixpkgs.pandoc nixpkgs.ghc
<Mic92> pandocs contains string references to /nix/store/ghjrl4kznrfy2l89b5yb94gb60rxb7w1-pandoc-types-1.17.3.1/bin
<Mic92> which eventually end up in having to download ghc for pandoc
goibhniu has quit [Ping timeout: 248 seconds]
<gchristensen> gross!
<Mic92> this recently broke, let's check
jtojnar has joined #nixos-dev
GlennS has quit [Remote host closed the connection]
<Mic92> a question to the haskell people: I have a series of variables set in the binary: pandoc_types_bindir, pandoc_types_libdir pandoc_types_dynlibdir, pandoc_types_libexecdir etc
<Mic92> who does set this?
<Mic92> the same seems to be set for other libraries linked into pandoc
<Mic92> ok. then I can just pipe my knowledge into the issue.
<Mic92> rabin2 from radare2 is a cool tool btw. Just link strings but better.
ma27 has quit [Ping timeout: 256 seconds]
__Sander__ has quit [Quit: Konversation terminated!]
simpson has quit [Ping timeout: 276 seconds]
simpson has joined #nixos-dev
<clever> lrwxrwxrwx 1 root root 28 Mar 21 14:55 /nix/var/nix/gcroots/auto/np6ywmzv2zbwgzbwhp0fc89nnwprb90a -> /tmp/nix-build.vYhVVN/result
<clever> i need to adjust these, to land somewhere other then /tmp/
orivej has joined #nixos-dev
<clever> ah
<clever> TMPDIR is obeyed, ok
ma27 has joined #nixos-dev
MichaelRaskin has joined #nixos-dev
tv has quit [Ping timeout: 252 seconds]
tv has joined #nixos-dev
davidlt_ has quit [Ping timeout: 240 seconds]
davidlt has joined #nixos-dev
ma27 has quit [Ping timeout: 256 seconds]
davidlt has quit [Remote host closed the connection]
davidlt has joined #nixos-dev
ma27 has joined #nixos-dev
<Sonarpulse> responding, but I'm going to need backup here haha
<Sonarpulse> shlevy dtz bgamari
ma27 has quit [Ping timeout: 245 seconds]
jtojnar has quit [Quit: jtojnar]
davidlt_ has joined #nixos-dev
jtojnar has joined #nixos-dev
davidlt has quit [Ping timeout: 264 seconds]
<dtz> sorry was wrapping up some things just submitted PRs for
* dtz looks
<dtz> eep hard to have a quick opinion on this :D
<Sonarpulse> :D
<shlevy> is_runtime_of_this_files_binary_product_arch
<shlevy> etc.
ma27 has joined #nixos-dev
<Sonarpulse> maybe the improved names will help
<shlevy> Doubt it... seems like this one is lost :(
<Sonarpulse> I wrote that and pushed it before the second response came up
jtojnar_ has joined #nixos-dev
jtojnar has quit [Ping timeout: 240 seconds]
jtojnar_ is now known as jtojnar
ma27 has quit [Ping timeout: 276 seconds]
goibhniu has joined #nixos-dev
<Mic92> what is so special about the naming of these macros?
<angerman> Sonarpulse: hmm... I’ve rebase it locally as well, so that would probably result in a mess :-/
<Sonarpulse> angerman: your nix demo or nixpkgs/
<Sonarpulse> oh the PR
<Sonarpulse> gotcha
<dtz> WOW <3<3<3 niksnut
<gchristensen> dtz: ??
<dtz> (re: nix commits: https://git.io/vxWtV)
<shlevy> \p/
<shlevy> \o/*
<gchristensen> :D
<dtz> I typo that often enough I started just going with it
<dtz> it's a person with a ponytail cheering instead!
<dtz> well not really that often, but it became a thing anyway :D
<dtz> > from 632 MiB to 16 MiB.
<dtz> (etc.)
<dtz> haha
<dtz> all the gold stars
<dtz> gonna make mario jealous
<shlevy> "Just because we can" :D
<gchristensen> << exportMagic
davidlt_ has quit [Ping timeout: 260 seconds]
<shlevy> Hmm is there any guarantee that splitting a Nix "system" string on the last - gets you ISA and OS?
* shlevy grumbles about strings
<dtz> dunno, but why not use the parsed thing? as in hostPlatform.parsed.abi.name
<dtz> not sure but think that should work
<dtz> grep'ing for "Platform.parsed" shows a number of uses so it's a thing xD
<shlevy> dtz: I'm parsing out https://events.nix.ci/stats.php right now
<gchristensen> hah
* gchristensen looks at his three lines of haskell, also parsing out stats.php ...
<shlevy> :D
<shlevy> You nerdsniped me
<gchristensen> I recommend treating those keys as opaque tbh :P
<dtz> $ nix eval '(import <nixpkgs/lib>).systems.elaborate {system="x86_64-linux";}'
<dtz> use nix to "elaborate" those into parsed variants
<dtz> lol
<dtz> :P
<thoughtpolice> PR I'd appreciate any input on, if anyone has it, or just a 👍 if interested maybe - https://github.com/NixOS/nixpkgs/pull/37602
<shlevy> But they contain real, useful information! We care about more than equality of systems :P
<MichaelRaskin> for example, we care if a system isArm
<gchristensen> shlevy: depends what you're using those keys for ...
<shlevy> gchristensen: Sure, but I'm writing this as if there were going to be code reuse :)
<gchristensen> hmm
<gchristensen> I think I'd rather add better smarts to the API than push it to the clients
<shlevy> gchristensen: I mean ideally we'd have some common Nix "System" datatype that all sorts of Nix-related projects would use
<shlevy> gchristensen: what does "waiting" mean for a message?
<MichaelRaskin> datatype of what language?
<gchristensen> it is queued
<shlevy> MichaelRaskin: Haskell in this case
<shlevy> gchristensen: got it
<MichaelRaskin> «All Nix-related projects except a few insignificant tools, like Nix»
<gchristensen> the count of all jobs for that queue is (waiting + in_progress)
<shlevy> MichaelRaskin: All *sorts* of Nix related projects
<shlevy> Not all of them :)
<MichaelRaskin> shlevy: isn't Nix a special sotr of Nix-related projects, though?
<shlevy> "All sorts" is not "forall sort, phi" :P
<gchristensen> I am very annoyed that I used hyphens in these keys
<shlevy> It's good! Discourages blind mapping to data type fields :P
<shlevy> Also kebab-case is clearly superior to snake_case and camelCase, and preserving a-b as subtraction was the wrong tradeoff :P
<shlevy> gchristensen: Does the build-inputs- prefix of the queue names suggest there's another kind of build-queue possible?
<gchristensen> man
<gchristensen> yes
<gchristensen> but there is no guarantee the keys will stay like this, or there will be one key per system
<shlevy> Fiiiine
<shlevy> I'll just make a Text buildQueue_name :P
<gchristensen> :P
<gchristensen> good choice
* gchristensen doesn't commit the md5() change to opaquify the keyes
<MichaelRaskin> Obviously, a better PKDF is needed.
pie_ has quit [Read error: Connection reset by peer]
pie_ has joined #nixos-dev