jiebi/CodeConvo huggingface dataset:
Change:
nativeBuildInputs = [ flex bison ]; <del> configureFlags = "--with-pcap=linux"; </del> <ins> # Apparently, 32 bit systems need this forced? Not verified if still needed. configureFlags = stdenv.lib.optionals (stdenv.system == "i686-linux") "--with-pcap=linux"; </ins> preInstall = ''mkdir -p $out/bin''; crossAttrs = { # Stripping hurts in static libraries dontStrip = true; <del> configureFlags = [ "--with-pcap=linux" "ac_cv_linux_vers=2" ]; </del> <ins> configureFlags = configureFlags ++ [ "ac_cv_linux_vers=2" ]; </ins> }; meta = {

Discussion:
The reason is that the linux pcap type is forced instead of auto-detected.
I tested it compile now works, but then I get now If I again try install I get only that error
builds fine for me on master, can you check whether you still get the "CYCLE" not found error?
The thing was an unrelated bug in Nix that was a while back.
Ok, thanks!
Change:
patches = [ # Patch version in CMakeLists.txt to 5.0.0 # The library author doesn't use cmake, so when updating this package please <del> # check that the resulting library extension matches the version # and remove/update this patch (resulting library name should match # libraylib.so.${finalAttrs.version} </del> <ins> # check that the resulting library extension matches the package version # and remove/update this patch </ins> (fetchpatch { url = "https://github.com/raysan5/raylib/commit/032cc497ca5aaca862dc926a93c2a45ed8017737.patch"; hash = "sha256-qsX5AwyQaGoRsbdszOO7tUF9dR+AkEFi4ebNkBVHNEY="; }) ]; <ins> # fix libasound.so/libpulse.so not being found appendRunpaths = [ (lib.makeLibraryPath (lib.optional alsaSupport alsa-lib ++ lib.optional pulseSupport libpulseaudio)) ]; </ins> meta = with lib; { description = "Simple and easy-to-use library to enjoy videogames programming"; homepage = "https://www.raylib.com/";

Discussion:
When using an application built against the raylib library on Linux, audio doesn't work. Steps to reproduce the behavior: When playing the game there should be audio. The game logs the following to the terminal, indicating it was unable to initialize the audio device: I played with a patched version of raylib to confirm that the game does indeed feature audio. The audio patch was removed in <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hey Emmanuel, Unfortunately I don't have any time to act as maintainer for Nix at the moment or in the foreseeable future.
OK, no problem The solution is known, but the question is whether anyone else can reproduce this. For what it's worh, I had the same issue with a non-raylib application which uses miniaudio.
Change:
stdenv.mkDerivation rec { pname = "xapps"; <del> version = "1.8.9"; </del> <ins> version = "2.0.6"; </ins> outputs = [ "out" "dev" ]; <del> patches = [ (fetchpatch { url = "https://github.com/linuxmint/xapp/pull/110/commits/208563d4e2bbcfbeb4425d05f649867065c37615.patch"; sha256 = "0brqndfgawhayrm36cjh6fkff274729jivjq3h5jx93lprvl2zih"; }) ]; </del> src = fetchFromGitHub { owner = "linuxmint"; repo = pname; rev = version; <del> sha256 = "01jx7612p0c0pi0r7fn5g08s6zjfmq1gfm5hi0fkzl0fxf2cx7a7"; </del> <ins> sha256 = "11qbz547qlfsvkz4bdxhryrsf10aw5jc2f1glbik7pvmmm87gf4f"; </ins> }; # TODO: https://github.com/NixOS/nixpkgs/issues/36468

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 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: xapps <!-- The current version can be found easily with the same process than 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: 1.8.9 desired version: 1.9.0 or newer <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Change:
streamlit = python3Packages.callPackage ../applications/science/machine-learning/streamlit { }; <ins> stt = callPackage ../tools/audio/stt { }; </ins> stuntrally = callPackage ../games/stuntrally { ogre = ogre1_9; mygui = mygui.override {

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 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: tts <!-- The current version can be found easily with the same process than 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.0.9 desired version: 0.0.11 maintainers: mozilla fired the team and they founded a new company to continue their work new releases can be found here
We are aware of the forks, we'll probably get to it before the branch-off. STT (DeepSpeech) was recently packaged, but does not build from source, so my interest in that package is limited.
Same also not a STT user.
can you update deepspeech to the new repo, call it stt and deprecate deepspeech? how to deprecate a package is documented here: please add a review. when anything is unclear, i would like to improve it
How about we call it instead?
i don't think that is very helpful for the end-user. the package name should match the upstream project name
do you want to update tts again?
Hello, just wanted to say that there has been a new release , in case someone wants to give it a shot.
Change:
stdenv.mkDerivation rec { pname = "bind"; <del> version = "9.18.24"; </del> <ins> version = "9.18.25"; </ins> src = fetchurl { url = "https://downloads.isc.org/isc/bind9/${version}/${pname}-${version}.tar.xz"; <del> hash = "sha256-cJ1zAjyRFd2tO6tltsjHmlkBltDRFPXQyiUz29Ut32Y="; </del> <ins> hash = "sha256-WkpwQyoz0Anw5unbsyiq56XidQfpjii/PAxrJQzLKrM="; </ins> }; outputs = [ "out" "lib" "dev" "man" "dnsutils" "host" ];

Discussion:
Please run and paste the result.
should I just wait until hydra will build it?
it fails for x86_64-linux in hydra too
why am I have 'bind' in system-path? I do not need in a local DNS-server...
made the temporary workaround with previous version:
The tests succeed for me locally but they are indeed fail on hydra. This failure is probably most detailed: Two failed tests: I remember both tests to fail in the past occasionally. I'll try to reproduce locally by building a few times. Does it fail reproducibly for you locally as well? Or sometimes it does pass?
Hydra succeeded after kicking it enough times. Maybe we should skip those tests if they are known flaky?
Yes it fail each time, and it was the same with 9.18.24 too
вот реально - зачем? )
You don't actually have bind, you have dnsutils, which is built from the same source and provides .
Thank you! Now I understand
Now I'm sure we can skip them or made them optional for bind users
So let's wait for next update, I'm closing this issue (cache have bin version now)
Weird - it passed for me on all platforms I tried too. We should probably deal with this before next update, because it will cause pain for nixpkgs developers, who frequently need to rebuild everything.
Change:
# vs libstdc++, etc.) since Darwin isn't `useLLVM` on all counts. (See # https://clang.llvm.org/docs/Toolchain.html for all the axes one might # break `useLLVM` into.) <del> + optionalString (isClang && gccForLibs != null </del> <ins> + optionalString (isClang </ins> && targetPlatform.isLinux && !(stdenv.targetPlatform.useAndroidPrebuilt or false) <del> && !(stdenv.targetPlatform.useLLVM or false)) '' </del> <ins> && !(stdenv.targetPlatform.useLLVM or false) && gccForLibs != null) '' </ins> echo "--gcc-toolchain=${gccForLibs}" >> $out/nix-support/cc-cflags ''

Discussion:
Describe the bug Cannot peer into when cross-compiling from a GCC build platfrom to an LLVM platform. Or I'm doing something wrong. To Reproduce Additional context Would be nice to inspect to build a compiler wrapper for Nim - Notify maintainers Metadata system: host os: multi-user?: sandbox: version:
FWIW I was able to work around this by late-binding the toolchain at build-time.
fixes the infinite recursion, though it's worth noting I had to modify the example:
Change:
<ins> { "url": "https://github.com/shnarazk/tree-sitter-bqn", "rev": "a90b371503f158699042423918e4c5e9285f5519", "date": "2023-10-12T14:03:08+09:00", "path": "/nix/store/l8jagwjzgm9kwgda2rqgkzxpszlmf6br-tree-sitter-bqn", "sha256": "0xma9dmz591xfy20g7sk535d5w21migs9zajjw2nd1c5czj00nzw", "hash": "sha256-/FsA5GeFhWYFl1L9pF+sQfDSyihTnweEdz2k8mtLqnY=", "fetchLFS": false, "fetchSubmodules": false, "deepClone": false, "leaveDotGit": false } </ins>

Discussion:
BQN grammar for tree-sitter <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mpl2 platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
extraPrefix = "src/3rdparty/"; hash = "sha256-s4GsGMJTBNWw2gTJuIEP3tqT82AmTsR2mbj59m2p6rM="; }) <ins> ./qtwebengine-link-pulseaudio.patch </ins> ] ++ lib.optionals stdenv.isDarwin [ ./qtwebengine-darwin-no-platform-check.patch ./qtwebengine-mac-dont-set-dsymutil-path.patch

Discussion:
I found this bug while trying to create a package for (mentioned in ), but it seems all qtwebengine-based browsers like Qutebrowser and Falkon have the same issue. These browsers are able to pick up my microphone just fine, but any virtual devices created via pipewire do not show up. discord-screenaudio creates a virtual source to pipe desktop audio through, which then is meant to be detected as an audio input inside a qtwebengine window linked to Creating virtual devices manually via (following ) also doesn't work, as they do not show up in Qutebrowser or Falkon. They do show up in Firefox, Chromium, and the native Discord client, however. pipewire running as the audio server a virtual audio device using to on Falkon or Qutebrowser and see that does not show up in the input list. does show up in Falkon or Qutebrowser One final difference I see is within the Helvum program, where I can see how audio devices are connected. When Firefox, Chromium and Discord use my microphone a connection is made in Helvum, but when Qutebrowser, Falkon, or discord-screenaudio do no connection is visible. To me it seems that qtwebengine-based browsers must not be connecting to pipewire or pipewire-pulse at all, but talking to the audio devices directly somehow. (qtwebengine) Please run and paste the result.
I'm unsure if I should also mention the maintainers of Falkon and Qutebrowser here since it seems the issue lies with qtwebengine
You should, I think it's safe to say qtwebengine is pretty much maintained for qutebrowser alone. I don't use pipewire/pulse but I think does.
Alright then: falkon's maintainer is other qutebrowser maintainers that have not been mentioned yet are
I do use pipewire, but not virtual audio devices. Have you ensured that you have xdg-desktop-portal-wlr setup correctly? I have to run this sequence of commands in order to get screensharing to work, for example: Where is set to Of course, if you are not using wayland then you'd want instead of
Weird. I'm on X11, not wayland.

I both wireplumber and xdg-desktop-portal via the nixos configuration options and it still doesn't make a difference, even when running those commands before running these browsers
Is xdg-desktop-portal required for pipewire audio support in qtwebengine?
I don't think so since the mic was working even when video capture is not (and the later does requre it). However there appears to have been a regression recently, I just bumped my pin just yesterday and now my mic is not working at all in qutebrowser.
Can you paste the code for creating the package you have so far?
This still seems like an issue, see further attempts at packaging discord-screenaudio in .
The issue has indeed been fixed!
Change:
importlib-resources ]; <del> patches = [ ./dvc-daemon.patch ]; postPatch = '' substituteInPlace setup.cfg  --replace "grandalf==0.6" "grandalf>=0.6" substituteInPlace dvc/daemon.py  --subst-var-by dvc "$out/bin/dcv" ''; </del> # Tests require access to real cloud services doCheck = false;

Discussion:
The dvc package is on version 0.24, but PyPI has version 0.87 with a bunch of new features. The old version can't handle new dvc files.
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Dunno if you are interested yet, but it is a hell of a dependency-chasing to compile it. I have four libraries to Python packages, and now I found my first transitive dependency.
Change:
nameValuePair "wireguard-${name}" { description = "WireGuard Tunnel - ${name}"; <del> requires = [ "network-online.target" ]; after = [ "network.target" "network-online.target" ]; </del> <ins> after = [ "network-pre.target" ]; wants = [ "network.target" ]; before = [ "network.target" ]; </ins> wantedBy = [ "multi-user.target" ]; environment.DEVICE = name; path = with pkgs; [ kmod iproute2 wireguard-tools ];

Discussion:
Hello, Current wireguard-wgXX.service dependencies are as follows: Now it depends on network- which I believe is wrong. The following is correct: These settings allow wgXX interface to be brought up just like others. The other services that depend on or network- can now use wgXX interfaces. Similarly the following in the PeerUnit can be altered by the following. evrim.
I have the same issue. My workaround is let the service using wireguard interface depend on the wireguard service.
Right, but then we'll have network-, network-, network- ...
Opened . You may be interested.
Change:
buildGoPackage rec { pname = "nomad"; <del> version = "0.10.5"; </del> <ins> version = "0.11.0"; </ins> rev = "v${version}"; goPackagePath = "github.com/hashicorp/nomad";

Discussion:
When building chromium through nixos-rebuild off of the latest nixpkgs master: Not sure what changed, I don't see any recent updates to heimdal or pthreads, but I may have missed something.
I updated nixpkgs and this issue seemed to disappear. I'll reopen if I encounter this again.
I got this today on master ():
Ah, I see (I assume because of patch dependencies). Testing with that commit reverted now.
It worked. Pushed to master.

it's supposed to be reachable via , from within emacs, but it is not. However, the program can find it, when run as
I misunderstood some emacs-related things. I'm not sure if the situation is perfect or not, but at least the manual I want is available at

We seem to have unpatched vulnerabilities (noticed by nixpkgs monitor):
The first one was explicitly claimed to be fixed in 2.21 NEWS, although the CVE entry claims that version still suffers from it.

Here's the error message: Here's the full log:
cc
My installation command was wrong. I had when I should have had
Change:
vendorSha256 = "sha256-RzAQnuOjT8eMH+rJm+/JrF96PZbCgzDVNPQYUeXPWnY="; <ins> ldflags = ["-X github.com/docker/compose/v2/internal.Version=${version}"]; </ins> doCheck = false; installPhase = '' install -D $GOPATH/bin/cmd $out/libexec/docker/cli-plugins/docker-compose

Discussion:
Starting with NixOS 21.11, ships with as a plugin by default. This plugin seems to be build in a way that it fails to report its version correctly, leading to problems when tools check its version. In particular, prints which appears to be a fallback value when the version is neither derived from a git tag nor injected by a build script. This behavior unfortunately breaks docker-compose based self-hosted sentry deployments, as sentry will check and, if the former doesn't work . Under NixOS 21.05, there is no , so this works fine, but in 21.11, it breaks because is not considered = 2. Steps to reproduce the behavior: should print from its , e.g. . After reading the , I have tried to fix the derivation by adding either or but that did not make any difference in the result. I feel like I don't know enough about go packaging to fix this myself. Please run and paste the result. Maintainer information:
Hello I think your second solution can work if you change it to: You can find it in the documentation:
should this be to the package in nixpkgs?
Thanks for the super quick response :) I just tried your suggestion and it does indeed work! I'd love to see this upstream and can make a PR
I will let you do it, if it's ok for you!
Change:
}; desktopItem = makeDesktopItem { <del> name = pname; exec = pname; icon = icon; </del> <ins> name = finalAttrs.pname; exec = finalAttrs.pname; icon = finalAttrs.icon; </ins> desktopName = "Stretchly"; genericName = "Stretchly"; categories = [ "Utility" ];

Discussion:
Package name: Stretchly Latest released version: 1.15.1 <!-- 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! --- 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]:
Change:
"pbr" "bfd" "fabric" <del> "mgmt" </del> ]; <del> allServices = services ++ [ "zebra" ]; </del> <ins> allServices = services ++ [ "zebra" "mgmt" ]; </ins> isEnabled = service: cfg.${service}.enable;

Discussion:
using frr-9.0.1 from nixos-23.11 results in failure of staticd.service: = true systemctl status staticd staticd used to work with option see Quick fix see below. maybe / want to insert themselves kindly into maintainers :-) system: host os: multi-user?: sandbox: version: channels(fd): channels(root): nixpkgs:
No, sorry. I'm a BIRD user, and I like it that way. Me writing that test and getting FRR over the finish line was some morbid curiosity. My only interest in FRR was bgp-evpn signaling fwiw.
Thanks even more for contributing! My quickfix for this issue is so far It seems, config file location with mgmtd is now instead of mgmtd is needed for staticd to get configured.
also mentions
yes, all daemons have as default config file, I'll try to adapt the nixos service accordingly to get rid of in all service definitions.
Please also test with: (should not have changed this).
Change:
mypaint-brushes = callPackage ../development/libraries/mypaint-brushes { }; <del> mythtv = libsForQt514.callPackage ../applications/video/mythtv { }; </del> <ins> mythtv = libsForQt5.callPackage ../applications/video/mythtv { }; </ins> micro = callPackage ../applications/editors/micro { };

Discussion:
MythTV current version 31.0 desired version 32.0 Note to maintainer I tried installing Mythtv 31.0 in the latest version of NixOS and the following error appeared. collect2: error: ld returned 1 exit status For full logs, run 'nix log /nix/store/i7hayl96078skrs46yksjqxjsh31cmfv-mythtv-'. Reading the log displayed error: experimental Nix feature 'nix-command' is disabled; use '--extra-experimental-features nix-command' to override
started working on this, bump for version is , but doesn't build yet on NixOS master branch. first quick look on the error tells something about FFmpeg and impure path (see below). I'll check this later as my first priority is getting it to build and run on NixOS 22.05 the log reading is a bit confusion, you have to append literally (). so your command from the example you provided would be
I am currently building MythTV 32.0 (sha256 = "0i4fs3rbk1jggh62wflpa2l03na9i1ihpz2vsdic9vfahqqjxff1") with two patches. The first is called : The second patch is called . I patched it up , and it looks like my patch has been . Here is that patch: My current derivation is like this: Sorry that was back in April and I didn't propagate my changes to NixOS yet!
it looks like your branch and mine are basically the same except for the . I don't know if it is better to add my patch, or for you to move to a version of MythTV after the pull mentioned above.
I didn't paste my whole , there are also new deps (soundtouch, libzip) which you can see in the branch by
I the patch on top of 's branch . I haven't tried building it yet since my machine is already building my original version of the derivation in the background (due to NixOS upgrade), and it takes hours. That is actually what prompted me to notice this issue :).
I'll try if my issue is gone with your patch now (I also need lots of time for one build).

Going forward I think it's best to use the release version of MythTV 32 and your patch for bumping the version in NixOS. I'll however try the other route with the MythTV version after the merge of your fix as I want to set up a combination of official and my own packages anyway.
I'm happy to confirm that both routes work. for the one with the updated MythTV version I took the commit of the pull request mentioned. would you be so kind and open a pull request for the version bump ?
Change:
stdenv.mkDerivation rec { pname = "sqlcipher"; <del> version = "4.4.0"; </del> <ins> version = "4.4.2"; </ins> src = fetchFromGitHub { owner = "sqlcipher"; repo = "sqlcipher"; rev = "v${version}"; <del> sha256 = "0mx0n5n3s39r25b31sdkrd4psxjqqgcv6rpm9d57w5rlk75g2fiv"; </del> <ins> sha256 = "0zhww6fpnfflnzp6091npz38ab6cpq75v3ghqvcj5kqg09vqm5na"; </ins> }; nativeBuildInputs = [ installShellFiles ];

Discussion:
, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: .
Change:
github = "ethindp"; githubId = 8030501; }; <ins> ethinx = { email = "eth2net@gmail.com"; github = "ethinx"; githubId = 965612; name = "York Wong"; }; </ins> Etjean = { email = "et.jean@outlook.fr"; github = "Etjean";

Discussion:
Steps to reproduce the behavior: The derivation failed to build on macOS at test stage Encounter this problem when build , as is the dependency. <!-- 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.