jiebi/CodeConvo huggingface dataset:
Change:
owner = "Backblaze"; repo = "b2-sdk-python"; rev = "refs/tags/v${version}"; <del> hash = "sha256-xBLMvH51zbrSuBOtMxLeQJt7Wv31OcxBbD72EuLHzuU="; </del> <ins> hash = "sha256-eMFgsjEb0DMTLqG+8IZru1dEAuKZW4dEszrznZxR+mc="; </ins> }; nativeBuildInputs = [

Discussion:
Steps to reproduce the behavior: on <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- I don't have a machine, the failure is discovered by ofborg. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Closed by
No, that fixes runtime issue . Darwin still has failing tests
Change:
, gnome , gobject-introspection , intltool <ins> , libnotify </ins> , pavucontrol , python3Packages , util-linux

Discussion:
I get an error message when trying to exectute the autostart dektop file . Steps to reproduce the behavior: results Desktop file should be runnable without any problem. I ran into this because I wanted to autostart all my applications that follow the xdg-autostart specification. For this, I used the program dex. When it tried to autostart all the applications following xdg-autostart, it got this error when it tried to start everything. Additional thoughts Should the two autostart files really be enabled by default, without any option to turn them off? Maybe add a NixOS module with the option to enable the two desktop file separately and default to have them disabled? Because I do not think installing a package should automatically autostart a program, just because the system is following xdg-autostart. <!-- 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. `
Should have been fixed by
Change:
<del> { lib, stdenv, fetchurl </del> <ins> { lib , stdenv , fetchhg , autoreconfHook </ins> , fltk <ins> , libXcursor , libXi , libXinerama , libjpeg , libpng , mbedtls </ins> , openssl <del> , libjpeg, libpng </del> , perl <del> , libXcursor, libXi, libXinerama }: </del> <ins> , pkg-config , which }: </ins> <del> stdenv.mkDerivation rec { version = "3.0.5"; </del> <ins> stdenv.mkDerivation { </ins> pname = "dillo"; <ins> version = "unstable-2021-02-09"; </ins> <del> src = fetchurl { url = "https://www.dillo.org/download/${pname}-${version}.tar.bz2"; sha256 = "12ql8n1lypv3k5zqgwjxlw1md90ixz3ag6j1gghfnhjq3inf26yv"; </del> <ins> src = fetchhg { url = "https://hg.sr.ht/~seirdy/dillo-mirror"; rev = "67b70f024568b505633524be61fcfbde5337849f"; sha256 = "sha256-lbn5u9oEL0zt9yBhznBS9Dz9/6kSwRDJeNXKEojty1g="; </ins> }; <del> buildInputs = with lib; [ perl fltk openssl libjpeg libpng libXcursor libXi libXinerama ]; </del> <ins> nativeBuildInputs = [ autoreconfHook pkg-config which ]; buildInputs = [ fltk libXcursor libXi libXinerama libjpeg libpng mbedtls openssl perl ]; </ins> # Workaround build failure on -fno-common toolchains: #   ld: main.o:/build/dillo-3.0.5/dpid/dpid.h:64: multiple definition of `sock_set'; #     dpid.o:/build/dillo-3.0.5/dpid/dpid.h:64: first defined here NIX_CFLAGS_COMPILE = "-fcommon"; <del> configureFlags = [ "--enable-ssl" ]; </del> <ins> configureFlags = [ "--enable-ssl=yes" ]; </ins> meta = with lib; { <del> homepage = "https://www.dillo.org/"; </del> <ins> homepage = "https://hg.sr.ht/~seirdy/dillo-mirror"; </ins> description = "A fast graphical web browser with a small footprint"; longDescription = '' Dillo is a small, fast web browser, tailored for older machines. ''; maintainers = [ maintainers.AndersonTorres ]; platforms = platforms.linux; <del> license = licenses.gpl3; </del> <ins> license = licenses.gpl3Plus; </ins> }; }

Discussion:
Describe the bug Despite the derivation adding the flag '--enable-ssl' to the ./configure invocation dillo is not able to access site served via https:// To Reproduce Steps to reproduce the behavior: dillo to access Expected behavior Either dillo should not be compiled with the --enable-ssl flag or dillo should be able to access sites served with https Additional context This seems to be a common issue with dillo. Applying provided by the Debian packaging team solves this issue. My attempt to fix this. Metadata Maintainer information:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
This is old! Unfortunately I was not pinged on that time, however I have fixed it today.
Change:
# hledger* overrides inherit ( let <del> installHledgerExtraFiles = overrideCabal (drv: { </del> <ins> installHledgerExtraFiles = manpagePathPrefix: overrideCabal (drv: { </ins> buildTools = drv.buildTools or [] ++ [ pkgs.buildPackages.installShellFiles ]; postInstall = '' for i in $(seq 1 9); do <del> installManPage *.$i </del> <ins> installManPage ./${manpagePathPrefix}/*.$i </ins> done <del> install -v -Dm644 *.info* -t "$out/share/info/" </del> <ins> install -v -Dm644 ./${manpagePathPrefix}/*.info* -t "$out/share/info/" </ins> if [ -e shell-completion/hledger-completion.bash ]; then installShellCompletion --name hledger shell-completion/hledger-completion.bash

Discussion:
Running the package fails, apparently because it uses as input instead of as would be required to run:
Change:
<ins> { stdenv, lib, fetchurl, dpkg, autoPatchelfHook, dbus }: stdenv.mkDerivation rec { pname = "cloudflare-warp"; version = "2022.02.24"; src = fetchurl { url = "https://pkg.cloudflareclient.com/uploads/cloudflare_warp_2022_2_288_1_amd64_a0be7b47b3.deb"; sha256 = "sha256-gBXF0EfFMT6BC6ts/6PQYJH3AAQSDsFoZGK3RZIqmOA="; }; nativeBuildInputs = [ dpkg autoPatchelfHook ]; buildInputs = [ dbus ]; dontBuild = true; dontConfigure = true; unpackPhase = '' dpkg-deb -x ${src} ./ ''; installPhase = '' runHook preInstall mv usr $out mv lib $out mv bin $out runHook postInstall ''; postInstall = '' substituteInPlace $out/lib/systemd/system/warp-svc.service  --replace "ExecStart=" "ExecStart=$out" ''; meta = with lib; { description = "Replaces the connection between your device and the Internet with a modern, optimized, protocol"; homepage = "https://pkg.cloudflareclient.com/packages/cloudflare-warp"; license = licenses.unfree; maintainers = with maintainers; [ wolfangaukang ]; platforms = [ "x86_64-linux" ]; }; } </ins>

Discussion:
Project description An official Desktop Client for WARP was recently released by Cloudflare but is only for Debian and CentOS based distros. Metadata homepage URL: license: Unfree platforms: linux
I created the PR, but I need someone to test it, as I really can't ensure how this works, and don't want to push something that might not work while I am the maintainer (unless someone wants to take it :) )
Upon running as per the instructions given in I get the error: After googling I find that we also need to enable the warp-svc service ] but on running I get this log It tries to look for a file in the directory but is unable to find that. After running it writes those config files to the directory and it seems to work since running shows that . A nice addition would be that since this has a systemd service this would become very convenient to use if packaged as a NixOS module. Thanks
Yeah, in fact when trying to set this up, I stumbled with these modules and for a moment thought that was the best course of action for this package, as it definitely is a service that would be more interesting to be enabled through config than downloaded through Nixpkgs (like right now). Thank you very much for testing :)
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
#!/usr/bin/env bash <del> version="2.7.0" </del> <ins> version="2.8.0" </ins> bucket="https://storage.googleapis.com/tensorflow"

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking python3Packages.tensorflow-bin. python3Packages.tensorflow-bin maintainers cc: python39Packages.tensorflow maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
I'm not quite sure why this doesn't have the same internal tag as they seem to be the same AFAICT.
oh I see... the hashes in /nix/store/[hash]-pname-version for each of the dependencies changed. hmmmm
Change:
./programs/kclock.nix ./programs/kdeconnect.nix ./programs/lazygit.nix <ins> ./programs/kubeswitch.nix </ins> ./programs/less.nix ./programs/liboping.nix ./programs/light.nix

Discussion:
Kubeswitch requires both the binary and a script Steps to reproduce the behavior: kubeswitch to use Kubeconfig is set as intended only adds the binary, not the script itself. On the other hand, I'm not using nix directly but via fleek.
Hey happy first issue! About the kubeswitch, indeed, I did make this mistake as I am using it on my work machine which is not NixOS and I had done the standard installation in the past, so I got the binary from Nix, but not the script. Honestly, I need time and a little bit of searching on how to handle scripts, as I have only messed with Go or Python packages (which have a nice interface, BTW).
This will help fix it.
I did not test, but thanks. are you willing to do fix it?
Hi, sorry I want to but do not have much time recently.
Change:
, qtx11extras , libxcb , libXdmcp <ins> , qtbase </ins> }: mkDerivation rec {

Discussion:
Describe the bug fcitx5 does not emerge after pressed <kbdCtrl</kbd+ <kbdSpace</kbdin qt applications. Relevant information from : Additional context IIUC, fcitx5-qt should provide as a qt plugin. However, the current output does not contain this file: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(berberman): channels(root): nixpkgs: Maintainer information:
Change:
<ins> let pkgs = import <nixpkgs> { }; in with import <nixpkgs/nixos/lib/testing.nix> { inherit pkgs; system = builtins.currentSystem; }; with pkgs.lib; makeTest { name = "pg-initdb"; machine = {...}: { documentation.enable = false; services.postgresql.enable = true; services.postgresql.package = pkgs.postgresql_9_6; environment.pathsToLink = [ "/share/postgresql" ]; }; testScript = '' $machine->start; $machine->succeed("sudo -u postgres initdb -D /tmp/testpostgres2"); $machine->shutdown; ''; } </ins>  No newline at end of file

Discussion:
Calling doesn't seem to work from the command line: But using the full path of the symlink directly, it works: I think it's because resolves to and it tries to find by doing to . Nixpkgs version:
mutters something about being the devil does it work inside ?
I'm not sure what to try exactly here, this is a nixops deployed machine.
Not sure if this helps you much, but this seems to work with postgresql 9.6.
Since it works for 9.6, can we close this issue?
This is not fixed with 9.6; I have just tested it with on 18.03 and the error exists exactly as before. How did you run your commands to see it working?
Hi Actually, with further investigation I find that this is due to the setting being different on the two systems that I tested. Workaround 1: Workaround 2: add to the nixos configuration.
Hmm interesting. So is there some change to the package that we could make to tell it the equivalent of what does, so that just running works out of the box, as other commands in do?
Made a test for this: After it is now possible to link only PG dir (and not whole ). However I don't quite understand why isn't linked by default. When is installed through , all works because is at correct place. I'll prepare PR
Has this regressed on NixOS 23.05? There is no postgresql directory in /run/current-system/sw/share on my system suddenly.
Change:
./services/misc/ripple-data-api.nix ./services/misc/rippled.nix ./services/misc/rmfakecloud.nix <ins> ./services/misc/rkvm.nix </ins> ./services/misc/rshim.nix ./services/misc/safeeyes.nix ./services/misc/sdrplay.nix

Discussion:
Project description It's like synergy or barrier, but supports wayland and windows as well. I started packaging it , but it doesn't build yet ( fails to find the evdev files it wants). Metadata homepage URL: source URL: license: mit platforms: linux
here's the build log so far:
well, this is probably the issue: I'll file an issue.
If this is the only issue you can probably patch it like this: And during phrase you can use or to substitute with . Should work.
Good idea. Another weird one popped out though: Not sure what's up, since libevdev does not seem to actually come with that header file included... and from what I can tell ubuntu's libevdev-dev packages don't either??
Weird, debian's libevdev-dev pkg:
Looks like I misunderstood. I think they bundle their input.h for building their lib, but expect to be providing , so I'm adding that to the clang_args too...
Okay, update: error:
I marked this as stale due to inactivity. &rarr;
build: please see:
What's the status on this, doesn't look like it's made it into the binary cache yet. Is it a 23.11 addition?
the PR is still being reviewed:
Change:
./services/misc/octoprint.nix ./services/misc/ollama.nix ./services/misc/ombi.nix <ins> ./services/misc/open-webui.nix </ins> ./services/misc/osrm.nix ./services/misc/owncast.nix ./services/misc/packagekit.nix

Discussion:
Ollama is a big project and I think having a nice UI in the stable repos would make nix even better. I can help with the PR but I am new to nix and don't really understand the git workflow and all Pinging the package maintainer: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Current master is broken for (see ). However, I don’t think that should be a problem while backporting to , as .
Backport PR for 0.2.4:
To track the progress of backporting to latest , see:
I love this, thanks!!
Change:
krename-qt5 = throw "'krename-qt5' has been renamed to/replaced by 'krename'"; # Converted to throw 2022-02-22 krita-beta = krita; # moved from top-level 2021-12-23 kube-aws = throw "kube-aws is deprecated and archived by upstream"; # Added 2022-04-05 <ins> kubei = kubeclarity; # Added 2023-05-20 </ins> kubeless = throw "kubeless is deprecated and archived by upstream"; # Added 2022-04-05 kubicorn = throw "kubicorn has been dropped due to the lack of maintenance from upstream since 2019"; # Added 2022-05-30 kvm = throw "'kvm' has been renamed to/replaced by 'qemu_kvm'"; # Converted to throw 2022-02-22

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: kubei <!-- 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: 1.0.12 desired version: 2.9.0 <!-- 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:
/* <del> NixOS support 2 fontconfig versions, "support" and "latest". - "latest" refers to default fontconfig package (pkgs.fontconfig). configuration files are linked to /etc/fonts/VERSION/conf.d/ - "support" refers to supportPkg (pkgs."fontconfig_${supportVersion}"). configuration files are linked to /etc/fonts/conf.d/ </del> <ins> Configuration files are linked to /etc/fonts/${pkgs.fontconfig.configVersion}/conf.d/ </ins> This module generates a package containing configuration files and link it in /etc/fonts.

Discussion:
, CVSSv3=7.8 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives.
See also:
PR for unstable: PR for 20.03:
This is still an issue.
oops, sorry
We only use config files. We could probably just delete everything but from the derivation, or remove it from top-level.
Yeah, but we still ship the fontconfig binary in nixpkgs. Is there any reason we still need to provide config files parse-able by 2.10.x fontconfig implementations?
I doubt there is much of a reason these days, nobody will be running programs compiled against fontconfig 2.10. I just do not want to remove it now so that possible breakage caused by is not mixed with potential downfall from removing the unversioned path.
is a new attempt to address this.
Change:
spectrwm = callPackage ../applications/window-managers/spectrwm { }; <ins> spot = callPackage ../applications/audio/spot { }; </ins> spotify-cli-linux = callPackage ../applications/audio/spotify-cli-linux { }; spotifyd = callPackage ../applications/audio/spotifyd {

Discussion:
Project description Spot Gtk/Rust native Spotify client for the Gnome desktop. Only works with premium accounts! Based on librespot. Metadata homepage URL: source URL: license: mit platforms: unix/linux
Change:
{ options.programs.xwayland = { <del> enable = mkEnableOption '' Xwayland X server allows running X programs on a Wayland compositor. ''; </del> <ins> enable = mkEnableOption "Xwayland (an X server for interfacing X11 apps with the Wayland protocol)"; </ins> defaultFontPath = mkOption { type = types.str; default = optionalString config.fonts.fontDir.enable "/run/current-system/sw/share/X11/fonts"; <ins> defaultText = literalExample '' optionalString config.fonts.fontDir.enable "/run/current-system/sw/share/X11/fonts"; ''; </ins> description = '' Default font path. Setting this option causes Xwayland to be rebuilt. '';

Discussion:
Describe the bug Attempting to override the Wayland package used by with fails with a conflict error: To Reproduce Ensure you have the following channels set up: Add the following to your : Expected behavior XWayland v21.1.2 should be installed. Additional context These are the exact commits I'm on: Notify maintainers Metadata Maintainer information:
you can use as a "workaround" (also requires in ). we should likely apply this change to the XWayland package: Ideally with to provide a nice textual example in , etc.
Thanks! The workaround did the trick.
Change:
, nose , pyopenssl , iana-etc <ins> , pytestCheckHook </ins> , libredirect }: buildPythonPackage rec { pname = "eventlet"; version = "0.33.0"; <ins> format = "setuptools"; </ins> <del> src = fetchPypi { inherit pname version; sha256 = "80144f489c1bb273a51b6f96ff9785a382d2866b9bab1f5bd748385019f4141f"; </del> <ins> src = fetchFromGitHub { owner = "eventlet"; repo = pname; rev = "v${version}"; hash = "sha256-kE/eYBbaTt1mPGoUIMhonvFBlQOdAfPU5GvCvPaRHvs="; </ins> }; <del> propagatedBuildInputs = [ dnspython greenlet pyopenssl six ] ++ lib.optional (pythonOlder "3.5") monotonic; </del> <ins> propagatedBuildInputs = [ dnspython greenlet pyopenssl six ] ++ lib.optional (pythonOlder "3.5") [ monotonic ]; </ins> <del> checkInputs = [ nose ]; </del> <ins> checkInputs = [ pytestCheckHook nose ]; </ins> doCheck = !stdenv.isDarwin;

Discussion:
See A similar failure occurs for python38 on my machine locally (reproduce with in a freshly checked out ). Please run and paste the result.
Strange, I can't reproduce the error with 3.8 anymore :thinking: it seems that although the tests ~failed~ threw exceptions, and this was visible during , the derivation did successfully build.
It probably fails because of the hacky preCheck
So is the test simply flaky, and sometimes succeeds on Hydra? Or if not, shouldn't we exclude the test if it can't be set up properly?
Change:
def send_key(self, key: str) -> None: key = CHAR_TO_KEY.get(key, key) self.send_monitor_command("sendkey {}".format(key)) <ins> time.sleep(0.01) </ins> def start(self) -> None: if self.booted:

Discussion:
In combination with 21.11 adding it to the job, this prevents channel. The keymap tests don't have any maintainers. That's quite an issue for channel-blocking jobs, I think.
Well, we could remove from the blocking set, at least for now. It certainly doesn't feel so critical to me. (Though qwertz layout gets vast majority in my country actually.)
In it was discussed wether Linux 5.15 could be the cause, but the way I see it the test is running with Linux 5.10? 5.15 seems only to be used for the stdenv.
Yes, It is at least surprising that a large part of the channel tests is about keyboard layouts.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
if the keymap tests have no maintainers, perhaps they should be removed, or at leat disabled for now.
it looks like its random which one symbol fails azerty fails sometimes too
This test has been flaky since and does not provide much value. I propose to simply remove it from the tested job.
I'm thinking this is a race condition with sending keys too fast, maybe made worse when a builder is under high load. Something like this perhaps?
EDIT: it takes way too long to run the test without kvm so i didn't i'll run the test with and without that. and with running to mimic high load i had to apply this patch to run the test vm because kvm was failing but its very very slow now
So, at least the simple step for now?
the sleep patch does indeed fix the issue, at least when building on my Honeycomb. I do think it's odd though that the test fails in exactly the same way every time I run it. I'd expect it to fail less consistently, or in different ways…
azerty test fails sometimes too
While it's far from elegant, I'd be fine with adding the sleep patch. Since it's only 10ms per character, I don't think the performance impact will be significant, and I'd prefer to start verifying the functionality again (major use case: encryption passphrase input, where the results aren't even visible).

i've run some tests on my rpi4b and found that applying this patch fixes the issue even with load and no delay(i still think we should leave the delay) <pre<del0.02 sometimes works if there is no other load at least 0.04 is needed to sometimes not fail when i run 1 is safe according to this the average inter-key interval of a human is 238ms INTER-KEY INTERVALS Average inter-key interval is 238.656 ms (SD = 111.6). A lower bound of about 60 ms can be observed.</del</pre
Change:
runHook preUnpack dpkg -x $src ./wechat-uos <del> dpkg -x $uosSrc ./wechat-uos-old-source </del> runHook postUnpack '';

Discussion:
the package wechat uos is still using OpenSSL 1.1 which is end of life on 2023/09/11, so it is marked as insecure now. not sure if we need to wait for wechat-uos or we can just bump it up in here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
As far as I know, only from depends on OpenSSL 1.1. Seems like we may replace it with to completely remove dependency. I will try to fix that in the next PR when I have free time.
Would it be offensive if I could submit a patch about it now.
Feel free to do so. I would be happy to review your pr :)