jiebi/CodeConvo huggingface dataset:
Code change:
webcamoid = libsForQt5.callPackage ../applications/video/webcamoid { }; <ins> webcord = callPackage ../applications/networking/instant-messengers/webcord {}; </ins> webex = callPackage ../applications/networking/instant-messengers/webex {}; webmacs = libsForQt5.callPackage ../applications/networking/browsers/webmacs {};

Related discussion:
text: Project description Alternate Discord and Fosscord client made to be private, secure, customizable, and Linux friendly. Metadata homepage URL: source URL: license: MIT platforms: x86_64 and aarch64 on linux, darwin, windows
I had a shot at trying to package this from source, but it seems that for whatever reason, the nixpkgs' Electron crashes with SIGTRAP when trying to run with source. I haven't had much luck using on Electron to find a root cause either. Haven't tried using the AppImage yet, though.
I don't think the appimage will have much difference, but I've also gotten the same error. There is now a that uses dream2nix to package it properly
I made a derivation that doesn't use dream2nix, and it's available at if it's of any use. The SIGTRAP issue was just a bad Electron version, from what I could tell. I haven't submitted this to nixpkgs yet purely because I want merged first.
Ah it would make sense for the SIGTRAP to be an electron version issue, I've had it on a few other electron apps too. Your derivation looks pretty good, might try it out. Wonder how long it will take the pr you mentioned to be finished tho
The PR has been marked as a blocker for 22.11, so at the very latest, end of November. May be an excessive amount of time to wait, though.
Now that is mostly done and merged, I've used it to make a nice and simple derivation for it:
Looks great. Not sure if you're planning on submitting this to nixpkgs, but if you are it might be worth adding arm64 support as well.
Yeah it would be nice to get this to work on aarch64 and/or darwin too, but I don’t have any devices to test it on. Can you help with this? The package might already even work on arm since we're just wrapping nixpkgs electron. I’m also down to put this on nixpkgs, might wanna do a bit more testing and tweaking; if you can see any places for improvement that'd be great!
is there anything that would stop this package from running on i686?
Code change:
netifaces octoprint-filecheck octoprint-firmwarecheck <del> octoprint-pisupport </del> passlib pathvalidate pkginfo

Related discussion:
text: Steps to reproduce the behavior: also yields the "got" hash. The hash was last changed in nixpkgs @
we just hit the same issue in Alpine - it looks like the upstream uses format specifiers for that change depending on the state of the repo: (found by [here][1]) in your case it might help to do instead ( provided that doesn't just do on the remote URL, but fetches the repo in some other way ): [1]:
thanks for the new upstream issue and the infos!
Code change:
owner = "AzureAD"; repo = "microsoft-authentication-extensions-for-python"; rev = "refs/tags/${version}"; <del> hash = "sha256-ScInTvOgFxP5mgep5FRu6YZHPTtXhrcZGFE7Wdvcm4c="; </del> <ins> hash = "sha256-javYE1XDW1yrMZ/BLqIu/pUXChlBZlACctbD2RfWuis="; </ins> }; <del> nativeBuildInputs = [ setuptools ]; </del> <ins> build-system = [ setuptools ]; </ins> <del> propagatedBuildInputs = [ </del> <ins> dependencies = [ </ins> msal portalocker ];

Related discussion:
text: Trying to run an action with azure-cli that requries authentication, az will fail to read the cached authentication token from the token cache: This is due to a version mismatch of . will update the package, I checked that the authentication works afterwards. That's me! Please run and paste the result. ` Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I also experience this issue with , as well as with . Thanks for adding the fix!
Code change:
config = mkIf cfg.enable { services.xserver = { exportConfiguration = true; <del> displayManager.job.execCmd = ""; displayManager.lightdm.enable = lib.mkForce false; </del> }; <del> systemd.services.display-manager.enable = false; </del> # Other displayManagers log to /dev/null because they're services and put # Xorg's stdout in the journal

Related discussion:
text: I believe that this prevents the use of other display managers -Don't force it?
if you enable a another dm you wouldn't get this error i submitted a pr so that this error does not happen when lightdm is disabled but a another dm isn't enabled
Code change:
<ins> { lib , stdenv , fetchFromGitLab , meson , vala , ninja , pkg-config , wrapGAppsHook , desktop-file-utils , appstream-glib , python3 , glib , gtk3 , libhandy , libtransmission , libb64 , libutp , miniupnpc , dht , libnatpmp , libevent , curl , openssl , zlib }: stdenv.mkDerivation rec { pname = "fragments"; version = "1.5"; src = fetchFromGitLab { domain = "gitlab.gnome.org"; owner = "World"; repo = "Fragments"; rev = version; sha256 = "0x1kafhlgyi65l4w67c24r8mpvasg3q3c4wlgnjc9sxvp6ki7xbn"; }; patches = [ # Fix dependency resolution ./dependency-resolution.patch ]; nativeBuildInputs = [ meson vala ninja pkg-config wrapGAppsHook desktop-file-utils appstream-glib python3 ]; buildInputs = [ glib gtk3 libhandy libtransmission libb64 libutp miniupnpc dht libnatpmp libevent curl openssl zlib ]; meta = with lib; { homepage = "https://gitlab.gnome.org/World/Fragments"; description = "A GTK3 BitTorrent Client"; maintainers = with maintainers; [ angustrau ]; license = licenses.gpl3Plus; platforms = platforms.linux; }; } </ins>

Related discussion:
text: Project description Fragments is a modern, responsive and graphical Gnome bittorrent client Metadata homepage URL: source URL: license: gpl3 platforms: linux The new version of Fragments depends on libutp which hopefully gets merged soon. I've opened a pull request for it . for Fragments.
We have transmission and torrential. Maybe that's something for you.
That's true but Fragments is a really neat, easy and modern looking torrent client. It has an adaptive interface which would also work quite well on mobile devices, for example NixOS mobile :+1:
Code change:
acme.wait_for_unit("default.target") acme.wait_for_unit("pebble.service") <del> client.succeed("curl https://acme.test:15000/roots/0 > /tmp/ca.crt") client.succeed("curl https://acme.test:15000/intermediate-keys/0 >> /tmp/ca.crt") </del> <ins> client.succeed("curl https://${caDomain}:15000/roots/0 > /tmp/ca.crt") client.succeed("curl https://${caDomain}:15000/intermediate-keys/0 >> /tmp/ca.crt") </ins> with subtest("Can request certificate with HTTPS-01 challenge"): webserver.wait_for_unit("acme-finished-a.example.test.target")

Related discussion:
text: Describe the bug causes Lego to fail. To Reproduce Steps to reproduce the behavior: set on an enabled certificate. to this configuration. fail. Lego complains about an unrecognized (really misplaced) flag. Expected behavior The certificate will be successfully fetched, with Must-Staple enabled. Screenshots Additional context I think the problematic code is here: should not be in commonOpts, it should instead be in runOpts and renewOpts. Lego runs successfully when is to and . Notify maintainers (the acme team) Metadata Maintainer information:
Thanks for the report :) It appears that the --must-staple option is common to both "run" and "renew" modes, but is not actually a common option that can be specified before the mode. I'll get a PR ready for this.
Code change:
<ins> { lib , stdenvNoCC , fetchurl }: stdenvNoCC.mkDerivation (finalAttrs: { pname = "softnet"; version = "0.7.1"; src = fetchurl { url = "https://github.com/cirruslabs/softnet/releases/download/${finalAttrs.version}/softnet.tar.gz"; sha256 = "1g274x524xc85hfzxi3vb4xp720bjgk740bp6hc92d1ikmp0b664"; }; sourceRoot = "."; installPhase = '' runHook preInstall install -D softnet $out/bin/softnet install -Dm444 -t $out/share/softnet README.md LICENSE runHook postInstall ''; meta = with lib; { description = "Software networking with isolation for Tart"; homepage = "https://github.com/cirruslabs/softnet"; license = licenses.agpl3Plus; maintainers = with maintainers; [ emilytrau ]; platforms = [ "aarch64-darwin" ]; # Source build will be possible after darwin SDK 12.0 bump # https://github.com/NixOS/nixpkgs/pull/229210 sourceProvenance = with sourceTypes; [ binaryNativeCode ]; }; }) </ins>

Related discussion:
text: Project description <!-- Describe the project a little: --Metadata homepage URL: source URL: license: platforms: darwin
Code change:
patches = [ ./cflags-prune.diff ] ++ lib.optional ftNixSupport ./ft-nix-support.patch; configureFlags = [ <del> "--enable-gui=${guiSupport}" </del> "--with-features=${features}" "--disable-xsmp"              # XSMP session management "--disable-xsmp_interact"     # XSMP interaction

Related discussion:
text: The package hard-codes various X11 libraries as dependencies while making many other features optional, including GUIs. It would be nice to have an option to disable the X11 feature and the related . The use case I have in mind is installing a custom Vim on a remote server. Pulling X libraries, even without enabling a GUI, adds a few dozen megabytes for something essentially useless. An approach is doing something like this: but it doesn't feel very clean... Any thoughts from or ?
I agree. It would have been nice if these X dependencies would have been to only if is or .
/me whispers neovim~~~
I'm all for testing new things and neovim is on my list. But according to , the neovim package pulls 428MiB of dependencies, half of which for Ruby, the other half for both Python 3 and Python 2 (seriously?). Is there a way, by any chance, to configure neovim to avoid this bloat ?
admittedly I've never tried to configure a mininmal version but one can unselect these ecosystems:
See .
Code change:
passthru = { inherit targetPrefix; }; <ins> meta = { maintainers = with stdenv.lib.maintainers; [ matthewbauer ]; priority = 10; }; </ins> }

Related discussion:
text: I have installed a very barebones server with NixOS. Whenever I run it shows the following warnings: I get that it does not matter that much which of these are used, but it makes these commands not very transparent. Why is being used from and not , while is apparently part of ? Should we make sure these packages will not both be part of or should we make sure the files are only available in one of the two packages? up a minimal version of NixOS. the log
These are usually fixable by just setting priority values. coreutils should probably have a lower priority as they are usually cross platform but not as many supported features. The getconf and getent are interesting because they are actually symlinks to glibc. But we might as well make unixtools lower priority as well.
Is this something we should do nixpkgs-wide? Will that avoid the warning messages? I was thinking why these are providing the same files and why both packages are being used. For instance, do we really need openresolv or is that included unintentionally? The priorities is a way to solve this safely, but I feel like there shouldn't be any conflicts for the base packages at all.
Maybe openresolv we can leave out of systemPackages. But, some of these collisions are kind of unavoidable. We need both procps and coreutils even though they both provide kill bunary. It might be interesting to see which other distros use but IIRC they are almost identical
For coreutils, ArchLinux seems to leave out the kill binary: This also feels a bit wrong, as it isn't the original package anymore. Changing the priority does indeed sound like a better option. Coreutils should have a lower priority.
I tried giving coreutils a lower priority, but it doesn't seem to have made a difference for those warnings.
oh it already has lowprio: but it doesn't really work when everything has the same priority.
systemd-resolved is not enable by default so resolvconf shouln't be really pointing to resolvectl. I think the dummy command provided for compatibility doesn't work correctly if resolved is not running and dhcpcd needs it to configure interfaces.
Should we just give openresolv a higher priority than systemd?
Yes, correct.
Code change:
passthru = { inherit targetPrefix; }; <ins> meta = { maintainers = with stdenv.lib.maintainers; [ matthewbauer ]; priority = 10; }; </ins> }

Related discussion:
text: The dhcpcd resolvconf hook check if resolvconf is installed and, because the command is in the PATH, it won't fall back to writing directly but will attempt to execute something like this: echo 'nameserver 10.0.1.1' | resolvconf -a wlan0 Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
Reproducible way to see these collisions: With a file set to I ran in the (the latest commit on the branch), and I get these collision messages:
ping
Hi all nixos-version 03. (Koi) I have the same collision on kill gnutar resolvconf but also on collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.
Code change:
passthru = { inherit targetPrefix; }; <ins> meta = { maintainers = with stdenv.lib.maintainers; [ matthewbauer ]; priority = 10; }; </ins> }

Related discussion:
text: 0/share/icons/hicolor/48x48/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/48x48/apps/phonon-'
This seems to include many more collisions than related to this issue.
Maybe rather than changing the nix-env priority, a better solution is to remove some of these programs (e.g. delete in util-linux's ).
That seems hacky to me. What if you want util-linux's version of kill? Presumably if the maintainer thinks it's worth including, someone has a use for it. Nixpkgs shouldn't be making these decisions at the derivation level. Something like meta seems ideal because you can change it without effecting the derivation.
Since and were merged, does that mean this issue can be closed now?
I think so, I don't see these collisions anymore.
Let me know if this isn't fixed after all.
sorry, but i see these collisions.
Code change:
passthru = { inherit targetPrefix; }; <ins> meta = { maintainers = with stdenv.lib.maintainers; [ matthewbauer ]; priority = 10; }; </ins> }

Related discussion:
text: it's a different issue: it seems you're installing both the wrapped and unwrapped version of the same packages. I'd say there's something wrong with your configuration, but if you think otherwise open a new issue.
Code change:
--replace '$POLYML_HOME/$PLATFORM/polyml' ${polyml}/bin/poly substituteInPlace lib/scripts/run-polyml* lib/scripts/polyml-version  --replace '$ML_HOME/poly' ${polyml}/bin/poly <del> ''; </del> <ins> substituteInPlace contrib/z3*/etc/settings  --replace '$Z3_HOME/z3' '${z3}/bin/z3' '' + (if ! stdenv.isLinux then "" else '' arch=${if stdenv.system == "x86_64-linux" then "x86_64-linux" else "x86-linux"} for f in contrib/*/$arch/{bash_process,epclextract,eprover,nunchaku,SPASS}; do patchelf --set-interpreter $(cat ${stdenv.cc}/nix-support/dynamic-linker) "$f" done ''); </ins> installPhase = '' mkdir -p $out/bin

Related discussion:
text: Not all the executables of the /contrib directory are patched, so some functionalities of the theorem prover fail. For instance, running the Sledgehammer tool (subwindow in the bottom bar of Isabelle starting window) always fail with: The directory: The sub directories marked with a star contain the x64 executables I tried to execute manually and I got: "Not such file or directory" Run Isabelle and try to use Sledgehammer. Then try to execute the executables in the marked directories, and you will obtain "Not such file or directory". System: 16.03.1171. (Emu) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: "16.03.1171." I am definitely new to NixOS, but with my nonexistent experience I think at least two solutions are available: 1) I can substitute the broken software with the packaged one, as it is done with Java and Polyml in the Isabelle2016 derivation; 2) I can patch the executables with patchelf (hopefully). I did not have time to try these so far, but I was wondering how difficult would be the 2nd: I think that using (1) can potentially break Isabelle since we would use different versions of the software in /contrib. You guys are amazing! Thanks a lot for NixOS!!! It is the most elegant OS I ever tried!
Hello, after some experimenting, I found a hack to make Isabelle work in Nixos Emu x64: this derivation substitutes the broken provers and rebuilds the exec-process executable. What I do not like of this solution: the provers are not the same (versions) of the Isabelle distribution, and this works only for x64 -- if you use a 32 bit you have just to change (take away the_64 bit from the target directory name) the derivation after the comment in the postPatch phase. However it works. Hopefully someone more expert than me can propose a better solution! Thanks again!!
Code change:
{ lib , stdenv <ins> , fetchpatch2 </ins> , cmake , ninja , python

Related discussion:
text: Steps to reproduce the behavior: pyside6 Please run and paste the result. :sweat_smile: I guess it says not found because i have no channels (i use flakes)
This same failure is causing syncplay to fail to install on my system.
yeah thats how i knew lol
To confirm, I can reproduce this issue.
I'm trying to package something which relies on pyside6. Package builds fine on nixos-stable but fails under nixos-unstable due to pyside6 not building.
Code change:
dontWrapGApps = true; installPhase = '' <ins> runHook preInstall </ins> mkdir -p $out/bin mv opt/BlueMail/* $out ln -s $out/bluemail $out/bin/bluemail <ins> mkdir -p $out/share/icons mv usr/share/icons/hicolor $out/share/icons/ runHook postInstall </ins> ''; makeWrapperArgs = [

Related discussion:
text: When installed through Nix, Bluemail does not create a desktop shortcut in $out/share/applications. The program can only be run through the terminal by default. The program also fails to load unless the --disable-gpu-sandbox option is used. Steps to reproduce the behavior: Bluemail by adding to , and rebuild. for Bluemail in the Application Launcher - not present in terminal - core dumps on gpu process not usable in terminal - bluemail opens with the default wayland icon What currently happens is detailed step-by-step above. What I'd expect to happen is that a desktop icon is created when I rebuild to install bluemail, and that clicking the application from the Application Launcher opens bluemail without a core dump. Installing from NixOS-Unstable Running on Intel UHD Graphics (10th Gen)
Code change:
<del> { pcre, pcre2, libXinerama, picom, lib, fetchFromGitHub }: </del> <ins> { lib , fetchFromGitHub , libXinerama , pcre , pcre2 , picom , xcbutil }: </ins> <del> picom.overrideAttrs (oldAttrs: rec { </del> <ins> picom.overrideAttrs (oldAttrs: { </ins> pname = "picom-next"; <del> version = "unstable-2023-01-29"; buildInputs = [ pcre2 ] ++ lib.remove libXinerama (lib.remove pcre oldAttrs.buildInputs); </del> <ins> version = "unstable-2023-08-03"; buildInputs = [ pcre2 xcbutil ] # remove dependencies that are not used anymore ++ (lib.subtractLists [ libXinerama pcre ] oldAttrs.buildInputs); </ins> src = fetchFromGitHub { owner = "yshui"; repo = "picom"; <del> rev = "cee12875625465292bc11bf09dc8ab117cae75f4"; sha256 = "sha256-lVwBwOvzn4ro1jInRuNvn1vQuwUHUp4MYrDaFRmW9pc="; </del> <ins> rev = "5d6957d3da1bf99311a676eab94c69ef4276bedf"; hash = "sha256-Mzf0533roLSODjMCPKyGSMbP7lIbT+PoLTZfoIBAI6g="; </ins> }; meta.maintainers = with lib.maintainers; oldAttrs.meta.maintainers ++ [ GKasparov ]; })

Related discussion:
text: Package name: picom-next Latest released version: regrettably, v10.2 (released December 2022) is still the latest upstream release <!-- Search your package here: --- Current version on the unstable channel: unstable-2023-01-29 Current version on the stable/release channel: unstable-2023-01-29 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- There's at least one bugfix since the start of the year that would be nice to have: 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.
Can you help reviewing it?
Apologies for not testing this for you, I couldn't immediately work out how to do so. I've now opened to hopefully make it a little easier next time.
Code change:
enableParallelBuilding = true; <del> installPhase = '' runHook preInstall DESTDIR=$out PREFIX= pkgconfigdir=lib/pkgconfig make install $installFlags runHook postInstall ''; </del> <ins> makeFlags = [ "PREFIX=${placeholder "out"}" ]; </ins> FONTCONFIG_FILE="${fontconfig.out}/etc/fonts/fonts.conf"; FONTCONFIG_PATH="${fontconfig.out}/etc/fonts/";

Related discussion:
text: Hi, i need to use open-zwave as a dependency for a build, but the version built in the Nix package is a specific fork for supporting home-assistant, which does not work for my package build due to linking errors. I will happily contribute a new package, but I'm not sure how to proceed, with regards to how it would fit in with this package, or if indeed the best way would be to modify this package to use the upstream repo. Pinging people who have maintained the package, apologies for the noise!
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 .
We should replace the package with an official version and make use the fork.