jiebi/CodeConvo huggingface dataset:
Code change:
Vesktop opens up to a white screen. It cannot update from tray to latest version. I tried completely removing config files from Vencord but it doesn't change anything. Running Vesktop with flag --disable-gpu makes the Vesktop stuck at loading Steps to reproduce the behavior: Vesktop Launching Vesktop should open up the app normally ! Kernel: 6.5.7-xanmod1 Gpu: AMD (mesa 23.1.7)
vencorddesktop command doesn't output any logs. When doing update from the gui, it doesn't show anything. Only time it shows something is when i try updating from tray icon. The output is the following:
This is a problem with Vencord. It is currently broken with the curren versions of Discord (including the web app) We have to wait for upstream to fix these issues and release a new version of vencord
Alright, thank you for the fast response! Cheers
I encountered the same issue, and can confirm it is fixed when the system version of vencord is 1.6.0.

Related discussion:
text: npmRebuildFlags = [ "|| true" ]; makeCacheWritable = true; <del> npmDepsHash = "sha256-JeJjjrCfJMuxP9sVVkKJQ7bRCGu0jbGfiw78jS0r2Sg="; </del> <ins> npmDepsHash = "sha256-H2f6xdAa7fNETbQhIv+InCB7+O4nq0bx+RILjGjqXdY="; </ins> npmFlags = [ "--legacy-peer-deps" ]; npmBuildScript = if buildWebExtension then "buildWeb" else "build"; npmBuildFlags = [ "--" "--standalone" "--disable-updater" ];
Code change:
Vesktop opens up to a white screen. It cannot update from tray to latest version. I tried completely removing config files from Vencord but it doesn't change anything. Running Vesktop with flag --disable-gpu makes the Vesktop stuck at loading Steps to reproduce the behavior: Vesktop Launching Vesktop should open up the app normally ! Kernel: 6.5.7-xanmod1 Gpu: AMD (mesa 23.1.7)
vencorddesktop command doesn't output any logs. When doing update from the gui, it doesn't show anything. Only time it shows something is when i try updating from tray icon. The output is the following:
This is a problem with Vencord. It is currently broken with the curren versions of Discord (including the web app) We have to wait for upstream to fix these issues and release a new version of vencord
Alright, thank you for the fast response! Cheers
I encountered the same issue, and can confirm it is fixed when the system version of vencord is 1.6.0.

Related discussion:
text: { "name": "vencord", <del> "version": "1.5.8", </del> <ins> "version": "1.6.0", </ins> "lockfileVersion": 3, "requires": true, "packages": { "": { "name": "vencord", <del> "version": "1.5.8", </del> <ins> "version": "1.6.0", </ins> "license": "GPL-3.0-or-later", "dependencies": { "@sapphi-red/web-noise-suppressor": "0.3.3",
Code change:
Vesktop opens up to a white screen. It cannot update from tray to latest version. I tried completely removing config files from Vencord but it doesn't change anything. Running Vesktop with flag --disable-gpu makes the Vesktop stuck at loading Steps to reproduce the behavior: Vesktop Launching Vesktop should open up the app normally ! Kernel: 6.5.7-xanmod1 Gpu: AMD (mesa 23.1.7)
vencorddesktop command doesn't output any logs. When doing update from the gui, it doesn't show anything. Only time it shows something is when i try updating from tray icon. The output is the following:
This is a problem with Vencord. It is currently broken with the curren versions of Discord (including the web app) We have to wait for upstream to fix these issues and release a new version of vencord
Alright, thank you for the fast response! Cheers
I encountered the same issue, and can confirm it is fixed when the system version of vencord is 1.6.0.

Related discussion:
text: } }, "node_modules/@eslint-community/regexpp": { <del> "version": "4.9.1", "resolved": "https://registry.npmjs.org/@eslint-community/regexpp/-/regexpp-4.9.1.tgz", "integrity": "sha512-Y27x+MBLjXa+0JWDhykM3+JE+il3kHKAEqabfEWq3SDhZjLYb6/BHL/JKFnH3fe207JaXkyDo685Oc2Glt6ifA==", </del> <ins> "version": "4.10.0", "resolved": "https://registry.npmjs.org/@eslint-community/regexpp/-/regexpp-4.10.0.tgz", "integrity": "sha512-Cu96Sd2By9mCNTx2iyKOmq10v22jUVQv0lQnlGNy16oE9589yE+QADPbrMGCkA51cKZSg3Pu/aTJVTGfL/qjUA==", </ins> "dev": true, "engines": { "node": "^12.0.0 || ^14.0.0 || >=16.0.0"
Code change:
Vesktop opens up to a white screen. It cannot update from tray to latest version. I tried completely removing config files from Vencord but it doesn't change anything. Running Vesktop with flag --disable-gpu makes the Vesktop stuck at loading Steps to reproduce the behavior: Vesktop Launching Vesktop should open up the app normally ! Kernel: 6.5.7-xanmod1 Gpu: AMD (mesa 23.1.7)
vencorddesktop command doesn't output any logs. When doing update from the gui, it doesn't show anything. Only time it shows something is when i try updating from tray icon. The output is the following:
This is a problem with Vencord. It is currently broken with the curren versions of Discord (including the web app) We have to wait for upstream to fix these issues and release a new version of vencord
Alright, thank you for the fast response! Cheers
I encountered the same issue, and can confirm it is fixed when the system version of vencord is 1.6.0.

Related discussion:
text: "dev": true }, "node_modules/@types/node": { <del> "version": "18.18.6", "resolved": "https://registry.npmjs.org/@types/node/-/node-18.18.6.tgz", "integrity": "sha512-wf3Vz+jCmOQ2HV1YUJuCWdL64adYxumkrxtc+H1VUQlnQI04+5HtH+qZCOE21lBE7gIrt+CwX2Wv8Acrw5Ak6w==", "dev": true </del> <ins> "version": "18.18.7", "resolved": "https://registry.npmjs.org/@types/node/-/node-18.18.7.tgz", "integrity": "sha512-bw+lEsxis6eqJYW8Ql6+yTqkE6RuFtsQPSe5JxXbqYRFQEER5aJA9a5UH9igqDWm3X4iLHIKOHlnAXLM4mi7uQ==", "dev": true, "dependencies": { "undici-types": "~5.26.4" } </ins> }, "node_modules/@types/normalize-package-data": { "version": "2.4.3",
Code change:
Vesktop opens up to a white screen. It cannot update from tray to latest version. I tried completely removing config files from Vencord but it doesn't change anything. Running Vesktop with flag --disable-gpu makes the Vesktop stuck at loading Steps to reproduce the behavior: Vesktop Launching Vesktop should open up the app normally ! Kernel: 6.5.7-xanmod1 Gpu: AMD (mesa 23.1.7)
vencorddesktop command doesn't output any logs. When doing update from the gui, it doesn't show anything. Only time it shows something is when i try updating from tray icon. The output is the following:
This is a problem with Vencord. It is currently broken with the curren versions of Discord (including the web app) We have to wait for upstream to fix these issues and release a new version of vencord
Alright, thank you for the fast response! Cheers
I encountered the same issue, and can confirm it is fixed when the system version of vencord is 1.6.0.

Related discussion:
text: "dev": true }, "node_modules/@types/react": { <del> "version": "18.2.31", "resolved": "https://registry.npmjs.org/@types/react/-/react-18.2.31.tgz", "integrity": "sha512-c2UnPv548q+5DFh03y8lEDeMfDwBn9G3dRwfkrxQMo/dOtRHUUO57k6pHvBIfH/VF4Nh+98mZ5aaSe+2echD5g==", </del> <ins> "version": "18.2.33", "resolved": "https://registry.npmjs.org/@types/react/-/react-18.2.33.tgz", "integrity": "sha512-v+I7S+hu3PIBoVkKGpSYYpiBT1ijqEzWpzQD62/jm4K74hPpSP7FF9BnKG6+fg2+62weJYkkBWDJlZt5JO/9hg==", </ins> "dev": true, "dependencies": { "@types/prop-types": "*",
Code change:
Vesktop opens up to a white screen. It cannot update from tray to latest version. I tried completely removing config files from Vencord but it doesn't change anything. Running Vesktop with flag --disable-gpu makes the Vesktop stuck at loading Steps to reproduce the behavior: Vesktop Launching Vesktop should open up the app normally ! Kernel: 6.5.7-xanmod1 Gpu: AMD (mesa 23.1.7)
vencorddesktop command doesn't output any logs. When doing update from the gui, it doesn't show anything. Only time it shows something is when i try updating from tray icon. The output is the following:
This is a problem with Vencord. It is currently broken with the curren versions of Discord (including the web app) We have to wait for upstream to fix these issues and release a new version of vencord
Alright, thank you for the fast response! Cheers
I encountered the same issue, and can confirm it is fixed when the system version of vencord is 1.6.0.

Related discussion:
text: "through": "^2.3.8" } }, <ins> "node_modules/undici-types": { "version": "5.26.5", "resolved": "https://registry.npmjs.org/undici-types/-/undici-types-5.26.5.tgz", "integrity": "sha512-JlCMO+ehdEIKqlFxk6IfVoAUVmgz7cU7zD/h9XZ0qzeosSHmUJVOzSQvvYSYWXkFXC+IfLKSIffhv0sVZup6pA==", "dev": true }, </ins> "node_modules/union-value": { "version": "1.0.1", "resolved": "https://registry.npmjs.org/union-value/-/union-value-1.0.1.tgz",
Code change:
So, whenever I open Player, it starts installing Roblox, finishes, and does nothing. Even when launched from the website, starts installing, finishes, and most likely just exits. Logs show nothing important. However, when trying open Studio, the error saying " not found". Steps to reproduce the behavior: the grapejuice package (just write grapejuice in the with pkgs section) wine-wayland package (not sure if it is required, however I did) Grapejuice (I used rofi (drun), but I suppose $ would work) the message box that pops out (from wine), press "Install" to install the wine-mono thingy press the Open RobloxPlayer button, or go into Player, Initialize and Install Roblox, the behavior is the same Roblox installing and doing nothing... I expected RobloxPlayer to actually open, not install and exit... <!-- --
This is already tracked in issue

Related discussion:
text: gradle_5 = throw "gradle_5 has been removed because it's no longer being updated"; # Added 2023-01-17 grafana_reporter = grafana-reporter; # Added 2024-06-09 gr-ais = throw "'gr-ais' has been renamed to/replaced by 'gnuradio3_7.pkgs.ais'"; # Converted to throw 2023-09-10 <ins> grapefruit = throw "'grapefruit' was removed due to being blocked by Roblox, rendering the package useless"; # Added 2024-08-23 </ins> graylog = throw "graylog is now available in versions 3.3 up to 5.0. Please mind the upgrade path and choose the appropriate version. Direct upgrading from 3.3 to 4.3 or above is not supported"; # Added 2023-04-24 graylog-3_3 = throw "graylog 3.x is EOL. Please consider downgrading nixpkgs if you need an upgrade from 3.x to latest series."; # Added 2023-10-09 graylog-4_0 = throw "graylog 4.x is EOL. Please consider downgrading nixpkgs if you need an upgrade from 4.x to latest series."; # Added 2023-10-09
Code change:
So, whenever I open Player, it starts installing Roblox, finishes, and does nothing. Even when launched from the website, starts installing, finishes, and most likely just exits. Logs show nothing important. However, when trying open Studio, the error saying " not found". Steps to reproduce the behavior: the grapejuice package (just write grapejuice in the with pkgs section) wine-wayland package (not sure if it is required, however I did) Grapejuice (I used rofi (drun), but I suppose $ would work) the message box that pops out (from wine), press "Install" to install the wine-mono thingy press the Open RobloxPlayer button, or go into Player, Initialize and Install Roblox, the behavior is the same Roblox installing and doing nothing... I expected RobloxPlayer to actually open, not install and exit... <!-- --
This is already tracked in issue

Related discussion:
text: vikunja-frontend = throw "'vikunja-frontend' has been replaced by 'vikunja'"; # Added 2024-02-19 vimHugeX = vim-full; # Added 2022-12-04 vim_configurable = vim-full; # Added 2022-12-04 <ins> vinegar = throw "'vinegar' was removed due to being blocked by Roblox, rendering the package useless"; # Added 2024-08-23 </ins> virtmanager = throw "'virtmanager' has been renamed to/replaced by 'virt-manager'"; # Converted to throw 2023-09-10 virtmanager-qt = throw "'virtmanager-qt' has been renamed to/replaced by 'virt-manager-qt'"; # Converted to throw 2023-09-10 vivaldi-widevine = throw "'vivaldi-widevine' has been renamed to/replaced by 'widevine-cdm'"; # Added 2023-02-25
Code change:
So, whenever I open Player, it starts installing Roblox, finishes, and does nothing. Even when launched from the website, starts installing, finishes, and most likely just exits. Logs show nothing important. However, when trying open Studio, the error saying " not found". Steps to reproduce the behavior: the grapejuice package (just write grapejuice in the with pkgs section) wine-wayland package (not sure if it is required, however I did) Grapejuice (I used rofi (drun), but I suppose $ would work) the message box that pops out (from wine), press "Install" to install the wine-mono thingy press the Open RobloxPlayer button, or go into Player, Initialize and Install Roblox, the behavior is the same Roblox installing and doing nothing... I expected RobloxPlayer to actually open, not install and exit... <!-- --
This is already tracked in issue

Related discussion:
text: qtads = qt5.callPackage ../games/qtads { }; <del> grapejuice = callPackage ../games/grapejuice { wine = wineWowPackages.unstable; }; </del> graphwar = callPackage ../games/graphwar { }; gtypist = callPackage ../games/gtypist { };
Code change:
I'm trying to use from nixpkgs on my laptop and use remote builders (buildbarn). This fails due to patches that are applied in nixpkgs. Vanilla Bazel has a hardcoded fallback path for bash () . This has the downside of not producing a working fallback for (bash from nixpkgs will default initialize as ). The workaround for this is to default initialize the path variables somewhere else. Currently, this is done . This works fine for local execution, since this is where this function is called. However, this function is never called for remote execution (it is a hack to override things for the local execution environment only). So when using Bazel from nixpkgs locally and enabling remote execution, the shell is set to a bash from nixpkgs during the analysis phase but the variable is explicitly left unset by many actions, leading to the PATH in bash being and resulting in errors when executing tools in a script. I think there are two possible solutions: when using remote execution, do not replace the hardcoded (this is probably not a great fix since it only works for FHS executors) instead of replacing with a regular bash from nixpkgs, add a little helper script that adds shell utils to . This way, any shell rule created by bazel has a minimal set of tools. use when turning on remote execution. This has the downside of only working when the remote builder has a shell in that path. See this for a detailed reproducer: Using bazel from nixpkgs should work with remote execution. Using this version of bazel with remote execution is becoming more viable due to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- [^1]: [^2]:
got reverted, I'll reopen it.
Could we also remove the related patch here -, or is it still needed for some reason ?
To the best of my understanding, it should be sufficient to use a prepared bash (with tools in the PATH) and remove the patch you mentioned. Probably still a good idea to test this in practice!

Related discussion:
text: , file , substituteAll , writeTextFile <ins> , writeShellApplication </ins> }: let
Code change:
I'm trying to use from nixpkgs on my laptop and use remote builders (buildbarn). This fails due to patches that are applied in nixpkgs. Vanilla Bazel has a hardcoded fallback path for bash () . This has the downside of not producing a working fallback for (bash from nixpkgs will default initialize as ). The workaround for this is to default initialize the path variables somewhere else. Currently, this is done . This works fine for local execution, since this is where this function is called. However, this function is never called for remote execution (it is a hack to override things for the local execution environment only). So when using Bazel from nixpkgs locally and enabling remote execution, the shell is set to a bash from nixpkgs during the analysis phase but the variable is explicitly left unset by many actions, leading to the PATH in bash being and resulting in errors when executing tools in a script. I think there are two possible solutions: when using remote execution, do not replace the hardcoded (this is probably not a great fix since it only works for FHS executors) instead of replacing with a regular bash from nixpkgs, add a little helper script that adds shell utils to . This way, any shell rule created by bazel has a minimal set of tools. use when turning on remote execution. This has the downside of only working when the remote builder has a shell in that path. See this for a detailed reproducer: Using bazel from nixpkgs should work with remote execution. Using this version of bazel with remote execution is becoming more viable due to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- [^1]: [^2]:
got reverted, I'll reopen it.
Could we also remove the related patch here -, or is it still needed for some reason ?
To the best of my understanding, it should be sufficient to use a prepared bash (with tools in the PATH) and remove the patch you mentioned. Probably still a good idea to test this in practice!

Related discussion:
text: defaultShellPath = lib.makeBinPath defaultShellUtils; <ins> bashWithDefaultShellUtils = writeShellApplication { name = "bash"; runtimeInputs = defaultShellUtils; text = '' if [[ "$PATH" == "/no-such-path" ]]; then export PATH=${defaultShellPath} fi exec ${bash}/bin/bash "$@" ''; }; </ins> platforms = lib.platforms.linux ++ lib.platforms.darwin; system = if stdenv.hostPlatform.isDarwin then "darwin" else "linux";
Code change:
I'm trying to use from nixpkgs on my laptop and use remote builders (buildbarn). This fails due to patches that are applied in nixpkgs. Vanilla Bazel has a hardcoded fallback path for bash () . This has the downside of not producing a working fallback for (bash from nixpkgs will default initialize as ). The workaround for this is to default initialize the path variables somewhere else. Currently, this is done . This works fine for local execution, since this is where this function is called. However, this function is never called for remote execution (it is a hack to override things for the local execution environment only). So when using Bazel from nixpkgs locally and enabling remote execution, the shell is set to a bash from nixpkgs during the analysis phase but the variable is explicitly left unset by many actions, leading to the PATH in bash being and resulting in errors when executing tools in a script. I think there are two possible solutions: when using remote execution, do not replace the hardcoded (this is probably not a great fix since it only works for FHS executors) instead of replacing with a regular bash from nixpkgs, add a little helper script that adds shell utils to . This way, any shell rule created by bazel has a minimal set of tools. use when turning on remote execution. This has the downside of only working when the remote builder has a shell in that path. See this for a detailed reproducer: Using bazel from nixpkgs should work with remote execution. Using this version of bazel with remote execution is becoming more viable due to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- [^1]: [^2]:
got reverted, I'll reopen it.
Could we also remove the related patch here -, or is it still needed for some reason ?
To the best of my understanding, it should be sufficient to use a prepared bash (with tools in the PATH) and remove the patch you mentioned. Probably still a good idea to test this in practice!

Related discussion:
text: # If you add more replacements here, you must change the grep above! # Only files containing /bin are taken into account. substituteInPlace "$path"  <del> --replace /bin/bash ${bash}/bin/bash  --replace "/usr/bin/env bash" ${bash}/bin/bash  </del> <ins> --replace /bin/bash ${bashWithDefaultShellUtils}/bin/bash  --replace "/usr/bin/env bash" ${bashWithDefaultShellUtils}/bin/bash  </ins> --replace "/usr/bin/env python" ${python3}/bin/python  --replace /usr/bin/env ${coreutils}/bin/env  --replace /bin/true ${coreutils}/bin/true
Code change:
I'm trying to use from nixpkgs on my laptop and use remote builders (buildbarn). This fails due to patches that are applied in nixpkgs. Vanilla Bazel has a hardcoded fallback path for bash () . This has the downside of not producing a working fallback for (bash from nixpkgs will default initialize as ). The workaround for this is to default initialize the path variables somewhere else. Currently, this is done . This works fine for local execution, since this is where this function is called. However, this function is never called for remote execution (it is a hack to override things for the local execution environment only). So when using Bazel from nixpkgs locally and enabling remote execution, the shell is set to a bash from nixpkgs during the analysis phase but the variable is explicitly left unset by many actions, leading to the PATH in bash being and resulting in errors when executing tools in a script. I think there are two possible solutions: when using remote execution, do not replace the hardcoded (this is probably not a great fix since it only works for FHS executors) instead of replacing with a regular bash from nixpkgs, add a little helper script that adds shell utils to . This way, any shell rule created by bazel has a minimal set of tools. use when turning on remote execution. This has the downside of only working when the remote builder has a shell in that path. See this for a detailed reproducer: Using bazel from nixpkgs should work with remote execution. Using this version of bazel with remote execution is becoming more viable due to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- [^1]: [^2]:
got reverted, I'll reopen it.
Could we also remove the related patch here -, or is it still needed for some reason ?
To the best of my understanding, it should be sufficient to use a prepared bash (with tools in the PATH) and remove the patch you mentioned. Probably still a good idea to test this in practice!

Related discussion:
text: # bazel test runner include references to /bin/bash substituteInPlace tools/build_rules/test_rules.bzl  <del> --replace /bin/bash ${bash}/bin/bash </del> <ins> --replace /bin/bash ${bashWithDefaultShellUtils}/bin/bash </ins> for i in $(find tools/cpp/ -type f) do substituteInPlace $i  <del> --replace /bin/bash ${bash}/bin/bash </del> <ins> --replace /bin/bash ${bashWithDefaultShellUtils}/bin/bash </ins> done # Fixup scripts that generate scripts. Not fixed up by patchShebangs below. substituteInPlace scripts/bootstrap/compile.sh  <del> --replace /bin/bash ${bash}/bin/bash </del> <ins> --replace /bin/bash ${bashWithDefaultShellUtils}/bin/bash </ins> # add nix environment vars to .bazelrc cat >> .bazelrc <<EOF