worldofpeace_ changed the topic of #nixos-dev to: #nixos-dev NixOS Development (#nixos for questions) | NixOS stable: 20.03 ✨ https://discourse.nixos.org/t/nixos-20-03-release/6785 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html | https://r13y.com | 19.09 RMs: disasm, sphalerite; 20.03: worldofpeace, disasm | https://logs.nix.samueldr.com/nixos-dev
rajivr has joined #nixos-dev
<taktoa[c]> anyone know how to get something like [{key = "a"; deps = ["b", "c"];} {key = "b"; deps = ["c"];} {key = "c"; deps = [];}] out of builtins.genericClosure?
<taktoa[c]> builtins.genericClosure { startSet = [ { key = "a"; deps = ["b"]; } { key = "b"; deps = ["c"]; } { key = "c"; deps = []; } ]; operator = node: map (k: { key = k; }) node.deps; }
<taktoa[c]> ^ that's what I tried, but it's just returning startSet back to me
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 256 seconds]
tilpner_ is now known as tilpner
<taktoa[c]> oh, I understand now
<taktoa[c]> to do that, I want to run genericClosure once for each element of the list
<taktoa[c]> all = [ { key = "a"; } { key = "b"; } { key = "c"; } ];
<taktoa[c]> deps = { "a" = ["b"]; "b" = ["c"]; "c" = []; };
<taktoa[c]> foo = map (val: builtins.genericClosure { startSet = [ val ]; operator = node: map (k: { key = k; }) deps.${node}; }) all;
<taktoa[c]> ^ when the above is run, I get "value is a set while a string was expected", with no line information
<taktoa[c]> ah, figured it out, operator takes a { key = ...; } attrset as input
cole-h has joined #nixos-dev
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
justanotheruser has quit [Ping timeout: 256 seconds]
evanjs has quit [Quit: ZNC 1.8.1 - https://znc.in]
evanjs has joined #nixos-dev
justanotheruser has joined #nixos-dev
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
justanotheruser has quit [Ping timeout: 256 seconds]
vcunat has joined #nixos-dev
sgrunert has joined #nixos-dev
cole-h has quit [Quit: Goodbye]
sgrunert has quit [Remote host closed the connection]
sascha has joined #nixos-dev
sascha is now known as Guest56725
Guest56725 has quit [Quit: Leaving]
sgrunert has joined #nixos-dev
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #nixos-dev
alp has joined #nixos-dev
alp has quit [Ping timeout: 246 seconds]
alp has joined #nixos-dev
saschagrunert has joined #nixos-dev
sgrunert has quit [Ping timeout: 246 seconds]
ehmry has quit [Remote host closed the connection]
johanot has quit [Ping timeout: 256 seconds]
johanot has joined #nixos-dev
<vcunat> ris: on current master (b0a8a746) I tried nixos.tests.pantheon.x86_64-linux and it worked. Latest Hydra eval also shows the channel-critical tests as mostly green: https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents
<vcunat> so I assume there's something different on your machine.
<pbogdan> (still don't understand how that commit broke it in the first place)
<vcunat> Ah, thanks.
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
__monty__ has joined #nixos-dev
ckauhaus has joined #nixos-dev
ehmry has joined #nixos-dev
teto has joined #nixos-dev
<V> o.o
orivej has quit [Quit: No Ping reply in 180 seconds.]
evanjs has quit [Ping timeout: 256 seconds]
evanjs has joined #nixos-dev
evils has quit [Read error: Connection reset by peer]
evils has joined #nixos-dev
<WilliButz> is there currently any way to define more than just one instance of the available options in systemd unit files? (such as EnvionmenFile, ExecStart, ExecStartPre ...)
<WilliButz> seems to me like there is currently no way around having them in one nix attrset at some point, making multiple values for the same key pretty much impossible unless they're merged
<domenkozar[m]> let .. in?
<domenkozar[m]> hard to help without more context why you need two
<WilliButz> oh, sure. having a service that uses an environment file for the whole configuration would allow me to inject additional config that is not covered by the module or secrets that should not go into the nix store by defining an extra EnvironmentFile for the unit which will then also be read
<WilliButz> one such service would be bitwarden_rs
<symphorien[m]> make the key a list ?
<WilliButz> yeah, i thought so too, but i was hoping that this would already be possible without touching the upstream modules :>
ckauhaus has quit [Quit: WeeChat 2.7.1]
<immae> WilliButz: you want to add entries to a service config that is already defined somewhere else?
<WilliButz> immae: yes, specifically I'd like to add a second definition of EnvironmentFile to a service that already has one
<immae> If the other definition is already a list, you may use lib.mkAfter [ "your other file" ]; (or lib.mkBefore). If it’s a string then you’ll be obliged to use lib.mkForce [ "the upstream file" "your other file" ];
<julm> In case it's a list and in that case, I guess you could even omit the lib.mkAfter and lib.mkBefore
<WilliButz> immae: in the specific case of bitwarden_rs i don't see a way to access the generated environment file, which is only defined in a let..in block, and then used in the service config
<immae> Oh
<julm> I don't know if this helps here, but one can also define environment.${name} = "value";
<immae> A workaround would be to define a systemd/system/bitwarden_rs.override file (check the exact name) which would contain your override
<WilliButz> julm: i'd like to inject secrets, so for this purpuse setting environment wouldn't help :/
<immae> (in environment.etc)
<julm> WilliButz: in last resort, you can also blacklist the whole module with disabledModule and load your own
<julm> disabledModules*
<WilliButz> immae: oh, thanks for the tip with overriding the unit, i'll check if i can make that work
<immae> It needs to end in /etc/systemd/system/the_service_name.service.d/override.conf
<WilliButz> julm: i'd still like to use the existing modules as much as possible ^^
<immae> And you’ll probably need to force a "systemctl daemon-reload" somewhere
<WilliButz> yay %)
<immae> (because it’s clearly not "the nix way" :p )
<WilliButz> i also thought about adding another option one level above serviceConfig, like preStart or script, called something like environmentFiles
<immae> That’s another way
<immae> (you’re lucky there is a "systemctl daemon-reload" executer unconditionnaly during system activation)
<julm> IIRC, injecting stuffs in environment.etc."systemd/system" is not possible because environment.etc."systemd/system".source is used, so I had to use: systemd.packages = [ (pkgs.writeTextDir "etc/systemd/system/the_service_name.service.d/override.conf" "[Service]\n...") ];
<immae> oww
<WilliButz> ok, i think i'll add the mentioned option and open a pr :)
<immae> indeed, the workaround I suggested doesn’t work...
vcunat has quit [Ping timeout: 272 seconds]
<WilliButz> hmm, maybe it would be better to just make the assignment in the module a list. then merging would be trivial and no new systemd option is needed :)
<WilliButz> immae: so basically what you said first ("If the other definition is already a list...")
<immae> yes that would be the easiest
<immae> but I was searching for a solution that doesn’t involve modifying upstream :)
alp has quit [Ping timeout: 260 seconds]
<WilliButz> me too, but there is always this point where the workarounds become too ugly and touching upstream is easier ^^
<immae> yes right
<immae> The next "workaround level" would be to override the runCommand script that generates /etc/systemd/system :p
<immae> However julm’s solution seems to be "officially" supported from what I see in nixos/modules/system/boot/systemd-lib.nix so maybe his solution is the right one :p
<WilliButz> yeah, it's probably the best solution available, that does not involve upstream changes
<julm> maybe we could consider fixing this once and for all by modifying unitOption's merge= to merge string and list into list
orivej has joined #nixos-dev
<immae> that looks like a briliant idea :p
<WilliButz> indeed :)
<julm> I guess it could cause a runtime problem if someone defines two ExecStart= which systemd will refuse IIRC, but either we don't care or this specific option could maybe be checked
<immae> Is it currently checked anyway?
orivej has quit [Quit: No Ping reply in 180 seconds.]
<WilliButz> currently it is just not possible to define multiple definitions of the same key without merging them
<WilliButz> only when using explicit workarounds as the ones we discussed before
<julm> I guess one could currently ExecStart = mkForce ["/foo" "/bar"]. Also here the new freeFormType= feature could help to type-check a few options and still let the possibility to define other options
orivej has joined #nixos-dev
orivej has quit [Client Quit]
orivej has joined #nixos-dev
vcunat has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
Raito_Bezarius has quit [Read error: Connection reset by peer]
Raito_Bezarius has joined #nixos-dev
<worldofpeace> vcunat: I did some backports to pantheon etc. and forgot two commits. fixed that yesterday night
<vcunat> Yes, I knew that.
<vcunat> That's exactly why I had that test in recent history and used it for testing.
justanotheruser has joined #nixos-dev
ris has quit [Remote host closed the connection]
ris has joined #nixos-dev
alp has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
ixxie has joined #nixos-dev
orivej has joined #nixos-dev
saschagrunert has quit [Remote host closed the connection]
orivej has quit [Quit: No Ping reply in 180 seconds.]
justanotheruser has quit [Ping timeout: 265 seconds]
disasm has quit [Ping timeout: 240 seconds]
<hexa-> JJJollyjim: will there be a matrix-appservice-irc iteration #8? :o
disasm has joined #nixos-dev
ixxie has quit [Remote host closed the connection]
ixxie has joined #nixos-dev
teto has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
orivej has quit [Client Quit]
FRidh has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Client Quit]
justanotheruser has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Client Quit]
alp has quit [Remote host closed the connection]
alp has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
cole-h has joined #nixos-dev
teto has joined #nixos-dev
sascha has joined #nixos-dev
sascha is now known as Guest11582
teto has quit [Ping timeout: 260 seconds]
jonringer has joined #nixos-dev
<jonringer> wondering if anyone here is available to help with hydra jobset creations for 20.09
orivej has joined #nixos-dev
<jonringer> specifically, would be great if @gchristensen was available
alp has quit [Ping timeout: 244 seconds]
<cole-h> jonringer: Branch-off needs to happen before jobsets can be created, AFAIK
<cole-h> Since the jobset needs to be created by pointing it to a git branch
<cole-h> and cc vcunat
<vcunat> Yes, I am available ATM.
<vcunat> jonringer: ^^ (I should remain awake for a couple hours.)
<vcunat> I can't create a channel, but that shouldn't be a problem to start ZHF, etc.
<vcunat> s/problem/needed/
<worldofpeace> yeah, that was this thing https://github.com/NixOS/nixos-org-configurations/pull/120
<{^_^}> nixos-org-configurations#120 (by worldofpeace, 2 days ago, open): 20.09 channels
<worldofpeace> until one of our admins *eyerolls can respond I guess there will be no channels.
<vcunat> Binaries will be in cache regardless.
<worldofpeace> right
<worldofpeace> maybe ping zimbatm niksnut aminechikhaoui
<vcunat> So I think there will be lots of other work to do in the meantime.
<vcunat> I can also try to help with anything you get stuck on. I co-managed a couple releases, so I might still remember stuff.
<jonringer> should I create the branches? This will essentially be the branchoff
<jonringer> staging-next was merged into master, so now could be a reasonable time
<vcunat> tested jobset succeeded now: https://hydra.nixos.org/build/126594337
<jonringer> yea, I saw your comment on the staging-next PR
<worldofpeace> jonringer: you need to branch and there's some minor changes u have to make ONLY to the 20.09 branch
<worldofpeace> and others to the master brnach
<vcunat> Other than the stuff mentioned on the staging-next PR, I haven't been following the overall level of brokenness.
<jonringer> well, fixes can be backported, until we have the "beta" release on friday, I don't think minor breakages will be too bad
<jonringer> part of the reason why I wanted to start ZHF earlier
<worldofpeace> should we get on a call jonringer ?
<jonringer> sure
<worldofpeace> okay, one sec
ixxie has quit [Quit: Lost terminal]
dongcarl has quit [K-Lined]
orivej_ has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
alp has joined #nixos-dev
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-dev
<ris> oh it's the 7th
<ris> today's the big day isn't it?
<worldofpeace> ris: today's the branchoff
<ris> yup
<worldofpeace> Going to mention it here incase something thinks it's terrible, but me and Jon thought to name 21.03 Okapi https://duckduckgo.com/?q=okapi&t=ffcm&ia=web
<worldofpeace> we lucked out with nightingale for 20.09, but the o animals were... I guess not as poetically beautiful
<vcunat> Okapi sounds nice to me :-)
<worldofpeace> I'm just realizing there's an "oxpecker" which has some interesting behavior https://slate.com/technology/2015/10/vampire-finches-and-oxpecker-birds-drink-blood.html 🤣
<worldofpeace> vcunat: cool 👍️
<ris> would have liked to have got #95546 in before the branch
<{^_^}> https://github.com/NixOS/nixpkgs/pull/95546 (by risicle, 3 weeks ago, open): gpac: 0.8.0 -> 1.0.0 addressing numerous CVEs
<worldofpeace> ris: is it something that couldn't be backported? I see cve fixes which are usually accepted throughout. judging though, from the version, it's a major upgrade?
<ris> and #95592 but no word from the maintainers
<{^_^}> https://github.com/NixOS/nixpkgs/pull/95592 (by risicle, 3 weeks ago, open): flink: 1.9.0 -> 1.11.1, addressing CVE-2020-1960
FRidh has quit [Quit: Konversation terminated!]
<ris> those ones in particular were hard to backport
<worldofpeace> like, with all those CVE's even if we were at beta freeze it would make sense to make an exception
<ris> one because it's a binary package
<ris> the other because it's about 20 separate vulnerabilities
<worldofpeace> ris: I merged both
<worldofpeace> if Jon already checked out (probably did) u can always port to the branch
<vcunat> +1
<ris> :dusts-hands: done and done
<ris> thanks
<worldofpeace> np ris
<cole-h> Who should I ping to get a NixOS/nix docs update PR merged? I don't know if it'd be rude to ping Eelco since he's probably busy doing other stuff. https://github.com/NixOS/nix/pull/3982
<{^_^}> nix#3982 (by cole-h, 6 days ago, open): Minor docs updates
<samueldr> cole-h: try the @NixOS/nix-core team
<samueldr> not sure there is a "nix committers" team though
<cole-h> I think I've seen domenkozar[m] merge things, but I don't know if he'd be comfortable doing so/want to do so :P
ixxie has joined #nixos-dev
<worldofpeace> cole-h: he probably would be comfortable. though that isn't something I can decide for him
Guest11582 has quit [Remote host closed the connection]
<vcunat> samueldr: That team has been officially disbanded by https://github.com/NixOS/rfcs/pull/44
<{^_^}> rfcs#44 (by shlevy, 1 year ago, merged): [RFC 0044] Disband the Nix Core Team
<samueldr> yeah, but the team still exists :)
<samueldr> as in GitHub team
<vcunat> Yes, I confirm I still do have the push access even though not really "entitled" anymore.
<cole-h> vcunat++ Thanks! :)
<{^_^}> vcunat's karma got increased to 4
<vcunat> :-)
<vcunat> worldofpeace: do you have some ETA for when the branch will be available - or more precisely when you want the jobset created?
<worldofpeace> vcunat: incredibly soon
<worldofpeace> like probably in a few minutes I think
<vcunat> Great.
<worldofpeace> I'm about to review jon's changes since we had to rethink something last minute
<vcunat> I just wanted to avoid my sleep clashing with your plans.
alp has quit [Ping timeout: 246 seconds]
<worldofpeace> right right, I am very sorry about the time vcunat
<vcunat> Not a problem. I'd be awake at least for one more hour anyway, I think.
<aminechikhaoui> Hey worldofpeace, just saw the mentions now but I didn't go through the discussion, do you need a jobset to be created or that's gonna be done by vcunat already ?
<jonringer> D: sorry!
<worldofpeace> yay!
<worldofpeace> so vcunat is going to handle that if the time doesn't get to him
<worldofpeace> but we need someone to handle the channels I think?
<samueldr> the nixos org config repo?
<{^_^}> nixos-org-configurations#120 (by worldofpeace, 2 days ago, open): 20.09 channels
<worldofpeace> yes exatly samueldr
<worldofpeace> * exactly
<cole-h> (and also to verify that we're right in removing 19.03 and marking 19.09 EOL)
<aminechikhaoui> oh I think that needs a deploy of bastion, which probably was handled by Graham or niksnut before but I can take a look if they're not around.
<worldofpeace> yeah, neither of them are around
<samueldr> at the *very* worst, it's less of an issue for continuing on if that's not pushed today
<aminechikhaoui> it also likely needs the jobset to be created and maybe at least a first eval for the channel script to work
<worldofpeace> yes, exactly. both of those requirements were in our notes
<vcunat> Those three commits look good to me, at least in principle. (After the jobset is created.)
ixxie has quit [Quit: Lost terminal]
<aminechikhaoui> yeah me too, we can even merge I guess but won't have any impact until we deploy the services that run the channel scripts
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-dev
<vcunat> :-)
alp has joined #nixos-dev
__monty__ has quit [Quit: leaving]
Raito_Bezarius has quit [Read error: Connection reset by peer]
Raito_Bezarius has joined #nixos-dev
Raito_Bezarius has joined #nixos-dev
Raito_Bezarius has quit [Changing host]
<cole-h> vcunat: Hope you're still awake :D
<worldofpeace> vcunat: amine is in EDT so we've switched to them for now
<worldofpeace> lol
<worldofpeace> I mean't cole-h
<cole-h> Oh
<vcunat> yes, but I still am now
<cole-h> vcunat: Hope you have a pleasant sleep ;^)
<vcunat> :-)
<aristid> do i understand it correctly that if nix-build nixos/release-combined.nix -A tested succeeds, the channel should be updated not too long after that?
<samueldr> aristid: "not too long" is variable
<samueldr> every package has to be tried to be built, in addition to that
<aristid> so the 18 queued aarch64 jobs are holding up the unstable channel? https://hydra.nixos.org/eval/1611935#tabs-unfinished
<samueldr> 17, and 1 x86_64
<worldofpeace> aminechikhaoui: we're ready
<{^_^}> nixos-org-configurations#120 (by worldofpeace, 2 days ago, open): 20.09 channels
<vcunat> Yes, correct. (on the channel update stuff)
<aminechikhaoui> worldofpeace alright, I'll create the jobsets first, following https://gist.github.com/grahamc/8314fcea62772ef03d48dff7fee0dd57
<worldofpeace> aminechikhaoui: wait, just realized we need to push staging-20.09 too
<vcunat> I think it's easiest to use the "clone" button and edit the settings.
<vcunat> (on respective 20.03 branches)
<cole-h> Reading the release notes, "Support is planned until the end of October 2021, handing over to 21.09." -- should we mark 20.03 EOL in October of this year? Or is EOL != support length
<aminechikhaoui> right, I think I need to just switch stableBranch to false
<worldofpeace> samueldr: fab ✨
<worldofpeace> we decided to name the period from branch to beta, alpha https://github.com/NixOS/nixpkgs/releases/tag/20.09-alpha. and then tag once we know basic stuff like images are QA'd etc to make a 'beta'
teto has joined #nixos-dev
<vcunat> Oh, sounds like our nixpkgs master is only "alpha" quality. (but I don't want to bikeshed this stuff now)
<worldofpeace> lol, alpha is the assumption that all of tested works
justanotheruser has quit [Ping timeout: 246 seconds]
<worldofpeace> that's already a pretty good "alpha"
<aristid> and it does!
<jonringer> yea, it's just that staging-next was just merged a few hours ago and contains a lot of untested packages
<vcunat> aristid: I now cancelled those remaining jobs, so the channel should update quite soon. Sometimes I do that when it's desirable for the channel to update quickly. Right now we've had a very long period without update.
<aristid> vcunat: yeah thanks
<jonringer> and it's pretty typical for releases that a bunch of stuff gets crammed in right before branch off
<vcunat> At least we have it some weeks before release. The cramming used to be way worse.
<jonringer> Yea, but I would like for people to have a very "polished" experience when installing and using nixos
<jonringer> Ideally, I would love for the ZHF period to occur on master (after a staging-next merge), and just stabilize both for ~2 weeks, then do the branch off
<vcunat> I'd hope that the following three weeks will help polishing it. I agree it's generally not a very long time.
<vcunat> That would imply some kind of freeze on master.
<aristid> i also seem to recall that releases used to be on something like 2 months delayed, a few years ago? ;-)
<vcunat> Instead of freezing master we chose to branch off, though that implies lots of cherry-picking.
<infinisil> I think we've had a lot of backwards incompatible changes for a lot of modules over the last 6 months
<vcunat> First few releases weren't regular, that's for sure.
<infinisil> Justified backwards incompatibilities though
<vcunat> (I mean, they weren't periodically spaced.)
<infinisil> (with proper assertions too)
<aminechikhaoui> ok jobsets created:
<jonringer> vcunat: I wouldn't "freeze" master, just have some CI in place to make sure that people aren't breaking builds, but master would be freeze to bump/iterate
<cole-h> aminechikhaoui++
<{^_^}> aminechikhaoui's karma got increased to 3
<cole-h> jonringer++
<{^_^}> jonringer's karma got increased to 4
<cole-h> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 183
<worldofpeace> ❤️
<worldofpeace> 🎇 jonringer
<worldofpeace> ✨ jonringer
<{^_^}> jonringer's karma got increased to 5
<jonringer> would be free* to bump/iterate
<jonringer> worldofpeace++
<{^_^}> worldofpeace's karma got increased to 184
<aminechikhaoui> though it would probably take some time to eval each, anyone knows how much it takes to evaluate on master nowadays ? :)
<vcunat> (for now I didn't spend much effort on the topic, as there are currently pressing matters around the release now)
<worldofpeace> we did it. just the channels once everything works, ZHF issue, and planning meetings for 20.09 beta stuff
<vcunat> As I state there, evaluating all the tests takes around 10 minutes.
<jonringer> vcunat: agreed, I guess i was trying to hint at the 21.03 release may be able to try something like that, assuming that the infrastructure is in place
<vcunat> It certain seems an aspect that would be nice to improve.
<jonringer> aminechikhaoui++
<{^_^}> aminechikhaoui's karma got increased to 4
<worldofpeace> ✨ aminechikhaoui
<{^_^}> aminechikhaoui's karma got increased to 5
<worldofpeace> in the future, maybe we can enable github discussions for nixos/infra to get this planned better a week out
<aristid> i mean maybe i just don't know how to use it properly, but it's also kind of hard / cumbersome to tell if a hydra evaluation is good to go or not. like now i click on the evaluation and search for job "tested"
<vcunat> aristid: and you want... to find the last eval with green tested job or what?
<samueldr> it's not built for the purpose of having that put in front of your eyse indeed
<cole-h> What I do is: 1) status.nixos.org 2) click on the "Hydra job for tests" link 3) click on the latest build 4) click on the evaluation ("Part of:") 5) look for "Queued jobs"
<aristid> vcunat: well that's usually the channel. i just noticed that the channel was very outdated and wanted to see if there's any blocking failing jobs i can help with :) - and then i realized that it was already all fixed but not propagated to the channel yet
<cole-h> If there are no more queued jobs and the build was green, there should be a bump incoming (AFAIR)
<vcunat> aristid: for that I use https://status.nixos.org/
<aristid> vcunat: i didn't know that exists, thanks :)
<vcunat> It also shows all github issues and PRs with the "channel-blocker" label
<vcunat> (currently none, after lots of effort)
justanotheruser has joined #nixos-dev
<infinisil> jonringer: Damn, okapi's look dope!
<infinisil> Every NixOS release I learn about a new animal :P
<vcunat> After we get to Z, we can publish a nice NixOS Alphabet book for children.
<worldofpeace> merch opportunities just waiting for us
<infinisil> > alphabet = "abcdefghijklmnopqrstuvwxyz"
<{^_^}> alphabet defined
<infinisil> "O" is pretty far already :o
<cole-h> Thanks infinisil. I totally forgot about the alphabet.
<cole-h> ;)
<infinisil> xD
<infinisil> Um, there's no indexOf or so function in lib
<cole-h> aminechikhaoui++ Woot! Now just to wait for the channel updater to fire
<{^_^}> aminechikhaoui's karma got increased to 7, it's a crit!
<cole-h> Oh wait
<cole-h> And we need to wait for a bastion deploy
<cole-h> lol
<aminechikhaoui> hehe, yeah doing that now. Though I would expect the systemd units to just fail initially until the tested jobs are green for the release jobsets
<aminechikhaoui> but it runs in a timer so it would pick it up at some point
jonringer has quit [Ping timeout: 240 seconds]
<ris> my PR was the last to get in to master before branching :D
vcunat has quit [Quit: Leaving.]
<aminechikhaoui> bastion deployment just finished. Looking at hydra I think it's mostly busy with staging-next jobset so it didn't pick up any of the release-20.09 jobs yet
<cole-h> >> Queue (126/376457)
<cole-h> Holy moly
teto has quit [Ping timeout: 246 seconds]
<worldofpeace> yay aminechikhaoui