jiebi/CodeConvo huggingface dataset:
Code change:
python3Packages.gbinder-python python3Packages.pygobject3 python3Packages.pyclip <ins> gawk </ins> kmod lxc util-linux

Related discussion:
text: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.3.0 desired version: 1.3.3 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Code change:
githubId = 3159451; name = "Nicolas Schneider"; }; <ins> nkje = { name = "Niels Kristian Lyshøj Jensen"; email = "n@nk.je"; github = "NKJe"; githubId = 1102306; keys = [{ longkeyid = "nistp256/0xDE3BADFECD31A89D"; fingerprint = "B956 C6A4 22AF 86A0 8F77  A8CA DE3B ADFE CD31 A89D"; }]; }; </ins> nkpvk = { email = "niko.pavlinek@gmail.com"; github = "nkpvk";

Related discussion:
text: Project description An open source implementation of the Tailscale control server Metadata homepage URL: source URL: license: bsd platforms: linux
Code change:
fpm = config.services.phpfpm.pools.roundcube; localDB = cfg.database.host == "localhost"; user = cfg.database.username; <del> phpWithPspell = pkgs.php.withExtensions ({ enabled, all }: [ all.pspell ] ++ enabled); </del> <ins> phpWithPspell = pkgs.php74.withExtensions ({ enabled, all }: [ all.pspell ] ++ enabled); </ins> in { options.services.roundcube = {

Related discussion:
text: Describe the bug Roundcube just responds with the following message: Same thing in the systemd logs: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Maintainer information:
was just updated to in . That might be the issue. Override the package with maybe?
That was the problem, thank you! PR here:
Code change:
}; } // (args.argsOverride or { })); in <del> { lts = xanmodKernelFor ltsVariant; main = xanmodKernelFor mainVariant; } </del> <ins> xanmodKernelFor variants.${variant} </ins>

Related discussion:
text: Mainline / hardened / testing / ... kernels can be painlessly modified via : Sadly, this does not work with a bunch of other kernel variants: All kernels should honor I am not entirely sure how dynamic binding is implemented in kernel stuff, however slightly changing xanmod parts this way seems to fix : zen and lqx look similar to xanmod, no idea about libre Pinging people who seem to update affected packages often Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same underlying issue as it seems
Can confirm that this patch fix the issue for zen and lqx kernels:
have you submitted these changes as a PR that I can review?
sorry for the late response. I created a new PR with this changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Code change:
installPhase = '' mkdir -p $out/bin cp -r MediaBrowser.Server.Mono/bin/Release Mono/* $out/bin/ <ins> makeWrapper "${mono}/bin/mono" $out/bin/MediaBrowser.Server.Mono  --add-flags "$out/bin/MediaBrowser.Server.Mono.exe -ffmpeg ${ffmpeg}/bin/ffmpeg -ffprobe ${ffmpeg}/bin/ffprobe" </ins> ''; meta = {

Related discussion:
text: Emby uses ffmpeg for transcoding media and for generating thumbnails. Emby fails to find the FFmpeg binary during the setup wizard but can be specified manually if FFmpeg has been installed separately. Add to , browse to , and advance through the wizard. System: 17.03pre92039. (Gorilla) Nix version:nix-env (Nix) 1.11.4 Nixpkgs version: 17.03pre92039.
cc
Funny thing is that I was just watching a movie when I was mentioned on a system without any ffmpeg/ffprobe binary. My system was upgraded from an older version (config was already existing so no check was done by the wizard). I was able to reproduce the issue. Will take a more detailed look at it sometime tomorrow :)
Code change:
xgeometry-select = callPackage ../tools/X11/xgeometry-select { }; <ins> xmake-core-sv = callPackage ../development/libraries/xmake-core-sv { }; </ins> xmlada = callPackage ../development/libraries/ada/xmlada { }; xmlrpc_c = callPackage ../development/libraries/xmlrpc-c { };

Related discussion:
text: Project description A lightweight cross-platform build utility based on Lua Metadata homepage URL: source URL: license: asl20 platforms: unix
Code change:
buildPythonPackage rec { pname = "chex"; <del> version = "0.1.4"; </del> <ins> version = "0.1.5"; </ins> format = "setuptools"; src = fetchFromGitHub { owner = "deepmind"; repo = pname; rev = "refs/tags/v${version}"; <del> hash = "sha256-FiZElESyOVu1VJxUDNiN6HVADiaubDrGdQHYp2CN8f4="; </del> <ins> hash = "sha256-FYB0IhokM74HBY2wOJYE6xJrHxHHWhDSAZpWFs6HFu0="; </ins> }; propagatedBuildInputs = [

Related discussion:
text: Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
Code change:
# The redistArch is the name of the architecture for which the redistributable is built. # It is `"unsupported"` if the redistributable is not supported on the target platform. redistArch = flags.getRedistArch hostPlatform.system; <ins> sourceMatchesHost = flags.getNixSystem redistArch == stdenv.hostPlatform.system; </ins> in backendStdenv.mkDerivation ( finalAttrs: {

Related discussion:
text: should have only eliminated the s and removed some of the platform-based (adding new broken/non-buildable attrs), but instead has changed the actual logic. Since that commit, no longer resolves into but into (note the wrong cuda release), later leading to evaluation errors This currently breaks on Steps to reproduce the behavior: We should probably add some tests for the selection logic as well... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
# `ollama/llm/generate/gen_common.sh` -> "apply temporary patches until fix is upstream" # each update, these patches should be synchronized with the contents of `ollama/llm/patches/` llamacppPatches = [ <del> (preparePatch "01-load-progress.diff" "sha256-K4GryCH/1cl01cyxaMLX3m4mTE79UoGwLMMBUgov+ew=") </del> <ins> (preparePatch "01-load-progress.diff" "sha256-UTmnBS5hQjIL3eXDZc8RBDNJunLlkqJWH20LpXNiGRQ=") </ins> (preparePatch "02-clip-log.diff" "sha256-rMWbl3QgrPlhisTeHwD7EnGRJyOhLB4UeS7rqa0tdXM=") <del> (preparePatch "03-load_exception.diff" "sha256-0XfMtMyg17oihqSFDBakBtAF0JwhsR188D+cOodgvDk=") (preparePatch "04-metal.diff" "sha256-Ne8J9R8NndUosSK0qoMvFfKNwqV5xhhce1nSoYrZo7Y=") (preparePatch "05-default-pretokenizer.diff" "sha256-JnCmFzAkmuI1AqATG3jbX7nGIam4hdDKqqbG5oh7h70=") (preparePatch "06-qwen2.diff" "sha256-nMtoAQUsjYuJv45uTlz8r/K1oF5NUsc75SnhgfSkE30=") (preparePatch "07-gemma.diff" "sha256-dKJrRvg/XC6xtwxLHZ7lFkLNMwT8Ugmd5xRPuKQDXvU=") </del> <ins> (preparePatch "03-load_exception.diff" "sha256-NJkT/k8Mf8HcEMb0XkaLmyUNKV3T+384JRPnmwDI/sk=") (preparePatch "04-metal.diff" "sha256-bPBCfoT3EjZPjWKfCzh0pnCUbM/fGTj37yOaQr+QxQ4=") (preparePatch "05-default-pretokenizer.diff" "sha256-50+mzQBQZmYEhYvARHw/dliH0M/gDOYm2uy/yJupDF4=") (preparePatch "06-qwen2.diff" "sha256-FdDqEIblPy47z3yavKUnaV93Yk+3oboEzj4vHq+R66M=") (preparePatch "07-embeddings.diff" "sha256-lqg2SI0OapD9LCoAG6MJW6HIHXEmCTv7P75rE9yq/Mo=") (preparePatch "08-clip-unicode.diff" "sha256-1qMJoXhDewxsqPbmi+/7xILQfGaybZDyXc5eH0winL8=") (preparePatch "09-pooling.diff" "sha256-7meKWbr06lbVrtxau0AU9BwJ88Z9svwtDXhmHI+hYBk=") </ins> ]; preparePatch = patch: hash: fetchpatch {

Related discussion:
text: Package name: Ollama Latest released version: 0.2.1 <!-- Search your package here: --- Current version on the unstable channel: 0.1.48 Current version on the stable/release channel: 0.1.38 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
hash = "sha256-wvFdjsDtKH7CpbEpQjzWtLC4RVOU9+D2rSK0Xo1cJqo="; }; <del> # https://github.com/draios/sysdig/blob/0.38.0/cmake/modules/driver.cmake </del> <ins> # https://github.com/draios/sysdig/blob/0.38.1/cmake/modules/driver.cmake </ins> driver = fetchFromGitHub { owner = "falcosecurity"; repo = "libs";

Related discussion:
text: Steps to reproduce the behavior: sysdig Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can't repro on master () and the error isn't in the log output, can you provide additional info?
Hey, thanks for the response - checking again - it only happens if for me if I enable the sysdig-option in my config not building the sysdig-package - maybe this helps to reproduce and depends on the used kernel-version? I've uploaded the full build log:
Thanks, seems this is the error:
I guess this is already fixed upstream in the drivers () but needs to be to nixpkgs to fix 6.10-kernel builds.
fixes it for me
~Ah 0.38.1 - got released somehow oversaw it should check first if that includes the fix~ 38.1 does not include a driver-bump
Code change:
nestedTypes.elemType = elemType; }; <ins> # TODO: deprecate this in the future: loaOf = elemType: types.attrsOf elemType // { name = "loaOf"; deprecationMessage = "Mixing lists with attribute values is no longer" + " possible; please use `types.attrsOf` instead. See" + " https://github.com/NixOS/nixpkgs/issues/1800 for the motivation."; nestedTypes.elemType = elemType; }; </ins> # Value of given type but with no merging (i.e. `uniq list`s are not concatenated). uniq = elemType: mkOptionType rec { name = "uniq";

Related discussion:
text: Steps to reproduce the behavior: I updated nixpkgs and now nixops does not work anymore. I don't even use gce, so I'm baffled why it's failing. was still working. In both cases I used the same nixops version 1.7. My config did not change and can be found at <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
In the future, please ping the maintainers as instructed in the template. cc
Thanks for doing that, I didn't know who to ping
loaOf was removed in after many years of being deprecated nixops at 1.7 still had loaOf being used as it was released(2019) before the type was deprecated also cc
I've switched to morph in the meantime. I keep this issue open for if someone wants to fix it.
Not everyone may be able to switch away easily. Simple nixops deployment without cloud resources and static hosts may be easy, but that's not all deployments. Reverting in
Code change:
in fetchurl { url = "http://download.roonlabs.com/builds/RoonServer_linuxx64_${urlVersion}.tar.bz2"; <del> sha256 = "sha256-NSNaL0ERYTSYn9ETjWcQiuI4hY+w/lWVOz3n9lt6O+4="; </del> <ins> sha256 = "sha256-Td3iRYGmTg8Vx9c4e4ugIIbAqhDFPax9vR2BsCIQCZA="; </ins> }; <ins> dontConfigure = true; dontBuild = true; </ins> buildInputs = [ alsa-lib freetype krb5 <ins> libtasn1 </ins> stdenv.cc.cc.lib ];

Related discussion:
text: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: roon-server <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.8-850 desired version: 1.8-880 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Code change:
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}

Related discussion:
text: 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.
Code change:
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}

Related discussion:
text: 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.
Code change:
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}

Related discussion:
text: 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.
Code change:
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}

Related discussion:
text: 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?