jiebi/CodeConvo huggingface dataset:
Code change:
Agda 2.6.4.1 a configure flag that controls whether debug printing (with ) is enabled (previously it was always enabled). Should we enable this? I am leaning strongly towards "yes" as I use debug printing quite often and it would suck to have to rebuild Agda. cc
is there any downside to enabling it?
Performance is , though I'd say not in a way that matters.
If it was true by default before, we should keep that default. We can add an option to the derivation to make it configurable.
Opened I am not sure how to add an option to the derivation (I think should do) and I don't have enough motivation to add an option to the wrapper.

Related discussion:
text: hash = "sha256-0U6s6sXdynk2IWRBDXBJCf7Gc+gE8AhR1PXZl0DS4yU="; }; <del> # We don't need anything in support; avoid installing LICENSE.agda </del> postPatch = '' <ins> # We don't need anything in support; avoid installing LICENSE.agda </ins> rm -rf support <ins> # Remove verbosity options as they make Agda take longer and use more memory. shopt -s globstar extglob sed -Ei '/OPTIONS/s/ -v ?[^ #]+//g' src/**/*.@(agda|lagda.md) </ins> ''; libraryName = "1lab";
Code change:
Package name: brlcad Latest released version: 7.38.0 Current version on the unstable channel: 7.34.2 Current version on the stable/release channel: 7.34.2 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: { lib , stdenv , fetchFromGitHub <ins> , fetchpatch </ins> , cmake , fontconfig , libX11
Code change:
Package name: brlcad Latest released version: 7.38.0 Current version on the unstable channel: 7.34.2 Current version on the stable/release channel: 7.34.2 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: stdenv.mkDerivation rec { pname = "brlcad"; <del> version = "7.34.2"; </del> <ins> version = "7.38.2"; </ins> src = fetchFromGitHub { owner = "BRL-CAD"; <del> repo = pname; </del> <ins> repo = "brlcad"; </ins> rev = "refs/tags/rel-${lib.replaceStrings [ "." ] [ "-" ] version}"; <del> hash = "sha256-oafu255xElEIk8p4yvNyR2maykUfxQui/L5MkicA+JA="; </del> <ins> hash = "sha256-23UTeH4gY2x/QGYZ64glAkf6LmsXBAppIOHgoUdxgpo="; </ins> }; <ins> patches = [ # This commit was bringing an impurity in the rpath resulting in: # RPATH of binary /nix/store/rq2hjvfgq2nvh5zxch51ij34rqqdpark-brlcad-7.38.0/bin/tclsh contains a forbidden reference to /build/ (fetchpatch { url = "https://github.com/BRL-CAD/brlcad/commit/fbdbf042b2db4c7d46839a17bbf4985cdb81f0ae.patch"; revert = true; hash = "sha256-Wfihd7TLkE8aOpLdDtYmhhd7nZijiVGh1nbUjWr/BjQ="; }) ]; </ins> nativeBuildInputs = [ cmake ];
Code change:
Package name: brlcad Latest released version: 7.38.0 Current version on the unstable channel: 7.34.2 Current version on the stable/release channel: 7.34.2 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

Related discussion:
text: "-DBRLCAD_ENABLE_STRICT=OFF" ]; <ins> env.NIX_CFLAGS_COMPILE = toString [ # Needed with GCC 12 "-Wno-error=array-bounds" ]; </ins> meta = with lib; { homepage = "https://brlcad.org"; description = "BRL-CAD is a powerful cross-platform open source combinatorial solid modeling system"; <ins> changelog = "https://github.com/BRL-CAD/brlcad/releases/tag/${src.rev}"; </ins> license = with licenses; [ lgpl21 bsd2 ]; maintainers = with maintainers; [ GaetanLepage ]; platforms = platforms.linux; <ins> # error Exactly one of ON_LITTLE_ENDIAN or ON_BIG_ENDIAN should be defined. broken = stdenv.system == "aarch64-linux"; </ins> }; }
Code change:
Package name: unrar Latest released version: 7.00 beta 3 Current version on the unstable channel: 6.2.12 Current version on the stable/release channel: 6.2.12 I receive more and more RAR files which are created with Unrar 7.00 beta versions / require a more recent version tan 6.2.12 I would appreciated if the existing unrar package can be updated or a new unrar-beta package be proposed .. Changelog : Notify maintainers
There was an automatic update in that I marked as draft, exactly because it's in beta. I'd much rather add a new package. what do you think?
I don't think we should update to the beta either. Sometimes I think about adding beta and release candidate versions to package , but that would be a nixpkgs policy discussion.
If people are still creating new RAR files then I don't want to be maintainer of this package. Stop using RAR.

Related discussion:
text: - The `power.ups` module now generates `upsd.conf`, `upsd.users` and `upsmon.conf` automatically from a set of new configuration options. This breaks compatibility with existing `power.ups` setups where these files were created manually. Back up these files before upgrading NixOS. <ins> - `unrar` was updated to v7. See [changelog](https://www.rarlab.com/unrar7notes.htm) for more information. </ins> - `k3s` was updated to [v1.29](https://github.com/k3s-io/k3s/releases/tag/v1.29.1%2Bk3s2). See [changelog and upgrade notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md#urgent-upgrade-notes) for more information. - `k9s` was updated to v0.31. There have been various breaking changes in the config file format,
Code change:
Package name: unrar Latest released version: 7.00 beta 3 Current version on the unstable channel: 6.2.12 Current version on the stable/release channel: 6.2.12 I receive more and more RAR files which are created with Unrar 7.00 beta versions / require a more recent version tan 6.2.12 I would appreciated if the existing unrar package can be updated or a new unrar-beta package be proposed .. Changelog : Notify maintainers
There was an automatic update in that I marked as draft, exactly because it's in beta. I'd much rather add a new package. what do you think?
I don't think we should update to the beta either. Sometimes I think about adding beta and release candidate versions to package , but that would be a nixpkgs policy discussion.
If people are still creating new RAR files then I don't want to be maintainer of this package. Stop using RAR.

Related discussion:
text: <ins> { lib , stdenv , fetchzip }: stdenv.mkDerivation (finalAttrs: { pname = "unrar"; version = "7.0.7"; src = fetchzip { url = "https://www.rarlab.com/rar/unrarsrc-${finalAttrs.version}.tar.gz"; stripRoot = false; hash = "sha256-S7BMywydetDh1GINcK3k3fN9ciDoKTCAe/1tkgykoAQ="; }; sourceRoot = finalAttrs.src.name; postPatch = '' substituteInPlace unrar/makefile  --replace "CXX=" "#CXX="  --replace "STRIP=" "#STRIP="  --replace "AR=" "#AR=" ''; outputs = [ "out" "dev" ]; # `make {unrar,lib}` call `make clean` implicitly # separate build into different dirs to avoid deleting them buildPhase = '' runHook preBuild cp -a unrar libunrar make -C libunrar lib make -C unrar -j1 runHook postBuild ''; installPhase = '' runHook preInstall install -Dm755 unrar/unrar -t $out/bin/ install -Dm644 unrar/{acknow.txt,license.txt} -t $out/share/doc/unrar/ install -Dm755 libunrar/libunrar.so -t $out/lib/ install -Dm644 libunrar/dll.hpp -t $dev/include/unrar/ runHook postInstall ''; setupHook = ./setup-hook.sh; meta = with lib; { description = "Utility for RAR archives"; homepage = "https://www.rarlab.com/"; license = licenses.unfreeRedistributable; mainProgram = "unrar"; maintainers = with maintainers; [ wegank ]; platforms = platforms.all; }; }) </ins>
Code change:
Package name: unrar Latest released version: 7.00 beta 3 Current version on the unstable channel: 6.2.12 Current version on the stable/release channel: 6.2.12 I receive more and more RAR files which are created with Unrar 7.00 beta versions / require a more recent version tan 6.2.12 I would appreciated if the existing unrar package can be updated or a new unrar-beta package be proposed .. Changelog : Notify maintainers
There was an automatic update in that I marked as draft, exactly because it's in beta. I'd much rather add a new package. what do you think?
I don't think we should update to the beta either. Sometimes I think about adding beta and release candidate versions to package , but that would be a nixpkgs policy discussion.
If people are still creating new RAR files then I don't want to be maintainer of this package. Stop using RAR.

Related discussion:
text: <ins> unpackCmdHooks+=(_tryUnrar) _tryUnrar() { if ! [[ "$curSrc" =~ .rar$ ]]; then return 1; fi unrar x "$curSrc" >/dev/null } </ins>
Code change:
Package name: unrar Latest released version: 7.00 beta 3 Current version on the unstable channel: 6.2.12 Current version on the stable/release channel: 6.2.12 I receive more and more RAR files which are created with Unrar 7.00 beta versions / require a more recent version tan 6.2.12 I would appreciated if the existing unrar package can be updated or a new unrar-beta package be proposed .. Changelog : Notify maintainers
There was an automatic update in that I marked as draft, exactly because it's in beta. I'd much rather add a new package. what do you think?
I don't think we should update to the beta either. Sometimes I think about adding beta and release candidate versions to package , but that would be a nixpkgs policy discussion.
If people are still creating new RAR files then I don't want to be maintainer of this package. Stop using RAR.

Related discussion:
text: <ins> { unrar , fetchzip }: unrar.overrideAttrs (finalAttrs: _: { version = "6.2.12"; src = fetchzip { url = "https://www.rarlab.com/rar/unrarsrc-${finalAttrs.version}.tar.gz"; stripRoot = false; hash = "sha256-VAL3o9JGmkAcEssa/P/SL9nyxnigb7dX9YZBHrG9f0A="; }; sourceRoot = finalAttrs.src.name; }) </ins>
Code change:
Package name: unrar Latest released version: 7.00 beta 3 Current version on the unstable channel: 6.2.12 Current version on the stable/release channel: 6.2.12 I receive more and more RAR files which are created with Unrar 7.00 beta versions / require a more recent version tan 6.2.12 I would appreciated if the existing unrar package can be updated or a new unrar-beta package be proposed .. Changelog : Notify maintainers
There was an automatic update in that I marked as draft, exactly because it's in beta. I'd much rather add a new package. what do you think?
I don't think we should update to the beta either. Sometimes I think about adding beta and release candidate versions to package , but that would be a nixpkgs policy discussion.
If people are still creating new RAR files then I don't want to be maintainer of this package. Stop using RAR.

Related discussion:
text: <del> { lib , stdenv , fetchzip }: stdenv.mkDerivation (finalAttrs: { pname = "unrar"; version = "6.2.12"; src = fetchzip { url = "https://www.rarlab.com/rar/unrarsrc-${finalAttrs.version}.tar.gz"; stripRoot = false; hash = "sha256-VAL3o9JGmkAcEssa/P/SL9nyxnigb7dX9YZBHrG9f0A="; }; sourceRoot = finalAttrs.src.name; postPatch = '' substituteInPlace unrar/makefile  --replace "CXX=" "#CXX="  --replace "STRIP=" "#STRIP="  --replace "AR=" "#AR=" ''; outputs = [ "out" "dev" ]; # `make {unrar,lib}` call `make clean` implicitly # separate build into different dirs to avoid deleting them buildPhase = '' runHook preBuild cp -a unrar libunrar make -C libunrar lib make -C unrar -j1 runHook postBuild ''; installPhase = '' runHook preInstall install -Dm755 unrar/unrar -t $out/bin/ install -Dm644 unrar/{acknow.txt,license.txt} -t $out/share/doc/unrar/ install -Dm755 libunrar/libunrar.so -t $out/lib/ install -Dm644 libunrar/dll.hpp -t $dev/include/unrar/ runHook postInstall ''; setupHook = ./setup-hook.sh; meta = with lib; { description = "Utility for RAR archives"; homepage = "https://www.rarlab.com/"; license = licenses.unfreeRedistributable; mainProgram = "unrar"; maintainers = with maintainers; [ wegank ]; platforms = platforms.all; }; }) </del>
Code change:
Package name: unrar Latest released version: 7.00 beta 3 Current version on the unstable channel: 6.2.12 Current version on the stable/release channel: 6.2.12 I receive more and more RAR files which are created with Unrar 7.00 beta versions / require a more recent version tan 6.2.12 I would appreciated if the existing unrar package can be updated or a new unrar-beta package be proposed .. Changelog : Notify maintainers
There was an automatic update in that I marked as draft, exactly because it's in beta. I'd much rather add a new package. what do you think?
I don't think we should update to the beta either. Sometimes I think about adding beta and release candidate versions to package , but that would be a nixpkgs policy discussion.
If people are still creating new RAR files then I don't want to be maintainer of this package. Stop using RAR.

Related discussion:
text: <del> unpackCmdHooks+=(_tryUnrar) _tryUnrar() { if ! [[ "$curSrc" =~ .rar$ ]]; then return 1; fi unrar x "$curSrc" >/dev/null } </del>
Code change:
Package name: unrar Latest released version: 7.00 beta 3 Current version on the unstable channel: 6.2.12 Current version on the stable/release channel: 6.2.12 I receive more and more RAR files which are created with Unrar 7.00 beta versions / require a more recent version tan 6.2.12 I would appreciated if the existing unrar package can be updated or a new unrar-beta package be proposed .. Changelog : Notify maintainers
There was an automatic update in that I marked as draft, exactly because it's in beta. I'd much rather add a new package. what do you think?
I don't think we should update to the beta either. Sometimes I think about adding beta and release candidate versions to package , but that would be a nixpkgs policy discussion.
If people are still creating new RAR files then I don't want to be maintainer of this package. Stop using RAR.

Related discussion:
text: , fetchFromGitHub , autoreconfHook , fuse <del> , unrar </del> <ins> , unrar_6 </ins> }: stdenv.mkDerivation rec {
Code change:
Package name: unrar Latest released version: 7.00 beta 3 Current version on the unstable channel: 6.2.12 Current version on the stable/release channel: 6.2.12 I receive more and more RAR files which are created with Unrar 7.00 beta versions / require a more recent version tan 6.2.12 I would appreciated if the existing unrar package can be updated or a new unrar-beta package be proposed .. Changelog : Notify maintainers
There was an automatic update in that I marked as draft, exactly because it's in beta. I'd much rather add a new package. what do you think?
I don't think we should update to the beta either. Sometimes I think about adding beta and release candidate versions to package , but that would be a nixpkgs policy discussion.
If people are still creating new RAR files then I don't want to be maintainer of this package. Stop using RAR.

Related discussion:
text: ''; nativeBuildInputs = [ autoreconfHook ]; <del> buildInputs = [ fuse unrar ]; </del> <ins> buildInputs = [ fuse unrar_6 ]; </ins> configureFlags = [ <del> "--with-unrar=${unrar.src}/unrar" </del> <ins> "--with-unrar=${unrar_6.src}/unrar" </ins> "--disable-static-unrar" ];
Code change:
Package name: unrar Latest released version: 7.00 beta 3 Current version on the unstable channel: 6.2.12 Current version on the stable/release channel: 6.2.12 I receive more and more RAR files which are created with Unrar 7.00 beta versions / require a more recent version tan 6.2.12 I would appreciated if the existing unrar package can be updated or a new unrar-beta package be proposed .. Changelog : Notify maintainers
There was an automatic update in that I marked as draft, exactly because it's in beta. I'd much rather add a new package. what do you think?
I don't think we should update to the beta either. Sometimes I think about adding beta and release candidate versions to package , but that would be a nixpkgs policy discussion.
If people are still creating new RAR files then I don't want to be maintainer of this package. Stop using RAR.

Related discussion:
text: unnaturalscrollwheels = callPackage ../tools/inputmethods/unnaturalscrollwheels { }; <del> unrar = callPackage ../tools/archivers/unrar { }; </del> unrar-wrapper = python3Packages.callPackage ../tools/archivers/unrar-wrapper { }; uptime-kuma = callPackage ../servers/monitoring/uptime-kuma { };
Code change:
Package name: crunchy-cli Latest released version: 3.2.2 <!-- Search your package here: --- Current version on the unstable channel: 3.0.0-dev.10 Current version on the stable/release channel: 3.0.0-dev.10 <!-- 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.

Related discussion:
text: <del> { lib , stdenv , clangStdenv , darwin , xcbuild , openssl , pkg-config , rustPlatform , fetchFromGitHub }: rustPlatform.buildRustPackage.override { stdenv = clangStdenv; } rec { pname = "crunchy-cli"; version = "3.0.0-dev.10"; src = fetchFromGitHub { owner = "crunchy-labs"; repo = pname; rev = "v${version}"; hash = "sha256-uc19SmVfa5BZYDidlEgV6GNvcm9Dj0mSjdwHP5S+O4A="; }; cargoHash = "sha256-H3D55qMUAF6t45mRbGZl+DORAl1H1a7AOe+lQP0WUUQ="; nativeBuildInputs = [ pkg-config ] ++ lib.optionals stdenv.isDarwin [ xcbuild ]; buildInputs = [ openssl ] ++ lib.optionals stdenv.isDarwin [ darwin.apple_sdk.frameworks.Security ]; meta = with lib; { description = "A pure Rust written Crunchyroll cli client and downloader"; homepage = "https://github.com/crunchy-labs/crunchy-cli"; license = with licenses; [ gpl3 ]; maintainers = with maintainers; [ stepbrobd ]; mainProgram = "crunchy-cli"; }; } </del>
Code change:
Package name: crunchy-cli Latest released version: 3.2.2 <!-- Search your package here: --- Current version on the unstable channel: 3.0.0-dev.10 Current version on the stable/release channel: 3.0.0-dev.10 <!-- 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.

Related discussion:
text: <ins> { lib , stdenv , darwin , fetchFromGitHub , openssl , pkg-config , rustPlatform }: rustPlatform.buildRustPackage rec { pname = "crunchy-cli"; version = "3.2.5"; src = fetchFromGitHub { owner = "crunchy-labs"; repo = "crunchy-cli"; rev = "v${version}"; hash = "sha256-hzmTwUd+bQwr+5UtXKMalJZUDxOC5nhXNTXbYZN8xtA="; }; cargoLock = { lockFile = ./Cargo.lock; outputHashes = { "native-tls-0.2.11" = "sha256-+NeXsxuThKNOzVLBItKcuTAM/0zR/BzJGMKkuq99gBM="; }; }; nativeBuildInputs = lib.optionals stdenv.isLinux [ pkg-config ]; buildInputs = lib.optionals stdenv.isLinux [ openssl ] ++ lib.optionals stdenv.isDarwin [ darwin.apple_sdk.frameworks.SystemConfiguration ]; env = { OPENSSL_NO_VENDOR = true; }; meta = with lib; { description = "Command-line downloader for Crunchyroll"; homepage = "https://github.com/crunchy-labs/crunchy-cli"; license = licenses.mit; maintainers = with maintainers; [ stepbrobd ]; mainProgram = "crunchy-cli"; }; } </ins>
Code change:
Package name: crunchy-cli Latest released version: 3.2.2 <!-- Search your package here: --- Current version on the unstable channel: 3.0.0-dev.10 Current version on the stable/release channel: 3.0.0-dev.10 <!-- 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.

Related discussion:
text: crunch = callPackage ../tools/security/crunch { }; <del> crunchy-cli = callPackage ../applications/video/crunchy-cli { }; </del> crudini = callPackage ../tools/misc/crudini { }; csv2odf = callPackage ../applications/office/csv2odf { };
Code change:
Right now, only supports passing a schedule of dates with or without a . This means that either: machine that uses the same module will update simultaneously () need to override the on every machine to something different (machine a is , machine b is , ...), which is manual effort can build jitter into it with a value of greater than zero, but since every run re-rolls the randomness, updates can now be extremely non-uniform - for example, a system set to update daily with up to 23 hours of randomness may update twice within two hours, and then not for 46 hours. Of course, all of (1)-(3) are adequate enough for most general circumstances. However, systemd 247 introduced which generates a stable random offset (up to ) which is different for each machine ID. This allows for the consistent periodicity of (2) automatically instead of manually. Please consider whether (default ) would be an appropriate new option to add. Until then, I'll be setting it myself through .

Related discussion:
text: ''; }; <ins> fixedRandomDelay = mkOption { default = false; type = types.bool; example = true; description = lib.mdDoc '' Make the randomized delay consistent between runs. This reduces the jitter between automatic upgrades. See {option}`randomizedDelaySec` for configuring the randomized delay. ''; }; </ins> rebootWindow = mkOption { description = lib.mdDoc '' Define a lower and upper time value (in HH:MM format) which
Code change:
Right now, only supports passing a schedule of dates with or without a . This means that either: machine that uses the same module will update simultaneously () need to override the on every machine to something different (machine a is , machine b is , ...), which is manual effort can build jitter into it with a value of greater than zero, but since every run re-rolls the randomness, updates can now be extremely non-uniform - for example, a system set to update daily with up to 23 hours of randomness may update twice within two hours, and then not for 46 hours. Of course, all of (1)-(3) are adequate enough for most general circumstances. However, systemd 247 introduced which generates a stable random offset (up to ) which is different for each machine ID. This allows for the consistent periodicity of (2) automatically instead of manually. Please consider whether (default ) would be an appropriate new option to add. Until then, I'll be setting it myself through .

Related discussion:
text: systemd.timers.nixos-upgrade = { timerConfig = { RandomizedDelaySec = cfg.randomizedDelaySec; <ins> FixedRandomDelay = cfg.fixedRandomDelay; </ins> Persistent = cfg.persistent; }; };
Code change:
Package name: limesurvey Latest released version: 6.4.1+ Current version on the unstable channel: 6.1.2+ Current version on the stable/release channel: 6.1.2+ Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Related discussion:
text: stdenv.mkDerivation rec { pname = "limesurvey"; <del> version = "6.1.2+230606"; </del> <ins> version = "6.4.1+240108"; </ins> src = fetchFromGitHub { owner = "LimeSurvey"; repo = "LimeSurvey"; rev = version; <del> hash = "sha256-a89Kdr9XV1TSCoWxYrU0j8ec7rAcIlU/bgLtRjdzqbg="; </del> <ins> hash = "sha256-Cpf8X6igF7LdRbFihGudFmx/8aY0Kf0BE7jHnEF1DYA="; </ins> }; phpConfig = writeText "config.php" ''