jiebi/CodeConvo huggingface dataset:
Code change:
<del> { lib, stdenv, fetchurl, makeWrapper, jre, ncurses }: stdenv.mkDerivation rec { version = "3.1.0"; pname = "dotty-bare"; src = fetchurl { url = "https://github.com/lampepfl/dotty/releases/download/${version}/scala3-${version}.tar.gz"; sha256 = "9bsZ2FtIb6AvA3W3r2Vv0dPNicuYjMBz3X48z45Avv8="; }; propagatedBuildInputs = [ jre ncurses.dev ] ; nativeBuildInputs = [ makeWrapper ]; installPhase = '' mkdir -p $out mv * $out ''; fixupPhase = '' bin_files=$(find $out/bin -type f ! -name common) for f in $bin_files ; do wrapProgram $f --set JAVA_HOME ${jre} --prefix PATH : '${ncurses.dev}/bin' done ''; meta = with lib; { description = "Research platform for new language concepts and compiler technologies for Scala"; longDescription = '' Dotty is a platform to try out new language concepts and compiler technologies for Scala. The focus is mainly on simplification. We remove extraneous syntax (e.g. no XML literals), and try to boil down Scala’s types into a smaller set of more fundamental constructs. The theory behind these constructs is researched in DOT, a calculus for dependent object types. ''; homepage = "http://dotty.epfl.ch/"; license = licenses.bsd3; platforms = platforms.all; maintainers = [maintainers.karolchmist maintainers.virusdave]; }; } </del>

Related discussion:
text: Project description Scala 3 is more than a year old. It would be nice to have it packaged in nixpkgs as well. Maybe it is, but I couldn't find it under "scala-3" or respective versions. Metadata homepage URL: https://scala- source URL: license: Apache-2.0 License platforms: unix, linux, darwin, ...
is already packaged.
Indeed: the Scala 3 compiler started out under the codename 'dotty', and that's how it was packaged initially in nixpkgs. Now that dotty has become the 'official' scala 3 compiler (see also ), we should probably rename the package to as well? /cc
Feel free to update, rename and alias the old name :) Maybe should point at and can be
Code change:
sha256 = "3c0f73db9f8392f7048c8a244809f154d7c39f354e2167f6c477630aa517ed04"; }; <ins> propagatedBuildInputs = [ setuptools ]; </ins> patches = [ (fetchpatch { stripLen = 2;

Related discussion:
text: Describe the bug fails to run because setuptools is no longer propagated implictly. If were purely a python application built with then we would just need to add to propagatedBuildInputs and be done. However, is not simply a Python application, but a wrapper around , and isn't built using. The derivation patches the script as follows: This does result in the site-packages directories from all python packages ending up in , including setuptools (e.g. ). I'm not that familiar with Python packaging but from experimenting I found that the full path to the Python egg needs to be included (e.g. ) in order for this method to work. I made an attempt at resolving the issue but being new to Python packaging in Nix, neither are likely to be ideal: We could use buildPythonPackage in place of mkDerivation, using and use Or continue to use mkDerivation and manually set for patchPythonScript: I'm happy to submit a PR but I'm not sure what the recommended solution is here. To Reproduce Steps to reproduce the behavior: Expected behavior should launch with the extension loaded: Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
It seems is normally used by adding a to , or calling with (what the wrapper registered in does). This script then just does some addition calculations to register itself (we probably don't that at all) and some python 2 specific fixups, and then calls , which starts executing some code on import. I'd suggest to package it as a regular python application first (via ), so you can successfully import it inside a . The python tooling should automatically take care of patching the python shebang properly if you make script executable.
proposed fix
Code change:
}; nativeBuildInputs = [ makeWrapper unzip ]; <del> buildInputs = [ ant jre8 jdk8 gtk3 gsettings-desktop-schemas ]; </del> <ins> buildInputs = [ ant jdk gtk3 gsettings-desktop-schemas ]; </ins> postPatch = '' sed -i -e 's,../SweetHome3D,${applicationSrc},g' build.xml

Related discussion:
text: Wanted to install and start sweethomed.application. the build worked without problems but when i started it, it didnt started. Steps to reproduce the behavior: sweethome3d.application via configuration file to start it Starting the Application stucks at the start screen ! Add any other context about the problem here. At the moment its installed in my user context. When i try to start it as my user over the terminal i get no errors. When i start it with "sudo sweethome3d" I get the following error, and it also dont start, also start at starting screen and vanishing from the task bar: I think these happens because its not installed as user, but propably it helps to find the issue.
Starting random applications as root seems like an unwise idea.
Apologies, I misread the error, this appears to be a separate issue
Just to confirm, which GPU do you use?
I've got the same issue, and none of the solutions given in appear to work. On my side says my GPU is . EDIT: I should mention SH3D 7.02 works fine on my setup Mmh, I just tried with , and things work just fine (even though I'm on NixOS + tells me OpenGL is happy)...
Same problem here, on NIXOS unstable. Stuck on the starting blue window. Had to install it with flatpak in the mean time... Any idea?
sorry for delay i dont get informations from messages in last time from github... really annoying... I have an Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics]
Same here, also on Intel hardware.
Based on the NixGL idea, applying the following patch works to update to the latest version and fix the driver issue on Intel. But this does not seem like the best way to go about it; I can't find a single other package messing with , and it seems more like a debugging tool than something that should be in a package.
I forgot to mention, to avoid getting terrible performance (< 1 fps), I also had to set Not sure if it's needed for others. Maybe related to my using Wayland/Sway. I also have to use to get the window displayed properly, but that's a common issue for most Java apps and tiling windowing managers.
I also ran into this issue with a Nvidia card.
Code change:
}; nativeBuildInputs = [ makeWrapper unzip ]; <del> buildInputs = [ ant jre8 jdk8 gtk3 gsettings-desktop-schemas ]; </del> <ins> buildInputs = [ ant jdk gtk3 gsettings-desktop-schemas ]; </ins> postPatch = '' sed -i -e 's,../SweetHome3D,${applicationSrc},g' build.xml

Related discussion:
text: For me, was needed (with patch). I also needed . and didn't seem needed (or give noticable changes).
Code change:
- heterogeneous-list-literals - hetris - heukarya <del> - hevm </del> - HExcel - hexchat - hexif

Related discussion:
text: <!-- 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: <!-- 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: 1.7.3 desired version: 2.0.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.
waiting for 0.50.0 release of
I fixed echidna.
Lovely. Thanks you so much for you effort.
Code change:
aesop = callPackage ../applications/office/aesop { }; <ins> AusweisApp2 = libsForQt5.callPackage ../applications/misc/ausweisapp2 { }; </ins> avidemux = libsForQt5.callPackage ../applications/video/avidemux { }; avrdudess = callPackage ../applications/misc/avrdudess { };

Related discussion:
text: Project description Client for authenticating to services using a German ID Metadata homepage URL: source URL: license: EUPL platforms: unix, linux, darwin, win32
Code change:
url = "https://git.archlinux.org/svntogit/packages.git/plain/trunk/qtbug-77037-workaround.patch?h=packages/qt5-webengine&id=fc77d6b3d5ec74e421b58f199efceb2593cbf951"; sha256 = "1gv733qfdn9746nbqqxzyjx4ijjqkkb7zb71nxax49nna5bri3am"; }) <del> ] ++ optional stdenv.isDarwin ./qtwebengine-darwin-no-platform-check.patch; </del> <ins> ] ++ optionals stdenv.isDarwin [ ./qtwebengine-darwin-no-platform-check.patch ./qtwebengine-darwin-fix-failed-static-assertion.patch ]; </ins> qtwebkit = [ ./qtwebkit.patch ] ++ optionals stdenv.isDarwin [ ./qtwebkit-darwin-no-readline.patch

Related discussion:
text: The component of the derivation fails to compile on MacOS. But in two ways, and I can't tell what causes one or the other to trigger. On command: On command: the channel compilation failure Compiles.
It has been broken for a while now for different reasons. Maintaining it for darwin is a lot of work and nobody has stepped up to do that. Also, this is a duplicate of
By the way, what is your use case for ?
We're building a desktop version of mobile application and we need for our in-app browser with Ethereum support.
Code change:
url = "https://git.archlinux.org/svntogit/packages.git/plain/trunk/qtbug-77037-workaround.patch?h=packages/qt5-webengine&id=fc77d6b3d5ec74e421b58f199efceb2593cbf951"; sha256 = "1gv733qfdn9746nbqqxzyjx4ijjqkkb7zb71nxax49nna5bri3am"; }) <del> ] ++ optional stdenv.isDarwin ./qtwebengine-darwin-no-platform-check.patch; </del> <ins> ] ++ optionals stdenv.isDarwin [ ./qtwebengine-darwin-no-platform-check.patch ./qtwebengine-darwin-fix-failed-static-assertion.patch ]; </ins> qtwebkit = [ ./qtwebkit.patch ] ++ optionals stdenv.isDarwin [ ./qtwebkit-darwin-no-readline.patch

Related discussion:
text: Full log: Error message: That's the result I get from my macOS remote builder. When I run the build on my desktop Mac, it builds fine and uses the impure SDK from my Catalina install (10.15.1): However, the local build displays this warning repeatedly: I assume this is related to the macOS patches and hopefully gives some clue as to why it's broken.
qtbase builds fine on hydra: qtwebengine fails:
Those links point to the same thing. Anyway, strictly speaking I'm trying to build , but it's failing in .
Can you explain what do you mean? How are you using ?
It's a dependency of . edit: sorry, I see what you mean now. is a dependency of . I was confused by the message from the build saying that QT would be installed in .
Sure, depends on . Realistically, your best bet for now is to just use anki from an old version of nixpkgs. You see, doesn't have a darwin maintainer. I think, I was the last person to fix it around last January. The problem is that it's hard to keep up with all the updates. Every "minor" Qt version bump brings serious breaking changes for on darwin (like they might not even support our version of SDK anymore...). To make things worse we port all those bumps to the stable branch, so it quickly breaks there too.
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, many qt apps are broken on darwin due to this one.
Code change:
mask-rcnn = callPackage ../development/python-modules/mask-rcnn { }; <ins> mat2 = callPackage ../development/python-modules/mat2 { }; </ins> matchpy = callPackage ../development/python-modules/matchpy { }; mathlibtools = callPackage ../development/python-modules/mathlibtools { };

Related discussion:
text: Project description Metadata proposed package name: homepage source URL: license: platforms: probably portable to all platforms which Nix supports. requires python3, exiftool, gobject introspection
Code change:
+            .arg(dest_path) +            .output(); +    } <ins> +    else if is_lib { +        let _ = ::std::process::Command::new("@patchelf@/bin/patchelf") +            .arg("--set-rpath") +            .arg("@libPath@") +            .arg(dest_path) +            .output(); +    } </ins> +} + #[derive(Debug)]

Related discussion:
text: Describe the bug As of rust nightly 2020-06-22, Rust nightly cannot find This issue is not present in Rust nightly 2020-06-21. To Reproduce Steps to reproduce the behavior: Expected behavior rustc works Additional context This also happens with rust nightly from Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jade): nixpkgs: Maintainer information:
We are currently using in internally to set the elf interpreter. Looks like we need to extend this to also extend the RPATH to add zlib. If someone makes a PR, I will review it! Not sure when I would get to implement that myself.
Here is where we add :
I'm working on a patch for this. This is definitely the issue, just need to find the right way to extend the RPATH. I have something replacing it with a path containing zlib, but that overwrites the existing , which breaks it. I would like to verify what is setting there but hardcoding it should provide an early fix
Extending the RPATH seems not to have worked
I'm investigating patching the files in lib This issue may have been introduced by rust-lang/rust so it's likely the new zlib dependency shows up in the LLVM libraries
Code change:
#   registered in /etc/shells. The nix's bash is not in there when running #   cpu-x from nixpkgs. <del> stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation (finalAttrs: { </ins> pname = "cpu-x"; version = "5.0.4"; src = fetchFromGitHub { owner = "X0rg"; repo = "CPU-X"; <del> rev = "v${version}"; sha256 = "sha256-8jJP0gxH3B6qLrhKNa4P9ZfSjxaXTeBB1+UuadflLQo="; </del> <ins> rev = "refs/tags/v${finalAttrs.version}"; hash = "sha256-8jJP0gxH3B6qLrhKNa4P9ZfSjxaXTeBB1+UuadflLQo="; </ins> }; <del> nativeBuildInputs = [ cmake pkg-config wrapGAppsHook3 nasm makeWrapper ]; </del> <ins> nativeBuildInputs = [ cmake pkg-config wrapGAppsHook3 nasm ]; </ins> buildInputs = [ <del> gtk3 ncurses libcpuid pciutils procps vulkan-headers vulkan-loader glfw opencl-headers ocl-icd libXdmcp pcre util-linux libselinux libsepol libthai libdatrie libxkbcommon libepoxy dbus at-spi2-core </del> <ins> gtk3 gtkmm3 ncurses libcpuid pciutils procps vulkan-headers vulkan-loader glfw opencl-headers ocl-icd libXdmcp pcre util-linux libselinux libsepol libthai libdatrie libxkbcommon libepoxy dbus at-spi2-core </ins> libXtst ]; <del> postInstall = '' wrapProgram $out/bin/cpu-x  --prefix PATH : ${lib.makeBinPath [ stdenv.cc ]}  </del> <ins> preFixup = '' gappsWrapperArgs+=( --prefix PATH : ${lib.makeBinPath [ stdenv.cc ]} </ins> --prefix LD_LIBRARY_PATH : ${vulkan-loader}/lib <ins> ) </ins> ''; <del> meta = with lib; { </del> <ins> passthru = { tests = { version = testers.testVersion { package = finalAttrs.finalPackage; }; }; }; meta = { </ins> description = "Free software that gathers information on CPU, motherboard and more"; mainProgram = "cpu-x"; homepage = "https://thetumultuousunicornofdarkness.github.io/CPU-X"; <del> license = licenses.gpl3Plus; </del> <ins> license = lib.licenses.gpl3Plus; </ins> platforms = [ "x86_64-linux" ]; <del> maintainers = with maintainers; [ viraptor ]; </del> <ins> maintainers = with lib.maintainers; [ viraptor ]; </ins> }; <del> } </del> <ins> }) </ins>

Related discussion:
text: When trying to start the App from the launcher, nothing happens. In the terminal starts the text based version, but typing throws the following error =Source: Also check: And this is my system: !
Code change:
config = mkMerge [ (mkIf cfgC.enable { <del> systemd.services."synergy-client" = { after = [ "network.target" ]; </del> <ins> systemd.user.services."synergy-client" = { after = [ "network.target" "graphical-session.target" ]; </ins> description = "Synergy client"; <del> wantedBy = optional cfgC.autoStart "multi-user.target"; </del> <ins> wantedBy = optional cfgC.autoStart "graphical-session.target"; </ins> path = [ pkgs.synergy ]; serviceConfig.ExecStart = ''${pkgs.synergy}/bin/synergyc -f ${optionalString (cfgC.screenName != "") "-n ${cfgC.screenName}"} ${cfgC.serverAddress}''; serviceConfig.Restart = "on-failure"; }; }) (mkIf cfgS.enable { <del> systemd.services."synergy-server" = { after = [ "network.target" ]; </del> <ins> systemd.user.services."synergy-server" = { after = [ "network.target" "graphical-session.target" ]; </ins> description = "Synergy server"; <del> wantedBy = optional cfgS.autoStart "multi-user.target"; </del> <ins> wantedBy = optional cfgS.autoStart "graphical-session.target"; </ins> path = [ pkgs.synergy ]; serviceConfig.ExecStart = ''${pkgs.synergy}/bin/synergys -c ${cfgS.configFile} -f ${optionalString (cfgS.address != "") "-a ${cfgS.address}"} ${optionalString (cfgS.screenName != "") "-n ${cfgS.screenName}" }''; serviceConfig.Restart = "on-failure";

Related discussion:
text: Synergy crashes without an X Display available, but the autostart option attempts to start synergy regardless of whether login is graphical or TTY. It would probably make more sense to spawn this after
(triage) status?
In case this is still relevant - would it make sense for those to run as user services instead to take advantage of recent changes merged in
I think this is probably still relevant, and I think your suggestion is probably a good one, . With this config: out of the box, I get the following: But if I kill the service and start the synergyc command manually as my unprivileged desktop user, it works just fine:
Code change:
owner = "named-data"; repo = "ndn-cxx"; rev = "${pname}-${version}"; <del> sha256 = "1lcaqc79n3d9sip7knddblba17sz18b0w7nlxmj3fz3lb3z9qd51"; </del> <ins> sha256 = "sha256-oTSc/lh0fDdk7dQeDhYKX5+gFl2t2Xlu1KkNmw7DitE="; </ins> }; nativeBuildInputs = [ doxygen pkg-config python3 python3Packages.sphinx wafHook ]; <del> buildInputs = [ boost openssl sqlite ]; </del> <ins> buildInputs = [ boost175 openssl sqlite ]; </ins> wafConfigureFlags = [ "--with-openssl=${openssl.dev}" <del> "--boost-includes=${boost.dev}/include" "--boost-libs=${boost.out}/lib" </del> <ins> "--boost-includes=${boost175.dev}/include" "--boost-libs=${boost175.out}/lib" # "--with-tests" # disabled since upstream tests fail (Net/TestFaceUri/ParseDev Bug #3896) </ins> ]; <ins> doCheck = false; # disabled since upstream tests fail (Net/TestFaceUri/ParseDev Bug #3896) checkPhase = '' runHook preCheck LD_PRELOAD=build/ndn-cxx.so build/unit-tests runHook postCheck ''; </ins> meta = with lib; { homepage = "https://named-data.net/"; description = "A Named Data Neworking (NDN) or Content Centric Networking (CCN) abstraction";

Related discussion:
text: The default boost version has been bumped from 1.69 (or 1.75) to 1.77. This is a notice for maintainers that the following packages are now failing to build: - - - - - - - - - - [x] cryfs A typical fix would involve pinning the package to a specific version (e.g. see )
My fix in is not the same as . Is there a very good reason to prefer one over the other ?
Well, I like trying to keep it away from the huge top-level file. (which is e.g. harder to use in git)
Re. pivx, I think we should mark it broken. Our current version is very old (and therefore useless), and the new version includes a rust build. I don't have the capacity to fix this ATM.
In my case, what broke it was the update from boost175 to boost177. Fix is in .
It's in the branch now, so please target any further fixes there as well (unless they're a mass rebuild, etc.)
colobot fixed with
FYI, ledger has some broken behavior with the new boost version, although it curiously doesn't cause a test failure: ledger/ledger.
Our expression does not attempt to run tests.
Ah, that would be why, thanks. Nevertheless, the binary exhibits the same problem described in that issue in interactive use.
Code change:
</varlistentry> <varlistentry> <term> <del> GStreamer </del> <ins> GNOME platform </ins> </term> <listitem> <para> <del> Adds the GStreamer plugins subdirectory of each build input to the <envar>GST_PLUGIN_SYSTEM_PATH_1_0</envar> or <envar>GST_PLUGIN_SYSTEM_PATH</envar> environment variable. </del> <ins> Hooks related to GNOME platform and related libraries like GLib, GTK and GStreamer are described in <xref linkend="sec-language-gnome" />. </ins> </para> </listitem> </varlistentry>

Related discussion:
text: I just found out about wrapGAppsHook by examining a gnome package, but there really should be documentation about this in the Nixpkgs User Guide (a section about Gnome would be nice, which would show the right way to package GTK3 / GTK2 glib based apps). Also, perhaps there are other things I missed that one should know when packaging Gnome Applications or GTK3/2 apps? /cc Gnome maintainers
I'd like to know as well. Currently receiving this error: On one of the packages I'm trying to put into nixpkgs. Apparently sometimes you need for buildInputs. So apparently all you need to do to use this is:
The error occurs when you do not have any directory containing in variable. One of the things does is (which usually contains the aforementioned file) of dependencies to . (Actually this happens in cooperation with via variable.) Icon themes work in the same vein, only is used and it is populated by which is propagated to (). (XDG fallback theme) should be probably to any GTK application that uses icons (I think that is every GTK applicaton nowadays due to CSD) but some applications require Adwaita because they use icons not in hicolor. Not sure if this functions correctly though, at least it should not according to my mental model of how icon theme selection works; I will need to read the relevant XDG spec before I can finish the documentation.
Just thought I'd leave this comment here for future reference: if you get an error like for python gtk applications, try adding to propogatedBuildInputs!
It should go to , though. But be wary of
Code change:
stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

Related discussion:
text: , CVSSv3=9.8 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives. Cc Cc
See also: , ,
Code change:
stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

Related discussion:
text: , CVSSv3=9.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives. Cc Cc
See also: