jiebi/CodeConvo huggingface dataset:
Change:
patches = [ ./compiler-rt-codesign.patch # Revert compiler-rt commit that makes codesign mandatory <del> ] ++ stdenv.lib.optional stdenv.hostPlatform.isMusl ./sanitizers-nongnu.patch; </del> <ins> ] ++ stdenv.lib.optional stdenv.hostPlatform.isMusl ./sanitizers-nongnu.patch ++ stdenv.lib.optional stdenv.hostPlatform.isAarch32 ./compiler-rt-armv7l.patch; </ins> # TSAN requires XPC on Darwin, which we have no public/free source files for. We can depend on the Apple frameworks # to get it, but they're unfree. Since LLVM is rather central to the stdenv, we patch out TSAN support so that Hydra

Discussion:
Describe the bug A clear and concise description of what the bug is. Same issue as or , but on armv7l Additional context Add any other context about the problem here. On hydra, the clang build first started failing with this error after going from to . I diffed the range and found to be the most likely culprit. It enabled some cmakeFlags globally which used to only be enabled on darwin and useLLVM systems. I don't know what exactly these do but, I was able to build on my rpi2 by disabling them on aarch32: Since I have no idea why this works and what would be affected, I'd rather have someone look over this. 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 Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
we probably need to add armv7l here:
I tried but it fails with this error now: I guess it can't find a default target for armv7l somehow? Not really familiar with cmake unfortunately
I made some progress, it seems to be taking the target arch from the triplet given to , even if you override the target arch with a flag. Printf debugging showed me that it does this halfway through the configure phase, it's armhf in the beginning if I set the flag. Setting the compiler target to instead of makes it find its target and compile successfully. Does have any importance outside the build process?
I don't think it does. It's possible it sets in compiler calls, but that is considered equivalent to .
Change:
"-DBRLCAD_ENABLE_STRICT=OFF" ]; <ins> env.NIX_CFLAGS_COMPILE = toString [ # Needed with GCC 12 "-Wno-error=array-bounds" ]; </ins> meta = with lib; { homepage = "https://brlcad.org"; description = "BRL-CAD is a powerful cross-platform open source combinatorial solid modeling system"; <ins> changelog = "https://github.com/BRL-CAD/brlcad/releases/tag/${src.rev}"; </ins> license = with licenses; [ lgpl21 bsd2 ]; maintainers = with maintainers; [ GaetanLepage ]; platforms = platforms.linux; <ins> # error Exactly one of ON_LITTLE_ENDIAN or ON_BIG_ENDIAN should be defined. broken = stdenv.system == "aarch64-linux"; </ins> }; }

Discussion:
Package name: brlcad Latest released version: 7.38.0 Current version on the unstable channel: 7.34.2 Current version on the stable/release channel: 7.34.2 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<ins> diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt index e7befae..e7dc255 100644 --- a/src/CMakeLists.txt +++ b/src/CMakeLists.txt @@ -86,7 +86,6 @@ if (UNIX) ) endif () if (APPLE) -    if (DMG) set_target_properties(${EXECUTABLE_NAME} PROPERTIES MACOSX_BUNDLE ON MACOSX_BUNDLE_EXECUTABLE_NAME "${EXECUTABLE_NAME}" @@ -94,21 +93,12 @@ if (UNIX) MACOSX_BUNDLE_ICON_FILE "${EXECUTABLE_NAME}.icns" MACOSX_BUNDLE_GUI_IDENTIFIER "${RDNS_NAME}" MACOSX_BUNDLE_LONG_VERSION_STRING "${PROJECT_VERSION}" -                            MACOSX_BUNDLE_BUNDLE_NAME "${PROJECT_NAME}" +                            MACOSX_BUNDLE_BUNDLE_NAME "Easy Audio Sync" MACOSX_BUNDLE_SHORT_VERSION_STRING "${PROJECT_VERSION}" MACOSX_BUNDLE_BUNDLE_VERSION "${PROJECT_VERSION}" MACOSX_BUNDLE_COPYRIGHT "Public Domain" ) -      install(CODE "include(BundleUtilities)nfixup_bundle("${PROJECT_BINARY_DIR}/${EXECUTABLE_NAME}.app" "" "")") -      add_custom_target(my_install COMMAND ${CMAKE_COMMAND} --build . --target install WORKING_DIRECTORY "${PROJECT_BINARY_DIR}") -      add_custom_target(dmg -        COMMAND mv "${EXECUTABLE_NAME}.app" "${PROJECT_NAME}.app" # fixup_bundle won't accept app names with spaces so need to manually rename -        COMMAND "${MACDEPLOYQT}" "${PROJECT_NAME}.app" -dmg -        COMMAND mv "${PROJECT_NAME}.dmg" "${EXECUTABLE_NAME}-${PROJECT_VERSION}-${CMAKE_OSX_ARCHITECTURES}.dmg" -        WORKING_DIRECTORY "${PROJECT_BINARY_DIR}") -      add_dependencies(dmg my_install) -    endif () else () install(TARGETS ${EXECUTABLE_NAME} DESTINATION "${CMAKE_INSTALL_PREFIX}/bin") set (DATA_DIR "${CMAKE_INSTALL_PREFIX}/share") </ins>

Discussion:
Project description From the project GitHub: Easy Audio Sync is an audio library syncing and conversion utility. The intended use is syncing an audio library with many lossless files to a mobile device with limited storage. The program's design is inspired by the utility. It supports folder-based source to destination syncing, with audio transcoding capability, and is GUI-based instead of CLI-based. Metadata homepage URL: source URL: license: Public Domain (Unlicense) platforms: Linux, Windows, and macOS Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
else let gem = gems.${pname}; <del> version = gem.version; </del> <ins> suffix = gem.suffix; </ins> in <del> "${pname}-${version}"; </del> <ins> "${pname}-${suffix}"; </ins> pname' = if pname != null then pname

Discussion:
Describe the bug fails to build when the gem configured in the is pointing to a git repository. <details<summaryGemfile</summary</details<details</summary</details<details</summary</details<details<summarynix-build output</summary</detailsTo Reproduce Run with the configuration posted above. Expected behavior The package should build like it does when the gem is pointed to a released version. Metadata Maintainer information:
Can confirm this, I have the same issue trying to package
I ran into this issue today. Both in my scenario and the recipe above the issue happens bundlerApp tries to of the gem. The directory find is call with doesn't exist. While I don't know the proper way to fix bundlerApp, a work around is to set the installManpages attributes to false. ej.
I'm having issue as well, is there any temporal fix atleast? Its annoying, and making my setup not-so-reproducible, I'm bundling puppet and it says: Its actually been created with rev: at and haven't been copied over.
Seems like you're right not installing manpages did somehow fix it, but not sure how you figured out... What I find post trying that is that the problem resides exactly in these lines:
I figured out the workaround by reading the error from nix log . Seeing the call to find being the error and looking for the expression responsible for making the call. Found it was the the installManpages option as you linked above. However I'm not familiar enough with the process to know what is the proper way to fix this. It seems the reason it fails is because in only has the dependencies of the gem we are building, not the gem itself. Should the man page installation happen in a latter phase? Should it look for the gem man pages in a different place? In what phase it is running?
I started a PR for the fix, can you please try building packages from this PR branch?
Change:
}; }; in <del> mapAttrs (exporter: testConfig: (makeTest { </del> <ins> mapAttrs (exporter: testConfig: (makeTest (let nodeName = testConfig.nodeName or exporter; in { </ins> name = "prometheus-${exporter}-exporter"; <del> nodes.${exporter} = mkMerge [{ </del> <ins> nodes.${nodeName} = mkMerge [{ </ins> services.prometheus.exporters.${exporter} = testConfig.exporterConfig; } testConfig.metricProvider or {}]; testScript = '' <del> ${exporter}.start() </del> <ins> ${nodeName}.start() </ins> ${concatStringsSep "n" (map (line: if (builtins.substring 0 1 line == " " || builtins.substring 0 1 line == ")") then line <del> else "${exporter}.${line}" </del> <ins> else "${nodeName}.${line}" </ins> ) (splitString "n" (removeSuffix "n" testConfig.exporterTest)))} <del> ${exporter}.shutdown() </del> <ins> ${nodeName}.shutdown() </ins> ''; meta = with maintainers; { <del> maintainers = [ willibutz ]; </del> <ins> maintainers = [ willibutz elseym ]; </ins> }; <del> })) exporterTests </del> <ins> }))) exporterTests </ins>

Discussion:
Project description Collect ALL UniFi Controller, Site, Device & Client Data Nixpkg currently has which is not developed anymore. Corresponding NixOS module may have to be updated. Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin
Change:
{ stdenv, python, buildPythonPackage <del> , protobuf, google_apputils, pyext </del> <ins> , protobuf, google_apputils, pyext, libcxx </ins> , disabled, doCheck ? true }: with stdenv.lib;

Discussion:
Building the python 3 protobuf package fails for me on macOS. Digging in (by launching ), the cause seems to be that calls instead of . The call above fails, but the same call works after replacing by . Similarly, works fine. That in turn matters because of in the / wrappers, because the system include path is missing in the case. System: mac OS 10.12.5 Nix version: nix-env (Nix) 1.11.8 Nixpkgs version: "17.09pre108299." Sandboxing enabled: grep: No such file or directory :) When digging in, I used a checkout of nixpkgs with hash , but it seems to make no difference.
seems related.
uses Python on Darwin and might help here.
I've had a look at the python setup tools: The relevant line is (rather: appears to be, I haven't tested this) which causes C++ source files to be compile with . Not sure whether this is the right or wrong thing to do... I see two reasonable ways to fix this bug, in a more principled way than : python distutils to compile C++ files using nixpkg to treat like with respect to and friends If 1. is the right thing to do, it might still be nice to work around the bug in another way for now.
I've also been bitten by this problem once: The core problem is that setuptools pretty much ignores the difference between CC and CXX. This however is not a problem on a standard mac xcode installation, as both and link the C++ standard library there. However our nix-clang does not link against the C++ standard library (and probably should not) and that's why you will encounter this problem every once in a while when dealing with darwin and c++ python extensions. I'm not an expert on the darwin-stdenv, so I wouldn't know how to fix this in a way that does not require hacking our ways around that problem. To hack around this problem you simply have to grep the pythonPackages for . There are a few packages that use a workaround that involves adding to the C-compile flags: See e.g.

here:
However our nix-clang does not link against the C++ standard library (and probably should not) and that's why you will encounter this problem every once in a while when dealing with darwin and c++ python extensions. any clue how to solve this issue?
The problem does not seem all-too widespread, but there are a few instances:
Any reason we can't just change to use ? Seems like it would work on Linux just fine, and fix a bunch of other stuff.
I knew this was an issue in general (), but assumed the problem was something more complicated.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
n8n = callPackage ../applications/networking/n8n { }; <del> neomutt = callPackage ../applications/networking/mailreaders/neomutt { }; </del> <ins> neomutt = darwin.apple_sdk_11_0.callPackage ../applications/networking/mailreaders/neomutt { }; </ins> neosay = callPackage ../applications/networking/instant-messengers/neosay { };

Discussion:
Steps to reproduce the behavior: neomutt, I tested using because I didn't know how to do overrides from the CLI The fix on only fixed , it was that it could be fixed by adding into . I just tested this and it's still broken <!-- 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:
homepage = "https://github.com/google/flax"; license = licenses.asl20; maintainers = with maintainers; [ ndl ]; <del> # Py3.10 requires orbax, tensorstore which needs packaging # Py3.11 requires tensorboard, which is unsupported at py3.11 atm broken = true; # At 2023-02-05 </del> }; }

Discussion:
your commit broke due to Please test your changes with or at least before committing them to master. Can you please issue a fix by reverting your change and downgrading to 0.6.2? There is not currently a fix available upstream.
That commit is from the regular Python batch updates. While we try to fix as many build failures as possible we can't guarantee every package continues to work. I suggest you file a PR reverting that change.
I understand that python-updates is a messy process. But in the case that you do not know or do not test whether a package update will build successfully, please do not update it. There is no need to upgrade flax, and the risks of pushing untested code to master are simply much higher than the reward.
I think it would be a good idea to maintain a list of packages that shouldn't be updated in python-updates. Let's discuss that over at .
I think that's a great idea! will switch over to matrix
Change:
libpthreadstubs lapack blas <ins> python3 </ins> ] ++ lists.optionals cudaSupport (with cudaPackages; [ cuda_cudart.dev # cuda_runtime.h cuda_cudart.lib # cudart

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . python3Packages.torchvision maintainers cc: magma maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags:
This is also breaking atm
This shows that fortran name mangling is using the underscore ``. (See ) Magma should have the flag "-DADD" set during compilation to fix this
And, in fact, clmagma already sets :
Both of the following overlays fixed the problem: Specify the fortran name mangling convention To explain this, in , we see that if USEFORTRAN=off then the FORTRANCONVENTIONS flag is set and also copied to CFLAGS and CXXFLAGS. FORTRANCONVENTIONS is copied outside of this block into the NVCCFLAGS, and DEVCCFLAGS (which can't otherwise be set), so all three flags are necessary if we use the default of USE_FORTRAN=on. Disable fortran in magma
Nice! Would you be interested in turning that into a PR? It'd be great to fix on master!
Change:
export XDG_DATA_DIRS=$XDG_ICON_DIRS:$GSETTINGS_SCHEMAS_PATH''${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS <ins> # Mainly for xdg-open but also other xdg-* tools: export PATH="${xdg_utils}/bin''${PATH:+:}$PATH" </ins> . w EOF

Discussion:
Describe the bug Opening magnet links in Chromium fails and so does opening links in Discord when I'm using Sway. To Reproduce Steps to reproduce the behavior: to piratebay. using a magnet link. Discord. a link. Expected behavior When I use a magnet link to download torrent I expect it to open my torrent client (qbittorrent). In Discord clicking on links should open in Chromium. Screenshots Clicking on the open button doesn't do the thing. Additional context I only tried in Sway among the wayland compositors. X11 is fine. I haven't tried in Gnome wayland. The same might be the case with other electron apps. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Give advice if you know whom I should xdg_utils: Chromium: Discord: Metadata Maintainer information:
Have you tried configuring xdg using ?
Another possible option is that something like isn't set correctly within the sway context, so it doesn't find the correct settings
could you give (doesn't require rebuilding Chromium, only the wrapper) a test without xdg_utils installed globally?
I'm not sure how to do it, although is true by default, xdg tools are not available on PATH when I use sway unlike on for say bspwm.
Setting didn't help.
I'm currently rebuilding Chromium with , how do I avoid the full rebuild?
you can only avoid it if hydra populated the binary cache for you. You most likely CANT avoid it in this situation.
that's gonna take like 6 hours
I haven't had an issue with x11, so i changed your title
Just finished compiling, idd it works. On the other hand is it really a good solution?
FWIW, I use sway and have part of my user's packages and never had any issues with this, magnet links, mailto etc. links work just fine in Firefox, Chromium and everywhere else.
Next time you can try to e.g. cherry-pick the commit onto a channel like nixos-unstable. Should've mentioned that, sorry. In that case my branch was based on master the branch and the build on Hydra was still pending. I don't really see a problem with it.

It is a bit strange/hacky but Chromium depends on these binaries and in such cases we usually prefix accordingly (see for other Nixpkgs examples, usually via ).
All the discussion here seems to be about chromium, was there a fix for discord? I am having the same problem
You can e.g. "fix" it by installing .

Describe the bug "Set browser as default" functionality doesn't work for Firefox and Chromium in Sway. (bspwm and other x11 wms worked) Additional context If I have xdgutils installed globally, it works as expected. Notify maintainers xdgutils & firefox: firefox: Metadata Please run and paste the result.
Chromium seems to be ok now.
Added additional context, which might lead to solving the main issue.
Oh, I forgot that this is also for Firefox.
Change:
<del> { stdenv, wrapQtAppsHook, makeDesktopItem, fetchFromGitHub , qtbase, qmake, qtmultimedia, qttools , qtgraphicaleffects, qtdeclarative , qtlocation, qtquickcontrols, qtquickcontrols2 , qtwebchannel, qtwebengine, qtx11extras, qtxmlpatterns </del> <ins> { stdenv, wrapQtAppsHook, makeDesktopItem , fetchFromGitHub, qmake, qttools, pkgconfig , qtbase, qtdeclarative, qtgraphicaleffects , qtmultimedia, qtxmlpatterns , qtquickcontrols, qtquickcontrols2 </ins> , monero, unbound, readline, boost, libunwind <del> , libsodium, pcsclite, zeromq, cppzmq, pkgconfig , hidapi, randomx </del> <ins> , libsodium, pcsclite, zeromq, cppzmq , hidapi, libusb, protobuf, randomx </ins> }: with stdenv.lib; stdenv.mkDerivation rec { pname = "monero-gui"; <del> version = "0.15.0.1"; </del> <ins> version = "0.15.0.4"; </ins> src = fetchFromGitHub { owner  = "monero-project"; repo   = "monero-gui"; rev    = "v${version}"; <del> sha256 = "08j8kkncdn57xql0bhmlzjpjkdfhqbpda1p07r797q8qi0nl4w8n"; </del> <ins> sha256 = "12m5fgnxkr11q2arx1m5ccpxqm5ljcvm6l547dwqn297zs5jim4z"; </ins> }; nativeBuildInputs = [ qmake pkgconfig wrapQtAppsHook ]; buildInputs = [ <del> qtbase qtmultimedia qtgraphicaleffects qtdeclarative qtlocation qtquickcontrols qtquickcontrols2 qtwebchannel qtwebengine qtx11extras qtxmlpatterns monero unbound readline </del> <ins> qtbase qtdeclarative qtgraphicaleffects qtmultimedia qtquickcontrols qtquickcontrols2 qtxmlpatterns monero unbound readline </ins> boost libunwind libsodium pcsclite zeromq <del> cppzmq hidapi randomx </del> <ins> cppzmq hidapi libusb protobuf randomx </ins> ]; NIX_CFLAGS_COMPILE = [ "-Wno-error=format-security" ];

Discussion:
Describe the bug monero-gui fails to build, it was part of my . I am on nixos-unstable. To Reproduce Steps to reproduce the behavior: Expected behavior Build success. Metadata
Change:
<del> { lib , buildPythonPackage , isPy3k , fetchFromGitHub , mkdocs , pytestCheckHook }: buildPythonPackage rec { pname = "mkdocs-simple-hooks"; version = "0.1.5"; format = "setuptools"; disabled = !isPy3k; src = fetchFromGitHub { owner = "aklajnert"; repo = "mkdocs-simple-hooks"; rev = "v${version}"; hash = "sha256-N6xZjCREjJlhR6f8m65WJswUQv/TTdTbk670+C46UWQ="; }; propagatedBuildInputs = [ mkdocs ]; nativeCheckInputs = [ pytestCheckHook ]; pytestFlagsArray = [ "tests.py" ]; # disable failing tests disabledTests = [ "test_no_hooks_defined" "test_no_attribute" ]; meta = with lib; { description = "Define your own hooks for mkdocs, without having to create a new package."; homepage = "https://github.com/aklajnert/mkdocs-simple-hooks"; license = licenses.mit; maintainers = with maintainers; [ arjan-s ]; }; } </del>

Discussion:
Steps to reproduce the behavior: (e.g. use sth like ) (tried on both unstable n unstable-small) Seems somewhat similara Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Perhaps we can just remove this package? It's only required by ntfy-sh currently, which . Also, according to those release notes, hooks are a native part of mkdocs since 1.4, so I want to propose to just remove this.
Change:
<del> { stdenv, fetchFromGitHub, autoreconfHook, pkgconfig, zeromq3, jdk }: stdenv.mkDerivation rec { pname = "jzmq"; version = "3.1.0"; src = fetchFromGitHub { owner = "zeromq"; repo = "jzmq"; rev = "v${version}"; sha256 = "1wlzs604mgmqmrgpk4pljx2nrlxzdfi3r8k59qlm90fx8qkqkc63"; }; nativeBuildInputs = [ autoreconfHook pkgconfig ]; buildInputs = [ zeromq3 jdk ]; preConfigure = '' ${if stdenv.hostPlatform.system == "x86_64-darwin" then '' sed -i -e 's~/Headers~/include~' -e 's~_JNI_INC_SUBDIRS=".*"~_JNI_INC_SUBDIRS="darwin"~' configure '' else ""} ''; meta = { homepage = "http://www.zeromq.org"; description = "Java bindings for ZeroMQ"; platforms = stdenv.lib.platforms.unix; license = stdenv.lib.licenses.lgpl3; maintainers = [ stdenv.lib.maintainers.vizanto ]; }; } </del>

Discussion:
, (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
According to this comment , should not be affected. Nontheless, this is a very old version and there are only two packages depends on it: rzmq (apparently supports 4.x but is broken since 2016) jzmq (support 3.x and looks unmaintained) jzmq is only needed by apache stom but the dependecy as since been dropped: see can you update apache storm so we can get rid of jzmq?
Change:
email = "babathriviere@gmail.com"; github = "babariviere"; githubId = 12128029; <del> name = "babariviere"; </del> <ins> name = "Bastien Rivière"; keys = [{ longkeyid = "rsa4096/0xF202AD3B6EDF4BD1"; fingerprint = "2F85 B362 B274 0012 37E2  81EE F202 AD3B 6EDF 4BD1"; }]; </ins> }; babbaj = { name = "babbaj";

Discussion:
Describe the bug When running I get the following error message: Looking at the executable the first line is: In fish does not return the name of the current executed file. It appear to work when running this using . Also as comparison look at the file generated via package manager: To Reproduce Steps to reproduce the behavior: Expected behavior should start the server Additional context So with . Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(yogsototh): nixpkgs: Maintainer information:
Hey this version is pretty outdated, could you try latest which is using graalvm binary?
Also the brew forumla you saw is outdated as well, the updated is
You are probably using the stable channel 20.09 channel, that should explain why you're still using the with JVM instead of GraalVM compiled binary. Switch to the unstable channel instead. I am not sure if it will work though since this package was never tested with macOS (and the fact that this package is broken in Hydra: ).
I just tested with latest master commit And if failed to build: I think the main bug is probably fixed. This is just another one :). This is late for me. I'll probably give it a look another day. Thanks for checking!
I think all GraalVM's packages build with Clojure are broken in macOS simply by the lack of people that has macOS systems to test/fix them. If you can fix this, a PR would be welcome :slightlysmilingface: .
Agreed If you have mac, using the homebrew official clojure-lsp formula should work as well: https://clojure-