2018-04-14

<MichaelRaskin> And then it is not as much stateVersion as «defaultVersion»
<joepie91> I feel like maybe stateVersion should be renamed to something that more clearly describes you shouldn't change it, like originalStateVersion or so
<tilpner> stateVersion is "your state has this version", not "please state the version of NixOS you want to use"
<monokrome> Do I just change stateVersion and go?
<LnL> day|flip: no, don't change stateVersion :/
<tilpner> day|flip - No, that will not happen. stateVersion does not "state the version of your NixOS channel", it's the version your state has
<tilpner> day|flip - What do you want to do? You should never touch stateVersion without reinstalling, in general

2018-04-11

<fadenb> Just dumping this here for others to find: Upgrading NixOS 17.09 to 18.03 might break matrix-synapse startup (even with stateVersion kept at 17.03)

2018-04-09

<gchristensen> mg-: you shouldn't change the stateVersion unless the docs indicate you should
<samueldr> there aren't that many `stateVersion` uses in <nixpkgs>, if you're curious you can grep around to see if there can be any breakge
<samueldr> there is a condition, stateVersion < 17.09 it uses the older user, else the new user
<samueldr> it *can* be updated if you have verified that all modules using stateVersion that were in use were manually updated
<warbo> it was my understanding that "stateVersion" basically records which version the system was "originally" built with
<samueldr> stateVersion shouldn't be updated when using software that uses stateVersion, but keeping it low should not be an issue
<achambe> https://nixos.org/nixos/manual/release-notes.html -> search for stateVersion

2018-04-07

<MichaelRaskin> cx405: maybe a migration tool that could get some tratction would be nix-diffing your system evaluated with different stateVersion values
<cx405> tilpner: you may probably remember me, you massively helped me when I borked the system by flipping the stateVersion before 18.03 was officially released.
<infinisil> Search for stateVersion on that page, there is only 1 item for 18.03 and I doubt you're using it
<cx405> infinisil: I have a problem with relics in configuration. As world moves on, the relics tend to get less attention, so at some point I could end with inconsistency in workaround for current old stateVersion, which would produce bugs that nobody can replicate on fresh system. Actually I though that Nixos does core upgrades (irrevocable, its fine) automatically, so flipping the stateVersion after that would change nothing because the core has
<ottidmes> I think the question was, how to upgrade those DB store paths to the new locations, if we take DBs as an example that use stateVersion and assume they use it for their changed storage location
<cx405> Well, this is not correct. There is a structure, that is from 17.09, which is being worked-around by parsing the stateVersion variable, and I would appreciate if I could get away from this relic. Something like tool in live ISO, that allows to upgrade the core. I don't really need any backward compatibility to 17.09.
<infinisil> cx405: stateVersion is used by nixos for state whose default changed throughout different versions, e.g. a database directory now being in /var/db instead of /var/lib/db. So there is a switch: dbDir = if stateVersion < 18.03 then /var/db else /var/lib/db
<cx405> But how does this var gets updated? I got impression that stateVersion is version of the core, right? I don't have any generation or channel 17.09.
<cx405> infinisil: I already borked one install by changing it and understood that stateVersion is sorta "profile". When could I get upgrade it? I am running nixos on baremetal.
<ottidmes> infinisil: There are only a few packages that actually depend on stateVersion, right, some databases and such?
<infinisil> cx405: Don't change stateVersion

2018-04-03

<tilpner> clever - grep -R stateVersion ~/dev/nixpkgs | grep ssh comes up empty
<clever> Turion: grep nixpkgs for stateVersion
<clever> so if your not using postgress, then that specific problem wont happen for you when changing the stateVersion
<elvishjerricco> Guest29: stateVersion is the version of your state, not the statement of your version :P
<Guest29> then what do I set nix.package to? What exactly is stateVersion for?
<elvishjerricco> That's a mistake I made before I knew what stateVersion was for

2018-03-19

<gchristensen> if you don't run those on your server the stateVersion is unused

2018-03-11

<sphalerite> there's some stuff that's also dictated by stateVersion, like database versions and stuff. But that's part of the config

2018-03-10

<Lisanna> but I'm not changing my stateVersion...

2018-03-07

<clever> if you mess with the stateVersion, it will break the things it was meant to fix

2018-02-23

<NixOS_GitHub> nixpkgs/master e349ccc Aristid Breitkreuz: nixos/alsa: Do not make sound.enable conditional on stateVersion....

2018-02-22

<NixOS_GitHub> nixpkgs/master a43e33d Aristid Breitkreuz: nixos: disable sound by default, if stateVersion >= 18.03 (#35355)
<NixOS_GitHub> [nixpkgs] oxij opened pull request #35366: nixos: properly disable sound by default, if stateVersion > 18.03 (master...pull/35355-no-sound-v2) https://git.io/vAgpa
<NixOS_GitHub> [nixpkgs] aristidb reopened pull request #35355: nixos: disable sound by default, if stateVersion > 18.03 (master...sound-disabled-by-default) https://git.io/vAgi9
<NixOS_GitHub> [nixpkgs] aristidb closed pull request #35355: nixos: disable sound by default, if stateVersion > 18.03 (master...sound-disabled-by-default) https://git.io/vAgi9
<NixOS_GitHub> [nixpkgs] aristidb opened pull request #35355: nixos: disable sound by default, if stateVersion > 18.03 (master...sound-disabled-by-default) https://git.io/vAgi9
<NixOS_GitHub> nixpkgs/sound-disabled-by-default ea48c41 Aristid Breitkreuz: nixos: disable sound by default, if stateVersion > 18.03

2018-02-21

<clever> seequ: the only thing stateVersion does, is adjust what version of something like postgresql you get, to make sure you dont break the on-disk state
<clever> seequ: you always get the version in the channel, stateVersion doesnt control what version you get
<clever> seequ: the stateVersion must always be set to the version you originally installed with

2018-02-12

<{^_^}> All commands: -A ask cloudfront foo let-where library notfound pills send-help stateVersion stuck tofu unfree whichchannel

2018-01-05

<deltasquared> so, this mysterious stateVersion variable, saying it should only be changed when instructed... I'll have to look at what that does later

2017-12-28

<srhb> Acou_Bass: That said, as long as you don't fiddle with stateVersion you should be fine.

2017-12-17

<sudoreboot[m]> LnL: So one is supposed to be able to have the stateversion set to, say, 17.09 and root setting the nixos channel to nixpkgs-unstable?
<clever> sudoreboot[m]: the stateVersion has no control on what channel it uses
<LnL> you should never change the stateVersion

2017-12-05

<gchristensen> stphrolland: no, don't change stateVersion

2017-11-29

<samueldr> fresheyeball: iirc, postgresql will not set a password, it will allow use of `psql` by using `sudo -u root psql` with stateVersion prior to 17.09, and `sudo -u postgres psql` 17.09 and following
<fresheyeball> boxofrox: I am on 17.09, but my configuration.nix stateVersion is 17.03
<clever> thats why its called stateVersion

2017-11-25

<adisbladis> pcarrier: Beware of stateVersion though.

2017-11-19

<Shados> samueldr: Looks like the "Backward Incompatibilities" section has a bit explicitly about stateVersion changes, so that's pretty much what I wanted, thanks
<samueldr> not sure if it's all the things affected, but release notes generally have stateVersion summaries
<tilpner> Alling - You're not supposed to touch stateVersion, in general
<samueldr> keeping an older stateVersion is generally not an issue, but if you're absolutely sure there's nothing that can be lost, it wouldn't be an issue

2017-11-18

<chreekat> hyper_ch: nix-channel says the same, 17.03. (I though stateVersion was something else, but wasn't sure)
<jeaye> neonfuz: Changing stateVersion should only be done once every 6 months or so, when the next release is stable.

2017-11-09

<iqubic> And this is the only time where it makes sense to change stateVersion.

2017-11-07

<LnL> if changing the default has significant brhaviour changes stateVersion should probably be used to avoid breaking stuff

2017-11-05

<sphalerite> you shouldn't need to touch stateVersion

2017-10-26

<LnL> JosW: no don't change stateVersion, that's for backwards compatibility
<JosW> system stateversion to 17.09 thus?
<etu> JosW: You need to update stateVersion in your configuration.nix

2017-10-22

<iqubic> yeah, I'm going to update stateVersion to tell nix that this new machine started life on 17.09 and not 17.03
<clever> yeah, this is the only time its right to update stateVersion

2017-10-20

<infinisil> disasm: adamt_: Well, the module needs to be backwards compatible though, so you may need to do some stateVersion default thing

2017-10-18

<clever> eacameron: and do NOT change the stateVersion in the configuration

2017-10-14

<srhb> Has an earlier stateVersion ever been deprecated yet, and how does that work?

2017-10-13

<disasm> yeah, I know... when I refactored my machine configs all into one repo I must have lost that :( I rolled back to 17.03 adding stateVersion in and will try again
<infinisil> did you change stateVersion?

2017-10-10

<gchristensen> Ralith: https://nixos.org/nixos/manual/release-notes.html#sec-release-17.09 read about each mention of stateVersion before you change it
<hodapp> huh, I am still at stateVersion of 16.09 for some reason

2017-10-09

<srhb> gchristensen: I adviced them to set stateVersion to "17.03" before upgrading to 17.09
<gchristensen> pxc: search.nix.gsc.io + stateVersion :)

2017-10-05

<clever> MichaelRaskin: it needs the stateVersion to continue using the "right" version for your database

2017-10-03

<pstn_matrix_kill> Didn't change stateVersion. Had it moved. Please check.
<srhb> pstn_matrix_kill: Yes, if you change stateVersion

2017-09-29

<LnL> kuznero: don't change the stateVersion that could break stuff

2017-09-18

<clever> Jackneilll: stateVersion tells nixos what version your state is from

2017-09-07

<supremacsy> Hi all! Can anybody suggest anything on how to proceed after a not quite successful upgrade from nixos-16.09 (system.stateVersion = "16.09") to nixos-{17.03,17.09,unstable}? KDE fails to start global shortcuts daemon for all 3 channels I tried. Another system with stateVersion="17.03" is doing perfectly fine with the almost the same set of system packages.

2017-09-06

<sphalerite> so postgres will only be upgraded if the stateVersion has been bumped

2017-08-31

<NixOS_GitHub> nixpkgs/release-17.09 1664e69 Graham Christensen: configuration.nix: Document the stateVersion more...
<NixOS_GitHub> [nixpkgs] grahamc closed pull request #28775: Document the stateVersion more (master...describe-stateVersion) https://git.io/v5lI2
<NixOS_GitHub> [nixpkgs] grahamc opened pull request #28775: Document the stateVersion more (master...describe-stateVersion) https://git.io/v5lI2

2017-07-19

<srhb> krav_: The idea is that the stateversion will prevent breaking (read, possibly destructive) changes to stateful things happening automatically.

2017-07-15

<simpson> pstn: Use the same version of nixpkgs and nixos in both, and then use the same services.openssh clauses in both. That should be sufficient, I think? There's a couple things like stateVersion that affect SSH which you should keep identical too.

2017-07-04

<Infinisil> LnL gchristensen: (regarding my question before) Ah, I didn't know you were talking about stateVersion
<LnL> so if you have stateVersion = "16.09"; you'll stay on the old version so everything keeps working
<LnL> oh the stateVersion
<gchristensen> no, don't change stateVersion

2017-07-02

<clever> spinus: stateVersion controls a range of things that arent backwards compatible, like the postgresql format on-disk, what type of ssh host keys sshd uses, and a few others

2017-06-14

<gchristensen> GlennS: no, stateVersion is used in only a few places:

2017-06-13

<clever> goibhniu: stateVersion also handles that, so when you do switch channels, it will keep using postgress 8

2017-05-30

<clever> jsgrant: the only thing stateVersion controls is the version of pgsql and some sshd config

2017-05-26

<clever> stateVersion tells nixos what version of nixos you originally installed
<clever> b: stateVersion has no impact on what channel it downloads
<clever> a: stateVersion should never be changed

2017-05-25

<clever> personaly, i run nixos-unstable (so i never have to change the channel) and i just delete stateVersion from the config (so such breaking changes happen sooner)
<ekleog> like, the stateVersion upgrade procedure seems nowhere documented, which means people will stay with a pgsql94 I guess?
<clever> ekleog: and i believe only 2 things even use stateVersion, postgres, and sshd (it enables some older less secure ssh host key stuff)
<clever> for postgres, you would need to dump the entire db as sql, delete the db files, update the stateVersion, and re-import it again
<clever> stateVersion tells nixos what version the state was originaly created in
<GiGa|Laptop> OK, so leave stateVersion at 16.09, OK
<ekleog> wait, wasn't stateVersion supposed to be bumped up once you were sure you wouldn't go back to an older revision?
<clever> stateVersion shouldnt be changed

2017-05-21

<gchristensen> Olgierd: to be clear, you shouldn't chhange the stateVersion in your configuration.nix

2017-05-05

<gchristensen> iirc stateVersion is mostly used for cases where it'd break access to the system should it change (like the host ssh keys)
<LnL> that's what stateVersion is used for

2017-04-03

<LnL> gchristensen: nothing uses stateVersion except for postgres AFAIK
<gchristensen> mg_: the stateVersion should not be touched
<mg_> Is it enough to set system.stateVersion = "17.03"; in my conf.nix to upgrade to 17.03, or do I have to do that channel --add stuff as well? Or only that, and don't touch stateVersion?

2017-04-02

<benley> re stateVersion: it appears to be very few things: openstack keystone version, sshd ancient style hostkeys, postgres daemon version, ... and that's it
<simpson> It makes sense to not change stateVersion.
<Yaniel> does it make sense to keep stateVersion in sync with the stable channel?
<simpson> Uh. Don't change stateVersion unless you really mean it.
<lush> fresheyeball: stateVersion?
<lush> do I need to change the stateVersion manually?

2017-03-11

<clever> c0ff33: changing stateVersion will break the things it was meant to protect
<clever> c0ff33: and the whole point of stateVersion, is so nixos knows which version you originaly installed
<joachifm> c0ff33: stateVersion is mostly for modules to use internally, I think
<clever> c0ff33: stateVersion doesnt control what version of nixos you get
<clever> c0ff33: stateVersion doesnt do what you think

2017-03-07

<gchristensen> nekroze: do not increment stateVersion

2017-03-05

<LnL> ^ I feel like stateVersion is more for things liek a database upgrade

2017-01-16

<simpson> gchristensen: So my 15.09 machines in the cloud, which are running a branch based on unstable... When do we stop supporting the 15.09 stateVersion?

2017-01-12

<srhb> ixxie: I don't think stateVersion has anything to do with channel at all (or were you just using it to infer the active channel?)

2016-12-21

<gchristensen> no, stateVersion is only used for 1 or 2 things in nixpkgs that can't be updated
<kmicu> I thought that stateVersion handles that.