jiebi/CodeConvo huggingface dataset:
Change:
clang installed through nix doesn't correctly output DWARF data. system: host os: multi-user?: sandbox: version: channels(fghibellini): nixpkgs:
For reference, we use a dummy dsymutil script due to Apple not releasing the original source. This is found here: and . llvm has its own version that should be available to us soon. I'm not sure which version it is first released in.
Thanks for the quick answer! Based on I would think dsymutil is supposed to be Apple specific. Does the llvm release of dsymutil mean this (separate debug info linking) will become standard across operating systems or the llvm dsymutil is also supposed to be used only on OSX?
dsymutil is for MACH-O binaries only. I think OSX is the only place where those are used. You can do something similar on Linux with objcopy though: But this is a good reminder that we need to get the separate debug symbols to work on MacOS as well.

Discussion:
<del> { stdenv, binutils-unwrapped, cctools }: </del> <ins> { stdenv, binutils-unwrapped, cctools, llvm }: </ins> # Make sure both underlying packages claim to have prepended their binaries # with the same targetPrefix.

let inherit (binutils-unwrapped) targetPrefix; cmds = [ <del> "ar" "ranlib" "as" "dsymutil" "install_name_tool" </del> <ins> "ar" "ranlib" "as" "install_name_tool" </ins> "ld" "strip" "otool" "lipo" "nm" "strings" "size" ]; in <del> # TODO loop over targetPrefixed binaries too </del> <ins> # TODO: loop over targetPrefixed binaries too </ins> stdenv.mkDerivation { name = "${targetPrefix}cctools-binutils-darwin"; outputs = [ "out" "info" "man" ];

# We specifically need: # - ld: binutils doesn't provide it on darwin # - as: as above <del> # - ar: the binutils one prodices .a files that the cctools ld doesn't like </del> <ins> # - ar: the binutils one produces .a files that the cctools ld doesn't like </ins> # - ranlib: for compatibility with ar <del> # - dsymutil: soon going away once it goes into LLVM (this one is fake anyway) </del> # - otool: we use it for some of our name mangling # - install_name_tool: we use it to rewrite stuff in our bootstrap tools # - strip: the binutils one seems to break mach-o files

ln -sf "${cctools}/bin/$i" "$out/bin/$i" done <ins> ln -s ${llvm}/bin/llvm-dsymutil $out/bin/dsymutil </ins> ln -s ${binutils-unwrapped.out}/share $out/share ln -s ${cctools}/libexec $out/libexec

popd ''; <del> postInstall = '' cat >$out/bin/dsymutil << EOF #!${stdenv.shell} EOF chmod +x $out/bin/dsymutil ''; </del> passthru = { inherit targetPrefix; };

binutils-unwrapped = callPackage ../os-specific/darwin/binutils { inherit (darwin) cctools; inherit (pkgs) binutils-unwrapped; <ins> inherit (pkgs.llvmPackages_5) llvm; </ins> }; binutils = pkgs.wrapBintoolsWith {
Change:
The following setting has no effect: This is because the is set globally depending on whether the host is IPv6 capable . This line should be set after , otherwise it is not possible to override it for a specific host (first match wins). Perhaps the other options should be moved as well? Alternatively, the line could only be set if it is not , as that is the default. However, I don't think that is the right solution. Insert the above snippet into , and try to connect to an IPv4 only server from an IPv6-capable client. Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): channels(kai): nixpkgs:
This server is probably a bit weird in that it has both IPv6/4 DNS entries, but only accepts SSH connections over IPv4, so it's an odd edge case.

Discussion:
type = types.lines; default = ""; description = '' <del> Extra configuration text appended to <filename>ssh_config</filename>. </del> <ins> Extra configuration text prepended to <filename>ssh_config</filename>. Other generated options will be added after a <code>Host *</code> pattern. </ins> See <citerefentry><refentrytitle>ssh_config</refentrytitle><manvolnum>5</manvolnum></citerefentry> for help. '';

# generation in the sshd service. environment.etc."ssh/ssh_config".text = '' <ins> # Custom options from `extraConfig`, to override generated options ${cfg.extraConfig} # Generated options from other settings Host * </ins> AddressFamily ${if config.networking.enableIPv6 then "any" else "inet"} ${optionalString cfg.setXAuthLocation ''

${optionalString (cfg.pubkeyAcceptedKeyTypes != []) "PubkeyAcceptedKeyTypes ${concatStringsSep "," cfg.pubkeyAcceptedKeyTypes}"} ${optionalString (cfg.hostKeyAlgorithms != []) "HostKeyAlgorithms ${concatStringsSep "," cfg.hostKeyAlgorithms}"} <del> ${cfg.extraConfig} </del> ''; environment.etc."ssh/ssh_known_hosts".text = knownHostsText;
Change:
i ran today and got this error: Please run and paste the results.
looks like has changed:
For future debugging, you should always include when the configure script fails. Reproducing it, this is the error: The breaking commit appears to be: not sure what is going on though.
FWIW, I came to the same conclusion via git bisect (starting based on hydra builds ) Isn't nixos-unstable supposed to receive updates from master only after the build succeeds on hydra?
I don't think it's actually libffi that broke... It's just the way gnustep-base is tesing libffi, namely In particular, note on the first line without a corresponding . Rather strangely, earlier tests specifically for bfd seem to have succeeded. Eg: I'm not sure how...
Nice work! I suspect that libbfd is hardcoded into clang somewhere. For whatever reason it does not pick up the right location though. This is true for certain things that are blocking jobs (or dependencies of those jobs). They are listed here: but right now we don't have gnustep or unar in any of these.
Oh ok, I suppose blocking only on "important" things makes sense. Also, thinking about it a little more, I'm not entirely sure libbfd needs to be in (vs ). Running ldd on an older unar, doesn't show up anywhere. That could be either because it was being statically linked, or because it was only used at build time. (I'm somewhat familiar with libbdf from work I did years ago, but not at all familiar with libffi.)
hi, i'm still getting this error, what can i do to debug/fix this?
fwiw, I have this error when building via (i.e. ).

Discussion:
, cups , fetchurl , gmp, gnutls <del> , libffi </del> <ins> , libffi, libbfd </ins> , libjpeg, libtiff, libpng, giflib, libungif , libxml2, libxslt, libiconv , libobjc, libgcrypt

aspell audiofile cups gmp gnutls <del> libffi </del> <ins> libffi libbfd </ins> libjpeg libtiff libpng giflib libungif libxml2 libxslt libiconv libobjc libgcrypt
Change:
The ffuu tool analyses iptable rules and dumps them. I thought it would be pretty cool to try it out on NixOS.
Looks like has done this:

Discussion:
<ins> { mkDerivation, haskellPackages, fetchFromGitHub, lib }: mkDerivation rec { pname = "fffuu"; version = "unstable-2018-05-26"; src = fetchFromGitHub { owner = "diekmann"; repo = "Iptables_Semantics"; rev = "e0a2516bd885708fce875023b474ae341cbdee29"; sha256 = "1qc7p44dqja6qrjbjdc2xn7n9v41j5v59sgjnxjj5k0mxp58y1ch"; }; postPatch = '' substituteInPlace haskell_tool/fffuu.cabal  --replace "containers >=0.5 && <0.6" "containers >= 0.6"  --replace "optparse-generic >= 1.2.3 && < 1.3" "optparse-generic >= 1.2.3" ''; preCompileBuildDriver = '' cd haskell_tool ''; isLibrary = false; isExecutable = true; # fails with sandbox doCheck = false; libraryHaskellDepends = with haskellPackages; [ base containers split parsec optparse-generic ]; executableHaskellDepends = with haskellPackages; [ base ]; testHaskellDepends = with haskellPackages; [ tasty tasty-hunit tasty-golden ]; description = "Fancy Formal Firewall Universal Understander"; homepage = https://github.com/diekmann/Iptables_Semantics/tree/master/haskell_tool; license = lib.licenses.bsd2; maintainers = [ lib.maintainers.marsam ]; } </ins>

flootty = callPackage ../development/tools/flootty { }; <ins> fffuu = haskell.lib.justStaticExecutables (haskellPackages.callPackage ../tools/misc/fffuu { }); </ins> flow = callPackage ../development/tools/analysis/flow { inherit (darwin.apple_sdk.frameworks) CoreServices; };
Change:
This is addressed on staging by which doesn't seem appropriate for master due to the amount of rebuilds. The build failure is blocking two tests on the channel. master
There's also which turns on by default, preventing these problems more generally (would also have to go through staging of course). Hydra has almost nothing to do at the moment though , so we should probably start up staging-next again.

Discussion:
, curl , enableTNC            ? false, trousers, sqlite, libxml2 , enableNetworkManager ? false, networkmanager <ins> , libpcap </ins> }: # Note on curl support: If curl is built with gnutls as its backend, the

[ curl gmp python iptables ldns unbound openssl pcsclite ] ++ optionals enableTNC [ trousers sqlite libxml2 ] ++ optionals stdenv.isLinux [ systemd.dev pam ] <del> ++ optionals enableNetworkManager [ networkmanager ]; </del> <ins> ++ optionals enableNetworkManager [ networkmanager ] # ad-hoc fix for https://github.com/NixOS/nixpkgs/pull/51787 # Remove when the above PR lands in master ++ [ libpcap ]; </ins> patches = [ ./ext_auth-path.patch
Change:
Starting liquibase results in: system: host os: multi-user?: sandbox: version: channels(philipp): channels(root): nixpkgs:
This is fixed in: So the next release should have this. Alternatives seem to be: Manually download the slf4j jar file and include it in the classpath Use an older version (3.5.* seems to work) Include the PR in the derivation. This would mean building liquibase from source. Keep it broken until it's released. I'm a little baffled that nobody actually tried to execute liquibase apparently. What do you suggest? I made a preliminiary PR that fixes the problem.

Discussion:
with stdenv.lib; let extraJars = optional mysqlSupport mysql_jdbc; <ins> logback-core = fetchurl { url = "http://central.maven.org/maven2/ch/qos/logback/logback-core/1.2.3/logback-core-1.2.3.jar"; sha256 = "5946d837fe6f960c02a53eda7a6926ecc3c758bbdd69aa453ee429f858217f22"; }; logback-classic = fetchurl { url = "http://central.maven.org/maven2/ch/qos/logback/logback-classic/1.2.3/logback-classic-1.2.3.jar"; sha256 = "fb53f8539e7fcb8f093a56e138112056ec1dc809ebb020b59d8a36a5ebac37e0"; }; slf4j = fetchurl { url = "http://central.maven.org/maven2/org/slf4j/slf4j-api/1.7.25/slf4j-api-1.7.25.jar"; sha256 = "18c4a0095d5c1da6b817592e767bb23d29dd2f560ad74df75ff3961dbde25b79"; }; </ins> in stdenv.mkDerivation rec {

in '' mkdir -p $out/{bin,lib,sdk} mv ./* $out/ <ins> cp ${logback-core} ${logback-classic} ${slf4j} $out/lib </ins> # Clean up documentation. mkdir -p $out/share/doc/${name}
Change:
tests pass, while tests fail with: Official Hydra sees the same thing: with their Travis setup. (That is a build of a recent commit, but I still see the same failures after pointing at a checkout of ) Does anyone have any ideas? With nixpkgs master,
See scrapinghub/dateparser, scrapinghub/dateparser and scrapinghub/dateparser.
As long as this problem remains, the best thing to do is using for affected application. Switching to should be done in commits that don't change anything else and that reference this issue in their commit message so that they can easily be reverted. Simply skipping the tests does not make much sense since these are real incompatibilities.

Discussion:
{ stdenv, python3, fetchFromGitHub, fetchpatch }: with python3.pkgs; buildPythonApplication rec { <del> version = "3.8"; </del> <ins> version = "4.1"; </ins> pname = "buku"; src = fetchFromGitHub { owner = "jarun"; repo = "buku"; rev = "v${version}"; <del> sha256 = "0gv26c4rr1akcaiff1nrwil03sv7d58mfxr86pgsw6nwld67ns0r"; </del> <ins> sha256 = "166l1fmpqn4hys4l0ssc4yd590mmav1w62vm9l5ijhjhmlnrzfax"; </ins> }; checkInputs = [

arrow werkzeug click <ins> html5lib vcrpy </ins> ]; <ins> postPatch = '' # Jailbreak problematic dependencies sed -i  -e "s,'PyYAML.*','PyYAML',g"  setup.py ''; </ins> preCheck = '' # Fixes two tests for wrong encoding export PYTHONIOENCODING=utf-8

burp = callPackage ../tools/backup/burp { }; <del> buku = callPackage ../applications/misc/buku { }; </del> <ins> buku = callPackage ../applications/misc/buku { python3 = python36; # due to #52766 }; </ins> byzanz = callPackage ../applications/video/byzanz {};
Change:
tests pass, while tests fail with: Official Hydra sees the same thing: with their Travis setup. (That is a build of a recent commit, but I still see the same failures after pointing at a checkout of ) Does anyone have any ideas? With nixpkgs master,
See scrapinghub/dateparser, scrapinghub/dateparser and scrapinghub/dateparser.
As long as this problem remains, the best thing to do is using for affected application. Switching to should be done in commits that don't change anything else and that reference this issue in their commit message so that they can easily be reverted. Simply skipping the tests does not make much sense since these are real incompatibilities.

Discussion:
$hass->succeed("curl http://localhost:8123/api/states/binary_sensor.mqtt_binary_sensor -H 'x-ha-access: ${apiPassword}' | grep -qF '"state": "on"'"); # Toggle a binary sensor using hass-cli <del> $hass->succeed("${hassCli} entity get binary_sensor.mqtt_binary_sensor | grep -qF '"state": "on"'"); </del> <ins> $hass->succeed("${hassCli} --output json entity get binary_sensor.mqtt_binary_sensor | grep -qF '"state": "on"'"); </ins> $hass->succeed("${hassCli} entity edit binary_sensor.mqtt_binary_sensor --json='{"state": "off"}'"); $hass->succeed("curl http://localhost:8123/api/states/binary_sensor.mqtt_binary_sensor -H 'x-ha-access: ${apiPassword}' | grep -qF '"state": "off"'");

<del> { lib, python3 }: </del> <ins> # dateparser tests fail on pyton37: https://github.com/NixOS/nixpkgs/issues/52766 { lib, python36, glibcLocales }: </ins> <del> python3.pkgs.buildPythonApplication rec { </del> <ins> python36.pkgs.buildPythonApplication rec { </ins> pname = "homeassistant-cli"; <del> version = "0.3.0"; </del> <ins> version = "0.4.2"; </ins> <del> src = python3.pkgs.fetchPypi { </del> <ins> src = python36.pkgs.fetchPypi { </ins> inherit pname version; <del> sha256 = "42d7cb008801d7a448b62aed1fc46dd450ee67397bf16faabb02f691417db4b2"; </del> <ins> sha256 = "e0b05af9e49baf88a44f1b36c3446a106223016dceefd5f9910e204af5901f44"; </ins> }; postPatch = '' # Ignore pinned versions <del> sed -i "s/'(.*)==.*'/'1'/g" setup.py </del> <ins> sed -i "s/'(.*)(==|>=).*'/'1'/g" setup.py </ins> ''; <del> propagatedBuildInputs = with python3.pkgs; [ requests pyyaml netdisco click click-log tabulate idna jsonpath_rw jinja2 </del> <ins> propagatedBuildInputs = with python36.pkgs; [ requests pyyaml netdisco click click-log tabulate idna jsonpath_rw jinja2 dateparser </ins> ]; <del> checkInputs = with python3.pkgs; [ pytest requests-mock </del> <ins> checkInputs = with python36.pkgs; [ pytest requests-mock glibcLocales </ins> ]; checkPhase = '' <del> pytest </del> <ins> LC_ALL=en_US.UTF-8 pytest </ins> ''; meta = with lib; {
Change:
Inkscape has support for openclipart but it doesn't work in the package provided by nixpkgs. inkscape to File -Import Clip Art... a search term and click the Search button. the in the GUI and in the terminal. NixOS 18.09 and nixpkgs master.
I researched a bit and thought adding glib-networking would fix it. I wrote the following patch, but it doesn't seem to have any effect:
I wonder whether it really is because TLS support is unavailable, or because uses an invalid security certificate?
Good point. Hm, that's weird. I followed that URL () a day or two ago (when I first noticed this) and was redirected to https:// without problems. But now I see the certificate warning in firefox.
I think it may be a packaging bug after all. Look at this grep: The message only appears in the glib tree, in the gdummytlsbackend.c file. No matches from glib-networking, which AFAIK, provides TLS support.
I tried the patch and am getting Probably because the site is down.
is not down for me.
Thank you!

Discussion:
, glib, libgudev, udisks2, libgcrypt, libcap, polkit , libgphoto2, avahi, libarchive, fuse, libcdio , libxml2, libxslt, docbook_xsl, docbook_xml_dtd_42, samba, libmtp <del> , gnomeSupport ? false, gnome, makeWrapper </del> <ins> , gnomeSupport ? false, gnome, wrapGAppsHook </ins> , libimobiledevice, libbluray, libcdio-paranoia, libnfs, openssh , libsecret, libgdata, python3 }:

nativeBuildInputs = [ meson ninja python3 <del> pkgconfig gettext makeWrapper </del> <ins> pkgconfig gettext wrapGAppsHook </ins> libxml2 libxslt docbook_xsl docbook_xml_dtd_42 ];

# ToDo: a ligther version of libsoup to have FTP/HTTP support? ] ++ stdenv.lib.optionals gnomeSupport (with gnome; [ libsoup gcr <ins> glib-networking # TLS support </ins> gnome-online-accounts libsecret libgdata ]);

doCheck = false; # fails with "ModuleNotFoundError: No module named 'gi'" doInstallCheck = doCheck; <del> preFixup = '' for f in $out/libexec/*; do wrapProgram $f  ${stdenv.lib.optionalString gnomeSupport "--prefix GIO_EXTRA_MODULES : "${stdenv.lib.getLib gnome.dconf}/lib/gio/modules""}  --prefix XDG_DATA_DIRS : "$GSETTINGS_SCHEMAS_PATH" done ''; </del> passthru = { updateScript = gnome3.updateScript { packageName = pname;
Change:
When using Racket throws the error: . Sadly, installing libGLU(thus, ) doesn't fix the error. store into a file system: host os: multi-user?: sandbox: version: channels(trev): channels(root): nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos
Does adding 's to the environment variable help?
The answer is yes. I will add and to racket's lib dependencies.

Discussion:
, gtk3 , libedit, libffi , libiconv <ins> , libGL , libGLU </ins> , libjpeg , libpng, libtool, mpfr, openssl, pango, poppler , readline, sqlite

gtk3 gsettings-desktop-schemas libedit <ins> libGL libGLU </ins> libjpeg libpng mpfr
Change:
Hi! Just a quick heads up that with security fixes has been released. Thanks for updating!
Thank you!

Discussion:
stdenv.mkDerivation rec { name = "uriparser-${version}"; <del> version = "0.9.0"; </del> <ins> version = "0.9.1"; </ins> # Release tarball differs from source tarball src = fetchurl { url = "https://github.com/uriparser/uriparser/releases/download/${name}/${name}.tar.bz2"; <del> sha256 = "0b2yagxzhq9ghpszci6a9xlqg0yl7vq9j5r8dwbar3nszqsfnrzc"; </del> <ins> sha256 = "1gisi7h8hd6mswbiaaa3s25bnb77xf37pzrmjy63rcdpwcyqy93m"; </ins> }; nativeBuildInputs = [ pkgconfig doxygen graphviz ];
Change:
System hangs during boot when the timer configured via fires during the boot sequence. option. option such that the timer will be due to run immediately upon the next reboot of the system. ; allow sufficient amount of time to pass. Boot the system, observe the system to hang during the boot sequence. system: host os: multi-user?: sandbox: version: channels(pbogdan): nixpkgs:
Does setting help?
but otherwise yes, it does help, thank you.
Hi, I reproduced this on 19.03 yesterday. The unit already contained , so it seems it is not sufficient to fix this. Some data about my system:

Discussion:
systemd.timers.zfs-scrub = { wantedBy = [ "timers.target" ]; <ins> after = [ "multi-user.target" ]; # Apparently scrubbing before boot is complete hangs the system? #53583 </ins> timerConfig = { OnCalendar = cfgScrub.interval; Persistent = "yes";
Change:
Cross compiling any package with or results in an infinite recursion error. The same error when just evaluating I get the same results with A resulted into this commit: By removing the part from that commit already fixes this issue. Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
should fix this, hopefully. /cc

Discussion:
patches = [ ./osvi.patch ]; meta = { <del> platforms = stdenv.lib.platforms.windows; </del> <ins> platforms = stdenv.lib.platforms.all; </ins> }; }

# built with, and use, that cross-compiled libc. gccCrossStageStatic = assert stdenv.targetPlatform != stdenv.hostPlatform; let libcCross1 = <del> if stdenv.targetPlatform.libc == "msvcrt" then targetPackages.windows.mingw_w64_headers </del> <ins> if stdenv.targetPlatform.libc == "msvcrt" then windows.mingw_w64_headers </ins> else if stdenv.targetPlatform.libc == "libSystem" then darwin.xcode else null; binutils1 = wrapBintoolsWith {
Change:
fails to build. The build error is in an internal dependency, . The nix derivation uses the upstream version from Github but Toggl is actually using a vendored internal version that has a number of fixes in it. The build error is due to using the discontinued library. Toggl's internal version uses . This problem has been noted in .
cc
Fixed in (tagged ). See for Nixpkgs PR.

Discussion:
{ stdenv, fetchzip, buildEnv, makeDesktopItem, runCommand, writeText, pkgconfig , cmake, qmake, cacert, jsoncpp, libX11, libXScrnSaver, lua, openssl, poco <del> , qtbase, qtwebkit, qtx11extras, sqlite }: </del> <ins> , qtbase, qtwebengine, qtx11extras, sqlite }: </ins> let name = "toggldesktop-${version}";

qt-oauth-lib = stdenv.mkDerivation rec { name = "qt-oauth-lib-${version}"; <del> version = "20180521.233208"; </del> <ins> version = "20190125.190943"; </ins> src = fetchzip { url = "https://github.com/yegortimoshenko/qt-oauth-lib/archive/${version}.tar.gz"; <del> sha256 = "0f46d44slzvzaqx0lksvv14lsc1jp8vd2mragxd61r820hybf5z3"; </del> <ins> sha256 = "0zmfgvdf6n79mgfvbda7lkdxxlzjmy86436gqi2r5x05vq04sfrj"; </ins> }; nativeBuildInputs = [ qmake ]; <del> buildInputs = [ qtbase qtwebkit ]; </del> <ins> buildInputs = [ qtbase qtwebengine ]; </ins> }; poco-pc = writeText "poco.pc" ''

libtoggl qxtglobalshortcut qtbase <del> qtwebkit </del> <ins> qtwebengine </ins> qt-oauth-lib qtx11extras libX11
Change:
The weather applet included in mate-applets fails to download weather information. It just shows "0°F", or sometimes "--" instead. I've tried setting it to different cities all over the world, none of them work. Interestingly, for UK cities, I get see the following in , perhaps it fails for a similar reason on other cities (though I don't see an error message for these): Install the weather applet in MATE and try to get it to show anything useful. I've tried adding to the of both and , but it doesn't help at all. system: host os: multi-user?: sandbox: version: channels(shane): channels(root): nixpkgs:
Adding to would not do anything, since is loaded from the runtime environment. will wrap executables in and directories, setting variable correctly – that is an operation which does not make sense for libraries, it should work for , though.
works now. The only thing that's changed is that I now have Gnome and MATE installed side-by-side, whereas before I only had MATE. It seems a lot of things in MATE need bits of Gnome to work properly. I can't say for sure that's what was causing this, but I just can't think of anything else it could have been. In any case I'm going to close this.
Ran into this, please reopen. I'm running MATE on NixOS, but not Gnome.
Yep, also seeing this:
2 ugly workarounds are done right now: propagated enabled So I assume this is already fixed in 23.11. Note that since the weather applet is built in-process since we want to package the wayland session.

Discussion:
programs.system-config-printer.enable = (mkIf config.services.printing.enable (mkDefault true)); services.gnome.at-spi2-core.enable = true; <ins> services.gnome.glib-networking.enable = true; </ins> services.gnome.gnome-keyring.enable = true; services.udev.packages = [ pkgs.mate.mate-settings-daemon ]; services.gvfs.enable = true;
Change:
is broken on darwin, it requires an updated patch: Full log: Failure intrudoced in Blocks trunk through : cc

Discussion:
libsForQt512 = recurseIntoAttrs (lib.makeScope qt512.newScope mkLibsForQt5); <del> qt5 = qt512; libsForQt5 = libsForQt512; </del> <ins> # TODO bump to 5.12 on darwin once it's not broken qt5 = if stdenv.isDarwin then qt511 else qt512; libsForQt5 = if stdenv.isDarwin then libsForQt511 else libsForQt512; </ins> qt5ct = libsForQt5.callPackage ../tools/misc/qt5ct { };