jiebi/CodeConvo huggingface dataset:
Change:
see this issue Steps to reproduce the behavior: gnirehtet from 22.11 or unstable (22.05 still has a working version) a smartphone and enable adb it should suffice to build gnirehtet with rust 1.63 or older to fix the issue

Discussion:
<del> { lib, stdenv, rustPlatform, fetchFromGitHub, fetchzip, androidenv, makeWrapper }: </del> <ins> { lib , stdenv , rustPlatform , fetchFromGitHub , fetchpatch , fetchzip , androidenv , makeWrapper }: </ins> let version = "2.5"; apk = stdenv.mkDerivation {

inherit version; src = fetchzip { url = "https://github.com/Genymobile/gnirehtet/releases/download/v${version}/gnirehtet-rust-linux64-v${version}.zip"; <del> sha256 = "1db0gkg5z8lighhkyqfsr9jiacrck89zmfnmp74vj865hhxgjzgq"; </del> <ins> hash = "sha256-+H35OoTFILnJudW6+hOaLDMVZcraYT8hfJGiX958YLU="; </ins> }; installPhase = '' mkdir $out

inherit version; src = fetchFromGitHub { <del> owner = "Genymobile"; repo = "gnirehtet"; rev = "v${version}"; sha256 = "0wk6n082gnj9xk46n542h1012h8gyhldca23bs7vl73g0534g878"; </del> <ins> owner = "Genymobile"; repo = "gnirehtet"; rev = "v${version}"; hash = "sha256-6KBHRgFvHLqPXkMo1ij0D0ERQICCFGvI7EnaJxCwZnI="; </ins> }; sourceRoot = "source/relay-rust"; <del> cargoSha256 = "03r8ivsvmhi5f32gj4yacbyzanziymszya18dani53bq9zis9z31"; </del> <ins> cargoPatches = [ (fetchpatch { name = "fix-trailing-semicolon-in-macro.patch"; url = "https://github.com/Genymobile/gnirehtet/commit/537b3d87344a456e1310f10dcef37592063f4e54.patch"; hash = "sha256-6U4ZEcqyXcXrfLRtynepS7gp+Uh5sujRyHVLXbWvpq8="; stripLen = 1; }) # Updates Cargo.lock and is needed to apply the subsequent patch (fetchpatch { name = "prefix-unused-field-with-underscore.patch"; url = "https://github.com/Genymobile/gnirehtet/commit/2f695503dd80519ce73a80c5aa360b08a97c029d.patch"; hash = "sha256-YVd1B2PVLRGpJNkKb7gpUQWmccfvYaeAmayOmWg8D+Y="; stripLen = 1; }) # https://github.com/Genymobile/gnirehtet/pull/478 (fetchpatch { name = "fix-for-rust-1.64.patch"; url = "https://github.com/Genymobile/gnirehtet/commit/8eeed2084d0d1e2f83056bd11622beaa1fa61281.patch"; hash = "sha256-Wwc+4vG48/qpusGjlE+mSJvvarYq2mQ2CkDkrtKHAwo="; stripLen = 1; }) ]; cargoHash = "sha256-3iYOeHIQHwxmh8b8vKUf5fQS2fXP2g3orLquvLXzZwE="; </ins> nativeBuildInputs = [ makeWrapper ];
Change:
changed on which address Grafana listens by default. Previously (under 22.05) it was localhost only and it was necessary to explicitly adjust this if so desired. Now (with 22.11) Grafana is listening on all IPs. Previously: New default is to listen on all IPs: Without enabled (and properly configured) firewall this could result in situations where people are exposing their Grafana installation unintentionally.
but the default settings should suffice to catch this, right? This also matches the upstream grafana default
Yes, I would think so. Therefore not really dramatic in most cases.

Discussion:
</listitem> <listitem> <para> <ins> <literal>services.grafana</literal> listens only on localhost by default again. This was changed to upstreams default of <literal>0.0.0.0</literal> by accident in the freeform setting conversion. </para> </listitem> <listitem> <para> </ins> A new <literal>virtualisation.rosetta</literal> module was added to allow running <literal>x86_64</literal> binaries through

- `nixos/lib/make-disk-image.nix` can now mutate EFI variables, run user-provided EFI firmware or variable templates. This is now extensively documented in the NixOS manual. <ins> - `services.grafana` listens only on localhost by default again. This was changed to upstreams default of `0.0.0.0` by accident in the freeform setting conversion. </ins> - A new `virtualisation.rosetta` module was added to allow running `x86_64` binaries through [Rosetta](https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment) inside virtualised NixOS guests on Apple silicon. This feature works by default with the [UTM](https://docs.getutm.app/) virtualisation [package](https://search.nixos.org/packages?channel=unstable&show=utm&from=0&size=1&sort=relevance&type=packages&query=utm). - The new option `users.motdFile` allows configuring a Message Of The Day that can be updated dynamically.

}; http_addr = mkOption { <del> description = lib.mdDoc "Listening address."; default = ""; </del> type = types.str; <ins> default = "127.0.0.1"; description = lib.mdDoc '' Listening address. ::: {.note} This setting intentionally varies from upstream's default to be a bit more secure by default. ::: ''; </ins> }; http_port = mkOption {
Change:
Nim programs contain a full-path reference to the Nim standard library, which pulls the Nim compiler into the programs' store closure. Steps to reproduce the behavior: nix path-info -rsSh nixpkgs#nimPackages.c2nim less nix path-info -rsSh nixpkgs#nimmm | sort -nk3
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Discussion:
./nixbuild.patch # Load libraries at runtime by absolute path <ins> ./extra-mangling.patch # Mangle store paths of modules to prevent runtime dependence. </ins> ] ++ lib.optional (!stdenv.hostPlatform.isWindows) ./toLocation.patch; configurePhase = ''

<ins> diff --git a/compiler/modulepaths.nim b/compiler/modulepaths.nim index e80ea3fa6..8ecf27a85 100644 --- a/compiler/modulepaths.nim +++ b/compiler/modulepaths.nim @@ -70,6 +70,13 @@ proc checkModuleName*(conf: ConfigRef; n: PNode; doLocalError=true): FileIndex = else: result = fileInfoIdx(conf, fullPath) +proc rot13(result: var string) = +  for i, c in result: +    case c +    of 'a'..'m', 'A'..'M': result[i] = char(c.uint8 + 13) +    of 'n'..'z', 'N'..'Z': result[i] = char(c.uint8 - 13) +    else: discard + proc mangleModuleName*(conf: ConfigRef; path: AbsoluteFile): string = ## Mangle a relative module path to avoid path and symbol collisions. ## @@ -78,9 +85,11 @@ proc mangleModuleName*(conf: ConfigRef; path: AbsoluteFile): string = ## ## Example: ## `foo-#head/../bar` becomes `@foo-@hhead@s..@sbar` -  "@m" & relativeTo(path, conf.projectPath).string.multiReplace( +  result = "@m" & relativeTo(path, conf.projectPath).string.multiReplace( {$os.DirSep: "@s", $os.AltSep: "@s", "#": "@h", "@": "@@", ":": "@c"}) +  rot13(result) proc demangleModuleName*(path: string): string = ## Demangle a relative module path. result = path.multiReplace({"@@": "@", "@h": "#", "@s": "/", "@m": "", "@c": ":"}) +  rot13(result) diff --git a/compiler/msgs.nim b/compiler/msgs.nim index 3f386cc61..054f7f647 100644 --- a/compiler/msgs.nim +++ b/compiler/msgs.nim @@ -659,8 +659,10 @@ proc uniqueModuleName*(conf: ConfigRef; fid: FileIndex): string = for i in 0..<trunc: let c = rel[i] case c -    of 'a'..'z': -      result.add c +    of 'a'..'m': +      result.add char(c.uint8 + 13) +    of 'n'..'z': +      result.add char(c.uint8 - 13) of {os.DirSep, os.AltSep}: result.add 'Z' # because it looks a bit like '/' of '.': </ins>
Change:
<!-- 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: dt-schema <!-- 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: 2022.1 desired version: 2022.12 <!-- 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.
A new version is out: Should I just update this and my PR to make use of this new version?

Discussion:
, rfc3987 , ruamel-yaml , setuptools-scm <ins> , libfdt </ins> }: buildPythonPackage rec { pname = "dtschema"; <del> version = "2022.01"; </del> <ins> version = "2022.12"; </ins> format = "setuptools"; disabled = pythonOlder "3.7";

owner = "devicetree-org"; repo = "dt-schema"; rev = "refs/tags/v${version}"; <del> hash = "sha256-wwlXIM/eO3dII/qQpkAGLT3/15rBLi7ZiNtqYFf7Li4="; </del> <ins> sha256 = "sha256-+wF6WdonZrkZEnlq/P6QeT3X7CMinxbapLa7q0t2zUc="; </ins> }; <ins> patches = [ # Change name of pylibfdt to libfdt ./fix_libfdt_name.patch ]; </ins> SETUPTOOLS_SCM_PRETEND_VERSION = version; nativeBuildInputs = [

jsonschema rfc3987 ruamel-yaml <ins> libfdt </ins> ]; # Module has no tests

<ins> diff --git a/setup.py b/setup.py index 62db8af..4a980c1 100755 --- a/setup.py +++ b/setup.py @@ -52,7 +52,7 @@ setuptools.setup( 'ruamel.yaml>0.15.69', 'jsonschema>=4.1.2', 'rfc3987', -        'pylibfdt', +        'libfdt', ], classifiers=[ </ins>
Change:
Olaris server requires ffmpeg to be available and raises an error when it can't be found: Steps to reproduce the behavior: olaris-server a library. The software runs correctly. There are two main ways to fix this: the software to use the full path to the ffmpeg dependency (ideally upstream). the program to add ffmpeg to its path. Please run and paste the result.
In fact it looks like it needs a custom image as it passes arguments that only exist on the modified version.
Actually it looks like the fork is no longer required: But this doesn't seem to be released yet. But probably is still a better option than packaging the custom ffmpeg.
yep, this looks like an easy fix EDIT: I was keen to try building the ffmpeg fork so that we can stick to a released version, however that proved prohibitively difficult, so tip of the default branch it is
no action required, but note the way I used in the pr and commit, means this issue would have autoclosed when the change merged
That is what happened.
sorry, I only saw this issue's update and assumed that you manually closed it; I assume most people involved in nixpkgs prs do not have merge perms, and github really needs to work on their ux. terribly sorry for the hassle, and assuming you were a more novice user.
No worries, GitHub really doesn't make it clear.

Discussion:
<del> { buildGoModule, fetchFromGitLab, fetchzip, installShellFiles, lib }: </del> <ins> { buildGoModule , fetchFromGitLab , fetchzip , ffmpeg , installShellFiles , lib , makeWrapper }: </ins> buildGoModule rec { pname = "olaris-server"; <del> version = "0.4.0"; </del> <ins> version = "unstable-2022-06-11"; </ins> src = fetchFromGitLab { <del> owner = "olaris"; </del> <ins> owner = "olaris"; </ins> repo = pname; <del> rev = "v${version}"; hash = "sha256-iworyQqyTabTI0NpZHTdUBGZSCaiC5Dhr69mRtsHLOs="; </del> <ins> rev = "bdb2aeb1595c941210249164a97c12404c1ae0d8"; hash = "sha256-Uhnh6GC85ORKnfHeYNtbSA40osuscxXDF5/kXJrF2Cs="; </ins> }; preBuild = let

"-X gitlab.com/olaris/olaris-server/helpers.Version=${version}" ]; <del> vendorHash = "sha256-xWywDgw0LzJhPtVK0aGgT0TTanejJ39ZmGc50A3d68U="; </del> <ins> vendorHash = "sha256-bw8zvDGFBci9bELsxAD0otpNocBnO8aAcgyohLZ3Mv0="; </ins> <del> nativeBuildInputs = [ installShellFiles ]; </del> <ins> nativeBuildInputs = [ installShellFiles makeWrapper ]; </ins> # integration tests require network access doCheck = false;

--bash <($out/bin/olaris-server completion bash)  --fish <($out/bin/olaris-server completion fish)  --zsh <($out/bin/olaris-server completion zsh) <ins> wrapProgram $out/bin/olaris-server --prefix PATH : ${lib.makeBinPath [ffmpeg]} </ins> ''; meta = with lib; {
Change:
A clear and concise description of what the bug is. Steps to reproduce the behavior: created with expected behavior from This might be due to vhs being outdated in nixpkgs. Please run and paste the result.
Nixpkgs has since been updated to the latest version (v0.2.0), and the error still occurs on the latest Nixpkgs commit ()
Any suggestions on a fix?
I believe the fix might be to include as a dependency and ensure that looks for the binary in the same place nix installs it (i.e. it is located in the as chromium):
The PR for this breaks vhs on darwin, since chromium isn't supported on that platform
Thanks for filing a new issue

Discussion:
<del> { lib, buildGoModule, installShellFiles, fetchFromGitHub, ffmpeg, ttyd, makeWrapper }: </del> <ins> { lib, buildGoModule, installShellFiles, fetchFromGitHub, ffmpeg, ttyd, chromium, makeWrapper }: </ins> buildGoModule rec { pname = "vhs";

vendorHash = "sha256-9nkRr5Jh1nbI+XXbPj9KB0ZbLybv5JUVovpB311fO38="; nativeBuildInputs = [ installShellFiles makeWrapper ]; <del> buildInputs = [ ttyd ffmpeg ]; </del> ldflags = [ "-s" "-w" "-X=main.Version=${version}" ]; postInstall = '' <del> wrapProgram $out/bin/vhs --prefix PATH : ${lib.makeBinPath [ ffmpeg ttyd ]} </del> <ins> wrapProgram $out/bin/vhs --prefix PATH : ${lib.makeBinPath [ chromium ffmpeg ttyd ]} </ins> $out/bin/vhs man > vhs.1 installManPage vhs.1 installShellCompletion --cmd vhs
Change:
I keep hitting a heisenbug in , where we get . this is triggered because, per suggestion, we split setup into and . this makes intuitive sense, because the former is a bunch of nix related in place substitutions, and the latter is a pre-build code generation phase. because this suggestion came late in the development process, I had already seeded a fod into the nix store, with a single containing all the logic. as such, when I broke them apart, the derivation was broken, but it worked on my system. this caused a large amount of delay, and probably annoyed sorry. I understand the logic of wanting to share between the main derivation and , but most authors will not be clear that only gets shared, and it needs to work without other hooks. Steps to reproduce the behavior: a derivation with both attrs build the derivation in two (say and ) such that alone is not enough that it builds successfully locally that it fails to build on empty nix store I would have expected that we pass all the hooks or none. I know we already have , and maybe that is the correct way to pass things like or , e.g. and respectively. the ux for this would not be too bad: , but I get that this is a breaking change. Please run and paste the result.
I've seen a couple of people get bitten by this sort of thing, been meaning to do something about. Give me a week or two and I'll take a look at improving it.
yep, no rush. I opened the issue half to document what went wrong, so that other people searching this might find it. I am also happy to help, if you can sketch out what your proposed solution would be, e.g. my naive suggestion.

Discussion:
inherit (args) src; inherit (go) GOOS GOARCH; <ins> prePatch = args.prePatch or ""; </ins> patches = args.patches or []; patchFlags = args.patchFlags or []; <ins> postPatch = args.postPatch or ""; </ins> preBuild = args.preBuild or ""; <ins> postBuild = args.postBuild or ""; </ins> sourceRoot = args.sourceRoot or ""; GO111MODULE = "on";
Change:
Steps to reproduce the behavior: -rebuild of NixOS with GNOME Known workaround: reverting ( ) Please run and paste the result.
Opened an issue but unsure about what is going on / how to fix other than reverting that commit. I don't know that much nix :C
does fix the issue for you?
It does, thanks for the fix. :3

Discussion:
strings.  The latter is concatenated, interspersed with colon characters. ''; <del> type = with types; attrsOf (oneOf [ str path (listOf str) ]); </del> <ins> type = with types; attrsOf (oneOf [ (listOf str) str path ]); </ins> apply = mapAttrs (n: v: if isList v then concatStringsSep ":" v else "${v}"); };
Change:
Restart cinnamon from the panel freezes the desktop, from the journal you will find cinnamon crashes. click the panel trouble shooting cinnamon No crash.
Okay, I guess I need upstream help for this, going to forward this to upstream...

Discussion:
{ stdenv , lib , fetchFromGitHub <ins> , fetchpatch </ins> , substituteAll , cairo , cinnamon-desktop

outputs = [ "out" "dev" "man" ]; <del> patches = [ (substituteAll { src = ./fix-paths.patch; zenity = gnome.zenity; }) ]; </del> src = fetchFromGitHub { owner = "linuxmint"; repo = pname;

hash = "sha256-bHEBzl0aBXsHOhSWJUz428pG5M6L0s/Q6acKO+2oMXo="; }; <ins> patches = [ (substituteAll { src = ./fix-paths.patch; zenity = gnome.zenity; }) # compositor: Fix crash when restarting Cinnamon # https://github.com/linuxmint/muffin/pull/655 (fetchpatch { url = "https://github.com/linuxmint/muffin/commit/1a941ec603a1565dbd2f943f7da6e877d1541bcb.patch"; sha256 = "sha256-6x64rWQ20ZjM9z79Pg6QMDPeFN5VNdDHBueRvy2kA6c="; }) ]; </ins> nativeBuildInputs = [ desktop-file-utils mesa # needed for gbm
Change:
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

Discussion:
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";
Change:
Project description Oculante's vision is to be a fast, unobtrusive, portable image viewer with wide image format support, offering image analysis and basic editing tools. Metadata homepage URL: source URL: license: MIT platforms: cross

Discussion:
<ins> { lib , rustPlatform , fetchFromGitHub , cmake , pkg-config , openssl , fontconfig , nasm , libX11 , libXcursor , libXrandr , libXi , libGL , stdenv , gtk3 , darwin }: rustPlatform.buildRustPackage rec { pname = "oculante"; version = "0.6.38"; src = fetchFromGitHub { owner = "woelper"; repo = pname; rev = version; sha256 = "sha256-0msPeW0FoBzHBDfX2iFH4HzAknaGPNThuCLi2vhdK08="; }; cargoSha256 = "sha256-eKRn8MC4/jjPRoajhwrtXsa8n9bGO5MAKjDuwHWs7Oc="; nativeBuildInputs = [ cmake pkg-config nasm ]; checkFlagsArray = [ "--skip=tests::net" ]; # requires network access buildInputs = [ openssl fontconfig ] ++ lib.optionals stdenv.isLinux [ libX11 libXcursor libXi libXrandr libGL gtk3 ] ++ lib.optionals stdenv.isDarwin [ darwin.libobjc ]; postFixup = lib.optionalString stdenv.isLinux '' patchelf $out/bin/oculante --add-rpath ${lib.makeLibraryPath [ libGL ]} ''; meta = with lib; { broken = stdenv.isDarwin; description = "A minimalistic crossplatform image viewer written in Rust"; homepage = "https://github.com/woelper/oculante"; changelog = "https://github.com/woelper/oculante/blob/${version}/CHANGELOG.md"; license = licenses.mit; maintainers = with maintainers; [ dit7ya ]; }; } </ins>

octoprint = callPackage ../applications/misc/octoprint { }; <ins> oculante = callPackage ../applications/graphics/oculante { }; </ins> ocr-a = callPackage ../data/fonts/ocr-a {}; ocrad = callPackage ../applications/graphics/ocrad { };
Change:
Installing and on Nixos 22.11 yields when building. This error also appears everytime the fish shell is started and makes it hardly usable. Steps to reproduce the behavior: and on Nixos 22.11 with as your shell the error message during build and when starting the fish shell afterwards The Plugin working without further configuration. 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.
could you please take a look at this? Unfortunately, i don't have the required understanding of nix to do it myself.
I'll have a look, thank you for reporting the issue! I'm still using this plugin but not sure what the error is here
any progress?
Can you provide your configuration? This is how I'm using the grc plugin in fish with Home Manager Maybe this solves the problem for you
Ha, you finally made me use home-manager! With home-manager it works. Previously, i installed the fishPlugins as environmentPackages and configured fish the ordinary way via its file. All other Plugins from Nixos worked fine but the doesn't because of the error with . So i guess that this could be fixed but i'm no expert.
Hey I can reproduce the problem now in a virtual machine. I'll try to fix the package and add an additional section to the NixOS wiki page on how to use plugins without Home Manager (by just putting them into environment.systemPackages)
Thanks!
Added an example configuration for enabling plugins system wide to the Wiki page The following PR fixes system wide usage Thank you for the bug report :)
Thank you!
Is there any advice on how I could use this change as of now? I'm new to NixOS and am having the same issue currently. I'm wondering if I can use this patch before its released Edit: This seemed to work
As a general tip, at the beginning of your add the following: and then you can prefix every package with that you want from unstable. In this case, you could have to

Discussion:
sha256 = "sha256-NQa12L0zlEz2EJjMDhWUhw5cz/zcFokjuCK5ZofTn+Q="; }; <ins> postInstall = '' cp conf.d/executables $out/share/fish/vendor_conf.d/ ''; </ins> meta = with lib; { description = "grc Colourizer for some commands on Fish shell"; license = licenses.mit;
Change:
After upgrading NixOS-16.09 from to my graphiteWeb service broke with the following messages in my journal: The only directly related patch in that range is: . any idea how to fix this?
FWIW I think your hashes were reversed, here is the compare:
thanks for the compare. Can anybody confirm the graphiteWeb failure that I'm seeing?

Discussion:
{ stdenv, fetchurl, gmp }: stdenv.mkDerivation rec { <del> name = "ikarus-0.0.3"; </del> <ins> version = "0.0.3"; name = "ikarus-${version}"; </ins> src = fetchurl { <del> url = "http://ikarus-scheme.org/${name}.tar.gz"; </del> <ins> url = "http://launchpad.net/ikarus/0.0/${version}/+download/${name}.tar.gz"; </ins> sha256 = "0d4vqwqfnj39l0gar2di021kcf6bfpkc6g40yapkmxm6sxpdcvjv"; };