jiebi/CodeConvo huggingface dataset:
Code change:
Project description Netdata agent plugin Metadata homepage URL: source URL: license: GPL 3.0 platforms: unix, linux, darwin We already do have netdata, however it seems to be built without support for the cloud agent that allows it to stream to the cloud or other netdata servers.
I have a local checkout with some edits that allow me to build netdata with cloud support. Unfortunately they also require a change in the libwebsockets build expression. Should I open a PR to integrate my changes into nixpkgs?
A PR would be great! I'm not a maintainer, but if they decide it's out of scope for nixpkgs, perhaps one on NUR might work - I'd try for a PR here first though
Great, I think having a configuration option that is per default would make sense. Maybe ?
Yeah, that seems to fall in line with the various flags present in other packages
I marked this as stale due to inactivity. &rarr;
Upstream has incorporated some of the suggestions in this thread, I intend to pick up on it again soon
what would be needed to make this work? Perhaps I can help?
The newest major release of Netdata (1.30.0) includes a cloud link implementation without the need for vendored dependencies. Unfortunately, it is not currently in a reliable state because of a bug in the custom HTTPS implementation. The has already been merged into Netdata master and will be included in the next release. I plan to make a PR that enables cloud support as soon as that release is available.
v1.31.0 dropped 12 minutes ago :) Anything I can do to help?
Thanks, I've already gotten a notification for that. Planning to make a PR when I get off work today. When my PR is done, it would be helpful if you could test my changes on your machines.
Just FYI, I have opened the PR that enables cloud support a few days ago. If you are still interested it would be greatly appreciated if you could test if everything works for you and maybe drop a comment.
Sorry, missed this but the pr looks good! I propose we backport this to stable?

Related discussion:
text: configureFlags = [ "--localstatedir=/var" "--sysconfdir=/etc" <ins> ] ++ optionals withCloud [ "--enable-cloud" "--with-aclk-ng" </ins> ]; postFixup = ''
Code change:
Describe the bug , a package which requires PySide2, fails to install, either system-wide, nix-env local, nix-env global, or with home-manager. To Reproduce Results Running the above command: Expected behavior Syncplay installs correctly without error. Notify maintainers pyside2: syncplay: Metadata Please run and paste the result.
This not only affects syncplay. Many other dependencies are broken as well. Freecad for instance does not build either.
looks like updating pyside2 to 5.12.6 fixed this issue on my fork:
Your fix looks good to me. Could you PR it?
done,

Related discussion:
text: stdenv.mkDerivation rec { pname = "pyside2"; <del> version = "5.12.3"; </del> <ins> version = "5.12.6"; </ins> src = fetchurl { url = "https://download.qt.io/official_releases/QtForPython/pyside2/PySide2-${version}-src/pyside-setup-everywhere-src-${version}.tar.xz"; <del> sha256 = "0hk89jm8pa0q6kifask5rrffa3bvx02dg2f97ibv7wds9dysnyjg"; </del> <ins> sha256 = "1n45l6xxyxs6cfp2l4rp8qs1c2fyfwyrdxa4qcpwfsqsi51rydsk"; </ins> }; patches = [
Code change:
Describe the bug , a package which requires PySide2, fails to install, either system-wide, nix-env local, nix-env global, or with home-manager. To Reproduce Results Running the above command: Expected behavior Syncplay installs correctly without error. Notify maintainers pyside2: syncplay: Metadata Please run and paste the result.
This not only affects syncplay. Many other dependencies are broken as well. Freecad for instance does not build either.
looks like updating pyside2 to 5.12.6 fixed this issue on my fork:
Your fix looks good to me. Could you PR it?
done,

Related discussion:
text: <del> --- pyside-setup-everywhere-src-5.12.3/sources/shiboken2/ApiExtractor/clangparser/compilersupport.cpp~	2019-06-15 10:31:04.712949189 +0200 +++ pyside-setup-everywhere-src-5.12.3/sources/shiboken2/ApiExtractor/clangparser/compilersupport.cpp	2019-06-15 11:52:52.894987343 +0200 @@ -317,15 +317,15 @@ </del> <ins> --- pyside-setup-everywhere-src-5.12.6/sources/shiboken2/ApiExtractor/clangparser/compilersupport.cpp~	2020-07-08 14:37:13.022476435 -0700 +++ pyside-setup-everywhere-src-5.12.6/sources/shiboken2/ApiExtractor/clangparser/compilersupport.cpp	2020-07-08 14:37:18.271484269 -0700 @@ -330,17 +330,15 @@ </ins> } #endif // NEED_CLANG_BUILTIN_INCLUDES
Code change:
Describe the bug , a package which requires PySide2, fails to install, either system-wide, nix-env local, nix-env global, or with home-manager. To Reproduce Results Running the above command: Expected behavior Syncplay installs correctly without error. Notify maintainers pyside2: syncplay: Metadata Please run and paste the result.
This not only affects syncplay. Many other dependencies are broken as well. Freecad for instance does not build either.
looks like updating pyside2 to 5.12.6 fixed this issue on my fork:
Your fix looks good to me. Could you PR it?
done,

Related discussion:
text: -    // A fix for this has been added to Clang 5.0, so, the code can be removed -    // once Clang 5.0 is the minimum version. -    if (needsGppInternalHeaders()) { <del> -        const HeaderPaths gppPaths = gppInternalIncludePaths(QStringLiteral("g++")); </del> <ins> -        const HeaderPaths gppPaths = gppInternalIncludePaths(compilerFromCMake(QStringLiteral("g++"))); </ins> -        for (const HeaderPath &h : gppPaths) { <del> -            if (h.path.contains("c++")) </del> <ins> -            if (h.path.contains("c++") -                || h.path.contains("sysroot")) { // centOS </ins> -                headerPaths.append(h); <ins> -            } </ins> +    const HeaderPaths gppPaths = gppInternalIncludePaths(QStringLiteral("g++")); +    for (const HeaderPath &h : gppPaths) { +        // PySide2 requires that Qt headers are not -isystem
Code change:
Describe the bug oneDNN is a dependency of pytorch. Today, oneDNN's are all linux-based but oneDNN actually appears to compile fine on ; its tests just all immediately fail because of RPATH problems. To Reproduce Expected behavior I expect oneDNN to build and check successfully. Additional context I think that this problem may be able to be fixed by adding in on Darwin, much like is currently set and exported. Note, for even more detail/context on CMake's support for controlling RPATH on macOS, please see Notify maintainers Metadata (Note, I am actually testing this using nix flakes, with this ) Maintainer information:

Related discussion:
text: # https://github.com/oneapi-src/oneDNN#oneapi-deep-neural-network-library-onednn stdenv.mkDerivation rec { pname = "oneDNN"; <del> version = "1.5"; </del> <ins> version = "1.5.1"; </ins> src = fetchFromGitHub { owner = "oneapi-src"; repo = "oneDNN"; rev = "v${version}"; <del> sha256 = "0diiy3g4wz5lnz5mdvka5p2nwmrpfldsz83sssr5yiir29m4lqap"; </del> <ins> sha256 = "1l66gkidldjpznp8pb01wdgrmm0rmrbndv8lzidz8fp9hf473zgl"; </ins> }; outputs = [ "out" "dev" "doc" ];
Code change:
Describe the bug oneDNN is a dependency of pytorch. Today, oneDNN's are all linux-based but oneDNN actually appears to compile fine on ; its tests just all immediately fail because of RPATH problems. To Reproduce Expected behavior I expect oneDNN to build and check successfully. Additional context I think that this problem may be able to be fixed by adding in on Darwin, much like is currently set and exported. Note, for even more detail/context on CMake's support for controlling RPATH on macOS, please see Notify maintainers Metadata (Note, I am actually testing this using nix flakes, with this ) Maintainer information:

Related discussion:
text: # The test driver doesn't add an RPath to the build libdir preCheck = '' <del> export LD_LIBRARY_PATH=$PWD/src </del> <ins> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH''${LD_LIBRARY_PATH:+:}$PWD/src export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH''${DYLD_LIBRARY_PATH:+:}$PWD/src </ins> ''; # The cmake install gets tripped up and installs a nix tree into $out, in
Code change:
Describe the bug oneDNN is a dependency of pytorch. Today, oneDNN's are all linux-based but oneDNN actually appears to compile fine on ; its tests just all immediately fail because of RPATH problems. To Reproduce Expected behavior I expect oneDNN to build and check successfully. Additional context I think that this problem may be able to be fixed by adding in on Darwin, much like is currently set and exported. Note, for even more detail/context on CMake's support for controlling RPATH on macOS, please see Notify maintainers Metadata (Note, I am actually testing this using nix flakes, with this ) Maintainer information:

Related discussion:
text: meta = with lib; { description = "oneAPI Deep Neural Network Library (oneDNN)"; <del> homepage = "https://01.org/dnnl"; </del> <ins> homepage = "https://01.org/oneDNN"; </ins> changelog = "https://github.com/oneapi-src/oneDNN/releases/tag/v${version}"; license = licenses.asl20; <del> platforms = [ "aarch64-linux" "x86_64-linux" ]; </del> <ins> platforms = platforms.all; </ins> maintainers = with maintainers; [ alexarice bhipple ]; }; }
Code change:
Describe the bug AppImages assume that the gmp library is present on the system, but appimage-run does not include gmp. To Reproduce Steps to reproduce the behavior: +x the appimage Expected behavior The app should run. Additional context I believe it is because of this commit: I fixed it on my end with: 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(root): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. &rarr;
not stale
Also affected:
as pointed out by t-paul, appimage specifically assumes GMP is provided by the system

Related discussion:
text: fribidi p11-kit <ins> gmp </ins> # libraries not on the upstream include list, but nevertheless expected # by at least one appimage libtool.lib # for Synfigstudio
Code change:
See e.g. or
I've been hoping for someone else to look at this one, but I expect I have to give it more visibility, hence this ticket.

Related discussion:
text: sha256 = "03nislxccnbxld89giak2s8xa4mdbwscfxbdwhmw5qpvgz08dgwh"; }; <ins> # See <https://gitlab.com/apparmor/apparmor/-/issues/74> This and the # accompanying application in prePatchCommon should be removed in 2.13.5 gnumake43Patch = fetchpatch { url = "https://gitlab.com/apparmor/apparmor/-/merge_requests/465.patch"; name = "2-23-fix-build-with-make-4.3.patch"; sha256 = "0xw028iqp69j9mxv0kbwraplgkj5i5djdlgf0anpkc5cdbsf96r9"; }; </ins> prePatchCommon = '' <ins> patch -p1 < ${gnumake43Patch} chmod a+x ./common/list_capabilities.sh ./common/list_af_names.sh patchShebangs ./common/list_capabilities.sh ./common/list_af_names.sh </ins> substituteInPlace ./common/Make.rules --replace "/usr/bin/pod2man" "${buildPackages.perl}/bin/pod2man" substituteInPlace ./common/Make.rules --replace "/usr/bin/pod2html" "${buildPackages.perl}/bin/pod2html" substituteInPlace ./common/Make.rules --replace "/usr/include/linux/capability.h" "${linuxHeaders}/include/linux/capability.h"
Code change:
The current version of qutebrowser (1.13.0, nixpkgs svn-revision: .) packaged in unstable fails to start with webkit backend. Forcing the backend in the resulting error dialog does nothing. To Reproduce Steps to reproduce the behavior: in qutebrowser Screenshots ! Notify maintainers
The qtwebkit backend was disabled in . Apparently at the time there was talk about dropping the backend but eventually they decided to keep it for a while. In any case here's what the current README says about it Soo, we could revert the commit but it seems it's going to be anyway. This is the reason, it looks like a variable that points to the qutebrowser executable is not actually resolved:
Thanks for the info regarding the readme and webkit. I'm pretty new to nixpks. Let me now if this would be a viable solution: and I'll make the PR. Also, where should I branch off of and what should be the target branch for my PR. It is the best I could come up with, because webkit and webengine depend on to different versions of qt5 so, we cannot easily have qutebrowser depend on both.
You can just revert the commit I mentioned: that should take care of also enabling qtwebkit by default, which is probably what you want. To make a PR you should target the master branch, also take a look at the .
Hmm... I don't really know, what to make of this part: in the current version it reads: and reverting just the other changes gives me build-errors.
Uhm, try something like this:
Now I get the original import error on starting qutebrowser, when I have set to . Maybe was the right solution after all, because that at least worked.

Related discussion:
text: , mkDerivationWith, wrapQtAppsHook, wrapGAppsHook, qtbase, glib-networking , asciidoc, docbook_xml_dtd_45, docbook_xsl, libxml2 , libxslt, gst_all_1 ? null <del> , withPdfReader        ? true , withMediaPlayback    ? true </del> <ins> , withPdfReader      ? true , withMediaPlayback  ? true , backend            ? "webkit" </ins> }: assert withMediaPlayback -> gst_all_1 != null;
Code change:
The current version of qutebrowser (1.13.0, nixpkgs svn-revision: .) packaged in unstable fails to start with webkit backend. Forcing the backend in the resulting error dialog does nothing. To Reproduce Steps to reproduce the behavior: in qutebrowser Screenshots ! Notify maintainers
The qtwebkit backend was disabled in . Apparently at the time there was talk about dropping the backend but eventually they decided to keep it for a while. In any case here's what the current README says about it Soo, we could revert the commit but it seems it's going to be anyway. This is the reason, it looks like a variable that points to the qutebrowser executable is not actually resolved:
Thanks for the info regarding the readme and webkit. I'm pretty new to nixpks. Let me now if this would be a viable solution: and I'll make the PR. Also, where should I branch off of and what should be the target branch for my PR. It is the best I could come up with, because webkit and webengine depend on to different versions of qt5 so, we cannot easily have qutebrowser depend on both.
You can just revert the commit I mentioned: that should take care of also enabling qtwebkit by default, which is probably what you want. To make a PR you should target the master branch, also take a look at the .
Hmm... I don't really know, what to make of this part: in the current version it reads: and reverting just the other changes gives me build-errors.
Uhm, try something like this:
Now I get the original import error on starting qutebrowser, when I have set to . Maybe was the right solution after all, because that at least worked.

Related discussion:
text: stripRoot = false; }; <ins> backendPackage = if backend == "webengine" then python3Packages.pyqtwebengine else if backend == "webkit"    then python3Packages.pyqt5_with_qtwebkit else throw '' Unknown qutebrowser backend "${backend}". Valid choices are qtwebengine (recommended) or qtwebkit. ''; </ins> in mkDerivationWith python3Packages.buildPythonApplication rec { pname = "qutebrowser"; version = "1.13.0";
Code change:
The current version of qutebrowser (1.13.0, nixpkgs svn-revision: .) packaged in unstable fails to start with webkit backend. Forcing the backend in the resulting error dialog does nothing. To Reproduce Steps to reproduce the behavior: in qutebrowser Screenshots ! Notify maintainers
The qtwebkit backend was disabled in . Apparently at the time there was talk about dropping the backend but eventually they decided to keep it for a while. In any case here's what the current README says about it Soo, we could revert the commit but it seems it's going to be anyway. This is the reason, it looks like a variable that points to the qutebrowser executable is not actually resolved:
Thanks for the info regarding the readme and webkit. I'm pretty new to nixpks. Let me now if this would be a viable solution: and I'll make the PR. Also, where should I branch off of and what should be the target branch for my PR. It is the best I could come up with, because webkit and webengine depend on to different versions of qt5 so, we cannot easily have qutebrowser depend on both.
You can just revert the commit I mentioned: that should take care of also enabling qtwebkit by default, which is probably what you want. To make a PR you should target the master branch, also take a look at the .
Hmm... I don't really know, what to make of this part: in the current version it reads: and reverting just the other changes gives me build-errors.
Uhm, try something like this:
Now I get the original import error on starting qutebrowser, when I have set to . Maybe was the right solution after all, because that at least worked.

Related discussion:
text: ]; propagatedBuildInputs = with python3Packages; [ <del> pyyaml pyqt5 pyqtwebengine jinja2 pygments </del> <ins> pyyaml backendPackage jinja2 pygments </ins> pypeg2 cssutils pyopengl attrs setuptools # scripts and userscripts libs tldextract beautifulsoup4 pyreadability pykeepass stem ]; <del> patches = [ ./fix-restart.patch ]; </del> <ins> patches = [ ./fix-restart.patch ]; </ins> dontWrapGApps = true; dontWrapQtApps = true;
Code change:
The current version of qutebrowser (1.13.0, nixpkgs svn-revision: .) packaged in unstable fails to start with webkit backend. Forcing the backend in the resulting error dialog does nothing. To Reproduce Steps to reproduce the behavior: in qutebrowser Screenshots ! Notify maintainers
The qtwebkit backend was disabled in . Apparently at the time there was talk about dropping the backend but eventually they decided to keep it for a while. In any case here's what the current README says about it Soo, we could revert the commit but it seems it's going to be anyway. This is the reason, it looks like a variable that points to the qutebrowser executable is not actually resolved:
Thanks for the info regarding the readme and webkit. I'm pretty new to nixpks. Let me now if this would be a viable solution: and I'll make the PR. Also, where should I branch off of and what should be the target branch for my PR. It is the best I could come up with, because webkit and webengine depend on to different versions of qt5 so, we cannot easily have qutebrowser depend on both.
You can just revert the commit I mentioned: that should take care of also enabling qtwebkit by default, which is probably what you want. To make a PR you should target the master branch, also take a look at the .
Hmm... I don't really know, what to make of this part: in the current version it reads: and reverting just the other changes gives me build-errors.
Uhm, try something like this:
Now I get the original import error on starting qutebrowser, when I have set to . Maybe was the right solution after all, because that at least worked.

Related discussion:
text: postFixup = '' wrapProgram $out/bin/qutebrowser  "''${gappsWrapperArgs[@]}"  <del> "''${qtWrapperArgs[@]}" </del> <ins> "''${qtWrapperArgs[@]}"  --add-flags '--backend ${backend}' </ins> ''; meta = with stdenv.lib; {
Code change:
Dropbox does not work for me after the last update to version to 3.8.5 (commit ). The daemon starts, but no activity at all can be observed (it doesn't sync nor start the notification applet). If I start the old version that I still have in the store (3.6.9) it works. I run nixos on 32bit. I made several attempt: unlink/relink the computer from the dropbox site; restart with fresh ~/.dropbox and ~/Dropbox dirs; etc. Nothing works.
/cc author
does output anything?
also, which channel are you on? I just set up a nixos-unstable 32bit vm with dropbox 3.8.8 (not yet pushed) and it works fine
It's probably, because with 3.8.4, dropbox' qt dependency has been upgraded to 5.4, while current nixos-stable is still on 5.3 I bet you're on stable, right? Not sure if we should backport qt 5.4 to stable, or just downgrade dropbox to 3.6.9 and hope it keeps working till there is a new stable release.

Related discussion:
text: # them with our own. let <del> version = "3.8.5"; </del> <ins> version = "3.6.9"; </ins> sha256 = { <del> "x86_64-linux" = "1r0wz2fsx2piasl04qsgwbl88bi0ajr0dm2swbslxwkf789vk18y"; "i686-linux" = "1dvfgp9dg3frhwmchwa6fyws4im9vgicchfsv0zzflvc7rm9fcig"; </del> <ins> "x86_64-linux" = "1i260mi40siwcx9b2sj4zwszxmj1l88mpmyqncsfa72k02jz22j3"; "i686-linux" = "0qqc8qbfaighbhjq9y22ka6n6apl8b6cr80a9rkpk2qsk99k8h1z"; </ins> }."${stdenv.system}" or (throw "system ${stdenv.system} not supported"); arch =
Code change:
Describe the bug fails to build when attempting to cross-compile to aarch64 on : To Reproduce Expected behavior builds without error. Metadata nixpkgs Maintainer information:
I marked this as stale due to inactivity. &rarr;
Not stale - this issue still reproduces on current nixos-unstable ()

Related discussion:
text: mkdir -p $out/etc/udev/rules.d sed -i '/udev-acl/d' usb/55-Argyll.rules cp -v usb/55-Argyll.rules $out/etc/udev/rules.d/ <ins> sed -i -e 's/^CREATED .*/CREATED "'"$(date -d @$SOURCE_DATE_EPOCH)"'"/g' $out/share/argyllcms/RefMediumGamut.gam </ins> ''; meta = with lib; {
Code change:
Mattermost fixed a security issue in 4.5.1:
cc
thanks for bringing this up. I'll create the necessary PRs.

Related discussion:
text: in stdenv.mkDerivation rec { pname = "mattermost-desktop"; <del> version = "4.5.0"; </del> <ins> version = "4.5.2"; </ins> src = if stdenv.hostPlatform.system == "x86_64-linux" then fetchurl { url = "https://releases.mattermost.com/desktop/${version}/${pname}-${version}-linux-x64.tar.gz"; <del> sha256 = "1p44vxs7i9f15h4xjyr99g8x73qygv909a32lfkqip1fh8lk7sf4"; </del> <ins> sha256 = "0r9xmhzif1ia1m53yr59q6p3niyq3jv3vgv4703x68jmd46f91n6"; </ins> } else if stdenv.hostPlatform.system == "i686-linux" then fetchurl { url = "https://releases.mattermost.com/desktop/${version}/${pname}-${version}-linux-ia32.tar.gz"; <del> sha256 = "03pn853z2famqxcsrwayqb94pzghlpfb0qs2nfi8mc5zzsgcic7z"; </del> <ins> sha256 = "1h8lw06p3cqz9dkgbhfmzcrzjsir5cfhx28xm4zrmvkj4yfzbcnv"; </ins> } else throw "Mattermost-Desktop is not currently supported on ${stdenv.hostPlatform.system}";