sphalerite changed the topic of #nixos-dev to: NixOS Development (#nixos for questions) | NixOS 19.03 released! https://discourse.nixos.org/t/nixos-19-03-release/2652 | https://hydra.nixos.org/jobset/nixos/trunk-combined https://channels.nix.gsc.io/graph.html https://r13y.com | 19.03 RMs: samueldr,sphalerite | https://logs.nix.samueldr.com/nixos-dev
aria has left #nixos-dev [#nixos-dev]
magnetophon has quit [Ping timeout: 244 seconds]
tilpner_ has joined #nixos-dev
tilpner has quit [Ping timeout: 244 seconds]
orivej has joined #nixos-dev
Drakonis has quit [Quit: WeeChat 2.4]
Drakonis has joined #nixos-dev
drakonis1 has quit [Ping timeout: 264 seconds]
drakonis_ has joined #nixos-dev
Drakonis has quit [Ping timeout: 250 seconds]
__monty__ has joined #nixos-dev
Jackneill has joined #nixos-dev
johanot has joined #nixos-dev
tilpner_ is now known as tilpner
johanot has quit [Ping timeout: 268 seconds]
johanot has joined #nixos-dev
<FRidh> infinisil: deprecating python2, or at least minimizing its usage when bulding core packages, is blocked by darwin
<{^_^}> #63174 (by FRidh, 5 weeks ago, open): libxml2 and libxslt: build against python3 by default
magnetophon has joined #nixos-dev
psyanticy has joined #nixos-dev
johanot has quit [Quit: WeeChat 2.4]
<infinisil> Ah darn
<LnL> yeah, we need to bootstrap the stdenv using python3 for that
<LnL> I don't expect anything problematic, just requires reshuffling a bunch of stuff
<__monty__> What could go wrong?™ : )
<LnL> nothing, but I really don't want to depend on 2 and 3 while bootstrapping
__Sander__ has joined #nixos-dev
Drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 250 seconds]
ciil has quit [Quit: Lost terminal]
__monty__ has quit [Ping timeout: 245 seconds]
ciil has joined #nixos-dev
drakonis_ has joined #nixos-dev
__monty__ has joined #nixos-dev
Drakonis has quit [Ping timeout: 258 seconds]
orivej has quit [Ping timeout: 268 seconds]
__monty__ has quit [Ping timeout: 272 seconds]
__monty__ has joined #nixos-dev
__Sander__ has quit [Quit: Konversation terminated!]
Jackneill has quit [Ping timeout: 245 seconds]
Jackneill has joined #nixos-dev
Drakonis has joined #nixos-dev
drakonis_ has quit [Ping timeout: 276 seconds]
pie_ has quit [Ping timeout: 252 seconds]
<asymmetric> is there something like a documentation working group? :)
<gchristensen> nothing formal like that, but it'd be cool to make one!
orivej has joined #nixos-dev
<makefu> asymmetric: there is the nixos-wiki team, and efforts by individuals (mostly gchristensen ;) to fix up the official documentation
drakonis_ has joined #nixos-dev
Drakonis has quit [Ping timeout: 245 seconds]
webster23 has joined #nixos-dev
pie_ has joined #nixos-dev
Jackneill has quit [Remote host closed the connection]
bgamari_ is now known as bgamari
<aristid> are you guys aware of this problem with systemd-timesyncd?
<aristid> Jul 23 21:27:21 cobalt systemd[26114]: systemd-timesyncd.service: Failed to set up special execution directory in /var/lib: Not a directory
<aristid> Jul 23 21:27:21 cobalt systemd[26114]: systemd-timesyncd.service: Failed at step STATE_DIRECTORY spawning /nix/store/wzrglgf7i2zajmm5k53hypgnv3n0z3v6-systemd-242/lib/systemd/systemd-timesyncd: Not a directory
psyanticy has quit [Quit: Connection closed for inactivity]
<samueldr> aristid: does your configuration.nix have a system.stateVersion?
<aristid> samueldr: i think not, but let me check
<{^_^}> #64922 (by yorickvP, 1 week ago, open): systemd-timesyncd fails at step STATE_DIRECTORY on semi-clean install
<samueldr> cc andi-
magnetophon has quit [Remote host closed the connection]
<aristid> samueldr: yeah this laptop has been running unstable since way before stateVersion existed
<aristid> and i guess i never set one :D
<samueldr> hmm
<samueldr> uuuuugh, I guess it would break even more stuff to set stateVersion to something like 00.00 by default
<samueldr> since the default has been that none is like the latest :/
<samueldr> (I think?)
<aristid> i'm happy to just set it to something that works, for now
<samueldr> tohugh I think you have a legit case of not having a stateVersion on your system
<yorick> ah, this again
<samueldr> I think there was head-scratching about users not having stateVersion set
<aristid> samueldr: i set up this laptop in 2015
<yorick> yeah, I think failure to set state version means "I don't care about state" for me
<aristid> and have been rolling nixos-unstable ever since
<aristid> yorick: in 2015 it didn't exist and i was never forced to set it and i didn't have any real issues until now... so i never set it :P
<yorick> samueldr: maybe it should be mandatory
<aristid> yeah, either make it work
<aristid> without it set
<aristid> or make it mandatory
<aristid> the current state of affairs where some stuff is just weirdly broken is not great
<aristid> so what do i need to set the stateVersion to? 19.03?
<yorick> aristid: yes, or you can rm -rf /var/run/systemd-timesyncd
<yorick> aristid: make a PR for mandatory :)
<aristid> the rm -rf did not work
<aristid> yay, deleting /var/lib/systemd/timesync is what really helped
<aristid> yorick: also i feel like this "fix" was using stateVersion for something wrong. i think stateVersion is for stuff like databases, not things that a system activation script could fix up
<aristid> there's another problem with this: it assumes people don't use nixos-unstable!
<samueldr> nixos-unstable has stateVersion since stateVersion was instroduced, and is more about a "schema" of all state (including some service's) than datatabases only
<samueldr> one of the mistakes might have been to tie it to the nixos release version numbering scheme
<aristid> samueldr: well this was clearly a change significantly after 19.03
<aristid> or did i just not notice the issue for multiple months? (possible, i guess)
<samueldr> if one was to run a postgreSQL database on unstable without stateVersion in the upgrade from IIRC 17.09 to 18.03 it would have affected them
<aristid> yeah but i don't run a postgres on my laptop :D
<samueldr> there only a few places where it ended up being used, thankfully
<aristid> samueldr: if stateVersion was a running counter instead of the nixos release string i think i could tolerate it much better
<globin> it does not assume people don't run unstable, you generally always keep stateVersion where you started out
<samueldr> globin: I think there might be issues with the "unset" use case here
<samueldr> not sure if it's specific to the timesyncd one though
<aristid> globin: what i meant is that changes in unstable that affect the stateVersion cannot be really represented with the stateVersion because it uses the release names
<aristid> so in theory you would need to make sure to time those changes to coincide exactly with the release dates
<samueldr> stateVersion defaults to `cfg.release` :/
<infinisil> I mentioned this before, I think stateVersion should be per-module: https://github.com/NixOS/nixpkgs/pull/50112#issuecomment-438769388
<aristid> samueldr: i'll make the PR to make it mandatory, but i don't expect it will actually be merged. nonetheless, this is a discussion that needs to be had.
<aristid> infinisil: i think a simple running counter could work too
<aristid> when you make a change that breaks stuff, you IMMEDIATELY increment that counter
<samueldr> aristid: when a new release is cut, cfg.release is increased, so a nixos-generate-config on nixos-unstable on the day following the cutting of the new release is not an issue
<aristid> in the same git commit
<samueldr> aristid: I agree, I made the case in a PR already
<samueldr> #50112
<{^_^}> https://github.com/NixOS/nixpkgs/pull/50112 (by samueldr, 36 weeks ago, open): Renames stateVersion to stateEpoch
<adisbladis> infinisil: What would the ergonomics of that be? I have a hard time seeing how that would work.
<samueldr> this was in addition to being user-hostile in the naming and looking like where you'd upgrade your system version
<infinisil> adisbladis: Not sure about the ergonomics, but the usecase is that you can migrate the state from different modules independently
<adisbladis> infinisil: The use case is awesome :)
<infinisil> And it makes a lot of sense
<adisbladis> I'm not understanding how it would work in practice though
<infinisil> It's like a version number for modules
<infinisil> adisbladis: Possibly every module could have its stateVersion option (if it needs it, could be done with some mkStateVersion function)
<adisbladis> stateVersion now is nice because it's just the one number, it can easily be embedded in everyones config without much fuzz.
<samueldr> the ergonomics are weird, since you can't assume "unset == latest", and users are unlikely to know they need to configure it unless they're pestered by the configuration to do so
<adisbladis> infinisil: The bit I don't understand is how that would be expressed in my config
<infinisil> Although, users won't have that set in their modules by default
<infinisil> adisbladis: It would work just like stateVersion, in that you have to write it as an option value
<samueldr> if you assume unset == epoch 0, then new installs will still use the old state scheme :/
<adisbladis> infinisil: Oh so by default config has no epoch?
<infinisil> samueldr: Yeah, so we'd have to force users to set it to the default value
<adisbladis> And you can pin a service at an older one?
<samueldr> so, the story is "on first upgrade requiring a module state epoch, pester the user to choose"?
<infinisil> adisbladis: Yeah, a bit like pinning
<infinisil> samueldr: Yeah.. it's not very nice
<samueldr> so in actuality it's "for new users past the addition of module state, always be pestered"
<samueldr> yeah
<infinisil> But something like that would be ideal
<adisbladis> I don't like the UX :/
<adisbladis> Tough the intent is great
<infinisil> I mean, that doesn't sound too bad actually, when you enable postgresql, you get "Please specify services.postgres.stateVersion = 0 to prevent problems when updating to future versions"
<aristid> uh, i forgot how to make an option mandatory :D
<aristid> can somebody remind me?
<infinisil> aristid: Just don't declare any default value :)
<adisbladis> infinisil: Hmm... It's probably not as bad as I think. There are not that many modules that actually care about stateVersion currently anyway.
<infinisil> adisbladis: Yeah, it's rarely used
<samueldr> the message is likely to be "set stateVersion to 0 if you were already using the module, to ${current} for new installations."
<infinisil> And the UX for module authors is that they can just increase the default value for stateVersion in the relevant module itself when updating it in an incompatible way
<adisbladis> infinisil: I like it =)
<adisbladis> That's _much_ better than the current situation
<aristid> i guess when i make the PR i shouldn't make the branch in the nixpkgs repo
<aristid> last time i did that people were unhappy :D
<infinisil> Ohhh, or even, `stateVersion = "9.4"` for postgres version 9.4
<infinisil> You can have program-specific state versions
<samueldr> infinisil: that's not likely a good idea :/
<infinisil> Ah yeah upon second thought maybe not
<samueldr> imagine if the idea is to change the superuser defaults
<aristid> infinisil: too fine-grained becomes maintenance nightmare IMHO
<infinisil> Okay just a simple integer then :)
<samueldr> and as usual, the idea should be to strive never to need stateVersion
<aristid> lol, using nixpkgs git you do kind of need a beefy machine given how huge the repo is these days
<infinisil> samueldr: Yeah, stateVersion is probably only really needed if it's dangerous to do a migration automatically
<infinisil> aristid: I think shallow clones should work
<infinisil> And then with mkStateVersion we could even put migration documentation in the option description
<infinisil> To look up how to update the postgres stateVersion you just have to look at that options description
<infinisil> mkStateVersion { name = "postgres"; migrations = [ { target = 1; description = "Do this and that to migrate to this state"; } ]; }
<aristid> ^ #65314
<{^_^}> https://github.com/NixOS/nixpkgs/pull/65314 (by aristidb, 16 seconds ago, open): make nixos.stateVersion mandatory
<aristid> infinisil: that sounds really complex
<aristid> infinisil: how would you make sure that for every relevant module, a value is actually set? or would you just always assume the oldest possible version by default?
<infinisil> Yeah not sure about that one, but it would be fancy if you then could ask "How do i get from 0 to 2" and it would list steps from 0 to 1 and 1 to 2
<infinisil> aristid: For every relevant module?
<aristid> infinisil: the "how do i get from 0 to 2" could also be done with a global counter :-)
<aristid> like when you commit a change that increases the current maximum counter you'd have to give a description to what changed and how to migrate
<infinisil> Ah
<infinisil> aristid: Simple: the current default value of stateVersion is the number of items the list has
<infinisil> s/default/current
<aristid> "the current current value"?
<infinisil> Hehe, I mean, it's still a default value, just not one that gets accepted without users explicitly setting it
<infinisil> Such a migration list would translate to a type `enum (range 0 (length list))`, and a message "Set services.foo.stateVersion = ${length list} to make sure it works for future updates"
<infinisil> (and you don't actually need a `target` attribute because that could be inferred from the index in the list, but it might still be nice to have that just for visibility)
<infinisil> Ohh, and with this we could even deprecate support for older stateVersions easily, just add an assertion for stateVersion being higher than some value
<infinisil> With a nice migration warning
Jackneill has joined #nixos-dev
Drakonis has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
Jackneill has quit [Remote host closed the connection]
__monty__ has quit [Quit: leaving]
pie_ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie_ has quit [Remote host closed the connection]
pie_ has joined #nixos-dev
pie_ has quit [Client Quit]
pie_ has joined #nixos-dev
<yorick> I don't expect systemd-timesyncd to have state, hence I don't expect to have to set stateVersion on a 'stateless' system
drakonis1 has joined #nixos-dev
drakonis_ has quit [Ping timeout: 252 seconds]
webster23 has quit [Ping timeout: 264 seconds]