jiebi/CodeConvo huggingface dataset:
Change:
<ins> diff --git a/main.go b/main.go index 23c4756..c52e9c3 100644 --- a/main.go +++ b/main.go @@ -335,7 +335,7 @@ func main() { gtkSettings, _ = gtk.SettingsGetDefault() -	builder, _ := gtk.BuilderNewFromFile("/usr/share/nwg-look/main.glade") +	builder, _ := gtk.BuilderNewFromFile("@out@/share/nwg-look/main.glade") win, _ := getWindow(builder, "window") win.Connect("destroy", func() { diff --git a/tools.go b/tools.go index e6e7665..59d6f35 100644 --- a/tools.go +++ b/tools.go @@ -1034,7 +1034,7 @@ func getDataDirs() []string { if os.Getenv("XDG_DATA_DIRS") != "" { xdgDataDirs = os.Getenv("XDG_DATA_DIRS") } else { -		xdgDataDirs = "/usr/local/share/:/usr/share/" +		xdgDataDirs = "@out@/local/share/:@out@/share/" } for _, d := range strings.Split(xdgDataDirs, ":") { @@ -1280,7 +1280,7 @@ func detectLang() string { } func loadVocabulary(lang string) map[string]string { -	langsDir := "/usr/share/nwg-look/langs/" +	langsDir := "@out@/share/nwg-look/langs/" enUSFile := filepath.Join(langsDir, "en_US.json") if pathExists(enUSFile) { log.Infof(">>> Loading basic lang from '%s'", enUSFile) </ins>

Discussion:
Project description A GTK3 settings editor adapted to work in the wlroots environment, a part of the nwg-shell project. <!-- Describe the project a little: --Metadata homepage URL: https://nwg- source URL: license: MIT platforms: Linux
I am happy to work on this and I am currently working a pr to implement it!
Change:
pytestFlagsArray = [ "tests/unit" <ins> ]; disabledTestPaths = [ </ins> # requires puresasl <del> "--ignore=tests/unit/advanced/test_auth.py" </del> <ins> "tests/unit/advanced/test_auth.py" </ins> ]; disabledTests = [ # doesn't seem to be intended to be run directly

Discussion:
Describe the bug gremlinpython (a dependency of cassandra-driver, but otherwise no idea how important it is) fails to build. To Reproduce Steps to reproduce the behavior: a recent checkout of nixpkgs -build -I nixpkgs=. -p python3Packages.gremlinpython how attempts to fetch something from the interwebs Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(cmm): nixpkgs: Maintainer information:
Should be fixed by .
Change:
fontconfig ]; <ins> # Required for OneClick makeWrapperArgs = [ ''--prefix PATH : "${lib.makeBinPath [ xdg-utils ]}"'' ]; </ins> meta = with lib; { description = "Yet another mod installer for Beat Saber, heavily inspired by ModAssistant"; homepage = "https://github.com/affederaffe/BeatSaberModManager";

Discussion:
BeatSaberModManager does not launch without having xdg-utils installed. Add BeatSaberModManager to package list, but not xdg-utils, try to run it. It exits with error code 255. A log file is created containing: run in , and it runs with no issue. I would make a PR, but when I tried to build the package, I got and do not have time right now to debug. ping maintainer: Thanks.
Thanks for the report, I'll take a look!
I am not able to reproduce this issue on . I have moved my and can run without issue.
Aha, you need to enable OneClick support and then restart the app for this error to manifest itself.
Change:
stdenv.mkDerivation rec { pname = "yEd"; <del> version = "3.19.1"; </del> <ins> version = "3.19.1.1"; </ins> src = fetchzip { url = "https://www.yworks.com/resources/yed/demo/${pname}-${version}.zip"; <del> sha256 = "19bnzpwszfrlpi5ssgfsv29gdmfj7pvxad9z8fdjf9k61187dgqj"; </del> <ins> sha256 = "0px88rc1slf7n1n8lpk56hf29ppbnnd4lrqfyggihcr0pxmw157c"; </ins> }; nativeBuildInputs = [ makeWrapper unzip ];

Discussion:
To (maybe) reproduce, install using the stable 19.09 channel. Strangely, I have two machines which have the same Nix modulo some minimal hardware-generated and device-specific configuration. This only fails on one of them. Metadata Weird, what's that about? terminates with no issues.
Changing the version from 3.19.1 to 3.19.1.1 makes it work:
Going further I've also a parameter for high-DPI screens, but this necessitates using .
Change:
, openvpn-mullvad , shadowsocks-rust }: <del> let # result of running address_cache as of 02 Mar 2022 bootstrap-address-cache = writeText "api-ip-address.txt" '' 193.138.218.78:443 193.138.218.71:444 185.65.134.66:444 185.65.135.117:444 217.138.254.130:444 91.90.44.10:444 ''; in </del> rustPlatform.buildRustPackage rec { pname = "mullvad"; <del> version = "2022.1"; </del> <ins> version = "2022.2"; </ins> src = fetchFromGitHub { owner = "mullvad"; repo = "mullvadvpn-app"; rev = version; <del> hash = "sha256-bLwuM3Qy2iStbXIvDEWp31vuiihSQThOej297XKo5Xc="; </del> <ins> hash = "sha256-ZtQKzbFrkacrfPIkMz/UOfIwQBXQUoVVlFla//jmMwY="; </ins> }; <del> cargoHash = "sha256-CBbm8cJHTjyvvzCFQfKmsE5d9N7azEm8nI6KeWLVaa8="; </del> <ins> cargoHash = "sha256-J6h3KY1RDCnAc/tQHNGEyOlVQoQNhRqjWbmimPitydQ="; </ins> nativeBuildInputs = [ pkg-config

Discussion:
Latest version uses Electron 18 instead of 16, which fixes issues with Wayland + Nvidia graphics. <!-- 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: mullvad-vpn <!-- 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.2 <!-- 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.
Change:
<ins> { pkgs ? import ../../../.. { config = {}; overlays = []; } }: pkgs.lib.mapAttrs (k: v: pkgs.writeDirectReferencesToFile v) (import ./sample.nix { inherit pkgs; }) </ins>

Discussion:
There is an issue in the test by . This line introduces a dependency on the contents of nixpkgs, making every change evaluate with a different hash. cc
Steps to reproduce:
You're absolutely right, but I don't think I see the impact of this fact. It's not recursed into (no /) and it's not even built by ofborg. The test needs to compare results, but perhaps the actual evaluation can be removed from it; injected as store paths by the test runner instead. It won't make the test easier to read :(
This currently impacts every ofborg evaluation. For example:
I have no idea how to solve this. Why would ofborg have a different hash for multiple evaluations? Cause it puts stuff in the nixpkgs path?
is the whole Nixpkgs source tree, which kinda always changes. Here's a solution . Not pretty but still quick to run outside the sandbox and solves this issue.
Still an issue ?
Ofborg doesn't rebase PRs so if the PR is based on a master that's of the wrong age, you'll still see this happen. Please check that the PR includes the improved test.
I did, and it's been more than 12 hours since the commit landed. At the same time my original repro doesn't see the issue:
It's a broader issue that applies to all NixOS tests, , but it went under the radar.
This seems to be fixed now. Thanks for looking into this!
Change:
# the environment used for building. dumpVars() { if [ "${noDumpEnvVars:-0}" != 1 ]; then <del> export > "$NIX_BUILD_TOP/env-vars" || true </del> <ins> export >| "$NIX_BUILD_TOP/env-vars" || true </ins> fi }

Discussion:
[Moved here from , where claims that this is an issue with stdenv and refers to as proof.] When I run in the source tree of , I get this: I just installed nix today so I assume I am running the current version. I have this in my : points at: I freely admit that this may be a problem with rss2email rather than a problem with nix, but it's not self-evidently that and I don't know how to debug further. Any insight you have would be appreciated.
btw, this is happening all of the time for me, I am surprised nobody opened a ticket for this already.
So we can fix this by doing a in dumpVars. It sounds like this happens when you have the option set in bash.
Opened to fix.
Yay , I also have this issue.
Change:
lib, fetchFromGitHub, bambu-studio, <ins> opencv2, </ins> }: bambu-studio.overrideAttrs ( finalAttrs: previousAttrs: { <del> version = "2.0.0"; </del> <ins> version = "2.1.1"; </ins> pname = "orca-slicer"; <del> # Don't inherit patches from bambu-studio patches = [ ./0001-not-for-upstream-CMakeLists-Link-against-webkit2gtk-.patch ]; </del> src = fetchFromGitHub { owner = "SoftFever"; repo = "OrcaSlicer"; rev = "v${finalAttrs.version}"; <del> hash = "sha256-YlLDUH3ODIfax5QwnsVJi1JjZ9WtxP3ssqRP1C4d4bw="; </del> <ins> hash = "sha256-7fusdSYpZb4sYl5L/+81PzMd42Nsejj+kCZsq0f7eIk="; </ins> }; <ins> patches = previousAttrs.patches ++ [ # FIXME: only required for 2.1.1, can be removed in the next version ./0002-fix-build-for-gcc-13.diff ./dont-link-opencv-world.patch ]; buildInputs = previousAttrs.buildInputs ++ [ opencv2 ]; preFixup = '' gappsWrapperArgs+=( # Fixes blackscreen dialogs --set WEBKIT_DISABLE_COMPOSITING_MODE 1 ) ''; </ins> # needed to prevent collisions between the LICENSE.txt files of # bambu-studio and orca-slicer. postInstall = ''

Discussion:
Package name: orca-slicer Latest released version: 2.1.1 <!-- Search your package here: --- Current version on the unstable channel: 2.0.0 Current version on the stable/release channel: 2.0.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! --- <!-- 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]:
please change update from 2.0.0 to 2.1.1 due to some major bugs in 2.1.0
Change:
++ lib.optional (stdenv.isDarwin && stdenv.isAarch64) cc; substitutions = { <del> cc = "${cc}/bin/cc ${lib.escapeShellArgs (map (s: "-fsanitize=${s}") sanitizers)}"; </del> <ins> cc = "${cc}/bin/${cc.targetPrefix}cc ${lib.escapeShellArgs (map (s: "-fsanitize=${s}") sanitizers)}"; </ins> # Extract the function call used to create a binary wrapper from its embedded docstring passthru.extractCmd = writeShellScript "extract-binary-wrapper-cmd" ''

Discussion:
making a pr fixing cross compilation for some things and found this
... and defaults to which is per shrug : /
Something that seems to fix the problem, weirdly, is to add to instead of , and use in I have no idea what's going on, need a cross-compilation guru ( ?).
is special: All packages in a package set are host→target (e.g. the normal attribute), however is derived from and re-exposed as the thing that builds this package set. This gives rise to the inconsistency that is one of the few attributes in the package set that's build→host. Putting into (where it conceptually belongs) will of course pick , since it itself comes from . To pick the default compiler we should use to build here, it should take by default where would then be the package set produced by which is the actual cross compiled set: . We need to jump through these hoops because, unfortunately the default compiler / libc etc. picking logic is only done as part of picking the 's from the previous package set.
Do you mean host→target here?
Yes, fixed.
Attempting a fix in
Thanks for reporting this Artturin! Verified the PR that was made and merged :)
Change:
gnumake hugin enblend-enfuse <ins> exiftool </ins> ] }) qtWrapperArgs+=(--suffix DK_PLUGIN_PATH : ${placeholder "out"}/${kdePackages.qtbase.qtPluginPrefix}/digikam) substituteInPlace $out/bin/digitaglinktree  <del> --replace "/usr/bin/perl" "${perl}/bin/perl"  --replace "/usr/bin/sqlite3" "${sqlite}/bin/sqlite3" </del> <ins> --replace "/usr/bin/perl" "${lib.getExe perl}"  --replace "/usr/bin/sqlite3" "${lib.getExe sqlite}" </ins> ''; meta = {

Discussion:
The following message appears whenever I start digiKam: Steps to reproduce the behavior: digiKam from current unstable digiKam All tools necessary for digiKam should be in its derivation. ! system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hmm, it’s never had ExifTool in the so this at least shouldn’t be my fault. It might be as simple as just adding it . Looks like we could also patch .
It looks like it's been reporting "ExifTool process cannot be started" since at least .
Change:
{ lib , buildPythonPackage , fetchFromGitHub <ins> , setuptools </ins> , pytestCheckHook }:

Discussion:
upon importing Cerberus. Steps to reproduce the behavior: Because was introduced in Python 3.7 I suspected this might only affect some Python versions but from the above example it is clear this is more widespread. runs without error. 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.
nixos-21.11 is affected
Change:
inherit lua; }); <del> vimNox = lowPrio (vim_configurable.override { source = "vim-nox"; lua = pkgs.lua5_1; # vimNox source is from 2012, requires older lua }); </del> qpdfview = libsForQt5.callPackage ../applications/misc/qpdfview {}; qtile = callPackage ../applications/window-managers/qtile {

Discussion:
in master (at ) is built from a patched source tree for vim 7.3 from 2012 which was never updated. The resulting package's name is vimconfigurable-8.1.0001 but it actually contains vim 7.3.315. Unfortuately there's no newer version for the source at the listed URL. should either be updated or dropped from nixpkgs. Given that nobody has bothered to update it since 2012, I vote to drop it. (This issue surfaced when removed the pin of to lua 5.1 and broke because the old vim 7.3 is incompatible with lua 5.2).
Let's drop this now since no one has shown any interest.
Change:
propagatedBuildInputs = [ cloudpickle jinja2 <ins> numpy </ins> psutil <del> rich </del> pynvml <ins> rich </ins> ] ++ lib.optionals stdenv.hostPlatform.isLinux [ nvidia-ml-py ]; pythonRemoveDeps = [

Discussion:
Steps to reproduce the behavior: python312Packages.scalene Per , this failure is intentional due to some behaviour changes in setuptools. I'm not completely familiar with the change or setuptools overall, but the gist seems to be that setuptools now "prefers installed dependencies over vendored ones", whatever that means in this case. fails on () Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
EDIT: Filed a PR to fix this in Scalene.
As soon as Emery has a fix on his end, we can bump the version number or apply the patch. Edit: Watch this PR
Updated in the original sources. We need Emery to cut a new release of Scalene as we're building from the published binary. (The scalene source build is complicated.)
FYI, I managed to make source builds work. That will make future bug responses quicker.
Change:
processConfig = mkOption { description = '' Process integration configuration See http://docs.datadoghq.com/integrations/process/ ''; default = null;

Discussion:
Expected output: empty gohai can be found here: This holds for nixpkgs master.
I've submitted to fix this issue. We've worked around it until this is released by adding the derivation to our NixOS configuration repository and adding it to the unit's path, like so: NixOS will merge that option together with the already existing derivations on the unit's path, so it doesn't break the existing configuration. We've been running this change on a dozen or so live-servers and it works fine.
pull request was merged.
The fix is now in 18.03 :)
Change:
propagatedBuildInputs = [ msgpack <del> ] ++ lib.optional (!isPyPy) [ </del> <ins> ] ++ lib.optionals (!isPyPy) [ </ins> greenlet ];

Discussion:
A clear and concise description of what the bug is. Steps to reproduce the behavior: neovim 0.9.1 from unstable (/nix/store/v777qfyiinf796rgghiidn5fswgv3jyy-neovim-0.9.1/bin/nvim) neovim with healthcheck section "Python 3 provider (optional)" There should be no error shown I'll post the text output of the section, should be better than a screenshot. Add any other context about the problem here. Please run and paste the result.
seems to be broken by , opened to fix it
Change:
<ins> { config, lib, pkgs, ... }: let inherit (lib) types; cfg = config.services.open-webui; in { options = { services.open-webui = { enable = lib.mkEnableOption "Enable open-webui, an interactive chat web app"; package = lib.mkPackageOption pkgs "open-webui" { }; stateDir = lib.mkOption { type = types.path; default = "/var/lib/open-webui"; description = "State directory of open-webui."; }; host = lib.mkOption { type = types.str; default = "localhost"; description = "Host of open-webui"; }; port = lib.mkOption { type = types.port; default = 8080; description = "Port of open-webui"; }; environment = lib.mkOption { type = types.attrsOf types.str; default = { }; example = '' { OLLAMA_API_BASE_URL = "http://localhost:11434"; # Disable authentication WEBUI_AUTH = "False"; } ''; description = "Extra environment variables for open-webui"; }; }; }; config = lib.mkIf cfg.enable { systemd.services.open-webui = { description = "User-friendly WebUI for LLMs (Formerly Ollama WebUI)"; wantedBy = [ "multi-user.target" ]; after = [ "network.target" ]; preStart = '' mkdir -p ${cfg.stateDir}/static ''; environment = { STATIC_DIR = "${cfg.stateDir}/static"; DATA_DIR = "${cfg.stateDir}"; } // cfg.environment; serviceConfig = { ExecStart = "${lib.getExe cfg.package} serve --host ${cfg.host} --port ${toString cfg.port}"; WorkingDirectory = cfg.stateDir; StateDirectory = "open-webui"; RuntimeDirectory = "open-webui"; RuntimeDirectoryMode = "0755"; PrivateTmp = true; DynamicUser = true; DevicePolicy = "closed"; LockPersonality = true; MemoryDenyWriteExecute = false; # onnxruntime/capi/onnxruntime_pybind11_state.so: cannot enable executable stack as shared object requires: Permission Denied PrivateUsers = true; ProtectHome = true; ProtectHostname = true; ProtectKernelLogs = true; ProtectKernelModules = true; ProtectKernelTunables = true; ProtectControlGroups = true; ProcSubset = "all"; # Error in cpuinfo: failed to parse processor information from /proc/cpuinfo RestrictNamespaces = true; RestrictRealtime = true; SystemCallArchitectures = "native"; UMask = "0077"; }; }; }; meta.maintainers = with lib.maintainers; [ shivaraj-bh ]; } </ins>

Discussion:
Ollama is a big project and I think having a nice UI in the stable repos would make nix even better. I can help with the PR but I am new to nix and don't really understand the git workflow and all Pinging the package maintainer: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Current master is broken for (see ). However, I don’t think that should be a problem while backporting to , as .
Backport PR for 0.2.4:
To track the progress of backporting to latest , see:
I love this, thanks!!
Change:
libPath = filter (pkgs.path + "/lib"); pkgsLibPath = filter (pkgs.path + "/pkgs/pkgs-lib"); nixosPath = filter (pkgs.path + "/nixos"); <del> modules = map (p: ''"${removePrefix "${modulesPath}/" (toString p)}"'') docModules.lazy; </del> <ins> modules = "[ " + concatMapStringsSep " " (p: ''"${removePrefix "${modulesPath}/" (toString p)}"'') docModules.lazy + " ]"; passAsFile = [ "modules" ]; </ins> } '' export NIX_STORE_DIR=$TMPDIR/store export NIX_STATE_DIR=$TMPDIR/state

Discussion:
When building nixos top level, will be too long to consume. I don't have a minimal config to generate the drv but here is an example: No Error Related code: Not entirely sure which version is causing the failure --- used to be able to built on but seems to be failing afterwards. Will update once find the exact hash. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The module list grows over time, so it would make sense to hit the limit at some point. I suppose you could write the expression to a file and pass to fix the problem. I don't get why this derivation is called "lazy" though.
Change:
-    free.argtypes = [c_void_p] -    free.restype = None +_lgeos = CDLL('@libgeos_c@') <del> +free = CDLL('@libc@').free </del> <ins> +if sys.platform == 'darwin': +    # ctypes.CDLL(None) internally calls dlopen(NULL), and as the dlopen +    # manpage says, "If filename is NULL, then the returned handle is for the +    # main program". This way we can let the linker do the work to figure out +    # which libc Python is actually using. +    free = CDLL(None).free +else: +    free = CDLL('@libc@').free </ins> +free.argtypes = [c_void_p] +free.restype = None

Discussion:
Describe the bug python38Packages.shapely does not build for me on darwin. It looks like the previous release, 1.7.0, did build on hydra (). I'm not sure if this is a difference depending on the version of shapely or on the version of macosx. To Reproduce Failure It looks like this store path is specifically being by a nixpkgs patch, but that the patch refers to a file that doesn't exist. Additional context The're no here: Notify maintainers Metadata
Ah, it's broken on hydra too, so it's not just me:
I think it's possible that the regression is related to how interact with
Change:
rustPlatform.buildRustPackage rec { pname = "vaultwarden"; <del> version = "1.26.0"; </del> <ins> version = "1.27.0"; </ins> src = fetchFromGitHub { owner = "dani-garcia"; repo = pname; rev = version; <del> sha256 = "sha256-LPIc1odUBvjVJty3GYYFNhile4XBWMisLUeVtWH6xgE="; </del> <ins> hash = "sha256-QvU1Y3syr6PZbTRebbZF4sEzI4lIj1enJe2F/gGfvQM="; </ins> }; <del> cargoSha256 = "sha256-IfseODaoqlPNBlVjS+9+rKXAOq29TgULMA/ogmqg0NA="; postPatch = '' # Upstream specifies 1.57; nixpkgs has 1.56 which also produces a working # vaultwarden when using RUSTC_BOOTSTRAP=1 sed -ri 's/^rust-version = .*//g' Cargo.toml ''; </del> <ins> cargoHash = "sha256-lylRGg5pzJ4sBS3bY4ObMoJ5s5kakMLTtq1VOnmS5HM"; </ins> nativeBuildInputs = [ pkg-config ]; buildInputs = with lib; [ openssl ]

Discussion:
Package name: VaultWarden Latest released version: 1.27.0 Current version on the unstable channel: 1.27.0 Current version on the stable/release channel: 1.26.0 The currently packaged version of VaultWarden in 22.11 is out of date enough as to be incompatible with officially released BitWarden clients. As I understand it, the latest release has no drawbacks and is server backwards compatible but is compatible with the latest clients. Given that the expectation of the stable channel is to be inter-compatible with the world generally, I would expect the most currently compatible server to be present there. That is not the case presently. I think we should simply backport 1.27.0 from unstable to 22.11. Notify maintainers Note for maintainers: Please tag this issue in your PR.