jiebi/CodeConvo huggingface dataset:
Change:
<del> { lib, stdenv, fetchFromGitHub, rustPlatform , pkg-config, curl, libgit2, openssl, Security }: </del> <ins> { lib , stdenv , fetchFromGitHub , rustPlatform , pkg-config , curl , libgit2 , openssl , Security }: </ins> rustPlatform.buildRustPackage rec { pname = "cargo-raze"; <del> version = "0.12.0"; </del> <ins> version = "0.16.0"; </ins> src = fetchFromGitHub { owner = "google"; repo = pname; rev = "v${version}"; <del> sha256 = "161m4y6i4sgqi9mg3f3348f5cr0m45vhix4a4bcw54wnmhiklnnl"; </del> <ins> hash = "sha256-ip0WuBn1b7uN/pAhOl5tfmToK73ZSHK7rucdtufsbCQ="; </ins> }; sourceRoot = "source/impl"; <del> cargoSha256 = "1vlywdq0bx6b1k3w1grisca0hvv2s4s88yxq7bil8nhm5ghjgxdr"; </del> <ins> cargoHash = "sha256-hNZgQwhm4UPqmANplZGxG0DYHa31tu06nmqYaCA7Vdg="; </ins> nativeBuildInputs = [ pkg-config ]; buildInputs = [ libgit2 openssl <del> (curl.override { inherit openssl; }) </del> <ins> curl </ins> ] ++ lib.optional stdenv.isDarwin Security; <del> # thread 'main' panicked at 'Cannot ping mock server.: "cannot send request to mock server: cannot send request to mock server: failed to resolve host name"' # __darwinAllowLocalNetworking does not fix the panic doCheck = !stdenv.isDarwin; </del> meta = with lib; { description = "Generate Bazel BUILD files from Cargo dependencies"; homepage = "https://github.com/google/cargo-raze";

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: cargo-raze <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.12.0 desired version: 0.16.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers:
ty!
Change:
{ lib, stdenv, fetchurl, fetchpatch }: <del> let </del> <ins> stdenv.mkDerivation rec { pname = "cpio"; </ins> version = "2.13"; <del> name = "cpio-${version}"; in stdenv.mkDerivation { inherit name; </del> src = fetchurl { <del> url = "mirror://gnu/cpio/${name}.tar.bz2"; </del> <ins> url = "mirror://gnu/cpio/cpio-${version}.tar.bz2"; </ins> sha256 = "0vbgnhkawdllgnkdn6zn1f56fczwk0518krakz2qbwhxmv2vvdga"; }; <del> patches = [ (fetchpatch { name = "CVE-2021-38185.patch"; url = "https://git.savannah.gnu.org/cgit/cpio.git/patch/?id=dd96882877721703e19272fe25034560b794061b"; sha256 = "0vmr0qjwj2ldnzsvccl105ckwgx3ssvn9mp3f27ss0kiyigrzz32"; }) </del> <ins> patches = let fp = suffix: rev: sha256: fetchpatch { name = "CVE-2021-38185-${suffix}.patch"; url = "https://git.savannah.gnu.org/cgit/cpio.git/patch/?id=${rev}"; inherit sha256; }; in [ (fp "1" "dd96882877721703e19272fe25034560b794061b" "0vmr0qjwj2ldnzsvccl105ckwgx3ssvn9mp3f27ss0kiyigrzz32") (fp "2" "dfc801c44a93bed7b3951905b188823d6a0432c8" "1qkrhi3lbxk6hflp6w3h4sgssc0wblv8r0qgxqzbjrm36pqwxiwh") (fp "3" "236684f6deb3178043fe72a8e2faca538fa2aae1" "0pidkbxalpj5yz4fr95x8h0rizgjij0xgvjgirfkjk460giawwg6") </ins> ]; <del> preConfigure = if stdenv.isCygwin then '' </del> <ins> preConfigure = lib.optionalString stdenv.isCygwin '' </ins> sed -i gnu/fpending.h -e 's,include <stdio_ext.h>,,' <del> '' else null; </del> <ins> ''; </ins> enableParallelBuilding = true;

Discussion:
Practical consequence: with (this log snippet is cleaner thanks to ) I checked that it really is the patch by applying Some bugs are discussed in the upstream ML thread: I'm not sure about the best approach for us so far; the rebuild amounts complicate this. Perhaps just temporarily fixup the kernel build and get a properly fixed cpio with the next iteration? I expect that three to five upstream commits will be needed; maybe just the whole diff since the last release.
I think we should just fix this in master; the channel isn't going to advance anyway, and I'd rather not ship a known-buggy version of by fixing just the cpio used by the kernel. Is that reasonable?
Maybe the current channel version with public code-execution exploit (linked above) is a worse bug than this, but I don't know how commonly this bug manifests. ( channel has advanced, by the way)
Change:
nativeBuildInputs = [ pkg-config cmake ninja python3 wrapGAppsHook wrapQtAppsHook removeReferencesTo ]; buildInputs = [ <del> qtbase qtimageformats gtk3 libsForQt5.kwayland libsForQt5.libdbusmenu enchant2 lz4 xxHash dee ffmpeg openalSoft minizip libopus alsaLib libpulseaudio range-v3 tl-expected hunspell glibmm webkitgtk </del> <ins> qtbase qtimageformats gtk3 libsForQt5.kwayland libsForQt5.libdbusmenu lz4 xxHash ffmpeg openalSoft minizip libopus alsaLib libpulseaudio range-v3 tl-expected hunspell glibmm webkitgtk jemalloc rnnoise abseil-cpp extra-cmake-modules </ins> tg_owt # Transitive dependencies: pcre xorg.libpthreadstubs xorg.libXdmcp util-linux libselinux libsepol epoxy

Discussion:
, CVSSv3=5.3 (nixos-21.05, nixos-unstable) A reordering issue exists in Telegram before 7.8.1 for Android, Telegram before 7.8.3 for iOS, and Telegram Desktop before 2.8.8. An attacker can cause the server to receive messages in a different order than they were sent a client. Scanned versions: nixos-21.05: ; nixos-unstable: . Cc Cc Cc
Change:
container-linux-config-transpiler = callPackage ../development/tools/container-linux-config-transpiler { }; <ins> chkcrontab = callPackage ../tools/admin/chkcrontab { }; </ins> djmount = callPackage ../tools/filesystems/djmount { }; dgsh = callPackage ../shells/dgsh { };

Discussion:
It would be nice to see packaged such that at least an executable is exposed.
How about doing it yourself? Have a look at the and at the many examples in If you have questions, just ask them in this thread.
Change:
rm -rf $out/lib/openjdk/jre/bina ln -s $out/lib/openjdk/bin $out/lib/openjdk/jre/bin <ins> # Make sure cmm/*.pf are not symlinks: # https://youtrack.jetbrains.com/issue/IDEA-147272 rm -rf $out/lib/openjdk/jre/lib/cmm ln -s {$jre,$out}/lib/openjdk/jre/lib/cmm </ins> # Set PaX markings exes=$(file $out/lib/openjdk/bin/* $jre/lib/openjdk/jre/bin/* 2> /dev/null | grep -E 'ELF.*(executable|shared object)' | sed -e 's/: .*$//') echo "to mark: *$exes*"

Discussion:
Right now the IntelliJ derivation hardcodes oraclejdk8, and AFAICT the only way to override this choice is by overriding oraclejdk8 itself: (I have tried and with no effect.) Can we make this overridable somehow? (FWIW, I've had no problems with 15 and 15 EAP under openjdk8, although I'm getting redraw artifacts with 16 EAP.) cc
It was just recently changed away from that due to Idea having some bug with and not seeming very open to dealing with it. I can't find the ticket right now...
Oh
Okay, found the root cause of this bug. The crucial line is the following in (in openjdk): This checks that is indeed in , and guess what this returns with our symlink maze... As a temporary workaround you can set as an extra environment variable. This manages to hit the only special case in which doesn't have this check, and then intellij works fine with openjdk. Maybe I can draft a PR to fix this tomorrow.
Since the PR is merged, I assume this issue was just forgotten.
Change:
build = latest_build(channel) new_version = build["@version"] new_build_number = build["@fullNumber"] <del> if all(x not in channel["@name"] for x in ["EAP", "Gateway"]): </del> <ins> if "EAP" not in channel["@name"]: </ins> version_or_build_number = new_version else: version_or_build_number = new_build_number

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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! --- There is , which mentions that the "script still has issues with Gateway". A manual download of the updated Gateway does work. Updating this myself is a bit over the top of my head. There is an script involved, etc. If you prefer, please fill me in on how the pipeline works! 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.
Change:
- [Monado](https://monado.freedesktop.org/), an open source XR runtime. Available as [services.monado](#opt-services.monado.enable). <ins> - [intel-gpu-tools](https://drm.pages.freedesktop.org/igt-gpu-tools), tools for development and testing of the Intel DRM driver. Available as [hardware.intel-gpu-tools](#opt-hardware.intel-gpu-tools.enable) </ins> - [Pretix](https://pretix.eu/about/en/), an open source ticketing software for events. Available as [services.pretix](#opt-services.pretix.enable). - [microsocks](https://github.com/rofl0r/microsocks), a tiny, portable SOCKS5 server with very moderate resource usage. Available as [services.microsocks](#opt-services.microsocks.enable).

Discussion:
For Intel dGPUs, requires in order to access GPU utilization. Steps to reproduce the behavior: an Intel dGPU, such as the Arc A380 and the following relevant logs: This error should not happen, and should be able to read GPU utilization. ! As you can see, GPU utilization information is not being displayed. N.A. CC Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi It looks like there's an upstream issue tracking this: I'll look into this more to see how we can get this working, but I don't think this is something we can solve directly in the mangohud package. We'll need to use a separate NixOS module for since it'll require a security wrapper to enable . After creating a intel-gpu-tools module that sets the capabilities, I'm pretty sure we'll be able to get it working through something like this: but this would need to be used in addition to installing mangohud. Installing mangohud by itself wouldn't be enough.
Was able to get this working : Before | After ----------|--------- ! | ! Now just need to add this to a new module.
Change:
# following lines, double-check that your code behaves properly # when the number of layers equals: #      maxLayers-1, maxLayers, and maxLayers+1, 0 <del> store_layers="$( paths | jq -sR ' rtrimstr("n") | split("n") | (.[:$maxLayers-1] | map([.])) + [ .[$maxLayers-1:] ] | map(select(length > 0)) </del> <ins> paths | jq -sR ' rtrimstr("n") | split("n") | (.[:$maxLayers-1] | map([.])) + [ .[$maxLayers-1:] ] | map(select(length > 0)) </ins> '  <del> --argjson maxLayers "$availableLayers" )" </del> <ins> --argjson maxLayers "$availableLayers" > store_layers.json # The index on $store_layers is necessary because the --slurpfile # automatically reads the file as an array. </ins> cat ${baseJson} | jq ' . + { "store_dir": $store_dir, "from_image": $from_image, <del> "store_layers": $store_layers, </del> <ins> "store_layers": $store_layers[0], </ins> "customisation_layer", $customisation_layer, "repo_tag": $repo_tag, "created": $created } ' --arg store_dir "${storeDir}"  --argjson from_image ${if fromImage == null then "null" else "'"${fromImage}"'"}  <del> --argjson store_layers "$store_layers"  </del> <ins> --slurpfile store_layers store_layers.json  </ins> --arg customisation_layer ${customisationLayer}  --arg repo_tag "$imageName:$imageTag"  --arg created "$created" | tee $out ''; result = runCommand "stream-${baseName}" { inherit (conf) imageName;

Discussion:
fails with when building an image with many layers. is used to build a JSON containing the image layers, and those layers are passed to through the command line. At some point we're passing the max allowed argument list length resulting in the error. Steps to reproduce the behavior: A docker image is build successfully. Maintainer information:
Does this also happen with
It does not happen with . I created a patch (before I read your comment) to pass the layers via the store instead via the command line. I noticed does the same, except using the discouraged instead of . I submitted the patch anyway so we can fix this without waiting for to land.
Don't worry about the potential conflict. If you have that many layers, you'll probably benefit from . Would you be interested in contributing to that?
I thought so too, that's why I submitted it ;)
Oh :laughing: copy paste error. I intended to ask about .
I marked this as stale due to inactivity. &rarr;
Change:
<ins> diff --git a/vpn/openvpn/openvpnadvancedwidget.cpp b/vpn/openvpn/openvpnadvancedwidget.cpp index 2f11ba1d..310f11b4 100644 --- a/vpn/openvpn/openvpnadvancedwidget.cpp +++ b/vpn/openvpn/openvpnadvancedwidget.cpp @@ -75,7 +75,7 @@ OpenVpnAdvancedWidget::OpenVpnAdvancedWidget(const NetworkManager::VpnSetting::P connect(m_ui->cmbProxyType, static_cast<void (QComboBox::*)(int)>(&QComboBox::currentIndexChanged), this, &OpenVpnAdvancedWidget::proxyTypeChanged); // start openVPN process and get its cipher list -    const QString openVpnBinary = QStandardPaths::findExecutable("openvpn", QStringList() << "/sbin" << "/usr/sbin"); +    const QString openVpnBinary = "@openvpn@/bin/openvpn"; const QStringList ciphersArgs(QLatin1String("--show-ciphers")); const QStringList versionArgs(QLatin1String("--version")); </ins>

Discussion:
I am unable to configure the Cipher field of an openvpn connection in networkmanager. The dropdown is greyed out, with the text "OpenVPN cipher lookup failed". This causes problems because OpenVPN defaults to a very weak cipher (BF-CBC) that most modern vpn servers reject. On a system with set and plasma5 installed, use to create an openvpn connection. On the VPN tab of the connection editor, click Advanced..., and then click on the Security tab in the Advanced OpenVPN Properties window that pops up. The top item should read Cipher: and the dropdown will be greyed out with the error message mentioned above. ! System: NixOS 17.03 at Nix version: 1.11.8 Nixpkgs version:
temporary workaround: use to manually edit the property and add to it
Change:
changelog = "https://github.com/tectonic-typesetting/tectonic/blob/tectonic@${version}/CHANGELOG.md"; license = with licenses; [ mit ]; mainProgram = "tectonic"; <del> maintainers = with maintainers; [ lluchs doronbehar ]; </del> <ins> maintainers = with maintainers; [ lluchs doronbehar bryango ]; </ins> }; }

Discussion:
Describe the bug Reproduction  Expected behavior No errors Notify maintainers Metadata Maintainer information:
The version of biber that we ship corresponds to . ships with texlive 2018 (tectonic-typesetting/tectonic-staging). And doesn't yet have a builtin solution for biber tectonic-typesetting/tectonic. You can try overriding biber to version 2.11, which should be compatible. cc as maintainer of
I would also appreciate a fix for this. I tried overriding to version 2.11, but that didn't help (similar version incompatibility), at least not on the current unstable channel or on 20.03 to match with the date of message. The version in the current derivation seems to be 3.3, which dates back to 2016, so it looks like updating would make more sense.
I marked this as stale due to inactivity. &rarr;
I've just encountered this issue too.
Which version of nixpkgs are you using? What is the output of:
Currently biber expects while nixpkgs (as well as texlive) contains . For me the override suggested in works with no issue; e.g. with home-manager: Although this works on my end, I hope this could be upstreamed to nixpkgs itself so that we can make use of the hydra cache with no need to locally rebuild tectonic; cc maintainers: Thank you very much!
Tectonic is tracking this issue in . In general, we sort of rely on Tectonic's bundles to follow texlive releases. That's why we don't embed such hardcoding of the version in Tectonic - since Tectonic could update it's bundle without an update to Tectonic itself, which could fix such an issue if it arises after a Tectonic release. Perhaps also the following Tectonic nixpkgs update will help:
Indeed... Is it then possible to create some package without the dependency, so that we can install the appropriate versions of and separately, without the need to recompile the package? :thinking: Thanks!
You have a point. I was the one who introduced the wrapping of with in ... I tend to think now that it shouldn't be that way, especially with this frequent issue of incompatibility. I pushed that as well to .

Wow nice! Thank you very much!
I have hence created a wrapper so that one can combine the two into a single package, where the -specific biber is renamed to prevent conflict with the texlive biber: I am far from proficient in nix, so the package is created following along with the previous revision of . It can be used e.g. as an override: I don't know whether it's good to upstream this or not. In any case, I think it may be useful to others like me, so it would be good to share this here haha.
Update: I am now trying to upstream a more polished solution via . would you be interested in a review? :pleading_face: The PR will close this issue.
Change:
gtk3 json-glib libcacard <ins> libcap_ng </ins> libdrm libjpeg_turbo libopus

Discussion:
A regular update fails because apparently won't find the module: (edit: line-wrapped for clarity) Please run and paste the result.
now I see that this is fixed by . I did my search before, but I haven't seen that one.
This PR is already on nixos-unstable, but I still cannot compile :
I had the same problem and can still reproduce on master building with the flake:
We need this upstream patch: freedesktop/spice-common
fixed , not . , like , pulls in as a Git submodule.
I just tried bumping spice-gtk to version 0.40 locally (like suggested by ) and it indeed passes that "check for dependencies" phase of the build. It fails later on though for reasons that I'm not familiar enough with the build process to understand. With this patch: I get the following build log:
the issue is still persisting after 4 days :(
Not directly, it's fixed on master (and stable branches I guess, it builds on nixos-21.11 for example), but nixos-unstable can't catch up right now because of another completely unrelated issue, see .
Change:
, stdenv , rustPlatform , fetchFromGitHub <del> , xz , autoPatchelfHook }: </del> <ins> , fetchurl }: </ins> let <del> assets = import ./assets.nix { inherit lib stdenv fetchFromGitHub xz autoPatchelfHook; </del> <ins> nnueFile = "nn-6762d36ad265.nnue"; nnue = fetchurl { url = "https://tests.stockfishchess.org/api/nn/${nnueFile}"; sha256 = "0727dsxfpns9fkyir95fybibqmigk5h45k154b2c5rk5s9md6qk7"; </ins> }; in rustPlatform.buildRustPackage rec { pname = "fishnet"; <del> version = "2.2.6"; </del> <ins> version = "2.4.0"; </ins> src = fetchFromGitHub { owner = "niklasf"; repo = pname; rev = "v${version}"; <del> sha256 = "0dmc58wzv758b82pjpfzcfi0hr14hqcr61cd9v5xlgk5w78cisjq"; </del> <ins> sha256 = "sha256-1Gl2vJFn9yVYH62yBJefAOBX/jJaFAdSZj2Lj3imcps="; fetchSubmodules = true; </ins> }; <del> cargoSha256 = "1s37b0w1aav6gz399zncfp0zqh5sfy0zmabhl7n8p5cwlmlvnlsj"; preBuild = '' rmdir ./assets ln -snf ${assets}/${assets.relAssetsPath} ./assets </del> <ins> postPatch = '' cp -v '${nnue}' 'Stockfish/src/${nnueFile}' cp -v '${nnue}' 'Fairy-Stockfish/src/${nnueFile}' </ins> ''; <del> passthru.assets = assets; </del> <ins> cargoSha256 = "sha256-/s7Yyi2FUh+EDvgaHLgZ/FA6kk2FQrZr3L3B76fqTuc="; </ins> meta = with lib; { description = "Distributed Stockfish analysis for lichess.org";

Discussion:
fails to build as: Maintainer information:
fishnet-assets is archived; fishnet's builtin stockfish and fairy-stockfish are now submodules built from source. So I think we can just get rid of entirely. I think the only hard part is adjusting their build script so it doesn't try to download the NNUE file.
Change:
nativeBuildInputs = [ fontforge <del> (pythonFull.withPackages (ps: [ </del> <ins> (python3.withPackages (ps: [ </ins> ps.jinja2 ps.py3to2 ps.fonttools

Discussion:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency.

The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.