jiebi/CodeConvo huggingface dataset:
Code change:
After babashka can't display Unicode characters I have a babashka script that outputs the following JSON: The text is a Nerd Font Symbol code point. After the output is: Steps to reproduce the behavior: This has been fixed in the past by I did not test other packages that could be affected by the PR.
Pretty sure this is related to this bug in GraalVM upstream: I am curious if this is affecting projects using GraalVM 21.0.0 vanilla or if not, how is it working and why it is broken in .
It does seem that even setting up inside the C compiler environment is not sufficient to make it work. CC to see if they have more context on what the possibly issue is.
I also hit this today. I tested the same version(v1.3.186) from upstream binary release, which does not have this issue. Shall we always sync the same version of graavm as upstream build ci?
I don't think this is the issue and even if it was, it is not like babashka is the only GraalVM package we have.
I know that folks can't reproduce this issue with upstream, but I also can't reproduce it with GraalVM using Java, e.g.: A patch if anyone wants to test to be applied to : So, can anyone reproduce this issue with GraalVM Native Image itself? If not, the only thing I can think is that the issue here is the GCC (i.e.: non-static) version (upstream compiles with by default). Or something else.
So I got this warning: But this was after already started to build, so I assume this is the same issue as and need to be fixed upstream.
To explain in more details why I think this is an upstream issue: I don't get the same in the initial part of the build, only when the build starts that I get this warning. So what I assume is doing: Running the CC (C Compiler) inside a shell with clean environment We see the , because this shell couldn't set the proper locale thanks to missing environment variables (e.g.: ) Since this shell environment has no environment variables (at least, not the environment variables that we need), this ends up breaking macOS compilation and locale (Unicode) support in Linux Not sure why it works in GraalVM itself though yet. This is all really strange.
While I'm not familiar with graalvm, I do find a hack for this issue, maybe can weigh in to test whether this hack is valid: Some inspiration from a random reddit post and those issues: And I do find it's using , so I thought if I those two into build args, maybe it'd work. And indeed it seems to work.. After I built bb with above args,
BTW, I cannot reproduce with GraalVM Native Image on helloworld java as well. Helloworld produced by GraalVM Native Image has correct unicode output.
Thanks for investigating this issue. Opened so we can have this fixed.

Related discussion:
text: ]; in stdenv.mkDerivation ({ <del> inherit dontUnpack LC_ALL jar; </del> <ins> inherit dontUnpack jar; </ins> nativeBuildInputs = (args.nativeBuildInputs or [ ]) ++ [ graalvmDrv glibcLocales ];
Code change:
Project description Python REPL plugin for automatic time tracking and metrics generated from your programming activity. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin, ...

Related discussion:
text: <ins> { lib , buildPythonPackage , pythonOlder , fetchPypi , ptpython , ipython , setuptools , setuptools-scm , setuptools-generate }: let pname = "repl-python-wakatime"; version = "0.0.6"; in buildPythonPackage { inherit pname version; format = "pyproject"; disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; hash = "sha256-s2UelniMn4+wWILbVIIKidRCFaOvo/nNNofA7yf2+9c="; }; nativeBuildInputs = [ setuptools setuptools-scm setuptools-generate ]; propagatedBuildInputs = [ ptpython ipython ]; pythonImportsCheck = [ "repl_python_wakatime" ]; meta = with lib; { description = "Python REPL plugin for automatic time tracking and metrics generated from your programming activity"; homepage = "https://github.com/wakatime/repl-python-wakatime"; license = licenses.gpl3Only; maintainers = with maintainers; [ jfvillablanca ]; }; } </ins>
Code change:
Project description Python REPL plugin for automatic time tracking and metrics generated from your programming activity. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin, ...

Related discussion:
text: repeated-test = callPackage ../development/python-modules/repeated-test { }; <ins> repl-python-wakatime = callPackage ../development/python-modules/repl-python-wakatime { }; </ins> repocheck = callPackage ../development/python-modules/repocheck { }; reportengine = callPackage ../development/python-modules/reportengine { };
Code change:
Package name: python311Packgaes.openrazer Latest released version: 3.6.1 <!-- Search your package here: --- Current version on the unstable channel: 3.5.1 Current version on the stable/release channel: 3.5.1 Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Last update pull request was made by: Note for maintainers: Please tag this issue in your PR.

Related discussion:
text: { lib , fetchFromGitHub }: rec { <del> version = "3.5.1"; </del> <ins> version = "3.6.1"; </ins> format = "setuptools"; src = fetchFromGitHub { owner = "openrazer"; repo = "openrazer"; rev = "v${version}"; <del> hash = "sha256-6YU2tl17LpDZe9pQ1a+B2SGIhqGdwME3Db6umVz7RLc="; </del> <ins> hash = "sha256-bboTRZqJq5tKeBQuiEQAXxTHYvoldDQlwbfehjDA8EE="; </ins> }; meta = with lib; {
Code change:
Looking at my filed ofborg does not ping in most cases. I am thinking of ofborg pings people, or the above command does not print (I guess) No response. No response.

Related discussion:
text: concatAttrLists = attrsets: zipAttrsWithNames (filterAttrNames isList (head attrsets)) (_: concatLists) attrsets; <del> template = rec { inherit pname version; </del> <ins> template = { </ins> nativeBuildInputs = [ pkg-config xfce4-dev-tools wrapGAppsHook ]; buildInputs = [ hicolor-icon-theme ]; configureFlags = [ "--enable-maintainer-mode" ];
Code change:
Looking at my filed ofborg does not ping in most cases. I am thinking of ofborg pings people, or the above command does not print (I guess) No response. No response.

Related discussion:
text: pos = builtins.unsafeGetAttrPos "pname" args; <del> passthru.updateScript = gitUpdater { inherit rev-prefix odd-unstable patchlevel-unstable; }; </del> <ins> passthru = { updateScript = gitUpdater { inherit rev-prefix odd-unstable patchlevel-unstable; }; } // passthru; </ins> meta = with lib; { homepage = "https://gitlab.xfce.org/${category}/${pname}"; license = licenses.gpl2Plus; # some libraries are under LGPLv2+ platforms = platforms.linux; <del> }; </del> <ins> } // meta; </ins> }; <del> publicArgs = removeAttrs args [ "category" "pname" "sha256" ]; </del> <ins> publicArgs = removeAttrs args [ "category" "sha256" ]; </ins> in <del> stdenv.mkDerivation (recursiveUpdate template publicArgs // concatAttrLists [ template args ]) </del> <ins> stdenv.mkDerivation (publicArgs // template // concatAttrLists [ template args ]) </ins> # TODO [ AndersonTorres ]: verify if it allows using hash attribute as an option to sha256
Code change:
Package name: rubberband Latest released version: 3.3.0 Current version on the unstable channel: 3.1.0 Current version on the stable/release channel: 3.1.0 Notify maintainers Note for maintainers: Please tag this issue in your PR.

Related discussion:
text: { lib, stdenv, fetchurl, pkg-config, libsamplerate, libsndfile, fftw <ins> , lv2, jdk </ins> , vamp-plugin-sdk, ladspaH, meson, ninja, darwin }: stdenv.mkDerivation rec { pname = "rubberband"; <del> version = "3.1.0"; </del> <ins> version = "3.3.0"; </ins> src = fetchurl { url = "https://breakfastquay.com/files/releases/${pname}-${version}.tar.bz2"; <del> sha256 = "sha256-uVp22lzbOWZ3DGARXs2Dj4QGESD4hMO/3JBPdZMeyao="; </del> <ins> hash = "sha256-2e+J4rjvn4WxOsPC+uww4grPLJ86nIxFzmN/K8leV2w="; </ins> }; <del> nativeBuildInputs = [ pkg-config meson ninja ]; buildInputs = [ libsamplerate libsndfile fftw vamp-plugin-sdk ladspaH ] ++ lib.optionals stdenv.isDarwin </del> <ins> nativeBuildInputs = [ pkg-config meson ninja jdk ]; buildInputs = [ libsamplerate libsndfile fftw vamp-plugin-sdk ladspaH lv2 ] ++ lib.optionals stdenv.isDarwin </ins> (with darwin.apple_sdk.frameworks; [Accelerate CoreGraphics CoreVideo]); makeFlags = [ "AR:=$(AR)" ]; <ins> # TODO: package boost-test, so we can run the test suite. (Currently it fails # to find libboost_unit_test_framework.a.) mesonFlags = [ "-Dtests=disabled" ]; doCheck = false; </ins> meta = with lib; { description = "High quality software library for audio time-stretching and pitch-shifting"; homepage = "https://breakfastquay.com/rubberband/";
Code change:
Project description A powerful testing framework for ZSH projects Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ...

Related discussion:
text: <ins> { lib, stdenvNoCC, fetchFromGitHub, zsh, revolver, installShellFiles, testers, nix-update-script, }: stdenvNoCC.mkDerivation (finalAttrs: { pname = "zunit"; version = "0.8.2"; src = fetchFromGitHub { owner = "zunit-zsh"; repo = "zunit"; rev = "v${finalAttrs.version}"; hash = "sha256-GkBewb795piCaniZJZpGEZFhKaNs8p8swV5z34OegPY="; deepClone = true; # Needed in order to get "tests" folder }; strictDeps = true; doCheck = true; doInstallCheck = true; nativeBuildInputs = [ zsh installShellFiles ]; nativeCheckInputs = [ revolver ]; buildInputs = [ zsh revolver ]; postPatch = '' for i in $(find src/ -type f -print); do substituteInPlace $i  --replace-warn " revolver " " ${lib.getExe revolver} " done ''; buildPhase = '' runHook preBuild zsh build.zsh runHook postBuild ''; checkPhase = '' runHook preCheck HOME="$TEMPDIR" zsh zunit runHook postCheck ''; installPhase = '' runHook preInstall install -Dm755 zunit $out/bin/zunit runHook postInstall ''; postInstall = '' installShellCompletion --cmd zunit --zsh zunit.zsh-completion ''; installCheckPhase = '' runHook preInstallCheck PATH=$PATH:$out/bin zunit --help runHook postInstallCheck ''; passthru = { tests.version = testers.testVersion { package = finalAttrs.finalPackage; }; updateScript = nix-update-script { }; }; meta = { description = "Powerful testing framework for ZSH projects"; homepage = "https://zunit.xyz/"; downloadPage = "https://github.com/zunit-zsh/zunit/releases"; license = lib.licenses.mit; mainProgram = "zunit"; inherit (zsh.meta) platforms; maintainers = with lib.maintainers; [ d-brasher ]; }; }) </ins>
Code change:
rendered in : ! bumping osl to did not work. Applying did not work <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: nixpkgs:
I have verified that the problem exists with the current derivation even with version , which was updated away from in . I guess somehow the ZLIB_VERSION is replaced improperly , but I've got no idea what could be causing it, and I'm really confused why it's only become a problem recently, as it doesn't look like osl has been touched in either.
I've tracked it down to , and reverting it seems to fix it. I also believe it's a cmake issue. Consider this file Output: Maybe because the header changed to (? But if I'm reading the correctly, I think it should just set the version to an empty string? Either way, this patch seems to fix it I don't think it's worth raising with zlib because with the next patch version they're going to fix it anyway. It might be worth warning them in advance of 1.4. It's probably worth raising with cmake, because they will want to support all version, and then zlib won't have to care anymore either. I can open a PR for this tomorrow or when I have time, but don't wait for me if anybody wants to do it before.
Nice catch! One minor note: you are looking at 's master branch. It seems to be already fixed there as: We'll need that backport to . UPDATE: or wait for to reach master. With now is in .

Related discussion:
text: in stdenv.mkDerivation rec { pname = "openshadinglanguage"; <del> version = "1.12.13.0"; </del> <ins> version = "1.12.14.0"; </ins> src = fetchFromGitHub { owner = "AcademySoftwareFoundation"; repo = "OpenShadingLanguage"; rev = "v${version}"; <del> hash = "sha256-EVV7YHovWwbRju+uv8IK2wpcpoK1ndZ8yNRHzU8LUuE="; </del> <ins> hash = "sha256-x8t7uC4q29MkTCIS1rK0ICw78u5zZG+/zyhwttLOBr4="; </ins> }; cmakeFlags = [
Code change:
rendered in : ! bumping osl to did not work. Applying did not work <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: nixpkgs:
I have verified that the problem exists with the current derivation even with version , which was updated away from in . I guess somehow the ZLIB_VERSION is replaced improperly , but I've got no idea what could be causing it, and I'm really confused why it's only become a problem recently, as it doesn't look like osl has been touched in either.
I've tracked it down to , and reverting it seems to fix it. I also believe it's a cmake issue. Consider this file Output: Maybe because the header changed to (? But if I'm reading the correctly, I think it should just set the version to an empty string? Either way, this patch seems to fix it I don't think it's worth raising with zlib because with the next patch version they're going to fix it anyway. It might be worth warning them in advance of 1.4. It's probably worth raising with cmake, because they will want to support all version, and then zlib won't have to care anymore either. I can open a PR for this tomorrow or when I have time, but don't wait for me if anybody wants to do it before.
Nice catch! One minor note: you are looking at 's master branch. It seems to be already fixed there as: We'll need that backport to . UPDATE: or wait for to reach master. With now is in .

Related discussion:
text: osl = libsForQt5.callPackage ../development/compilers/osl { boost = boost179; <ins> libclang = llvmPackages_15.libclang; clang = if stdenv.cc.libcxx != null then (overrideLibcxx llvmPackages_15.stdenv).cc else clang_15; llvm = llvm_15; </ins> }; osqp = callPackage ../development/libraries/science/math/osqp { };
Code change:
Package name: raysession Latest released version: 0.14.2 Current version on the unstable channel: 0.13.1 Current version on the stable/release channel: 0.13.1 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Update PR:

Related discussion:
text: <del> { lib, fetchurl, buildPythonApplication, libjack2, pydbus, pyliblo, pyqt5, which, bash, qt5 }: </del> <ins> { lib, fetchurl, buildPythonApplication, libjack2, pyliblo, pyqt5, which, bash, qt5 }: </ins> buildPythonApplication rec { pname = "raysession"; <del> version = "0.13.1"; </del> <ins> version = "0.14.2"; </ins> src = fetchurl { url = "https://github.com/Houston4444/RaySession/releases/download/v${version}/RaySession-${version}-source.tar.gz"; <del> sha256 = "sha256-iiFRtX43u9BHe7a4ojza7kav+dMW9e05dPi7Gf9d1GM="; </del> <ins> sha256 = "sha256-qEN3zBK/goRLIZaU06XXm8H5yj4Qjj/NH+bkHkjhLaw="; </ins> }; postPatch = ''
Code change:
Package name: raysession Latest released version: 0.14.2 Current version on the unstable channel: 0.13.1 Current version on the stable/release channel: 0.13.1 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Update PR:

Related discussion:
text: qt5.wrapQtAppsHook ]; buildInputs = [ libjack2 bash ]; <del> propagatedBuildInputs = [ pydbus pyliblo pyqt5 ]; </del> <ins> propagatedBuildInputs = [ pyliblo pyqt5 ]; </ins> dontWrapQtApps = true; # The program is a python script.
Code change:
A NAT port forwarding rule fails to build with nftables when ranges are used. This is also the entirety of nix log /nix/store/sir8pvbk65zk4j6rqcj8sgwi0y78s3kc-nftables- Steps to reproduce the behavior: The nfables-rules derivation should compile. Using a single port rule, or disabling nftables results in a successful build. Please run and paste the result.

Related discussion:
text: <del> { config, lib, pkgs, ... }: </del> <ins> { config, lib, ... }: </ins> with lib;
Code change:
A NAT port forwarding rule fails to build with nftables when ranges are used. This is also the entirety of nix log /nix/store/sir8pvbk65zk4j6rqcj8sgwi0y78s3kc-nftables- Steps to reproduce the behavior: The nfables-rules derivation should compile. Using a single port rule, or disabling nftables results in a successful build. Please run and paste the result.

Related discussion:
text: mkTable = { ipVer, dest, ipSet, forwardPorts, dmzHost }: let <del> # nftables does not support both port and port range as values in a dnat map. # e.g. "dnat th dport map { 80 : 10.0.0.1 . 80, 443 : 10.0.0.2 . 900-1000 }" # So we split them. fwdPorts = filter (x: length (splitString "-" x.destination) == 1) forwardPorts; fwdPortsRange = filter (x: length (splitString "-" x.destination) > 1) forwardPorts; </del> # nftables maps for port forward # l4proto . dport : addr . port <del> toFwdMap = forwardPorts: toNftSet (map </del> <ins> fwdMap = toNftSet (map </ins> (fwd: with (splitIPPorts fwd.destination); "${fwd.proto} . ${toNftRange fwd.sourcePort} : ${IP} . ${ports}" ) forwardPorts); <del> fwdMap = toFwdMap fwdPorts; fwdRangeMap = toFwdMap fwdPortsRange; </del> # nftables maps for port forward loopback dnat # daddr . l4proto . dport : addr . port <del> toFwdLoopDnatMap = forwardPorts: toNftSet (concatMap </del> <ins> fwdLoopDnatMap = toNftSet (concatMap </ins> (fwd: map (loopbackip: with (splitIPPorts fwd.destination);
Code change:
A NAT port forwarding rule fails to build with nftables when ranges are used. This is also the entirety of nix log /nix/store/sir8pvbk65zk4j6rqcj8sgwi0y78s3kc-nftables- Steps to reproduce the behavior: The nfables-rules derivation should compile. Using a single port rule, or disabling nftables results in a successful build. Please run and paste the result.

Related discussion:
text: ) fwd.loopbackIPs) forwardPorts); <del> fwdLoopDnatMap = toFwdLoopDnatMap fwdPorts; fwdLoopDnatRangeMap = toFwdLoopDnatMap fwdPortsRange; </del> # nftables set for port forward loopback snat # daddr . l4proto . dport
Code change:
A NAT port forwarding rule fails to build with nftables when ranges are used. This is also the entirety of nix log /nix/store/sir8pvbk65zk4j6rqcj8sgwi0y78s3kc-nftables- Steps to reproduce the behavior: The nfables-rules derivation should compile. Using a single port rule, or disabling nftables results in a successful build. Please run and paste the result.

Related discussion:
text: type nat hook prerouting priority dstnat; ${optionalString (fwdMap != "") '' <del> iifname "${cfg.externalInterface}" dnat meta l4proto . th dport map { ${fwdMap} } comment "port forward" ''} ${optionalString (fwdRangeMap != "") '' iifname "${cfg.externalInterface}" dnat meta l4proto . th dport map { ${fwdRangeMap} } comment "port forward" </del> <ins> iifname "${cfg.externalInterface}" meta l4proto { tcp, udp } dnat meta l4proto . th dport map { ${fwdMap} } comment "port forward" </ins> ''} ${optionalString (fwdLoopDnatMap != "") '' <del> dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatMap} } comment "port forward loopback from other hosts behind NAT" ''} ${optionalString (fwdLoopDnatRangeMap != "") '' dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatRangeMap} } comment "port forward loopback from other hosts behind NAT" </del> <ins> meta l4proto { tcp, udp } dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatMap} } comment "port forward loopback from other hosts behind NAT" </ins> ''} ${optionalString (dmzHost != null) ''
Code change:
A NAT port forwarding rule fails to build with nftables when ranges are used. This is also the entirety of nix log /nix/store/sir8pvbk65zk4j6rqcj8sgwi0y78s3kc-nftables- Steps to reproduce the behavior: The nfables-rules derivation should compile. Using a single port rule, or disabling nftables results in a successful build. Please run and paste the result.

Related discussion:
text: type nat hook output priority mangle; ${optionalString (fwdLoopDnatMap != "") '' <del> dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatMap} } comment "port forward loopback from the host itself" ''} ${optionalString (fwdLoopDnatRangeMap != "") '' dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatRangeMap} } comment "port forward loopback from the host itself" </del> <ins> meta l4proto { tcp, udp } dnat ${ipVer} daddr . meta l4proto . th dport map { ${fwdLoopDnatMap} } comment "port forward loopback from the host itself" </ins> ''} } '';
Code change:
H.264 videos and specifically those (WebM and Theora are fine) don't play, which means that videos on Facebook and Twitter (at least) report an error. There are instructions for getting a patched version of the ffmpeg lib installed into your home folder which works, but ideally wouldn't be needed: to that the H.264 video don't work but the others do. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
What browser are you using? Works on Chromium, Firefox and qutebrowser (qtwebkit) on master for me.
Vivaldi, hence the title of the issue...
Oh, sorry, didn't know there's a browser called vivaldi.

Related discussion:
text: lihop = "Leroy Hopson <nixos@leroy.geek.nz>"; linquize = "Linquize <linquize@yahoo.com.hk>"; linus = "Linus Arver <linusarver@gmail.com>"; <ins> lluchs = "Lukas Werling <lukas.werling@gmail.com>"; </ins> lnl7 = "Daiderd Jordan <daiderd@gmail.com>"; loskutov = "Ignat Loskutov <ignat.loskutov@gmail.com>"; lovek323 = "Jason O'Conal <jason@oconal.id.au>";
Code change:
H.264 videos and specifically those (WebM and Theora are fine) don't play, which means that videos on Facebook and Twitter (at least) report an error. There are instructions for getting a patched version of the ffmpeg lib installed into your home folder which works, but ideally wouldn't be needed: to that the H.264 video don't work but the others do. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
What browser are you using? Works on Chromium, Firefox and qutebrowser (qtwebkit) on master for me.
Vivaldi, hence the title of the issue...
Oh, sorry, didn't know there's a browser called vivaldi.

Related discussion:
text: , gstreamer, gst-plugins-base, libxml2 , glib, gtk3, pango, gdk_pixbuf, cairo, atk, gnome3 , nss, nspr <del> , patchelf </del> <ins> , patchelf, makeWrapper , proprietaryCodecs ? true, vivaldi-ffmpeg-codecs ? null </ins> }: stdenv.mkDerivation rec { name = "${product}-${version}"; product = "vivaldi"; <del> version = "1.10.867.38-1"; </del> <ins> version = "1.10.867.48-1"; </ins> src = fetchurl { url = "https://downloads.vivaldi.com/stable/${product}-stable_${version}_amd64.deb"; <del> sha256 = "1h3iygzvw3rb5kmn0pam6gqy9baq6l630yllff1vnvychdg8d9vi"; </del> <ins> sha256 = "1han45swvv0y2i2kg7xhml1wj5zyrf2c2hc5b07kqsjkfg9iz1lc"; </ins> }; unpackPhase = ''
Code change:
H.264 videos and specifically those (WebM and Theora are fine) don't play, which means that videos on Facebook and Twitter (at least) report an error. There are instructions for getting a patched version of the ffmpeg lib installed into your home folder which works, but ideally wouldn't be needed: to that the H.264 video don't work but the others do. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
What browser are you using? Works on Chromium, Firefox and qutebrowser (qtwebkit) on master for me.
Vivaldi, hence the title of the issue...
Oh, sorry, didn't know there's a browser called vivaldi.

Related discussion:
text: tar -xvf data.tar.xz ''; <del> nativeBuildInputs = [ patchelf ]; </del> <ins> nativeBuildInputs = [ patchelf makeWrapper ]; </ins> buildInputs = [ stdenv.cc.cc stdenv.cc.libc zlib libX11 libXt libXext libSM libICE libxcb