jiebi/CodeConvo huggingface dataset:
Change:
<del> { lib, stdenv, buildPecl, php, valgrind, pcre2, fetchFromGitHub }: </del> <ins> { lib , stdenv , buildPecl , php , valgrind , pcre2 , fetchFromGitHub }: </ins> let <del> version = "5.0.3"; </del> <ins> version = "5.1.2"; </ins> in buildPecl { inherit version; pname = "swoole";

Discussion:
Package name: Latest released version: 5.1.1 <!-- Search your package here: --- Current version on the unstable channel: 5.0.3 Current version on the stable/release channel: 5.0.3 <!-- 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! --- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Version 5.1.0 fixed compatibility of this extension with PHP 8.3, so the current version 5.0.3 is unusable with PHP 8.3. It outputs these build warnings/errors
Could you please provide the PR to update this? I think it's a matter of changing 2 lines. Actually, creating the PR would have been faster than creating this issue :)
Change:
(fetchNuGet { pname = "DotNet.ReproducibleBuilds"; version = "1.1.1"; sha256 = "0wa0xwbwv1lzjmqwg1vq06vrpb9kkbv3xw5nq50savj0dzhqakzq"; }) (fetchNuGet { pname = "Expecto"; version = "10.1.0"; sha256 = "127yy5i0p2lybhm5xcy2wa6j1rcahk61mb1nbym687b23pgizrq9"; }) (fetchNuGet { pname = "Expecto.Diff"; version = "9.0.4"; sha256 = "06g6nbr5kdr7hyayh24ry6xfghxpcfkqc8kma5qa5lcvhmy56f7j"; }) <del> (fetchNuGet { pname = "fake-cli"; version = "5.23.0"; sha256 = "1bmw5kyc9q1sqd08pamibgk0qm5xwylawc5nfrnfx3pl1pifd71y"; }) </del> (fetchNuGet { pname = "Fake.Api.GitHub"; version = "5.20.4"; sha256 = "1hgzqin7bm5fm0n97w7s9cq3zcxyncjmd6xk2da3p12wi7kghx0v"; }) (fetchNuGet { pname = "Fake.Core.CommandLineParsing"; version = "5.23.1"; sha256 = "10zlkri6w2xly19v4qqvg9vii5mjwbjqfynn525swzwyna9jws76"; }) (fetchNuGet { pname = "Fake.Core.Context"; version = "5.23.1"; sha256 = "1z3a77d53f5084sai9r9w9cdnyp4xn3x0262nhsi0znx52vizppl"; })

Discussion:
Package name: fsautocomplete Latest released version: Current version on the unstable channel: 0.67.0 Current version on the stable/release channel: nil <!-- 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! --- 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:
libcublas.lib # cublas libcusparse.dev # cusparse.h libcusparse.lib # cusparse <del> ] ++ lists.optionals (strings.versionOlder cudaVersion "11.8") [ </del> <ins> ] ++ lists.optionals (cudaOlder "11.8") [ </ins> cuda_nvprof.dev # <cuda_profiler_api.h> <del> ] ++ lists.optionals (strings.versionAtLeast cudaVersion "11.8") [ </del> <ins> ] ++ lists.optionals (cudaAtLeast "11.8") [ </ins> cuda_profiler_api.dev # <cuda_profiler_api.h> <del> ] ++ lists.optionals (strings.versionAtLeast cudaVersion "12.0") [ </del> <ins> ] ++ lists.optionals (cudaAtLeast "12.0") [ </ins> cuda_cccl.dev # <nv/target> ]) ++ lists.optionals rocmSupport [ rocmPackages.clr

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . python3Packages.torchvision maintainers cc: magma maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags:
This is also breaking atm
This shows that fortran name mangling is using the underscore ``. (See ) Magma should have the flag "-DADD" set during compilation to fix this
And, in fact, clmagma already sets :
Both of the following overlays fixed the problem: Specify the fortran name mangling convention To explain this, in , we see that if USEFORTRAN=off then the FORTRANCONVENTIONS flag is set and also copied to CFLAGS and CXXFLAGS. FORTRANCONVENTIONS is copied outside of this block into the NVCCFLAGS, and DEVCCFLAGS (which can't otherwise be set), so all three flags are necessary if we use the default of USE_FORTRAN=on. Disable fortran in magma
Nice! Would you be interested in turning that into a PR? It'd be great to fix on master!
Change:
description = "D-BUS Service"; serviceConfig = { Name = "net.connman.vpn"; <del> before = [ "connman" ]; </del> <ins> before = [ "connman.service" ]; </ins> ExecStart = "${cfg.package}/sbin/connman-vpnd -n"; User = "root"; SystemdService = "connman-vpn.service";

Discussion:
With the nixos system fails to build, with the following message: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
Caused by .
Change:
"runtime.win-x86.Microsoft.NETCore.DotNetHost"  "runtime.win-x86.Microsoft.NETCore.DotNetHostPolicy"  "runtime.win-x86.Microsoft.NETCore.DotNetHostResolver"  <del> "Microsoft.NETCore.App.Composite"  </del> "Microsoft.NETCore.App.Host.linux-musl-arm"  "Microsoft.NETCore.App.Host.osx-arm64"  "Microsoft.NETCore.App.Runtime.linux-musl-arm" 

Discussion:
Package name: , Latest released version: 8.0.100-preview.6..14 Current version on the unstable channel: 8.0.100-preview.5..2 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.
I have a PR for the other dotnet versions (), unfortunately the 8.0 version has problems with missing system nuget versions. Due to that I was planning on skipping this version (it's unstable and should not be dependended upon anyway). Are there any features in this new version that you consider important? I can try hacking up the update script in that case.
Change:
}; x86_64-linux = fetchurl { url = "https://zoom.us/client/${version}/zoom_x86_64.pkg.tar.xz"; <del> sha256 = "9gspydrGaEjzAM0nK1u0XNm07HTupJ2wnPxCFWy+Nts="; </del> <ins> sha256 = "8QIkF5+875VFoGK6T0CROsqML6bJDG934c1gkuz8Klk="; </ins> }; };

Discussion:
I notice zoom-us from nixpkgs-unstable gets killed by SIGILL shortly after the application window is shown. This does not occur when running zoom-us from NixOS 21.11. A strace ends with the following output: Observe that the zoom process is killed by SIGILL shortly after the application window is shown. The Zoom application proceeds to run without crashing. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I stepped through commits that touched zoom-us. The behavior appears to start with (no launch), resp. with (SIGILL observed).
I can‘t reproduce this issue, at least I get into a video call and to making faces at myself for a minute without issues. I am running zoom 5.10.4, on x86_64-linux with kernel 5.17.9.
I didn't see this on my system using the version from nixpkgs . It's expected that would not launch (it's fixed by the commits after). These should really have been one commit, or in another order to allow bisection, but oh well.
From what I can muster, SIGILL is caught while in It looks like is part of the binary distribution of Zoom and not built as part of nixpkgs? But I figure if can run it with no crash it’s more likely an application bug rather than some ABI issue?
I now notice that one Zoom invocation results in two coredumps. The other one is a SIGSYS arising from libc. I’m not really versed in such dark magics, but FWIW:
I really don't expect to be able to debug this, but could you post the output of and (and maybe if the output is short, particularly around the marker) from gdb on the SIGILL core? To me this really feels like a zoom problem. You don't happen to be using an ancient or unusual processor do you?
It looks like version 5.10.6 (3192) is out for linux now, so it might be worth trying that too.
Cheers, that seems to resolve the problem. Not really, it’s an i9-10885H. In case you’re still curious for whatever reason, I’ve attached the information copied from gdb.

Otherwise I’d say this issue is obsoleted by the new Zoom release. (NB just said “No function contains program counter for selected frame.”)
my zoom is dying too, I got it working for now with
Thanks, that's pretty interesting; something jumps into the middle of an instruction. Good that updating it works anyway.
Change:
}; }); <del> ## Upstreamed, awaiting a Hackage release singletons = overrideCabal super.singletons (drv: { ## Setup: Encountered missing dependencies: ## th-desugar ==1.7.* src = pkgs.fetchFromGitHub { owner  = "goldfirere"; repo   = "singletons"; rev    = "23aa4bdaf05ce025a2493b35ec3c26cc94e3fdce"; sha256 = "0hw12v4z8jxmykc3j8z6g27swmfpxv40bgnx7nl0ialpwbz9mz27"; }; }); </del> <ins> singletons = super.singletons_2_4_1; </ins> ## Upstreamed, awaiting a Hackage release tar = overrideCabal super.tar (drv: {

Discussion:
doesn't build on unstable. The root cause seems to be that 1.7 requires but ghc-8.4.1 only provides according to . run system: host os: multi-user?: sandbox: version: channels(chisui): channels(root): nixpkgs:
Only the 2.4 version of singletons works with GHC 8.4.1.
Than version should be changed from 2.3.1 to 2.4.
See
Change:
<ins> { config, lib, ... }: with lib; { ####### interface options = { hardware.onlykey = { enable = mkOption { type = types.bool; default = false; description = '' Enable OnlyKey device (https://crp.to/p/) support. ''; }; }; }; ## As per OnlyKey's documentation piece (hhttps://docs.google.com/document/d/1Go_Rs218fKUx-j_JKhddbSVTqY6P0vQO831t2MKCJC8), ## it is important to add udev rule for OnlyKey for it to work on Linux ####### implementation config = mkIf config.hardware.onlykey.enable { services.udev.extraRules = builtins.readFile ./onlykey.udev; }; } </ins>

Discussion:
The onlykey udev rule in is different from the one available on the onlykey documentation here The onlykey isn't recognized using the udev rules currently available on the nixpkgs tree. I don't know why the two rules are completely different... Maybe there are two different versions of the onlykey out there using different hardware? Anyway, my workaround to get the onlykey working: add the correct udev rule manually, by using the option in your
Looks like it has been mentioned in the original pull request without response from the OP: The changes appears to have been done in so maybe ask there.
I marked this as stale due to inactivity. &rarr;
Change:
liblastfmSF = callPackage ../development/libraries/liblastfmSF { }; <del> liblastfm = callPackage ../development/libraries/liblastfm { }; </del> <ins> liblastfm = libsForQt5.callPackage ../development/libraries/liblastfm { }; </ins> liblcf = callPackage ../development/libraries/liblcf { };

Discussion:
Describe the bug Since some day, clementine refuse to work. I bisected the error to the commit . The error message in the terminal is: realloc(): invalid pointer fish : Tâche , './result/bin/clementine' terminée par le signal SIGABRT (Abandon) To Reproduce go to a nixpkgs git tree Expected behavior clementine start as expected 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): channels(marius): nixpkgs: Maintainer information:
Looks like we are hitting here. cc
I could have sworn I tested this… let me see if I can reproduce this issue.
Yup, and reverting the projectm fix makes it run again. Hm… I was really sure I tested clementine. I don't think I'll have time to look into this properly until the weekend, so as a quick fix, you can revert the projectm update, if you want to.
Change:
nativeBuildInputs = [ makeWrapper pkgconfig ]; buildInputs = [ cmake git python3 python3Packages.lxml <del> glslang spirv-tools x11 libxcb libXrandr libXext wayland </del> <ins> glslang x11 libxcb libXrandr libXext wayland </ins> ]; enableParallelBuilding = true;

Discussion:
Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:
Change:
{ lib , buildPythonPackage <del> , fetchPypi </del> <ins> , fetchFromGitLab </ins> , lxml <del> , pytest </del> <ins> , pytestCheckHook , pythonOlder </ins> }: buildPythonPackage rec { <del> version = "1.0.1"; pname = "et_xmlfile"; </del> <ins> pname = "et-xmlfile"; version = "1.1"; format = "setuptools"; </ins> <del> src = fetchPypi { inherit pname version; sha256="0nrkhcb6jdrlb6pwkvd4rycw34y3s931hjf409ij9xkjsli9fkb1"; </del> <ins> disabled = pythonOlder "3.7"; src = fetchFromGitLab { domain = "foss.heptapod.net"; owner = "openpyxl"; repo = "et_xmlfile"; rev = version; hash = "sha256-MJimcnYKujOL3FedGreNpuw1Jpg48ataDmFd1qwTS5A="; </ins> }; <del> nativeCheckInputs = [ lxml pytest ]; checkPhase = '' py.test $out ''; </del> <ins> nativeCheckInputs = [ lxml pytestCheckHook ]; pythonImportsCheck = [ "et_xmlfile" ]; </ins> meta = with lib; { description = "An implementation of lxml.xmlfile for the standard library";

Discussion:
Package name: et_xmlfile Latest released version: 1.1.0 <!-- Search your package here: --- Current version on the unstable channel: 1.0.1 Current version on the stable/release channel: 1.0.1 <!-- 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! --- 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.
Looks like I'm not the maintainer of this package, but if you make a PR updating it feel free to ping me for review.
Change:
yojson ]; <ins> postInstall = '' wrapProgram $out/bin/docfd --prefix PATH : "${lib.makeBinPath [ pandoc poppler_utils ]}" ''; passthru.tests.version = testers.testVersion { package = docfd; }; </ins> meta = with lib; { description = "TUI multiline fuzzy document finder"; longDescription = '' <del> Think interactive grep for both text and other document files, but word/token based instead of regex and line based, so you can search across lines easily. Aims to provide good UX via integration with common text editors and other file viewers. Optional dependencies: fzf - for fuzzy file picker with "docfd ?". poppler_utils - for pdf search. pandoc - for .epub, .odt, .docx, .fb2, .ipynb, .html, & .htm files. </del> <ins> Think interactive grep for text and other document files. Word/token based instead of regex and line based, so you can search across lines easily. Aims to provide good UX via integration with common text editors and other file viewers. </ins> ''; homepage = "https://github.com/darrenldl/docfd"; license = licenses.mit;

Discussion:
Steps to reproduce the behavior: on x8664-darwin Package is a dependency of . Builds fine on linux and aarch64-darwin, just fails on x86_64-darwin. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
if you submit a patch, I will review it, but I don’t own any Darwin hardware to test…
Pinging to see if anyone can help on this issue as it's outside my area of expertise. Otherwise will mark which depends on this as broken for darwin x86_64. Many thanks!
Can test later, but it looks like there is a workaround for this exact error at
Thanks. I tried that flag earlier, which turns the error into a warning and allows to build (with warnings). But then when I try and build which depends on this I get linker errors,
and were in 11.0. It should use to override the stdenv to use the 11.0 SDK with an 11.0 deployment target. Edit: It uses , so probably something like (untested):
Many thanks, that worked! Much appreciated.

nix shell nixpkgs#docfd Wanted to try out but it failed to build. I noticed the package is not on the . Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi thanks for the report. I currently have a PR for version 4.0.0, but this same build error occurs there too, so it's unrelated to version. Strangely docfd builds fine on aarch64-darwin. The problem is with x8664-darwin, and specifically with the ocaml dependency which fails to build as your error message shows. I'm going to open an issue for that an ping the maintainer.
Change:
<section xml:id="ssec-language-ruby"><title>Ruby</title> <del> <para>For example, to package yajl-ruby package, use gem-nix:</para> </del> <ins> <para>There currently is support to bundle applications that are packaged as Ruby gems. The utility "bundix" allows you to write a <filename>Gemfile</filename>, let bundler create a <filename>Gemfile.lock</filename>, and then convert this into a nix expression that contains all Gem dependencies automatically.</para> <para>For example, to package sensu, we did:</para> </ins> <screen> <del> $ nix-env -i gem-nix $ gem-nix --no-user-install --nix-file=pkgs/development/interpreters/ruby/generated.nix yajl-ruby $ nix-build -A rubyPackages.yajl-ruby </del> <ins> <![CDATA[$ cd pkgs/servers/monitoring $ mkdir sensu $ cat > Gemfile source 'https://rubygems.org' gem 'sensu' $ bundler package --path /tmp/vendor/bundle $ $(nix-build '&nixpkgs>' -A bundix)/bin/bundix $ cat > default.nix { lib, bundlerEnv, ruby }: bundlerEnv { name = "sensu-0.17.1"; inherit ruby; gemfile = ./Gemfile; lockfile = ./Gemfile.lock; gemset = ./gemset.nix; meta = with lib; { description = "A monitoring framework that aims to be simple, malleable, and scalable."; homepage    = http://sensuapp.org/; license     = with licenses; mit; maintainers = with maintainers; [ theuni ]; platforms   = platforms.unix; }; }]]> </ins> </screen> <del> </section> </del> <ins> <para>Please check in the <filename>Gemfile</filename>, <filename>Gemfile.lock</filename> and the <filename>gemset.nix</filename> so future updates can be run easily. </para> </section> </ins> <section xml:id="ssec-language-go"><title>Go</title>

Discussion:
nixpkgs documentation is outdated: Announcement for new ruby infrastructure: I have one question: how do we handle packages that depend on a single rubt lib? See
Anything happenning here? Current state of affairs seems very frustrating to me from a user perspective.
cc
I'll be willing to help with bundix and ruby infrastructure tools if someone is willing to get me up to speed with this. cc
Hey, Here's a PR to bring back , along with my thoughts (and open questions) on the subject: I'm on - could we perhaps chat over IRC?
Is it the outdated documentation that's frustrating, or the requirement to use that you find frustrating? If it's the latter, why?
I linked to the mailing list announcement on page as a stop-gap.
I just worked with this yesterday and I'm happy to update the documentation to reflect that status quo. Not sure about the rubyLibs thing. Even if you depend on only a single package: using bundix is quite straight forward and there is no reason not to use it even in that situation. I'll try to work on this today.
Change:
./programs/npm.nix ./programs/noisetorch.nix ./programs/oblogout.nix <ins> ./programs/openvpn3.nix </ins> ./programs/pantheon-tweaks.nix ./programs/partition-manager.nix ./programs/plotinus.nix

Discussion:
Project description This is the next generation OpenVPN client for Linux. I am having issues connecting to my work OpenVPN server, everyone else that is connecting from linux succesfully is using this package homepage source URL: license: AGPL-3.0 License
I marked this as stale due to inactivity. &rarr;
Not stale.
Here is a draft at packaging, it only seems to work using latest unstable at the time of this comment: It's amazing how quickly these packagings accumulate hacks and seds and shebang patches
Change:
source-code-pro = callPackage ../data/fonts/source-code-pro {}; source-sans = callPackage ../data/fonts/source-sans { }; <ins> source-sans-pro = callPackage ../data/fonts/source-sans-pro { }; </ins> source-serif = callPackage ../data/fonts/source-serif { }; <ins> source-serif-pro = callPackage ../data/fonts/source-serif-pro { }; </ins> source-han-code-jp = callPackage ../data/fonts/source-han-code-jp { };

Discussion:
The font as installed by the package, is now called . This breaks all references to the font in documents, but also in web pages, etc. The font Open this webpage: The logo uses the Source Sans Pro font and it should look correct when the package is installed. Instead, it shows an alternative font with serif. The font should be called and not , keeping all references. If this was not desirable (because the font is just too different) then a package should be provided to install the old version with the old name. Please run and paste the result.
The upstream name change was intentional (adobe-fonts/source-serif).
Thank you andersk that explains a lot! I guess then it makes sense to also install the older version? Edit: or provide it as a separate package.
We should be able to deal with this through fontconfig.
If I understand correctly, it's not only the name that has been changed, but the renamed font has also different metrics. This means that if we just configure fontconfig to replace "Source Sans Pro" with "Source Sans 3", the layout of existing documents might change. So I think, it would make sense to either reintroduce Pro fonts as a separate package, or include the older (Pro) version together with the new one (which is what ). If is interested, I can turn , which does the former, to a PR.
I agree. Either of these two solutions would be satisfying to me.
I wasn't aware of the metrics changes. I think adding the older version back as a new package makes perfect sense, thank you!
Change:
# Wrap emacs and friends so they find our site-start.el before the original. for prog in $emacs/bin/*; do # */ local progname=$(basename "$prog") <del> local autoloadExpression="" </del> rm -f "$out/bin/$progname" <del> if [[ $progname == emacs ]]; then # progs other than "emacs" do not understand the `-l` switches autoloadExpression="-l cl-loaddefs -l nix-generated-autoload" fi </del> substitute ${./wrapper.sh} $out/bin/$progname  --subst-var-by bash ${emacs.stdenv.shell}  --subst-var-by wrapperSiteLisp "$deps/share/emacs/site-lisp"  --subst-var-by wrapperSiteLispNative "$deps/share/emacs/native-lisp:"  <del> --subst-var autoloadExpression  </del> --subst-var prog chmod +x $out/bin/$progname done

Discussion:
The file generated by the Emacs wrapper is redundant because the autoload definitions are already processed by the builtin : the is loaded after with the command line option , but loads the package autoloads before . We can understand this better by considering a few scenarios. If we start Emacs with disabled, then the autoloads will not be available in because is not loaded until later: If we modify the wrapper as in so that is not loaded, the autoloads will still be found as long as is enabled: is enough on its own to handle autoloads for the Emacs wrapper. Therefore, I propose to remove in favor of the builtin Emacs functionality.
Somehow, removing this broke from emacs-overlay. I have to manually run or anything depending on autoloaded tramp functions errors out with "no such function". I do disable as my site-lisp directory is managed by Nix. Is this configuration no longer recommended/supported? Is there a way to just engage 's autoload mechanism without allowing it to access the network or install packages?
I also fully disable since all of my emacs packages are installed via nix and noticed this change broke things for me. I'm interested in this as well. Edit: Maybe this: