jiebi/CodeConvo huggingface dataset:
Code change:
{ lib <ins> , stdenv </ins> , rustPlatform , fetchFromGitHub , asciidoctor

Related discussion:
text: Package name: repgrep Latest released version: 0.15.0 <!-- Search your package here: --- Current version on the unstable channel: 0.14.3 Current version on the stable/release channel: 0.14.3 <!-- 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:
# comments with variant added for update script # ./update-zen.py zen zenVariant = { <del> version = "6.7.5"; #zen </del> <ins> version = "6.7.6"; #zen </ins> suffix = "zen1"; #zen <del> sha256 = "1f7czivsmqzhcbckcyi058lqwa4qds03fmylqa1wa4sybrq4diri"; #zen </del> <ins> sha256 = "1qvnv5jmzf1ziarvxyr81j8cpfnag7vvkpnfja6haba7yjavgvkc"; #zen </ins> isLqx = false; }; # ./update-zen.py lqx lqxVariant = { <del> version = "6.7.5"; #lqx </del> <ins> version = "6.7.6"; #lqx </ins> suffix = "lqx1"; #lqx <del> sha256 = "1vkcl0ll7m60mmd1hbdqi9sj7gq513cadfxaamxzb9isq2c1wa03"; #lqx </del> <ins> sha256 = "1z737ma2ak2yddc416svr5s2f7pl31v1cs2bknl9v6syl6xm9sxk"; #lqx </ins> isLqx = true; }; zenKernelsFor = { version, suffix, sha256, isLqx }: buildLinux (args // {

Related discussion:
text: Package name: linuxKernel.kernels.linux_zen Latest released version: 6.7.6-zen1 <!-- Search your package here: --- Current version on the unstable channel: 6.7.5 Current version on the stable/release channel: 6.6.1 <!-- 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]:
Oh, forgot to do it. Currently not at home. Will see how late it is when I get back. PR will be up tomorrow at the very latest.
PR is up. When it get's merged, I'll close this one.
Code change:
}; requestEncryptionCredentials = mkOption { <del> type = types.bool; </del> <ins> type = types.either types.bool (types.listOf types.str); </ins> default = true; <ins> example = [ "tank" "data" ]; </ins> description = '' <del> Request encryption keys or passwords for all encrypted datasets on import. For root pools the encryption key can be supplied via both an interactive prompt (keylocation=prompt) and from a file (keylocation=file://). </del> <ins> If true on import encryption keys or passwords for all encrypted datasets are requested. To only decrypt selected datasets supply a list of dataset names instead. For root pools the encryption key can be supplied via both an interactive prompt (keylocation=prompt) and from a file (keylocation=file://). </ins> ''; };

Related discussion:
text: Describe the bug I have a ZFS pool with approximately the following layout: The datasets under are those that the local system is installed on and the datasets under are backups from a different machine received via . All datasets are using native ZFS encryption, however, datasets under are encrypted with a different key (that of the machine that sent the backups) than the rest of the pool. When I boot, the initrd will query me for the key for and but this key is not available and I also don't want to make it available for obvious reasons. The culprit lies in this statement in the : This forces loading of all keys, which is a good default, but cannot easily be overridden. My current workaround for this is to turn this off and only load the key for manually. To this end I would like to propose the following patch by which it should be possible to load the key only for the specified datasets. To Reproduce Steps to reproduce the behavior: NixOS with an encrypted ZFS pool a dataset with a different encryption key and set you lost the key for this new dataset errors when mounting due to the lack of keys Expected behavior It should be possible to restrict for which pools and datasets to query encryption credentials. Screenshots N/A Additional context N/A 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 system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
I think you can open a PR with your patch for this one.
Code change:
stdenv.mkDerivation rec { pname = "wayland-protocols"; <del> version = "1.31"; </del> <ins> version = "1.32"; </ins> # https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/48 doCheck = stdenv.hostPlatform == stdenv.buildPlatform && stdenv.targetPlatform.linker == "bfd" && wayland.withLibraries; src = fetchurl { url = "https://gitlab.freedesktop.org/wayland/${pname}/-/releases/${version}/downloads/${pname}-${version}.tar.xz"; <del> hash = "sha256-oH+nIu2HZ27AINhncUvJovJMRk2nORLzlwbu71IZ4jg="; </del> <ins> hash = "sha256-dFl5nTQMgpa2le+FfAfd7yTFoJsJq2p097kmQNKxuhE="; </ins> }; postPatch = lib.optionalString doCheck ''

Related discussion:
text: Package name: wayland-protocols Latest released version: 1.32 <!-- Search your package here: --- Current version on the unstable channel: 1.31 Current version on the stable/release channel: 1.31 <!-- 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 Note for maintainers: Please tag this issue in your PR.
fixed in
Code change:
ninka = callPackage ../development/tools/misc/ninka { }; <del> nodejs-0_12 = callPackage ../development/web/nodejs { libuv = libuvVersions.v1_2_0; }; </del> <ins> nodejs-0_12 = callPackage ../development/web/nodejs { libuv = libuvVersions.v1_6_1; }; </ins> nodejs-unstable = callPackage ../development/web/nodejs { libuv = libuvVersions.v1_2_0; unstableVersion = true; }; nodejs-0_10 = callPackage ../development/web/nodejs/v0_10.nix { };

Related discussion:
text: doesn't build with GHCJS as of due to an issue on and/or as suggested in It looks like this is related to
I'm trying to build again with at the moment, I'll report afterwards if it was successful.
Yep. Updating 's dependency on did the trick. Everything built just fine. See pull-request
Code change:
<del> {pkgs, pkgs_i686}: </del> <ins> {pkgs, pkgs_i686, includeSources ? true}: </ins> rec { platformTools = import ./platform-tools.nix {

Related discussion:
text: Currently, our Android SDK derivations contain only binary files. This is unfortunate during development, when one wants to jump to a definition of a particular symbol in the SDK and it is not found. For comparison, ArchLinux is doing this in their packages, e.g. System: 16.09pre-git (Flounder) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "16.09beta335." /cc
Created PR .
Code change:
passthru = { fancyName = "MariaDB"; <del> driver = "lib/libmyodbc3-3.51.12.so"; </del> <ins> driver = "lib/libmaodbc.so"; </ins> }; meta = with stdenv.lib; {

Related discussion:
text: The file does not exist so ODBC connections fail. The offending line is which should reference . In add: to nixpkgs Create/Edit and add the following: [MyNewDSN] Driver = MariaDB Server = localhost Port = 3306 Database = MyDatabase User = MyUser Password = MyPassword Run Then run: and you get the error: [][unixODBC][Driver Manager]Can't open lib '/nix/store/4cnh6dg7mwhsw0yy7c5ajxhw29l6hwa8-mariadb-connector-odbc-2.0.10/lib/libmyodbc3-' : file not found [ISQL]ERROR: Could not SQLConnect system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Fixed in
Code change:
}: let <del> version = "4.4.0"; </del> <ins> version = "4.4.4"; </ins> libsecp256k1_name = <del> if stdenv.isLinux then "libsecp256k1.so.0" else if stdenv.isDarwin then "libsecp256k1.0.dylib" </del> <ins> if stdenv.isLinux then "libsecp256k1.so.{v}" else if stdenv.isDarwin then "libsecp256k1.{v}.dylib" </ins> else "libsecp256k1${stdenv.hostPlatform.extensions.sharedLibrary}"; libzbar_name =

Related discussion:
text: Package name: electrum Latest released version: 4.4.4 <!-- Search your package here: --- Current version on the unstable channel: 4.4.0 Current version on the stable/release channel: 4.4.0 <!-- 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. Reporters Note: Tried the update locally and got the error Looking at the diff on the electrum github I see the substituteInPlace pattern will no longer match: In:
PR in
Code change:
owner = "KhronosGroup"; repo = "Vulkan-Headers"; rev = "sdk-${version}"; <del> sha256 = "1qggc7dv9jr83xr9w2h375wl3pz3rfgrk9hnrjmylkg9gz4p9q03"; </del> <ins> sha256 = "sha256-SvC0AX1wIZWLzws3ZS8Wi8fbNUw1+An/PRlFIfNj24Y="; </ins> }; meta = with lib; {

Related discussion:
text: name: All packages in current version: 1.2.189.1 desired version: 1.2.200 maintainers: Please tag this issue in your PR.
Code change:
mpv-cheatsheet = callPackage ./mpv-cheatsheet.nix { }; mpv-notify-send = callPackage ./mpv-notify-send.nix { }; mpv-osc-modern = callPackage ./mpv-osc-modern.nix { }; <ins> mpv-osc-tethys = callPackage ./mpv-osc-tethys.nix { }; </ins> mpv-playlistmanager = callPackage ./mpv-playlistmanager.nix { }; mpv-slicing = callPackage ./mpv-slicing.nix { }; mpv-webm = callPackage ./mpv-webm.nix { };

Related discussion:
text: Project description An OSC UI replacement for MPV with icons from the bomi video player. Also contains thumbnail preview and a picture-in-picture button. (MPV Userscript) Metadata homepage URL: source URL: license: unlicensed platforms: unix, linux, darwin
Code change:
<ins> { stdenv, lib, fetchFromGitHub, cmake }: stdenv.mkDerivation rec { pname = "libutp"; version = "unstable-2017-01-02"; src = fetchFromGitHub { # Use transmission fork from post-3.3-transmission branch owner = "transmission"; repo = pname; rev = "fda9f4b3db97ccb243fcbed2ce280eb4135d705b"; sha256 = "CvuZLOBksIl/lS6LaqOIuzNvX3ihlIPjI3Eqwo7YJH0="; }; nativeBuildInputs = [ cmake ]; meta = with lib; { description = "uTorrent Transport Protocol library"; homepage = "https://github.com/transmission/libutp"; license = licenses.mit; maintainers = with maintainers; [ angustrau ]; platforms = platforms.unix; }; } </ins>

Related discussion:
text: Project description Fragments is a modern, responsive and graphical Gnome bittorrent client Metadata homepage URL: source URL: license: gpl3 platforms: linux The new version of Fragments depends on libutp which hopefully gets merged soon. I've opened a pull request for it . for Fragments.
We have transmission and torrential. Maybe that's something for you.
That's true but Fragments is a really neat, easy and modern looking torrent client. It has an adaptive interface which would also work quite well on mobile devices, for example NixOS mobile :+1:
Code change:
<ins> diff --git i/pkgconfig/meson.build w/pkgconfig/meson.build index 8ed8299..594cbfe 100644 --- i/pkgconfig/meson.build +++ w/pkgconfig/meson.build @@ -2,8 +2,8 @@ pkgconf = configuration_data() pkgconf.set('prefix', get_option('prefix')) pkgconf.set('exec_prefix', '${prefix}') -pkgconf.set('libdir', '${prefix}/@0@'.format(get_option('libdir'))) -pkgconf.set('includedir', '${prefix}/@0@'.format(get_option('includedir'))) +pkgconf.set('libdir', join_paths(get_option('prefix'), get_option('libdir'))) +pkgconf.set('includedir', join_paths(get_option('prefix'), get_option('includedir'))) pkgconf.set('GST_API_VERSION', api_version) pkgconf.set('VERSION', gst_version) </ins>

Related discussion:
text: Describe the bug When trying to use this package, I'm getting: To Reproduce Additional context I'm currently disabling gst-rtsp-server's split outputs in order to actually use it. Notify maintainers Maintainer information:
We should probably apply
That patch won't apply. But I managed to apply a different fix based on a common fix to other gst plugins, at .
Code change:
systemd.services = { "nextcloud-setup" = let <ins> c = cfg.config; writePhpArrary = a: "[${concatMapStringsSep "," (val: ''"${toString val}"'') a}]"; </ins> overrideConfig = pkgs.writeText "nextcloud-config.php" '' <?php <ins> ${optionalString (c.dbpassFile != null) '' function nix_read_pwd() { $file = "${c.dbpassFile}"; if (!file_exists($file)) { throw new RuntimeException(sprintf( "Cannot start Nextcloud, dbpass file %s set by NixOS doesn't exist!", $file )); } return trim(file_get_contents($file)); } ''} </ins> $CONFIG = [ 'apps_paths' => [ [ 'path' => '${cfg.home}/apps', 'url' => '/apps', 'writable' => false ],

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:
systemd.services = { "nextcloud-setup" = let <ins> c = cfg.config; writePhpArrary = a: "[${concatMapStringsSep "," (val: ''"${toString val}"'') a}]"; </ins> overrideConfig = pkgs.writeText "nextcloud-config.php" '' <?php <ins> ${optionalString (c.dbpassFile != null) '' function nix_read_pwd() { $file = "${c.dbpassFile}"; if (!file_exists($file)) { throw new RuntimeException(sprintf( "Cannot start Nextcloud, dbpass file %s set by NixOS doesn't exist!", $file )); } return trim(file_get_contents($file)); } ''} </ins> $CONFIG = [ 'apps_paths' => [ [ 'path' => '${cfg.home}/apps', 'url' => '/apps', 'writable' => false ],

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:
systemd.services = { "nextcloud-setup" = let <ins> c = cfg.config; writePhpArrary = a: "[${concatMapStringsSep "," (val: ''"${toString val}"'') a}]"; </ins> overrideConfig = pkgs.writeText "nextcloud-config.php" '' <?php <ins> ${optionalString (c.dbpassFile != null) '' function nix_read_pwd() { $file = "${c.dbpassFile}"; if (!file_exists($file)) { throw new RuntimeException(sprintf( "Cannot start Nextcloud, dbpass file %s set by NixOS doesn't exist!", $file )); } return trim(file_get_contents($file)); } ''} </ins> $CONFIG = [ 'apps_paths' => [ [ 'path' => '${cfg.home}/apps', 'url' => '/apps', 'writable' => false ],

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.