<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?
<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
<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>
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]
<{^_^}>
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?
<{^_^}>
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
<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
<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.)
<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
<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)
<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