jiebi/CodeConvo huggingface dataset:
Code change:
<ins> --- a/mesonbuild/coredata.py +++ b/mesonbuild/coredata.py @@ -266,18 +266,13 @@ ''' if option.endswith('dir') and os.path.isabs(value) and  option not in builtin_dir_noprefix_options: -            # Value must be a subdir of the prefix # commonpath will always return a path in the native format, so we # must use pathlib.PurePath to do the same conversion before # comparing. -            if commonpath([value, prefix]) != str(PurePath(prefix)): -                m = 'The value of the {!r} option is {!r} which must be a '  -                    'subdir of the prefix {!r}.nNote that if you pass a '  -                    'relative path, it is assumed to be a subdir of prefix.' -                raise MesonException(m.format(option, value, prefix)) -            # Convert path to be relative to prefix -            skip = len(prefix) + 1 -            value = value[skip:] +            if commonpath([value, prefix]) == str(PurePath(prefix)): +                # Convert path to be relative to prefix +                skip = len(prefix) + 1 +                value = value[skip:] return value def init_builtins(self, options): </ins>

Related discussion:
text: To prevent issues like , meson setup hook should define install directories just like stdenv and cmake do Unfortunately, simple patch like the following will not work Meson does not like it very much when the directories are not descendants of prefix See also
Code change:
<del> { pkgs, lib }: </del> <ins> { __splicedPackages, lib }: let pkgs = __splicedPackages; in </ins> rec { /* Similar to callPackageWith/callPackage, but without makeOverridable

Related discussion:
text: Describe the bug I need to list the out paths of cross compiled packages beforehand which causes an eval error. To Reproduce Steps to reproduce the behavior: Expected behavior List all out paths like `. Additional context I need this feature for nixpkgs-review when cross compiling. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(user): nixpkgs: Maintainer information:
I think its because of the lack of splicing for perl-packages. Note however, that when that is fixed, other package sets will fail with the same issue. cc
Probably multiple issues. Have seen that problem with building xwayland for aarch64 too. Removing makeWrapper helps but probably breaks it :(. But the deps don't cross-build anyway so never got that far for now. Was thinking about opening an issue but got caught up trying to find the issue -- to no avail. Not currently at my machine, might post it later.
I marked this as stale due to inactivity. &rarr;
still important to me
Fix in
Code change:
}; in python.pkgs.buildPythonApplication rec { pname = "spotdl"; <del> version = "4.1.10"; </del> <ins> version = "4.1.11"; </ins> format = "pyproject";

Related discussion:
text: Failure happens locally as well when trying to build spotdl on the nixos-23.05 branch. this the tail of the log: The last line is apparently unrelated: (maintainer) (recent bumps)
This test doesn't fail if spotdl is built using version from this nixpkgs commit , I'm not sure if this is an upstream issue with spotdl while using newer yt-dlp versions (newer than ).
Code change:
sources = { "aarch64-darwin" = fetchurl { url = "https://github.com/oven-sh/bun/releases/download/bun-v${version}/bun-darwin-aarch64.zip"; <del> hash = "sha256-aPFKKCqjKZSz/ZX5G3RiIkLHIj89MGPp+PgFbE4vpgE="; </del> <ins> hash = "sha256-xwKNDTlghNkq36wMAKSa+reROqGwMm4dZ/Hfos1zuP4="; </ins> }; "aarch64-linux" = fetchurl { url = "https://github.com/oven-sh/bun/releases/download/bun-v${version}/bun-linux-aarch64.zip"; <del> hash = "sha256-u2UlimmIE2z7qsqkAbSfi7kxuOjlJGkX4RAsUGMklGc="; </del> <ins> hash = "sha256-gaquYp4q22IJHV7Fx5GxZWVFvJzU30HOmL32lkxJeQ8="; </ins> }; "x86_64-darwin" = fetchurl { url = "https://github.com/oven-sh/bun/releases/download/bun-v${version}/bun-darwin-x64.zip"; <del> hash = "sha256-MO01plCsZRR+2kC2J0/VhXJIhchMfLtMFvidPNAXtB4="; </del> <ins> hash = "sha256-DPVnTzdGprjZ16kme3Y6xBognjWHt+0N/zk0J3dm8jY="; </ins> }; "x86_64-linux" = fetchurl { url = "https://github.com/oven-sh/bun/releases/download/bun-v${version}/bun-linux-x64.zip"; <del> hash = "sha256-yw17x8DmKktE5fNBF3JQdVSEXFwAotA7hCzfLcd6JoI="; </del> <ins> hash = "sha256-Er7QiWBhENTa9xhCIVqECCzexWejBwBC59u3CJKQiwc="; </ins> }; }; updateScript = writeShellScript "update-bun" ''

Related discussion:
text: Package name: bun Latest released version: 1.0.9Current version on the unstable channel: 1.0.7 Current version on the stable/release channel: 0.6.2 Notify maintainers People who've also recently updated the package: Note for maintainers: Please tag this issue in your PR.
Code change:
rm ./texmf.cnf sed  -e 's,texmf-dist,texmf,g'  <del> -e 's,texmf-local,texmf,g'  </del> -e "s,$SELFAUTOLOC,$out,g"  -e "s,$SELFAUTODIR,$out/share,g"  -e "s,$SELFAUTOPARENT,$out/share,g" 

Related discussion:
text: TEXMF defines the order in which files are read in The idea is that TEXMFSYSVAR and TEXMFCONFIG files take precedence over files distributed with TEXMFDIST, so there is a way for the user to override configuration files. Our lists: This seems all fine, except that our derivation also makes TEXMFLOCAL point to TEXMFDIST as well, and this destroys override-ability. My suggestion is to use a separate and empty $out/share/texmf-local for TEXMFLOCAL.
Could you please provide an example of the override that doesn't work?
I dropped my customization here: It boils down to adding a custom package (minionpro availble for my ) and running: in postBuild.
I investigated your override. I see that you sneak the original , then add your font to it and regenerate the mappings which go to share/texmf-var. At the same time our texlive setup just reuses prebuilt maps provided by (for pdftex), individual font packages and others and those are installed into share/texmf which happens to be also pointed by TEXMFLOCAL. I also now discover that the line does nothing for us. Your change makes sense to me. Makes me wonder if we could do better. For example, not deleting should not hurt anything. I could not find any way to automatically scan for new entries for The Gentoo documentation mentions [1] concatenating it from /etc/texmf/updmap.d. [1]
First of all thank you for taking such a careful look at my code snippet. I really appreciate it! First, yes, I sneak out and later sneak back in. I do think that there are no adverse side-effects from not deleting in texlive.combine. I will submit a PR to remove it. This will minimize my postBuild override to just: That looks much cleaner :) As there is no real "hooks" functionality in our texlive package derivation, it seems to be a good idea to optimistically merge (by concatenation) separate snippets. I will file a separate issue to discuss this.
Thank you!
Code change:
'') plugins} ''; <ins> # Function that automatically links the default NDK plugin. linkNdkPlugin = {name, plugin, check}: lib.optionalString check '' ln -s ${plugin}/libexec/android-sdk/${name} ${name} ''; </ins> # Function that automatically links a plugin for which only one version exists linkPlugin = {name, plugin, check ? true}: lib.optionalString check ''

Related discussion:
text: Starting with it is not possible to build the android sdk with ndk included. I tried varous ndk versions which have different failure messges: fails with fails with Steps to reproduce the behavior: the following with : Dropped into a nix-shell with androidsdk in <!-- 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.
Code change:
<del> { stdenv, fetchFromGitHub, autoreconfHook, pkgconfig, perl, pythonPackages, libiconv }: </del> <ins> { stdenv, fetchFromGitHub, autoreconfHook, pkgconfig, perl, pythonPackages, libiconv, jansson }: </ins> stdenv.mkDerivation { pname = "universal-ctags";

Related discussion:
text: universal-ctags is not built with jansson, which means that universal-ctags does not have support for outputting JSON files. Steps to reproduce the behavior: universal-ctags with error: Expected: Tags file created with json format. Additional context I think this can be resolved by simply adding to the , but I've never written a nix package before so I'm not certain. I did this locally and it seemed to work, but I don't know if there's a better way to do it. Metadata Maintainer information:
cc I took a whack at fixing this locally. If this looks good to you, let me know and I can create a PR. I'm really new to Nix so it's likely I did something wrong.
Welcome and thanks a lot for the wonderful bug description Open the PR of course! You can update the package to the last version or add yourself to maintainers too if you are agree Don't hesitate to ask if your find any troubles
Code change:
buildInputs = [ ffmpeg qtbase qtdeclarative qtlocation qtquickcontrols2 qtwebchannel qtwebengine ]; nativeBuildInputs = [ qmake qttools ]; <del> postPatch = lib.optionalString (ffmpeg != null) '' </del> <ins> patches = [ ./yt-dlp-path.patch ]; postPatch = '' substituteInPlace youtube_dl.cpp  --replace 'QString YoutubeDl::path = QString();'  'QString YoutubeDl::path = QString("${yt-dlp}/bin/yt-dlp");' '' + lib.optionalString (ffmpeg != null) '' </ins> substituteInPlace converter_ffmpeg.cpp  --replace '"ffmpeg"' '"${ffmpeg.bin}/bin/ffmpeg"'  --replace '"ffmpeg ' '"${ffmpeg.bin}/bin/ffmpeg '

Related discussion:
text: When started, ClipGrab always want to download youtube-dl. When after that, ClipGrab never finds the video and stays stuck on «please wait while ClipGrab downloads video info» (translated from french). Steps to reproduce the behavior: ... or ... Start ClipGrab ... youtube-dl dependency should be accessible, and video info should be fetched ! !
Code change:
<del> { stdenv, config, lib, fetchFromGitHub, cmake, libusb1, ninja, pkg-config, gcc </del> <ins> { stdenv , config , lib , fetchFromGitHub , fetchpatch , cmake , libusb1 , ninja , pkg-config , gcc </ins> , cudaSupport ? config.cudaSupport or false, cudatoolkit <del> , enablePython ? false, pythonPackages ? null }: </del> <ins> , enablePython ? false, pythonPackages ? null }: </ins> assert cudaSupport -> cudatoolkit != null; assert enablePython -> pythonPackages != null;

Related discussion:
text: Describe the bug librealsense cannot be built on/for aarch64-linux. I see that the derivation says it is not supported on aarch64-linux but I also know it is possible to compile the library normally on that platform as I have done it before. So I think its just a problem with the derivation for now. I am willing to help in the work to fix the recipe, and test the fixes, but I am relatively new to the nix language and build system. I have attached the error message I get, could someone point me in the direction I should be looking to fix it? To Reproduce Steps to reproduce the behavior: Screenshots Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Maintainer information:
Hello! I tried it and got similar errors building graphite, though I can get it to build when I use the versions of the libraries so maybe that's a good place to start? I'm not sure what the issue is unfortunately.
I fixed the build of on aarch64-darwin and aarch64-linux in PR will not work on aarch64 unless somebody fixes the build of package on aarch64 theoretically should work, but in reality the build of which is a dependency fails on aarch64 Will you please open two new issues for and not available for aarch64? The build failures you see have nothing to do with librealsense.
Code change:
postInstall = '' mkdir -p $out/lib/password-store/extensions <del> cp ${src}/import.bash $out/lib/password-store/extensions/import.bash </del> <ins> cp import.bash $out/lib/password-store/extensions/import.bash </ins> wrapProgram $out/lib/password-store/extensions/import.bash  --prefix PATH : "${python3Packages.python.withPackages (_: propagatedBuildInputs)}/bin"  --prefix PYTHONPATH : "$out/${python3Packages.python.sitePackages}"  --run "export PREFIX" <del> cp -r ${src}/share $out/ </del> <ins> cp -r share $out/ </ins> ''; postCheck = ''

Related discussion:
text: Package name: Latest released version: 3.5 <!-- Search your package here: --- Current version on the unstable channel: 3.2 Current version on the stable/release channel: 3.2 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
BINARY = 64; TARGET = setTarget "ATHLON"; DYNAMIC_ARCH = setDynamicArch true; <ins> NO_AVX512 = !enableAVX512; </ins> USE_OPENMP = !stdenv.hostPlatform.isMusl; };

Related discussion:
text: Describe the bug In the AVX512 support was turned back on in openblas, allowing for the use of dynamic, AVX512 optimized compute kernels. started to discover problems with AVX512 while working on the and I can confirm that this problem affects multiple packages that are built against openblas. The problem already manifest itself in that packages fail their unit tests, when build on an AVX512 enabled machine (see for a detailed list). The tests either fail due to a wrong result or time out. I could indentify 5 different packages which are affected by this bug, leading to the conclusions this very likely affects many more packages. Affected versions of openblas, which I have tested, are 0.3.13 (master/release-21.05) and 0.3.15 (in staging at the moment). The problem disappears when: is complied with in is injected into the test phase or just set at runtime. Note that any core type that does not use AVX512 works fine here (tested: , or , but , which uses AVX512 fails). is turned off at openblas build time and is set to a non-AVX512 target (see point 2). you seem to be making use AVX512 optimizations. Did you notice any problems? I suggest to revert and thus re-introduce the makeFlag in openblas. To Reproduce an affected program which is linked against openblas on an Intel CPU that supports AVX512 instructions (e.g. Xeon Scalable) and check the results. In nixpkgs it is at least that is affected (delivers wrong results). , for example, on an Intel CPU with AVX512: the self tests/unit tests never finish in this case. external packages fail to run their tests on and AVX512 enabled machine: Notify maintainers CC Metadata This should affect since (~January 2021) and . The tests I have carried out were run with versions from the ~last week.
Sorry to hear that :(. Then we should indeed revert that change again.
Can this be closed?
The PR has been merged into staging. Should we wait to close the issue until the fix reaches master?
Code change:
<ins> { addressable = { dependencies = ["public_suffix"]; groups = ["default"]; platforms = []; source = { remotes = ["https://rubygems.org"]; sha256 = "022r3m9wdxljpbya69y2i3h9g3dhhfaqzidf95m6qjzms792jvgp"; type = "gem"; }; version = "2.8.0"; }; bson = { groups = ["default"]; platforms = []; source = { remotes = ["https://rubygems.org"]; sha256 = "03n3w96vpblaxvk1qk8hq7sbsmg4nv7qdkdr8f7nfvalgpakp5i5"; type = "gem"; }; version = "4.14.1"; }; ipaddr = { groups = ["default"]; platforms = []; source = { remotes = ["https://rubygems.org"]; sha256 = "13qd34nzpgp3fxfjbvaqg3dcnfr0cgl5vjvcqy0hfllbvfcklnbq"; type = "gem"; }; version = "1.2.4"; }; json = { groups = ["default"]; platforms = []; source = { remotes = ["https://rubygems.org"]; sha256 = "1z9grvjyfz16ag55hg522d3q4dh07hf391sf9s96npc0vfi85xkz"; type = "gem"; }; version = "2.6.1"; }; mongo = { dependencies = ["bson"]; groups = ["default"]; platforms = []; source = { remotes = ["https://rubygems.org"]; sha256 = "19sihy8ihi3hmdg3gxbf4qvzmjnzx8xygg9534012j9z0wmhs7h1"; type = "gem"; }; version = "2.17.1"; }; public_suffix = { groups = ["default"]; platforms = []; source = { remotes = ["https://rubygems.org"]; sha256 = "1xqcgkl7bwws1qrlnmxgh8g4g9m10vg60bhlw40fplninb3ng6d9"; type = "gem"; }; version = "4.0.6"; }; rchardet = { groups = ["default"]; platforms = []; source = { remotes = ["https://rubygems.org"]; sha256 = "1isj1b3ywgg2m1vdlnr41lpvpm3dbyarf1lla4dfibfmad9csfk9"; type = "gem"; }; version = "1.8.0"; }; } </ins>

Related discussion:
text: Project description A scanner informing the technologies and headers a website uses. Metadata homepage URL: source URL: license: GPL-2.0 platforms: Agnostic (Darwin, Linux, Windows) See also:
I was able to build it, check it here
Thanks!
Code change:
(assertMacAddress "MACAddress") ]; <ins> # NOTE The PrivateKey directive is missing on purpose here, please # do not add it to this list. The nix store is world-readable let's # refrain ourselves from providing a footgun. checkWireGuard = checkUnitConfig "WireGuard" [ (assertOnlyFields [ "PrivateKeyFile" "ListenPort" "FwMark" ]) (assertRange "FwMark" 1 4294967295) ]; # NOTE The PresharedKey directive is missing on purpose here, please # do not add it to this list. The nix store is world-readable,let's # refrain ourselves from providing a footgun. checkWireGuardPeer = checkUnitConfig "WireGuardPeer" [ (assertOnlyFields [ "PublicKey" "PresharedKeyFile" "AllowedIPs" "Endpoint" "PersistentKeepalive" ]) (assertRange "PersistentKeepalive" 1 65535) ]; </ins> checkVlan = checkUnitConfig "VLAN" [ (assertOnlyFields ["Id" "GVRP" "MVRP" "LooseBinding" "ReorderHeader"]) (assertRange "Id" 0 4094)

Related discussion:
text: This configuration: If you poke around in the configuration I linked, you should see that I disable NetworkManager and use a static configuration for my main NIC. I can't think of anything special in my config or with this machine that would affect my usage of Wireguard, but I'm also new to using Wireguard. I'm currently on nixpkgs with a few of my own commits on top of . Please run and paste the results.
It doesn't seem happy when already exists... I have done two things, both of which were necessary, to resolve this: the link manually () sure the path to the private key exists (if not, you get a different failure in the journal, with failing). (It's possible that fixing the private key path and rebooting would have been sufficient). I'm leaving this open for two reasons: user should receive a better error message in both cases. that we're in NixOS, we should assume full control of the interface and just re-configure it, instead of failing in the setup script.
I ran into this issue after trying to debug my wireguard setup. My setup is essentialy identical and I get the same error message. Running the start script that is causing the error results in this output. The offending 2 lines are .
I had to go one step further than deleting the interface. I needed to stop the via then redeploy configuration. But this solved it for me. Nixos should handle this much more gracefully.
I had to remove the routes with etc.
The command is . You can build it in your conf as pre-setup command, but it has the nasty side effect that it possible interferes with other connections.
I am still running into this issue.
Code change:
index 0000000..44a7fbd --- /dev/null +++ b/dust.in <del> @@ -0,0 +1,43 @@ </del> <ins> @@ -0,0 +1,40 @@ </ins> +#!/usr/bin/env bash + +base_path=@basePath@ +pixie_path=@pixiePath@ <ins> +rlwrap_cmd=@rlwrapPath@ </ins> + +function set_load_path() { +    load_path=""

Related discussion:
text: Running reports: To Reproduce on NixOS 19.09. . Metadata I ran but got .
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
I had this same problem today.
I marked this as stale due to inactivity. &rarr;
Not stale; this is still a problem on a flakes based NixOS system using
Code change:
buildPythonPackage rec { pname = "msal-extensions"; <del> version = "1.1.0"; </del> <ins> version = "1.2.0"; </ins> pyproject = true; disabled = pythonOlder "3.7";

Related discussion:
text: Trying to run an action with azure-cli that requries authentication, az will fail to read the cached authentication token from the token cache: This is due to a version mismatch of . will update the package, I checked that the authentication works afterwards. That's me! Please run and paste the result. ` Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I also experience this issue with , as well as with . Thanks for adding the fix!
Code change:
<ins> { lib , stdenv , fetchFromGitHub , substituteAll , python3 , ghostscript , coreutils , pdftk , poppler_utils }: let python-env = python3.withPackages (ps: with ps; [ tkinter ]); in stdenv.mkDerivation { pname = "pdf-sign"; version = "unstable-2023-08-08"; src = fetchFromGitHub { owner = "svenssonaxel"; repo = "pdf-sign"; rev = "98742c6b12ebe2ca3ba375c695f43b52fe38b362"; hash = "sha256-5GRk0T1iLqmvWI8zvZE3OWEHPS0/zN/Ie9brjZiFpqc="; }; patches = [ (substituteAll { src = ./use-nix-paths.patch; gs = "${ghostscript}/bin/gs"; mv = "${coreutils}/bin/mv"; pdftk = "${pdftk}/bin/pdftk"; pdfinfo = "${poppler_utils}/bin/pdfinfo"; }) ]; buildInputs = [ python-env ]; installPhase = '' runHook preInstall mkdir -p $out/bin cp pdf-sign pdf-create-empty $out/bin patchShebangs $out/bin runHook postInstall ''; meta = { description = "A tool to visually sign PDF files"; homepage = "https://github.com/svenssonaxel/pdf-sign"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ tomasajt ]; platforms = lib.platforms.unix; }; } </ins>

Related discussion:
text: Project description From the project page: A tool to sign PDF files with Linux support. Why There appears to be a lack of applications that run on Linux and allow for attaching free-hand signatures to PDF files in a good way. (Non-)alternatives include: Xournal and Xournal++: Allows free-hand annotations but not saving those for later use. Allows inserting images and .pdf files but will rasterize them rather than retain the vector graphics, resulting in lower quality. LibreOffice Draw: Allows inserting images and .pdf files but will rasterize them rather than retain the vector graphics, resulting in lower quality. Okular: Allows free-hand annotations but not saving those for later use. Allows inserting custom saved stamps, but these will not be visible in other PDF readers. Evince: Allows certain kinds of annotations, but nothing that can look like a free-hand signature. pdftk, Ghostscript, and other command-line tools: Allows superimposing .pdf files, but not interactively selecting where. Metadata homepage URL: source URL: license: MIT platforms: linux
Working on it