jiebi/CodeConvo huggingface dataset:
Code change:
cd ../.. <ins> # Symlink required sources mkdir -p sources cd sources ${if includeSources then stdenv.lib.concatMapStrings (platformVersion: if (builtins.hasAttr ("source_"+platformVersion) sources) then let source = builtins.getAttr ("source_"+platformVersion) sources; in "ln -s ${source}/* android-${platformVersion}n" else "") platformVersions else ""} cd .. </ins> # Symlink required platforms mkdir -p platforms

Related discussion:
text: Currently, our Android SDK derivations contain only binary files. This is unfortunate during development, when one wants to jump to a definition of a particular symbol in the SDK and it is not found. For comparison, ArchLinux is doing this in their packages, e.g. System: 16.09pre-git (Flounder) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "16.09beta335." /cc
Created PR .
Code change:
# package customization , enableNaCl ? false <del> , enableHotwording ? false </del> , enableWideVine ? false , gnomeSupport ? false, gnome ? null , gnomeKeyringSupport ? false, libgnome-keyring3 ? null

Related discussion:
text: When building chromium with args like this and the gn args aren't known/accepted by chromium (like the above one actually is that is still given incorrectly in 18.03), it will print: but continue to build anyway, which can be super surprising when your build doesn't do what you expect. We should catch that when building. Unfortunately doesn't seem to have a feature to warn. But we can run to see the in stdout and grep for it: I have confirmed that only seems to work that way when giving a build target, like . CC
Suggestion: We switch to
PR
pull request was merged.
Code change:
dontAutoPatchelf = true; postFixup = (attrs.postFixup or "") + optionalString (stdenv.isLinux) '' ( <del> cd $out/clion-${version} </del> <ins> cd $out/clion </ins> # bundled cmake does not find libc rm -rf bin/cmake/linux ln -s ${cmake} bin/cmake/linux

Related discussion:
text: CLion 2021.3.3 derivation fails to build. Steps to reproduce the behavior: to system/user packages The system rebuilds. Seems the folder has been renamed to just : Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(zane): channels(root): nixpkgs:
Same issues here, waiting for fix : (
cc
Code change:
postInstall = '' wrapProgram $out/bin/git-flow  <del> --set FLAGS_GETOPT_CMD ${pkgs.getopt}/bin/getopt  --suffix PATH : ${pkgs.git}/bin  --prefix PATH : ${pkgs.coreutils}/bin </del> <ins> --set FLAGS_GETOPT_CMD ${getopt}/bin/getopt  --suffix PATH : ${git}/bin  --prefix PATH : ${coreutils}/bin </ins> ''; meta = with lib; {

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:
{ fetchurl }: rec { <del> version = "1.6.23"; </del> <ins> version = "1.6.24"; </ins> src = fetchurl { url = "http://www.openafs.org/dl/openafs/${version}/openafs-${version}-src.tar.bz2"; <del> sha256 = "1gy7a0jhagxif8av540xb1aa6cl7id08nsgjbgady54bnmb0viga"; </del> <ins> sha256 = "1dxzc1y5mmx3ap0m94sx80vfs3qxkckid3wc1xm0wr5i6fh7zn1h"; </ins> }; srcs = [ src (fetchurl { url = "http://www.openafs.org/dl/openafs/${version}/openafs-${version}-doc.tar.bz2"; <del> sha256 = "18my71s9mddy0k835852ksjzkza7xs73kyxavmdqflh5vkywb6y0"; </del> <ins> sha256 = "0aq9ipqpr2ksmk30h2dc4mlrkrqs16xnmspwfb6xj3rgr1pwszlx"; </ins> })]; }

Related discussion:
text: , CVSSv3=7.5 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) CVSSv3=5.9 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives. Cc Cc
A security update 1.6.24 addressing the vulnerabilities exists. I'd suggest marking openafs-1.6 as broken, now, to enforce migration to openafs-1.8. I am unaware of plans to further maintain openafs-1.6 beyond 1.6.24. Edit: Maybe, we should do both, update to 1.6.24 and mark it broken. So, users have a secure version as of now and still get the hint to take action.
Alternative idea: Go with only openafs 1.8 on master and upgrade to openafs 1.6.24 on NixOS 20.03. This way, user must migrate to 1.8 when upgrading to NixOS 20.09 which is the only sensible action security wise.
This is fixed with the move to 1.6.24 for 20.09. Closed.
Code change:
crow-translate = libsForQt5.callPackage ../applications/misc/crow-translate { }; <del> cryptowatch-desktop = callPackage ../applications/finance/cryptowatch { }; </del> dae = callPackage ../tools/networking/dae { }; darling = callPackage ../applications/emulators/darling { };

Related discussion:
text: Steps to reproduce the behavior: cryptowatch-desktop download url redirects to a blog Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
As of September the 30th 2023, Cryptowatch was sunset and users were advised to use their parent companies offering Kraken Pro. I'll create a pull request to remove cryptowatch from nixpkgs as there aren't any archives available that contain it that are reliable
Code change:
local dst="$1" local wrapper="$2" export prog="$3" <del> export use_response_file_by_default=${if isClang then "1" else "0"} </del> <ins> export use_response_file_by_default=${if isClang && !isCcache then "1" else "0"} </ins> substituteAll "$wrapper" "$out/bin/$dst" chmod +x "$out/bin/$dst" }

Related discussion:
text: Describe the bug hides clang arguments in a "response file" by default if is true, but ccache does not support this and responds with "no input files" instead. Additional context The following workaround can be used to disable response files in a result , fixing the issue: Notify maintainers Maintainer information:
I've run into this issue as well. Edit: my bad, that doesn't work; we need the env var to be set before the outer layer of stdenv wrapper machinery runs. By the time we're in the ccache wrapper it's too late. It's also not clear to me if this is a bug in or intended behavior (I was not able to find an issue for it upstream) but it's definitely reproducible:
Code change:
let pname = "ollama"; # don't forget to invalidate all hashes each update <del> version = "0.1.48"; </del> <ins> version = "0.2.1"; </ins> src = fetchFromGitHub { owner = "ollama"; repo = "ollama"; rev = "v${version}"; <del> hash = "sha256-rMStHUFC88TXIH/1c9bCOU0csnEZHOhWKBlLKarmCmE="; </del> <ins> hash = "sha256-hzB/sS+6vsMuJfCPZucTQerytnq+TBzTtiWwwd+H+bE="; </ins> fetchSubmodules = true; };

Related discussion:
text: Package name: Ollama Latest released version: 0.2.1 <!-- Search your package here: --- Current version on the unstable channel: 0.1.48 Current version on the stable/release channel: 0.1.38 <!-- 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:
, ilmbase, gtk3, intltool, lcms2, lensfun, libX11, libexif, libgphoto2, libjpeg , libpng, librsvg, libtiff, openexr, osm-gps-map, pkgconfig, sqlite, libxslt , openjpeg, lua, pugixml, colord, colord-gtk, libwebp, libsecret, gnome3 <ins> , ocl-icd </ins> }: stdenv.mkDerivation rec {

Related discussion:
text: Darktable can make use of OpenCL, but the nix package apparently isn't set up properly to allow this. Run : system: host os: multi-user?: sandbox: version: channels(root): channels(lukas): nixpkgs: OpenCL is set up properly on my system: cc darktable maintainers:
I'd been meaning to fix this for myself for awhile. Should be good now, pending review.
Thanks!
Sorry to revive this, but I am still having this problem in dartable 2.4.4 using intel OpenCL Neo driver. Should ti be already solved? Or the fix is still not present in 2.4.4? Thanks
Disregard (at least partially) my last comment. I was using the snap version in Ubuntu 18.10. Using the deb, OpenCl works. Where should I submit the bug for the snap version?
Code change:
then tag else lib.head (lib.strings.splitString "-" (baseNameOf result.outPath)); <del> # Docker can't be made to run darwin binaries meta.badPlatforms = lib.platforms.darwin; </del> } '' ${lib.optionalString (tag == null) '' outName="$(basename "$out")"

Related discussion:
text: Using on macOS requires using . Steps to reproduce the behavior: a new nix file: it with error The derivation and the built docker image work fine, and should build correctly even without . I believe this might be due to , while it's true docker cannot run macOS binaries, nix can be used to build Linux binaries on macOS, either by downloading them from a binary cache or by cross compiling, and those binaries can be put in docker images. cc
The fix is as simple as you suggest. I don't expect any problems with . Some users already do what you're doing but with .
Code change:
executableName = "codium"; longName = "VSCodium"; <del> shortName = "Codium"; </del> <ins> shortName = "vscodium"; </ins> src = fetchurl { url = "https://github.com/VSCodium/vscodium/releases/download/${version}/VSCodium-${plat}-${version}.${archive_fmt}";

Related discussion:
text: Describe the bug The desktop file packaged with VSCodium specifies the wrong StartupWMClass To Reproduce VSCodium on the started application Expected behavior Step 4 prints . Therefore step 5 should print one of those strings. But instead, the file contains . Additional context Those must match or else the application won't be linked to the .desktop file when started. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels: nixpkgs: Maintainer information:
I'm surprised says that the is . After all, for it seems to be , as , and as I also just tested on my system: After all, the executable for vscode is and for vscodium it's . Nevertheless, I can reproduce your output. Since I don't know whether that could be changed, it's probably easier to simply change the file. Will push a PR in a moment.
I wish I could assign myself to this issue.
I had a quick look at the history of the and they had it this way since the beginning. So I think it's safe to assume this won't change anytime soon.
Code change:
Similarly [virtualisation.vmVariantWithBootloader](#opt-virtualisation.vmVariantWithBootLoader) was added. - The configuration portion of the `nix-daemon` module has been reworked and exposed as [nix.settings](options.html#opt-nix-settings): <del> * Legacy options have been mapped to the corresponding options under under [nix.settings](options.html#opt-nix.settings) but may be deprecated in the future. </del> <ins> * Legacy options have been mapped to the corresponding options under under [nix.settings](options.html#opt-nix.settings) and will be deprecated when NixOS 21.11 reaches end of life. </ins> * [nix.buildMachines.publicHostKey](options.html#opt-nix.buildMachines.publicHostKey) has been added. - The `writers.writePyPy2`/`writers.writePyPy3` and corresponding `writers.writePyPy2Bin`/`writers.writePyPy3Bin` convenience functions to create executable Python 2/3 scripts using the PyPy interpreter were added.

Related discussion:
text: The current process for renames puts out-of-tree modules in a situation where users are confronted with warnings they can't solve, and neither can the maintainers. Steps to reproduce the behavior: one change, create the new option/package/..., create the alias with a deprecation warning that goes into effect immediately -of-tree modules, such as home-manager, nix-darwin, start emitting warnings reports warning -of-tree module maintainer can't do anything, because stable release does not have the new option All generated warnings can be resolved by the user. Suggested process: one change, create the new option/package/... and the alias but no deprecation warning 1-7 months pass. All current branches now support the new way. enable the warning on master (more on that) -of-tree modules, such as home-manager, nix-darwin, start emitting warnings warnings can now be fixed To facilitate the process, we can add an argument to functions like to indicate the first release that will support the change. We'll maintain two (hidden?) version numbers that we update during the NixOS release process. For example, at the time of writing, the only supported stable version is 21.11 and 22.05 has not been released yet. To enable warnings on , we only need to update . Interestingly, we'll be deprecating functions that deprecate without . Sounds meta, but it's not complicated. It just means that some old style deprecations will slip through the net for some more time. (also a big one, but no complaints yet)
This is also related to NixOS/rfcs, which was a previous attempt at establishing general such deprecation behaviors
Code change:
<ins> { yarn2nix-moretea , fetchFromGitHub }: yarn2nix-moretea.mkYarnPackage rec { name = "gotify-ui"; packageJSON = ./package.json; yarnNix = ./yarndeps.nix; version = "2.0.8"; src_all = fetchFromGitHub { owner = "gotify"; repo = "server"; rev = "v${version}"; sha256 = "17bxs3wcazrxippf3i9w7d2mq8lf0v5m4bn3nl2zb8v8dl3lsc9a"; }; src = "${src_all}/ui"; buildPhase = '' yarn build ''; } </ins>

Related discussion:
text: Project description A simple server for sending and receiving messages in real-time per WebSocket. Includes a web UI, also has an Android client for receiving notifications and an optional CLI program (distributed separately) for sending notifications. Metadata homepage URL: source URL: license: MIT platforms: anything Go runs on
I started an attempt locally, however it failed due to some timeouts while fetching Go dependencies... will retry during this week :)
I think the main difficulty is the UI, which needs to be compiled with NPM. In essence, I think the build is three-staged: fetch UI dependencies, fetch Go dependencies, do the actual build.
You may want to take a look at .
Code change:
"CONF_GCC_LINKER_OPTS_STAGE2=-fuse-ld=gold" ] ++ stdenv.lib.optionals (disableLargeAddressSpace) [ "--disable-large-address-space" <del> ] ++ stdenv.lib.optional enableDwarf [ "--enable-dwarf-unwind" </del> ]; # Make sure we never relax`$PATH` and hooks support for compatability.

Related discussion:
text: Our can no longer link executables. For example: This issue is present in current versions of . Compiling and linking works fine with an older revision, say . It looks like this might be related to some change in binutils, maybe?
This is probably from
Yes, it is. came to the same conclusion.
This probably is GHC bug though. Things like gmp and libiconv get their paths hardcoded so this isn't a problem. I would expect the same treatment for elfutils. should provide a arg.
/cc
I guess now I know why there's a patch in branch.
I'll reopen the PR fixing the linking issues.
I opened while we wait on upstream fix.
Which one, from
Yes, although it doesn't help. See
Yes, it would have surprised me a bit if it helped against that symptom -- my patch fixes that DWARF-enabling is skipped completely.
I'm surprised this worked for you back then and now there are linking errors.
Code change:
<ins> { stdenv, fetchurl, appimageTools, undmg, libsecret }: let inherit (stdenv.hostPlatform) system; throwSystem = throw "Unsupported system: ${system}"; pname = "keeweb"; version = "1.15.7"; name = "${pname}-${version}"; suffix = { x86_64-linux = "linux.AppImage"; x86_64-darwin = "mac.dmg"; }.${system} or throwSystem; src = fetchurl { url = "https://github.com/keeweb/keeweb/releases/download/v${version}/KeeWeb-${version}.${suffix}"; sha256 = { x86_64-linux = "0cy0avl0m07xs523xm0rzsmifl28sv4rjb2jj3x492qmr2v64ckk"; x86_64-darwin = "0r8c3zi0ibj0bb0gfc1axfn0y4qpjqfr0xpcxf810d65kaz6wic4"; }.${system} or throwSystem; }; appimageContents = appimageTools.extract { inherit name src; }; meta = with stdenv.lib; { description = "Free cross-platform password manager compatible with KeePass"; homepage = "https://keeweb.info/"; license = licenses.mit; maintainers = with maintainers; [ sikmir ]; platforms = [ "x86_64-linux" "x86_64-darwin" ]; }; linux = appimageTools.wrapType2 rec { inherit name src meta; extraPkgs = pkgs: with pkgs; [ libsecret ]; extraInstallCommands = '' mv $out/bin/{${name},${pname}} install -Dm644 ${appimageContents}/keeweb.desktop -t $out/share/applications install -Dm644 ${appimageContents}/keeweb.png -t $out/share/icons/hicolor/256x256/apps install -Dm644 ${appimageContents}/usr/share/mime/keeweb.xml -t $out/share/mime substituteInPlace $out/share/applications/keeweb.desktop  --replace 'Exec=AppRun' 'Exec=${pname}' ''; }; darwin = stdenv.mkDerivation { inherit pname version src meta; nativeBuildInputs = [ undmg ]; sourceRoot = "KeeWeb.app"; installPhase = '' mkdir -p $out/Applications/KeeWeb.app cp -R . $out/Applications/KeeWeb.app ''; }; in if stdenv.isDarwin then darwin else linux </ins>

Related discussion:
text: Project description Keeweb webapp is a browser and desktop password manager compatible with KeePass databases. It features an Electron-based desktop application. Metadata homepage URL: source URL: license: mit platforms: Electron (unix, linux, darwin, windows) and Web
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
still important to me
While PR to nixpkgs is still open, I've keeweb to NUR repo () as well.
Code change:
, vala , wrapGAppsHook3 , glib <ins> , glib-networking </ins> , gtk3 , json-glib , libappindicator

Related discussion:
text: Gives this error: , yet installing doesn't fix the problem. Steps to reproduce the behavior: Meteo That the Maps section works. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I have this exact issue. Hoping for some clarity.
should be here:
Code change:
<ins> prefix=@out@ exec_prefix=${prefix} libdir=@out@/lib includedir=@out@/include Name: tbox Description: A glib-like multi-platform c library Version: @version@ Libs: -L${libdir} -ltbox Cflags: -I${includedir} </ins>

Related discussion:
text: Project description A lightweight cross-platform build utility based on Lua Metadata homepage URL: source URL: license: asl20 platforms: unix
Code change:
python3Packages.buildPythonApplication rec { pname = "pass-import"; <del> version = "3.2"; </del> <ins> version = "3.5"; </ins> <del> src = fetchFromGitHub { owner = "roddhjav"; repo = "pass-import"; rev = "v${version}"; sha256 = "0hrpg7yiv50xmbajfy0zdilsyhbj5iv0qnlrgkfv99q1dvd5qy56"; </del> <ins> src = fetchurl { url = "https://github.com/roddhjav/${pname}/releases/download/v${version}/${pname}-${version}.tar.gz"; hash = "sha256-+wrff3OxPkAGu1Mn4Kl0KN4FmvIAb+MnaERcD5ScDNc="; </ins> }; <del> patches = [ (fetchpatch { name = "support-for-pykeepass-4.0.3.patch"; url = "https://github.com/roddhjav/pass-import/commit/f1b167578916d971ee4f99be99ba0e86ef49015e.patch"; hash = "sha256-u6bJbV3/QTfRaPauKSyCWNodpy6CKsreMXUZWKRbee0="; }) ]; </del> propagatedBuildInputs = with python3Packages; [ cryptography defusedxml <ins> jsonpath-ng </ins> pyaml pykeepass python-magic # similar API to "file-magic", but already in nixpkgs. <ins> requests </ins> secretstorage <ins> zxcvbn </ins> ]; nativeCheckInputs = [

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:
py.test ''; <ins> patches = [ # Add Python 3.7 support. Remove with the next release (fetchpatch { url = "https://github.com/google/python-fire/commit/668007ae41391f5964870b4597e41493a936a11e.patch"; sha256 = "0rf7yzv9qx66zfmdggfz478z37fi4rwx4hlh3dk1065sx5rfksi0"; }) ]; </ins> meta = with stdenv.lib; { description = "A library for automatically generating command line interfaces";

Related discussion:
text: This might just be darwin; haven't tried on Linux. $ nix-shell -p these derivations will be built: /nix/store/dpcwgrlydrrlbdrnf0mi9hmr0kjvia89-python3.7-fire- building '/nix/store/dpcwgrlydrrlbdrnf0mi9hmr0kjvia89-python3.7-fire-'... unpacking sources unpacking source archive /nix/store/20rzw7yi3yvjb7w2ixzj6aqa5fim6p1q-source source root is source setting SOURCEDATEEPOCH to timestamp of file patching sources configuring building running bdistwheel The [wheel] section is deprecated. Use [bdistwheel] instead. running build running buildpy creating build creating build/lib creating build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire copying -build/lib/fire installing to running install running installlib creating creating creating copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - copying - running installegginfo running egginfo creating writing writing dependencylinks to writing requirements to writing top-level names to writing manifest file '' reading manifest file '' reading manifest template '' writing manifest file '' Copying to running installscripts creating creating 'dist/fire-0.1.3-py2.