jiebi/CodeConvo huggingface dataset:
Change:
<ins> --- a/src/ifcwrap/CMakeLists.txt +++ b/src/ifcwrap/CMakeLists.txt @@ -68,26 +68,17 @@ endif() # directory in which the wrapper can be installed. FIND_PACKAGE(PythonInterp) IF(PYTHONINTERP_FOUND AND NOT "${PYTHON_EXECUTABLE}" STREQUAL "") -    EXECUTE_PROCESS( -        COMMAND ${PYTHON_EXECUTABLE} -c "import sys; from distutils.sysconfig import get_python_lib; sys.stdout.write(get_python_lib(1))" -        OUTPUT_VARIABLE python_package_dir -    ) - -    IF("${python_package_dir}" STREQUAL "") -        MESSAGE(WARNING "Unable to locate Python site-package directory, unable to install the Python wrapper") -    ELSE() FILE(GLOB_RECURSE sourcefiles "${CMAKE_CURRENT_SOURCE_DIR}/../ifcopenshell-python/ifcopenshell/*.py") FOREACH(file ${sourcefiles}) FILE(RELATIVE_PATH relative "${CMAKE_CURRENT_SOURCE_DIR}/../ifcopenshell-python/ifcopenshell/" "${file}") GET_FILENAME_COMPONENT(dir "${relative}" DIRECTORY) INSTALL(FILES "${file}" -                    DESTINATION "${python_package_dir}/ifcopenshell/${dir}") +                    DESTINATION "@site_packages@/ifcopenshell/${dir}") ENDFOREACH() INSTALL(FILES "${CMAKE_BINARY_DIR}/ifcwrap/ifcopenshell_wrapper.py" -                DESTINATION "${python_package_dir}/ifcopenshell") +                DESTINATION "@site_packages@/ifcopenshell") INSTALL(TARGETS _ifcopenshell_wrapper -                DESTINATION "${python_package_dir}/ifcopenshell") -    ENDIF() +                DESTINATION "@site_packages@/ifcopenshell") ELSE() MESSAGE(WARNING "No Python interpreter found, unable to install the Python wrapper") ENDIF() </ins>

Discussion:
Project description Open source IFC library and geometry engine base c++ Metadata homepage URL: source URL: license: lgpl 3.0 platforms: linux
This package would be great to have
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 .
soft bump
Change:
patches = [ (substituteAll { src = ./0001-emulate-clang-sysroot-include-logic.patch; <del> resourceDir = "${llvmEnv}/lib/clang/18/"; </del> <ins> resourceDir = "${llvmEnv}/lib/clang/${lib.versions.major llvmPackages.llvm.version}/"; </ins> }) ];

Discussion:
Package name: emscripten Latest released version: 3.1.57 <!-- Search your package here: --- Current version on the unstable channel: 3.1.51 Current version on the stable/release channel: 3.1.47 <!-- 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]:
tl;dr: 3.1.57 is not currently compatible with the version of llvm in tree (18.1.5). The latest compatible version with llvm 18.1.5 appears to be Emscripten 3.1.54. The emscripten nixpkg (3.1.51) currently uses an LLVM17 environment which needs be migrated to LLVM18. The configuration as it exists today doesn't work in some cases. (Godot4.3dev6 web template builds failed missing in , prompting finding this issue) Emscripten 3.1.51 seems to be compatible with the LLVM 18.1.5 currently in nixpkgs unstable. Emscripten 3.1.59 (current as of this comment) and 3.1.57 are not compatible with that version of LLVM (In my usage, ran into errors with and ). These flags were introduced in Emscripten 3.1.55 making the last compatible version against the current in-tree dependencies 3.1.54. <details<summaryThis override was able to successfully build the godot4.3dev6 web templates using Emscripten 3.1.54</summary<p</p</details
Change:
outputs = [ "out" "doc" ]; <ins> patches = [ # Hardcode system installed banks & presets (fetchpatch { url = "https://patch-diff.githubusercontent.com/raw/zynaddsubfx/zynaddsubfx/pull/295.patch"; hash = "sha256-UN62i9/JBs7uWTmHDKk3lkAxUXsVmIs6+6avOcL1NBg="; }) ]; </ins> postPatch = '' patchShebangs rtosc/test/test-port-checker.rb src/Tests/check-ports.rb <del> substituteInPlace src/Misc/Config.cpp --replace /usr $out </del> ''; nativeBuildInputs = [ cmake makeWrapper pkg-config ];

Discussion:
I upgraded Zynaddsubfx (latest unstable), and was surprised to discover the new amazing interface (whooa)... and that I had no more loaded instrument (empty bank). I solved that problem by removing the user zynaddsubfx configuration and bank cache (I think the problem is the bank cache): and indeed, once you reload zynaddsubfx, you can see that the instruments are back. Also, a new file is created, and the bank path is hardcoded, like: I guess that in other distributions this path does not change when zynaddsubfx is updated, but with nix the bank path changes on upgrade, so the user needs to manually clear the cache on each upgrade. I'm not sure what's the best way to solve this problem. I was thinking that the best solution may be to add a small wrapper around zynaddsubfx which clears the cache if it detects in a path to another nix executable. The other possibility may be to use instead of the one, but it won't work outside of NixOs. If these options are not working, at least it would be nice to document that bank cache should be cleared on upgrades. Steps to reproduce the behavior: zynaddsubfx and potentially garbage collect the old version zynaddsubfx: instruments may disapear
Yeah it's really nice :blush: It was a lot of work to get it built. I'm not sure if any other distro even uses the new Zyn-Fusion interface, because it's not the default UI when building from source. I also noticed this problem before between upgrading & running . I tried working on a patch to avoid dumping the default paths into the config, but I never finished it. I'll try looking into it again!
I marked this as stale due to inactivity. &rarr;
still relevant, just haven't gotten around to fixing it
I think this issue should not be closed as for now it is based on a non-accepted PR , so I'll re-open waiting for the changes to be merged upstream.
Change:
<del> { lib, stdenv, substituteAll, fetchpatch, fetchFromGitHub, glib, glib-networking, libgtop, gnome3 }: </del> <ins> { lib, stdenv, substituteAll, fetchFromGitHub, glib, glib-networking, libgtop, gnome3 }: </ins> stdenv.mkDerivation rec { pname = "gnome-shell-system-monitor"; <del> version = "2020-04-27-unstable"; </del> <ins> version = "unstable-2021-04-08"; </ins> src = fetchFromGitHub { owner = "paradoxxxzero"; repo = "gnome-shell-system-monitor-applet"; <del> rev = "7f8f0a7b255473941f14d1dcaa35ebf39d3bccd0"; sha256 = "tUUvBY0UEUE+T79zVZEAICpKoriFZuuZzi9ArdHdXks="; </del> <ins> rev = "942603da39de12f50b1f86efbde92d7526d1290e"; sha256 = "0lzb7064bigw2xsqkzr8qfhp9wfmxyi3823j2782v99jpcz423aw"; </ins> }; buildInputs = [

Discussion:
Describe the bug The system-monitor GNOME Shell extension does not display the correct icon. ! To Reproduce Steps to reproduce the behavior: the extension the "Show icon" box in the extension's settings. Expected behavior The following icon should be shown: ! 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
If I recall correctly, that is an upstream bug. Edit:
Change:
> "$subdirs" # Byte-compiling improves start-up time only slightly, but costs nothing. <del> $emacs/bin/emacs --batch -f batch-byte-compile "$siteStart" "$subdirs" "$siteAutoloads" </del> <ins> $emacs/bin/emacs --batch -f batch-byte-compile "$siteStart" "$subdirs" </ins> ${optionalString nativeComp '' $emacs/bin/emacs --batch  --eval "(add-to-list 'native-comp-eln-load-path "$out/share/emacs/native-lisp/")"  <del> -f batch-native-compile "$siteStart" "$subdirs" "$siteAutoloads" </del> <ins> -f batch-native-compile "$siteStart" "$subdirs" </ins> ''} '';

Discussion:
The file generated by the Emacs wrapper is redundant because the autoload definitions are already processed by the builtin : the is loaded after with the command line option , but loads the package autoloads before . We can understand this better by considering a few scenarios. If we start Emacs with disabled, then the autoloads will not be available in because is not loaded until later: If we modify the wrapper as in so that is not loaded, the autoloads will still be found as long as is enabled: is enough on its own to handle autoloads for the Emacs wrapper. Therefore, I propose to remove in favor of the builtin Emacs functionality.
Somehow, removing this broke from emacs-overlay. I have to manually run or anything depending on autoloaded tramp functions errors out with "no such function". I do disable as my site-lisp directory is managed by Nix. Is this configuration no longer recommended/supported? Is there a way to just engage 's autoload mechanism without allowing it to access the network or install packages?
I also fully disable since all of my emacs packages are installed via nix and noticed this change broke things for me. I'm interested in this as well. Edit: Maybe this:
Change:
let mostOfVersion = builtins.concatStringsSep "." (lib.take 3 (lib.versions.splitVersion version)); <ins> platform = "${stdenv.hostPlatform.parsed.kernel.name}-${stdenv.hostPlatform.parsed.cpu.name}"; </ins> in stdenv.mkDerivation {

Discussion:
From what I could tell this was only mentioned in some comment of a closed PR. This is blocking me from wrapping up a flake for Invoke AI (a Stable Diffusion webui). Any help/advice would be appreciated. This was described on Discourse by :
What commit of nixpkgs are you using? I might have some cycles this weekend to spend on this.
Looks like the cause is an outdated version of cutensor. It appears cupy is the only dependent of that so hopefully an upgrade is simple. I am working on a patch now.
Change:
cmakeFlags = [ "-DEMBREE_TUTORIALS=OFF" "-DEMBREE_RAY_MASK=ON" <ins> "-DTBB_ROOT=${tbb}" "-DTBB_INCLUDE_DIR=${tbb.dev}/include" </ins> ];

Discussion:
Steps to reproduce the behavior: Breaks since it depends on <!-- 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.
Possibly running an outdated version of TBB. Current release is 2021.7.0, the version in unstable is 2020.3. Of course, this could be on purpose.
This is very likely fallout from (more precisely, commit ). See also (broken in a similar fashion) See the following Hydra failures: embree: openimagedenoise: FYI
Change:
<del> { stdenv, lib, buildGoModule, fetchFromGitHub }: </del> <ins> { stdenv, lib, buildGoModule, fetchFromGitHub, installShellFiles }: </ins> buildGoModule rec { pname = "hubble"; <del> version = "0.9.0"; </del> <ins> version = "0.10.0"; </ins> src = fetchFromGitHub { owner = "cilium";

Discussion:
Steps to reproduce the behavior: hubble Maybe related to and I've tried to build with Go 1.18 inside nix expression and get the same error, a nix-shell with cmake and go118 can build it OK. <!-- 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.
Change:
# Somehow this does not get set automatically cmakeFlags = [ "-DSDL2MAIN_LIBRARY=${SDL2}/lib/libSDL2.so" ]; <ins> postInstall = '' install -Dm644 $src/resources/milkytracker.desktop $out/share/applications/milkytracker.desktop install -Dm644 $src/resources/pictures/carton.png $out/share/pixmaps/milkytracker.png install -Dm644 $src/resources/milkytracker.appdata $out/share/appdata/milkytracker.appdata.xml ''; </ins> meta = with stdenv.lib; { description = "Music tracker application, similar to Fasttracker II"; homepage = "http://milkytracker.org";

Discussion:
Describe the bug Milkytracker is missing a menu entry to launch the application Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Change:
<ins> diff --git a/Cargo.lock b/Cargo.lock index 3c728f348..51df0ea7b 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -5098,9 +5098,9 @@ dependencies = [ [[package]] name = "time" -version = "0.3.34" +version = "0.3.36" source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "c8248b6521bb14bc45b4067159b9b6ad792e2d6d754d6c41fb50e29fefe38749" +checksum = "5dfd88e563464686c916c7e46e623e520ddc6d79fa6641390f2e3fa86e83e885" dependencies = [ "deranged", "itoa", @@ -5121,9 +5121,9 @@ checksum = "ef927ca75afb808a4d64dd374f00a2adf8d0fcff8e7b184af886c3c87ec4a3f3" [[package]] name = "time-macros" -version = "0.2.17" +version = "0.2.18" source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "7ba3a3ef41e6672a2f0f001392bb5dcd3ff0a9992d618ca761a11c3121547774" +checksum = "3f252a68540fde3a3877aeea552b832b40ab9a69e318efd078774a01ddee1ccf" dependencies = [ "num-conv", "time-core", </ins>

Discussion:
Steps to reproduce the behavior: X 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
see
Change:
}; in clangStdenv.mkDerivation rec { name    = "fcitx-mozc-${version}"; <del> version = "2.20.2673.102"; </del> <ins> version = "2.23.2815.102"; </ins> src = fetchFromGitHub { owner  = "google"; repo   = "mozc"; <del> rev    = "280e38fe3d9db4df52f0713acf2ca65898cd697a"; sha256 = "0s599f817gjgqynm4n1yll1ipd25ai2c55y8k6wvhg9s7qaxnyhs"; </del> <ins> rev    = "afb03ddfe72dde4cf2409863a3bfea160f7a66d8"; sha256 = "0w2dy2j9x5nc7x3g95j17r3m60vbfyn5j617h7js9xryv33yzpgx"; </ins> }; nativeBuildInputs = [ gyp which ninja python pkgconfig ];

Discussion:
Describe the bug I was trying to upgrade my system to latest unstable when I encountered this error: error: --- Error
--------------------- nix-build builder for '/nix/store/4akxpw50h059071m68rm96qi3jmdv7zi-ibus-mozc-' failed with exit code 1; last 10 log lines: File "", line 854, in BuildMain BuildWithNinja(options, targets) File "", line 828, in BuildWithNinja RunOrDie([ninja, '-C', buildarg] + ninjatargets) File "", line 99, in RunOrDie '=========='])) ERROR: ninja -C outlinux/Release ibusmozc mozcemacshelper mozcserver mozctool mozc_renderer
cc: because of .
likewsie fcitx-mozc stopped working. Seems like there is this fork of google-mozc with more recent commits but changing upstream would require more changes:
Change:
opentimestamps-client = python3Packages.callPackage ../tools/misc/opentimestamps-client {}; <del> opentoonz = (qt514.overrideScope' (_: _: { libtiff = callPackage ../applications/graphics/opentoonz/libtiff.nix { }; })).callPackage ../applications/graphics/opentoonz { }; </del> <ins> opentoonz = let opentoonz-libtiff = callPackage ../applications/graphics/opentoonz/libtiff.nix { }; in qt5.callPackage ../applications/graphics/opentoonz { libtiff = opentoonz-libtiff; opencv = opencv.override { libtiff = opentoonz-libtiff; }; }; </ins> opentabletdriver = callPackage ../tools/X11/opentabletdriver { };

Discussion:
Thought I'd try out Opentoonz because it looks cool, however I can't get the derivation for libtiff-4.0.3-opentoonz (patched version of libtiff for opentoonz) to build. Steps to reproduce the behavior: on NixOS 21.05 -4.0.3-opentoonz derivation fails to build to successfully evaluate and drop me to a shell prompt from whence I can run and try out Opentoonz. This is the relevant output from :
the build of opentoonz is also failing on master but for a different reason
Change:
echo 'abort "Illegal use of <nixpkgs> in Nixpkgs."' > $TMPDIR/barf.nix # Make sure that Nixpkgs does not use <nixpkgs>. <del> badFiles=$(find $src/pkgs -type f -name '*.nix' -print | xargs grep -l '^[^#]*<nixpkgs/' || true) </del> <ins> badFiles=$(find $src/pkgs -type f -name '*.nix' -print | xargs grep -l '^[^#]*<nixpkgs/' || true) </ins> if [[ -n $badFiles ]]; then echo "Nixpkgs is not allowed to use <nixpkgs> to refer to itself." echo "The offending files: $badFiles"

Discussion:
This blocks all three unstable channels. For log see e.g. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
&& (allowsLogin cfg.hashedPassword || cfg.password != null <del> || cfg.passwordFile != null </del> <ins> || cfg.hashedPasswordFile != null </ins> || cfg.openssh.authorizedKeys.keys != [] || cfg.openssh.authorizedKeys.keyFiles != []) ) cfg.users ++ [

Discussion:
Password hashes, while less sensitive than unhashed passwords, are secrets. We should therefore have a option in that avoids both placing the hashes in the store world-readable and storing the password unhashed.
This is a common misunderstanding due to the bad naming of these options: → string of plaintext password → string of password hash → file containing password hash So, what you want already exists and it's .
Oh wow, indeed. Thanks! Given that the option is named so confusingly and that its description starts with "The full path to a file that contains the user's password." I think we should keep the issue, pending an option rename and a documentation improvement.
Change:
runScript = writeShellScript "wechat-uos-launcher" '' export QT_QPA_PLATFORM=xcb export LD_LIBRARY_PATH=${lib.makeLibraryPath wechat-uos-runtime} <ins> if [[ ''${XMODIFIERS} =~ fcitx ]]; then export QT_IM_MODULE=fcitx export GTK_IM_MODULE=fcitx elif [[ ''${XMODIFIERS} =~ ibus ]]; then export QT_IM_MODULE=ibus export GTK_IM_MODULE=ibus export IBUS_USE_PORTAL=1 fi </ins> ${wechat.outPath}/opt/apps/com.tencent.wechat/files/wechat ''; extraInstallCommands = ''

Discussion:
This is a bug tracker for im issue on Please report further issues here. DO NOT report on merged / closed pull request. For anyone who is interested in trouble shooting, you may also want to check out , which may helps to fix this issue. Known problematic DE: [ ] Hyperland / Wayland Steps to reproduce the behavior: input using fcitx5 / ibus / ... IM should be working on . <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
can you verify whether fixes IM issue for you? Please kindly provide your feedback on as original pr is closed and should not being used to discuss anymore
Nope. Steps I ran: the previously installed wechat-uos the new build file in your commit into command command Hyprland shortcut key to launch -wechat-uos -not work command -can work
If can be running properly by , then I guess it may probably be related to , which means does not properly provide environment variables to my wrapper. I will try to investigate whether there is anything I could do. In the meantime, you may try to use the workaround provided in that issue (Not recommended by devs, through) and see whether it works for you.
Thanks! However, I cannot make it work when I use a Hyprland shortcut key to execute the command , nor the command works inside a terminal environment. I find it is related to Home Manager's environment variable settings. According to , home manager's is only for interactive shells, which is not clear on the Home Manager's manual / differs from the behavior of (will be merged into environment variables). After I set the environment variable to in Hyprland's configuration, the holy pitfall was solved. This is my solution: ,62-79,211-214
One thing to mention, QT application may have display issue in Wayland or only in Hyrpland (m version is v0.37.1) when scale of the monitor is not 1 or other integer numbers. Specially, wechat-uos have illegible non-antialiasing texts when my monitor scale is 1.25
Change:
"-DARROW_BUILD_TESTS=ON" "-DARROW_VERBOSE_THIRDPARTY_BUILD=ON" "-DARROW_DEPENDENCY_SOURCE=SYSTEM" <ins> "-DThrift_SOURCE=AUTO" # search for Thrift using pkg-config (ThriftConfig.cmake requires OpenSSL and libevent) </ins> "-DARROW_DEPENDENCY_USE_SHARED=${if enableShared then "ON" else "OFF"}" "-DARROW_COMPUTE=ON" "-DARROW_CSV=ON"

Discussion:
It seems that all of a sudden a few dependencies are missing to . As a start, I found the need to add . The problem is with which also makes the impression it's needed: But our build of doesn't provide cmake files. Building with cmake instead of autoconf might help, but they don't use the cmake module there which makes the transition harder. cc (maintainers) and .
The new requirements come from thrift since
I have an idea of how to fix this. Will put a PR up shortly
Change:
# We look for plugins in `/run/current-system/sw/lib/` because # there are multiple plugin providers (e.g. gala and wingpanel). ./plugins-dir.patch <ins> # WindowManager: save/restore easing on workspace switch # https://github.com/elementary/gala/pull/1430 (fetchpatch { url = "https://github.com/elementary/gala/commit/1f94db16c627f73af5dc69714611815e4691b5e8.patch"; sha256 = "sha256-PLNbAXyOG0TMn1y2QIBnL6BOQVqBA+DBgPOVJo4nDr8="; }) </ins> ]; nativeBuildInputs = [

Discussion:
After updating to 21.11, the animation for directly switching between workspaces looks really bad. (I hope this isn't normal behaviour with Pantheon 6?) Steps to reproduce the behavior: NixOS 21.05 w/ Pantheon workspace switching NixOS 21.11 w/ Pantheon workspace switching Smooth workspace switching like on 21.05. Before: After: Add any other context about the problem here. Please run and paste the result. Maintainer information:
I can reproduce this on NixOS 21.11: you mean the grey space between the workspaces, right? ! can you reproduce this too? I think the best way forward would be an upstream issue, since we can't do much about this (i think).
Sorry for not being more specific, I was in a hurry to get some assignments done until midnight. I meant the way the workspace doesn't finish smoothly sliding in, instead opting to jump into place once it reaches the last sixth of the screen. This jumpiness is also present in your recording. But maybe this grey space is caused by the same underlying problem, I don't know. This looks very distracting coming from 21.05 where it was fully smooth. And it looks even more wrong because going to the workspace overview first (<kbdSuper</kbd+ <kbd↓</kbd) and then switching workspaces shows a completely smooth animation as expected. That's why I reported it here, because I assumed they wouldn't have shipped that in their own distro considering all the other animations are smooth.
Yes, that's quiet a difference.
FYI there is , not sure if that is the problem described here. When doing Pantheon 7 upgrade, I guess I will be more careful when choosing mutter versions and just use what elementary is using :-(
I doubt they will fix it anytime soon. Focal might be stuck with mutter3.36.
36.4 should be pretty same story as this so just replacing it would fix it gonna give it try