jiebi/CodeConvo huggingface dataset:
Change:
buildPythonPackage rec { pname = "textual"; <del> version = "0.15.1"; </del> <ins> version = "0.23.0"; </ins> format = "pyproject"; disabled = pythonOlder "3.7";

Discussion:
Package name: textual Latest released version: 0.23.0 <!-- Search your package here: --- Current version on the unstable channel: 0.15.1 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.
Does resolve this?
As far as I can tell: yes. Would be great to have it merged into master (so it shows up in nixpkgs-unstable at some point).
And of course there have been two new releases in the meantime....
Was fixed, closing.
Change:
pkg-config wrapQtAppsHook ]; buildInputs = [ alsa-lib ffmpeg

Discussion:
Package name: Latest released version: <!-- 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.
Change:
<ins> { lib , libsForQt5 , symlinkJoin , unwrapped ? libsForQt5.callPackage ./. { } , krita-plugin-gmic , binaryPlugins ? [ # Default plugins provided by upstream appimage krita-plugin-gmic ] }: symlinkJoin { name = lib.replaceStrings [ "-unwrapped" ] [ "" ] unwrapped.name; inherit (unwrapped) version buildInputs nativeBuildInputs meta; paths = [ unwrapped ] ++ binaryPlugins; postBuild = '' wrapQtApp "$out/bin/krita"  --prefix PYTHONPATH : "$PYTHONPATH"  --set KRITA_PLUGIN_PATH "$out/lib/kritaplugins" ''; passthru = { inherit unwrapped binaryPlugins; }; } </ins>

Discussion:
Krita 5 complains that it cannot find the G'Mic plugin. Steps to reproduce the behavior: Krita and the G'Mic plugin by adding and to in Krita a new image the menu item Filter→Start G'MIC-Qt will complain, via a modal dialog, that it cannot load the plugin. the menu item Settings→Configure Krita… should be a "G’Mic plugin" section in the left-hand sidebar, but there is not. For there to be a Krita setting to specify the path to the G'Mic plugin. The explains the correct behaviour.
Starting from the package won't work with Krita. Krita team forked and Krita will only work with that fork: It would take some effort to implement the build process mentioned in the README since cmake and make need to be invoked multiple times. (Probably need to manually write the whole and )
Is it possible to maintain a separate krita-gmic package like arch linux does?
It is possible but making it a separate package probably wouldn't make it easier to implement. We just need someone to implement the build process I linked above in nix (sorry I don't have time to do it)
Making some minor changes to you can build the krita plugin: I've not yet been able to have krita load the plugin though. I've tried creating a symlinkJoin'ed version with the plugin, that does not work :confused: Krita is not logging enough information about where it tried to load the plugin for me to be able to deduce what is going wrong.
Do you think the Krita fork of gmic-qt should be integrated in the definition at ? I was originally afraid modifying it now would not be worth it because the two versions might deviate too much from one another.
If you want to remove the original gmic-qt and change it to krita's fork, I believe it will conflict with the previous one, and I would therefore vote against it If you want to keep the fork along with the original, it's fine! You can use overrideAttrs magic in order to reuse the previous expression. Look at as an example for inspiration.
Option 1 is terrible, I'd never ask for that :smiley:.

I was asking if krita's gmic-qt should be included as a "variant" in , effectively does the same as option 2 <details<summaryLike this</summary</detailsI think it's best to keep it as a completely separate package, because both packages will never have matching versions.
So close! I got the "Q'MIC-qt for Krita" window to open by manipulating : ! Unfortunately it segfaults the moment I try to use any of the filters: Progress at
Change:
<ins> { stdenv, fetchFromGitHub, rustPlatform, cargo, cmake, sphinx, lib, prefix ? "uutils-" }: rustPlatform.buildRustPackage { name = "uutils-coreutils-2018-02-09"; src = fetchFromGitHub { owner = "uutils"; repo = "coreutils"; rev = "f333ab26b03294a32a10c1c203a03c6b5cf8a89a"; sha256 = "0nkggs5nqvc1mxzzgcsqm1ahchh4ll11xh0xqmcljrr5yg1rhhzf"; }; # too many impure/platform-dependent tests doCheck = false; cargoSha256 = "0qv2wz1bxhm5xhzbic7cqmn8jj8fyap0s18ylia4fbwpmv89nkc5"; makeFlags = [ "CARGO=${cargo}/bin/cargo" "PREFIX=$(out)" "PROFILE=release" "INSTALLDIR_MAN=$(out)/share/man/man1" ] ++ lib.optional (prefix != null) [ "PROG_PREFIX=${prefix}" ]; nativeBuildInputs = [ cmake ]; buildInputs = [ cargo sphinx ]; # empty {build,install}Phase to use defaults of `stdenv.mkDerivation` rather than rust defaults buildPhase = ""; installPhase = ""; meta = with stdenv.lib; { description = "Cross-platform Rust rewrite of the GNU coreutils"; longDescription = '' uutils is an attempt at writing universal (as in cross-platform) CLI utils in Rust. This repo is to aggregate the GNU coreutils rewrites. ''; homepage = https://github.com/uutils/coreutils; maintainers = with maintainers; [ ma27 ]; license = licenses.mit; platforms = platforms.unix; }; } </ins>

Discussion:
I would absolutely love for somebody to package up :)
will attempt to reserve some time to give it a try in the next days :-)
I created a first working version which compiles on my machine ( ): Unfortunately I had to use an older revision since the latest revisions require language features from Rust 1.19 and I'll have to bump it in nixpkgs before using the latest revision, after that I'll open a PR :-)
btw do we want to add an option which allows to change the coreutils pkg from to ? Something like and every module should start start using .
I had contemplated using a package override and just make equal to . Not sure how well that would work out... This may be something where is one of the few qualified to chime in.
Please don't introduce this as a NixOS option. This rewrite is not compatible with the GNU coreutils. This will certainly break NixOS. The package override will break lots of packages and will trigger a full rebuild anyway. Packaging these for testing is fine. :+1:
Could you just wrap this into a PR then? I will certainly test this and create some aliases to replace the GNU tools (in the user environment)
sorry for the delay at first. I'm aware of this. I just proposed an approach to switch the package just for system-wide testing purposes. This is actually the better approach. Furthermore this is something anyone can do locally, so shouldn't have concers with it as it shouldn't affect code in for now :-) I'll certainly do. However we have to wait for since the latest revisions of require Rust 1.19 (I'm currenty using an older revision from July 2017 locally). I checked out this change tried to compile uutils-coreutils against the new Rust compiler, but it cargo builds seem to fail ()
Ah, of course. Let's wait for then.
after has been merged it should be possible to finally implement this. Will open a PR in th next days...
Change:
sh autogen.sh ''; <del> configureFlags = [ "--x-includes=${libX11.dev}/include" "--x-libraries=${libX11.out}/lib" "--enable-examples=no" ]; </del> <ins> configureFlags = lib.optionals stdenv.isLinux [ "--x-includes=${lib.getDev libX11}/include" "--x-libraries=${lib.getLib libX11}/lib" "--enable-examples=no" ]; </ins> # libtool --tag=CXX --mode=link g++ -g -O2 libexamples.la ../src/platform/X11/libaggplatformX11.la ../src/libagg.la -o alpha_mask2 alpha_mask2.o # libtool: error: cannot find the library 'libexamples.la'

Discussion:
Project description Superset of package , which isnt actively developed now. Metadata homepage URL: https://lite- source URL: license: mit platforms: linux, darwin
Change:
systemd fuse yajl libvirt gmp readline file hivex numactl xen libapparmor getopt perlPackages.ModuleBuild ] ++ (with perlPackages; [ perl libintl_perl GetoptLong SysVirt ]) <del> ++ (with ocamlPackages; [ ocaml findlib ocamlbuild ocaml_libvirt ocaml_gettext ounit ]) </del> <ins> ++ (with ocamlPackages; [ ocaml findlib ocamlbuild ocaml_libvirt gettext-stub ounit ]) </ins> ++ stdenv.lib.optional javaSupport jdk; prePatch = ''

Discussion:
Describe the bug To Reproduce Steps to reproduce the behavior: vagrant on latest master error Expected behavior Builds Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata system: host os: multi-user?: sandbox: version: channels(maciej): nixpkgs: Maintainer information:
Broken in . I don't know anything about ocaml, so I'm not well qualified to fix this. CC
Apologies for breaking . Thanks for reporting this issue; PR should fix it.
Change:
meta = with stdenv.lib; { description = "A tiling window manager"; homepage    = "http://i3wm.org"; <del> maintainers = with maintainers; [ garbas modulistic ]; </del> <ins> maintainers = with maintainers; [ garbas modulistic fpletz ]; </ins> license     = licenses.bsd3; platforms   = platforms.all;

Discussion:
i3 has been updated to 4.13. I attempted to update our derivation but they switched to and I don't know how that works :) If somebody could update i3, I would really appreciate that. /cc maintainers
FYI, for to work it is sufficient to add to the (see ).
Thanks :) I think with the main i3 the issue was that the needed to change and I did not know what to set them to.
Yes, and indeed the and are already included with the source distribution for , but I had to add the for .
Change:
<del> { stdenv, fetchFromRepoOrCz, fetchurl, nasm, perl, python3, libuuid, mtools, makeWrapper }: </del> <ins> { stdenv, fetchgit, fetchurl, fetchpatch, nasm, perl, python3, libuuid, mtools, makeWrapper }: </ins> stdenv.mkDerivation { <del> name = "syslinux-2019-02-07"; </del> <ins> pname = "syslinux"; version = "unstable-20190207"; </ins> # This is syslinux-6.04-pre3^1; syslinux-6.04-pre3 fails to run. # Same issue here https://www.syslinux.org/archives/2019-February/026330.html <del> src = fetchFromRepoOrCz { repo = "syslinux"; </del> <ins> src = fetchgit { url = "https://repo.or.cz/syslinux"; </ins> rev = "b40487005223a78c3bb4c300ef6c436b3f6ec1f7"; <del> sha256 = "1qrxl1114sr2i2791z9rf8v53g200aq30f08808d7i8qnmgvxl2w"; </del> <ins> sha256 = "1acf6byx7i6vz8hq6mra526g8mf7fmfhid211y8nq0v6px7d3aqs"; fetchSubmodules = true; </ins> }; patches = let

Discussion:
pxelinux (from syslinux) is compiled without support for UEFI PXE boot: I had a quick look at getting it to compile uefi support but I didn't get very far. system: host os: multi-user?: sandbox: version: channels(root): channels(peter): nixpkgs:
Does the NixOS netboot image support UEFI boot? I did try netbooting NixOS (18.03) a few weeks ago with a pre-compiled iPXE UEFI loader. It started booting the kernel but failed to mount the initrd (kernel panic no root).
The image is using pxelinux.0 instead of lpxelinux.0 it seems and you need lpxelinux for HTTP support so maybe that's what is going on.
The http support seemed to worked just fine in my case. I did serve the iPXE UEFI loader via tftp, the kernel image and the initrd via http (initrd is too big to load trouble-free via tftp). The iPXE loader pulled bzImage and initrd via http and began booting the kernel. The kernel then failed to mount the ramdisk for some reason I do not understand. I solved the problem by setting 'Legacy mode' in the firmware (Supermicro) and booting everything in classical BIOS/PXE mode (no UEFI components involved). I can try to reproduce the problem and send you some screenshots if that helps. My vague guess is that the NixOS netboot image needs some modifications to be UEFI capable. I just wanted to raise awareness that there are potential problems with UEFI-PXE down the road.
IIRC, specifying on the kernel command line is required with EFI booting for some reason (edit: when booting with iPXE, that is).
would fix this.
Change:
<ins> { lib, buildNimPackage, fetchFromGitHub, }: buildNimPackage (final: prev: { pname = "nimlangserver"; version = "1.2.0"; # lock.json was generated by converting # nimble.lock into requires "<gitUrl>#revSha" in a dummy.nimble # for all packages and then running nim_lk on said dummy package # default nim_lk output fails because it attempts # to use branches that will not work instead of HEAD for packages lockFile = ./lock.json; src = fetchFromGitHub { owner = "nim-lang"; repo = "langserver"; rev = "71b59bfa77dabf6b8b381f6e18a1d963a1a658fc"; hash = "sha256-dznegEhRHvztrNhBcUhW83RYgJpduwdGLWj/tJ//K8c="; }; doCheck = false; meta = with lib; final.src.meta // { description = "The Nim language server implementation (based on nimsuggest)"; license = licenses.mit; mainProgram = "nimlangserver"; maintainers = with maintainers; [daylinmorgan]; }; }) </ins>

Discussion:
Project description <!-- Describe the project a little: --official sostitute of nimlsp Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ...
Change:
description = "A CD ripper aiming for accuracy over speed"; maintainers = with maintainers; [ emily ]; license = licenses.gpl3Plus; <del> platforms = platforms.linux; </del> <ins> platforms = platforms.unix; </ins> }; }

Discussion:
Ripped CD The original issue: The fix linked in the issue: So the fix seems to be either downgrade to 1.2.4 or apply the patch listed in the arch repo. Please run and paste the result.
It's hard to imagine how this specific error could be related to an encoding issue... both of your links point to the same place, do you have a link to the fix you're talking about?
Ah, I found the one used in the Arch package. I'm not presently able to test the fix myself, however; if I give you an amended Nixpkgs branch and instructions to try it, would you be able to see if it works correctly?
I applied the downgrade and it works. If you can give me the patch I can test it as well.
Thanks; please try (patch: ). Sadly it seems like neither cdrdao nor whipper get very much upstream maintainer attention these days...
Gave it a try with the following in my home-manager config: I was able to successfully rip a CD so the patch seems to be effective. :partying_face:
Thanks for testing; opened
Change:
<ins> diff --git a/scripts/mosh.pl b/scripts/mosh.pl index 56e96d7..2a2177e 100755 --- a/scripts/mosh.pl +++ b/scripts/mosh.pl @@ -61,7 +61,7 @@ my $have_ipv6 = eval { $|=1; -my $client = 'mosh-client'; +my $client = '@mosh-client@'; my $server = 'mosh-server'; my $predict = undef; @@ -91,7 +91,7 @@ my @cmdline = @ARGV; my $usage = qq{Usage: $0 [options] [--] [user@]host [command...] --client=PATH        mosh client on local machine -                                (default: "mosh-client") +                                (default: "@mosh-client@") --server=COMMAND     mosh server on remote machine (default: "mosh-server") </ins>

Discussion:
Describe the bug When running the program in a context where is not set up perfectly for nix usage, running fails to run, saying it can not count colors. To Reproduce Steps to reproduce the behavior: mosh in a "clean" env without any nix paths on it: that it's unable to exec : Expected behavior An attempt to connect to Additional context I suspect this could easily be fixed by making the wrapper that mosh installs prefix the mosh bin to . Notify maintainers Metadata Please run and paste the result. Maintainer information:
As a workaround, I currently run mosh like this in iTerm: That seems not ideal, but it works for now (:
Change:
# Inherit arguments from the derivation <del> makeWrapperArgs=( ${makeWrapperArgs-} ) </del> <ins> declare -a derivationMakeWrapperArgs="( ${makeWrapperArgs-} )" makeWrapperArgs=( "${derivationMakeWrapperArgs[@]}" ) </ins> # First argument is the executable you want to wrap, # the second is the destination for the wrapper.

Discussion:
I'm trying to do something similar to the following: Apparently, however, does not translate the Nix list into a Bash array as I'd expect. I see the following error: Add to the attributes which contains a argument with whitespace. For example: This results in a bash array with the following items (one per line): Use the following patch to print the array members: Please run and paste the result.
Using flags with spaces as a derivation attribute can . I'd append to in , as explained in the link:
Thanks for your comment. That's frustrating. I wonder if should have an argument at all, if it works sometimes. Also, I think manipulating in does not work as the defined by run first.
Spaces can be supported if some quoting is to : This is also how it's done in Python's build-support:
Change:
qtwayland ]; <del> preConfigure = lib.optionalString stdenv.isDarwin '' </del> <ins> preConfigure = '' export SOURCE_DATE_EPOCH=$(date -d 20${lib.versions.major version}0101 +%s) '' + lib.optionalString stdenv.isDarwin '' </ins> export LC_ALL=en_US.UTF-8 '';

Discussion:
Stellarium 23.3 will report its version as 80.3 and its copyright as 2000-1980 and not 2000-2023 Steps to reproduce the behavior: ~ nix run nixpkgs#stellarium -- -v Stellarium 80.3 A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Please run and paste the result.
Probably export with a timestamp in 2023 (instead of 1980) in ?
Change:
githubId = 11587657; keys = [ { fingerprint = "E173 237A C782 296D 98F5  ADAC E13D FD4B 4712 7951"; } ]; }; <ins> scvalex = { name = "Alexandru Scvorțov"; email = "github@abstractbinary.org"; github = "scvalex"; githubId = 2588; }; </ins> sdaqo = { name = "sdaqo"; email = "sdaqo.dev@protonmail.com";

Discussion:
doesn't seem to work as a module Steps to reproduce the behavior: livebook service any env variables or use environment file with any variables first of all, its systemd unit does not appear to start by default. so i did and but it doesn't work, i can't access it either by IP or by domain, which is set up in my nginx configuration as a reverse proxy. some strange things happen while the unit is active [1st screenshot]. also there's nothing in the journal except info messages about the unit itself as i see it, livebook fails to start, but the service is active because something is going on with inside this wrapper script i tried to make it work several different ways: from using option instead of my environment file to writing my very own systemd unit in NixOS configuration file, also using home-manager like so: but that doesn't work too. surely i tried starting livebook manually - and it works as expected [2nd screenshot] module/service works and is accessible systemd livebook unit works and is accessible |
---------------| NixOS 24.05.3214. (Uakari) x86_64 running on a VPS cc Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thank you for reporting this issue. I am ashamed to admit that I have actually known about this for a while now, without doing anything about it. Now that someone else is having problems with the service, I'll prioritize getting something done soon. I'm not actually sure what's going wrong, but it seems like the service hangs in the command. As far as I remember it ends up using 100% cpu and just loop forever. I'll try to take a look at it later this week.
Perhaps you have encountered this issue as well?
I've seen this before and I think it was because livebook was trying to generate a in some weird way. This is my current configuration which works: Could you try manually setting a in your service setup, please?
a screenshot from filtering cpu usage ! not so much is used i've tried setting up a cookie and you can see it works - :pleading_face: thanks!!!! ~<
The issue seems to have been described and debugged here: The solution is to set in the systemd service configuration. I'll mint a PR.
Change:
./fix-for-rust-1.65.diff ]; <del> cargoSha256 = "sha256-1OMWEk+DerltF7kwdo4d04rbgIFLHBRq3vZaL7jtrdE="; LIBCLANG_PATH="${llvmPackages.libclang.lib}/lib"; </del> <ins> LIBCLANG_PATH = "${llvmPackages.libclang.lib}/lib"; cargoLock = { lockFile = ./Cargo.lock; outputHashes = { "confy-0.4.0" = "sha256-e91cvEixhpPzIthAxzTa3fDY6eCsHUy/eZQAqs7QTDo="; "parity-tokio-ipc-0.7.3-1" = "sha256-eULJePtBu0iBI3It/bPH0h82Obsb1PJALgwYwrnCFYI="; "rdev-0.5.0-2" = "sha256-7CEZ2wIM4QAPfY1tGKqXfHplTaxHnccVqFRPjY21Svo="; "tokio-socks-0.5.1-1" = "sha256-45QQ6FrhGU9uEhbKXTKd/mY6MDumO6p46NmlakdyDQk="; "libappindicator-0.6.1" = "sha256-JGnnZrcwbh8WJ6+/4bYhfD3HvgF2C7XaaGb6TaMRWdw="; "magnum-opus-0.4.0" = "sha256-U5uuN4YolOYDnFNbtPpwYefcBDTUUyioui0UCcW8dyo="; "rust-pulsectl-0.2.12" = "sha256-8jXTspWvjONFcvw9/Z8C43g4BuGZ3rsG32tvLMQbtbM="; "sciter-rs-0.5.57" = "sha256-ZZnZDhMjK0LjgmK0da1yvB0uoKueLhhhQtzmjoN+1R0="; "systray-0.4.1" = "sha256-p1PMr/8oS6zHx4+Ng4zCqt0xZ57cq3wAu6/agyWq5Jw="; }; }; </ins> # Change magnus-opus version to upstream so that it does not use # vcpkg for libopus since it does not work.

Discussion:
Steps to reproduce the behavior: rustdesk None
Should be fixed in , thanks if you can test it.
tested and it works! Will close once it gets merged lands on unstable.
Change:
inherit pname version; src = { <del> "x86_64-linux" = fetchurl { url = "https://downloads.realvnc.com/download/file/viewer.files/VNC-Viewer-${finalAttrs.version}-Linux-x64.rpm"; </del> <ins> "x86_64-linux" = requireFile rec { name = "VNC-Viewer-${finalAttrs.version}-Linux-x64.rpm"; url = "https://downloads.realvnc.com/download/file/viewer.files/${name}"; </ins> sha256 = "sha256-Ull9iNi8NxB12YwEThWE0P9k1xOV2LZnebuRrVH/zwI="; <ins> message= '' vnc-viewer can be downloaded from ${url}, but the download link require captcha, thus if you wish to use this application, you need to download it manually and use follow command to add downloaded files into nix-store $ nix-prefetch-url --type sha256 file:///path/to/${name} ''; </ins> }; }.${stdenv.system} or (throw "Unsupported system: ${stdenv.hostPlatform.system}");

Discussion:
Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
there is now a captcha on the page at "" <img width="381" alt="image" src=""
Looks like it's the original website request captcha, I've submitted a PR to prompt it.
The captcha seems to have been removed.