jiebi/CodeConvo huggingface dataset:
Code change:
Steps to reproduce the behavior: / / All plugins show the same error with a different hash when building, I only included the log from : The es were updated with but the plugins fail with a hash mismatch on two machines I tried it on. Both are x86_64 machines running NixOS unstable. I can make a PR to update the hashes, but I want to make sure I'm not missing something. Please run and paste the result.
I've just opened a PR to fix this, if you have time to review, it would be great, otherwise no worries. I won't wait too long before merging since everything is broken.
Looks good to me, those are the same hashes I got.

Related discussion:
text: inherit pname; version = "0.85.0"; src = nushell.src; <del> cargoHash = "sha256-OKtktjBOujvljAX260TbC2sQWZOiGgU+sXsbYRhGPRM="; </del> <ins> cargoHash = "sha256-WS8VRpJnn/VWS7GUkGowFf51ifUx0SbEZzcoTfx2dp0="; </ins> nativeBuildInputs = [ pkg-config ]; <del> buildInputs = [ IOKit Foundation ]; </del> <ins> buildInputs = lib.optionals stdenv.isDarwin [ IOKit Foundation ]; </ins> cargoBuildFlags = [ "--package nu_plugin_formats" ]; doCheck = false; meta = with lib; {
Code change:
Steps to reproduce the behavior: / / All plugins show the same error with a different hash when building, I only included the log from : The es were updated with but the plugins fail with a hash mismatch on two machines I tried it on. Both are x86_64 machines running NixOS unstable. I can make a PR to update the hashes, but I want to make sure I'm not missing something. Please run and paste the result.
I've just opened a PR to fix this, if you have time to review, it would be great, otherwise no worries. I won't wait too long before merging since everything is broken.
Looks good to me, those are the same hashes I got.

Related discussion:
text: inherit pname; version = "0.85.0"; src = nushell.src; <del> cargoHash = "sha256-Fj70uKYzEKxeZeNrqlwM7ZFJ+K1tz10RqLndrdY40CE="; </del> <ins> cargoHash = "sha256-6luY3SIRRd9vaY9KIJcj8Q974FW0LtAvRjVpdpzkdLo="; </ins> nativeBuildInputs = [ pkg-config ]; buildInputs = [ openssl ] ++ lib.optionals stdenv.isDarwin [ Security ]; cargoBuildFlags = [ "--package nu_plugin_gstat" ];
Code change:
Steps to reproduce the behavior: / / All plugins show the same error with a different hash when building, I only included the log from : The es were updated with but the plugins fail with a hash mismatch on two machines I tried it on. Both are x86_64 machines running NixOS unstable. I can make a PR to update the hashes, but I want to make sure I'm not missing something. Please run and paste the result.
I've just opened a PR to fix this, if you have time to review, it would be great, otherwise no worries. I won't wait too long before merging since everything is broken.
Looks good to me, those are the same hashes I got.

Related discussion:
text: src = nushell.src; <del> cargoHash = "sha256-8iUqOdGWm2kDW72ptlCBIqqe4zjckN09MOQD77kCf5Y="; </del> <ins> cargoHash = "sha256-xyty3GfI+zNkuHs7LYHBctqXUHZ4/MNNcnnfYvI18do="; </ins> buildInputs = lib.optionals stdenv.isDarwin [ IOKit CoreFoundation ];
Code change:
Package name: sudo-rs Latest released version: 0.2.1 <!-- Search your package here: --- Current version on the unstable channel: 0.2.0 Current version on the stable/release channel: N/A <!-- 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: { lib , bash , fetchFromGitHub <del> , fetchpatch </del> , installShellFiles , nix-update-script , nixosTests
Code change:
Package name: sudo-rs Latest released version: 0.2.1 <!-- Search your package here: --- Current version on the unstable channel: 0.2.0 Current version on the stable/release channel: N/A <!-- 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: rustPlatform.buildRustPackage rec { pname = "sudo-rs"; <del> version = "0.2.0"; </del> <ins> version = "0.2.1"; </ins> src = fetchFromGitHub { owner = "memorysafety"; repo = "sudo-rs"; rev = "v${version}"; <del> hash = "sha256-Kk5D3387hdl6eGWTSV003r+XajuDh6YgHuqYlj9NnaQ="; </del> <ins> hash = "sha256-EQEdNDUXEMMiFZKuu9LR9ywjvKWyM5bWcRHHUB9+gp4="; </ins> }; <del> cargoHash = "sha256-yeMK37tOgJcs9pW3IclpR5WMXx0gMDJ2wcmInxJYbQ8="; </del> <ins> cargoHash = "sha256-Zs9/A7u4yMLKY4cAUCnsqRHgkxI8R3w1JwkAd2lw0eo="; </ins> nativeBuildInputs = [ installShellFiles pandoc ]; buildInputs = [ pam ]; <del> patches = [ (fetchpatch { # @R-VdP's patch to work with NixOS' suid wrappers name = "Skip self_check when executed as root.patch"; url = "https://github.com/R-VdP/sudo-rs/commit/a44541dcb36b94f938daaed66b3ff06cfc1c2b40.patch"; hash = "sha256-PdmOqp/NDjFy8ve4jEOi58e0N9xUnaVKioQwdC5Jf1U="; }) ]; </del> # Don't attempt to generate the docs in a (pan)Docker container postPatch = '' substituteInPlace util/generate-docs.sh
Code change:
When creating nixos-containers with umask 077, files get created with the wrong permissions, and services such as dbus don't work because they probably can't read certain files: Like for nixos activation, the creation of nixos containers should force umask 022.

Related discussion:
text: import ./generic.nix ( rec { <del> version = "3.4.2"; </del> <ins> version = "3.4.4"; </ins> testing = false; preConfigure = ''
Code change:
When creating nixos-containers with umask 077, files get created with the wrong permissions, and services such as dbus don't work because they probably can't read certain files: Like for nixos activation, the creation of nixos containers should force umask 022.

Related discussion:
text: src = fetchurl { url = "mirror://kernel/linux/kernel/v3.x/${if testing then "testing/" else ""}linux-${version}.tar.xz"; <del> sha256 = "0pd96g1qcp2wgdnvk79hljjrpr6xjk0159lks47n181a3yirzf4x"; </del> <ins> sha256 = "0l4h7amhsmgpnii8rgwi32nd7ajsifk2xckjd39pfzwdifacw5yw"; </ins> }; config = configWithPlatform stdenv.platform;
Code change:
A clear and concise description of what the bug is. launches, but cannot select language in the welcome screen. If I open the "preference" from tray, no text is displayed. Steps to reproduce the behavior: Ctrl+Shift+I to open devtools, found error. A clear and concise description of what you expected to happen. The app should display normally. If applicable, add screenshots to help explain your problem. ! ! Add any other context about the problem here. Running on NixOS unstable. The log from devtool: <!-- 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.
This is still an issue, and i think the current maintainer is
I have tested out the newest version and found out that the above mentioned issue does not happen on this version.

Related discussion:
text: stdenv.mkDerivation (finalAttrs: { pname = "stretchly"; <del> version = "1.15.1"; </del> <ins> version = "1.16.0"; </ins> src = fetchurl { url = "https://github.com/hovancik/stretchly/releases/download/v${finalAttrs.version}/stretchly-${finalAttrs.version}.tar.xz"; <del> hash = "sha256-suTH6o7vtUr2DidPXAwqrya5/WukQOFmS/34LaiWDBs="; </del> <ins> hash = "sha256-gOMUXGldtZUfqLABJHfbToYe0pcAn8dRWEFxCi/gY9Y="; </ins> }; icon = fetchurl {
Code change:
Project description A self-hosted BitTorrent indexer, DHT crawler, content classifier and torrent search engine with web UI, GraphQL API and Servarr stack integration. The DHT crawler is bitmagnet’s killer feature that (currently) makes it unique. … DHT’s lesser known feature is that it allows you to crawl the info hashes it knows about. This is how bitmagnet’s DHT crawler works works - it crawls the DHT network, requesting metadata about each info hash it discovers. It then further enriches this metadata by attempting to classify it and associate it with known pieces of content, such as movies and TV shows. It then allows you to search everything it has indexed. This means that bitmagnet is not reliant on any external trackers or torrent indexers. It’s a self-contained, self-hosted torrent indexer, connected via DHT to a global network of peers and constantly discovering new content. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin

Related discussion:
text: <ins> { lib , buildGoModule , fetchFromGitHub }: buildGoModule rec { pname = "bitmagnet"; version = "0.0.6"; src = fetchFromGitHub { owner = "bitmagnet-io"; repo = "bitmagnet"; rev = "v${version}"; hash = "sha256-+KAIHg8M2CM+GRRv+htmev8MFe/Y1sJ8p+um/c7kI7c="; }; vendorHash = "sha256-ydiZ3KMEiVkmdzhHjYYLJ7wuiKmwlMEn4OWrKSOnaSo="; ldflags = [ "-s" "-w" ]; meta = { description = "A self-hosted BitTorrent indexer, DHT crawler, and torrent search engine"; longDescription = '' A self-hosted BitTorrent indexer, DHT crawler, content classifier and torrent search engine with web UI, GraphQL API and Servarr stack integration. ''; homepage = "https://bitmagnet.io/"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ eclairevoyant ]; mainProgram = "bitmagnet"; }; } </ins>
Code change:
I note that the package sets in .[(1)] says [(2)] that the reason to disable "JBIG" is patent concerns, that disabling it removes support for many printers, and that "The patent will expire on April 4, 2012". Given the last, need we still disable this feature? [(1)]: [(2)]:
I don't think so. openSUSE enabled it, too. Other distributions might have done the same, not sure.
A PR that implements this change request would be very welcome. I'd rather not have this issue lying around, though, without someone having committed to actually work on it.

Related discussion:
text: }; preBuild = '' <del> makeFlags="V=1 DISABLE_JBIG=1 CUPSFILTER=$out/lib/cups/filter CUPSPPD=$out/share/cups/model" </del> <ins> makeFlags="V=1 CUPSFILTER=$out/lib/cups/filter CUPSPPD=$out/share/cups/model" </ins> ''; buildInputs = [cups zlib];
Code change:
The home-assistant component currently declares that it's missing the input However the package actually exists, it's just called . This appears to be the old name of the package, it looks as though it got renamed at some point, although the nixpkgs packge for it wasn't updated for the name change.
Note that merely setting restores the component's functionality.

Related discussion:
text: <del> { lib , aiohttp , beautifulsoup4 , buildPythonPackage , fetchFromGitHub , pkce , poetry-core , pythonOlder }: buildPythonPackage rec { pname = "pymyq"; version = "3.1.13"; pyproject = true; disabled = pythonOlder "3.8"; src = fetchFromGitHub { owner = "Python-MyQ"; repo = "Python-MyQ"; rev = "refs/tags/v${version}"; hash = "sha256-kW03swRXZdkh45I/up/FIxv0WGBRqTlDt1X71Ow/hrg="; }; nativeBuildInputs = [ poetry-core ]; propagatedBuildInputs = [ aiohttp beautifulsoup4 pkce ]; # Project has no tests doCheck = false; pythonImportsCheck = [ "pymyq" ]; meta = with lib; { description = "Python wrapper for MyQ API"; homepage = "https://github.com/Python-MyQ/Python-MyQ"; changelog = "https://github.com/Python-MyQ/Python-MyQ/releases/tag/v${version}"; license = with licenses; [ mit ]; maintainers = with maintainers; [ fab ]; }; } </del>
Code change:
The home-assistant component currently declares that it's missing the input However the package actually exists, it's just called . This appears to be the old name of the package, it looks as though it got renamed at some point, although the nixpkgs packge for it wasn't updated for the name change.
Note that merely setting restores the component's functionality.

Related discussion:
text: <ins> { lib , aiohttp , beautifulsoup4 , buildPythonPackage , fetchFromGitHub , pkce , poetry-core , pythonOlder }: buildPythonPackage rec { pname = "python-myq"; version = "3.1.13"; pyproject = true; disabled = pythonOlder "3.8"; src = fetchFromGitHub { owner = "Python-MyQ"; repo = "Python-MyQ"; rev = "refs/tags/v${version}"; hash = "sha256-kW03swRXZdkh45I/up/FIxv0WGBRqTlDt1X71Ow/hrg="; }; nativeBuildInputs = [ poetry-core ]; propagatedBuildInputs = [ aiohttp beautifulsoup4 pkce ]; # Project has no tests doCheck = false; pythonImportsCheck = [ "pymyq" ]; meta = with lib; { description = "Python wrapper for MyQ API"; homepage = "https://github.com/Python-MyQ/Python-MyQ"; changelog = "https://github.com/Python-MyQ/Python-MyQ/releases/tag/v${version}"; license = with licenses; [ mit ]; maintainers = with maintainers; [ fab ]; }; } </ins>
Code change:
The home-assistant component currently declares that it's missing the input However the package actually exists, it's just called . This appears to be the old name of the package, it looks as though it got renamed at some point, although the nixpkgs packge for it wasn't updated for the name change.
Note that merely setting restores the component's functionality.

Related discussion:
text: sqlalchemy ]; "myq" = ps: with ps; [ <del> ]; # missing inputs: python-myq </del> <ins> python-myq ]; </ins> "mysensors" = ps: with ps; [ aiohttp-cors janus
Code change:
The home-assistant component currently declares that it's missing the input However the package actually exists, it's just called . This appears to be the old name of the package, it looks as though it got renamed at some point, although the nixpkgs packge for it wasn't updated for the name change.
Note that merely setting restores the component's functionality.

Related discussion:
text: "mullvad" "mutesync" "my" <ins> "myq" </ins> "mysensors" "mystrom" "mythicbeastsdns"
Code change:
The home-assistant component currently declares that it's missing the input However the package actually exists, it's just called . This appears to be the old name of the package, it looks as though it got renamed at some point, although the nixpkgs packge for it wasn't updated for the name change.
Note that merely setting restores the component's functionality.

Related discussion:
text: pymc3 = pymc; # added 2022-06-05, module was rename starting with 4.0.0 pymssql = throw "pymssql has been abandoned upstream."; # added 2020-05-04 PyMVGLive = pymvglive; # added 2023-02-19 <ins> pymyq = python-myq; # added 2023-10-20 </ins> pyqt4 = throw "pyqt4 has been removed, because it depended on the long EOL qt4"; # added 2022-06-09 pyramid_beaker = pyramid-beaker; # added 2023-08-23 pyramid_chameleon = pyramid-chameleon; # added 2023-08-23
Code change:
The home-assistant component currently declares that it's missing the input However the package actually exists, it's just called . This appears to be the old name of the package, it looks as though it got renamed at some point, although the nixpkgs packge for it wasn't updated for the name change.
Note that merely setting restores the component's functionality.

Related discussion:
text: pymvglive = callPackage ../development/python-modules/pymvglive { }; <del> pymyq = callPackage ../development/python-modules/pymyq { }; </del> <ins> python-myq = callPackage ../development/python-modules/python-myq { }; </ins> pymysensors = callPackage ../development/python-modules/pymysensors { };
Code change:
After babashka can't display Unicode characters I have a babashka script that outputs the following JSON: The text is a Nerd Font Symbol code point. After the output is: Steps to reproduce the behavior: This has been fixed in the past by I did not test other packages that could be affected by the PR.
Pretty sure this is related to this bug in GraalVM upstream: I am curious if this is affecting projects using GraalVM 21.0.0 vanilla or if not, how is it working and why it is broken in .
It does seem that even setting up inside the C compiler environment is not sufficient to make it work. CC to see if they have more context on what the possibly issue is.
I also hit this today. I tested the same version(v1.3.186) from upstream binary release, which does not have this issue. Shall we always sync the same version of graavm as upstream build ci?
I don't think this is the issue and even if it was, it is not like babashka is the only GraalVM package we have.
I know that folks can't reproduce this issue with upstream, but I also can't reproduce it with GraalVM using Java, e.g.: A patch if anyone wants to test to be applied to : So, can anyone reproduce this issue with GraalVM Native Image itself? If not, the only thing I can think is that the issue here is the GCC (i.e.: non-static) version (upstream compiles with by default). Or something else.
So I got this warning: But this was after already started to build, so I assume this is the same issue as and need to be fixed upstream.
To explain in more details why I think this is an upstream issue: I don't get the same in the initial part of the build, only when the build starts that I get this warning. So what I assume is doing: Running the CC (C Compiler) inside a shell with clean environment We see the , because this shell couldn't set the proper locale thanks to missing environment variables (e.g.: ) Since this shell environment has no environment variables (at least, not the environment variables that we need), this ends up breaking macOS compilation and locale (Unicode) support in Linux Not sure why it works in GraalVM itself though yet. This is all really strange.
While I'm not familiar with graalvm, I do find a hack for this issue, maybe can weigh in to test whether this hack is valid: Some inspiration from a random reddit post and those issues: And I do find it's using , so I thought if I those two into build args, maybe it'd work. And indeed it seems to work.. After I built bb with above args,
BTW, I cannot reproduce with GraalVM Native Image on helloworld java as well. Helloworld produced by GraalVM Native Image has correct unicode output.
Thanks for investigating this issue. Opened so we can have this fixed.

Related discussion:
text: , glibcLocales # The GraalVM derivation to use , graalvmDrv <del> , name ? "${args.pname}-${args.version}" </del> , executable ? args.pname # JAR used as input for GraalVM derivation, defaults to src , jar ? args.src
Code change:
After babashka can't display Unicode characters I have a babashka script that outputs the following JSON: The text is a Nerd Font Symbol code point. After the output is: Steps to reproduce the behavior: This has been fixed in the past by I did not test other packages that could be affected by the PR.
Pretty sure this is related to this bug in GraalVM upstream: I am curious if this is affecting projects using GraalVM 21.0.0 vanilla or if not, how is it working and why it is broken in .
It does seem that even setting up inside the C compiler environment is not sufficient to make it work. CC to see if they have more context on what the possibly issue is.
I also hit this today. I tested the same version(v1.3.186) from upstream binary release, which does not have this issue. Shall we always sync the same version of graavm as upstream build ci?
I don't think this is the issue and even if it was, it is not like babashka is the only GraalVM package we have.
I know that folks can't reproduce this issue with upstream, but I also can't reproduce it with GraalVM using Java, e.g.: A patch if anyone wants to test to be applied to : So, can anyone reproduce this issue with GraalVM Native Image itself? If not, the only thing I can think is that the issue here is the GCC (i.e.: non-static) version (upstream compiles with by default). Or something else.
So I got this warning: But this was after already started to build, so I assume this is the same issue as and need to be fixed upstream.
To explain in more details why I think this is an upstream issue: I don't get the same in the initial part of the build, only when the build starts that I get this warning. So what I assume is doing: Running the CC (C Compiler) inside a shell with clean environment We see the , because this shell couldn't set the proper locale thanks to missing environment variables (e.g.: ) Since this shell environment has no environment variables (at least, not the environment variables that we need), this ends up breaking macOS compilation and locale (Unicode) support in Linux Not sure why it works in GraalVM itself though yet. This is all really strange.
While I'm not familiar with graalvm, I do find a hack for this issue, maybe can weigh in to test whether this hack is valid: Some inspiration from a random reddit post and those issues: And I do find it's using , so I thought if I those two into build args, maybe it'd work. And indeed it seems to work.. After I built bb with above args,
BTW, I cannot reproduce with GraalVM Native Image on helloworld java as well. Helloworld produced by GraalVM Native Image has correct unicode output.
Thanks for investigating this issue. Opened so we can have this fixed.

Related discussion:
text: "-H:Name=${executable}" "-march=compatibility" "--verbose" <ins> "-J-Dsun.stdout.encoding=UTF-8" "-J-Dsun.stderr.encoding=UTF-8" </ins> ] # Extra arguments to be passed to the native-image , extraNativeImageBuildArgs ? [ ] # XMX size of GraalVM during build , graalvmXmx ? "-J-Xmx6g" <del> # Locale to be used by GraalVM compiler , LC_ALL ? "en_US.UTF-8" </del> , meta ? { } , ... } @ args: