Question:
Data that was once config and recorded on doesn't get updated when the configuration changes. This is a violation of purity. And more than that, it's very surprising when trying to install, hesitating between pgsql and sqlite, and struggling before understanding that the configuration doesn't get used anyway :p cc
that's a bit tough. We have a unit, that's supposed to do the installation. We use the command to install nextcloud (passing the configured database and adminpass settings as command parameters). This CLI generates , and installs nextcloud. The script checks the presence of , and skips installation on following starts. If you now change configuration from the module, we won't run the install command again, as the config file already exists, and assumes nextcloud is already installed.
Hmm… Maybe it would be possible to generate the somewhere in the store, and symlink to it? This way the next time runs it can in addition check whether points to the correct store path. Now, I don't really know what exactly does, so maybe it's not actually possible to do this because eg. one would need to re-run on certain configuration changes? In which case it'd be hard :/ but at least we can maybe make fail or something like that, so that the issue is at least noisy?
I don't recommend to do this, I just tried that (after upgrading one of my personal systems) and this tries to recreate a database schema which can end in very bad results. Unfortunately I doubt that this will work properly, nextcloud wants to merge this during the runtime. E.g. it adds a after a successful or adds trusted domains when running the corresponding command. I'm using this as well now and hitting these issues, unfortunately I don't have useful ideas either ATM, but I'm happy to discuss better solutions :)
Nextcloud edits it's in a lot of different places, so having it generated through Nix currently isn't possible. digs into that already, I a comments about our use case here too.
to avoid other people running into the reconfiguration issue for now, what about documenting that, maybe in ?
That's certainly a good thing to do. If nobody else wants to take over, I'd volunteer to do this during the next week as investing time on improving the nextcloud module is one item on my todo list :) I was aware of being stateful, but thanks a lot for linking the corresponding ticket! I'll have a look at this as soon as I have sufficient time to :)
In the light of this issue, what's the correct way to upgrade nextcloud to a new major version? Do I just pull a newer , upgrade my system and hope that the systemd job will do the right thing?
The service runs an that should apply all changes like database migrations needed for the new Nextcloud version (beware, downgrades aren't possible). As long as you let Nextcloud do its job, you shouldn't get that much issues. IMHO the actual problem here is the configuration of the software within Nix(OS).
just a simple question (could not come to a conclusion after the lengthy thread) but I recently updated my nextcloud via nixops deploy and the update disabled the calendar module. Did I mess up or is that expected ? any way to configure this from nix ?
Assuming that you installed the calendar module via the UI, it is installed in . The beginning of my config reads: So in principle nextcloud can edit the apps installed via the web interface (otherwise you couldn't install them via the interface in the first place).
I don't think there's anything actionable here - the nextcloud nixos module is limited by how Nextcloud (imperatively) manages its configuration. The current state is properly documented in , and we raised our concerns to upstream in - closing this issue, feel free to reopen if there's more to be done.
I think one actionable item would be to have the nextcloud service fail with an explicit error if the configuration being used is not compatible with the configuration defined in the .nix. At least the user would be warned in practice that configuration is not really applied, and not only by the manual that they are relatively unlikely to actually read. Reopening for now, feel free to reclose if you think that's not a reasonable “solution” :)
The problem is we don't know whether the configuration on disk containing database connection information () differs from the one that would be generated through an installation via - we don't render the configuration on our own, but the installer writes it out as a side-effect. If I'm not missing something obvious, checking configuration changes would translate to parsing/evaluating on every nextcloud startup as an , comparing every "interesting" key with the one provided through nixos configuration, and eventually then bailing out if they differ. I'm not sure if that's a road we'd like to go and keep up to date, while the underlying bug is a missing distinction between configuration and state upstream…
Since upstream mixes state and config it's questionable whether their configuration format is somehow supposed to be backwards-compatible (as it's only supposed to be used internally by Nextcloud). Hence I'm afraid that this will make i.e. upgrades even harder in case of configuration changes, so :-1: from me. As the issues are documented in the manual now, folks are warned and I think that this is a better option in contrast to adding more complexity to . I suggest we either close this for the reasons already stated or wait for an appropriate upstream fix.
I really don't feel good having stuff in that's actually a disguised command line… :/ Something that would sound nicer to me would be an executable that the user would have to manually run, and a bare-bones module that does not handle setup or configuration and just makes sure that the systemd unit is setup. At least the error is obvious (enabling the module without having run the executable would fail), all module options actually mean something, and the impure operation is made explicit. Either that or, similar to , rename all the options so it's explicit that they're used only for initial configuration. Would one of these solutions make sense to you?
Me neither, but currently we don't have much choice… I really like the fact that we can set up the Nextcloud instance in an unattended fashion, without having to worry about manual setting things up. I really don't want to end with more imperative setup steps than necessary. In theory, we could move some of the options in to to make it more obvious what isn't applied continuously. But TBH, I'd rather like to see the state/config mixing fixed upstream than having to introduce more mental complexity here, especially if this gets fixed and we end up with both incarnations. Really, this issue only occurs while a user changes nextcloud database parameters (mostly while tweaking his initial setup), and not having read the module documentation, where the behaviour is documented. What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?
Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)

services.postgresql = { <link linkend="opt-services.postgresql.enable">enable</link> = true; <del> <link linkend="opt-services.postgresql.initialScript">initialScript</link> = pkgs.writeText "psql-init" '' CREATE ROLE nextcloud WITH LOGIN; CREATE DATABASE nextcloud WITH OWNER nextcloud; ''; </del> <ins> <link linkend="opt-services.postgresql.ensureDatabases">ensureDatabases</link> = [ "nextcloud" ]; <link linkend="opt-services.postgresql.ensureUsers">ensureUsers</link> = [ { name = "nextcloud"; ensurePermissions."DATABASE nextcloud" = "ALL PRIVILEGES"; } ]; </ins> }; # ensure that postgres is running *before* running the setup


Question:
Data that was once config and recorded on doesn't get updated when the configuration changes. This is a violation of purity. And more than that, it's very surprising when trying to install, hesitating between pgsql and sqlite, and struggling before understanding that the configuration doesn't get used anyway :p cc
that's a bit tough. We have a unit, that's supposed to do the installation. We use the command to install nextcloud (passing the configured database and adminpass settings as command parameters). This CLI generates , and installs nextcloud. The script checks the presence of , and skips installation on following starts. If you now change configuration from the module, we won't run the install command again, as the config file already exists, and assumes nextcloud is already installed.
Hmm… Maybe it would be possible to generate the somewhere in the store, and symlink to it? This way the next time runs it can in addition check whether points to the correct store path. Now, I don't really know what exactly does, so maybe it's not actually possible to do this because eg. one would need to re-run on certain configuration changes? In which case it'd be hard :/ but at least we can maybe make fail or something like that, so that the issue is at least noisy?
I don't recommend to do this, I just tried that (after upgrading one of my personal systems) and this tries to recreate a database schema which can end in very bad results. Unfortunately I doubt that this will work properly, nextcloud wants to merge this during the runtime. E.g. it adds a after a successful or adds trusted domains when running the corresponding command. I'm using this as well now and hitting these issues, unfortunately I don't have useful ideas either ATM, but I'm happy to discuss better solutions :)
Nextcloud edits it's in a lot of different places, so having it generated through Nix currently isn't possible. digs into that already, I a comments about our use case here too.
to avoid other people running into the reconfiguration issue for now, what about documenting that, maybe in ?
That's certainly a good thing to do. If nobody else wants to take over, I'd volunteer to do this during the next week as investing time on improving the nextcloud module is one item on my todo list :) I was aware of being stateful, but thanks a lot for linking the corresponding ticket! I'll have a look at this as soon as I have sufficient time to :)
In the light of this issue, what's the correct way to upgrade nextcloud to a new major version? Do I just pull a newer , upgrade my system and hope that the systemd job will do the right thing?
The service runs an that should apply all changes like database migrations needed for the new Nextcloud version (beware, downgrades aren't possible). As long as you let Nextcloud do its job, you shouldn't get that much issues. IMHO the actual problem here is the configuration of the software within Nix(OS).
just a simple question (could not come to a conclusion after the lengthy thread) but I recently updated my nextcloud via nixops deploy and the update disabled the calendar module. Did I mess up or is that expected ? any way to configure this from nix ?
Assuming that you installed the calendar module via the UI, it is installed in . The beginning of my config reads: So in principle nextcloud can edit the apps installed via the web interface (otherwise you couldn't install them via the interface in the first place).
I don't think there's anything actionable here - the nextcloud nixos module is limited by how Nextcloud (imperatively) manages its configuration. The current state is properly documented in , and we raised our concerns to upstream in - closing this issue, feel free to reopen if there's more to be done.
I think one actionable item would be to have the nextcloud service fail with an explicit error if the configuration being used is not compatible with the configuration defined in the .nix. At least the user would be warned in practice that configuration is not really applied, and not only by the manual that they are relatively unlikely to actually read. Reopening for now, feel free to reclose if you think that's not a reasonable “solution” :)
The problem is we don't know whether the configuration on disk containing database connection information () differs from the one that would be generated through an installation via - we don't render the configuration on our own, but the installer writes it out as a side-effect. If I'm not missing something obvious, checking configuration changes would translate to parsing/evaluating on every nextcloud startup as an , comparing every "interesting" key with the one provided through nixos configuration, and eventually then bailing out if they differ. I'm not sure if that's a road we'd like to go and keep up to date, while the underlying bug is a missing distinction between configuration and state upstream…
Since upstream mixes state and config it's questionable whether their configuration format is somehow supposed to be backwards-compatible (as it's only supposed to be used internally by Nextcloud). Hence I'm afraid that this will make i.e. upgrades even harder in case of configuration changes, so :-1: from me. As the issues are documented in the manual now, folks are warned and I think that this is a better option in contrast to adding more complexity to . I suggest we either close this for the reasons already stated or wait for an appropriate upstream fix.
I really don't feel good having stuff in that's actually a disguised command line… :/ Something that would sound nicer to me would be an executable that the user would have to manually run, and a bare-bones module that does not handle setup or configuration and just makes sure that the systemd unit is setup. At least the error is obvious (enabling the module without having run the executable would fail), all module options actually mean something, and the impure operation is made explicit. Either that or, similar to , rename all the options so it's explicit that they're used only for initial configuration. Would one of these solutions make sense to you?
Me neither, but currently we don't have much choice… I really like the fact that we can set up the Nextcloud instance in an unattended fashion, without having to worry about manual setting things up. I really don't want to end with more imperative setup steps than necessary. In theory, we could move some of the options in to to make it more obvious what isn't applied continuously. But TBH, I'd rather like to see the state/config mixing fixed upstream than having to introduce more mental complexity here, especially if this gets fixed and we end up with both incarnations. Really, this issue only occurs while a user changes nextcloud database parameters (mostly while tweaking his initial setup), and not having read the module documentation, where the behaviour is documented. What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?
Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)

are used internally to configure an HTTP server using <literal><link xlink:href="https://php-fpm.org/">PHP-FPM</link></literal> and <literal>nginx</literal>. The <literal>config</literal> attribute set is <del> used for the <literal>config.php</literal> which is used for the application's configuration. <emphasis>Beware: this isn't entirely pure since the config is modified by the application's runtime!</emphasis> </del> <ins> used by the imperative installer and all values are written to an additional file to ensure that changes can be applied by changing the module's options. </ins> </para> <para> <del> In case the application serves multiple hosts (those are checked with </del> <ins> In case the application serves multiple domains (those are checked with </ins> <literal><link xlink:href="http://php.net/manual/en/reserved.variables.server.php">$_SERVER['HTTP_HOST']</link></literal>) <del> those can be added using </del> <ins> it's needed to add them to </ins> <literal><link linkend="opt-services.nextcloud.config.extraTrustedDomains">services.nextcloud.config.extraTrustedDomains</link></literal>. </para> <ins> <para> Auto updates for Nextcloud apps can be enabled using <literal><link linkend="opt-services.nextcloud.autoUpdateApps.enable">services.nextcloud.autoUpdateApps</link></literal>. </para> </ins> </section> <section xml:id="module-services-nextcloud-pitfalls-during-upgrade"> <title>Pitfalls</title>


Question:
Data that was once config and recorded on doesn't get updated when the configuration changes. This is a violation of purity. And more than that, it's very surprising when trying to install, hesitating between pgsql and sqlite, and struggling before understanding that the configuration doesn't get used anyway :p cc
that's a bit tough. We have a unit, that's supposed to do the installation. We use the command to install nextcloud (passing the configured database and adminpass settings as command parameters). This CLI generates , and installs nextcloud. The script checks the presence of , and skips installation on following starts. If you now change configuration from the module, we won't run the install command again, as the config file already exists, and assumes nextcloud is already installed.
Hmm… Maybe it would be possible to generate the somewhere in the store, and symlink to it? This way the next time runs it can in addition check whether points to the correct store path. Now, I don't really know what exactly does, so maybe it's not actually possible to do this because eg. one would need to re-run on certain configuration changes? In which case it'd be hard :/ but at least we can maybe make fail or something like that, so that the issue is at least noisy?
I don't recommend to do this, I just tried that (after upgrading one of my personal systems) and this tries to recreate a database schema which can end in very bad results. Unfortunately I doubt that this will work properly, nextcloud wants to merge this during the runtime. E.g. it adds a after a successful or adds trusted domains when running the corresponding command. I'm using this as well now and hitting these issues, unfortunately I don't have useful ideas either ATM, but I'm happy to discuss better solutions :)
Nextcloud edits it's in a lot of different places, so having it generated through Nix currently isn't possible. digs into that already, I a comments about our use case here too.
to avoid other people running into the reconfiguration issue for now, what about documenting that, maybe in ?
That's certainly a good thing to do. If nobody else wants to take over, I'd volunteer to do this during the next week as investing time on improving the nextcloud module is one item on my todo list :) I was aware of being stateful, but thanks a lot for linking the corresponding ticket! I'll have a look at this as soon as I have sufficient time to :)
In the light of this issue, what's the correct way to upgrade nextcloud to a new major version? Do I just pull a newer , upgrade my system and hope that the systemd job will do the right thing?
The service runs an that should apply all changes like database migrations needed for the new Nextcloud version (beware, downgrades aren't possible). As long as you let Nextcloud do its job, you shouldn't get that much issues. IMHO the actual problem here is the configuration of the software within Nix(OS).
just a simple question (could not come to a conclusion after the lengthy thread) but I recently updated my nextcloud via nixops deploy and the update disabled the calendar module. Did I mess up or is that expected ? any way to configure this from nix ?
Assuming that you installed the calendar module via the UI, it is installed in . The beginning of my config reads: So in principle nextcloud can edit the apps installed via the web interface (otherwise you couldn't install them via the interface in the first place).
I don't think there's anything actionable here - the nextcloud nixos module is limited by how Nextcloud (imperatively) manages its configuration. The current state is properly documented in , and we raised our concerns to upstream in - closing this issue, feel free to reopen if there's more to be done.
I think one actionable item would be to have the nextcloud service fail with an explicit error if the configuration being used is not compatible with the configuration defined in the .nix. At least the user would be warned in practice that configuration is not really applied, and not only by the manual that they are relatively unlikely to actually read. Reopening for now, feel free to reclose if you think that's not a reasonable “solution” :)
The problem is we don't know whether the configuration on disk containing database connection information () differs from the one that would be generated through an installation via - we don't render the configuration on our own, but the installer writes it out as a side-effect. If I'm not missing something obvious, checking configuration changes would translate to parsing/evaluating on every nextcloud startup as an , comparing every "interesting" key with the one provided through nixos configuration, and eventually then bailing out if they differ. I'm not sure if that's a road we'd like to go and keep up to date, while the underlying bug is a missing distinction between configuration and state upstream…
Since upstream mixes state and config it's questionable whether their configuration format is somehow supposed to be backwards-compatible (as it's only supposed to be used internally by Nextcloud). Hence I'm afraid that this will make i.e. upgrades even harder in case of configuration changes, so :-1: from me. As the issues are documented in the manual now, folks are warned and I think that this is a better option in contrast to adding more complexity to . I suggest we either close this for the reasons already stated or wait for an appropriate upstream fix.
I really don't feel good having stuff in that's actually a disguised command line… :/ Something that would sound nicer to me would be an executable that the user would have to manually run, and a bare-bones module that does not handle setup or configuration and just makes sure that the systemd unit is setup. At least the error is obvious (enabling the module without having run the executable would fail), all module options actually mean something, and the impure operation is made explicit. Either that or, similar to , rename all the options so it's explicit that they're used only for initial configuration. Would one of these solutions make sense to you?
Me neither, but currently we don't have much choice… I really like the fact that we can set up the Nextcloud instance in an unattended fashion, without having to worry about manual setting things up. I really don't want to end with more imperative setup steps than necessary. In theory, we could move some of the options in to to make it more obvious what isn't applied continuously. But TBH, I'd rather like to see the state/config mixing fixed upstream than having to introduce more mental complexity here, especially if this gets fixed and we end up with both incarnations. Really, this issue only occurs while a user changes nextcloud database parameters (mostly while tweaking his initial setup), and not having read the module documentation, where the behaviour is documented. What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?
Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)

</para> <para> <del> Right now changes to the <literal>services.nextcloud.config</literal> attribute set won't take effect after the first install (except <literal><link linkend="opt-services.nextcloud.config.extraTrustedDomains">services.nextcloud.config.extraTrustedDomains</link></literal>) since the actual configuration file is generated by the NextCloud installer which also sets up critical parts such as the database structure. </del> <ins> All configuration parameters are also stored in <literal>/var/lib/nextcloud/config/override.config.php</literal> which is generated by the module and linked from the store to ensure that all values from <literal>config.php</literal> can be modified by the module. However <literal>config.php</literal> manages the application's state and shouldn't be touched manually because of that. </ins> </para> <del> <para> <emphasis>Warning: don't delete <literal>config.php</literal>! This file </del> <ins> <warning> <para>Don't delete <literal>config.php</literal>! This file </ins> tracks the application's state and a deletion can cause unwanted <del> side-effects!</emphasis> </para> </del> <ins> side-effects!</para> </warning> </ins> <del> <para> <emphasis>Warning: don't rerun <literal>nextcloud-occ </del> <ins> <warning> <para>Don't rerun <literal>nextcloud-occ </ins> maintenance:install</literal>! This command tries to install the application <del> and can cause unwanted side-effects!</emphasis> </para> <para> The issues are known and reported in <link xlink:href="https://github.com/NixOS/nixpkgs/issues/49783">#49783</link>, for now it's unfortunately necessary to manually work around these issues. </para> <para> Right now app installation and configuration is done imperatively in the nextcloud web ui or via the <literal>nextcloud-occ</literal> command line utility. You can activate auto updates for your apps via <literal><link linkend="opt-services.nextcloud.autoUpdateApps.enable">services.nextcloud.autoUpdateApps</link></literal>. </para> </del> <ins> and can cause unwanted side-effects!</para> </warning> </ins> </section> </chapter>


Question:
Data that was once config and recorded on doesn't get updated when the configuration changes. This is a violation of purity. And more than that, it's very surprising when trying to install, hesitating between pgsql and sqlite, and struggling before understanding that the configuration doesn't get used anyway :p cc
that's a bit tough. We have a unit, that's supposed to do the installation. We use the command to install nextcloud (passing the configured database and adminpass settings as command parameters). This CLI generates , and installs nextcloud. The script checks the presence of , and skips installation on following starts. If you now change configuration from the module, we won't run the install command again, as the config file already exists, and assumes nextcloud is already installed.
Hmm… Maybe it would be possible to generate the somewhere in the store, and symlink to it? This way the next time runs it can in addition check whether points to the correct store path. Now, I don't really know what exactly does, so maybe it's not actually possible to do this because eg. one would need to re-run on certain configuration changes? In which case it'd be hard :/ but at least we can maybe make fail or something like that, so that the issue is at least noisy?
I don't recommend to do this, I just tried that (after upgrading one of my personal systems) and this tries to recreate a database schema which can end in very bad results. Unfortunately I doubt that this will work properly, nextcloud wants to merge this during the runtime. E.g. it adds a after a successful or adds trusted domains when running the corresponding command. I'm using this as well now and hitting these issues, unfortunately I don't have useful ideas either ATM, but I'm happy to discuss better solutions :)
Nextcloud edits it's in a lot of different places, so having it generated through Nix currently isn't possible. digs into that already, I a comments about our use case here too.
to avoid other people running into the reconfiguration issue for now, what about documenting that, maybe in ?
That's certainly a good thing to do. If nobody else wants to take over, I'd volunteer to do this during the next week as investing time on improving the nextcloud module is one item on my todo list :) I was aware of being stateful, but thanks a lot for linking the corresponding ticket! I'll have a look at this as soon as I have sufficient time to :)
In the light of this issue, what's the correct way to upgrade nextcloud to a new major version? Do I just pull a newer , upgrade my system and hope that the systemd job will do the right thing?
The service runs an that should apply all changes like database migrations needed for the new Nextcloud version (beware, downgrades aren't possible). As long as you let Nextcloud do its job, you shouldn't get that much issues. IMHO the actual problem here is the configuration of the software within Nix(OS).
just a simple question (could not come to a conclusion after the lengthy thread) but I recently updated my nextcloud via nixops deploy and the update disabled the calendar module. Did I mess up or is that expected ? any way to configure this from nix ?
Assuming that you installed the calendar module via the UI, it is installed in . The beginning of my config reads: So in principle nextcloud can edit the apps installed via the web interface (otherwise you couldn't install them via the interface in the first place).
I don't think there's anything actionable here - the nextcloud nixos module is limited by how Nextcloud (imperatively) manages its configuration. The current state is properly documented in , and we raised our concerns to upstream in - closing this issue, feel free to reopen if there's more to be done.
I think one actionable item would be to have the nextcloud service fail with an explicit error if the configuration being used is not compatible with the configuration defined in the .nix. At least the user would be warned in practice that configuration is not really applied, and not only by the manual that they are relatively unlikely to actually read. Reopening for now, feel free to reclose if you think that's not a reasonable “solution” :)
The problem is we don't know whether the configuration on disk containing database connection information () differs from the one that would be generated through an installation via - we don't render the configuration on our own, but the installer writes it out as a side-effect. If I'm not missing something obvious, checking configuration changes would translate to parsing/evaluating on every nextcloud startup as an , comparing every "interesting" key with the one provided through nixos configuration, and eventually then bailing out if they differ. I'm not sure if that's a road we'd like to go and keep up to date, while the underlying bug is a missing distinction between configuration and state upstream…
Since upstream mixes state and config it's questionable whether their configuration format is somehow supposed to be backwards-compatible (as it's only supposed to be used internally by Nextcloud). Hence I'm afraid that this will make i.e. upgrades even harder in case of configuration changes, so :-1: from me. As the issues are documented in the manual now, folks are warned and I think that this is a better option in contrast to adding more complexity to . I suggest we either close this for the reasons already stated or wait for an appropriate upstream fix.
I really don't feel good having stuff in that's actually a disguised command line… :/ Something that would sound nicer to me would be an executable that the user would have to manually run, and a bare-bones module that does not handle setup or configuration and just makes sure that the systemd unit is setup. At least the error is obvious (enabling the module without having run the executable would fail), all module options actually mean something, and the impure operation is made explicit. Either that or, similar to , rename all the options so it's explicit that they're used only for initial configuration. Would one of these solutions make sense to you?
Me neither, but currently we don't have much choice… I really like the fact that we can set up the Nextcloud instance in an unattended fashion, without having to worry about manual setting things up. I really don't want to end with more imperative setup steps than necessary. In theory, we could move some of the options in to to make it more obvious what isn't applied continuously. But TBH, I'd rather like to see the state/config mixing fixed upstream than having to introduce more mental complexity here, especially if this gets fixed and we end up with both incarnations. Really, this issue only occurs while a user changes nextcloud database parameters (mostly while tweaking his initial setup), and not having read the module documentation, where the behaviour is documented. What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?
Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)

dbtype = "pgsql"; dbname = "nextcloud"; dbuser = "nextcloud"; <del> dbhost = "localhost"; dbpassFile = toString (pkgs.writeText "db-pass-file" '' hunter2 ''); </del> <ins> dbhost = "/run/postgresql"; </ins> inherit adminuser; adminpassFile = toString (pkgs.writeText "admin-pass-file" '' ${adminpass}


Question:
Data that was once config and recorded on doesn't get updated when the configuration changes. This is a violation of purity. And more than that, it's very surprising when trying to install, hesitating between pgsql and sqlite, and struggling before understanding that the configuration doesn't get used anyway :p cc
that's a bit tough. We have a unit, that's supposed to do the installation. We use the command to install nextcloud (passing the configured database and adminpass settings as command parameters). This CLI generates , and installs nextcloud. The script checks the presence of , and skips installation on following starts. If you now change configuration from the module, we won't run the install command again, as the config file already exists, and assumes nextcloud is already installed.
Hmm… Maybe it would be possible to generate the somewhere in the store, and symlink to it? This way the next time runs it can in addition check whether points to the correct store path. Now, I don't really know what exactly does, so maybe it's not actually possible to do this because eg. one would need to re-run on certain configuration changes? In which case it'd be hard :/ but at least we can maybe make fail or something like that, so that the issue is at least noisy?
I don't recommend to do this, I just tried that (after upgrading one of my personal systems) and this tries to recreate a database schema which can end in very bad results. Unfortunately I doubt that this will work properly, nextcloud wants to merge this during the runtime. E.g. it adds a after a successful or adds trusted domains when running the corresponding command. I'm using this as well now and hitting these issues, unfortunately I don't have useful ideas either ATM, but I'm happy to discuss better solutions :)
Nextcloud edits it's in a lot of different places, so having it generated through Nix currently isn't possible. digs into that already, I a comments about our use case here too.
to avoid other people running into the reconfiguration issue for now, what about documenting that, maybe in ?
That's certainly a good thing to do. If nobody else wants to take over, I'd volunteer to do this during the next week as investing time on improving the nextcloud module is one item on my todo list :) I was aware of being stateful, but thanks a lot for linking the corresponding ticket! I'll have a look at this as soon as I have sufficient time to :)
In the light of this issue, what's the correct way to upgrade nextcloud to a new major version? Do I just pull a newer , upgrade my system and hope that the systemd job will do the right thing?
The service runs an that should apply all changes like database migrations needed for the new Nextcloud version (beware, downgrades aren't possible). As long as you let Nextcloud do its job, you shouldn't get that much issues. IMHO the actual problem here is the configuration of the software within Nix(OS).
just a simple question (could not come to a conclusion after the lengthy thread) but I recently updated my nextcloud via nixops deploy and the update disabled the calendar module. Did I mess up or is that expected ? any way to configure this from nix ?
Assuming that you installed the calendar module via the UI, it is installed in . The beginning of my config reads: So in principle nextcloud can edit the apps installed via the web interface (otherwise you couldn't install them via the interface in the first place).
I don't think there's anything actionable here - the nextcloud nixos module is limited by how Nextcloud (imperatively) manages its configuration. The current state is properly documented in , and we raised our concerns to upstream in - closing this issue, feel free to reopen if there's more to be done.
I think one actionable item would be to have the nextcloud service fail with an explicit error if the configuration being used is not compatible with the configuration defined in the .nix. At least the user would be warned in practice that configuration is not really applied, and not only by the manual that they are relatively unlikely to actually read. Reopening for now, feel free to reclose if you think that's not a reasonable “solution” :)
The problem is we don't know whether the configuration on disk containing database connection information () differs from the one that would be generated through an installation via - we don't render the configuration on our own, but the installer writes it out as a side-effect. If I'm not missing something obvious, checking configuration changes would translate to parsing/evaluating on every nextcloud startup as an , comparing every "interesting" key with the one provided through nixos configuration, and eventually then bailing out if they differ. I'm not sure if that's a road we'd like to go and keep up to date, while the underlying bug is a missing distinction between configuration and state upstream…
Since upstream mixes state and config it's questionable whether their configuration format is somehow supposed to be backwards-compatible (as it's only supposed to be used internally by Nextcloud). Hence I'm afraid that this will make i.e. upgrades even harder in case of configuration changes, so :-1: from me. As the issues are documented in the manual now, folks are warned and I think that this is a better option in contrast to adding more complexity to . I suggest we either close this for the reasons already stated or wait for an appropriate upstream fix.
I really don't feel good having stuff in that's actually a disguised command line… :/ Something that would sound nicer to me would be an executable that the user would have to manually run, and a bare-bones module that does not handle setup or configuration and just makes sure that the systemd unit is setup. At least the error is obvious (enabling the module without having run the executable would fail), all module options actually mean something, and the impure operation is made explicit. Either that or, similar to , rename all the options so it's explicit that they're used only for initial configuration. Would one of these solutions make sense to you?
Me neither, but currently we don't have much choice… I really like the fact that we can set up the Nextcloud instance in an unattended fashion, without having to worry about manual setting things up. I really don't want to end with more imperative setup steps than necessary. In theory, we could move some of the options in to to make it more obvious what isn't applied continuously. But TBH, I'd rather like to see the state/config mixing fixed upstream than having to introduce more mental complexity here, especially if this gets fixed and we end up with both incarnations. Really, this issue only occurs while a user changes nextcloud database parameters (mostly while tweaking his initial setup), and not having read the module documentation, where the behaviour is documented. What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?
Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)

services.postgresql = { enable = true; <del> initialScript = pkgs.writeText "psql-init" '' create role nextcloud with login password 'hunter2'; create database nextcloud with owner nextcloud; ''; </del> <ins> ensureDatabases = [ "nextcloud" ]; ensureUsers = [ { name = "nextcloud"; ensurePermissions."DATABASE nextcloud" = "ALL PRIVILEGES"; } ]; </ins> }; }; };


Question:
Our current legacy nvidia driver of the 340 branch does not work with kernel version 4.19.2: NixOS is currently on the 340.104 version, but upstream is on 340.107: I hope that updating to 340.107 resolves the issue, but I don't understand how to update the different checksums for the nvidia driver. /nix/store/kic17fw8wil74k04kzh3dha43izrr9j3-bash-interactive-4.4-p23-dev copying path '/nix/store/kic17fw8wil74k04kzh3dha43izrr9j3-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The hashes are located at and can be generated like so: Please try:
Thanks alot for giving me a hand and teaching me how to get those four hashes! :+1: Updating to 340.107 indeed resolves this issue. PR:

beta = stable; legacy_340 = generic { <del> version = "340.104"; sha256_32bit = "1l8w95qpxmkw33c4lsf5ar9w2fkhky4x23rlpqvp1j66wbw1b473"; sha256_64bit = "18k65gx6jg956zxyfz31xdp914sq3msn665a759bdbryksbk3wds"; settingsSha256 = "1vvpqimvld2iyfjgb9wvs7ca0b0f68jzfdpr0icbyxk4vhsq7sxk"; persistencedSha256 = "0zqws2vsrxbxhv6z0nn2galnghcsilcn3s0f70bpm6jqj9wzy7x8"; </del> <ins> version = "340.107"; sha256_32bit = "0mh83affz6bim26ws7kkwwcfj2s6vkdy4d45hifsbshr82qd52wd"; sha256_64bit = "0pv9yv3x0kg9hfkmc50xb54ahxkbnyy2vyy4hj2h0s6m9sb5kqz3"; settingsSha256 = "1rgaa24acdyqa1rqrx56293vxpskr792njqqpigqmps04llsx703"; persistencedSha256 = "0nwv6kh4gxgy80x1zs6gcg5hy3amg25xhsfa2v4mwqa36sblxz6l"; </ins> useGLVND = false; patches = maybePatch_drm_legacy ++ [ ./vm_operations_struct-fault.patch ];


Question:
During configure, ’s configuration script checks for certain features of the command, to quote the source: The latter two are not available on macOS, but nevertheless get enabled (I suppose is in when configuring?). Things we can do: with on darwin. haven’t really looked into how this build system works, but maybe we can pass configure flags to explicitly disable these features no matter what on darwin? it away.
For searchability, a typical error would be:
FTR I’m not quire sure where to apply any of the fixes, probably in . (/cc

''; }); <ins> # On Darwin, git-annex mis-detects options to `cp`, so we wrap the binary to # ensure it uses Nixpkgs' coreutils. git-annex = with pkgs; if (!stdenv.isLinux) then let path = stdenv.lib.makeBinPath [ coreutils ]; in overrideCabal (addBuildTool super.git-annex makeWrapper) (_drv: { postFixup = '' wrapProgram $out/bin/git-annex  --prefix PATH : "${path}" ''; }) else super.git-annex; </ins> # The test suite has undeclared dependencies on git. githash = dontCheck super.githash;


Question:
(this is a qt specific test): Loc: [t-(458)] PASS : TofuInfoTest::cleanupTestCase() Totals: 7 passed, 1 failed, 0 skipped, 0 blacklisted, 1047ms This seems to affect master too, but for some reason it's been built successfully once. The aarch64 build started failing when updating qt5 from 5.11 to 5.12 making it the likely root cause: Edit: the cause was expired testing keys: cc maintainer cc as you've been active in keeping plasma/kde up to date lately. ping staging next:
Did you found ? Sounds very similar and should be fixed...
No didn't find that, but yeah, that sure looks exactly like the same issue. I'm guessing the qt issue were never actually fixed: Blame on the test gives no change at least:
And applying the suggested patch does fix the test: diff +++ gpgme-1.10.0/lang/qt/tests/t- -455,7 +455,7 private Q_SLOTS: QVERIFY(result.numSignatures() == 1); auto sig = result.signatures()[0]; QVERIFY(sig.validity() == Signature::Marginal); QVERIFY(sig.validity() == Signature::Marginal sig.validity() == Signature::Unknown); auto stats = ().userID(0).tofuInfo(); QVERIFY(!stats.isNull());
So, what are we want to do? Do you maybe want to comment on the upstream issue?
Hmm, strange, I'm getting the same failure on master (using ), forcing single core does not fix the problem though, so probably not a race condition. I've reported the failure as you suggested:
The cause is most likely qt 5.11 to 5.12 upgrade, as the aarch64 build started failing the test then:
So the keys used in this test expired on 2019-01-06, which explains why we suddenly saw this without any apparent reason. :
Thanks for fixing this and sorry for my late reply... (Edit: And of course also thanks

{ stdenv, fetchurl, libgpgerror, gnupg, pkgconfig, glib, pth, libassuan , file, which, ncurses <del> , autoreconfHook </del> <ins> , autoreconfHook, fetchpatch </ins> , git , texinfo , qtbase ? null


Question:
(this is a qt specific test): Loc: [t-(458)] PASS : TofuInfoTest::cleanupTestCase() Totals: 7 passed, 1 failed, 0 skipped, 0 blacklisted, 1047ms This seems to affect master too, but for some reason it's been built successfully once. The aarch64 build started failing when updating qt5 from 5.11 to 5.12 making it the likely root cause: Edit: the cause was expired testing keys: cc maintainer cc as you've been active in keeping plasma/kde up to date lately. ping staging next:
Did you found ? Sounds very similar and should be fixed...
No didn't find that, but yeah, that sure looks exactly like the same issue. I'm guessing the qt issue were never actually fixed: Blame on the test gives no change at least:
And applying the suggested patch does fix the test: diff +++ gpgme-1.10.0/lang/qt/tests/t- -455,7 +455,7 private Q_SLOTS: QVERIFY(result.numSignatures() == 1); auto sig = result.signatures()[0]; QVERIFY(sig.validity() == Signature::Marginal); QVERIFY(sig.validity() == Signature::Marginal sig.validity() == Signature::Unknown); auto stats = ().userID(0).tofuInfo(); QVERIFY(!stats.isNull());
So, what are we want to do? Do you maybe want to comment on the upstream issue?
Hmm, strange, I'm getting the same failure on master (using ), forcing single core does not fix the problem though, so probably not a race condition. I've reported the failure as you suggested:
The cause is most likely qt 5.11 to 5.12 upgrade, as the aarch64 build started failing the test then:
So the keys used in this test expired on 2019-01-06, which explains why we suddenly saw this without any apparent reason. :
Thanks for fixing this and sorry for my late reply... (Edit: And of course also thanks

nativeBuildInputs = [ file pkgconfig gnupg autoreconfHook git texinfo ] ++ lib.optionals pythonSupport [ python swig2 which ncurses ]; <ins> patches = [ (fetchpatch { name = "fix-key-expiry.patch"; url = "https://files.gnupg.net/file/data/fehgbjmataj5tc2pnfhj/PHID-FILE-aqck6l4elhw53tjanrie/file"; sha256 = "1h80m045gy7r0g7dzzlfpql6p065x88p274ij9jnf7d4lwwgrf1a"; }) ]; </ins> postPatch ='' substituteInPlace ./configure --replace /usr/bin/file ${file}/bin/file '';


Question:
An update of zip-archive package from 0.3.3 to 0.4 in is causing a runtime error in elm compiler (). It would be good to set the elm's dependency on zip-archive to version < 0.4 until this gets fixed.
probably best to patch it
I think fixes it, will try to find more time to test tomorrow morning.
Shoot, I forgot all about this -- I did confirm that commit fixes it, I will clean up and open a PR soon.

elmPackages = (import ./packages/elm-srcs.nix); versionsDat = ./versions.dat; }; <ins> patches = [ (fetchpatch { url = "https://github.com/elm/compiler/pull/1886/commits/39d86a735e28da514be185d4c3256142c37c2a8a.patch"; sha256 = "0nni5qx1523rjz1ja42z6z9pijxvi3fgbw1dhq5qi11mh1nb9ay7"; }) ]; </ins> buildTools = drv.buildTools or [] ++ [ makeWrapper ]; jailbreak = true; postInstall = ''


Question:
should be enables horizontal scrolling
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .

default = true; description = lib.mdDoc '' <del> Disables horizontal scrolling. When disabled, this driver will discard any horizontal scroll events from libinput. Note that this does not disable horizontal scrolling, it merely discards the horizontal axis from any scroll events. </del> <ins> Enables or disables horizontal scrolling. When disabled, this driver will discard any horizontal scroll events from libinput. This does not disable horizontal scroll events from libinput; it merely discards the horizontal axis from any scroll events. </ins> ''; };


Question:
I tried to enable syncing Unix passwords to Samba via PAM using the option. However, I see a bunch of errors in the logs because the library PAM is looking for, , doesn't exist. Use the following config: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(USER): channels(root): nixpkgs:
Same issue here. The folder it was searching for () only contains on my system. Additionally, querying for presents no results.
Just experienced exactly same issue on 19.03. Is samba broken in this release?
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
It's still relevant now. I noticed this issue in my system logs as well. Samba is not broken, they've just deprecated this feature. See and . Here's a PR for us:

"password sufficient ${pkgs.sssd}/lib/security/pam_sss.so use_authtok"} ${optionalString config.krb5.enable "password sufficient ${pam_krb5}/lib/security/pam_krb5.so use_first_pass"} <del> ${optionalString config.services.samba.syncPasswordsByPam "password optional ${pkgs.samba}/lib/security/pam_smbpass.so nullok use_authtok try_first_pass"} </del> ${optionalString cfg.enableGnomeKeyring "password optional ${pkgs.gnome3.gnome-keyring}/lib/security/pam_gnome_keyring.so use_authtok"}


Question:
I tried to enable syncing Unix passwords to Samba via PAM using the option. However, I see a bunch of errors in the logs because the library PAM is looking for, , doesn't exist. Use the following config: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(USER): channels(root): nixpkgs:
Same issue here. The folder it was searching for () only contains on my system. Additionally, querying for presents no results.
Just experienced exactly same issue on 19.03. Is samba broken in this release?
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
It's still relevant now. I noticed this issue in my system logs as well. Samba is not broken, they've just deprecated this feature. See and . Here's a PR for us:

[global] security = ${cfg.securityType} passwd program = /run/wrappers/bin/passwd %u <del> pam password change = ${smbToString cfg.syncPasswordsByPam} </del> invalid users = ${smbToString cfg.invalidUsers} ${cfg.extraConfig}


Question:
I tried to enable syncing Unix passwords to Samba via PAM using the option. However, I see a bunch of errors in the logs because the library PAM is looking for, , doesn't exist. Use the following config: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(USER): channels(root): nixpkgs:
Same issue here. The folder it was searching for () only contains on my system. Additionally, querying for presents no results.
Just experienced exactly same issue on 19.03. Is samba broken in this release?
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
It's still relevant now. I noticed this issue in my system logs as well. Samba is not broken, they've just deprecated this feature. See and . Here's a PR for us:

{ imports = [ (mkRemovedOptionModule [ "services" "samba" "defaultShare" ] "") <ins> (mkRemovedOptionModule [ "services" "samba" "syncPasswordsByPam" ] "This option has been removed by upstream, see https://bugzilla.samba.org/show_bug.cgi?id=10669#c10") </ins> ]; ###### interface


Question:
I tried to enable syncing Unix passwords to Samba via PAM using the option. However, I see a bunch of errors in the logs because the library PAM is looking for, , doesn't exist. Use the following config: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(USER): channels(root): nixpkgs:
Same issue here. The folder it was searching for () only contains on my system. Additionally, querying for presents no results.
Just experienced exactly same issue on 19.03. Is samba broken in this release?
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
It's still relevant now. I noticed this issue in my system logs as well. Samba is not broken, they've just deprecated this feature. See and . Here's a PR for us:

''; }; <del> syncPasswordsByPam = mkOption { type = types.bool; default = false; description = '' Enabling this will add a line directly after pam_unix.so. Whenever a password is changed the samba password will be updated as well. However, you still have to add the samba password once, using smbpasswd -a user. If you don't want to maintain an extra password database, you still can send plain text passwords which is not secure. ''; }; </del> invalidUsers = mkOption { type = types.listOf types.str; default = [ "root" ];


Question:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.

udev = config.systemd.package; <del> modulesTree = config.system.modulesTree; </del> <ins> kernel-name = config.boot.kernelPackages.kernel.name or "kernel"; modulesTree = config.system.modulesTree.override { name = kernel-name + "-modules"; }; </ins> firmware = config.hardware.firmware;


Question:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.

# The closure of the init script of boot stage 1 is what we put in # the initial RAM disk. initialRamdisk = pkgs.makeInitrd { <ins> name = "initrd-${kernel-name}"; </ins> inherit (config.boot.initrd) compressor prepend; contents =


Question:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.

# `contents = {object = ...; symlink = /init;}' is a typical # argument. <del> { stdenv, perl, cpio, contents, compressor, prepend, ubootTools </del> <ins> { stdenv, perl, cpio, contents, ubootTools , name ? "initrd" , compressor ? "gzip -9n" , prepend ? [] </ins> }: stdenv.mkDerivation rec { <del> name = "initrd"; </del> <ins> inherit name; </ins> builder = ./make-initrd.sh; makeUInitrd = stdenv.hostPlatform.platform.kernelTarget == "uImage";


Question:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.

<del> { stdenv, kmod, modules, buildEnv }: </del> <ins> { stdenv, kmod, modules, buildEnv, name ? "kernel-modules" }: </ins> buildEnv { <del> name = "kernel-modules"; </del> <ins> inherit name; </ins> paths = modules;


Question:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.

makeAutostartItem = callPackage ../build-support/make-startupitem { }; <del> makeInitrd = { contents, compressor ? "gzip -9n", prepend ? [ ] }: callPackage ../build-support/kernel/make-initrd.nix { inherit contents compressor prepend; }; </del> <ins> makeInitrd = callPackage ../build-support/kernel/make-initrd.nix; # Args intentionally left out </ins> makeWrapper = makeSetupHook { deps = [ dieHook ]; substitutions = { shell = pkgs.runtimeShell; }; } ../build-support/setup-hooks/make-wrapper.sh;


Question: I have been burned by this several times; and I am not alone: When calling with multiple arguments, we should either patch all of them or print an error. Ignoring arguments silently should be a crime. cc

# /usr/bin/env gets special treatment so that ".../bin/env python" is # rewritten to /nix/store/<hash>/bin/python.  Interpreters that are # already in the store are left untouched. <ins> # A script file must be marked as executable, otherwise it will not be # considered. </ins> fixupOutputHooks+=(patchShebangsAuto) <del> # Run patch shebangs on a directory. # patchShebangs [--build | --host] directory </del> <ins> # Run patch shebangs on a directory or file. # Can take multiple paths as arguments. # patchShebangs [--build | --host] PATH... </ins> # Flags: # --build : Lookup commands available at build-time


Question: I have been burned by this several times; and I am not alone: When calling with multiple arguments, we should either patch all of them or print an error. Ignoring arguments silently should be a crime. cc

shift fi <del> local dir="$1" header "patching script interpreter paths in $dir" </del> <ins> echo "patching script interpreter paths in $@" </ins> local f local oldPath local newPath


Question: I have been burned by this several times; and I am not alone: When calling with multiple arguments, we should either patch all of them or print an error. Ignoring arguments silently should be a crime. cc

local oldInterpreterLine local newInterpreterLine <del> [ -e "$dir" ] || return 0 </del> <ins> if [ $# -eq 0 ]; then echo "No arguments supplied to patchShebangs" >0 return 0 fi </ins> local f while IFS= read -r -d $'0' f; do


Question: I have been burned by this several times; and I am not alone: When calling with multiple arguments, we should either patch all of them or print an error. Ignoring arguments silently should be a crime. cc

# - options: something starting with a '-' # - environment variables: foo=bar if $(echo "$arg0" | grep -q -- "^-.*|.*=.*"); then <del> echo "$f: unsupported interpreter directive "$oldInterpreterLine" (set dontPatchShebangs=1 and handle shebang patching yourself)" </del> <ins> echo "$f: unsupported interpreter directive "$oldInterpreterLine" (set dontPatchShebangs=1 and handle shebang patching yourself)" >0 </ins> exit 1 fi


Question: I have been burned by this several times; and I am not alone: When calling with multiple arguments, we should either patch all of them or print an error. Ignoring arguments silently should be a crime. cc

rm "$timestamp" fi fi <del> done < <(find "$dir" -type f -perm -0100 -print0) </del> <ins> done < <(find "$@" -type f -perm -0100 -print0) </ins> stopNest }


Question: building some cross-compiled packages and inspecting their run-time closures: will show that depends on (on master ). this is because the package isn't spliced correctly: The cross compiled packages depend on the folder, but this path also contains x86 binaries in it! (like ). This causes a bunch of other run-time x86 dependencies to be packaged with the cross-compiled binaries. pointed me here: , which is possibly broken. Trying to move the ARM libs into the output caused a cyclic dependency between the lib output and the normal output :( so I'm stuck & posting this issue. build a cross-compiled binary with a cross , notice that it has x86 binaries in it's run-time closure (assuming the build system is x86): system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:

// lib.optionalAttrs (stdenv.hostPlatform != stdenv.buildPlatform) { preInstall = null; # clobber the native hook <del> dontStrip = true; separateDebugInfo = false; # this is currently broken for crossDrv </del> # To avoid a dependency on the build system 'bash'. preFixup = '' rm -f $bin/bin/{ldd,tzselect,catchsegv,xtrace}


Question:
fails with the vdirsyncer version from nixos-unstable. it works if I install vdirsyncer with pip. Output of :
Which do you get via ? Is it the old 0.16 branch or the new 0.17 one (which was mostly rewritten in rust)? We have the latest git version of 0.17 in nixpkgs. Unfortunately, so it might be some time before this bug is fixed.
outputs this:
Same problem here. Was there any reason to go for an alpha release except for the issue referenced in ? If not, a downgrade to 0.16.7 should be fine, since the original bug is still open and probably won't be fixed for a while without anyone maintaining vdirsyncer.
There are , so I'd rather not downgrade. I'd be happy with a package for the 0.16 branch though.
That'd be great! I haven't looked into packaging yet, so it would take some time if I tried. Would you mind helping out?
I just opened a PR. It’s my first time contributing to , so I hope it’s up to snuff.

github = "lo1tuma"; name = "Mathias Schreck"; }; <ins> loewenheim = { email = "loewenheim@mailbox.org"; github = "loewenheim"; name = "Sebastian Zivota"; }; </ins> lopsided98 = { email = "benwolsieffer@gmail.com"; github = "lopsided98";


Question:
fails with the vdirsyncer version from nixos-unstable. it works if I install vdirsyncer with pip. Output of :
Which do you get via ? Is it the old 0.16 branch or the new 0.17 one (which was mostly rewritten in rust)? We have the latest git version of 0.17 in nixpkgs. Unfortunately, so it might be some time before this bug is fixed.
outputs this:
Same problem here. Was there any reason to go for an alpha release except for the issue referenced in ? If not, a downgrade to 0.16.7 should be fine, since the original bug is still open and probably won't be fixed for a while without anyone maintaining vdirsyncer.
There are , so I'd rather not downgrade. I'd be happy with a package for the 0.16 branch though.
That'd be great! I haven't looked into packaging yet, so it would take some time if I tried. Would you mind helping out?
I just opened a PR. It’s my first time contributing to , so I hope it’s up to snuff.

<ins> { lib, python3Packages, fetchpatch }: # Packaging documentation at: # https://github.com/pimutils/vdirsyncer/blob/0.16.7/docs/packaging.rst python3Packages.buildPythonApplication rec { version = "0.16.7"; pname = "vdirsyncer"; src = python3Packages.fetchPypi { inherit pname version; sha256 = "6c9bcfb9bcb01246c83ba6f8551cf54c58af3323210755485fc23bb7848512ef"; }; propagatedBuildInputs = with python3Packages; [ click click-log click-threading requests_toolbelt requests requests_oauthlib # required for google oauth sync atomicwrites ]; nativeBuildInputs = with python3Packages; [ setuptools_scm ]; checkInputs = with python3Packages; [ hypothesis pytest pytest-localserver pytest-subtesthack ]; patches = [ # Fixes for hypothesis: https://github.com/pimutils/vdirsyncer/pull/779 (fetchpatch { url = https://github.com/pimutils/vdirsyncer/commit/22ad88a6b18b0979c5d1f1d610c1d2f8f87f4b89.patch; sha256 = "0dbzj6jlxhdidnm3i21a758z83sdiwzhpd45pbkhycfhgmqmhjpl"; }) ]; postPatch = '' # Invalid argument: 'perform_health_check' is not a valid setting substituteInPlace tests/conftest.py  --replace "perform_health_check=False" "" substituteInPlace tests/unit/test_repair.py  --replace $'@settings(perform_health_check=False)  # Using the random module for UIDsn' "" ''; checkPhase = '' make DETERMINISTIC_TESTS=true test ''; meta = with lib; { homepage = https://github.com/pimutils/vdirsyncer; description = "Synchronize calendars and contacts"; license = licenses.mit; maintainers = with maintainers; [ loewenheim ]; }; } </ins>


Question:
fails with the vdirsyncer version from nixos-unstable. it works if I install vdirsyncer with pip. Output of :
Which do you get via ? Is it the old 0.16 branch or the new 0.17 one (which was mostly rewritten in rust)? We have the latest git version of 0.17 in nixpkgs. Unfortunately, so it might be some time before this bug is fixed.
outputs this:
Same problem here. Was there any reason to go for an alpha release except for the issue referenced in ? If not, a downgrade to 0.16.7 should be fine, since the original bug is still open and probably won't be fixed for a while without anyone maintaining vdirsyncer.
There are , so I'd rather not downgrade. I'd be happy with a package for the 0.16 branch though.
That'd be great! I haven't looked into packaging yet, so it would take some time if I tried. Would you mind helping out?
I just opened a PR. It’s my first time contributing to , so I hope it’s up to snuff.

inherit (darwin.apple_sdk.frameworks) Security; }; <ins> vdirsyncerStable = callPackage ../tools/misc/vdirsyncer/stable.nix { }; </ins> vdpauinfo = callPackage ../tools/X11/vdpauinfo { }; verbiste = callPackage ../applications/misc/verbiste {


Question:
After in nixops, we can remove the locally pinned version in nixpkgs.
Not yet, I would like to keep those for building nixops v1.6.1 for any users of the Azure backend.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .

<del> { pkgs , buildPythonPackage , fetchPypi , python , azure-mgmt-common }: buildPythonPackage rec { version = "0.20.1"; pname = "azure-mgmt-compute"; src = fetchPypi { inherit pname version; extension = "zip"; sha256 = "97298fc7f133f1d50a974ed6299151eda494a574b0f7fdf8192a388015c2215a"; }; preConfigure = '' # Patch to make this package work on requests >= 2.11.x # CAN BE REMOVED ON NEXT PACKAGE UPDATE sed -i 's|len(request_content)|str(len(request_content))|' azure/mgmt/compute/computemanagement.py ''; postInstall = '' echo "__import__('pkg_resources').declare_namespace(__name__)" >> "$out/lib/${python.libPrefix}"/site-packages/azure/__init__.py echo "__import__('pkg_resources').declare_namespace(__name__)" >> "$out/lib/${python.libPrefix}"/site-packages/azure/mgmt/__init__.py ''; propagatedBuildInputs = [ azure-mgmt-common ]; meta = with pkgs.lib; { description = "Microsoft Azure SDK for Python"; homepage = "https://azure.microsoft.com/en-us/develop/python/"; license = licenses.asl20; maintainers = with maintainers; [ olcai ]; }; } </del>


Question:
After in nixops, we can remove the locally pinned version in nixpkgs.
Not yet, I would like to keep those for building nixops v1.6.1 for any users of the Azure backend.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .

<del> { pkgs , buildPythonPackage , fetchPypi , azure-mgmt-common , python }: buildPythonPackage rec { version = "0.20.1"; pname = "azure-mgmt-network"; src = fetchPypi { inherit pname version; extension = "zip"; sha256 = "10vj22h6nxpw0qpvib5x2g6qs5j8z31142icvh4qk8k40fcrs9hx"; }; preConfigure = '' # Patch to make this package work on requests >= 2.11.x # CAN BE REMOVED ON NEXT PACKAGE UPDATE sed -i 's|len(request_content)|str(len(request_content))|' azure/mgmt/network/networkresourceprovider.py ''; postInstall = '' echo "__import__('pkg_resources').declare_namespace(__name__)" >> "$out/lib/${python.libPrefix}"/site-packages/azure/__init__.py echo "__import__('pkg_resources').declare_namespace(__name__)" >> "$out/lib/${python.libPrefix}"/site-packages/azure/mgmt/__init__.py ''; propagatedBuildInputs = [ azure-mgmt-common ]; meta = with pkgs.lib; { description = "Microsoft Azure SDK for Python"; homepage = "https://azure.microsoft.com/en-us/develop/python/"; license = licenses.asl20; maintainers = with maintainers; [ olcai ]; }; } </del>


Question:
After in nixops, we can remove the locally pinned version in nixpkgs.
Not yet, I would like to keep those for building nixops v1.6.1 for any users of the Azure backend.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .

<del> { pkgs , buildPythonPackage , fetchPypi , azure-nspkg }: buildPythonPackage rec { version = "1.0.0"; pname = "azure-mgmt-nspkg"; src = fetchPypi { inherit pname version; extension = "zip"; sha256 = "1rq92fj3kvnqkk18596dybw0kvhgscvc6cd8hp1dhy3wrkqnhwmq"; }; propagatedBuildInputs = [ azure-nspkg ]; meta = with pkgs.lib; { description = "Microsoft Azure SDK for Python"; homepage = "https://azure.microsoft.com/en-us/develop/python/"; license = licenses.asl20; maintainers = with maintainers; [ olcai ]; }; } </del>


Question:
After in nixops, we can remove the locally pinned version in nixpkgs.
Not yet, I would like to keep those for building nixops v1.6.1 for any users of the Azure backend.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .

<del> { pkgs , buildPythonPackage , fetchPypi , python , azure-mgmt-common }: buildPythonPackage rec { version = "0.20.1"; pname = "azure-mgmt-resource"; src = fetchPypi { inherit pname version; extension = "zip"; sha256 = "0slh9qfm5nfacrdm3lid0sr8kwqzgxvrwf27laf9v38kylkfqvml"; }; preConfigure = '' # Patch to make this package work on requests >= 2.11.x # CAN BE REMOVED ON NEXT PACKAGE UPDATE sed -i 's|len(request_content)|str(len(request_content))|' azure/mgmt/resource/resourcemanagement.py ''; postInstall = '' echo "__import__('pkg_resources').declare_namespace(__name__)" >> "$out/lib/${python.libPrefix}"/site-packages/azure/__init__.py echo "__import__('pkg_resources').declare_namespace(__name__)" >> "$out/lib/${python.libPrefix}"/site-packages/azure/mgmt/__init__.py ''; propagatedBuildInputs = [ azure-mgmt-common ]; meta = with pkgs.lib; { description = "Microsoft Azure SDK for Python"; homepage = "https://azure.microsoft.com/en-us/develop/python/"; license = licenses.asl20; maintainers = with maintainers; [ olcai ]; }; } </del>


Question:
After in nixops, we can remove the locally pinned version in nixpkgs.
Not yet, I would like to keep those for building nixops v1.6.1 for any users of the Azure backend.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .

<del> { pkgs , buildPythonPackage , fetchPypi , python , azure-mgmt-common }: buildPythonPackage rec { version = "0.20.0"; pname = "azure-mgmt-storage"; src = fetchPypi { inherit pname version; extension = "zip"; sha256 = "16iw7hqhq97vlzfwixarfnirc60l5mz951p57brpcwyylphl3yim"; }; preConfigure = '' # Patch to make this package work on requests >= 2.11.x # CAN BE REMOVED ON NEXT PACKAGE UPDATE sed -i 's|len(request_content)|str(len(request_content))|' azure/mgmt/storage/storagemanagement.py ''; postInstall = '' echo "__import__('pkg_resources').declare_namespace(__name__)" >> "$out/lib/${python.libPrefix}"/site-packages/azure/__init__.py echo "__import__('pkg_resources').declare_namespace(__name__)" >> "$out/lib/${python.libPrefix}"/site-packages/azure/mgmt/__init__.py ''; propagatedBuildInputs = [ azure-mgmt-common ]; meta = with pkgs.lib; { description = "Microsoft Azure SDK for Python"; homepage = "https://azure.microsoft.com/en-us/develop/python/"; license = licenses.asl20; maintainers = with maintainers; [ olcai ]; }; } </del>


Question:
After in nixops, we can remove the locally pinned version in nixpkgs.
Not yet, I would like to keep those for building nixops v1.6.1 for any users of the Azure backend.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .

<del> { pkgs , buildPythonPackage , fetchPypi , python , azure-common , futures , python-dateutil , requests , isPy3k }: buildPythonPackage rec { version = "0.20.3"; pname = "azure-storage"; src = fetchPypi { inherit pname version; extension = "zip"; sha256 = "06bmw6k2000kln5jwk5r9bgcalqbyvqirmdh9gq4s6nb4fv3c0jb"; }; propagatedBuildInputs = [ azure-common python-dateutil requests ] ++ pkgs.lib.optionals (!isPy3k) [ futures ]; postInstall = '' echo "__import__('pkg_resources').declare_namespace(__name__)" >> "$out/lib/${python.libPrefix}"/site-packages/azure/__init__.py ''; meta = with pkgs.lib; { description = "Microsoft Azure SDK for Python"; homepage = "https://azure.microsoft.com/en-us/develop/python/"; license = licenses.asl20; maintainers = with maintainers; [ olcai ]; }; } </del>


Question:
It should always show the NixOS version. Reproducible on: Lenovo Thinkpad X230 with grub Not reproducible on: Apple iMac 11,3 with systemd-boot (EFI) Thinkpad L470 with systemd-boot (EFI) system down system system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs:
I can second this. It's been the case for ages.
Yes, I'm not sure why this is. It used to show it at startup, and I don't think anything much has changed there.
I did an update yesterday and bootet the system today and the version was shown. It's a Thinkpad L470. I will see if it fixes it also on the system i used when reporting this issue. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Doesn't work here on latest unstable.
Seems to be a problem specifically with GRUB.
I'm using systemd-boot, not GRUB.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Problem persists.
This is because the Plymouth plugin is missing from the initrd, along with a font with which to render the text. See .

enable = mkEnableOption "Plymouth boot splash screen"; <ins> font = mkOption { default = "${pkgs.dejavu_fonts.minimal}/share/fonts/truetype/DejaVuSans.ttf"; type = types.path; description = '' Font file made available for displaying text on the splash screen. ''; }; </ins> themePackages = mkOption { default = [ nixosBreezePlymouth ]; type = types.listOf types.package;


Question:
It should always show the NixOS version. Reproducible on: Lenovo Thinkpad X230 with grub Not reproducible on: Apple iMac 11,3 with systemd-boot (EFI) Thinkpad L470 with systemd-boot (EFI) system down system system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs:
I can second this. It's been the case for ages.
Yes, I'm not sure why this is. It used to show it at startup, and I don't think anything much has changed there.
I did an update yesterday and bootet the system today and the version was shown. It's a Thinkpad L470. I will see if it fixes it also on the system i used when reporting this issue. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Doesn't work here on latest unstable.
Seems to be a problem specifically with GRUB.
I'm using systemd-boot, not GRUB.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Problem persists.
This is because the Plymouth plugin is missing from the initrd, along with a font with which to render the text. See .

mkdir -p $out/lib/plymouth/renderers # module might come from a theme <del> cp ${themesEnv}/lib/plymouth/{text,details,$moduleName}.so $out/lib/plymouth </del> <ins> cp ${themesEnv}/lib/plymouth/{text,details,label,$moduleName}.so $out/lib/plymouth </ins> cp ${plymouth}/lib/plymouth/renderers/{drm,frame-buffer}.so $out/lib/plymouth/renderers mkdir -p $out/share/plymouth/themes


Question:
It should always show the NixOS version. Reproducible on: Lenovo Thinkpad X230 with grub Not reproducible on: Apple iMac 11,3 with systemd-boot (EFI) Thinkpad L470 with systemd-boot (EFI) system down system system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs:
I can second this. It's been the case for ages.
Yes, I'm not sure why this is. It used to show it at startup, and I don't think anything much has changed there.
I did an update yesterday and bootet the system today and the version was shown. It's a Thinkpad L470. I will see if it fixes it also on the system i used when reporting this issue. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Doesn't work here on latest unstable.
Seems to be a problem specifically with GRUB.
I'm using systemd-boot, not GRUB.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Problem persists.
This is because the Plymouth plugin is missing from the initrd, along with a font with which to render the text. See .

cp -r themes/* $out/share/plymouth/themes cp ${cfg.logo} $out/share/plymouth/logo.png <ins> mkdir -p $out/share/fonts cp ${cfg.font} $out/share/fonts mkdir -p $out/etc/fonts cat > $out/etc/fonts/fonts.conf <<EOF <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd"> <fontconfig> <dir>$out/share/fonts</dir> </fontconfig> EOF </ins> ''; boot.initrd.extraUtilsCommandsTest = ''


Question:
It should always show the NixOS version. Reproducible on: Lenovo Thinkpad X230 with grub Not reproducible on: Apple iMac 11,3 with systemd-boot (EFI) Thinkpad L470 with systemd-boot (EFI) system down system system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs:
I can second this. It's been the case for ages.
Yes, I'm not sure why this is. It used to show it at startup, and I don't think anything much has changed there.
I did an update yesterday and bootet the system today and the version was shown. It's a Thinkpad L470. I will see if it fixes it also on the system i used when reporting this issue. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Doesn't work here on latest unstable.
Seems to be a problem specifically with GRUB.
I'm using systemd-boot, not GRUB.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Problem persists.
This is because the Plymouth plugin is missing from the initrd, along with a font with which to render the text. See .

ln -s $extraUtils/share/plymouth/logo.png /etc/plymouth/logo.png ln -s $extraUtils/share/plymouth/themes /etc/plymouth/themes ln -s $extraUtils/lib/plymouth /etc/plymouth/plugins <ins> ln -s $extraUtils/etc/fonts /etc/fonts </ins> plymouthd --mode=boot --pid-file=/run/plymouth/pid --attach-to-session plymouth show-splash


Question: The rust crate "built" assumes that certain environment variables are always set -- to an empty string if necessary. This is what cargo does, so let's emulate that. See for more details. See I am preparing a patch to fix this, so I skip this.

, completeDeps , crateAuthors , crateDescription <ins> , crateHomepage </ins> , crateFeatures , crateName , crateVersion


Question: The rust crate "built" assumes that certain environment variables are always set -- to an empty string if necessary. This is what cargo does, so let's emulate that. See for more details. See I am preparing a patch to fix this, so I skip this.

export CARGO_PKG_VERSION_MAJOR=${builtins.elemAt version 0} export CARGO_PKG_VERSION_MINOR=${builtins.elemAt version 1} export CARGO_PKG_VERSION_PATCH=${builtins.elemAt version 2} <ins> export CARGO_PKG_VERSION_PRE="${versionPre}" export CARGO_PKG_HOMEPAGE="${crateHomepage}" </ins> export NUM_JOBS=1 export RUSTC="rustc" export RUSTDOC="rustdoc" <del> if [[ -n "${versionPre}" ]]; then export CARGO_PKG_VERSION_PRE="${versionPre}" fi </del> BUILD="" if [[ ! -z "${build}" ]] ; then